Overstap naar IPv6 is geen revolutie

Het nieuws rondom IPv6 gaat met name over het moment dat IPv4-adressen opraken en een internet dat als gevolg volledig vastloopt en inboet aan openheid. Angstbeelden worden geïnsinueerd zoals een verdwijning van de digitale snelweg, omdat je site simpelweg niet meer te vinden is. Maar angst is geen goede raadgever in deze. Laat staan dat het zorgdraagt voor een business case die de migratie rechtvaardigt.

De veelgehoorde term migratie is ook niet de beste woordkeuze. Het veronderstelt een drastische overstap naar IPv6, in een wereld waar geen ruimte is voor IPv4. De meeste experts zijn het er wel over eens dat niet het geval is. Het zou zelfs onmogelijk zijn. Er is te veel relevante informatie die voorlopig alleen nog op een IPv4-adres beschikbaar is. Dit mag en zal niet verloren gaan, en IPv4 is dus voorlopig ook nog niet uit zicht. Bovendien was IPv6-verkeer vorig jaar nog maar goed voor 0,3 procent van het totale verkeer. Dit komt vooral doordat zelfs bedrijven die intern IPv6 ondersteunen, nog altijd het IPv4-internet gebruiken, omdat het de standaard is.

Het gebruik van IPv6 lijkt vooral aangezwengeld te worden door het mobiele internetverkeer. Door de enorme groei van mobiele apparatuur en het gebrek aan IPv4-adressen, zijn veel service providers overgestapt op IPv6. Logisch: klanten zullen toegang tot bepaalde (en de nieuwste) diensten eisen, of dat nu op IPv4 of IPv6 is, maakt hen niet uit. Ze zullen de provider kiezen die hen toegang biedt.

Maar wederom: De meeste content is nog op het IPv4-internet, dus gaan gebruikers massaal nog dat netwerk op. Dus waarom zou je dan overstappen? Wat zijn de redenen die de gang naar IPv6 rechtvaardigen en hoe ziet zo’n proces eruit? Voordat we daar op ingaan, eerst een situatieschets


Nederland loopt achter
Hoewel de IPv6-discussie wereldwijd gevoerd wordt, blijkt Nederland een van de landen te zijn die vooralsnog geen aanstalten maakt IPv6 grootschalig in te voeren. KPMG onderzocht dit en concludeerde dat de meeste bedrijven geen noodzaak zien om nu al over te stappen. Het probleem van oprakende internetadressen wordt wel erkend, maar 70 procent denkt dat dit niet direct een bedrijfsrisico oplevert en 60 procent geeft aan andere prioriteiten te hebben dan deze ‘issue’.

IT-afdelingen lijken dus een afwachtende houding aan te nemen. Kan dit kwaad? Wel als je beseft dat andere gebruikers in de wereld al wel klaar zijn voor IPv6. Het is wachten op de rest, voordat het daadwerkelijke gebruik kan groeien. De angst voor onbereikbare websites komt dan snel dichterbij, zeker bij bedrijven die internationaal actief zijn. Geen enkele IT-manager wil aan zijn baas of aandeelhouders uitleggen waarom site-traffic minimaliseert, omdat hij te lang de kat uit de boom heeft gekeken.

Het kan ook kwaad wanneer je nagaat dat veel softwaresystemen IPv4 afhankelijk is geschreven. Uit een verkennend onderzoek begin dit jaar van de Software Improvement Group (SIG) blijkt dat 1 op de 7 (15 procent) informatiesystemen IPv4-afhankelijk is en bij een overgang mogelijk niet correct zal werken of zelfs helemaal niet meer functioneren. Vreemd genoeg is dat een groei ten opzichte van eerder onderzoek in 2010 toen het nog 1 op de 12 was.


Voordelen IPv6
Het wordt een ander verhaal wanneer je nagaat dat een ‘IPv6-ready’ strategie een bedrijf wel degelijk voordelen blijkt te geven. Het aanbieden van content-diensten bijvoorbeeld voor mobiele apparatuur, waarbij IPv6 wordt ondersteund, kan veel sneller en betrouwbaarder, terwijl mobiele netwerken makkelijker zijn te beheren. Als we dan eenmaal zo ver zijn, en dat moment komt zeker in de komende jaren, heeft zo’n bedrijf een duidelijke voorsprong.

Daarbovenop komt dat een overstap nu wel eens goedkoper kan uitpakken dan over niet al te lange tijd, wanneer de nood veel hoger is. Dan gaat het marktwerking principe een rol spelen wat de prijzen zal doen stijgen. De adressen worden duurder en het overstappen wordt duurder, omdat er meer vraag naar is. Dus dan toch maar als prioriteit bestempelen, en een groot project van maken? Nee, hier is het goede nieuws: Een overstap naar IPv6 kan geleidelijk worden uitgevoerd, zonder dat dit hele IT-budgeten vereist, systemen plat legt of een groot projectteam verlangt. In vijf stappen is de overgang soepel te regelen


Website toegankelijk houden
Als eerste heb je uiteraard IPv6-adressen nodig via een ISP. Dit is een eenvoudig verzoek en vereist enkel van de service provider wat inspanningen (zie het kader Uitdagingen voor de service provider). Vervolgens is het zaak de website toegankelijk te houden voor klanten, prospects en andere geïnteresseerde partijen. Het overgrote deel zal nu nog via IPv4 de website bezoeken, maar de balans zal na verloop van tijd overslaan naar IPv6. Landen als China en India, niet onbelangrijk in de hedendaagse wereldeconomie, opereren vrijwel uitsluitend via IPv6.

Wanneer reeds gebruik wordt gemaakt van dual-stacked application delivery controllers (ADC’s) voor het verwerken van het verkeer naar webservers, kan de omzetting plaatsvinden zonder de servers aan te passen. Een ADC die zowel IPv4 als IPv6 aankan, fungeert dan als gateway en zet IPv6-verkeer om naar IPv4 en vice versa. Wanneer deze nieuwe virtuele IPv6-adressen worden toegevoegd aan de DNS-server zijn ze te gebruiken en is je aanwezigheid op IPv6 geregeld. Deze methode is gemakkelijk door te voeren en biedt een goede tussenoplossing zonder aanpassingen aan infrastructuur of applicaties door te voeren. Belangrijk hierbij is dat naast NAT64-functionaliteit ook aan DNS64 wordt gedacht. Een IPv6-only gebruiker kan alleen een IPv4-gebaseerde applicatie benaderen wanneer DNS64 een vertaling van het IPv4-adres maakt.


Security inrichten
Wanneer internetverkeer door een gateway gaat, wordt het lastiger te achterhalen wat de bron-IP-adressen zijn, dus moeten er enkele security-maatregelen worden genomen. Als het goed is, beschermen aanwezige firewalls, proxies, IDS/IPS, authenticatiemiddelen en antivirus software tegen uiteenlopende risico’s. Het zou mooi zijn wanneer deze tools ook IPv6-verkeer kunnen herkennen, zodat te achterhalen is aan welke apparatuur ze gekoppeld zijn en of dit binnen of buiten het vertrouwde netwerk is. Denk naast protectie voor het netwerk ook aan het beschermen van applicaties op het juiste niveau, namelijk OSI laag 7. De gevaren op applicatieniveau blijven helaas ook met de komst van IPv6 op de loer liggen.

Verschillende security-producten ondersteunen reeds IPv6 en anderen zullen niet achterblijven. De voorkeur gaat uit naar producten die zowel IPv4 als IPv6 aankunnen om te voorkomen dat extra apparatuur in de IT-omgeving moet worden opgenomen. Consolidatie is een veiligere strategie dan uitbreiding. Ga dus na of de leverancier binnen korte tijd IPv6-ondersteuning kan bieden of ga op zoek naar een alternatief.

Ervoor zorgen dat ADC’s IPv6-verkeer aankunnen is een praktische oplossing zonder veranderingen in de architectuur van infrastructuur of applicaties door te moeten voeren.


Hou je collega’s connected
In heel veel organisaties is een vorm van flexwerken mogelijk, waarbij medewerkers van buiten het netwerk toegang kunnen krijgen tot IT-resources binnen het bedrijf. Dit is ook van groot belang als support-medewerkers remote ondersteuning moeten bieden. In principe kan dit nog wel op IPv4 blijven draaien, maar als klanten overstappen op IPv6 wil je wel de best mogelijke support bieden. Remote access-tools moeten dus ook worden overgezet, en op termijn moet natuurlijk alles worden overgezet.

Een goede oplossing is het toewijzen van nieuwe virtuele IPv6-adressen aan de hosting servers en de clients daarvan bewust maken. Hierbij is van belang de security-policies in de gaten te houden. Dezelfde regels moeten gelden voor IPv6 en IPv4.


Site-to-site communicatie
Een veel gebruikte technologie als SSL VPN is prima om een verbinding op te zetten, maar om verschillende locaties of business units te verbinden is een site-to-site verbinding beter. Nog maar weinig ISP’s ondersteunen directe site-to-site circuits op basis van IPv6, maar het aantal is groeiende. Een site-to-site verbinding die zowel IPv4 als IPv6 ondersteund heeft duidelijk de voorkeur. Een dergelijke oplossing maakt het immers mogelijk om alle gebruikelijke taken gewoon uit te blijven voeren zoals gewend.


Legacy
De laatste stap is nagaan hoe en of legacy toepassingen om kunnen gaan met IPv6. Dat lijkt lastig, maar voordat IPv6 zijn voorganger volledig heeft overgenomen, zijn we heel wat jaren verder. Mogelijk zijn deze legacy systemen dan al verdwenen. Mocht dat niet het geval zijn dan is het simpelweg een kwestie van het verkeer omleiden, feitelijk zoals dat in de eerste stap is beschreven.


Neem de tijd
Belangrijk is dat we allemaal kunnen lezen en schrijven met IPv4. Voor IPv6 ligt dit anders, het zal voor velen voelen als de ervaring van de eerste rijles. Begin er dan niet aan op het moment dat er druk op de ketel staat, maar zorg dat je vertrouwd raakt met de nieuwe adressering, het gedrag en hoe dit in jou omgeving het beste is te implementeren.


De uitdaging voor service providers
Geen enkele service provider zal in staat zijn met een druk op de knop al zijn apparatuur en toepassingen over te zetten naar IPv6. De komende jaren zal IPv4 dan ook zeker niet van het toneel verdwijnen. Service providers moeten hun datacenters, netwerkinfrastructuur en security-systemen voorlopig inrichten voor zowel IPv4 als IPv6 verkeer. Daarnaast moeten zij ervoor zorgen dat hun applicaties en diensten blijven draaien binnen beide domeinen. Netwerk-firewalls, access management tools en applicatie delivery tools zijn dus allemaal onderdeel van het IPv6-migratieplan

Aangezien de overstap geleidelijk zal gaan, zullen er binnen een infrastructuur geïsoleerde IPv4-netwerken ontstaan die toch moeten communiceren met de rest van de systemen en gebruikers die al wel over zijn. Bovendien zorgt een overstap voor uitdagingen op het security-gebied doordat apparatuur veelzijdiger moet worden ingezet. Er zijn eenvoudigweg meer dingen om rekening mee te houden en meer risico’s om tegen te beschermen.

Om hiermee om te gaan, hebben een service providers een slim migratieplan en praktische tools nodig. Deze tools moeten in staat zijn om de infrastructuur te testen, te veranderen en te migreren op een veilige, controleerbare manier.

Published Mar 14, 2013
Version 1.0

Was this article helpful?

No CommentsBe the first to comment