Zijn we klaar om IPv4 uit te schakelen?

Op de RIPE 67 bijeenkomst in Athene, deed de RIPE IPv6-werkgroep een klein experiment om de haalbaarheid van een ‘IPv6-only’ netwerk te testen en om de uitdagingen in gebruikservaring te identificeren. Hoewel de resultaten zeer bemoedigend waren, gaven ze ook aan dat er nog veel werk moet worden verzet voordat IPv4 eens en voor altijd kan worden uitgeschakeld.

Nu IPv6 langzaam maar zeker over de hele wereld wordt uitgerold, zijn we in een fase beland waarin het voor je apparaten nodig is om met behulp van één van de twee IP-protocollen die momenteel in gebruik zijn te communiceren. Genaamd dual-stack, waarmee een apparaat op het zelfde moment gebruik maakt van zowel een actief IPv4- als IPv6-adres. Zodra IPv6 voldoende is uitgerold, is het idee dat we uiteindelijk IPv4 helemaal uitschakelen en daarbij overgaan op een internet dat onbeperkt kan groeien – het IPv6-only internet.

Wereldwijd is IPv4 aan het opraken – de beschikbare IP-adres reeksen van de Regionale Internet registries (RIR’s) in Europa, het Midden-Oosten, Azië en de Pacific (met Noord- en Zuid-Amerika niet ver achter) zijn uitgeput. De vraag naar IPv4 zal alleen maar toenemen naar mate het internet groter wordt. Dit zal het gebruik van IP-adres deel-protocollen zoals Carrier Grade NAT (CGN) noodzakelijk maken. Dit is kostbaar te implementeren en kan resulteren in een gecompromitteerde ervaring voor klanten: een onvermogen om verbindingen tot stand te brengen achter de vertaler, het falen van apparaten die afhankelijk zijn van rijke connectiviteit en de mogelijke afname van de prestaties.

IPv4 behouden is op de lange termijn geen haalbare optie. Een gedurfd alternatief zou zijn om in één keer een ​​IPv6-only netwerk uit te rollen, maar de grote vraag is dan of een dergelijke oplossing een goede gebruikservaring biedt. Dit is wat we wilden ontdekken met ons tijdelijke netwerk op RIPE 67.

Uiteraard zou het uitrollen van een IPv6-only netwerk een hoop websites onbereikbaar maken, aangezien ze IPv6 nog niet hebben geïmplementeerd. Om onze gebruikers deze diensten wel te laten bereiken, hebben we NAT64 ingezet (een vorm van Network Address Translation). Met behulp van deze techniek worden systemen wijs gemaakt te geloven dat een site of dienst beschikbaar is via IPv6 – zelfs als dat niet zo is. Een router aan de rand van het netwerk onderschept IPv6-verbindingen en zet ze om in IPv4, met behulp van een kleine reeks van gedeelde IPv4-adressen.

Terwijl NAT64 alle gebruikelijke beperkingen van IPv4-adres deel-technieken kent, geeft het gebruikers, dienstverleners of applicaties ook de mogelikheid om te werken met behulp van het IPv6-protocol. En naar mate IPv6 verder wordt uitgerold, daalt de vraag naar deze vertaling met de tijd (in plaats van te verhogen in het geval van IPv4 CGNs).

Tijdens het experiment dat een week duurde, gebruikten meer dan 40 mensen (10 % van RIPE 67 deelnemers) ons IPv6-only netwerk . Afgezien van een kleine verstoring veroorzaakt door een defecte kabel, draaide het netwerk vlot en met vergelijkbare prestaties ten opzichte van de dual-stacked netwerken die de RIPE NCC verstrekt . Over het experimentele netwerk was de feedback van gebruikers zeer positief. Sommige mensen gaven zelfs toe dat ze niet wisten dat ze de hele dag van het experimentele netwerk gebruikmaakten .

Er waren echter een aantal problemen met de client software. In het bijzonder toepassingen op smartphones en tablets. Terwijl connectiviteit prima werkte voor eenvoudige toepassingen zoals web browsing of e-mail, bleken een heleboel speciale toepassingen expliciet te testen op de aanwezigheid van een IPv4-adres. Bij het niet daarvan, werd er aangenomen dat er geen netwerkconnectiviteit was en werd dit gemeld als een fout of werd overgeschakeld naar de offline-modus. We vonden ook een aantal interactieve web-based applicaties die probeerde verbindingen in de achtergrond op te zetten en daarbij uit gingen van een IPv4-adres voor het volgen van de sessie of authenticatie.

Hoewel deze problemen niet ernstig waren en vaak omzeild konden worden, vergroten ze de kans dat gebruikers gaan bellen met de klantenservice, waardoor de opstelling in ons experiment niet geschikt is voor grootschalige implementaties bij de consument. Ondanks aanhoudende inspanningen om er bij softwareontwikkelaars op aan te dringen niet alleen ondersteuning voor IPv6 in te bouwen in hun producten en te zorgen dat ze correct functioneren in een IPv6-omgeving, is het onwaarschijnlijk dat deze problemen binnen afzienbare tijd verdwenen zijn.

Daarom heeft de IETF een alternatief ontwikkeld voor de NAT64-translatie die we gebruikten tijdens RIPE 67, namelijk: 464XLAT. Gebaseerd op dezelfde principes van het vertalen van IPv6 in IPv4-gebaseerde verbindingen, vertrouwt deze techniek op een kleine wijziging van het client-besturingssysteem . Dit zal ervoor zorgen dat elke toepassing die vertrouwt op een IPv4-adres, voor de juiste werking IPv4 beschikbaar zal hebben. Deze toepassingen zijn gemaakt om te geloven dat een volledig functionerend IPv4-netwerk beschikbaar is, terwijl op de achtergrond alle aansluitingen zijn vertaald en gebruik maken van het IPv6-protocol.

Verschillende smartphone-fabrikanten maken 464XLAT beschikbaar in hun producten. Het wordt ook gebruikt door een grote Amerikaanse telecomprovider, die het inzet voor de miljoenen gebruikers op haar 4G-netwerk. Dit bewijst dat, terwijl een zorgvuldige planning en het testen nog steeds nodig is, het in sommige gevallen mogelijk is om IPv4 in access netwerken uit te schakelen zonder dat het een effect heeft op de performance van het netwerk of een toenemende vraag voor support.

Dual-stack blijft de voorkeursoplossing. Echter, als je een keuze moet maken, waarom kies je dan niet voor een IPv6-only omgeving? Dit zou ervoor zorgen dat jouw netwerk klaar is voor de toekomst en tegelijkertijd waardevolle IPv4-bronnen vrij kan implementeren waar IPv6-ondersteuning nog een ‘feature request’ is.

En als je software of applicaties ontwikkeld – is het zaak niet alleen zo spoedig mogelijk IPv6-support in te bouwen,  maar er ook zorg voor te dragen dat jouw product correct werkt bij de afwezigheid van een werkende IPv4-verbinding.


Marco Hogewoning is Technisch Adviseur bij RIPE NCC.

Dit artikel verscheen 13 december 2013 (in het Engels) op RIPE Labs en is met toestemming van de auteur op ISP Today gepubliceerd.

Over Marco Hogewoning

Laatste artikelen