"Gelukkig beginnen ook de hoge heren in Brussel te beseffen welke rol het in gebruik nemen van IPv6 speelt voor de verdere ontwikkeling van internet." Met die zin verwezen we naar een rapport van de Europese Commissie waarin werd benadrukt dat een snellere transitie naar IPv6 noodzakelijk was. Er zouden nog maar voor een aantal jaren IPv4-adressen zijn. De overstap naar IPv6 werd een quantumsprong genoemd die snel moest worden genomen om het naderende onheil af te wenden. We publiceerden dat bericht in 2002.
In de jaren erna verschenen veel artikelen over de urgentie om toch echt zo snel mogelijk over te stappen op IPv6. Er kwamen verschillende initiatieven om de internetwereld te overtuigen van de noodzaak, zoals de IPv6 Awards (winnaars: GeenStijl en Xs4all) en World IPv6 Day. De Internet Society riep 6 juni uit tot IPv6-dag, onder het motto 'this time, it's for real'. De eerste editie werd in 2012 gehouden, tien jaar na de waarschuwing van de EU dat de adoptie toch echt sneller moest gaan.
Wie lang roept dat het mis gaat zonder dat er iets mee gebeurt, wordt op een zeker moment niet meer geloofd. Dat is het zogenaamde Boy who cried wolf-effect. Was de zorg dat de adressen opraakten dan onterecht? Nee, dat was het zeker niet. In 2011 deelde RIPE NCC de laatste blokken met IPv4-adressen uit aan providers in Europa, Rusland en West-Azië. Er kwam daarna wat schot in de zaak en providers als UPC, Ziggo, KPN, Belgacom en Telenet maakten bekend te starten met de overstap. Dat kon niet voorkomen dat het eind 2019 echt over en uit was en RIPE de laatste adressen had vergeven.
Hoe staat het er anno 2022 voor, na alle initiatieven en goede voornemens? Volgens Akamai verloopt 50,1 procent van de Belgische en 34 procent van de Nederlandse connecties via IPv6. Google komt tot 56,8 procent voor België en 35,5 procent voor Nederland. In absolute aantallen heeft Nederland overigens al meer IPv6-connecties dan België en bovendien is Nederland volgens RIPE NCC met een flinke inhaalslag bezig. Hoe dan ook, de adressen zijn op en we zijn nog lang niet over op IPv6. Daar merken we weinig van, maar zonder gevolgen is het niet.
Blokken schrapen door RIR's en LIR's
Hoe kan het dat we na tientallen jaren waarschuwen voor het opraken van IPv4-adressen nog altijd niet over zijn, en we nog altijd zo afhankelijk zijn van IPv4? De voornaamste reden is dat er workarounds zijn ontwikkeld. Dat begon al in de jaren negentig. Al in 1992 kwam men tot het besef dat vier bytes, 256 x 256 x 256 x 256, oftewel 4,3 miljard adressen, gezien de groei van het internet te weinig zou zijn. De voorspelling op basis van de snelheid waarmee adressen werden uitgedeeld, was dat er nog voor enkele jaren voorraad was. Die realisatie en het opvolgende werk aan een oplossing leidde eind december 1995 tot de publicatie van RFC1883 van de Internet Engineering Task Force, waarin Internet Protocol versie 6 werd gespecificeerd.
De allocatie van IPv4-adressen was tegen die tijd echter alweer flink teruggevallen. De reden daarvoor lag bij de introductie in 1994 van classless inter-domain routing, of cidr als opvolger van classful networking. In het oude systeem werden blokken van IP-adressen aan organisaties verstrekt op basis van drie klassen: A, B en C. De grootste daarvan, A, bestond uit 24 bits voor host-ID's. Dat zijn 16.777.216 adressen, veel te veel voor zelfs het grootste bedrijf of de grootste organisatie. Ook met blok B van 65.536 adressen kregen organisaties voor die tijd wel erg veel adressen toebedeeld, terwijl de kleinste klasse, C, met een blok van 256 adressen voor grote bedrijven weer aan de krappe kant was. Met andere woorden, veel IP-adressen bleven ongebruikt en de voorraad liep snel leeg.
Cidr bracht daar verandering in, door gebruik te maken van variable-length subnet masking. Daarmee was de allocatie van adressen veel beter af te stemmen op de behoefte van bedrijven en organisaties. Voortaan gaf een suffix achter een IP-adres, de cidr-notatie, het aantal bits van de routeringsprefix aan. Zo geeft 213.239.100.0/22 de 1024 IPv4-adressen van 213.239.100.0 tot 213.239.103.255 weer, want 2addreslengte − prefixlengte, of 232−22 = 210 = 1024 adressen.
Adressen op rantsoen
Het systeem van Regional Internet Registries (RIR's) maakte in de jaren negentig ook dat er wereldwijd voortaan beter toezicht wordt gehouden op het uitdelen van IP-adressen. Dat gebeurt in Europa en Rusland door het Réseaux IP Européens Network Coordination Centre (RIPE NCC), in de VS en Canada door het American Registry for Internet Numbers (ARIN), en in het grootste deel van Azië door het Asia-Pacific Network Information Centre (Apnic)
Nog belangrijker, zo zou blijken, was het toenemende gebruik van network adress translation of nat door providers. Daarmee kan een groot aantal clients met een intern IP-adres achter een gateway met een publiek IPv4-adres worden geplaatst. Bovendien was er het Dynamic Host Configuration Protocol oftewel DHCP. Hiermee konden servers dynamisch IP-adressen toekennen zodat adressen konden worden hergebruikt. Aan het einde van de jaren negentig was het aantal toewijzingen van IPv4-adressen door deze maatregelen alweer zover gedaald dat er nog weinig urgentie was om over te stappen naar IPv6.
Die situatie bleek echter van korte duur, want na 2000 nam het internetgebruik zo snel toe dat het aantal allocaties weer rap groeide. Die stijging van het internetgebruik kwam onder andere door de toenemende populariteit van dsl en kabelinternet, en de opkomst van het mobiele internet met smartphones. In 2010 bereikte de toewijzing van IPv4-adressen zijn piek, met een aantal van bijna 250 miljoen. In de jaren erna nam het aantal noodgedwongen weer af: de adressen gingen op rantsoen.
Wachten op een blokje
Dat laatste kon niet voorkomen dat de adressen opraakten. De Internet Assigned Numbers Authority deelde in 2011 de laatste blokken uit aan de RIR's en in 2012 verstrekte RIPE NCC de laatste /8-blokken aan providers in Europa. Vanaf dat moment konden providers nog in aanmerking komen voor een /22-blok van 1024 IPv4-adressen, maar eind 2019 werden ook de laatste /22-blokken uit het laatste 185.0.0.0/8 blok uitgedeeld. Volgens RIPE was dat het moment van de run-out. Sindsdien is het schrapen naar nieuwe blokken. Aanvankelijk verstrekte RIPE NCC nog wat teruggegeven /23- en /24-blokken van respectievelijk 512 en 256 adressen, maar in november vorig jaar werd ook het allerlaatste herverkregen blok toegewezen.
Sindsdien staan de Local Internet Registries (LIR's) zoals providers en grote internetbedrijven die adressen willen, op een wachtlijst, in de hoop in aanmerking te komen voor een teruggegeven blok van slechts 256 adressen. Het aantal LIR's op die wachtlijst neemt sinds eind vorig jaar flink toe. Ook het aantal dagen dat ze moeten wachten op een restje IPv4 groeit.
60 dollar voor een IPv4-adres
Nu kunnen providers en andere partijen ook op andere manieren aan adressen komen, namelijk via de markt van vraag en aanbod. Vanaf 2012 kunnen LIR's namelijk onderling adresblokken uitwisselen. Ze moeten nog wel een account bij RIPE hebben zodat die organisatie overzicht houdt op wie de eigenaar van welk blok is, en er geldt de restrictie dat ze daarna 24 maanden lang niet opnieuw mogen worden overgedragen. Helemaal vlekkeloos loopt de onderlinge handel niet. "Sinds de run-out in 2019 neemt het aantal transfers van IPv4-adressen nog altijd toe en we moeten fraudezaken en disputen over eigenaarschap afhandelen", aldus RIPE, eind vorig jaar. De organisatie maakte eerder duidelijk dat organisaties documenten vervalsen, en accounts en zelfs IP-blokken kapen om aan adressen te komen. De RIR benadrukt dat het om een klein aantal zaken gaat, maar tegelijkertijd geeft de organisatie toe veel tijd kwijt te zijn aan de onderzoeken.
Het overdragen van blokken IPv4-adressen kan behoorlijk lucratief zijn. In de afgelopen jaren hebben tal van organisaties met voorraden IP-adressen, delen daarvan voor veel geld verkocht. Het gaat dan om grote blokken die ze in de jaren tachtig of negentig hadden ontvangen, maar waar ze niks mee deden.
Zo verkocht de non-profitorganisatie Amateur Radio Digital Communications het 44.192.0.0/10-block in 2019 voor 108 miljoen dollar. In 1981 verkregen radioamateurs de 44.0.0.0/8-reeks, een klasse A-blok van 16,7 miljoen adressen. In 1986 werd dat verdeeld in een 44.0/9-blok voor de VS en een 44.128/9-blok voor de rest van de wereld. Radioamateurs konden die adressen gebruiken voor Amprnet, digitale packetradiocommunicatie tussen netwerken op basis van het Amateur X.25-protocol. Meer dan de helft van de toegewezen adressen lag echter te verstoffen en het zag er ook niet naar uit dat ze nog gebruikt gingen worden: de hoogtijdagen van Amprnet lagen tussen 1988 en 1995.
Amazon op IPv4-jacht
De partij die bereid bleek 108 miljoen dollar neer te tellen voor de 4.194.304 adressen was Amazon, dat ze inzet voor zijn AWS Elastic Compute Cloud. Amazon blijkt meer IPv4-adressen te zoeken en op te kopen. In 2017 kocht het bedrijf een 18.128.0.0/9-blok van zo'n acht miljoen adressen van MIT en een jaar later verkreeg Amazon een 3.0.0.0/8-blok van zestien miljoen IPv4-adressen van GE. In 2020 kocht Amazon de helft van een 43.192.0.0/12-blok dat Apnic en het Japanse WIDE-onderzoeksproject in de verkoop deden als onderdeel van een omvangrijk aanbod. Op basis van publieke informatie van de RIR's ARIN, Apnic en RIPE becijferde Andre Toonk, oprichter van BGPMon, dat Amazon meer dan honderd miljoen IPv4-adressen had. Het waren er 100.750.168 om precies te zijn, waarvan slechts 53 procent echt in gebruik was. Scott Seligman komt tot een lager aantal, mogelijk omdat hij zich puur op AWS richt. Volgens zijn tracker heeft Amazon momenteel 66,3 miljoen IPv4-adressen.
Groei van hoeveelheid IPv4-adressen AWS. Bron: Scott Seligman
Niet alleen Amazon heeft in de loop van de jaren de nodige IPv4-adressen vergaard, ook andere grote cloudproviders hebben dit gedaan. AWS lijkt de grootste pool van adressen te hebben, maar ook Microsoft Azure, Cloudflare en Oracle bezitten grote hoeveelheden. Niet alleen Amerikaanse cloudproviders azen op adressen om hun voorraden aan te vullen. Bij de hiervoor genoemde uitverkoop van Apnic en WIDE namen de Chinese cloudaanbieders Alibaba en Tencent respectievelijk 8 en 4 miljoen IPv4-adressen over.
Het deel van de IPv4-ruimte van internet dat de drie grote cloudbedrijven innemen. Bron: Scott Seligman
Toenemende schaarste, handel in adressen die overgelaten wordt aan de markt en partijen met diepe zakken die aan het hamsteren zijn geslagen: dat kan alleen maar leiden tot prijsstijgingen. Dat is ook precies wat er is gebeurd. Bij afname van /16-blokken betaalden partijen in 2015 nog zo'n 5 dollar per IP-adres, maar dat was eind 2020 al gestegen naar meer dan 20 dollar per IPv4-adres, zo becijferde IPv4 Market Group, dat de transfers van adresblokken tussen verkopers en kopers faciliteert. In die jaren ging het nog om een lineaire verhoging van de prijs. In 2021 steeg de prijs nog sneller, naar meer dan 30 dollar.
Prijzen IPv4-adressen, Hilco-Streambank
Partijen die /17-blokken of lagere aantallen willen, betalen nog meer per adres. Volgens de marktplaats liggen de prijzen daarvan momenteel gemiddeld rond de 38 tot 40 dollar per IPv4-adres. Op de IPv4-marktplaats van Hilco Streambank zijn aanbiedingen met omgerekend meer dan 60 dollar per adres al geen uitzondering meer. Als we het aantal van 66,3 miljoen IPv4-adressen voor AWS aanhouden en daar een lage schatting van 30 dollar per adres op plakken, betekent dit dat Amazon voor 2 miljard dollar aan IPv4-adressen heeft.
Freedom Internets zoektocht naar adressen
De grote vraag is waarom de bigtechbedrijven dat doen. IPv4 zou toch uitgefaseerd moeten worden ten faveure van IPv6? "Het gaat om bedrijven die aan de serverkant erg actief zijn, en servers zullen nog heel lang via IPv4 beschikbaar moeten zijn", vertelt Marco Davids van de SIDN. Die servers moeten immers verbinding kunnen blijven maken met diensten die exclusief via IPv4 bereikbaar zijn. Zolang die er zijn, blijft IPv4 belangrijk. De SIDN is al jaren bezig om IPv6 te promoten, onder andere door korting te geven als domeinnamen via het protocol bereikbaar zijn. De organisatie merkt ook hoe moeizaam de transitie verloopt. Davids: "Het is makkelijker om aan de clientkant over te stappen dan aan de serverkant."
Nat-lapmiddelen
Voor de transitie aan de clientkant zijn er volgens hem in de afgelopen twintig jaar een aantal technieken ontwikkeld. Providers kunnen uit die technieken kiezen om klanten van IPv6 gebruik te laten maken zonder IPv4-compatibilieit te verliezen. Elk van die technieken heeft zijn voor- en nadelen. KPN, Freedom en Zeelandnet van Delta gebruiken dual stack waarbij IPv4- en IPv6-netwerken naast elkaar bestaan. Het nadeel is dat dit prijzig is voor de provider en hij dus de nodige IPv4-adressen moet kunnen toewijzen. Het voordeel is dat klanten nog gewoon over IPv4 kunnen beschikken en zo bijvoorbeeld portforwarding kunnen inzetten en zelfgehoste applicaties kunnen draaien vanaf een systeem met een eigen IP-adres. Dat kan dan weer niet als de provider Carrier Grade nat inzet, zoals NAT44 of NAT444, waarbij een vertaling wordt gemaakt van een intern naar een publiek IPv4-adres.
Mogelijkheden voor self-hosting en uitgebreide peer-to-peertoepassingen via IPv4 zijn er ook een stuk minder bij gebruik van dual stack-lite of DS-lite door een provider zoals Ziggo. Ook hierbij gaat het om een Cgnat-techniek waarbij verkeer van een IPv4-adres wordt getunneld over een op IPv6 gebaseerd netwerk. Het voordeel voor de provider is dat hij geen twee netwerken hoeft te onderhouden en de overstap naar IPv6-only kleiner is. Die stap is nog een stuk kleiner bij gebruik van 464XLAT. Hierbij brengt een DNS64-server de connecties naar servers die alleen via IPv4 bereikbaar zijn in kaart, om verkeer via IPv6 naar een NAT64-gateway te routeren.
Marco Davids: "Als internetgebruiker merk je er weinig van dat de IPv4-adressen op zijn. Het is fijn dat nat zo goed bleek te werken, maar halverwege de jaren negentig hadden we nog de kans om in korte tijd over te stappen op IPv6. Daarna was het niet meer zo makkelijk om te veranderen. We moeten ook steeds meer ballen hoog houden om met Cgnat de levensduur van IPv4 op te rekken. Dat kost meer werk en geld." Bij voip en WebRTC kan het gebruik van nat voor problemen zorgen. Dat is dan weer op te lossen door een apart server-IPv4-adres tussen peers in te zetten, een techniek met de naam traversal using relays around nat. Die server moet bufferen en vereist bandbreedte, met mogelijke vertraging tot gevolg. De inzet van zo'n turn-server is te vermijden door ice in te zetten, interactive connectivity establishment. Dit is een extensie op SIP om peers direct met elkaar te laten communiceren. En zo zijn er meer lapmiddelen voor de nadelen van de verschillende nat-lagen. Een principieel argument tegen de toegenomen afhankelijkheid van nat is dat dit het asymmetrische client-servermodel in stand houdt. Het internet is grotendeels verworden tot een netwerk dat afhankelijk is van centrale partijen, terwijl het van oorsprong als decentrale architectuur is opgezet.
Anco Scholte ter Horst, Freedom Internet
"We hebben een verminderde concurrentiepositie"Een partij die direct problemen ondervond door de IPv4-schaarste, is Freedom Internet. De provider zag zich genoodzaakt IPv4-adressen te leasen. Maar waarom wilde Freedom überhaupt nog die adressen, als IPv6 de toekomst is? We vroegen het Freedom-directeur Anco Scholte ter Horst: "Bij de start hebben we eerst overwogen om de eerste IPv6-only provider van Nederland te worden. Dit bleek echter nog niet haalbaar vanwege de slechte acceptatie van IPv6 in Nederland. Dat betekent dat IPv4 een must was. Omdat wij ook een veeleisende gebruikersgroep kennen, we de Cgnat-oplossingen technisch minder vinden en we iedereen een vast IPv4-adres willen geven, zijn we op zoek gegaan naar beschikbare blokken. Dit is een zoektocht die onverminderd doorgaat." Dat de prijzen voor de adressen zo gestegen zijn, maakt het volgens de directeur nog eens extra moeilijk. "Nadeel hiervan zijn de kosten, aangezien deze adressen schaars zijn en de andere providers allemaal beschikken over blokken die destijds vrij verkrijgbaar waren. Hiermee hebben we dus een verminderde concurrentiepositie."
Dan maar de 127.0.0.0/8-reeks?
De voorstellen om toch nog ergens voorraden IPv4-adressen vandaan te toveren, nemen ook steeds verregaandere vormen aan. Zo is er het IPv4 Unicast Extensions Project, dat voorstelt het Class E-blok 240/4 en delen van de blokken 0/8, 127/8 en 225/8 tot 232/8 vrij te geven om er 419 miljoen beschikbare IPv4-adressen bij te krijgen. Dit zijn onder andere blokken die niet aan hosts zijn toe te wijzen en niet voor algemeen gebruik waren bedoeld.
IANA heeft 240/4 altijd gereserveerd gehouden voor 'toekomstig gebruik' en als er een moment was om dit Class E-blok van 268.435.456 adressen vrij te geven, dan is dat nu wel, zou je zeggen. Maar zoals Apnic stelt, is dit in de afgelopen vijftien jaar vaker voorgesteld en is er in al die tijd geen werkbare manier voorbij gekomen om dit te realiseren. Apnic: "Het resultaat van de moeite die gestoken zou worden in het vrijmaken van deze IPv4-ruimte voor algemeen gebruik, zou de voorspelde datum van het opraken van de overgebleven IPv4-adrespool iets verlengen, terwijl de moeite voor de IPv6-transitie veel meer op zou leveren."
Met name het voorstel om het grootste deel van de 127.0.0.0/8-reeks vrij te geven en alleen een 127.0.0.0/16-reeks nog voor loopback te behouden, kwam de opstellers van de internet drafts op kritiek te staan. Ook de SIDN zag het niet zitten: "Het vereist aanpassingen in de netwerkstacks van alle hosts, in alle netwerkhardware en in alle netwerksoftware. De grootste problemen zullen zijn dat de vrijgekomen adressen in de praktijk niet bruikbaar blijken te zijn vanwege gebrekkige routering/acceptatie, en dat software die voorheen alleen lokaal toegankelijk was ineens van buitenaf benaderd kan worden."
De voorstellen van het IPv4 Unicast Extensions Project zijn niet warm onthaald en het lijkt er dus niet op dat er miljoenen IPv4-adressen bijkomen. De vraag naar adressen blijft groot en de IPv6-transitie blijft zich traag voltrekken. Dat roept de vraag op waar het eindigt met de prijsstijgingen. Davids: "Die gaan nog wel even door. Tegelijkertijd zijn er ook veel positieve ontwikkelingen. De grap is dat big tech behoorlijk goed bezig is. Zo werkt Facebook intern met IPv6. Google, Netflix, LinkedIn: ze zijn allemaal via IPv6 bereikbaar. Er komt een moment dat de IPv6-adoptie een kritiek punt bereikt, zodat het in stand houden van IPv4 niet meer lonend is. Op dat moment stort de IPv4-markt in."
Bij KPN werkt IPv6 zonder problemen op hun APN internet
Dit is dan wel IPv6 singel stack en het IPv4 internet is bereikbaar via hun CG-NAT64
Maar dat zou niet zo een probleem moeten zijn aangezien IPv4 via CG-NAT44 loopt.
Ze geven je een dynamic toegewezen /64 subnet dus voldoende voor een mobile device en alles wat daar achter zou kunnen hangen.
Zakekelijk ben ik ook af en toe bezig met IPv6.
Ik werk ruim 28 jaar fulltime in IT en voornamelijk als network engineer. Ik heb bij grotere en kleine bedrijven gewerkt en ook als consultant bij veel bedrijven over de vloer geweest. Maar IPv6 awareness is over het algemeen vrij laag en de adoptie nog lager.
Ook vrij weinig van mijn netwerk collega's hebben er enige affiniteit mee of willen er echt mee spelen of implementeren. Hierdoor ben ik ook vrij somber gestemd over verdere snelle adoptie van IPv6 in NL. De mede network engineers die ik tegenkom in het wild die wel wat met IPv6 hebben zijn schaars, maar als ik ze tegenkom kan ik er zeer leuke en goede gesprekken mee hebben en veel zeggen ook min of meer het zelfde.
Ik hoop dat wanneer eindelijk meer internet providers IPv6 bieden meer netwerk engineers (in spe) er thuis ook mee gaan spelen.
Wat ook niet heeft geholpen is dat IPv6 support in network equipment lang achter liep of dat je daar een extra licentie voor aan moest schaffen. Of IPv4 wel in ASIC/FPGA kon worden afgehandel maar IPv6 in trage cpu.
Nu de Cloud!
Ik heb zelf bijna alleen ervaring met Microsoft Azure helaas nog niet van AWS of andere cloud providers.
Maar IPv6 support in Azure is ook nog om te huilen. Inbound met Application gateways en publieke load balancers is okay, daar kan je IPv6 adressen aanhangen en werkt prima voor verkeer naar services die er achter hangen toe.
Maar de dual-stack implementatie in de VNETs is echt om te huilen. Werkt exact het zelfde als met IPv4. Als eerste moet je je eigen IPv6 range meenemen om aan de interfaces van je VM's te hangen in je VNET wat dan eigenlijk als soort rfc1918 private ip adressen gebruikt zal worden. Voor communicatie met de buitenwereld moet je bij Azure een publieke IPv6 adres of range afnemen wat je dan als publiek adres aan de interface van je VM hangt. Dan vind er een NAT translatie plaats tussen je private IPv6 en je publieke IPv6.. WTF?!! Het was nou juist de bedoeling om met IPv6 geen NAT meer te gebruiken.
Thuis mee spelen is het probleem niet. Maar dubbel boekhouden kost de klant gewoon extra geld en daar wil de klant niet voor betalen. Mijn ervaring is dat het probleem daar zit en niet bij de geschoolde netwerkbeheerders.
En met netwerkbeheerder bedoel ik inderdaad niet de electro, camera, kassa of lokaal ict dozen schuivende telecom dealer uit het dorp. Die weten inderdaad vaak niet eens wat ipv6 is.
[Reactie gewijzigd door xbeam op 22 juli 2024 16:13]
Dat ben ik voor een groot deel met je eens. Ja, ik ken meerdere bedrijven waar er door financiële redenen nooit wat met IPv6 is gedaan.
Maar meestal is IPv6 door de architecten en engineering niet eens op tafel gekomen.
Omdat er hier in het westen nog vrijwel geen business case is voor IPv6 zijn de implementaties die ik ken vrijwel allemaal gestuurd door engineering zoals bij mijn twee vorige werkgevers.
En om eerlijk te zijn heb persoonlijk maar twee gevallen meegemaakt waar IPv6 nodig was. Er waren IPSec vpn's nodig tussen branch offices o.a. in India waar ze geen fixed IPv4 adressen kregen alleen dynamic met korte lease time. Ze kregen wel static IPv6 prefixes per locatie. Dus tunnels over IPv6 opgezet.
En ook een keer zo'n zelfde scenario met cgnat.
Dat ben ik voor een groot deel met je eens. Ja, ik ken meerdere bedrijven waar er door financiële redenen nooit wat met IPv6 is gedaan.
Maar meestal is IPv6 door de architecten en engineering niet eens op tafel gekomen.
Omdat er hier in het westen nog vrijwel geen business case is voor IPv6 zijn de implementaties die ik ken vrijwel allemaal gestuurd door engineering zoals bij mijn twee vorige werkgevers.
En om eerlijk te zijn heb persoonlijk maar twee gevallen meegemaakt waar IPv6 nodig was.
Mijn kunstje is om in zo'n netwerk m'n laptop in te prikken, een IPv6 router te configureren en na een enkele announce loopt opeens een flink deel van het internetverkeer via mijn laptop. Soms lukt het dan ook om systemen te hebben die strenge firewall/acls hebben op IPv4 maar IPv6 gewoon doorlaten.
Mijn stelling is dan dat je IPv6 niet kan negeren. Als je het niet wil gebruiken zal je het ook echt uit moeten schakelen. Als je er dan toch moeite in gaat steken kun je het misschien maar beter in één keer goed doen en IPv6 wel implementeren zodat je klaar bent voor de toekomst.
Klopt. Als je het niet gebruikt moet het ook echt uit en dicht zitten. Iets wat te vaak vergeten wordt.
Daarin is de koste keuze volledig uitschakelen of wel gebruiken natuurlijk volledig afhankelijke van de grote van het netwerk en verwachte onderhoud daarvan.
[Reactie gewijzigd door xbeam op 22 juli 2024 16:13]
Beter kan je intern gewoon alleen ipv6 gebruiken, en legacy IP als een dienst aanbieden. Of je dat nu via nat64 of iets anders doet kan je per geval bekijken. Werkt perfect, en je draagt bij aan de oplossing in plaats van aan het in stand houden van het probleem.
Ik snap je punt en hebt helemaal gelijk. Alleen zakelijk zijn er heel kleinere bedrijven in Nederland vanwege hun telecom boer nog steeds ip4 only.
Enreach/Voicework wholesale partijen/resellers
Veel bedrijven houden niet van top edge technology zolang ze er extra externe mensen voor moeten inhuren. Zodra 1 antwoord op een vraag of het ook zonder kan dan ja is dan zeggen ze meestal doe dan maar niet. Met als reden de afhankelijkheid van 3e of kosten te verlagen. Geloof me ik doe echt me best maar er zijn er bij die wissel van provider een te groot risico vinden dat zonder telefoon komen te zitten. Ik heb ze er bij zitten die het update van een switches al eng vinden omdat ze bang zijn dat de administratie medewerkers morgenochten de telefoon moeten herstarten omdat ze 1x gehad hebben dat deze geen ip adres meer had.
[Reactie gewijzigd door xbeam op 22 juli 2024 16:13]
Soms lukt het dan ook om systemen te hebben die strenge firewall/acls hebben op IPv4 maar IPv6 gewoon doorlaten.
Mijn vraag: als strenge firewalls op IPv4 gericht zijn, is dan IPv6 een risico? Of is er nu gewoon nog te weinig aandacht voor het inrichten van een firewal/acl op IPv6?
Als je strenge firewall regels heb voor ipv4 dan moet precies de zelfde regels voor ipv6 maken (dubbel boekhouden) anders fiets met ipv6 dwars om/door de ipv4 firewall omdat deze geen weet van elkaar hebben.
Vandaar ook dat wanneer Ipv6 niet gebruikt je ook echt op iedere apparaat in je net werk moet uitzetten en niet zomaar kan negeren
[Reactie gewijzigd door xbeam op 22 juli 2024 16:13]
Ja kan ik mij voorstellen dat je dat zo ervaart, wat de weinige interesse betreft. Ik moet je bekennen dat ik mij er ook nog niet veel mee bezig heb gehouden, zeker zakelijk gezien niet.
Ik persoonlijk heb niet zoveel met netwerk-technologie, servers & clients vind ik interessanter, als systeembeheerder zijnde. Neemt niet weg dat ik mij wel bezig houdt met basis netwerk-werkzaamheden & als ik expertise hierbij nodig heb, dan huur ik die in.
Ik vraag me af hoe lang het nog gaat duren voordat Nederland en Europa providers verplichten IPv6 aan hun klanten te geven. Ook die met eigen modem of router.
Het begint de goede kant op te gaan in ons landje. Ziggo geeft steeds meer mensen (ook die met bridge mode) IPv6. KPN heeft ook keurig Dual stack IPv6 en IPv4. Maar er zijn ook nog steeds verbindingen zonder IPv6. Gisteren leverde ik een T-mobile Thuis glasvezellijn op. Geen IPv6. Eerder dit jaar een KPN EEN MKB (Routit) glasvezellijn. Die kan enkel IPv4. Ze hebben IPv6, dat moet je telefonisch extra aanvragen, maar dat werkt niet met de meegeleverde KPN Box 12. Je moet dus je eigen router gebruiken.
De helpdesks van zowel T-mobile als KPN EEN zijn om te janken op IPv6 gebied. De mensen die daar werken hebben niet eens een Idee wat IPv6 is, laat staan hoe je het moet configureren. Daar moet echt verandering in komen. Een citaat van een helpdesk medewerker afgelopen januari, die niet wist wat een IPv6 adres blok was: “Ah ik zie het al, uw adres is verkeerd doorgegeven. Er staan dubbele punten en letters in. Dat kan niet.”
Ik heb jaren geleden bij Ziggo juist m’n IPv6 om laten zetten naar IPv4 omdat ik anders niet remote bij m’n Plex server kon. Ik weet niet hoe het nu zit maar toen der tijd waren er best aardig wat toepassingen waar IPv6 gewoon niet voor werkte.
Ik heb een /24 en draai zoveel mogelijk op IPv6 om IP adressen te sparen. Bijv iDracs, ILO's. Als ze dat al ondersteunen.
Webservers draai ik op IPv6 en reverse proxy ik via Cloudflare zodat ze toch benaderbaar zijn via IPv4.
Maar inderdaad vaak is IPv6 only onmogelijk. Heel veel applicaties werken dan gewoon niet meer. Bijv bij Docker containers werkt het vaak niet eens.
Maar het wordt wel beter, ik draai ook Plex en heel veel zaken zoals Radarr, Sonarr etc draai ik op VMs met IPv6 only, maar weer gereverse proxied met nginx/cloudflare.
Dat zou ik echt nooit doen, ik zou het altijd via een hopping server (of reverse proxy met additionele beveiliging) bereikbaar maken, of via vpn. Ik vertrouw die interfaces niet genoeg om ze direct vanuit Internet toegankelijk te hebben.
Je past nu in feite gewoon "security through obscurity" toe als er niks tussen zit waarmee je de toegang limiteert vanuit alleen je eigen IPv6-reeks. Als je er wel minimaal een firewall tussen hebt zitten waarmee je de toegang limiteert dan is het natuurlijk een ander verhaal.
Ik vraag me af hoe lang het nog gaat duren voordat Nederland en Europa providers verplichten IPv6 aan hun klanten te geven. Ook die met eigen modem of router.
Dat is overigens altijd al zo geweest, je hoeft maar iets te weten van computers en internet en de kans is 99% dat je meer weet dan de klantenservicemedewerker. Het frustrerende daarbij is dat je vervolgens met tegenzin wordt gedwongen een stappenplan af te gaan van modem resetten enz. terwijl je zeker weet dat het daar niet aan ligt.
Aan de ene kant klopt dat wel, maar anderzijds zou ik zeggen als provider ¨laat ik mijn medewerkers verplicht cursussen laten volgen over het product dat ik verkoop¨.
Providers zijn eigenlijk niet eens het probleem hierin, die hebben er zelfs juist het meeste last van het gebrek aan ipv4. Het zijn juist de grote bedrijven waar altijd wel iets beters te doen is dan ipv6 uitrollen.
Delta fiber die in onze regio (West-Friesland) flink aan het adventeren is, levert geen ipv6 op kpn glaslijnen. Dit zowel zakelijk als privé.
Heb sinds december ipv6 van Ziggo op m'n bridge verbinding maar mijn firewall (Sophos XG) heeft de implementatie nog niet op orde (moet snat gebruiken) daarna werkt het goed behalve Dnat wat weer zonde is van een /56 ip blok welke ik dus niet kan gebruiken.
Verder heeft een groot deel van mijn zakelijke klanten nog steeds geen mogelijkheid om ipv6 te nemen vanuit de provider.
Het probleem ligt hem hier, in mijn ogen, dus niet bij de netwerkbeheerder die onvoldoende kennis heeft maar de providers die het nog niet op grote schaal willen uitrollen.
Wat natuurlijk ook niet helpt is dat de grote jongens, KPN/Ziggo nog een grote voorraad ipv4 hebben en er in Nederland geen tekort is aan ipv4 wat ook de noodzaak om ipv6 uit te rollen niet echt motiveerd.
Er is geen klant van mij die gevraagt heeft, moeten wij ook niet wat met die ipv6, geen één.
Ja ik ben van mening dat we snel door moeten pakken met ipv6, maar de noodzaak is er in Nederland gewoon (nog) niet.
Ik zit hier op een Budget alles in 1 met alleen IPv4. Ik ben blij dat Hurricane Electric nog steeds gratis tunnels aanbiedt voor IPv6, maak er inmiddels al een aantal jaar gebruik van.
Navraag bij Budget een paar maanden geleden maakte duidelijk dat er geen plannen zijn om een whitelabel dienst van KPN (dat is Budget namelijk) te gaan voorzien van IPv6. Het duurde echter wel even voordat ik iemand bij de servicedesk (of is het nou customer success manager?) doorverbonden had gekregen die snapte wat IPv6 is en er ook nog iets zinnigs over kon zeggen. Lage prijzen hebben zo hun keerzijde.
Wat is het nut als eindgebruiker? Alle diensten op het internet ondersteunen (voorlopig) ook IPv4. Als mijn provider (T-Mobile Thuis) IPv6 aan gaat bieden juich ik dat toe, maar tot die tijd sta ik niet te springen om een IPv6-tunnel op te zetten.
[Reactie gewijzigd door Lrrr op 22 juli 2024 16:13]
Klopt, voor veel grote diensten is de bereikbaarheid via IPv4 ook goed geregeld. Maar ls een beetje tweaker wil je toch ook mee in de vaart der volkeren. Zo heb ik wat zitten spelen met de Sandbox VPS van TransIP en dat is IPv6 only. Zo zijn er nog wel wat niche dingetjes die enkel of bij voorkeur met IPv6 werken.
Maar nee, voor het overgrote deel heb je gelijk en is het met IPv4 only ook prima te doen.
IPv6 ondersteund grotere datapakketjes waardoor het in theorie sneller is. Omdat er geen NAT meer nodig bent is de tussenliggende NAT niet meer nodig waardoor het sneller is. Verder heb je nog het feit dat hij autoconfiguration doet waardoor je geen dhcp server mee nodig bent. Dus connected met een netwerk zou sneller moeten zijn. Ook heb je minder kans op overlappende IP-adressen waardoor je minder problemen hiermee kan hebben. IPv6 is gemaakt met security in mind dus hij heeft native ondersteuning voor IPSec. En heel veel verbeteringen voor multicasting en native support voor QoS.
"IPv6 ondersteund grotere datapakketjes waardoor het in theorie sneller is."
De maximale grootte van een IP pakket hangt niet af van welk IP protocol gebruikt wordt, dit hangt af van de ingestelde MTU op ethernet. Als ik wil kan ik zonder problemen IPv4 pakketten van 9600 bytes groot versturen, daar is geen IPv6 voor nodig. Wel moeten alle (tussenliggende) netwerkcomponenten dit ondersteunen.
Sterker nog, door de grootte van de IP header kan er per pakket minder data (payload) worden verstuurd via IPv6 dan IPv4, aangezien een IPv4 header 20 bytes groot is en een IPv6 header 40 bytes. Hierdoor zijn er dus meer IPv6 pakketten nodig om dezelfde hoeveelheid data te transporteren als via IPv4.
Een van de voordelen is dat ik al mijn systemen van buiten kan benaderen zonder gegoochel met NAT.
Daarmee ben ik misschien geen typische gebruiker maar ik ben wel degelijk een eindgebruiker.
Maar het is een beetje een kip-ei verhaal. Omdat het met IPv4 zo moeilijk is om je eigen systemen te bereiken zijn er een hoop workarounds om dat te bereiken, zoals een centraal schakelpunt. Veel webcams en deurbellen zijn zo afhankelijk van een of andere server op internet. Het werkt, maar echt mooi is het niet. In theorie zou je het ook met NAT kunnen doen maar voor velen is dat eigenlijk al te lastig. Met IPv6 heb je alleen een firewall nodig en dat makat het allemaal wat eenvoudiger te overzien.
Er komen steeds meer workarounds (NAT, CGNAT, SNI, STUN, ...) en die brengen steeds complicaties met zich mee. Het configuren van NAT is voor velen te lastig. Met IPv6 heb je geen NAT meer nodig en maar alleen een firewall en dat maakt het allemaal wat overzichtelijker.
Als eindgebruiker zie je dat misschien niet direct maar uiteindelijk betaal je er wel voor.
Waar je ook last van hebt, zonder het echt te weten, is de vertraagde uitrol van nieuwe technieken. Ik denk dat bellen via internet tien of twintig jaar eerder gemeengoed had kunnen zijn als we geen te kort aan IP-adressen hadden gehad.
[Reactie gewijzigd door CAPSLOCK2000 op 22 juli 2024 16:13]
Mja, ik ben wel Tweaker genoeg om zelf te portforwarden of desnoods een VPN op te zetten.
Ik ben het op zich wel eens met je betoog, als de wereld morgen overgaat op IPv6 is dat een dikke duim omhoog van mij. Maar als ik op dit moment mijn eigen verkeer via een IPv6-tunnel ga laten lopen, haal ik daar individueel geen voordeel uit, terwijl ik mijn netwerk dan wel gecompliceerder maak.
Ik vind dat meer een taak van de ISP, maar goed, T-Mobile leeft wat dat betreft nog in de steentijd Nu is T-Mobile natuurlijk ook een stuk goedkoper dan ISPs die wel IPv6 aanbieden (KPN, Ziggo).
[Reactie gewijzigd door Lrrr op 22 juli 2024 16:13]
Dat van HE klopt, rond afgelopen kerst bijvoorbeeld. Maar voor een gratis dienst werd de eerste dag na kerst het probleem wel gefixed. En dat is netjes voor iets waar je niet voor betaalt.
Hoe bevalt de HE tunnel? Betrouwbaar? Als je het zou toepassen op een 1000/1000 T-mobile glasvezellijn, zou je dan een vertraging ondervinden (vergeleken met je IPv4 verkeer) door langere route en wellicht mindere bandbreedte?
Sowieso is de bandbreedte 100Mbps, dus dat is al een factor. Daarnaast is het ipv6 verkeer ingepakt in ipv4 packets, dus meer overhead dan native ipv6.
Beschikbaarheid is goed, maar het is een shared medium dus doordeweek overdag wil de snelheid wel eens fluctueren. Ik gebruik QoS op de tunnel om het wat soepeler te laten werken (cake op Mikrotik).
Overall biedt het mij ipv6, het kost niets, en voor wat ik doe is 100Mbps meer dan genoeg.
Dat kan best wel denk ik, hebben ze met vrije modemkeuze ook gedaan. Alleen zouden ze zoiets bij voorkeur Europees en wereldwijd regelen anders blijven het lokale initiatieven...
alsjeblieft, heb het nou niet over "quantumsprong" als iets groots. Een quantumsprong is de kleinst mogelijke energetische veranderingin het universum...
Prive ben Ik al jaren lang bezig met IPv6, eerst vis XS4All via adsl met 6bone met tunnel broker en later native. Dat was in de tijd dat xs4all ook nog 4 ip addressen aan klanten gaf (voor kleine bijbetaling dacht ik?).
Toen ik overstapte op kabel internet bij Zeelandnet (Delta) via verschillende brokers SixXS en he.net.
Daarna heb ik meegewerkt aan de proef met IPv6 bij Zeelandnet (Delta). waarvan ik uiteindelijk een hele poos een happy (en af en toe ook minder happy. waren soms kleine issues in de implementatie) gebruiker ben geweest. Ik zag in de stats van m'n router (mbv netflow) dat er door de jaren heen het percentage ipv6 verkeer omhoog ging. Tot uiteindelijk vaak rond de 70% - 80%. Wat voor een groot deel ook komt doordat een aantal streaming diensten zoals Netflix via IPv6 werken.
Wanneer ik minder streamde en meer van bittorent gebruik maakte ging het vaak flink omlaag tot onder de 50%
Groot was mijn verbazing toen ik overstapte op glasvezel van Delta dat ik geen IPv6 meer had. WTF!!
Erg jammer, van een vooruitstrevende provider die als 2de provider in NL (na XS4All) IPv6 uitrolde voor al hun consumenten. Nu dus weer terug te tijd in naar IPv4 only via "de aansluiting van de toekomst genaamd glasvezel"
Ik had zo'n mooi setup met meerdere vlans met ieder eigen IPv6 prefix etc.
Weer tunnel brokers geprobeerd.. maar dan kom ik niet hoger dan 100mbit wat een beetje jammer is van m'n 1gbps glas aansluiting.
Dus noodgedwongen terug naar IPv4.
Binnenkort krijg ik hier ook een KPN glas aansluiting dan ben ik ook van plan om over te stappen en dan overweeg ik Freedom Internet. Voornamelijk vanwege IPv6. Het is gewoon een principieel dingetje, nog geen technische noodzaak,
[Reactie gewijzigd door JustVodka op 22 juli 2024 16:13]
Wordt tijd dat juist die ip4-hamster-tech hun verantwoordelijkheid nemen. Een IPv6 address op load balancer lukt dan nog, maar IPv6 op compute is vaak niet mogelijk. Dit zou al erg veel schelen. En wat te denken van de inkomende mailservers (live/hotmail), deze luisteren alleen op ipv4.
Thuis zit ik in een oud UPC gebied waardoor ik geen IPv6 DS kan krijgen in bridged mode. Rumors dat dat in 2022 wel kan(modem keuzevrijheid?)
De Internet Assigned Numbers Authority deelde in 2011 de laatste blokken uit aan de rir's en in 2012 verstrekte RIPE NCC de laatste /8-blokken aan providers in Europa.
Dit klopt niet helemaal. RIPE NCC deelde vanaf 2012 uit hun laatste /8 (185/8) blokken uit, om precies te zijn één /22 per LIR. Gelukkig niet complete /8's
Vanaf 2012 kunnen LIR's namelijk onderling adresblokken uitwisselen. Ze moeten nog wel een account bij RIPE hebben zodat die organisatie overzicht houdt op wie de eigenaar van welk blok is, en er geldt de restrictie dat ze daarna 24 maanden lang niet opnieuw mogen worden overgedragen.
Dit is wat krom geschreven. Je bent een LIR (Local Internet Registry) als je een member bij RIPE NCC bent. Je bent dan ook direct onderdeel van de RIPE community.
Op enkele andere plekken worden RIPE (de community) en RIPE NCC (het Network Coordination Centre) door elkaar gehaald. Voor meer info:
Ik heb een aantal jaar geleden XS4ALL gehad, dual stack, Echt perfect. Toen der tijd begon ik pas te experimenteren met self hosting. Omdat het prijsverschil vrij groot was t.o.v. KPN, Ben ik overgestapt. Want het glas van KPN had ook IPv6, vast ipv4(onofficieel), en kon eigen router gebruiken achter de ft/nt.
Maar na verloop van jaren en prijsstijgingen, werd het aantrekkelijker, omdat we geen lineaire tv meer keken om over te stappen naar T-Mobile thuis.
2 nadelen van T-Mobile, het gaat alsnog over KPN netwerk met max 100mbp/s up/down en geen IPv6. Ik moet zeggen, 100mbp/s up down is voldoende 95% van de tijd. Nu host ik zelf Nextcloud, en als tweaker zijnde wil ik ook graag dit IPv6 beschikbaar hebben, om toekomst bestendig te zijn en hier kennis over op te doen.
:strip_exif()/i/2004987920.png?f=thumblarge)
In de jaren erna verschenen veel artikelen over de urgentie om toch echt zo snel mogelijk over te stappen op IPv6. Er kwamen verschillende initiatieven om de internetwereld te overtuigen van de noodzaak, zoals de IPv6 Awards (winnaars: GeenStijl en Xs4all) en World IPv6 Day. De Internet Society riep 6 juni uit tot IPv6-dag, onder het motto 'this time, it's for real'. De eerste editie werd in 2012 gehouden, tien jaar na de waarschuwing van de EU dat de adoptie toch echt sneller moest gaan./i/2004987918.png?f=imagenormal)
:strip_exif()/i/2004968284.jpeg?f=imagenormal)
:strip_exif()/i/2004968338.jpeg?f=imagenormal)
/i/2004968344.png?f=imagenormal)
/i/2004987938.png?f=imagenormal)
Zo verkocht de non-profitorganisatie Amateur Radio Digital Communications het 44.192.0.0/10-block in 2019 /i/2004989470.webp?f=imagenormal)
/i/2004986698.png?f=imagenormal)
/i/2004989746.png?f=imagenormal)
:strip_exif()/i/2004989740.jpeg?f=imagenormal)
/i/2004989736.png?f=imagenormal)
:fill(white):strip_exif()/i/2004989472.jpeg?f=imagemedium)
:strip_icc():strip_exif()/i/2004816166.jpeg?f=fpa_thumb)
/i/1338557512.png?f=fpa_thumb)
:strip_icc():strip_exif()/i/1296735696.jpeg?f=fpa_thumb)
/i/2004804258.png?f=fpa)
:strip_exif()/i/2005404652.jpeg?f=fpa)
/i/2005118682.png?f=fpa)
:strip_exif()/u/10546/S.gif?f=community){kind=small}
:strip_icc():strip_exif()/u/39485/crop5b6d63a9ef6f9.jpeg?f=community){kind=small}
:strip_icc():strip_exif()/u/79614/Family-Guy-Victory-is-Ours.jpg?f=community){kind=small}
/u/1533218/crop6202456a20713.png?f=community){kind=small}
/u/25873/crop622f02c12b62e_cropped.png?f=community){kind=small}
:strip_icc():strip_exif()/u/71325/blablaleet.jpg?f=community){kind=small}
:strip_exif()/u/290839/crop5b757283a589c_cropped.gif?f=community){kind=small}
:strip_icc():strip_exif()/u/78725/train-icon3.jpg?f=community){kind=small}
/u/399457/crop5a9e7c5ce5925_cropped.png?f=community){kind=small}
/u/8/oog3.png?f=community){kind=small}
:strip_icc():strip_exif()/u/9023/crop586ff6dbba130_cropped.jpeg?f=community){kind=small}
:strip_icc():strip_exif()/u/436304/14020.jpg?f=community){kind=small}
/u/96077/crop5b8d7c89bae9d_cropped.png?f=community){kind=small}
/u/34556/welles60x60.PNG?f=community){kind=small}
Nu is T-Mobile natuurlijk ook een stuk goedkoper dan ISPs die wel IPv6 aanbieden (KPN, Ziggo).
/u/192449/crop5b7e8477db46e_cropped.png?f=community){kind=small}
:strip_exif()/u/13101/icon.gif?f=community){kind=icon}