Zo'n 15 jaar geleden zei ik regelmatig dat het feit dat zo goed als niemand aandacht besteedde aan de invoering van IPv6 betekende dat rond 2020 IPv6 ofwel het grootste technologie-debakel ofwel de grootste technologie-triomf ooit zou zijn. Debakel als na de enorme inspanning van de internet-industrie IPv6-adoptie nog altijd 0% zou zijn, triomf als 100% van de aan het internet verbonden apparaten de upgrade naar IPv6 gekregen had zonder dat de gebruikers het merkten. Destijds kon het nog beide kanten opgaan.
Vervolgens zagen we twee weken geleden in De opkomst van IPv6 en ondergang van IPv4 in de jaren 2010 dat op dit moment zo'n 25 tot 30 % van het internet IPv6-connectiviteit heeft. Dus het binaire "0% IPv6 = gefaald, 100% IPv6 = succes" is het niet geworden. Tot nu toe, in elk geval. Dus: geven we IPv6 nog (flink wat?) tijd om die 100% te bereiken zodat we van een succes kunnen spreken, of kiezen we andere succescriteria?
Maar laten we eerst eens kijken naar de vooruitzichten voor 100% IPv6-adoptie. De Google statistieken laten zien dat IPv6-adoptie vanaf begin 2016 ieder jaar met zo'n 5% gestegen is. In dit tempo zouden we in 2034 100% IPv6-adoptie moeten bereiken. Echter, adoptie van nieuwe technologie volgt gewoonlijk niet een rechte lijn. Volgens innovatietheorie van Rogers gaat dit volgens een S-curve:
Volgens deze theorie kunnen we verwachten dat IPv6-adoptie op een gegeven moment vertraagt. In 2017 legde APNIC's George Michaelson een S-curve over Google's statistieken en concludeerde dat we in 2022 op 80% IPv6-adoptie zouden zitten. We hebben ondertussen echter de voorspelde 40% voor 2020 met ruim 10% gemist. In een daarop volgend artikel uit 2019 concludeert hij dat het verhaal zowel duidelijker als minder duidelijk geworden is.
En vorig jaar modelleerde Christofer Flinta van Ericsson Research IPv6-adoptie en stelde vast dat "het model een verrassend laag uiteindelijk niveau van IPv6-adoptie voorspelt op maar zo'n 28%". Google ziet op dit moment in de weekeinden zo'n 30% IPv6 en doordeweeks maar zo'n 25%, dus we zitten nog 3% onder de voorspelde 28%.
Dus gebaseerd op de cijfers kan de 100%-IPv6-datum vallen op ieder moment tussen 2027 en wanneer de kalveren op het ijs dansen. Aan de andere kant is voorspellen lastig , en er zijn maar weinig mensen die nog IPX of AppleTalk of andere netwerkprotocollen die populair waren in de jaren '80 en '90 runnen. (En van IPv4 naar IPv6 migreren is een fluitje van een cent vergeleken met van IPX of AppleTalk naar IPv4 migreren.)
IPv6 is in veel opzichten superieur aan IPv4. Maar niet in zo'n mate dat het de moeite waard is om IPv4 door IPv6 te vervangen voor mensen die nu beschikken over IPv4-connectiviteit die goed werkt. Zelfs IPv6 toevoegen aan IPv4 is niet economisch rendabel voor degenen met goede IPv4. Dezelfde apparatuur runt zowel IPv4 als IPv6, maar er is wel extra complexiteit die komt kijken bij het runnen van een extra protocol en de interactie tussen de twee protocollen.
Zodoende is het bij (alleen) IPv4 houden volkomen logisch, afgezien van een klein probleempje: we hebben niet genoeg IPv4-adressen. Maar: IP-adressen zijn geen gebruiksgoed; de IPv4-adressen die je al hebt blijven gewoon werken. De problemen komen pas wanneer er meer adressen nodig zijn omdat een enterprise-netwerk meer apparaten aansluit of een serviceprovider nieuwe aansluitingen realiseert.
De IPv4-wereld de rug toekeren is vooralsnog geen optie, gezien het feit dat IPv4 alle content heeft en IPv6 maar ongeveer een kwart. Dus op plaatsen waar IPv4-adressen schaars worden door groei moeten er IPv4-adressen gedeeld worden. Dat is niet nieuw: nagenoeg alle consumenten hebben meerdere internet-verbonden apparaten, maar ze krijgen maar één publiek IPv4-adres van hun ISP. De thuisrouter snijdt dit IPv4-adres in plakjes door middel van Network Address Translation (NAT) zodat meerdere systemen in het huis dat adres kunnen delen. Dit werkt prima voor communicatie die aan de binnenkant geïnitieerd wordt en dan naar buiten gaat, want de NAT zag de uitgaande pakketten en weet dus naar welk systeem hij de corresponderende inkomende pakketten moet doorsturen.
NATs maken wel inkomende (van buitenaf gestarte) communicatie moeilijker, omdat ze dan niet weten welk systeem de betreffende pakketten moet krijgen. Wanneer dit firewall-achtige bijeffect van NAT niet gewenst is kan daar omheen gewerkt worden door de thuisrouter te vertellen welk systeem systeem de ontvanger van de inkomende communicatie moet zijn.
Wanneer ISPs niet langer elke abonnee een eigen IPv4-adres kunnen geven omdat ze onvoldoende IPv4 hebben is het een optie om zelf een grote NAT neer te zetten (vaak Carrier Grade NAT, CGN, genoemd). Alleen maakt dat inkomende communicatie een stuk moeilijker. Weinig gebruikers willen of moeten een server runnen, maar inkomende communicatie is ook nodig voor peer-to-peer applicaties, waaronder IP-telefonie en vooral videochat zoals Facetime.
Een ander probleem met NAT in het ISP-netwerk is dat al het verkeer door de NAT heen moet. Dus wanneer de hoeveelheid verkeer groeit betekent dat meer of grotere NATs aanschaffen.
De problemen die NAT oplevert worden een heel stuk minder door het toevoegen van IPv6. Als een gebruiker IPv6 heeft dan kan hij of zij peer-to-peer communicatie met andere NAT+IPv6 gebruikers over IPv6 afhandelen. En bij peer-to-peer communicatie met een IPv4-gebruiker kan de verbinding vanaf de NAT+IPv6-gebruiker naar de IPv4-gebruiker opgezet worden zodat de NAT aan de NAT+IPv6-kant geen problemen oplevert.
NAT+IPv6 heeft ook minder NAT-capaciteit nodig omdat de NAT+IPv6-gebruiker een deel van haar of zijn communicatie afhandelt over IPv6, en dit IPv6-verkeer gaat niet door de NAT. En nog beter: wanneer meer en meer diensten beschikbaar komen over IPv6 dan kan de hoeveelheid verkeer die door de NAT gaat zelfs omlaag gaan. In elk geval is de NAT-capaciteit die nodig is voor NAT+IPv6-gebruikers altijd minder dan voor NAT-zonder-IPv6-gebruikers.
Het is algemeen bekend dat alle technologie-problemen als sneeuw voor de zon verdwijnen door "aaS" achter een acroniem te plakken. Het is natuurlijk mogelijk om een NAT+IPv6-dienst te leveren door gebruikers publieke IPv6 en private IPv4 te geven, en dan de private IPv4 te vertalen naar publieke IPv4 door middel van een CGN. Maar dat betekent wel dat er drie netwerken naast elkaar bestaan: IPv6, publiek IPv4 en privaat IPv4.
Een overzichtelijker alternatief: we geven de abonnee alleen IPv6, en voorzien dan in een vertaalde (NAT64) of getunnelde (DS-Lite) IPv4-dienst over die IPv6-connectiviteit. Op deze manier ziet het netwerk geen IPv4-pakketten met private adressen die voor verwarring kunnen zorgen. Na verloop van tijd zullen sommige ISPs waarschijnlijk zelf niet meer die vertaalde IPv4-dienst willen draaien en dit outsourcen naar een gespecialiseerde "IPv4aaS"-aanbieder.
Wanneer IPv6+IPv4aaS-gebruikers naar websites gaan die alleen over IPv4 bereikbaar zijn betekent dit dat een NAT64 of een DS-Lite CGN dit verkeer moet vertalen. Geen probleem, daar is-ie voor. Doorsnee web-verkeer is niet zo veel. Maar wat als diezelfde gebruiker video begint te kijken? Dat is minstens een megabit of twee, en kan oplopen naar 15 of zelfs 25 Mbps, en dit duurt dan vele minuten tot zelfs uren.
Zodoende is het voor een ISP met IPv6+IPv4aaS-gebruikers veel beter wanneer die gebruikers hun video bekijken op streamingdiensten die IPv6 hebben, zoals Netflix. Wanneer gebruikers video streamen van een dienst die alleen over IPv4 bereikbaar is, zoals Disney+ (in december 2019, in elk geval), dan moeten die enorme hoeveelheden verkeer vertaald worden, wat meer hardware en meer IPv4-adressen kost.
Gewoonlijk hebben zowel content-aanbieders als ISPs er baat bij om een directe netwerkverbinding op te zetten ("peering"). Dat scheelt beide partijen kosten en zorgt voor een optimale dienstverlening aan de gebruiker. ISPs stellen wel vaak eisen voor ze willen peeren. Het is logisch dat in de toekomst ISPs gaan eisen dat diensten die veel verkeer genereren beschikbaar zijn over IPv6 om te willen peeren.
Of misschien breiden ze hun NAT64/CGN-capaciteit niet zo snel uit als dat het verkeer groeit, zodat vertaalde IPv4 last krijgt van vertragingen terwijl IPv6 wel snel is. Zelfs als ze dat niet doen is het waarschijnlijk dat IPv6 beter presteert omdat routers een direct pad kunnen kiezen van de gebruiker naar de buitenwereld. Tenzij de NAT64/CGN zich op dat directe pad bevindt zal de IPv4-route langer zijn dan de IPv6-route en dus (een beetje) trager.
Via deze omweg zullen aldus de mensen die last hebben van gebrek aan IPv4-adressen deze pijn doorgeven aan degenen die hier zelf geen last van hebben, en ze op deze manier een reden geven om ook te upgraden.
Gebaseerd op het bovenstaande kunnen we concluderen dat de komende jaren twee groepen IPv6 zullen invoeren: ISPs met een snelgroeiend abonneebestand en grote content-aanbieders. We zien nu al dat veel mobiele netwerken op grote schaal NAT64 toepassen, wat makkelijk kan omdat moderne telefoons goed werken met NAT64. Daarnaast kunnen de betreffende netwerken makkelijk NAT64 aan gebruikers van deze nieuwere telefoons geven en IPv4 (met NAT) aan gebruikers van andere telefoons.
Voor nieuw een enterprise-netwerk kan het voordelen hebben om het IPv6+IPv4aaS-model toe te passen, hoewel ze wellicht hardware of software zullen tegenkomen die niet werkt met een IPv6-only enterprisenetwerk. Voor bestaande enterprisenetwerken is het al duur en complex om IPv6 alleen maar toe te voegen, laat staan IPv4 te verwijderen. Het is dus onwaarschijnlijk dat veel enterprisenetwerken IPv6 gaan adopteren, behalve misschien de netwerken van organisaties die zo groot zijn dat ze gebrek aan private IPv4-adressen hebben.
Het internet is nu niet langer een IPv4-only netwerk. IPv6 doet waar het voor ontworpen is: verdere groei van het internet mogelijk maken nu IPv4 niet langer in staat is die groei te faciliteren zoals voorheen. Succes! Maar de komende tijd is er nog geen business case te maken voor een volledig-IPv6 internet... IPv4 gaat waarschijnlijk nog zijn 50e verjaardag meemaken in 2031.
23 januari 2020, door Iljitsch van Beijnum.
