Nejedná se o hypotetickou úvahu, protože v současnosti již IPv6 podporují produkty většiny výrobců. Konkrétně oba nejvýznamnější hráči na poli směrovačů – Cisco Systems a Juniper Networks – už mají IPv6 implementováno v produkčních verzích svých systémů. Pravda, k dokonalosti těmto implementacím ještě dost chybí, nicméně základní podporu nového protokolu zvládnou, a lze proto uvažovat o jejich nasazení v rutinním provozu.
Přirozeně vzniká otázka, jaké má poskytovatel, který by chtěl svým zákazníkům nabídnout IPv6, možnosti. Právě tomuto tématu se věnuje dokument s atraktivním názvem D2.1.1, jenž je jedním z výstupů skupiny, která se v rámci 6NETu zabývá otázkami koexistence IPv4 a IPv6.
Autoři se kupodivu nezmiňují o variantě, kterou používá 6NET sám – samostatná IPv6 síť. Zřejmě jsou si vědomi skutečnosti, že takovéto řešení je sice čisté, ale v současné době ekonomicky neudržitelné. Můžete si je dovolit jen v případě, kdy máte za zády grantovou podporu či jiný zdroj financí, který vám umožní provozovat ztrátovou síť.
Pojďme tedy k realističtějším modelům. Vycházejí z toho, že poskytovatel chce své stávající linky a zařízení využít vedle IPv4 také k přepravě IPv6.
Jednou z možností je převést síť kompletně „pod obojí“. Čili instalovat podporu obou protokolů ve všech směrovačích sítě. Toto řešení s sebou ale přináší řadu praktických problémů. Například potřebujete dvojí adresování – jednotlivá rozhraní musí mít jak IPv4 tak IPv6 adresy.
Horší je, že nejspíš budete potřebovat dva směrovací protokoly. Některé protokoly (jako třeba IS-IS či BGP4+) umožňují směrovat obě verze IP. Pokud používáte něco jiného, budete buď muset pro IPv6 přidat druhý nebo zvážit změnu směrovacího protokolu (což je hodně nepříjemný krok).
Opatrnější přístup představuje tunelování. Jádro sítě může zůstat beze změny a na místa, kde jsou potřeba, nasadíte přípojné IPv6 body propojené navzájem tunely. Tunel znamená, že IPv6 datagram se na jednom konci zabalí do IPv4, přenese běžnou IPv4 sítí a na druhém konci rozbalí a pošle dál (možná dalším tunelem, možná nativní IPv6 sítí).
Problémy s dvojím zásobníkem (jako je nutnost směrování dvou různých protokolů, dvojí adresování a podobně) se tady projevují jen u koncových bodů tunelů. Jejich zatížení se však nadále zvýší nutností balit a rozbalovat datagramy. Riskujete také neoptimální směrování, protože tunel je vlastně virtuální kanál mezi dvěma body. Je možné, že IPv6 datagramy by se daly směrovat efektivněji, než jak to umožňuje daná síť tunelů. Tento problém lze obejít automatickými tunely (jako třeba 6to4), ale tím se opět zvyšují nároky na schopnosti koncových směrovačů.
Zajímavé možnosti se rýsují, pokud je síť poskytovatele postavena na technologii MPLS. Jen stručně připomenu základní myšlenku: MPLS je založeno na principu „chytré konce a hloupé, ale rychlé jádro“. Směrování funguje na nálepkách (labelech), které datagramům přidělují hraniční směrovače sítě (tak zvané PE čili Provider Edge směrovače). Uvnitř páteřní sítě se pak nacházejí P (Provider) směrovače, které nic moc nerozhodují a jen podle existujících nálepek proklatě rychle předávají datagramy z jednoho rozhraní na druhé.
Pro poskytovatele připojení je nejjednodušším způsobem implementace IPv6 metoda „já nic, já muzikant“. V takovém případě si zákazníci postaví své tunely sami na svých CE (Customer Edge) směrovačích. Tento směrovač představuje hranici zákaznické sítě a komunikuje s poskytovatelovým PE směrovačem konfekčním IPv4 (datagramy verze 6 zabalí a posílá tunelem). Tohle lze ale jen těžko nazvat službou.
Z nabídky pokročilejších možností MPLS je možno pro IPv6 využít emulaci linkové vrstvy. Existují totiž služby jako Ethernet over MPLS (EoMPLS) či Any Transport over MPLS (AToM), které vytvoří například virtuální Ethernet procházející MPLS sítí. Stačí jen, aby odpovídající PE směrovač datagramy přicházející z určitého rozhraní označil odpovídající nálepkou a MPLS jádro je pak dopraví na druhý konec tohoto virtuálního kanálu.
Jedná se vlastně o tunel, ale ve vrstvě pod IP. Hlavní výhodou je naprostá transparentnost tohoto řešení. Zákazník dostane nativní IPv6 spoj odkudsi kamsi. Naproti tomu MPLS jádro se o obsah datagramů nestará a dopravuje je podle značek, takže není nutné cokoli měnit na P směrovačích.
Jenže tento přístup nijak neřeší směrování IPv6 v páteřní síti. Také špatně škáluje, protože onen virtuální kanál je třeba někde ukončit – například na nějakém centrálním směrovači nebo u jiného zákaznického přípoje.
Asi nejzajímavější možností založenou na MPLS je použití BGP tunelů. V terminologii firmy Cisco Systems najdete tuto technologii pod názvem 6PE, ovšem něco podobného dovedou i směrovače jiných výrobců. Základní myšlenkou je, že zúčastněné PE směrovače podporují IPv4 i IPv6. Vůči koncovému zákazníkovi nabízejí nativní IPv6 linku, do MPLS jádra sítě pak IPv6 datagramy označují příslušnými nálepkami a nechávají je dopravit k odpovídajícímu PE směrovači. O topologii se navzájem informují prostřednictvím multiprotokolového BGP.
Čili jádro sítě (P směrovače) se opět obejde beze změny, je třeba jen odpovídající PE směrovače naučit 6PE. Jeho oficiální podpora by se v operačním systému pro Cisco měla objevit co nevidět. Podrobnější informace o ní (včetně konfigurace) se dočtete v prezentaci, jejíž obsah mimochodem až překvapivě ladí s výše zmiňovanou zprávou projektu 6NET ;-) Juniper podporuje podobnou technologii, jak dokládá manuál pro JUNOS.
Sečteno a podtrženo: možnosti pro podporu IPv6 v páteřních sítích existují, a to i pro produkční prostředí. Ostatně nejlepším důkazem jsou Japonci, kteří už tuto službu nabízejí. A nezapomeňte, že nejenom.
a
ale i
(Obrázky převzaty z http://www.v6start.net/. Netuším, co znamenají, ale moc se mi líbí.)