Amerikaanse registry-organisatie kan niet meer aan ipv4-vraag voldoen

De Amerikaanse organisatie die ip-adressen uitdeelt aan isp's en hosters heeft de uitgifte van ipv4-adressen op rantsoen gezet en een IPv4 Unmet Requests-beleid ingevoerd. De dienst kan niet meer aan grote vraag voldoen en moet uit een kleine reserve putten.

ARIN voerde het IPv4 Unmet Requests-beleid in na goedkeuring van een aanvraag voor ipv4-adressen die groter was dan de beschikbare voorraad. Er is nog wel een kleine voorraad adressen, maar die wordt alleen gebruikt voor aanvragen voor kleinere blokken. De ARIN houdt een lijst bij over het opraken van de adressen.

Wie in de VS en Canada toch nog ipv4-adressen nodig heeft kan beperkt putten uit die kleine voorraad, maar wie grote hoeveelheden wil zal deze moeten aanschaffen op de vrije markt. ARIN herinnert organisaties verder aan de overvloedige beschikbaarheid van de ipv6-adresruimte.

De laatste stap in de Amerikaanse uitgifte volgt op die van de Europese evenknie, Ripe NCC, in 2012. Er gaan al decennia berichten over het opraken van de ipv4-adressen. Pas recent beginnen de meeste bedrijven met de overstap naar ipv6. Overigens hebben veel providers en hosters een eigen voorraad ipv4-adressen, maar zodra die op zijn, kunnen ze geen nieuwe meer krijgen. De Afrikaanse registry-organisatie heeft wel nog ipv4-blokken te vergeven.

Reacties (221)

[zonoskar]

Het lijkt een beetje op het olie-voorraad probleem. We blijven doorconsumeren terwijl aan alle kanten de alarmbellen afgaan. Maar er tijdig iets aan doen, ho maar. Het is jammer dat er altijd ergens tegen een muur aan gelopen moet worden, voordat er iets substantieels gebeurd (bijv. veiligheid).

[eerdepeer]

uhm, het alternatief is toch gewoon ipv6, dus we hebben toch gewoon een alternatief?

[zalazar]

Een alternatief is het wel maar dan wel een heel slecht en ondoordacht alternatief.
Als je IPv6 backwards compatible had gemaakt met IPv4 en geimplementeerd had op een manier waarbij er maar 1 TCP/IP stack is die in een soort dual mode werkt dan had een overgang eenvoudiger geweest en zou de acceptatie ook veel sneller hebben plaatsgevonden.

[Verwijderd]

Helemaal mee eens.

Echter, de wijzneuzen die vooraan stonden bij IPv6 in de vroege jaren negentig waren helemaal gekant tegen backwards-compatability. In hun ogen zou dat er voor zorgen dat mensen nog jaren lang IPv4 en IPv6 in combinatie zouden gebruiken. En dat wilden ze niet hebben. Ze wilden iedereen dwingen om zo snel mogelijk op IPv6 over te stappen, door het juist express niet compatible te maken. Backfired.

Wat ook geholpen zou hebben, is als IPv6 voordelen had gehad over IPv4. Dat heeft het niet. Het is (bijna) precies hetzelfde protocol, alleen met meer bits voor de adressen. Een gemiste kans.

IPv6 had meer problemen kunnen opgelossen, zeker op layer-3 niveau (networking). Zoals host-multihoming, as-multihoming, locator-identifier separation, on-the-fly renumbering, betere automatic prefix-summarization, mobile, noem maar op. Als dat het geval was geweest, dan hadden endusers en ISPs staan springen om IPv6 in te voeren.

[Reactie gewijzigd door Verwijderd op 26 juli 2024 07:31]

[Blokker_1999]

Er zijn imho wel degelijk voordelen verbonden aan IPv6 die je niet had bij IPv4 zoals de eenvoudigere routering of de eenvoudigere configuratie. Ook hebben we geen nood meer aan NAT, indien gewenst kan elk systeem direct vanaf het internet benaderd worden.

Je mag ook niet vergeten dat IPv6 ondertussen ook al weer 20 jaar oud is. Ergens is het een schande dat we nog niet verder staan met de uitrol.

[Verwijderd]

"eenvoudigere configuratie". O ja? En NAT is de grootste netwerkzegen gebleken als het om beveiliging gaat. Iedere gebruiker MOET het wel toepassen omdat het anders niet functioneert, en je krijgt er een wagonlading beveiliging gratis bij.

Zal academisch wel niet kloppen of zo, maar security uit noodzaak is de beste security.

[e_balk]

NAT een zegen?
Jij hebt niet meegemaakt hoe het was toen NAT geintroduceerd werdt als pleister voor het probleem dat de uitgifte van IPv4 adresblokken langzaam aan banden gelegd werden.

Om NAT goed te laten werken is er veel aanpaswerk nodig geweest op netwerklagen die eigenlijk helemaal niet met dat soort zaken bezig horen te zijn. Zaken als NAT hebben netwerken alleen maar extra complex gemaakt.

Dat NAT toevallig een beschermende factor met zich meeneemt is toeval, maar het is er niet voor bedoeld. Je netwerk goed beschermen doe je met een firewalls niet met NAT. Als NAT uitgefaseerd wordt dan kan de snelheid van netwerken omhoog en kunnen de connectie apparaten simpeler en efficiënter gemaakt worden. De Router die bij jou in de kast staat is drukker met het bijhouden van de NAT translatietabel dan dat hij druk is met het routeren van internetverkeer.

[Verwijderd]

"De Router die bij jou in de kast staat is drukker met het bijhouden van de NAT translatietabel dan dat hij druk is met het routeren van internetverkeer.". En dat is een probleem omdat?

[Verwijderd]

...een router 24/7 draait en als de CPU zwaarder belast wordt hij dus meer stroom zal gebruiken!

[Verwijderd]

Al die NAT requests ook midden in de nacht.... Net als die router in slaapstand staat en zijn ledjes uitdoet. O sjips, dat doet ie niet. En dan het FON wireless netwerk....

Ik hoef dit argument toch niet serieus te nemen, toch?

[THA_ErAsEr]

Energie verspilling bijvoorbeeld?

[necessaryevil]

Energie en vooral performance.

[CAPSLOCK2000]

Omdat het simpeler en (dus) goedkoper had gekund.
Uiteindelijk betalen wij er voor.

[e_balk]

Omdat dat weinig effectief is, extra taken uitvoeren kost ook extra energie, in een wereld waarin we groen (moeten gaan) denken is dit eigenlijk tegennatuurlijk, ook zou je verbinding een stuk sneller kunnen zijn zonder extra conversie/vertaal slagen.

[Verwijderd]

Ik zeg het nog maar een keer, omdat het nooit tussen de oren komt:
1) ik zeg NIET dat NAT de beste oplossing is uit TECHNISCH oogpunt
2) ik zeg NIET dat ipv6, mits goed geïmplementeerd, onveilig is
3) ik zeg NIET dat NAT problemen kent.

Ik zeg alleen dat NAT uit ORGANISATORISCH oogpunt een zegen is, omdat het wel gebruikt MOET worden omdat anders e.e.a. niet functioneert met het tekort aan adressen. Het is geen OPTIE, het is NOODZAAK.

Ik ben het geflame (wat ik natuurlijk verwachtte), dat ik er niets van snap wel heel erg zat aan het worden. Geflame (deels, ik zeg niet dat jij dat bent) door onder andere dezelfde figuren die alles op SSL wilde hebben, maar vergaten dat de implementatie zelf lek was.

En DAT is nu het grote voordeel van NAT: het moet goed zijn anders werkt het netwerk niet. Geen excuus om beveiliging op de lange baan te schuiven.

Dan nog ff over je argumentatie, daarvoor geldt:
- qua energie. Quick win: haal alle ledjes van de router. De energiebesparing als er geen nat wordt gebruikt maar een 'echte' firewall is marginaal. Als dit het argument is...
- qua stuk sneller: hardware ondersteunde NAT heeft nauwelijks vertraging, zeker niet ten opzichte van al die hops die er tussen zitten.

Pfff

[e_balk]

Ik zeg het nog maar een keer, omdat het nooit tussen de oren komt:
1) ik zeg NIET dat NAT de beste oplossing is uit TECHNISCH oogpunt
2) ik zeg NIET dat ipv6, mits goed geïmplementeerd, onveilig is
3) ik zeg NIET dat NAT problemen kent.

Ik zeg alleen dat NAT uit ORGANISATORISCH oogpunt een zegen is, omdat het wel gebruikt MOET worden omdat anders e.e.a. niet functioneert met het tekort aan adressen. Het is geen OPTIE, het is NOODZAAK.

Dus NAT is geen zegen, maar een noodzakelijk kwaad, dan waren we het al eens.

Ik ben het geflame (wat ik natuurlijk verwachtte), dat ik er niets van snap wel heel erg zat aan het worden. Geflame (deels, ik zeg niet dat jij dat bent) door onder andere dezelfde figuren die alles op SSL wilde hebben, maar vergaten dat de implementatie zelf lek was.

En DAT is nu het grote voordeel van NAT: het moet goed zijn anders werkt het netwerk niet. Geen excuus om beveiliging op de lange baan te schuiven.

Nergens hoor je mij zeggen SSL te gebruiken, ik heb het over NAT.

Dan nog ff over je argumentatie, daarvoor geldt:
- qua energie. Quick win: haal alle ledjes van de router. De energiebesparing als er geen nat wordt gebruikt maar een 'echte' firewall is marginaal. Als dit het argument is...
- qua stuk sneller: hardware ondersteunde NAT heeft nauwelijks vertraging, zeker niet ten opzichte van al die hops die er tussen zitten.

Er is helemaal niets mis met mijn argumenten, het heeft te maken met schaal en met efficientie, ledjes zijn ook niet efficient voor een router, daarom zijn er routers waarbij ze uitgezet kunnen worden als je ze niet nodig hebt.

Het argument dat een "echte" firewall energie zou besparen ten opzichte van NAT heb ik niet gemaakt en dat is ook geenszins waar, maar een echte firewall is ook niet geimplementeerd in Consumenten routers. Die zouden namelijk veel meer energie nodig hebben dan NAT verbruikt en ook je verbinding aanzienlijk vertragen.

NAT is een oplossing voor een probleem dat niet zou moeten bestaan, noodzakelijk nu, maar niet een efficiente oplossing of nodig als er beter nagedacht was in eerste instantie. NAT vormt een extra belasting op je apparatuur hoe klein deze ook is, net zoals een firewall dat doet. hij is niet meer nodig met IPv6 en daarmee is IPv6 dus efficienter voor je apparatuur (misschien niet merkbaar op jouw eigen netwerk, maar denk eens op wereldschaal).

Stel dat iedere router een miniscuul beetje energie gebruikt om NAT uit te voeren zeg: 0,001 watt (Dit is helemaal fictief en ik heb geen idee wat het verbruik van NAT zou kunnen zijn gemiddeld, maar 0,001 watt lijkt me zo weinig dat het niet realistisch is, het gaat even om het idee.

Als we daar vanuit gaan, gaan we ook fictief uit van het feit dat ieder IP adres in de 32bits adresruimte toegekend is aan een IP adres, dit is wat overdreven want dat is niet mogelijk door broadcast en privé netwerkadressen ik weet het, maar gun me dit als compensatie voor het bizar lage verbruik van NAT. Dan zouden we de beschikking hebben over ongeveer 4.200.000.000 adressen volgens deze berekening zou je wereldwijd 4,2 MWatt besparen als je NAT zou kunnen uitschakelen. En volgens mij is dat toch weer een leuk begin aan het verminderen van de CO2 uitstoot wereldwijd. We kunnen wel alleen maar groot denken, maar vele kleintjes maken ook een grote.

Voor vertraging zou je dezelfde tactiek kunnen gebruiken, stel dat ieder pakketje met 0,001 milliseconde vertraagd wordt, dan loopt dit ook in de miljoenen seconden die dagelijks verspilt worden aan NAT.

Als je zo smal kijkt als alleen je eigen netwerk, dan kloppen je argumenten, maar het gaat om het idee dat het verspilde tijd en energie is en ook al zijn het in jouw netwerk hele kleine beetjes, in alle netwerken samen maken al die kleine beetjes toch weer een verschil, waarom zouden we vasthouden aan iets dat verouderd en inefficient is als er verbeteringen beschikbaar zijn? Ik zit die energie in ieder geval liever in voor iets anders.

[nullbyte]

Het maakt het wel wat overzichtelijker. Ik gebruik liever private IPv4 of v6 IPadressen in mn netwerk dan een ellenlange publieke IPv6 range die ik eventueel van mn ISP zou krijgen.

[Accretion]

Ja privé is het wel logisch... Enigszins (zijn natuurlijk ook oplossingen voor).
Voor extern zijn er toch dns namen?

[Alfa1970]

Volgens mij is het sprookje dat NAT "bescherming" biedt een van de grootste misconcepties in de IT.

[Verwijderd]

Mijn IP adres is 192.168.1.10, log jij even in?

NAT is niet bedoeld als beveiliginsmaatregel, maar het zorgt er wel voor dat miljoenen slecht beveiligde Windows-PC's niet bereikt kunnen worden vanaf het Internet.

[JAVE]

NAT is leuk als je op geen enkele manier inkomende verbindingen nodig hebt.
Anders moet je portforwarding gaan instellen, maar dat is weer zoveel werk (net als een Firewall instellen), dus daardoor heb je uPnP gekregen.

En laat uPnP nu net weer een enorme hoeveelheid beveiligingsproblemen geven, want dit gebeurt lekker achter de schermen, zodat de onbenullige gebruiker er niet mee wordt lastiggevallen.

En die gebruiker maar denken dat hij veilig is met z'n NAT...

Nee, kom aub niet met NAT als reden dat IPv4 zo handig is.

[Verwijderd]

Ik heb expres uPnP niet genoemd, omdat dat inderdaad weer een gatenkaas ervan maakt.

En ik noem zeker NAT niet als reden om IPv4 te houden. Ik voorspel wel dat er nog een hele hoop problemen gaan komen met IPv6-connected end devices als die plotseling de "bescherming" van NAT kwijt zijn...

[JAVE]

Ik denk dat er meer problemen komen met devices die geen IPv6 ondersteunen (netwerk printers, IP cams, audio systemen, etc).

Maar ik denk dat het beter is dat mensen weten dat ze geen bescherming hebben, dan dat ze denken dat ze wel bescherming hebben (door een NAT).

[Verwijderd]

ik voorzie daar bijna geen problemen. Wie hangt er nu zijn printer, webcams, audio speakers rechtstreeks aan het internet?

Als je router ipv6 voorbereidt is, wat ze bijna allemaal zijn, kan je intern gewoon op ipv4 verder blijven werken zoals je het nu al doet.

[nullbyte]

Hoezo niet? Inkomende verbindingen doe je met een VPN. De VPN poort naar de VPN server is dan ook de enige die open gezet en geforward hoeft te worden. De portforwarding is naar het andere netwerk te komen en op de firewall moet de poort open gezet worden. De gebruiker kan ook best denken dattie veilig is met z'n NAT, dat issie ook want er zit meestal een firewall in de router.

[Reactie gewijzigd door nullbyte op 26 juli 2024 07:31]

[Verwijderd]

Dat gaat dan met ip6 zeker een stuk sneller, toch? Of zijn netwerken heel misschien inherent ingewikkeld.

[Inny]

@jeroenr

Dat is geen sterk argument voor 'de beveiliging die NAT biedt.' Als NAT niet nodig was geweest, had dat ingehouden dat er een grotere noodzaak was geweest om de beveiliging van dergelijke PC's op orde te brengen. En het dus waarschijnlijk zou zijn, dat dit beter zou zijn opgepakt.

[Reactie gewijzigd door Inny op 26 juli 2024 07:31]

[Verwijderd]

Ja, duh, achteraf was het betwer geweest als we geen NAT hadden gehad. Natuurlijk. Maar NAT is een feit. En NAT is geen beveiliging, maar desalniettemin hangen er miljoenen Windows-PC's niet "open" aan het Internet dankzij NAT. Het is geen doel, het is geen reden om NAT te willen, maar voor veel thuis-PC's is het wel een toevallig voordeel.

[nullbyte]

De meeste consumenten routers hebben een firewall, daarom zijn de interne netwerken beschermd, niet vanwege de NAT.

[Reactie gewijzigd door nullbyte op 26 juli 2024 07:31]

[Verwijderd]

en macs en linuxen en androids en iphones en windows fones. Of zijn al die mccen en linuxboxen altijd veilig? De would-be Linux systeembeheerders in de thuisomgeving weten natuurlijk precies wat ze doen...

[CAPSLOCK2000]

Maar een eenvoudige firewall bereikt precies hetzelfde op een eenvoudigere en overzichtelijkere manier. Veel mensen lijken te denken dat je zonder NAT geen beveiliging zou hebben gehad maar dat is dus een misverstand.

[nullbyte]

De meeste consumenten routers zijn 3 in 1. Firewall, router en modem. Daar komt die illusie waarschijnlijk vandaan.

[e_balk]

Dit is niet helemaal waar, meestal zijn consumenten routers een combinatie van een Router en een Switch, er wordt wel eens geschermd met een Firewall, maar dat komt over het algemeen niet verder als een deels functionele firewall voor de meest basale aanvallen van buitenaf.

Alleen de Routers met een ingebouwde DSL aansluiting zijn ook nog een modem, maar veelal heb je alleen een WAN poort, daar vind geen Modulatie en Demodulatie op plaats (dus geen Modem functionaliteit)

[nullbyte]

Ik vergat de swich functie idd. Met een beetje googlen zie ik dat consumenten routers die door de ISP verstrekt worden zoals de fritzbox 7360, 7390, speedtouch 780 enz, wel degelijk een firewall hebben. Zou die er niet zijn dan is NAT de enige "bescherming" die er voor het netwerk is. Natuurlijk hebben deze firewalls niet dezelfde functionaliteiten als de professionele firewalls van bv Cisco.

[e_balk]

... Natuurlijk hebben deze firewalls niet dezelfde functionaliteiten als de professionele firewalls van bv Cisco.

Zelfs niet vergelijkbaar met de functionaliteiten van de in Windows ingebouwde firewall. Meestal zijn er SPI firewalls ingebouwd in die routers, Statefull Package Inspection. Wat erop neerkomt dat verbindingen nog steeds gemaakt kunnen worden wanneer er een actieve verbinding gesimuleerd kan worden.

https://en.wikipedia.org/wiki/Stateful_firewall

[e_balk]

De firewall in consumenten routers is zo ontzettend basaal en beperkt dat je niet kunt stellen dat ze echte bescherming bieden.

NAT beschermt wel in zichzelf doordat de aangesloten devices niet direct benaderbaar zijn van buitenaf (geen routeerbare IP's die worden gebruikt)

Maar NAT is niet gebouwd voor bescherming, het doet dus verder niets dan hetgeen het van nature doet, namelijk niet routeerbare pakketten vertalen naar routeerbare pakketten, NAT zal dus als tussenstation fungeren voor iedere individueel pakketje dat naar internet gestuurd wordt door lokale IP adressen en zal vervolgens de antwoorden bijhouden en weer omzetten naar een intern netwerkpakketje, verre van efficient, maar noodzakelijk door een gebrek aan publieke IP adressen

[CAPSLOCK2000]

De firewall in consumenten routers is zo ontzettend basaal en beperkt dat je niet kunt stellen dat ze echte bescherming bieden.

NAT beschermt wel in zichzelf doordat de aangesloten devices niet direct benaderbaar zijn van buitenaf (geen routeerbare IP's die worden gebruikt)

De meeste consumentenrouters draaien tegenwoordig op Linux en daar is NAT een onderdeel van de firewall. De standaard Linux-firewall is dus gewoon beschikbaar. Als je alle nieuwe inkomende verbindingen weigert heb je minstens zo veel veiligheid als bij een NAT-box.

[e_balk]

Welke consumentenrouters draaien dan volledig op Linux?

Ik vermoed dat de routers waar jij het over hebt toch echt in het hogere segment zitten en dit zijn niet de routers die de meeste mensen aanschaffen, tweakers kennen de waarde, maar de gemiddelde consument niet, die wil alleen dat internet overal op werkt.

Ik zie nog regelmatig routers staan bij mensen die meer dan 10 jaar al hun werk doen.....

[CAPSLOCK2000]

Betere vraag is welke niet. Zo'n beetje alle "normale" consumentenrouters gebruiken het. BV de nieuwere modellen van D-link (oa Boxee), Netgear (oa SabaiOS en NGOS), Asus (SabaiOS), TP-Link, Linksys en AVM (FritzBox).

[e_balk]

Sorry mijn vraag was duidelijk niet duidelijk genoeg want je argument is nog steeds niet voldoende onderbouwt.

Welke van deze routers hebben aantoonbaar een Linux firmware, waarbij de gebruiker via de standaard (web) interface de mogelijkheid heeft om iptables te configureren?

Iedere firewall heeft een behoorlijke hoeveelheid rekenkracht nodig om een niet al te grote bottleneck te vormen voor het netwerkverkeer, met verbindingen van 100, 120, 500 en 1000mbps heb je een behoorlijke hoeveelheid processorkracht nodig om deze snelheden te blijven halen, sterker nog dan kom je in de Enterprise grade firewalls die dit nog kunnen volhouden, deze hardware zit echt niet in consumer grade routers ingebakken tegen een fractie van de prijs.

De instapmodellen van enkele tientjes (veelal geleverd door ISP's of zelf gekocht) kunnen dit soort zaken dus absoluut niet aan en zullen deze functionaliteit dus ook nooit bieden. De duurdere modellen hebben misschien een deel van deze functionaliteit, maar dat zijn modellen van meer dan 100 a 150 euro, en deze kopen gemiddelde consumenten niet.

Ik vind dan ook dat je reageert op zo'n wijze dat de informatie misleidend kan zijn, de kern van de boodschap blijft hetzelfde, consumentenrouters zijn niet in staat om een legitieme laag van beveiliging te bieden die noodzakelijk is voor een echt veilig netwerk. Zeker niet wanneer IPv6 gebruikt wordt. NAT is daarbij een welkome toevallige laag van bescherming (op IPv4), maar echt beveiligd ben je niet, je vertrouwd er met dit soort apparatuur op dat je geen slachtoffer wordt van gerichte inbraakpogingen, want als die uitgevoerd worden.

[CAPSLOCK2000]

Welke van deze routers hebben aantoonbaar een Linux firmware, waarbij de gebruiker via de standaard (web) interface de mogelijkheid heeft om iptables te configureren?

Geen idee, maar de kernelcode is aanwezig. Ik probeer niet te zeggen dat de huidige generatie routers het in praktijk kan. Bij die dingen kun je NAT niet eens uitschakelen via de GUI dus die zijn toch niet geschikt om zonder NAT te draaien.
Maar de hardware en het OS kunnen het wel. Als een fabrikant zo'n ding zonder NAT maar met firewall wil leveren kan dat.

De fabrikant zou het ding zo moeten configureren dat het out-of-the-box inkomende verbindingen weigert. Als ze NAT kunnen configureren dan is zo'n firewall helemaal geen probleem. Eindgebruikers hoeven er nu ook niet voor te kiezen om NAT aan te zeten, dat is de standaard instelling.

Sterker nog. Ik denk dat veel van die routers nu ook al met een firewall worden geleverd die precies doet wat ik wil, inkomende verbindingen weigeren. Zo'n beetje iedere handleiding NAT-onder-Linux begint daar namelijk mee.

Een firewall is eenvoudiger dan NAT. Zowel voor de programmeur, voor hardware als voor de eindgebruiker.

Iedere firewall heeft een behoorlijke hoeveelheid rekenkracht nodig om een niet al te grote bottleneck te vormen voor het netwerkverkeer, met verbindingen van 100, 120, 500 en 1000mbps heb je een behoorlijke hoeveelheid processorkracht nodig om deze snelheden te blijven halen, sterker nog dan kom je in de Enterprise grade firewalls die dit nog kunnen volhouden, deze hardware zit echt niet in consumer grade routers ingebakken tegen een fractie van de prijs.

NAT is een onderdeel van de Linux-firewall code. Voor je bij de NAT-code komt heb je de helft van de firewall al gehad. Als je router snel genoeg is om die hele 1000Mbs te kunnen NATten dan is de hardware zeker snel genoeg voor een eenvoudige firewall. Je kan firewall heel uitgebreid en langzaam maken maar dat is niet van toepassing op een consumentensituatie. Als je het kan NAT'ten dan kun je de equivalente firewall-operatie zeker aan.

consumentenrouters zijn niet in staat om een legitieme laag van beveiliging te bieden die noodzakelijk is voor een echt veilig netwerk.

Dat ben ik met je eens. Maar ik ben het niet met je eens dat NAT veiliger is dan een firewall. Zeker niet als je het over gerichte aanvallen hebt.

[e_balk]

Ik beweer gelukkig ook nergens dat NAT veiliger is dan een Firewall Het tegenovergestelde zelfs een Firewall is namelijk gemaakt met de intentie te beveiligen.

Een firewall die alle poorten standaard dichtzet zal niet werken, omdat er dan geen antwoord meer komt op de door je computer uitgezonden pakketjes, de firewall moet dus poorten openzetten op basis van bepaalde regels, SPI doet dat aan de hand van hele simpele regels, namelijk is er een connectie vanuit mijn netwerk naar deze client gegaan en antwoord hij op de door mij verwachte poort? Ja laat door, nee drop, maar SPI is in mijn ogen eigenlijk geen echte firewall functie, maar een NAT functie, het is namelijk het blokkeren van verkeer dat niet geinitieerd is door een lokale netwerk client, niet meer en niet minder en precies dat wat NAT andersom doet, eigenlijk is SPI dus een benaming voor de "beschermende" functie die NAT van nature bied.

Een "echte" firewall inspecteert IP pakketjes op inhoud en als een pakketje aan gestelde voorwaarden voldoet dan mag het pakketje passeren en het pakketje wordt gedropped als dit niet het geval is, deze firewall functionaliteit is vrijwel niet beschikbaar in consumentenrouters en daar is de hardware ook verre van krachtig genoeg voor. SPI is geen enkel probleem omdat dit eigenlijk gewoon standaard al gebeurt met NAT (of strikt genomen met PAT), dat is dus ook de situatie die ontstaan is, NAT is in de Linux Kernel misschien een onderdeel van de IPTables functionaliteit, maar dat wil niet zeggen dat dan de volledige functionaliteit ook beschikbaar is of inzetbaar is helaas, ik zou het echter graag zien! Want wat is er een betere plek om te beveiligen dan je centrale netwerkingang?

Software firewalls zijn overigens altijd minder efficient dan hardware firewalls, net als dat GPU's beter zijn in bitcoinminen dan CPU's, maar ASIC's beter zijn dan GPU's (aantal berekeningen per seconde per watt etc.) Dus hardware firewalls zouden eigenlijk een plekje moeten gaan krijgen in consumentenrouters, dat zou echt een hele grote stap voorwaarts zijn in netwerkbeveiliging.

[CAPSLOCK2000]

[quote]
Ik beweer gelukkig ook nergens dat NAT veiliger is dan een Firewall Het tegenovergestelde zelfs een Firewall is namelijk gemaakt met de intentie te beveiligen.
[/quote
gelukkig, daar zijn we het over eens

Ja laat door, nee drop, maar SPI is in mijn ogen eigenlijk geen echte firewall functie, maar een NAT functie, het is namelijk het blokkeren van verkeer dat niet geinitieerd is door een lokale netwerk client, niet meer en niet minder en precies dat wat NAT andersom doet, eigenlijk is SPI dus een benaming voor de "beschermende" functie die NAT van nature bied.

Daar moet ik toch bezwaar tegen maken, het werkt conceptueel én technisch andersom. NAT maakt gebruik van de SPI/connectiontracking-functionaliteit van de (Linux-)firewall.

Een "echte" firewall inspecteert IP pakketjes op inhoud en als een pakketje aan gestelde voorwaarden voldoet dan mag het pakketje passeren en het pakketje wordt gedropped als dit niet het geval is, deze firewall functionaliteit is vrijwel niet beschikbaar in consumentenrouters en daar is de hardware ook verre van krachtig genoeg voor.

Het ligt er maar aan wat je een "echte" firewall noemt. Voor mij hoeft dat geen 4th gen firewall te zijn die DPI doet. Gewoon kijken naar poorten, ip-adressen en connecties (wat SPI doet) is voldoende om minstens hetzelfde beveiligingsniveau te bieden als NAT. Daar is helemaal niet veel rekenkracht voor nodig. Iedere consumentenrouter is daar snel genoeg voor. Voor NAT moet dit ook gebeuren.

NAT is in de Linux Kernel misschien een onderdeel van de IPTables functionaliteit, maar dat wil niet zeggen dat dan de volledige functionaliteit ook beschikbaar is of inzetbaar is helaas, ik zou het echter graag zien!

Ik volg je niet, wat mis je? In mijn ervaring is het juist NAT waarbij je in de problemen komt omdat je adressen halverwege de firewall worden aangepast en je dan moeilijk moet gaan doen als je toch van die informatie gebruik wil maken in een later stadium.

Software firewalls zijn overigens altijd minder efficient dan hardware firewalls. <knip> Dus hardware firewalls zouden eigenlijk een plekje moeten gaan krijgen in consumentenrouters,

De prijs van een stuk dedicated hardware ligt al snel een stuk hoger dan een iets duurdere general purpose processor. Voor consumentenhardware denk ik niet dat het de moeite waard is om speciale hardware voor te ontwikkelen.

[e_balk]

- Inderdaad gelukkig zijn we het daarover eens

- Dat het conceptueel en technisch andersom werkt is ook wat ik bedoelde met gelijk aan NAT maar dan andersom

- Een echte firewall hoeft nog geen DPI uit te voeren om toch wat specifieker naar de pakketheaders te kijken, zoals hij nu werkt houd hij verder niets tegen dat niet op basis van een initiele connectie op die poort wordt toegestaan ook al is het een andere vorm van verkeer.

- Ik bedoelde daarbij de beschikbaarheid van de volledige firewall functionaliteit in een NAT/SPI capabele Router, niet over de technische problemen die nog kunnen ontstaan intern in de kernel.... Dat gaat ook voor mij net iets te ver

- Dedicated chips zijn al beschikbaar natuurlijk, ze moeten eventueel nog een beetje gedownscaled worden uit de enterprise toepassingen, maar neemt niet weg dat een dergelijke chip veel functionaliteit (bruikbaar) toe zou kunnen voegen aan consumenten routers, iets wat bij gebruik van IPv6 (zoals het bedoeld is althans) geen overbodige luxe zou zijn volgens mij. True op dit moment liggen de kosten veel hoger, maar met massa en downscaling moet dat best omlaag kunnen.

Maar goed mijn mening blijft dat SPI/NAT een heel basale beschermingslaag bieden die voor een echt kwaadwillende zeker makkelijk te doorbreken zijn. Uiteindelijk is overigens iedere vorm van beveiliging maar zo sterk als de zwakste keten in de schakel, welke meestal de consument zelf is....

[nullbyte]

"De firewall in consumenten routers is zo ontzettend basaal en beperkt dat je niet kunt stellen dat ze echte bescherming bieden."

Waarom dan?

[e_balk]

Omdat deze firewalls niet verder gaan dan SPI, dus eigenlijk iedere connectie die niet opgezet is door een interne client wordt gedropt verder wordt alles doorgelaten.

[nullbyte]

Het is heel simpel: Als de routers geen bescherming bieden en NAT ook geen bescherming is dan zijn alle consumenten netwerken redelijk makkelijk toegankelijk. Dit is gewoon niet zo. Was het wel zo geweest dan zouden de producenten van deze apparaatjes ze wel iets veiliger maken. Een beetje googlen leert dat meeste ISP vandaag de dag een redelijk veilige firewall/router/switch leveren bij een internet abonnement. Heeft verder geen bal met SPI te maken.

[e_balk]

Dit voelt als een wij van wc-eend argument.

De routers die geleverd worden zijn net zo veilig als de goedkope routers die je kunt kopen. Er zit nergens een behoorlijke beveiliging in omdat dit te complex is, het doel is een werkende connectie opleveren en het liefst op zo'n manier dat de klant er geen drol aan hoeft te doen.

Echt veilige netwerken zitten toch een beetje anders in elkaar. Als je een veilige router zou hebben zou je DMZ kunnen gebruiken zonder verder iets te hoeven doen, maar ik zou dan toch maar zorgen dat je DMZ device(s) goed beveiligd is, want de firewall van je Router doet dan helemaal niets meer.

[Alfa1970]

NAT werkt 2 kanten op! Je kan perfect terug piggybacken op een open NAT.

[e_balk]

Dubbel

[Reactie gewijzigd door e_balk op 26 juli 2024 07:31]

[e_balk]

Het is ook niet de taak van NAT om bescherming te bieden, NAT is bedoeld om meerdere interne (niet routeerbare) IP's te laten communiceren met een publiek (routeerbare) IP adres.

De bescherming die ervaren wordt is te wijten aan het feit, dat het werkt met interne niet routeerbare IP adressen, deze zijn niet direct te benaderen van buiten dat netwerk.

Een firewall heeft een hele andere taak dan een NAT en die is ontwikkeld met beveiliging in gedachten in tegenstelling tot NAT.

[Alfa1970]

Ja maar het probleem met die zogenaamde veiligheid is dat die er gewoonweg niet is omdat Nat 2 kanten op werkt.

Zodra jij een connectie opzet met je niet routeerbare interne IP adres open je een adres dat wél gerouteerd kan worden en waarmee je perfect het interne station kan aanspreken.

En hoewel een firewall een functie heeft in beveiliging is het al lang niet meer afdoende omdat er zo verschrikkelijk veel poorten open moeten staan dat het eigenlijk een gatenkaas is.

Maar buiten dat, het is volledig onnodig om te proberen van buiten naar binnen een connectie op te zetten als je met trojans en social engineering de connectie van binnen naar buiten op kan laten zetten. En poort 80 staat altijd open van binnen naar buiten, dus de hele discussie dat NAT ooit een "onbedoeld" veiligheid aspect in zich heeft gehad is gewoon grote onzin.
Het is een gedrocht dat is gemaakt om niet hele grote blokken externe IP adressen te hoeven aanschaffen omdat al 30 jaar bekend is dat IPv4 onvoldoende ruimte biedt, niets meer en niets minder.

[e_balk]

Vanwaar deze discussie, ik ben het eens met je.

NAT is geen beveiliging, de ingebouwde firewalls zijn een lachertje.

[Verwijderd]

NAT is een ramp. Vrijwel alle applicaties gebruiken tegenwoordig TCP of UDP. Niet omdat deze protocollen zo fantastisch zijn, of omdat we geen betere protocollen kunnen verzinnen maar simpelweg omdat de meeste NAT implementaties geen andere protocollen doorlaten. Door de miljoenen NAT routertjes die bij mensen thuis staan ligt de ontwikkeling van nieuwe of verbeterde protocollen nu al zo'n twee decennia helemaal stil.

Om het nog maar niet te hebben over alle trucjes die apps toe moeten passen om toch maar vooral goed te functioneren achter zo'n NAT routertje. Skype als een van de eersten met "hole-punching"; innovatief, maar triest dat dat soort trucjes noodzakelijk zijn. Functies als "PPTP pass-through" om je VPN te laten werken, of keepalives in je app inbouwen om toch vooral niet uit de NAT tabel gedropt te worden. Ik kan er erg verdrietig van worden.

Last but not least is het onzin dat NAT een soort veiligheidszege is geweest. Alles wat NAT veilig maakt kan een router ook toepassen zonder NAT. Je lijkt te suggereren dat routers een dergelijke voorziening niet zouden bieden als ze er niet toe gedwongen waren door NAT, maar daar is geen bewijs voor. Zodra beveiliging een issue wordt springen fabrikanten daar op in. Je zou hooguit kunnen stellen dat de beveiligingsoplossing er mogelijkerwijs iets anders uit had gezien.

[e_balk]

Dit zijn zaken die ik inderdaad bedoelde, NAT is niets meer dan een pleister voor een probleem dat ontstaat door het gebrek aan beschikbaarheid van publieke IPv4 adressen..

[Ximon]

NAT is geen beveiligingsfunctie. Als je security wilt, zet dan een firewall neer. Beveiliging wordt altijd uit noodzaak toegepast. Als niemand zou stelen hoef je ook niet moeilijk te doen met sleutels, scheelt een hoop gedoe.

[Verwijderd]

De discussie die al jaren woedt zullen we hier maar niet over doen. Maar toch:
1) Dat het er niet voor bedoeld is, is geen reden. IT is een evolutionair systeem waardoor zaken soms van functie veranderen. Stomme games waren ook geen bedoeling van computers a la Babbage en Turing, maar het is er wel van gekomen. Mogen we nu niet meer gamen? Videokaarten waren voor het laten zijn van graphics, maar worden nu ingezet als bitcoinminers. Ook verboten?
2) Dat het in het begin een crime was om te configuren, zal best. Dat geldt voor dik en dun ethernet, tokenring en alle andere technologieën die er zijn (geweest). Als dat het argument is, zouden er nooit computers zijn gebouwd.
3) "Gebruik een Firewall". Als er iets niet te configureren is voor een normale gebruiker.... Bij NAT weet je dat je 'veilig' bent omdat het werkt. Het testen van een firewall is iets ingewikkelder.
4) En mijn opinie is dat de migratie van IP4 juist zo moeizaam gaat omdat NAT succesvol en nuttig is. Het punt is, en ik maak het nog maar een keer: NAT biedt GRATIS en AUTOMATISCH beveiliging. Extreem belangrijk in een wereld waar een groot deel van de gebruikers nog niet de noodzaak inziet om het standaard wachtwoord van de router te wijzigen.

[Fermion]

NAT biedt GRATIS en AUTOMATISCH beveiliging

Totaal mee eens, natuurlijk is het tegenwoordig de eenvoudigste vorm van een beveiliging die ik overigens bij IPv6 zou gaan missen. Betekent straks meer werk om voor te zorgen dat alle devices niet zomaar op elk poort netwerk verkeer accepteert. Ik vrees met IPv6 de gouden tijden voor de botnets nog moeten komen.

Voor een huis en tuin keuken gebruik voldoet NAT.

[marcelvb]

Hoe kom je erbij dat NAT makkelijk in te stellen is en een firewall niet?

Standaard instelling NAT: inkomend verkeer wordt tegengehouden, uitgaand verkeer werkt.

Standaard instelling firewall: inkomend verkeer wordt tegengehouden, uitgaand verkeer werkt.

Wil je een poort open zetten bij NAT: poort forwarding toevoegen

Wil je een poort open zetten bij firewall: poort open zetten

Oftewel geen verschil qua configuratie.

Maar wel een groot verschil in functionaliteit.
IPv4 + NAT:
- elke poort kan maar één keer worden gebruikt, dus je kunt maar een server/service draaien
- veel applicaties werken niet of met moeite met NAT omdat het IP-adres in het protocolbericht zit verwerkt

IPv6 + firewall:
- je kan zoveel servers of services draaien als je wilt
- applicaties werken beter en kunnen veel simpeler zijn

[Verwijderd]

Verschil:

Ip4 zonder NAT: thuisnetwerk doet het niet en beveiliging

ip6 zonder firewall: thuisnetwerk doet het wel en een beveiligingsprobleem

En voor je over de kwaliteit van de beveiliging valt...Toen een tiental jaar geleden adsl en zo in zwang kwam zat iedereen met zonealarm naar die domme portscan waarschuwingen te kijken.

En ik ga hier niet herhalen dat ik denk dat NAT technisch intrinsiek beter is dan IP6 of een aparte firewall. Ik zeg wat anders.

[nullbyte]

"Voor een huis en tuin keuken gebruik voldoet NAT."

Dat is vanwege de ingebouwde firewall

[Reactie gewijzigd door nullbyte op 26 juli 2024 07:31]

[Ximon]

NAT werkt niet als beveiligingsmaatregel, of het er wel of niet voor bedoeld is doet er niet veel toe.

Stel dat je het als firewall ziet, dan is het er een waar je met gemak gaten in kunt schieten, zeker als UPnP aan staat.

Ik geef toe dat NAT beter is dan niks, maar het ongelukkige hiervan is dat fabrikanten van routers voor thuisgebruik en de ISP's die die dingen bij een internetabonnement meeleveren hierdoor ook niet gedwongen worden iets beters te verzinnen.

[Reactie gewijzigd door Ximon op 26 juli 2024 07:31]

[Verwijderd]

NAT werkt wel. Je geeft het zelf aan door expliciet te stellen dat het leveranciers van routers lui maakt.

Upnp standaard aanzetten, wpa wchtwoorden die herleid kunnen worden uit je ssid (die routers zijn er nog steeds), standaard wachtwoorden.. Het geeft aan dat leveranciers er niet mee kunnen omgaan.

Maar gelukkig is er nat. Zeker in deze warme tijden.

[sirdupre]

Sithistar schreef:

Upnp standaard aanzetten, wpa wchtwoorden die herleid kunnen worden uit je ssid (die routers zijn er nog steeds), standaard wachtwoorden.. Het geeft aan dat leveranciers er niet mee kunnen omgaan.

Maar gelukkig is er nat. Zeker in deze warme tijden.

Leg mij eens uit hoe NAT je beschermt tegen WPA wachtwoorden die herleid kunnen worden uit je SSID? Als een aanvaller op je lokale netwerk zit zal NAT je toch echt weinig soelaas bieden. Dan heb je waarschijnlijk meer aan zo'n "verschrikkelijk ingewikkelde" firewall die je standaard bij je OS of antiviruspakket krijgt.

[Reactie gewijzigd door sirdupre op 26 juli 2024 07:31]

[Verwijderd]

Nee, ik zeg niet dat dit iets met NAT te maken heeft. Het gaat om de mentaliteit van de leveranciers van modems en hun software.

[nullbyte]

Helemaal mee eens. Lekker open minded. Dingen doen met systemen waar ze niet voor bedoeld zijn. Dat zorgt ook voor veel beveiligings problemen. Mensen met grijze en zwarte hoeden maken hier nogal eens misbruik van.

[freaky]

Onzin. Het deel dat je NAT verhaaltje veilig maakt is het stateful firewall component wat er bij zit en dat kun je bij IPv6 ook gewoon gebruiken zonder het NAT deel. En je kunt het net zo goed default aanzetten op een router/firewall (per definitie gekoppeld in de gemiddelde consumenten router).

[e_balk]

Het probleem is dus dat je niet veilig bent met het gebruik van NAT. Configuratie van een firewall is inderdaad niet veel beter, dus zo veilig is het allemaal niet.

[locke960]

NAT is geen beveiligingsfunctie.

Dit wordt altijd maar weer herhaald in deze discussie, en het was ooit waar, maar nu klopt het niet meer.
Het is nog steeds geen beveiligingsfunctie in de zin dat het buitenstaanders uit je netwerk houd, daar is een firewall voor.
Maar in de huidige tijd van Infosec, internet surveillance en Big data is er een heel andere functie, en dat is het onthouden van zoveel mogelijk informatie aan potentiële tegenstanders. In dit geval bijvoorbeeld hoeveel interne apparaten je hebt. Zonder NAT ziet een externe afluisteraar (je ISP, de veiligheidsdienst, hele grote websites als Google) precies hoeveel apparaten je hebt. En door correlatie met de bestemming van het dataverkeer kan men vaak ook nog het soort apparaat afleiden.

In het geval van ipv6 wordt dit zelfs nog belangrijker. Dat protocol is namelijk zo dom gedefinieerd dat het unieke MAC adres van de hardware een onderdeel is van het IPv6 adres. Iemand die je externe verkeer afluistert weet dan niet alleen hoeveel apparaten je hebt, maar ook van welke fabrikant en mogelijk zelfs wat voor apparaat.
Fabrikanten als Apple registreren van elke verkocht apparaat het MAC adres en koppelen dat aan de koper. Ze hoeven die database alleen maar te koppelen aan de logfiles van hun webservers en ze weten precies wanneer jij hun website hebt bezocht en wat je daar gedaan hebt.

Nu is hier wel een " oplossing " voor bedacht, RFC 4941 " Privacy Extensions for Stateless Address Autoconfiguration in IPv6", maar dat is maar ten dele effectief en veroorzaakt een reeks andere problemen.

Het veroorzaakt problemen omdat het werkt door ipv het MAC adres willekeurige adressen te generen, die slechts kort gebruikt worden. Dat maakt het troubleshooten en monitoren van een intern netwerk erg lastig.
Nu is dat ook weer op te lossen, maar dat heeft weer als gevolg dat je apparaten weer (semi) permanente adressen krijgen, alleen nu niet je hardware adres, waardoor ze weer te tellen en te herkennen zijn.

Het is maar ten dele effectief omdat het random adres het MAC adres niet vervangt, het is een tweede adres. Je apparaat kan in een netwerk nog steeds gescand worden op het originele ipv6 adres met je MAC adres erin. In je eigen netwerk misschien niet zo een groot probleem, maar een mobiel apparaat zit tegenwoordig vaker in een vreemd netwerk dan een eigen netwerk.

Dus, als je een geef-je-tegenstanders-geen-enkele-informatie-als-het-niet-absoluut-nodig-is" filosofie aanhangt, dan heeft NAT ook voor ipv6 nog een security functie.

Vreemd genoeg lijkt het er op dat veel tweakers dit niet zo zien als het om NAT gaat, maar tegelijkertijd dit standpunt wel aanhangen als het gaat om wat de AIVD af mag luisteren, en wat voor informatie grote bedrijven allemaal van je verzamelen. Ze blokkeren cookies, scripts, tracking images en klagen over het registreren van hun enkele ipv4 adres door ISP en grote bedrijven.

[CAPSLOCK2000]

Zonder NAT ziet een externe afluisteraar (je ISP, de veiligheidsdienst, hele grote websites als Google) precies hoeveel apparaten je hebt.

NAT helpt een beetje maar minder dan je misschien zou denken. Er zijn verschillende technieken om de systemen die geNAT worden uit elkaar te houden. Zie bv [url=]https://www.cs.columbia.edu/~smb/papers/fnat.pdf]A Technique for Counting NATted Hosts[/quote]

In het geval van ipv6 wordt dit zelfs nog belangrijker. Dat protocol is namelijk zo dom gedefinieerd dat het unieke MAC adres van de hardware een onderdeel is van het IPv6 adres.

Het MAC-adres gebruiken is een keuze. Het hoeft niet. Moderne OS'en gebruik by default de privacy extensies. Wie dat verandert kan inderdaad z'n MAC-adres lekken maar dat is dan wel een beetje eigen keuze. Maar ik ben het met je eens dat dit niet ideaal is.

Het is maar ten dele effectief omdat het random adres het MAC adres niet vervangt, het is een tweede adres. Je apparaat kan in een netwerk nog steeds gescand worden op het originele ipv6 adres met je MAC adres erin.

IPv6 ranges scannen is haast niet te doen omdat het zo ontzettend veel adressen zijn. Er zijn ook wel technieken om dat wat efficienter te maken, zoals alleen op mac-gebaseerde-adressen te scannen, maar een echt random gekozen adres ga je met een scan niet vinden.

Vreemd genoeg lijkt het er op dat veel tweakers dit niet zo zien als het om NAT gaat, maar tegelijkertijd dit standpunt wel aanhangen als het gaat om wat de AIVD af mag luisteren, en wat voor informatie grote bedrijven allemaal van je verzamelen. Ze blokkeren cookies, scripts, tracking images en klagen over het registreren van hun enkele ipv4 adres door ISP en grote bedrijven.

Ik snap je punt. Meer beveiliging is beter. NAT voegt alleen niet zo veel toe dat ik die trade-off de moeite waard vind.
Maar als jij graag je IPv6 wil NATten dan kan dat. Technisch gezien is het prima mogelijk*.


* Er gaat een gerucht dat IPv6 niet kan/niet mag NATten maar dat klopt niet. Oudere implementaties konden het niet maar dat is niet fundamenteel.

[e_balk]

Serieus?

Kun jij mij uitleggen hoe NAT helpt dit te voorkomen precies? Volgens mij kunnen Google, de AIVD en je internetprovider en wie dan ook echt wel achterhalen hoeveel devices achter jouw router actief zijn. Ze kunnen de pakketjes namelijk uitlezen en heel veel informatie halen uit de IP Headers, is dat niet genoeg dan kunnen de pakketjes ook nog geopend worden (Deep Packet Inspection) om alles te weten te komen. Dus NAT beschermt je echt niet tegen datgene wat jij zegt.

Het enige dat NAT doet in deze is vereisen van de "afluisterende" partij dat ze wat kennis van zaken hebben en de juiste middelen inzetten, niet meer en niet minder.

[P-e-t-j-e]

NAT is geen beveiligingsfunctie

Dat zegt hij niet.. hij zegt

en je krijgt er een wagonlading beveiliging gratis bij

... dus bijkomend voordeel...

Het heeft vaak wel degelijk een (onbedoelde) beveiligingsfunctie door verkeer niet door te laten tussen de subnetten, dat is in 99 van de 100 consumentenrouters het geval waar nat (dus geen adressmapping of dmz) gebruikt wordt... Gelukkig zit er tegenwoordig in de betere routers vaak ook nog een firewall laag overheen, maar ook zonder die firewall wordt het meeste verkeer 'tegengehouden' door het niet door te laten naar het interne subnet.

[flabber]

"eenvoudigere configuratie". O ja? En NAT is de grootste netwerkzegen gebleken als het om beveiliging gaat.

Besef je dan wel dat NAT (RFC 1918) pas is bedacht na de IPv6 specificatie?
Het is heel leuk en aardig om NAT als zaligmakend voor IPv4 te bestempelen, maar het is een feit dat NAT helemaal niet bestond toen IPv6 bedacht werd.
NAT is in dat opzicht eigenlijk een goed bewijs voor het feit dat de mensen achter IPv6 al lang door hadden dat er problemen gingen ontstaan en dat ze een oplossing bedachten die veel langer houdbaar was dan IPv4, zelfs met NAT.

[mdavids]

NAT, hoezo NAT? Begrijp het nu eens; NAT was al een lapmiddel om een dreigend tekort aan IP-adressen op te vangen, maar dat tekort is nu zo groot dat zelfs voor NAT niet meer voldoende adres-ruimte is. Ieder zijn eigen NAT-box thuis, kan straks dus niet meer. En dus wordt het hooguit Carrier-Grade NAT. Nee, dat is lekker als je een portforward naar je webcam of NAS wilt hebben (die hopelijk goed beveiligd is). Kan namelijk in de meeste gevallen gewoon niet.

En die "wagonlading aan beveiliging" die je er zogenaamd bij krijgt, dat is gewoon simpelweg niet waar, zoals in andere reacties al uitgebreid is betoogt. NAT heeft niets met beveiliging te maken, tenzij je verlies van gemak en beperking van functionaliteit als een security-feature ziet (dan zou ik zeggen: zet je internet uit voor de ultieme beveiliging!) Je bent waarschijnlijk in de war met een firewall.

[Verwijderd]

zoals de eenvoudigere routering

Dat mag je mij dan even uitleggen.
http://blog.ipspace.net/2010/02/ipv6-myths.html

Ik kan een RFC lezen. Dus je mag net zo veel technische details gebruiken als je wilt.

Of misschien ben je enkel en alleen IPv6-PR aan het nabrabbelen, die je ergens ooit gelezen hebt ?

[Reactie gewijzigd door Verwijderd op 26 juli 2024 07:31]

[Snow_King]

Router Advertisements, multicasting, geen broadcast ARP meer, etc.

IPv6 bied wel degelijk veel voordelen over IPv4.

[Verwijderd]

Router Advertisements, multicasting, geen broadcast ARP meer, etc.

Router Advertisements zijn een detail in het grotere geheel. RA zou DHCP overbodig moeten maken (omdat je je default gateway dynamisch leert). Echter, in de loop de jaren heeft men geleerd dat DHCP toch zo z'n voordelen heeft. En nu is DHCPv6 weer heel populair.

Het probleem is dat de meeste IPv6-fanboys voornamelijk iets afweten over hoe hosts met routers communiceren. En niks over hoe routers onderling communiceren.

Een protocol maken dat werkt met een router en een paar dozijn hosts, dat kunnen we allemaal. Novell IPX, AppleTalk, DecNET, Vines. Er zijn genoeg voorbeelden van speelgoed-protocols. Het mooie van IP is dat het werkt op een wereldwijde schaal. En dat heeft niks te maken met Router Advertisements of ARP.

IPv6 bied wel degelijk veel voordelen over IPv4.

Zelfs het vervangen van DHCP en ARP door ND is een probleem. Zie hier de uitleg van een probleem waar mensen tegen aan lopen met IPv6:
http://blog.ipspace.net/2...bor-discovery-nd-and.html

[nullbyte]

Zonder ARP werkt IPv4 niet hoor.

[Snow_King]

Klopt, maar v6 kent geen ARP meer. Daar ben je vanaf.

[Snow_King]

Met de 'fanboy' opmerking zette je jezelf wel direct buiten spel.

Ik ben een groot voorstander van IPv6 omdat het uitrollen van IPv4 met NAT ed een zeer onwenselijke situatie is, het maakt meer kapot dan je lief is.

V6 lost wel degelijk problemen op die we nu hebben en de wereld is dan ook veel te laks geweest met het uitrollen.

Zie XS4All, bieden het al jaren aan en inmiddels is 53% van hun verkeer IPv6. Vraag is er dus zeker wel.

[Verwijderd]

Zie XS4All, bieden het al jaren aan en inmiddels is 53% van hun verkeer IPv6. Vraag is er dus zeker wel.

Ik ben xs4all klant. Onder andere omdat dat 1 van de 2 keuzes is die ik hier heb. (Geen kabel, geen glas). Mijn DSL doet 6.5Mbps. Ik had liever gehad dat xs4all (eigenlijk de kpn) had geinvesteerd in een kleine DSLAM vlak bij mijn huis. En in pair-bonding. Dan zou mijn snelheid van 6.5Mbps naar 30-40Mbps zijn gegaan. Maar nee, ik krijg IPv6 voor mijn geld. Not a happy customer. IPv6 is goed. Maar eerst meer bandbreedte is beter.

Wat betreft NAT heb je gedeeltelijk gelijk. Maar voor Nederlandse consumenten maakt het niet veel uit. Voor lastige services moet je nu met de hand een gat prikken in NAT. Met IPv6 moet je met de hand een gat prikken in je firewall. (Als je router die een heeft, tenminste).

[Reactie gewijzigd door Verwijderd op 26 juli 2024 07:31]

[Martinspire]

Maar hoeveel zijn er voor de meeste gebruikers ook daadwerkelijk een voordeel. Als het voor een kabelaar weinig oplevert, waarom zou hij er dan moeite in steken?

Ik denk dat het opraken van IP's de enige methode is om de overgang naar IPv6 te forceren. En dat gebeurt nu dus

[Belboer]

Eenvoudigere routing: IPv6 wordt standaard bij RIPE in /29 gealloceerd zonder dat er extra documentatie bij de aanvraag nodig is. De door RIPE geadviseerde end user assignment is /59. Met een /29 kan je dus 2^20 klanten bedienen. Dat is veel meer dan de grootste ISP's aan klanten hebben. Elke ISP heeft in principe dus maar 1 allocatie nodig. En het aantal IPv6 routes zal redelijk vergelijkbaar zijn met het aantal actieve AS-en.

Door de beperkte adres ruimte van IPv4 fragmenteerd deze ruimte als een dolle. Dat kan je zien aan de exponentiele groei van geadverteerde prefixes die niet vertraagd ook al is de pool van de grootste RIR's al leeg. In een full BGP feed staan nu al 585629 routes in voor 51308 actieve AS-en. Van die 51308 kondigen 20219 slechts een enkele prefix aan. Effectief worden er dus 535410 prefixen aangekondigd door 31189 AS-en ofwel gemiddeld 17 prefixes per AS. Meer dan de helft van de geadverteerde prefixen zijn /24. Dat is absurd. En dat wordt erger als ISP's delen van hun IPv4 ruimte aan derden in gebruik geven. Bij het overschreiden van 512K prefixes waren er al problemen met routers die dat niet meer in hun FIB kwijt konden. Als we straks over de een of twee miljoen gaan krijgen we dat weer.

[Verwijderd]

En het is mijn voorspelling dat IPv6 net zo erg zal worden.

Een groot deel van die more-specific-prefixes worden geadverteerd vanwege multi-homing. Of omdat een klant verhuist van ISP en niet wil hernummeren. Dat gaat ook gebeuren in IPv6.

Als we dat hadden willen voorkomen, dan had IPv6 tijdens de specificatie nieuwe technieken en algorithmes moeten krijgen voor site-multi-homing en on-the-fly renumbering. DHCP is daar niet genoeg voor.

Afijn, dat is iedere keer juist mijn punt. IPv6 had een hoop oude problemen kunnen oplossen. Maar dat is niet gebeurd. Jammer. En als side-effect heeft het (imho) dat de invoering van IPv6 erg traag is.

[lezzmeister]

En veel van die voordelen die ipv6 had zijn gewoon geïmplementeerd in ipv4. Er was een presentatie over op Defcon.

Uit mijn hoofd is nat juist een van de dingen die eerst was voorbehouden aan ipv6, als soortement veiligheidsmaatregel. Zal zo nog wel even kijken of ik het kan vinden.

[CAPSLOCK2000]

Je bedoelt IPSEC. Dat kan tegenwoordig inderdaad ook met IPv4. In de tijd de tijd dat IPv6 bedacht werd was het een belangrijke stap.

[Pyrone89]

Je kunt je ook afvragen waarom we in de afgelopen 10 jaar (zo lang weten we al dat de overgang extreem stroef verloopt) niet gewoon IPv7 hebben ontwikkeld die de eerder genoemde zaken aanpakt en het daadwerkelijk een aantrekkelijk alternatief maakt. Met een beetje geluk hadden ze tevens het probleem van de backwards compatibility opgelost.

Zou hetzelfde zijn als dat Microsoft gaat wachten tot iedereen van Windows 7 32-bit naar Windows 7 64-bit is gegaan voordat ze begonnen met de opvolgers.

[Reactie gewijzigd door Pyrone89 op 26 juli 2024 07:31]

[MSalters]

Onzinnig verhaal. "Backwards compatibility" is niet iets wat je zo maar in IPv6 kunt gieten. Het betekent dat je IPv6 host met een IPv4 host moet kunnen communiceren (client-4/server-6 en andersom, maar ook P2P).. De stack is niet het enige probleem. Database tabellen moeten groter worden,hash algoritmes moeten aangepast worden, etcetera.

Je verhaal over "geen voordelen" is simpelweg niet waar. Met IPv6 kun je binnen je eigen subnet elk MAC adres een eigen IP adres geven, wat DHCP overbodig maakt.

De andere voordelen die je suggereert maken IPv6 alleen maar minder compatible met IPv4, dus je spreekt jezelf nog tegen ook.

[The Zep Man]

Je verhaal over "geen voordelen" is simpelweg niet waar. Met IPv6 kun je binnen je eigen subnet elk MAC adres een eigen IP adres geven, wat DHCP overbodig maakt.

Misschien wil ik wel DHCP (of wellicht een vorm van NAT), om zo de privacy te beschermen van elke eigenaar van een apparaat dat via mijn verbinding het internet op gaat. Anders is een apparaat te volgen door te kijken naar de laatste 6 bytes van een IPv6 adres. Dat lijkt mij erg ongewenst.

Natuurlijk kan je een willekeurig locally administered unicast MAC adres gebruiken bij elke verbinding, maar dat kan je niet instellen op elk consumentenapparaat.

[Reactie gewijzigd door The Zep Man op 26 juli 2024 07:31]

[Maurits van Baerle]

Als je de privacy van je devices wil waarborgen kun je IPv6 Privacy Extensions gebruiken. Staat al standaard aan in de meeste OS-en.

[Verwijderd]

IPv6 Privacy Extensions heeft op zichzelf ook weer problemen.

De reden is dat met rfc4941 iedere hosts vele verschillende IP-addressen kan genereren. En die vermenigvulding kan weer tot scalability problemen leiden. Bv omdat sommige implementaties hun adres iedere paar seconden veranderen. De layer3-layer2 mapping tabellen raken vol. De tabellen van statefull gateways raken vol. Tabellen van load-balancers. Accounting en logging. Meer ND packets op het netwerk. Noem maar op.

Zie hier een paper dat uitlegt dat rfc4941 niet goed genoeg is. Tijd voor een vernieuwing.
https://www.usenix.org/sy...ticles/105438-Barrera.pdf

[CAPSLOCK2000]

Bv omdat sommige implementaties hun adres iedere paar seconden veranderen. De layer3-layer2 mapping tabellen raken vol. De tabellen van statefull gateways raken vol.

Welke? De paar implementaties die ik ken doen dat niet?

PS. Ik ben nieuwschierig, ik weet dat jij er veel van weet dus je hebt vast gelijk maar ik ben ze op onze netwerken nog niet tegen gekomen. Wij hebben hier overigens beveiliging tegen maar dat alarm is nog nooit af gegaan. Ik ken wel telefoons die iedere 2 seconde een nieuw IPv4-DHCP-request doen dus ik geloof direct dat er ook brakke IPv6 implementaties zijn. Het zou me zelfs verbazen als het niet zo is maar ik ben ze nog niet tegen gekomen.

[Reactie gewijzigd door CAPSLOCK2000 op 26 juli 2024 07:31]

[Dorank]

Misschien wil ik wel DHCP (of wellicht een vorm van NAT), om zo de privacy te beschermen van elke eigenaar van een apparaat dat via mijn verbinding het internet op gaat. Anders is een apparaat te volgen door te kijken naar de laatste 6 bytes van een IPv6 adres. Dat lijkt mij erg ongewenst.

Geen probleem:
-DHCPv6
-bv ipv6 nat met ip6tables

Maar zoals al aangedragen, voor privacy doeleinden zijn er de privacy extensies voor autoconf in ipv6

[Verwijderd]

Je privacy gaat eerder verloren aan cookies, auto-sign-in en browser fingerprinting.

[e_balk]

Zijn reactie verbaasd mij ook al, maar hij staat wel aangemerkt als Ipv6 specialist dus blijkbaar zijn er niet voldoende netwerkspecialisten hier actief op Tweakers. Of hij weet waar het over gaat, maar dan ben ik wel benieuwd naar meer inhoud in deze, want IPv6 heeft toch wel degelijk een toekomst volgens mij.

IPv6 heeft een hele waslijst van voordelen en verbeteringen doorgevoerd die niet mogelijk waren geweest als er gewerkt zou moeten worden met IPv4 compatibility. Het is juist ook zo gemaakt dat er een mogelijkheid is voor IPv6 clients te communiceren met IPv4 clients, alleen helaas niet andersom, maar goed dat is ook niet nodig, het is allemaal zo opgebouwd dat het overstappen van het een naar het ander geleidelijk doorgevoerd kan worden en zodanig gedaan kan worden, dat er geen enkel probleem is, maar er zou nu eigenlijk langzaamaan een stap moeten komen dat IPv4 ook daadwerkelijk uitgefaseerd gaat worden. Er moet langzaamaan gedwongen worden overgestapt op IPv6.

[Reactie gewijzigd door e_balk op 26 juli 2024 07:31]

[Verwijderd]

Zijn reactie verbaasd mij ook al, maar hij staat wel aangemerkt als Ipv6 specialist dus blijkbaar zijn er niet voldoende netwerkspecialisten hier actief op Tweakers.

Ik zou mezelf geen IPv6-specialist willen noemen. Ik vind het dan ook erg grappig dat ik hier de IPv6-King ben.

Maar ik zou mezelf wel een netwerk-specialist willen noemen. Vooral als het over routing (layer-3) en routing protocols gaat. Ik denk niet dat er veel Nederlanders zijn die ooit zelf een protocol-implementatie hebben gebouwd.

dan ben ik wel benieuwd naar meer inhoud in deze, want IPv6 heeft toch wel degelijk een toekomst volgens mij.

Tuurlijk heeft IPv6 een toekomst. De vraag alleen is: wanneer komt die toekomst ? Volgend jaar ? Of over 10 jaar ? Heel erg lang leek het er op dat het nog jaren (5-10 jaar) zou duren voor IPv6 relevant wordt. Dit jaar begint het iets duidelijker te worden.

IPv6 heeft een hele waslijst van voordelen en verbeteringen doorgevoerd die niet mogelijk waren geweest als er gewerkt zou moeten worden met IPv4 compatibility.

Wat ?
Noem me een voorbeeld van verbetering.
http://blog.ipspace.net/2010/02/ipv6-myths.html

En nee, SLAA en ND tellen niet.

[CAPSLOCK2000]

Ik zou mezelf geen IPv6-specialist willen noemen. Ik vind het dan ook erg grappig dat ik hier de IPv6-King ben.

Je bent dan ook wel heel fanatiek in op ieder IPv6 topic duiken om te vertellen hoe stom ze twintig jaar geleden waren en dat IPv6 nauwelijks voordelen biedt. Ik ben het op zich wel met je eens maar je komt af en toe nog al zuur over.
Ik ben vooral blij dat het nu eindelijk wel op gang komt zodat we hopelijk een keer over het volgende protocol kunnen gaan nadenken.

[Verwijderd]

Je bent dan ook wel heel fanatiek in op ieder IPv6 topic duiken om te vertellen hoe stom ze twintig jaar geleden waren en dat IPv6 nauwelijks voordelen biedt.

Ik hou mijn mond.
Totdat er iemand gaat spuien dat IPv6 zo ontzettend veel beter is dan IPv4. En zo veel voordelen heeft. Dan post ik. Sorry.

[CAPSLOCK2000]

Excuses zijn niet nodig
De manier waarop je post verraadt een zekere passie voor het onderwerp. Dat je er dan nogal negatief tegenover lijkt te staan is vrij bijzonder. Dat valt op, geen probleem hoor, ik ben blij met je kritische mening maar het valt wel op

[nullbyte]

Natuurlijk heeft IPv6 een toekomst, de IPv4 adressen zijn op.

[Tukkertje-RaH]

Tegenover dat voordeel van geen DHCP server meer nodig hebben (wat niet het allerlastigste is in een netwerk) staat een flinke hoeveelheid bezwaren. DNS wordt nog belangrijker in het netwerk (en die zijn wel erg lastig goed en veilig te beheren), al je netwerk beheerders moeten op cursus voor nieuwe tools en (ik denk 't allerbelangrijkst) mensen hebben geen 'gevoel' bij de adressen die nu worden gebruikt.

Waar je 'vroeger' als DNS gewoon Google's IP even instelde (8.8.8.8) kom je nu aan met adressen als 3ffe:6a88:85a3:08d3:1319:8a2e:0370:7344. Dat blijft gewoon niet 'plakken' en voelt vreemd. Dan komt er iemand die handig lijkt te zijn en '0000' gaat vervangen door '::' en de meerderheid is het spoor bijster...

IPv6 had mijns inziens even de wind mee eind jaren '90 bij het dreigende tekort. Dat zette niet door met als gevolg dat IPv6 wat bleef sudderen op de achtergrond. Sommige apparaten kwamen met een tweede stack waar je dan geen idee van had wat 't precies allemaal op de achtergrond deed: Teredo interface in je Windows machine? IPv4 met z'n NAT - het werkte allemaal wel!

[anboni]

Voor well-known diensten kun je natuurlijk nog steeds een mooi adres verzinnen. Om bij jouw voorbeeld te blijven, 2001:4860:4860::8888 is het ipv6 adres van google dns. Goed, het zijn iets meer cijfertjes, maar als je telefoonnummers kunt onthouden, kun je dit soort dingen ook onthouden.

[P-e-t-j-e]

maar als je telefoonnummers kunt onthouden

dat doet dus niemand meer door telefoonboeken/contacts in de gsmmetjes van tegenwoordig

[mjl]

Ik weet genoeg ip'S uit mijn hoofd. Diverse proxys, servers, routers die ik vaak nodig heb rammel ik zo uit de vingers..

Ja telefoonnummers onthoud ik dan weer niet.

[P-e-t-j-e]

Ach, en anders heb je een mooie ping- of nslookup-app op je mobieltje nog hé

[Verwijderd]

Onzinnig verhaal.

Dank je wel.

"Backwards compatibility" is niet iets wat je zo maar in IPv6 kunt gieten.

Nee. Nu niet meer. Dat had moeten gebeuren in 1993-1995, toen IPv6 werd ontwikkeld.

Het betekent dat je IPv6 host met een IPv4 host moet kunnen communiceren (client-4/server-6 en andersom, maar ook P2P).. De stack is niet het enige probleem. Database tabellen moeten groter worden,hash algoritmes moeten aangepast worden, etcetera.

Dit is pas een onzinnig verhaal.
En ik zal je vertellen waarom.
Database tabellen en hash algorithmes zijn *intern* in een router of ander apparaat. Dat betekent dat je ze kunt veranderen, *zonder* dat je een protocol hoeft te veranderen. Daarom zijn dit geen factoren die meespelen in netwerk-transitie. Interne zaken kun je makkelijk veranderen. Machine per machine. Protocollen zijn het probleem. Want dan moet je of compatibility inbouwen, of je moet allemaal tegelijk overgaan (aka Flag Day).

Je verhaal over "geen voordelen" is simpelweg niet waar. Met IPv6 kun je binnen je eigen subnet elk MAC adres een eigen IP adres geven, wat DHCP overbodig maakt.

Ik heb het over routing op grote schaal. Het Internet. Grote ISPs. Grote data centers. SLAA is slechts een detail.

De andere voordelen die je suggereert maken IPv6 alleen maar minder compatible met IPv4, dus je spreekt jezelf nog tegen ook.

Waarschijnlijk was een betere IPv6 nog meer incompatible met IPv4 geweest. Inderdaad. Maar dat is het vandaag ook. Maar als een nieuwe IPvX echte voordelen had gehad, voor consumenten, ISPs, grote bedrijven en data centers, dan was IPvX misschien wel *veel* sneller geaccepteerd.

Het Internet zoals wij het kennen begon in November 1988. Toen mocht het net gebruikt worden voor commerciele doeleinden. En de eerste commerciele ISPs begonnen. In 1997 had 11% van de mensen in de westerse wereld Internet-access. Dat was dus 9 jaar, voor een totaal nieuwe techniek. IPv6 is slechts een "verbetering". We zijn 20 jaar verder, en we zitten nog steeds niet op die 11%.

[H!GHGuY]

Nee. Nu niet meer. Dat had moeten gebeuren in 1993-1995, toen IPv6 werd ontwikkeld.

Anderzijds heeft iedereen ook diezelfde 20 jaar gehad om een beter protocol te verzinnen dan IPv6. Dat is ook niet gebeurd.
De kost om over te schakelen is gigantisch (en dan heb ik het ook over het aanpassen van software) en is uiteindelijk gewoon gespreid over de tijd.

En een IPv4compatibel protocol zie ik echt op geen enkele andere manier gebeuren. We moeten nu eenmaal over op IPv6 en hopen dat die het lang genoeg uithoudt.
Gelukkig is de IPv6 extension-header handling middels TLV en zonder maximul lengte een stuk beter dan die van IPv4. Dat betekent dat Ipv6 ten minste het forward compatibility probleem probeert aan te pakken.

Een andere probleem is dat ze van de IPv4-suite (IP, ARP, IGMP, ...) nu alles onder dezelfde IPv6 header geduwd hebben.

Allemaal verbeteringen - alleen vallen ze niet hard op omdat IPv4 nu eenmaal al geimplementeerd is en niemand nog wakker ligt van die problemen (behalve mensen die firewalls opzetten).

[conhen]

Geen dhcp betekent dat een gebruiker iets moet (laten) configureren op zijn nieuwe pc. DHCP betekend dat dat automatisch gaat. Juist reuze handig lijkt me...

[flabber]

Echter, de wijzneuzen die vooraan stonden bij IPv6 in de vroege jaren negentig waren helemaal gekant tegen backwards-compatability.

"Wijsneuzen"?
Ik zou durven beweren dat het uitzonderlijk begaafde en vooruitziende IT'ers waren.
We hebben het hier over 1992-1994 waarin men eraan begonnen is.
De tijd dat je op Windows 3.1 nog zat te hannesen met winsock 2 om een TCP/IP verbinding op te zetten richting NLnet. Toen tokenring en IPX nog dagelijks over de tong gingen en een 56k6 modem state-of-the-art was.
Het opstellen van een nieuw network protocol is geen kattepis en zij zagen de problemen al ontstaan op het moment dat menig Tweaker die tot een jaar geleden de IPv4 problemen afdeed als 'minor nuisance' nog niet eens geboren was.

In hun ogen zou dat er voor zorgen dat mensen nog jaren lang IPv4 en IPv6 in combinatie zouden gebruiken. En dat wilden ze niet hebben. Ze wilden iedereen dwingen om zo snel mogelijk op IPv6 over te stappen, door het juist express niet compatible te maken. Backfired.

Het enige dat echt 'backfired', is de traagheid waarmee de bedrijven die meer oog hadden voor winst op de korte termijn de overgang naar IPv6 wisten uit te stellen tot het laatste moment.

Wat ook geholpen zou hebben, is als IPv6 voordelen had gehad over IPv4. Dat heeft het niet. Het is (bijna) precies hetzelfde protocol, alleen met meer bits voor de adressen. Een gemiste kans.

IPv6 had/heeft legio voordelen boven IPv4.
Het bieden van een (voorlopig) oneindig aantal IP adressen is uiteraard het meest besproken voordeel. Maar zaken als [gedegen] multi- en unicast, discovery mogelijkheden voor types systemen (routers, DNS servers, etc) zijn andere voorbeelden. Simpelere routering, afschaffen van NAT, en dan niet de veel betwiste "beveiliging", maar problemen tengevolge van NAT.
Menig consultant/bedrijf heeft veel geld verdient met het koppelen van twee bedrijfsnetwerken met overlappende reeksen. Fijn dat het voor mensen thuis 'veiligheid' biedt, maar gemeente en brandweer die met elkaar moeten communiceren? Mijn inzet in dat soort gevallen is vaak duur betaald...
En dan is er nog beveiliging.
Wat dacht je van IPsec? Encryptie en/of authenticatie?
Of het afschaffen van fragmentatie wat toch een bron is van menig vulnerability.

Natuurlijk heeft IPv4 anno 2015 de meeste van die problemen opgelost, maar het is een feit dat een zeer groot gedeelte daarvan vanuit IPv6 gebackport is naar IPv4.

IPv6 had meer problemen kunnen opgelossen, zeker op layer-3 niveau (networking). Zoals host-multihoming, as-multihoming, locator-identifier separation, on-the-fly renumbering, betere automatic prefix-summarization, mobile, noem maar op. Als dat het geval was geweest, dan hadden endusers en ISPs staan springen om IPv6 in te voeren.

Is IPv6 perfect?
Nee, natuurlijk niet. Maar het daarom afdoen als iets slechts en amper de moeite waard om over te gaan is gewoon kortzichtig.
Zou je terug willen naar tokenring en IPX met alle problemen daarvan?
IPv4 is zo'n 20 jaar eerder ontstaan dan IPv6. Ik dan kdat het na 40 jaar (!) wel hoog tijd wordt om voor eens en altijd afscheid te nemen van zo'n oud legacy protocol.

IPv6 is bedacht voor internet, google en facebook alledaagse dingen waren.
Men had de overgang al veel eerder moeten maken, dan waren de kosten en de impact nooit zo gigantisch uit de klauwen gelopen.
AWaar de muziekindustrie wordt bespuugd om het vasthouden aan oude methoden en gebruiken, lijkt het erg bon-ton om de netwerkindustrie in bescherming te nemen voor het feit dat ze gewoon zelf te laks zijn geweest.

[Verwijderd]

Ongeveer alles wat je zegt heb ik al ontkracht in andere posts op deze pagina. Als je IPv6 echt zo'n stap vooruit vind, dan raad ik je aan om dit eens te lezen:
http://blog.ipspace.net/2010/02/ipv6-myths.html
Dat heb ik ook al tientallen keren gelinkt hier op Tweakers.

IPv6 gebruikt BGP, OSPF en IS-IS, net als IPv4. Niks simpeler. Forwarding is bijna hetzelfde. Fragmentatie in IPv4 kennen we ook al lang niet meer, since ip-mtu-discovery. IPsec zit ook in IPv4. Multicast in IPv6 is ongeveer hetzelfde (PIM). Geen NAT is inderdaad een verbetering. Maar dat had *ieder* nieuw protocol gebracht. Backporten uit IPv6 ? Misschien IPSec. Maar alle nieuwe tech wordt eerst voor IPv4 uitgebracht, deployed en getest. En pas daarna gaat het in IPv6.

Echt, ik weet dat het lijkt: IPv6 is nieuwer, dus zal het wel beter zijn. Nope. Meer adressen, dat is alles. Meer adressen zijn noodzakelijk, daarom zal IPv6 er we op een dag komen. Maar daar ging het hier niet over. Het ging over: IPv6 is expres niet backwards-compatible (maar dual stack). En dat heeft de introductie vertraagt. Bovendien heeft IPv6 geen financiele of technische voordelen voor ISPs of eindgebruikers. Anders was het er al lang geweest.

[flabber]

Ongeveer alles wat je zegt heb ik al ontkracht in andere posts op deze pagina. Als je IPv6 echt zo'n stap vooruit vind, dan raad ik je aan om dit eens te lezen:
http://blog.ipspace.net/2010/02/ipv6-myths.html
Dat heb ik ook al tientallen keren gelinkt hier op Tweakers.

Ik ken het artikel, maar ben het zeker niet eens met alle punten.
Om te beginnen, zijn punt over NAT is spot-on: "Anyone who thinks NAT is a security feature deserves to become part of a botnet."

Dat de routing tables groeien, uiteraard; IPv6 adressen nemen nu eenmaal meer ruimte in beslag. Echter, IPv6 beschrijft een protocol en wat je e rmee zou kunnen doen. De adresruimte was dusdanig groot dat er voorstellen waren voor een dusdanig wereldwaijde verdeling dat routering wel veel simpeler zou worden. Men heeft echter besloten om bij fe uitrol van IPv6 ranges hier geen rekening mee te houden zodat er in feite geen versimpeling overblijft.
De overgang naar IPv6 had een nieuw begin kunnen zijn om dit direct bij aanvang goed te regelen zodat er wel voordelen te behalen waren, maar helaas heeft men die kans nu alweer laten liggen. Dat is echter niet inherent aan IPv6 of IPv4

Bovendien heeft IPv6 geen financiele of technische voordelen voor ISPs of eindgebruikers. Anders was het er al lang geweest.

Voor eindgebruikers maakt het verschil tussen IPv4 en IPv6 geen ene mallemoer uit. Natuurlijk, een klein gedeelte IT'ers kan leze en schrijven met IPv4, maar ik schat dat zo'n 99,99% van de gebruikers blijft steken bij 'What's my IP address'.
Voor ISPs zou het hebben van een schier oneindig aantal IP reeksen al voldoende technische reden moeten zijn.

Financieel, tsja, daar ben ik het roerend met je eens.
Voor de meeste ISP's is er geen enkele reden om over te stappen.
Pas nu er echt een tekort dreigt gaan sommige westerse ISP's merken dat ze in de problemen komen. Buiten de VS en EU weet men dat al veel langer en is IPv6 gewoon een werkelijkheid en speelt IPv4 technisch of financieel helemaal geen rol.

[ReneX]

Op zich is dual stack een prima methode om het oude protocol uit te faseren.

Grootste probleem is dat men er niet in geslaagd is om in >10 jaar een IPv6 netwerk in de lucht te brengen. Eigenlijk van de zotte, en m.i. pure onwil of onkunde.

Backwards compatibiliteit is niet altijd even handig te realiseren. Je gaat er dan vanuit dat IPv4 apparatuur ook tegen IPv6 moeten kunnen ... (Je zou dan altijd ergens een mapping van IPv4 naar IPv6 moeten hebben voor v4 clients naar v6 servers en v.v.).

[Reactie gewijzigd door ReneX op 26 juli 2024 07:31]

[Verwijderd]

Op zich is dual stack een prima methode om het oude protocol uit te faseren.

IPv6 is het bewijs dat dat misschien helemaal niet zo'n prima methode is.

Eigenlijk van de zotte, en m.i. pure onwil of onkunde.

Het is heel simpel.
Er is geen technisch voordeel om op IPv6 over te stappen.
Er is geen financieel voordeel om op IPv6 over te stappen.
Niet voor consumenten, niet voor gebruikers, en niet voor ISPs.

Jij en ik kijken misschien naar Internet-technologie vanuit het oogpunt van een enthousiasteling. Maar wij betalen niet de rekeningen. Die worden betaald door mensen/bedrijven die vooral in winst en omzet zijn geinteresseerd. IPv6 levert ze niets op. Kost ze alleen geld.

Backwards compatibiliteit is niet altijd even handig te realiseren. Je gaat er dan vanuit dat IPv4 apparatuur ook tegen IPv6 moeten kunnen ...

Nee.
Ik ga er vanuit dat als je backwards compatability wilt, dat je dan IPv6 zo designt, dat het mogelijk is om een IPv4 naar IPv6 gateway te bouwen. Zodat sommige delen van het net IPv4-only zijn, en andere delen van het net IPv6-only. Dat had gekund. Op het moment kan dat niet, want IPv6-only kan niet met IPv4-only praten. Dat was een bewuste design-decision van de IPv6 IETF workgroups.

[Reactie gewijzigd door Verwijderd op 26 juli 2024 07:31]

[Paul]

Er is geen technisch voordeel om op IPv6 over te stappen.
Er is geen financieel voordeel om op IPv6 over te stappen.
Niet voor consumenten, niet voor gebruikers, en niet voor ISPs.

Voor iemand die mee heeft geholpen aan het schrijven van RFC's is dat redelijk kort door de bocht. Er is één ZEER goede reden om op IPv6 over te stappen: De IPv4-addressen raken op!

Ik ga hier geen commerciële bedrijven linken als bewijs maar een snelle zoektocht zegt me dat je momenteel tussen de 8 en 13 euro betaalt voor één IP-adres, terwijl IPv6-adressen zo goed als gratis zijn.
Qua support in moderne hardware en software zit het ook wel goed.

Er zijn dus financiële redenen te over om wel over te stappen en technisch is er geen belemmering. Waarom zou je het dan niet doen?

Ik snap dat de financiële overweging vooral zit in het niet meer gebruiken van IPv4, maar het antwoord daarop is simpelweg IPv6...

[Jaco69]

Er is één ZEER goede reden om op IPv6 over te stappen: De IPv4-addressen raken op!

Zolang de IPv4 adressen niet daadwerkelijk op zijn is die reden er dus niet. Olie, kolen en uranium raken ook op maar zolang dat niet gebeurt is (en het de goedkoopste oplossingen zijn) halen we daar onze energie vandaan.

[Paul]

Zolang de IPv4 adressen niet daadwerkelijk op zijn is die reden er dus niet.

De titel van het bericht is dat ARIN niet meer aan de vraag kan voldoen. Hoezo is het dan niet op?

"Ja, er is nog één adres, en dat krijg jij niet, maar ze zijn dus niet op!", sorry, maar als ik geen adressen kan krijgen dan mag je er best een ander labeltje aan hangen maar onder de streep is het effect hetzelfde

[Verwijderd]

ARIN is slechts 1 bron van IP adressen. Een internationaal bedrijf kan ze ook bij RIPE of APNIC aanvragen. Daarnaast is er een levendige handel in ongebruikte subnetten, zowel verkoop als diverse lease constructies.

Kijk eens op een forum als webhostingtalk. Er zijn diverse providers die nog altijd 128-256 IP adressen bij een simpel servertje leveren. Ik heb er zelf diverse in gebruik.

Een prijs van 8 tot 13 euro per IP is dan ook flauwekul. Je zult vast een paar bedrijven kunnen vinden die dergelijke bedragen vragen, maar ik betaal zo'n $119 per server inclusief 128 adressen. (En dat zijn recente aanbiedingen.)

Enfin, ik zit met smart te wachten op IPv6, maar dat is toch echt puur om technische redenen. Financieel heb ik nog geen motief kunnen ontdekken.

[Paul]

Een prijs van 8 tot 13 euro per IP is dan ook flauwekul. Je zult vast een paar bedrijven kunnen vinden die dergelijke bedragen vragen, maar ik betaal zo'n $119 per server inclusief 128 adressen. (En dat zijn recente aanbiedingen.)

$119 eenmalig? En ongetwijfeld bij een bedrijf dat nog voorraad heeft...

[Jaco69]

[...]
De titel van het bericht is dat ARIN niet meer aan de vraag kan voldoen. Hoezo is het dan niet op?

"Ja, er is nog één adres, en dat krijg jij niet, maar ze zijn dus niet op!", sorry, maar als ik geen adressen kan krijgen dan mag je er best een ander labeltje aan hangen maar onder de streep is het effect hetzelfde

Pas als de IPv4 adressen niet meer geleverd kunnen worden door je eigen ISP, of als je favoriete site alleen op IPv6 bereikbaar is, zal je aan de IPv6 moeten. Tot die tijd worden we niet zo geraakt door het feit dat IPv4 adressen ergens schaars zijn geworden.

[Verwijderd]

Er zijn dus financiële redenen te over om wel over te stappen en technisch is er geen belemmering. Waarom zou je het dan niet doen?

Nee. Er zijn financiele redenen voor sommige mensen (zij zonder IPv4 adressen) om te hopen dat *andere* mensen overstappen.

Als je IPv4 adressen hebt, dan hoef je helemaal niks. Alleen als je geen IPv4 adressen hebt, dan hoop je dat iedereen overstapt. Dat is wezenlijk verschillend.

[CAPSLOCK2000]

Nee. Er zijn financiele redenen voor sommige mensen (zij zonder IPv4 adressen) om te hopen dat *andere* mensen overstappen.

Dat klopt, ik heb zelfs wel eens gedacht dat er partijen zijn die opzettelijk vertraagde om nieuwe concurrenten van de markt te houden.

Vroeg of laat gaat er een punt komen dat het omdraait. Er zijn nu al VPS-boeren die standaard geen IPv4-adressen leveren, daar moet je voor bij betalen. Als er eenmaal genoeg eindgebruikers zijn met IPv6 dan zullen er gebruikers komen die geen geld meer willen uitgeven aan IPv4. "Bij mij werkt het gewoon dus het ligt aan jouw systeem".
Het kan nog even duren voor wij daar zijn maar in Belgie zou het nu al kunnen gebeuren.

[Ximon]

[...]

IPv6 is het bewijs dat dat misschien helemaal niet zo'n prima methode is.

IPv4 is het bewijs dat het een betere methode is dan tot nu toe gehanteerd wordt

Het is heel simpel.
Er is geen technisch voordeel om op IPv6 over te stappen.
Er is geen financieel voordeel om op IPv6 over te stappen.
Niet voor consumenten, niet voor gebruikers, en niet voor ISPs.

Jij en ik kijken misschien naar Internet-technologie vanuit het oogpunt van een enthousiasteling. Maar wij betalen niet de rekeningen. Die worden betaald door mensen/bedrijven die vooral in winst en omzet zijn geinteresseerd. IPv6 levert ze niets op. Kost ze alleen geld.

Dit argument heeft er voor gezorgd dat ze bijvoorbeeld nu bij ARIN met de rug tegen de muur staan. IPv6 valt onder business continuity en heeft niet als doel extra geld verdienen (tenzij je natuurlijk IPv6 consultant bent). Data backup kost ook bakken met geld, maar toch wordt het overal gebruikt.

Ik ga er vanuit dat als je backwards compatability wilt, dat je dan IPv6 zo designt, dat het mogelijk is om een IPv4 naar IPv6 gateway te bouwen. Zodat sommige delen van het net IPv4-only zijn, en andere delen van het net IPv6-only. Dat had gekund. Op het moment kan dat niet, want IPv6-only kan niet met IPv4-only praten. Dat was een bewuste design-decision van de IPv6 IETF workgroups.

464XLAT kan dit. Ik ga niet pretenderen dat ik hiermee een succesvolle implementatie heb gedaan of dat het makkelijk is, maar er zijn zeker mogelijkheden in die richting. Men heeft jaren gedaan over het ontwerpen van de standaard en als ze hadden geprobeerd elk probleem dat er te verzinnen valt binnen de standaard op te lossen, dan waren ze nu nog steeds aan het ontwerpen geweest.

[Verwijderd]

464XLAT kan dit. Ik ga niet pretenderen dat ik hiermee een succesvolle implementatie heb gedaan of dat het makkelijk is, maar er zijn zeker mogelijkheden in die richting. Men heeft jaren gedaan over het ontwerpen van de standaard en als ze hadden geprobeerd elk probleem dat er te verzinnen valt binnen de standaard op te lossen, dan waren ze nu nog steeds aan het ontwerpen geweest.

De hele discussie hier is: als in 1992-1995 de IPv6 community had nagedacht over backwards-compatability, dan had X464 wellicht een heel stuk simpeler kunnen zijn. Maar dat wilden ze juist precies niet.

In 1994 waren er verschillende voorstellen voor de opvolger van IPv4. Het project heette IPng. (Star Trek!). Een van de voorstellen was genaamd TUBA. "TCP en UDP with Bigger Addresses". Het was een heel simpel voorstel. TCP en UDP houden, DNS ook, alle applicaties ook. Enkel de netwerk-layer vervangen door CLNP. CLNP was een protocol net als IPv4 (connectionless best-effort delivery). Maar het had 20-byte addressen.
https://tools.ietf.org/ht...d-ipng-tuba-whitepaper-00
TUBA was heel makkelijk te bouwen. Cisco had een implementatie. Die is nog jaren gebruikt door grote ISPs. (Je kon telnet/ssh doen over CLNP, als je IPv4 routing om zeep was). Performance was net zo goed als IPv4 (zelfde pps op een Cisco 7000). Als de IAB voor TUBA had gekozen, dan waren we in 2000 allemaal al over geweest op het nieuwe IPvX.

Maar de IPv6-community vond het maar niks. Omdat CLNP uit de Telco/PTT community kwam. Ze waren zelfs zo vals, dat ze IPv6 16-bytes adressen gaven, ipv 20 bytes. Zodat je een CLNS adres niet in IPv6 kon stoppen.

[CAPSLOCK2000]

TUBA was heel makkelijk te bouwen. Cisco had een implementatie. Die is nog jaren gebruikt door grote ISPs. (Je kon telnet/ssh doen over CLNP, als je IPv4 routing om zeep was). Performance was net zo goed als IPv4 (zelfde pps op een Cisco 7000). Als de IAB voor TUBA had gekozen, dan waren we in 2000 allemaal al over geweest op het nieuwe IPvX.

Ik vraag me dan af waarom het niet gebeurd is. Het zal best dat er een paar vervelende IPv6-fanboys waren die er tegen waren was dat de enige reden? Het zou niet de eerste keer zijn dat een inferieure techniek het wint maar meestal is dat gekoppeld aan een enorm succes (denk bv VHS en Windows). IPv6 is dusver geen succes te noemen. Dus waarom zijn die andere protocollen helemaal niks geworden?

[Verwijderd]

De hele beslissing was puur politiek. Ik was net nieuw in networking, en heb de hele IPng-discussie net gemist. Mijn eerste IETF was in 1996. Ik weet wel wat de mening is van een hoop ipv4-veterans waar ik veel respect voor heb.

IPng en IPv6 gebeurde in 1992-1996. Net in de tijd dat het Internet booming was. Bedrijven als cisco (en later Juniper) verdienden goud geld met IPv4. En hun employees waren 24 uur per dag druk doende om het Internet aan de praat te houden, en ook nog eens te laten groeien als kool.

Sommige bedrijven hadden de boot gemist. Wellfleet/Nortel bv. Engineers van die bedrijven hadden weinig te doen, want niemand kocht hun producten. Bovendien hoorden ze er niet echt bij, want ze hadden geen klanten. Of geen echte internet-producten (zoals Sun). Al die engineers, plus een paar jokers, zagen hun kans schoon toen IPng er aan kwam. Die stonden vooraan om mee te spelen. Als je weet hoe de IETF werkt, dan weet je dat je ze niet buiten de deur kunt houden. De engineers die 1990-1995 de techniek hebben gebouwd om IPv4 te laten groeien (voornamelijk cisco en ex-cisco lui), en de engineers bij de grote ISPs hadden geen zin in politieke spelletjes. Toen ze het politieke spel verloren hebben, hebben ze hun handen van IPv6 afgetrokken. Mensen met nul ervaring in het bouwen van grote netwerken, of routers daarvoor, hebben IPv6 gedefinieerd. Dat is het probleem. Die wisten niet eens wat multi-homing was. Die hadden geen idee hoe je routing-table-growth moet aanpakken (nee, CIDR was niet genoeg. En is niet genoeg in IPv6). Letterlijk bij ARP hield hun kennis van routing op. Het waren host/application luitjes.

Zelf heb ik me ook weinig met IPv6 bemoeid. Ik had wel wat beters of interessanters te doen.

Afijn, een hoop mensen zullen wel denken dat ik dit verhaal uit m'n duim heb gezogen. Maar zo heb ik het beleefd.
Ik moet nog wel eens denken aan dit artikel.
http://www.lightreading.c...-priesthood/a/d-id/576216
Ik kan je verzekeren dat van die IP-priesthood zich helemaal niemand bezig hield met IPv6.

[Reactie gewijzigd door Verwijderd op 26 juli 2024 07:31]

[Ximon]

Ik kende TUBA nog niet, en heb snel even zitten lezen maar ik zie duidelijke overeenomsten met IPv6:

• Implementatie is dual stack
• Welk protocol gebruikt moet worden tussen twee hosts wordt bepaald door de DNS server (denk A of AAAA records)

Er zullen ongetwijfeld praktische verschillen zijn, maar feit is dat IPv4 adressen nu echt bijna op zijn. Linksom of rechtsom moet er iets gebeuren en de keuze is destijds gemaakt om IPv6 te gebruiken. IPv6 heeft een eigen set problemen, en het had waarschijnlijk beter gekund maar ondertussen zitten we er aan vast. IPv4 nog verder oprekken d.m.v. CG-NAT of een andere nog uit te vinden techniek lijkt me niet handig, het kost je een hoop moeite en uiteindelijk loop je tegen hetzelfde probleem aan als waar we nu mee zitten. Dit gaat natuurlijk ook op voor een slechte IPv6 implementatie maar ik schat zo in dat IPv6 een stuk beter houdbaar is dan elke IPv4 workaround die nu beschikbaar is.

[Verwijderd]

maar feit is dat IPv4 adressen nu echt bijna op zijn. Linksom of rechtsom moet er iets gebeuren en de keuze is destijds gemaakt om IPv6 te gebruiken. IPv6 heeft een eigen set problemen, en het had waarschijnlijk beter gekund maar ondertussen zitten we er aan vast.

Mee eens.
De discussie hier is: was het niet beter geweest als IPv6 ontworpen was geweest met IPv4-IPv6 translatie. En niet alleen met dual stack. Ik denk van wel. Het had imho de transitie makkelijker gemaakt.

[Verwijderd]

Iedereen is gek, behalve jij?

Er zijn keuzes gemaakt die je misschien zelf anders had gezien. Echter om te zeggen dat IPv6 mislukt is is ook wat. Comcast, Facebook, Google, Telenet, Linkedin hebben allemaal managers en techneuten die het niet snappen en derhalve toch IPv6 hebben ingevoerd, waarbij zelfs diverse partijen IPv6 only.

Dat IPv6 misschien niet is geworden wat jij ervan had verwacht/gehoopt maakt het niet iets inherent slecht.

Even daargelaten wat het zou/kunnen/had moeten zijn, zullen we dan maar meer en meer systemen achter een IPv4 CGN gaan hangen, wordt het internet daar beter van?

Bij IPv6 zijn er ook wat NAT64/DNS64 oplossingen nodig, maar deze nemen af naarmate meer mensen IPv6 access hebben. Bij Ipv4 CGN worden problemen naar verloop van tijd groter.

[Verwijderd]

Iedereen is gek, behalve jij?

Er zijn keuzes gemaakt die je misschien zelf anders had gezien. Echter om te zeggen dat IPv6 mislukt is is ook wat.

Heb je mij horen zeggen dat IPv6 mislukt is ? Nee.
Hoor je mij zeggen dat IPv6 er nooit komt ? Nee.
Hoor je mij zeggen dat IPv6 slechter is dan IPv4 ?
Nee.

Het enige wat ik hier zeg is:
1) niemand weet hoe lang het nog gaat duren voor de meerderheid van het net is overgestapt op IPv6. Kan 2 jaar duren. Kan 10 jaar duren.

2) IPv6 heeft geen relevante voordelen boven IPv4. Behalve meer adressen. De veranderingen die er zijn, zijn klein. Er zijn geen verbeteringen voor routing op grote schaal.
http://blog.ipspace.net/2010/02/ipv6-myths.html

3) Het feit dat er geen echte voordelen zijn (technisch en financieel) heeft een hele grote, en hele negatieve impact gehad op de adaptatie van IPv6.

4) Het feit dat de IPv6 community express geen backwards-compatability wilde, heeft het probleem waarschijnlijk alleen maar verergerd.

En nee, ik denk niet dat ik hier alleen in sta.

[flabber]

1) niemand weet hoe lang het nog gaat duren voor de meerderheid van het net is overgestapt op IPv6. Kan 2 jaar duren. Kan 10 jaar duren.

Correct.
Niemand weet het, maar persoonlijk ben ik meer van de 2 dan de tien jaar. Het feit dat niemand het weet is echter nooit een goed argument, in welke discussie dan ook.
Niemand weet wanneer de olie op is, of kanker echt uitgebannen kan worden. Moeten we daarom maar achterover leunen en doen met de middelen die we nu hebben?

2) IPv6 heeft geen relevante voordelen boven IPv4. Behalve meer adressen. De veranderingen die er zijn, zijn klein. Er zijn geen verbeteringen voor routing op grote schaal.

IPv6 had veel technische voordelen boven IPv4.
Maar in plaats van IPv6 te omarmen heeft de industrie besloten (bijna) al die voordelen uit IPv6 over te nemen en te backporten naar IPv4.
Blijkbaar vonden de ontwikkelaars/industrie/gebruikers dat IPv6 daadwerkelijk ideeen bevatte die dusdanig grote voordelen hadden dat men besloten heeft om het over te nemen.
Dat deze ontwikkelingen ervoor gezorgd hebben dat IPv4 steeds meer op IPv6 is gaan lijken, neemt niet weg dat IPv6, op het moment van ontstaan, veel verbeteringen bracht.

3) Het feit dat er geen echte voordelen zijn (technisch en financieel) heeft een hele grote, en hele negatieve impact gehad op de adaptatie van IPv6.

Technisch zijn we het duidelijk niet met elkaar eens, financieel wel, helaas.
Mijns inziens heeft de industrie steeds gekeken wat voordeliger was: overstappen naar IPv6 of het oplossen van problemen met IPv4.
En daardoor is de meerwaarde van IPv6 steeds verder uitgehold waardoor de keuze voor patchen steeds eenvoudiger werd.

4) Het feit dat de IPv6 community express geen backwards-compatability wilde, heeft het probleem waarschijnlijk alleen maar verergerd.

Backward compatability is geen heilige graal.
IPv4 was in totaal niet backward compatible met eerdere netwerk protocollen; moeten we het daarom nu alsnog in de ban doen?
Levert het problemen op? Uiteraard, maar dat was twintig jaar geleden ook het geval met netwerken die niet met elkaar konden communiceren. Toendertijd was dat ook geen onoverkomelijk probleem. Sterker nog, menig groot bedrijf dat de afgelopen jaren weinig haast maakte met IPv6 hebben juist in de 'begintijd' van internet als TCP/IP(v4) netwerk een enorme spurt gemaakt.

[mdavids]

1) niemand weet hoe lang het nog gaat duren voor de meerderheid van het net is overgestapt op IPv6.

Dat valt nog te bezien. De laatste paar jaar verdubbeld het gebruik van IPv6 zich jaarlijks en raken we nog dit jaar waarschijnlijk een wereldwijd gemiddelde van 8%.

Dus als deze trend doorzet, zouden nog ruwweg 4 jaar nodig hebben voor 100% (hoewel die laatste loodjes natuurlijk het zwaarst wegen). Maar pak 'm beet in 2019 ben je volgens mij wel een enorme looser als je alleen nog maar IPv4 doet hoor. De cijfers spreken wat dat betreft duidelijke taal.

[ReneX]

Niet selectief quoten, dual stack is een prima methode (en niet alleen bij IPvX gebruikt) maar ik geef ook aan dat er andere redenen zijn waarom het een probleem is.

Het niet erg realistisch om een compatibiliteit te verwachten van IPv6 naar IPv4 (routering, mapping ..etc.). Wat niet onlogisch is, is het idee dat je een tijdlang 2 protocollen naast elkaar laat bestaan om de overgang makkelijker te maken. Dat providers te beroerd zijn dat te doen is het echte probleem (het opraken van IPv4 adressen was 1 van de drijfveren achter IPv6 20!! jaar terug).

De oplossing voor het probleem ligt al heel lang op de plank, en je kan de IPv6 standaard er niet verantwoordelijk voor houden dat deze niet al lang gemeengoed is. (Tenslotte heeft men met een transitie periode rekening gehouden!)

[BitProcessor]

IPv6-only kan niet met IPv4-only communiceren zeg je ?
Heb je ooit NAT64/DNS64 getest? Dat werkt anders best aardig?
Toegegeven, je hebt "ergens" een NAT64 Gateway nodig met 1 IPv4 adres, maar dan kan je hele IPv6-only netwerk communiceren met IPv4 only netwerken.

Maakt het deel uit van de standaard: nee
Werkt het: ja

Is het iets van je wil: wellicht niet

Verder heb je gelijk: er is was geen enkel technisch / noch economisch voordeel voor het overstappen op IPv6.

[The Zep Man]

Backwards compatibiliteit is niet altijd even handig te realiseren. Je gaat er dan vanuit dat IPv4 apparatuur ook tegen IPv6 moeten kunnen ... (Je zou dan altijd ergens een mapping van IPv4 naar IPv6 moeten hebben voor v4 clients naar v6 servers en v.v.).

Een IPv6 client kan nu met een IPv4 server verbinding maken via verschillende oplossingen. Andersom kan inderdaad niet, maar dat hoeft ook niet.

Wat je dan kan doen is voor elke nieuwe verbinding alleen een blok IPv6 adressen uitdelen. Op verzoek van de eigenaar van de verbinding kan je alsnog een enkel IPv4 adres toekennen, die op het eindpunt met dual stack bruikbaar is om ook IPv4 services te hosten. Reken er maar op dat 99,9% van de gebruikers hier geen gebruik van zal maken en dat er dus zat IPv4 adressen overblijven voor die enkelingen die echt iets op IPv4 willen hosten.

[Reactie gewijzigd door The Zep Man op 26 juli 2024 07:31]

[Jheroun]

IPv6 kan de ontwikkelingen die jij noemt nog steeds krijgen, het protocol staat niet stil.

Backwards compatibility is niet nodig, hosts kunnen al jaren v4 en v6 gewoon naast elkaar draaien zodat een meer geleidelijke overgang mogelijk is.

Als je stappen wilt zetten moet je soms de legacy loslaten.

[Verwijderd]

IPv6 kan de ontwikkelingen die jij noemt nog steeds krijgen, het protocol staat niet stil.

Er zijn allerlei ontwikkelingen op netwerk gebied. MPLS, overlay networks, SDN. Maar niet op het gebied van IPv6 zelf. Layer-3, de netwerk-laag. Die is al 20 jaar hetzelfde. Kun je me een RFC aanwijzen waar iets substantieels nieuws in wordt vermeld ?

Dit is een oud voorstel om IPv6 te veranderen. Uit 1996. 8+8. Van Mike O'Dell, de CTO van de grootste ISP ter wereld in die tijd (UUnet).
http://www.potaroo.net/ietf/all-ids/draft-odell-8+8-00.txt
Vele IPv4 routing experts vonden het een goed voorstel. Met 8+8 krijg je locator-identifier separation. Waar je weer site-multihoming kunt maken. En makkelijkere renumbering. Werd compleet afgeschoten door de IPv6 community.

Als je stappen wilt zetten moet je soms de legacy loslaten.

Had de IPv6 community de legacy maar echt losgelaten. Maar dat wilden ze niet. Ze wilden precies IPv4, maar dan met grotere adressen. Niks meer. En dat was een grote fout, blijkt nu de laatste 10-15 jaar.

Edit: oops. Vergeten link naar 8+8 te vermelden.
http://www.potaroo.net/ietf/all-ids/draft-odell-8+8-00.txt

[Reactie gewijzigd door Verwijderd op 26 juli 2024 07:31]

[Jheroun]

Dat laatste is natuurlijk wat anders dan zeggen dat backwards compatibility nodig was. Dan stel je eerder dat ze een nog veel grotere sprong hadden moeten maken, daar ben ik het wel mee eens, zeker gelet op de trage adaptatie had het allemaal stukken verder kunnen gaan.

Ik moet toegeven dat de laatste keer dat ik in de echte details van v6 ben gedoken zeker 10 jaar geleden is maar ontwikkelingen zijn er toch wel, er zijn wel workgroups met dingen bezig. Of daar iets substantieel nieuws in zit weet ik niet, ik ben er niet in detail ingedoken

Maar ja, zolang het niet hoeft gaan veel bedrijven gewoon uberhaupt niet over, een mens is toch een gewoontedier. Overigens is de adaptatie langzaam op gang aan het komen. Voor Google is nu iets van 6% v6 verkeer, dat is stukken meer dan pakweg 5 jaar geleden het geval was. Ik betwijfel of we nu meer echt v6 verkeer zouden hebben als het protocol backwards compatible was, volgens mij was het dual stack concept dan in het protocol gepropt in plaats van aan de host overgelaten.

[Verwijderd]

Dat laatste is natuurlijk wat anders dan zeggen dat backwards compatibility nodig was.

Klopt. De discussie hier ging over backward compatability. Dat zou imho geholpen hebben. Maar zodra het over IPv6 gaat, dan komen er mensen vertellen dat IPv6 zo geweldig is. "Want het heeft RD en SLAA! En het lost alle problemen op". Niet dus. Daar ga ik dan ook maar weer tegenin.

Of daar iets substantieel nieuws in zit weet ik niet, ik ben er niet in detail ingedoken

Ik ook niet. Ik ben al een tijdje "met vakantie". Als ik me in networking verdiep, dan is het in iets interessants. Zoals alle nieuwe SDN dingessen.
Ik lees wel geregeld: http://blog.ipspace.net/
Omdat Ivan heel helder schrijft. En geen marketing en pr onzin herhaalt. En weet ongelofelijk veel. Op IPSpace komen er geregeld verhalen over problemen met IPv6 langs.

Overigens is de adaptatie langzaam op gang aan het komen.

Ja. Ivan schijnt het ook te geloven.
http://blog.ipspace.net/2...-here-get-used-to-it.html

[CAPSLOCK2000]

Hoewel ik het met je eens ben dat IPv6 veel meer had kunnen zijn moet ik ook concluderen dat dit blijkbaar niet haalbaar was.

We hebben twintig jaar de tijd gehad om een protocol te ontwikkelen dat zo veel beter was iedereen het spontaan ging gebruiken.

Het enige wat een beetje in die buurt komt is NAT en dat is een nog kleinere vooruitgang dan IPv6. Maar het is wel (min of meer) backwardscompatible. Dus wat dat betreft lijk je gelijk te hebben.

[Reactie gewijzigd door CAPSLOCK2000 op 26 juli 2024 07:31]

[Alex3]

Als IPv6 direct was ingevoerd toen het klaar was zouden de kosten veel lager zijn geweest dan nu, nu bijna iedereen internet heeft. Het probleem is dat het niet lonend is om als eerste over te stappen; wat je implementeert blijft ongebruikt zolang anderen niet overgestapt zijn, dus iedereen wacht op elkaar.

[e_balk]

Je hebt deze reactie behoorlijk aangepast en nu kan ik me veel beter vinden in je reactie over de gebreken van IPv6.

Het enige echt grote voordeel van IPv6 is inderdaad de veel bredere adresruimte en dat er missers mee gemaakt zijn moge ook duidelijk zijn uit het gebrek aan implementatie.

Het probleem is nu overigens wel, dat het een standaard is en de enige standaard die beschikbaar is om het probleem van het opraken van IPv4 adressen aan te pakken, want lang gaan we het daar niet meer mee volhouden, de rek is er nu echt wel uit.

Ze kunnen niet in deze korte tijd weer een nieuwe standaard opstellen en uitrollen. Dus het lijkt erop dat we het toch met IPv6 zullen moeten gaan doen en dat daarbij kansen gemist zijn is jammer, maar goed wie weet bied IPv7 of 8 of 24 ofzo in de toekomst wel ruimte, backward compatibility zullen ze vast niet nog een keer zomaar overslaan.

[Verwijderd]

Ik dacht niet dat ik mijn posts op deze pagina heb aangepast. Ik heb enkel (vrij veel:)) extra posts gemaakt om mijn standpunt uit te leggen.

Er is iets als ILNP. Identifier/Locator Network Protocol.
Hopelijk dat dat meer en meer toegepast gaat worden in IPv6. Met de grotere adressen, en mogelijkheid tot header-stacking, zou dat makkelijker moeten kunnen in IPv6 dan in IPv4.

Aan de ene kant lees ik dat de IRTF ILNP al een paar jaar aanraadt. Aan de andere kant zag ik dit filmpje: https://www.youtube.com/watch?v=oPKQli3NBTI Hannes Gredler (van Juniper) die erg enthousiast lijkt over ILNP. Misschien is er toch hoop voor IPv6.

[e_balk]

Gelukkig maar een beetje hoop kunnen we wel gebruiken

[Caelestis]

Het is niet dat ze gekant waren tegen backward-compatability maar een inschattings fout hebben gemaakt over hoe het netwerk gefaseerd overgeschakeld zou worden van ipv4 naar ipv6.
Het idee was van het begin al geweest om dual stack draaiend te hebben en over tijd het ipv4 apparatuur te upgraden of schakelen naar ipv6.
Ze had echter geen rekening gehouden met apparatuur wat nooit de upgrade zou kunnen hebben en simpelweg niet binnen een redelijk termijn vervangen zou worden.
Dus ja ze hebben een aardig grote fout gemaakt door een instelling te hebben dat ipv6 het ipv4 protocol compleet vervangt en niet samen als 1 netwerk verder zou gaan.
Aan de andere kant het probleem speelt al dusdanig zo lang dat je net zoveel schuld kan neerleggen bij de fabrikanten van apparatuur en netwerk architecten dat ze zo dom zijn geweest om zichzelf vast te zetten in het ipv4 protocol terwijl ze van het begin af aan al wisten hoe het ipv6 geïmplementeerd zou worden.

[Verwijderd]

Volgens mij is IPv6 een mengemoes van IPv4 en MAc adres.

Want bij IPV6 kan je toch gegevens achterhalen wat je ook bij MAc adres kan (merk/type device bijvoorbeeld).

Dat het niet backwards compatible is is niet zo erg, ik vind het vreemd dat men maar IPv4 blijft gebruiken.

[flabber]

IPv6 biedt een mogelijkheid tot autoconfiguratie waarbij je IPv6 adres gedeeltelijk wordt bepaald aan de hand van je MAC adres.
Dit is een mogelijkheid die je wel of niet kan gebruiken.
Door de enorme hoeveelheid IP adressen id het mogelijk om zo unieke adressen te genereren binnen je eigen IP reeks (/48of /64 bv).
Dit kan makkelijker zijn, in sommige gevallen.
Maar het staat eigenlijk los van wat IPv6 is; in Windows wordt een soortgelijke vorm van autoconfiguratie ook al gedaan met de bekende 196.254.x.x reeks, maar dan iets inder mooi...

[Verwijderd]

Volgens mij is IPv6 een mengemoes van IPv4 en MAc adres.

Volgens mij is IPv6 turqoise. En smaakt een beetje naar kaneel.

Sorry. Maar misschien moest je je eerst een beetje inlezen in de materie.

[Blokker_1999]

Alleen had je dan je protocol vol met legacy meuk moeten steken waardoor je buiten het vergroten van de adres lengte eigenlijk weinig andere aanpassingen zou hebben kunnen maken. Aanzie het zoals 64bit CPUs die vandaag ook nog altijd in 32bit kunnen werken. Heel leuk omdat de omschakeling zo rustig en zonder problemen kan verlopen, maar we blijven wel in een situatie zitten waarin developers werk dubbel moeten blijven doen om maximale perfirmantie te kunnen garanderen op beide platformen.

[Verwijderd]

En hoeveel problemen levert dat dan eigenlijk tegenwoordig? Ik zou zeggen dat we juist lekker eenvoudig de overstap naar 64bit aan het maken zijn. Mag dan ietsje meer werk voor developers kosten, maar de overstap wordt ten minste gemaakt! IPv6 bestaat al 20 jaar, en nog steeds gebruikt geen hond het!

[Jheroun]

Totaal mee oneens. Ipv6 is juist doordacht doordat het NIET backwards compatible is. Als je wilt verbeteren moet je ooit stoppen met evolueren (opties op IPv4 bijbouwen) en een revolutie doorgaan (introductie IPv6).

Die dual mode waar je het over hebt is er al en werkt prima, maar dan niet in het IP protocol zelf maar doordat het systeem dat de IP stack gebuikt beide stacks tegelijk kan gebruiken. Dat is iets dat door zo'n beetje alle systemen en appliances ondersteund wordt.

[Verwijderd]

Totaal mee oneens. Ipv6 is juist doordacht doordat het NIET backwards compatible is. Als je wilt verbeteren moet je ooit stoppen met evolueren (opties op IPv4 bijbouwen) en een revolutie doorgaan (introductie IPv6).

Het probleem is juist dat IPv6 *geen* revolutie was. Het is precies hetzelfde als IPv4. Alleen meer adressen. Zonder enige verbetering. Daarom ziet niemand er (financieel of technisch) voordeel in. En daarom wordt het zo langzaam geaccepteerd.

Die dual mode waar je het over hebt is er al en werkt prima ...

Niet dus. Anders waren we allang over geweest.
Deze discussie begon omdat zalazar hiet in deze comments aangaf dat ze IPv6 juist wel backwards compatible hadden moeten maken. Er waren genoeg mensen in 1992-1995 die dat ook vonden. Maar de IPv6-community wilde per se geen backwards compatibility. En dat bleek een grote fout te zijn.

[Jheroun]

Wat is het probleem met dual stack op een host dan? Of is je stelling dat we verder waren geweest als de dual stack vanuit het protocol zelf werd verzorgd en niet door de host moest worden geregeld?

[Verwijderd]

Het probleem is nu dat IPv4-only niet met IPv6-only kan praten.

Er zijn apparaten die IPv4 naar IPv6 kunt converteren. Een soort NAT. NAT64 heet dat. Echter, er zijn allerlei beperkingen. Je kunt het niet op grote schaal gebruiken. Bv het was mooi geweest als je gewoon IPv4-only en IPv6-only hosts op een netwerk zou hebben kunnen aansluiten. En dat dan de routers en/of speciale NAT-apparaten er voor gezorgd zouden hebben dat alles gewoon met elkaar had kunnen praten.

Dat had gekund. Maar dan had je daar rekening mee moeten houden in het originele design van IPv6. Bv hoe je addressen ontwerpt. Maar dat is niet gebeurd. Expres. En dat heeft de introductie van IPv6 meer benadeelt dan bevoordeelt.

[Verwijderd]

Dat kan wel met SIIT-DC waarbij je IPV6 only netwerk kan gebruiken en op IPv4 diensten kan aanbieden aan je edge.

Dan wordt stateless IPv4 traffic naar IPv6 hosts omgezet. Mocht er software op je IPv6 only host zijn dat nog IPv4 nodig hebt, dan komt er op het OS nog een stukje vertaling bij 464xlat.

Het is niet erg mooi, maar werkt in veel gevallen wel. Niet als er IP literals worden gebruikt maarja, a perfect world is not there. IPv4 en NAT heeft ook zijn dingen.

Positief punt is wel dat het nu een "hack" is om dingen te laten werken maar dat deze tzt wel verdwijnt waarbij nu met IPv4 meer hacks nodig zijn om het te laten werken en dit alleen maar complexer wordt in de toekomst.

[Mijzelf]

Mijn netwerk kan zowel IPv4 als IPv6 afhandelen. Voor zover ik weet is op alle relevante plaatsen dual-stack geïmplementeerd. Waarom zou een enkele stack met 'dual mode' eenvoudiger zijn?

[Verwijderd]

Het gaat niet om de stack op *jouw* apparaten.
Het gaat erom dat als IPv6 backward compatable was geweest, dan had de conversie ergens anders in "het netwerk" kunnen gebeuren. Bv door je ISP. Dan hadden IPv4-only en IPv6-only machines met elkaar kunnen praten.

[Mijzelf]

Hoe stel je je dat voor? Ik kan me geen enkele IPv6 implementatie voorstellen waar ik vanuit een IPv4 apparaat een willekeurig IPv6 adres kan aanspreken. De adresruimte is te klein. Dus zou je een soort mapping tabel moeten bijhouden, waarbij je IPv6 adressen in de ongebruikte ruimte van de IPv4 adresruimte mapt.
Als IPv6 de initiator is, kan ik me er nog iets bij voorstellen. Maar hoe zou een IPv4 client ooit een willekeurig IPv6 adres aan kunnen spreken zonder eerst op de een of andere manier de mapping te regelen?

[Verwijderd]

Daar heb je helemaal gelijk in. Je hebt apparaten nodig die de mapping doen. Ik kan/ga hier nu geen gedetailleerde technische tekst schrijven. Het is zowiezo jaren geleden dat ik er naar gekeken heb. Maar ik kan me herinneren dat er "kleine dingetjes" zijn die ze hadden kunnen doen, om het makkelijker te maken om die "mapping-machines" te maken.

[Compizfox]

Heeft het wel zin om zoiets backwards compatible te maken? Het lijkt me dat je daar alleen iets aan hebt als systemen die IPv6 ondersteunen, geen IPv4 ondersteunen. En dat is absoluut niet het geval: bij alle systemen die IPv6 ondersteunen, gaat het nu (nog) om dual-stack.

Het probleem is juist dat een heleboel systemen niet over IPv6 bereikbaar zijn, maar IPv4 only zijn. Dat soort mensen moeten eens eventjes heel snel IPv6 gaan implementeren. IPv4 kun je er dan gewoon bij houden hoor, het is niet dat je IPv4 moet afschaffen zodra je IPv6 support hebt op je machines.

[Johan9711]

Jazeker, echter dan moeten wel eerst alle ISP's bedrijven, etc over op IPV6, en daar hebben ze nog niet bijzonder veel trek in.

[JAVE]

Net als het milleniumprobleem destijds: We steken onze kop in het zand totdat het niet anders meer kan.

IPv6 bestaat al heel lang, het is al langer bekend hoeveel IPv4 adressen er zijn, en hoe snel ze opraken met het huidige tempo van uitgifte.

En nu maar klagen dat het zoveel werk is/zoveel kost om plotseling over te gaan op IPv6.

[Jaco69]

millenniumprobleem? Dat heeft zich toch nooit gematerialiseerd?
De schrikkelseconde laatst gaf meer problemen.

[JAVE]

Je moest eens weten hoeveel geld & manuren erin gestoken zijn zodat er uiteindelijk geen problemen waren...

Dat was overigens wel frustrerend. Hebben we ons werk zo zo goed gedaan dat het zo goed als foutloos loopt, gaat iedereen vervolgens mekken dat er zoveel geld aan gespendeerd is, en 'alles ging toch goed?'

JA, DOORDAT ER ZOVEEL GELD AAN GESPENDEERD IS!

Disclaimer: Ik heb zowel aan het milleniumprobleem als aan de euroconversie gewerkt, dus het raakt me persoonlijk als iemand vindt dat het een storm in een glas water was.

[Jaco69]

Disclaimer: Ik heb zowel aan het millenniumprobleem als aan de euroconversie gewerkt, dus het raakt me persoonlijk als iemand vindt dat het een storm in een glas water was.

En met jouw vele anderen. ik heb zelf ook aan het millenniumprobleem gewerkt (en aan verdiend). Zelfs nadat er lang van tevoren al naar gekeken werd, alles succesvol getest en we eigenlijk al 100% zeker wisten dat er geen probleem was hebben duizenden mensen die nacht gewerkt en nog veel meer standby gestaan. Dat had best wat minder gekund.

[Mizgala28]

Het zijn helaas meestal de mensen die de nachten destijds gewoon in hun bed lagen, terwijl er ook mensen waren die hele nacht doorwerkten om shit te voorkomen.

Niemand die even nadenkt dat het niet oplossen en veel geld aan spenderen veel problemen op zou leveren en NOG meer geld zou kosten.

[CAPSLOCK2000]

Het is nooit te controleren hoe groot het probleem nu echt was maar er is destijds enorm veel werk verzet om overal te verhelpen.
De meeste systemen waren het ongetwijfeld blijven doen en van de systemen die wel stuk gingen waren de meeste waarschijnlijk niet belangrijk genoeg om echt pijn te doen.

We zullen nooit weten hoe het was gegaan als we niks hadden gedaan.

[JAVE]

Als je een huurhuis had rond de eeuwwisseling, dan kan ik je garanderen dat er een hoop problemen waren geweest als er niets aan gedaan was.

De problemen waren het grootst in systemen die in COBOL waren geschreven.
En laten dat nu net zo'n beetje alle grote financiele systemen zijn...

De spookverhalen dat de stroom zou uitvallen, of dat er geen water uit de kraan zou komen waren onzin, maar zonder heel veel werk van de programmeurs zouden er wel problemen zijn geweest met je spaargeld, en je hypotheek, en je huur, en je verzekeringen...

[Verwijderd]

En niet vergeten alle websites en internet diensten

[SuperDre]

helaas genoeg apparatuur dat men heeft die niet overweg kan met ipv6...

[calvinturbo]

Dat lijkt helaas iets menselijks. We doen pas iets als we er zichtbaar last van hebben, dus eigenlijk op het laatste moment.

[Verwijderd]

Efficiency heet dat

[Brummetje]

Nee precies op tijd iets doet is efficiency... Want op het laatste moment (als het al te laat is) iets doen brengt alleen maar extra kosten/werk en dat is ver van efficient

[Verwijderd]

Op tijd.
Het probleem is alleen dat niemand weet wanneer "op tijd" is.

Ik heb 10 of zelfs 15 jaar geleden genoeg mensen zien huilen en janken, dat iedereen nu echt direct met IPv6 moest beginnen. Anders zou het Internet er echt heel direct meer op houden.
Het Internet werkt nog steeds.

Mijn voorspelling is: als je niet op IPv6 overstapt, werkt het over 5 jaar nog. Misschien over 10 jaar ook nog wel. Uitstel = uitstel van kosten. Tot nu toe was afwachten financieel gunstiger dan proberen vooraan te lopen.

[Compizfox]

Nee, dat heet uitstellen. Je krijgt er juist een heleboel problemen mee straks als IPv4-ruimte steeds schaarser (en duurder) wordt terwijl IPv6 nog niet wijdverspreid genoeg is.

[TimMer]

Nee, dat heet luiheid en een gebrek aan visie.

[3raser]

Het is voornamelijk het probleem van een ander, dus zijn we niet bereid om er moeite voor te doen. Want wat boeit het die webhoster nou dat er 2 mensen zijn die hun websites niet kunnen bezoeken? Maar als jij net 1 van die 2 mensen bent dan is het dus een heel groot probleem.
Iedereen hoopt stilletjes nog op een geleidelijke overgang. En dat zal waarschijnlijk ook wel gebeuren, maar de eerste gebruikers zullen wel 99% van alle ellende moeten incasseren.

[Snow_King]

Zie het een beetje positief, inmiddels zijn KPN en Ziggo ook aan de IPv6 uitrol begonnen.

ZeelandNet, XS4All en Solcon hebben al even IPv6, maar nog steeds is het weinig.

[Verwijderd]

Het lijkt een beetje op het olie-voorraad probleem. We blijven doorconsumeren terwijl aan alle kanten de alarmbellen afgaan. Maar er tijdig iets aan doen, ho maar. Het is jammer dat er altijd ergens tegen een muur aan gelopen moet worden, voordat er iets substantieels gebeurd (bijv. veiligheid).

Er is grote schaarste aan IPv4 adressen en daarom doet iedereen mee aan de overstap. Ik heb nooit alarmbellen horen rinkelen bij de professionals, die waren gewoon aan het werk om het op te lossen. Een pijnlijke maar noodzakelijke overstap maar niemand verwacht eigenlijk veel problemen.

En er is geen gebrek aan olie in de komende 50 jaar, wel zal de prijs oplopen als de makkelijk te ontginnen voorraden op zijn. De analogie loopt dan ook aan beide kanten spaak.

[SpoekGTi]

Behalve dat je amper kan schatten hoeveel olie er nog in de grond zit......dus je opmerking gaat mank. IPv4 adressen zijn te berekenen hoeveel je er hebt/had.

In de 70's was er ook een oliecrisis, de laatste keer dat ik checkte zijn we inmiddels 40 jaar verder en hoor ik niemand over een olie crisis en ik kan me niet voorstellen dat er minder verbruikt wordt.

Daarbij heb ik liever dat de IPv4 adressen op zijn dan de olie want dan hebben we serieuze shit. Ben het wel met je eens dat er met dingen te lang gewacht wordt

[RenaldoN]

Was die oliecrisis niet door de arabische wereld opzettelijk gecreëerd omdat de westerse wereld israel steunde in de jom kipoeroorlog ? Kan je niet vergelijken met echt opraken van de olie.

[Quilt]

Oliecrisis en peak oil waren leuke concepten die tot het begin van deze eeuw relevantie hadden. Maar vandaag is het probleem niet de voorraad aan fossiele brandstoffen, maar de capaciteit om de afvalstoffen (CO²) op te vangen.

Onze atmosfeer kan het niet (meer) aan.

De discussie over hoeveel olie/gas/kool er nog onder de grond zit (en tegen welke prijs we die boven kunnen halen), heeft is zijn relevantie aan het verliezen.
De hamvraag is nu: hoeveel van het goedje kunnen we opstoken zonder onszelf/het klimaat te veel pijn te kunnen doen.

Of om het plastisch uit te drukken: niet meer het kraantje, maar wel de afvoer.

[MSalters]

Er blijft sowieso een vraag naar olie los van de CO2 discussie. Het is namelijk ook een erg handige grondstof voor smeermiddelen en plastics. In de eerste oliecrisis heerste er nog een vrees dat ook die zouden opraken.

[laptopleon]

Ja, uiteraard er blijft voorlopig behoefte aan smeermiddelen en kunststoffen. Aardolie was decennia lang verreweg de goedkoopste grondstof daarvoor. Als je goedkoop het handigste vindt (en laten we wel zijn, daar draait het toch meestal om) dan was aardolie altijd het handigste. Aangezien er enorme investeringen in de productie gedaan werden en onze hele economie er op ingericht was, was er simpelweg ook geen keuze meer.

Maar als de olie schaarser wordt… daardoor uiteindelijk andere grondstoffen goedkoper worden… zal de vraag naar olie op lange termijn even hard opdrogen als de oliebronnen. Want koolstof zit niet alleen in aardolie. Sterker nog, aardolie is zelf 'gemaakt' van planten. Plantaardige grondstoffen zijn een prima vervanging voor aardolie.

Voorbeeldje: De Cosun (Nederlandse suikerbietentelers coöperatie) test op kleine schaal het maken van grondstof voor kunststof uit suiker. Technisch gezien geen probleem. In Brazilië doen ze al decennia hetzelfde maar dan met rietsuiker om alcohol als brandstof voor auto's te gebruiken.

Als je ook punten geeft voor nul risico op milieurampen, fijnstof of andere vervuiling, efficiëntie in productie, lokaal produceren / produceren waar vraag is, etc, dan valt er met de alternatieven heel wat te scoren en niet alleen qua CO2.

[Verwijderd]

"Daarbij heb ik liever dat de IPv4 adressen op zijn dan de olie want dan hebben we serieuze shit"

Ik zou liever hebben dat de olie vlug opraakt, want we zijn de planeet steeds verder aan het verknallen. IPv4 adressen die opraken dat is een 1st world problem.

[Verwijderd]

IPv4 adressen die opraken dat is een 1st world problem.

Want in de 2de en 3de wereld gebruiken ze al IPv6? Of omdat ze daar geen internet hebben? Kijk voor de grap eens hoeveel IPv4 blokken India heeft bijvoorbeeld.

[Maurits van Baerle]

Klopt. Het is eigenlijk juist niet een 1st World Problem, het is niet toevallig dat het uitgerekend Noord Amerika is die zo ongeveer als laatste door de IPv4 adressen heen is. Het grootste deel van de wereld is er al langer doorheen. Vooral in Azië is het IPv4 tekort al meer dan tien jaar erg nijpend.

[Verwijderd]

In landen met weinig infrastructuur is het wellicht makkelijker over te schakelen naar IPv6. Dat zie je ook in mobiele telefonie infrastructuur: die is dikwijls moderner in 2de en 3de wereld want recenter.

[Niemand_Anders]

Het opraken van de (aard) olie is primair ook een 1st world problem. Wij (de mensheid) doet ontzettend veel met ruwe aardolie. Brandstoffen (diesel, benzine, kerosine, etc) zijn misschien het meest belangrijk, maar de olie wordt ook gebruikt voor de productie van verschillende soorten kunststoffen en ook scheiden we olie in hun afzonderlijke componenten zoals parafinnen en bitumen (vooral bekend van dakbekleding) en asfalt..

Synthetische olien zijn helaas geen oplossing hier omdat hiervoor andere fossielen grondstoffen nodig zijn zoals bruinkool en steenkool. Voor andere synthetische olien kunnen ook gewassen (vooral zaden) worden gebruikt.

Producten gewonnen uit aardolie worden in de derde wereld niet zoveel gebruikt als in de westerse. Elektrische voertuigen beginnen nu pas eigenlijk een beetje rendabel te worden voor woon-werk verkeer. De transport sector zie ik nog niet snel overstappen op alternatieven van fossiele brandstoffen. Dat zonnevliegtuig had een nieuw record verbroken, alleen jammer dat het twee weken aan de grond moest blijven vanwege te veel wind. Ironisch genoeg zetten we windmolens ook stil als het te hard waait.

Zowel olie als internet is ontzettend belangrijk voor onze wereld. Beide houden ontzettend veel mensen aan het werk. En wat betreft het verknallen van onze aarde. Ook zonder olie zijn we daar ontzettend goed in..

[Verwijderd]

Dat olie mensen aan het werk houdt is een bullshit-argument natuurlijk. Er is geen reden om aan te nemen dat alternatieven minder mensen aan het werk zouden houden.

Olie wordt niet door alternatieven verdrongen omdat ze goedkoop te winnen is en niemand echt geeft om het teloor gaan van de aarde, blijkbaar, zolang we maar geld verdienen... Het ganse CO2-reductie verhaal is terug te brengen tot het stoppen met gigantische hoeveelheden fossiele brandstoffen uit de aarde te halen, al de rest is larie want wat we niet uit de aarde halen kunnen we ook niet verstoken.

Moest de olie van vandaag op morgen opraken: je zou zien hoe snel de alternatieven zich ontwikkelen en hoe dat leidt tot een economische boom! Je moet het eens opzoeken, maar er zijn verschillende studies te vinden die aantonen dat we de aardolie industrie overigens massaal subsidiëren, vele keren meer dan de alternatieven.

[Read]

Olie crisis 1973 had heel andere reden heeft niets met de vergelijking van jou te maken https://nl.wikipedia.org/wiki/Oliecrisis_van_1973

[HiBe]

moet je de volgende filmpjes maar eens bekijken... olie voorraad gaat eerder op dan verwacht :
https://www.youtube.com/watch?v=F-QA2rkpBSY

[FrankHe]

Een heel duidelijk op een uitstekende wijze vertelt. I love the video.

[mdavids]

In de 70's was er ook een oliecrisis, de laatste keer dat ik checkte zijn we inmiddels 40 jaar verder en hoor ik niemand over een olie crisis en ik kan me niet voorstellen dat er minder verbruikt wordt.

Heb je je ooit wel eens afgevraagd waarom al die windmolens geplaatst zijn in ons landschap, de laatste decennia? Die stonden er echt nog niet in de jaren '70 hoor.

[Verwijderd]

Websites worden tegenwoordig met zowel IPv4 als IPv6 uitgerold. Je moet IPv4 blijven gebruiken omdat er een sloot aan apparaten is dat heel IPv6 niet eens herkent.

[Verwijderd]

Ja maar die alarmbellen gaan nu toch al 5 jaar af en de planeet is nog niet geimplodeerd. Wanneer is tijdig ? Wat gaat er misgaan ? Dat een nieuwe ISP gedwongen op ipv6 moet ?

[matty___]

Het trouwens nog steeds zo dat enkele bedrijven volledige A netten hebben?

[CyBeR]

Ja, maar dat lost het probleem niet op en bovendien worden de netten van de paar bedrijven die /8's hebben (classes worden al sinds de jaren '90 niet gebruikt dus vergeet dat alsjeblieft) best nog ok ingezet.

[dasiro]

wat noem je "best nog ok" ? MIT, Ford, Halliburton, US Postal, Daimler zijn maar een paar namen waarvan ik absoluut zeker ben dat ze geen enkele meerwaarde bieden voor het globale internet, want er zijn duizenden, zoniet honderdduizenden sectorgenoten die het minstens even goed doen zonder.

[CyBeR]

Best ok als in, wordt gewoon prima benut. Al die bedrijven die je noemt hebben enorm uitgebreide netwerken.

[dasiro]

het is niet omdat je een groot bedrijf bent (ik gok dat je hun interne netwerkstructuur niet kent), dat je daarom het net/class ook goed benut.

[Z80]

bij Cisco hebben ze het nog steeds over classes.
dat de blokken nu verder versnipperd zijn en er met subnet notaties gewerkt wordt betekend niet dat de classes niet meer bestaan.

[CyBeR]

De enige classes die nog bestaan zijn D en E. De rest is compleet betekenisloos.

[DYX]

Ja, bedrijven als IBM en Apple hebben inderdaad een /8. Ik dacht ook Microsoft, maar die zie ik even niet in deze lijst staan.
Zie ook https://nl.wikipedia.org/...oegekende_IPv4_/8-blokken

[Maurits van Baerle]

Ja, alle adressen die met 15. of 16. beginnen zijn van HP bijvoorbeeld. Maar tenzij zo'n bedrijf failliet gaat en de adressen onderdeel worden van de failliete boedel die aan de hoogste bieder verkocht wordt heb je daar niet veel aan.

Voor bestaande bedrijven is het doorgaans veel te duur om hun hele netwerk om te gooien om wat blokken te kunnen verkopen. Het zijn immers doorgaans multinationals met zulke grote blokken, niet de bakker op de hoek.

Bovendien, het levert misschien voor een paar maanden aan adressen op en daarna zijn ze alweer op.

[Reactie gewijzigd door Maurits van Baerle op 26 juli 2024 07:31]

[CAPSLOCK2000]

Ja, maar ze teruggeven heeft eigenlijk geen zin. Dat is uitstel voor een paar weken of maanden maar daarna zitten we in hetzelfde schuitje als nu.

[gamezfreak]

Als IPv6 toch al een lange tijd bestaat, waarom is het dan niet volledig ingezet of op een manier gemaakt dat als er geen IPv4 adressen meer beschikbaar zijn dat het automatisch IPv6 adres gebruikt?
Als ik het mij nog goed kan herinneren, zei een docent van mij dat in China IPv6 nu wordt gebruikt wegens dat IPv4 al lang daar op is.

Dit lijkt meer op een kind die vlak voor de inleverdatum zijn werk begint te maken, rampzalig en nog niet eens te spreken over duidelijkheid.

Daarnaast heb ik ook weinig les gehad in IPv6, puur omdat het nog niet volledig is geïmplementeerd. Dat betekent dus straks dat de boeken herschreven moeten worden en dat het weer alles op last minute komt.

Ze wisten toch jaren geleden dat IPv4 op zou raken, waarom waren zij dan niet bezig geweest om IPv6 te implementeren?

[CAPSLOCK2000]

Ze wisten toch jaren geleden dat IPv4 op zou raken, waarom waren zij dan niet bezig geweest om IPv6 te implementeren?

In één woord: geld.

De meeste bedrijven stellen investeringen zo lang mogelijk uit en weigeren geld uit te geven als er geen direct voordeel aan zit. Als er dan eindelijk geinvesteerd wordt in iets nieuws dan kiezen ze bij voorkeur de goedkoopste en meest minimale oplossing. In deze context is dat NAT.

We stevenen nu af op de situatie dat organisaties grote kosten moeten gaan maken om hun oude spullen te kunnen blijven gebruiken of juist alles in één keer te moeten vervangen.

Het was beter geweest als er eerder was geinvesteerd om alle software en apparatuur stukje bij beetje geschikt te maken.

[Verwijderd]

Dat is natuurlijk een waarheid als een koe. Maar je moet toch wel een bijzonder antiek netwerk hebben wil je netwerkhardware daar anno 2015 nogsteeds niet mee om kunnen gaan.

[CAPSLOCK2000]

Ik ben bang dat er toch nog een hoop fabrikanten zijn die er niet vol voor gaan. Maar erger dan de netwerkapparatuur is de software. Er zijn nog heel veel programma's die "iets" met ip-adressen doen maar niet met IPv6 overweg kunnen. Daarnaast is er nog een hoop software die wel "iets" met IPv6 doet maar het toch niet helemaal heeft begrepen. Zo ken ik een programma waar je een ip-adres in een lijst moet opzoeken. Met IPv4 werkt dat wel omdat er meestal enkele honderden adressen zijn om uit te kiezen en zelden meer dan enkele tienduizenden. Dat is een paar pagina's vol adressen. Oner IPv6 heb je echter op z'n minst een paar miljard pagina's vol adressen om uit te kiezen. Dat werkt niet.
Het wordt steeds beter maar er is nog steeds een berg aan antiek.

[Compizfox]

Als IPv6 toch al een lange tijd bestaat, waarom is het dan niet volledig ingezet of op een manier gemaakt dat als er geen IPv4 adressen meer beschikbaar zijn dat het automatisch IPv6 adres gebruikt?

Dat kan niet zomaar. IPv6 is niet backwards compatible met IPv4, dus als je een computer alleen een IPv6-adres geeft, kan die computers geen andere computers op het internet bereiken die nog IPv4-only zijn (en dat zijn er helaas nog veel te veel, waaronder Tweakers zelf).

Je wilt dus een soort van periode hebben waarin de meeste computers/servers beide protocollen tegelijk ondersteunen (dual-stack). Pas als dan iedereen over is op IPv6, kun je IPv4 helemaal de deur uit doen.

[mdavids]

Als IPv6 toch al een lange tijd bestaat, waarom is het dan niet volledig ingezet

Heel simpel; omdat de tussentijdse, tijdelijke noodoplossing (NAT), tegen de verdrukking in veel beter bleek te werken dan de bedoeling was.

Leuk voor de ontwikkeling van het internet (die anders al jaren geleden piepend en krakend tot stilstand zou zijn gekomen), maar een beetje killing voor de deployment van IPv6.

[Verwijderd]

ARIN herinnert organisaties verder aan de overvloedige beschikbaarheid van de ipv6-adresruimte.

You don't say!
Probleem met IPv6 is natuurlijk de uitrol er van. Internetboeren als Ziggo zijn er nogsteeds niet aan. Dan wil zo'n bedrijf natuurlijk ook geen IPv6 adres want een dik vet deel van NL kan helemaal geen IPv6 adressen benaderen.
Als je de uitrol van IPv6 wil versnellen hoef je, denk ik, alleen maar in de telecomwet vast te leggen dat IPv6 MOET. Dat kan vast wel, gezien absurde data storage ook vereist kan worden in het kader van "nationale veiligheid".

[JJ Le Funk]

nieuws: Ziggo begint met uitrol van ipv6
uitrol is nog maar net gestart.
Ze zijn er idd laat mee.

[Reactie gewijzigd door JJ Le Funk op 26 juli 2024 07:31]

[Verwijderd]

Ik was me er van bewust dat Ziggo er (eindelijk) mee bezig was maar het is nog altijd niet een gevestigd feit. En dan geld dat ook nog alleen maar voor het Ziggo gebied.

[Verwijderd]

Als de providers ipv6 sneller zouden hebben geïmplementeerd zou er niets aan de hand zijn. Maar nee we blijven liever aan het oude vertrouwde vasthouden dan hoeven we niets te upgraden en blijft het geld als water binnenstromen zonder er iets voor te hoeven doen.

[CAPSLOCK2000]

Misschien hebben bepaalde grote providers het wel een prettig idee gevonden dat nieuwe concurrenten de markt niet kunnen betreden omdat ze niet genoeg IPv4-adressen kunnen krijgen. Je kan ze wel op kleine schaal kopen maar dat is toch weer een flinke investering.

[TERW_DAN]

Ergens is dit ook wel een beetje goed nieuws. Misschien dat er nu eindelijk een keer volledig IPv6 gedaan gaat worden en iedereen wel moet gaan upgraden.
Zolang de druk niet hoog genoeg is zullen we waarschijnlijk gewoon IPv4 blijven gebruiken.

[OddesE]

Ik moet weer even denken aan deze 'presentatie' van RIPE uit 2007:

The day the routers died

[CAPSLOCK2000]

Ik ben bijna blij dat het op is en er eindelijk een beetje schot in IPv6 begint te komen. Ik zou willen dat die migratie twintig jaar geleden al was afgerond want zo lang zijn we er al mee bezig. In die twintig jaar hadden we ook aan het volgende protocol kunnen werken. IPv6 is wel een vooruitgang ten opzichte van IPv4 maar het is een muizenstapje. We hadden veel verder kunnen zijn.

[Mizgala28]

Dit doet mij aan Windows XP denken, ondertussen draaien veel bedrijven nog op XP terwijl Windows Vista, 7, 8 en 8.1 uit zijn, en eind deze maand zelfs 10.

Maar nee, lekker doorgaan op XP, hetzelfde als dit.