Dual-stack en IPv6-only vormen snelste weg naar IPv6

De belangrijkste reden voor deze netwerk-intensieve ondernemingen om naar IPv6-only te gaan is vanzelfsprekend het opraken van de IPv4-adressen. Maar dit argument blijkt aanzienlijk ingewikkelder dan alleen de beschikbaarheid van publieke (dat wil zeggen: routeerbare) IPv4-adressen. Zo heeft de IT-afdeling van Microsoft al zijn IPv4-adressen al in 2011 over moeten dragen aan de Azure-groep. De systemen en diensten van hun externe klanten (in de cloud) moeten immers allemaal een publiek IPv4-adres hebben om bereikbaar te zijn. Maar zelfs de private 10.0.0.0/8 adresruimte bestaande uit ruim 16 miljoen adressen (in combinatie met NAT44) blijkt dan op termijn niet groot genoeg te zijn om alle interne systemen en gebruikers te kunnen bedienen. De helft van deze adresruimte wordt nu bij Microsoft gebruikt voor de interne systemen op het Azure-netwerk. De andere helft is beschikbaar voor de 220 duizend eigen gebruikers en hun apparatuur. Maar als je weet dat deze gebruikers verspreid zitten over 800 locaties over de hele wereld, dan is 8 miljoen helemaal niet zo veel. Een aanzienlijk deel van die adresruimte gaat immers "verloren" bij de opdeling in praktisch routeerbare subnetwerken.

Niet houdbaar

Routeerbaarheid is ook de reden dat de aankoop van nieuwe IPv4-adressen voor grotere organisaties geen houdbare oplossing is: adressen zijn wel te koop (prijzen schommelen nu rond de 25 dollar per adres) maar alleen in beperkte blokgrootten. Dat maakt de routetabellen langer en het beheer ingewikkelder. Zo gebruikt Microsoft nu verschillende IPv6-prefixen voor verschillende continenten, zodat direct duidelijk is waar een adres thuishoort. Daarnaast is de beschikbaarheid van aaneengesloten blokken voor dit bedrijf van belang om grote gevirtualiseerde testomgevingen op te zetten. Ander probleem bij het gebruik van de gedeelde 10.0.0.0/8 adresruimte is dat dit botsingen oplevert bij de integratie van overgenomen bedrijven. In het ergste geval moet de hele IPv4-infrastructuur van zo'n nieuw onderdeel worden omgenummerd. Carrier-Grade NAT (CGNAT), een tweelaagse NAT zoals nu regelmatig door grote access providers wordt toegepast, wordt voor zo ver ons bekend niet gebruikt door ondernemingen en overheidsorganisaties. Daarmee zou de bereikbaarheid van hun eigen gebruikers immers sterk verslechteren. Hoewel er wel een paar private organisaties zijn die een eigen /8 adresblok toegekend hebben gekregen, was dat zelfs in de begindagen van het moderne internet zeer uitzonderlijk. Op de huidige IPv4-adreslijst van IANA staan nog AT&T, Apple, Ford, PSINet (nu Cogent), Daimler en het Amerikaanse postbedrijf (USPS). Zij hebben hun /8 blok allemaal in de eerste helft van de jaren '90 gekregen.

Uitfasering IPv4

Naast de genoemde problemen van routering en overlap lost IPv6-only (op termijn) nog een ander probleem op: veelgehoord bezwaar is dat een dual-stack infrastructuur leidt tot een dubbele beheerslast – denk ook aan beveiliging en probleemoplossing – met bijbehorende kosten. Het moge duidelijk zijn dat je dit vermijdt door het interne IPv4-netwerk in zijn geheel op te ruimen. Om te zorgen dat je gebruikers nog steeds wel de IPv4-only servers op internet kunnen bereiken, zet je daarbij een 464XLAT gateway in zoals beschreven in dit artikel. Deze opzet zien we met name terug bij grote telecom operators in opkomende landen, die op deze manier tientallen of honderden miljoenen mobiele gebruikers van internettoegang voorzien.

Grootverbruikers

Andere grootverbruikers die voor hun interne netwerken een IPv6-only strategie hebben ingezet zijn Google, Facebook [1, 2] en LinkedIn [1, 2, 3, 4, 5]. Het gaat ons niet om IPv6, maar we willen van IPv4 af, aldus Franck Martin, verantwoordelijk voor de transitie van IPv4 naar IPv6 bij LinkedIn. Nadat alle systemen dual-stack draaien, wordt IPv4 in de loop der tijd uit de organisatie weggebeiteld. Binnen het IPv6 (AAAA)-team van LinkedIn is dat de verantwoordelijkheid van de 'IPv4 disposal experts'. We zien een vergelijkbare aanpak terug bij de IPv6-transities van alle grote organisaties: eerst gaat men van IPv4 naar dual-stack. Daarna wordt alle verkeer naar IPv6 gebracht, waarna IPv4 uitgefaseerd kan worden. Nieuwe systemen en netwerken gaan ondertussen (waar mogelijk) gelijk op IPv6-only.

Software en diensten

Belangrijk aandachtspunt (of sta-in-weg) daarbij is de ondersteuning van IPv6 in software. Bij LinkedIn voorkomen ze dat dual-stack systemen met incompatibele software over IPv6 benaderd worden door het AAAA record nog niet in te stellen (want daarna is het IPv6-preferred). Op LinkedIn’s website lees je hoe ze twee netwerken parallel naast elkaar leggen op een manier die het later het makkelijkst maakt om IPv4 uit te faseren, zonder dat daarbij nog aan het IPv6-netwerk gesleuteld hoeft te worden. Daarbij maken ze gebruik van een gedeelde IPAM voor beide IP-netwerken. Software-ontwikkelaars worden ondertussen gedwongen om afhankelijkheden van IPv4 uit hun code te halen. Daartoe wordt een deel van hen in een IPv6-only omgeving geplaatst. Systemen en applicaties test je op dezelfde manier: door IPv4 uit te schakelen. Facebook vertelt op zijn website hoe het zijn interne IP6-only datacenters voor externe diensten ontsluit voor gebruikers die via IPv4 binnenkomen: Verbindingen worden van buiten naar binnen geleid via een tweelaags gecombineerde proxy/load-balancer, eerst op IP-niveau, vervolgens op HTTP-niveau. Daarmee is de Demilitarized Zone (DMZ) weer helemaal terug van weggeweest.

Nu beginnen

Wat deze grote ondernemingen gemeen hebben is dat zij hun IPv6-only strategie al jaren geleden ingezet hebben, dat die projecten nog steeds lopen, en dat die transitie ook nog jaren gaat duren. Dat betekent dat je te laat bent als je pas begint op het moment dat je met je IPv4-adressen in de problemen komt.