Managed hosting door True
Deze opinie is van een externe deskundige. De inhoud vertegenwoordigt dus niet noodzakelijk het gedachtegoed van de redactie.

Hoe hard is IPv6 nodig?

 

Bij de eeuwwisseling en de invoering van de euro liep de spanning in de it-wereld hoog op. Welke complicaties zouden die met zich meebrengen? Allerlei doemscenario’s doken op. Nu wordt er, zij op wat mindere schaal, zorgelijk gedaan over het naderende einde van de voorraad IP-adressen,. Met het huidige groeitempo komt het eind snel in zicht. Links en rechts is al heel wat over geschreven.

Wiskundig valt niet moeilijk te berekenen dat de 32 bits van de huidige IP-adressering (IPv4) maximaal 4,294 miljard IP-adressen toelaten. Dan is de koek op. De oplossing zou zijn, zo wordt in brede kring aangenomen: IP versie 6 met 128 bits. Het aantal uit te geven adressen komt daarmee miljarden malen hoger . Er komt dan een getal met 39 cijfers uit, in plaats van het getal met ‘slechts’ 10 cijfers van IPv4.

Het brainstormde over de hele wereld. Voor de it-techneuten betekende dit RFC’s (Request For Comments) en meer RFC’s; plannen en ideeën worden in de groep gegooid en er ontstaan pittige discussies, niet zelden met niet-technische achtergronden.


Weer een hype?

Nu we over de schrik van het snel naderende einde van de adressenvoorraad heen zijn, duiken echter allerlei andere overwegingen op. Eén daarvan is overigens dat we het leven van IPv4 met aanvullende technologieën nog best lang kunnen redden (of rekken ...). Dus loopt het dan zo’n vaart niet?

Op het eerste gezicht zou je misschien denken dat het weer een voorbeeld van een hype of een commercieel complot is. We zijn inmiddels achterdochtig geworden. Want niet alles wat met tamtam gepresenteerd wordt, slaat ook aan, zo weten we. Mobiel video-telefoneren bleek geen ‘killer applicatie’ van de derde generatie (3G), maar wel is het gebruik van fotografie en filmpjes maken met de mobiele telefoon snel gegroeid. WAP is evenmin aangeslagen, maar televisie via internet en projecten als Joost, Fon en wifi/hotspots zien er veelbelovend uit. VPN’s schieten de grond uit, of de ether in.


Broodrooster

Er is wel meer aan de hand. De eisen van gebruikers en telecomaanbieders zijn de laatste decennia toegenomen. Het is inmiddels niet meer het befaamde broodrooster met een IP-adres. Het is veel interactiviteit, samenwerking, mobiele apparatuur (denk aan wereldwijde roaming! breedband draadloos internet, 3G), evenementen die snel en efficiënt, maar tijdelijk, van (real-time) communicatiefaciliteiten voorzien moeten worden (denk aan de Olympische Spelen), herstel van data en functionaliteit na rampen (natuurrampen, maar ook netwerkcrashes) en de toegenomen veiligheidseisen.

Aan eisen voor een betere beveiliging kan in IPv6 tegemoetgekomen worden door authenticatieroutines en encryptie ìn het protocol op te nemen. Dit draagt bij aan de ‘plug&play’-functionaliteit van v6 en maakt huidige adhoc-oplossingen (imap, HTTPS, VPN SSH et cetera) min of meer overbodig. De rol van firewalls en poortbewaking zal evenmin geheel buiten schot blijven.

Een ander proces dat we met de invoering van IPv6 in geschiedenisboeken kunnen bijschrijven, is NAT (Network Address Translation), een werkje dat de router verder bespaard kan worden. Maar of men in de overgangsperiode juist kiest voor een rol van NAT-verzorgende routers, zou in de optiek van sommigen mogelijk ‘politiek incorrect’ zijn.

Voor IPsec en FTP heeft men iets anders slims moeten bedenken.

En dan mogen we de Jumbograms niet vergeten, de grotere datapakketten dan de traditionele 16 bits (= 64kb) van UDP en TCP/IP. Omdat deze eis/wens/feature de grens van het lagenmodel, naar de transportlaag dreigde te overschrijden, is daar met tweaks uit RFC 2675 een bevredigende oplossing voor gevonden. Het zal duidelijk zijn dat de benodigde overhead bij de transmissie van de Jumbograms veel minder zal kunnen zijn dan om de 16 bits ‘effe checken’.


Migratie

Een van de grootste taken waarvoor netwerkexploitanten zich bij de migratie naar IPv6 gesteld zien, is: Hoe houden wij het IPv4-verkeer maximaal ‘in de lucht’?

Want het zal duidelijk zijn dat IPv4 nog geruime tijd zal blijven bestaan, ook na de (verwachte) invoering en groei van IPv6. Er zal dus een tijd van ‘heradressering’ en ‘redirect’-mechanismen aanbreken. Daarvoor zijn dan weer oplossingen mogelijk als: alle IPv4-adressen een nieuw IPv6-adres geven via NAT (Network Address Translation), of de IPv4-adressen zodanig modificeren dat ze passen in het nieuwe IPv6-formaat, een kwestie van aanvullen met nullen tot 128 bits. Enerzijds wil je dus met IPv6 af van de omstreden NAT en anderzijds zou je NAT juist goed kunnen gebruiken bij één van de mogelijke interim-oplossingen. Hoewel het een forse operatie zal worden, vereist het geen baanbrekende technologie. Maar wel goede afspraken en nog betere testen. En natuurlijk hardware. ‘dual-stack devices’, die de gekozen oplossingen moeten uitvoeren.

Er mag zich niets van de toe te passen technieken ‘in het verborgene’ afspelen, dus moet er maximale openheid zijn en speelt het netwerkbeheer een cruciale rol. Alleen al de toename van het verkeer (VoIP, video) zorgt al voor een zware druk op de efficiency van routing en van de administratie. Dit zal vooral merkbaar zijn in de hoofdnetwerken, de zogenaamde ‘back bones’. Daarvoor vormt MPLS (Multiprotocol Label Switching) een prima uitgangspunt.


Tunneling en MPLS

Er is veel te zeggen voor tunneling-oplossingen (bijv. 6PE dat via MPLS werkt of GRE, dan wel een andere IPinIP-techniek) in de beginfase van de transitie. Betrokken partijen kunnen dan ervaring opdoen met IPv6, zonder meteen de Grote Sprong te hoeven maken met de risico’s die men zich daarmee op de hals zou halen. Nadeel is natuurlijk wel dat we veel energie (moeten) steken in deze tussenoplossingen, maar tunneling blijft een interessante technologie, ook zonder de druk van IPv4/IPv6.

MPLS is als digitale schakeltechniek ontworpen om juist al die protocollen en dataformaten te kunnen verwerken. De eindgebruiker hoeft daar niets van te merken, laat staan te weten. Maar voor de telecomaanbieders is MPLS des te belangrijker. Drie technologische (tussen)oplossingen naast elkaar:

- Routing over netwerken die alleen nog IPv4 verstaan. Er wordt dan met MPLS-labels gewerkt. Deze inkapseling heeft voordelen ten opzichte van dual stack.

- Ook zou men subnetten alvast kunnen opwaarderen naar IPv6 en deze via tunnels met elkaar verbinden.

- Ondersteunen van het aanmaken van IPv6-tunnels over bestaande (IPv4)-netwerken, waar dual-stack-hardware geïnstalleerd is. Ook dit kan via MPLS geregeld worden, met MPLS TE (Traffic Engineering).

Als een netwerk al MPLS ondersteunt, is er een vlotte en veilige overgang mogelijk van versie 4 naar versie 6. Voor MPLS maakt het niet uit of er (al dan niet versleutelde) IPv6-tunnels tussen IPv4-nodes opgezet worden òf IPv4-tunnels tussen IPv6-nodes.


Kosten

De kosten blijven voor telecomaanbieders die met hun tijd mee zijn gegaan, beperkt tot het installeren of upgraden van IPv6-compatibele apparatuur (de genoemde ‘stacks’) en het opleiden van specialisten. Daarna kan de verbetering snel te gelde worden gemaakt: beter beheer, veiliger verkeer (de beveiliging zit nu in het protocol), efficiënter routeren, meer diensten kunnen aanbieden. Dit vertaalt zich snel in rendement en dus ‘business’.

Jos Martens, directeur strategic marketing carrier services Global Crossing

Conclusie

De ervaringen met IPv6 zijn tot dusver hoopgevend. Al zal het kostenaspect zeker niet hèt doorslaggevende argument zijn om potentiële klanten nu over de streep te trekken. En dat hoeven we niet erg te betreuren, want kwaliteitsbewustzijn in de ict kan nog een ‘boost' gebruiken. De belangen zijn er groot genoeg voor.

Dit artikel is afkomstig van Computable.nl (https://www.computable.nl/artikel/2213329). © Jaarbeurs IT Media.

?


Lees meer over


 
Vacatures

Stuur door

Stuur dit artikel door

Je naam ontbreekt
Je e-mailadres ontbreekt
De naam van de ontvanger ontbreekt
Het e-mailadres van de ontvanger ontbreekt

×
×