Vyšla definice NAT64

Stručně připomeňme historii, která k němu vedla. Již v raných fázích vývoje IPv6 bylo zřejmé, že je třeba zpřístupnit uživatelům nového protokolu služby, které jsou poskytovány protokolem starým (a pokud možno i naopak). Proto vznikla specifikace SIIT (RFC 2765) definující základní pravidla pro vzájemný převod datagramů a jako jeden z jejích významných uživatelů mechanismus NAT-PT (RFC 2766), který doplňoval mapování adres.

NAT-PT se snažil o oboustrannou průchodnost – umožňoval navázat komunikaci jak z IPv4 strany, tak z IPv6 strany. První případ je výrazně těžší a vyžadoval poměrně drsné manipulace s DNS, jež navíc musely být synchronizovány se stavem tabulky pro mapování adres. Důsledkem byla řada provozních problémů, jimiž NAT-PT trpěl a kvůli nimž byl později vRFC 4966 zavržen. V jeho závěru se píše, že překlad mezi IPv6 a IPv4 může být užitečný (což je silný eufemismus) a že se určitá omezená verze NAT-PT může v budoucnu znovu objevit. Což je přesně to, k čemu nyní dochází pod názvem NAT64.

IETF nyní vydalo celkem čtyři vzájemně související dokumenty:

• Framework for IPv4/IPv6 Translation (RFC 6144) popisuje obecné požadavky na překlad protokolů, možné způsoby řešení a scénáře pro jejich použití. Zároveň konstatuje, že pro některé scénáře (např. propojení obecného IPv4 Internetu s IPv6 Internetem) zatím nemáme použitelné řešení.

• IP/ICMP Translation Algorithm (RFC 6145) nahrazuje původní SIIT a definuje pravidla pro vzájemný převod datagramů a ICMP zpráv z jednoho protokolu do druhého.

• Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers (RFC 6146) popisuje vlastní NAT64, zejména vzájemné převody adres a správu potřebných informací.

• DNS64: DNS Extensions for Network Address Translation from IPv6 Clients to IPv4 Servers (RFC 6147) obsahuje specifikaci algoritmu DNS64, který se používá v kombinaci s NAT64 pro zásahy do DNS.

Hlavním cílem NAT64 je umožnit připojení koncové IPv6 sítě k IPv4 Internetu a zpřístupnit místním klientům služby poskytované po IPv4. Jeho chování se do značné míry podobá NATům, jak je známe ze současných IPv4 sítí. Na rozdíl od nich se však neomezuje na změny adres, ale mění celý datagram, který překládá mezi oběma protokoly.

Vlastní překlad paketů je přesně a jednoznačně popsán v RFC 6145. NAT64 k němu přidává „nadstavbové“ prvky – zejména správu adres a filtrování.

Pro mapování adres používá dva zásadně odlišné principy. Překlad IPv4 adresy na IPv6 je velmi jednoduchý díky mnohonásobně většímu adresnímu prostoru IPv6. Jeho část v podobě prefixu délky obvykle 96 bitů (může být i kratší, ale je to zbytečné) se vyhradí pro reprezentaci IPv4 adres ve světě IPv6. Když je třeba IPv4 adresu převést na IPv6, jednoduše se připojí na konec určeného prefixu. Pokud se používá například prefix 64:ff9b::/96, adresa Lupy 91.213.160.123 se do IPv6 přeloží jako 64:ff9b::91.213­.160.123.

Tímto způsobem NAT64 překládá zdrojové adresy IPv4 paketů, které přeposílá do IPv6 sítě. A naopak pokud mu z IPv6 sítě dorazí datagram s takto vytvořenou cílovou adresou, jednoduše z ní vyzvedne cílovou IPv4 adresu pro odeslání do IPv4 sítě. Dotyčný prefix je v dokumentech označován jako Prefix64::/n a pro příslušné IPv6 adresy se používá pojem IPv4-převedené (IPv4-converted). Tento bezstavový přístup k mapování adres je popsán v RFC 6052, které definuje i standardní prefix 64:ff9b::/96 pro mapování. Jeho použití ale není povinné, v konfiguraci lze nastavit libovolný vhodný prefix, například z lokálního adresního prostoru.

Reprezentace IPv6 adres ve světe IPv4 nemůže být tak jednoduchá. Zde přichází ke slovu dynamicky udržovaná překladová tabulka, podobná tabulkám současných NATů. NAT64 překládá místní IPv6 adresy (v kombinaci s číslem UDP nebo TCP portu) na svou vlastní IPv4 adresu a vhodné číslo portu. Kdykoli z IPv6 sítě dorazí paket, který má být přeposlán do IPv4 (jeho cílová adresa je IPv4-převedená), vyhledá NAT64 v mapovací tabulce příslušnou položku pro jeho odesilatele – případně ji vytvoří – a podle ní vloží do odesílaného datagramu IPv4 adresu a číslo portu. Analogická procedura proběhne s cílovou adresou, když dorazí odpověď.

Mapovací tabulka dynamicky pracuje. Její položky vznikají, kdykoli některý klient z IPv6 sítě zahájí komunikaci do IPv4 Internetu a zanikají, pokud nejsou delší dobu používány. Specifikace NAT64 požaduje, aby si zařízení pro každý z podporovaných protokolů (UDP, TCP a ICMP) udržovalo hned dvě tabulky: jednu pro mapování adres (oficiálně nazývanou Binding Information Base, BIB) a druhou s aktivními relacemi, tedy probíhajícími komunikačními toky. Pokud pro určitou mapovací položku neexistuje žádná aktivní relace, bude odstraněna.

Kromě základních dynamicky spravovaných položek NAT64 počítá i s položkami statickými, které vloží správce zařízení a zůstávají v tabulce trvale. Jejich cílem je (v omezené míře) zpřístupnit místní IPv6 služby do IPv4 Internetu. NAT64 se zabývá i dalšími funkcemi, které si dnes s NATem spojujeme. Konkrétně mám na mysli případné filtrování či podporu vlásenek (hairpinning), kdy paket opustí zařízení stejným rozhraním, kterým dorazil. Podobně jako dnešní NATy se zařízení může chovat trychtýřově, kdy jednou vytvořené mapování IPv6 adresy zpřístupní všem zájemcům z IPv4, nebo omezeně, kdy propustí jen komunikaci z IPv4 zdroje, pro který má v tabulce relací aktivní záznam. Cílem volnějšího režimu je propustit různé peer-to-peer služby.

Výše jsem uvedl, že NAT64 je omezenou variantou dřívějšího NAT-PT. V čem omezení spočívá? Především v těchto dvou bodech:

• NAT64 je asymetrický. Komunikaci lze volně zahájit jen ze strany IPv6, v opačném směru pouze omezeně.
• Podporuje jen vybrané protokoly – aktuálně jen UDP, TCP a ICMP. Jakýkoli jiný protokol bude zahozen.

Zbývá zodpovědět otázku, jak IPv6 stanice přijde k IPv4-převedené adrese IPv4 zdroje. To je úkol pro DNS64 – cíle se obvykle identifikují jmény a malý švindl v DNS poskytne adresy ve vhodném tvaru. DNS64 bude nejčastěji implementováno v lokálním rekurzivním DNS serveru, který řeší dotazy místních klientů.

Dostane-li IPv6 klient doménové jméno, bude se shánět po záznamech typu AAAA. DNS64 tento dotaz nejprve předá, a pokud dostane kladnou odpověď, bez jakýchkoli úprav ji předá tazateli. Když ale řešení skončí chybou, která signalizuje, že poptávané jméno sice existuje, ale nejsou pro ně k dispozici žádné AAAA záznamy, zkusí DNS64 poptat ještě záznamy typu A, tedy IPv4 adresy. Příchozí odpověď pak převede na IPv6 – typ záznamů změní na AAAA a k adresám přidá Prefix64::/n. Spolupracující NAT64 a DNS64 musí samozřejmě používat stejný prefix pro reprezentaci IPv4 adres a směrování musí zajistit, aby IPv6 datagramy mířící na IPv4-převedené adresy procházely NAT64 zařízením.

DNS64 mění obsah záznamů, proto má z principu problém s DNSSEC. Dokud se klient o DNSSEC nestará, nebo ponechá jeho ověření na rekurzivním DNS serveru, nevznikne problém. Jestliže si ale chce vše ověřit sám (nastaví v dotazu příznak CD) bude DNS64 fungovat, jen pokud je podporuje i klient a dokáže reprodukovat změny provedené DNS64 serverem. V opačném případě skončí ověření neúspěšně.

Základní stavební kameny jsou tedy k dispozici, zbývá otázka motivace – kdo a proč by měl NAT64 používat. Neočekávám, že by se hojně objevoval tam, kde jsme si zvykli vídat IPv4 NAT, tedy v domácích směrovačích. NAT64 ke své funkci potřebuje veřejnou IPv4 adresu a když už poskytovatel tuto službu dovede až ke koncové síti, bude zřejmě pro všechny strany jednodušší vsadit na současné řešení: V domácí síti nasadit oba protokoly, pro IPv4 použít neveřejné adresy a překládat je konvenčním NATem. Varianta čisté domácí IPv6 sítě s NAT64 na vstupu těžko nabídne nějaké výhody.

NAT64 lze spíše očekávat na úrovni poskytovatele, kterému umožní postavit pro zákazníky IPv6 síť a pomocí centrálního NAT64 jim zpřístupnit IPv4 Internet. Nemusí mu přidělit jen jednu veřejnou IPv4 adresu, ale celou sadu. Její využití bude rozhodně efektivnější, než kdyby jednotlivé adresy přiděloval konkrétním zákazníkům.

Pokud byste si chtěli na NAT64 osobně sáhnout, můžete již dnes. Přestože jsou oficiální specifikace ještě teplé, existuje řada implementací, například Ecdysis, TAYGA, Microsoft UAG či Juniper.Cisco na ní teprve pracuje a nabízí zatím jen malou část potřebných dovedností.

Pro budoucnost IPv6 je podle mého soudu přístup k IPv4 službám klíčový. Z tohoto pohledu považuji přijetí NAT64 za velmi významný krok vpřed.