Zmíněné RFC 6106 najdete zde: RFC 6106
IPv6 definuje dva způsoby automatické konfigurace síťových parametrů: Stavový (čili DHCP), kdy konfigurační parametry přiděluje DHCP server, a jednodušší bezstavový, při němž si své síťové rozhraní konfiguruje každý sám na základě ohlášení zasílaných místními směrovači.
Hlavní devizou bezstavové konfigurace je jednoduchost. Stačí nastavit směrovači IPv6 adresu pro dané rozhraní a případně zapnout její ohlašování, pokud to není implicitní stav. Server pak v pravidelných intervalech (a případně i na žádost) posílá do připojené sítě ohlášení směrovače (router advertisement, RA), ve kterém typicky sděluje:
-
Adresy v této podsíti mají následující prefixy.
-
Můžete mě používat jako implicitní směrovač, a to po dobu X sekund.
Připojené stanice si k ohlášenému prefixu (či několika prefixům) připojí svůj identifikátor rozhraní a získají tak platnou IPv6 adresu. Zároveň si jsou schopny vytvořit alespoň jednoduchou směrovací tabulku, kdy všechny pakety směřující mimo danou podsíť předávají některému z implicitních směrovačů – ohlášení může totiž přicházet od více strojů. Ve většině koncových sítí je však směrovač jen jeden a bezstavová konfigurace je zcela dostačující pro základní nastavení síťování.
Doposud jí ale chyběla jedna podstatná věc – DNS. Bez schopnosti převádět doménová jména na IP adresy nemůže stroj v Internetu rozumně existovat. A v IPv6 Internetu s jeho strašlivými adresami dvojnásob.
O problému se samozřejmě vědělo a již před časem jsme vás v samostatném článku informovali o zvažovaných alternativách jeho řešení. Jedinou oficiálně funkční a doporučovanou variantou byla kombinace bezstavové automatické konfigurace s bezstavovým DHCPv6, které jí doplnilo chybějící údaje, čili adresy místních DNS serverů a případně přípony doménových jmen k prohledávání.
Bezstavová konfigurace s touto možností počítá, dokonce pro ni obsahuje samostatný příznak „adresu si nastav sám a ostatní údaje si obstarej pomocí DHCP“. Jen je poněkud otravné kvůli tomu provozovat a konfigurovat další server. Lepší by bylo, kdyby bezstavová konfigurace uměla dodat i základní údaje pro DNS a po DHCP jsme museli sahat jen pro rafinovanější věci.
RFC 6106 směřuje k tomuto cíli. Nový standard definuje dvě nové volby pro ohlášení směrovače:
-
RDNSS (Recursive DNS Server) ohlašuje IPv6 adresy rekurzivních serverů obsluhujících místní klienty. Součástí jedné volby může být libovolný počet adres, proti původním návrhům z ní zmizela priorita a zůstala pouze životnost, která je pro všechny servery stejná. Ovšem ohlášení může obsahovat několik voleb RDNSS, díky nimž lze přiřadit různým adresám odlišné životnosti.
Tato volba není nová. Její návrh obsahovalo již RFC 5006, které ovšem mělo pouze experimentální statut. RFC 6106 je nahrazuje a směřuje k internetovému standardu.
-
DNSSL (DNS Search List) obsahuje seznam přípon, které má klient zkusit připojit na konec doménového jména, pokud se nedaří najít odpověď. Díky tomu lze zadávat nekompletní jména, třeba jen www. Na rozdíl od RNDSS tato informace není nezbytná, jen uživatelům poněkud usnadňuje život. Autoři ji zařadili zejména z toho důvodu, že je obsažena i v DHCP a chtěli, aby oba mechanismy nabídly v oblasti DNS srovnatelné možnosti. Také DNSSL může obsahovat několik přípon a stanoví jim společnou životnost. Na rozdíl od RDNSS je volba DNSSL novinkou, dřívější specifikace ji neobsahovala.
Na základě informací z ohlášení směrovače si klienti budou udržovat dva seznamy – jeden obsahuje adresy místních rekurzivních serverů, druhý prohledávané přípony doménových jmen. Každé další ohlášení směrovače se do nich promítne:
-
Údaje, které měly v ohlášení nulovou životnost, budou ze seznamu vymazány. Životnost 0 oznamuje, že dotyčný server (či příponu) již nelze dále používat.
Stejný osud je čeká, pokud jejich životnost jednoduše vypršela a nebyla prodloužena. RFC 6106 povoluje položku používat, jen dokud nevypršela její vlastní životnost ani životnost odesílajícího směrovače jako implicitního (která de facto hraje roli životnosti jeho ohlášení).
-
U ostatních, které již seznam obsahuje, bude aktualizována životnost podle aktuálního oznámení.
-
Nové informace budou přidány do seznamu. RFC zároveň požaduje, aby byl jako systémový parametr nastaven jejich dostatečný počet (a zároveň pro něj doporučuje hodnotu 3). Pokud délka seznamu překročí doporučenou mez, budou z něj smazány položky s nejkratší životností. Je žádoucí, aby k tomu docházelo jen výjimečně – od nestabilních a stále se měnících seznamů se nedá čekat nic dobrého. Lze tedy doporučit neposílat klientům více než tři položky do každého ze seznamů.
Situaci ještě komplikuje, že lze spojovat několik konfiguračních protokolů. Klient se některé údaje může dozvědět z ohlášení směrovače, jiné z DHCPv6. Pro takový případ RFC 6106 doporučuje, aby si klient ponechal nějaké údaje z každého použitého mechanismu – pokud by se některý zbláznil nebo byl napaden, aby mu zbyly alespoň nějaké příčetné informace získané jinou cestou. Dále požaduje, aby pořadí informací v používaných seznamech dodržovalo následující priority:
DHCPv6>RA chráněné SEND>nechráněné RA
RFC 6106 je zcela nové, vyšlo v listopadu. Na implementace si budeme muset chvíli počkat. Lze ale očekávat, že se objeví. Bezstavovou automatickou konfiguraci podporují snad všechny implementace IPv6 a DNS je jejím velmi žádoucím a zároveň jednoduchým doplňkem. Předpokládám, že autoři budou mít zájem svůj software tento nový trik naučit.
