Hoe kan dat nou? 4.29 miljard IP4 adressen... die je dan moet verdelen over nog geen kwart van de wereldbevolking (terwijl de andere helft ligt te slapen). In theorie zou dat toch moeten lukken.
Wereldwijde internetpenetratie ligt dichter bij een derde dan een kwart, mensen slapen niet de helft van hun tijd maar een derde, dat mensen slapen betekent nog niet dat computers uit staan, sommige mensen hebben meer dan één computer (vergeet mobieltjes niet!), en dan heb je alleen nog maar client machines geteld; vergeet de servers niet.
En nee, daarmee kom je op dit moment misschien nog niet aan 4 miljard adressen, maar dat is slechts een kwestie van tijd, want het aantal computers groeit. En tegen de tijd dat de IPv4 adressen daadwerkelijk op zijn is het te laat om eens te beginnen met migreren naar IPv6, dat moet dan klaar zijn!
En 2^32 mag dan ongeveer 4.3 miljard zijn, dat wil niet zeggen dat er 4.3 miljard bruikbare adressen zijn. Zo is 127.0.0.0/8 gereserveerd voor loopback adressen, 10.0.0.0/8 voor lokale netwerken, en 224.0.0.0/4 voor multicast. Alles bij elkaar hou je net 3.7 miljard adressen over.
En als we het over de indeling van de adresruimte hebben...
Deel van het probleem is dat er IP ranges uitgegeven worden en dat de providers de ranges - uiteraard - niet volmaken. Zo ben je inderdaad wel snel door je IP4 adressen heen.
Natuurlijk maken providers hun ranges niet vol - dat kan namelijk niet.
Je kunt een adresruimte voor een netwerk zo complex als het Internet niet willekeurig indelen. Packets komen namelijk niet magisch vanzelf aan op hun bestemming.
Adres 1.2.3.4 voor een UPC klant in Nederland, 1.2.3.5 voor een Tsjech, en 1.2.3.6 voor een server in Amerika werkt niet. Stel je een router op de
AMS-IX voor. Die router moet dan weten dat een packet voor 1.2.3.4 naar Nederland moet, 1.2.3.5 richting het oosten, en 1.2.3.6 richting de transatlantische fiber.
Dat moet die router dan weten voor alle gebruikte adressen (laten we zeggen, ongeveer 2 miljard), en voor elk packet (ongeveer één miljoen per seconde) moet hij dat opzoeken in zijn geheugen. Het zal niet verbazen dat dat gewoon echt niet kan.
Een alternatieve methode: we verdelen alle adressen zodat de eerste byte aangeeft bij welk land het adres hoort. Bijvoorbeeld: alle 3.x.y.z adressen zijn voor Nederland, 4.x.y.z is voor luxemburg, en de US heeft er vast meer nodig, dus die krijgen 20.x.y.z t/m 40.x.y.z. Plotseling hoeven de core routers alleen nog maar naar de eerste byte te kijken, en dus hoogstens 256 verschillende bestemmingen te onthouden. Dat kan wel!
De routers binnen Nederland krijgen het ook makkelijker; ze hoeven geen 2^32 adressen meer te kennen, maar nog maar 2^24 (alle adressen die beginnen met 3). Alle adressen die niet beginnen met 3 zijn voor het buitenland en moeten dus richting een backbone waar de routers het verder wel uitzoeken.
Om dit nog werkbaarder te maken kun je dit schema natuurlijk verder doorvoeren; 3.x.y.z voor Nederland, waar x de provincie aanduidt, y de plaats binnen die provincie, en z het huis binnen die plaats. Op die manier hoeft elke router maximaal 256+1 verschillende adrescategorieën te kennen!
Maar deze methode brengt natuurlijk wel overhead met zich mee. 4.0.0.0/8 voor Luxemburg betekent dat Luxemburg zo'n 16 miljoen adressen krijgt op nog geen half miljoen inwoners. Binnen een land heb je vergelijkbare 'verspillingen' - het is onmogelijk om alles precies passend te maken, al was het maar omdat deze categorisatie met 2-machten werkt, en de vraag naar adressen altijd fluctueert en niet constant is.
De werkelijkheid ligt ergens tussen de twee bovenstaande situaties in; het alloceren van adressen is een balans tussen de opzoekcapaciteiten van routers, de schaarste van adressen, de topografische verdeling van de computers en de verbindingen, en de aansluiting op de al uitgedeelde adressen. Ik hoef je niet te vertellen dat dat een ingewikkeld verhaal is, want de IPv4 address space is aardig gefragmenteerd.
Ik hoop dat het duidelijk is dat je simpelweg nooit 100% van alle beschikbare adressen kunt benutten.
IPv6 maakt dit een stuk eenvoudiger, precies omdat het zo enorm veel meer adressen heeft. Dit maakt eenvoudige verdelingen als "elk land krijgt een /50 netwerkblok" mogelijk, wat de routering veel en veel envoudiger maakt. Dat betekent uiteindelijk dat routers minder werk per packet hoeven te doen, en dus sneller kunnen werken. Zie bijvoorbeeld ook
IPv6 sparse allocation.
Juist. De (veel te grote) adresruimte van IPv6 ondersteunt 3.4x10^38 adressen.
De adresruimte van IPv6 is niet "veel te groot". Hij is groot, maar groot is goed.
Daarnaast zorgt IP6 voor een hoop extra overhead.
Zoals ik boven heb laten zien wordt de routing overhead juist kleiner bij IPv6. Bovendien zijn IPv6 headers eenvoudiger en altijd van dezelfde lengt (itt de variabele lengte van IPv4 headers), wat ze nog eenvoudiger te routen maakt.
Wel is het zo dat IPv6 headers langer zijn dan IPv4 headers, vanwege de grotere adressen, maar dit verschil is niet erg groot. IPv6 headers zijn 40 bytes, IPv4 headers minimaal 20 bytes. Verder zijn TCP headers minimaal 20 bytes, en is de maximale packetgrootte typisch 1500 bytes.
Dat betekent dat we met TCP/IPv4 ongeveer 97% van packets kunnen gebruiken voor payload, en met TCP/IPv6 ongeveer 96%. Dat is geen groot verschil.
Veel providers bieden nog geen IP6 en gebruikers tunnelen hun IP4 naar IP6, of iets wat erop lijkt.
Dus? Dat is een tijdelijke oplossing en heeft niks te maken met de kwaliteiten (of gebrek daaraan) van IPv6. Providers moeten native IPv6 gaan aanbieden, maar ik vrees dat dat pas gaat gebeuren als het eigenlijk al te laat is.