Mechanizm 6to4, rozpoznawalny po charakterystycznym prefiksie 2002::/16, był przez lata jednym z najpopularniejszych sposobów na wprowadzenie protokołu IPv6 do sieci, które natywnie obsługiwały tylko IPv4. Choć technologia ta odegrała ogromną rolę w popularyzacji nowego standardu adresowania, dziś uznaje się ją za przestarzałą. Czy jednak to samo tunelowanie było głównym powodem jego deprecjacji? Odpowiedź jest złożona, ponieważ problemem nie był sam fakt "pakowania" pakietów IPv6 w IPv4, ale sposób, w jaki ten konkretny mechanizm zarządzał ruchem.

Dlaczego 6to4 przestało być dobrym rozwiązaniem?

Głównym powodem deprecjacji 6to4 (zgodnie z dokumentem RFC 7526) nie był sam fakt wykorzystania tunelowania, lecz jego nieprzewidywalność i brak niezawodności. W przeciwieństwie do tuneli konfigurowanych ręcznie, gdzie administrator ma kontrolę nad oboma końcami połączenia, 6to4 opierało się na publicznych przekaźnikach (anycast relay). To generowało szereg problemów, z którymi współczesny internet nie chciał się już mierzyć.

Największą bolączką była asymetria ruchu. Pakiet wysłany z Twojego komputera mógł trafić do internetu przez jeden przekaźnik, ale odpowiedź mogła wracać przez zupełnie inny, znajdujący się na drugim końcu świata. To powodowało ogromne opóźnienia (latency) oraz częste gubienie pakietów. W świecie, gdzie liczy się każda milisekunda, taka niestabilność była nie do zaakceptowania.

Problemy z MTU i "czarne dziury" w sieci

Kolejnym gwoździem do trumny 6to4 były kwestie techniczne związane z rozmiarem pakietów, czyli MTU (Maximum Transmission Unit). Ponieważ pakiet IPv6 musiał zostać "opakowany" w nagłówek IPv4, jego efektywny rozmiar malał. Jeśli sieć po drodze nie radziła sobie z fragmentacją lub mechanizm Path MTU Discovery zawodził, pakiety po prostu znikały.

Tworzyło to tzw. "czarne dziury", gdzie użytkownik miał wrażenie, że połączenie istnieje (np. ping działał), ale strony internetowe ładowały się tylko do połowy lub wcale. Dla przeciętnego użytkownika wyglądało to na awarię internetu, co skutecznie zniechęcało do wdrażania IPv6.

Czy tunelowanie samo w sobie jest złe?

Warto zaznaczyć, że tunelowanie jako technika wciąż ma się dobrze. Mechanizmy takie jak 6rd (IPv6 Rapid Deployment), który jest ewolucją 6to4, czy DS-Lite (Dual-Stack Lite) są powszechnie stosowane przez dostawców usług internetowych (ISP). Różnica polega na tym, że w tych przypadkach tunelowanie odbywa się wewnątrz kontrolowanej sieci operatora, a nie w otwartym, publicznym internecie.

Deprecjacja 6to4 wynikała więc z faktu, że był to mechanizm "najlepszego starania" (best-effort), który w dobie dojrzałego internetu stał się zbyt zawodny.

Ciekawostka: Prefiks 2002::/16 wciąż można spotkać

Mimo że RFC 7526 oficjalnie wycofało wsparcie dla prefiksu anycastowego 192.88.99.0/24 (który był bramą dla 6to4), w niektórych starych konfiguracjach routerów wciąż można natknąć się na ślady tego mechanizmu. Jeśli zobaczysz adres zaczynający się od 2002:, wiesz już, że masz do czynienia z cyfrowym "reliktem", który prawdopodobnie generuje więcej problemów niż korzyści.

Oficjalny status i co dalej?

Obecnie standardem, do którego dąży cały świat, jest Native IPv6 (Dual Stack). Mechanizm 6to4 został przeniesiony do statusu "Historic", co oznacza, że nie powinien być już implementowany w nowych urządzeniach ani używany w nowoczesnych sieciach.

Podsumowując, 6to4 nie upadło dlatego, że tunelowało dane, ale dlatego, że robiło to w sposób niekontrolowany i podatny na błędy. Współczesne metody przejściowe wyciągnęły lekcję z tej lekcji historii, stawiając na stabilność i pełną kontrolę nad ścieżką, jaką pokonują dane.