Autor: Veronika Štorková, Systems Engineer, Cisco Systems

část 1: zde

Část 2: Způsoby přechodu mezi IPv4 a IPv6

Svět se hýbe zajímavým směrem. Od vydání první části tohoto článku vloni v září uběhlo něco málo přes 5 měsíců a IANA oznámila vyčerpání volných IPv4 adres (31. ledna 2011¹ a ²).

Vyčerpání zásob regionálních internetových registrů (RIR) již nějaký čas probíhá (viz např. „APNIC IPv4 Address Pool Reaches Final /8“ ³). Též se začalo s přidělenými IPv4 adresami obchodovat, jeden z mediálně zajímavých okamžiků nastal na konci března, kdy Microsoft koupil IPv4 adresy Nortelu za cenu 7,5 milionů USD, což je přibližně 11 USD za IPv4 adresu ⁴.

¹⁾    IANA IPv4 depletion http://www.ipv4depletion.com/?page_id=326

^2 )   Net approaches address exhaustion http://www.bbc.co.uk/news/technology-12306573

³⁾    APNIC IPv4 Address Pool Reaches Final /8 http://www.apnic.net/publications/news/2011/final-8

⁴⁾   Microsoft spends $7.5m on net addresses http://www.bbc.co.uk/news/technology-12859585

Čili “den D” již nastal, proto se pojďmě podívat na možné způsoby překlenutí období změny z IPv4 na IPv6, resp. na techniky pro paralelní existenci obou protokolů.

Mechanismy koexistence a přechodu mezi IPv4 a IPv6

IPv6 není revolucí, ale dalším vývojovým stádiem úspěšného IPv4. Též je potřeba si uvědomit, že tyto dvě verze Internetového Protokolu nejsou mezi sebou interoperabilní. Proto bylo od počátku vývoje IPv6 nutné zajistit postupy, které umožní oběma protokolům vedle sebe existovat a postupně přejít z jedné verze na druhou. Protože tak jako je skutečností, že již není přístup k IPv4 adresám, tak stejně platí, že tyto dva protokoly budou vedle sebou ještě dlouho existovat. Technik pro řešení paralelního fungování a přechodu z v4 na v6 je několik.

Dual stack

Specifikován v RFC4213 ⁵, je technikou pro zajištění kompletní paralelní podpory obou Internetových protokolů – IPv4 a IPv6 – na koncových stanicích a směrovačích. Někdy bývá též nazýván jako „dvojitá IP vrstva“.

⁵⁾  Basic Transition Mechanisms for IPv6 Hosts and Routers http://tools.ietf.org/html/rfc4213

Koncová stanice či směrovač, které mají dual stack zprovozněný, umějí posílat a přijímat jak IPv4, tak IPv6 provoz a mohou přímo komunikovat s IPv4 uzly a IPv6 uzly. Pro IPv6 data zabalená v Ethernetovém rámci se využívá nový Ethertype kód 0x86DD k signalizaci vyšší vrstvě OSI modelu (IPv4 patří Ethertype 0x0800).

Obrázek 1: Podpora dual-stack na koncové stanici

Stanice či směrovač mají buď nakonfigurovány jak IPv4, tak IPv6 adresy nebo využívají běžné mechanismy pro získání IP adresy (DHCP pro IPv4 a např. bezstavovou autokonfiguraci či DHCPv6 pro IPv6). Využívají DNS pro mapování IP adres a doménových jmen – pro IPv6 je definován nový typ  zdrojového záznamu “AAAA” ⁶. V dual stack uzlu pak musí existovat mechanismus, který zajistí zpracování jak “A” (IPv4), tak “AAAA” záznamů. Pořadí v jakém jsou DNS záznamy zpracovávány na koncové stanici pak může ovlivnit preferenci verze IP aplikacemi koncové stanice (moderní operační systémy běžně preferují v6 před v4).

Z hlediska sítě provozované jako dual-stack to znamená, že v ní fungují dvě logické sítě nad jednou fyzickou vrstrou. Dual-stack je považován za jednoduché řešení koexistence IPv4 a IPv6. Moderní síťové prvky mají ve svým operačních systémech podporu IPv6 bez nároků na další finanční náklady, takže se stačí do vybudování IPv6 sítě pustit a využít to, co jsme do stávající fyzické sítě nainvestovali. Směrovače musí být akorát vybaveny větší pamětí, protože musí udržovat dvojí směrovací tabulku pro obě verze IP.

Námitkou proti “dvojí” síti jsou provozní náklady, vše je potřeba konfigurovat dvakrát (IP adresy, QoS, směrovací protokoly, bezpečnost apod.) a též skutečnost, že se v síti mohou vyskytovat starší zařízení, která dual-stack nepodporují.

⁶⁾ Pokud čtenáře zaujalo, proč je IPv6 DNS zdrojový záznam AAAA, je to z toho důvodu, že IPv6 adresa je 4-krát delší než IPv4 adresa

Dual stack lite

Technika, která využívá tunelování IPv4 provozu přes IPv6 síť a NAT44 pro zajištění IPv4 konektivity, je specifikována v RFC 6333 ⁷ a představuje, ve srovnání s dual-stack řešením, obrácený přístup ke koexistenci a přechodu mezi IPv4 a IPv6.

Hlavní myšlenkou je „přetavení“ páteřních sítí poskytovatelů služeb na čisté IPv6 sítě a tunelování většinového IPv4 provozu připojených uživatelů od DS-Lite CPE (Customer Premises Equipment) přes IPv6 síť. Tunelovaný IPv4-v-IPv6 provoz je ukončen na centrálním výkonném síťovém prvku (AFTR = Address Family Transition Router), který provádí Carrier-Grade NAT44 a provoz odesílá do IPv4 Internetu.

AFTR pracuje s rozšířenou tabulkou spojení NAT, do které je přidána informace o zdrojové IPv6 adrese příchozího provozu. Tím se zabrání možnému (a pravděpodobnému) problému s překrývajícími se privátními IPv4 adresami různých zákazníků.

DS-lite CPE je síťový prvek, který stojí na hranici IPv4 a IPv6 sítě. Pro připojující se koncové uživatele, kromě poskytování IPv4 konektivity a tunelování IPv4 provozu na AFTR, též musí fungovat jako IPv4 DHCP server (přiděluje IPv4 adresy podle RFC 1918) a IPv4 DNS proxy (sám v sobě má implementován pouze IPv6 DNS). Tunelování provozu mezi DS-lite CPE a AFTR pak podléhá specifikaci podle RFC 2473 ⁸ a RFC 4213.

Podle autorů, DS-Lite umožňuje oddělit nasazení IPv6 v SP sítích od pomalejšího nasazování IPv6 v globálním Internetu a na koncových zařízeních a aplikacích. Problém, který ovšem vyvolává, je, že předkládá SP myšlenku: zbavte se toho, co dnes znáte do nejmenších detailů (IPv4) a nahraďte to novým a neznámým (IPv6). Je to opravdu něco do čeho se každý poskytovatel služeb pustí s nadšením? Nebo-li zahodí svůj „denní chléb“ a vydá vstříc neznámému? Dalším problémem jsou dobře známé limity NAT44 a výkonnost AFTR.

⁷⁾ Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion http://tools.ietf.org/html/rfc6333

⁸⁾ Generic Packet Tunneling in IPv6 Specification http://www.ietf.org/rfc/rfc2473.txt

Tunelovací mechanismy

Dual-stack řešení je založeno na předpokladu, že koncová stanice či směrovač má konektivitu do IPv4 a IPv6 světa.  Jelikož dnes stále není běžné nativní IPv6 připojení a též z dříve uvedených důvodů nemusí být nasazení dual-stack v celé síti vždy možné, byly vytvořeny různé tunelovací mechanismy pro propojení IPv6 „ostrovů“ skrze IPv4 sítě. Koncové stanice a směrovače příjímají a odesílájí IPv6 pakety s využitím tunelů, sestavených přes IPv4 síť nebo přes MPLS síť.

Možných typů tunelů je několik, mohou propojovat sítě (site-to-site) nebo sloužit k připojení koncové stanice do IPv6 sítě (remote access), též mohou být statické nebo dynamické.

Manuálně konfigurované tunely

Specifikovány v RFC 3056 ⁹, též bývají nazývány 6in4 tunely. Tento typ tunelu je podobný GRE tunelům, kdy je celý IPv6 datagram zabalený uvnitř IPv4 paketu. Struktura 6in4 paketu je pak nasledující:

Obrázek 1 Struktura 6in4 tunelovaného paketu

6in4 tunely mohou využívat i GRE (pak je typ protokolu 47), syntaxe paketu je téměř stejná, akorát se mezi IPv4 a IPv6 hlavičku přidá ještě GRE hlavička.

Tyto tunely jsou statické, potřebují statickou IPv4 adresu a musí mít přidělenou globální unicast IPv6 adresu.

 ⁹⁾ Connection of IPv6 Domains via IPv4 Clouds http://www.ietf.org/rfc/rfc3056.txt

Dynamické tunely – 6to4

Tento typ tunelu slouží podobně jako manuálně konfigurované tunely pro propojení  site-to-site, ale na rozdíl od nich jsou dynamické. IPv6 prefix je odvozen od IPv4 adresy a jedno tunelové rozhraní dokáže přijímat a posílat provoz od/na více vzdálených konců tunelu (point-to-multipoint).

Směrovač, který stojí na hranici mezi IPv6 a IPv4 sítí se nazývá 6to4 router. Jeho IPv4 adresa se používá pro vypočítání IPv6 síťového prefixu (48 bitů) kombinací 6to4 prefixu 2002::/16 s 32-bitovou IPv4 adresou vnějšího rozhraní.

Obrázek 2 Syntaxe síťové části IPv6 adresy 6to4 směrovače

Protože použitá IPv4 adresa je globálně unikátní, je takto zajištěna i unikátnost IPv6 prefixu. Využití IPv4 adresy a IPv6 síťového prefixu zjednodušuje konfiguraci tunelu a konfigurací statické cesty směrem na 6to4 tunel se postaráme od odchod veškerého IPv6 provozu skrze tunel. Enkapsulace je pak stejná jako u 6in4 tunelů.

Problém pro 6in4 a 6to4 tunely, které se putují přes více sítí (jen např. přes hraniční směrovač) představuje NAT. Oba typy tunelů fungují přímo nad IP a NAT zařízení bežně podporují pouze protokoly bežící přes UDP nebo TCP. (Ne zcela vhodné) řešení pro NAT, běžný v dnešních IPv4 sítích, představuje dále zmíněné Teredo.

Tunely také narážejí v reálném provozu, kdy se musí dostat přes firewally a access listy, které běžně ve své konfiguraci nepovolují neznámý příchozí provoz. 6to4 provoz se totiž dostane ven ze sítě, ale není pro něj udržován stav, jako pro TCP či UDP provoz, a proto bývá zpětná komunikace blokována.¹⁰

¹⁰⁾ Emile Aben: 6to4 –Why is it so bad? RIPE labs. http://labs.ripe.net/Members/emileaben/6to4-why-is-it-so-bad

6rd (6 Rapid Deployment)

Jde  o rozšíření 6to4, o nadmnožinu 6to4 z hlediska používaných IPv6 prefixů. Tento mechanismus je specifikován v RFC 5969.¹¹

6rd popisuje způsob, jak poskytnout nativní konketivitu koncovým uživatelům skrze IPv4 síť SP. Staví na výše zmíněném 6to4 mechanismu a od něj se odlišuje tím, že namísto známého prefixu 2002::/16 využívá IPv6 prefix vlastněný (přidělený) poskytovateli služeb. Provozní doména 6rd je pak omezena na síť SP, který ji má přímo pod svou kontrolou. Proto by se zde neměl vyskytovat výše zmíněný problém s blokování tunelovaného provozu jako u 6in4 a 6to4.

Obrázek 3: 6rd řešení. Zdroj: www.cisco.com

Jeden 6rd prefix je možné používat pouze v rámci jedné 6rd domény, pokud z provozních důvodů SP potřebuje používat jiný 6rd prefix, pak musí přidat novou 6rd doménu. 6rd se spoléhá na IPv4 jakžto na transportní vrstvu, která umožní přenos IPv6 provozu mezi koncovými uživateli skrze páteřní síť poskytovatele služeb, která je na IPv4. Provoz, který odchází mimo 6rd doménu SP, nebo do ní přichází z vnějšku, musí projít přes 6rd Border Relay.

6rd také staví na algoritmu mapování IPv4 a IPv6 adres do tzv. 6rd delegovaného prefixu, čímž umožňuje automatické určení IPv4 adresy koncových bodů tunelů z IPv6 adresy a tím pádem bezstavové fungování 6rd. Z tohoto pohledu je 6rd, ve srovnání s dual-stackem, ještě pohodlnější pro nasazení a provoz, protože pro poskytování nativní IPv6 konektivity koncovým uživatelům je nutné 6rd zrovoznit pouze na CPE, implementovat 6rd Border Realy, vlastní síť SP ponechat na IPv4 a postupně ji (pokud vůbec) migrovat na IPv6.

¹¹⁾ IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) -- Protocol Specification http://tools.ietf.org/html/rfc5969

ISATAP

Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) je tunelovací mechanismus pro vzdálený přístup, specifikován v RFC 4214.¹²  V rámci organizací se též využívá pro připojení dual-stack koncových stanic k IPv6 částem sítě.  Pokud je ISATAP nasazen jako technika pro vzdálený přístup přes IPv4 internet k IPv6 internetu, jde o hub-spoke tunelování, kdy se koncové stanice (spokes) připojují na ISATAP server (hub).

Na klientské straně je vyžadována minimální konfigurace – seznam IPv4 adres ISATAP směrovačů. ISATAP uzly si následně vytvoří vlastní globálně unikátní adresu (podle principů bezstavové autokonfigurace). Pokud nakonfigurujeme více jak jeden ISATAP sever, zajistíme záložní konektivitu  a vysokou dostupnost. Po té co si koncová stanice vymění RA a RS zprávy s ISATAP serverem, ISATAP tunel se stane aktivním a stanice si vytvoří svou IPv6 adresu.

Obrázek 4 Schéma napojení ISATAP klienta na ISATAP server

Přístup k ISATAP tunelům na straně směrovačů (hub) se může lišit výrobce od výrobce. Např. u směrovačů Cisco je potřeba nakonfigurovat “no ipv6 nd suppress-ra” na rozhraní ISATAP tunelu, což změní defaultní chování směrovače. Ten pak začne posílat do tunelu RA zprávy (jinak potlačované), které hrají zásadní roli pro bezstavovou autokonfiguraci ISATAP koncových stanic.

¹²⁾ Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) http://www.ietf.org/rfc/rfc4214.txt

Teredo

Výše uvedené tunelovací mechanismy vloží IPv6 paket hned za IPv4 hlavičku s využitím protokolu typu 41. S tím ovšem neumí pracovat NAT zařízení. Pokud se tedy dual-stack koncová stanice nachází za takovým zařízením, pak je možným řešením Teredo. Specifikována v RFC 4380¹³, tato technika zabalí IPv6 paket uvnitř IPv4 UDP datagramu. Což je podobné UDP enkapsulaci IPSec pro tzv. NAT-Traversal.

Obrázek 5 Syntaxe Teredo paketu

Teredo funcionalita je realizována třemi komponentami:

-         Teredo klient – dual-stack koncová stanice, která zabalí IPv6 pakety do IPv4 UDP Teredo paketů;

-         Teredo relay – hlavní uzel pro dekapsulaci a enkapsulaci Teredo provozu;

-         Teredo server – server sloužící pro registraci Teredo klientů a Teredo relay. Díky Teredo serveru klienti najdou Teredo relays, na které posílají provoz, a naopak.

Teredo představuje zajímavý bezpečnostní problem, ke kterému se dostaneme v poslední části tohoto článku.

¹³⁾ Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs) http://www.faqs.org/rfcs/rfc4380.html

6VPE

Všechny předchozí tunelovací mechanismy využívají pro svůj transport IPv4. Dalším běžným transportním prostředím je MPLS. MPLS síť dokáže přenášet přes Label Switched Path (LSP) různé typy dat – IPv4 a samozřejmě i IPv6. MPLS se pohybuje mezi L2 a L3, čili v sobě „zabalí“ L3 a tímto způsobem se vyhne řešení problému verze IP. Též jej nezajímá IP adresa, ale label paketu, který slouží pro určení cesty paketu v MPLS síti.

Směrovače, které připojují koncová CPE, se nazývají PE (Provider Edge) a pro připojení více zákazníků a pro oddělení směrovací informace mezi jednotlivými zákazníky využívají Virtual Routing and Forwarding (VRF). Propojení mezi jednotlivými CPE zákazníků se pak nazývá MPLS-VPN. Směrovací informace z konkrétních VRF mezi PE směrovači jsou vyměňovány pomocí MP-BGP, který v sobě obsahuje rozšíření pro více protokolů, tzv. address families. BGP tím pádem dokáže přenášet i IPv6 – BGP spojení mezi PE routery je ovšem navázáno přes IPv4 adresy loopback rozhraní PE. Tím se elegantně vyhneme migraci páteřní sítě na IPv6.

Dual-stack PE směrovač, který podporuje IPv4 a IPv6 VRF, je schopen posílat oba typy provozu na další PE směrovače a odpovídajícím IPv4 a IPv6 VRF. Páteřní MPLS směrovače, P (Provider), pak zpracovávají pouze MPLS pakety a na verzi IP jim nezáleží.

Obrázek 6 6VPE

6VPE je využíváno poskytovateli služeb pro zajištění IPv6 konektivity zákazníkům, protože náklady nasazení a provozování 6VPE jsou nižší než plná migrace na dual-stack síť.

NAT 64

Myšlenka překladu mezi verzemi IP je nejspíš stejně stará, jako myšlenka vytvoření nového protokolu. Network Address Translation (NAT) je téma, které se vyskytne při jakékoliv diskuzi o nasazení IPv6 – staré (zlo)zvyky se špatně opouštějí.

Původní NAT-PT (Network Address Translation-Protocol Translation) speficikovaný v RFC 2766 umožňoval nativním IPv6 koncovým stanicím, aby komunikovaly s nativními IPv4 stanicemi. NAPT-PT prvek by se nacházel na hranici mezi IPv4 a IPv6 sítí a využíval by množinu globálně směrovatelných IPv4 adres. Zároveň by v sobě obsahoval Application Level Gateway (ALG) jako je např. IPv4 NAT zařízení nebo firewall. ALG dokáže pracovat s různými protokoly, kdy L4 data jako TCP nebo UDP jsou jednoduše kopírována z IPv4 paketu do IPv6 paketu a obráceně. U jiných protokolů, které mají IP adresu zakomponovánu uvnitř dat v paketu (jako jsou FTP a SIP), by ALG musela odpovídajícím způsobem paket modifikovat. NAT-PT byl ovšem IETF zrušen v RFC 4966 z důvodu technické a provozní náročnosti a možných omezení, které by NAT-PT mohl přinést pro budoucí rozvoj IPv6 sítí.

V současné době byla původní myšlenka oživena v podobě stavového NAT64 a je zpracována v RFC 6146 z dubna letošního roku¹⁴ (bezstavový NAT64 je specifikován v RFC 6145¹⁵ a má své limity¹⁶). Tato specifikace se zabývá pouze protokoly TCP, UDP a ICMP. NAT64 opět pracuje s IPv4 adresami, které jsou sdílené mezi IPv6 klienty. Spolupracuje s DNS64¹⁷, které zajišťuje propojení IPv4 A zdrojových záznamů s IPv6 AAAA záznamy.

Pouze IPv6 klienti mohou inciovat relaci na IPv4 klienta/server. V závislosti na politice filtrování provozu IPv4 klienti mohou zahájit komunikaci na IPv6 klienta (neboli poslat provoz opačným směrem), pokud má NAT64 zařízení pro ně již existující mapování (buď z nedávno iniciované relace nebo statické mapování – což samozřejmě není možné efektivně škálovat). Pro řešení problému s malým množstvím globálních IPv4  adres versus IPv6 adresy využívá IPv4 Port Address Translation (PAT), interně směrem k IPv6 hostům oznamuje IPv6-prefix+IPv4-adresu, kde je na jednu IPv4 adresu vázáno více IPv6 prefixů. NAT64 prvek si udržuje tři oddělené tabulky spojení (biding tables) – samostatně pro TCP, UDP a ICMP.

Jak je čtenáři nejspíš zřejmé, NAT64 naráží na stejné limity jako NAT44 (resp. PAT44). Každá IPv4 adresa má 65535 portů, které lze využít. Ač se to zdá jako dostatečné množství, víme, že dnešní uživatelské aplikace z důvodů rychlosti odezvy navazují více než jedno spojení a tím pádem vyčerpávají větší množství portů než jeden. Čili NAT64 je možné využít v malém nasazení, nikoliv jako škálující a dlouhodobé řešení. Kromě toho ještě jednou zdůrazním směr komunikace NAT64. Z IPv6 světa do IPv4 sítí, nikoliv obráceně.

¹⁴⁾  Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers http://tools.ietf.org/html/rfc6146

¹⁵⁾  IP/ICMP Translation Algorithm http://tools.ietf.org/html/rfc6145

¹⁶⁾ Stateless NAT64 – Restrictions

 ¹⁷⁾ DNS64: DNS Extensions for Network Address Translation from IPv6 Clients to IPv4 Servers http://tools.ietf.org/html/rfc6147



Závěr

Když se čtenář zamyslí, možností pro překlenutí období mezi čistým IPv4 a čistým IPv6 je dostatek. Otázka je, která z nich je nejlepší, zde platí, že neexistuje jedno univerzální řešení. Modelů koexistence je více a různým sítím budou více vyhovovat různé cesty k jejich dosažení.

Pokud se dostanete do diskuze s lidmi jako je Fred Baker¹⁸, jejich názor na tyto různé mechanismy je tento: Teredo v síti vypnout (z bezpečnostních důvodů), NAT64 nepoužívat (narušuje end-to-end model komunikace). ISATAP je možný pro nasazení v rámci firemních sítí, ale již ne ve větších (SP) sítích.  Dual-stack, 6rd a 6VPE jsou spolehlivé přístupy, které lze s klidem využít.

Naopak, DS-lite  vnímají jako zbytečně komlikovaný přístup, který v konečném důsledku naráží na stejné limity na NAT44 a vede SP k „odsunutí do šrotu“ své důvěrně známé IPv4 sítě a její náhradě IPv6 sítí, prakticky experimentálního charakteru.

Na toto téma bych čtenářům doporučila k přečtení návrh Guidelines for Using IPv6 Transition Mechanisms during IPv6 Deploymen¹⁹, jehož autory jsou právě Fred Baker a Jari Arkko.