Hlavní navigace

IPv4 jako služba aneb jak síť zbavit dual-stacku

9. 6. 2014
Doba čtení: 7 minut

Sdílet

Jsou to už dva roky, co byl oficiálně odstartován obsah dostupný protokolem IPv6. Míček je teď na straně poskytovatelů připojení. Ti se vcelku oprávněně brání, že přidávání druhého protokolu do jejich stávající infrastruktury představuje náklady, které nikdo nezaplatí. Nešlo by to nějak jinak?

Zavedení IPv6 metodou dual-stack, tedy současný provoz protokolu IPv4 a IPv6, je často vnímáno jako jediný možný model přechodu na nový protokol. I když množství obsahu dostupného pomocí IPv6 stále narůstá, rozhodně ještě několik let nebude možné považovat síť bez podpory připojení i k IPv4 zdrojům za reálně použitelnou. Na druhé straně, stále prakticky neexistují služby, které by bez IPv6 konektivity nefungovaly.

Nasazení IPv6 metodou dual-stack tak v přístupové síti znamená jen mnoho práce, která problém s tenčící se zásobou IPv4 adres nevyřeší, nedá se moc dobře kompenzovat zvýšením ceny, ani nepřinese velké množství spokojených zákazníků. Existují proto i alternativy, které mají jedno společné: síť se jednoduše přepne na IPv6 bez podpory IPv4. Podpora spojení ke zdrojům, které IPv6 nepodporují je pak řešena jako jedna ze služeb sítě. O těchto metodách je dnešní článek.

NAT64 a DNS64

Každého jistě napadne, že při tak obrovském adresním prostoru, jakým disponuje protokol IPv6, není problém do nějaké části tohoto prostoru schovat celý IPv4 prostor. Přesně na této myšlence je založen koncept NAT64 (vyslovuje se NAT-šest-čtyři – pozn. redakce). Přístupová síť podporuje pouze IPv6, při odeslání paketu do speciálního podprostoru však takový paket dojde do zařízení, které jej přeloží na běžný IPv4 paket a odešle do IPv4 internetu. Adresní podprostor takto mapovaný do IPv4 světa může být součástí adresního prostoru provozovatele, nebo může jít o vyhrazený prefix  64:ff9b::/96


Mro, CC-BY-SA Wikimedia

Princip NAT64/DNS64

K tomu, aby se zařízení namísto k IPv4 připojovala k překládanému IPv6 prefixu, slouží úprava rekurzivního DNS severu. Ten pro dotaz na IPv6 adresu serveru, který takovou adresu nemá, uměle vytvoří odpověď mapující danou adresu do překládaného prefixu.

Známé rozšíření IPvFoo dokáže správně detekovat vyhrazený prefix a označit jej červenou barvou, i když jde o IPv6 provoz

NAT64 na vlastní kůži

Technologie NAT64 je v současnosti asi nejrozšířenějším způsobem eliminace dual-stacku. V běžném produkčním prostředí je už několik let nasazena u mobilních operátorů ve Slovinsku a USA, kteří jsou v nasazování IPv6 asi nejdál. WiFi síť s podporou NAT64 se také pravidelně objevuje na technologických konferencích jako RIPE nebo FOSDEM, kde dokonce taková síť přebrala roli hlavní konferenční WiFi sítě. Pozadu nezůstal ani CZ.NIC, který na své konferenci IT 14 podobně zařízenou IPv6-only WiFi síť provozoval na jednom routeru Turris, který zároveň prováděl NAT64 i DNS64.

Máte-li IPv6 konektivitu, můžete celkem snadno vyzkoušet, do jaké míry je řešení s NAT64 použitelné, aniž byste kamkoli jezdili. Stačí k tomu využít několik veřejně dostupných instalací NAT64, které provozuje Jan Žoržgo6Lab. Vypněte IPv4 protokol a jako rekurzivní DNS server nastavte některý uvedený na odkazované stránce. Pro adresy, které nejsou dostupné nativním IPv6, budete přesměrováni na NAT64 zařízení umístěné v go6Lab ve Slovinsku, které jej dále odbaví do IPv4 internetu.

Problémy čistého NAT64

Pokud síť s NAT64 vyzkoušíte, zjistíte, že funguje téměř všechno. Nefunkční případy můžeme rozdělit do následujících kategorií:

  • Zařízení předpokládá existenci IPv4 konektivity. To je třeba problém WiFi rozhraní všech zařízení s OS Android, včetně nejnovější verze 4.4.3.
  • Aplikace otvírá pouze IPv4 soket. Tak se například chová drtivá většina aplikací pro iOS.
  • Aplikace nepoužívá DNS, ale pracuje přímo s adresními literály. Typickým příkladem je Skype.

Řešení jménem 464XLAT

K odstranění výše uvedených problémů vznikl koncept 464XLAT. Ten popisuje plnohodnotný transport IPv4 protokolu IPv6 prostředím pomocí dvou překladačů, jednoho na straně providera (PLAT), který je totožný s NAT64/DNS64, druhého na straně zákazníka (CLAT). Právě druhý jmenovaný překladač sedí v blízkosti uživatele a řeší několik posledních případů, pro které NAT64 správně nefunguje. Může být implementován například jako mezivrstva v operačním systému, která se aktivuje, kdykoli se aplikace pokusí otevřít IPv4 soket, a transparentně požadavek obslouží skutečným IPv6 soketem namířeným do vyhrazeného IPv6 rozsahu. Druhá možnost spočívá v NAT64 algoritmu obráceném „naruby“, takže sbírá z klienta IPv4 provoz, překládá jej a posílá dále směrem k PLAT. Výhodou této možnosti je, že CLAT nemusí být implementován přímo v koncovém zařízení, ale třeba v domácím routeru. Domácí síť pak může běžet na obyčejném dual-stacku.

Jediný problém, který bylo potřeba vyřešit, aby se koncept 464XLAT stal použitelným, je automatická konfigurace CLATu. Při každém připojení do sítě je potřeba zjistit, zda je v síti přítomen PLAT a pokud ano, za jakým prefixem je schovaný IPv4 svět. Celý problém poměrně zeširoka popisuje RFC 7051, jedna z implementací je pak popsána v RFC 7050. Ta používá k objevení prefixu systém DNS: Zeptá se na IPv6 adresu dobře známého DNS jména ipv4only.arpa, ke kterému jsou přiřazeny IPv4 adresy 192.0.0.170 a 192.0.0.171. Dostane-li v odpovědi nějakou IPv6 adresu, znamená to, že v síti je zapojen PLAT a analýzou IPv6 adresy v odpovědi je možné zjistit, za jaký prefix je mapován IPv4 svět.

CLATy jsou přítomny v nejnovějších verzích OS Android, které pak jsou schopny u mobilních operátorů pracovat v režimu IPv6-only, aniž by některá aplikace poznala, že síť operátora ve skutečnosti IPv4 nepřenáší. CLAT si také můžete vyzkoušet na svém počítači, stačí nainstalovat clatd. Tento skript v Perlu provede objevení PLATu podle RFC 7050 a následně nakonfiguruje a spustí NAT64 překladač TAYGA. Od té chvíle bude fungovat vše stejně jako na síti s plnohodnotnou podporou IPv4, tedy například včetně příkazů ping nebo mosh, které IPv6 nepodporují.

Dual-Stack lite

NAT64 pochopitelně není jediná možnost, jak vytlačit souběžný provoz IPv4 i IPv6 z přístupové sítě. Za zmínku například stojí mechanizmus Dual-Stack lite, v současnosti provozovaný například u německého kabelového operátora Kabel Deutschland. V tomto režimu je domácí síť za zákaznickým routerem v obyčejném dual-stack režimu. IPv4 provoz na cestě do internetu je routerem zapouzdřen a poslán tunelem prostřednictvím IPv6 k NATu providera, který jej rozbalí a obslouží.


Mro, CC-BY-SA Wikimedia

Princip DS-lite

Mapping of Adddress and Port

Všechny předchozí metody mají jedno společné: vyžadují provádění překladu adres v jádru sítě nebo v jeho blízkosti. Taková řešení se obecně špatně škálují, neboť NAT musí ke každému spojení udržovat stavové informace. Navíc se tím podkopává základní myšlenka internetových sítí, totiž princip dumb core – smart edge, tedy inteligence umístěná na okraji a přenosová síť bez zvláštních schopností. Všechny výše popsané metody (včetně nepopisované metody obyčejného NATu IPv4 do IPv4 na straně ISP) navíc trpí jistým uživatelským nekomfortem, kdy uživatelé již nejsou schopni na svém koncovém zařízení přesměrovat určité číslo portu do své domácí sítě.

Oba tyto problémy řeší obsáhlá specifikace zvaná The Address plus Port (A+P) Approach to the IPv4 Address Shortage, kterou dále vyvíjí Cisco pod názvem MAP. Tento přechodový mechanismus eliminuje potřebu pro stavový NAT v jádru sítě; zároveň však umožňuje sdílení jedné IPv4 adresy několika zákazníky. Každý zákazník má k dispozici pouze omezené množství portů transportního protokolu, které jsou k jeho přípojce směrovány bezestavově. Router u zákazníka musí být upraven tak, aby pro komunikaci se zbytkem světa použil pouze jemu přidělený rozsah portů. Zákazník má ale plnou možnost nastavit pro některý z nich přesměrování do domácí sítě a tak mít určité domácí služby přístupně i po IPv4.

Příklad, jak rozdělit adresy mezi zákazníky, je možné simulovat ve webové aplikaci. Výše uvedený rozděluje 256 IPv4 adres mezi 65536 zákazníků. Každý zákazník má k dispozici 240 portů z dané IPv4 adresy. To, kterou IPv4 adresu a který rozsah portů může zákazník využívat, je zakódováno šestnáctibitovým číslem, které je součástí IPv6 prefixu zákazníka.

Podle způsobu, jakým se IPv4 provoz přenáší v přístupové IPv6 síti, se protokol MAP dále dělí na MAP-T (Translation), který funguje obdobně jako 464XLAT a MAP-E (Encapsulation), který funguje obdobně jako DS-lite. I když protokol MAP ještě není zralý k produkčnímu nasazení, jeho síťová část je už nyní k dispozici v routerech značky Cisco. Pro zákaznickou část je zatím k dispozici několik testovacích implementací, které je možné nainstalovat do libovolného routeru s OpenWRT. Podrobněji tento koncept představoval Andrew Yourtchenko v přednášce Run your next CGN on a $20 OpenWRT. Níže se můžete podívat na demonstraci takového řešení:

root_podpora

Pokrok nastává pomalu

Dobrou zprávou je, že okamžikem zapnutí IPv6 u velkých poskytovatelů služeb se vývoj nezastavil. Během dvou let se povedlo dosáhnout bezproblémové funkčnosti téměř všech desktopových operačních systémů. Smutné je, že se z jejich vývoje nepoučili vývojáři mobilních platforem.

Přístupové sítě zatím stále váhají. Příklady ze zahraničí ale ukazují, že kompletní přepnutí přístupové sítě z IPv4 na IPv6 není utopií ani hudbou budoucnosti, je možné jej udělat už dnes a často i tak, že si toho zákazník ani nevšimne.

Byl pro vás článek přínosný?

Autor článku

Ondřej Caletka vystudoval obor Telekomunikační technika na ČVUT a dnes pracuje ve vzdělávacím oddělení RIPE NCC, mezinárodní asociaci koordinující internetové sítě.