AWS gaat geld vragen voor gebruik van publieke IPv4-adressen

Amazon Web Services gaat geld vragen voor publieke IPv4-adressen voor publieke clouddiensten en vpn's. De IPv4-adressen voor EC2-instances zijn inmiddels te schaars om weg te geven bij diensten als Virtual Private Cloud, zegt Amazon.

Vanaf 1 februari volgend jaar gaan IPv4-adressen 0,005 dollar per uur kosten, schrijft Amazon. Het gaat om publieke IPv4-adressen voor diensten als databases en clouddiensten. AWS noemt specifiek Elastic Compute Cloud (EC2), Relational Database Service en Elastic Kubernetes Service-nodes als die in Virtual Private Cloud, Global Accelerator of de vpn-tunnel zijn gekoppeld. De kosten gelden nu voor actieve IPv4-adressen en niet alleen voor adressen die niet actief aan een dienst zijn gekoppeld. Dat laatste kostte al geld.

AWS IPv4 prijsstijging

De gratis tier van Elastic Compute Cloud of EC2 kan het eerste jaar gratis worden gebruikt vanaf februari volgend jaar. Ook gaat het geen geld kosten als klanten hun eigen IP-adressen gebruiken in AWS. Amazon wijst klanten op de Cost Explorer-tool, zodat ze kunnen uitrekenen wat het gebruik van IPv4-adressen hen gaat kosten.

Volgens Amazon zijn de nieuwe prijzen nodig om de schaarste van IPv4-adressen op te vangen. "De kosten om een individueel publiek IPv4-adres aan te vragen zijn met 300 procent gestegen in de afgelopen vijf jaar", zegt het bedrijf. "Deze prijswijziging dekt onze kosten en is bedoeld om gebruikers aan te moedigen zuiniger met hun publieke IPv4-adressen om te gaan en na te denken over de adoptie van IPv6." De handel in IPv4-adressen wordt inderdaad snel opgedreven; Tweakers schreef vorig jaar al een achtergrondartikel over de prijsstijgingen van IPv4 door hamstergedrag van cloudbedrijven.

Door Tijs Hofmans

Nieuwscoördinator

01-08-2023 • 08:42

252

Submitter: Anonymoussaurus

Reacties (252)

252
250
138
3
0
86
Wijzig sortering
Als bedrijf schaarste als excuus noemen en dan geen onderbouwing geven is mij te makkelijk. AWS is een van de grootste opkopers van IPv4 in de afgelopen jaren. Ze hebben daarmee niet alleen heel veel IPv4 adressen bij anderen weggekocht, maar houden ook een groot deel ongebruikt.

Amazon heeft afgelopen jaren ongeveer 100.000.000 ipv4 adressen opgekocht. Ongeveer de helft willen ze gebruiken voor AWS, waarvan onbekend is hoeveel er werkelijk verkeer heeft of werkelijk beschikbaar is of wat ze tegen houden. De totale 'schaarste' lijkt dus vooral te bestaan bestaan omdat ze zelf opkopen en meer dan 50.000.000 IPv4 adressen niet willen gebruiken. Natuurlijk is het redelijk dat ze geen schaarste willen om klanten niets meer te kunnen leveren, en dus wat adressen achter de hand houden. Maar dit soort aantallen inkopen vraagt dan wel om verantwoording hoe ze schaarste zelf veroorzaken om daaraan dan te verdienen.
Iedereen weet al jaren dat er enorme IPv4 schaarste is, het is niet alleen Amazon die dit zegt. Zelfs als ze 50 miljoen adressen ongebruikt zouden laten is dat een druppel op de gloeiende plaat op het totaal van 4 miljard adressen. Als ze zo veel mogelijk AWS klanten op IPv6-only zetten, kunnen ze de overgebleven adressen efficienter gebruiken voor NAT64 gateways en IPv4 loadbalancers, waar meerdere klanten profijt van hebben.
Schaarste is te weinig beschikbaarheid bij de vraag. Je kan als aanbieder (AWS) niet zomaar van gebrek aan beschikbaar aanbod spreken als je ondertussen kennelijk opzettelijk de beschikbaarheid op de markt en naar je eigen klanten aan het verminderen bent, door het massaal op te kopen en achter te houden. Dan is er namelijk gebrek aan wil beschikbaar te maken, niet zomaar een 'gebrek' aan eigendom of beschikbaarheid zelf. Natuurlijk kan het bedrijf dat schaarste willen noemen om klanten te overtuigen dat die geld moeten gaan betalen, en die klanten ervaren schaarste als gevolg van was AWS aan keuzes maakt. Maar dan mag er op zijn minst een uitleg zijn waarom ze zoveel adressen in bezit hebben maar weigeren dat beschikbaar te maken om van schaarste te spreken. Want voor AWS is dat bezit geen schaarste, eerder een enorme beschikbaarheid.
Maar ze zijn het niet "achter aan het houden" of "weigeren" het beschikbaar te maken: als je betaalt kan je er gewoon gebruik van maken. Amazon maakt enorme kosten om deze adresruimte aan te schaffen op de tweedehands markt, dan is het toch niet meer dan normaal dat je er voor moet betalen als je het wil gebruiken?

AWS heeft een operationele adressenreserve zodat ze niet direct nee hoeven te verkopen. Ze gaan er terecht van uit dat ze de komende jaren zullen blijven groeien, terwijl het steeds moeilijker zal worden om aan extra adressen te komen. Je kan twisten over het formaat van de reserve, maar als je het formaat van AWS hebt is een reserve van een paar miljoen adressen compleet normaal.
Maar ze zijn het niet "achter aan het houden" of "weigeren" het beschikbaar te maken: als je betaalt kan je er gewoon gebruik van maken.
AWS is al jaren IPv4 space aan het opkopen waardoor ze meer aanbod hebben dan er vraag is vanuit hun klanten. Een groot deel van de IPv4 space hebben ze niet in gebruik, en dat lijkt niet omdat er meer vraag is dan aanbod. Dan is vragen om betalen niet door te weinig beschikbaarheid, hooguit omdat ze graag bepalen dat er voor die beschikbaarheid, die ze ook zelf bepalen, betaald moet worden.
AWS is enorm snel groeiend, en heeft niet alleen IPv4 ruimte nodig voor de klanten van nu, ze moeten ook de ruimte hebben voor de klanten van morgen.
Een bedrijf maakt meestal een inschatting hoe hun investering (in dit geval in IPv4 en gebruik en bewaren daarvan) het meeste waard is. Dus het bewaren is niet zomaar omdat ze groei of gelijkblijvende vraag naar IPv4 verwachten, maar omdat ze zelf eisen stellen hoe, wanneer en hoeveel winst ze uit hun investering in IPv4 willen hebben. Zolang AWS geen duidelijkheid wil geven over hun eisen voor hun winst is zulke grote voorraad niet zomaar redelijker dan het argument schaarste. Zeker niet aangezien groei niet zomaar doorzet, aandeelhouders niet zomaar lang willen wachten op winst uit hun investering en investeringen in ipv4 niet zomaar waardevast zijn of blijven.
Ook zonder AWS zou er schaarste zijn. Er zijn immers maar half zoveel IPv4-adressen als aardbewoners, en de meesten hebben meer dan één apparaat om aan te sluiten. Heb je maar één adres en meerdere apparaten en wil je een apparaat van buiten bereikbaar maken dan moet je een regel in je router aanmaken, wat met IPv6 niet nodig is. Maar veel gebruikers zitten zelf al achter NAT vanwege te weinig adressen; dan lukt dat niet.
Het een sluit het ander niet uit. Ieder adres dat Amazon koopt kan niet door een ander worden gekocht. Dat is vast niet het doel van Amazon maar het komt ook niet slecht uit.
Als ze zo schaar zijn waarom heb ik dan een vast IPv4 adres op mijn Fritz!Box van KPN? Ik heb er een servertje achter hangen.
In Nederland kwam internetgebruik vroeg op gang. In die tijd waren IPv4-adressen bijna gratis, er werd meer gekeken naar wat internetaanbieders konden gebruiken en redelijk was, dan om niet onnodig veel adressen uit te geven. Nederland zit dan ook relatief ruim in de hoeveelheid IPv4-adressen, Nederland heeft 2272 IPv4-adressen per 1000 inwoners en staat daarmee op de 12e plaats van de wereld.

Het is om die reden dat Nederlandse aanbieders vaste IPv4-adressen nog kunnen volhouden. In veel andere landen is dit totale weelde. Maar juist omdat IPv4-adressen zoveel waard zijn en internetaanbieders geen nieuwe adressen meer kunnen krijgen, is het niet vanzelfsprekend dat dit zo blijft. En beter gezegd, het is al niet meer zo: Bestaande klanten houden vooralsnog hun adres, maar bij een nieuwe verbinding is het al heel gebruikelijk dat je CGNAT moet gebruiken, (maar met dan vaak wel IPv6 en de royale hoeveelheid sdressen die daarbij horen erbij).
Een /24 block leasen kost bij diverse veiligen zo'n $129/maand. Bij Amazon mag je daar ruim $900 voor neertellen.

Schaarste is echt, de prijzen gaan omhoog en niemand verwacht dat AWS de goedkoopste is. Maar 800% duurder dan de markt is wel erg stevig hoor.

Edit: voor mensen die AWS gebruiken: zelf leasen dus, en dan de BYOIP dienst van AWS gebruiken.

[Reactie gewijzigd door NielsFL op 27 juli 2024 07:19]

AWS is dan ook niet de goedkoopste aanbieder van producten. Een beetje server die mij 25k nieuw kost (2 GPU, 2 Xeon, 1 TB RAM) en 5 jaar meegaat kost al snel 50k/jaar om op AWS te draaien + de kosten van het verkeer + de opslag.
Nu vergelijk je on prem gebruik met een cloud oplossing. Dit moet je in mij ogen alleen niet doen. Als je een cloud oplossing gebruikt, heb je ook voordelen die je geld besparen die je met on prem niet hebt: een server schalen op de minimale grote voor een enkel doel en uit zetten of terug schalen op de momenten dat je hem niet gebruikt. Dit kan je niet als je de server aanschaft en over 5 jaar afschrijft. Die kosten worden nooit minder…
Je omgeving zou ik ook anders inrichten; in plaats van een server die alles voor een stack kan draaien, koppel je kleinere VMs en (voornamelijk) losse specialistische diensten aan elkaar om een oplossing te bouwen.

En ik zou ook de beheer kosten niet vergeten. Voor 50K per jaar heb je geen systeem beheerders in dienst die de server draaiende houden. Dit is een specialisme dat je niet kunt verwachten van de ontwikkelaars die de applicaties die op de server draaien ontwikkelen.

Jouw berekening klopt, maar is in mijn ogen ook de grootste fout die gemaakt wordt bij cloud migraties. Als je IT infra in de cloud hetzelfde inricht als on prem, is het veel duurder en net zo inflexibel. Je zult ie hele infrastructuur moeten herzien on de voordelen te kunnen pakken.

De ervaring waaruit ik o.a. spreek: Door de stack Cloud-native te ontwerpen zijn de kosten van de BI stack waar ik verantwoordelijk voor ben door drie gegaan en kan het meer. Ik kan zelf een stack beheren die ik met geen mogelijkheid zelf had kunnen configureren.
Dat weet ik, je kunt echter een colo vinden voor de prijs van het verkeer en de opslag die ik aanhaalde.

Daarnaast heb je nog steeds je server admins nodig bij AWS, de cloud doet je setup niet en in vele gevallen zelfs meer want je hebt meer “systemen” die nu geïnventariseerd en geconfigureerd en beveiligd moeten worden en dan moet je ook nog steeds je backups regelen, hopelijk naar een andere cloud die dan andere tooling gebruikt.
100.000.000 klinkt natuurlijk naar veel, en dat zijn het ook maar er zijn ruim 4 miljard IP addressen waarvan een deel ontoegankelijk. Dus Amazon bezit 2,5% van alle addressen waarvan 1,25% publiekelijk beschikbaar zijn. Dat maakt de reden nog steeds niet minder relevant er zijn gewoon beperkt addressen beschikbaar ook met wat Amazon achter de hand houdt (voor eigen gebruik?).

Natuurlijk draait het om geld en creeert Amazon voor een klein deel zelf die schaarste maar tegelijkertijd het kost gewoon geld. IP addressen kosten gewoon geld en dat probeert Amazon te vercommercialiseren maar tegelijkertijd als klant dien je daar ook gewoon aandacht aan te geven.

Ik heb twee bedrijven en ik heb hier totaal geen moeite mee, maar ik heb wel moeite ermee als ontwikkelaars kosten voor lief nemen zonder daar bij stil te staan. Het "misbruiken" van een ip address is niets anders dan ook onnodig instances te laten draaien of onnodig grote instances te draaien.
Het "misbruiken" van een ip address is niets anders dan ook onnodig instances te laten draaien of onnodig grote instances te draaien.
Dat is geen redelijk uitgangspunt, omdat je daarmee negeert dat AWS geen enkele onderbouwing geeft waarom zij acceptabel 'nodig' zoveel IPv4 space hebben maar niet willen inzetten. Natuurlijk kun je het hun klanten kwalijk nemen dat die bijbragen aan de schaarste, maar het nieuws is dat AWS voor hun eigen klanten schaarste als excuus gebruikt, terwijl ze een enorme 'voorraad' hebben waarvoor ze geen verantwoording afleggen.

[Reactie gewijzigd door kodak op 27 juli 2024 07:19]

Amazon levert clouddiensten, en moet dus IPv4-addressen hebben. Als deze op zijn, kunnen ze niet meer groeien en hebben ze een serieus probleem. Het is dus héél normaal om een voorraad aan ongebruikte adressen te hebben, zodat je niet iedere week in totale paniek bent omdat je addressen weer eens op zijn. AWS groeide in 2021 bijvoorbeeld met 40% (omzet, maar het aantal gebruikte addressen zal ook flink zijn toegenomen). Ze hebben de groeiruimte dus echt nodig, en hebben in het verleden daarom grof geld neergelegd om ongebruikte adresruimte over te nemen.

Maar IPv4 addressen zijn eindig, en als iedere klant van AWS er zomaar een paar gratis kan claimen zijn ze zó verdwenen. Door er nu al geld voor te gaan vragen zorg je er voor dat mensen er alleen eentje reserveren als ze deze daadwerkelijk nodig hebben - en dus niet zomaar iedere server eentje toekennen "omdat dat lekker gemakkelijk is". Als je pas geld begint te vragen als ze op zijn, ben je véél te laat.

Je wekt de suggestie dat Amazon alles aan het opkopen is alleen maar zodat ze woekerprijzen kunnen vragen, maar dat is simpelweg niet het geval.
Ik stel dat AWS geen redelijke onderbouwing geeft. Enorm veel IPv4-space niet gebruiken, zeker als uit niets blijkt hoeveel die voorraad volgens hun komende tijd aangesproken moet worden of zelfs kan groeien, is niet zomaar een redelijke marge om van schaarste voor klanten te spreken. Vanaf het bestaan van AWS was het anders al een excuus geweest om geld te vragen, dus is simpel stellen dat schaarste het excuus is dan geen redelijke verklaring voor de huidige situatie. Het bedrijf heeft als hoofddoel winst maken. Als ze miljoenen uitgegeven hebben aan ipv4-space dan willen ze die investering minimaal terug en liefst met winst. Het is dus niet onredelijk om aan te nemen dat ze marges opzettelijk ruim nemen om nu meer winst te maken, in plaats van over een paar jaar misschien meer winst te maken. Het kan zelfs zijn dat ze tot de conclussie zijn gekomen dat er een risico is dat ze de ongebruikte IPv4 space niet mogen houden omdat het zo schaars is en de uitrol van ipv6 te langzaam. Want ipv4 space is niet alleen uitgegeven om er winst op te maken.

[Reactie gewijzigd door kodak op 27 juli 2024 07:19]

Weet niet of dat kan, zoniet zou het goed zijn als ARIN die in Noord-America over de uitgifte van ip adressen gaat zou zeggen: gebruik de ip adressen en anders trekken we ze terug en geven ze opnieuw uit.
Amazon heeft afgelopen jaren ongeveer 100.000.000 ipv4 adressen opgekocht.
M.a.w. ze kopen een goed dat hun klanten nodig hebben, en verhuren dat per uur. Net als alle andere onderdelen van hun dienstverlening. Op zich niet vreemd.

Als Amazon zegt dat het met schaarste te maken heeft geloof ik dat wel. Ze handelen stevig in IP adressen en zullen echt wel een goed inzicht in de markt hebben.
De reden dat ze er zoveel kopen, maar misschien nog niet gebruiken, is verwachte toekomstige schaarste. Als je nu niet koopt, heb je straks niets voor je klanten.

Bovendien is het een goed idee om een 'schaars goed' te beprijzen. De ervaring leert dat als iets gratis is er niet zuinig mee wordt omgegaan. Dat belemmert de oplossing, de transitie naar IPv6. Over het algemeen beweegt men alleen als het anders geld gaat kosten.
Als ze het zo goed kunnen onderbouwen dan zou ik juist verwachten dat ze dat ook doen, in plaats van weglaten. Het instemmen omdat een bedrijf slechts een bewering doet die je als klant geld kost klinkt niet verstandig als het bedrijf een winstdoel heeft en je als klanten zo jaarlijks miljoenen extra gaat betalen terwijl je er niet duidelijk iets extra voor terug krijgt.
Euh, hoe moeten ze ipv4 aanbieden aan hun klanten, als ze geen ipv4 adressen hebben om ze te geven?

Dus dat aws adressen koopt om hun dienstverlening in stand te houden, is toch helemaal niet gek?
Top! Hoe sneller IPv4 te duur wordt om te gebruiken, hoe sneller bedrijven IPv6 gaan gebruiken.

Je ziet nog steeds stacks op AWS draaien die gewoon ELB/ALB gebruiken maar IPv4-only zijn terwijl daar al gewoon IPv6 support in zit.

We moeten en zullen met zijn allen er voor moeten zorgen dat het internet zo snel mogelijk naar IPv6 over is.

Google, Meta, LinkedIn, het doet allemaal al jaaaaaaaaren IPv6 en nog steeds zijn er mensen die zeggen dat het niet kan.

Maak het maar 2 of 3x zo duur AWS, dan gaan mensen nog sneller nadenken om IPv4 uit te zetten.
Het probleem zit hem in de ip v4 infra die men al heeft draaien. Die zal je moeten afschrijven en vervangen. Die kosten zijn veel hoger dan de oplopende TCO kosten.
Eerder gaf iemand hier al het voorbeeld van de firewall die zijn organisatie gebruikt.
Dat zal toch echt een keer moeten gaan gebeuren. En daar in 2023 pas aan gaan denken betekend toch echt dat je hebt liggen slapen de afgelopen jaren.

Nee, ik ben persoonlijk best wel klaar met allemaal redenen waarom het niet kan. Al jaren lang negeren grote groepen mensen het en blijven vervolgens ook nog eens argumenten zoeken waarom iets niet kan.

4,3 miljard adressen is simpelweg te weinig voor deze hele planeet en alle plannen die we nog hebben.
Inderdaad, hier bij ons op de firma zie ik net hetzelfde gebeuren. Recent hebben ze eindelijk een eigen IPv4 subnet ontvangen en als ik dan de vraag stel waarom we de interconnect tussen kantoren niet via IPv6 zouden opzetten, staat men met een mond vol tanden. Men heeft het niet eens overwogen, niet over nagedacht.
Die mentaliteit zie je nog te vaak en dan krijg je dit soort fratsen. Legacy direct weer introduceren.

Het kan allemaal prima via IPv6, allemaal niet zo lastig. Maar je moet het willen en gewoon doen.
Mensen zijn gewoonte dieren, daarbij heb ik de indruk dat ruim 80% van de 'IT'ers geen flauw benul heeft hoe IPv6 op te zetten.
Beheerders hebben geen zin om zulke idiote lange IP-adressen in te tikken. Bijv. bij een ping-opdracht. En ze hebben daar geen zin in, omdat ze onder druk van hun bazen staan om meer/sneller te werken. Verder is 4x een getal tot 255 mentaal makkelijker te handlen, dan zo'n lang adres dat hexidecimaal geschreven wordt. Voor het internet is IPv6 voorlopig genoeg; maar vanuit 't oogpunt van de mens is 't op delen lastiger geworden.
Daar hebben we toch host namen voor? Je kan het jezelf heel makkelijk maken daarin. Zelf maak ik geen gebruik van om IP adressen te onthouden, stukken makkelijker om hostnames te onthouden (zelfs als het IP static is).

En zelfs als je eens een IP adres nodig heb kan je de hostname gewoon ff pingen om erachter te komen.

[Reactie gewijzigd door Cybergamer op 27 juli 2024 07:19]

Maar daarvoor moet DNS wel goed werken. Ik heb met regelmaat problemen waar de DNS niet snel genoeg wordt bijgewerkt of het systeem registreert zich niet met een hostname bij DHCP etc etc
IPv6 kan ingekort worden. In elke groep van vier cijfers kunnen de voorloopnullen worden weggelaten. opeenvolgende hexadecimale velden. Als meerdere dubbele punten achter elkaar staan dan mogen ze tot twee dubbele punten gereduceerd worden. Dit mag echter niet meer dan een keer binnen een IPv6-adres.

Maar ik snap het niet gebruiken van IPv6, het oogt nog steeds niet lekker met die rits hex getallen.
Ik stel voor nog 2x een octet bovenop IPv4 te gooien om het simpel te houden IPv4v2
T.a.v. IBAN-bankrekeningnummers ogen ook niet prettig t.o.v. de oude Nederlandse nummers. Toch hoor ik weinig gemopper.
T.a.v. IBAN-bankrekeningnummers ogen ook niet prettig t.o.v. de oude Nederlandse nummers. Toch hoor ik weinig gemopper.
Het verschil tussen IBAN-nummer en oud nummer is kleiner. Verder kan je bank-app/phone/PC je IBAN onthouden.
Ik zal je een geheimpje verklappen: Je DNS kan je ipv6-adres onthouden!
Het gaat pas mis als je de de facto standaard als "legacy" weg probeert te zetten en probeert vernieuwing te forceren terwijl er met de oude manier eigenlijk niks mis was. Dit zie je veel te vaak tegenwoordig. Bij sommigen is alles wat ouder is dan een paar jaar ineens "legacy" en moet perse vervangen worden door de "flavour of the year". Vooral javascript frameworks is een drama. Sommige bedrijven zijn iedere 5 jaar hun frontend opnieuw aan het bouwen omdat ze voor een "hip" framework hebben gekozen terwijl die na een paar jaar al weer dood is.
Vervangen om het vervangen is inderdaad onzin. Maar bij IPv4 is de reden toch duidelijk? Er zijn er simpelweg niet genoeg.
Klopt maar het probleem is dat het in de praktijk ook allemaal prima kan met IPv4. Tot nu toe is er gewoon te weinig noodzaak om te veranderen. IPv6 bestaat al zo lang dat ik me niet voor kan stellen dat het een technische belemmering is. Het is meer zoals met FM radio en DAB. Het nieuwe is beter maar het oude voldoet.
omdat jullie leverancier dan kan zeggen 'Ja dit werkt' ipv steeds terug moeten komen omdat voor jullie leverancier IPV6 experimenteel is... gewoon kosten vs risico.
Het probleem dat veel IT afdelingen hebben is niet dat ze zitten te slapen maar dat ze beperkte budgetten hebben. Vaak moet men eerder bezuinigen dan dat er geld voor investeringen beschikbaar wordt gesteld om de tech debt terug te dringen. De dagelijkse operatie is waar men op afgerekend wordt.

Iets roepen is erg makkelijk, ja er is een gebrek aan IP4 adressen, ja we moeten ooit over op IP6. Maar het is net als met de energie transitie, wanneer ga je als bedrijf of particulier dik investeren, ga je geld lenen om over te stappen op een energie neutrale oplossing? Velen kiezen er dan toch voor om de kat uit de boom te kijken en het geld nog een tijdje in de knip te houden.
Nou, ondanks dat informatica zich continu vernieuwd is het soms een bar conservatieve wereld. Serverruimtes worden nog altijd op 21° gekoeld omdat dat decennia geleden een goed idee leekt, 19"-rekken dateren uit de jaren '50 en QWERTY is anderhalve eeuw geleden bedacht vanwege de beperkingen van typmachines.

Men doet ipv4 omdat ipv4 er met de paplepel is ingegoten. Verandering van gewoonte roept weerstand op.
Dat ben ik dus niet met je eens. Het gaat hier niet om weerstand, het gaat hier om kosten die gemaakt moeten worden. Daar moet je dus budget, tijd en resources aan spenderen. Dat betekent dat andere zaken op de plank blijven liggen want niemand van ons werkt in een organisatie met genoeg middelen om alles te kunnen doen.

De meeste hier zijn IT-ers, die begrijpen prima dat IPv4 eindig is en dat je vroeg of later volledig over zal moeten gaan op IPv6. Alleen die IT-ers maken niet de keuzes in de bedrijven waar ze werken, de keuzes worden op hoog niveau gemaakt. En als die moeten kiezen tussen een investeringen die de business verlangt waarmee men op termijn geld mee denkt te verdienen dan wel kosten te besparen versus een tech debt project om qua IT toekomst bestendig te worden, denk dat we allemaal al vaak genoeg meegemaakt hebben hoe dan de hazen lopen.
Eens met dat het ook om kosten gaat, maar gewoontes doorbreken kost behalve euros ook energie van ITers, die gewoonlijk al met genoeg bezig zijn.
Dat betekent ook dat een oude bestaande oplossing behouden blijft tot het financieel echt onhoudbaar wordt, en daar zet Amazon nu de eerste stappen mee. Er hangt nu namelijk een expliciet prijskaartje aan het houden van een IPv4, en dat kaartje wordt alleen maar duurder. Eerst gaat dat een paar bedrijven (die v4 gehamsterd hebben) heel rijk maken, want weerstand, en daarna gaan bedrijven en mensen schoorvoetend over op IPv6, maar pas als we echt HARD tegen de effecten van NAT achter NAT aan lopen. Tot die tijd een een paar euro per maand betalen een veel snellere oplossing.
ITers moeten de noodzaak van een migratie uit kunnen leggen aan de budgetbeheerders. Andere afdelingen kunnen dat vaak beter. Je moet er altijs vanuit gaan dat degene die over het geld gaat geen verstand van het onderwerp heeft. Of dat nu it is, marketing of winkelinrichting of wat anders. Ergo, kom met een goed onderbouwd verhaal over kosten en wat kosten worden als je niets doet.
ik zou zeggen laat je gaan... Ik heb de bedrijfs geldbuidel in de hand...

Hoeveel publieke IP's hebben we 256? 256 * 3.72 = geen 1000 eur per maand, daar kan ik een specialist 1 dag voor laten werken.

Hoeveel dagen gaat dit migratie project in beslag nemen? Hoeveel meetings gaan we hier intern over hebben? Hoeveel downtime?

Vertel me eens @Frame164 wat is de business value van je project IPV4 naar IPV6? Hoe gaat dit mijn klanten een betere ervaring geven? Ga ik een snellere go-to market hebben? Verbeterd mijn product? mijn kas positie?...

Ik zal het vast een beetje chargeren, maar je begrijpt dat dit gewoon een moelijk verhaal is.. Als IT afdeling moet je ook je battles selecteren....
De vraag is hoe lang je dat excuus kan volhouden. Ben ooit bij een bedrijf geweest waar ik zachtjes over de gang moest lopen, omdat anders de VAX/VMS waar hun ERP op draaide zou kunnen hikken.

Nee, budgetten zijn niet oneindig. Maar voor zaken die al heeeel lang zichtbaar zijn, kun je gaan reserveren. Dan kun je op tijd iets gaan doen. Sowieso heb je (hopelijk) een vernieuwingscyclus van apparatuur, waarbij je stappen voorwaarts kunt maken.

Als je nu nog geen plan hebt liggen, dan mag je op de blaren zitten straks.
Qwerty is niet bedacht "vanwege de beperkingen van typmachines". Qwerty is bedacht als optimale layout die letters die je het meest gebruikt dichtbij je vingers plaatst. Daarom zitten minder vaak gebruikte zoals q en z in een hoek. En dat is ook waarom andere landen andere default layouts hebben, omdat hun woorden een andere samenstelling hebben en letters dus vaker of minder vaak voor komen. Bovendien, wie wil dat nou weer veranderen? Zoveel mensen hebben ondertussen leren typen dat je weer helemaal opnieuw zou moeten beginnen als je een andere layout zou introduceren. Ik ken niemand die de behoefte daaraan heeft. Je moet alleen zaken gaan veranderen om problemen op te lossen en die zie ik met qwerty niet. Dus wat is nou je punt?
Dat klopt echt niet. DVORAK is wél bedacht als optimale layout, maar DVORAK is nooit aangeslagen. De ontwerpcriteria bij QWERTY was het fenomeen dat als twee verkeerde toetsen bij een typmachine tegelijk aangeslagen worden, ze vast komen te zitten. De layout van Qwerty probeert de kans dat twee van dat soort problematische toetsen achter elkaar aangeslagen moeten worden te minimaliseren. Iets wat op een computertoetsenbord volledig onzinnig is.
Overstappen van QWERTY naar wat anders is idd een hele leercurve.
Maar bij lichamelijke klachten moet je wel iets veranderen, dus proberen sommigen dat dan wel.
In elk geval dus weg van QWERTY en naar bijvoorbeeld Colemak.
Het blijkt dat je dat wel in een paar weken/maanden onder de knie kan krijgen, zo onhaalbaar is dat niet. En zeker als je gemotiveerd bent door fysieke pijn oid.
Overigens, ook de gebruikelijke kolom layout is een overerfsel van typmachines, nergens meer voor nodig maar puur gewoonte en niet optimaal voor mensen. Bijvoorbeeld als je middelvinger van D naar E moet, moet ie niet gewoon natuurlijk naar boven (of rechtsboven als je je pols recht wilt houden) maar juist naar linksboven.
En ja sommigen typen mss anders dan het "hoort" waardoor ze hier mss minder last van hebben.
Maar dat was niet nodig geweest als de layout in de basis al beter overeen kwam met wat goed is voor een mens ipv een typmachine.
Offtopic, maar over de opmerking m.b.t. serverruimtes op 21 graden. Wat is een gangbare temperatuur en heb je daar meer informatie/bron van?
Servers worden gemaakt om tot 35 graden te kunnen functioneren. Het economische punt ligt veelal tussen de 25 en 30 graden. De compressoren hoeven dan alleen op warme dagen te draaien, zodat de koelkosten laag blijven. Ga je lager dan gaan de compressoren veel vaker draaien en stijgen de elektriciteitskosten snel, ga je hoger dan gaan de ventilatoren van de servers hard werken en verlies je daardoor efficiëntie.
Mijn persoonlijke reden is dat ik met een ip4 adres en NAT alles kan regelen maar als ik datzelfde met ip6 probeer te doen niets lijkt te werken. Dat is ongetwijfeld onkunde van mijn kant maar het geeft mogelijk wel aan dat de overstap naar ip6 iets lastiger is dan sommigen zouden willen.
Het is geen onkunde van jouw kant, we werken al zo lang met IPv4 dat we het kunnen dromen. Dus hebben de meeste van ons thuis alles op dat niveau ingeregeld. Mijn Pi-hole schijnt prima op IPv6 te kunnen werken, alleen heb ik het op IPv4 ingeregeld. Geldt voor bijna mijn hele netwerk. Dus heb ik vooralsnog IPv6 uitstaan op mijn belangrijkste sub LAN.
Al jaren lang negeren grote groepen mensen het en blijven vervolgens ook nog eens argumenten zoeken waarom iets niet kan.
Ik negeer het ook zolang mogelijk. Ik zet op mijn routers en netwerkapparaten IPv6 waar mogelijk gewoon uit. Ik vind IPv4 gewoon veel overzichtelijker in het gebruik. Ik denk dat men een fout heeft gemaakt door teveel te wijzigingen in IPv6 door te voeren die verder gaan dan sec het verruimen van beschikbare adresruimte. Ja, IPv6 heeft technische verbeteringen maar als je opeens geen NAT meer hebt, andere subnets hebt, andere manier van IPsec, andere QoS, enz. moet inrichten met als resultaat een werkende netwerkverbinding die in het gebruik niet merkbaar beter is dan IPv4, waarom zou je dat doen?
4,3 miljard adressen is simpelweg te weinig voor deze hele planeet en alle plannen die we nog hebben.
Niet eens: het grootste deel van de internetgebruikers consumeert diensten die zij zelf initiëren. Voor die toepassing is NAT gewoon voldoende.

Pas als (voor mij) essentiële diensten niet meer bereikbaar zijn via IPv4 ga ik iets doen. Ik zie het echter op korte termijn niet gebeuren.

[Reactie gewijzigd door ari3 op 27 juli 2024 07:19]

Nee hoor, het hoeft niet perse te gebeuren. IPv6 is een te complexe oplossing op een nauwelijks bestaand probleem. Niemand heeft zoveel adressen voor zichzelf nodig. Noem mij eens 1 use case om überhaupt 10 adressen alleen voor jezelf te hebben? De hoeveelheid apparaten die je thuis hebt, is niet relevant. Dat werkt nu prima via NAT. Jouw wifi lampen, game console en slimme schakelaar hebben geen eigen publiek IP adres nodig. Dat maakt ze alleen maar een doelwit voor hackers. Zijn ze nu ook al, maar al die lekken worden nog veel gevaarlijker als iedere dropl* direct op het apparaat kan inloggen omdat ze een publiek adres hebben. Alles werkt hier prima op 1 IPv4 adres (wij hebben van KPN niet eens een IPv6 adres gehad op onze glasvezel). Zelfde voor al die smartphones op 4/5G, dat werkt nu ook prima met carrier NAT. Jij zit op hetzelfde IP als duizenden anderen. En daar merk je niks van, want hoe vaak moet iemand vanaf het internet direct jouw apparaat benaderen? Mijne nooit in ieder geval.

Volgens mij is de grootste reden dat anno 2023 IPv6 nog steeds overal op een laag pitje staat, dat het deel van de wereld dat zich niet focust op de theoretische aspecten maar op de praktische kant groter is dan het kleine groepje techs dat moord en brand schreeuwt over adressen die op raken (maar blijkbaar 25 jaar later nog steeds genoeg zijn).
Ik denk niet dat je de afgelopen 5 jaar nog enterprise netwerkapparatuur kon kopen die geen IPv6 aankon. Misschien de goedkopere MKB devices maar zelfs daar betwijfel ik het. Alle IPv4 only apparatuur is al lang afgeschreven.
Voor de thuisgebruiker was 2012 het jaar dat vrijwel iedere modem/router leverancier ineens ook IPv6 ondersteunde (het was bijna alsof ze het allemaal met elkaar hadden afgesproken). Het lijkt me inderdaad stug dat MKB devices daar meer dan tien jaar op achter liepen.
Ziggo modems in bridge modus ondersteunen ipv6 pas sinds kort.
Dat probleem ken ik ja, maar dat was geen beperking van het modem, die ondersteunden dat al lang, dat was een beperking in de Ziggo implementatie. Die vonden dat geen prioriteit, mogelijk omdat het maar een heel beperkt deel van de gebruikers betrof.
Je hebt helemaal gelijk.
Klopt, maar nu werkt het op zich prima. Met als enige nadeel dat je ook bij IPv6 geen vast subnet krijgt. Wat enorm onhandig is, omdat veel lokale firewall regels op basis van je subnet lopen. Dus elke keer als ik van Ziggo een nieuw subnet krijg, moet ik al mijn regels nalopen.
Bij IPv6 is het helemaal niet nodig om steeds andere adressen of subnetten uit te delen.
Moet je provider daar wel in (willen) meegaan ...
Providers krijgen zo gigantisch veel IPv6-adressen toebedeeld... ze hebben geen reden om een klant steeds wisselende IP-adressen te geven.
Vertel dat aan die providers. ;)
Ziggo modems in bridge modus ondersteunen ipv6 pas sinds kort.
Tja nu Caiway/Delta nog....
Gewoon gênant!
Ik denk niet dat je de afgelopen 5 jaar nog enterprise netwerkapparatuur kon kopen die geen IPv6 aankon.
En zelfs als dat wel zou kunnen: investeren is vooruit zien, dus je zou niet geïnvesteerd moeten hebben in apparatuur die niet met IPv6 kan omgaan.
Het gaat niet om het niet ondersteunen van IPv6, maar dat sommige apparatuur/firmware/software nog steeds buggy is met IPv6 of andere beperkingen heeft. Bijvoorbeeld dat hardwareacceleratie niet ondersteund wordt in combinatie met IPv6.
Of de Ipv4 apparatuur is afgeschreven of niet doet er toch niet zoveel toe? Het gaat erom hoe je intern je bedrijfsnetwerk opgezet hebt. En daar was geen IPv4 probleem immers met 10.xxx.xxx.xxx heb je meer dan genoeg interne IP adressen tot je beschikking.

Maar als je je netwerk logisch gescheiden hebt op basis van Ipv4 regels, dus simplistisch gezegd 10.1.xxx.xxx voor Prod, 10.2.xxx.xxx voor UAT, 10.3.xxx.xxx voor Dev dan heb je nu ineens aardig wat werk als je alles om wil zetten naar IPv6. In de praktijk bestaan bedrijfsnetwerken uit heel veel segmenten, allemaal gescheiden door routering en firewall regels op basis van IPv4 ranges.

Het opzetten van routering en firewall regels gebeurt eerst op logisch niveau. Standaad staat alles dicht. Dus stel dat applicatie A wil interfacen over protocol ABC naar applicatie B. Dat soort regels worden door je tooling vertaalt naar fysieke regels. Subnet A met range x1 tot y1 wil TCP verkeer over port 22 naar Subnet B range x2 tot y2. En die regels zijn uiteindelijk weer vertaalt naar de regels in je routering en firewall hardware.

Op dat netwerk heb je decennia van alles gebouwd, databases, applicaties, interfaces, beheer software, noem het allemaal maar op. Vaak met automatisch fail-over naar andere servers in andere data centers. Dus wanneer database A uitvalt, dan wijst de DNS entry voor de connectie string in no-time naar database B. Al dat soort zaken, al dan niet gescript, zitten vol met IPv4 regels.

Het is gewoon heel veel werk om dat allemaal om te gaan zetten naar IPv6.
Maar als je een netwerk hebt van dat formaat dan gebruik je vast load-balanceren en reverse-proxies om je diensten aan de buitenwereld te serveren. Dat soort edge-devices zijn de enige die IPv6 moeten hebben. Houd je intern netwerk op IPv4 als omzetten daar teveel werk is.
Het probleem zit hem in de ip v4 infra die men al heeft draaien. Die zal je moeten afschrijven en vervangen. Die kosten zijn veel hoger dan de oplopende TCO kosten.
Eerder gaf iemand hier al het voorbeeld van de firewall die zijn organisatie gebruikt.
Als die infra nog geen IPv6 aankan, dan is die allang afgeschreven. De meeste (netwerk) apparatuur kan echt al tientallen jaren IPv6.

Of er zijn echt hele crappy apparaten gebruikt.

Ik heb vrij lang bij een ISP gewerkt, die deden ook destijds weinig IPv6, toen ik voor een LCM traject loadbalancers ging vervangen kreeg ik de vraag of de vervangde apparatuur wel IPv6 geschikt was, want dat moest echt wel. Nou dat was het zeker, want de apparatuur die we gingen vervangen (was dus afgeschreven en aan vervanging toe) was al lang en breed IPv6 geschikt.
Infra is veel meer dan alleen de netwerk apparatuur. Je netwerk apparatuur kan ongetwijfeld IPv6 aan, daar zit het probleem niet. Je infra laag daarboven op, die is vaak niet ingeregeld op IPv6. Dus je virtuele servers gebruiken nog IPv4 adressen, je firewall, je BCM tools, de configuratie van je apps, interfaces, je white-listing van je servers et cetera.

Als je die laag over wil zetten naar IPv6 dan is dat echt een heel groot project want je moet alles aanpassen en alles end-to-end doortesten.
Infra is veel meer dan alleen de netwerk apparatuur.
Dat klopt.
Dus je virtuele servers gebruiken nog IPv4 adressen, je firewall, ...
Dat je virtuele servers geen IPv6 gebruiken is een (slecht i.m.h.o) design keuze. Een firewall lijkt me ook netwerk apparatuur, hoewel die natuurlijk ook hosted base kan zijn, met SDN is die scheidslijn ook flinterdun geworden.
Als je die laag over wil zetten naar IPv6 dan is dat echt een heel groot project want je moet alles aanpassen en alles end-to-end doortesten.
Dat ben ik ben je eens, maar daar had je meer dan 10 jaar geleden ook al mee kunnen beginnen ook is een design keuze.

Zoals eerder werd aangehaald, begin er gewoon mee. Alle nieuwe ontwikkelingen op IPv6 met een vleugje IPv4 on the edge. Dat zou een goede basis houding zijn om over te kunnen stappen.
Je reageert vanuit de techniek. Het probleem is niet technisch van aard, het gaat om budget, tijd en resources. De prioriteit op wat wel en wat niet opgepakt wordt in een organisatie is zelden een technische keuze.

Vanuit de techniek iets opleggen terwijl dat grote consequenties kan hebben voor het applicatie landschap, dat gaat niet werken. De netwerk groep wint die discussie nooit.

Zaken als een goede basishouding, ik weet niet hoe ik dat moet zien in een grote organisatie. De mensen die de beslissingen nemen zijn zelden technisch onderlegt. Die redeneren vanuit waar zij kansen zien en geven tech debt alleen prioriteit als het echt niet anders meer kan. En zelfs dan doen ze nog moeilijk over projecten die uitgesteld moeten worden omdat er geen geld en/of capaciteit meer is doordat een stuk tech debt opgelost moet worden.

Overigens waren er intern natuurlijk ook helemaal geen probleem. Een bedrijf had intern met 10.xxx.xxx.xxx meer dan genoeg IPv4 adressen voor al hun hardware beschikbaar. Pas nu delen naar de Cloud gaan, ontstaan er problemen tussen de IPv6 cloud en de interne IPv4 systemen. Waar natuurlijk ook weer oplossingen zijn, al ligt het met de corporate firewall soms wat lastiger.

[Reactie gewijzigd door wiseger op 27 juli 2024 07:19]

Als iemand dusdanig oude infra heeft draaien dat het alleen IPv4 aankan, dan zijn ze zeker een decennium te laat met vervangen. En hebben ze waarschijnlijk een aantal gapende security gaten.
Het is niet een kwestie dat de infra geen IPv6 aankan, het is hoe de infra is opgezet. Je firewall rules, je automatische tools die switchen naar een ander data center als bijvoorbeeld als een database uitvalt, de VMs die opgezet zijn met een fixed IPv4. Noem maar op. Zoveel zaken waar veranderingen nodig zijn om over te stappen op IPv6 only.

Dat zijn gewoon grote projecten die heel veel budget, tijd en resources vragen. De return op die investering is dat je organisatie toekomst bestendiger is. Op de korte termijn zal het niet tot kosten reductie leiden.

Probeer dat er maar eens doorheen te krijgen in organisaties waar de IT afdeling toch al behoorlijk overbelast is.
Elke keer als ik ipv6 wil gebruiken is het weer huilen. Het is gewoon totaal niet plug en play, wat ipv4 wel is. Op papier ondersteund alles ipv6, maar als je het dan aanzet werkt het de helft van de tijd niet. Unix tools als curl of ping hebben soms geen ipv6 support dus je moet ping6 installeren, je router weigert ipv6 door te routen naar wan zonder te klooien met router instellingen, enzovoorts. Misschien dat het aan mij ligt, maar ik heb nog nooit een aangename plug en play ervaring gehad met ipv6
Het probleem zit hem in de ip v4 infra die men al heeft draaien. Die zal je moeten afschrijven en vervangen. Die kosten zijn veel hoger dan de oplopende TCO kosten.
Als dat nu nog een probleem is hebben die organisaties de afgelopen 15 jaar zitten slapen. Dit zit er al heel lang aan te komen.
Eerder gaf iemand hier al het voorbeeld van de firewall die zijn organisatie gebruikt.
Ik kan me eigenlijk niet voorstellen dat er nog moderne firewalls zijn die geen IPv6 doen. Ik denk dat het gewoon oude meuk is die je niet over je netwerk wil laten waken. Trouwens, alle moderne computers (windows, linux, macos, android, ios) ondersteunen IPv6 by default. Als je firewall geen IPv6 doet is de kans groot dat je ongcontroleerd IPv6 verkeer over je netwerk toestaat.

[Reactie gewijzigd door CAPSLOCK2000 op 27 juli 2024 07:19]

Als je firewall geen IPv6 doet is de kans groot dat je ongcontroleerd IPv6 verkeer over je netwerk toestaat.
Als je firewall geen IPv6 doet zal ie het überhaupt niet doorlaten omdat ie geen geldige packets herkent. Netwerkverkeer is niet magisch en kan niet zichzelf een weg banen door kabels heen. Iedere schakel in de keten moet het pakket actief routeren.
Als je firewall geen IPv6 doet zal ie het überhaupt niet doorlaten omdat ie geen geldige packets herkent. Netwerkverkeer is niet magisch en kan niet zichzelf een weg banen door kabels heen. Iedere schakel in de keten moet het pakket actief routeren.
Niet binnen je lokale netwerk. Ik was misschien een beetje te makkelijk met de term "firewall". Ik bedoel iedere vorm van netwerkapparatuur. De meeste mensen hebben thuis echter maar 1 kastje met daarin een router, firewall en switch vandaar dat ik een beetje los met dat woord ben.

Binnen een netwerksegment kunnen hosts typisch onderling direct communiceren. Als je niet actief filtert dan gebeurt dat gewoon. Als je dan zelf een laptop met IPv6 meeneemt (bv via een mobiele verbinding) dan zal het hele netwerk je opeens als router accepteren. Een van mijn favoriete party tricks als ik ergens op bezoek ben is even IPv6 pingetje te doen waarna alle computers op het netwerk zich braaf komen melden. Met 1 router advertisement pakket neem je zo'n heel netwerksegment over.

De meeste clubs die niet aan IPv6 doen weten niet eens dat ze er rekening mee moeten houden en gaan er van uit dat alles by default dicht staat. Ik stel daarom wel eens dat je IPv6 pas kan uitschakelen als je het heel goed begrijpt. Niks met IPv6 doen en denken dat je veilig bent is niet verstandig.

Uiteraard zou je netwerk zo geconfigureerd moeten zijn dat alles wat niet goedgekeurd is dus wordt geweigerd maar de meeste organisaties zijn nog niet zo ver. De organisaties die het wel zo ver onder controle hebben die maken ook weloverwogen keuzes over IPv6.
Al die apparatuur moet je over de jaren heen tóch al vervangen. Als je gewoon bij de aankoop van nieuwe apparatuur al rekening houd met IPv6, heb je binnen een jaar of 10 al een compleet IPv6-capable omgeving. Gelukkig heeft praktisch alle enterprise-hardware al vele jaren IPv6 ondersteuning, dus als je netwerk in 2023 nog geen IPv6 heeft komt dat omdat je simpelweg nooit de moeite hebt genomen om het in te stellen.
Infra is veel meer dan alleen de netwerk apparatuur. Je netwerk apparatuur kan ongetwijfeld IPv6 aan, daar zit het probleem niet.
Zoals ik zei, dat is het probleem niet. Het gaat erom wat je op je netwerk hebt gebouwd. Die infra is vaak niet IPv6 ingericht.
We moeten en zullen met zijn allen er voor moeten zorgen dat het internet zo snel mogelijk naar IPv6 over is.
Nouja ik ben er inmiddels ook wel een beetje klaar mee. In 1993 leerde ik al over IPv6 dat "the next big thing" zou zijn. Inmiddels heb ik het nog steeds niet op mijn thuisaansluiting (in 1993 had ik helemaal geen thuisaansluiting 8)7 ). Ik heb eind jaren '90 nog een tijd zo'n 4-to-6 gateway gedraaid omdat ik er enthousiast over was. Maar in de loop der tijd is dat gewoon weggevallen. Ik ben gewoon moe van het pushen hiervoor terwijl er toch niks van komt.

Ze doen maar, maar ik ga er geen tijd meer aan besteden. Laten de providers eerst maar zorgen dat het overal ook echt beschikbaar is. Momenteel schakel ik IPv6 dan ook uit op al mijn bakken. Op het werk doen we er ook nauwelijks aan (alles zit op een van de interne IP ranges).

Bovendien is IPv6 inmiddels ook alweer redelijk oudbakken. Destijds zaten er allemaal uitbreidingen in voor mobiele roaming achtige toepassingen die inmiddels alweer zo verouderd zijn dat ze niet meer mee kunnen. Terwijl we wel andere uitdagingen hebben op het gebied van security bij routing (denk aan BGP problemen). Ik zou liever zien dat ze gewoon helemaal opnieuw beginnen en met iets komen dat voor de huidige uitdagingen is bedacht en niet voor die van de jaren '90 - zo ongeveer de middeleeuwen op IT gebied. En liefst ook wat meer aandacht besteden aan een simpel migratietraject want als dat in IPv6 had gezeten dan was het allang al van de grond gekomen.

[Reactie gewijzigd door GekkePrutser op 27 juli 2024 07:19]

We gaan echt werkelijk nooit IPv8 (voorbeeld) maken en overal in apparatuur krijgen. Dat is een traject van 20 jaar en dan is het internet op IPv4 echt al helemaal een overlap van CGNAT op CGNAT geworden.

IPv6 gaat te langzaam, dat zeker, maar het is in delen van de wereld al de meerderheid. Vergeet landen als India en China niet.
We gaan echt werkelijk nooit IPv8 (voorbeeld) maken en overal in apparatuur krijgen. Dat is een traject van 20 jaar en dan is het internet op IPv4 echt al helemaal een overlap van CGNAT op CGNAT geworden.
Dat hoeft niet per se natuurlijk. Als je de migratie makkelijker maakt, kan het snel gaan. Dat was het probleem met IPv6. In begin jaren '90 was het juiste moment geweest daarvoor, toen was er nauwelijks installed base. Maar niemand wilde eraan.
IPv6 gaat te langzaam, dat zeker, maar het is in delen van de wereld al de meerderheid. Vergeet landen als India en China niet.
Ja ik weet het maar daar hebben we hier niet zoveel mee te maken natuurlijk. China zit achter hun nationale firewall (en ik denk dat we gezien de geopolitieke spanningen daar een soort 'ijzeren gordijn' mee krijgen) en India is toch 1 grote puinhoop. Als je ziet hoe de boel daar aangelegd is, dan verbaast het me dat er uberhaupt nog een bitje door komt daar :')

[Reactie gewijzigd door GekkePrutser op 27 juli 2024 07:19]

Je beseft je wel dat het internet groter is dan Europa en ons wereldje? De manier waarop je zo over India spreekt is natuurlijk nogal neerbuigend naar hen toe.

Afrika gaat ook nog hard groeien evenals Zuid-Amerika, daar is simpelweg IPv4 niet afdoende voor.

We hebben die langere adresruimte van IPv6 nodig en hard ook.
Je beseft je wel dat het internet groter is dan Europa en ons wereldje? De manier waarop je zo over India spreekt is natuurlijk nogal neerbuigend naar hen toe.
Moet je daar eens heen gaan en zien hoe de bekabeling erbij hangt, dan snap je het ;)
Dat staat toch los van het protocol? Mijn punt blijft dat het internet een wereldwijde gelegenheid is, niet enkel met onze Westerse bril er naar kijken.
Ik heb hetzelfde sentiment. Daarnaast loop ik - nog steeds - tegen allerlei implementatie moeilijkheden aan met IPv6. Iedereen hier mag daar allemaal luchtig over doen, maar als ik een NextCloud Docker image moet opzetten dat communiceren met een office image, wat draait in een Proxmox VM, met daarin de firewall regels, dan is het toch allemaal super complex.

Een ander voorbeeld is een transparante bridge gebaseerd op pfSense, die kwaadwillende ip's blokkeert. Werkt perfect met IPv4, maar met IPv6 er bij is het een ramp om op te zetten.

Bij mij thuis heb ik een eigen openwrt router, maar ik krijg het IPv6 netwerk van YouFone niet te pakken, en dan heb ik best ervaring met openwrt en IPv6. Daarnaast mis is ik de semi natuurlijke firewall achtige afscherming van NAT. Met IPv6 moet je er gewoon veel meer over na denken.

Kortom, ik ben ook voorstander van een nieuw protocol, en ik hoop al 10 jaar dat iemand er mee komt. Wat mij betreft gebaseerd op IPv4, pas het aan dat het niet tot 255 loopt, maar tot 999, of zet er een extra octet of twee bij. Daarmee krijg je ook 100% backwards compatibility met IPv4. (als je afspreekt dat 'fff' speciaal is, dan kun je '8.8.8.8' vervangen door 'fff.fff.8.8.8.8' en heb je daarmee ondersteuning voor IPv10 (ik noem maar wat) en ipv4.

Daardoor kan ook de adoptie veel sneller gaan, zijn firewall aanpassingen veel eenvoudiger en de adoptie zal veel sneller kunnen gaan.

Op zich zou misschien zo'n contructie ook wel redelijk goed op oudere devices uitgebracht kunnen worden.

Afijn. Geratel :)
Kortom, ik ben ook voorstander van een nieuw protocol, en ik hoop al 10 jaar dat iemand er mee komt. Wat mij betreft gebaseerd op IPv4, pas het aan dat het niet tot 255 loopt, maar tot 999, of zet er een extra octet of twee bij. Daarmee krijg je ook 100% backwards compatibility met IPv4. (als je afspreekt dat 'fff' speciaal is, dan kun je '8.8.8.8' vervangen door 'fff.fff.8.8.8.8' en heb je daarmee ondersteuning voor IPv10 (ik noem maar wat) en ipv4.
Dit bestaat al - het heet NAT64 (IPv4 adressen gecodeerd als 64:ff9b::8.8.8.8 ), en ongeveer een miljard mensen gebruiken het nu al. IPv6 is backwards compatible met IPv4 dat is niet het probleem, het probleem is dat IPv4 niet forwards compatible met IPv6 is.

[Reactie gewijzigd door Dreamvoid op 27 juli 2024 07:19]

Jouw antwoord op Faceless geeft ook aan waarom het invoeren van IPv6 niet zo snel gaat. Het verhaal van Faceless is doorspekt met ingewikkelde technische termen, en zelfs zo'n geavanceerde IT'er kent NAT64 niet.
Er komt gewoon heel veel bij kijken; veel meer dan dat velen denken. En het is ook niet zo dat IPv4 opeens weg is; daar zul je voorlopig ook nog mee moeten kunnen communiceren. Persoonlijk vind ik IPv4 al complex; en als je IPv6 wilt implementeren moet je náást IPv6 óók nog flink kaas hebben gegeten van IPv4. Kortom... het is ook echt wel een issue met hoeveel een mens allemaal kan leren, onthouden en toepassen.
Getallen groter dan 255 passen niet in een byte. 8)7
oh, bel ff met ipv6
Mensen hadden denk ik de verkeerde voorstelling hoe de migratie zou lopen, men dacht aan een soort Big Bang waar IPv4 uit ging en IPv6 aan ging. In de praktijk is IPv6 compatible met IPv4 geworden, waardoor IPv4 zonder problemen kan voortbestaan naast IPv6, net zoals je bv 32 bit applicaties op een 64 bit OS kan draaien. Net zoals je DOS applicaties anno 2023 ook nog steeds werken op DOSBox.

De helft van de wereld heeft IPv6 zonder dat gebruikers het merken. Als IPv4 gebruiker kan je IPv6 uitschakelen en er niets van merken, maar je internet verkeer wordt over onderliggende IPv6 netwerken getransporteerd naar IPv6 servers achter een IPv4 loadbalancer. Het is allemaal onzichtbaar geworden. Natuurlijk kan niet iedereen op het internet IPv4 blijven gebruiken (da's het hele probleem), maar de legacy netwerken kunnen voor altijd blijven bestaan.
... maar de legacy netwerken kunnen voor altijd blijven bestaan.
Ja, maar op termijn stelt dat niks meer voor. Er zijn ook niet veel werkplekken meer die op DOS6 draaien.
Op termijn niet, maar die termijn kan lang duren.
Google, Meta, LinkedIn, het doet allemaal al jaaaaaaaaren IPv6 en nog steeds zijn er mensen die zeggen dat het niet kan.
Het helpt niet dat ze IPv6 ook te ingewikkeld gemaakt hebben. Kijk, ik wil men home NAS/Server publiek maken. Ipv4 kan ik vergeten want ze gebruiken hier CNAT of whatever wat IPv4 over IPv6 is. Vergeet het om een server te draaien met Ipv4.

Ok, dat zet ik de boel gewoon op IPv6 want waarom niet. Is gewoon zodat ik buiten huis de boel kan accessen. Je zet de poort open in je router, ... hmmmm, waarom heb ik niet de mogelijkheid zoals met IPv4 om de IP statistisch te maken. A ja, die Ipv6 komt van een block van de provider... Ok, geen probleem

Heuuu, waarom zijn de prefix van men IPv6 veranderd. Really ... veranderende IP weeral. Zucht... Ok gewoon zoals vroeger, externe dienst zoals DuckDNS voor een domain en .... dat werkt maar dan werkt met VPN weeral niet op men android phone want Wireguard kan de ipv6 niet vinden op de domain. Probeer via hetzner domain, zelfde probleem. Android probleem met IPV6 DNS. Fuck ... Dus ik moet een statis ip hebben dat ik manueel ingeeft en dat niet via de domain AAA record moet.

O, als ik men NAS reboot, dan worden de postfix weeral veranderd want de server heeft geen statis IP voor de laatste nummers (wat bij ipv4 gewoon zeggen aan de router om iedere keer statis IP4 toe te kennen aan de server). Nowp, nu moet je weeral statis ip manueel toekennen op de server zelf, maar heuu, fuck, ik kan niet de volledige IP6 toekennen als statis want de provider veranderend de eerste digits om de zoveel tijd.

Na letterlijk 2 dagen men tijd te verspillen om te proberen te leren hoe ipv6 werkt, de verwarring van de dozen verschillende settings in men router rondom ipv6. De enorm klote manier hoe de interfaces under Unraid opgezet zijn voor Ipv6, en men verwarring met die elle lange ip addressen, dat soms hetzelfde uitzien maar niet hetzelfde zijn (leuk als je dyslexia heb) omdat de pre of after fix veranderd is.

Het is zo god verdoemen ingewikkeld. Moest het enkel men server zijn dat geen statis ip heeft en dat kan ik oplossen maar met de veranderende prefix heb je dubbel zoveel problemen.

Ik HAAAAAT ipv6, het is niet een probleem van willen leren, het is te gvd ingewikkeld. Het lijkt op IPV4 maar die dubbel opbouw met prefix en postfix maakt het zo ingewikkeld als je prefix ook constant veranderd via je ISP. Dan heb je je router met veel meer Ipv6 opties (ivm ipv4) omdat die moeten omgaan met de IPv4 vertalingen, de pre-fix issues, verschillen in de DNS enz.

Ondanks dat ik 30 jaar IT achter men kiezen heb en jaren met IPv4 omgegaan heb, kan ik gewoon niet een simpele NAS opzetten met van buiten toegankelijk IP (dat werkelijk toegankelijk BLIJFT!). Al wat ik wil van IPv6 was gewoon IPv4 met een grotere address range. Dat is het... maar nee, men moest de boel opspliten in pre and postfix blokken, men gaat postfix blokken uitdelen zoals snoep. En om eerlijk te zijn, vind ik het een beetje idioot dat je individuele toestellen hun eigen IPv6 geeft, want dat maakt attack vectors veel makkelijk (in mijn mening). Ik heb liever de router ervoren, zodat je interne routing, INTERN blijft zoals met IPv4.

Waarschijnlijk zal er iemand commentaar geven dat ik alles misdeed maar sorry, de frustratie niveau is 1000% met de tijd dat ik verschilde om nergens de eindigen. Als ze gewoon Ipv6 gemaakt hadden als Ipv4 met extra nummers, dan zouden we VEEL sneller omgeschakeld geraakt naar ipv6, want dan is de software simpeler aan te passen.Gewoon ipv4+extra nummers > iedereen kan dezelfde router/internet setup blijven gebruiken. Is weeral de zoveelste overgedachte standaard en voor wat ...

En om eerlijke zijn. Ipv4 is leesbaar zelf voor iemand als mij met dyslexia. Ipv6 is een ramp met nummers en letters en de extra lengte. Zelf als je de boel inkort met :: (wat weeral men hersenen doet kronkelen dat dit in de standaard zit als 0000 ipv gewoon 0000 te schrijven en de boel overzichtelijk te houden). Ze konden gewoon IPv4 nemen en 2 extra blokken toevoegen en dat alleen al was een insane ENORM aantal extra publieke IP addressed en de rest doe je gewoon intern via NAT.

/ipv6 rant finished!
Ok, dat zet ik de boel gewoon op IPv6 want waarom niet. Is gewoon zodat ik buiten huis de boel kan accessen. Je zet de poort open in je router, ... hmmmm, waarom heb ik niet de mogelijkheid zoals met IPv4 om de IP statistisch te maken. A ja, die Ipv6 komt van een block van de provider... Ok, geen probleem

Heuuu, waarom zijn de prefix van men IPv6 veranderd.
Jouw probleem zit bij je provider die dynamische IP-adressen uitdeelt in plaats van vaste.
Zucht... Ok gewoon zoals vroeger, externe dienst zoals DuckDNS voor een domain en .... dat werkt maar dan werkt met VPN weeral niet op men android phone want Wireguard kan de ipv6 niet vinden op de domain. Probeer via hetzner domain, zelfde probleem. Android probleem met IPV6 DNS. Fuck ... Dus ik moet een statis ip hebben dat ik manueel ingeeft en dat niet via de domain AAA record moet.
Volgens mij kan ik wel raden bij welke ISP jij zit. Ze lijken het opzettelijk zo moeilijk mogelijk te maken.
O, als ik men NAS reboot, dan worden de postfix weeral veranderd want de server heeft geen statis IP voor de laatste nummers (wat bij ipv4 gewoon zeggen aan de router om iedere keer statis IP4 toe te kennen aan de server).
Het heeft niks met techniek te maken. Je hebt ruzie met je provider, niet met IPv6.
Ik HAAAAAT ipv6, het is niet een probleem van willen leren, het is te gvd ingewikkeld. Het lijkt op IPV4 maar die dubbel opbouw met prefix en postfix maakt het zo ingewikkeld als je prefix ook constant veranderd via je ISP.
Wat je kan doen is NAT gebruiken. Eigenlijk net als onder IPv4. Dan kun je op je eigen netwerk vast adressen gebruiken en je router vertaalt tussen interne en externe adressen. (Je kan daarvoor 1:1 NAT gebruiken).
Ondanks dat ik 30 jaar IT achter men kiezen heb en jaren met IPv4 omgegaan heb, kan ik gewoon niet een simpele NAS opzetten met van buiten toegankelijk IP (dat werkelijk toegankelijk BLIJFT!). Al wat ik wil van IPv6 was gewoon IPv4 met een grotere address range. Dat is het... maar nee, men moest de boel opspliten in pre and postfix blokken, men gaat postfix blokken uitdelen zoals snoep.
IPv4 werkt precies hetzelfde hoor alleen heb je daar alleen maar de dynamische prefix. De postfix die je zelf mag gebruiken bestaat eigenlijk niet. Dat is 1 adres en daar moet je masquerading NAT voor zetten om dat ene adres te delen met meerdere computers.
En om eerlijk te zijn, vind ik het een beetje idioot dat je individuele toestellen hun eigen IPv6 geeft, want dat maakt attack vectors veel makkelijk (in mijn mening). Ik heb liever de router ervoren, zodat je interne routing, INTERN blijft zoals met IPv4.
Dat is perfect mogelijk. Je ISP heeft er voor gekozen om dat niet te doen.
Waarschijnlijk zal er iemand commentaar geven dat ik alles misdeed maar sorry, de frustratie niveau is 1000% met de tijd dat ik verschilde om nergens de eindigen. Als ze gewoon Ipv6 gemaakt hadden als Ipv4 met extra nummers, dan zouden we VEEL sneller omgeschakeld geraakt naar ipv6, want dan is de software simpeler aan te passen.
Dat is het, je ISP maakt IPv6 moeilijker dan nodig.
Gewoon ipv4+extra nummers > iedereen kan dezelfde router/internet setup blijven gebruiken. Is weeral de zoveelste overgedachte standaard en voor wat ...
Ik vind IPv6 juist een veel te kleine verandering om zoveel moeite voor te doen. Ik zou liever een veel grotere stap nemen zodat er meer redenen zijn om over te willen. Maar ja, dit had nooit een grote stap moeten worden. Halverwege de jaren 90 dachten we dat het even in een jaartje in te voeren. 30 jaar later is het wel heel erg veel moeite geworden voor een piepkleine upgrade.
Ze konden gewoon IPv4 nemen en 2 extra blokken toevoegen en dat alleen al was een insane ENORM aantal extra publieke IP addressed en de rest doe je gewoon intern via NAT.
Dat had gekund maar het was net zo veel werk geweest om over te stappen.
de rest doe je gewoon intern via NAT.
Dat kan nog steeds. Niet iedereen vind het een goed idee maar technisch gezien kan het op precies dezelfde manier als IPv6. Jouw ISP / jouw router heeft er voor gekozen om het anders te doen.
Wat je kan doen is NAT gebruiken. Eigenlijk net als onder IPv4. Dan kun je op je eigen netwerk vast adressen gebruiken en je router vertaalt tussen interne en externe adressen. (Je kan daarvoor 1:1 NAT gebruiken).
Jammer genoeg werkte dat niet meer... Fritxbox (wat ik gebruik) voorziet IPv6 enkel als doorgeef luikt. Gevolg is dat je geen statis ipv6 interne routing kunt opzetten. Heb die optie al lang geprobeerd.

Ok, wat dan van Ipv4 op je NAT en IPv6 buiten de router, zal werken, right, RIGHT? Nowp, de porten kan je enkel assigned op dezelfde ip standaard. Ik stelde de ipv4 in, en dacht, well, dat zal werken, right? Nowp ... dat word geweigerde.

Trust me, ik heb HEEEEEEL wat spullen doorlopen. Het is idd niet enkel de schuld van ipv6 maar gans de implementatie van ipv6 heeft veel haken overal.

En men ISP ... ik zit in Duitsland en dat is de 3de grootste als ik me herrinner. Het is normaal voor ISPs om de prefix te veranderen want oooo, je gaat toch geen home server opzetten? Fixed ip? Dat is voor bedrijfklanten, dus $$$$... Is dezelfde pot nat dat je hier nauwelijks 40mbit upload heb op glasvezel maar in spanje 1000mbit upload hebt. Feit is dat ik met ipv4 de boel werkend kreeg in het verleden, tot ze DS Lite tunnel door je keel duwde en ... Je heb dan geen keuze meer om de lijdensweg af te lopen.

Het probleem is hem niet IPS, veranderende IP4 deden ze ook. Het is gans de software implantatie en de idees hoe het moet werken volgende die implantaties overal. En dat is een IPv6 probleem. En waarom zo veel mensen er problemen mee hebben. Ik zeg het al lang, dat Ipv6 gewoon Ipv4 moest geweest zijn dat op dezelfde manier werkte en gewoon 2 extra 999 blokken kreeg ervoren. Simpeler implementatie, leesbaarder, en makkelijker om de software overal aan te passen.
O, als ik men NAS reboot, dan worden de postfix weeral veranderd want de server heeft geen statis IP voor de laatste nummers (wat bij ipv4 gewoon zeggen aan de router om iedere keer statis IP4 toe te kennen aan de server).
Snap ik niet, je postfix bij ipv6 is afgeleid van je mac-adres en verandert dus niet na reboot. Ik gebruik een Fritzbox zoals jij en alles werkt zoals verwacht.
[...]

Het lijkt op IPV4 maar die dubbel opbouw met prefix en postfix maakt het zo ingewikkeld als je prefix ook constant veranderd via je ISP. Dan heb je je router met veel meer Ipv6 opties (ivm ipv4) omdat die moeten omgaan met de IPv4 vertalingen, de pre-fix issues, verschillen in de DNS enz.

En om eerlijk te zijn, vind ik het een beetje idioot dat je individuele toestellen hun eigen IPv6 geeft, want dat maakt attack vectors veel makkelijk (in mijn mening). Ik heb liever de router ervoren, zodat je interne routing, INTERN blijft zoals met IPv4.

/ipv6 rant finished!
de postfix: heb je zelf in de hand... fixed IPv6 uitdelen kan prima, mijn mailserver bewijst dat al vele jaren (vereist wel een stabiele prefix)

De ISP die regelmatig je prefix aanpast: kwestie van betere ISP uitzoeken. xs4all vroeger en Freedom tegenwoordig (mogelijk anderen ook, maar van deze beide weet ik het zeker) geven je gewoon als onderdeel van je abonnement een vooraangekondigde vaste IPv6 prefix.
Anoniem: 76058 @aikebah1 augustus 2023 12:53
ISP shopping is niet de oplossing... Het werkte goed onder ipv4, het probleem is dat men een andere logica gebruikte voor ipv6 (ieder toestel zijn eigen externe ip) en zo de software overal op maakte. Gevolg is dat je dan een veranderende pre-fix heb, dan je in grote stront zit. Ja, je kan een andere ISP vinden maar dat is geen guarantee dat die zelfde fixed pre-fix gaan blijven gebruiken. Dat is geen onderdeel van je contract en contracten zijn hier vaak 2 jaar (Duitsland) bij ISP wissels. Gok je mis, zit je weeral vast. Ik zit hier nog altijd een jaar op deze 1&1 ISP vast.

Het is gewoon idioot dat je moet ISP jagen, als oplossing voor een rommeltje dat puur afhangt van hoe ipv6 opgebouwd is en hoe het geimplemteert is.
De prefix zal bij een provider-wissel inderdaad schuiven (sowieso, want net als bij IPv4 (CIDR ranges) is IPv6 in ranges (prefix) verkocht aan providers)

De oplossing voor een fixed prefix zou zijn dat je zelf een prefix koopt en er providers bij zoekt die werken met klant-geleverde prefixes.

Voor de prefix-wissel bij de provider zijn twee mogelijke work-arounds:
1) niet constant hoppen;
2) automatiseren van de fixed IPv6 configuratie update zodat het (buiten een initiele flinke inspanning) weinig moeite kost.

Prima mogelijk nog om zaken ondanks het globaal unieke IPv6 toch niet online te ontsluiten. Minstens de helft van wat ik aan VMs heb draaien heeft een eigen 'publiek' fixed IPv6, maar kan enkel bereikt worden vanaf internet via een IPv4+IPv6 reverse-proxy.
Het is gewoon idioot dat je moet ISP jagen, als oplossing voor een rommeltje dat puur afhangt van hoe ipv6 opgebouwd is en hoe het geimplemteert is.
Ja, maar ik geef de schuld aan de ISPs die zich er zo makkelijk mogelijk van af willen maken. Ik zal er wel bij zeggen dat er misschien niet één "juiste" antwoord voor iedereen is en dat er nog wel wat verschil van inzicht is over wat de "juiste" configuratie is. Het voelt allemaal heel geforceerd en een samenraapseltje van ideeen over hoe een modern netwerk er uit zou moeten zien. Het is een mix van oud en nieuw en er lijkt vaak niet goed over nagedacht waardoor zaken behoorlijk schuren.

IPv4 van nu is ook niet meer het IPv4 uit 1992. Sindsdien heeft de focus heel erg gelegen bij het minimaliseren van het aantal ip-adressen dat je nodig hebt en het vriendelijk genoeg te maken voor eindgebruikers. Daardoor hebben we nogal wat vreemde gewoontes opgepikt (zoals NAT en éénrichtingcommunicatie) en we worstelen een beetje met de vraag hoe we daar nu mee om moeten gaan. Gooien we de beperkingen van IPv4 overboord zodat we weer functionaliteit terug krijgen of blijven we in het IPv4-keurslijf zitten ook al is dat niet meer nodig.

Ik geef de schuld dus aan de ISPs, die zijn immers verantwoordelijk voor ervaring die mensen thuis hebben. Het probleem is volgens mij vooral dat ze te lang hebben gewacht waardoor ze nu pas gaan bedenken hoe het zou moeten werken en ze nu pas met de kinderziektes te maken hebben.
Het probleem zit hem denk ik ook in de extra complexiteit die het meebrengt. Wij heben IPv6 overal actief en draaien dus IPv4 en IPv6 als dual stack. Echter blijf ik voor interne netwerken IPv4 prefereren vanwege de simpliciteit.

Naar mijn gevoel was IPv6 al lang en breed uitgerold moest men gewoon de addresspace van 4B naar 8B hebben vergroot en adressen gewoon xxx.xxx.xxx.xxx.xxx.xxx.xxx.xxx hebben gemaakt en voor de rest gewoon dezelfde protocollen zoals DHCP, ICMP, ... hebben gebouwd eventueel met extra security.
Hier juist andersom: Wij hebben honderden fysieke servers en duizenden VM's IPv6-first gemaakt, al jaren geleden. IPv4 waar het nodig is, verder IPv6.

Kan gewoon prima, je moet het alleen ook willen doen.

(Dit idee afgekeken van Facebook overigens)
Hij heeft waarschijnlijk ook wel IPv6-first maar het zelf nog niet door? Of hij heeft het nog niet volledig geconfigureerd.

Windows en Linux prefereren IPv6 en veel Microsoft kunnen niet eens zonder gebruikt worden (Exchange).
Maar meestal weet men dit gewoon niet ;)
Hier juist andersom: Wij hebben honderden fysieke servers en duizenden VM's IPv6-first gemaakt, al jaren geleden. IPv4 waar het nodig is, verder IPv6.

Kan gewoon prima, je moet het alleen ook willen doen.

(Dit idee afgekeken van Facebook overigens)
Precies dit zou de mentaliteit moeten zijn, ipv vasthouden aan IPv4
_/-\o_
Voor de simpliciteit kan je beter je interne netwerk IPv6-only doen, en IPv4 enkel aan de WAN kant.
Qua netwerkapparatuur geen probleem, maar qua applicaties wel. Veel (legacy) applicaties kunnen helemaal geen IPv6 doen. Bij de grote bedrijven is dat een probleem, daarom moet je sowieso dual-stack doen.

Wij hebben IPv6 aan de WAN kant en IPv6 grotendeels intern, backbonen is wel IPv6, alleen de andere omgevingen nog niet. We hebben wel alle voorbereidingen gedaan.
Ja. En ik ben er ook wel voorstander van dat je geen IPv4 mag gebruiken zonder ook IPv6 te configureren. IPv4 mag alleen nog om legacy reden, IPv6 first beleid.

Helaas zijn er echt veel te veel ICTers die ipv6 te “moeilijk” vinden of het belang er niet van in zitten. De tijd van lief vragen is voorbij.

Edit: hoop ipv6 haters blijkbaar onder de mods :+

[Reactie gewijzigd door 3dmaster op 27 juli 2024 07:19]

Veel van mijn collega's begrijpen ipv6 ook nog steeds niet en lijken er ook geen tijd erin te willen stoppen.
Zolang IPv4 prima werkt, kan ik ze ook niet overhalen.

Maar als IPv4 duurder wordt in gebruik, zal het mogelijk vanaf het management wel doorgedrukt worden.
Geld bepaald alles uiteindelijk.
Veel van mijn collega's begrijpen ipv6 ook nog steeds niet en lijken er ook geen tijd erin te willen stoppen.
Zie men lange rant hieronder ergens ( Anoniem: 76058 in 'AWS gaat geld vragen voor gebruik van publieke IPv4-adressen' ).

Het is niet dat we er geen tijd willen instoppen, het is het probleem dat men de boel te ingewikkeld gemaakt heeft, ipv Ipv4 voor eigenlijk weinig voordelen.

Men kon gerust Ipv4 genomen hebben, 2 extra blokken toevoegen (wat letterlijk 999999 * de ganse ipv4 range extra addressed zou geweest zijn) en de overstap zou VEEL simpeler geweest zijn. Ja, ik spreek over 999 want men had de boel gewoon direct op grotere range kunnen zetten ipv een single byte.

ipv6: 2001:db8:3333:4444:CCCC:DDDD:EEEE:FFFF
ivp4+: 999.999.255.255.255.255

Wat is meer leesbaar? Je behoud de lasted 4 als bytes voor compatibility

De oude Ipv4 is 0.6 ips per bewoner op de wereld. Een 2 extra block, zou 602.828 ips zijn PER bewoner op de wereld.

En geen gedoe met pre en postfix blokken, je houd de rest gewoon met NAT enz. Het probleem is dat het minder leesbaar is, dat men de boel ingepekelde maakt om te configureren met pre-postfix blok structurer ZEKER wanneer beide kunnen veranderen.

Simpeler ook op de software gebied en VEEL simpeler in het configureren want Ipv6 heeft enorm caviats wanneer je prefix en postfix kunnen veranderen, en dat over je router loopt.

Ik heb 2 dagen tijd verspild om een huis NAS proberen toegankelijk te maken via ipv6 (en er gewoon niet ingeslaagt zijn). Het aantal stress en frustratie dat ik had, heb ik nooit gehad toen ik met IPv4 werkte. Is niet van niet willen leren, het is de dozen verschillende issues (zie andere post) dat de boel zo frustrerend maken. Enige dat ik wou van Ipv6 was Ipv4+extra blokken, en de rest dezelfde. Dat is het. Ik heb geen noodzaak dat ieder toestel in men huis zijn eigen extern toegankelijk ipv6 address heeft EN WIL IK OOK NIET!!! Is gewoon een idiote security ramp voor de toekomst. Dat een hoop ITers zoals mijzelf dachten dat dit een goed idee was, jongens toch...

Frustratie en frustratie, dat is wat ik vind van Ipv6 en jaja, ik zal commentaar krijgen dat ik het misdeed of wat dan ook, maar dat is dezelfde reden dat je colleges de boel niet willen aanraken. Het is gewoon niet zo simpel als ipv4 en waarom zouden mensen dan omschakelen. Een oplossing bedacht door ITers dat niet 2 seconden langer konden denken ( en ik zeg dat een 30 jaar ervaring ITer )

[Reactie gewijzigd door Anoniem: 76058 op 27 juli 2024 07:19]

Men kon gerust Ipv4 genomen hebben, 2 extra blokken toevoegen (wat letterlijk 999999 * de ganse ipv4 range extra addressed zou geweest zijn) en de overstap zou VEEL simpeler geweest zijn. Ja, ik spreek over 999 want men had de boel gewoon direct op grotere range kunnen zetten ipv een single byte.

ipv6: 2001:db8:3333:4444:CCCC:DDDD:EEEE:FFFF
ivp4+: 999.999.255.255.255.255

Wat is meer leesbaar? Je behoud de lasted 4 als bytes voor compatibility
Het is misschien leesbaarder maar technisch gezien is het nog complexer dan IPv6. Je zal nog steeds alle hardware en software moeten vervangen. Alle andere problemen die je noemt zouden net zo zeer gebeuren.
En geen gedoe met pre en postfix blokken, je houd de rest gewoon met NAT enz.
Er is wat dit betreft technisch gezien geen echt verschil tussen IPv4 en IPv6. De verschillen die je ziet zijn implementatiekeuzes.
Het probleem is dat het minder leesbaar is, dat men de boel ingepekelde maakt om te configureren met pre-postfix blok structurer ZEKER wanneer beide kunnen veranderen.
Dat is altijd zo geweest alleen werd het in IPv4 meestal platgeslagen tot 1 adres waardoor je zelf het verschil niet ziet.
Ik heb 2 dagen tijd verspild om een huis NAS proberen toegankelijk te maken via ipv6 (en er gewoon niet ingeslaagt zijn). Het aantal stress en frustratie dat ik had, heb ik nooit gehad toen ik met IPv4 werkte.
Het is misschien niet eerlijk om dat te vergelijken met een systeem waar je al 30 jaar ervaring mee hebt en dat in de tijd veel simpeler was (zaken als DHCP en NAT zijn pas later gekomen en de meeste mensen hadden maar 1 computer thuis een geen heel thuisnetwerk). In die tijd was het typisch ook het eerste en enige netwerk, niet een extra netwerk dat je toevoegt aan een bestaande situatie.
Is niet van niet willen leren, het is de dozen verschillende issues (zie andere post) dat de boel zo frustrerend maken. Enige dat ik wou van Ipv6 was Ipv4+extra blokken, en de rest dezelfde. Dat is het.
Dat is precies hoe het werkt.
Ik heb geen noodzaak dat ieder toestel in men huis zijn eigen extern toegankelijk ipv6 address heeft EN WIL IK OOK NIET!!! Is gewoon een idiote security ramp voor de toekomst. Dat een hoop ITers zoals mijzelf dachten dat dit een goed idee was, jongens toch...
Zoals ik al eerder schreef: dat is een implementatiekeuze en heeft niks te maken met IPv4 vs IPv6.
Ik zou me niet te veel voorstellen bij de veiligheid die NAT biedt. Om het systeem te laten werken moet het heel erg goedgelovig zijn. Typisch heb je er ook een firewall naast die het echte werk doet.
Frustratie en frustratie, dat is wat ik vind van Ipv6jaar ervaring ITer )
Ik heb met je te doen. De problemen die je ziet hebben echter weinig met IPv6 te maken en vooral met verandering. Iedere andere oplossing zou ook problemen hebben opgeleverd.

[Reactie gewijzigd door CAPSLOCK2000 op 27 juli 2024 07:19]

Ik ben zelf ook niet zo positief over IPv6. Ik heb er altijd alleen maar problemen mee gehad (zoals dat het actief is op hosts in een IPv4-only netwerk die vervolgens netwerkproblemen krijgen omdat ze toch IPv6 gaan proberen te praten). Maar behalve eventuele problemen, *wil* ik ook helemaal geen subnet voor mijn huisnetwerk van mijn provider krijgen. Mijn huisnetwerk is van mij, geen extensie van die meuk van de provider. Dus is alles hier lekker een afgesloten 192.168 netwerk met een gateway, *zoals het hoort* imho. Je hebt sowieso een gateway nodig, die hoeft niet alles lekker door te laten naar wat er achter hangt. Dan moet je weer aan de slag met firewalls. Alles blokkeren tenzij expliciet toegestaan. Leuk, ben je allemaal werk kwijt om van alles bij te houden die niet nodig was als je gewoon bij IPv4 was gebleven. Met de groeiende jungle van smart-meuk in sommige woningen wordt dat echt chaotisch.
Maar behalve eventuele problemen, *wil* ik ook helemaal geen subnet voor mijn huisnetwerk van mijn provider krijgen. Mijn huisnetwerk is van mij, geen extensie van die meuk van de provider. Dus is alles hier lekker een afgesloten 192.168 netwerk met een gateway, *zoals het hoort* imho.
Wat jij wil kan prima. Je bent niet verplicht het hele subnet van de provider te gebruiken. Je kan daar gewoon 1 adres uit pakken en dat voor je gateway gebruiken. Een andere interessante optie is om een 1:1 nat te tussen de adressen van je provider en je eigen systemen.
Je hebt sowieso een gateway nodig, die hoeft niet alles lekker door te laten naar wat er achter hangt.
In praktijk werkt het toch zo bij consumentenverbindingen? Je krijgt een kastje van je provider en daar zit een router en een firewall en een switch in. Ik ken niemand die alleen een switch krijgt zodat alles direct aan internet moet hangen.
Dan moet je weer aan de slag met firewalls. Alles blokkeren tenzij expliciet toegestaan.
Ik ken geen Nederlandse ISP die het zo levert. Alle ISPs die ik ken die IPv6 leveren die leveren ook een kastje met een default-dicht firewall.
Leuk, ben je allemaal werk kwijt om van alles bij te houden die niet nodig was als je gewoon bij IPv4 was gebleven. Met de groeiende jungle van smart-meuk in sommige woningen wordt dat echt chaotisch.
Dat is niet de praktijk die ik ken. Ik vind IPv6-firewalling juist makkelijker omdat je geen portforwarding hoeft te doen. Ik kan gewoon zeggen "poort x op apparaat y moet publiek beschikbaar zijn" en dat is genoeg. Bij IPv4 heb je altijd te maken met 2 ip-adressen en 2 poorten (die soms wel en soms niet hetzelfde zijn).

Als je die smartmeuk op internet wil aansluiten (wat veel mensen nu eenmaal willen) dan moet je met IPv4 zelf zorgen dat ieder apparaat een unieke poort heeft. Ze willen echter allemaal op poort 80/443 zitten. Dan moet je zelf gaan bijhouden welke poort naar welk apparaat wijst. Dat is ook niet echt fijn te managen.
Tsja, IPv6 is er nog steeds moeilijk doorheen te krijgen “het werkt toch” en “kost tijd, dus geld” (al is dat in de meeste gevallen echt max 5 minuten), worden nog altijd veel genoemd.

Zo goed als elke keer dat er een domein met IPv6 langs komt wat verhuisd wordt gaat het fout. Of men stelt IPv6 na verhuizing niet in, of laat de default van de provider staan. Een stukje educatie is dus wel nodig. Twee jaar geleden kwam er zelfs nog een ISP voorbij waar IPv6 niet ingesteld kon worden via een CP, maar waar een foute waarde wel werd overgenomen. Dat moest toen handmatig worden opgelost.

Incentives zijn wel nodig denk ik, maar totdat de overheid erin springt met boetes zullen weinigen zich geroepen voelen er iets aan te doen.

Amazon zou hierin ook mee kunnen doen door IPv6-loze IPv4 dubbel te belasten, maar dat zullen de klanten niet leuk vinden en het is lastig te controleren of de IPv6 wel echt gebruikt wordt. Aan de andere kant heeft bijvoorbeeld TransIP dan wel weer IPv6-only VPS om mee te testen en die zijn qua capaciteit goedkoper dan een VPS met IPv4.
Er zijn nou eenmaal een hoop oude rotten in de business, dat verander je niet zomaar even.
Zeker op netwerk gebied heeft men nog heel veel ouderwetse gedachten.
Ik merk dat met 'Moderne werkplek' omgevingen, het liefst wil men tientallen VLANs en firewall regels doorvoeren terwijl ik ze moet overtuigen dat een simpele ongefilterde internetverbinding een betere ervaring geeft.
Zero trust networking gaat idd volledig in tegen de ouderwetse gedachte, het is moeilijk om een complete generatie mee te krijgen.
Goed, er zijn nog zat cloud-services van de grote 3 die IPv6 helemaal niet ondersteunen. Voor zover ik weet ondersteunt AWS Lambda dit ook nog niet, terwijl dat toch een van de meest aantrekkelijke features is voor nieuwe producten.
Ik zit totaal niet in de hele IPv6 materie, en ik heb geen idee of ik het gebruik, hoe ik het kan gebruiken, etc. etc. Dus voor thuisgebruik zal het echt door providers moeten worden geregeld.
En gebeurt dat al? Of moet dat nog? En hoe zit het met apparatuur (zowel thuis als buitenshuis)?
Ligt aan je ISP. Ziggo en KPN doen al netjes IPv6. Freedom en XS4All (nu KPN) ook en nog wat andere ISP's.

T-Mobile thuis moet je daarom met een grote boog omheen lopen :-)

Het is in 2023 toch echt wel tijd je hier eens in te verdiepen.
Meer zelfs, GitHub heeft in 2023 nog steeds geen IPv6, dus kan je van een IPv6 only server zelfs niet eens iets clonen of binnenhalen.

Dat zoiets anno 2023 nog kan is te bizar voor woorden.
Het probleem is voor praktisch iedereen, welk voordeel levert het gebruik van IPv6 nou op. Eigenlijk helemaal niets. Alles kan IPv4 praten en maar een klein deel kan IPv6 praten. Oftewel, je MOET IPv4 supporten anders kan een groot deel van de gebruikers/clients je niet eens bereiken. Je hebt er dus best wat last van in de vorm van tijd, maar je krijgt er eigenlijk niets voor terug.
Dat is nog best aan de prijs met $3,36 per maand, zeker als je een paar adressen gebruikt tikt dat snel aan.
Zijn er nog use cases dan dat je een fixed public IPv4 adres nodig hebt?
Het is niet noodzakelijk fixed, maar gewoon een publiek IPv4 adres dat dynamisch is toegewezen wanneer je de resource start lijkt mij. Je betaald voor zolang je het IP adres in gebruik hebt en vasthoudt. Van zodra je alles uitzet en stopt met voor het adres te betalen kan een ander datzelfde adres krijgen toegewezen en de volgende keer dat jij alles start krijg jij waarschijnlijk ook weer een ander adres.
Ah ja dat kan ook. Maar kan men dan niet een IPv6 adres gebuiken?
Hangt ervan af of de partij aan de andere kant van de lijn beschikking heeft over IPv6.
Veel applicaties ondersteunen nog altijd geen IPv6 dus nee. Voor een website zou je nog een CDN zoals Cloudflare kunnen gebruiken.
Als je via een firewall systeem toegang nodig hebt en je kan daar alleen ipv4 opgeven. Vanuit een bedrijf zou dus best nodig zijn. Wij zitten hetzelfde met Azure databases welke een vast ip nodig hebben voor onze firewall.
Een ipv6 adres kan toch ook wel vast zijn lijkt mij?
Zeker, alleen alle systemen hier zijn nog ingericht op het whitelisten van IPv4..... Duurt altijd lang voordat dat soort dingen veranderen hier.
Misschien je firewall upgraden (of dat overwegen)? Meeste firewalls zijn tegenwoordig voorzien van IPv6 ondersteuning :)
Dat roepen we al jaren maar het schiet hier niet op, dus het is (nog) nodig. Uiteraard zijn er andere oplossingen maar in een groot bedrijf heb je weinig invloed hierop (grote multinational....)
Dat kan natuurlijk ook, maar dan zullen de kosten vanzelf zoveel toenemen dat het management er op wil gaan bezuinigen. (Dus een goede ontwikkeling)

Ik werk bij een klein bedrijf en alle technische beslissingen worden met het gehele technische team genomen. Het management kijkt dan naar de kosten en geeft er zijn 'stempel' op. Je kan al wel raden dat wij daarom ook over zijn op IPv6 als standaard :)
Er worden hier miljoenen verkwist aan dit soort dingen elke jaar dus die jaar euro voor een adres zal niemand wakker van liggen.
Eer dat het in de kosten gaat lopen ben je alweer een aantal jaren verder en is je complete infrastructuur alweer vervangen :p

Als ik bij ons kijk, paar 1000 servers, dan zal ipv6 weinig problemen oplossen. Dit soort keuzes liggen bij ons ook bij de techneuten maar die zullen hier niet zo 123 voor kiezen
Dank voor de toelichting, weer wat geleerd :)
Ja, die zijn er wel, alleen die zijn in de praktijk sporadisch. Er zijn voor (vrijwel alle??) use cases weliswaar technische alternatieven, maar dan moet je applicatie daar wel mee overweg kunnen.

Denk aan bepaalde database koppeling en site to site VPN. Wat ik al schreef. Er zijn alternatieve methoden voor, maar niet alle applicaties gaan daar even makkelijk mee overweg.
En uiteindelijk is de functie van je applicatie je doel en niet het cloudplatform.
Dankje voor de info!
Ja, die zijn er zeker. Er zijn best veel bedrijven die de firewall dicht hebben staan en enkel een fixed IP wil openstellen. Dan is het wel fijn dat dit IP adres niet veranderd. Overigens gaat het hier om ieder IPv4 adres en niet zozeer fixed. Je krijgt -tenzij je expliciet een fixed IP adres vastlegd- gewoon een dynamisch geallokeerd IPv4 adres per EC2 instantie en volgens mij betaal je daar ook gewoon voor. Bij een fixed IP betaal je gewoon 24/7 (ook als die EC2 instantie niet actief is).

Bij Azure betaal je bij mijn weten al lang voor een publiek IP adres, dus zo vreemd is het niet dat AWS dat nu ook gaat doen. Ook al draai je in een intern cluster, dan nog is het soms prettig om een publiek IP adres te hebben (bijv. om bij Dynamo DB, S3, ... te komen). Daar zijn wel weer andere workarounds voor, maar dat kost vaak meer effort en/of performance. Een NAT gateway is ook weer niet gratis.

[Reactie gewijzigd door BugBoy op 27 juli 2024 07:19]

Merci! Ik begrijp het nu wat beter :)
Als jij een service wil hosten in EC2 wil je toch van (bijv.) huis of kantoor er bij kunnen? En aangezien IPv6 nog niet beschikbaar is bij de meeste providers…
IPv6 is wel degelijk beschikbaar bij in ieder geval de grootste providers. Zowel KPN als Ziggo ondersteunen IPv6, en van de kleinere ISPs zullen er ook wel IPv6 ondersteunen. Uitblinkers op het gebied van afwezigheid hiervan zijn Delta / Caiway en T-Mobile. Waarbij de eerste momenteel zelfs CGNAT gebruikt op IPv4 wat de situatie alleen maar erger maakt (geen uniek adres dat je bv aan een "cloud" kant kunt whitelisten omdat het IP adres gedeeld is met tientallen/honderden/duizenden klanten).
Geen enkele serieuze hoster gaat het halve internet uitsluiten door exclusief op IPv6 te hosten. IPv4 is daarom gewoon nog essentieel.

Delta en T-Mobile zijn nou ook niet bepaald kleintjes.
Natuurlijk is IPv4 nog redelijk essentieel. Maar je hoeft ook niet de gehele infrastructuur op IPv4 te draaien. Als je bv 5 servers hebt met loadbalancing ertussen dan kan er prima een loadbalancer voor staan met een IPv4 adres (+ IPv6 adres) en dat de 5 daadwerkelijke servers waar de software op draait alleen IPv6 doen of alleen over een private network via IPv4 beschikbaar zijn (dus een 192.168.0.0/16 adres, of een 10.0.0.0/8 etc).
Dat zal ook wel zijn wat AWS wil bereiken. Dat niet een gehele cluster een IPv4 adres moet hebben, maar alleen het "entrypoint".

En webhostingpartijen die een kant en klaar hosting pakket aanbieden kunnen dat dus ook doen. Load balancer met IPv4 en de server(s) waar de daadwerkelijke sites op draaien alleen via private IPv4 adressen of IPv6 bereikbaar. Immers kun je websites (HTTP) al jaren routeren op basis van de meegezonden Host header. En bij FTP (bestaat dat nog? :X) kan dat ook. Immers had je 10, 20 jaar terug ook al shared hosting waarbij sites van meerdere klanten perfect op één server konden draaien.
IPv4 is nog essentieel, maar je sluit al lang niet meer het halve internet uit. Er zijn niet zo heel veel belangrijke diensten meer die nog geen v6 ondersteunen. Zodra je v6 hebt gaat het merendeel van je verkeer over v6.
IPv6-only hosting is heel normaal, maar dan met een IPv4 loadbalancer ervoor voor het (langzaaam krimpende) legacy verkeer.
Geen enkele serieuze hoster gaat het halve internet uitsluiten door exclusief op IPv6 te hosten. IPv4 is daarom gewoon nog essentieel.
En daardoor zit die markt op slot. Het is zo duur om IPv4-adressen te kopen als je ze nog niet hebt dat je haast geen bedrijf meer kan oprichten dat een flinke hoeveelheid IPv4-adressen nodig heeft. Je kan ze alleen krijgen door ze voor veel geld van anderen te kopen of te huren.

Hosting voor een VPS aanbieden voor €100 euro per jaar wordt lastig als de IPv4-adressen alleen al €50 per stuk kosten. Hoeveel jaar moet je een klant wel niet vasthouden om dat terug te verdienen?

Ik denk niet dat het een bewuste strategie is maar volgens mij vinden veel grote gevestigde bedrijven het eigenlijk wel best dat er geen nieuwe concurrenten bij kunnen. Hoe meer ze de uitrol van IPv6 vertragen hoe moeilijker het wordt voor anderen om de markt nog te betreden.

Daarom denk ik dat het tijd is dat de ACM ingrijpt en de grote (internet)bedrijven dwingt om volwaardige IPv6 aan te bieden zodat er niet meer geconcurreerd hoeft te worden op wie er in het verleden (te) veel adressen heeft gekregen.
Hier ligt een Ziggo verbinding en nog steeds geen IPv6. Maar ja ik zit dan wel bij ittdesk dus de kans dat het aan hen ligt is ook redelijk groot.
In toenemende mate is dat je eigen probleem. En je kunt altijd 6to4 of Teredo gebruiken.
Sorry? Ziggo wil hier nog niet aan de IPv6 en glasvezel al helemaal niet.
Dan neem je dus een internetaanbieder die het wel aanbiedt of configureert 6to4.
Die is hier niet, en zeker niet in de kwaliteit die je wil. Ik ga ook geen overhead toevoegen met die onzin als 6to4.

Dit moet gewoon aan de kant van de provider opgelost worden en daarna kan de rest. Ik snap niet dat de overheid of EU hier niet op ingrijpt.
Helemaal prima, maar dan is het je eigen keus dat je geen v6 hebt en dus de overlast voor lief neemt. Je zult zien dat grote bedrijven steeds minder geduld gaan hebben met mensen die nog geen v6 hebben, wat AWS hier doet wordt de regel en de prijs voor V4 stijgt verder.
Hoe is het mijn eigen keus? Ik krijg geen IPv6, en de provider wil dat niet aanbieden. Een bridge is niet te doen en te onderhouden in een huishouden met verschillende devices en ik ga geen achterlijk dure router kopen waar je een universitaire studie bij moet doen om te configureren. Nee, dit is niet mijn eigen keus, dit is opgelegd.
Het is een keus om een internetaanbieder te nemen die geen V6 doet, het is een keus om geen transitietechniek te willen configureren. En het is een keus om geen apparatuur te willen kopen.
Nee, maar dingen als het vinkje 6to4 in je Fritzbox aanvinken of even Miredo installeren kan ik iedereen wél aanraden.
Ik heb geen Fritzbox en ik ga me niet verdiepen in netwerktechnologie. Ik heb dat ooit gedaan maar dat kost te veel tijd en moeite. Internet moet gewoon werken, punt.
Dus weer een keus die je gemaakt hebt... en daar is helemaal niets mis mee, alleen keuzes hebben gevolgen, en die zijn dat IPv4 steeds duurder wordt en minder fijn gaat werken de komende jaren. Maar geen zorgen, er zijn geen aanwijzingen dat v4 gaat verdwijnen.
6to4 en Teredo, dat is een "blast from the past". Allebei al jaren deprecated.

Men doet dit tegenwoordig met IPv6 servers achter IPv4 loadbalancers.
Zal best, maar het is wel wat je doet als je op een v4-netwerk terecht komt. Vinkje 6to4 aanzetten op je Fritzbox bijvoorbeeld en je hebt ipv6. Geen andere oplossing kan dat evenaren, als internetaanbieder geen v6 ondersteunt en dat wat je wilt. Teredo eveneens, even miredo installeren, starten en tadaa ipv6, niemands hulp nodig, help yourself, klaar.
Dat is ook een beetje een kip/ei-verhaal. Op dit moment is ipv4 een must. Als je server alleen ipv6 ondersteunt, beperk je de bereikbaarheid enorm. En als je op je eigen netwerk alleen ipv6 aanzet, dan zal je nog steeds enorm veel diensten en sites niet kunnen bereiken.

Dit soort financiële incentives kunnen hier misschien verandering in brengen. Ooit zal er hopelijk geen dual stack meer nodig zijn. Als alles op ipv6 werkt, kun je ipv4 laten vallen. Dat scheelt ook weer geld. Momenteel kost het nog steeds erg veel geld om 2 volledige ip stacks te draaien.
Zijn er nog use cases dan dat je een fixed public IPv4 adres nodig hebt?
Uitgaande verbindingen vanuit je app die je moet kunnen whitelisten in een firewall
Dat kan ook met IPv6? Als in, waarschijnlijk is de andere kant ook een server met dus IPv6.

[Reactie gewijzigd door MiesvanderLippe op 27 juli 2024 07:19]

IPv6 firewalling werkt prima, net als IPv4 firewalling. Dat kan al tientallen jaren met ipchains, IPF en later ook met iptables, PF, nftables.

Waarschijnlijk doelt @Sfynx op de toepassing van NAT als firewall. Als je default uitgaande verbindingen blokkeert dan is dat geen probleem. Ook kun je in Android een VPN instellen en alle applicaties die VPN laten gebruiken. Android regelt dan de routing, en jij kunt dan met een allow of denylist e.e.a. regelen. Dat zou gewoon moeten werken. Ook LTE kan prima dual stack. Dat de Nederlandse providers het niet doen of kunnen, ligt aan hen.
Ik doelde in mijn eerdere post op uitgaande verbindingen vanuit jouw app die ergens anders gewhitelist moeten worden in een firewall van een of andere externe leverancier waar jij geen controle over hebt. Je krijgt dan de vraag "wat is je IP-adres, dan zetten we het open", en dan zal je dus voorspelbare uitgaande publieke IP-adressen moeten gebruiken, bijvoorbeeld via een NAT gateway die source NAT doet o.i.d.

En IPv6 is dan helaas niet altijd een optie.

[Reactie gewijzigd door Sfynx op 27 juli 2024 07:19]

Oh ja dat heb ik inderdaad wel eens gehad met OpenSSH. ssh -b kun je source adres mee aangeven, maar je kunt ook routing vanaf de machine gebruiken. Dus bijvoorbeeld target_ip routen over interface eth0:1

Het is pas een probleem met CGNAT omdat je dan voor te grote groep de boel openstelt. Maar dan moet je IPv6 boven IPv4 prefereren, en IPv6 ook correct implementeren. Door dat niet te doen, kom je bij sommigen uit op CGNAT (ofwel NAT) dat een te wijde scope heeft.
Kan dat niet op DNS naam?
DNS naam zal altijd naar een IP moeten resolven. Je werkt altijd met een IP, ook als deze dynamisch toegewezen wordt en dagelijks zou veranderen.
Maar dat kan ook naar IPv6-only resolven? Ik zie trouwens zat usecases voor IPv4, maar toch. :P
Och ja, sorry het is nog vroeg :+
Publiek gehoste websites? Verbindingen tussen twee entiteiten via een VPN/firewall? Kan genoeg use cases bedenken en durf te wedden dat het merendeel van websites die niet achter Cloudflare hangen gewoon vaste publieke IPs gebruiken.
Wat een agressie. Mag iemand die er geen verstand van heeft geen vragen meer stellen?
Van de andere kant zal een middelgroot bedrijf dat serieus gebruik maakt van aws al snel een rekening van duizenden euro's per maand hebben. Voor veel bedrijven zal het een druppel op een gloeiende plaat zijn.
Het gaat minder om kosten, maar om opbrengsten en marge.

Als iets dat voorheen gratis is mij nu geld kost en geen meerwaarde/marge biedt, dan gaan mijn resultaten naar beneden.

Dan moet ik of ergens anders groei hebben om het te compenseren of ik ga wel degelijk kosten besparen.

Failliet zal je er niet snel van gaan, maar juist ook dit soort kleine dingetjes gaan gewoon in de TCO mee en indien de post voldoende hoog is, dan komt er een projectje om die terug te dringen.

If “Kosten IP adres > “kosten engineer”, dan komt het zeker op de radar!

[Reactie gewijzigd door Keypunchie op 27 juli 2024 07:19]

If “Kosten IP adres > “kosten engineer”, dan komt het zeker op de radar!
Ik denk dat met dit soort veranderingen (grotere) bedrijven ook heel erg gaan kijken naar de toekomst, als dit nu al gebeurt, is de kans zeer groot dat de prijzen in de komende jaren eerder omhoog zullen gaan ipv. naar beneden, waardoor deze kostenpost alleen maar groter gaat worden. Dan is het interessant om iemand een onderzoek te laten doen naar de mogelijkheden om deze kosten te beperken en een kosten/baten analyse laten maken voor nu (en in de toekomst).
Neuh, dat zijn pennies voor grote bedrijven. Voor de kleinere is het een beetje slikken (vooral kleinere projecten).

Maar goed 3 euro per maand is ook weer niet super veel, maar begrijp inderdaad dat 1 + 1 + 1 veel wordt.

[Reactie gewijzigd door ilaurensnl op 27 juli 2024 07:19]

Als iets dat voorheen gratis is mij nu geld kost en geen meerwaarde/marge biedt,
Als een IPv4 adres geen meerwaarde voor je heeft dan zet je het uit :)
[...]

Als een IPv4 adres geen meerwaarde voor je heeft dan zet je het uit :)
Maar in de praktijk: als uitzetten eenmalig geld en/of moeite kost en aan laten staan gratis is laat je dat waardeloze ding zonder meerwaarde gewoon lekker aan staan.
En nu het geld gaat kosten wordt het de moeite waard om het uit te zetten.....
(en er mogelijk achter te komen dat er eea omvalt, en het toch meerwaarde blijkt te hebben)
Dit valt voor mij wel wee ronder de licentie maffia. Eerst vanalles gratis aanbieden en daarna er geld voor vragen. wanneer je eignelijk niet meer weg kan. Althans niet makkelijk of snel.
Voor IPv4 gaat die vlieger natuurlijk niet op, we wisten al decennia geleden dat de IPv4 'op' zou raken en de IPv6 standaard is al bijna 25 jaar oud en nog steeds kijken heel veel mensen/bedrijven er niet naar om. Nu zal de motivatie er zijn voor bepaalde groepen met bepaalde oplossingen om te kijken naar IPv6 en het daadwerkelijk te implementeren. Want ook bij Amazon raken de IPv4 adressen 'op'...

Don't get me wrong, in verschillende situaties is IPv6 (alleen) geen optie omdat je afhankelijk bent van een andere partij (denk aan financiële netwerken waar je niet omheen kan) of omdat de hardware het niet ondersteund (aan de andere kant). Maar er zijn legio instanties waarbij het wel kan en dan wordt het nu echt tijd om over te stappen!

Ik ben geen fan van de IPv6 implementatie, ik had veel liever gezien 256.256.256.256.256.256, maar dat is niet de realiteit, so be it!
Je mag het gratis gebruiken. Voor nieuwe gebruikers geen enkel probleem mee.
Tja, lock-in op een cloud platform is nu eenmaal een ding. Het is aan bedrijven zelf om daar vanaf het begin rekening mee te houden en architectuur te creëren die zoveel mogelijk draagbaar is.
Een ip4-adres op de vrije markt kost momenteel zo'n $40-$60 en die prijzen gaan voorlopig niet dalen. Ze vragen nu zo'n $43,80 per jaar per ip-adres, dat is niet een hele gekke prijs. Het zet klanten in ieder geval aan om zuiniger te zijn met hun publieke ip-adressen en niet even een hele rits ongebruikt te laten.
Inderdaad, voorlopig gaat de prijs voor IPv4 nog wel een tijd omhoog.

Het fascinerende is dat er op een gegeven moment een omslagpunt zal zijn waarbij mensen thuis en op kantoorwerkplekken geen IPv4 meer nodig hebben en de prijs ineens gigantisch in zal klappen. Dan zal een IPv4 adres alleen nog interessant zijn voor de serverkant om klanten met legacyverbindingen te kunnen bedienen. ISP’s en bedrijven kunnen dan hele IPv4 ranges gaan verkopen, waarschijnlijk zo snel mogelijk voordat de waarde verder daalt.

Waar dat punt ligt zal lastig in te schatten zijn en ook regionaal verschillen. Nederland loopt een beetje achter op IPv6 gebied maar België loopt dan bijvoorbeeld weer flink voor. Hier in het VK zul je denk ik echt moeten zoeken naar een ISP die alleen maar IPv4 levert en zijn er ISP’s die een publiek IPv6 met een IPv4 adres uit de RFC1918 range leveren (CG-NAT).

Ik heb thuis af en toe een klapperende lijn en mijn IPv6 adres komt altijd meteen terug maar voor IPv4 heb ik soms een herstart van het modem nodig. Het valt me vaak pas na een uurtje of zo op dat mijn IPv4 er uit ligt omdat de meeste internetdiensten tegenwoordig gewoon over IPv6 gaan.
Ik kon een paar jaar terug een /24 kopen voor iets van $23 per IP. Had ik dat gedaan had ik m'n geld nu verdubbeld. iPv4 is momenteel een betere belegging dan aandelen.
Voor de hobby gebruiker misschien maar daar is AWS eigenlijk niet voor. Voor zakelijke gebruikers zal die paar euro niet uitmaken. Helemaal niet als je kijkt wat een EC2 instance kost als je een beetje performance nodig hebt...
Hoe kom je precies op die $3.36 uit dan ?
0.005 * 24 uur = 0.12 / dag
0.12 * 30 dagen = $3.60 / maand
Mwha hetzner betaal je ook 2 euro per maand en dat is volgensmij ook gewoon een normaal tarief...
Hm irritant want dat is best duur. De prijs die ze daar vragen is hetzelfde wat ik voor mijn hele VPS betaal (storage + IP + computing voor een maand). Maar dat is op Scaleway - Stardust VPS.

Ik hoop dat de andere providers niet gaan volgen.

Hier bij mijn Spaanse provider (reseller van Orange) kan ik nog niet eens IPv6 krijgen...

[Reactie gewijzigd door GekkePrutser op 27 juli 2024 07:19]

Hm irritant want dat is best duur.
(...)
Ik hoop dat de andere providers niet gaan volgen.

Hier bij mijn Spaanse provider (reseller van Orange) kan ik nog niet eens IPv6 krijgen...
Des te meer mensen klagen over dat ze nog geen IPv6 hebben, des te meer reden om IPv6 toch eindelijk eens te implementeren. ;)

Je kan mogelijk ook IPv6-toegang via een VPN provider krijgen als workaround. Dan betaal je een vast laag bedrag per maand.

[Reactie gewijzigd door The Zep Man op 27 juli 2024 07:19]

Nouja ik wil ook eigenlijk mijn VPS'en niet op IPv6 hebben. Ik heb niet altijd controle over de netwerken waar ik op zit, immers. En als je een keer op een netwerk zit dat het niet heeft, dan heb je een probleem. IPv4 blijft de grootste gemene deler, behalve in Azie maar daar heb ik niks mee te maken. En een IPv4 adres kan je ook uit je hoofd intypen, dat is met een IPv6 veel lastiger.

Maar ik zie dat ik inmiddels al 0,004 cent per uur betaal voor het IP, de VPS zelf is maar 0,00015 :') Dus ik betaal 10 cent per maand voor de VPS en bijna 3 euro voor het IP :') Het is dan ook een promotionele aanbieding en je mag er maar 2 per persoon hebben - precies genoeg voor mij voor redundantie.
Teredo werkt altijd. Ik had persoonlijk een tijdje de situatie dat ik Tweakers niet over ipv4 kon bereiken en aanvankelijk had ik totaal niet door waarom. Dus als ik op vakantie met mijn laptop was, dan alleen v4 en dan was het iedere keer:

"systemctl start miredo"

... en hop, Tweakers werkt. Zoals vaak was uiteindelijk mijn eigen domme schuld dat ik ooit een keer het ip-adres van Tweakers aan /etc/hosts had toegevoegd tijdens een DNS-probleem en als dat een ipv6 adres is, dan werkt v4 natuurlijk niet meer.

Teredo is niet erg ideaal als permanente oplossing, maar ik vind het persoonlijk zeer nuttig om even te configureren op m'n apparaten en zo snel ipv6-toegang te hebben als je in een situatie zit waar je alleen een v4-adres hebt.

Het werkt overigens ook ideaal tegen Piratebay-blokkades e.d.
Nouja ik wil ook eigenlijk mijn VPS'en niet op IPv6 hebben. Ik heb niet altijd controle over de netwerken waar ik op zit, immers. En als je een keer op een netwerk zit dat het niet heeft, dan heb je een probleem.
Je gebruikt uiteraard standaard een VPN naar een endpoint dat ook IPv4 ondersteunt, en via die VPN maak je dan je IPv6 verbindingen. Zo heb je maar één endpoint waar je IPv4 voor nodig hebt. Of als het goedkoper is: neem een VPN-dienst af die ook IPv6-toegang levert.
Ja maar daar gebruik ik die VPS'en juist voor: Als VPN endpoint.
Ja maar daar gebruik ik die VPS'en juist voor: Als VPN endpoint.
Je kan dan één VPS gebruiken als IPv4 endpoint en via die de andere systemen benaderen. Of je gebruikt een (UDP) VPN door een (UDP) VPN van een third-party provider.
Ja dat is precies wat ik doe. Maar geen third-party VPN's, dat wil ik niet. Mijn twee VPS'en zijn de centrale punten van mijn peer to peer VPN.

Maar op het interne netwerk heb ik sowieso niks aan IPv6 want ik heb daar maar een paar tientallen endpoints :)

[Reactie gewijzigd door GekkePrutser op 27 juli 2024 07:19]

En daarom hebben we dus dns. Dan hoef je alleen maar gekkeprutser.nl te onthouden ipv een draak van een ipv6 adres
Ja maar DNS werkt niet altijd.. Vandaar dat het handig is om een paar IP adressen te weten.
Maar wanneer zou DNS niet werken als je het publieke adres wilt weten? Want dat betekend dat je over het internet aan het verbinden bent naar een internet bereikbaar adres?
Nou, gewoon als je problemen hebt en aan het troubleshooten bent, dan is het handig om het IP uit je hoofd te weten. Om te zien of het een DNS probleem is of wat anders.

Ik doe veel met adblocking DNS dus dat komt wel eens voor dat daar wat mee fout gaat.

[Reactie gewijzigd door GekkePrutser op 27 juli 2024 07:19]

Dan zit je helaas met diensten als Netflix die deze ranges expliciet blokkeren. Erg vervelend. Dat gebeurd ook al als je gebruik maakt van bijv. Tunnel Broker van HE.

Ik heb laatst geprobeerd het via een VPS te routeren, maar dit werkt niet goed qua locatie, geoip geeft dan aan dat ik uit Duitsland of Rusland kom, waardoor je met streaming diensten alsnog weer in de knel komt. Heb hier nog niet echt een goed werkend alternatief voor gevonden, zonder gebruik te maken van split DNS achtige oplossingen.
Dan zit je helaas met diensten als Netflix die deze ranges expliciet blokkeren.
In de context van het bereiken van AWS waarop jouw diensten draaien. Niet in de context van al je internetverkeer erdoorheen routeren.

[Reactie gewijzigd door The Zep Man op 27 juli 2024 07:19]

Misschien kan je zelf de op adressen van Netflix laten routeren via je normale provider ipv je vpn provider?
Wanneer iets schaars is, wanneer we het niet kunnen bijmaken en wanneer de vraag toeneemt, dan stijgt automatisch de prijs van dat goed om vraag en aanbod te kunnen balanceren.
Mooi moment om iedereen erop te wijzen dat je -waarschijnlijk- al IPv6 compatible bent. Je router krijgt wellicht al een IPv6 en je clients in je netwerk wellicht ook al.

https://test-ipv6.com/

Als dit niet werkt: aan de slag. Uitzoeken hoe je het werkende krijgt en regel het! Zat informatie op het forum, in de ISP gebruikersfora of op YouTube te vinden hoe je dit regelt.

Hoe sneller we naar IPv6 over zijn, hoe beter. Want steeds meer betalen voor IP nummers, zullen we daarmee stoppen?
Het is een illusie dat we niet óók gaan betalen voor IPv6 gebruik (IoT?). We horen nu al 20 jaar dat de IPv4 adressen op raken, maar dat is ook gewoon een gedeelde waarheid. Je kunt prima gebruik maken van beide systemen, met beide een ander doel. Zie ook mijn reactie over gebruikersgemak.

Edit: Verder betaalde je vroeger ook gewoon voor een IP4 een X bedrag. Niks nieuws dus eigenlijk.

[Reactie gewijzigd door m4ikel op 27 juli 2024 07:19]

Het is een illusie dat we niet óók gaan betalen voor IPv6 gebruik (IoT?).
Onzin. IPv6 kan letterlijk niet op raken. 2^128 adressen betekent dat iedere vierkante meter op aarde miljoenen miljarden IP-nummers gealloceerd zou kunnen krijgen.
We horen nu al 20 jaar dat de IPv4 adressen op raken, maar dat is ook gewoon een gedeelde waarheid. Je kunt prima gebruik maken van beide systemen, met beide een ander doel.
Nee. De IPv4-nummers zijn letterlijk al 12 jaar geleden allemaal uitgegeven: https://en.wikipedia.org/wiki/IPv4_address_exhaustion. Als je nu een blok IP nummers wil kopen, koop je die van anderen op en betaal je de hoofdprijs. 40 a 50 euro per IP nummer is doodnormaal geworden. Zie (bijvoorbeeld) https://auctions.ipv4.global/. Ter contrast: Het residential subnet in IPv6 is /64. Dat komt neer op 2^64 of 18.446.744.073.709.551.616 adressen puur voor jouw thuis. Helemaal gratis.
Zie ook mijn reactie over gebruikersgemak.
Dat zal een belangrijke reden zijn voor de slechte adoptie ja en ook de reden waarom ik het jaren vooruit schoof. Maar uiteindelijk is dat heel gemakkelijk oplosbaar met zaken als mDNS en 30 minuten nemen om te leren hoe IPv6 werkt. (spoiler: zo moeilijk is het allemaal niet)
Edit: Verder betaalde je vroeger ook gewoon voor een IP4 een X bedrag. Niks nieuws dus eigenlijk.
25 jaar geleden kon je ze nog nagenoeg gratis aanvragen bij bijvoorbeeld RIPE. 10 jaar geleden waren ze gemiddel 10 euro per stuk. Vandaag gaat het richting de 50.

[Reactie gewijzigd door mOrPhie op 27 juli 2024 07:19]

Ter contrast: Het residential subnet in IPv6 is /64. Dat komt neer op 2^64 of 18.446.744.073.709.551.616 adressen puur voor jouw thuis. Helemaal gratis.
Zoveel apparaten in een enkel subnet. Yay... :/

Veel technieken werken niet op IPv6-netwerken kleiner dan /64, waardoor dat niet wordt aanbevolen. Een beetje internetverbinding heeft een /56, /52 of zelfs een /48 adresbereik. Al wil je NAT en mogelijk overlappende private ranges vermijden met bijvoorbeeld P2P verbindingen, dan gaat het al hard. Ja, er is nog zat, maar het is echt niet alsof er daadwerkelijk 128 bit aan adresruimte beschikbaar is.

[Reactie gewijzigd door The Zep Man op 27 juli 2024 07:19]

De is kans is vooralsnog vrij klein dat IPv6-adressen duur gaan worden, omdat bedrijven zelf lid van RIPE kunnen worden en adresruimte toegewezen krijgen. Concurrentie zal de rest doen en zorgen dat de prijs van een v6-adres erg laag zal blijven.

Bij v4 was dat traditioneel ook het geval, alleen door schaarste konden op een bepaald moment alleen nog ISP's adressen krijgen en momenteel is zelfs dat niet meer mogelijk. Alleen nieuwe internetaanbieders kunnen op het moment nog kleine hoeveelheden V4-adressen krijgen en daar is dan al weer een wachtlijst voor.
Het is een illusie dat we niet óók gaan betalen voor IPv6 gebruik (IoT?). We horen nu al 20 jaar dat de IPv4 adressen op raken, maar dat is ook gewoon een gedeelde waarheid. Je kunt prima gebruik maken van beide systemen, met beide een ander doel. Zie ook mijn reactie over gebruikersgemak.

Edit: Verder betaalde je vroeger ook gewoon voor een IP4 een X bedrag. Niks nieuws dus eigenlijk.
We moeten even drie dingen uit elkaar houden.

Het één is de prijs die betaalt als je zelf een IP adres wil hebben volgens de officiele weg. RIPE heeft die adressen altijd gratis uitgegeven, zowel IPv4 als IPv6. Die hebben ook niet het doel om er geld aan te verdienen. Iemand moet bijhouden wie welk stukje adresruimte heeft, meer niet. IPv4 adressen kun je niet meer krijgen bij RIPE, die zijn op.

Het tweede is de prijs die je betaalt als je op de vrije markt IP-adressen wil overkopen. In die markt betaal je tientallen euro's per adres en het wordt steeds meer want de voorraad is beperkt en vrijwel niemand wil ze verkopen. (Ik maak me wel eens zorgen wat onze directie zou doen als ze horen hoeveel onze IP-adressen tegenwoordig waard zijn).

Het derde is de prijs die je aan Amazon betaalt om een van hun IP-adressen te mogen gebruiken. Daar kan Amazon voor vragen wat ze willen. Je betaalt niet alleen voor het IP-adres zelf maar ook voor de service die er bij hoort. Amazon heeft die adressen in de loop der jaren verkregen via allerlei routes. Een deel zullen ze gratis hebben gekregen, een deel gekocht. Maar nu het eenmaal hun eigendom is hebben ze er geen kosten meer aan en kunnen ze verhuren voor zoveel of weinig als ze willen.
AWS noemt specifiek Elastic Compute Cloud (EC2), Relational Database Service en Elastic Kubernetes Service-nodes als die in Virtual Private Cloud, Global Accelerator of de vpn-tunnel zijn gekoppeld
Die noemen ze, maar er staat ook duidelijk
This change applies to all AWS services including Amazon Elastic Compute Cloud (Amazon EC2), Amazon Relational Database Service (RDS) database instances, Amazon Elastic Kubernetes Service (EKS) nodes, and other AWS services that can have a public IPv4 address allocated and attached, in all AWS regions (commercial, AWS China, and GovCloud).
Ook je loadbalancers, API GW, Transfer Family en andere zaken die komen met een IPv4-adres krijgen dus deze kosten.
Corey Quinn legt het netjes uit:

In a rare price hike, AWS will be charging for IPv4 addresses. The change brings them in line with other cloud providers and encourages good internet hygiene.
https://www.lastweekinaws...or-Public-IPv4-Addresses/

Hoewel Corey altijd heel kritisch is op kosten (hij adviseert zijn klanten hoe ze het beste hun cloud rekeningen kunnen verlagen), is ook hij positief over deze keuze.
Wat is de drempel om over te stappen naar een IPV6 adres als er een nieuw adres wordt geregistreerd?
Iets duurder dan Azure rekent. Zij rekenen $0,004/uur voor een dynamisch adres, $0,0036 voor een statisch adres (in US en West Europe althans).

Kost je de kop niet, maar hopelijk toch een drempeltje om de stap naar IPv6 iets aantrekkelijker te maken.
Ik heb een paar honderd servers die IPv6 only zijn. Inbound IPv4 verkeer doe ik via reverse proxy en outbound via NAT64/DNS64.

Op dit item kan niet meer gereageerd worden.