Stav DHCPv6 na světových tocích

Stručně připomenu, že IPv6 nabízí dva modely automatické konfigurace stanic: bezstavovou a stavovou. Bezstavová je zabudována přímo do samotného IPv6 a nevyžaduje žádné speciální servery ani doplňkové mechanismy. Podle ní si spodní polovinu adresy určí počítač sám jednoduchou úpravou své linkové adresy. Z ethernetové a­dresy

00:04:76:47:8E:81

vytvoří

0204:76FF:FE47:8E81

(doprostřed vloží FFFE, aby původních 48 bitů natáhl na 64, a invertuje druhý bit prvního bajtu). Horní polovinu se dozví z ohlášení směrovačů, které každý směrovač posílá do sítí, k nimž je připojen. Složí obě poloviny a dostane globální IPv6 adresu, aniž by kdo co musel konfigurovat nebo se o něco starat. Ohlášení směrovače obsahuje zároveň informaci o tom, zda dotyčný směrovač lze použít jako implicitní.

Bezstavová konfigurace tedy naučí počítač směrovat – sdělí mu jeho adresu, masku podsítě (to je ryzí formalita, pokud se nedějí strašné věci, je adresa podsítě vždy 64 bitů dlouhá) a implicitní směrovač(e).

K čemu tedy stavovou konfiguraci čili DHCP? Například k nastavení prvků, které v bezstavové chybí. Nejvýznamnější z nich je nepochybně DNS. Bezstavová konfiguraci nesdělí počítači nic o tom, kde je jeho nejbližší DNS server a kam se tedy obracet s DNS dotazy.

Vedle něj může DHCP poskytnout i řadu dalších doplňujících informací, jako třeba lokální doménu, adresu NTP serveru pro synchronizaci času či konfiguraci dalších protokolů. Další důvody pro nasazení DHCP mohou ležet mimo technologickou oblast. Například může odporovat charakteru instituce, aby fungoval kterýkoli počítač, který si zrovna někdo přinesl a zapojil do sítě. Správce sítě může požadovat kontrolu nad přidělováním adres.

Zajímavou variantu představuje současné použití obou autokonfiguračních mechanismů – bezstavového pro přidělení adresy a stavového pro ostatní informace. Tento přístup podstatně zjednodušuje život DHCP serveru, který se nestará o adresy. Díky tomu si nemusí uchovávat stavové informace (nemusí si pamatovat, komu co a do kdy přidělil), což významně usnadňuje implementaci. Tento přístup byl pojmenován „bezstavové DHCP“. Předpokládá se, že právě toto by mohl být většinový způsob nasazení DHCPv6.

Pořadové číslo 28 u aktuálního návrhu DHCPv6 jasně naznačuje, jak dlouhý a bolestný proces vzniku má za sebou. Skutečnost, že většina současných implementací podporuje nižší než 20, zase dokazuje, že implementátorům prostě došla trpělivost. Velmi dobrou zprávou v tomto kontextu je, že v prosinci 2002 získal zmíněný návrh statut navrženého standardu (proposed standard) a že by se měl v nejbližší době ustálit do podoby RFC.

Co se změnilo? Základ pochopitelně zůstal stejný. Kdesi v lokální síti je server (či několik serverů) s databází informací. Klient jej v první fázi vyhledá a ve druhé pak osloví se žádostí o konfigurační parametry. Pokud pro něj server má potřebné údaje, dodá mu je. Adresy se propůjčují na omezenou dobu, klient může požádat o prodloužení.

Změnou, která je nabíledni, je adresování. Jedno rozhraní může mít přehršel IPv6 adres a DHCPv6 server jich tedy může poslat celou řadu. Také adresa klienta se liší, protože v IPv6 si každý stroj může sám přidělit lokální linkovou adresu (která platí jen v rámci linky, tedy k nejbližšímu směrovači). Právě tu používá při komunikaci se serverem.

Významně se změnily též vnitřní formality protokolu. Formát DHCP zprávy byl zjednodušen až na naprosté minimum – povinnými položkami jsou jen typ zprávy a identifikátor transakce. Vše ostatní bylo odsunuto do voleb.

K identifikaci klienta nyní slouží tak zvaný DHCP Unique Identifier (DUID), který by v ideálním případě měl zůstat stejný i po změně síťové karty. Uvažuje se o identifikátorech přidělených výrobcem či o identifikátorech, které si počítač jednou vygeneruje, uloží do trvalé paměti a nadále bude používat během celé své existence. Realisticky se však připouští i identifikátor založený na hardwarové adrese karty jako jeden z možných druhů DUID.

V rámci klienta se pak jednotlivé karty identifikují prostřednictvím Identity Association (IA). IA v podstatě reprezentuje balíček konfiguračních informací přidělených danému rozhraní.

Zkrátka vše je obecnější, ale také jaksi rozplizlejší a méně konkrétní. Určitou představu poskytne i prosté srovnání rozsahu definic. Zatímco RFC 2131 s definicí DHCPv4 měří něco málo přes 100 kB, draft-ietf-dhc-dhcpv6–28 měří zhruba dvojnásobek. A to ještě neobsahuje definice jednotlivých voleb, které mají své vlastní návrhy a dohromady přidají bratru dalších 100 KB.

Dlouho trvající vývoj a vyšší složitost výsledného návrhu vedly k nepříliš potěšujícímu stavu implementací. Právě jejich přehled je jádrem výše zmiňovaného dokumentu projektu 6NET. Velmi stručný přehled testovaných implementací a utrpěných výsledků vypadá následovně:

KAME (v prostředí FreeBSD)

Jediná alespoň trochu aktuální implementace (verze 26). Výsledek nelze nazvat jinak než jako legrační. Veškerá komunikace proběhla perfektně, klient dostal vše potřebné, až na to, že získané informace k ničemu nepoužil a nenastavil konfiguraci sítě.

KAME Linport

Výsledek snahy přenést KAME do Linuxu. DHCP klient však posílá nesmyslnou adresu, takže mu server nemůže odpovědět.

DHCPv6 pro INRIA implementaci

Dobře dopadla jen první fáze (hledání DHCP serverů). Klient pak nedokázal server oslovit se žádostí o konfigurační parametry.

DHCPv6 NetBSD pro Alpha64

Autoři neměli k dispozici stroj s Alpha procesorem. Pokusy o překlad pod Linuxem či FreeBSD byly neúspěšné.

Modifikovaná distribuce DHCP od IST, verze 3

Klient se zhroutil. Když jej nahradili jiným klientem, choval se server nekorektně.

DHCP pro HP-UX 11i

Výsledky testů chybí.

DHCP od Motorola Labs

Velmi experimentální. Řeší pouze přidělování adres.

Sečteno a podtrženo: pokud uvažujete o nasazení DHCPv6 ve vaší síti, neměli byste váhat a využít výhodné povánoční slevy ke koupi pevného provazu.

Abych ale nekončil tak depresivně, minulý týden se mi dostala do rukou zpráva o nové implementaci pro Linux. Dokonce vychází z poslední verze návrhu, tak se snad blýskne na lepší časy…