Podrobněji jsme se principům 6to4 a příbuzného mechanismu 6rd věnovali ve starším článku, nebudeme se proto opakovat. Jen jednou větou shrneme, že v 6to4 se z jedné veřejné IPv4 adresy vytvoří IPv6 prefix standardní délky 48 bitů, jehož adresy jsou následně automaticky tunelovány IPv4 sítí.
Hlavní předností tohoto přístupu je naprostá nezávislost. Nepotřebujete žádnou podporu od svého poskytovatele Internetu, stačí jen ta jedna veřejná IPv4 adresa a zařízení podporující 6to4, abyste mohli zavést IPv6 do celé koncové sítě. Na některých platformách se to děje automaticky – mají-li veřejnou IPv4 adresu a nemají nativní IPv6, automaticky si vytvoří 6to4 připojení. Důsledkem je značná popularita – ve všech statistikách předčí objem 6to4 provozu jakékoli jiné způsoby IPv6 komunikace. To se nepochybně postupně změní ve prospěch nativního připojení, zatím však 6to4 vede.
Zkušenosti s praktickým využíváním bohužel ukazují, že 6to4 trpí řadou neduhů. Těmi nejvýznamnějšími jsou následující:
-
Problémy s MTU, společné všem tunelovacím mechanismům. Zabalení jednoho paketu do druhého znamená jednu IP hlavičku navíc a pokud byl původní datagram dimenzován na maximum (např. v Ethernetu na 1500 B), obalující datagram už je příliš velký a nelze jej vcelku odeslat.
-
6to4 používá obecný tunelovací princip GRE, kdy obalující datagram obsahuje jako typ nesených dat hodnotu 41. Některými firewally takové datagramy neprojdou.
-
Při komunikaci s nativním IPv6 je směrování asymetrické – každý z partnerů posílá pakety na sobě nejbližší relay. Asymetrické směrování je obecně vnímáno jako nežádoucí, ale nemusí nutně znamenat akutní problém.
-
Pokud se však problém vyskytne, poskytovatel Internetu má jen omezené možnosti k jeho vyřešení. Může provozovat svou vlastní 6to4 relay, která poskytne kvalitní služby jeho zákazníkům, ovšem jen na jedné straně. Jestliže nefunguje relay, na kterou jsou směrovány odpovědi pro některého ze zdejších uživatelů, nemá žádnou možnost, jak situaci napravit.
-
Potřebuje výběrové (anycast) směrování na adresu 192.88.99.1 používanou pro relay.
To vše vede k velmi vysoké chybovosti. Geoff Huston naměřil, že špatně skončí kolem 13 % požadavků přicházejících po 6to4, což je číslo vyloženě strašlivé.
Důsledkem je návrh na převedení 6to4 do historického stavu a jeho postupné opuštění, který aktuálně absolvuje první krůčky na cestě k RFC. Není drastický a nepožaduje okamžité zavržení 6to4, ukončení jeho směrování, vypálení všech budov, kde se kdy 6to4 vyskytlo, či podobná drakonická opatření. V jádru navrhuje následující:
-
Deklarovat 6to4 a jeho prefix 2002::/16 jako historické, prefix v nejbližší době nevyužívat pro jiné účely.
-
Na straně klientů používat 6to4 jen jako poslední záchranu. Všechny ostatní způsoby připojení by měly mít přednost.
-
6to4 připojení by nemělo být vytvářeno automaticky, ale jen na základě explicitní konfigurace.
-
Existující implementace samozřejmě poběží dál, proto je záhodno, aby zatím nedocházelo k vypínání relay. Útlum by měl být postupný.
Opustit 6to4 není zrovna snadné pro jeho nemalou popularitu. Ve výše odkazovaném Hustonově měření bezmála 80 % všech IPv6 požadavků přicházelo touto cestou. Jestliže je IETF pustí k vodě, jaké mají jeho stávající uživatelé možnosti?
Situace naštěstí není tak zlá jako v případě NAT-PT, u kterého se teprve po zrušení začala vyvíjet následnická technologie NAT64. Už dnes máme dvě alternativy:
-
6rd, což je v jádru 6to4, ovšem s odlišným adresováním a organizačním obalem. Je provozováno pod křídly jednoho poskytovatele, který tudíž má datové toky pod kontrolou a dokáže garantovat funkčnost. 6rd je díky tomu spolehlivější, ovšem pokud je váš poskytovatel neprovozuje, máte smůlu. Na rozdíl od 6to4 si je nemůžete uvést do provozu sami.
-
Manuální tunely získané prostřednictvím tunel brokerů. Vyžadují určité úsilí při konfiguraci a směrování IPv6 nebude ideální, ovšem na druhé straně si takový tunel může vytvořit kdokoli kdekoli a je vázán pouze na provozovatele tunel brokeru.
6to4 tedy je čím nahradit a jeho opuštění by nemělo bolet tolik jako v případě NAT-PT. Než se tak ale stane, bylo by záhodno, aby fungovalo pokud možno co nejlépe. K tomuto cíli směřují technická doporučení pro 6to4 orientovaná zejména na provozovatele sítí a služeb. Zde se lze dočíst, na co dávat pozor a jak zajistit, aby nedokonalé 6to4 fungovalo pro dotčené uživatele, jak to jenom jde. S nativním IPv6 ale nikdy srovnatelné nebude.
