Konwerter IPv4 na IPv6

Cztery oktety IPv4 tworzą dokładnie 32 bity

Adres IPv4 192.0.2.128 składa się z czterech liczb po osiem bitów. W zapisie szesnastkowym są to c0, 00, 02 i 80. Po połączeniu otrzymujemy 32-bitową wartość c0000280, którą można podzielić na dwa pola po 16 bitów: c000 oraz 0280.

IPv6 ma osiem pól po 16 bitów. Osadzenie IPv4 polega na umieszczeniu jego 32 bitów w określonych pozycjach adresu IPv6, a pozostałe 96 bitów wynika z wybranego prefiksu i formatu. Sama zamiana systemu liczbowego nie wybiera jeszcze znaczenia adresu.

Kalkulator pokazuje obie 16-bitowe części, pełny zapis z czterema cyframi oraz skróconą postać. Dzięki temu można sprawdzić każdy etap, zamiast traktować wynik jak nieprzejrzysty ciąg znaków. Oktety IPv4 zachowują swoją kolejność sieciową.

W zapisie skróconym 0280 zmienia się w 280

RFC 5952 zaleca usuwanie zer wiodących z każdego 16-bitowego pola. Dlatego końcówkę c000:0280 zapisujemy kanonicznie jako c000:280. Nie zmienia to bitów adresu; jest tylko krótszą reprezentacją tekstową tej samej wartości.

Ciąg podwójnego dwukropka zastępuje najdłuższą sekwencję pól równych zero i może wystąpić w adresie tylko raz. Pełne 0000:0000:0000:0000:0000:ffff:c000:0280 skraca się więc do ::ffff:c000:280. Rozwinięcie musi zawsze dać osiem pól.

RFC 5952 zaleca również małe litery a–f. Parser IPv6 zwykle zaakceptuje wielkie litery i zera wiodące, ale jeden kanoniczny format ułatwia wyszukiwanie w logach, porównywanie konfiguracji i unikanie duplikatów zapisanych na kilka sposobów.

Zapis mieszany może pozostawić kropkowany IPv4

Dla adresu IPv4-mapped spotyka się postać ::ffff:192.0.2.128. Ostatnie 32 bity są tu pokazane w znanym zapisie dziesiętnym z kropkami, choć binarnie są identyczne z c000:0280. Jest to czytelne dla operatora analizującego połączenie IPv4 przez interfejs IPv6.

Zapis ::ffff:192.0.2.128 i ::ffff:c000:280 opisuje tę samą wartość. Pełna postać ułatwia analizę bitów i prefiksu, a mieszana szybkie rozpoznanie oryginalnego IPv4. Kalkulator umieszcza obie w tabeli, lecz jako wynik główny stosuje skrócony zapis szesnastkowy.

Nie każda biblioteka, baza danych i reguła zapory normalizuje adresy w taki sam sposób. Przy porównywaniu tekstu najpierw sparsuj adres do wartości 128-bitowej lub zastosuj spójną normalizację. Zwykłe porównanie ciągów uzna równoważne postacie za różne.

Prefiks ::ffff:0:0/96 ma konkretne znaczenie

RFC 4291 definiuje IPv4-mapped IPv6 jako 80 bitów zer, następnie 16 bitów jedynek i na końcu 32 bity adresu IPv4. Dla 192.0.2.128 otrzymujemy ::ffff:c000:280. W tej formie oprogramowanie może przechowywać informację o kliencie IPv4 w strukturze zdolnej pomieścić IPv6.

Taki adres często pojawia się przy gnieździe nasłuchującym dual-stack. Aplikacja używa interfejsu IPv6, ale połączenie faktycznie przyszło przez IPv4, więc system przekazuje zmapowaną reprezentację. To pomaga obsłużyć oba protokoły wspólnym kodem, zależnie od ustawień stosu.

Nie należy przypisywać ::ffff:c000:280 jako zwykłego adresu IPv6 interfejsu ani ogłaszać go w routingu. Jest to oznaczenie adresu IPv4 w przestrzeni reprezentacji IPv6. Pakiet wysłany do takiego tekstu nie zyskuje magicznie ścieżki do hosta IPv4 przez Internet IPv6.

Mapped nie oznacza natywnego adresu tego samego hosta

Host 192.0.2.128 może mieć zupełnie niezależny natywny adres IPv6, na przykład przydzielony z prefiksu operatora. Nie da się go wyliczyć z IPv4 bez znajomości planu adresacji. Wynik mapped nie zastępuje rekordu AAAA i nie jest odpowiednikiem routowalnym w sieci IPv6.

Jeżeli migracja wymaga adresu dla serwera dual-stack, administrator musi przydzielić prawidłowy prefiks IPv6, skonfigurować interfejs, routing, DNS oraz zapory. Konwerter może pomóc w logach lub API, ale nie projektuje adresacji i nie sprawdza, czy wybrany prefiks należy do organizacji.

W szczególności prywatny IPv4 nie staje się publicznym IPv6 po dodaniu ::ffff. Informacja o zakresie i osiągalności IPv4 pozostaje. 10.0.0.1 zapisane jako ::ffff:a00:1 nadal reprezentuje adres IPv4 10.0.0.1, a nie globalny punkt w IPv6.

Logi powinny normalizować i zachować typ źródła

Jeżeli aplikacja zapisuje jednych klientów jako 192.0.2.128, a innych jako ::ffff:192.0.2.128, raport może rozdzielić tę samą wartość na dwa rekordy. Warto ustalić politykę: przechowywać binarnie z rodziną adresu albo normalizować mapped z powrotem do IPv4 tam, gdzie ma to sens.

Reguły dostępu również muszą rozpoznawać mapped. Lista blokująca 192.0.2.128 może nie objąć tekstu ::ffff:c000:280, jeśli warstwa aplikacyjna porównuje napisy zamiast adresów. Testuj wejście przez IPv4 i IPv6 oraz zachowanie frameworka, reverse proxy i serwera aplikacji.

Przy przekazywaniu adresu przez nagłówki proxy dochodzi problem zaufania do źródła. Sam format IPv6 nie potwierdza, kto go wstawił. Loguj adres połączenia oraz zweryfikowany łańcuch proxy zgodnie z architekturą, a nie przyjmuj dowolnego tekstu klienta jako wiarygodnego IP.

Adres działa tylko wtedy, gdy sieć kieruje go do translatora

Klient IPv6 wysyła pakiet do syntetycznego adresu. Routing musi doprowadzić go do urządzenia NAT64, które wyciągnie ostatnie 32 bity i utworzy ruch IPv4 do 192.0.2.128. Odpowiedź wraca przez translator i jest przedstawiana klientowi jako ruch IPv6.

Jeżeli w danej sieci nie ma trasy do Pref64 ani poprawnie skonfigurowanego translatora, sam adres 64:ff9b::c000:280 będzie nieosiągalny. Konwerter wykonuje syntezę bitową, ale nie bada routingu, polityki operatora, puli źródłowych IPv4, stanów sesji ani obsługi protokołu.

NAT64 nie gwarantuje działania każdej aplikacji. Protokoły umieszczające literalne adresy IPv4 w danych, wymagające połączeń inicjowanych z drugiej strony albo zależne od nietypowych mechanizmów mogą potrzebować dodatkowych bram. Test musi obejmować rzeczywistą usługę, nie tylko ping.

DNS64 zwykle tworzy adres z rekordu A

IPv6-only klient pyta o rekord AAAA. Jeżeli nazwa nie ma natywnego AAAA, DNS64 może pobrać rekord A i zbudować syntetyczny adres IPv6 zgodny z prefiksem translatora. RFC 6147 opisuje taki mechanizm współpracy DNS64 z NAT64.

Dla A równego 192.0.2.128 i Pref64 64:ff9b::/96 odpowiedzią syntetyczną może być 64:ff9b::c000:280. Klient łączy się z tym adresem po IPv6, a translator dociera do serwera IPv4. Aplikacja zwykle używa nazwy i nie musi ręcznie przeliczać adresu.

Gdy istnieje prawdziwy rekord AAAA, DNS64 domyślnie nie powinien dodawać syntetycznego odpowiednika. Natywna łączność IPv6 i translacja mają inne właściwości. Ręczne wstawianie syntetycznych rekordów bez znajomości polityki DNS64 może kierować ruch niepotrzebnie przez NAT.

Najpierw wybierz zastosowanie, dopiero potem tryb

Jeśli analizujesz adres zwrócony przez gniazdo dual-stack, log lub bibliotekę, wybierz IPv4-mapped. Jeśli budujesz adres celu w konkretnej sieci NAT64 używającej well-known prefix, wybierz NAT64. Te dwa pytania prowadzą do różnych wyników mimo tego samego IPv4.

Jeśli potrzebujesz natywnego adresu IPv6 serwera, żaden z tych trybów nie jest odpowiedzią. Odczytaj konfigurację interfejsu, DHCPv6, SLAAC, system IPAM albo rekord AAAA. Nie istnieje globalny algorytm, który z dowolnego publicznego IPv4 wyprowadza przydzielony hostowi IPv6.

Jeśli pracujesz z network-specific prefix NAT64, użyj narzędzia obsługującego długość i układ tego prefiksu. Proste doklejenie IPv4 na końcu jest poprawne dla /96, lecz RFC 6052 definiuje również inne długości z określonym rozmieszczeniem bitów.

Rozwiń adres do ośmiu pól przy ręcznej kontroli

Dla mapped pełny wynik to 0000:0000:0000:0000:0000:ffff:c000:0280. Widać pięć pól zer, ffff oraz dwa pola IPv4. Dla NAT64 /96 pełny wynik to 0064:ff9b:0000:0000:0000:0000:c000:0280.

Policz pola po rozwinięciu. Podwójny dwukropek musi uzupełniać dokładnie tyle zer, aby razem było osiem grup. Błąd o jedną grupę przesuwa 32 bity IPv4 i tworzy inny adres, nawet jeśli końcówka c000:280 nadal wygląda znajomo.

Możesz również odwrócić proces: c000 to 192 i 0, a 0280 to 2 i 128, więc wraca 192.0.2.128. Taka kontrola jest szczególnie użyteczna w regułach zapory i dokumentacji, gdzie literówka może pozostać syntaktycznie poprawnym IPv6.

Testuj rozwiązywanie nazwy, trasę i połączenie aplikacji

W środowisku NAT64 sprawdź odpowiedź AAAA z właściwego resolvera, odkryty lub skonfigurowany Pref64, trasę do translatora oraz dostępność docelowego IPv4. Samo porównanie tekstu z kalkulatorem potwierdza syntezę, ale nie potwierdza całej ścieżki.

Przetestuj TCP lub UDP używany przez usługę, nie wyłącznie ICMP. Sprawdź DNSSEC, certyfikaty związane z nazwą, timeouty, MTU i logi translatora. Przy problemie ustal, czy zawiodło DNS64, routing IPv6, stan NAT64, routing IPv4 czy sama aplikacja.

W dokumentacji zapisz oryginalny IPv4, rodzaj formatu, prefiks z długością oraz wynik. Zapis „przekonwertowano na IPv6” jest zbyt nieprecyzyjny. „IPv4-mapped ::ffff:c000:280” albo „NAT64 WKP 64:ff9b::c000:280” od razu mówi, do czego adres ma służyć.

IPv4-mapped i NAT64 odpowiadają na dwa różne problemy

Adres IPv4-mapped IPv6 ma prefiks ::ffff:0:0/96 i jest używany głównie przez oprogramowanie, które chce reprezentować połączenia IPv4 w strukturze przeznaczonej na adres IPv6. Nie oznacza to, że pakiet IPv6 z takim adresem można po prostu wysłać przez Internet. To zapis wewnętrzny spotykany między innymi w interfejsach gniazd i logach serwerowych.

Prefiks 64:ff9b::/96 jest natomiast dobrze znanym prefiksem syntezy dla mechanizmów NAT64. Umieszczenie 32 bitów IPv4 w jego końcówce tworzy adres, do którego klient IPv6 może kierować ruch, jeśli w sieci rzeczywiście działa translator NAT64. Samo wyliczenie adresu nie uruchamia translacji, nie konfiguruje DNS64 i nie rozwiązuje ograniczeń protokołów przenoszących adresy w danych aplikacyjnych.

Ostatnie 32 bity wynikają z czterech oktetów IPv4

Każdy oktet IPv4 zamienia się na dwie cyfry szesnastkowe. Dla 192.0.2.128 otrzymujemy kolejno c0, 00, 02 i 80, czyli osiem cyfr c0000280. Po podziale na hekstety zapis ma postać c000:0280, a z pominięciem wiodących zer — c000:280. Konwerter wykonuje właśnie tę reprezentację, pozostawiając prefiks wybranego mechanizmu bez zmian.

W zapisie IPv6 wolno usuwać wiodące zera w hekstecie i jednokrotnie skrócić najdłuższy ciąg zer symbolem ::. Dlatego ten sam adres może wystąpić w logu w formie skróconej lub rozwiniętej. Przy porównywaniu nie należy zestawiać samych tekstów; adresy trzeba sparsować i znormalizować. Inaczej dwa równoważne zapisy mogą zostać uznane za różne klucze lub różne reguły dostępu.

1. Sprawdź poprawność wszystkich czterech oktetów IPv4.
2. Zamień każdy oktet na dwucyfrowy zapis szesnastkowy.
3. Połącz osiem cyfr w dwa hekstety.
4. Dołącz prefiks właściwy dla IPv4-mapped albo NAT64.

Co należy zweryfikować przed użyciem wyniku

Dla NAT64 ustal prefiks skonfigurowany w konkretnej sieci. Organizacja może używać własnego prefiksu zamiast 64:ff9b::/96, a wtedy wynik z prefiksem dobrze znanym nie będzie prowadził do translatora. Sprawdź też routing IPv6, reguły zapory, DNS64 oraz dostępność docelowej usługi po IPv4. Każdy z tych elementów może przerwać połączenie mimo poprawnie zbudowanego adresu syntetycznego.

W logach aplikacyjnych zachowaj informację, czy zapis pochodzi z adresu klienta IPv4, translacji czy natywnego IPv6. Sprowadzanie wszystkiego do podobnego tekstu może utrudnić analizę incydentu i stosowanie limitów. Wyniku nie należy także traktować jako metody migracji bazy adresów: polityki, listy blokad i geolokalizacja muszą świadomie obsługiwać obie rodziny oraz znormalizowane formaty.