IPv6 bez strachu: praktyczny przewodnik dla sieciowców z epoki IPv4

Cel jest prosty: uruchomić IPv6 (najczęściej jako dual-stack) w istniejącej sieci IPv4 tak, żeby użytkownicy nie widzieli różnicy, a Ty miał(a) pełną kontrolę nad ruchem, DNS, routingiem i politykami bezpieczeństwa. Jeśli masz w głowie obawy typu „włączę i coś zacznie działać inaczej” — to dobra intuicja. IPv6 potrafi „pojawiać się samo” (link-local, automatyczne preferencje stosu), a typowe wpadki dotyczą tych samych obszarów: RA/ND, DNS, ICMPv6 i firewall.

Realne pytania, które zwykle padają przed pierwszym wdrożeniem

• Czy zaczynać od dual-stack wszędzie, czy od jednego VLAN-u pilotowego?
• Jak zaplanować adresację IPv6, żeby nie przepisywać jej po pół roku?
• SLAAC czy DHCPv6 — kto ma kontrolować DNS i ewidencję hostów?
• Co musi przechodzić przez firewall w IPv6 (zwłaszcza ICMPv6), żeby nie zrobić czarnej dziury?
• Czy mogę dodać rekordy AAAA „na próbę”, czy to proszenie się o incident?
• Jak testować: co uznać za „działa”, a nie tylko „ping przechodzi”?
• Jakie czerwone flagi wskazują, że RA albo routing wymknęły się spod kontroli?
• Jak zrobić rollout etapami i mieć realny rollback?

Te pytania przewijają się przez cały przewodnik, a odpowiedzi są ułożone proceduralnie: od celu, przez przygotowanie i projekt, po wdrożenie, weryfikację oraz listę najczęstszych pułapek.

wdrożenie IPv6 dual-stack, plan adresacji IPv6, SLAAC vs DHCPv6, Router Advertisement RA Guard, Neighbor Discovery ND, ICMPv6 PMTUD, DNS AAAA i reverse IPv6, firewall IPv6 zasady, testy ping6 traceroute6, OSPFv3 IS-IS BGP IPv6, happy eyeballs problemy

Krok 0 — ustaw cel i granice: co dokładnie ma działać po IPv6?

Minimalny „definition of done”, żeby nie skończyć na „ping przechodzi”

Zacznij od doprecyzowania: co ma działać po IPv6 i dla kogo. Sam fakt, że host dostanie adres IPv6, nie jest sukcesem. Sukcesem jest sytuacja, w której IPv6 jest poprawnie routowany, filtrowany, diagnozowalny i nie psuje aplikacji przez niekompletny DNS czy zbyt agresywny firewall.

Praktyczne „done” można zapisać jako listę usług. Niech będzie krótka, ale konkretna:

• Internet outbound po IPv6 z sieci użytkowników (HTTP/HTTPS, aktualizacje, NTP).
• Dostęp do usług firmowych (AD/LDAP, serwery plików, aplikacje webowe) — albo jasno: które jeszcze zostają IPv4-only.
• DNS działa poprawnie (rozwiązywanie AAAA tam, gdzie ma sens, oraz brak „zawieszania” się klientów przez błędne AAAA).
• VPN / zdalny dostęp — czy ma działać po IPv6 od razu, czy dopiero w kolejnym etapie.
• Monitoring i logi widzą IPv6: źródła, destynacje, alerty na problemy typowe dla v6 (RA, ND, PMTUD).

Pytanie diagnostyczne: czy celem jest dual-stack wszędzie, czy tylko wybrane segmenty (np. Wi‑Fi gościnne, IoT, VLAN testowy, serwery w DC)? Jeśli nie umiesz tego jednoznacznie powiedzieć, najbezpieczniej przyjąć pilot: jeden segment + jasne kryteria sukcesu.

Warunki brzegowe: kiedy stop, kiedy lab, kiedy tylko pilot

Nie każde środowisko jest gotowe na „włącz IPv6 i jedziemy”. Są warunki, które aż proszą się o etapowanie albo o lab przed produkcją.

Stop albo pilot ma sens, jeśli:

• Masz stare firewalle/CPE/kontrolery Wi‑Fi, które „mają IPv6”, ale bez sensownych polityk, logowania i diagnostyki.
• Wiesz o aplikacjach z twardo wpisanym IPv4 albo z IP-allowlistami, których nikt nie potrafi zmapować na IPv6.
• Nie masz pewności, czy zrobisz rollback bez cięcia kabli: czy umiesz wyłączyć RA na SVI, wycofać prefiksy z IGP/BGP, zdjąć AAAA z krytycznych nazw.

Pytanie kontrolne: co jest Twoim bezpiecznikiem? Jeśli coś pójdzie źle, czy potrafisz w minutę wyłączyć rozgłaszanie RA na danym VLAN-ie i przywrócić sytuację sprzed zmian? Bez tego dual-stack bywa „wdrożeniem, którego nie da się wyłączyć”.

Model wdrożenia: dual-stack jako domyślny wybór, a IPv6-only jako cel

W praktyce dual-stack to najrozsądniejszy start: IPv4 zostaje jako „siatka bezpieczeństwa”, a IPv6 można uruchamiać etapami. IPv6-only zaczyna mieć sens dopiero wtedy, gdy masz dojrzałą politykę DNS, firewall, monitoring i gotowe mechanizmy przejściowe dla zasobów IPv4 (np. NAT64/464XLAT) — ale to temat na później.

Jeśli ktoś naciska na „IPv6-only od jutra”, zapytaj: które aplikacje są w 100% gotowe? Zwykle sama ta rozmowa zawęża ambicję do rozsądnego pilota.

Krok 1 — inwentaryzacja i przygotowanie „pod IPv6”, zanim cokolwiek ogłosisz w LAN

Co sprawdzić u operatora i na WAN, zanim dotkniesz LAN

Zanim IPv6 trafi na VLAN-y użytkowników, upewnij się, że masz stabilną podstawę po stronie WAN. Wiele „awarii IPv6” to w rzeczywistości brak pełnego upstreamu, brak trasy domyślnej, błędna filtracja prefiksów albo niespójność w delegacji prefiksów.

• Jaki prefiks dostajesz (np. /48, /56) i czy jest stały.
• Czy operator robi delegację prefiksu (PD) do Twoich routerów brzegowych / oddziałów.
• Jak dostajesz routing: statycznie, BGP, RA (na łączu) — i co jest źródłem default route.
• Czy masz jasne zasady filtrów po stronie ISP (np. czy filtrują zbyt agresywnie ICMPv6).

Pytanie diagnostyczne: czy potrafisz wskazać, którędy idzie domyślna trasa IPv6 i gdzie jest egzekwowany firewall? Jeśli „nie wiadomo”, to znaczy, że pierwsza godzina po wdrożeniu może zamienić się w polowanie na czarną dziurę.

Kontrola infrastruktury L2/L3: funkcje, które ratują rollout

Na przełącznikach i routerach interesują Cię nie tyle „czy mają IPv6”, tylko czy mają mechanizmy kontroli pierwszego skoku i czy da się to sensownie monitorować.

• RA Guard (blokada nieautoryzowanych Router Advertisement na portach access).
• Mechanizmy ochrony ND (zależnie od platformy): ND inspection, limity, detekcja spoofingu, kontrola tabeli sąsiadów.
• Możliwość egzekwowania polityk IPv6 na SVI i na trunkach (ACL, polityki per VLAN).
• Na routerach/L3: wsparcie dla IGP w IPv6 (OSPFv3/IS-IS) lub sensowne statyki; CoPP/policery dla ICMPv6.

Jeśli brakuje RA Guard w dostępie, IPv6 da się wdrożyć, ale ryzyko rośnie: pojedynczy błędny host (albo niechciany routerek) może zacząć rozgłaszać RA i przejąć bramę domyślną w całym segmencie.

„Miejsca, gdzie się wywraca” — lista min przed startem

Trzy miny odpowiadają za większość problemów w pierwszym tygodniu dual-stack.

Mina 1: IPv6 zaczyna wpływać na ścieżki „sam z siebie”

Hosty mają link-local, czasem dostają też GUA/ULA i preferują IPv6 (Happy Eyeballs, preferencje systemu). Jeśli AAAA istnieje, klient spróbuje IPv6. Gdy IPv6 nie jest kompletne (routing/firewall/MTU), użytkownik widzi „czasem działa, czasem nie”.

Mina 2: ICMPv6 potraktowane jak „zbędne ICMP”

W IPv4 ludzie przyzwyczaili się, że można „uciąć ping” i żyć. W IPv6 ICMPv6 jest częścią działania protokołu: ND (sąsiedzi), RA, PMTUD. Blokada kluczowych typów to przepis na losowe timeouty i problemy z większymi pakietami.

Mina 3: DNS z AAAA przed siecią

Dodanie AAAA do publicznych nazw usług bez pewności, że firewall i routing są gotowe, to klasyczny błąd. U klientów IPv6 może stać się „pierwszym wyborem”, a wtedy każde niedociągnięcie wyjdzie natychmiast.

Mini-scenariusze: jak dobrać kolejność wdrożenia

Biuro/kampus z wieloma VLAN-ami

Najbezpieczniej: jeden VLAN pilotowy (np. IT), pełna kontrola RA na access, dopiero potem Wi‑Fi, goście, IoT. Krytyczne jest wykrywanie nieautoryzowanych RA i utrzymanie spójnego DNS.

DC z load balancerem

Zwykle zaczyna się od frontendów: VIP-y po IPv6, poprawne healthchecki po v6, dopiero potem backendy (albo zostają IPv4-only). Upewnij się, czy LB nie ukrywa source IP oraz jak rozwiązuje DNS (czy sam robi AAAA, czy korzysta z resolwera).

Zdalne lokalizacje z CPE od operatora

Tu ryzyko jest inne: CPE może rozgłaszać RA w sposób, którego nie kontrolujesz. Często sensowniejsze jest włączenie IPv6 dopiero za centralnym firewallem lub użycie PD do zarządzalnego routera w oddziale.

Krok 2 — plan adresacji IPv6, który nie zemści się za pół roku

Skąd adresy i jak je kroić: GUA, ULA i logika agregacji

Jeśli dostajesz prefiks od operatora, to zwykle będzie GUA (Global Unicast Address) — publicznie routowalne. Dla wewnętrznych potrzeb czasem rozważa się ULA (Unique Local Address), ale nie jako „zamiennik prywatnych z NAT”. ULA ma sens, gdy chcesz niezależność od ISP dla komunikacji wewnętrznej lub stabilność adresacji niezależnie od zmian GUA — tylko wtedy musisz jasno ustalić, co jest routowane gdzie i jak wygląda DNS.

Najważniejsza zasada projektowa, która „przestawia myślenie” z IPv4: /64 per VLAN/subnet. Nie oszczędzaj adresów. W zamian oszczędzaj… prefiksy w routingu przez agregację.

Pytanie diagnostyczne: czy prefiks w oddziale jest stały? Jeśli masz PD, które może się zmieniać, to wpływa na DNS, reverse i wszelkie allowlisty. Wtedy często potrzebujesz warstwy abstrakcji (nazwy DNS zamiast IP, automatyzacja aktualizacji) albo przemyślenia, które segmenty faktycznie muszą być dostępne z zewnątrz.

Przykładowa struktura: „ładnie” nie znaczy „dobrze”

W IPv6 łatwo wpaść w pułapkę „układania ładnych adresów”. Operacyjnie ważniejsze są: powtarzalny schemat, rezerwa i agregacja.

Przykład podejścia (koncepcyjnie):

• Jeden większy blok dla lokalizacji (site), np. /48 lub /56.
• Z niego wydzielasz /64 na każdy VLAN: użytkownicy, serwery, IoT, goście, management.
• Zostawiasz rezerwę na nowe VLAN-y i migracje (to ogranicza przebudowy routingu).

Jeśli używasz IGP/BGP, agregacja jest Twoim przyjacielem: mniej prefiksów w dystrybucji to mniej filtrów, mniej wyjątków i mniej ryzyka wycieku „testowego” prefiksu do produkcji.

Reguły operacyjne: co adresujesz statycznie, a co dynamicznie

IPv6 nie wymaga, żeby wszystko było statyczne. W praktyce statykę rezerwuje się dla rzeczy, które mają być przewidywalne i łatwe do wpisania w konfiguracje:

• adresy na interfejsach routerów/SVI (często „pierwszy” lub „ostatni” adres w /64, zależnie od konwencji),
• serwery infrastruktury: DNS, NTP, syslog, monitoring,
• load balancery, reverse proxy, krytyczne VIP-y.

Stacje robocze i urządzenia końcowe zwykle mogą iść dynamicznie (SLAAC/DHCPv6). Jeśli potrzebujesz identyfikowalności, rozważ logikę po stronie DHCPv6 lub 802.1X/NAC, zamiast próbować „wymusić” statyczne adresy na wszystkim.

Krok 3 — konfiguracja hostów: SLAAC, DHCPv6 czy miks (i jak nie zepsuć DNS)

Decyzja: kto ma kontrolować adres i parametry DNS?

Tu nie ma religii, są konsekwencje. Zadaj sobie pytanie: czy chcesz przede wszystkim prostoty, czy ewidencji i kontroli?

Najpierw odpowiedz sobie na jedno: czy musisz wiedzieć „kto ma jaki adres”, czy wystarczy, że hosty po prostu działają i mają poprawny DNS? SLAAC daje szybkość i mało ruchomych części, DHCPv6 daje ewidencję i wygodę zarządzania, a miks bywa najlepszy… ale tylko jeśli wiesz, co dokładnie mieszasz.

W praktyce najczęstszy kłopot nie dotyczy samego adresu, tylko tego, skąd host bierze serwery DNS. Przy SLAAC możesz reklamować DNS przez RDNSS w RA (jeśli klienci to wspierają), a przy DHCPv6 – podajesz DNS w opcjach DHCPv6. Pytanie diagnostyczne: czy Twoje stacje mają jeden, przewidywalny mechanizm dostarczania DNS, czy część bierze z RA, część z DHCPv6, a reszta jeszcze „zostaje” na IPv4? Ta niespójność wygląda potem jak losowe awarie aplikacji.

Jeśli środowisko jest mieszane (Windows, Linux, drukarki, IoT), to często wygrywa wariant „miks kontrolowany”: SLAAC do adresu (bo działa praktycznie wszędzie), a DHCPv6 tylko do DNS i opcji (bo chcesz wymusić resolwery firmowe). Tyle że wtedy musisz pilnować flag w RA (M/O) i zachowania klientów. Typowa mina: ktoś włącza DHCPv6 „bo tak”, ale zapomina, że część systemów i tak użyje SLAAC, a rejestracja w DNS staje się nieczytelna.

Dwa krótkie scenariusze z życia, które oszczędzają godzin debugowania: jeśli helpdesk zgłasza „strony działają, ale aplikacja nie”, sprawdź, czy klient nie próbuje IPv6 do FQDN z AAAA, a potem nie dostaje odpowiedzi DNS po IPv6 (bo resolwer jest tylko v4 lub firewall blokuje 53/udp v6). A jeśli „działa tylko na kablu, na Wi‑Fi nie”, podejrzyj, czy na jednym segmencie RA niesie RDNSS, a na drugim DNS jest wyłącznie z DHCPv6 – klienci potrafią zachować się inaczej i wyjdzie chaos.

Najczęstszy błąd, który psuje całą robotę, jest banalny: wrzucenie AAAA do DNS zanim ścieżka IPv6 jest domknięta end-to-end (routing, firewall, ICMPv6/PMTUD, DNS). Dual-stack nie wybacza półśrodków — IPv6 zaczyna być używany „po cichu”, a Ty dostajesz zgłoszenia, które brzmią jak awarie aplikacji, choć to tylko niedopięta sieć.

Ustawienia RA, które decydują o zachowaniu klientów

Zanim klikniesz „enable IPv6” na SVI, odpowiedz sobie na krótkie pytanie: czy chcesz, żeby hosty brały adres z SLAAC, z DHCPv6, czy jedno i drugie? To nie jest detal — to jest zachowanie całej podsieci.

• A-flag (Autonomous): gdy włączona, host może tworzyć adresy SLAAC z prefiksu z RA.
• M-flag (Managed): host ma użyć DHCPv6 do uzyskania adresu (stateful).
• O-flag (Other): host ma użyć DHCPv6 tylko po „inne opcje” (np. DNS), nawet jeśli adres bierze z SLAAC.
• Router lifetime: czy RA ogłasza bramę domyślną (jeśli przypadkiem ustawisz 0, IPv6 „jest”, ale nie ma default route).

Najprostszy wariant operacyjny w wielu firmach to: SLAAC do adresu + O-flag do DNS. Ale tu pojawia się pytanie kontrolne: czy Twoje klienty faktycznie robią DHCPv6 po opcje, jeśli dostaną O-flag? W świecie IoT i drukarek odpowiedź bywa „różnie”, więc planuj tak, żeby brak DHCPv6 nie wywracał podstawowej łączności.

DNS dla klientów: jeden mechanizm, jedna prawda

Jeśli chcesz ograniczyć „czasem działa”, dopnij temat DNS jako pierwszy. Podejmij decyzję: RDNSS w RA czy DNS z DHCPv6. Mieszanie da się przeżyć, ale dopiero gdy jest świadome i spójne.

Kryterium „jest dobrze”: na kliencie w każdym VLAN-ie jesteś w stanie odpowiedzieć na dwa pytania w 30 sekund:

• skąd host wziął serwery DNS (RA RDNSS / DHCPv6 / IPv4),
• czy resolwery są osiągalne po IPv6 (jeśli reklamujesz je jako IPv6).

Typowa pułapka: reklamujesz IPv6 adresy resolverów (bo „skoro IPv6, to IPv6”), ale firewall do segmentu infrastruktury przepuszcza DNS tylko po IPv4. W efekcie klient ma poprawny AAAA, ma default route, ale zapytania DNS po v6 wiszą — przeglądarka próbuje, czeka, dopiero potem przechodzi na v4 i użytkownik widzi „mulenie”.

Bezpieczne minimum: co powinno przejść przez ACL zanim zaczniesz testy

Jeśli politykę budujesz „default deny”, to IPv6 wymaga od razu zestawu wyjątków. Pytanie diagnostyczne: czy Twoje ACL-e w ogóle przepuszczają ICMPv6 niezbędne do działania?

Minimalny zestaw, który zwykle musi przejść w obrębie segmentu L2/L3 (między hostem a bramą, oraz w sąsiedztwie routerów):

• Neighbor Solicitation / Neighbor Advertisement (ND) — odpowiednik ARP, tylko bardziej rozbudowany.
• Router Solicitation / Router Advertisement — hosty pytają o RA, router odpowiada.
• Packet Too Big (PMTUD) — bez tego pojawią się czarne dziury dla większych pakietów, szczególnie przy tunelach/VPN.
• Time Exceeded i typowe błędy diagnostyczne — inaczej traceroute i część mechanizmów debugowania będzie „kłamać”.

To nie znaczy „przepuszczaj cały ICMPv6 wszędzie bez limitu”. To znaczy: przepuszczaj kluczowe typy, a resztę kontroluj (CoPP na routerze, policery, sensowne ACL-e per strefa).

Krok 4 — uruchomienie dual-stack bez czarnych dziur: routing, firewall, ICMPv6 i testy

Najpierw domknij ścieżkę: czy IPv6 ma trasę do internetu i z powrotem?

Dual-stack ma jedną bezlitosną cechę: klient spróbuje IPv6 nawet wtedy, gdy Ty „jeszcze nie skończyłeś”. Dlatego startuj od pytania: czy w tej sieci IPv6 ma komplet: default route, routing zwrotny i polityki na brzegu?

Procedura w praktyce wygląda prosto:

1. Na core/edge: upewnij się, że masz stabilną trasę domyślną IPv6 (do ISP lub do upstreamu) i że prefiksy LAN są anonsowane właściwie (lub statycznie znane).
2. Na firewallu brzegowym: zdefiniuj reguły IPv6 osobno (nie zakładaj, że „kopiują się” z IPv4). Sprawdź strefy i polityki stateful dla v6.
3. Routing zwrotny: zweryfikuj, że upstream widzi Twoje prefiksy i ma jak odesłać ruch (BGP, statyki u operatora, poprawny PD/aggregacja).

Kryterium „jest dobrze”: z hosta w VLAN pilotowym robisz traceroute -6 do znanego celu i widzisz sensowną ścieżkę, a na firewallu masz stan sesji dla IPv6 i licznik ruchu rośnie na regułach, które tego oczekujesz.

Firewall w IPv6: „kopiuj z IPv4” to za mało

Tu najczęściej dzieją się dwie rzeczy naraz: (1) ktoś przepuszcza za dużo, bo „nie ma NAT, więc niech leci”, albo (2) ktoś blokuje za dużo, bo „ICMP to ping”. Jaką filozofię wybierasz: domyślnie blokuj i odblokowuj świadomie, czy domyślnie przepuszczaj i obserwuj? W firmach praktycznie zawsze bezpieczniej startować od pierwszej opcji, ale z poprawnie dobranymi wyjątkami ICMPv6.

Sprawdzenia, które oszczędzają nerwy:

• Reguły per strefa: użytkownicy → internet, użytkownicy → serwery, goście → tylko internet, IoT → tylko do brokerów/API. IPv6 nie powinien omijać segmentacji.
• Publikacja usług: jeśli wystawiasz coś po IPv6, sprawdź, czy reguły inbound obejmują v6, logowanie działa, a WAF/LB rozumie adresy źródłowe IPv6.
• Logi: czy SOC/monitoring widzi IPv6, a narzędzia parsują adresy (to zaskakująco częsta „awaria po wdrożeniu”).

ICMPv6 i PMTUD: test, który wykrywa „losowe timeouty” zanim zadzwoni helpdesk

Jeśli masz tunel, PPPoE, VPN, albo po drodze urządzenia z mniejszym MTU, PMTUD zrobi Ci albo robotę, albo bałagan. Pytanie diagnostyczne: czy potrafisz potwierdzić, że „Packet Too Big” wraca do klienta?

Co sprawdzić praktycznie:

• Wykonaj test pobrania większego obiektu po IPv6 (np. większy plik w HTTPs) i obserwuj, czy nie ma zawieszek mimo „pingu działa”.
• Jeśli masz możliwość, sprawdź na firewallu/routerze liczniki i logi ICMPv6 typu Packet Too Big.
• Gdy coś „stoi”, a DNS jest OK: bardzo często winne jest właśnie filtrowanie ICMPv6 lub zła ścieżka zwrotna.

Klasyczny objaw: małe rzeczy (DNS, małe odpowiedzi HTTP) działają, większe sesje TLS lub RDP/SSH „zrywają się” albo wiszą. To prawie zawsze woła: sprawdź ICMPv6 i MTU po drodze, zanim zaczniesz grzebać w aplikacji.

Kontrola routingu: gdzie wycieka prefiks i kto ogłasza bramę?

W dual-stack zdarzają się dwa typowe „ciche” błędy: błędny anons prefiksu i nieautoryzowany RA. Pierwsze robi bałagan w trasach, drugie potrafi przejąć ruch w jednym VLAN-ie.

Szybki zestaw kontroli:

• Na routerach dystrybucji/core: czy widzisz tylko oczekiwane prefiksy w tablicy routingu IPv6? Czy agregacja działa tak, jak planowałeś?
• Na access: czy RA Guard działa na portach użytkowników i na Wi‑Fi uplinkach? Czy porty trunk są oznaczone jako zaufane tam, gdzie powinny?
• Na hostach: czy brama domyślna IPv6 jest tą, którą przewidujesz (a nie przypadkowym urządzeniem)?

Jeśli chcesz „złapać” problem zanim rozleje się po biurze, ustaw alerty na wykrycie nowych źródeł RA w VLAN-ach użytkowników. To jest jedna z tych rzeczy, które w IPv4 rzadko istniały w takim kształcie, a w IPv6 potrafią zjeść dzień.

Checklista uruchomienia: przed / w trakcie / po

Przed włączeniem IPv6 w pierwszym VLAN-ie

• Masz decyzję: SLAAC vs DHCPv6 vs miks oraz spójny plan dostarczania DNS (RA RDNSS albo DHCPv6).
• Firewall ma przygotowane reguły IPv6 i przepuszcza wymagane typy ICMPv6 (przynajmniej dla ND/RA/PMTUD).
• Masz kontrolę RA: RA Guard na access i zaufane porty ustawione świadomie.
• Routing zwrotny jest potwierdzony: upstream wie, gdzie odesłać Twoje prefiksy.

W trakcie (VLAN pilotowy)

• Na kliencie: widzisz adres IPv6 z oczekiwanego prefiksu, bramę domyślną i działający DNS.
• Testy: ping -6 do bramy, potem do resolvera, potem do celu z internetu; traceroute -6 ma sensowną ścieżkę.
• Na firewallu: widać sesje IPv6 i logi nie pokazują masowych dropów ICMPv6 typu Packet Too Big.

Po rozszerzeniu na kolejne segmenty

• Split-horizon DNS i rekordy AAAA są dodawane etapami, zgodnie z tym, gdzie ścieżka jest już domknięta.
• Monitoring łapie osobno: dostępność po v4 i po v6 (żeby „działa” nie oznaczało tylko IPv4).
• Polityki segmentacji są równoważne w IPv4 i IPv6 (żadnych „bocznych drzwi” przez v6).

Ostrzeżenie na koniec tej fazy: „AAAA wszystko naprawi” to mit

Najbardziej zdradliwy błąd w rolloutach dual-stack wygląda niewinnie: ktoś dodaje AAAA „żeby było nowocześnie”, zanim upewni się, że każdy element po drodze (routing, firewall, ICMPv6, DNS, monitoring) jest gotowy. Efekt nie przypomina awarii sieci — przypomina „dziwne” problemy aplikacji. Jeśli masz wybrać jedną rzecz, którą wdrażasz wolniej i ostrożniej niż resztę, to niech to będzie publikacja AAAA dla usług użytkowników.

Krok 5 — DNS i publikacja usług: AAAA dodawaj jak bezpiecznik, nie jak ozdobę

Pytanie, które oszczędza najwięcej zgłoszeń: czy Twoi użytkownicy mają korzystać z usług po IPv6, czy tylko „mieć IPv6” na interfejsie? To nie to samo. Dual-stack bez publikacji AAAA w DNS często działa „spokojnie”, a dual-stack z AAAA potrafi natychmiast obnażyć braki w routingu, firewallu albo MTU.

Procedura publikacji AAAA dla usług wewnętrznych i zewnętrznych

1. Wybierz usługę o małym ryzyku (np. prosty serwis HTTP, wewnętrzny portal, endpoint API bez krytycznych zależności).
   
   Kryterium: jeśli coś pójdzie źle, rollback to usunięcie AAAA i nie zatrzymujesz produkcji.
2. Zweryfikuj, że usługa faktycznie nasłuchuje po IPv6 (nie tylko system ma adres).
   
   Przykład: serwer ma tcp6 :::443 albo 0.0.0.0:443 i osobno [::]:443 – zależnie od stosu i aplikacji.
3. Sprawdź ścieżkę od klienta do usługi i z powrotem w IPv6 (routing, firewall, MTU).
   
   Kryterium: z VLAN-u pilotowego otwierasz usługę po IPv6 bez „zawieszki”, a na firewallu widzisz stan sesji v6.
4. Dopiero wtedy dodaj rekord AAAA (w odpowiedniej strefie: publicznej albo wewnętrznej).
   
   Jeśli masz split-horizon, upewnij się, że nie publikujesz AAAA „wszędzie”, gdy usługa działa po v6 tylko w części lokalizacji.
5. Dodaj obserwowalność: osobne checki monitoringu po v4 i po v6, oraz logowanie adresów źródłowych IPv6.
   
   Kryterium: gdy IPv6 padnie, monitoring nie zamelduje „zielono”, bo działa IPv4.

Reverse DNS i „czy to w ogóle ma znaczenie?”

Jeśli masz kontrolę nad strefą reverse (wewnętrzną albo od operatora), pytanie brzmi: czy coś w Twoim środowisku podejmuje decyzje na bazie PTR (poczta, systemy bezpieczeństwa, niektóre integracje)? Jeżeli tak, to brak reverse IPv6 będzie wychodził jako „dziwne” odrzucenia, a nie jako klasyczna awaria sieci.

• Dla usług wychodzących (np. SMTP, API do partnera): PTR po IPv6 bywa wymagany tak samo jak po IPv4.
• Dla środowisk wewnętrznych: PTR ułatwia analizę logów i korelację incydentów. Bez tego masz „adresy jak zupa”.

Pułapka: w IPv6 reverse deleguje się „na nibbles”, więc ręczne dłubanie w strefie bez automatyzacji szybko staje się niewykonalne. Jeśli nie masz narzędzia do generowania PTR-ów, ogranicz reverse do krytycznych serwisów, a nie „dla całej puli, bo wypada”.

Happy Eyeballs i fałszywy spokój

Jeśli użytkownik mówi „działa, tylko wolno”, to często nie jest aplikacja, tylko Happy Eyeballs: klient próbuje IPv6, coś po drodze timeoutuje (DNS po v6, firewall, PMTUD), po chwili przechodzi na IPv4. Masz dostęp do stacji testowej?

• Sprawdź czas rozwiązywania DNS i pierwszego połączenia TCP/TLS osobno dla v4 i v6 (w przeglądarce/devtools albo narzędziami CLI).
• Jeżeli IPv6 ma opóźniony fallback, szukaj: niedostępnego resolvera po v6, brakującego ICMPv6 Packet Too Big, albo asymetrii routingu.

Krok 6 — diagnostyka, którą da się powtarzać: szybkie testy i twarde kryteria „OK”

Najgorszy rollout to taki, gdzie testy są „na oko”. Potrzebujesz zestawu, który uruchomisz tak samo w każdym VLAN-ie i w każdej lokalizacji. Pytanie kontrolne: czy potrafisz w 5 minut powiedzieć, czy problem jest w DNS, RA/ND, routingu czy firewallu?

Testy na hoście: kolejność, która najszybciej zawęża problem

1. Adres i brama: czy host ma IPv6 z właściwego prefiksu i domyślną trasę?
   
   Kryterium: widzisz GUA/ULA zgodne z planem i default route wskazującą na oczekiwany router.
2. Warstwa lokalna: ping -6 do bramy, potem do sąsiada w tym samym VLAN-ie.
   
   Jeśli brama nie odpowiada, pierwsze podejrzenia: RA/ND, ACL na SVI, RA Guard, filtr ICMPv6.
3. DNS: odpytywanie resolvera po IPv6 (a nie tylko „czy domena się rozwiązuje”).
   
   Kryterium: zapytania idą do właściwego resolvera, a odpowiedź przychodzi bez timeoutów.
4. Ścieżka do internetu: traceroute -6 do znanego celu, a potem test ruchu aplikacyjnego (HTTPS).
   
   Jeżeli traceroute wygląda sensownie, a HTTPS wisi – to bardzo często MTU/PMTUD albo polityki na firewallu.

Testy na routerze/firewallu: co sprawdzić, gdy host „ma IPv6, ale nie działa”

• ND/ARP-equivalent: czy router widzi sąsiadów IPv6 na interfejsie (tabela neighborów), czy wpisy nie „flapują”?
• Trasa domyślna i preferencja: czy default route IPv6 jest aktywna i nie znika przy odświeżeniach?
• Liczniki dropów: czy nie rośnie liczba dropów ICMPv6 (szczególnie Packet Too Big), albo dropów z powodu polityki strefowej?
• Sesje: czy firewall tworzy stan dla ruchu IPv6 tak, jak dla IPv4 (i czy to na pewno ten sam „kierunek” polityk)?

Krótki scenariusz z praktyki wdrożeń: VLAN pilotowy działa, ale po rozszerzeniu na Wi‑Fi „internet muli”. Najczęściej winne jest to, że Wi‑Fi ma inne ACL-e niż LAN przewodowy (albo inny path przez firewall), a IPv6 został dopuszczony częściowo: RA przechodzi, DNS po v6 nie, ICMPv6 jest pocięty. Efekt to seria timeoutów i fallback na IPv4.

Lista kontrolna „IPv6 działa poprawnie” dla segmentu

• Host dostaje adres IPv6 zgodny z planem oraz stabilną bramę domyślną (brak „losowych” RA).
• DNS działa bez timeoutów, a klient nie próbuje resolverów, do których nie ma ścieżki (RDNSS/DHCPv6 spójne z polityką firewall).
• Ruch aplikacyjny (HTTPS) działa bez „dziwnych zawieszek” przy większych transferach (PMTUD/MTU OK).
• Firewall egzekwuje segmentację również dla IPv6 (te same intencje, niekoniecznie 1:1 te same reguły).
• Monitoring ma osobne testy IPv4 i IPv6, a logowanie/parsowanie adresów IPv6 działa w narzędziach bezpieczeństwa.

Ostrzeżenie operacyjne: „włączę IPv6 na interfejsie, nic się nie stanie”

W IPv6 „nic się nie stanie” rzadko bywa prawdą, bo wystarczy RA w VLAN-ie, żeby hosty zaczęły próbować nowej ścieżki. Jeśli urządzenie dostępu albo router przypadkiem zacznie emitować RA (albo dopuścisz cudze RA), to klienci mogą przełączyć się na IPv6 mimo braku dopiętego routingu i polityk.

Jeżeli masz wybrać jeden bezpiecznik, który wdrażasz zanim dotkniesz użytkowników, to niech to będzie: kontrola RA (RA Guard + zaufane porty) oraz spójny firewall dla DNS i ICMPv6. Bez tego dual-stack potrafi wyglądać jak losowa niestabilność, a nie jak przewidywalna zmiana.