IPv6 in 2025: overgang naar IPv6

De derde in een reeks blogs in 2025 waarin de stand van zaken van IPv6 in de sector wordt belicht, best practices waarmee rekening moet worden gehouden, en hoe Cisco klanten op hun reis helpt met zijn producten en diensten.

De IPv6-transitie is al bijna dertig jaar aan de gang en het IPv6-verkeer op internet bedraagt nu in alle opzichten meer dan 50% [1]. De meeste applicaties en netwerkstacks geven nu standaard de voorkeur aan IPv6, dankzij technologieën als Happy Eyeballs [2]eindgebruikers in een dual-stack-omgeving merken zelden dat IPv6 overgaat naar IPv4. Gelukkig komt dit mislukkingsscenario steeds minder vaak voor naarmate de robuustheid van het IPv6-internet verbetert en eindgebruikersnetwerken met grote veiligheid worden ingezet.

Twee grote fases

De reis naar IPv6 verloopt doorgaans in twee grote fasen: ten eerste de overgang van de wereld met alleen IPv4 naar een dual-stack-wereld, waarin we IPv6 mogelijk maken en beide protocollen tegelijkertijd uitvoeren; en vervolgens geleidelijk IPv4 buiten gebruik stellen. Traditionele dual-stack-implementaties worden vaak aangevuld met wat gewoonlijk de “Inside Out”-methode wordt genoemd, waarbij de kern van het netwerk eerst dual-stacked wordt. Zodra de routerings- en operationele ervaring in de netwerkinfrastructuur is gevestigd en al het andere op zijn plaats is (zie hieronder), zullen edge access-switches en AP’s eindelijk IPv6 mogelijk maken op hun gebruikersgerichte segmenten, waardoor eindgebruikers IPv6-connectiviteit krijgen. Daarna vindt de overgang van dual-stack naar IPv6-only min of meer in omgekeerde volgorde plaats.

Internet Edge en datacenters

Voordat we onze gebruikers kunnen dual-stacken, moeten we onze Internet Edge dual-stacken met de steun van ons beveiligingsteam (die er vanaf het begin bij betrokken zou moeten zijn!). Zodra Internet Edge IPv6 ondersteunt, verschuift de focus naar datacenters; Dankzij de dubbele stapeling van servers kunnen we beginnen met het testen van applicatietoegang via IPv6, terwijl de meerderheid van de gebruikers IPv4 blijft gebruiken (met specifieke testgebruikers in dual-stack). Het netwerkteam en de helpdesk moeten dual-stack zijn, zodat ze de transitie uit de eerste hand kunnen ervaren. (In een verwante notitie: uiteindelijk kunnen alle functies op het netwerkbeheervlak alleen overgaan naar IPv6 zolang het datavlak dual-stacked blijft.) U kunt vervolgens de DMZ overzetten en DNS-invoeren opgeven om een aanwezigheid op het internet te creëren met IPv6. Ten slotte kan IPv6 worden geïmplementeerd op gebruikersgerichte VLAN’s.

NetFlow en verkeersmonitoring

Idealiter zal 100% van onze interne applicaties IPv6 ondersteunen en de voorkeur hebben. De NetFlow-verzameling van intern verkeer helpt dit te monitoren, waardoor verouderde applicaties snel kunnen worden geïdentificeerd voor herstel (via upgrades, vervangingen of front-end met dual-stack-apparaten). Het doel is dat het enige IPv4-verkeer dat op het netwerk overblijft, aan het internet wordt gebonden. NetFlow zou moeten aantonen dat internetgebonden IPv6-verkeer gestaag toeneemt naarmate meer organisaties dit aanvullen Zij eigen IPv6-transitie.

DNS64 en NAT64

Zodra u de dual-stack-overgang heeft voltooid en eventuele door Happy Eyeballs verborgen gebreken proactief heeft geïdentificeerd en verholpen, is het tijd om stapsgewijs IPv4 uit uw netwerk te verwijderen. Gelukkig hebben de standaardisatie-instellingen NAT64 gedefinieerd [3] en DNS64 [4] alleen voor dit gebruiksscenario. Met deze complementaire technologieën kan een client die alleen IPv6 gebruikt, inhoud bereiken die alleen IPv4 bevat, waardoor IPv6 als één enkel protocol binnen het netwerk kan worden gebruikt [5]. Hoewel DNS64 en NAT64 kunnen worden geïmplementeerd voordat IPv4 volledig wordt verwijderd om bekendheid en ervaring op te doen, gebeurt de echte magie zodra IPv4 verdwenen is.

Voornamelijk IPv6 en CLAT

Nu dual-stack en NAT64 aanwezig zijn, is de volgende stap de overstap naar een overwegend IPv6-implementatie, een nieuw paradigma dat is gebouwd op een aantal technologieën [6][7] wat een eenvoudiger pad biedt naar een toekomst met alleen IPv6. In de meeste IPv6-gevallen biedt het clientbesturingssysteem zijn eigen IPv4-IPv6-vertaler, bekend als CLAT (client-side vertaler), voor toepassingen die nog steeds IPv4-afhankelijkheden hebben. Of de bestemming nu alleen IPv4 is of dat de applicatiecode ingebedde IPv4-literals gebruikt, dit verkeer wordt vertaald in IPv6-pakketten via het zakelijke IPv6-only netwerk en vervolgens via NAT64 teruggestuurd naar IPv4 aan de rand. Clients worden gesignaleerd om IPv6 te gebruiken, voornamelijk op dual-stack-toegangssegmenten via DHCP-optie 108, een DHCPv4-optie die de client vertelt dat het veilig is om een IPv4-adres op te geven en alleen IPv6 uit te voeren. Omdat IPv4 nog steeds wordt aangeboden, blijft een overwegend IPv6-netwerk klanten bedienen die geen lokale vertaling via CLAT ondersteunen. Nu klanten ze kunnen het te gebruiken protocol kiezen op basis van hun mogelijkheden, in plaats van zich erdoor te laten dwingen netto.

Alleen toekomstige IPv6

Terwijl we het netwerkverkeer met NetFlow blijven monitoren, mogen we verwachten dat het IPv6-verkeer gestaag zal blijven toenemen en uiteindelijk zal bevestigen dat er geen gebruik meer is van IPv4 op bepaalde gebruikers-VLAN’s. Het is tijd om IPv4 uit die netwerksegmenten te verwijderen. Naarmate meer IPv4 wordt uitgeschakeld, kan het ook worden verwijderd uit netwerkinfrastructuurapparatuur. Op een dag, in de hopelijk niet al te verre toekomst, zullen we 100% IPv6-gebruik zien op de Internet Edge en DMZ. Tot die tijd zullen NAT64, DNS64 en CLAT ons goed van dienst blijven.