Přibližně před rokem jsme vás informovali o zavržení NAT-PT, který byl dlouhá léta považován za nejnadějnější řešení problému vzájemné komunikace mezi IPv4 a IPv6. Dočkal se i několika implementací, z nichž nejvýznamnější je nepochybně ta ve směrovačích Cisco, ovšem míra jeho nasazení zaostala za očekáváním. (Ovšem, ruku na srdce, to se dá prohlásit o celém IPv6.)
RFC 4966, které NAT-PT poslalo na smetiště dějin, v závěru uvádí jako jeho alternativy BIS či aplikační proxy servery. BIS (Bump in the Stack) či BIA (Bump in the API) je v podstatě soukromý NAT, kdy mapování adres a překlad datagramů probíhá uvnitř počítače. Jeho podstatnou nevýhodou je, že zatímco jeden směrovač realizující NAT-PT obslouží celou koncovou síť, BIS je třeba implementovat a nastavit v každém jednotlivém počítači. Aplikační proxy servery jsou společné, ale jednoúčelové a navíc s nimi aplikace musí vědomě spolupracovat. Vyžadují zpravidla úpravu konfigurace na koncových stanicích, navíc rozptýlenou do řady aplikací.
Praktičnost společného transparentního řešení, jakým je NAT-PT, pěkně demonstrovalo vypnutí IPv4 během jarního RIPE Meetingu. Běžné služby fungovaly v čisté IPv6 síti normálně, přestože řada serverů, které je poskytují, hovoří pouze IPv4. IETF po vyhlášení NAT-PT za historický čelí kritice, že opustilo užitečný mechanismus, navíc v nejpalčivější oblasti vzájemné kompatibility mezi IPv4 a IPv6, kde je o jakákoli řešení značná nouze.
Ovšem když NAT-PT dveřmi vyhodíte, oknem se vám vrátí NAT64. RFC 4966 ve svém závěru připouští jeho možnou reinkarnaci v upravené podobě, a právě to se v současné době děje. NAT64 se samozřejmě snaží vyhnout problémům, které vedly k odmítnutí NAT-PT. Dělá to jednak omezením svých funkcí (NAT-PT byl obousměrný, v NAT64 se komunikace navazuje jen z IPv6 sítě do IPv4), jednak rozšířením DNS o indikaci uměle vytvořených záznamů.
Základní princip NAT64 se shoduje s jeho předchůdcem. Mezi koncovou IPv6 sítí a IPv4 Internetem je umístěno zařízení, které překládá jeden protokol na druhý (podle pravidel SIIT, jiná ani nejsou) a zároveň mapuje adresy. Pro reprezentaci IPv4 adres v IPv6 síti používá statické bezstavové mapování. NAT64 zařízení má správcem sítě přidělen jeden IPv6 prefix délky 96 bitů z rozsahu zdejší sítě a venkovní IPv4 adresu jednoduše připojí za něj. Pokud například používá prefix 2001:db8:aa:ee::/96 a dorazí IPv4 datagram z adresy 1.2.3.4, bude do vnitřní sítě předán jako IPv6 datagram odeslaný z adresy 2001:db8:aa:ee::0102:0304. Standardní směrovací mechanismy pak zařídí pro datagramy v opačném směru, jejichž cíl má prefix pro NAT64, aby se posílaly překladači.
Mapování IPv6 adres na IPv4 při odesílání do běžného Internetu je složitější, protože adres je nedostatek a překladač má často k dispozici jen jednu, nanejvýš několik málo IPv4 adres. Dvojice IPv6 adresa+port se pak mapuje na dvojici IPv4 adresa+port, která obsahuje některou z globálních IPv4 adres překladače. Mapování se řídí podobnými pravidly jako u současných IPv4 NATů. Vazba mezi IPv6 a IPv4 dvojicemi se vytváří dynamicky v okamžiku, kdy místní IPv6 stroj odešle první datagram směřující do IPv4 sítě. Následně ji mohou využívat datagramy proudící oběma směry a pokud komunikace ustane, po vypršení určitého času bude odstraněna. IPv4 dvojici pak lze využít pro jinou komunikaci.
NAT64 musí být doprovázeno manipulací s DNS, protože počítače z koncové IPv6 sítě budou ve svých DNS dotazech nepochybně shánět záznamy typu AAAA, zatímco adresy strojů podporujících pouze IPv4 jsou uloženy v záznamech typu A. Místní DNS server, na nějž se obracejí zdejší IPv6 počítače, by měl podporovat algoritmus označený jako DNS64. Pokusí se nejprve získat záznam AAAA. Pokud neuspěje, zeptá se na záznam typu A pro stejné jméno. Jestliže na něj dostane odpověď, připojí IPv4 adresu z něj k místnímu prefixu pro NAT64 a vytvoří tak adresu zapadající do výše popsaného schématu. Tu ve své odpovědi dostane místní počítač, odešle na ni datagram, jenž díky směrovacím tabulkám dorazí k NAT64 překladači. Zde se vytvoří mapování pro jeho odesilatele, datagram se přeloží do IPv4 a odešle se do Internetu.
Nejzávažnější problémy NAT-PT byly svázány právě s úpravami DNS. Ovšem v jeho případě byl překlad obousměrný – počítače z IPv4 Internetu mohly získat adresy zdejších serverů. Součástí vyřízení takového dotazu byl převod mezi záznamy A a AAAA a také mapování adres. Komunikace díky tomu mohla být zahájena i zvenčí, ale na druhou stranu se otevíral prostor pro různé nekonzistence a karamboly. NAT64/DNS64 tuto možnost nepřipouští, mapuje pouze dotazy směřující z koncové IPv6 sítě do IPv4 Internetu. Navíc své upravené odpovědi označuje nově přidanou volbou Status of Answer Section (SAS). Díky ní může klient poznat, že se jedná o synteticky vytvořenou odpověď a přizpůsobit své chování.
NAT64 zatím teprve vzniká. Jeho současnou podobu definuje draft-bagnulo-behave-nat64–01, v němž najdete i rozebraný postup navázání komunikace mezi koncovým počítačem a serverem v Internetu, dopady na bezpečnostní mechanismy a řadu dalších informací.
Mechanismus, který transparentně (i když s řadou omezení) zprostředkuje výměnu dat mezi IPv4 a IPv6, je nepochybně žádoucí. NAT64 je poměrně jednoduchý a má šanci dočkat se většího počtu implementací než NAT-PT. Určitý problém vidím v jeho jednosměrnosti. Ta nevadí při řešení aktuálního problému – zpřístupnit IPv6 strojům zdroje v IPv4 Internetu. Ostatně většina instalací NAT-PT sloužila právě k tomuto účelu. Jednosměrnost bude ale odrazovat od poskytování služeb po IPv6, protože se k nim IPv4 klienti nedostanou.
Z pohledu vizionáře je to dobře, protože služby dostupné jen po IPv6 budou motivovat klienty k přechodu na nový protokol. Pragmatik ovšem nechce poskytovat službu bez uživatelů, a proto ji bude nabídne po IPv4. A Internet je jedním obrovským důkazem síly pragmatických řešení…
ČLÁNKY DO MAILU