Kantelpunt bereikt: de transitie naar IPv6 gaat nieuwe fase in

De adoptie van IPv6 is een kleine 10 jaar geleden goed op gang gekomen. Sindsdien zien we aan gebruikerszijde een gestage groei van grofweg 5 procentpunt per jaar. Op moment van schrijven (oktober 2023) komt ongeveer 45 procent van het verkeer bij Google over IPv6 binnen.

Wereldwijd IPv6-gebruik aan clientzijde. Bron: Google.

Overheidsdruk

Volgens RFC 9386 zijn de 2 belangrijkste drivers achter deze groei de schaarste aan IPv4-adressen en druk van nationale overheden.

Dat de landen om ons heen veel verder zijn met de adoptie van IPv6 dan wij [1, 2], is mede te danken aan verplichtingen vanuit de overheid.

In België werd de toepassing van CGNAT beperkt tot maximaal 16 gebruikers per publiek IPv4-adres om de opsporing van cybercriminelen niet onmogelijk te maken. Dat is 10 jaar geleden vastgelegd in een convenant tussen Belgische overheidsdiensten en accessproviders. De adoptie van IPv6 speelde daarbij een belangrijke rol; de inperking van CGNAT zet accessproviders immers economisch op achterstand. [1]

Interoperabiliteit, innovatie en competitie

In Frankrijk is de verplichte ondersteuning van IPv6 in de grote steden onderdeel van de 5G-licenties. Belangrijkste argumenten voor de stimulatie van IPv6 door de Franse overheid zijn interoperabiliteit, innovatie en competitie (het wegnemen van drempels voor nieuwkomers). [1]

In Duitsland wordt de adoptie van IPv6 vooral gestimuleerd door de federale overheid. Die heeft in haar 'Netzstrategie 2030 für die öffentliche Verwaltung' strategisch ingezet op IPv6 als fundament onder de digitalisering van overheidsdiensten. Op termijn moet hun overheidsnetwerk uitgroeien tot het basisnetwerk voor de gehele overheid. Die strategie en de daarvoor benodigde maatregelen zijn door de Duitse minister van Binnenlandse Zaken vastgelegd in het 'IPv6-Masterplan für die Bundesverwaltung'.

Wat verder weg zetten Amerikaanse [1, 2], Chinese [1] en Indiase overheden [1, 2] vergelijkbare strategieën in.

In landen als Brazilië, India, China [1] en andere Aziatische landen is IPv6-only sowieso de enige manier om tientallen of zelfs honderden miljoenen mobiele gebruikers op internet aan te kunnen sluiten.

Een toekomstbestendige netwerkarchitectuur

De auteurs van RFC 9386 hebben de belangrijkste hobbels en incentives op weg naar een IPv6-only toekomst in kaart gebracht. Het ultieme doel is een internet waarin directe IPv4-toegang (via dual-stack) en indirecte toegang (via een transitiemechanisme) helemaal niet meer gebruikt worden (al is die IPv6-only toekomst nog ver weg). De auteurs beschouwen de transitie richting IPv6-only voor accessproviders in de breedste zin des woords: het gaat niet alleen om IPv4-toegang over IPv6 bij de traditionele internetproviders en mobiele providers, maar ook om IPv4-toegang bij ondernemingen, academia en overheden.

Uitgangspunt bij dit alles is dat we inmiddels het stadium wel gepasseerd zijn waarin IPv6 ontsloten wordt over het IPv4-netwerk. Bij de nieuwbouw of opwaardering van een netwerk van enige substantie moet IPv6 het beginpunt zijn. Toegang tot IPv4 is dan een (essentiële) dienst daarbovenop. Gezien de gestage groei van IPv6 is dit nu al de enige toekomstbestendige netwerkarchitectuur. Bijkomend voordeel van deze strategie is dat het de keuze voor een transitiemechanisme sterk vereenvoudigd.

Dual-stack plus (CG)NAT

Uit een onderzoek in 2020 bleek dat dual-stack bij accessproviders het meest toegepaste transitiemechanisme is. Omdat de IPv4 en IPv6-netwerken volledig onafhankelijk van elkaar zijn, is deze opzet makkelijk te implementeren. Tegelijkertijd brengt de implementatie, het onderhoud, het beheer en de beveiliging van 2 parallelle netwerken wel extra kosten met zich mee. Omdat IPv6 inmiddels door alle systemen ondersteund wordt, is gelukkig geen aparte hardware voor IPv6 nodig. Besparingen zitten in de reductie van de NAT-capaciteit; IPv6-verkeer gaat immers zonder adresvertaling direct het netwerk op.

Tegelijkertijd biedt dual-stack geen oplossing voor een tekort aan IPv4-adressen. Gebruikers hebben nog steeds een IPv4-adres nodig voor toegang tot IPv4-only servers; ze gebruiken deze alleen minder (vandaar die besparing op de NAT-werklast). Ook de extra complexiteit van CGNAT blijft gewoon bestaan.

IPv4-as-a-Service

Vanaf een bepaald kantelpunt is het dus om zowel economische redenen als vanwege de complexiteit van alle IPv4-lapmiddelen verstandiger om te kiezen voor een IPv6-netwerk met daarop een aparte faciliteit voor toegang tot IPv4-only systemen. Vandaar de naam IPv4-as-a-Service (IPv4aaS). RFC 9386 noemt een percentage van 50-60 procent IPv6-verkeer als een redelijk omslagpunt waarbij de overstap naar een andersoortige (volgende) transitie-architectuur gerechtvaardigd is.

Voor het aanduiden van die transitie-architectuur gebruiken de auteurs deze 2 begrippen:

• IPv6-Only Overlay: het klassieke end-to-end IPv4-netwerk waarover het IPv6-verkeer getunneld wordt. Deze architectuur biedt geen goede oplossing (meer) omdat je je bestaande IPv4-netwerk hiervoor volledig in stand moet houden en onderhouden/opwaarderen. Deze opzet is zeker niet meer geschikt voor een groeiend netwerk.

• IPv6-Only Underlay: over het netwerk loopt alleen nog IPv6-verkeer en IPv4 gaat daar in tunnels overheen. Er zijn 2 belangrijke redenen om voor deze architectuur te kiezen:

  • deze opzet is toekomstbestendig, want je kunt je IPv4aaS-systemen afschalen naarmate je IPv4-verkeer afneemt

  • je hebt een goede overgang weg van dual-stack, want als de IPv4aaS-faciliteit eenmaal is opgezet kun je daarna het resterende IPv4-gedeelte van je netwerk (in de underlay) opruimen

IPv6-only

Let op dat deze aanpak typisch alleen geldt voor accessnetwerken. Op de backbone stap je gewoon over van IPv4-only naar IPv6-only. In datacenters wil je immers niet de complexiteit van dual-stack of andere transitiemechanismen. Dat zie je terug bij grote online dienstverleners als Microsoft, Facebook en LinkedIn (de zogenaamde hyperscalers), die allemaal al jaren geleden een IPv6-only strategie voor hun interne netwerken hebben ingezet. Waar mogelijk proberen zij dat ook te vertalen naar een IPv6-first propositie [Amazon].

Maar ook voor kleine en middelgrote hostingproviders is IPv6-only een interessante commerciële optie. De Zwitserse serviceprovider Ungleich profileert zich onder de vlag IPv6onlyHosting expliciet als IPv6-only dienstverlener. En serviceproviders Hetzner, PCextreme (voor de overname door Versio) en TransIP bieden allemaal IPv6-only Virtual Private Servers (VPS-en) aan.

Voor allemaal geldt dat er tot een paar euro per maand van de prijs af kan vanwege de uitsparing van een IPv4-adres. Wil je je IPv6-only server toch toegankelijk maken voor IPv4, dan kan dat via een (reverse) proxy (waarbij je je IPv4-adres via Server Name Indication (SNI) wel deelt met andere servers).

Keuze transitie-architectuur

Een van de lastigste onderdelen bij het opzetten van een IPv6-strategie was altijd de keuze voor een transitiemechanisme. Een en ander hangt af van wat je al hebt aan apparatuur, de grootte, complexiteit en architectuur van je netwerk, waar je staat in de transitie naar IPv6, en wie je bent (datacenter, access/mobile/hosting-provider, enterprise). Onderstaand overzicht laat een dozijn mechanismen zien, en dat zijn ze niet eens allemaal.

Klik op de afbeelding om deze te vergroten. De tekst gaat door onder de afbeelding.

https://images.ctfassets.net/yj8364fopk6s/2M9cLWIjy8a9zQWWwHDXtp/97ec2304e1e495f2c46d9ea79370599e/Transitiemechanismen_inclusief_legacy.svg

Maar de gestage groei van IPv6 heeft deze keuze inmiddels een stuk makkelijker gemaakt: met het naderen van het IPv4-IPv6-omslagpunt, kies je nu voor IPv6-only op je accessnetwerk, in combinatie met IPv4aaS voor de ontsluiting van IPv4-only hosts, wat we hierboven aanduidden als de 'IPv6-Only Underlay'-architectuur.

Keuze IPv4aaS-mechanisme

Wat dan rest is de keuze voor een IPv4aaS-mechanisme, en ook dat is inmiddels een stuk makkelijker geworden. Hieronder zie je een overzicht van de actuele transitiemechanismen voor access-netwerken (in het groene gedeelte). Volgens RFC 9313 (een andere dan RFC 9386 waarnaar we hierboven refereerden!) zijn dit de enige mechanismen die je nu nog zou moeten gebruiken. Hoewel de karakteristieken van en de verschillen tussen deze 5 algoritmen ook in de tweede sectie van deze RFC worden besproken, verwijzen we je voor een toegankelijker uitleg liever naar onze IPv6 FAQ.

Klik op de afbeelding om deze te vergroten. De tekst gaat door onder de afbeelding.

https://images.ctfassets.net/yj8364fopk6s/2x1OhGcA26Yvk1vhWnRgSQ/4d90151be50e1deb022901b4f3efb833/Transitiemechanismen.svg

464XLAT

Van de actuele mechanismen in dat groene blok valt nog eens de bovenste helft af (alle tunneling-gebaseerde technieken, waaronder ook DS-Lite) als je het advies van de Amerikaanse veiligheidsdienst NSA volgt. Die raadt om veiligheidsredenen de toepassing van elk protocol gebaseerd op tunneling en translatie af – uitgezonderd de inzet van NAT64/DNS64 en 464XLAT in IPv6-only-netwerken. Een belangrijk bezwaar tegen tunnels is dat deze de beveiliging van de netwerkperimeter – denk aan firewalls en screening routers – omzeilen. En als je ziet dat 464XLAT voortbouwt op de andere 2 technieken NAT64 en DNS64, dan blijft dus alleen 464XLAT over.

Voordeel van 464XLAT is dat deze technologie het belangrijkste IPv4-probleem (het tekort aan adressen) aanpakt. Bovendien beperkt (segmenteert) 464XLAT niet de port range per gebruiker zoals CGNAT dat wel doet met zijn gedeelde IPv4-adressen. Dat laatste maakt dat regelmatig grote groepen eindgebruikers in 1 keer geblokkeerd worden vanwege misbruik door een enkele gebruiker.

Een tweede transitie

Volgens RFC 9386 is 464XLAT het populairst in de mobiele wereld en is DS-Lite favoriet bij internetproviders. Beide mechanismen voorzien in een IPv4aaS-dienst (voor eindgebruikers zichtbaar als dual-stack/NAT) op een IPv6-Only Underlay (belangrijk voor providers die naar een IPv6-only netwerk toewerken).

Internetproviders hebben de afgelopen jaren vaak al een eerste transitie doorlopen van IPv4-only naar dual-stack (in combinatie met (CG)NAT) en draaien inmiddels IPv6-only in hun datacenters. Voor hen zijn de kosten van nieuwe IPv4-adressen, de kosten voor de plaatsing van nieuwe CPE's (modems) bij eindgebruikers en de kosten voor de CGNAT-capaciteit het meest relevant. Naarmate de prijs van IPv4-adressen toeneemt, kiezen deze providers voor CGNAT of IPv4aaS, waarbij CGNAT populair is omdat zij daarmee hun huidige dual-stack/NAT setup kunnen continueren [Delta].

Met name de hoge kosten van de CPE-apparatuur en hun lange afschrijvingstermijn maken dat internetproviders pas naar een nieuw transitiemechansime kunnen overstappen bij de installatie, upgrade of vervanging van gebruikersapparatuur. Bovendien levert CGNAT bij doorsnee eindgebruikers relatief weinig problemen op [1, 2, 3].

Voor mobiele providers is IPv4aaS (en dan wel 464XLAT) voor de hand liggender omdat zij vanwege de grote aantallen gebruikers eerder tegen de grenzen van hun IPv4-adresblokken en CGNAT-systemen aanlopen [casus Telstra]. Bovendien hebben zij geen legacy CPE-hardware bij de eindgebruikers staan die voor deze transitie moet worden vervangen [casus T-Mobile].

Ondernemingen

Enterprises kiezen ook voor IPv6-only op hun interne netwerken. IPv4-schaarste is in het algemeen echter niet hun eerste probleem, omdat zij geen grote aantallen systemen op IPv4 voor de buitenwereld beschikbaar hoeven maken zoals hostingproviders dat moeten doen. Voor hun verbindingen van en naar de buitenwereld werken enterprises veelal met proxy’s en NAT-gateways, wat betekent dat zij grootgebruikers zijn van private IPv4-adressen.

Enterprises gebruiken IPv6-only dan ook vooral om zichzelf in te dekken tegen IPv4-naamruimte-botsingen, wat een belangrijk obstakel voor netwerkintegratie kan zijn bij fusies en overnames. Daarnaast is voor sommige innovaties – denk aan Internet of Things (IoT) – IPv6 onontbeerlijk vanwege de grote aantallen sensors, actuators en andere apparaatjes die allemaal een eigen IP-adres nodig hebben.

Voor zowel enterprises als hostingproviders geldt bovendien dat zij IPv6 moeten ondersteunen om overheden te kunnen bedienen, die IPv6 steeds vaker opnemen in hun aanbestedingscriteria.

Industrie

Hoewel industriële bedrijven ook grote netwerken en grote groepen gebruikers kunnen hebben, zijn die volgens de auteurs van RFC 9386 behoudender in de adoptie van nieuwe technologie. Dat heeft onder andere te maken met machines en installaties die niet zelden een afschrijvingstermijn hebben die decennia beslaat.

Maar ook hier kunnen grote innovaties wel reden zijn voor een transitie naar IPv6. Denk maar aan Industrie 4.0, Industriële IoT (IIoT) en smart manufacturing. Van belang hierbij is te weten dat binnen de IETF regelmatig discussies worden gevoerd over de toekomst van IPv4 en of dit protocol nog wel doorontwikkeld moet worden nu IPv6 de norm is (afgezien van wat nodig is om van IPv4 naar IPv6 te komen en daarna IPv4 uit te faseren) [1, 2, 3].

Wat enterprises en industriële bedrijven gemeen hebben is dat ICT niet tot hun kernactiviteiten behoort. Bovendien hebben beide last van respectievelijk applicaties en apparaten die niet met IPv6 overweg kunnen. Het gaat dan met name om problemen met zogenaamde literals (hardgecodeerde IPv4-adressen). Iets soortgelijks geldt overigens ook voor sommige smart devices bij eindgebruikers (denk aan slimme televisies). 464XLAT gaat daar beter mee om dan NAT64/DNS64, maar daar heb je wel IPv6-ondersteuning voor nodig.

Voorlichting en training

Volgens de auteurs van RFC 9386 zijn het ook met name de enterprises en de industrie waar het aan IPv6-kennis en -ervaring ontbreekt (voor het mkb is dat ook het geval, maar zij zijn voor hun netwerkinfrastructuur volledig afhankelijk van hun internetaanbieder). Voorlichting en training moeten de adoptie van nieuwe netwerktechnologie in die omgevingen stimuleren. Belangrijkste argumenten voor de inzet van IPv6 in de behoudende industriële wereld zijn de auto-configuratie van IIoT-apparatuur en standaardisatie op het Internet Protocol (ter vervanging van proprietary applicatieprotocollen en communicatiesystemen).

IPv6 is niet fundamenteel anders of ingewikkelder dan IPv4 – zeker als je daarbij ook alle lapmiddelen voor IPv4 in ogenschouw neemt. Maar de transitie van IPv4 naar IPv6 is een apart onderwerp en vraagt aandacht op netwerk-strategisch niveau.

Wie meer wil weten over IPv6 en het belang daarvan, op zoek is naar toegankelijke informatie over deze moderne internetstandaard, of zelf met IPv6 aan de slag moet of wil, raden we aan om onze IPv6 FAQ door te nemen. Hoewel deze is vormgegeven als een lijst van veelgestelde vragen, is dit overzicht ook goed lineair door te lezen. Voor de .nl-registrars bieden we 2 IPv6 e-learningmodules aan via de SIDN Academy. Daarnaast brengen we regelmatig IPv6-gerelateerd nieuws op onze website.