Hlavní navigace

IPv6 - přechodové mechanismy (1)

14. 3. 2002
Doba čtení: 6 minut

Sdílet

O tom, že nahrazení starého IPv4 novým protokolem IPv6 bude muset být pozvolné a nabídnout dostatečně dlouhou přechodovou dobu, kdy síť bude podporovat oba protokoly současně, není pochyb. Podívejme se dnes na mechanismy, které dosud byly vymyšleny k usnadnění jejich vzájemné budoucí koexistence.

Jsou především výsledkem práce skupiny Next Generation Transition (NGTRANS), která má v rámci IETF v popisu práce právě tyto aktivity. Lze je rozdělit do tří kategorií: dvojí zásobník, tunelování a překladače.

Dvojí zásobník (dual stack)

Tento přístup by zřejmě napadl každého: počítače prostě budou podporovat dva protokoly a pro komunikaci se podle potřeby použije IPv4 nebo IPv6 – v závislosti na schopnostech protějšího konce. Oba se zpravidla chovají jako navzájem nezávislé a případná komunikace mezi nimi probíhá až na úrovni aplikační vrstvy.

V tomto režimu se nyní nachází valná většina zařízení podporujících IPv6. Má pochopitelně jedno velmi zásadní omezení: vyžaduje přítomnost IPv4 a tedy IPv4 adresu. Z hlediska perspektivy dalšího rozvoje tudy cesta nepovede, protože právě IPv4 adresy začínají docházet.

Ovšem prvky s dvojím zásobníkem se objevují prakticky ve všech dalších přechodových mechanismech. V nich se datagramy převádějí z jednoho světa do druhého.

Tunelování

Nejvýznamnější specifikace

Základní mechanismy tunelování RFC 2473
Tunel server, tunel broker RFC 3053
6to4 RFC 3056
6over4 RFC 2529
ISATAP draft-ietf-ngtrans-isatap

Tunelování je obecný princip, jak protlačit data jim nepřátelským územím. V našem případě se typicky jedná o přenos IPv6 datagramů sítí, která podporuje jen IPv4 (v pozdějších fázích přechodu se očekává, že to bude právě naopak). Tunel představuje virtuální dvoubodový spoj. Na jednom jeho konci se IPv6 datagram zabalí jako data do běžného IPv4 datagramu a pošle se na IPv4 adresu druhého konce tunelu. Tam se původní IPv6 datagram vybalí a odešle dál – buď IPv6 sítí nebo třeba dalším tunelem. To záleží na zdejších směrovacích tabulkách.

Nejjednodušší případ představují manuální tunely, které je třeba explicitně nakonfigurovat. Správci obou koncových systémů musí zadat příkazy, jimiž se vytvoří tunel, a podniknout kroky k jeho začlenění do směrovacích tabulek na obou zařízeních. Právě manuálně konfigurované tunely dnes drží pohromadě síť 6bone.

Pomocnou ruku – především pro uživatele či administrátory menších sítí – zde nabízejí tunel servery. Jedná se o veřejně nabízené koncové body tunelů. Uživatel vyplní WWW formulář, na základě zadaných údajů se na tunel serveru vytvoří protější strana tunelu a uživatel dostane poštou skript s konfiguračními příkazy pro svůj systém. Když jej spustí, vznikne jeho konec tunelu a připojí tak svůj počítač k IPv6 síti. Je to snadné a může to vyzkoušet prakticky každý – například na Freenet6.

Jelikož se v praxi ukázalo, že rozhraní pro uživatele a vlastní realizace tunelu jsou dva dost odlišné úkoly, došlo k rozdělení práce. Tunel broker dostal na starosti správu systému, komunikaci s uživateli a řízení dalších komponent. Naproti tomu tunel server bývá typicky směrovač, který pouze zajišťuje vlastní tunelování. Jeden tunel broker tak může řídit celou skupinu tunel serverů a například vybírat pro každého uživatele ten z nich, který je pro něj topologicky nejvýhodnější.

Vedle manuálních tunelů jsou k dispozici i tunely automatické. Jedny vycházejí přímo z IPv6 adres. Pokud má počátečních 96 bitů nulových, představuje adresu pro automatické tunelování. Posledních 32 bitů se interpretuje jako IPv4 adresa, datagram se zabalí do IPv4 a pošle na ni. Zatím se ale nezdá, že by tento způsob komunikace čekala zářná budoucnost – například proto, že předpokládá podporu IPv4 na cílovém stroji. Zajímavější jsou jiné mechanismy pro automatické tunelování.

6to4

Jako daleko nadějnější se jeví 6to4. Vychází z předpokladu, že máme dvě koncové IPv6 sítě, mezi nimiž leží konfekční IPv4 Internet. Na hranici mezi nimi a Internetem bude směrovač podporující 6to4. Data poběží koncovými sítěmi v nativním IPv6 a mezi oběma hraničními směrovači se budou tunelovat. K tomu hraniční směrovač potřebuje alespoň jednu IPv4 adresu.

Z ní se vytvoří 6to4 prefix pro adresy koncové sítě. Konstruuje se tak, že za počátečních 16 bitů s hodnotou 2002 (šestnáctkově) se připojí 32 bitů IPv4 adresy hraničního směrovače. Tím vznikne obvyklý 48 bitů dlouhý prefix, kterým lze adresovat podsítě a počítače v koncové síti. Jediná IPv4 adresa tak pro ni umožňuje zavést plnohodnotné IPv6 adresy.

Kdykoli hraniční směrovač dostane datagram s prefixem začínajícím 2002::/16, vyzvedne si z následujících 32 bitů IPv4 adresu a na ni datagram pošle tunelem. Pokud naopak dorazí tunelovaná data na jeho vlastní IPv4 adresu, vybalí IPv6 datagram a odešle jej do „své sítě“. Báječnou vlastností tohoto schématu je, že nevyžaduje žádné úpravy v uzlech. Vše je postaveno na standardních mechanismech, jediným novým prvkem je hraniční 6to4 směrovač. Stačí, aby ohlašoval do lokální sítě směrovací informaci, že přes něj vede cesta do sítě 2002::/16 a vše bude skvělé.

6over4

Zatímco 6to4 řeší otázku vzájemné komunikace mezi koncovými IPv6 sítěmi, 6over4 míří přímo do nich. Počítá s tím, že koncová síť umí pouze IPv4 a snaží se zajistit, aby v ní mohly působit IPv6 stroje. V podstatě používá IPv4 síť jako linkový protokol pro přenos IPv6 datagramů.

6over4 staví na standardních mechanismech, jako je objevování sousedů a podobně. Když chce odeslat data jinému počítači ve zdejší síti, zjistí si prostřednictvím objevování sousedů jeho IPv4 adresu a na ni pak odešle tunelovaný IPv4 datagram. Vlastní adresu si může zjistit z ohlášení směrovače a podobně.

Je tu ale nemalý zádrhel. Mechanismy objevování sousedů používají skupinové adresy (multicast). 6over4 definuje postup, jak se tyto adresy mapují na IPv4 skupiny (převezmou se jejich poslední dva bajty a před ně se předřadí 239.192). Vyžaduje však, aby koncová síť podporovala skupinové adresování. Bohužel při současném stavu multicastu na datových tocích to není vůbec triviální požadavek. Nad praktickou použitelností 6over4 tak visí velký otazník.

ISATAP

Analogické cíle, ale menší nároky má Intra-Site Automatic Tunnel Addressing Protocol (ISATAP). Také zde se řeší otázka vzájemné komunikace IPv6 strojů v koncové síti, která podporuje jen IPv4. A rovněž se IPv4 používá jako protokol linkové vrstvy. Tentokrát se však nekladou na IPv4 žádné speciální nároky.

ISATAP kóduje IPv4 adresy strojů do identifikátoru rozhraní, tedy do závěrečných 64 bitů. Konstruuje identifikátor tak, že jeho počátečních 32 bitů obsahuje 0000:5EFE. Za ně se připojí 32 bitů s IPv4 adresou odpovídajícího rozhraní.

Když ISATAP rozhraní dostane datagram ze své podsítě s takto konstruovaným identifikátorem, tuneluje jej uvnitř IPv4 datagramu na adresu, kterou získá z jeho závěrečných čtyř bajtů. Pokud tento leží v jiné síti či podsíti, přijde ke slovu směrování. Aby vše fungovalo, měl by „next hop“ ve směrovací tabulce používat zdejší ISATAP adresu, aby byl dosažitelný prostřednictvím ISATAP sítě.

ISATAP nemá žádné požadavky na prefix sítě a podsítě (prvních 64 bitů adresy) – ty mohou být zcela libovolné. Například se může jednat o 6to4 prefix. Je tedy docela dobře představitelné schéma, že v lokální IPv4 síti se IPv6 datagramy budou tunelovat na bázi ISATAP k hraničnímu 6to4 směrovači, který je protuneluje do cílové sítě a zde opět nastoupí ISATAP, aby datagramy dopravil k adresátovi.

Největším zádrhelem ISATAP je plnění tabulky implicitních směrovačů. Hromadné ohlášení směrovače tu není k dispozici (od IPv4 se neočekává podpora skupinových či oznamovacích adres). Plánuje se tedy využití DNS, případně manuální konfigurace, následované ověřováním prostřednictvím individuálně adresované výzvy směrovači a jeho odpovědi.

BRAND24

ISATAP se zatím nachází ve fázi pracovního návrhu (draft). Svými minimálními požadavky na IPv4 je lákavý, ale obávám se, že vyžaduje příliš zásadní úpravy na straně všech uzlů lokální sítě. Uvidíme, zda se mu podaří oslovit širší spektrum uživatelů.

Všechny dosud popsané metody měly jednu společnou vlastnost: oba komunikující partneři hovořili stejným protokolem. Co když ale budu chtít ze svého IPv6 klienta hovořit se serverem, který podporuje výlučně IPv4. Toto je úloha pro překladače, kterým se budu věnovat příště.

Který z přechodových mechanismů je vám nejsympatičtější:

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

Autor článku

Autor dělá nepořádek v příslovích, protože sítě nejen dělá, ale i učí a dokonce také řídí. Působí na Ústavu nových technologií a aplikované informatiky na Technické univerzitě v Liberci. Píše knihy.
Upozorníme vás na články, které by vám neměly uniknout (maximálně 2x týdně).