IPv6: Niets doen is geen optie

Voordat we ingaan op de verschillende transitiescenario's, kort nog een aantal uitgangspunten rond IPv6. IPv6 is geen nieuwe versie van IPv4. Het is een ander protocol dat als een nieuw netwerk actief is naast het bestaande netwerk. IPv6 en IPv4 kunnen niet met elkaar samenwerken. De manier waarop pakketjes informatie over netwerken worden verstuurd en de informatie die wordt meegegeven aan die pakketjes (de ‘headers'), verschillen namelijk. Applicaties en computers moeten beide protocollen kunnen gebruiken en verwerken. Daarom heeft IPv6 impact op elk aspect van het ict-landschap van organisaties en is het niet alleen een aangelegenheid van netwerkbeheerders. Het ‘aanzetten' van IPv6 is één ding, het geschikt maken van het totale landschap is een tweede.

Niets doen en alles bij het oude laten, kan voor sommige bedrijven een aantrekkelijke optie lijken. Bijvoorbeeld voor meer behoudende bedrijven en bedrijven die in hun commerciële activiteiten niet erg afhankelijk zijn van internet. Denk hierbij aan back office (legacy) omgevingen van ondernemingen als financiële instellingen. Echter op langere termijn zullen klanten IPv6 gaan eisen, omdat ze via IPv6 toegang hebben tot het internet. En een overstap naar de concurrentie is snel gemaakt. Mocht u (nu nog) niet de overstap willen maken, dan moet uw bedrijf bovendien actief stappen ondernemen om te voorkomen dat er met behulp van IPv6 ongeautoriseerd toegang tot uw bedrijfsomgeving wordt verkregen. Door standaard installaties of upgrade van operating software en automatische configuratietechnieken kan geprobeerd worden om ongeautoriseerd toegang te krijgen tot uw netwerk. U dient in dit scenario IPv6 dus actief te weren. ‘Niets doen' heeft dus tot gevolg dat u actief IPv6 dient te vermijden.

Scenario 2: IPv6 vertalen naar IPv4
Voor bedrijven waarbij een platform moet kunnen blijven draaien op het IPv4-protocol, maar er wel toegang mogelijk moet zijn voor IPv6, is ‘protocol vertaling' een optie. Een vertalingstechniek, het ‘NAT64 transitiemechanisme' aan de randen van uw netwerk vertaalt in dat geval inkomende IPv6-connecties naar IPv4. Deze techniek wordt veel gebruikt op netwerkapparatuur als firewalls en load balancing hardware. Implementatie van NAT64 is niet enorm ingewikkeld en kan in een relatief korte tijd.

Een nadeel is echter dat bij NAT64 de status van de vertaalde verbinding wordt bijgehouden. De oplossing is hierdoor beperkt schaalbaar. Wanneer de omvang van inkomend IPv6-dataverkeer toeneemt, zal de bandbreedtelimiet of de capaciteit van de centrale verwerkings eenheid (cpu - cental processing unit) van de netwerkapparatuur op den duur bereikt worden. De vertaling zorgt er bovendien voor dat inzicht in de bron van de verbinding, het adres van de afzender, verloren gaat. Dit breekt het ‘end-to-end' principe waarbij de (web)applicatie weet met welke eindgebruiker hij communiceert. Voor marketinggedreven organisaties, waarvoor juist deze kennis over de eindgebruiker essentieel is, is dit een probleem. Tot slot is het bekend dat sommige applicaties, zoals videoconferencing en vpn-tunnelingtechnieken, problemen hebben met NAT64-vertaling en dus niet goed meer kunnen werken.

Voor dit scenario zijn componenten benodigd als: Internet Access routers (eventueel met Border Gateway Protocol (BGP) mogelijkheden), firewalls en een NAT64-gatewayoplossing.

Het meest aanbevolen transitiescenario is om IPv4 en IPv6 tegelijkertijd (parallel) naast elkaar te laten draaien op uw platform. Dit scenario heet het hybride of ‘dual stack' scenario. Bij dit scenario kan eventueel de scope worden beperkt tot de internetzijde, zoals de DeMilitarized Zone (DMZ), waardoor de back-end van uw platform IPv4 single stack blijft. Bedenk hier wel bij dat bijvoorbeeld de applicaties die worden gebruikt voor het genereren van statistieken en andere tooling mogelijk aangepast zullen moeten worden voor gebruik in de dual stack omgeving.

Dit dual stack scenario moet ondersteund worden door: Internet Access Routers (eventueel met Border Gateway Protocol (BGP) ondersteuning), firewalls, load-balancers , alle andere hard- en software binnen de DMZ en mogelijk de tooling in andere zones.

De laatste optie is om een IPv6 single stack omgeving te creëren met een IPv4-toegangspunt (entry point). Een perimeter apparaat, de zogenoemde NAT46-gateway, vertaalt inkomende IPv4 sessies naar IPv6, voordat ze de bij de omgeving binnenkomen. De NAT46-gateway moet voldoende verwerkingscapaciteit hebben om het verkeer snel te kunnen afhandelen. Omdat de verwachting is dat de hoeveelheid IPv4-verkeer in de loop van de tijd zal afnemen, is het niet waarschijnlijk dat er grote toekomstige capaciteitsuitbreidingen nodig zijn van deze gateway. Dit in tegenstelling tot de NAT64-gateway in scenario 2.

Het spreekt voor zich dat dit scenario het beste werkt voor een nieuwe it-omgeving waar alles gebouwd kan worden met alleen IPv6 en waar er geen ‘IPv4 legacy' is. Net als in het NAT64-scenario verbreekt deze optie het end-to-end principe, in dit geval echter voor het IPv4-verkeer.

Voor dit scenario moet alle hard- en software in de omgeving ‘native' IPv6 ondersteunen. Deze optie zal vooral interessant zijn voor universiteiten en andere innovatieve organisaties. In de praktijk blijkt dit scenario voor velen nog een brug te ver.

Het mag duidelijk zijn: niets doen is geen optie. Welke optie u als bedrijf kiest, zal grotendeels afhankelijk zijn van het segment waarin u werkzaam bent. Een online retailer heeft andere wensen en behoeften dan een zakelijke dienstverlener. Het segment waarin u werkzaam bent, vertaalt zich in uw marketingstrategie en de noodzaak om innovatief te zijn.

Voorbereiding en planning
Voor welke optie u ook kiest, implementatie van IPv6 is niet iets wat je in één dag doet. Er is zorgvuldige voorbereiding voor nodig. Vooral in organisaties waarbij de ict bedrijfskritisch is. Afhankelijk van welk scenario u kiest moet u er minimaal een half jaar tot een jaar voor uittrekken.

Betrek uw stakeholders
Vergeet ook niet uw leveranciers voor hardware en software en andere stakeholders binnen en buiten uw organisatie, zoals toeleveranciers en andere zogenaamde ‘3rd parties' in het traject te betrekken. Want als één van deze partijen niet of niet meteen IPv6 ondersteunt, kan dat gevolgen hebben voor het gekozen scenario, uw implementatieplan of de planning.

Testen
Alvorens u IPv6 daadwerkelijk implementeert in uw organisatie, is het belangrijk deze te testen. Het blijkt namelijk dat leveranciers van hardware of software soms hun eigen interpretatie van IPv6 hebben, waardoor onderdelen niet goed kunnen samenwerken. Een ‘Proof of Concept' zal eventuele issues identificeren voordat met de daadwerkelijke implementatie begonnen wordt.

Implementatie
Pas nadat de Proof of Concept succesvol is afgerond, kunt u uw risico's in kaart brengen, uw implementatieplan afronden en starten met de daadwerkelijke implementatie.

Ideaal gesproken laat u de implementatie samenvallen met het moment dat u uw oude it-omgeving afgeschreven hebt en een nieuwe implementeert. Doet u zaken met Azië en is uw it-omgeving nog niet IPv6 proof? Dan is directe actie nodig: in Azië zijn de IPv4 adressen al op. In Europa zal dat naar verwachting voor het einde van het jaar zijn en in Noord- en Zuid Amerika voor eind 2013. Elke onderneming moet zelf het moment bepalen, maar wacht niet te lang. Want, zoals men in de IPv6-community zegt: The future is forever. Are you ready?

Dennis Silva en Erwin Blekkenhorst
Mission critical Engineers
Schuberg Philis