RIPE NCC deelt laatste blok ipv4-adressen uit

De pool met vrij te gebruiken ipv4-adressen, is leeg. Dat heeft de Europese organisatie die ip-adressen uitdeelt aan isp's en hosters vrijdag laten weten. Het is nu van belang dat providers overstappen op ipv6, benadrukt de organisatie.

Vrijdag heeft RIPE NCC, de lokale internet registry voor Europa, het Midden-Oosten en delen van Azië, de laatste ipv4-blocks uitgedeeld. Dat laat een stafmedewerker van de in Amsterdam gevestigde organisatie weten op een openbare mailinglijst. Vorige week werd al bekend dat deze maand de laatste ipv4-adresblokken zouden worden uitgedeeld.

Het opraken van de ipv4-blocks betekent niet dat internetproviders geen ipv4-adressen meer hebben: veel internetproviders hebben nog een voorraad. Zodra ze echter door die voorraad heen zijn, kunnen ze geen ipv4-adressen meer krijgen. Daarom is het van belang dat providers overstappen op ipv6, dat een schier oneindige hoeveelheid ip-adressen biedt, benadrukt RIPE NCC.

Overigens is het niet zo dat RIPE NCC helemaal geen ipv4-adressen meer heeft om uit te delen: er is nog een kleine voorraad. Uit die voorraad van rond de 16 miljoen adressen kan echter niet zomaar worden geput: er zijn strenge voorwaarden aan bevonden. Ze worden bijvoorbeeld, per blok van 1024 adressen, uitgedeeld aan nieuwe internetproviders die hun ipv6-only-netwerken zullen moeten verbinden aan dat deel van het internet dat nog op ipv4 draait. Aangezien een ipv6-netwerk niet rechtstreeks kan worden verbonden met een ipv4-netwerk, moet daar een host tussen die én via ipv6, én via ipv4 communiceert. Daarvoor zijn adressen van beide protocollen nodig.

Het grootste verschil tussen ipv4 en ipv6 is het aantal beschikbare ip-adressen. Waar er circa 4,3 miljard ipv4-adressen zijn, ligt het aantal ipv6-adressen fors hoger. Er zijn om en nabij de 340 sextiljoen ip-adressen - dat is een getal van 39 cijfers - wat betekent dat er per aardbewoner veel meer ipv6-adressen beschikbaar zijn dan dat er in totaal ipv4-adressen zijn. Een nadeel is echter dat ipv4- en ipv6-packets niet compatibel zijn; daardoor is het noodzakelijk dat het hele internet het nieuwe protocol in gebruik neemt.

Tweakers.net sprak eerder dit jaar met RIPE NCC-oprichter Rob Blokzijl, onder meer over ipv6.

Reacties (128)

[Pete]

Ze hebben nog wel iets meer dan 1024 adressen in voorraad. Ze hebben een compleet /8 (16777216 adressen) over die ze gaan uitdelen in blokken van 1024 (/22)

Ze hebben dus nog 16384 blokken en met de restrictie van 1 blok per provider, en alleen wanneer ipv6 ingevoerd word hebben ze genoeg voor de laatste noden van (nieuwe) ISP's.


EDIT: In het originele artikel stond dat RIPE maar 1024 adressen meer over heeft.

[Reactie gewijzigd door Pete op 23 juli 2024 13:56]

[jip_86]

Het staat hier toch wel duidelijk volgens mij:

Uit die voorraad van rond de 16 miljoen adressen kan echter niet zomaar worden geput: er zijn strenge voorwaarden aan bevonden. Ze worden bijvoorbeeld, per blok van 1024 adressen, uitgedeeld aan nieuwe internetproviders die hun ipv6-only-netwerken zullen moeten verbinden aan dat deel van het internet dat nog op ipv4 draait.

[Pete]

Zoals ik al aangaf in mijn edit, in het originele artikel stond letterlijk dat RIPE maar 1024 meer heeft. De auteur heeft het inmiddels aangepast.

[databeestje]

Deze laatste /8 is ook bedoeld voor ondernemingen welke nog geen ASN (aansluitnummer) hebben en voor het eerst bij de RIPE NCC aankloppen.

De kleinste allocatie is op dit moment een /24 (256 adressen), dus hopelijk kunnen ze meer dan 1024 organisaties helpen.Toch zie ik het in de toekomst nog wel gebeuren dat er allocaties van /25 zullen worden uitgegeven.

Wishful thinking is dat de grotere organisaties geen /22 allocaties meer aanvragen en er zo meer "overblijft" voor de organisaties welke nog geen allocatie hebben.

Het is nu even geduld tot het voorjaar van 2013 wanneer de echte crunch bij de hosting providers en access providers gaat spelen.

Ik kijk persoonlijk de tijden met extra lagen NAT zwaar tegemoet. De problemen waarbij beide partijen achter een dubbele NAT laag zitten brengt substantiele problemen met zich mee. En er is geen uPNP voor de NAT "gateway" van de ISP of andere alternatieven die hier makkelijk mee helpen.

De problemen die spelen voor de overheid en de bewaarplicht zijn substantieel. Er moet een volledige NAT sessie bewaart worden met juiste tijden om de klant te kunnen herleiden. Meer investeringen aan de kant van de ISP.

De ISPs zien de grote NAT gateways als 1 groot gat waar geld in gestort moet worden wat ze niet meer terugverdienen. Wat uiteindelijk ook doorberekend wordt aan de klant.

Het internet takelt weer langzaam af richting 1990 door de zeer sterke fragmentatie van de IPv4 space in steeds kleinere stukken. En dat brengt ons op een ander probleem.

De huidige IPv4 route tabel is al dik over de 400.000 routes heen:
418243 network entries using 56881048 bytes of memory
En natuurlijk komen er ook steeds meer IPv6 routes bij:
10277 network entries using 1644320 bytes of memory

Mijn verwachting is dan ook dat er steeds vaker bij BGP routers problemen komen met het geheugen gebruik. Dus willen ze filteren op steeds grotere netwerken (/23 bv) om het geheugen gebruik te drukken. Maar omgekeerd willen mensen nog kleinere netwerken (/25) gebruiken om met het laatste IPv4 het internet op te komen.

Het eindresultaat is helaas niet mooi. We zullen het er maar mee moeten doen.

[musiman]

De problemen waarbij beide partijen achter een dubbele NAT laag zitten brengt substantiele problemen met zich mee.

Je zult niet achter dubbele NAT zitten. Providers kunnen gebruik maken van CGN (Carrier Grade NAT) wat inhoudt dat jouw routertje alleen routeert van jouw Private Range ipadressen naar een ander IPv4 netwerk dat pas bij de AFTR m.b.v. CGN wordt vertaald naar een voor het internet publiek IPv4 adres, waarbij je als klant dus gezamenlijk gebruik maakt van een pool beschikbare IPv4 adressen. Je hebt geen "eigen" IPv4 adres meer.

Dus maar één keer NAT.

Hier kleeft echter een nadeel aan en dat heeft alles te maken met Apple. Apple heeft namelijk een Happy Eyeballs implementatie gemaakt waarbij niet IPv6 de voorkeur heeft, maar de verbinding die op dat moment het snelst is. Hierdoor gaan users die een native IPv6 conntectie naar het internet hebben, toch nog voor zo'n 40% over IPv4 connecten, wat dus over die CGN gaat. En dat terwijl providers juist graag willen dat gebruikers zoveel mogelijk over IPv6 gaan, wat niet geNAT hoeft te worden.
Heb je nou bijvoorbeeld een pc met Chrome als browser, die doet het veel beter. Chrome probeert eerst de IPv6 connectie en met 300msec vertraging de IPv4 connectie. Dus alleen wanneer de IPv6 connectie brak is, zal teruggevallen worden op de IPv4 connectie. Veel beter dan hoe Apple het in Lion en hoger opgelost heeft.

[databeestje]

Ik denk dat je wat door elkaar haalt. Je router thuis doet NAT, en CGN is ook gewoon NAT, met dat verschil dat je nu in plaats van 1 huishouden, 100 huishoudens 1 publiek IP adres delen. Het probleem is dat je hier geen controle over hebt, evenmin port ranges.

Vooralsnog is de consensus om port ranges toe te kennen aan klanten, maar ook dat is problematisch en niet zonder haken en ogen. Een ander groot probleem is langdurige sessie. Geheugen is duur, en zeker op zo'n grote schaal als 10 gigabit en meer is de overhead significant te noemen.

Sterker nog, je huis deelt 1 "extern" IP adres. b.v. 10.34.42.231, tussen jouw router en de CGN/LSN en vervolgens ga je samen met nog 100 huishoudens door de LargeScaleNat heen waarna de pleuris uitbreekt als er meerder mensen google Earth gebruiken. Die applicatie is een goed voorbeeld welke in korte tijd veel sessie opzet en af laat vallen. En zo zijn er nog wel meer.

Jouw thuis router moet wel NAT gebruiken, zoals het nu doet, want de ISP kan niet weten dat het netwerk 192.168.1.x (wat in bijna alle huishoudens in gebruik is) achter jouw router in gebruik is. Dat is normale routering, en dat gaat niet zonder kennis van het netwerk daar achter. En je kan niet 192.168.1.x naar alle klanten routeren. Dat is IP routing 101.

Je verhaal met Apple is grotendeels correct, dit is van toepassing op mensen die MacOS X 10.7 en later gebruiken. Mac OS X 10.6 en lager werkt volgens de oude IPv6 over IPv4 methode. Dit staat overigens los van de browser, applicaties mogen zelf expliciet uitmaken met welk adres ze verbinden.

Ik heb de IPv6 ondersteuning in de open source pfSense firewall geschreven, ik heb een aardig idee hoe hoort te werken.

[musiman]

Ik begrijp wat je bedoelt.

[Reactie gewijzigd door musiman op 23 juli 2024 13:56]

[r.elu]

Elke LIR (RIPE member) kan maximaal nog 1 /22 krijgen, ook grote organisaties zullen het daar dus mee moeten doen. Meer aanvragen is dus niet mogelijk.

[Reactie gewijzigd door r.elu op 23 juli 2024 13:56]

[Verwijderd]

Hadden ze nou niets iets kunnen verzinnen dat ipv4 en ipv6 min of meer compatible zouden zijn? Ondanks dat we al jaren weten dat het einde van ipv4 in zicht is, is er nog steeds vrijwel niets gedaan om op ipv6 over te stappen! En dat komt natuurlijk vanwege die compatibliteits issues. Dat had toch wel iets handiger gekunt!?

[the_stickie]

Neen, dat is zo goed als onmogelijk. Al is het alleen maar omdat ipv4 implementaties rekining houden met 32-bits adressen en dus niet genoeg geheugen hebben om met veel grotere adressen te werken.
Bovendien heeft men van "de gelegenheid" gebruik gemaakt om het hele IP protocol een update teb geven.
Overigens is er wél rekening gehouden met interoperabiliteit. Je kan mits de juiste infrastuctuur IPv4 en IPv6 netwerken aan elkaar knopen

[Verwijderd]

Natuurlijk hadden de mensen in de IPv6 workgroups veel meer kunnen doen om IPv4 en IPv6 (meer) compatible te maken. Echter, er was een sterke politieke wil om bepaalde technische beslissingen te nemen.

Een daarvan was dat IP4 en IPv6 niet compatible mochten worden gemaakt. Er mocht zelfs geen NAT tussen v4 en v6 mogelijk zijn. Allemaal om mensen te dwingen om zo snel mogelijk over te stappen. En dat er geen langdurige overgangs-phase zou zijn.

Dat heeft dus niet goed uitgepakt.

[bigbadbull]

Tuurlijk was dat mogelijk.
maar het was niet wenselijk.
ipv6was gewoon beter dan de ander alternatieven, niet in het minst door de protocol update die op zijn zachts gezegd al wat verouderd was bij ipv4.
moest je een compatibele standaard gebruiken, dan zaten we nog steeds met een verouderd protocol;
Eindelijk hebben ze eens verstandig beslist om een nieuw standaard met een up2date protocol te nemen ipv oude zooi mee te sleuren.

[Zr40]

Compatibiliteit is niet de issue, noodzaak is dat. IPv6 werkt gewoon prima naast IPv4.

Tot nu toe is er weinig noodzaak geweest om IPv6 te implementeren, omdat er toch nog steeds IPv4 adressen beschikbaar geweest zijn. Daarnaast heerste de angst dat bepaalde systemen door bugs of misconfiguratie toegang verliezen tot sites met zowel een IPv4- als IPv6-adres. Dit samen heeft er waarschijnlijk voor gezorgd dat de uitrol van IPv6 niet bepaald snel ging.

De World IPv6 Launch heeft aangetoond dat de angst grotendeels ongegrond was. Nu ook de IPv4-blokken van RIPE NCC op beginnen te raken zie je nu ook steeds meer providers IPv6-toegang aanbieden.

[Verwijderd]

Je hebt helemaal gelijk dat er geen noodzaak is voor individuele ISPs, bedrijven of mensen om over te stappen naar v6. Alleen het "algeheel belang".

Echter, als v4 en v6 compatible waren gemaakt, dan was de overgang *veeeeel* makkelijker geweest. Als er over na was gedacht hoe je NAT (of eigenlijk: "protocol translation") zou hebben kunnen doen, dan had dat ook al heel veel gescheeld. De IPv6-jongens hebben zichzelf in de voet geschoten.

[ReneX]

Vast wel ... maar dan had ipv4 daar al rekening mee moeten houden ...

In principe draaien v4 en v6 naast elkaar - dus incompatibel is het niet.
Alleen moet al je apparatuur (naast je provider) wel v6 ondersteunen.
Niet onverstandig om daar bij aanschaf op te letten!

[Verwijderd]

Hardstikke incompatible.
Zoek eens op: "ships in the night". Of "dual stack".

Als ik IBM's SNA op mijn computer draai, en AppleTalk, wil dat dan zeggen dat SNA en AppleTalk compatible zijn ?

[Waah]

best wel ongelofelijk, dat er straks per gebruiker meer IPV6 adressen zijn dan er nu in totaal IPV4 adressen zijn

[Verwijderd]

Fantastisch.
Alleen wil dat nog niet alles zeggen.

IPv4 addressen zijn adressen. (Duh). Dat wil zeggen, ze geven aan waar iets is. De locatie. (De meeste mensen denken bij IPv4 adressen alleen aan identifiers). Je kunt wel iedereen een unieke identifier geven. Netjes boven aan de lijst beginnen met uitdelen. Maar als je die als adres wilt gebruiken, moet je slimmer te werk gaan. IPv4 was niet zo heel slim wat dat betreft. IPv6 heeft er helemaal niks aan verbeterd. Maar als je meer adressen uitdeelt, (en daar veel lakser in bent), dan wordt het helemaal een zooitje.

Vergelijk het met postcodes. We hebben in Nederland 10^4 * 26^2 mogelijke postcodes. Dat zijn er 6760000, zo'n 6 miljoen. Stel er komen straten bij (nieuwbouw). De postcodes in bv. Helmond liggen allemaal tussen 5700 en 5709. Dat zijn er 6084. Stel je voor dat die allemaal in gebruik zijn. En er komt een nieuwe straat bij. Welke postcode krijgt die dan ? Je kunt hem gewoon een vrije postcode geven, bv 8888DF. Maar dan werkt de post-sorteer niet meer. Je kunt niet meer zeggen: 5700-5709 -> stuur maar naar Helmond. Er moet een uitzonderings-regeltje bij komen.

Hoe meer je van de uitzonderings-regeltjes krijgt, hoe groter de tabel bij alle sorteer-centra. En als je maar lang genoeg wacht, krijgen de tabellen bij de sorteerderijen gewoon een apart regeltje voor iedere straat in Nederland. Dan helpt de postcode dus niet meer. Dan krijg je "een flat address-space". Alsof het hele Internet gebridged is.

Dit is een serieus probleem. Routers in de backbone(s) van het Internet hebben al een half miljoen IPv4 routes die ze moeten kennen. CIDR was een initiatief om de global routing table weer wat beter te comprimeren. Maar het moet eigenlijk veel beter. IPv6 heeft daar een kans laten liggen. En als iedereen met IPv6 adressen gaat strooien of het niks is, dan wordt de global IPv6 routing table nog veel groter dan de IPv4 table.

Je kunt dus niet zeggen "we hebben zat adressen". Je moet ook goed nadenken over hoe je ze gebruikt en toewijst.

[Reactie gewijzigd door Verwijderd op 23 juli 2024 13:56]

[Belboer]

IPv6 helpt weldegelijk om de routing tabellen kleiner te houden. Immers per ASN heb je in principe maar één of als je een hele grote ISP bent enkele IPv6 allocaties nodig. Dit omdat een standaard allocatie van /29 voldoende ruimte heeft om een half miljoen klanten van een /48 te voorzien.
Dat betekend dat het aantal routes tussen de 1-2 x het aantal ASNs zal vallen. Bij de huidige IPv4 routing voor het internet is het aantal routes op dit moment 10 x het aantal ASNs. De globale routing tabel voor IPv6 zou dus een factor 5 kleiner zijn als elk AS IPv6 ondersteunt. En nu IPv4 uitgegeven is zal daar waarschijnlijk ruilhandel ontstaan waardoor de adresruimte verder versnippert en de route tabellen helemaal uit de klauwen gaan lopen.
Ook al is bij het ontwerp van IPv6 van alles gebeurt waar je het niet eens mee bent, als je bezorgd bent over de groei van route tabellen dan is meewerken aan de uitrol van IPv6 een stuk productiever dan vast blijven houden aan IPv4.

[Verwijderd]

IPv6 helpt weldegelijk om de routing tabellen kleiner te houden.

Nee, het opnieuw uitdelen van adressen geeft gelegenheid om de tabellen klein te houden. Echter, dat is een administratieve kwestie. Er is geen enkele verandering in de techniek die het makkelijker maakt.

Immers per ASN heb je in principe maar één of als je een hele grote ISP bent enkele IPv6 allocaties nodig. Dit omdat een standaard allocatie van /29 voldoende ruimte heeft om een half miljoen klanten van een /48 te voorzien.

Helemaal waar.

Dat betekend dat het aantal routes tussen de 1-2 x het aantal ASNs zal vallen.

Je vergeet twee dingen.
1) Multi-homed sites. Die moeten een eigen prefix in de global routing table hebben. Met IPv4 en met IPv6. Als IPv6 echt vernieuwende technologie was geweest, dan was dat niet nodig geweest.
2) Verandering. Klanten veranderen van ISP. ISPs veranderen van transit/upstream/backbone provider. Als een klant van ISP veranderd, hernummert hij dan zijn hele netwerk ? Kleine klanten moeten waarschijnlijk wel. Maar grotere klanten zullen ISP-onafhankelijk adressen willen hebben, zodat ze van ISP kunnen veranderen. Kleine en middel-grote ISPs zullen ook hun eigen prefixes willen hebben. Na verloop van tijd zal er meer en meer entropie in de adressen komen. Als je dat had willen tegengaan, dan had je in de architectuur van je netwerk-laag eerder met nieuwe oplossingen moeten komen. En dat is niet gebeurd, helaas.

Ook al is bij het ontwerp van IPv6 van alles gebeurt waar je het niet eens mee bent, als je bezorgd bent over de groei van route tabellen dan is meewerken aan de uitrol van IPv6 een stuk productiever dan vast blijven houden aan IPv4.

Zeker waar. De vraag is, of een factor 5 de moeite waard is, voor de meeste ISPs en bedrijven. Mijn punt was niet wat je nu moet doen. (Ik weet dat niet). Mijn punt was dat IPv6 een kans heeft gemist om het een stuk beter te doen. Wat nu wel te doen ? Ik heb geen idee.

[Reactie gewijzigd door Verwijderd op 23 juli 2024 13:56]

[Verwijderd]

Het aantal mogelijke adressen dat IPv6 oplevert is wel een enorme overkill. Iedereen die onmiddellijk begin met:

Ja maar.... 16, 32 etc. bits waren ook niet genoeg, moet toch echt maar eens tot zich door laten dringen hoeveel 2^128 eigenlijk wel is. Dat is namelijk dit: 340,282,366,920,938,000,000,000,000,000,000,000,000

Ik vraag me af of het niet beter was geweest om een systeem te bedenken met minder mogelijke adressen, maar dat wel meer compatibele zou zijn geweest met IPv4.

[MSalters]

Al had je 33 bits gebruikt, dan nog was het niet compatible geweest met IPv4. Dus vandaar de keuze om meteen naar 128 bits te gaan, dan is deze transitie de laatste ooit.

[Verwijderd]

De IPv6 workgroup had drie dingen wezenlijk anders kunnen doen.

1) Ze hadden er voor kunnen zorgen dat IPv6 makkelijk "compatible" had kunnen worden gemaakt met IPv4. Bv door er voor te zorgen dat je makkelijker NAT-achtige apparaten had kunnen bouwen die je tussen je IPv4 en IPv6 netwerken had kunnen hangen. Een soort "protocol translation". Er is bewust voor gekozen om dat niet te doen. En zelfs om te proberen dat tegen te gaan. (Zie mijn comments elders hier waarom).

2) Ze hadden een makkelijkere oplossing kunnen kiezen. Bv door CLNS als nieuw layer-3 protocol te kiezen. CLNS is de oude netwerk-standaard van de OSI groep van ISO. CLNS werkte, en werd in produktie-netwerken gebruikt. Op redelijk grote schaal. De layer4-7 van OSI zijn knudde (maar layer 3 is goed. misschien wel beter dan IP layer 3, imho). Dit voorstel heette TUBA (TCP and UDP with Bigger Addresses). CLNS adressen waren variabele lengte, met max 20 bytes. (De keuze voor 16 bytes in IPv6 was bewust, om CLNS te treiteren en er voor te zorgen dan CLNS adressen niet in een IPv6 adres pasten). Cisco had het binnen een paar weken werkend, in 1994. Voorstel bewust afgeschoten.

3) Ze hadden kunnen kiezen voor een heel nieuw "paradigm". Een nieuwe manier van denken. Er waren verschillende voorstellen (google eens naar Nimrod of Noel Chiappa). En dan echte layer-3 problemen oplossen (adres/locator separation, multi-homing, mobility, on the fly renumbering, auto-summarization, etc). Ook bewust afgeschoten.

Er waren dus allerlei andere oplossingen mogelijk. Meer praktische, meer toekomst-gericht, meer compatibel. Maar er is voor de huidige IPv6 gekozen. Zoals ik al zei: IPv6 is ook een politieke keuze geweest (of religeuze, hoe je het net wilt noemen).

[IceTeaGX]

Evengoed nee, vermits er meer dan alleen de adressering is aangepakt. IPv6 is op meer vlakken verbeterd.
Al had 64 bit adressering misschien ook wel voldoende geweest. Eventueel met optie om later gemakkelijk uit te bereiden naar iets groter moest het echt nodig zijn. Zou toch weeral 64 bit per packet overhead uitsparen.

[freaky]

Een zeer belangrijke reden die hier niet genoemd wordt zijn de router tabellen. Die zijn, als het goed is, veel kleiner dan bij 4. Dit komt omdat 4 verspreid zit in vele kleine blokken over de wereld. Bij 6 gaan veel grotere blokken ineens waardoor er veel minder fragmentatie in de address space zit.

Praten hier wel over core routers uiteraard. Niet dat spul dat je thuis hebt staan.

[Verwijderd]

Ik vraag me af hoeveel bestaande ipv4 adressen al jaren niet meer in gebruik zijn omdat ze voor kortstondige reclame/spam werden gebruikt, misschien wordt het tijd om het internet eens een keer schoon te vegen...

[freaky]

Tuurlijk... begin jij? Je hebt echt geen idee.

[Verwijderd]

Als een adres uitgedeeld is, is dat omdat het voor bepaalde of onbepaalde tijd geleased is. Je kunt adressen niet zomaar terugclaimen omdat het weinig of niet gebruikt wordt.

Als ik de laatste emmer benzine ter wereld koop, is dat mijn emmer benzine, ook als ik hem ongebruikt in de garage laat staan.

Daarnaast heb je weinig aan bij elkaar gesprokkelde kleine blokken adressen. Als een bedrijf een blok van 32 adressen heeft, en er maar 25 gebruikt, is het technisch meer werk om de ongebruikte adressen elders uit te delen dan het waard is.

[Metallize]

Dan zullen we in ieder geval genoeg IPv6 adressen hebben tot en met het volgende Millenium

[flippy]

dat zeiden ze ook over ipv4, "dat zal nooit opraken".

hoewel het natuurlijk bij ipv6 ietsjes langer zal duren zal over enkele tientallen jaren ipv6 gewoon moeten worden vervangen voor de toekomstige technieken.

[Verwijderd]

Inderdaad, dat verwachtte men toen niet. Maar er zijn wel zo gruwelijk veel IPv6 adressen ( 2^128 = 340,282,366,920,938,463,463,374,607,431,768,211,456 ) dat als je elk zandkorreltje op alle stranden van de hele wereld een eigen IPv6 adres zou geven, dat je dan nog steeds adressen over had.

Helaas gaat het nogal hard door iedereen maar zo makkelijk een /64 te geven, maar dan nog.

Er zal vast wel een IPv7 komen, maar dan waarschijnlijk niet omdat het aantal IPv6 adressen niet meer toereikend is voor het aantal aardbewoners.

[Herko_ter_Horst]

Het is nog veel sterker: je kunt elk zandkorreltje op alle stranden ter wereld een adres geven uit één enkele /64 en dan hou je nog meer dan de helft over... Of andersom: als je alle adressen zou verdelen over het totaal aan zandkorreltjes, krijgt elke zandkorrel 10 miljoen triljoen adressen

Zie ook: http://itsnobody.wordpres...-addresses-can-ipv6-hold/

[Reactie gewijzigd door Herko_ter_Horst op 23 juli 2024 13:56]

[Netrunner]

Dat zijn leuke facts om te weten !

[Ventieldopje]

3.156 x 10^31 Unique IPv6 addresses that would be assigned after 1 trillion years if a new IPv6 address was assigned at every picosecond.

3.403 x 10^38 IPv6 address space size (128-bit).

Mwa ... iets zegt mij dat dit nooit op gaat raken

[Sfynx]

Zelfs al geef je iedere aardbewoner een /64, dan heb je nog steeds redelijk wat adresjes over.

[Verwijderd]

grappig ook als je iedere aardbewoner 1 ipv6 zou geven:

er zijn:
340,282,366,920,938,463,463,374,607,431,768,211,456 ipv6 adressen

geef je iedere aardbewoner een ipv6 adres, dan zijn er nog ~:
340,282,366,920,938,463,463,374,607,424,768,211,456 ipv6 adressen

even om de schaal te zien

[Reactie gewijzigd door Verwijderd op 23 juli 2024 13:56]

[Netrunner]

dat is vrij ziek.

[Kewne]

Momenteel krijg je bij veel server hosts ook een eigen /64 per gehuurde server. Tunnel providers doen er ook niet al te moeilijk over om iets tussen een /48 en een /64 uit te geven. Zelfs met /48 netwerken zitten we nog steeds op makkelijk 1000x de IPv4 adresruimte, maar ik vind het toch wel erg snel gaan.

Komt nog bij dat een /64 niet voor iedereen genoeg is, ruimte voor meerdere netwerken met autoconfig lijkt me toch wel erg wenselijk voor een kantoor.

[Herko_ter_Horst]

ISPs wordt daarom aangeraden /48s uit te delen. Dat is ook helemaal geen probleem: in de nu publiek beschikbare IPv6 ruimte, zitten genoeg /48s om 8 miljard sites te voorzien van 4000 /48s.

En als dat op is, kan IANA er zo nog eens zo'n blok bijschakelen uit de nu nog ongedefinieerde pool.

Bron: http://rednectar.net/2012...dresses-are-there-really/

[databeestje]

Er is al een IP versie 7, en 8 en 9. 10 is voorbehouden geloof ik, dus we tellen weer verder met 11.

Er zijn wel meerdere IP protocollen, alleen 4 en 6 zijn in grote omloop.

[Verwijderd]

Bron?

[Marcelloz]

7 en 8 zijn er wel ontworpen maar nooit aangeslagen
9 is een april's fool joke
10 is rubbish
bron

[Martinspire]

Dat is natuurlijk erg naïef geweest. Rond die tijd waren er ook al minder ip-adressen dan mensen op aarde waardoor het gewoon een kwestie van tijd was.

[mcDavid]

Misschien zijn we nu ook wel naief. In de tijd dat IPv4 ontwikkeld werd, had men gewoon nooit gedacht dat ieder mens (of bedrijf zelfs) op de wereld ooit een computer zou krijgen. Laat staan een computer met internetverbinding. Tegenwoordig hebben mensen in westerse landen vaak een stuk of 5 computers met netwerkverbinding en dan komen de datacentra en kantoren er nog bij.

Wie weet krijgen we over 10 jaar wel apparaten bestaande uit duizenden nanobots die allemaal hun eigen netwerkverbinding hebben. Ik zou er nu nog geen toepassing voor kunnen verzinnen, maar 30 jaar geleden had ook nooit iemand kunnen verzinnen dat iedereen een internetcomputer in zijn broekzak zou hebben om foto's van de buurman te liken.

[MSalters]

En? Heb je enig idee hoeveel IPv6 addressen er zijn? Als had ik m'n hele huis vol met nanobots, dan nog zou de kleinste standaard allocatie (/48) meer dan genoeg zijn.

[endemion]

Als je alles gaat chippen waar het wel naar lijkt uit te draaien zoals in dat spel Syndicate dan kan het snel gaan met die ipv6 adressen.

Wel jammer dat ff een ip adres onthouden wel erg lastig wordt met 8x4 posities die ook nog eens uit letters en cijfers bestaan.

[Daenney]

Hint: http://datatracker.ietf.org/doc/rfc1035/

[mbb]

Dat gaat waarchijnlijk dus ook het probleem worden; iedereen gaat een allocatie kirijgen want dat verdeelt makkelijker en er is toch genoeg. + ieder apparaat krijgt zijn eigen IP dat niet gerecyvled wordt wanneer het apparaat verouderd is , want 1x uitgeven is voor de politie makkelijker te traceren, etc. Dus over honderd jaar is de boel dan alweer op.

[firest0rm]

iedere auto 1 IP adress vliegtuigen met IP adress
je TV met IP edress

straks zelf je magnatron met IP adress

het kan nog veel gekker!

je fiets met IP adress

[sab]

wikiquote: "IPv6 allows for around 4.8×10²⁸ addresses per person". Zoals MSalters al zegt, zelfs met je persoonlijke leger nanobots wordt het lastig om op te maken.

[windwarrior]

Om hier even op in te haken, er zijn dan ook 6.67 * 10^27 IPv6 adressen per vierkante meter van de aarde, dat haal je niet met nanobots Die zijn dan al lang tegen andere problemen opgelopen, grondstoffen bijvoorbeeld.

[Abomination]

Dat is natuurlijk erg naïef van jou. Rond die tijd was er gewoonweg niet genoeg cpu kracht in de routers om grote adresblokken als ipv6 te kunnen routeren.

[Sissors]

Ik wil niet zeggen dat we het een millenium uithouden met ipv6 (oké dat zal zeker weten niet het geval zijn), maar de adresruimte zal iig geen reden zijn om over enkele tientallen jaren het te vervangen. Er zijn simpelweg zo verschrikkelijk veel ipv6 adressen dat dat geen issue is.

En voordat iemand aankomt met fake 640k quotes, dan heb je geen idee hoeveel ipv6 adressen er zijn. http://xkcd.com/865/

[Tarquin]

Nee, dat is niet zo. Indertijd waren ze gewoon bezig met netwerken op en tussen universiteiten. Ze hadden niet het doel een wereldwijd netwerk te creëeren.
Er bestonden nog niet eens PCs, er waren nog geen mobiele telefoons en er was geen internet.

Laat staan dat ze konden bevroeden dat er op hun netwerk 1 miljard PCs en nog meer telefoons op aangesloten zouden gaan worden.

Dat zie je ook aan de gigantische adressenblokken die de eerste bedrijven toegewezen kregen. Een doorsnee ISP heeft er minder

Hardware, processingtijd en geheugen waren duur, dus ze hebben een keuze gemaakt waarbij zij alle computers in de wereld PLUS alle voorzienbare computers konden aansluiten.

[Verwijderd]

dat zeiden ze ook over ipv4, "dat zal nooit opraken".

Was je erbij ?
Heb je een quote ?
Heb je een link ?

Het Internet zoals wij het kennen (groot, publiek, commercieel, wereldwijd), is begonnen in November 1988. Toen was men zich er al lang van bewust dat 2^32 een klein aantal is. Wij hadden het er in ieder geval al over, tijdens de lunch in 1990 of zo.

http://en.wikipedia.org/wiki/IPv6#Working-group_proposal

By the beginning of 1992, several proposals appeared and by the end of 1992, the IETF announced a call for white papers.

Dat was 20 jaar geleden. En slechts zo'n 3 jaar na het begin van het commerciele Internet.

[Herko_ter_Horst]

dat zeiden ze ook over ipv4, "dat zal nooit opraken".

hoewel het natuurlijk bij ipv6 ietsjes langer zal duren zal over enkele tientallen jaren ipv6 gewoon moeten worden vervangen voor de toekomstige technieken.

"ietsjes langer" zegtie. "enkele tientallen jaren" zegtie. lolwut

Als je 1 triljoen IPv6 adressen (oftewel 250x de totale IPv4 adresspace) per seconde zou uitdelen, zou je over 1 triljoen jaar nog pas 1/10miljoenste van de hoeveelheid IP adressen hebben uitgedeeld...

Dus IPv6 zal vast vervangen worden, maar niet omdat de adressen op zijn.

[Reactie gewijzigd door Herko_ter_Horst op 23 juli 2024 13:56]

[hackerhater]

wellicht dat we problemen krijgen als we andere planeten gaan koloniseren
Maar is dan een planeet-code ervoor niet makkelijker?

[switchboy]

Met de lag tussen mars en de aarde vw de lichtsnelheid zie ik een www en mww niet zomaar aan elkaar gehangen worden. Dus dat levert denk ik geen probleem op.

[Verwijderd]

Ik denk niet dat we het volgende millennium halen met deze cultuur. Onze cultuur kan niet nog 1000 jaar doorgaan met dezelfde paradigma's. Internet incluis. We zullen moeten evolueren en het internet net zo goed.

Iedereen snapt nu wel dat we leven in een tijd van piek olie, piek klimaat, piek alles.

Ik denk dat het systeem van IP adressen vervangen zal worden door iets anders. Dat zal gepaard gaan met een verandering van ICT in haar geheel en de manier waarop we computers gebruiken. Hoe dan ook, 1000 jaar consumptie en 1000 jaar cultuur en levenswijze zoals wij die hanteren kan de aarde niet aan.

Er was geen politieke partij die dat snapte de laatste verkiezingen m.u.v. wellicht van MenS.

[Verwijderd]

Dan is het nu toch zo ver. Gelukkig is er nog wel een voorraad bij de providers, zoals het artikel ook al aanhaalt. De meeste daarvan zijn nu ook wel bezig met IPv6, althans dat mag ik hopen. Bij XS4All kon je volgens mij zelf al een tijd geleden een IPv6 blok aanvragen.

Ben wel benieuwd hoeveel oudere netwerkapparaten er al voorzien zijn van mogelijkheden tot het praten van IPv6. Daar zijn er wel aardig wat van denk ik. Geldt sowieso minder voor intern lijkt mij, ik ken weinig bedrijven die niet genoeg hebben aan de RFC1918 adressen voor hun interne netwerk. Het is ook wel wat handiger, want 10.0.1.12 is wat makkelijker dan FE80:AE::1A:2B:7F .

[musiman]

Er zijn al heel veel gebruikers die routers hebben staan welke geschikt zijn voor IPv6. Je kunt verwachten dat nieuwe gebruikers eerst op het IPv6 netwerk aangesloten worden en later pas de huidige gebruikers, zodat de overgang zo soepel mogelijk gebeurt.

[blorf]

Een nadeel is echter dat ipv4- en ipv6-packets niet compatibel zijn; daardoor is het noodzakelijk dat het hele internet het nieuwe protocol in gebruik neemt.

Hoezo? ipv6 wordt toch al breed ondersteund? Het komt volgens mij neer op een lichte tijdelijke fragmentatie van het internet doordat de bestaande ipv4 nodes geen nodes kunnen bereiken die alleen een ipv6 adres hebben. Waarschijnlijk worden veel bedrijven dat snel zat en stappen vanzelf over. Maar ok, als je het internet definieert als iets waarbij alle deelnemers elkaar allemaal moeten kunnen bereiken wordt de collectieve overstap noodzakelijk. Volgens mij is dat overigens nog nooit het geval geweest met al die landen die de boel naar "eigen inzicht" regulieren.

[Reactie gewijzigd door blorf op 23 juli 2024 13:56]

[zx9r_mario]

Helaas werkt tweakers.nl nog altijd niet via IPv6. Zowat alles wat getweaked kan worden staat beschreven op de site, maar IPv6 zelf uitrollen lukt jullie nog steeds niet na al die jaren?

PS Jullie gebruiken Varnish, die ondersteund ook IPv6. Dit moet toch voor een tweaker te doen zijn?

[Reactie gewijzigd door zx9r_mario op 23 juli 2024 13:56]