Kiedy IPv6 się zwróci

Technologiczne zawiłości mogą nie przekonać zarządu do wdrożenia IPv6. Silnym argumentem przemawiającym do biznesu jest oszacowanie stopy zwrotu. Kalkulacja ROI zależy przede wszystkim od topologii sieci, wykorzystywanych systemów, aplikacji, usług oraz firmowej strategii. Amerykański Department of Commerce (DoC) wykonał kilka lat temu analizę, z której wynika, że każdy dolar zainwestowany w budowę sieci IPv6 powinien przynieść 10 dolarów przychodu.

Przykładowo, trzeba odpowiedzieć na pytanie, czy będzie używany podwójny stos czy raczej od razu sieć firmowa zostanie przełączona na „czysty” IPv6. Zanim przejdzie się do wyliczeń, jest konieczne opracowanie planu migracji uwzględniającego analizę istniejącej infrastruktury, projekt przyszłej sieci oraz wskazującego na wszystkie czynniki generujące koszty bądź wpływające na przychody.

Funkcje IPv6 są już wbudowane w urządzenia sieciowe lub można je dodać poprzez instalację aktualizacji oprogramowania. Rodzaj i marka urządzeń, jak również ich wiek, będą miały różny wpływ w każdej sieci. Jeśli firma ma urządzenia zakupione w ostatnim czasie, IPv6 prawie na pewno będzie już w nie wbudowany. Przed wdrożeniem IPv6 powinno się zinwentaryzować posiadane urządzenia i oprogramowanie, a następnie określić, w jakim zakresie obsługują IPv6.

Pułapki migracji

Sukces wdrożenia IPv6 wymaga starannego zaplanowania, przeanalizowania możliwości obsługi tego protokołu przez posiadaną infrastrukturę i aplikacje, skalowalności oraz dostępności narzędzi do zarządzania. Jest kilka kwestii, na które należy szczególnie uważać, aby uniknąć typowych błędów i pułapek. Należy sprawdzić, czy urządzenia sieciowe przetwarzające sprzętowo pakiety IPv4 z wykorzystaniem dedykowanych układów potrafią to samo w przypadku pakietów IPv6 czy może ten protokół jest przetwarzany tylko programowo. W tym drugim przypadku trzeba liczyć się ze spadkiem wydajności sieci.

W przypadku aplikacji bliższe zbadania wymagają te, które “zwracają uwagę” na to, jaki protokół IP jest używany w sieci. Dotyczy to w szczególności aplikacji używających protokołu SIP (Session Initiation Protocol). W ich przypadku dostawcy i twórcy aplikacji bazujących na SIP muszą je modyfikować pod kątem obsługi IPv6 w nagłówku SIP.

Wsparcie operatorów dla IPv6 jest wciąż bardzo ograniczone, szczególnie dla takich usług, jak MPLS czy dostęp o Internetu dla użytkowników domowych (istotne, jeśli firma ma zdalnych pracowników). Jeśli obecny dostawca Internetu nie daje możliwości korzystania z IPv6, można go zmienić. Jednak są też inne sposoby wyjścia z sytuacji. Po pierwsze, można od drugiego dostawcy wykupić drugą linię do obsługi komunikacji IPv6, ale jest to kosztowne rozwiązanie. Drugi pomysł to skorzystanie z usług wirtualnego ISP. Tego rodzaju firmy mogą zapewnić łączność IPv6, ale nie oferują fizycznych łączy. Zamiast tego stworzą tunel przez sieć IPv4 fizycznego operatora do sieci operatora wirtualnego. Ostatnia koncepcja zakłada utworzeniu tunelu 6to4 poprzez sieć operatora do lokalizacji, która obsługuje IPv6.

Uwagi wymaga rozwiązanie typu multihoming (urządzenia podłączone do sieci z wykorzystaniem kilku interfejsów) oraz prywatna adresacja. Multihoming to standardowa praktyka w wielu firmach, ale schemat adresacji IPv6 został zaprojektowany jako hierarchiczna struktura agregująca trasy w celu uproszczenia tablic routingu. Twórcy IPv6 nie brali pod uwagę potrzeby stosowania prywatnej adresacji czy multihomingu, ale użytkownicy korporacyjni są zainteresowani tymi technikami ze względu na bezpieczeństwo i niezawodność. Dlatego korzystanie z multihomingu czy NATv6 wymaga koordynacji z ISP, a niezbędne może się okazać uzyskanie własnej puli adresów IPv6.

Po pokonaniu opisanych trudności z reguły na koniec zostaje największe wyzwanie. Współczesne sieci IP często składają się nie tylko z routerów, przełączników i urządzeń końcowych. Narzędzia do optymalizacji sieci WAN, platformy zarządzania, aplikacje do zarządzania zmianami, sensory czy urządzenia typu M2M również wymagają analizy pod kątem zgodności z IPv6. Trzeba też znaleźć rozwiązanie, jak zapewnić komunikację starym urządzeniom i aplikacjom, których nie da się zaktualizować do obsługi IPv6.

(Nie)bezpieczeństwo tuneli 6to4

Z natury tunele 6to4 pomiędzy routerami nie są bezpieczne. Problemy z bezpieczeństwem w takich tunelach są nieodłączne. Mimo że routery relay 6to4 kapsułkują i dekapsułkują pakiety, nie sprawdzają one danych zawartych w tych pakietach. Częstym problemem jest spoofing (podmiana) adresów. Dla ruchu przychodzącego router 6to4 nie jest w stanie porównać adresu IPv4 routera relay ze źródłowym adresem IPv6. Dlatego adres hosta IPv6 można łatwo podmienić bez wykrycia.

Domyślnie nie ma żadnego mechanizmu uwierzytelniającego pomiędzy routerami 6to4 a routerami 6to4 typu relay. Dlatego router 6to4 nie jest w stanie określić, czy router relay 6to4 można uznać za zaufany. Nie potrafi nawet zweryfikować, czy faktycznie ma do czynienia z routerem relay 6to4. Natomiast obie strony tunelu 6to4 powinny móc zweryfikować, czy rozmawiają z zaufanym urządzeniem, w przeciwny razie wystawiają się na możliwe ataki.

Biorąc pod uwagę opisane problemy, z routerów relay 6to4 należy korzystać tylko w specyficznych sytuacjach. Po pierwsze, jeśli tunele będą łączyć prywatne, zaufane sieci IPv6. Przykładowo, może to być połączenie w ramach sieci kampusowej składającej się z zamkniętej lokalizacji 6to4 oraz lokalizacji natywnie obsługującej IPv6. Kolejna sytuacją, to jeśli są istotne powody biznesowe przemawiające za komunikacją firmowej sieci 6to4 z urządzeniami natywnie używającymi adresów IPv6. Ostatnią sytuacją jest wdrożenie modelu bezpieczeństwa opisanego w dokumencie Security Considerations for 6to4 opracowanym przez IETF.