Stále se zmenšující adresový prostor současného protokolu IPv4 již před léty vedl ke vzniku technik majících dočasně zbrzdit problém docházejících IPv4 adres. Přibližně v polovině 90. let se podařilo najít řešení, které umožnilo sítím na privátních adresách [RFC 1918] komunikovat do globálního Internetu s využitím malého množství nebo dokonce jedné veřejné IPv4 adresy.

Základní myšlenka se opírala o překlad adres, který umožnil mapování malého počtu veřejných adres na mnohem větší množství privátních adres uvnitř sítě. Tomuto základnímu konceptu říkáme NAT (network address translation). Tento model byl následně rozšířen o možnost zahrnutí do překladu i čísla portů vyšší vrstvy (TCP, UDP), kterému se správně říká PAT (port address translation) nebo NAPT (network address port translation). V běžné praxi se však pro označení PATu, či NAPTu běžně používá termín NAT, což vnáší do situace trochu zmatek. Pokud tedy dneska někdo hovoří o NATu, s největší pravděpodobností je tím myšlen PAT (NAPT) – stejně tak s tímto termínem budeme pracovat i v našem seriálu, nebude-li řečeno jinak.

Překlad adres s sebou nese samozřejmě nemalé vady na kráse. Mezi největší nedostatky patří nutnost navazovat spojení z vnitřní sítě. Zařízení připojená v NATované síti není možno adresovat přímo z Internetu. Tím vznikají velké komplikace aplikacím, které vyžadují přímou komunikaci mezi koncovými uzly. Situace je ještě složitější, pokud se oba uzly nacházejí v NATované síti. Příkladem může být například aplikace skype, která musí využívat různé kontroverzní skrčky a obezličky pro navázání komunikace mezi uzly v NATovaných sítích. Nelze se tedy divit, že pro mnohé představuje technologie NATu ztělesnění snad všeho zla Internetu, které současně představuje největší překážku v dalším rozvoji nových služeb.

Na první pohled by se tedy mohlo zdát, že s nástupem IPv6 může být NAT jednou pro vždy smeten z povrchu zemského. Protokol IPv6 disponuje dostatečným adresovým prostorem a nic nebrání tomu, aby každé zařízení v IPv6 síti mělo svoji vlastní IPv6 adresu, nebo dokonce několik adres, které jsou dosažitelné přímo z jakéhokoliv místa v síti. Jenže, jak už to chodí, nic není tak jednoduché, jak se na první pohled jeví.

Je potřeba si uvědomit, že technologie NATu je tady zhruba 15 let. To, co původně vzniklo jako dočasně překlenovací řešení, se dnes usadilo téměř v každé firmě a domácnosti. Těžko dnes najdeme síť, kde by nebylo nasazeno nějaké zařízení realizující NAT. Výjimkou nejsou ani sítě, kde je NAT použit dokonce v několika stupních. S NATem jsme se zkrátka nějakým způsobem naučili žít a postupem času začali odhalovat některá pozitiva. Zkusme se podívat na ty nejvíce diskutované přednosti a současně se pokusit nastínit možnosti řešení nabízené protokolem IPv6. Jako obvykle se pokusíme vyjít z možností, které nám IPv6 poskytuje v aktuální úrovni rozpracování standardů a z reálných implementací v zařízeních.

Firemní sítě

Podívejme se nejdříve, jak se dnes typicky připojují firemní sítě k Internetu. Zpravidla je síť rozdělena na 3 základní celky.

Uspořádání prvků firemní sítě

• Vnější „zlý“ veřejný Internet, tvořený rozhraním s jednou nebo více veřejnými IPv4 adresami pro připojení k poskytovateli.

• Demilitarizovaná zóna (DMZ), ve které jsou umístěné servery na veřejných anebo privátních adresách. V případě privátních adres je prostřednictvím mapování (DNAT) zajištěno zpřístupnění veřejných služeb do zbytku Internetu.

• Klienti a služby ve vnitřní síti pracující na IPv4 adresách. Zpravidla bez nějakých zvláštních omezení přistupují na servery v DMZ. Topologie vnitřní sítě může mít různou složitost – od jednoho prostého segmentu až po složitou topologii s komplexním směrováním řešeným směrovacím protokolem.

Ústřední prvek zpravidla tvoří firewall v kombinaci s NATem, který současně řeší případné bezpečnostní politiky mezi jednotlivými zónami.

IPv6 ve firemní síti

Jak budeme postupovat při implementaci protokolu IPv6 v takové síti? Nikoho nepřekvapí, že na rozdíl od několika IPv4 adres nám bude poskytovatelem přidělena celá síť. S největší pravděpodobností to bude síť s délkou prefixu 48 nebo 56 bitů. Původní brána, která realizovala NAT, bude v konfiguraci s IPv6 nahrazena směrovačem. S poskytovatelem se rovněž musíme dohodnout na vytvoření záznamu ve směrovací tabulce, který odkazuje na přidělený prefix na našem směrovači. Pro propojovací síť mezi vaším směrovačem a směrovačem poskytovatele můžete případně použít link-local adresy.

Na straně vašeho směrovače zprovozníte směrování pro IPv6, dovedete příslušné koncové IPv6 sítě do DMZ a ostatních koncových sítí a samozřejmě nezapomenete nakonfigurovat firewall. Předpokládejme, že budete chtít zachovat omezení přístupu na klientské systémy z Internetu a nakonfigurujete stavový firewall. V tomto okamžiku můžete začít připojovat zařízení prostřednictvím IPv6 a vše by dle předpokladu mělo začít fungovat. Do sítě postupně připojujete nové servery, tiskárny, čtečky docházky, IP telefony, komunikátory, IP kamery atd.

Až doteď zní vše jako pohádka. Žádný NAT, žádné mapovaní adres a portů do DMZ. Zůstává pouze konfigurace firewallu. Jednoho dne se však rozhodnete, že dosavadní poskytovatel připojení vám nevyhovuje (jak jinak než z cenových důvodů) a rozhodnete se jej změnit. S tím samozřejmě souvisí i změna síťového prefixu. V IPv4 světe s NATem to není výraznější problém. Překonfigurují se IPv4 adresy na vnějším rozhraní NATu, upraví se mapování veřejně dostupných služeb do DMZ a změní záznamy v DNS odkazující na veřejně dostupné služby. Přechod k novému poskytovateli tak může být záležitost několika hodin. Zásahy a znalost vnitřní struktury sítě jsou bezpředmětné. Vše to je možné díky odstínění vnitřní infrastruktury od zbytku Internetu prostřednictvím NATu.

Jistě už tušíte, že v případě IPv6 nemusí jít vše tak jednoduše. Samotná skutečnost, že IPv6 prefix přidělený ISP je doslova rozeset i do toho nejtemnějšího zákoutí firmy, znamená, že v případě změny poskytovatele se změna týká úplně každého zařízení, které má přidělenou globální IPv6 adresu. Je třeba si uvědomit, že pouhá změna IPv6 není vše, co je třeba provést. Musíte současně upravit adresy rekurzivních DNS serverů, pravidla na firewallu atd. Taková změna se ještě více komplikuje, pokud máte několik firemních poboček propojených prostřednictvím VPN okruhů. Dalo by se namítnout, že leccos se dá do značné míry automatizovat. Velkou výhodou může být, že od nového poskytovatele s největší pravděpodobnosti obdržíte prefix stejné délky. Změny v DNS se tedy dají provést algoritmicky a s vlastním přečíslováním sítí by vám mohla pomoct autokonfigurace. Kdo však někdy absolvoval proces přečíslování fungující sítě, jistě ví, že se jedná o velice náročnou proceduru. Vždy narazíte na nejrůznější systémy, kde je adresa nastavena staticky (například všechny servery, tiskárny) anebo jsou uživatelé zvyklí „chodit na některé služby přes IP adresu“. Překvapení a předem netušených komplikací je vždy mnoho.

Použití ULA adres

Možným řešením situace je použití unikátních lokálních adres (ULA, Unique Local IPv6 Unicast Addresses, RFC 4193). O těchto adresách již byla řeč v předchozím díle, proto jen krátce shrneme, že se jedná o obdobu IPv4 privátních adres. Mezi klíčové výhody patří světová unikátnost síťového prefixu, který se rozhodnete ve své síti použít.

Při použití ULA adres se již nemusíme obávat, že je budeme muset měnit s příchodem nového poskytovatele. Jednou nakonfigurované ULA adresy můžou zůstat ve firemní sítí na věčné časy, aniž by se muselo cokoliv měnit. Díky unikátnosti prefixu není rovněž problematické spojování sítí při různých fúzích atd. Jejich použitím tedy získáváme zpět přednosti použití privátních IPv4 adres ve firemní síti. Zní to docela dobře a mohlo by se zdát, že problém měnících se adres poskytovatele je tímto vyřešen. Má to samozřejmě háček. Je asi dost pravděpodobné, že na zařízeních, kterým přidělíme ULA adresy, budeme chtít občas přistupovat do Internetu (například měřící přístroj, který si občas potřebuje stáhnout aktualizace). V IPv4 světě by věc byla velice jednoduchá – o vše se postaral NAT. Toto ošklivé slovo však svět IPv6 nechce znát, nezbývá proto nic jiného, než těmto zařízením přidělit kromě ULA adresy také nějakou globální. Takže jsme zase na začátku? Ne tak docela.

Obecně lze doporučit používání ULA adres pro služby a zařízení, u kterých bezpečně víte, že na ně budete přistupovat z firemní sítě. Takové adresy pak můžete s klidem zavést do místní DNS a nemusíte se obávat jejich nedostupnosti v případě změny globálního prefixu přiděleného poskytovatelem. Přidělení ULA adres nijak nevylučuje použití globálních adres u těch zařízení, u kterých víte, že budou současně potřebovat přístup do globálního Internetu. V každém případě změna globálního prefixu (například v důsledku změny poskytovatele připojení) není zcela bezproblémová a vyžaduje změnu globálních adres v celé firemní síti, tedy dobrou přípravu a plánování. Využitím ULA adres můžete náročnost zásahu zmírnit. Jistou pomůckou může být ještě využití proxy služeb, které zajistí přestupní stanici mezi ULA a globálními adresami. Tuto možnost nelze ovšem použít vždy pro všechny služby.

PI adresy

Dalším možným řešením nastíněného problému je použití PI adres. O PI adresách jsme se již také zmínili v předchozím díle. Použití PI adres se z pohledu organizace může zdát jako velice elegantní řešení. Koncové instituci je jednou provždy přidělen dostatečné velký blok IPv6 adres, který může být směrován libovolným poskytovatelem. Směrování PI adres je v technické rovině vázáno na existenci samostatného autonomního systému (AS) a z globálního pohledu se jedná o samostatný záznam ve směrovacích tabulkách. Minule už jsme si řekli, že samotná existence PI adres je řešení, které je přímo v rozporu se šetrným, hierarchicky definovaným přidělováním adres, a jedná se o jakýsi ústupek, protože se dosud nepodařilo najít schůdnější řešení pro multihomované sítě (sítě připojené k více poskytovatelům). Koncové organizaci však zcela jistě budou počty záznamů v globálních směrovacích tabulkách celkem lhostejné a možnost použití PI adres by tak jistě uvítala nejedna organizace.

Dřív než vůbec začnete s úvahami o použití PI adres, je dobré si prostudovat pravidla pro jejich přidělování. Pokud vás ani tento první krok neodradí, bude následovat ne zcela jednoduchý administrativní proces v podobě vyplňování formulářů a prokazování, zda jste o PI adresy vůbec oprávněni žádat, dokumentování vaší sítě a zejména prokázání, že v dohledné době bude vaše síť připojená k více poskytovatelům (multihoming). Po přidělení adres si budete muset ještě zažádat o přidělení vlastního čísla autonomního systému (pokud jej už nemáte pro IPv4). Po absolvování administrativy a zaplacení souvisejících poplatků můžete začít vyjednávat s poskytovateli Internetu o připojení vašeho směrovače protokolem BGP4+. Jak jistě vidíte, tato cesta je akceptovatelná výhradně pro velké organizace. Pro středně velkou firmou s linkou řádově několik desítek megabitů je tato varianta zcela mimo reálné možnosti.

Multihoming malých sítí

Další velice častou úlohou NATu ve firemním prostředí je jakýsi zjednodušený multihoming. Ten je použitelný v případě, že je pro chod firmy naprosto kritický přístup k veřejným službám na Internetu nebo serverům umístěným někde ve datovém centru. V takovém případě si firma kromě primárního připojení pořídí ještě jednu záložní linku horších parametrů (například ADSL). V případě výpadku primárního připojení je provoz automaticky přesměrován na záložní linku. V době překlopení na záložní linku pochopitelně dojde k přerušení již navázaných spojení, a také veřejné služby provozované na adresách primárního poskytovatele nebudou po záložní lince dostupné. Pro většinu menších sítí je to dnes prakticky jediné dostupné řešení pro zvýšení spolehlivosti připojení do Internetu.

V principu je multihoming malých sítí velice podobný již výše popsané změně poskytovatele s tím rozdílem, že celý proces je vyvolán automaticky. Detekce výpadku připojení se provádí na základě detekce linky nebo dostupnosti brány poskytovatele.

V případě IPv6 získáme od každého poskytovatele samostatný prefix délky 48 nebo 56 bitů. Teoreticky nic nebrání směrovat oba prefixy a na koncových stanicích mít použity obě sítě. Prostřednictvím priorit bychom měli být schopni nastavit i upřednostňování některé ze sítí, a tím tedy primárně použité připojení. Problém nastane v případě výpadku některého z připojení, kdy zcela schází jakýkoliv mechanizmus informování koncových zařízení o tom, že jedna ze sítí je dočasně nedostupná. Toto řešení tedy není v současné době příliš použitelné.

Elegantní podpora multihomingu měla být společně s podporou mobility klíčovým vylepšením protokolu IPv6 oproti IPv4. Žádný z historických návrhů se ovšem do dnešního dne nepodařilo dovést do alespoň trochu použitelného stavu. Jisté světlo na konci tunelu představuje rozšíření shim6 (viz. článek Pavla Satrapy). Jeho implementace je však záležitostí daleké budoucnosti a na praktickou implementaci si budeme muset počkat v lepším případě několik let.

Nezbývá tedy než konstatovat, že v současné době je dostupná pouze možnost multihoumingu, a to prostřednictvím vlastního autonomního systému a PI adres. Další alternativy dnes jsou zpravidla ve fázi rozpracovaných návrhů a silně experimentálních implementací.

Mapování prefixů sítí

Poměrně zajímavou novinku, kterou nabízí IPv6, je mechanizmus mapování prefixů. Veřejný prefix, který máme přidělený od poskytovatele, namapujeme na prefix stejné délky na privátních ULA adresách. Tímto zajistíme odstínění vnitřní struktury sítě od vnějších adres, které je nezbytné pro snadnou výměnu prefixu přiděleného poskytovatelem a realizaci zjednodušeného multihomingu.

Na první pohled by se mohlo zdát, že mechanizmus se nijak výrazně neliší od překladu adres v podobě NATu, nicméně je zde významný rozdíl. Mapování prefixů odstraňuje hned několik klíčových nedostatků NATu:

Mapování prefixu IPv6

• Koncová zařízení je možno adresovat přímo z vnějších sítí. Není tedy nutno zahajovat komunikaci z vnitřní sítě.
• Zařízení realizující mapování prefixů nemusí udržovat stavovou informaci. Z hlediska implementace je mechanizmus mapování prefixů velice jednoduchý.
• Vzhledem k tomu, že dochází k výměně prefixu pouze na síťové úrovni (tedy na úrovni IPv6 adres), nemusí mechanizmus nijak zasahovat do vyšších protokolových vrstev TCP, UDP, ICMP, GRE, atd.
• Mechanizmus nadále bude způsobovat komplikace aplikacím a protokolům, které si v rámci komunikace vyměňují IPv6 adresy komunikujících uzlů. Pokud však protokoly a aplikace budou předem počítat s možností mapování prefixů, tak se dokážou zpravidla s problémem vypořádat vhodným návrhem protokolu.
• Jedná se o ověřený princip, který se na mnoha místech používá pro mapování adres do DMZ (demilitarizované zóny). Tam se sice provádí mapování jednotlivých adres, ale z hlediska principu toto příliš nehraje roli.
• Na rozdíl od NATu ani v nejmenším neposkytuje možnost ochrany vnitřní sítě a tedy jednou provždy řeší nekonečný rozpor, zda lze NAT považovat za ochranný prvek či nikoliv. Zkrátka a jednoduše nelze, a případnou ochranu vnitřní sítě je nutno řešit vhodnou konfigurací firewallu.

Mechanizmus mapování prefixů byl poprvé představen v roce 2008 v rámci draftu draft-mrw-behave-nat66 a následně upraven v podobě draft-mrw-nat66. Tvůrce v původních návrzích pojmenoval mechanizmus poněkud nešťastně jako NAT66, což způsobuje, že se mnozí již při zmínce dožadují příchodu vymítače ďábla, aniž by zkoumali skutečnou podstatu fungování mechanizmu. I přes mnohé výhrady byl mechanizmus mapování prefixů podstoupen dalšímu zpracování na 74. zasedání IETF v San Franciscu (viz. zápis). Terminologický problém si naštěstí tvůrci uvědomili a počínaje druhou verzí draftu je mechanizmus označován NPTv6 (Network Prefix Translation), který je mnohem výstižnější a nevytváří negativní asociaci na původní mechanizmy NATu či NAPTu.

V linuxových systémech je možné už nyní otestovat experimentální implementaci pro iptables. Tu je možné získat na stránkách projektu map66. Po přeložení a instalaci v systému je možné prostřednictvím pravidel ip6tables konfigurovat pravidla pro mapování. Následující příklad ukazuje mapování veřejného prefixu 2001:67c:1220­:3::/64 na ULA adresy fc00:b0b0:bebe::/64 a obráceně:

ip6tables -t mangle -I PREROUTING -i eth0 -d 2001:67c:1220:3::/64 -j MAP66 --dst-to fc00:b0b0:bebe::1/64
ip6tables -t mangle -I POSTROUTING -o eth0 -s fc00:b0b0:bebe::1/64 -j MAP66 --src-to 2001:67c:1220:3::/64

Na úrovni vnitřní sítě můžeme pochopitelně vytvořit libovolně komplikovanou topologii sítě. V mapování prefixů osobně vidím velkou budoucnost. Domnívám se, že díky jednoduché implementaci a velké poptávce po odpovídajícím mechanizmu se poměrně rychle rozšíří. Zatím existuje pouze jedna experimentální implementace, ale to se jistě rychle změní.

Systému mapování prefixů lze rovněž považovat jisté řešení pro připojování domácích sítí. Pokud by zařízení realizující mapování prefixů poskytlo na veřejném rozhraní jakousi ND (neighbor discovery) proxy službu (RFC 4389), mohlo by dojít k výraznému zjednodušení připojování „domácích krabiček“ bez nutnosti delegace prefixů a vytváření směrovacích záznamů pro domácí sítě na straně ISP (viz. předchozí díl našeho seriálu). Návrh se o této možnosti zmiňuje zatím pouze okrajově.

Závěr

Množství adres, které IPv6 disponuje, je dostatečné pro všechna zařízení, která mohou být připojena do Internetu. Prvotní důvod pro použití technologie překladu adres v podobě NATu a PATu se zdá být tímto eliminován. Masové využívání této technologie v posledních 15 letech mělo výrazný dopad na způsob budování sítí, a postupem času se začalo využívat některých výhod pramenících z použití NATu. Bohužel z dnešního úhlu pohledu standardy IPv6 stále nenabízejí plnohodnotnou náhradu některých funkcionalit, které NAT poskytuje. Historicky jakákoliv snaha, byť jen o otevření debaty na téma překladu adres, byla IPv6 komunitou zpravidla odmítnuta v samém zárodku. Teprve až v roce 2010 bylo uveřejněno informační RFC 5902 zabývající se aspekty použití NATu v IPv6 sítích. Situace je o to více nepříjemná, že tímto stavem je postižen zejména firemní sektor, který výrazným způsobem může podpořit nebo naopak zbrzdit rozšiřování IPv6. 

Problematika NATu v IPv6 sítích zcela nepochybně patří mezi nejkontroverznější témata v historii celého IPv6. V diskusích se často zapomíná, že díky dostatečnému adresovému prostoru již nemusí být mechanizmus překladu adres koncipován tak, jak tomu bylo v případě IPv4. Nově lze využít mechanizmu mapování celých sítí (NPTv6), který odstraňuje velkou část problémů souvisejících s provozem NATu. Do vytvoření plnohodnotného standardu a provozně použitelné implementace je však stále ještě docela daleko.