Inleiding

Op het internet zien we een wildgroei van allerlei communicatieprotocollen (TCP, UDP, HTTP, FTP, SMTP, etc.) en infrastructuurcomponenten (switches, routers, glasvezel, koper, draadloos, etc.). Over de jaren heen is de diversiteit steeds verder toegenomen, tot een niveau waarbij er voor een buitenstaander geen touw meer aan vast te knopen is. Er is echter één constante factor in deze enorme vergaarbak en dat is het Internet Protocol (IP)-adres.

Het IP-adres ([DARP81]) is een unieke code om een apparaat (pc, server, televisie, koelkast, etc.) op het internet aan te sluiten, vergelijkbaar met de unieke combinatie postcode/huisnummer die TNT Post nodig heeft om een pakketje af te kunnen leveren op de juiste locatie. Figuur 1 bevat een grafische weergave van de bovenstaande situatie in het zogenaamde zandlopermodel ([CSTB94]). De centrale rol die IP speelt in internetcommunicatie is daarin duidelijk zichtbaar.

Figuur 1. Het zandlopermodel voor internetcommunicatie.

Ondanks dat het IP-adres (versie 4 om precies te zijn, IPv4) door de jaren heen vrijwel de enige constante factor is gebleken in internetcommunicatie, weten we al sinds eind jaren tachtig dat de 32 bits die binnen IPv4 voor het adres beschikbaar zijn (en resulteren in ruim 4 miljard adressen), onvoldoende zijn om in de groeiende behoefte aan adresruimte te voorzien. Als reactie op deze constatering heeft de Internet Engineering Task Force (IETF) in de jaren negentig een nieuwe 128 bits-versie van het IP-protocol ontwikkeld, IPv6 ([NWG98]).

In de afgelopen tien jaar zijn er verschillende voorspellingen gedaan over de exacte datum waarop de adressen echt op zouden zijn, maar op 3 februari 2011 was het dan eindelijk zover: het internet kan met IPv4 niet nog meer gebruikers bedienen ([NITF11]).

Probleemstelling

Nu de IPv4-adressen op zijn, rijst de vraag hoe ernstig deze situatie is. Om een inschatting te maken van de consequenties, zullen we eerst beschrijven wat de mogelijkheden zijn voor verdere ontwikkeling van het internet. Daarna gaan we verder in op de barrières in deze ontwikkeling en de impact op uw bedrijfsvoering. Als laatste trekken we de conclusies over een mogelijke aanpak en keuzen die u de komende jaren zal moeten maken aangaande uw IT-landschap, gerelateerd aan de overgang naar de nieuwe versie van het internetprotocol.

Verdere ontwikkeling van het internet

Zelfs nu de Internet Assigned Numbers Authority (IANA) niet meer beschikt over IPv4-adressen heeft dat nog geen directe consequenties voor IP-adresaanvragen van eindgebruikers en van Internet Service Providers (ISP’s). De Regional Internet Registries (RIR’s) hebben nog een voorraad waarmee bijvoorbeeld het Europese Coördinatie Centrum (Reseaux IP Européens – RIPE) tot ongeveer het midden van 2011 toekan ([Hust11]). Daarnaast is er nog een aantal vrijwel ongebruikte ‘legacy blocks’: grote blokken met IP-adressen, die in het verleden direct aan organisaties zijn toegewezen. Als deze blokken worden herverdeeld, zal het iets langer duren voordat de eindgebruikers in Europa geen IPv4-adressen meer kunnen aanvragen ([Vego08]).

Als ultieme noodmaatregel voor het oprekken van de IPv4-beschikbaarheid is er nog de mogelijkheid om binnen uw organisatie de infrastructuur te optimaliseren. Door middel van Network Address Translation (NAT) kan ervoor worden gekozen om grote delen van uw netwerk niet (direct) toegankelijk te maken vanaf het internet ([NWG01]). U wijst dan adressen toe die alleen van binnen uw organisatie te bereiken zijn en legt dus minder beslag op publieke IP-adressen. De systemen kunnen overigens zelf wel van toegang tot het internet worden voorzien, ze zijn alleen niet (direct) benaderbaar vanaf het internet.

Overgang naar IPv6

Alle eerdergenoemde maatregelen zijn eindig. Voor verdere ontwikkeling is een overgang naar de nieuwe versie van het internetprotocol noodzakelijk. Het laatste blok met ongeveer 17 miljoen IPv4-adressen dat RIPE beschikbaar heeft, wordt dan ook gebruikt om de overgang naar de nieuwe versie van het internetprotocol (IPv6) te faciliteren. In de andere regio’s van de wereld zijn vergelijkbare afspraken gemaakt. In de praktijk zal dat betekenen dat deze IP-adressen niet beschikbaar zijn voor eindgebruikers en ISP’s, maar zullen worden verdeeld volgens speciale richtlijnen ([Smit10]).

Nu bijna alle adressen oude stijl zijn vergeven, rest geen andere mogelijkheid meer dan het maken van de overstap naar IPv6. Daarbij moeten we ons realiseren dat de nieuwe versie niet in staat is te communiceren met de oude versie en omgekeerd: IPv4 en IPv6 zijn twee volledig gescheiden parallelle netwerken ([DARP81], [NWG98]).

IPv6 bevat een aantal interessante verbeteringen ten opzichte van IPv4 met betrekking tot veiligheid en schaalbaarheid ([NWG98]). Zo is standaardondersteuning voor data-encryptie (met IPsec) ingebouwd en kunnen IPv6-systemen zichzelf door communicatie met hun omgeving (via ICMPv6) automatisch op de juiste manier configureren op het netwerk (stateless address autoconfiguration). Verder is routering geoptimaliseerd, zodat relatief nieuwe concepten als multicast (het sturen van informatie naar meerdere ontvangende systemen) sterk worden vereenvoudigd.

De oplossing voor een vloeiende overgang van IPv4 naar IPv6 ligt in de zogenaamde dual-stack protocolimplementatie ([NWG05]). Met andere woorden, internetinfrastructuurcomponenten moeten beide protocolversies (gaan) ondersteunen. Moderne dual-stack implementaties bieden de mogelijkheid om applicaties te ontwikkelen die gebruikmaken van zogenaamde hybride poorten, zodat deze direct geschikt zijn voor beide protocollen. Niet alle systemen bieden echter deze mogelijkheid. Op bijvoorbeeld Windows XP en Server 2003 moeten expliciet twee gescheiden poorten worden geopend voor dual-stack ondersteuning ([Micr]), wat leidt tot extra ontwikkelinspanningen.

Impactanalyse

Als de dual-stack oplossing zo voor de hand ligt, waarom zijn we dan nog niet overgestapt? Wachten tot het laatste IPv4-adres is vergeven, is toch niet nodig! Er zijn twee facetten die daar een belangrijke rol in spelen.

• Een verandering naar een standaard die niet compatibel is met zijn voorganger is altijd een ingewikkelde klus. Zeker als de standaard een fundamenteel en wijdverspreid onderdeel is van de bestaande goed werkende infrastructuur. Vergelijk het maar met een beslissing om met zijn allen links op de weg te gaan rijden in plaats van rechts. Daar moet echt heel wat voor gebeuren.
• Er is heel lang geworsteld met het kip-ei-probleem. Iedereen had de beschikking over IPv4, dus er was (nog) geen noodzaak om te investeren in het aanbieden van diensten via IPv6. Aan de andere kant, als alle diensten worden aangeboden over IPv4, waarom zouden eindgebruikers dan investeren in IPv6?

Het kip-ei-probleem is door de uitputting van de IPv4-adrespool inmiddels doorbroken. Met name in Azië gaan de ontwikkelingen snel en worden op dit moment op grote schaal IPv6-infrastructuren uitgerold (zie bijvoorbeeld figuur 2). Daarmee ontstaat de situatie dat binnenkort (grote) delen van het internet alleen nog via IPv6 beschikbaar zijn. Dat is een belangrijke stimulans voor aanbieders van internetdiensten (en in mindere mate ook voor eindgebruikers) om op dual-stack over te schakelen. De internetreuzen zoals Google en Facebook hebben al IPv6-varianten van hun portals, bijvoorbeeld op http://ipv6.google.com.

Figuur 2. Trendbreuk in India, explosieve toename van IPv6-adressen sinds eind 2010.

Op infrastructuurgebied zijn we er in Europa nog lang niet (zie ook http://v6asns.ripe.net/v/6). Hoewel een aantal ISP’s al proactief bezig is met de ondersteuning van IPv6, zijn grote delen van het internet nog niet ontsloten. Probeer thuis of op het werk maar eens of de Google of Facebook IPv6-portal toegankelijk is, grote kans dat u eindigt met een ‘Network Error’.

Om de ontsluiting van IPv6 te bespoedigen is er een aantal technieken beschikbaar. Bij zogenaamde IPv6-over-IPv4-tunnels worden IPv6-pakketjes verpakt in IPv4-pakketjes ([NWG05]). Op die manier kunnen twee afzonderlijke IPv6-delen van het internet elkaar bereiken door een IPv4-gebied heen. Er zijn diverse automatische tunneltechnieken in gebruik (bijvoorbeeld Teredo) om de bereikbaarheid van IPv6-sites te vergroten ([NWG10]).

Een andere belangrijke techniek voor het faciliteren van de overgang naar IPv6 is een variant op de al eerder genoemde Network Address Translation (NAT). Figuur 3 toont een schematische weergave van een IPv6- en een IPv4-gedeelte van het internet. Via een speciaal daarvoor ingerichte server (in dit geval gebruikmakend van NAT64) kan aan de eindgebruikers op het IPv6-netwerk toegang worden verschaft tot het IPv4-netwerk (maar niet andersom!) door de IPv4-adressen te vertalen in IPv6-adressen ([BWG10]). Deze technieken worden nu al toegepast in de wereld van de mobiele communicatie. Zie bijvoorbeeld de public beta-tests door T-Mobile op http://groups.google.com/group/tmoipv6beta.

Figuur 3. Segmentering van het internet in gebieden met IPv4 en IPv6.

Opvallend aan eerdergenoemde oplossingen voor de transitie van IPv4 naar IPv6 is dat er voldoende mogelijkheden zijn om vanaf systemen met alleen het nieuwe protocol toegang te verkrijgen tot delen van het internet met alleen het oude protocol. Andersom zijn de mogelijkheden echter zeer beperkt. Eindgebruikers met alleen de beschikking over een IPv4-adres zijn niet in staat om gebruik te maken van nieuwe IPv6 only-diensten. Voor die groep zijn er twee oplossingen. Zelf overschakelen op dual-stack, waarbij aan de ISP duidelijk moet worden gemaakt dat deze ondersteuning noodzakelijk is, of aandringen op dual-stack bij de leverancier van de dienst. De eerste oplossing zal daarbij in toenemende mate haalbaar zijn omdat dit voor ISP’s een concurrerende factor wordt. De tweede oplossing daarentegen wordt met het beperkte aantal beschikbare IPv4-adressen steeds onwaarschijnlijker.

Conclusie

Organisaties en eindgebruikers zullen in toenemende mate worden geconfronteerd met de schaarste aan IPv4-adressen. Hoewel er door verschillende belanghebbenden proactief wordt gewerkt aan de uitrol van IPv6 (zie bijvoorbeeld [SURF11]), is er nog een lange weg te gaan.

IPv6 ligt als een sluipmoordenaar op de loer en bedreigt de concurrentiepositie van uw organisatie. De ontwikkeling voltrekt zich op dit moment nog grotendeels buiten uw gezichtsveld. Immers, het IPv4-netwerk blijft gewoon functioneren en IPv6 only-delen van het internet ontstaan vooral in gebieden waar relatief weinig contact mee is, zoals Azië. Zolang er in Europa nog internetadressen te verkrijgen zijn, lijkt er geen directe noodzaak voor een dual-stack implementatie.

Het probleem ontstaat als Europa dan ook eindelijk overgaat op IPv6. Plotseling krijgt u de massale concurrentie te verwerken van bedrijven die al geruime tijd in die markt actief waren op tot dan toe onbereikbare delen van het internet. Met recht wordt u op dat moment geconfronteerd met een remmende voorsprong van formaat. Naarmate de IPv6 only-gebieden van het internet groter worden, wordt het voor uw organisatie steeds belangrijker om dual-stack te ondersteunen.

De belangrijkste conclusie is om proactief om te gaan met de komst van IPv6. Bij iedere verandering in uw IT-landschap moet u zich afvragen of er de mogelijkheid is voor dual-stack ondersteuning. Dit geldt niet alleen op netwerkbeheergebied, maar ook bij de vervanging van applicaties of het afsluiten van nieuwe contracten met ISP’s of andere IT-partners, zoals bijvoorbeeld cloud-serviceproviders. Alleen op die manier kunt u zich ervan verzekeren dat uw organisatie op tijd klaar is voor de ongekende mogelijkheden van IPv6.