IPv6

Het Internet Protocol (IP) vormt de basis onder al het verkeer op internet. Dit netwerkprotocol zorgt ervoor dat alle computers die op internet zijn aangesloten ook bereikbaar zijn. Het gaat dan niet alleen om desktops, laptops en mobiele apparatuur, maar bijvoorbeeld ook om server-systemen, webcams en IoT-apparatuur.

IP-versie 4 (IPv4) is de traditionele standaard van het Internet Protocol. Deze kent aan elk apparaat een eigen IP-adres toe bestaande uit 4 getallen (32 bits in totaal), bijvoorbeeld 192.0.2.26. Op die manier zijn alle computers die op internet zijn aangesloten (in principe) bereikbaar vanaf elke andere computer.

IPv4 is inmiddels bijna een halve eeuw oud en technisch achterhaald (legacy). Het grootste probleem is dat deze standaard maximaal 4 miljard (232) unieke IP-adressen ondersteunt. Dat lijkt heel veel, maar dat is het niet als je bedenkt dat we inmiddels met bijna 8 miljard mensen zijn en elk van onze apparaten – desktops, laptops, mobiele apparatuur, webcams, noem maar op – (in principe) een eigen IP-adres (en soms meer dan één) nodig heeft om zich met internet te verbinden.

Daar komt nog eens bij dat steeds meer kleine apparaatjes met internet worden verbonden en dus ook allemaal een IP-adres nodig hebben. Voorbeelden zijn de slimme energiemeter, het managementsysteem voor de zonnepanelen, de verwarmingsthermostaat en alle andere smart home devices. Hetzelfde geldt in nog veel grotere mate voor alle sensors en actuators van industriële toepassingen. IPv4 is absoluut ongeschikt voor het aansluiten van al die systemen en systeempjes, het zogenaamde Internet of Things (IoT).

Een gerelateerd probleem is dat zelfs de grootste private IPv4-adresreeks (10.0.0.0/8), bestaande uit ruim 16 miljoen adressen (gebruikt in combinatie met NAT44), niet groot genoeg is om alle interne systemen en gebruikers te kunnen bedienen bij IT-reuzen zoals Microsoft, Google en Amazon (de zogenaamde hyperscalers). Een aanzienlijk deel van die adresruimte gaat immers 'verloren' bij de opdeling in praktisch routeerbare subnetwerken.

Bovendien treden botsingen op in deze adresruimte bij fusies van organisaties en hun netwerken of bij het koppelen van verschillende Virtual Private Networks (VPN's).

Ondanks al zijn tekortkomingen transporteert IPv4 vandaag de dag nog steeds het grootste deel van al het internetverkeer.

De IPv4-adressen zijn allang op: Eind 2019 deelde RIPE NCC, de Regional Internet Registry (RIR) voor groot Europa en West-Azië, de allerlaatste IPv4-adressen uit. En niet alleen zijn de reguliere IPv4-adresblokken uitgeput, maar ook de wachtlijst voor teruggegeven adresblokken is helemaal leeg (wat je in de tweede grafiek hieronder terugziet in lineair oplopende wachttijden en afhakende LIR's).

Dat betekent praktisch gezien dat je nu alleen nog op de secundaire (dat wil zeggen: commerciële) markt terecht kunt als je nieuwe IPv4-adressen nodig hebt of je bestaande IPv4-netwerk wilt uitbreiden.

Figuur 1: De IPv4 adres-pool van RIPE NCC. Bron: RIPE NCC.

Figuur 2: De IPv4 wachtlijst van RIPE NCC. Bron: RIPE NCC.

De reden dat dienstaanbieders en eindgebruikers (in het Westen) maar beperkt last van dit adrestekort ondervinden, is dat accessproviders, telco's en netwerkbeheerders allerlei lapmiddelen inzetten om de levensduur van het uitgeputte IPv4-netwerk steeds weer te verlengen. De belangrijkste technische trucjes om bestaande IP-adressen te delen en te hergebruiken zijn NAT en CGNAT (aan gebruikerszijde) en SNI (aan hostingzijde). Maar wie nu een website of een andere dienst op internet aanbiedt, merkt weldegelijk iets van dit tekort: het wordt steeds moeilijker om een IP-adres van je hosting provider te krijgen en bijna altijd moet een bedrag per stuk per maand worden betaald.

Om de levensduur van het uitgeputte IPv4-netwerk steeds weer te verlengen, hebben we in de loop der tijd almaar nieuwe lapmiddelen ontwikkeld, waarvan NAT en CGNAT (aan gebruikerszijde) en SNI (aan hostingzijde) de belangrijkste zijn. De haast universele toepassing van deze technologieën hebben het karakter van het internet echter fundamenteel veranderd: het huidige internet is grotendeels een asymmetrisch netwerk geworden waarbij systemen van eindgebruikers niet meer direct vanaf het internet bereikbaar zijn.

Als gevolg daarvan zijn self-hosting en peer-to-peer-protocollen niet of niet goed meer mogelijk. Voorbeelden daarvan zijn:

• het draaien van je eigen webserver;

• het draaien van je eigen (gedistribueerde) 'social media'-servers (denk aan Matrix/Synapse, Mastodon, PeerTube en Pixelfed)

• elders of onderweg ook toegang tot je bestanden of muziekcollectie thuis;

• op al je apparaten toegang tot je zelfbeheerde adresboek, agenda, bookmarks, taken en aantekeningen (denk aan Nextcloud);

• real-time verbindingen zonder de vertraging van een relay tussen deelnemers in een multi-player game;

• probleemloze real-time verbindingen voor geluid en video tussen de deelnemers in een VoIP/WebRTC call;

• directe verbindingen tussen de nodes in een gedistribueerd/federated netwerk (denk aan Matrix en de Fediverse)

STUN, TURN en ICE zijn weer nieuwe lapmiddelen om een deel van de beperkingen van (CG)NAT te repareren, maar die werken niet altijd.

Het Internet Protocol heeft echter nooit onderscheid gemaakt tussen clients en servers, en kent van origine alleen maar (gelijkwaardige) hosts (het end-to-end-principe).

Het IPv4-gebaseerde internet met zijn lapmiddelen (NAT, CGNAT en SNI) biedt al lang geen volwaardige connectiviteit meer. Het is niet toekomstbestendig en het vormt een grote belemmering voor innovatie.

De schaarste aan IPv4-adressen maakt het onmogelijk voor bestaande providers om nieuwe grootschalige diensten in de markt te zetten. Denk aan nieuwe mobiele toepassingen en het Internet of Things (IoT). Daarnaast is het voor nieuwkomers heel lastig om überhaupt van start te gaan. Dat laatste ondervond Freedom Internet toen het een oplossing moest vinden om al zijn klanten een publiek IPv4-adres te kunnen aanbieden.

Praktisch gezien kun je nu alleen nog op de secundaire (dat wil zeggen: commerciële) markt terecht als je nieuwe IPv4-adressen nodig hebt of je bestaande IPv4-netwerk wilt uitbreiden. Onderstaande grafiek van het aantal transacties bij RIPE NCC (de Regional Internet Registry (RIR) voor groot Europa en West-Azië) laat zien hoe er de afgelopen jaren een levendige handel in IPv4-adresblokken is ontstaan.

Figuur 1: IPv4 transfers in de RIPE NCC regio. Bron: RIPE NCC.

Dat de nood hoog is blijkt ook uit de sterk gestegen marktprijzen voor IPv4-adresblokken. Afhankelijk van de blokgrootte betaal je volgens de broker IPv4 Market Group nu (juni 2024) tussen de 30 en 40 euro per adres. De concullega's van IPv4.Global rapporteren vergelijkbare prijzen.

Figuur 2: Ontwikkeling prijs per IP-adres. Bron: IPv4 Market Group.

Figuur 3: De prijzen van IPv4-adressen. Bron: IPv4.Global.

IPv4-adresreeksen zijn inmiddels zo duur dat ze een financiële asset zijn geworden. In oktober 2020 becijferde netwerkspecialist Andree Toonk dat de 100 miljoen IPv4-adressen die Amazon toen al in bezit had zo'n 2.5 miljard dollar waard waren (inmiddels is dat waarschijnlijk meer dan 3 miljard euro). Ondertussen gaat het opkopen van grote adresblokken gestaag door, en niet alleen door Amazon [1, 2] maar ook door andere grote cloudleveranciers als Microsoft, Google en Oracle – uiteindelijk ten koste van kleinere aanbieders en startups.

Het opkopen van IPv4-adressen is ook voor grote, kapitaalkrachtige organisaties echter geen houdbare oplossing: adressen zijn nog wel te koop, maar alleen in beperkte blokgrootten. Dat maakt de route-tabellen langer en het beheer ingewikkelder.

Figuur 4: Het percentage van de IPv4-adresruimte in bezit van Amazon. Bron: Scott Seligman.

In maart 2020 voorspelde Vincentas Grinius, de CEO van de Londense hosting provider Heficed, dat de prijzen voor IPv4-adressen de komende 5 jaar zouden verdubbelen. Daarmee zijn IPv4-adresblokken een verhandelbare commodity geworden, waaromheen nu allerlei leaseconstructies worden opgetuigd. De prijs die Grinius daarvoor noemde ligt op de 2,50 dollar per adres per jaar. Tegelijkertijd is het window om deze waarde uit te nutten beperkt: de adoptie van IPv6 betekent naar verwachting dat de waarde van IPv4-adressen binnen 10 jaar ook weer afneemt.

Het goede nieuws is dan ook dat de prijzen van IPv4-adressen de laatste jaren inderdaad eerst gestabiliseerd zijn en daarna zelfs flink gedaald. Dat is een belangrijke aanwijzing dat we Piek-IPv4 inmiddels gepasseerd zijn.

Zakelijk gezien betekent dit alles dat het gebruik van IPv4-adressen bijna altijd per adres per maand aan de klant moet worden doorberekend.

Bron: 'IPv4-adressen: het nieuwe goud!'

Het Internet Protocol heeft nooit onderscheid gemaakt tussen clients en servers, en kent van origine alleen maar (gelijkwaardige) hosts (het end-to-end-principe). De haast universele toepassing van (CG)NAT heeft het karakter van het internet echter fundamenteel veranderd: het huidige internet is grotendeels een asymmetrisch netwerk geworden waarbij systemen van eindgebruikers niet meer direct vanaf het internet bereikbaar zijn.

Als gevolg daarvan zijn self-hosting en peer-to-peer-protocollen niet of niet goed meer mogelijk. Voorbeelden daarvan zijn:

• het draaien van je eigen webserver;

• het draaien van je eigen (gedistribueerde) 'social media'-servers (denk aan Matrix/Synapse, Mastodon, PeerTube en Pixelfed)

• elders of onderweg ook toegang tot je bestanden of muziekcollectie thuis;

• op al je apparaten toegang tot je zelfbeheerde adresboek, agenda, bookmarks, taken en aantekeningen (denk aan Nextcloud);

• real-time verbindingen zonder de vertraging van een relay tussen deelnemers in een multi-player game;

• probleemloze real-time verbindingen voor geluid en video tussen de deelnemers in een VoIP/WebRTC call;

• directe verbindingen tussen de nodes in een gedistribueerd/federated netwerk (denk aan Matrix en de Fediverse)

IP-versie 6 (IPv6) is de directe opvolger van IPv4, de traditionele internetstandaard die ervoor moet zorgen dat alle computers die op internet zijn aangesloten ook bereikbaar zijn.

Inmiddels kunnen we IPv4 als legacy beschouwen en moeten we zo snel mogelijk over naar IPv6.

IPv6 is een hele nieuwe (niet-compatible) versie van het Internet Protocol, maar goed vergelijkbaar met IPv4. De 2 belangrijkste voordelen van IPv6 zijn:

• de enorm grote adresruimte;

• de auto-configuratie van IPv6-adressen op netwerkinterfaces door middel van het SLAAC-protocol.

2 andere verbeteringen van IPv6 zijn:

• de pakket-headers zijn groter dan die van IPv4, maar ze hebben een vaste lengte en bevatten geen checksum meer;

• pakketten worden onderweg niet meer gefragmenteerd: De verzendende host moet zorgen voor een niet te grote pakketgrootte. Een router die een pakket ontvangt dat te groot is om te verwerken stuurt een ICMP(v6)-bericht terug naar de afzender dat deze kleinere pakketten moet versturen. Hierdoor kunnen IPv6-pakketten in theorie sneller verwerkt worden (al zijn moderne routers inmiddels zo snel dat dit geen verschil meer maakt).

Ten slotte is iedereen met IPv6 volledig bereikbaar, wat betekent dat eindgebruikers ook weer self-hosting en peer-to-peer-protocollen kunnen toepassen. Merk op dat deze mogelijkheden tegen de commerciële belangen van hostingproviders in gaan; denk aan de verkoop van zakelijke hosting-abonnementen en dure vergaderdiensten.

Maar om al deze voordelen daadwerkelijk te benutten, moeten we IPv6 wel met zijn allen gaan gebruiken.

Jazeker: IPv6 bestaat al bijna 30 jaar; de eerste officiële specificatie voor IPv6 (RFC 1883) werd al in december 1995 gepubliceerd. IPv6 is bewezen, robuuste technologie. Inmiddels (juni 2024) komt bijna de helft van het bezoek bij Google over IPv6 binnen.

IPv6-adressen zijn in overvloed beschikbaar: de totale IPv6-adresruimte bevat 340 sextiljoen adressen, dat is het getal 34 gevolgd door 37 nullen.

De prefixes die de Regional Internet Registries (RIR's) aan hun leden toekennen zijn 32 bits lang, wat betekent dat een organisatie nog 24/16 bits tot haar beschikking heeft om deze adresruimte verder op te delen tot 56/48-bits routing prefixes voor eindgebruikers/vestigingen. Eindgebruikers/vestigingen hebben op hun beurt dan nog eens 8/16 bits tot hun beschikking voor verdere opdeling in subnetwerken.

IPv6 wordt ondersteund in alle gangbare netwerk-apparatuur: Interoperabiliteit is geen enkel probleem meer. Testen voor interoperabiliteit van professionele apparatuur is niet meer nodig; systemen voor bedrijfsmatige inzet doen gewoon IPv6.

IPv6 wordt ondersteund door alle gangbare netwerkmanagement-software en -tools. Dat geldt ook voor provider platforms als Plesk, cPanel en DirectAdmin.

IPv6 wordt ondersteund door alle gangbare operating systems, zowel open source als proprietary. Kennis, ervaring en ondersteuning voor IPv6 zijn breed beschikbaar bij leveranciers en dienstverleners. Dit alles maakt investeringen in en de overstap naar IPv6 risicoloos wat de technologie betreft.

IPv6 wordt al op grote schaal gebruikt: Inmiddels (juni 2024) komt bijna de helft van het bezoek bij Google over IPv6 binnen. Bovendien groeit dat aandeel met ongeveer 5 procentpunt per jaar. Voor eindgebruikers thuis die IPv6 hebben en vooral Google, YouTube, Netflix, Facebook, Instagram en Whatsapp gebruiken, loopt waarschijnlijk al meer dan de helft van hun verkeer over IPv6.

Figuur 1: Wereldwijd IPv6-gebruik aan clientzijde. Bron: Google.

Figuur 2: IPv6-verkeer op de Amsterdam Internet Exchange (AMSIX), Bron: AMSIX.

Deze voorbeeldcases beschrijven grote IPv6-implementaties bij accessproviders:

• Dual-stack, NAT en CGNAT vs. 464XLAT vs. DS-Lite;

• Telstra overgestapt naar IPv6-only voor mobiele gebruikers;

• Zuid-Koreaanse en Vietnamese telco's doen grote IPv6-only-implementaties;

• India en China implementeren IPv6 op grote schaal;

• China wil tegen 2030 volledig zijn overgestapt op IPv6.

Dat maakt de risico's van investeringen in IPv6 vanuit zakelijk perspectief goed beheersbaar. Of naar het technologie-adoptiemodel van Rogers: als je nu investeert in IPv6 behoor je al bijna tot de zogenaamde 'late majority'.

Uitgebreidere informatie over de adoptie van IPv6 vind je hier.

IPv5 is ooit bedacht als een standaard voor internettelefonie. Het protocol zou naast IPv4 gebruikt kunnen worden. IPv5 is echter niet verder gekomen dan het experimentele stadium en nooit daadwerkelijk gebruikt. IPv6 is dus de directe opvolger van IPv4.

Als aanbieder van een internetdienst – bijvoorbeeld een website, een maildomein of een onlinewinkel – is het van belang om goed bereikbaar te zijn.

Diensten die nog geen IPv6-adres hebben maken geen deel uit van het moderne internet en zijn daardoor minder goed bereikbaar. Bovendien kennen zoekmachines aan websites die geen moderne internetstandaarden ondersteunen een lagere score toe. Dat betekent dat de betreffende site minder bezoekers naar zich toe zal trekken.

Tenslotte loopt verkeer van bezoekers vanwege het adrestekort steeds vaker via gateways. Dat maakt het lastig om inzicht te krijgen in het aantal terugkerende bezoekers en de locatie van bezoekers. IPv6 ondersteunt zo veel adressen dat alles en iedereen een eigen IP-adres of -reeks toegewezen kan krijgen. Dat maakt het makkelijker om analyses van het gebruik van een site te maken.

IPv6 is de basis onder een hele nieuwe versie van internet. Heb je nog geen IPv6-adres, dan maak je geen deel uit van dit moderne internet. Dat betekent dat je niet alle aangesloten computers kunt bereiken. Nu in alle regio's van de wereld de IPv4-adressen daadwerkelijk op zijn, wordt dat een steeds groter probleem.

De Nederlandse overheid heeft een belangrijke voortrekkersrol bij de adoptie van IPv6. In 2010 is IPv6 door het Forum Standaardisatie, onderdeel van de ministeries van Economische Zaken en Binnenlandse Zaken, toegevoegd aan de zogenaamde 'pas toe of leg uit'-lijst (ptolu). Sindsdien zijn overheidsorganisaties dus min-of-meer verplicht om IPv6 in hun infrastructuur te implementeren.

Daarnaast is het Forum Standaardisatie initiatiefnemer van Internet.nl. Daar kun je je verbindingen en domeinen testen op de toepassing van een zestal moderne internetstandaarden: IPv6, DNSSEC, HTTPS, DMARC, STARTTLS en DANE. De uitkomsten resulteren in een score, waarmee je ook een kwantitatieve indicatie krijgt van je 'compliance'. Inmiddels zijn er op die manier al honderdduizenden tests uitgevoerd.

Volgens RFC 9386 zijn de schaarst aan IPv4-adressen en druk van nationale overheden de belangrijkste drijvers achter de adoptie van IPv6.

Informatie over de adoptie van IPv6 aan serverzijde in Nederland vind je hier.

IPv6 is in 2010 door het Forum Standaardisatie, onderdeel van de ministeries van Economische Zaken en Binnenlandse Zaken, toegevoegd aan de zogenaamde 'pas toe of leg uit'-lijst (ptolu). Dat betekent dat alle (semi-)overheidsorganisaties sindsdien min-of-meer verplicht zijn om IPv6 in hun infrastructuur te implementeren.

IPv6 is in 2010 door het Forum Standaardisatie, onderdeel van de ministeries van Economische Zaken en Binnenlandse Zaken, toegevoegd aan de zogenaamde 'pas toe of leg uit'-lijst (ptolu). Alle relevante standaarden die op de ptolu-lijst staan moeten worden opgenomen in aanbestedingen boven de 50.000 euro, tenzij er goede argumenten zijn om dat niet te doen. Daarmee is de invoering van IPv6 in de publieke sector veelal onderdeel van vernieuwingen in de IT-infrastructuur.

Bij SIDN maken we ons hard voor de verdere uitrol van IPv6 in Nederland – samen met het Forum Standaardisatie en het Platform Internetstandaarden (die de stimulerende rol van de in 2018 opgeheven IPv6 Task Force heeft overgenomen).

Zo startten we in de zomer van 2017 een incentiveregeling waarbij we registrars een korting geven op domeinen die bereikbaar zijn over IPv6. Daarmee proberen we omslagpunten in investeringen in IPv6 dichterbij te brengen.

Na het instellen van deze regeling vloog het aandeel .nl-domeinen waarvoor de mailserver of de webserver (met bijbehorende nameservers) via IPv6 bereikbaar was omhoog, maar die groei is een paar jaar later sterk afgevlakt [1, 2] en ook niet meer op gang gekomen na het verhogen van het incentivebedrag.

In 2019 kreeg IPv6 in Nederland een nieuwe boost. Wij organiseerden dat jaar onder de vlag van SIDN Academy (in samenwerking met de Vereniging van Registrars) 3 IPv6-workshops. Deze trainingen duurden een hele dag en waren voor registrars een goede gelegenheid om hun IPv6-kennis uit te breiden.

In datzelfde jaar ondertekenden Logius, VNG Realisatie, verschillende leveranciers, service-providers en andere overheidsorganisaties de 'Intentieverklaring IPv6'. Deze verklaring resulteerde uiteindelijk in de zogenaamde streefbeeldafspraak om eind 2021 alle overheidsservers op IPv6 beschikbaar te hebben.

In 2022 zijn we van start gegaan met de lancering van een hele nieuwe hoek op onze website waar we alle informatie en gereedschappen die je kunnen helpen bij de implementatie van moderne internetstandaarden op een overzichtelijke manier organiseren en presenteren. Naast alle informatie over DNSSEC, SPF/DKIM/DMARC en DANE vind je hier ook een uitgebreide pagina over IPv6, waar deze FAQ weer onderdeel van is.

Voor onze registrars hebben we 2 SIDN Academy e-learningmodules voor IPv6 beschikbaar.

World IPv6 Launch Day vond plaats op 6 juni 2012. Op die dag hebben honderden internetbedrijven – waaronder Akamai, Cisco, Facebook, Google, Microsoft, Wikimedia, Yahoo en YouTube – allemaal tegelijk (een deel van) hun diensten op het IPv6-netwerk beschikbaar gemaakt (door het publiceren van een AAAA DNS-record).

Deze dag was een initiatief van de Internet Society (ISOC), en werd voorafgegaan door de World IPv6 Day op 12 januari 2011. Die dag fungeerde als een (succesvolle) test voor de Launch Day anderhalf jaar later.

IPv6 lost het adrestekort van IPv4 ruimschoots op. IPv6-adressen zijn 128 bits lang, wat 2¹²⁸ = 3,4x10³⁸ (340 sextiljoen) unieke adressen oplevert. Dat is zó veel – het getal 34 gevolgd door 37 nullen – dat we deze hoeveelheid alleen in astronomische termen kunnen duiden.

Om een indruk te geven: Het routeerbare gedeelte van een IPv6-adres bestaat uit een eerste prefix van 32 bits (/32). Dat is het niveau waarop providers en grote organisaties (de LIR's) de adresblokken van hun Regional Internet Registry (RIR) uitgereikt krijgen. Van de resterende 96 bits gebruikt een accessprovider er meestal 16 om subnetwerken voor zijn klanten te definiëren.

Oorspronkelijk kregen eindgebruikers dan ieder een uniek /48-prefix toegekend, maar RFC 6177 suggereert nu een /56-prefix voor eindgebruikers, waarmee ze nog 256 eigen lokale subnetwerken kunnen definiëren. Binnen elk van die subnetwerken zijn dan nog 64 bits over, waarmee elk systeem (of nauwkeuriger: elke netwerkinterface) weer een uniek IP-adres krijgt.

Elke individuele internetgebruiker met een /56-prefix (adresblok) heeft dus 2⁷² = 4,7 triljard adressen beschikbaar voor eigen gebruik. Onze persoonlijke adresruimte is in dit geval dus 2⁴⁰ = 1,1 biljoen maal zo groot als de ruimte die we nu met IPv4 voor het hele internet ter beschikking hebben (2³²).

Behalve de enorm grote adresruimte biedt IPv6 de automatische configuratie van IPv6-adressen op netwerkinterfaces door middel van het SLAAC-protocol.

2 andere verbeteringen van IPv6 zijn:

• de pakket-headers zijn groter dan die van IPv4, maar ze hebben een vaste lengte en bevatten geen checksum meer;

• pakketten worden onderweg niet meer gefragmenteerd: De verzendende host moet zorgen voor een niet te grote pakketgrootte. Een router die een pakket ontvangt dat te groot is om te verwerken stuurt een ICMP(v6)-bericht terug naar de afzender dat deze kleinere pakketten moet versturen. Hierdoor kunnen IPv6-pakketten in theorie sneller verwerkt worden (al zijn moderne routers inmiddels zo snel dat dit geen verschil meer maakt).

Ten slotte is iedereen met IPv6 volledig bereikbaar, wat betekent dat eindgebruikers ook weer self-hosting en peer-to-peer-protocollen kunnen toepassen. Merk op dat deze mogelijkheden tegen de commerciële belangen van hostingproviders in gaan; denk aan de verkoop van zakelijke hostingabonnementen en dure vergaderdiensten.

Maar om al deze voordelen daadwerkelijk te benutten, moeten we IPv6 wel met zijn allen gaan gebruiken.

IPv6 heeft op zichzelf geen nadelen. Het lost belangrijke problemen van het uitgeputte IPv4-netwerk op en is tegelijkertijd goed vergelijkbaar met IPv4.

Op dit moment zitten we echter in de overgangsfase van IPv4 naar IPv6, waarin zowel de IPv4-lapmiddelen als de IPv4-IPv6-transitiemechanismen ons leven bemoeilijken. Zijn we eenmaal door deze periode heen – en dat kunnen we alleen door zo snel mogelijk IPv6 te implementeren en te gebruiken – dan is IPv6 vergelijkbaar met de recht-toe-recht-aan IPv4-netwerken van weleer.

Aanbieders van internetdiensten zullen waarschijnlijk niets merken als zij IPv6 implementeren op hun systemen; IPv6 biedt in principe immers precies dezelfde netwerkdienst als IPv4.

Wel kan het zijn dat de betere bereikbaarheid via IPv6 resulteert in een hogere score bij zoekmachines, waardoor de betreffende site meer bezoekers naar zich toe zal trekken.

IPv6 biedt in principe precies dezelfde netwerkdienst als IPv4. Toch merken internetgebruikers die IPv6 aanzetten waarschijnlijk dat een aantal verbindingsproblemen veel minder vaak zal optreden.

Het Internet Protocol heeft nooit onderscheid gemaakt tussen clients en servers, en kent van origine alleen maar (gelijkwaardige) hosts (het end-to-end-principe). De haast universele toepassing van (CG)NAT heeft het karakter van het internet echter fundamenteel veranderd: het huidige internet is grotendeels een asymmetrisch netwerk geworden waarbij systemen van eindgebruikers niet meer direct vanaf het internet bereikbaar zijn. Als gevolg daarvan zijn self-hosting en peer-to-peer-protocollen niet of niet goed meer mogelijk.

IPv6, waarbij ieder systeem weer een publiek adres krijgt (of kan krijgen), herstelt het end-to-end-principe van het Internet Protocol.

IPv6 is inmiddels bijna 30 jaar oud, maar nog steeds niet breed ingevoerd. Ondanks al zijn tekortkomingen transporteert IPv4 vandaag de dag nog steeds het grootste deel van al het internetverkeer. Dat heeft enerzijds te maken met de technische trucjes (dynamische toekenning, NAT, CGNAT, SNI) die providers en netwerkbeheerders inzetten om bestaande IP-adressen te delen en te hergebruiken, anderzijds met het feit dat IPv6 niet compatibel is met IPv4.

Wel zijn we inmiddels een belangrijk omslagpunt voorbij: waar je voorheen je IPv4-netwerk uitbreidde met IPv6, zonder direct toegevoegde waarde, zien we steeds meer cases waarbij IPv6 als uitgangspunt wordt genomen, met daarbij een transitiemechanisme voor IPv4-only-connectiviteit (IPv4-as-a-Service).

Op dit moment (juni 2024) komt bijna de helft van het bezoek bij Google over IPv6 binnen. Bovendien groeit dat aandeel met ongeveer 5 procentpunt per jaar. Voor eindgebruikers thuis die IPv6 hebben en vooral Google, YouTube, Netflix, Facebook, Instagram en Whatsapp gebruiken, loopt waarschijnlijk al meer dan de helft van hun verkeer over IPv6.

Figuur 1: Wereldwijd IPv6-gebruik aan clientzijde. Bron: Google.

IPv6 zal IPv4 uiteindelijk volledig moeten vervangen. In de tussentijd kunnen IPv4 en IPv6 gewoon naast elkaar op hetzelfde onderliggende netwerk gebruikt worden. Vrijwel alle apparatuur en software ondersteunt inmiddels zowel IPv4 als IPv6. Bovendien is er een hele batterij aan transitiemechanismen beschikbaar om de overgang van IPv4 naar IPv6 zo goed mogelijk te laten verlopen.

Nederland had al een ernstige achterstand op de rest van de wereld en de ons omringende landen. Op dit moment (juni 2024) komt grofweg een derde van de Nederlandse bezoekers bij Google over IPv6 binnen. De verdere adoptie is inmiddels echter nagenoeg tot stilstand gekomen. Omdat de opmars van IPv6 elders gewoon doorgaat, raken we steeds verder achterop.

Figuur 1: Nederlands IPv6-gebruik aan clientzijde. Bron: Google.

Figuur 2: Nederlands IPv6-gebruik aan clientzijde (internationaal). Bron: APNIC Labs.

Figuur 3: Nederlands IPv6-gebruik aan clientzijde (West-Europa). Bron: APNIC Labs.

Figuur 4: Nederlands IPv6-gebruik aan clientzijde (over de tijd). Bron: APNIC Labs.

In onze grote IPv6-inventarisatie (eind 2018 door SIDN gepubliceerd), en deze update daarop, kun je in detail lezen wat de Nederlandse positie is, waarom onze achterstand schade oplevert voor de economie en de internetgebruiker, en waarom we zo snel mogelijk over moeten naar IPv6.

Ondertussen blijkt onze positie bovendien niet beter maar slechter te worden: 2 jaar geleden zijn belangrijke statistieken voor de Nederlandse adoptie van IPv6 onbruikbaar geraakt. Daarmee zijn we het zicht op de IPv6-adoptie in Nederland kwijtgeraakt. Dat het nu veel moeilijker is dan voorheen om de Nederlandse IPv6-adoptie op een betrouwbare manier te kwantificeren, maakt het lastig om beleid ter stimulering van verdere adoptie te ontwikkelen, laat staan om de toepassing van IPv6 wettelijk verplicht te stellen. Bovendien vragen stimulering en beleid ook om goede instrumenten om de effecten van die inspanningen te meten.

Zijn we Piek-IPv4 inderdaad inmiddels gepasseerd, dan zou Nederland wel eens op grote achterstand uit de IPv4-IPv6-transitie kunnen komen.

In Nederland lopen we sterk achter met de adoptie van IPv6 vergeleken met andere landen. Probleem is dat de meeste providers en bedrijven op dit moment nog geen IPv6 aanbieden voor hun klanten en gebruikers. Het goede nieuws is dat de 2 grootste Nederlandse accessproviders, KPN en Ziggo (onderdeel van VodafoneZiggo), de afgelopen jaren (eindelijk) grote stappen hebben gemaakt.

Figuur 1: IPv6-gebruik op het KPN-netwerk. Bron: APNIC Labs.

Figuur 2: IPv6-gebruik op het Vodafone-Libertel-netwerk. Bron: APNIC Labs.

Kleinere providers en netwerkbeheerders lijken echter stil te staan. Uitzonderingen daarop zijn Freedom Internet, SURF, de Universiteit Twente, XS4ALL (wordt inmiddels geïncorporeerd in KPN) en Zeelandnet (onderdeel van Delta). Deze partijen staan erom bekend voorop te lopen waar het de invoering van nieuwe technologie betreft en zijn al langer met IPv6 bezig; voor hen is de inzet van de laatste technologie ook expliciet onderdeel van hun waardepropositie.

Al met al lopen we in Nederland sterk achter met de adoptie van IPv6 vergeleken met andere landen. Omdat wij traditioneel voorloper zijn op gebied van internet, hebben Nederlandse access- en serviceproviders wel meer IPv4-adressen tot hun beschikking dan de rest van de wereld. Dat is ook een mede-verklaring voor onze achterstandspositie (naar de Wet van de remmende voorsprong).

In onze grote IPv6-inventarisatie (eind 2018 door SIDN gepubliceerd), en deze update daarop, kun je in detail lezen wat de Nederlandse positie is, waarom onze achterstand schade oplevert voor de economie en de internetgebruiker, en waarom we zo snel mogelijk over moeten naar IPv6.

Ondertussen blijkt onze positie bovendien niet beter maar slechter te worden: 2 jaar geleden zijn belangrijke statistieken voor de Nederlandse adoptie van IPv6 onbruikbaar geraakt. Daarmee zijn we het zicht op de IPv6-adoptie in Nederland kwijtgeraakt. Dat het nu veel moeilijker is dan voorheen om de Nederlandse IPv6-adoptie op een betrouwbare manier te kwantificeren, maakt het lastig om beleid ter stimulering van verdere adoptie te ontwikkelen, laat staan om de toepassing van IPv6 wettelijk verplicht te stellen. Bovendien vragen stimulering en beleid ook om goede instrumenten om de effecten van die inspanningen te meten.

Zijn we Piek-IPv4 inderdaad inmiddels gepasseerd, dan zou Nederland wel eens op grote achterstand uit de IPv4-IPv6-transitie kunnen komen.

Statistieken over de adoptie van IPv6 aan serverzijde zijn maar sporadisch beschikbaar. Uit de grote IPv6-inventarisatie die we eind 2018 publiceerden, bleek wel dat domeinnaamhouders/registrars geen beleid hadden ingesteld voor IPv6 en dat de adoptie van IPv6 moeizaam verliep. Bovendien zagen zij grote verschillen in adoptie tussen verschillende sectoren.

Uitzondering hierop is de Nederlandse overheid, die het gebruik van IPv6 verplicht heeft gesteld. Volgens de laatste rapportage zit de adoptie van IPv6 bij de overheid nu op 80 procent voor webservers en 46 procent voor mail-gateways. Maar dat is bij lange na niet de 100 procent score die de overheid zich per eind 2021 als ambitie had gesteld (in de zogenaamde Streefbeeldafspraken).

Figuur 1: De bereikbaarheid van websites en mailservers bij de Nederlandse overheid. Bron: Forum Standaardisatie.

Wij voeren maandelijks metingen uit op alle .nl-domeinen als onderdeel van de incentiveregelingen die we voor de .nl-registrars instelden. De uitkomsten daarvan gebruiken we om kortingen te geven op domeinen die onder andere IPv6 toepassen.

Deze metingen bevestigen de stagnatie: na het instellen van de IPv6-incentive in de zomer van 2017 vloog het aandeel .nl-domeinen waarvoor de mailserver of de webserver (met bijbehorende nameservers) via IPv6 bereikbaar was omhoog, maar die groei is een paar jaar later sterk afgevlakt [1, 2] en ook niet meer op gang gekomen na het verhogen van het incentivebedrag.

Merk op dat het aantal .nl-domeinen waarvoor de mailserver en de webserver (met bijbehorende nameservers) via IPv6 bereikbaar zijn maar half zo hoog is (1,4 miljoen in plaats van 2,7 miljoen).

Figuur 2: Het percentage .nl-domeinnamen waarvan de webserver of de mailserver (met bijbehorende nameservers) via IPv6 bereikbaar zijn. Bron: SIDN.

Figuur 3: Het aantal .nl-domeinnamen waarvan de webserver of de mailserver (met bijbehorende nameservers) via IPv6 bereikbaar zijn. Bron: SIDN.

Figuur 4: Het aantal .nl-domeinnamen waarvan de name-, mail- en webservers via IPv6 bereikbaar zijn (uitgesplitst). Bron: SIDN.

Al met al lopen we in Nederland sterk achter met de adoptie van IPv6 vergeleken met andere landen. Omdat wij traditioneel voorloper zijn op gebied van internet, hebben Nederlandse access- en serviceproviders wel meer IPv4-adressen tot hun beschikking dan de rest van de wereld. Dat is ook een mede-verklaring voor onze achterstandspositie (naar de Wet van de remmende voorsprong).

In werelddelen waar internet veel later op gang kwam is het tekort aan IPv4-adressen veel groter en acuter dan hier; daar kunnen IPv4-adressen vaak alleen nog ingezet worden voor gedeelde hosting en CGNAT-gateways. Maar bedenk dat al onze IPv4-adressen ons niet meer helpen op het moment dat de eerste IPv6-only-clients elders onze IPv4-only-servers niet meer kunnen bereiken. Of andersom: dat onze IPv4-only-clients de eerste IPv6-only-servers elders niet meer kunnen bereiken.

In onze grote IPv6-inventarisatie (eind 2018 door SIDN gepubliceerd), en deze update daarop, kun je in detail lezen wat de Nederlandse positie is, waarom onze achterstand schade oplevert voor de economie en de internetgebruiker, en waarom we zo snel mogelijk over moeten naar IPv6.

Ondertussen blijkt onze positie bovendien niet beter maar slechter te worden: 2 jaar geleden zijn belangrijke statistieken voor de Nederlandse adoptie van IPv6 onbruikbaar geraakt. Daarmee zijn we het zicht op de IPv6-adoptie in Nederland kwijtgeraakt. Dat het nu veel moeilijker is dan voorheen om de Nederlandse IPv6-adoptie op een betrouwbare manier te kwantificeren, maakt het lastig om beleid ter stimulering van verdere adoptie te ontwikkelen, laat staan om de toepassing van IPv6 wettelijk verplicht te stellen. Bovendien vragen stimulering en beleid ook om goede instrumenten om de effecten van die inspanningen te meten.

Zijn we Piek-IPv4 inderdaad inmiddels gepasseerd, dan zou Nederland wel eens op grote achterstand uit de IPv4-IPv6-transitie kunnen komen.

Het aantal Nederlandse netwerken (Autonomous Systems) dat IPv6-routes adverteert via het Border Gateway Protocol (BGP), maakte een sterke groei door in de periode 2008-2014, maar in de jaren daarna is er helemaal niets meer gebeurd.

Figuur 1: Het aantal Nederlandse Autonomous Systems dat IPv6-routes adverteert. Bron: RIPE NCC.

Het aandeel van de resolvers dat de nameservers voor het .nl-domein over IPv6 bevraagt zat jaren vast op zo'n 20–25 procent en heeft alleen een jaar of drie geleden een klein sprongetje gemaakt richting de 30 procent.

Figuur 2: Het aandeel van de resolvers dat de nameservers voor het .nl-domein over IPv6 bevraagt. Bron: SIDN Labs.

In onze grote IPv6-inventarisatie (eind 2018 door SIDN gepubliceerd), en deze update daarop, kun je in detail lezen wat de Nederlandse positie is, waarom onze achterstand schade oplevert voor de economie en de internetgebruiker, en waarom we zo snel mogelijk over moeten naar IPv6.

Ondertussen blijkt onze positie bovendien niet beter maar slechter te worden: 2 jaar geleden zijn belangrijke statistieken voor de Nederlandse adoptie van IPv6 onbruikbaar geraakt. Daarmee zijn we het zicht op de IPv6-adoptie in Nederland kwijtgeraakt. Dat het nu veel moeilijker is dan voorheen om de Nederlandse IPv6-adoptie op een betrouwbare manier te kwantificeren, maakt het lastig om beleid ter stimulering van verdere adoptie te ontwikkelen, laat staan om de toepassing van IPv6 wettelijk verplicht te stellen. Bovendien vragen stimulering en beleid ook om goede instrumenten om de effecten van die inspanningen te meten.

Zijn we Piek-IPv4 inderdaad inmiddels gepasseerd, dan zou Nederland wel eens op grote achterstand uit de IPv4-IPv6-transitie kunnen komen.

Onze achterstandspositie in de adoptie van IPv6 levert ons economische schade op. Het maakt Nederland onaantrekkelijk voor nieuwe grootschalige mobiele toepassingen en initiatieven op gebied van het Internet of Things (IoT), en het tast ons innovatie-imago en vestigingsklimaat aan.

Eindgebruikers achter (CG)NAT kunnen geen self-hosted-applicaties draaien en ervaren verbindingsproblemen met peer-to-peer-toepassingen. Tenslotte maakt de schaarste aan IPv4-adressen het niet alleen moeilijk voor bestaande providers om nieuwe grootschalige diensten in de markt te zetten, maar ook voor nieuwkomers heel lastig om überhaupt van start te gaan.

Deze achterstandspositie verhoudt zich niet met onze zakelijke, technische en economische ambities op gebied van modern internet, zoals die zowel door de sector als onze overheid regelmatig worden uitgesproken.

In onze grote IPv6-inventarisatie (eind 2018 door SIDN gepubliceerd), en deze update daarop, kun je in detail lezen wat de Nederlandse positie is, waarom onze achterstand schade oplevert voor de economie en de internetgebruiker, en waarom we zo snel mogelijk over moeten naar IPv6.

Ondertussen blijkt onze positie bovendien niet beter maar slechter te worden: 2 jaar geleden zijn belangrijke statistieken voor de Nederlandse adoptie van IPv6 onbruikbaar geraakt. Daarmee zijn we het zicht op de IPv6-adoptie in Nederland kwijtgeraakt. Dat het nu veel moeilijker is dan voorheen om de Nederlandse IPv6-adoptie op een betrouwbare manier te kwantificeren, maakt het lastig om beleid ter stimulering van verdere adoptie te ontwikkelen, laat staan om de toepassing van IPv6 wettelijk verplicht te stellen. Bovendien vragen stimulering en beleid ook om goede instrumenten om de effecten van die inspanningen te meten.

Zijn we Piek-IPv4 inderdaad inmiddels gepasseerd, dan zou Nederland wel eens op grote achterstand uit de IPv4-IPv6-transitie kunnen komen.

Bronnen:

• We zijn het zicht op de IPv6-adoptie in Nederland kwijtgeraakt, januari 2024

• Verdere adoptie IPv6 in Nederland nagenoeg tot stilstand gekomen, september 2021

• Nederlandse positie IPv6 verder achteruit, januari 2019

• SIDN IPv6-inventarisatie, oktober 2018

Naarmate de adoptie van IPv6 doorgroeit, komt er een punt waarop de behoefte aan IPv4-adressen weer afneemt en ook de prijzen weer zullen dalen. Dat kantelpunt noemen we Piek-IPv4.

De verwachting is dat na het passeren van Piek-IPv4 de waarde van IPv4-adressen alleen maar verder zal afnemen. Grote houders zullen hun ongebruikte en vrijkomende IPv4-adressen dan op korte termijn naar de markt willen brengen, wat de prijzen nog sneller zal doen dalen.

We lijken Piek-IP4 inmiddels inderdaad gepasseerd te zijn: Na jaren van stijging zijn de prijzen van verhandelde adresblokken in de periode 2021-2022 eerst gestabiliseerd en in 2023 zelfs flink gedaald. Zoals je in onderstaande grafiek kunt zien, heeft die daling zich ook in 2024 doorgezet.

Figure 1: De prijzen van IPv4-adressen. [bron: IPv4.Global]

Er zijn verschillende mogelijke verklaringen voor het dalen van de prijzen: Zo hebben de grote cloudaanbieders de afgelopen jaren enorme hoeveelheden IPv4-adressen opgekocht. Dat om de online diensten van hun klanten van een IPv4-ingang te kunnen blijven voorzien. Inmiddels is die gekte alweer even voorbij, wat het inzakken van de prijzen zou kunnen verklaren.

Hoewel de prijzen van de grootste verhandelde blokken (/16 en groter) inderdaad een daling laten zien, dalen de prijzen van de kleinere adresblokjes nog veel harder. Dat laatste sluit ook uit dat de oorzaak van de overall-daling ligt in de verschuiving naar transacties van steeds kleinere adresblokken. De prijzen voor IPv4-adressen laten dus een structurele daling zien over de hele breedte van blokgrootten.

Figuur 2: De prijzen van IPv4-adressen (adresblokken /16 en groter). [bron: IPv4.Global]

Figuur 3: De prijzen van IPv4-adressen (adresblokken /17 en kleiner). [bron: IPv4.Global]

Naast de dalende prijzen zijn er nog legio andere aanwijzingen dat het IPv4-netwerk over zijn hoogtepunt heen is: Het aantal IPv4-routes neemt niet langer toe. De efficiëntie van het IPv4-gebruik stijgt niet maar daalt. En voor een deel van de accessproviders is verdere uitbreiding van hun infrastructuur middels NAT niet langer kosteneffectief.

Bronnen:

• Groei uit IPv4-netwerk; komende jaren krimp verwacht

• Zijn we piek-IPv4 gepasseerd?

• Kantelpunt bereikt: de transitie naar IPv6 gaat nieuwe fase in

Met het passeren van Piek-IPv4 is IPv4 niet langer het standaard Internet Protocol, maar moet dit als legacy gekwalificeerd worden. Bij de nieuwbouw en opwaardering van computernetwerken moet IPv6 nu leidend zijn en wordt de ontsluiting van IPv4-only systemen verzorgd door een dienst boven op die IPv6-basis (IPv4-as-a-Service).

Met deze kanteling is ook een andere groep IPv4-IPv6-transitiemechanismen uitgangspunt geworden. Op weg naar een IPv6-mainly wereld moeten oude mechanismen als dual-stack met NAT en CGNAT nu plaatsmaken voor nieuwere mechanismen gebaseerd op NAT64, DNS64 en 464XLAT.

Maar let op dat deze aanpak typisch alleen geldt voor access-netwerken. Op de backbone stap je gewoon over van IPv4-only naar IPv6-only. In datacenters wil je immers niet de complexiteit van allerlei transitiemechanismen en andere lapmiddelen. Dat zie je ook 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].

Bronnen:

• Groei uit IPv4-netwerk; komende jaren krimp verwacht

• Zijn we piek-IPv4 gepasseerd?

• Kantelpunt bereikt: de transitie naar IPv6 gaat nieuwe fase in

Het zou heel goed kunnen dat we Piek-IPv4 al in 2023 hebben bereikt en dat 2026 misschien zelfs al de eerste krimp van het IPv4-netwerk zal laten zien. Zo blijkt uit een analyse van Geoff Huston, Chief Scientist bij APNIC. Haalt hij wat uitschieters uit zijn statistieken, dan zet die krimp een paar jaar later alsnog in. De trend voor de komende jaren is hoe dan ook naar een negatieve groei. Naar verwachting zal de markt voor IPv4-adressen dan heel snel ineenstorten. [1, 2]

Figuur 1: Een kwadratische polynoom levert de beste modellering van de IPv4-routetabel op; deze voorspelt voor de komende jaren een omslag naar krimp. [bron: Geoff Huston]

De zorgwekkende eindconclusie van Huston is dat het huidige IPv4-netwerk zijn werk nog steeds doet, maar dat dit wel ten koste is gegaan van de innovatie, openheid en diversificatie van internet. De massale toepassing van NAT maakt dat inmiddels alleen nog client-server-verbindingen over TCP en UDP, geïnitieerd vanuit de client, mogelijk zijn. Applicaties die niet met deze architectuur matchen – denk aan multi-user-games en real-time peer-to-peer-toepassingen (internet/videotelefonie) – werken niet (goed) meer. Hoewel de meeste eindgebruikers dit niet als een belemmering ervaren, kan het zelf hosten van servers alleen nog in het uitzonderlijke geval dat een accessprovider zijn klanten een echt (statisch) IPv4-adres geeft [Freedom Internet].

Gevolg hiervan is een sterke marktconcentratie rondom een klein aantal hele grote partijen – voor zowel de infrastructuur als de content – die belang hebben bij risico-aversie, behoudendheid en controledrang. Bovendien lopen we het risico dat het huidige internet desintegreert, waarbij afzonderlijke fragmenten ('service cones' met een eigen private adresruimte) ontstaan rondom CDN points-of-presence (PoP's). Daarnaast is het slechts een kwestie van tijd voordat de eerste IPv6-only diensten (waarschijnlijk in Azië of Zuid-Amerika) beschikbaar komen. Die zijn dan onbereikbaar voor IPv4-only clients.

Al met al zijn innovatie en ondernemerschap op de huidige internetinfrastructuur stilgevallen. Huston verwacht dat dit pas weer op gang komt nadat we door de IPv4-IPv6-transitie heen zijn. Belangrijkste conclusie is dan ook dat we zo snel mogelijk moeten overstappen naar IPv6.

Bronnen:

• Groei uit IPv4-netwerk; komende jaren krimp verwacht

• Zijn we piek-IPv4 gepasseerd?

• Kantelpunt bereikt: de transitie naar IPv6 gaat nieuwe fase in

Op dit moment verkeert Nederland niet in de positie om de voordelen van een IPv6-gebaseerd internet uit te nutten. Sterker nog: we weten onze bestaande voorsprong op gebied van (IPv4-gebaseerde) internetdiensten en -infrastructuur niet te vertalen naar een koploperspositie op het IPv6-netwerk.

Omdat wij traditioneel voorloper zijn op gebied van internet, hebben Nederlandse access- en serviceproviders wel meer IPv4-adressen tot hun beschikking dan de rest van de wereld. Dat is ook een mede-verklaring voor onze achterstandspositie (naar de Wet van de remmende voorsprong).

Onze achterstandspositie in de adoptie van IPv6 levert ons echter economische schade op. Het maakt Nederland onaantrekkelijk voor nieuwe initiatieven op gebied van het Internet of Things (IoT) en het tast ons innovatie-imago en vestigingsklimaat aan.

Bovendien blijkt onze positie wat dat betreft niet beter maar slechter te worden: Twee jaar geleden zijn belangrijke statistieken voor de Nederlandse adoptie van IPv6 onbruikbaar geraakt. Daarmee zijn we het zicht op de IPv6-adoptie in Nederland kwijtgeraakt. Dat het nu veel moeilijker is dan voorheen om de Nederlandse IPv6-adoptie op een betrouwbare manier te kwantificeren, maakt het lastig om beleid ter stimulering van verdere adoptie te ontwikkelen, laat staan om de toepassing van IPv6 wettelijk verplicht te stellen. Bovendien vragen stimulering en beleid ook om goede instrumenten om de effecten van die inspanningen te meten.

Zijn we Piek-IPv4 inderdaad inmiddels gepasseerd, dan zou Nederland wel eens op grote achterstand uit de IPv4-IPv6-transitie kunnen komen.

Bronnen:

• Groei uit IPv4-netwerk; komende jaren krimp verwacht

• Zijn we piek-IPv4 gepasseerd?

• Kantelpunt bereikt: de transitie naar IPv6 gaat nieuwe fase in

Hoewel de implementatie van IPv6 een investering is waarvan het zakelijke rendement niet direct evident is, zijn er weldegelijk belangrijke voordelen en kansen waarvoor een valide business case gemaakt kan worden. Waar IPv4 met zijn lapmiddelen inmiddels uitgeput is, biedt IPv6 mogelijkheden voor hele nieuwe internettoepassingen vanwege zijn enorm grote adresruimte (wat betekent dat er geen rem op de groei zit) en de mogelijkheid eindgebruikers direct te bereiken (symmetrisch internet).

Sterker nog: IPv4 is een doodlopende straat, dus investeringen in internetafhankelijke innovaties zou je alleen op IPv6 moeten doen. De afgelopen jaren hebben we de eerste IPv6-only-gebaseerde businessmodellen en diensten al zien opkomen, wat betekent dat ook niets doen een risico inhoudt. IPv6 is het Internet Protocol voor de nabije toekomst, waarmee investeringen in IPv6-only sowieso toekomstbestendig zijn.

Specifiek voor providers en netwerkbeheerders biedt IPv6 de mogelijkheid om zich met 'moderne internetstandaarden' in de markt te profileren. Voordeel voor klanten en eindgebruikers is dat ze volledig bereikbaar zijn, waarmee self-hosting en peer-to-peer-toepassingen weer mogelijk worden.

Daarnaast zijn IPv4-adressen inmiddels zo duur dat investeren in IPv6 juist een besparing kan opleveren. Deze case beschrijft hoe de Australische telecomprovider Telstra zijn mobiele gebruikers heeft overgezet naar IPv6-only vanwege de hoge kosten van nieuwe IPv4-adresblokken.

Een andere kostenbesparing zit in de dure abuse-afhandeling. Waar gekraakte IPv4-servers direct gaan portscannen op internet en handmatig ingrijpen vereisen, is de IPv6-adresruimte is zo groot dat rangescannen heel inefficient is: "IPv6-only-servers zijn vooral stil" [PCextreme].

Ten slotte krijgen registrars die IPv6 ondersteunen via de incentiveregeling een korting op hun domeinnamen. Daarmee proberen we omslagpunten in investeringen in IPv6 dichterbij te brengen.

Jazeker: deze cases beschrijven nieuwe IPv6-only-proposities bij hosting- en serviceproviders:

• Amazon: virtuele IPv6-only-netwerken en Virtual Private Servers;

• TransIP: IPv6-only Virtual Private Servers;

• Ungleich: IPv6-only-hosting op basis van virtuele machines, jump hosts en proxy’s;

• PCextreme: IPv6-only-infrastructuur, IPv6-only-virtual servers.

Integendeel: IPv6 is een goed doordacht, toekomstbestendig en hoognodig protocol dat inmiddels sterke opgang vindt.

Jazeker: inmiddels (juni 2024) komt bijna de helft van het bezoek bij Google over IPv6 binnen. Bovendien groeit dat aandeel met ongeveer 5 procentpunt per jaar.

Jazeker: IPv6 is nodig en dringend ook.

Hoewel we dit de laatste jaren niet meer horen werd IPv6 wel eens 'een oplossing voor een niet-bestaand probleem' genoemd, met argumenten als: "we horen al zo lang dat de IPv4-adressen op zijn" en "(CG)NAT is een goede oplossing waarmee we nog lange tijd vooruit kunnen".

De brede adoptie van IPv6 heeft inderdaad veel langer op zich laten wachten dan we ooit hadden gedacht. Dat komt vooral omdat we in de loop der tijd almaar nieuwe lapmiddelen hebben ontwikkeld om de levensduur van het uitgeputte IPv4-netwerk steeds weer te verlengen. Al die lapmiddelen zorgen echter voor technische problemen, extra complexiteit met bijbehorende beheerslast en extra kosten.

Kortom: IPv6 is hoognodig en het is goed dat de brede adoptie eindelijk op gang is gekomen. Specifiek voor Nederland is het wel belangrijk onze achterstandspositie op de rest van de wereld en de ons omringende landen in te lopen.

Het IPv6-protocol zelf is zeker niet fundamenteel ingewikkelder dan het IPv4-protocol. Integendeel: de auto-configuratie van IPv6 maakt het leven van beheerders juist makkelijker. Wel is het IPv6-protocol een stuk uitgebreider dan IPv4.

Wat de huidige IP-netwerken complex maakt zijn alle ingewikkelde lapmiddelen die we in de loop der tijd hebben ontwikkeld om de levensduur van het uitgeputte IPv4-netwerk steeds weer te verlengen. Hetzelfde geldt voor de transitiemechanismen om de overgangsperiode van IPv4 naar IPv6 te overbruggen.

Zijn we eenmaal in die IPv6-only (of IPv6-mainly)-wereld aanbeland, dan hebben we daarmee een toekomstbestendige infrastructuur die juist veel minder complex is dan het huidige IPv4-netwerk met al zijn lapmiddelen en beperkingen en IPv4-IPv6-transitiemechanismen.

Integendeel: de auto-configuratie van IPv6 maakt het leven van beheerders juist makkelijker. Naarmate we de huidige IPv4-netwerken met alle lapmiddelen en IPv4-IPv6-transitiemechanismen kunnen uitfaseren, wordt het beheer van de nieuwe IP(v6)-netwerken juist veel minder arbeidsintensief.

Integendeel: IPv6 is bewezen, robuuste technologie, die inmiddels (juni 2024) door bijna de helft van de bezoekers van Google gebruikt wordt. Dat maakt investeringen in en de overstap naar IPv6 risicoloos wat de technologie betreft.

Jazeker: IPv6 wordt ondersteund door alle gangbare netwerkapparatuur, operating systems, netwerkmanagement-software en -tools. Interoperabiliteit is geen enkel probleem meer. En kennis, ervaring en ondersteuning voor IPv6 zijn breed beschikbaar bij leveranciers en dienstverleners.

Jazeker: dat systemen achter een (CG)NAT-gateway niet direct vanaf internet bereikbaar zijn levert grote problemen op: self-hosting is niet meer mogelijk en peer-to-peer-protocollen werken niet goed meer.

Hoewel dit niet per se het geval is, is dit weldegelijk een punt van aandacht/zorg. Het SLAAC-protocol voor de auto-configuratie van IPv6-adressen gebruikt het min-of-meer unieke MAC-adres van de betreffende netwerkinterface om de interface-identifier (de laatste 64 bits) van een unicast-adres te genereren. Omdat deze identifier steeds op dezelfde manier gegenereerd wordt, onafhankelijk van de network-prefix, kunnen deze adressen gebruikt worden om het online-gedrag van gebruikers en de locatie van mobiele devices te volgen.

De Privacy Extensions voor SLAAC gaan dit tegen door bijvoorbeeld dagelijks een tijdelijk (random) adres te genereren.

Opsporingsdiensten (alsook accessproviders) hebben al meerdere malen aangegeven dat met name CGNATproblemen oplevert bij de opsporing van online criminelen. Achter het IPv4-adres van een CGNAT-gateway zit nu immers een grote groep gebruikers, waarvan de identiteit alleen achterhaald kan worden door de adres/poort-toekenningen in de verschillende NAT-lagen over de tijd precies met elkaar te koppelen.

Achter elk IPv6-adres zit maximaal één eindgebruiker. Opsporingsdiensten hebben daarom een sterke voorkeur voor de snelle invoering van IPv6 uitgesproken.

Eindgebruikers die hun privacy willen beschermen zullen daarvoor een VPN-dienst of andere Privacy-Enhancing Technology (PET) moeten gebruiken.

We bespreken de privacy-aspecten van IPv6 uitgebreider in dit artikel.

IPv6 is geen bedreiging voor de veiligheid, maar vraagt weldegelijk extra aandacht. NAT(44) wordt (ten onrechte) vaak gezien als een firewall omdat systemen achter de gateway van buiten (het internet) niet benaderd kunnen worden (zonder expliciete port forwarding). Maar NAT is geen firewall; het is niet meer dan een (welhaast universeel ingezet) IPv4-lapmiddel dat als bijwerking heeft dat het de systemen achter de gateway onbereikbaar maakt.

Alle generieke IPv6-adressen worden in principe gerouteerd (behalve de Link-Local en ULA-adressen). Dit in tegenstelling tot de veelgebruikte private IPv4-adresreeksen achter een NAT-gateway. Dat betekent weer meer aandacht voor firewalls, screening routers, demilitarized zones (DMZ's) en proxy’s.

Ander punt is dat de IPv6-adresruimte zo groot is dat het blokkeren van individuele adressen (blacklisting/whitelisting) bij misbruik niet meer mogelijk is (alleen op basis van prefixes). Dat betekent dat filteren straks meer op de reputatie van een domeinnaam plaatsvindt.

Iets vergelijkbaars geldt overigens voor IPv4 in combinatie met CGNAT: het blokkeren van een enkel IPv4-adres kan leiden tot het ten onrechte uitsluiten van een grote groep gebruikers. En voor meerdere diensten ondergebracht op een enkel IPv4-adres (bijvoorbeeld met behulp van SNI): bij een aanval op een gedeelde host is niet direct duidelijk op welke specifieke dienst deze aanval gericht is.

De operationele beveiligingsaspecten van IPv6 bespreken we in dit artikel.

Dual-stack vraagt inderdaad extra tijd en geld vanwege de uitrol en het onderhoud van een tweede IP(v6)-netwerk parallel aan het bestaande IP(v4)-netwerk. Omdat IPv6 wordt ondersteund in alle gangbare netwerkapparatuur, operating systems, netwerkmanagement-software en -tools, gaat het vooral om configuratie en beheer.

Accessproviders die hun klanten een publiek IPv4-adres aanbieden moeten indien nodig IPv4-adresblokken bijkopen (of leasen). Zij zullen een businessmodel hanteren waarbij deze investeringen/kosten zich terugverdienen.

We zitten deze jaren echter in de overgang van IPv4 naar IPv6, wat betekent dat je een keer een IPv4-IPv6-transitiemechanisme zult moeten implementeren. Daarbij is het cruciaal je te realiseren dat we inmiddels een belangrijk omslagpunt voorbij zijn: waar je voorheen je IPv4-netwerk uitbreidde met IPv6, zonder directe toegevoegde waarde, zien we steeds meer cases waarbij IPv6 als uitgangspunt wordt genomen, met daarbij een transitiemechanisme voor IPv4-only-connectiviteit (IPv4-as-a-Service). Dit artikel beschrijft een aantal actuele transitiemechanismen en afwegingen voor verschillende situaties: dual-stack, NAT en CGNAT vs. 464XLAT vs. DS-Lite. Maar ook de hier genoemde cases bevatten informatie die je kan helpen bij het opstellen van een strategie, de ontwikkeling van een roadmap en het selecteren van een transitiemechanisme.

Inmiddels is de keuze voor een transitiemechanisme voor het accessnetwerk helemaal makkelijk geworden: De NSA 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.

Bovendien lijkt het erop dat we Piek-IP4 inmiddels gepasseerd te zijn. Daarmee is ook een andere groep transitiemechanismen uitgangspunt geworden. Op weg naar een IPv6-mainly wereld moeten oude mechanismen als dual-stack met NAT en CGNAT nu plaatsmaken voor nieuwere mechanismen gebaseerd op NAT64, DNS64 en 464XLAT.

IPv6 zelf verandert niets aan het IPv4-adrestekort, maar met IPv6 zijn zo veel IP-adressen beschikbaar – het getal 34 gevolgd door 37 nullen – dat alles en iedereen zo veel adressen kan krijgen als men nodig heeft. Daarvoor moet dan wel iedereen overstappen naar deze 'nieuwe' internetstandaard.

Veel van de IPv4-IPv6-transitiemechanismen maken het wel mogelijk om in gebruik zijnde IPv4-adressen terug te winnen, zodat die weer ingezet kunnen worden om diensten en gebruikers aan het huidige IPv4-netwerk te koppelen. Op die manier verlengen deze mechanismen (net als de lapmiddelen voor IPv4) dus wel de levensduur van het IPv4-netwerk.

Er zijn over de jaren heen allerlei onderzoeken uitgevoerd naar snelheidsverschillen tussen IPv4 en IPv6. Deze vergelijkingen leveren alles bij elkaar echter geen duidelijke winnaar op: soms is IPv6 wat sneller, en soms IPv4.

In theorie zou IPv6 iets sneller moeten zijn: het protocol bevat een paar optimalisaties in de pakket-header waardoor IPv6-pakketten sneller gerouteerd zouden moeten kunnen worden. Daarnaast hebben (native) IPv6-verbindingen onderweg geen adresvertaling nodig zoals bij IPv4-verbindingen via (CG)NAT het geval is.

Daar staat tegenover dat IPv6 pas later in de netwerkapparatuur ingebouwd is. Dat zou kunnen betekenen dat IPv6 in sommige gevallen nog niet perfect door de ASIC-hardware wordt ondersteund en dat optimalisaties in een router nog in het voordeel van IPv4 uitvallen.

Kortom: voor de snelheid maakt het gebruik van IPv6 in het algemeen geen verschil. Veruit het belangrijkste argument voor de inzet van IPv6 is de enorm grote adresruimte.

IPv6-adressen zijn 128 bits (= 16 bytes) lang. Ze worden genoteerd in een reeks van 8 hexadecimale getallen (elk bestaande uit maximaal 4 hexadecimale cijfers), gescheiden door een dubbele punt: ':'.

IPv6-adressen zijn 128 bits (= 16 bytes) lang. Ze worden genoteerd in een reeks van 8 hexadecimale getallen (elk bestaande uit maximaal 4 hexadecimale cijfers), waarbij alleen kleine letters gebruikt mogen worden. Die 8 hexadecimale getallen worden van elkaar gescheiden door een dubbele punt: ':'. Daarbij mogen een of meerdere opeenvolgende getallen met de waarde 0 worden weggelaten, zodat het betreffende adres op die plek alleen een dubbele dubbele punt heeft staan: '::'. Maar let op dat die dubbele dubbele punt maar één keer in het betreffende adres mag voorkomen. Bijvoorbeeld:

2001:db8::abad:cafe:8765:4321

De precieze notatie voor IPv6-adressen is vastgelegd in RFC 5952.

Merk op dat de notatie van een letterlijk IPv6-adres (een zogenaamde literal) een probleem oplevert als je deze in een URL verwerkt in combinatie met een poortnummer (waarvoor traditioneel ook een dubbele punt als scheidingsteken wordt toegepast). Daarom worden IPv6-literals in URL's en andere identifiers altijd tussen vierkante haakjes geplaatst:

https://[2001:db8::abad:cafe:8765:4321]:443/

IPv6 kent 3 typen adressen:

• unicast: adressen voor één-op-één verbindingen tussen hosts (algemener: netwerkinterfaces). De scope van deze adressen (zoals gedefinieerd in RFC 4007) kan globaal of lokaal zijn. In het algemeen is de lengte van het prefix (het routeringsgedeelte van het adres) vrij (vergelijk Classless Inter-Domain Routing (CIDR) in de IPv4-adresruimte), al is de verdeling van prefix en interface-identifier meestal 64/64 bits.

• anycast: adressen voor een groep van hosts (algemener: netwerkinterfaces) waarvan er één (de dichtstbijzijnde in netwerktechnische zin) door de routers geselecteerd wordt. Deze adressen zijn precies hetzelfde als unicast-adressen en onderdeel van dezelfde adresruimte; het verschil zit in de routering van de pakketten. Hoewel er geen fundamentele belemmeringen zijn voor de verspreiding van een anycast-groep over het globale internet, zou dat specifieke routeringsinformatie (een host-route) vereisen in alle routers. Vandaar dat anycast-groepen in de praktijk beperkt zijn tot een topologische regio met een zo lang mogelijk gedeeld prefix.

• multicast: adressen voor een groep van hosts (algemener: netwerkinterfaces) die alle tegelijk benaderd worden. De scope van deze adressen varieert van lokaal tot globaal. Bepaalde (permanente) groepen zijn al voorgedefinieerd voor specifieke systemen, zoals alle aangesloten nodes, routers, en NTP-, mDNSv6- en DHCPv6-servers.

De verschillende typen IPv6-adressen zijn te herkennen (te onderscheiden) aan de meest-significante bits van het adres:

De details voor de verschillende typen IPv6-adressen vind je in RFC 4291.

Hieronder laten we zien hoe de verschillende typen adressen opgebouwd zijn.

Generieke unicast-adressen zijn globale adressen die een systeem (eigenlijk: een netwerkinterface) aanduiden; oftewel: de unieke adressen die we in het algemeen gebruiken om een host of server op internet aan te duiden. Ze bestaan uit een 64-bits network-prefix (om pakketten te routeren), gevolgd door een 64-bits netwerkinterface-identifier (om een systeem (interface) op het betreffende (sub)netwerk aan te duiden).

Het network-prefix is weer opgedeeld in een routing-prefix van 48 bits of meer (om pakketten naar het betreffende netwerk te routeren; bijvoorbeeld naar een bedrijfsvestiging), gevolgd door een subnet-identifier van 16 bits of minder (om pakketten intern naar verschillende subnetwerken binnen het betreffende netwerk (de vestiging) te routeren).

De netwerkinterface-identifier is in het algemeen:

• afgeleid van het MAC-adres van de betreffende interface (in 'Modified EUI-64'-formaat, volgens RFC 2464)

• toegekend via DHCPv6

• random toegekend (via de Privacy Extensions voor SLAAC, zoals gedefinieerd in RFC 8981)

• of handmatig toegekend

64 bits is de maximale lengte van een network-prefix; deze kan wel korter zijn (zoals besproken in RFC 7421). De waarde van de interface-identifier heeft geen speciale betekenis meer als deze eenmaal is samengesteld (zoals besproken in RFC 7136). Voor de routering van IPv6-pakketten zijn altijd alle 128 bits van het destination address beschikbaar.

Alle globale unicast-adressen die beginnen met iets anders dan 3 nul-bits (0b000...) hebben altijd een 64-bits network-prefix gevolgd door een interface-identifier in 'Modified EUI-64'-formaat. Voor adressen die beginnen met 3 nul-bits (bijvoorbeeld de IPv4-mapped IPv6-adressen) kan dit anders zijn. De details van het 'Modified EUI-64'-formaat vind je in RFC 4291, sectie 2.5.1.

Het unicast-adresformaat is gedefinieerd in RFC 4291, sectie 2.5.

Anycast-adressen zijn globale adressen die één systeem uit een groep systemen (eigenlijk: netwerkinterfaces) onder een gedeeld IP-adres aanduiden; oftewel: unieke adressen die we net als unicast-adressen in het algemeen gebruiken om een host of server op internet aan te duiden. Ze zijn dan ook precies hetzelfde als unicast-adressen en onderdeel van dezelfde adresruimte.

Het anycast-adresformaat is gedefinieerd in RFC 4291, sectie 2.6.

Multicast-adressen zijn adressen die een groep van meerdere systemen tegelijk onder een gedeeld IP-adres aanduiden. Ze bestaan uit een eerste byte met de waarde 0xff. Van de tweede byte geven de minst-significante 4 bits de scope van het adres aan: variërend van lokaal tot globaal (zoals gedefinieerd in RFC 7346 en door IANA). De meest-significante 4 bits bevatten 3 vlaggen voor specifieke type-aanduidingen en functies (uitgewerkt in RFC's 3306 en 3956). Zie RFC 4291, sectie 2.7 voor de details, alsook RFC 4489). De resterende 14 bytes bevatten de unieke multicast group id; de inhoud daarvan is verder uitgespecificeerd in RFC's 3306 en 7371.

Het multicast-adresformaat is gedefinieerd in RFC 4291, sectie 2.7.

Bepaalde (permanente) multicast-groepen (aangeduid door een T-vlag met waarde nul) zijn al voorgedefinieerd voor specifieke systemen (in specifieke scopes), zoals alle aangesloten nodes, routers, en NTP-, mDNSv6- en DHCPv6-servers. Deze lijst van groepen/adressen wordt hier bijgehouden door IANA:

https://www.iana.org/assignments/ipv6-multicast-addresses/ipv6-multicast-addresses.xhtml

Solicited-Node multicast-adressen worden door het Neighbor Discovery Protocol (NDP) gebruikt om te detecteren of een interface-identifier al in gebruik is op een netwerksegment (middels de Duplicate Address Detection (DAD)-procedure). Een dergelijk adres bestaat uit het ff02::1:ff00:0/108-prefix, gevolgd door de laatste 24 bits van het unicast/anycast-adres (zijnde de minst-significante bits van de interface identifier).

Dit adresformaat is gedefinieerd in RFC 4291, sectie 2.7.1.

De specifieke IPv6-adressen zijn adressen en segmenten binnen de IPv6-adresruimte gereserveerd voor specifieke doeleinden/functies. De meeste van deze adresformaten zijn in detail gedefinieerd in RFC 4291, sectie 2.5.

Let op dat dit iets anders is dan de gereserveerde IPv6-adresreeksen, die je simpelweg niet mag gebruiken.

Alle speciale IPv6-adressen houdt IANA in deze lijst bij:

https://www.iana.org/assignments/iana-ipv6-special-registry/iana-ipv6-special-registry.xhtml

Het (unicast) loopback-adres heeft het formaat 0:0:0:0:0:0:0:1 of ::1 (localhost).

Dit adres heeft Link-Local als scope en refereert naar de node zelf (via de virtuele loopback interface). Dit adres mag dus nooit aan een fysieke netwerkinterface toegekend worden.

Het ongespecificeerde adres heeft het formaat 0:0:0:0:0:0:0:0 of ::.

Dit adres is geen echt adres: het wordt alleen gebruikt als geen IPv6-adres bekend of nodig is. Dit adres mag dus nooit aan een node of netwerkinterface toegekend worden.

Voor routering wordt dit formaat voor de default route gebruikt: ::/0.

De IPv4-compatible IPv6-adressen bestaan uit 96 nul-bits, gevolgd door een embedded IPv4-adres in de laatste 32 bits: ::<IPv4-adres>/96.

Het betreffende IPv4-adres moet globaal en uniek zijn (oftewel: een host of server op internet aanduiden).

Deze adressen waren alleen bedoeld om IPv4-adressen in een datastructuur voor IPv6-adressen op te slaan tijdens de transitie van IPv4 naar IPv6 en worden inmiddels niet meer gebruikt.

De IPv4-mapped IPv6-adressen bestaan uit 80 nul-bits en 16 één-bits, gevolgd door een embedded IPv4-adres in de laatste 32 bits: ::ffff:<IPv4-adres>.

Dit formaat mapt de hele IPv4-adresruimte binnen de IPv6-adresruimte. Deze mapping is bedoeld om de complexiteit van dual-stack implementaties weg te houden van IP-versie-onafhankelijke netwerkapplicaties tijdens de transitie van IPv4 naar IPv6; intern volstaat dan een enkele implementatie van IPv6. Meer informatie hierover vind je in RFC 4038, sectie 4.2.

De adresselectie-algoritmen voor IP-versie-afhankelijke netwerkapplicaties zijn beschreven in RFC 3484.

De Link-Local unicast-adressen bestaan uit 0b1111111010 (10 bits) en 54 nul-bits, gevolgd door een 64-bits interface-identifier in 'Modified EUI-64'-formaat: fe80::<interface id>.

Deze adressen zijn alleen geldig op een lokaal netwerksegment en worden dus nooit gerouteerd. Ze worden meestal automatisch toegekend aan een netwerkinterface en kunnen alleen gebruikt worden voor verbindingen met lokale systemen op hetzelfde segment.

De Site-Local unicast-adressen bestaan uit 0b1111111011 (10 bits), gevolgd door een 54-bits subnetwork-identifier en een 64-bits interface-identifier in 'Modified EUI-64'-formaat: fec0::/10<subnet id>:<interface id>.

Deze adressen zijn alleen geldig op een lokaal netwerk (bijvoorbeeld binnen een bedrijfsvestiging) en worden dus nooit naar/van buiten gerouteerd. Dit formaat heeft inmiddels de status 'deprecated' (in RFC 3879) en is opgevolgd door de ULA-reeks.

De unieke lokale unicast-adressen (ULA's) beginnen alle met het prefix fc00::/7. Dit prefix wordt gevolgd door een één-bit (de 'Locally assigned'-vlag) en een 40-bits (pseudo-random) global identifier. Het resultaat is een 48-bits prefix dat ‘statistisch uniek’ is voor de organisatie: fd00:<global id><subnet id><interface id>.

Deze adressen zijn vrij beschikbaar voor intern gebruik binnen een organisatie (vergelijkbaar met de 'private network'-adresreeksen voor IPv4). Ze zijn alleen geldig binnen de organisatie en worden dus nooit naar/van buiten gerouteerd.

Het voordeel van de random-identifier is dat er geen botsingen in de adresruimte optreden bij fusies van organisaties en hun netwerken of bij het koppelen van verschillende Virtual Private Networks (VPN's), en dat er geen rampen gebeuren als deze lokale adressen per ongeluk toch op het internet belanden.

Dit adresformaat is gedefinieerd in RFC 4193.

De Subnet-Router anycast-addressen bestaan uit het complete subnet-prefix, gevolgd door een interface-identifier van allemaal nullen: <subnet prefix>::.

Deze anycast-adressen hebben een lokale scope en adresseren één van routers in het betreffende netwerksegment.

Dit adresformaat is gedefinieerd in RFC 4291, sectie 2.6.1.

De IPv6-adressen voor 6to4 bestaan uit het prefix 2002::/16, gevolgd door een 32-bits embedded IPv4-adres: 2002:<IPv4-adres>::/48.

Het resultaat is een 48-bits prefix dat in combinatie met een 16-bits subnet-identifier en een 64-bits interface-identifier gebruikt kan worden voor intern IPv6-verkeer, eventueel gekoppeld over IPv4 via 6in4 tunneling.

Het nadeel van het 6to4-protocol is dat dit alleen werkt voor clients met een publiek IPv4-adres, en niet voor IPv4-clients achter een NAT-gateway. We bespreken dit transitiemechanisme hier uitgebreider.

Dit adresformaat is gedefinieerd in RFC 3056.

De IPv6-adressen voor Teredo tunneling bestaan uit het prefix 2001:0000:/32, gevolgd door het 32-bits embedded IPv4-adres van de IPv4 Teredo-server, gevolgd door een aantal vlaggen (16 bits), de UDP-poort van de client (16 bits) en het IPv4-adres van de client (32 bits): 2001:0000:<IPv4-adres Teredo-server>:<vlaggen>:<UDP-poort Teredo-client>:<IPv4-adres Teredo-client>.

Teredo is een IPv6-over-IPv4 tunneling-protocol ontworpen door Microsoft. Het voordeel van het Teredo-protocol is dat dit ook werkt voor IPv4-clients achter een NAT-gateway, terwijl het 6to4 tunneling-protocol alleen werkt voor clients met een publiek IPv4-adres.

Teredo is inmiddels achterhaald en zou niet meer gebruikt moeten worden voor nieuwe implementaties.

Dit adresformaat is gedefinieerd in RFC 4380.

De IPv4-translated IPv6-adressen bestaan uit 64 nul-bits, 16 één-bits en 16 nul-bits, gevolgd door een embedded IPv4-adres in de laatste 32 bits: ::ffff:0:<IPv4-adres>.

Deze adressen werden gereserveerd voor de allereerste versie van stateless IPv4–IPv6-translatie (SIIT) en worden inmiddels niet meer gebruikt.

Dit adresformaat werd gedefinieerd in RFC 2765.

De IPv6-adressen voor IPv4–IPv6-translatie bestaan uit het prefix 64:ff9b::/64, gevolgd door een embedded IPv4-adres in de laatste 32 bits: 64:ff9b::<IPv4-adres>/96.

Naast deze well-known adresreeks bestaat de mogelijkheid om een alternatief adresformaat met een optionele postfix variërend in lengte van 0/24/32/40/48/56 bits te gebruiken. Het prefix varieert dan van 32 tot 96 bits, waarbij de 8 bits vanaf positie 64 altijd de waarde 0b00000000 moeten hebben: <prefix>::<IPv4-adres, onderbroken door de waarde 0x00 op positie 64><suffix>.

Het prefix 64:ff9b::/96 mag (kan) alleen gebruikt worden in de eerste vorm (zonder suffix). In de andere gevallen moet een regulier prefix van de organisatie zelf worden gebruikt. Het suffix zelf is gereserveerd voor toekomstige toepassingen en moet tot die tijd op nul gezet worden.

Deze adressen worden gebruikt door de NAT64/DNS64-transitiemechanismen.

Dit adresformaat is gedefinieerd in RFC 6052.

Een paar jaar geleden is het veel bredere prefix 64:ff9b:1::/48 ook beschikbaar gemaakt voor IPv4–IPv6-translatie. Dit maakt het makkelijker om verschillende/meerdere transitiemechanismen naast elkaar in te zetten.

Dit adresformaat is gedefinieerd in RFC 8215.

De IPv6 discard-adressen (voor routering) beginnen allemaal met het prefix 0100::/64.

Alle pakketten naar deze discard-adressen moeten door routers uit het reguliere verkeer gehaald worden.

Deze adresreeks wordt als 'zwart gat' of zinkgat (voorzien van logging/stats) gebruikt in dynamische filters en route-tabellen om Denial-of-Service (DoS)-aanvallen af te slaan.

Dit adresformaat is gedefinieerd in RFC 6666.

Het kan voorkomen dat een niet-globaal IPv6-adres tegelijkertijd gebruikt wordt in verschillende zones van een systeem; dat gebeurt dan meestal bij Link-Local adressen. Hoewel dit verwarrend kan zijn, voldoet een dergelijke configuratie aan de eisen: elk van de 'identieke' adressen is immers alleen geldig binnen zijn eigen lokale zone.

Om binnen een systeem toch onderscheid te kunnen maken tussen deze adressen – bijvoorbeeld bij het selecteren van een interface voor uitgaand verkeer – krijgen ze een zone-index mee:

• voor Unix-achtigen is dat een procentteken gevolgd door de interfacenaam: fe80::dead:beef:1234:5678%eth0

• voor Windows-systemen is dat een procentteken gevolgd door het interfacenummer: fe80::dead:beef:1234:5678%2

De details over zone-indexen vind je in sectie 6 van RFC 4007.

Gereserveerde IPv6-adresreeksen zijn reeksen binnen de IPv6-adresruimte die je simpelweg niet mag gebruiken.

Let op dat dit iets anders is dan de specifieke adressen en segmenten die zijn gereserveerd voor specifieke doeleinden/functies.

Alle speciale IPv6-adressen worden door IANA in deze lijst bijgehouden:

• https://www.iana.org/assignments/iana-ipv6-special-registry/iana-ipv6-special-registry.xhtml

Alle door IANA uitgereikte (gedelegeerde) unicast-adresreeksen (prefixes) worden in deze lijst bijgehouden:

• https://www.iana.org/assignments/ipv6-unicast-address-assignments/ipv6-unicast-address-assignments.xhtml

De IPv6-adressen voor ORCHIDv2-toepassingen (Overlay Routable Cryptographic Hash Identifiers) beginnen allemaal met het prefix 2001:20::/28.

Deze adresreeks is gereserveerd voor gebruik door ORCHIDv2-toepassingen; daarbij worden endpoint identifiers in IPv6-formaat gebruikt om hosts alleen te identificeren (op basis van publieke sleutels), in plaats van deze ook gelijk te lokaliseren (zoals de route-tabellen voor IPv6 doen).

Reden voor het gebruik van een IPv6-gelijkend formaat is dat applicaties en API's ontworpen voor het gebruik van IPv6-adressen dan ook gelijk deze identifiers kunnen verwerken. Routering vindt plaats op een aparte overlay-laag (tussen applicatie/API en IP-netwerk). Voorbeeld van een dergelijke toepassing is het Host Identity Protocol (HIP).

Deze reeks vormt een aparte namespace onafhankelijk van het IPv6-netwerk. Om verwarring tussen de 2 namespaces te voorkomen, is voor deze toepassingen een eigen prefix gedefinieerd, waarvan de adressen ook niet op internet gerouteerd worden.

Deze adresreeks is gedefinieerd in RFC 7343.

De IPv6-adressen gereserveerd voor benchmarking beginnen allemaal met het prefix 2001:2::/48.

Deze adresreeks is gedefinieerd in RFC 5180.

De IPv6-adressen gereserveerd voor documentatie beginnen allemaal met het prefix 2001:db8::/32.

Deze adresreeks is gereserveerd voor gebruik in documentatie, voorbeelden en broncode. Deze adressen worden nooit gerouteerd.

Deze adresreeks is gedefinieerd in RFC 3849.

Elke IPv6-host heeft het loopback (unicast) adres ::1.

Elke afzonderlijke IPv6-netwerkinterface heeft een Link-Local unicast-adres (beginnend met fe80::, gevolgd door een lokaal-unieke 64-bits interface identifier).

Daarnaast worden globaal-unieke unicast-adressen automatisch of handmatig toegewezen aan alle publieke netwerkinterfaces (een en ander afhankelijk van het operating system).

Anycast- en multicast-adressen worden door de beheerders toegewezen.

RFC 7934 raadt aan om verschillende IPv6-adressen op een interface te gebruiken voor verschillende functies (applicaties) op hetzelfde systeem.

Er zijn verschillende manieren om IPv6-adressen aan netwerkinterfaces toe te kennen (we bespreken deze gelijk hieronder):

• SLAAC;

• Privacy Extensions voor SLAAC;

• DHCPv6;

• handmatig.

De belangrijkste eis aan de interface-identifier is dat deze uniek moet zijn in combinatie met de subnet-identifier.

IPv6 is erop ingericht om de toekenning van unieke adressen (binnen hun scope) aan interfaces zo veel mogelijk automatisch uit te voeren.

SLAAC (Stateless Address Autoconfiguration) is het protocol voor de auto-configuratie van IPv6-adressen. Het gaat dan met name om de interface-identifiers van de Link-Local unicast-adressen (beginnend met fe80::) en unieke (binnen hun scope) unicast-adressen.

Interface-identifiers worden traditioneel afgeleid van het MAC-adres van de betreffende interface (in 'Modified EUI-64'-formaat). Daarbij wordt een check uitgevoerd op de uniekheid ervan door middel van de Duplicate Address Detection (DAD)-procedure (onderdeel van het Neighbor Discovery Protocol, NDP).

De interface-identifiers worden tenslotte met de network-prefixes gecombineerd tot unieke unicast-adressen.

Deze methode is geschikt voor het snel en eenvoudig automatisch toekennen van IPv6-adressen die uniek en routeerbaar zijn, waarbij het niet uitmaakt welke adressen een host precies gebruikt.

SLAAC is gedefinieerd in RFC 4862.

Interface-identifiers worden traditioneel afgeleid van het MAC-adres van de betreffende interface (in 'Modified EUI-64'-formaat). Daarbij wordt een check uitgevoerd op de uniekheid ervan door middel van de Duplicate Address Detection (DAD)-procedure (onderdeel van het Neighbor Discovery Protocol, NDP).

Daartoe stuurt de node een 'Neighbor Solicitation'-bericht uit naar het lokale multicast-adres van het (nu nog 'tentative') IPv6-adres dat hij wil gaan gebruiken. Als de node hierop 'Neighbor Solicitation'-berichten of 'Neighbor Advertisement'-berichten van andere nodes ontvangt, kan de node het IPv6-adres niet gebruiken en moet hij een andere genereren.

De DAD-procedure (die niet alleen bij SLAAC maar ook bij andere vormen van adrestoekenning gebruikt wordt) is gedefinieerd in RFC 4862, sectie 5.4.

Het Neighbor Discovery Protocol (NDP) is een 'link layer'-protocol – dat wil zeggen: multicast-protocol – voor IPv6. Het wordt gebruikt door de DAD-procedure om de uniekheid van interface identifiers te checken.

NDP is gedefinieerd in RFC 4861.

IPv6 is er op ingericht om de toekenning van unieke adressen (binnen hun scope) aan interfaces zo veel mogelijk automatisch uit te voeren.

SLAAC (Stateless Address Autoconfiguration) is het protocol voor de auto-configuratie van IPv6-adressen. Het gaat dan met name om de interface-identifiers van de Link-Local unicast-adressen (beginnend met fe80::) en unieke (binnen hun scope) unicast-adressen.

Network-prefixes worden periodiek gepubliceerd door de routers op het betreffende netwerksegment (via een Router Advertisement). Deel-prefixes daarvan kunnen weer door routers lager in de hiërarchie gebruikt worden voor verdere verdeling/toekenning. Het uitreiken van deel-prefixes naar subnetwerken kan geautomatiseerd worden door middel van DHCPv6-PD (prefix delegation) volgens RFC 3633 (typisch door een accessprovider voor CPE's).

Interface-identifiers worden traditioneel afgeleid van het MAC-adres van de betreffende interface (in 'Modified EUI-64'-formaat). Daarbij wordt een check uitgevoerd op de uniekheid ervan door middel van de Duplicate Address Detection (DAD)-procedure (onderdeel van het Neighbor Discovery Protocol, NDP).

De interface-identifiers worden tenslotte met de network-prefixes gecombineerd tot unieke unicast-adressen.

Omdat interface-identifiers onder SLAAC direct zijn afgeleid van het min-of-meer unieke MAC-adres van de betreffende interface, kunnen deze adressen gebruikt worden om het online-gedrag van gebruikers en de locatie van mobiele devices te volgen. Deze identifiers blijven immers gelijk zelfs als het network-prefix verandert.

De Privacy Extensions gaan dit tegen door bijvoorbeeld dagelijks een tijdelijk (random) adres te genereren. Eerdere tijdelijke adressen blijven in dit voorbeeld nog een dag langer werken voor binnenkomend verkeer. De status van een tijdelijk adres verandert dan van 'preferred' naar 'deprecated' naar uiteindelijk 'invalid'.

Merk op dat interfaces onder andere door het gebruik van de Privacy Extensions tegelijkertijd meerdere IPv6-adressen binnen hetzelfde prefix kunnen hebben.

RFC 7934 raadt sowieso aan om verschillende IPv6-adressen op een interface te gebruiken voor verschillende functies (applicaties) op hetzelfde systeem.

De Privacy Extensions voor SLAAC zijn gedefinieerd in RFC 8981.

RFC 7217 formuleert een alternatief voor deze tijdelijke adressen. Daarbij worden random interface-identifiers gegenereerd en bijgehouden per interface en subnet. Op die manier blijven de IPv6-adressen wel constant per netwerk (prefix) maar zijn ze niet op basis van hun interface-identifier aan elkaar te koppelen.

RFC 8064 raadt het gebruik van hardware-afhankelijke SLAAC-adressen af en beveelt in plaats daarvan het gebruik van IPv6-adressen volgens bovenstaande methode (RFC 7217) aan.

Security- en privacy-overwegingen met betrekking tot adrestoekenning worden besproken in RFC 7721.

Network-prefixes worden periodiek gepubliceerd door de routers op het betreffende netwerksegment (via een Router Advertisement). Deel-prefixes daarvan kunnen weer door routers lager in de hiërarchie gebruikt worden voor verdere verdeling/toekenning. Het uitreiken van deel-prefixes naar subnetwerken kan geautomatiseerd worden door middel van DHCPv6-PD (prefix delegation) volgens RFC 3633 (typisch door een accessprovider voor CPE's).

DHCPv6 is het IPv6-equivalent van DHCP voor IPv4. Dit protocol wordt onder andere gebruikt om meer controle te hebben over de gebruikte IPv6-adressen dan bij SLAAC het geval is, of om additionele IPv6-adressen aan systemen toe te kennen (typisch via een oplossing voor IP Address Management, IPAM).

Daarnaast wordt DHCPv6 gebruikt om verschillende netwerk- en applicatieparameters te verspreiden, onder andere voor de IPv4-IPv6-transitiemechanismen.

De hierboven beschreven DAD-procedure wordt ook uitgevoerd voor adressen toegekend door middel van DHCPv6.

DHCPv6 is gedefinieerd in RFC 8415.

Met de automatische adrestoekenning van IPv6 is DHCPv6 eigenlijk niet meer nodig. Hetzelfde geldt voor het instellen van de DNS-resolvers: deze informatie kan net als de prefixes door de routers verspreid worden via NDP (als gedefinieerd in RFC 8106).

Maar DHCPv6 wordt ook gebruikt om verschillende netwerk- en applicatieparameters te verspreiden, onder andere voor de IPv4-IPv6-transitiemechanismen.

Wees alert op illegale DHCPv6-servers die proberen valse IP-adressen uit te delen.

RFC 8273 beschrijft een adresschema waarbij elke eindgebruiker een uniek prefix krijgt, zodat zij alleen via een router met elkaar kunnen communiceren.

Net zoals bij IPv4 kunnen ook IPv6-adressen handmatig aan netwerkinterfaces worden toegekend.

De DAD-procedure wordt ook uitgevoerd voor deze handmatig toegekende adressen.

Tegelijkertijd raden wij de handmatige toekenning van generieke Link-Local en globale unicast-adressen af. IPv6 is erop ingericht om de toekenning van adressen aan interfaces zo veel mogelijk automatisch uit te voeren. Dat betekent bijvoorbeeld dat het omnummeren van complete netwerken relatief eenvoudig zou moeten zijn (als besproken in RFC 7010), omdat daarvoor alleen de geadverteerde prefixes aangepast hoeven worden.

ICMPv6 is het IPv6-equivalent van ICMP voor IPv4. Dit protocol is integraal onderdeel van IPv6 en verzorgt foutmeldingen en diagnostische functies.

Zo maakt het Neighbor Discovery Protocol (NDP) gebruik van ICMPv6-berichten om routes, prefixes en parameters uit te wisselen. En als een router een pakket ontvangt dat te groot is om te verwerken, stuurt deze een ICMPv6-bericht terug naar de afzender dat deze kleinere pakketten moet versturen.

De toekenning van IPv6-adressen in het DNS gebeurt op precies dezelfde manier als voor IPv4-adressen, maar dan in het speciaal daarvoor gedefinieerde AAAA-record.

In een dual-stack-omgeving bevat de zone dus zowel A-records als AAAA-records voor elke hostname:

www.example.nl    IN    A       192.0.2.3
                  IN    AAAA    2001:db8::baad:b002:2:3

Deze uitbreiding van het DNS voor IPv6 is gedefinieerd in RFC 3596.

De specificatie van de reverse DNS lookup voor IPv6 is vergelijkbaar met die van IPv4, maar vanwege de adreslengte is oplettendheid geboden: alle individuele hexadecimale cijfers (nibbles) van het IPv6-adres worden omgedraaid en gescheiden door punten '.', gevolgd door de 'ip6.arpa.'-suffix.

Zo wordt de reverse van het adres 2001:db8::d06:f00d:567:89ab weergegeven als:

b.a.9.8.7.6.5.0.d.0.0.f.6.0.d.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa.

Let op dat het suffix hier 'ip6.arpa.' moet zijn, en dat het oude suffix 'ip6.int.' niet meer gebruikt mag worden (zoals aangegeven in RFC 4159).

Deze uitbreiding van het DNS voor IPv6 is gedefinieerd in RFC 3596.

Het Internet Protocol heeft nooit onderscheid gemaakt tussen clients en servers, en kent van origine alleen maar (gelijkwaardige) hosts. De haast universele toepassing van (CG)NAT heeft het karakter van het internet echter fundamenteel veranderd: het huidige internet is grotendeels een asymmetrisch netwerk geworden waarbij systemen van eindgebruikers niet meer direct vanaf het internet bereikbaar zijn. Als gevolg daarvan zijn self-hosting en peer-to-peer-protocollen niet of niet goed meer mogelijk.

IPv6, waarbij ieder systeem weer een publiek adres krijgt (of kan krijgen), herstelt het end-to-end-principe van het Internet Protocol.

Gelijk hieronder bespreken we de implicaties voor de beveiliging van IPv6-netwerken.

NAT(44) wordt (ten onrechte) vaak gezien als een firewall omdat systemen achter de gateway van buiten (vanaf het internet) niet benaderd kunnen worden (zonder expliciete port forwarding). Maar NAT is geen firewall; het is niet meer dan een (welhaast universeel ingezet) IPv4-lapmiddel dat als bijwerking heeft dat het de systemen achter de gateway onbereikbaar maakt.

Alle generieke IPv6-adressen worden in principe gerouteerd (behalve de Link-Local en ULA-adressen). Dit in tegenstelling tot de veelgebruikte private IPv4-adresreeksen achter een NAT-gateway.

Dat betekent dat je de interne routering van alle IPv6-adressen binnen je netwerk strikt moet vastleggen, want je wilt niet dat intern verkeer onbedoeld door 2 firewalls heen buitenom over het publieke internet loopt. Bovendien zijn intern en extern verkeer (voor de mens) bij IPv6 minder goed van elkaar te onderscheiden dan bij het gebruik van de private IPv4-adresreeksen.

Kortom: zonder NAT neemt het belang van firewalls en screening routers weer toe. En ook de traditionele demilitarized zone (DMZ) wordt weer in ere hersteld; interne adressen worden niet geadverteerd of extern gerouteerd, maar zijn alleen via proxy’s benaderbaar. Hetzelfde geldt voor verbindingen die van binnen naar buiten worden opgezet.

Ander punt is dat de IPv6-adresruimte zo groot is dat het blokkeren van individuele adressen (blacklisting/whitelisting) bij misbruik niet meer mogelijk is (alleen op basis van prefixes). Dat betekent dat filteren straks meer op de reputatie van een domeinnaam plaatsvindt.

Iets vergelijkbaars geldt overigens voor IPv4 in combinatie met CGNAT: het blokkeren van een enkel IPv4-adres kan leiden tot het ten onrechte uitsluiten van een grote groep gebruikers. En voor meerdere diensten ondergebracht op een enkel IPv4-adres (bijvoorbeeld met behulp van SNI): bij een aanval op een gedeelde host is niet direct duidelijk op welke specifieke dienst deze aanval gericht is.

De operationele beveiligingsaspecten van IPv6 bespreken we in dit artikel.

Er zijn over de jaren heen allerlei onderzoeken uitgevoerd naar snelheidsverschillen tussen IPv4 en IPv6. Deze vergelijkingen leveren alles bij elkaar echter geen duidelijke winnaar op: soms is IPv6 wat sneller, en soms IPv4.

In theorie zou IPv6 iets sneller moeten zijn: het protocol bevat een paar optimalisaties in de pakket-header waardoor IPv6-pakketten sneller gerouteerd zouden moeten kunnen worden. Daarnaast hebben (native) IPv6-verbindingen onderweg geen adresvertaling nodig zoals bij IPv4-verbindingen via (CG)NAT het geval is.

Daar staat tegenover dat IPv6 pas later in de netwerkapparatuur ingebouwd is. Dat zou kunnen betekenen dat IPv6 in sommige gevallen nog niet perfect door de ASIC-hardware wordt ondersteund en dat optimalisaties in een router nog in het voordeel van IPv4 uitvallen.

Kortom: voor de snelheid maakt het gebruik van IPv6 in het algemeen geen verschil. Veruit het belangrijkste argument voor de inzet van IPv6 is de enorm grote adresruimte.

Bij de ontwikkeling van IPv6 is een aantal mogelijkheden die bij IPv4 bovenop het Internet Protocol zijn gedefinieerd in het protocol zelf verwerkt. Voorbeelden daarvan zijn IPsec (voor de authenticatie van hosts en versleuteling van verbindingen), automatische adrestoekenning, en verschillende niche-uitbreidingen via de Extension Headers.

Uiteindelijk zijn maar weinig van die innovaties in de praktijk doorgekomen. Waar IPsec initieel een verplicht onderdeel was van de IPv6-implementatie – ook als onderdeel van IPv6 ontwikkeld werd – werd dat later optioneel (zoals beschreven in RFC 8504, sectie 13). De Extension Headers komen we op internet nooit tegen. Ze blijken ook voor problemen te zorgen bij de routering van dergelijke pakketten (beschreven in RFC 7872 en deze presentatie).

Van deze 3 voorbeelden is alleen de automatische adrestoekenning via SLAAC en NDP een succes geworden. En zelfs daarvoor hebben we inmiddels een alternatief in de vorm van DHCPv6.

Wat IPv4 (tegenwoordig, vroeger niet) complex maakt zijn alle lapmiddelen die we hebben ontwikkeld om de problemen veroorzaakt door het adrestekort steeds weer een paar jaar voor ons uit te schuiven: NAT, CGNAT, SNI, STUN, TURN en ICE.

Wat IPv6 (nu nog, in een toekomstige IPv6-only-wereld niet meer) complex maakt zijn alle transitiemechanismen die zijn ontwikkeld om van de oude IPv4-wereld naar de moderne IPv6-wereld te komen.

Dat betekent dat in de huidige overgangsfase zowel de IPv4-lapmiddelen als de IPv4-IPv6-transitiemechanismen ons leven bemoeilijken. Zijn we eenmaal door deze periode heen – en dat kunnen we alleen door zo snel mogelijk IPv6 te implementeren en te gebruiken – dan is de complexiteit van IPv6 vergelijkbaar met de recht-toe-recht-aan IPv4-netwerken van weleer.

Om de overgang van IPv4 naar IPv6 zo goed mogelijk te kunnen maken zijn technische gateway- en transitiemechanismen ontwikkeld. Onderstaande grafiek geeft een overzicht.

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

De beschrijvingen in deze sectie zijn zeker niet bedoeld om uit het hoofd te kennen; ze geven een overzicht van de transitiemechanismen die je tegen kunt komen of zelf kunt toepassen.

Zoals je ziet bespreken we ook transitiemechanismen die je inmiddels niet meer moet toepassen. Deze mechanismen bespreken we hier toch omdat je ze nog tegen kunt komen in bestaande netwerken of omdat ze de basis vormen voor latere/verbeterde mechanismen.

In deze sectie bespreken we ook IPv4-IPv6-transitiemechanismen die je inmiddels niet meer moet toepassen. Deze mechanismen bespreken we hier toch omdat je ze nog tegen kunt komen in bestaande netwerken of omdat ze de basis vormen voor latere/verbeterde mechanismen.

Onderstaande grafiek geeft een overzicht van de transitiemechanismen die je nu nog kunt inzetten om de overgang van IPv4 naar IPv6 te kunnen maken (ook besproken in RFC 9313).

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

Inmiddels is de keuze voor een transitiemechanisme voor het accessnetwerk helemaal makkelijk geworden: De NSA 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 zoals je ziet bouwt 464XLAT voort op de andere 2 technieken NAT64 en DNS64, waarmee dus alleen 464XLAT overblijft.

Bovendien lijkt het erop dat we Piek-IP4 inmiddels gepasseerd te zijn. Daarmee is ook een andere groep transitiemechanismen uitgangspunt geworden. Op weg naar een IPv6-mainly wereld moeten oude mechanismen als dual-stack met NAT en CGNAT nu plaatsmaken voor nieuwere mechanismen gebaseerd op NAT64, DNS64 en 464XLAT.

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.

In een dual-stack-configuratie hebben systemen zowel een volledige IPv4- als IPv6-network-stack actief. Omdat het IPv6-netwerk in dit geval volledig parallel aan en onafhankelijk van het IPv4-netwerk draait, is een dergelijke configuratie is de makkelijkste manier om IPv6 in een bestaand netwerk te implementeren. Vanwege de goede auto-configuratie ondersteuning van IPv6 is dat meestal minder werk dan de configuratie en het beheer van IPv4:

• de IPv6-prefixes moeten in de routers, firewalls en andere netwerkapparatuur geplaatst worden;

• IPv6 moet in alle hosts (naast IPv4) aangezet worden (indien nodig).

Is de implementatie van IPv6 op netwerkniveau eenmaal rond, dan kunnen ook de applicaties naar IPv6 omgezet worden. Systemen en services waarvoor de ondersteuning van IPv6 compleet is kunnen waar relevant aan de DNS-zone worden toegevoegd.

Voordelen:

• 2 aparte, onafhankelijke IP-netwerken, zonder de combinatorische complexiteit van de andere transitiemechanismen die we hieronder bespreken.

Nadelen:

• 2 IP-netwerken parallel naast elkaar, met de bijbehorende kosten, zonder dat daar een zakelijke return tegenover staat;

• geen oplossing voor de schaarste aan IPv4-adressen.

Dual-stack is gedefinieerd in RFC 4213, sectie 2, met aanvullende richtlijnen voor content/service providers in RFC 6883.

Dual-stack-systemen hebben de mogelijkheid om de IP-versie te selecteren die de voorkeur geniet (meestal IPv6 als die beschikbaar is), of de verbinding te gebruiken die het snelst tot stand komt. In dat laatste geval vraagt een client tegelijkertijd de AAAA- en A-records van een server op, om zo snel mogelijk verbindingen over zowel IPv6 als IPv4 op te starten. De verbinding die het eerst tot stand komt wordt dan gebruikt voor het vervolg van de sessie.

Omdat dit resulteert in de beste response voor de eindgebruiker, wordt deze methode Happy Eyeballs genoemd. In het algoritme zit een voorkeur voor IPv6 ingebakken op basis van de volgorde van de acties en de benaderde systemen, en de timing tussen de verschillende onderdelen. Tegelijkertijd wordt hiermee voorkomen dat een gebruiker zijn bestemming niet kan bereiken omdat de beheerder van een dual-stack-infrastructuur zijn IPv6-netwerk verwaarloosd heeft ('IPv6 brokenness').

Happy Eyeballs is gedefinieerd in RFC 8305.

6to4 is een manier om bestaande systemen een voorlopige 48-bits IPv6-prefix (en vervolgens een compleet IPv6-adres/subnet) te geven op basis van hun publieke IPv4-adres. Hiervoor is het 2002::/16-prefix gereserveerd, wat in combinatie met een publiek 32-bits IPv4-adres resulteert in een globaal uniek 48-bits IPv6-prefix.

IPv6-verkeer wordt vervolgens ingepakt in IPv4-pakketten en over het bestaande IPv4-only-netwerk verstuurd. Voor verkeer naar native IPv6-netwerken worden speciale relay-routers ingezet (waar de IPv6-in-IPv4-pakketten in- en uitgepakt worden).

Hetzelfde mechanisme kan niet alleen door individuele hosts maar ook door 'IPv4'-routers gebruikt worden om achterliggende lokale IPv6-only-netwerken te ontsluiten (zogenaamde border-routers voorzien van een 6to4 pseudo-interface).

Het voordeel van 6to4 is dat bestaande systemen eenvoudig van een uniek IPv6-adres kunnen worden voorzien, en dat IPv6-in-IPv4-pakketten over het bestaande IPv4-only-netwerk verstuurd kunnen worden zonder dat daarvoor aparte tunnels hoeven worden opgezet.

Het nadeel van 6to4 is dat dit protocol alleen werkt voor clients met een publiek IPv4-adres, en niet voor clients achter een NAT-gateway (want hun IPv4-adressen zijn niet uniek).

6to4 is gedefinieerd in RFC 3056, met aanvullende security-overwegingen in RFC 3964 en deployment-richtlijnen in RFC 6343.

RFC 3068 definieerde het adres 192.88.99.1 als anycast-adres voor de (lokale) relay-routers waarmee 6to4-hosts verkeer naar native IPv6-netwerken kunnen sturen. Deze optie is later echter weer afgeschaft (in RFC 7526).

6to4 is inmiddels achterhaald en zou niet meer gebruikt moeten worden voor nieuwe implementaties.

6in4 (ook wel: configured tunneling) maakt gebruik van dezelfde concepten en IPv6-in-IPv4-verpakking als het hierboven beschreven 6to4-mechanisme. Maar waar 6to4 een globaal unieke 48-bits IPv6-prefix afleidt uit het publieke IPv4-adres van een systeem, worden de IPv6-eindpunten voor 6in4 handmatig geconfigureerd. Het voordeel hiervan is dat ook IPv4-only-systemen achter een NAT-gateway (dat wil zeggen: systemen zonder een publiek IPv4-adres) op deze manier van een uniek IPv6-adres kunnen worden voorzien.

Hoewel deze technologie ook voor individuele hosts gebruikt kan worden, blijft de inzet van 6in4 vanwege de handmatige configuratie meestal beperkt tot routers. Er zijn wel technische hulpmiddelen beschikbaar om de toekenning van IPv6-adressen te automatiseren en om IPv4-only-diensten achter de NAT-gateway te ontsluiten.

6in4 is gedefinieerd in RFC 4213, sectie 3.

6in4 is inmiddels achterhaald en zou niet meer gebruikt moeten worden voor nieuwe implementaties.

Net als 6in4 is ook IPv6 rapid deployment (kortweg 6rd) gebaseerd op het hierboven beschreven 6to4-mechanisme, maar het gebruikt een adresseringsschema dat uitgaat van de reguliere IPv6-prefixes die aan een organisatie zijn toegekend.

6to4 voorziet in principe alle publieke IPv4-nodes ook van een unieke IPv6-prefix en koppelt deze via gateway-routers aan de rest van het IPv6-gebaseerde internet. Om daadwerkelijk bereikbaar te zijn moeten deze 6to4-specifieke IPv6-prefixes wel door iedereen in de buitenwereld geadverteerd en gerouteerd worden.

Voor 6rd gebruikt een organisatie een van zijn eigen reguliere IPv6-prefixes in plaats van het generieke 2002::/16-prefix. Om een node voor het IPv6-gebaseerde internet te ontsluiten, wordt zijn IPv4-adres gecombineerd met het 6rd IPv6-prefix.

De routing prefixes die de Regional Internet Registries (RIR's) aan hun leden toekennen zijn 32 bits lang. Zou je daar nog een volledig 32-bits IPv4-adres aan vastplakken, dan kom je uit op 64-bits prefixes voor de eindgebruikers. 6rd-routers kunnen daarom de gedeelde meest-significante bits van je publieke IPv4-adresreeks weglaten, waarmee gebruikers kortere prefixes kunnen krijgen en ruimte overhouden voor subnetwerken. Een andere/aanvullende mogelijkheid is om verschillende IPv6-prefixes te gebruiken voor verschillende IPv4-netwerken.

De nodes worden onder 6rd aangeduid als Customer Edge (CE) routers en kunnen zowel CPE's (Customer-Premises Equipment) als applicatieservers betreffen. De Border Relays (BR's), waarvan er een of meerdere kunnen zijn, zijn de routers die de 6rd-pakketten naar en van buiten het 6rd-domein routeren.

Voordeel van 6rd is dat je het hele 6rd-domein in eigen beheer hebt, zodat je zeker weet dat je pakketten ook overal gerouteerd worden.

6rd is gedefinieerd in RFC 5969.

6rd is inmiddels achterhaald en zou niet meer gebruikt moeten worden voor nieuwe implementaties.

6over4 (ook wel 'virtueel Ethernet') is een manier om bestaande systemen van een Link-Local IPv6-adres te voorzien, en deze met elkaar tot een lokaal IPv6-netwerksegment te verbinden op basis van een IPv4-multicast-netwerk dat als onderliggende 'data link'-laag voor het IPv6-segment fungeert.

Daartoe wordt eerst een Link-Local IPv6-adres geconstrueerd door het fe80::/96-prefix te combineren met het 32-bits IPv4-adres van het betreffende systeem.

Merk op dat de Universal/Local-vlag op positie 7 van de 64-bits interface-identifier nu de waarde nul heeft, wat aangeeft dat deze identifiers niet uniek zijn (in tegenstelling tot de eerder besproken 'Modified EUI-64'-gebaseerde identifiers waar deze vlag de waarde één heeft).

Voor NDP – een IPv6 'link layer'- (dat wil zeggen: multicast)-protocol – wordt gebruikt gemaakt van een bestaand (of: hiervoor opgezet) IPv4 multicast-netwerk dat de verschillende 6over4-uitgeruste systemen 'direct' met elkaar verbindt.

Transport van de IPv6-pakketten geschiedt weer in dezelfde IPv6-in-IPv4-verpakking als bij de 6to4- en 6in4-mechanismen.

6over4 is gedefinieerd in RFC 2529.

6over4 is inmiddels achterhaald en zou niet meer gebruikt moeten worden voor nieuwe implementaties.

Public 4over6 is bedoeld voor access providers die eindgebruikers over een IPv6-only-access-netwerk toegang willen bieden tot het IPv4-gebaseerde internet (als alternatief voor een volledige dual-stack-implementatie).

Daartoe krijgen de gebruikers (CPE's) publieke IPv4-adressen uitgereikt, waarmee dit mechanisme ook goed werkt voor het ontsluiten van IPv4 applicatieservers. De toekenning gebeurt door middel van DHCP(v4) over IPv6 voor grote aantallen, en statisch voor IPv4 applicatieservers.

Transport van de IPv4-pakketten over het IPv6-only-netwerk vindt plaats via generieke IPv4-in-IPv6 tunneling volgens RFC 2473. Daarbij fungeert de IPv6-tunnel als virtuele 'data link'-laag voor het IPv4-verkeer dat eroverheen loopt. In- en uitpakken van de IPv4-in-IPv6 tunnelpakketten gebeurt door de routers/gateways aan de uiteinden van de tunnel. Omdat het IPv4-adres nu niet in het IPv6-adres is verwerkt, moet de gateway aan providerzijde (de tunnel concentrator) de binding tussen de gebruikte IPv4- en IPv6-adressen bijhouden.

Public 4over6 is gedefinieerd in RFC 7040.

Public 4over6 is inmiddels achterhaald en zou niet meer gebruikt moeten worden voor nieuwe implementaties.

Accessproviders die maar een beperkt aantal publieke IPv4-adressen tot hun beschikking hebben worden verwezen naar het gelijk hieronder beschreven Dual-Stack Lite (een alternatief gebaseerd op CGNAT), of het daaropvolgende, beter schaalbare Lightweight 4over6.

Dual-Stack Lite (kortweg DS-Lite) combineert de hierboven beschreven IPv4-in-IPv6 tunneling van Public 4over6 met (CG)NAT. Dat betekent dat eindgebruikers (CPE's) geen publiek IPv4-adres meer toegewezen krijgen, maar alleen een privaat IPv4-adres.

Hiervoor is het IPv4-netwerk 192.0.0.0/29 gereserveerd:

• de Address Family Transition Router (AFTR) aan providerzijde (een combinatie van tunnel concentrator en NATP-gateway) krijgt altijd het adres 192.0.0.1;

• de Basic Bridging BroadBand (B4)-interface op de CPE krijgt altijd het adres 192.0.0.2;

• het IPv6-adres van de AFTR-gateway voor het versturen van de IPv4-in-IPv6 tunnelpakketten (en andere instellingen) krijgt de B4-interface meestal aangereikt via DHCPv6.

Op de AFTR (aan providerzijde) wordt na het uitpakken en voor het inpakken van de IPv4-in-IPv6 tunnelpakketten een IPv4–IPv4-vertaalslag voor NATP uitgevoerd. Omdat hierbij de binding met de IPv6-adressen gebruikt wordt, kan dit tot een enkele vertaalslag beperkt blijven.

DS-Lite is niet meer afhankelijk van de beschikbaarheid van voldoende publieke IPv4-adressen, wat dit mechanisme geschikt maakt om grote aantallen gebruikers aan te sluiten via een IPv6-only-access-netwerk. Omdat gebruikers nu niet meer vanaf het internet bereikbaar zijn, is deze oplossing echter niet langer geschikt om applicatieservers te ontsluiten.

DS-Lite is gedefinieerd in RFC 6333.

Lightweight 4over6 (lw4o6) is een uitbreiding op het hierboven beschreven DS-Lite-mechanisme, waarbij de IPv4-IPv6-vertaalslag van de centrale tunnel concentrator (de AFTR) naar de individuele CPE's is verplaatst.

Omdat de IPv4-adressen van de AFTR en de B4-interface voor alle individuele gebruikers altijd hetzelfde zijn, en de IPv4-pakketten tussen de CPE en de NATP-gateway niet gerouteerd hoeven worden (want door de IPv6-tunnel getransporteerd), kan de IPv4-IPv4-vertaalslag op de IPv4-pakketten zonder meer op de CPE (dat wil zeggen: aan de andere kant van de tunnel, aan gebruikerszijde) uitgevoerd worden.

Daarvoor hoeft de CPE alleen te weten welk publiek IPv4-adres en welke port range voor hem gereserveerd is aan de publieke zijde van de NATP-gateway, zodat deze de IPv4-pakketten alvast in de juiste vorm voor routering in de buitenwereld (dat wil zeggen: met de juiste source/destination) kan samenstellen. Deze (aanvullende) informatie krijgt de lwB4-interface van de lwAFTR aangereikt via DHCP of het Port Control Protocol (PCP).

Het voordeel van Lightweight 4over6 ten opzichte van DS-Lite is dat hiermee de NATP-functie van de centrale AFTR naar de individuele CPE's wordt verplaatst, wat de schaalbaarheid van deze oplossing vergroot.

Lightweight 4over6 is gedefinieerd in RFC 7596.

NAT64 is een (stateful) NAT-technologie waarmee IPv6-only-systemen achter een NAT64-gateway met IPv4-only-systemen op internet kunnen communiceren.

De clients achter de gateway gebruiken daarvoor als destination-adres het 64:ff9b::/96-prefix (of een prefix uit de 64:ff9b:1::/48-adresruimte, of een regulier prefix van de organisatie zelf) gecombineerd met het IPv4-adres van de server. Deze speciale pakketten worden intern van en naar de NAT64-gateway gerouteerd, waar de vertaling tussen IPv6 en IPv4 plaatsvindt (op protocolniveau dus).

Net als de traditionele IPv4-IPv4 NAT (NAT44) werkt NAT64 alleen voor verbindingen geïnitieerd door clients achter de gateway.

Omdat alleen de headers van de IP-pakketten worden vertaald (volgens RFC 7915, voorheen RFC 6145), werkt NAT64 bovendien niet voor applicatieprotocollen waarbij ook letterlijke IP-adressen (zogenaamde literals) in de payload van de pakketten worden opgenomen (bekendste geval is het oude FTP-protocol). Stuurt een IPv6-only-client een IPv6-adres/poort-combinatie naar de IPv4-only-server (bijvoorbeeld omdat daar een applicatiespecifieke poort open staat), dan kan de server deze immers niet openen. En de andere kant op: stuurt een IPv4-only-server een IPv4-adres/poort-combinatie terug naar de IPv6-only-client, dan kan de client deze niet openen.

NAT64 is gedefinieerd in RFC 6146, met deployment-scenario's in RFC 6144.

NAT64 ondersteunt (vooralsnog) alleen TCP, UDP en ICMP (net als NAT44).

Gelijk hieronder bespreken we hoe NAT64 met DNS64 gecombineerd wordt tot een compleet transitiemechanisme waarvoor geen wijzigingen aan de individuele IPv6-only-systemen nodig zijn.

DNS64 is een DNS-functie om AAAA (IPv6)-records samen te stellen uit A (IPv4)-records, voor gebruik in combinatie met het hierboven beschreven NAT64-transitiemechanisme.

Ontvangt een DNS64-server een verzoek om AAAA-records voor een domeinnaam waarvoor alleen A-records beschikbaar zijn, dan creëert deze zelf een (synthetisch) AAAA resource-record-set. Daarvoor worden de A-records gecombineerd met het 64:ff9b::/96-prefix (of een prefix uit de 64:ff9b:1::/48-adresruimte, of een regulier prefix van de organisatie zelf).

De combinatie van NAT64 en DNS64 levert een compleet transitiemechanisme op waarvoor geen wijzigingen aan de individuele IPv6-only-systemen nodig zijn.

Hoewel deze netwerkarchitectuur goed schaalt, introduceert de NAT64-gateway wel een bottleneck in het netwerk.

Het belangrijkste nadeel van deze oplossing is echter dat deze niet werkt in combinatie met end-to-end DNSSEC-validatie. De DNS64-server (functionerend als recursieve resolver) kan immers geen digitale handtekening (het RRSIG-record) genereren voor de AAAA-resource-record-set die het voor een andermans domeinnaam heeft gecreëerd.

Een validerende (DNS64-aware) resolver op de IPv6-only-client zou eventueel wel zelf nog validatie voor IPv4 kunnen doen als deze een resource-record-set met DNS64-prefix terugkrijgt. In andere gevallen kan de DNS64-server de IPv4 resource-record-set valideren en eventueel nog de AD-vlag zetten (indien de (stub) resolver van de client wel de AD-vlag maar niet de CD-vlag heeft gezet), zij het dat daarmee de 'the last mile' niet is beschermd. Bovendien is deze laatste optie (het zetten van een AD-vlag voor niet-authentieke resource-record-sets) volgens de DNSSEC-standaard officieel niet toegestaan.

DNS64 is gedefinieerd in RFC 6147.

Net als de hierboven beschreven NAT64/DNS64-combinatie maakt ook 464XLAT het mogelijk voor IPv6-only-systemen achter een NAT64-gateway om met IPv4-only-systemen op internet te kunnen communiceren.

In dit geval wordt de NAT64-gateway gecombineerd met een Customer-side Translator (CLAT) op elke client, die daar een virtuele IPv4-interface (uit een private adresreeks) aanbiedt. Benadert zo'n client nu een IPv4-only-server, dan maakt de lokale CLAT een eerste (stateless) vertaalslag waarbij uitgaande IPv4-pakketten naar het 64:ff9b::/96-prefix (of een prefix uit de 64:ff9b:1::/48-adresruimte, of een regulier prefix van de organisatie zelf) worden omgezet (volgens RFC 7915). Aangekomen bij de NAT64-gateway (nu genaamd de Provider-side Translator, PLAT) wordt een tweede (stateful) vertaalslag van IPv6 terug naar IPv4 uitgevoerd, waarna de pakketten naar de betreffende IPv4-only-server worden gestuurd.

Omdat beide hosts nu IPv4 gebruiken is het probleem van de incompatibele literals opgelost. De beperkingen van NAT blijven wel bestaan.

Het prefix te gebruiken voor de eerste vertaalslag door de CLAT krijgt deze meestal aangereikt via DHCPv6. Alternatief is om een regulier IPv6-prefix dat aan de organisatie is toegekend te gebruiken, maar dan loop je het risico dat je deze een keer ten onrechte als veilig intern verkeer aanmerkt.

Hoewel het 464XLAT-mechanisme wel lijkt op tunneling is het dat niet: de IPv4-pakketten worden niet ingepakt in IPv6, maar daadwerkelijk omgezet naar IPv6 en daarna weer terug.

Hoewel een DNS64-server voor 464XLAT niet per se nodig is, kan deze wel gebruikt blijven worden voor verkeer (dat wil zeggen: applicaties) dat gegarandeerd geen literals bevat. Voor die verkeersstromen volstaat dan een enkele vertaalslag op de PLAT, identiek aan de hierboven beschreven NAT64/DNS64-combinatie.

Voordelen:

• geeft je de mogelijkheid een toekomstbestendige interne IPv6-only-infrastructuur en datacenters op te zetten, zonder dat je daarmee de aansluiting met het IPv4-only-deel van internet verliest;

• heeft een minimum aantal publieke IPv4-adressen nodig;

• je hoeft maar één IP-netwerk te onderhouden, waarmee de kosten beperkt blijven.

464XLAT is gedefinieerd in RFC 6877, met aanvullende richtlijnen voor datacenters in RFC's 7755 en 7756 (SIIT-DC), voor IPv4-verkeer van buiten naar binnen).

Mapping of Address and Port (MAP) is een methode om de stateful gateways van de eerder besproken DS-Lite- en NAT64-transitiemechanismen zo veel mogelijk stateless te maken en op te schalen. Daartoe wordt nu ook het (gedeelde) IPv4-afzenderadres in het IPv6-afzenderadres verwerkt.

IPv4-adressen kunnen eventueel door meerdere eindgebruikers (CPE's) gedeeld worden door de 16-bits poortruimte in blokken op te delen en die blokken individueel aan CPE's toe te kennen. Zo kan met een beperkte hoeveelheid (globaal/lokaal unieke, port-restricted) IPv4-adressen een veelvoud aan eindgebruikers worden geholpen zonder dat daarbij adres/poort-combinaties gedeeld worden. In wezen worden hiermee de meest-significante bits van de poortruimte toegevoegd aan de IPv4-adresruimte. Deze techniek heet Address plus Port (A+P) en is gedefinieerd in RFC 6346.

De MAP-standaarden gebruiken de termen Customer Edge (CE) voor de CPE, Border Relay (BR) voor de IPv4-IPv6-gateway, Port Set voor de individuele blokken van poorten, Port Set ID (PSID) voor de meest-significante poort-bits die een Port Set identificeren, IPv4-prefix voor de gedeelde bits in het IPv4-adres, IPv4-suffix voor de unieke bits in het IPv4-adres, Embedded Address (EA)-bits voor de samengestelde IPv4-suffix/PSID-identificatie van een CE, en MAP-domein voor de adresruimte die door de EA-bits wordt gecreëerd.

Door nu alle CE-devices een IPv6-adres te geven bestaande uit een regulier IPv6-prefix toegekend aan de organisatie (typisch 32 bits), gevolgd door de EA-bits (tezamen 64 bits), gevolgd door een 64-bits netwerkinterface-identifier (die het volledige IPv4-adres en de PSID bevat) ontstaat een uniek IPv6-afzenderadres: <organisation prefix><EA bits>:0000:<IPv4 address><PSID>.

Merk op dat het 64-bits network-prefix (met eventuele overloop naar de interface-identifier) van dit IPv6-afzenderadres alle informatie bevat om pakketten volledig van en naar de betreffende CPE te routeren. Dat maakt dat de gateway nu nagenoeg stateless zijn werk kan doen.

CPE's binnen een MAP-domein (de MAP-nodes) kunnen direct met elkaar communiceren (in zogenaamde 'Mesh mode'). IPv4-verkeer naar buiten loopt via een point-to-point-tunnel van de CPE naar de Border Relay via generieke IPv4-in-IPv6 tunneling volgens RFC 2473 (voor MAP with Encapsulation), of via de NAT64-translatiefunctie van de Border Relay (voor MAP using Translation).

MAP is gedefinieerd in RFC's 7597 en 7599.

De eerste RFC beschrijft MAP-E (MAP with Encapsulation), waarbij IPv4-verkeer ingepakt wordt in IPv4-in-IPv6 tunnelpakketten. Dat maakt MAP-E een stateless variant op het DS-Lite-mechanisme.

De tweede RFC beschrijft MAP-T (MAP using Translation), waarbij MAP gecombineerd wordt met de NAT64-translatie om deze stateless te maken. In feite wordt hiervoor een dubbele NAT64-translatie uitgevoerd (nu niet alleen voor het destination- maar ook voor het source-adres).

MAP-enabled CPE's kunnen alle informatie over hun IPv6-prefixes, IPv4-postfixes en Port Sets aangereikt krijgen via DHCPv6, zoals gespecificeerd in RFC 7598. De NATP-functie op de CPE zorgt ervoor dat alleen poorten uit de eigen Port Set gebruikt worden voor de embedded IPv4-afzenderadressen van verbindingen naar buiten. De MAP-specifieke configuraties voor CPE's en Border Relays worden vastgelegd en gedistribueerd in zogenaamde mapping rule sets.

De implementatie van IPv6 in een bestaande netwerkinfrastructuur is enorm afhankelijk van de bestaande situatie. In het algemeen definieer je voor grote en complexe bedrijfsnetwerken op basis van de uitgangssituatie en zakelijke/technische doelstellingen eerst een strategie en een roadmap, en selecteer je daarbij een IPv4-IPv6-transitiemechanisme. Deze documenten werk je vervolgens uit tot een concrete netwerkarchitectuur, het adresplan, het routeringsplan en de securitypolicy's.

Onderstaande puntenlijst kan je helpen om de implementatie van IPv6 in gang te zetten:

• de uitgangssituatie en zakelijke/technische doelstellingen en afwegingen leiden achtereenvolgens tot:

  • het opstellen van een strategie;

  • strategische overwegingen voor de implementatie van IPv6 in bedrijfsnetwerken vind je in RFC 7381;

  • de ontwikkeling van een roadmap;

  • de selectie van een transitiemechanisme;

• de volgende stappen bestaan uit het opstellen (dat wil zeggen: expliciet maken) van:

  • de netwerkarchitectuur;

  • het adresplan;

    • meer over de toekenning van unicast IPv6-adressen vind je in RFC 5375;

  • het routeringsplan;

  • de security policy’s voor de netwerkknooppunten en -segmenten;

  • de inrichting van security-logging, analyse en afhandeling;

• daarbij kun je je laten helpen door software voor netwerkontwerp en -management en IP Address Management (IPAM).

Voor onze registrars hebben we 2 SIDN Academy e-learning-modules voor IPv6 beschikbaar.

We bespreken in deze FAQ ook IPv4-IPv6-transitiemechanismen die je inmiddels niet meer zou moeten willen toepassen. Deze mechanismen behandelen we hier toch omdat je ze nog tegen kunt komen in bestaande netwerken of omdat ze de basis vormen voor latere/verbeterde mechanismen.

Onderstaande grafiek geeft een overzicht van de transitiemechanismen die je nu nog kunt inzetten om de overgang van IPv4 naar IPv6 te kunnen maken (ook besproken in RFC 9313).

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

Inmiddels is de keuze voor een transitiemechanisme voor het accessnetwerk helemaal makkelijk geworden: De NSA 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 zoals je ziet bouwt 464XLAT voort op de andere 2 technieken NAT64 en DNS64, waarmee dus alleen 464XLAT overblijft.

Bovendien lijkt het erop dat we Piek-IP4 inmiddels gepasseerd te zijn. Daarmee is ook een andere groep transitiemechanismen uitgangspunt geworden. Op weg naar een IPv6-mainly wereld moeten oude mechanismen als dual-stack met NAT en CGNAT nu plaatsmaken voor nieuwere mechanismen gebaseerd op NAT64, DNS64 en 464XLAT.

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.

Jazeker: alle gangbare netwerkapparatuur ondersteunt IPv6. Interoperabiliteit is geen enkel probleem meer. Testen voor interoperabiliteit van professionele apparatuur is niet meer nodig; systemen voor bedrijfsmatige inzet doen gewoon IPv6.

Ook alle gangbare netwerkmanagementsoftware en -tools ondersteunen IPv6. Dat geldt ook voor provider platforms als Plesk, cPanel en DirectAdmin.

Gedetailleerde (functionele) eisen met betrekking tot de ondersteuning van IPv6 in netwerkapparatuur vind je onder andere in RFC 8504 (BCP 220), en in het 'ripe-772'-document gepubliceerd door RIPE NCC.

Kennis, ervaring en ondersteuning voor IPv6 zijn breed beschikbaar bij leveranciers en dienstverleners.

Investeringen in en de overstap naar IPv6 zijn risicoloos wat de technologie betreft.

Jazeker: alle gangbare operating systems ondersteunen IPv6, zowel open source als proprietary.

Ook alle gangbare netwerkmanagementsoftware en -tools ondersteunen IPv6. Dat geldt ook voor provider platforms als Plesk, cPanel en DirectAdmin.

Gedetailleerde (functionele) eisen met betrekking tot de ondersteuning van IPv6 in netwerkapparatuur vind je onder andere in RFC 8504 (BCP 220), en in het 'ripe-772'-document gepubliceerd door RIPE NCC.

Kennis, ervaring en ondersteuning voor IPv6 zijn breed beschikbaar bij leveranciers en dienstverleners.

Investeringen in en de overstap naar IPv6 zijn risicoloos wat de technologie betreft.

Vrijwel alle applicatiesoftware met een netwerkcomponent ondersteunt inmiddels IPv6. Is dat niet het geval, dan raden wij je aan om bij de leverancier (nog eens) aan te dringen op IPv6-ondersteuning. De informatie in deze FAQ kan daarbij wellicht bij helpen. In het uiterste geval moet je overstappen op een ander pakket, als dat tot de mogelijkheden behoort.

Kennis, ervaring en ondersteuning voor IPv6 zijn breed beschikbaar bij leveranciers en dienstverleners.

Investeringen in en de overstap naar IPv6 zijn risicoloos wat de technologie betreft.

Alle gangbare netwerkserversoftware ondersteunt inmiddels IPv6. Het kan wel zijn dat je IPv6 (naast IPv4) apart moet aanzetten en configureren in de configuratiebestanden van het betreffende pakket.

Kennis, ervaring en ondersteuning voor IPv6 zijn breed beschikbaar bij leveranciers en dienstverleners.

Investeringen in en de overstap naar IPv6 zijn risicoloos wat de technologie betreft.

Wil de beheerder van je server je niet helpen met IPv6, dan raden wij je aan om (nog eens) aan te dringen op IPv6-ondersteuning. De informatie in deze FAQ kan daarbij wellicht bij helpen. In het uiterste geval moet je overstappen naar een andere leverancier, als dat tot de mogelijkheden behoort.

Kennis, ervaring en ondersteuning voor IPv6 zijn breed beschikbaar bij leveranciers en dienstverleners.

Investeringen in en de overstap naar IPv6 zijn risicoloos wat de technologie betreft.

Voor (virtuele) servers in de cloud geldt in principe hetzelfde als voor servers in eigen beheer: alle gangbare netwerkserversoftware ondersteunt inmiddels IPv6. Het kan wel zijn dat IPv6 (naast IPv4) apart aangezet en geconfigureerd moet worden in de configuratiebestanden van het betreffende pakket.

Wil de provider van je server je niet helpen met IPv6, dan raden wij je aan om (nog eens) aan te dringen op IPv6-ondersteuning. De informatie in deze FAQ kan daarbij wellicht behulpzaam zijn. In het uiterste geval moet je overstappen naar een andere provider, als dat tot de mogelijkheden behoort.

Kennis, ervaring en ondersteuning voor IPv6 zijn breed beschikbaar bij leveranciers en dienstverleners.

Investeringen in en de overstap naar IPv6 zijn risicoloos wat de technologie betreft.

Naast de standaard netwerk-utilities (denk aan ping6 en traceroute6), zijn er ook allerlei online tools voor het testen van IPv6 beschikbaar. We raden je de Internet.nl-portal van harte aan: alle 3 de tests (voor je webdomein, je maildomein en je internetverbinding) nemen ook de ondersteuning van IPv6 mee.

2 testportals die zich specifiek op IPv6 richten zijn ip.bieringer.net en ipv6-test.com.

Alle generieke IPv6-adressen worden in principe gerouteerd (behalve de Link-Local en ULA-adressen). Dit in tegenstelling tot de veelgebruikte private IPv4-adresreeksen achter een NAT-gateway.

Dat betekent dat je de interne routering van alle IPv6-adressen binnen je netwerk strikt moet vastleggen, want je wilt niet dat intern verkeer onbedoeld door 2 firewalls heen buitenom over het publieke internet loopt. Bovendien zijn intern en extern verkeer (voor de mens) bij IPv6 minder goed van elkaar te onderscheiden dan bij het gebruik van de private IPv4-adresreeksen.

Kortom: zonder NAT neemt het belang van firewalls en screening routers weer toe. En ook de traditionele demilitarized zone (DMZ) wordt weer in ere hersteld; interne adressen worden niet geadverteerd of extern gerouteerd, maar zijn alleen via proxy’s benaderbaar. Hetzelfde geldt voor verbindingen die van binnen naar buiten worden opgezet.

Ander punt is dat de IPv6-adresruimte zo groot is dat het blokkeren van individuele adressen (blacklisting/whitelisting) bij misbruik niet meer mogelijk is (alleen op basis van prefixes). Dat betekent dat filteren straks meer op de reputatie van een domeinnaam plaatsvindt.

Security- en privacy-overwegingen met betrekking tot adrestoekenning worden besproken in RFC 7721.

De operationele beveiligingsaspecten van IPv6 bespreken we in dit artikel.

Omdat interface identifiers onder SLAAC direct zijn afgeleid van het min-of-meer unieke MAC-adres van de betreffende interface, kunnen deze adressen gebruikt worden om het online-gedrag van gebruikers en de locatie van mobiele devices te volgen. Deze identifiers blijven immers gelijk zelfs als de network-prefix verandert.

De Privacy Extensions voor SLAAC gaan dit tegen door bijvoorbeeld dagelijks een tijdelijk (random) adres te genereren. Eerdere tijdelijke adressen blijven in dit voorbeeld nog een dag langer werken voor binnenkomend verkeer. De status van een tijdelijk adres verandert dan van 'preferred' naar 'deprecated' naar uiteindelijk 'invalid'.

RFC 7217 formuleert een alternatief voor deze tijdelijke adressen. Daarbij worden random interface identifiers gegenereerd en bijgehouden per interface en subnet. Op die manier blijven de IPv6-adressen wel constant per netwerk (prefix) maar zijn ze niet op basis van hun interface-identifier aan elkaar te koppelen.

RFC 8064 raadt het gebruik van hardware-afhankelijke SLAAC-adressen af en beveelt in plaats daarvan het gebruik van IPv6-adressen volgens bovenstaande methode (RFC 7217) aan.

Security- en privacy-overwegingen met betrekking tot adrestoekenning worden besproken in RFC 7721.

We bespreken de privacyaspecten van IPv6 ook in dit artikel.

Het breed instellen van de Privacy Extensions voor SLAAC voor je gebruikers doe je met behulp van netwerkmanagement-software – denk aan IPAM en DHCPv6. Op individuele computersystemen doe je dit in het configuratiescherm voor de netwerkinstellingen.

Behalve voor alle IP-adres-gebaseerde security-gereedschappen (denk aan blacklisting/whitelisting en reputatie-management) levert IPv4 in combinatie met CGNAT ook problemen op voor opsporingsdiensten. Zo liet Europol al in 2017 weten dat access providers die CGNAT inzetten technisch vaak niet meer aan hun wettelijke verplichting kunnen voldoen om de abonneegegevens achter een verbinding aan te leveren. Daardoor moeten volgens de dienst bij onderzoeken regelmatig de verbindingen van veel meer mensen dan eigenlijk noodzakelijk is worden opgevraagd of afgetapt.

Omstreeks dezelfde tijd publiceerde de Europese Commissie de brief 'Resilience, Deterrence and Defence: Building strong cybersecurity for the EU', waarin zij beschreef hoe zij de adoptie van IPv6 wilde stimuleren. Doel was om uiteindelijk maar één gebruiker per IP-adres te hebben om zo onderzoek door politie- en veiligheidsdiensten veel gerichter te kunnen uitvoeren. Daarvoor zou de Commissie gebruikmaken van aanbestedingsbeleid, onderzoeks- en projectfinanciering, en convenanten. Lidstaten zouden daarvoor ook (niet-dwingende) convenanten moeten afsluiten met hun access providers.

Hier in Nederland publiceerde het Wetenschappelijk Onderzoek- en Documentatiecentrum (WODC), de onderzoekstak van het Ministerie van Justitie en Veiligheid, in 2019 een onderzoek naar de identificatie van individuele gebruikers van IP-adressen ten behoeve van opsporing en vervolging (onderdeel van de Wet bewaarplicht telecommunicatiegegevens). Ook daarin wordt de brede adoptie van IPv6 als de meest voor de hand liggende oplossing aangedragen.

Hoewel je als eindgebruiker vanuit privacyoverwegingen bezwaren kunt hebben tegen het gebruik van IPv6 – wat dat betreft biedt CGNAT onbedoeld een zekere bescherming, enigszins vergelijkbaar met het gebruik van een VPN-provider – stellen de onderzoekers zich op het standpunt dat IPv6 in dit geval juist een privacy-voordeel oplevert. Gebruikers die niet gericht onderzocht worden kunnen dan immers buiten beschouwing worden gelaten. Afgezien van technische en zakelijke overwegingen maakt IPv6 het voor access providers sowieso veel makkelijker om aan hun compliance-eisen te voldoen dan dat nu met CGNAT het geval is.

Als eindgebruiker ben je voor een IPv6-adresreeks (bestaande uit miljarden adressen) afhankelijk van je accessprovider of netwerkbeheerder. Helaas bieden veel providers en bedrijven in Nederland op dit moment nog steeds geen IPv6 aan voor hun klanten en gebruikers. Gelukkig hebben de 2 grootste Nederlandse access providers, KPN en Ziggo (onderdeel van VodafoneZiggo), de afgelopen jaren grote stappen gemaakt. Kleinere providers en netwerkbeheerders lijken echter stil te staan. Uitzonderingen daarop zijn Freedom Internet, SURF, de Universiteit Twente en Zeelandnet (onderdeel van Delta). Deze partijen staan erom bekend voorop te lopen waar het de invoering van nieuwe technologie betreft en zijn al langer met IPv6 bezig; voor hen is de inzet van de laatste technologie ook expliciet onderdeel van hun waardepropositie.

Als je accessprovider of netwerkbeheerder IPv6 ondersteunt, heb je goede kans dat dit automatisch is aangezet. Is dat niet het geval, dan raden wij je aan om contact op te nemen met je provider of beheerder.

Kan of wil je provider of beheerder je niet helpen met IPv6, dan raden wij je aan om (nog eens) aan te dringen op IPv6-ondersteuning. De informatie in deze FAQ kan daarbij wellicht bij helpen. In het uiterste geval moet je overstappen naar een andere provider, als dat tot de mogelijkheden behoort.

Jazeker: als je accessprovider of netwerkbeheerder IPv6 wel ondersteunt maar dit nog niet voor je heeft aangezet, kan je provider of beheerder dit op verzoek voor je doen.

Kan of wil je provider of beheerder je niet helpen met IPv6, dan raden wij je aan om (nog eens) aan te dringen op IPv6-ondersteuning. De informatie in deze FAQ kan daarbij wellicht bij helpen. In het uiterste geval moet je overstappen naar een andere provider, als dat tot de mogelijkheden behoort.

Kan of wil je provider of beheerder je niet helpen met IPv6, dan raden wij je aan om (nog eens) aan te dringen op IPv6-ondersteuning. De informatie in deze FAQ kan daarbij wellicht bij helpen. In het uiterste geval moet je overstappen naar een andere provider, als dat tot de mogelijkheden behoort.

Naast de standaard netwerk-utilities (denk aan ping6 en traceroute6), zijn er ook allerlei online tools voor het testen van IPv6 beschikbaar. We raden je de Internet.nl-portal van harte aan: alle 3 de tests (voor je webdomein, je maildomein en je internetverbinding) nemen ook de ondersteuning van IPv6 mee.

2 testportals die zich specifiek op IPv6 richten zijn ip.bieringer.net en ipv6-test.com.

Alle generieke IPv6-adressen worden in principe gerouteerd (behalve de Link-Local en ULA-adressen). Dit in tegenstelling tot de veelgebruikte private IPv4-adresreeksen achter een NAT-gateway. Dat betekent dat je bij het gebruik van IPv6 extra aandacht zult moeten besteden aan je firewalls (zowel op je internetrouter als je individuele systemen).

Omdat interface-identifiers onder SLAAC direct zijn afgeleid van het min-of-meer unieke MAC-adres van de betreffende interface, kunnen deze adressen gebruikt worden om het online-gedrag van gebruikers en de locatie van mobiele devices te volgen. Deze identifiers blijven immers gelijk zelfs als de network-prefix verandert.

De Privacy Extensions voor SLAAC gaan dit tegen door bijvoorbeeld dagelijks een tijdelijk (random) adres te genereren. Eerdere tijdelijke adressen blijven in dit voorbeeld nog een dag langer werken voor binnenkomend verkeer. De status van een tijdelijk adres verandert dan van 'preferred' naar 'deprecated' naar uiteindelijk 'invalid'.

RFC 7217 formuleert een alternatief voor deze tijdelijke adressen. Daarbij worden random interface-identifiers gegenereerd en bijgehouden per interface en subnet. Op die manier blijven de IPv6-adressen wel constant per netwerk (prefix) maar zijn ze niet op basis van hun interface-identifier aan elkaar te koppelen.

RFC 8064 raadt het gebruik van hardware-afhankelijke SLAAC-adressen af en beveelt in plaats daarvan het gebruik van IPv6-adressen volgens bovenstaande methode (RFC 7217) aan.

Het breed instellen van de Privacy Extensions voor SLAAC doe je in de meeste gevallen op je internetrouter. Op je individuele computersystemen doe je dit in het configuratiescherm voor de netwerkinstellingen.

Als LAN-beheerder ben je voor een IPv6-adresreeks (bestaande uit miljarden adressen) afhankelijk van je (zakelijke) accessprovider. Om je netwerk(en) van IPv6 te voorzien, raden we je dan ook aan om contact op te nemen met je provider.

Kan of wil je provider je niet helpen met IPv6, dan raden wij je aan om (nog eens) aan te dringen op IPv6-ondersteuning. De informatie in deze FAQ kan daarbij wellicht bij helpen. In het uiterste geval moet je overstappen naar een andere provider, als dat tot de mogelijkheden behoort.

IPv6 is er op ontworpen om de toekenning van adressen zo veel mogelijk automatisch uit te voeren. Dat betekent dat interface-identifiers automatisch gegenereerd worden (middels SLAAC) en dat prefixes zo veel mogelijk op router-niveau beheerd worden. Daarmee zou bijvoorbeeld het omnummeren van complete netwerken relatief eenvoudig moeten zijn (als besproken in RFC 7010), omdat daarvoor alleen de geadverteerde prefixes aangepast hoeven worden.

Om ook je subnetwerken van IPv6 te voorzien hoef je dus alleen een sub-prefix in te stellen op de router voor het betreffende netwerksegment. De routers in je netwerk wisselen die informatie onderling uit, waarmee IPv6 in een keer voor een heel segment beschikbaar komt.

Hieronder zie je hoe de 'prefix delegation'-instellingen er op de FRITZ!Box 7590 uitzien (Home Network → Network → Network Settings → Additional Settings → IPv6 Settings):

Naast de standaard netwerk-utilities (denk aan ping6 en traceroute6), zijn er ook allerlei online tools voor het testen van IPv6 beschikbaar. We raden je de Internet.nl-portal van harte aan: alle 3 de tests (voor je webdomein, je maildomein en je internetverbinding) nemen ook de ondersteuning van IPv6 mee.

2 testportals die zich specifiek op IPv6 richten zijn ip.bieringer.net en ipv6-test.com.

Alle generieke IPv6-adressen worden in principe gerouteerd (behalve de Link-Local en ULA-adressen). Dit in tegenstelling tot de veelgebruikte private IPv4-adresreeksen achter een NAT-gateway. Dat betekent dat je bij het gebruik van IPv6 extra aandacht zult moeten besteden aan de firewalls (zowel op de internet-gateway als de individuele systemen).

Security- en privacy-overwegingen met betrekking tot adrestoekenning worden besproken in RFC 7721.

De operationele beveiligingsaspecten van IPv6 bespreken we in dit artikel.

Omdat interface-identifiers onder SLAAC direct zijn afgeleid van het min-of-meer unieke MAC-adres van de betreffende interface, kunnen deze adressen gebruikt worden om het online-gedrag van gebruikers en de locatie van mobiele devices te volgen. Deze identifiers blijven immers gelijk zelfs als de network prefix verandert.

De Privacy Extensions voor SLAAC gaan dit tegen door bijvoorbeeld dagelijks een tijdelijk (random) adres te genereren. Eerdere tijdelijke adressen blijven in dit voorbeeld nog een dag langer werken voor binnenkomend verkeer. De status van een tijdelijk adres verandert dan van 'preferred' naar 'deprecated' naar uiteindelijk 'invalid'.

RFC 7217 formuleert een alternatief voor deze tijdelijke adressen. Daarbij worden random interface identifiers gegenereerd en bijgehouden per interface en subnet. Op die manier blijven de IPv6-adressen wel constant per netwerk (prefix) maar zijn ze niet op basis van hun interface identifier aan elkaar te koppelen.

RFC 8064 raadt het gebruik van hardware-afhankelijke SLAAC-adressen af en beveelt in plaats daarvan het gebruik van IPv6-adressen volgens bovenstaande methode (RFC 7217) aan.

Security- en privacy-overwegingen met betrekking tot adrestoekenning worden besproken in RFC 7721.

We bespreken de privacyaspecten van IPv6 ook in dit artikel.

Het breed instellen van de Privacy Extensions voor SLAAC voor je gebruikers doe je in de meeste gevallen op de internet-gateway. Op individuele computersystemen doe je dit in het configuratiescherm voor de netwerkinstellingen.

Voor onze registrars hebben we 2 e-learning-modules voor IPv6 beschikbaar. Daarnaast publiceren we regelmatig nieuwsberichten, technische artikelen, rapporten en cases over IPv6 op sidn.nl.

Meer informatie

• Internet Society (ISOC): IPv6 https://www.internetsociety.org/deploy360/ipv6/ https://www.internetsociety.org/issues/ipv6/

• ARIN: IPv6 Information: https://www.arin.net/resources/guide/ipv6/

Statistieken

• RIPE NCC: IPv6 Enabled Networks http://v6asns.ripe.net/v/6

• IPv6-Enabled Web Browsers: https://www.vyncke.org/ipv6status/compare.php?metric=p&countries=be,de,us,lu,nl

• AAAA and IPv6 connectivity statistics of top websites according to Alexa: https://www.employees.org/~dwing/aaaa-stats/

• IPv6 Deployment Aggregated Status: https://www.vyncke.org/ipv6status/

• Global IPv6 Deployment Progress Report: https://bgp.he.net/ipv6-progress-report.cgi

• ipv6-overview.xyz: https://ipv6-overview.xyz/

Implementatie

• Guidelines and Process: IPv6 for Public Administrations in Europe: https://joinup.ec.europa.eu/collection/egovernment/document/guidelines-and-process-ipv6-public-administrations-europe

• A Short IPv6 Guide for Home IPv4 Admins

Tools

• address calculator voor IPv4 en IPv6: http://silmor.de/ipaddrcalc.html

• of de command line tool sipcalc: http://www.routemeister.net/projects/sipcalc/index.html

• Internet.nl: tests voor (onder andere) IPv6 voor je webdomein, maildomein en internetverbinding: https://www.internet.nl/

• IPv6 domain readiness tester: https://ip6.nl/

• ip.bieringer.net: https://ip.bieringer.net/

• IPv6-test.com: https://ipv6-test.com/

• IPv6 health check: https://www.mythic-beasts.com/ipv6/health-check

• Is your site IPv6 ready? https://ready.chair6.net/

• What is my IP Address? http://ip6.me/

• Test your Happy Eyeballs: http://he.test-ipv6.com/