Szóstka na rozbiegu

Rezultaty testów prowadzonych w ramach europejskiej sieci powstałej w projekcie 6NET pokazują, że IPv6 można już wykorzystać do świadczenia usług komercyjnych. Do rozwiązania wciąż jest jednak sporo większych i mniejszych problemów - nie tylko na poziomie implementacji, ale także w sferze standardów szczegółowych.

Rezultaty testów prowadzonych w ramach europejskiej sieci powstałej w projekcie 6NET pokazują, że IPv6 można już wykorzystać do świadczenia usług komercyjnych. Do rozwiązania wciąż jest jednak sporo większych i mniejszych problemów - nie tylko na poziomie implementacji, ale także w sferze standardów szczegółowych.

Od opracowania pierwszej specyfikacji standardu protokołu IPv6 (RFC 1883) minęło już osiem lat - to wystarczająco długo, by jakikolwiek standard doczekał się implementacji. Realizacją funkcjonalności IPv6 szczycą się dziś prawie wszyscy dostawcy urządzeń sieciowych i systemów operacyjnych. Mimo to upowszechnienie się IPv6 na razie nie nastąpiło - ani w sieciach wewnętrznych firm, ani też w sieciach dużych operatorów.

Wiele wskazuje jednak na to, że okres wyczekiwania na wykorzystanie IPv6 dobiega właśnie końca. O tym, że najwyższy już czas wdrożyć IPv6, świadczą np. ostatnie działania Pentagonu, który ogłosił, że od października 2003 r. wszystkie nabywane przez amerykański Departament Obrony urządzenia sieciowe muszą być zgodne z IPv6 i umożliwiać bezproblemową współpracę z dotychczasową infrastrukturą opartą na IPv4.

Niezależnie od działań Pentagonu, w USA uruchomiono ogólnonarodowy, cywilny projekt Moon6 mający na celu przetestowanie protokołu IPv6 pod kątem wdrożeń w sieciach operatorskich. Zaangażowanie operatorów amerykańskich jest konieczne, ponieważ większość infrastruktury Internetu wciąż działa na terenie Stanów Zjednoczonych. Zakrojone na szeroką skalę testy, a nawet pierwsze komercyjne wdrożenia przeprowadzili już niektórzy operatorzy azjatyccy - najbardziej chyba dotknięci niedostatkiem wolnych adresów IP.

Europa jest znacznie bardziej zaawansowana pod względem testowania IPv6 niż USA.

Na naszym kontynencie od ponad dwóch lat trwa duży, międzynarodowy projekt 6NET, w którym mam przyjemność uczestniczyć z ramienia Poznańskiego Centrum Superkomputerowo-Sieciowego. Niniejszym chciałbym podzielić się z Państwem swoimi doświadczeniami i przemyśleniami na temat strategii wdrażania IPv6.

Pierwsze przymiarki

Dotychczasowe doświadczenia pokazują, że budowa całkiem nowych sieci na potrzeby IPv6 z reguły nie wchodzi w grę z powodów finansowych. Z konieczności więc protokół IPv6 jest wdrażany głównie w istniejących sieciach i działa równolegle z IPv4. Może to banał, ale każde uruchomienie protokołu IPv6 w sieci produkcyjnej muszą poprzedzać: dość szczegółowa analiza dokumentacji sprzętu i oprogramowania oraz testy praktyczne. Diabeł tkwi w szczegółach.

Najprostszym sposobem na uruchomienie transmisji IPv6 w sieci IPv4 jest tunelowanie pakietów IPv6 w IPv4, jednak już na tym początkowym etapie kryją się przeszkody.

Niektóre karty w routerach ograniczają przepustowość transmisji dla połączeń tunelowanych, inne zaś uniemożliwiają uruchomienie transmisji w trybie multicast. Takich problemów może być więcej, dlatego przeproszenie się z dokumentacją jest jak najbardziej wskazane.

Aby wykonać wstępne testy praktyczne, można połączyć się z 6bone - globalną testową siecią IPv6. Nie jest to jednak ścieżka optymalna. Ponieważ jest to sieć otwarta dla wszystkich zainteresowanych, zdarza się, że niektórzy nie przestrzegają ustalonych zasad polityki routingu, co powoduje dodatkowe problemy. Ponadto sieć 6bone obejmuje wiele długich (np. transatlantyckich) tuneli, w których występują dosyć długie opóźnienia. Od 1 stycznia 2004 r. wstrzymano przyznawanie pul pTLA (pseudo Top-Level Aggregation Identifiers) dla dostawców Internetu, a z dniem 6 czerwca 2006 r. sieć w ogóle przestanie działać. Dla ruchu produkcyjnego sieć 6bone jest w zasadzie nieprzydatna - znacznie lepszym pomysłem jest uzyskanie adresów produkcyjnych od dużych ISP lub własnej puli z RIPE.

Aby ograniczyć początkowe koszty uruchomienia IPv6, można wykorzystać techniki tunelowania na poziomie warstwy 2 modelu OSI (L2 VPN), np. MPLS/CCC Junipera, MPLS/ATOM Cisco lub tunelowanie UTI - również Cisco. Należy jednak wziąć pod uwagę, że w przypadku technik tunelowania dla interfejsów Ethernet i Fast Ethernet, gdzie MTU (Maximum Transmission Unit) wynosi 1500 bajtów, zostaje ono ograniczone do 1480 bajtów, co powoduje dodanie pewnych opóźnień. Zamiast tunelować IPv6 w IPv4, można posłużyć się łączem ATM. Takie rozwiązanie uniezależnia od protokołu IPv4 i nie ogranicza wartości MTU (która dla ATM jest większa). Z drugiej strony, ATM nie wspiera interfejsów o najwyższych prędkościach i jest relatywnie droga. Wszystko zależy więc od lokalnych możliwości technicznych i finansowych.

Przechodzenie od IPv4 do IPv6 będzie się odbywać stopniowo. Stan przejściowy będzie trwać tak długo, jak długo w sieci będą działać systemy wspierające tylko IPv4. Patrząc na "żywotność" DOS-a, pomimo upowszechnienia się systemów z interfejsem graficznym, trzeba założyć, że będzie to trwać jeszcze kilka ładnych lat. Być może, jeżeli potrzeba wdrożenia IPv6 jest pilna, a jednocześnie istnieje konieczność utrzymania infrastruktury IPv4, można by pokusić się o zakup oddzielnego sprzętu dla sieci IPv6. W praktyce będzie to jednak drogie i niezbyt wygodne - trzeba będzie zarządzać dwoma oddzielnymi sieciami.

Najbardziej naturalną i pożądaną strukturą sieci jest taka, w której protokoły IPv4 i IPv6 działają równolegle (dual stack). Rozwiązanie takie wymaga etapu przejściowego i poświęcenia czasu na sprawdzenie, czy wszystkie mechanizmy dla IPv6 działają dobrze i czy nie wpływa to negatywnie na działanie i wydajność dotychczasowej transmisji dla IPv4. W praktyce może to jednak okazać się trudne do wykazania.

Na etapie uruchamiania sieci IPv6 kluczową sprawą do rozważenia jest wybór właściwego protokołu routingu. Jak pokazują doświadczenia np. sieci GEANT, chodzi tu nie tylko o wydajność, lecz także o utrzymanie spójnej polityki routingu. Dostawcy Internetu muszą rozważyć, czy uruchamiać pojedynczy protokół IGP, obsługujący oba typy protokołów IP, czy też może dla każdego z nich uruchomić oddzielny protokół routingu. Przykładowo, równoległe uruchomienie protokołu OSPFv2 dla IPv4 i OSPFv3 dla IPv6 - jakkolwiek możliwe z punktu widzenia wydajności - wprowadza konieczność zarządzania dwoma bazami adresów IPv4.

W działających produkcyjnie kilku narodowych sieciach badawczych NREN (National Research and Educational Networks) wybrano protokół IS-IS obsługujący i IPv4, i IPv6. Wdrożenie protokołu poprzedzała seria testów, gdyż podczas wstępnych przygotowań operatorzy napotkali poważne problemy uniemożliwiające uruchomienie protokołu IPv6. Dotyczyły one zwłaszcza sieci heterogenicznych, w których działał sprzęt różnych producentów.