Dotaz: Jak na DHCPv6

[Zapik]

Zdravím, pokouším se rozjet IPv6 a trochu bojuji s DHCP. Aktuálně mám na routeru (Raspbian 9 Stretch - ano, musím tunelovat přes HE) rozjetý RADVD, který funguje jak má. Nicméně, chtěl jsem zkusit DHCPv6 ze 2 důvodů - abych v logu měl kdo má jakou adresu ale hlavně kvůli aktualizaci DNS.

V Stretchi (Debian 9) už je plná podpora a připravené konfigy. DHCPv6 se rozjel a zdá se že to i něco dělá. Nicméně pokud vypnu RADVD, tak adresu nedostanu.

Na druhou stranu se v logu objevuje například:

Nov 16 06:45:15 pi dhcpd[1108]: Advertise NA: address 2001:470:5c44:0:e291:23d2:5fe7:2c9e to client with duid 00:01:00:01:20:f4:d6:8e:60:45:cb:62:ea:76 iaid = 39863755 valid for 2592000 seconds Nov 16 06:45:15 pi dhcpd[1108]: Sending Advertise to fe80::c515:3434:dea9:2f2c port 546 Nov 16 06:45:16 pi dhcpd[1108]: Request message from fe80::c515:3434:dea9:2f2c port 546, transaction ID 0x8CE0D600 Nov 16 06:45:16 pi dhcpd[1108]: Reply NA: address 2001:470:5c44:0:e291:23d2:5fe7:2c9e to client with duid 00:01:00:01:20:f4:d6:8e:60:45:cb:62:ea:76 iaid = 39863755 valid for 2592000 seconds Nov 16 06:45:16 pi dhcpd[1108]: Sending Reply to fe80::c515:3434:dea9:2f2c port 546 Nov 16 06:45:20 pi dhcpd[1108]: Release message from fe80::c515:3434:dea9:2f2c port 546, transaction ID 0x88B9C00 Nov 16 06:45:20 pi dhcpd[1108]: Client 00:01:00:01:20:f4:d6:8e:60:45:cb:62:ea:76 releases address 2001:470:5c44:0:e291:23d2:5fe7:2c9e Nov 16 06:45:20 pi dhcpd[1108]: Sending Reply to fe80::c515:3434:dea9:2f2c port 546 Nov 16 06:45:20 pi dhcpd[1108]: Information-request message from fe80::c515:3434:dea9:2f2c port 546, transaction ID 0xECEB1700 Nov 16 06:45:20 pi dhcpd[1108]: Sending Reply to fe80::c515:3434:dea9:2f2c port 546

Takže nějak to žije, ale chybí mi tam ztotoženění MAC adresy s výslednou IPv6 (nebo to už nedostanu?). A hlavně důvod proč můj NB bez RADVD nedostane IPV6 adresu. V logu se neobjeví ani čárka, jak kdyby se neptal.

Díky Petr

Odpovědi

[1john2]

pouzijte prosim zncacky pre pro ten vypis, tohle se neda cist.

Jak vypada

- ip -6 r s

- ip -6 a s

[Zapik]

Pardon, v náhledu to vypadalo OK.

Nov 16 06:45:15 pi dhcpd[1108]: Sending Advertise to fe80::c515:3434:dea9:2f2c port 546
Nov 16 06:45:16 pi dhcpd[1108]: Request message from fe80::c515:3434:dea9:2f2c port 546, transaction ID 0x8CE0D600
Nov 16 06:45:16 pi dhcpd[1108]: Reply NA: address 2001:470:5c44:0:e291:23d2:5fe7:2c9e to client with duid 00:01:00:01:20:f4:d6:8e:60:45:cb:62:ea:76 iaid = 39863755 valid for 2592000 seconds
Nov 16 06:45:16 pi dhcpd[1108]: Sending Reply to fe80::c515:3434:dea9:2f2c port 546
Nov 16 06:45:20 pi dhcpd[1108]: Release message from fe80::c515:3434:dea9:2f2c port 546, transaction ID 0x88B9C00
Nov 16 06:45:20 pi dhcpd[1108]: Client 00:01:00:01:20:f4:d6:8e:60:45:cb:62:ea:76 releases address 2001:470:5c44:0:e291:23d2:5fe7:2c9e
Nov 16 06:45:20 pi dhcpd[1108]: Sending Reply to fe80::c515:3434:dea9:2f2c port 546
Nov 16 06:45:20 pi dhcpd[1108]: Information-request message from fe80::c515:3434:dea9:2f2c port 546, transaction ID 0xECEB1700
Nov 16 06:45:20 pi dhcpd[1108]: Sending Reply to fe80::c515:3434:dea9:2f2c port 546

ip -6 r s:

2001:470:6e:bd9::1 dev he-ipv6 metric 1024  pref medium
2001:470:6e:bd9::/64 dev he-ipv6 proto kernel metric 256  pref medium
2001:470:5c44::/64 dev eth0 proto kernel metric 256  pref medium
fe80::/64 dev eth0 proto kernel metric 256  pref medium
fe80::/64 dev he-ipv6 proto kernel metric 256  pref medium
default via 2001:470:6e:bd9::1 dev he-ipv6 metric 1024  pref medium

ip -6 a s:

1: lo: LOOPBACK,UP,LOWER_UP mtu 65536 state UNKNOWN qlen 1
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 state UP qlen 1000
    inet6 2001:470:5c44::1/64 scope global 
       valid_lft forever preferred_lft forever
    inet6 fe80::ba27:ebff:fed5:413b/64 scope link 
       valid_lft forever preferred_lft forever
4: he-ipv6@NONE: POINTOPOINT,NOARP,UP,LOWER_UP mtu 1480 state UNKNOWN qlen 1
    inet6 2001:470:6e:bd9::2/64 scope global 
       valid_lft forever preferred_lft forever
    inet6 fe80::c0a8:138/64 scope link 
       valid_lft forever preferred_lft forever

Díky za zájem

[elenril]

Bez radvd (nebo jeho obdoby) se neobejdeš - tak je to zkrátka designované. Každý router MUSÍ posílat router advertisement (RA) zcela nezávisle na tom jestli v té síti nějaké DHCP je nebo není. Ta RA se ale nemusí používat na konfiguraci adres - stačí vypnout AdvAutonomous (pak je dobré zapnout AdvManagedFlag a AdvOtherConfigFlag) v konfiguraci radvd.

[Zapik]

Aha, domníval jsem se tak nějak selským rozumem, že DHCP se taktéž postará o RA. Díky za nakopnutí, podívám se na ty 2 parametry.

Petr

[Skokan, Pavel]

nesnažte se stavět síť na IPv6 dle toho jak to máte naučené z IPv4 sítí...

https://www.root.cz/knihy/internetovy-protokol-ipv6-treti-vydani/

[Zapik]

Obecně se nesnažím, resp. většinou odlišnosti tuším, ale v drobných detailech se člověk občas zapomene. A to DHCPv6 je jedna z oblastí, ke které jsem nenašel nějakou hloubkovou dokumentaci, resp filozofický popis v návaznosti na další části skládanky.

[lertimir]

Satrapova kniha je velmi hezká.

[petr_p]

V DHCPv6 se MAC adresy nepoužívají. Místo nich je DUID. To je ten dlouhý šestnáctkový řetězec. Měl to být náhodný identifikátor, který si klient vymyslí, zapamatuje a pak kdykoliv a přes reboot jej posílá serveru. Ukládání ani náhodnost se nelíbila některým lidem, tak byly standardizovány tři metody vytváření DUID, z nichž jedna je založena na sériovém čísle klienta, což může být třeba jeho MAC adresa. Je třeba ale v klientovi nastavit, aby použil metodu založenou na MAC adrese (pokud to umí). Více v RFC 3315.

[Zapik]

Ještě mám doplňující dotaz, jeden z hlavních důvodů proč jsem chtěl DHCPv6 je aktualizace DNS, pro 4 to mám nastaveno a je to pohodlné se odvolávat na názvy. Ale v logu DHCPv4 vidím i názvy což pro 6 nevidím. Otázka je, umí DHCPv6 aktualizaovat DNS a zapisovat tam názvy zařízení? Dík

[elenril]

Samotný protokol DHCP (a to jak v4 tak v6) nic takového neřeší, takže tahle otázka striktně řečeno nedává smysl. Asi se ptáš, jestli tohle umí nějaký konkrétní DHCPv6 server. Já používám ISC a ten to rozhodně umí, i když to není úplně spolehlivé --- občas po nějakém klientovi neuklidí a pak se to musí udělat ručně.

[petr_p]

Doporučuji Dibbler User's Guide (PDF), kde je DHCPv6 včetně DNS updates vysvětleno na nastavení Bindu a Dibblera (výzkumná implementace DHCPv6). Obrázky a ukázky konfiguračních souborů obsaženy.

[Sten]

To DNS je potřeba s globální dostupností? Pokud stačí lokální, tak mDNS tohle řeší.

[erotel]

Kea dhcp server umí IPV6 adresu přidělit podle MAC.

[lertimir]

No myslím, že je základně chybně pracovat podle konceptu, který neodpovídá normě. Když si na to zvyknu nebude to fungovat ve spolupráci s jinými DHCP servery, jako v LEDE/openWRT, cisco, bind atd.

[erotel]

Ano to je pravda,jenže v některých situacích je přidělování podle mac nejlepší volbou.V domácím prostředí asi ne,ale na síti,kde přidělujeme prefix koncovým uživatelům to jinak nejde.Zvláště pokud "chytré" zařízení po každém restartu má jiné IAID nebo nedej bože DUID.

[elenril]

Zvláště pokud "chytré" zařízení po každém restartu má jiné IAID nebo nedej bože DUID.

To jsou ovšem rozbitá zařízení která neodpovídají standardu. Jediná rozumná věc co se s nimi dá dělat je nekupovat je.

A když už jsme u toho - zná někdo nějaký mechanismus na autentizaci DHCPv6 klientů? Např. pokud je v síti něco jako 802.1x, tak aby každý klient směl používat jen to svoje správné DUID a nemohl se vydávat za někoho jiného. Umí něco takového nějaké switche?

[Vantomas]

A zařízení co inkrementuje IAID podle pořadí ve kterém byl interface vytvořen/nastaven, je zařízení rozbité nebo funkční?

[elenril]

RFC 3315 sekce 10 říká

For any given use of an IA by the client, the IAID for that IA MUST be consistent across restarts of the DHCP client.

Moje naivní interpretace tohoto je taková, že daná krabička s danou konfigurací má pro daný fyzický interface vždy produkovat stejné IAID. Ale přiznám se, že moc zkušeností s tím nemám, pro moje malé potřeby stačí přidělovat podle DUID.

[Vantomas]

No jde třeba o to, že různým domácím routerům se mění IAID napříč factory resety. Takže dochází k tomu, že člověk si to nastaví, půl roku mu to funguje, pak si chce změnit heslo na wifi, protože zapomněl heslo do administrace, tak udělá factory reset a problém je na světě.

Bohužel Mikrotik, kde se s DHCPv6 serverem setkávám, statický lease jen proti DUID neumí a trvá i na IAID. Nevím tedy zda je to jen problém konkrétní implementace nebo je to takto vyžadováno, ale z tohoto pohledu to rozhodně není vhodné a v tomto usecase bych jendoduchou vazbu proti MAC ocenil.

[Sten]

To se většinou řeší tak, že DHCP server přiděluje IP adresy podle MAC a informací z 802.1x a DUID ignoruje.

[elenril]

S tím, že switch enforcuje vazbu "802.1x identita"<->MAC?

[Sten]

To by měl dělat vždy, jinak 802.1x trochu ztrácí smysl

[j]

Samozrejme ze to jde, pokud se pouzije prislusna k (mimo jine) tomu urcena sitova autentizace, coz pochopitelne vyzaduje odpovidajici sitova prvky. MAC je identifikator nanic i v ipv4. Jednak si ho muze kazdy zmenit, druhak sem uz mel v ruce hromadku krabicek, a vsechny mely MAC stejnou.

[vandrovnik]

Víc krabiček se stejnou MAC adresou - to pak asi na jednom síťovém segmentu moc nekomunikovaly, ne?

[j]

Tak ono to slo zmenit (preflashnout), ale takhle sem je dostal z "vyroby" a jako zajimavost, co vsechno taky soudruzi v cine vyrobej - okopirovali to teda dokonale.