- Door
- Sean Duggan
- geplaatst op
- 11 augustus 2011 08:01 uur
Er wordt weliswaar al tien jaar over gepraat, maar de discussies over IPv6 worden nu echt serieus. Daar heeft het succes van Wereld IPv6 Dag op 8 juni 2011 zeker aan bijgedragen. Iedereen die de vakpers bijhoudt, weet dat de IPv4-adressen zo goed als op zijn en dat een overstap naar IPv6 onvermijdelijk is.
Sommige organisaties zijn daarin afwachtend doordat ze nog beschikken over voldoende niet-toegewezen IPv4-adressen. Daar kunnen ze wellicht nog twee tot drie jaar mee verder. Echter, heel veel organisaties kunnen niet meer aan IPv4-adressen komen. Vooral in Azië, maar intussen ook in het Midden-Oosten en Europa adopteren organisaties daarom al IPv6. In een sterk onderling verbonden wereld heeft dat gevolgen voor iedereen. Wanneer organisaties hun publiekelijk toegankelijke websites niet geschikt maken voor IPv6, sluiten ze een grote groep gebruikers uit.
Vooral de mobiele carriers en internetserviceproviders (isp’s) hebben dit al onderkend. Zij krijgen te maken met grote groepen IPv6-klanten die in de toekomst over dezelfde internettoegang en mobiele services willen beschikken als nu. De markt heeft een punt bereikt waarop de ondersteuning van IPv6 niet langer een optie, maar noodzaak is voor serviceproviders. Ook bij isp’s raken de IPv4-adressen op en veel upstream-isp’s kunnen in de toekomst alleen maar IPv6-adressen aanbieden. Wanneer een serviceprovider niet voldoende adressen kan bieden om aan de klantvraag te voldoen, zal een klant overstappen naar een andere aanbieder. Om dat te voorkomen, is ondersteuning van IPv6 noodzakelijk.
Veel serviceproviders zoeken dan ook naar een efficiënte en kosteneffectieve manier om zowel IPv4- als IPv6-klanten te bedienen. Zij moeten verbindingen tussen en naar netwerken bieden, zodat exclusieve IPv6-klanten toegang hebben tot het IPv4-internet. Wanneer er eenmaal een betrouwbare IPv6-verbinding is, dan is er nog de uitdaging van een soepele transitie van de interne netwerken naar IPv6.
Gefaseerde migratiestrategie
Het is voor serviceproviders onmogelijk om in een keer grote wijzigingen in hun netwerken aan te brengen. Tegelijkertijd is downtime geen optie. Dat betekent dat een gefaseerde migratiestrategie de enige weg is. Serviceproviders hebben oplossingen nodig, die IPv6-ondersteuning mogelijk maken zonder gelijktijdige aanpassingen aan de interne infrastructuren. Er zijn gelukkig mogelijkheden die daarin geleidelijk voorzien.
Tunneling
Tunneling is een mechanisme om verkeer met een bepaald protocol in te pakken in een ander protocol dat voor het transport over het netwerk wordt gebruikt (bijvoorbeeld IPv4 inpakken in IPv6 of andersom).
- DS-Lite en 6rd zijn twee voorbeelden van tunnelingmethodes voor het gelijktijdig uitvoeren van IPv4- en IPv6-verkeer.
- DS-Lite stelt een organisatie in staat om IPv4-verkeer door een IPv6-backbone-netwerk te transporteren. Stel dat de eindgebruikersapparatuur van een isp – bijvoorbeeld een kabelmodem in een woning – IPv6 ondersteunt en het clientdevice waarop de modem is aangesloten, alleen IPv4. Wanneer de client een webadres opvraagt dat op een IPv4-netwerk aanwezig is, zorgt DS-Lite voor een IPv4-tunnel via het IPv6-netwerk van de provider. Door het verpakken of inkapselen van het IPv4-adres in het IPv6-pakket kan de client verbinding maken met de IPv4-website via het IPv6-netwerk van de isp. Echter, voordat het pakket het IPv6-netwerk verlaat, moet de Carrier Grade NAT (CGN) van de isp het IPv6-adres terugvertalen naar het originele IPv4-adres, zodat het pakket de eindbestemming op het IPv4-netwerk bereikt. DS-Lite heeft zijn mogelijkheden in bepaalde scenario’s zoals hierboven beschreven, maar het blijft een beperkte oplossing. Het is immers gebaseerd op het transporteren van pakketten via een IPv4-tunnel over IPV6-infrastructuur. Het helpt serviceproviders niet bij het toewerken naar een nieuwe situatie: een volledige IPv6-infrastructuur.
- IPv6 rapid deployment, of 6rd, is een tunnelingmechanisme dat in essentie het tegenovergestelde is van DS-Lite. 6rd transporteert IPv6-verkeer via een tunnel over een IPv4-netwerk. Een belangrijk verschil met DS-Lite is, dat 6rd volledig binnen het eindgebruiker-isp-netwerk draait. Nu serviceproviders starten met het implementeren van de dual stack-infrastructuur, die hun voorkeur heeft, zal het gebruik van 6rd naar verwachting snel teruglopen.
Dual stack
Met een echte dual stack-oplossing (niet te verwarren met DS-Lite) ondersteunt zowel de eindgebruikersapparatuur als het providernetwerk de IPv4- en IPv6-protocol-stacks volledig. Een dual stack is in zekere zin te vergelijken met iemand die volledig tweetalig is, bijvoorbeeld in Nederlands en Engels. Hij of zij kan een vraag in beide talen beantwoorden en zal uitgaan van de taal waarin de vraag is gesteld.
In een dual stack-omgeving spreken alle betrokkenen bij de communicatie-uitwisseling IPv4 en IPv6. Wanneer een client bijvoorbeeld een aanvraag stuurt voor een IPv6-adres www.voorbeeld.com en het adres bestaat, dan ontvangt de client een IPv6-adres en ontstaat er een verbinding via het IPv6-backbone-netwerk van de serviceprovider. Wanneer www.voorbeeld.com alleen op het IPv4-internet bestaat, krijgt de client een IPv4-adres voor die site en ontstaat de verbinding via het IPv4-netwerk. Dual stack is dus een mechanisme dat zowel IPv4- als IPv6-verkeer kan verwerken. Het stelt het protocol vast op basis van het verzoek van de client.
NAT64 en DNS64
Het inzetten van dual stack met NAT64 is een prima oplossing voor de eigen diensten van een serviceprovider, zoals een klantenwebportal of mobiele, video- of webcontent voor abonnees. Een serviceprovider die zijn video-on-demand-infrastructuur (VOD) wil overzetten naar IPv6, kan een Application Delivery Controller (ADC) dichtbij zijn VOD-servers plaatsen om NAT64 te verwerken.
Wanneer een IPv4-settopbox een video aanvraagt, vertaalt de ADC het adres naar IPv6 en stuurt het verzoek door naar het netwerk van de kabelexploitant. Wanneer de film begint met streamen in IPv6, komt het verzoek terug via het ADC-device, dat het IPv6-adres vertaalt naar IPv4, waarna de film naar de IPv4-settopbox van de klant gestuurd wordt. Deze oplossing stelt serviceproviders in staat om hun interne infrastructuur over te zetten naar IPv6, waarbij er ondersteuning blijft voor IPv4-client-apparatuur. Deze aanpak voorkomt ook tijd- en kapitaalinvesteringen in het upgraden van firmware in settopboxen en andere eindgebruikersapparatuur om deze geschikt te maken voor IPv6.
Voor verkeer dat via een netwerk van een serviceprovider naar een bestemming op het IPv4- of het IPv6-internet wordt gestuurd, is een combinatie van zowel dual stack met NAT64 en DNS64 de beste oplossing. DNS64 voorziet in name resolution voor IPv6-clients wanneer ze een site opvragen, die alleen op het IPv4-internet beschikbaar is. De client krijgt een samengevoegd adres van de DNS64-server, dat een pointer omvat naar een NAT64-server. De NAT64-server vertaalt vervolgens het samengevoegde IPv6-adres naar een IPv4-adres, verbindt de clients en houdt de beide adressen bij, zodat de sessies tussen de IPv6-client en de IPv4-bestemming in de lucht blijft.
Voor serviceproviders die uiteindelijk de transitie willen maken naar IPv6 (en IPv4 blijven ondersteunen tot het uitgestorven is), is de dual stack NAT64/DNS64-oplossing een goede manier om de transitie soepel te laten verlopen. Serviceproviders die nog niet met tunneling zijn begonnen, doen er verstandig aan weg te blijven van deze oplossing. Tunneling verlengt de afhankelijkheid van IPv4 en zorgt dus voor ongewenst uitstel van het onvermijdelijke. Met een dual stack-netwerk en NAT64/DNS64 waar nodig, is er geen sprake van wegwerpoplossingen. Deze benadering zorgt voor een stevig fundament voor de volledige transitie naar IPv6. En als je daarbij samenwerkt met leveranciers waarvan de oplossingen al ingebouwde IPv6-ondersteuning bieden, is dat alleen maar beter.
Door Sean Duggan, Director Product Management F5 Networks
