W trakcie trwającego tydzień eksperymentu z sieci IPv6 korzystało około 40 osób. Oprócz jednej poważnej awarii, której przyczyną był wadliwy kabel, sieć działała sprawnie i z wydajnością porównywalną do głównej sieci z podwójnym stosem, dostępnej dla uczestników konferencji. Wrażenie użytkowników korzystających z eksperymentalnej sieci były bardzo pozytywne. Niektóre osoby stwierdziły nawet, że nie zauważyły, że korzystały z tej sieci przez cały dzień. Podwójny stos pozostanie jeszcze przez lata preferowanym rozwiązaniem. Jednakże, jeśli organizacja ma wybór, dlaczego nie zdecydować się na IPv6? Taki krok oznacza, że sieć jest przygotowana na przyszłość. Jednocześnie umożliwia dostęp zarówno po IPv4, jak i IPv6.

Jednakże pojawiło się kilka problemów z oprogramowaniem klienckim. Trudności sprawiały aplikacje na smartfonach i tabletach. Komunikacja sieciowa działała poprawnie dla podstawowych aplikacji, jak przeglądarka WWW czy klient pocztowy. Z drugiej strony wiele aplikacji sprawdzało, czy urządzenie ma przydzielony adres IPv4, a przy jego braku uznawało, że nie ma łączności z siecią i zgłaszało komunikat o błędzie bądź przełączało się w tryb offline. Okazało się również, że niektórej aplikacje próbowały używać adresów IPv4 do uwierzytelniania lub śledzenia sesji.

Te problemy nie były szczególnie uciążliwe i można je był obejść, ale w przypadku mniej doświadczonych użytkowników z reguły w takiej sytuacji należy się liczyć z telefonem do help desku. To oznacza, że przejście na sieć wyłącznie IPv6 w dużym środowisku dostępnym dla konsumentów to jeszcze nie jest dobry pomysł. Mimo stałego nakłaniania twórców oprogramowania, aby swoje aplikacje przystosowywali nie tylko do obsługi protokołu IPv4, jest mało prawdopodobne, że opisane problemy znikną w najbliższym czasie.

Z tego powodu organizacja IETF opracowała alternatywę dla NAT64 o nazwie 464XLAT, które to rozwiązanie było używane podczas konferencji RIPE 67. Wykorzystując te same podstawowe zasady tłumaczenia połączeń IPv6 na IPv4, ta technika opiera się na drobnych modyfikacjach wprowadzanych do klienckiego systemu operacyjnego. W ten sposób ma się pewność, że dowolna aplikacja wykorzystująca protokół IPv4 otrzyma informację o dostępności adresu IPv4. Te aplikacje będę funkcjonowały w przekonaniu, że mają dostęp do w pełni funkcjonalnej sieci IPv4. Tymczasem w tle wszystkie połączenia są realizowane z wykorzystaniem IPv6.

Kilku producentów smartfonów wbudowuje już w swoje urządzenia obsługę 464XLAT. Ta technika jest również używana przez dużych, amerykańskich operatorów telekomunikacyjnych, również tych obsługujących sieć 4G. To potwierdza, że przy starannym planowaniu i testowaniu w niektórych przypadkach można pozwolić sobie na wyłączenie sieci IPv4 bez negatywnego wpływu na wydajność sieci czy zwiększenia liczby kontaktów z pomocą techniczną.

Plan migracji

Organizacja, która nie zamierza choćby opracować planu migracji na IPv6 naraża się na ryzyko, np. z czasem może utracić możliwość komunikowania się z klientami. Również strona internetowa takiej organizacji przestanie być dostępna, gdy upowszechni się protokół IPv6. Mogą pojawić się też inne problemy, np. spadek wydajności na skutek komunikacji poprzez NAT operatorski. Wiele poziomów translacji NAT oznacza dla firmy większą złożoność sieci, co utrudnia zarządzanie nią. Administratorzy sieciowi są w takiej sytuacji zmuszeniu do poświęcania znaczniej więcej czasu na zapewnienie komunikacji przestarzałej sieci IPv4 ze światem zewnętrznym korzystającym z IPv6.

Aby zaplanować strategię migracji IPv6, należy najpierw zrozumieć specyfikę adresacji IPv6. Podstawową różnicą jest nieporównywalnie większa przestrzeń adresowa wynosząca 2 do 128 potęgi. To oznacza, że adresami nie trzeba gospodarować tak oszczędnie, jak w przypadku IPv4. Warto zwrócić uwagę, że nie eliminuje to korzystania z NAT, jak powszechnie i błędnie się uważa.

NAT nie służy bowiem tylko do współdzielenia adresów publicznych z uwagi na ograniczoną przestrzeń IPv4. Ta technika ma też inne zalety, które są dostępne również w sieciach IPv6: ograniczenie ekspozycji hostów na ataki, ukrywanie topologii sieci lokalnej czy niezależność firmy od ISP w zakresie dysponowania adresami IP.

W sieci IPv6 adresy unicast oraz multicast funkcjonują w ten sam sposób, co ich odpowiedniki w sieci IPv4. Nowością w IPv6 są adresy anycast, które mogą być współdzielone przez wiele węzłów. Komunikat wysłany na adres anycast trafia tylko do jednego z interfejsów, który jest identyfikowany przez ten adres. Przykładowo, wszystkie serwery DNS w danej lokalizacji współdzielą jeden adres anycast, ponieważ wszystkie oferują tę samą usługę. Żądanie DNS wysłane na adres anycast trafi do tego serwera DNS, który znajduje się najbliżej węzła wysyłającego żądanie (wybór jest dokonywany na podstawie protokołów routingu). Ostatnim typem są mapowane adresy IPv4, wykorzystywane podczas migracji z IPv4 do IPv6.

Plan migracji obejmuje kilka obszarów, które należy uwzględnić. Pierwszym krokiem jest zrobienie rozpoznania własnej sieci i posiadanego sprzętu pod kątem możliwości obsługi IPv6. Przy tej okazji warto też zrobić rozeznanie wśród dostawców sprzętu i dostawców usług internetowych pod kątem ich planów i możliwości wsparcia dla IPv6. Może się okazać, że niektóre urządzenia sieciowe nie dadzą się zaktualizować i konieczny będzie zakup nowego sprzętu. Jeśli taka sytuacja wystąpi w przypadku routera IPv4, można podłączyć do niego router z obsługą IPv6. To pozwoli na utworzenie tunelu pomiędzy siecią IPv4 a siecią IPv6.

Od ISP należy wydobyć informacje o tym, jak obsługuje on protokół IPv6. Czy są to tunele IPv6, a może NAT pomiędzy sieciami IPv4 i IPv6? Przyda się również wiedza na temat tego, czy operator nadaje priorytety poszczególnym klasom ruchu sieciowego.

Kolejny obszar to aplikacje wykorzystywane w organizacji. Należy przyjrzeć się zarówno program „z pudełka”, jak i tym tworzonym na zamówienie. Dobrym pomysłem jest kontakt z twórcami tych aplikacji. Sytuacja komplikuje się, jeśli na jednym serwerze fizycznym działa kilka aplikacji, co przy dużej popularności wirtualizacji serwerów jest istotną kwestią. Może się bowiem okazać, że część aplikacji współpracuje poprawnie z IPv6, część wymaga IPv4, a jeszcze inne aplikacje są w stanie pracować z wykorzystaniem obu protokołów. Taka kombinacja może powodować różne problemy po stronie serwera.

Wybór terminu budowy wewnętrznej sieci IPv6 można połączyć z przejściem na ten protokół sieci zewnętrznej. Organizacja może również zdecydować, że nastąpi to w momencie, kiedy pojawi się wyraźne uzasadnienie biznesowe.