Logius: alle overheidsdiensten moeten vanaf 31 december werken met ipv6

ICT-overheidsdienst Logius waarschuwt dat alle Nederlandse overheidssites en e-maildiensten vanaf 31 december bereikbaar moeten zijn via zowel ipv4 als ipv6. Overheidsinstellingen die vanaf 2022 geen gebruik maken van het protocol, zijn wellicht moeilijker bereikbaar.

Op een supportpagina schrijft Logius dat heel wat overheidsorganisaties de overstap naar ipv6 al gemaakt hebben en dat dit slechts een kleine actie vereist. Welke actie precies, wordt uitgelegd via instructies. Overheidsorganisaties die ondersteuning nodig hebben bij de overstap, kunnen dit op de website van Logius aanvragen.

In 2020 werd vastgelegd dat websites en e-maildiensten van alle Nederlandse overheidsorganisaties vanaf 31 december beschikbaar moesten zijn via zowel ipv4 als ipv6. Dit gebeurt voorlopig via het dual stack-principe: hiermee worden beide protocollen gehanteerd waardoor gebruikers via ipv4 of ipv6 verbinding kunnen maken met de internetdiensten van de overheidsorganisaties.

Het Forum Standaardisatie schrijft dat steeds meer consumenten van hun internetprovider een ipv6-adres krijgen toegewezen. Hierdoor wordt het volgens Logius voor overheidsorganisaties noodzakelijker om ook via het meer toekomstgerichte ipv6 bereikbaar te zijn. Als het niet lukt om voor 31 december ipv6 te implementeren, kunnen overheidsorganisaties een website gateway en een e-mail relay aanvragen. Hiermee wordt ipv4-verkeer vertaald naar ipv6-verkeer.

Dankzij ipv6 kunnen er heel wat meer internetadressen gegenereerd worden in vergelijking met ipv4. Eind 2019 deelde de RIPE NCC, de organisatie die ip-adressen in Europa, Rusland en West-Azië verdeelt, mee dat het de laatste nog beschikbare ipv4-adressen had uitgedeeld.

Door Jay Stout

Redacteur

04-11-2021 • 20:36

243

Reacties (243)

243
238
74
12
0
136

Sorteer op:

Weergave:

Ik ben er wel voor dat de overheid op deze manier probeert om iets te doen aan de verdere adoptie van IPv6. Zouden meer partijen moeten doen. Want het gaat helaas niet allemaal vanzelf. Er moet best veel geduwd en getrokken worden.

Inmiddels gaan we wel de goede kant op (al zou je dat niet zeggen als je hier leest hoeveel ISP's in Nederland nog achterblijven), maar er is nog een behoorlijke weg te gaan.

We mogen niet vergeten dat IPv4 al jaren aan het infuus ligt. De levensduur ervan wordt kunstmatig gerekt met bedenkelijke workarounds en hacks zoals NAT, STUN, TURN en ICE. Of, aan de server-zijde met de HTTP Host:-header en SNI. En de volgende generatie trucs is inmiddels ook al jaren een feit. Gezellig met je hele wijk, of met 10.000 andere mobiele-telefoonklanten achter 1 gedeeld IPv4-adres o.b.v. Carrier Grade NAT. Niet omdat het technologisch zo volmaakt is, maar eerder uit pure noodzaak.

Wie beweert dat IPv4 nog niet op is, gaat aan bovenstaande realiteit voorbij. Vier miljard IP-adressen (minus flink wat snijverlies) is nou eenmaal onvoldoende.

IPv4 bevindt zich wat mij betreft op een heilloze, doodlopende weg. Het einde is onvermijdelijk, denk ik. Of in elk geval zeer gewenst. Daarom is elk initiatief dat bijdraagt aan een versnelling van het transitie-proces welkom. Want hoe sneller IPv6 mainstream wordt, hoe beter het is.
NAT is geen hack, niet alles hoeft een eigen internet ip te hebben, bovendien is dat ook veiliger ondanks je het geen firrewall mag noemen kan een hacker niet zomaar bij je aankloppen want de router weet niet wat hij ermee moet doen(tenzij je DMZ of portforwarding instelt).

Mijn pc in het interne netwerk moet toch echt eerst een verzoek doen voordat de router iets terug communiceerd vanuit het internet naar mijn pc.

Michien ken je nog wel de worms van vroeger die je OS lieten crashen, als je zonder software firrewall het internet op ging met je USB ADSL modem of 56K modem was de kans groot dat je hem te pakken had, toen iedereen een router had met NAT was het opgelost, firrewalls zoals nu zaten er vroeger zeker nog niet op.

kwa beheer heb ik daarom ook liever dat mijn apparaten geen routeerbare ipv6 adres krijgen toegewezen omdat het lastiger te managen wordt, 1 foutje in de router config en je apparaten staan bloot op het internet, dat kan bij NAT op ipv4 niet zomaar gebeuren.

[Reactie gewijzigd door mr_evil08 op 24 juli 2024 04:12]

NAT is letterlijk een 'hack' geweest om het groeiende tekort van ipv4 in te perken...
Abstract

The two most compelling problems facing the IP Internet are IP
address depletion and scaling in routing. Long-term and short-term
solutions to these problems are being developed.
Dat is uit de originele NAT RFC1631 uit 1994.
De nieuwere, RFC3022, heeft zijn abstract daar op aangepast.

Verder, zoals je zelf zegt, is NAT geen firewall. Omdat ipv6 routeren minder moeite kost voor een router (je hebt geen sessies om bij te houden en een translatie te doen), zou het zelfs efficienter zijn. Je moet enkel je firewall goed instellen. Je kan ipv6 namelijk ook gewoon prima firewallen, het klinkt alleen eng.
Wie deelt dan eigenlijk de IP adressen uit als je geen NAT hebt en alles aan t internet hangt? Moet je dan bij je ISP zijn als je iets static wilt instellen? Dat zou wel een flinke achteruitgang zijn zo net na het afdwingen van vrije modemkeuze.

Ik dacht dat op dit moment je gewoon een ipv6 adres van de provider kreeg en daarachter (op je eigen netwerk) alles hetzelfde blijft, maar ik heb er zelf nog geen ervaring mee.
Ik heb het zelf privé nog niet werkend, gezien ik al 6 jaar op de uitrol van IPv6 op Ziggo wacht, maar de verwachte implementatie zal zijn dat je in plaats van 1 IP adres (zoals nu met IPv4) een subnet aan IPv6 adressen gaat ontvangen van de provider. Dit subnet kun je zelf weer uitdelen (vanaf de router, net als IPv4 met bijvoorbeeld DHCP) aan je lokale netwerk.

Wat dat betekent is dat de router die je krijgt daadwerkelijk alleen maar routing functionaliteit en een stuk firewalling gaat doen van WAN naar LAN, dus er kan dan standaard nog steeds niets naar binnen.
De enige functie die je kwijt raakt is NAT, voor de rest is alles hetzelfde.

[Reactie gewijzigd door drocona op 24 juli 2024 04:12]

Qua privacy ga je er toch behoorlijk op achteruit denk ik? Want volgens mij zijn ip adressen van ziggo op dit moment waardeloos qua opsporing/tracking, iets wat ik als iets positiefs zie.
Qua privacy is er (bijna) geen wijziging, het IPv6 subnet dat je toegewezen krijgt op de router zal net zo goed dynamisch zijn als het huidige IPv4 adres wat je ontvangt. Alleen bij IPv4 zie je dat al het verkeer van 1 IP komt en bij IPv6 dat het verkeer uit het subnet komt. De waarde van opsporing/tracking blijft dus hetzelfde in dat opzicht.

Het enige waar je over zou kunnen discussiëren is dat je aan de hand van het aantal gebruikte IPv6 adressen zou kunnen inschatten hoeveel apparaten er op het netwerk leven, maar dat is net zo waardeloos gezien een enkel apparaat ook (veel) grotere aantallen IP's kan gebruiken en je dus niet per definitie kunt zeggen dat 1 IP = 1 apparaat.
Gevoelsmatig is het toch bij IPv4 dat men slechts ziet dat er iets de voordeur uit komt en bij IPv6 je doodleuk achter de voordeur kunt kijken. Het lijkt me niet uitgesloten dat zeker wanneer een bepaald apparaat meerdere IPv6 adressen gebruikt, aan de hand van die combinatie achterhaald kan worden wel apparaat het betreft. En dat maakt wel kwetsbaarder, wanneer dat apparaat bekend staat wegens bekende bugs in de beveiliging.
Dat is inderdaad gevoelsmatig, alhoewel je een IPv6 adres ziet zegt dat niets over waar het leeft, alleen dat het op een bepaalde aansluiting zit.
Als je vervolgens gaat scannen of poorten gaat proberen te bereiken op een van die IPv6 adressen, zit daar net als bij IPv4 de firewall tussen en komt er niets zo maar op je lokale netwerk, verder dan de firewall op de router komt het dus niet.

NAT is geen beveiliging, de firewall is de beveiliging. Het verwijderen van NAT met IPv6 levert geen kwetsbaarheden op. Alles wordt nog steeds aan de deur gestopt (tenzij je de firewall open zet natuurlijk).
(tenzij je de firewall open zet natuurlijk)
Tenzij je je firewall niet dicht zet is een betere aanname. Nu zullen de meeste routers van ISP's standaard de firewall aan hebben staan. Maar als je zelf een router of linux host er neer zet dan kan zomaar standaard de IPv6 firewall voor forwarding wijd open staan. In dat opzicht was NAT altijd wel een fijn vangnet om te hebben (IPv4 forwarding op 1 adres werkt namelijk helemaal niet zonder NAT of port forwards, dus je moest wel je firewall in duiken om het mogelijk te maken).
Zolang je firewall netjes ingesteld staat (default instelling) is dat kwetsbare apparaat niet bereikbaar vanaf buitenaf.
Meeste ISPs die vandaag IPv6 subnets uitdelen doen dat statisch. Ik heb al enkele jaren dezelfde IPv6 prefix van mijn ISP en ik geloof dat dit ook de aanbeveling is vanuit standarisatie organisaties.

En of het verkeer nu van 1 adres komt met NAT of van een subnet maakt voor privacy niet zo heel veel uit. Je weet dat dat verkeer van dezelfde locatie afkomstig is.
Yes, goede toevoeging. Ik ging met mijn situatie van Ziggo in mijn hoofd door met het dynamische (gezien Ziggo geen statisch van plan is), uiteraard zijn er genoeg ISP's die het anders aan kunnen/zullen pakken met statisch.
Verder kan je nog ipv6 adressen uitdelen /configureren op 2 manieren : slaac, waarbij het cliënt device zelf een ip kiest (al dan niet gebaseerd op je mac adres - hangt af van de privacy extensions), of dhcpv6, waarbij je dan weer centraal gaat uitdelen.
Precies zoals je zegt gaat het. Jij (je router) krijgt een hele berg IPv6 adressen van je ISP, en deel je dan weer uit aan je apparaten in je LAN. Je router doet zorgen voor firewalling. En die ellendige NAT tabel hoeft niet bewaard te blijven. Stel je voor! Je openstaande SSH sessie blijft open terwijl je router reboot! Je hebt even wat packetloss, maar dat lost TCP wel weer op :)
Werkt net iets anders met IPV6. Ipv van dat de router adressen uitdeelt, deelt hij slechts de 'prefix' met de cliënten op het netwerk. De clients mogen dan zelf een op adres 'verzinnen'. Dit kan op 2 manieren. 1) op basis van Mac adres. 2) of random (iets beter voor de privacy). De clients onderling zorgen dat er geen dubbele ips adressen zijn.
Werkt net iets anders met IPv6.
Meestal wel maar 't kan beide.
DHCP kan op v6 maar wordt minder snel gebruikt omdat er betere manieren zijn.
rebooten van een router zal de sessie niet doen blijven staan na 3 minuten downtime.
Er zitten toch nog veel nadelen aan de huidige implementatie van zelf ipv6 adressen uitdelen. Zo is er geen ondersteuning voor hostnames in ipv6, dus je kunt computers niet meer bij hostname pingen etc, verschillende OS implementaties die bijvoorbeeld geen dhcp6 ondersteunen maar direct hun IP van de ISP willen halen en deze zie je dan dus niet terug in je locale lease lijst.

Al met al ben ik nog lang niet tevreden met hoe IPV6 werkt. Men had het best iets vriendelijker kunnen maken.
Kun je hier wat dieper op ingaan?
IPv4 heeft ook geen ondersteuning voor hostnames? Als je een hostname wil pingen dan is dat een DNS aangelegenheid en dat kan ook prima met IPv6 adressen (AAAA record), of bedoel je iets anders?

Ik begrijp ook niet helemaal wat je bedoelt met een IP direct van het internet/ISP halen, er is statisch, DHCPv6 en SLAAC, welke allemaal lokaal afgehandeld kunnen worden, hoe probeert iets een IP van het "internet" te halen? In het ergste geval komt een IPv6 adres in de routing table naar voren als het OS geen DHCPv6 gebruikt?
Over dat stukje dat je nog wacht op ipv6 van ziggo. Heb je de nieuwste modem? (Die witte, niet die zwarte/Cisco). Als je aangeeft dat je problemen hebt (gewoon wat verzinnen no worries). Krijg je een nieuwe en ik kreeg toen ook ipv6.
Die witte had ik gekregen met de overstap naar zakelijk giganet, maar die gaat over de zeik (kan de snelheid niet aan) en past daarnaast niet in een serverrack door de lompe vormgeving dus heb een vervangende gekregen die "zodra IPv6 beschikbaar wordt" Dual Stack IPv6 zou ondersteunen. Het modem wat ik heb is de volgende en voldoet qua specificaties overal aan: https://www.ziggo.nl/klan...ifi-modems/ubee-ubc1318zg

[Reactie gewijzigd door drocona op 24 juli 2024 04:12]

Knap dat ze een router verkopen die niet eens de snelheid aankan..
Vreemd dat ziggo voor oudere IPv6 capable routers het niet gewoon open gooit.
Bij Ziggo krijg je een /56 subnet, waarmee je dus 72 bits aan hosts kunt configureren. Dat zijn veel meer adressen dan er nu met IPv4 beschikbaar zijn (IPv4 is 32 bit, en IPv6 128 bit).
Elk apparaat op je netwerk krijgt volgens mij ook weer een subnet, waaruit Windows bijvoorbeeld meerdere ipadressen gebruikt om het internet op te gaan.
Bij Ziggo krijg je alleen IPv4 als je ziggo router in bridge modus staat. Werkende IPv6 in bridge mode is nog steeds niet geregeld
Volgens de Ziggo medewerker die ik gister heb gesproken is er eerder deze week een interne Ziggo memo over geweest. Functionele ipv6 in bridgemode schijnt er eindelijk aan te komen (DHCPv6-PD)
Dit klinkt interessant, weet iemand hier meer over?
Nee, ik had IPv4 zonder bridge modus. De enige reden dat ik bridge modus ging gebruiken is zodat ik mijn eigen router kon gebruiken rechtstreeks op het publieke IPv4 adres wat ik van Ziggo had.
En in UPC-gebied IPv6 krijgen met een IPv4 /29 er naast zit er ook nog niet in helaas.
Dit heb ik dus echt nooit begrijpen hè.
Waarom zou je als provider ooit aan particulieren zoveel IP adressen Geven dat je alsnog straks een keer tekort gaat komen.
Wanneer je kijkt naar kleinere bedrijfjes en individuen had je toch makkelijk afgekund met bijvoorbeeld een /96 En zelfs voor de wat grotere bedrijven een /64.
Er gaat dan geen tekort komen. Met IPv6 heb je 2^128 ipadressen. Met een /56 subnet heb je 2^72 mogelijke ipadressen binnen je subnet, en er zijn dan dus 2^56 mogelijke subnets die Ziggo uit kan geven.
Hoor je wat je zegt

Doordat ziggo het nog netjes doet kunnen zei voor elke freedom klant
250+ klanten aansluiten

Met een /96 kun je alsnog
Zo’n 4 miljard devices aansluiten Besef dat dat er aanzienlijk meer zijn dan een class B subnet

Als ik naar een gemiddeld huishouden kijk dan hebben die zo’n 50 lampen 30 media devices 10 keuken apparaten 10 radiatoren misschien nog smartlocks en bewegings sensoren etc kortom in het meest extreme scenario kom je niet eens in de buurt van 1000 devies

Zelfs als je voor iedere openstaande applicatie op je pc een uniek ip wilt kom je vermoedelijk niet in de buurt van 1000 ips sterker nog zelfs op een gemiddelde school met alle leerlingen en hun smartphones en chromebooks ha je moeite krijgen om de verhouding 1000ips per leerling te bereiken

Nu zeg ik niet dat je geen rekening moet houden met de toekomst maar meer dan een miljoen ip’s per huishouden haat in de komende 300 jaar wel genoeg zijn

En in mijn vorige bericht had ik het al over 4000x dat aantal

[Reactie gewijzigd door i-chat op 24 juli 2024 04:12]

Ik begrijp niet helemaal of je het nu met mij eens bent of niet. Ik zeg dat Ziggo 2^56 subnets uit kan geven, wat al meer subnets zijn dan het aantal ipadressen in IPv4. Binnen elk /56 subnet kun je 2^72 adressen uitdelen.
Als je die subnets kleiner maakt, bijvoorbeeld /96, dan heb je in elk subnet 2^32 ipadressen om uit te delen, wat inderdaad ook meer dan zat is (dit is het aantal ipadressen die mogelijk zijn met IPv4).
Andersom zou je zelfs met /33 of /34 subnets nog genoeg subnets kunnen uitdelen wereldwijd.

Kortom, wat ik al zei, een tekort zal er niet komen met /56 subnets.
Dat zeg je nu, maar wat als die 6mrd mensen op aarde straks allemaal op de westerse manier met internet worden verbonden
En meneer Musk er op mars ook nog een paar honderdmiljoen kwijt kan

Als dat allemaal 48s worden komen we langzaam aan toch nog aan z’n max

En dat terwijl er absoluut geen noodzaak voor was
6 miljard is maar een klein deel van de mogelijke adressen. Als ik het goed heb zijn er nu zo'n 7,7 miljard mensen op de aarde, en met /56 subnets heb je 72.057.594.037.927.936 mogelijke subnets van nog eens 4.722.366.482.869.645.213.696 ipadressen. Dat lijkt me toch wel genoeg voor de komende jaren.
Persoonlijk zou ik wel kleinere subnets gebruiken, maar er zal nog lang geen tekort zijn denk ik.
Je gaat uit van bestaande kennis en apparaten. Ik durf met droge ogen te beweren dat we blij mogen zijn als IPv6 over 100 jaar nog afdoende zal blijken want als één ding zeker is dan is het dat niks zeker is :+
Zoals dit? :+
https://xkcd.com/865/

[Reactie gewijzigd door hackerhater op 24 juli 2024 04:12]

Bij IPv4 krijg je van de provider 1 IP adres en daar moet je het mee doen. Het komt zelfs voor dat je bij de provider al achter een nat-router zit.

Bij IPv6 krijg je een heel subnet. Bij Freedom.com bijvoorbeeld een /48 subnet: https://freedom.nl/landin...edt-internet-tv-en-bellen
IPv6 bestaat uit twee delen als ik mij niet vergis. deel 1 is van de isp deel 2 uniek aan elk apparaat. Soort MAC adres achter het ip geplakt. Op deze manier is elk toestel identificeerbaar op het internet. Het is wel niet eenvoudig om je firewall correct in te stellen want het werkt compleet anders. Denk dat dit ook het probleem is. Het is gewoon niet gebruiksvriendelijk (gemaakt) voor de huis tuin en keuken gebruikers.
Ik heb al zo'n 6 jaar IPv6. Een deel van het mac-adres zit inderdaad in het IPv6-adres. Niet zo fraai, want zo ben je op internet te volgen. Maar misschien ligt dat aan mijn Fritzbox. Zowel mijn pc als de Fritzbox heeft een firewall, maar aan beide hoef ik niets in te stellen.
Als het goed is, ben je daartegen beschermd. Zo niet, moet je in je OS de privacy extensions aanzetten. Dat kan in zo'n beetje elk modern OS, al staat het op sommige slechtere implementaties nog wel eens standaard uit.

Mocht je netwerk om de een of andere reden niet SLAAC maar DHCPv6 gebruiken, dan moet je de privacy extensions aan de kant van de Fritz aanzetten. Als je DHCPv6 gebruikt, zal overigens je publieke IP waarschijnlijk ook niet door je MAC worden bepaald.

Met de privacy extensions wordt namelijk periodiek een willekeurig adres gegenereerd voor uitgaand verkeer, dat naast je vaste adres gebruikt kan worden (zelfs meerdere tegelijkertijd, zodat langlopende verbindingen goed blijven gaan!). Voor inkomend verkeer blijft je MAC-adres relevant, want dat vaste adres is heel handig als je dingen serveert (je wilt natuurlijk niet constant je firewall moeten aanpassen telkens als je PC een nieuw adres genereert).
IPv6 bestaat uit twee delen als ik mij niet vergis.
De grap is dat dit voor IPv4 (zonder NAT) niet anders is. Alleen dat weten heel veel mensen niet meer, omdat ze van de NAT-generatie zijn. :'(
Het werkt vrijwel identiek aan IPv4, alleen zonder NAT. Je firewall is er hierdoor juist veel simpeler op geworden.
Ligt er aan. Op ipv4 krijg je of een dhcp lease van je ISP, of je moet pppoe doen, en krijgt via framing je subscriber info (je ip address).

Dat laatste geldt ook voor ipv6 (pppoe), of de ISP doet dhcpv6, SLAAC, of je krijgt statisch iets toegewezen.
Vaak krijg je nu een /56 van je ISP, eigenlijk adviseert RIPE ISP's om een /48 uit te delen. Dan krijg je op je thuis modempje een /56 bijv, en intern doen je ipv6 clients vaak SLAAC.

Of de ISP heeft poep aan ipv6...
Wie deelt dan eigenlijk de IP adressen uit als je geen NAT hebt en alles aan t internet hangt?
Leuke vraag!

Je ISP geeft je een zogenaamde prefix, bijvoorbeeld een /56. Da's zeg maar een subnet, waarbinnen je zelf mag nummeren of verder mag subnetten zoals je dat zelf wilt (en geloof me; je gaat geen adressen tekort komen!). Veelgebruikt is SLAAC, waarbij je thuisrouter (CPE) de betreffende prefix 'annonceert' op het thuisnet, waarna elk device dat oppikt en er een suffix achter plakt om het adres compleet te maken (volgens een bepaalde methode om dubbele adressen te voorkomen, die ik je even zal besparen). Een andere manier is DHCPv6 - gewoon de IPv6-versie van DHCP. Maar je kunt ook gewoon statisch een adres kiezen.

[Reactie gewijzigd door mdavids op 24 juli 2024 04:12]

Je router krijgt of een /56 (zodat je elk seperate netwerk/VLAN van een /64 kan voorzien) of een /64 met een hele bulk aan adressen.

Je kan daar 1e van "pakken" (uit die range) en die static instellen.

Dingen forwarden op hostname (+DNS registratie intern) is natuurlijk veel beter in dit soort situaties.
Het is ook vrij eng… straks is elk apparaat op een netwerk uniek identificeerbaar dankzij een ipv6 adres voor een Google e.d. terwijl je je nu nog kunt mengen met andere gebruikers op een netwerk. IPv6 prima, maar dat elk apparaat naar buiten toe uniek identificeerbaar is? Lijkt mij onzinnig, onnodig en bovenal onwenselijk.

@hieronder zeker wel, maar die technieken, hoe leuk ook bedacht, lossen dit echt niet op. En als ik op een kantoornetwerk zit, is op basis van het ip geen onderscheid te maken tussen het verkeer.

[Reactie gewijzigd door mrdemc op 24 juli 2024 04:12]

Je hebt een keer ergens een klok horen luiden geloof ik, en toen maar een hoed zonder rand gekocht.
Hier hebben de heren meesters IPv6 al lang over nagedacht, het heet 'Privacy extension' RFC 4941. Krijg je elke x tijd gewoon een nieuw, vers, IP adres. Juist jou NAT adres is een goede kandidaat om te tracken!
Wat is "elke keer"? Elke keer als er een stroomstoring is geweest? De meeste IOT-spullen staan gewoon 24/7 aan.
Ik zou gewoon even inlezen in http://www.faqs.org/rfcs/rfc4941.html als je er echt om geeft.
Het is handig als je dan ook even een quote geeft die meteen duidelijkheid verschaft.

Anders ben ik genoodzaakt mezelf gelijk geven :+
Section 12 of [DHCPV6] discusses the use of DHCPv6 for the assignment and management of "temporary addresses", which are never renewed and provide the same property of temporary addresses described in this document with regards to the privacy concern.
Elke keer als je apparaat opnieuw verbinding maakt dus, zoals bij een verhuizing of een stroomstoring.

Daaronder hebben ze het over automatische randomization na verloop van tijd. Ik las "elke x" als "elke keer", maar je laat de quote aan mij over. O-)

Overigens hebben ze het over "Possible Approaches"?

[Reactie gewijzigd door Sando op 24 juli 2024 04:12]

DHCPv6 is dan ook verre van de standaardmanier om adressering te doen. De Privacy Extensions die in ieder OS sinds minstens Vista aan staan gaan vooral over SLAAC, waar je geen DHCP meer nodig hebt. Clients kiezen zelf een vast IP (om op te ontvangen, bijvoorbeeld handig als je een gameserver draait) en een of meer tijdelijke IP's om uitgaande verzoeken te doen. Hoeveel tijdelijke IP's tegelijkertijd actief zijn en hoe lang ze functioneren is in te stellen, dat kan een enkel IP zijn dat elke paar minuten verandert of honderden IP's tegelijkertijd.

Ik denk dat je DHCPv6 verkeerd begrepen hebt. De quote die je aanhaalt, zegt namelijk het tegenovergestelde van wat jij zegt. "Renew" betekent in deze specificatie "de server vragen om de lease te verlengen", niet "veranderen naar een nieuw IP". Ook op DHCPv4 is de renew hoe je je adres na het verlopen van de lease houdt, daarom moet je eerst een release en dan een renew uitvoeren in ipconfig om zeker te zijn dat je een ander adres krijgt. Volgens de standaard zou het adres hetzelfde moeten/kunnen zijn als het was na een renew, namelijk.
quote: RFC8415
To extend the preferred and valid lifetimes for the leases assigned
to the IAs and obtain new addresses or delegated prefixes for IAs,
the client sends a Renew message to the server from which the leases
were obtained; the Renew message includes IA options for the IAs
whose lease lifetimes are to be extended.
De quote die je noemt, zegt dus dat er tijdelijke IP-adressen worden uitgekeerd die niet worden verlengd wanneer de lease verloopt. Dat betekent dat zodra de DHCP lease verloopt, het IP móet veranderen, en niet meer hetzelfde mag blijven. Als je 2001:1234:abcd::ab had, zal dat adres bij de eerstvolgende verlopen lease verdwijnen van je netwerk en daarmee van het hele internet. Je lease zal standaard elke zeven dagen verlopen, maar dat kun je zelf natuurlijk korter maken.

Er wordt over "possible approaches" gesproken omdat er bijvoorbeeld al diverse manieren zijn om tijdelijke adressen te genereren, en de standaard niet één manier van privacy afdwingt. Dat zou een probleem zijn als er een fout in het algoritme zou worden gevonden, want iedereen die de fout oplost zou dan niet meer volgens spec werken.

In de standaardconfiguratie van IPv6 (SLAAC) is dit natuurlijk geen probleem, dus alleen als je om wat voor reden dan ook zelf de adressering wilt overnemen in plaats van het systeem zijn werk te laten doen, kún je een privacy-risico veroorzaken als je de lease van de tijdelijke adressen veel te hoog instelt. Als je dat doet, is het eerlijk gezegd ook je eigen schuld.

[Reactie gewijzigd door GertMenkel op 24 juli 2024 04:12]

Ik wist helemaal niet dat het zoveel complexer anders was dan IPv4, en begrijp daarom nu pas waarom het niet van de grond komt.

Van netwerkbeheerder tot hobbyist, we weten allemaal een thuis- of bedrijfsnetwerk op te zetten, firewall op te zetten, statische IPs uit te delen, enkele poorten te mappen en applicaties te hosten.

Als je dan nu over wilt op IPv6 en je probeert logischerwijs de oude situatie te reproduceren om snel weer aan het werk te kunnen, dan kan het dus zomaar "eerlijk gezegd ook je eigen schuld" zijn dat je risico's binnen hebt gehaald?

Iedereen moet dus nieuwe netwerkstrategieën gaan aanleren en uitvoeren en er komen nieuwe risico's bij kijken.

[Reactie gewijzigd door Sando op 24 juli 2024 04:12]

Dat opzetten van een netwerkje heb je ook moeten leren, en er zitten ook héél veel totaalprutsers bij die met IPv4 denken veilig te zitten terwijl ze er een soepzooitje van maken.. maar hee, NAT dus veilig! IPv6 is een nieuw, ander protocol dan IPv4. Voordat je een systeem aan het publieke internet hangt, doe je er verstandig aan te leren hoe dat werkt. Voor IPv4 is en was dat niet anders. Ik zie echt het probleem niet. IPv6 is verder juist conceptueel veel eenvoudiger dan IPv4. Je moet alleen de gedachte loslaten dat de twee iets met elkaar te maken hebben.
Ik zie echt het probleem niet.
Je ziet heus wel om je heen dat IPv6 al jaren niet volledig van de grond komt, dus we kunnen het probleem empirisch vaststellen. Je kunt je hooguit niet sympathiseren met het probleem.

Misschien kan je je niet voorstellen dat veel mensen niet zitten te wachten op de paar miljard manuren die het wereldwijd kost om een systeem te leren die in jouw woorden niets met het systeem dat het vervangt te maken heeft. Maar het is logisch dat mensen in eerste instantie verwachten dat een versie x+1 een uitbreiding is op versie x en derhalve veel de zelfde eigenschappen heeft, dus dat gaat nog een dingetje worden.
Het probleem dat ik wél zie, is dat amateurs zich willen bemoeien met dingen waar ze vanaf zouden moeten blijven tot ze de juiste kennis van zaken ervoor opbouwen. Zaken aan publieke infrastructuur knopen is wel zo'n kennisgebied omdat je daarmee problemen voor anderen kunt veroorzaken. Doe dat op basis van ongevalideerde aannames, en je krijgt inderdaad een hoop toestanden. Daar sympathiseer ik inderdaad niet mee, als je het zo wilt uitdrukken.
Het is handig als je dan ook even een quote geeft die meteen duidelijkheid verschaft.

Anders ben ik genoodzaakt mezelf gelijk geven :+
Als je wat citeert, doe het dan wel goed !

Het stukje wat jij citeert staat dus inderdaad onder het kopje 'mogelijke oplossingen'. Het zijn dus hypothetische oplossingen, met een afweging van voor- en nadelen.

Als je verder leest, zie je dat de oplossing de volgende is:

Een host krijgt één vast permanent adres, voor het ontvangen van verbindingen. Dat adres verandert in principe nooit, zodat een server op een bekend adres te bereiken is. Voor inkomende verbindingen werkt privacy eerder belemmerend, dan dat het iets toevoegt - je moet toch weten met welke server je verbinding maakt!

Daarnaast genereert de host (bijv. diezelfde server) die privacy wenst dagelijks, of eerder, als het naar een ander netwerk verhuist, een 'random' adres, waarna het oude adres in principe niet meer gebruikt wordt, en na maximaal een week definitief vervalt (of direkt, als het gebeurt omdat de host naar een ander netwerk verhuist). Dat random adres wordt gebruikt om uitgaande verbindingen op te zetten naar andere machines. Die servers kunnen de host dus normaal niet langer dan een dag op basis van IP adres traceren (omdat een random adres daarna in principe niet meer gebruikt wordt), en sowieso niet langer dan een week (omdat het dan definitief vervalt).

Overigens zijn IoT devices waarschijnlijk prima langer te traceren, omdat ze vaak op dezelfde plaats blijven, of omdat ze zich op een bepaalde manier gedragen. Als een server bijvoorbeeld vandaag een IoT verbinding krijgt vanuit jouw netwerk met adres A, en morgen een andere verbinding met adres B, dan is dat waarschijnlijk hetzelfde device. En sowieso rapporteren die devices allerlei andere informatie op basis waarvan ze geïdentificeerd kunnen worden, ook als ze ineens op het netwerk van de buren zitten.
Daarnaast genereert de host die privacy wenst dagelijks (...) een 'random' adres
Hoe zit dat precies? Iemand moet die adressen uitdelen toch? Krijg je dan een blok van je ISP van adressen die je mag gebruiken? Krijg je dan niet op den duur dat bepaalde 'blokken' getracked worden?
Hoe zit dat precies? Iemand moet die adressen uitdelen toch? Krijg je dan een blok van je ISP van adressen die je mag gebruiken? Krijg je dan niet op den duur dat bepaalde 'blokken' getracked worden?
Je krijgt nu (meestal) van je ISP één IPv4 adres. Dat is op het niveau van het hele huishouden prima te tracken. Individuele apparaten / personen is moeilijker, omdat ze achter een NAT zitten, en allemaal vanuit internet gezien hetzelfde IP-adres hebben.

Met IPv6 krijg je een blok IPv6 adressen. Dat hele blok is gekoppeld aan jouw huishouden, en wat dat betreft vergelijkbaar met dat ene IPv4 adres. Individuele machines thuis krijgen allemaal een adres uit dat blok. Om te voorkomen dat individuele machines getrackt kunnen worden (wat om een aanvullende reden met IPv6 ook nog over meerdere netwerken zou kunnen, puur op basis van de manier waarop het vaste IPv6 adres bepaald wordt), maakt elke host *zelf* dus een aanvullend random adres binnen dat blok (één per dag, in principe). Dat adres wordt gebruikt voor uitgaande verbindingen (zodat de eigenaars van servers op het internet niet de individuele machines/personen kunnen tracken obv het IPv6 adres). Inkomende verbindingen gebruiken altijd het vaste adres. De blokken worden door de ISP uitgedeeld, de random adressen daarbinnen (en ook de niet-random adressen) worden voor eindgebruikers normaal door de computer / het device zelf gegenereerd. Er is dan natuurlijk ook een procedure om te zorgen dat niet twee hosts per ongeluk hetzelfde adres gaan gebruiken - alhoewel die kans heel erg klein is.

[Reactie gewijzigd door RJG-223 op 24 juli 2024 04:12]

Met PE genereerd een device elke X uur een nieuw adres. Ook daar is allang over nagedacht.
Je hebt dus in het "slechtste geval" 1x per dag een ander IP adres.

Zie ook: https://www.microsoft.com...utoconfiguration-in-ipv6/
Als je de DHCP lease tijd op oneindig zet wel ja... De zin die letterlijk vooraf gaat aan je quote zegt:
One way to avoid having a static non-changing address is to use DHCPv6 [DHCPV6] for obtaining addresses.
Alleen aanpassen bij een verhuizing of stroomstoring valt niet bepaald onder de noemer "non-changing address" :) Static slaat op het gebruik van de Interface Identifier, niet op het handmatig invullen van het adres op je device.

Voor degenen die wat roestig zijn met betrekking tot DHCP: Je DHCP-server geeft niet alleen een IP-adres, maar ook een Lease Time. Als die tijd op is, dan mag je device dat IP-adres niet meer gebruiken.

Halverwege het verlopen van deze tijd zal je device aan de DHCP-server vragen of het dit adres nog wat langer mag gebruiken (DHCPREQUEST / RENEWING) en als dat mag van de DHCP-server zal de client de Lease Time opnieuw toepassen. Dit is het 'renewen' waar de RFC het over heeft.

Lukt dit niet dan zal je device op 87.5% van het verlopen van de tijd een nieuwe broadcast sturen (DHCPDISCOVER), hetzelfde als wanneer je de netwerkkabel er net in prikt of er een stroomstoring is geweest.

Je adres wordt dus niet RENEWED, maar dat houdt in dat je moet STOPPEN met het gebruik van dat adres, niet dat je het adres tot in de lengte der dagen mag gebruiken :)
Overigens hebben ze het over "Possible Approaches"?
Yup. En het is goed mogelijk dat er nog meer opties zijn dan de twee die ze noemen. In het document gaan ze in ieder geval dieper in op de onderste van de twee opties die ze geven.

Of je één van die twee (of beide/meerdere, als ze niet mutually exclusive zijn) implementeert moet je zelf weten, ze zijn niet mandatory :)
Of je één van die twee (of beide/meerdere, als ze niet mutually exclusive zijn) implementeert moet je zelf weten, ze zijn niet mandatory :)
In hoeverre kan ik "moet je zelf weten" lezen als "moeten ze zelf weten"?

De implementatie in de router en de automatische instelling van je besturingssysteem (of connected device) zijn waarschijnlijk bepalend voor wat zo'n beetje de standaard gaat worden. Of zie ik dat verkeerd?
Ligt er aan wie je bedoelt met "ze". Jij bepaalt je of DHCP gebruikt (al is het inderdaad aan de ontwikkelaar van die DHCP-server of ze een functie inbouwen om renewals te declinen) of SLAAC, of iets anders.

Privacy Extensions zijn beschikbaar voor alle grote OS'en en staan onder Windows sowieso standaard aan (van anderen weet ik het niet). Voor IOT denk ik dat het niet gebruikt wordt, maar wat bezoekt jouw IOT device allemaal op het internet dat je bang bent voor tracking? De mijne zitten in een apart VLAN dat niet eens het internet op kan :)
wat bezoekt jouw IOT device allemaal op het internet dat je bang bent voor tracking? De mijne zitten in een apart VLAN dat niet eens het internet op kan :)
Van computers, telefoons, laptops, stofzuigers tot wifi-ledlampen, ik probeer gewoon een beeld te krijgen van de zaken waar ik te zijner tijd rekening mee moet houden. :)

offtopic:
Hoewel veel van die hardware volgens mij niet eens IPv6 ondersteunt.
IOT devices die het internet niet op mogen? Klinkt.raar.
Mijn IOT vlan heeft juist alleen maar internet , verder mogen de devices niks ;)
Hangt er denk ik vanaf wat je onder IOT schaart :) Ik snap dat de I in IOT voor "Internet" staat, maar "physical objects (or groups of such objects) that are embedded with sensors, processing ability, software, and other technologies, and that connect and exchange data with other devices and systems over the Internet or other communications networks" (even schaamteloos gejat van Wikipedia) hoeven niet over het internet te communiceren.

De sensors en software in mijn huis dienen mij, en alles draait on-prem :P Nu ja, vrijwel alles; er is een link naar Google voor spraakbesturing :) De camera's, deursensoren, lichtknoppen, rookmelders etc. hebben niks op het internet te zoeken.
Het is de client kant die IPv6 privacy extensions moet implementeren. De default is elke dag een nieuw IP-adres, maar Windows doet het voor zover ik weet veel vaker. Het is ook instelbaar, hoe lang een IP-adres mag leven.

Voor IoT spul is IPv6 Privacy Extensions niet zo zinvol. Die browsen normaliter het Internet niet af. IPv6 privacy extensions is juist om user tracking lastiger te maken, omdat je niet meer kan zien dat het MAC dat behoort bij de laptop van Pietje op meerdere locaties op Internet online komt.
Hier hebben de heren meesters IPv6 al lang over nagedacht, het heet 'Privacy extension' RFC 4941.
Klopt inderdaad, al moeten we er ons aan wennen dat we dit tegenwoordig liever RFC8981 noemen. :)

https://datatracker.ietf.org/doc/html/rfc8981#section-5
straks is elk apparaat op een netwerk uniek identificeerbaar dankzij een ipv6 adres
Onderstaand paper legt vrij goed uit waarom, mits je het goed doet (het paper beschrijft een situatie waar dit niet het geval is), dit niet zo hoeft te zijn. Sterker nog, je privacy is dan beter gewaarborgd dan met IPv4:

https://dl.acm.org/doi/pdf/10.1145/3487552.3487829

Een leuke quote uit dat paper is dat meer dan 90% van alle IPv6-adressen op het internet slechts 1 x (bijvoorbeeld 1 dag lang) voorkomt. Daarna nooit meer.
die technieken, hoe leuk ook bedacht, lossen dit echt niet op. En als ik op een kantoornetwerk zit, is op basis van het ip geen onderscheid te maken tussen het verkeer.
Dit volg ik weliswaar niet, maar een van mijn eerste vragen is: hoe verhoudt zich dit tot de IPv4 op kantoor?

[Reactie gewijzigd door mdavids op 24 juli 2024 04:12]

Ik zal die paper even doorlezen. Maar op alvast antwoord te geven op jouw laatste vraag: bij ipv4 met NAT op een netwerk met veel gelijktijdig actieve apparaten is het verkeer (even los van de inhoud van de pakketjes) onder 1 IP moeilijker te onderscheiden dan op een netwerk met weinig uniek actieve apparaten zoals op een thuisnetwerk.
Gewoon inbound verkeer tegen een whitelist aanhouden zou toch equivalent aan een "NAT firewall" zijn?
Dat is het in feite ook, en is tevens hoe elke IPv6 compatible router default is geconfigureerd.
NAT is letterlijk een 'hack' geweest om het groeiende tekort van ipv4 in te perken..
Nee dat is het niet.
Staat toch echt duidelijk 2 redenen. Scaling was een groot probleem bij server providers, makkelijk een cluster verhuizen van het ene naar de andere locatie zonder daarvoor hele IP configuraties ervoor te hoeven aanpassen, en daarvoor werd dus NAT ook gebruikt als hoofdreden.
De depletion van IP's was in die tijd al duidelijk dat het nogal rap ging toen het internet gigantisch groeide, welke een andere goede reden was voor NAT.
Ik ben wel benieuwd waar je het vandaan haalt dat het een "hack" is, aangezien het een logische header toepassing is voor NAT, net zoals je VXLAN hebt e.d.
En toch heb ik liever mijn thuisnetwerk op ipv4, een class C ip kan nooit zomaar op internet werken zonder NAT gezien je maar 1 ip van de provider krijgt.

[Reactie gewijzigd door mr_evil08 op 24 juli 2024 04:12]

Dit is een beetje ook de ‘denkfout’ die ik veel zie. Je moet gewoon netjes firewallen. Of het nu om IPv4 of 6 gaat.

Ik is helaas vrij veel it’ers met dit soort redenaties IPv6 uitstellen / niet implementeren terwijl het helemaal niet moeilijker is, eerst eenvoudiger omdat je dus geen NAT meer hebt. ( uitzonderingen daargelaten).
En toch steek je dan je kop in het zand. Dat jij thuis een class-c netwerk draait en je van je provider maar 1 ip adres krijgt beschermt jou helemaal niet. Het enige dat er mogelijk zou kunnen zijn is dat je wat security by obscurity hebt omdat je IP v4 adressen die je binnen gebruikt buiten niet bekend zijn. En dat jou router ze niet doorstuurt.

Bij IPv6 is het heel eenvoudig en in de meeste thuis-routers ook standaard dat de interne IPv6 adressen naar buiten toe niet gepubliceerd worden. En dat jou router ze standaard niet doorstuurt.

Als jij vanaf jou intene IPv4 machine naar buiten gaat, stuurt de webserver van buiten de gegevens net zo makkelijk naar jou interne IPv4 machine. Anders kan je ook niet van binnen naar buiten.

In een IPv4 router en in een IPv6 router voor thuis gebruik staat de firewall al jaren netjes dicht, tenzij je ze zelf open zet.
Waarom? Bij IPv6 houdt de firewall in je router standaard alles tegen van buitenaf. Dat is niet anders dan bij IPv4. NAT maakt het niet veiliger, want als je een malafide website of mail opent zou je malware kunnen krijgen. Ook voor portscans maakt het niet uit, want als je bijvoorbeeld scant op poort 80, en je hebt niks draaien op poort 80, zal het zowel bij IPv4 als IPv6 niets uitmaken.
En toch heb ik liever mijn thuisnetwerk op ipv4, een class C ip kan nooit zomaar op internet werken zonder NAT gezien je maar 1 ip van de provider krijgt.
Grappig hoe kennis over het echte internet na 1 generatie al is verwatert vanwege NAT. :)

Natuurlijk kan een class C zomaar op het internet werken (maar je bedoelt /24, want we doen CIDR tegenwoordig en class C is een verouderde term). Alleen niet de /24 die jij krijgt in je thuisnet. Want dat zijn namelijk 'nep-adressen', gedefineerd in RFC1918. Adressen dus, die steeds maar weer worden uitgegeven in netwerken die achter NAT zijn weggestopt en niet wereldwijd uniek zijn. Alleen die adressen kunnen niet zomaar op internet werken dus. En die 'nep-adressen' krijg je, enkel en alleen omdat er veel te weinig 'echte' IPv4 adressen zijn.

[Reactie gewijzigd door mdavids op 24 juli 2024 04:12]

En ik ken geen enkele consumenten router die standaard toestaat dat apparaten op IPv6 benaderbaar zijn vanaf het internet. Je zal altijd zelf bepaalde poorten moeten openzetten. Net omdat het anders een risico is.
Ga er maar van uit dat de router de firewall voor het internet regelt. Dus niet alle apparaten in je huis hoeven een firewall te hebben om veilig te zijn van het internet. Daarnaast is het zo dat je geen firewall nodig hebt als je nergens naar luistert. Als jouw telefoon geen poorten open heeft staan dan voegt een firewall niks toe.
Met ipv6 sta je open en bloot. Een controlemechanisme over welke services op je eigen toestel benaderbaar zijn zou toch echt wel nodig zijn, want hoe weet je anders welke poorten op je toestel open staan?
Er moet gewoon firewall beheer zitten op mobiele toestellen. Mobiel of desktop geen verschil. Tenzij je voorstander bent van de mobiele hyve infrastructuur waarbij je mobiel c. q. cloud-drone volledig is geïntegreerd in de cloud-infrastructuur van één of andere conglomaat zonder enige autonomie of soevereiniteit over je eigen apparatuur.
Het klopt dat NAT effectief als firewall fungeert, waarbij die firewall standaard alle inkomende porten dicht heeft staan. Het openen van porten doe je dan door ze expliciet te forwarden.
Het is wel grappig dat dit effect van NAT waarschijnlijk oorspronkelijk niets meer was dan een side-effect. Je zou hier dan ook kunnen spreken over: 'unintended security by design'.

Het is echter een misvatting om te denken dat alles ineens open staat als je IPv6 gebruikt. Veel routers zullen bij IPv6 standaard een firewall aanzetten die alle inkomende porten dichtzet. Je moet dan alsnog zelf instellen wat je toe wilt laten.
Trouwens wel met 1 groot voordeel: met IPv6 kunnen meerdere devices dezelfde port gebruiken.

Bovenstaande geldt hopelijk voor alle consumenten modem/routers. Het wordt natuurlijk gevaarlijk op het moment dat niet-wetende-consumenten ineens al hun devices volledig open hebben staan richting het internet.
Tegelijkertijd volgt daar ook uit dat het onwaarschijnlijk is dat providers een modem/router zullen leveren die zo extreem onveilig is (niet omdat ze zo nobel zijn, maar omdat dat teveel gezeur op gaat leveren).

[Reactie gewijzigd door Marq op 24 juli 2024 04:12]

Het probleem met firewalls is dat je je veilig waant achter de firewall, maar meestal staat alle verkeer voor interne apparaten naar buiten toe open. 1 gecompromitteerd apparaat achter de firewall (zeg bv. een 'slimme' koelkast, TV of LED lamp) kan een tunnel openen naar buiten en een kwaadwillende partij toegang geven tot je hele interne netwerk.

Uiteindelijk zal je heel restrictief moeten zijn in wat je op je netwerk toelaat of er vanuit moeten gaan dat je netwerk gecompromitteerd is en rekening houden dat alles wat je daarop aansluit meer lagen van beveiliging heeft.
Maar dat is toch hetzelfde vandaag met v4 en heeft dus niets met IPv4 of IPv6 te maken.

Wil je dat afvangen dan moet je een echte firewall neerzetten en beginnen met een regel die alles blokkeert waarna je kan beginnen opbouwen wat je net wel naar het internet wenst te sturen.
Klopt, maar daarom is het 'veiligheidsgevoel' wat mensen van NAT hebben ook behoorlijk misplaatst en dat het met IPv6 anders werkt ook minder een probleem dan je zou denken.
Nu is dat niet veel anders met de default instellingen van NAT onder IPv4 though :X
Veiliger als in een hordeur die gemaakt is om ongewenste insecten buiten te houden ook een obstakel vormt voor ongewenst volk. https://www.f5.com/servic...s-translation-as-security
We mogen niet vergeten dat IPv4 al jaren aan het infuus ligt.
Maar daar merkt niemand wat van, als je niet in een datacenter werkt tenminste. Het is net als roepen dat de aardappels op zijn, terwijl je voor een pallet aardappelen staat. De consument heeft niets in de gaten. Internet werkt, alles doet het.
Maar daar merkt niemand wat van
Nou, ik ben misschien niet de gemiddelde internetter, maar ik heb er dagelijks last van.

Paar voorbeelden:

- VPN naar de zaak (shit, we gebruiken aan beide zijden 192.168.100.0/24...)
- Even een tweede server optuigen in je thuisnet en dan port-forwarding doen naar poort 443 (shit, dat werkt maar voor 1 server en achter Carrier Grade NAT kan dit overigens helemaal niet meer)
- Een Jitsi-server draaien achter NAT (laat het grote STUN-feest maar beginnen)
- Peer-to-peer doen met een vriend (ai, die zit ook al op 192.168.100.0/24)
- NTP-server thuis laten meedraaien in de NTP-pool (helaas, ik kan conntrack niet uitzetten op de CPE, hele boel loopt vast, geen internet meer...)

Enfin, niet om flauw te doen en je hebt heus wel een punt. Veel mensen hebben er in de praktijk geen last van, maar dat betekent niet dat NAT superieure technologie is. Het kost engineers de nodige hoofdbrekers om de boel draaiend te houden, terwijl er een veel simpeler oplossing op de plank ligt en gelukkig inmiddels ook in toenemende mate wordt gebruikt.
You proved my point! Bedankt!

De man in de straat heeft er gewoon géén last van. Jij bent inderdaad niet de gemiddelde gebruiker. En dat is toch echt de grootste groep. Ik ben misschien geen doorsnee gebruiker, maar ook ik heb nergens last van. Maar ik heb ook geen servers meer draaien thuis die ik overal moet kunnen benaderen.

Ik zeg niets over de techniek, want ik ben geen netwerkspecialist. En ik weet dat er heel veel achter zit en het nogal houtje touwtje is, maar mijn punt wat alleen dat de gemiddelde internetter totaal niets merkt van IPV4 tekort of de superioriteit van IPV6. Als vannacht alles omschakelt hebben ze er waarschijnlijk alleen maar last van omdat er dan van alles niet meer werkt. Maar het is onzichtbare tech. Dus veel succes met het verkopen van IPV6 aan mijn moeder, maar die koopt niets van je... :+
Mijn punt wat alleen dat de gemiddelde internetter totaal niets merkt. Dus veel succes met het verkopen van IPV6 aan mijn moeder, maar die koopt niets van je... :
Dit is het lot van heel veel anonieme helden; bikkels (M/V), die bij nacht en ontij achter de schermen de wereld draaiend houden zonder ermee te koop te lopen. Is ook beter zo. Jouw moeder en vele anderen hebben wel betere dingen te doen. Het moet gewoon werken, geen gezeur.

Gelukkig hebben deze helden, als het IT-ers betreft tenminste, het Tweakers-forum.

Kunnen ze af en toe even bij elkaar uithuilen. ;)

[Reactie gewijzigd door mdavids op 24 juli 2024 04:12]

En dit is ook het hele nadeel van IPv6. Technisch gezien is het een mooie techniek met zeker zijn voordelen, maar het gaat volledig voorbij aan het hele menselijke aspect, zelfs voor de mensen die een beetje hobbymatig met ICT dingetjes bezig zijn. Een IPv4 adres is herkenbaar, mensen kunnen het wel onthouden en kunnen vaak door bepaalde ranges te gebruiken ook een beetje raden welk apparaat er bedoeld wordt met een IPv4-adres. Bij een IPv6-adres valt dat volledig weg, adressen zijn simpelweg te lang om te herkennen, krijg je ook nog eens erbij dat je met hexadecimale waardes werkt, dus dat het helemaal ingewikkelder wordt. Ik voorzie hele hordes aan mensen die "per ongeluk" alles open en bloot richting internet zetten, waardoor uiteindelijk je security er juist slechter op wordt, terwijl de techniek het theoretisch veiliger zou kunnen maken.

Onderschat de menselijke factor niet.
Dat valt ook allemaal wel mee. Je krijgt een range toegewezen van je upstream ISP: 2a10:3251:a542:/48. Goed, die ziet er misschien wat gaar uit, maar daarachter kun je alles doen wat je maar wilt:

2a10:3251:a542:10:/56 voor je werkplekken
2a10:3251:a542:20:/56 voor je servers
2a10:3251:a542:30:/56 voor je VPN's

..en ga zo nog maar even door.

Na verloop van tijd zie je het voorvoegsel niet eens meer omdat dat overal gelijk is en je dat intussen van buiten kent, en ga je verder van 10, 20, 30 en heb je daarachter de vrijheid om zelf logisch verder te subnetten. En je bent in één klap van overlappende nummerplannen aan de overkant van VPN-tunnels af.
Er zijn heel veel gemiddelde thuisgebruikers die VPN opzetten naar de zaak. En heel veel zaken waar ze gewoon ook subnets gebruiken in dezelfde ranges als je thuis hebt.

En wij hebben hier bij ons geluk dat we niet achter CG-NAT zitten. Was dat wel het geval geweest dan hadden we er allemaal heel wat meer last van gehad.
Ik werk ook thuis via een VPN en dat werkt gewoon als een speer. Net als mijn VPN ivm Torrents. Ik heb nog van niemand gehoord dat het niet werkt of problemen heeft veroorzaakt.
IPv6 blijft toch een grote grap? Ik geloof niet dat we binnen 10 jaar over zijn in Nederland. Misschien een dual stack oplossing maar niet voor meer dan 50% van het verkeer met een IPV4 bridge.

Het probleem is dat dit probleem niet bestaat voor de Microsoft's, Google's en Amazon's van de wereld, die kopen gewoon voor miljoenen aan IP adressen.

Verder zijn er nog zat gereserveerde blokken die vrijgegeven kunnen worden, de US Department of Defence heeft zelfs 14 /8 blokken en CLASS E is nog steeds gereserveerd voor de "toekomst" (Ik weet dat de CLASS E niet overal werkt maar dat is een software probleem)

[Reactie gewijzigd door GrooV op 24 juli 2024 04:12]

Ik vraag me wel eens af of er niet beter gewerkt kan worden aan een IPv7 (of misschien weer eentje overslaan en gelijk voor IPv8 gaan :+ ) die wel backwards compatible is zodat we dat hele gedoe met dual stacks niet meer hebben.

IPv6 komt uit 1995 en intussen zijn de inzichten ook wel veranderd. IPv6 had bijvoorbeeld coole dingen voor mobiel roaming die eigenlijk helemaal niet gebruikt worden omdat ze niet meer geschikt zijn voor de eisen van deze tijd. De vereiste voor een totale omslag werd destijds niet als een bezwaar gezien omdat het internet nog niet zo groot was. Intussen denken we ook heel anders over beveiliging. In die tijd ging alles nog over telnet :') Dus ik denk dat als we nu een protocol zouden uitvinden, dat er heel anders uit zou zien.

Ik weet nog dat we er les over kregen en dat het heel belangrijk werd gevonden 'want over 2 jaar zit iedereen er op' :') Destijds was het moment geweest om het te doen inderdaad, maar zelfs toen werd er een installed base opgebouwd die de boel begon te remmen. In die tijd verdubbelde het internet echt bijna elke maand van grootte.

Overigens vind ik het ook wel een knap staaltje van de uitvinders van IPv4 dat het zo'n groot netwerk op zo'n enorme schaal weet te runnen gedurende zo'n lange tijd.

[Reactie gewijzigd door GekkePrutser op 24 juli 2024 04:12]

Ik vraag me wel eens af of er niet beter gewerkt kan worden aan een IPv7 (of misschien weer eentje overslaan en gelijk voor IPv8 gaan :+ ) die wel backwards compatible is
Iedereen die denkt, laat staan propageert dat een backwards-compatible uitbreiding van IPv4 mogelijk is, en beter dan IPv6, omdat de software niet aangepast hoeft te worden, weet niet waar ie het over heeft. IPv4 is een soort jaar-2000 probleem voor het netwerk. Als je maar twee cijfers van datums gebruikt, dan kun je dat niet backwards compatible uitbreiden naar 4 cijfers. Daarvoor moet de software die met die twee-cijferige datums werkt aangepast worden. Zo ook met een hypothetische uitbreiding van IPv4. Misschien kun je hier en daar met een hack vermijden dat ook zeer oude software aangepast moet worden, maar dat kan met IPv4/IPv6 ook, daarvoor is geen bijzonder protocol nodig. In het algemeen zal de meeste software echter aangepast moeten worden.

Als er al een soort mogelijkheid te maken is die backwards-compatible is, dan zal dat wellicht onvermijdelijk toch een soort NAT-achtige oplossing moeten zijn. Een hack dus. En dat hebben we al. Misschien zou het een iets veredelde versie van NAT zijn. maar zeer waarschijnlijk met deels of volledig dezelfde beperkingen. En daarmee gaan we dan voor het idee van korte-termijn gemak (of het werkelijk veel gemakkelijker is, valt te betwijfelen), en waarschijnlijk tegen veel hogere kosten op langere termijn, omdat we altijd zullen blijven worstelen met de beperkingen van die korte-termijn hack.

Dit alles nog afgezien van het feit dat de overstap naar IPv6 nu al een paar decennia duurt. Voor een nieuw protocol kun je beslist ook weer makkelijk een paar decennia rekenen: de standaarden moeten eerst ontwikkeld worden (kost een jaar of wat), dan geïmplementeerd in de OSen (kost nog een jaar of wat, voordat het stabiel, betrouwbaar en voldoende bugvrij functioneert), zodra het stabiel is, moet het, afhankelijk van op welke manier het uiteindelijk backwards-compatible is, óf in alle netwerken (van ISPs etc.) geïmplementeerd worden, of moeten de OSen met ondersteuning ervoor op de meeste servers en/of clients uitgerold worden. En misschien ook nog de internet-routers bij de consumenten thuis. Of toch op bijna alles, omdat het backward-compatible idee niet gelukt is. In ieder geval zal geen van die verschillende upgrade-scenario's in minder dan een decennium te realiseren zijn.
zodat we dat hele gedoe met dual stacks niet meer hebben.
Is dat zo'n gedoe dan ? Of bedoel je alleen het feit dat IPv6 anders is dan IPv4, en dat mensen daar (nog) minder vertrouwd mee zijn ? Of is is het alleen de term 'dual-stack' die eng klinkt ? Beeld je niets in. Als er een backwards-compatible uitbreiding op IPv4 zou komen (als dat mogelijk is), dan zal dat deels ook anders werken dan 'oud' IPv4. Dus moeten mensen de eigenaardigheden daarvan ook weer leren. En wellicht dat dat dan toch ook vaak als dual-stack geïmplementeerd wordt, zodat bugs en onvolkomenheden in de implementatie van het nieuwe/gewijzigde protocol geen invloed hebben op het functioneren van het oude vertrouwde IPv4.
Er zijn wel degelijk voorstellen geweest om IPv6 compatibel te maken met IPv4. Er is zelfs een subnet voor voorzien geweest. Maar door de vele aanpassingen in v6 bleek het uiteindelijk te onpraktisch om het waar te maken. Je kan niet alle verbeteringen in v6 houden en toch nog compatibel proberen te zijn met v4.
Er zijn wel degelijk voorstellen geweest om IPv6 compatibel te maken met IPv4. Er is zelfs een subnet voor voorzien geweest. Maar door de vele aanpassingen in v6 bleek het uiteindelijk te onpraktisch om het waar te maken. Je kan niet alle verbeteringen in v6 houden en toch nog compatibel proberen te zijn met v4.
Volgens mij (IIRC) ging het meer over (beperkte) interoperabiliteit dan over compatibiliteit. En volgens mij ging dat ook enkel over transparante verbindingen van IPv6-only clients naar IPv4-only servers. Daar is ook altijd een NAT, of zelfs een ALG voor nodig. Ik weet de details niet, en of het inderdaad volledig afgeschreven is, maar anders lijkt het me dat het er wel zal komen, tegen de tijd dat het aantal IPv6-only clients (of clients waarbij IPv4 in de praktijk niet meer werkbaar is) begint toe te nemen.

Verbindingen van IPv4 clients naar IPv6 servers zijn niet transparant op te lossen. Met server-side IPv4/IPv6 NAT, waarbij een hele groep IPv6 servers achter een enkel IPv4 adres zit, is nog wel wat te doen, maar dan moet elke server toch weer andere poorten gebruiken. Dat is minder handig als het bijv. om websites gaat, waarvan iedereen verwacht dat ze gewoon poort 80 gebruiken.
Wat is dan het gedoe met dual stack?
Wat is dan het gedoe met dual stack?
Er is geen gedoe met dual stack - nou ja: met echte dual-stack, dus puur een IPv4 stack en een IPv6 stack die naast elkaar leven. De problemen komen met halfbakken stop-gap oplossingen zoals 'dual stack lite.'
Gewoon uit interesse, wat gaat er mis met dual stack lite?
Gewoon uit interesse, wat gaat er mis met dual stack lite?
Er zijn verschillende implementaties van, waar de grote gemene deler is dat het custom firmware in het modem vereist om transparant op te lossen voor de eindgebruiker. Je kunt vaak niet je eigen router voeren achter een bridged modem.

Vaak is ook de ondersteuning voor IPv4 incompleet en worden zaken zoals IPv4 port-forwarding (al dan niet bewust) niet ondersteund. Letterlijk halfbakken dus: als in half gebakken; half af; incompleet.

[Reactie gewijzigd door R4gnax op 24 juli 2024 04:12]

Er zijn verschillende implementaties van, waar de grote gemene deler is dat het custom firmware in het modem vereist om transparant op te lossen voor de eindgebruiker. Je kunt vaak niet je eigen router voeren achter een bridged modem.
Logisch. Waarschijnlijk gebruikt bijna niemand het nog, zeker in de westerse wereld. Dus dan wordt het ook niet verkocht, en er wordt dus ook niet voor betaald. En dus is het ook minder goed getest etc.
Vaak is ook de ondersteuning voor IPv4 incompleet en worden zaken zoals IPv4 port-forwarding (al dan niet bewust) niet ondersteund. Letterlijk halfbakken dus: als in half gebakken; half af; incompleet.
Port-forwarding moet voor DS-Lite (net zoals voor alle CGNAT) in het netwerk van de provider geïmplementeerd worden. Dat zou je dan moeten configureren met een website van de provider, of wellicht dat er een protocol komt (of misschien bestaat het al?) waarmee jouw router die gegevens aan het netwerk kan doorgeven. Maar dat configureer je dan ook via de webserver op de router, dus dan kan het net zo goed via een website van de ISP zelf.

Edit: DS-Lite is wat dat betreft dus in ieder geval niet half af. Het is gewoon NAT in combinatie met een IPv4 over IPv6 tunnel. Dat een ISP die DS-Lite / CGNAT gebruikt geen website heeft waarop je port forwarding kunt configureren ligt niet aan DS-Lite of CGNAT.

[Reactie gewijzigd door RJG-223 op 24 juli 2024 04:12]

Er is geen gedoe met dual stack - nou ja: met echte dual-stack, dus puur een IPv4 stack en een IPv6 stack die naast elkaar leven.
Zo ik het begrijp is DS-Lite enkel voor de ISP relevant. Functioneel is het feitelijk NAT, waarbij je thuis een private IPv4 adres krijgt (192.168.x.x, 10.x.x.x, etc). Het verschil met gewoon NAT, is dat de thuisrouter enkel een IPv6 adres heeft (en geen publiek IPv4 adres). Om de IPv4 pakketjes toch op internet te krijgen, worden die in een IPv6 pakket verpakt, en naar een machine van de ISP gestuurt, die wel een publiek IPv4 heeft, alwaar ze worden uitgepakt, en het internet op gaan.
De problemen komen met halfbakken stop-gap oplossingen zoals 'dual stack lite.'
Het is geen halfbakken oplossing. Het is gewoon een mogelijke oplossing voor ISPs die onvoldoende publieke IPv4 adressen hebben om elke klant er één te geven, terwijl die klanten toch IPv4 willen gebruiken. Of wanneer die ISP geen zin (meer - over 20 jaar) heeft om in het hele netwerk zowel IPv4 als IPv6 te configureren en te beheren.

Voor alle duidelijkheid: dual-stack betekent voor een apparaat dat het IPv4 en IPv6 naast elkaar gebruikt / kan gebruiken, en dus zowel een IPv4 als IPv6 adres heeft. Voor een netwerk betekent het dat alle functionaliteit zowel met IPv4 als met IPv6 werkt, en dat beide soorten verkeer gelijkwaardig over het netwerk gaan. Bij DS-Lite hoeft een deel van het ISP-netwerk niet dual-stack te zijn, maar enkel IPv6. Al die apparatuur heeft dan geen IPv4 adres, en kan dan ook niet overweg met IPv4 verkeer.
Ik denk niet dat er genoeg ipv4 adressen zijn om nog 10 jaar vooruit te kunnen. Dus binnen 10 jaar zal wel moeten.
Het is al meer dan 10 jaar geleden dat de laatste blokken aan de RIR's zijn gegeven (31-1 2011) en nog gebeurt er amper iets. Het probleem zit hem dan ook niet bij de westerse landen maar bij landen die de laatste jaren pas grote stappen zetten naar digitalisering. Die vissen nu achter het net.

De meeste providers zijn allemaal wel voorzien hier en mobiel verkeer gaat sowieso al via een (soort van) NAT, daar is het ook geen issue
Waarom die haast? De grote datacenter providers hebben een mooi goudmijntje hoor, vragen rustig 2,50 euro per maand per ipv4 adres.

Plus heel veel ISP’s ondersteunen het niet dus dit gaat nog jaaaaaaaren duren.
ISP's die het niet ondersteunen hebben gewoon geen kennis van IPv6. En wat je niet weet, kun je ook niet implementeren. Aan de apparatuur zal het niet liggen, die ondersteunen tegenwoordig wel allemaal IPv6.
Geen idee of het een kennis probleem is. Meer een gebrek aan mensen die het gaan supporten -naast- de al bestaande IPv4 infrastructuur en het feit dat het voor de ISP niet direct wat oplevert.
tja, alle onprem aansluitingen zijn ips terug aan het geven want ze hosten niks meer dus waarom nog sloten aan Ip`s aanhouden en betalen.
Het is al meer dan 10 jaar geleden dat de laatste blokken aan de RIR's zijn gegeven (31-1 2011) en nog gebeurt er amper iets.
Aan de ene kant worden er steeds meer kunstgrepen toegepast om dit mogelijk te maken. Denk maar aan carrier grade nat. Aan de andere kant komen er ook steeds ip adressen vrij. Ik werkte begin deze eeuw bij een bedrijf dat een compleet B klasse netwerk bezat. Alle systemen hadden dus een echt ip adres, maar geen enkel ging direct naar buiten (buiten uiteraard webserver, mail en proxy). Zo ver ik weet hebben zij inmiddels dat B netwerk afgestoten en doen ze IP4 ook gewoon via een interne range. Door dit soort opruimacties komen ook weer veel adressen vrij.
Het is al meer dan 10 jaar geleden dat de laatste blokken aan de RIR's zijn gegeven (31-1 2011) en nog gebeurt er amper iets.
Er gebeurt een heleboel, het gaat alleen niet snel. De groei van IPv6 is langzaam, maar gestaag. Er is dan ook (gelukkig!) geen acute reden om het sneller te doen - zoals met het jaar-2000 probleem.
Vreemd he, dat hier in het westen, waar we een onevenredig groot aantal blokken hebben uitgedeeld de problemen niet zien terwijl opkomende lande in Azie en Afrika amper IPv4 adressen hebben gekregen en je soms met honderden achter 1 publiek adres moet gaan zitten met CG-NAT om toch maar aan het internet te kunnen.

Natuurlijk zien wij de problemen niet, maar de wereld stopt niet aan onze voordeur.
Wij hebben als Nederland een enorme hoeveelheid IPv4 adressen. Wij stonden destijds redelijk vooraan met het claimen van ranges.

Voordat we hier in de problemen komen met IPv4 adressen zijn we al heel wat jaartjes verder. Vooralsnog hebben we er meer dan genoeg.
Er zijn in NL providers/ partijen de nog blokken/subnet van 2 miljoen stuks gewoon ongebruikt en aangebroken in de kast hebben liggen.

In Nederland zijn er nog genoeg ipv4 adressen voor de komende 10 jaar alleen zijn ze oneerlijk verdeeld omdat de internet pioniers in den beginnen veel meer hebben gekregen dan dan ze ooit nodig zouden kunnen hebben.

[Reactie gewijzigd door xbeam op 24 juli 2024 04:12]

2 miljoen adressen zijn zo op als er een paar succesvolle IoT applicaties* komen. CGNAT houdt ook een keer op.

*) Gazelle heeft bijvoorbeeld een deal met een provider voor 1 miljoen fietsen met een IoT device. En dat is maar 1 toepassing.
*) Gazelle heeft bijvoorbeeld een deal met een provider voor 1 miljoen fietsen met een IoT device. En dat is maar 1 toepassing.
Die krijgen toch geen publiek ip daarvoor als ze al wifi gebruiken

[Reactie gewijzigd door darioboy75 op 24 juli 2024 04:12]

Ook als die fietsen een simkaart (private 5G wan) krijgen dan krijgen ze waarschijnlijk binnen de provider een private/locale adress, een fiets hoeft niet te interneten kn gewoon binnen het lock neten van. Provider blijven en de verbinding naar de gaat waarschijnlijk via een api-proxy-bridge naar het internet/fiets gebruiker. Dan heeft die provider ook niet vier nieuwe cgnat/BGC nodig voor die simkaartjes/fietsen

En geef niet aan dat nog maar 2 miljoen zijn ik dat waarschijnlijk nog miljoenen zijn om dat er in Nederland providers zijn waar er nog onaangebroken subs/blokken van 2 miljoen stuk liggen te verstoffen.

Probleem is dat niet uit/ of teruggeven (speculeren op prijs stijging) met 2miljoen stuks een beleggings vermogen van 50miljoen euro’s op levert.

[Reactie gewijzigd door xbeam op 24 juli 2024 04:12]

2 miljoen adressen zijn zo op als er een paar succesvolle IoT applicaties* komen. CGNAT houdt ook een keer op
Ik vraag me af wanneer CGNAT dan ophoudt. Volgens mij is de belangrijkste beperking van NAT (en CGNAT dus), dat er tussen 2 IP adressen in de praktijk maximaal ca. 64000 (TCP) verbindingen tegelijk kunnen bestaan. Dus als een provider één publiek IP-adres heeft, en 1000000 klanten, die allemaal tegelijk (binnen een periode van zeg 10-20 minuten) met dezelfde facebook server verbinding willen maken, dan loopt het vast. En dat gebeurt nooit, want elke dienst die zoveel klanten heeft, heeft ook een heleboel servers verspreid over verschillende datacenters, met dus allemaal een ander IP adres. En de ISP heeft in dat geval ook 100% zeker méér dan 1 publiek IP adres beschikbaar. En ook meer dan één machine overigens om al dat verkeer af te kunnen handelen. Kortom: die 64000 verbindingen tussen twee IP adressen wordt in de praktijk nooit bereikt.

Volgens mij (CMIIW) zijn er geen andere beperkingen die pas optreden als het aantal klanten / devices op het netwerk toeneemt - afgezien dan enkel van het feit dat de CGNAT address range maximaal ca. 4 miljoen adressen ondersteunt. Een CGNAT provider met meer klanten dan dat, moet dan dus meer dan één CGNAT netwerk hebben.
Maak daar gerust maar over 20+ jaar van, ik zie het nog niet gebeuren binnen nu en 10 jaar, niet alles hoeft een eigen internet ip te hebben, veel zaken werken prima achter NAT.

Mijn mobiele telefoon zit bijvoorbeeld ook via mobiel netwerken achter NAT bij de provider en daar heb ik totaal geen hinder van, ja ok mogelijk iemand die rottigheid uithaalt en een IP ban wordt uitgedeelt.

[Reactie gewijzigd door mr_evil08 op 24 juli 2024 04:12]

Het probleem is dat er al geen ruimte meer is voor publieke ipadressen waardoor hacks als carrier grade NAT toegepast moeten worden (zoals je al aangeeft met je mobiele telefoon). NAT werkt prima, maar als er aan de buitenkant steeds meer truukjes toegepast moeten worden wordt het eens tijd voor IPv6.
Verder zijn er nog zat gereserveerde blokken die vrijgegeven kunnen worden, de US Department of Defence heeft zelfs 14 /8 blokken en CLASS E is nog steeds gereserveerd voor de "toekomst" (Ik weet dat de CLASS E niet overal werkt maar dat is een software probleem)
Dat laatste is wel een klein understatement. Van jouw browser tot aan de webserver waar je heen wilt, zitten tientallen of honderden apparaten en programma's, en een vrij groot deel daarvan is geprogrammeerd om al het verkeer van en/of naar 240.0.0.0/4 te discarden.

Class E vrijgeven voor publiek gebruik gaat een wereldwijde nachtmerrie worden. Succes met troubleshooten...

[Reactie gewijzigd door RefriedNoodle op 24 juli 2024 04:12]

En die software werkt wel met IPV6 dan? Je kan anno 2021 nog geen enkel spel via Steam op IPV6 online spelen... Om maar een voorbeeld te noemen.

Begrijp me niet verkeerd, ik ben pro IPV6 en wou dat mijn provider het ondersteunde (Tweak) maar zo lang niemand IPV4 uitzet blijft het aanmodderen

[Reactie gewijzigd door GrooV op 24 juli 2024 04:12]

Tweak ondersteund niet native IPv6, wel over een v4-tunnel naar hun eigen PoP.
Ik heb anders hartstikke native IPv6 van Tweak hoor :)
Dat is hartstikke mooi om te weten! Weet je of dit standaard beschikbaar is of moet je je daarvoor laten selecteren uit een testgroep? En weet je toevallig ook hoe groot het subnet is dat ze uitdelen?
Het moet voor nu nog handmatig geconfigureerd worden, maar het doel is om het dit jaar nog af te ronden (zie https://forum.tweak.nl/t/...n-voor-native-ipv6/48/153). Je kan daar ook proberen te vragen of je mee mag doen met de testgroep, maar ik denk dat het voor het testen niet meer nodig is (de groep draait er nu al een aantal weken op, en er zijn ook al een aantal switch firmwarebugs gevonden), en vooralsnog moet alles nog handmatig geregistreerd worden.

Je krijgt een /56 via DHCPv6 toegewezen die je helemaal naar eigen smaak kan inrichten en een /128 voor de router zelf.
Tweak is druk bezig met native IPv6, en er is inmiddels ook al een flinke groep gebruikers die daarop draaien. Ik weet niet wanneer het generiek beschikbaar gaat komen, maar tot die tijd zou je ook nog gebruik kunnen maken van de 6RD tunnel.
Sorry, maar dat is gewoon niet juist. De steam API ondersteund volledig IPv6:

https://partner.steamgames.com/doc/api/steamnetworkingtypes

En ik heb persoonlijk ook op verschillende games multiplayer op IPv6 gespeeld. Ik geloof dat deep rock galactic op IPv6 connect voor multiplayer. (ik speel niet veel multiplayer op het moment)

De steam client zelf is een ander verhaal. Dit is weer typisch Valve. Partner API volledig IPv6 compabitble maken, maar je eigen app alleen laten connecten op IPv4. Het is niet netjes, maar de back-end is iig ipv6 capable
Ik denk dat een ISP meer IPv4-adressen heeft / moet kopen dan Microsoft / Google / Amazon. Dus dat kost vooral ISPs veel geld om voldoende IPv4 te hebben.
Ik denk dat je je daarop verkijkt. Een ISP kan nog CG-NAT inzetten (Carrier-Grade NAT). Voor een cloud dienst is dat veel lastiger omdat die bereikbaar moeten zijn vanaf buiten. Met name op een mobiele provider zit je vrijwel altijd achter CG-NAT. Voor vast nog niet zo maar dat is meer omdat er in onze regio veel IP's zijn gehamsterd. In Azie zie je het veel meer.

Nu heb je wel trucjes om IP's te combineren met SNI maar dat is ook niet probleemloos.

[Reactie gewijzigd door GekkePrutser op 24 juli 2024 04:12]

Op een bepaald moment worden de kosten van een degelijke CG-NAT oplossing toch gewoon zo hoog dat je net zo goed kan inzetten op het conceptueel veel simpeler IPv6.
Naast betrouwbaarheidsproblemen heeft CG-NAT het probleem dat het bijvoorbeeld lastig wordt voor site beheerders om kwaadwillende partijen te blokkeren op IP adres. Dat site beheerders dan heel dure oplossingen (Cloudflare e.d.) nodig hebben zijn verborgen kosten die deels veroorzaakt worden door dit soort hacky oplossingen.
Het probleem is dat dit probleem niet bestaat voor de Microsoft's, Google's en Amazon's van de wereld, die kopen gewoon voor miljoenen aan IP adressen.
Die grote internationale organisaties zijn al lang over op IPv6. In grote delen van de wereld, met name de ' niet westerse' zijn de ipv4 adressen al lang op en is ook de routering een uitdaging.
Lol. Overheid. Zelfs vooraanstaande tech sites komen al niet heelhuids door de IPv6 checker :')

Dit gaan ze never nooit niet halen. Welterusten Logius :z

Als ik bij de overheid werkte zou ik hard lachen. En dan zeggen "Hahaha ik dacht even dat jullie 31 december dit jaar bedoelden :') "

Edit: Ik snap dat mijn laconieke reactie niet wordt gewaardeerd. Maar echt, zelfs Microsoft krijgt het al niet behoorlijk voor elkaar. Zie de comments hierboven over Azure enzo. Ik snap niet dat verwacht wordt dat elke overheidssite (en dat zijn er nogal wat!!!) dit wel kunnen als een van de grootste IT/Cloud specialisten er al problemen mee heeft.

[Reactie gewijzigd door GekkePrutser op 24 juli 2024 04:12]

Op zich is dit niet nieuw hoor. Ik werk bij een overheidsorganisatie en bij ons is het voor 99% geregeld voor de verschillende domeinen/servers.

Ook als ik naar collega-organisaties kijk met die tool van jou zie ik vrijwel overal groene vinkjes. Afaik is het ook al een tijdje een standaardeis bij aanbestedingen, maar pin me er niet op vast.
Oh nice, dat achtergrondverhaal kende ik natuurlijk niet. Bij ons op het werk zijn we ook nog 'rood' (niet mijn verantwoordelijkheid overigens O-)

Maar er zijn volgens mij best veel 'kleine' sites van overheidsinstanties. Scholen, gemeentegroepjes enz.. Het lijkt me best wel een berg werk om dat allemaal zelfs maar te checken voor eind December.

[Reactie gewijzigd door GekkePrutser op 24 juli 2024 04:12]

Oh nice, dat achtergrondverhaal kende ik natuurlijk niet. Bij ons op het werk zijn we ook nog 'rood' (niet mijn verantwoordelijkheid overigens O-)

Maar er zijn volgens mij best veel 'kleine' sites van overheidsinstanties. Scholen, gemeentegroepjes enz.. Het lijkt me best wel een berg werk om dat allemaal zelfs maar te checken voor eind December.
Logius entered the building ....
"we moeten alleen een paar uur meer kunnen declareren, maar dan zijn we ook klaar voor de toekomst"
Dat ligt meer aan True dan aan de techsite :P
Snap ik. Maar ook true is een grote IT partij natuurlijk. En als die site het zo belangrijk vond, waren ze al wel verhuisd. Kennelijk is het gewoon of niet zo simpel of heeft het gewoon de prioriteit niet.

Ik zit niet zo in de connectivity wereld maar als zelfs de IT kenners er al weinig aan doen, zie ik het de minder IT gerichte instanties toch met moeite aanpakken.

[Reactie gewijzigd door GekkePrutser op 24 juli 2024 04:12]

Suc6 met jullie IPv6 ellende maar 99,9% van de MKB doet er helemaal niks mee. En zoals vele andere al aangeven, we kunnen echt nog tientallen jaren vooruit met IPv4 en ik zie het ook niet gebeuren dat het voor 2035-2050 echt interessant wordt als het al ooit wat gaat worden. Veel apparaten ondersteunen het niet eens. Tegen die tijd hebben we misschien al weer verbeterde versies of iets ook wat compliant is met IPv4. Bovendien dat hele IPv6 is gewoon te omslachtig, niet gebruikersvriendelijk etc.
Suc6 met jullie IPv6 ellende maar 99,9% van de MKB doet er helemaal niks mee. En zoals vele andere al aangeven, we kunnen echt nog tientallen jaren vooruit met IPv4 en ik zie het ook niet gebeuren dat het voor 2035-2050 echt interessant wordt als het al ooit wat gaat worden. Veel apparaten ondersteunen het niet eens. Tegen die tijd hebben we misschien al weer verbeterde versies of iets ook wat compliant is met IPv4. Bovendien dat hele IPv6 is gewoon te omslachtig, niet gebruikersvriendelijk etc.
Als MKB hoef je waarschijnlijk bijna niets te doen. Als je je apparatuur een keertje vervangt, is de nieuwe apparatuur geschikt voor IPv6, en de rest gaat waarschijnlijk vanzelf bij het installeren van de nieuwe software. De meeste (bijna alle ?) nieuwe apparatuur ondersteunt het juist wel !

En ik verwacht dat zeker vóór 2050 er IPv6-only servers en diensten op internet zullen komen, simpelweg omdat de beheerders ervan geen zin hebben om veel geld uit te geven aan IPv4 adressen. Of ze rekenen je een fors bedrag per PC/server per maand extra als je IPv4 wilt gebruiken. Als jij zo'n dienst nodig hebt, of de kosten te hoog vindt, dan ben je snel over. En waarschijnlijk merk je dat het allemaal heel erg meevalt - als je ten minste geen antieke software uit de 20e eeuw gebruikt. En als je dat wel doet, heb je heel wat meer hoofdbrekens om die draaiende te houden dan dat IPv6 je ooit kan geven.

Een ander protocol op die termijn is ondenkbaar. We zijn met IPv6 al enkele decennia bezig. Een nieuw protocol is niet zoiets als een nieuwe TV. Je moet het vergelijken met nieuwe infrastructuur. Zeg maar: het vervangen van het hele spoornet door maglev. Of het overschakelen naar gelijkstroom voor het electriciteitsnet: alle apparatuur moet dan vervangen worden !

En zoals elders ook al gezegd: een IPv4 compliant protocol waarvoor je niet alle software moet herschrijven bestaat niet. Kan niet bestaan. En als je het probeert, wordt het een wangedrocht, erger waarschijnlijk dan NAT. En het idee dat IPv6 te omslachtig is is onzin. Koudwatervrees. Mensen zijn er niet mee bekend. En wat de boer niet kent...

IPv6 is de toekomst, althans de eerstkomende 100 jaar of langer, ga daar maar vanuit.
Veel apparaten ondersteunen het niet eens? Hoe kom je daar bij?

Kan jij een modern apparaat noemen? Printers, switches, routers, allemaal devices die ik gekocht heb die gewoon IPv6 ondersteunen.

Maar vooral je kop in het zand blijven steken. IPv6 is er, blijft er en wint heel hard terrein.

Inmiddels is bij Google al bijna 40% van het verkeer IPv6.
Ik heb Yamaha Speakers (MusicCast) gloednieuw. De beheer app op iOS ondersteunt alleen IP4. Dat is al jaren zo. Dus ik kan m’n speakers niet meer aan en uit zetten straks. Ik heb een Nintendo Switch uit 2014 die ondersteunt geen IPv6. Ik heb een printer van HP waar ik niet achterkom wat ie wel of niet ondersteunt. Maar de forums op internet doen niet veel goeds vermoeden. En zo kan ik wel even doorgaan. Iedere thuisgebruiker heeft tegenwoordig 20+ apparaten in een LAN. Die nooit werkend zijn geweest met IP6. Je kunt wel raden wat er gebeurt als je ineens IP6 gaat gebruiken.
IPv6 komt naast IPv4 te draaien. In je thuisnetwerk kan je nog prima een heele lange tijd IPv4 aan laten staan.

Dual-Stack heet dat en is heel normaal. IPv6 komt er naast en het meerendeel van je verkeer naar het internet zal dan IPv6 worden.
IPv4 uitbreiden is onmogelijk. Zelfs al doe je een domme IPv4-uitbreiding door gewoon de adresruimte groter te maken, zal je alsnog de software en hardware in je hele netwerk opnieuw moeten instellen. De firmware moet herschreven worden, de hardware acceleration moet opnieuw gebeuren, en er moet wat verzonnen worden om de routing tables enigszins normaal te houden. Je zult opnieuw moeten wachten tot alle servers het ondersteunen, en je zult exact dezelfde problemen krijgen als met IPv6.

Tot er een daadwerkelijk probleem met IPv6 ontstaat, zie ik de komende twintig jaar geen vervanging verschijnen. Zelfs als het MKB zover achter blijft lopen, zullen ze tegen de tijd van IPv7 al lang over zijn. Desnoods gebruiken ze dan allemaal 6to4 proxies omdat ze nog steeds een irreëele fobie hebben voor voor IPv6.

[Reactie gewijzigd door GertMenkel op 24 juli 2024 04:12]

Ik denk niet dat er vandaag nog apparaten op de markt komen die het NIET ondersteunen. IPv6 bestaat ondertussen al weer bijna 25 jaar!

En van zodra de grote bedrijven diensten moeten gaan wegsteken achter IPv6 omdat ze niet meer aan v4 adressen geraken dan is het ineens wel belangrijk. Maar iedereen die er zich niet op voorbereid gaat dan ineens achter het net vissen.Want de experts om dan alles snel in orde te brengen gaan dan ineens zo drukbevraagd zijn dat je weken of maanden zult moeten wachten tot het in orde is.

Intern, binnen in bedrijven zie ik inderdaad niet snel wegmigreren van IPv4, maar dat wil niet zeggen dat men niet klaar moet zijn met v6 aan de edge van het netwerk.
Ik denk niet dat er vandaag nog apparaten op de markt komen die het NIET ondersteunen. IPv6 bestaat ondertussen al weer bijna 25 jaar!
Bij nader inzien denk ik dat er toch nog veel IoT devices zijn die op een kleine embedded processor draaien, waarop IPv6 ondersteuning überhaupt niet bestaat. En als het voor een platform al bestaat, heeft de producent mogelijk niet aangezet, puur en alleen omdat dat extra moeite kost, en dus meer geld. Niet alles draait Linux of Windows, waarbij IPv6 standaard aan staat, en je juist moeite moet doen om het uit te zetten.
En nu de gewone providers nog.
Welke providers hebben het nog niet dan? Zit zelf bij KPN en heb al twee jaar ipv6 werkend

Aan de reacties hieronder te zien toch behoorlijk veel providers die het nog niet op orde hebben, schrik daar wel van eigenlijk

[Reactie gewijzigd door jcbvm op 24 juli 2024 04:12]

Oude UPC gebieden / Ziggo
+ iedereen op bridge mode!
Yup, zo is de verwachting dat ik nog jaren niet op ipv6 zal zitten
Typisch Ziggo…. Beloofden jaren geleden al IPv6, nooit van de grond gekomen.
Yup, had eerst wel IPv6 maar als je modem in bridge mode zet ga je naar IPv4 only bij Ziggo
En als je bridge mode weer uit laat zetten, dan blijf je in IPv4 mode. Hoewel je vast kan vragen om dat weer aan te passen, maar ik merk eigenlijk toch geen verschil.
Bestaande klanten bij Ziggo zitten meestal nog op ipv4 only. En ik weet dat Delta helemaal niet aan ipv6 doet.
Bestaande klant hier -- keurig IPv6. De verandering is vrij eenvoudig bij Ziggo.
Probeer maar eens IPv6 te krijgen met je router in bridge mode dan .....
En niet bestaande klanten hebben geen internet.
You crack me up haha.
En niet bestaande klanten hebben geen internet.
Want Ziggo is de enige provider die internet toegang biedt ?
Hier helaas wel. Als je meer dan 2mbit wil ;)
Delta wel op kabel netwerk, niet op glasvezel...
Ik zit bij Delta, vorige week mijn pfSense router gereboot en daarna had ik een IPv6 adres. Na wat instellingen wijzigen in pfSense werken nu al mijn devices met IPv6.

Geen idee wanneer ze dat geactiveerd hebben, ik kan er niets over vinden op hun website, ook geen nieuwsbericht.
Caiway hier. geen ipv6
Budget thuis bijvoorbeeld, zal wel te duur zijn. :D
T-Mobile, Caiway, Vodafone }:O
T-Mobile Thuis ook nog niet
Ik heb T-mobile thuis glas en nog geen ipv6 adressen. Als je daar op zoekt kom je op forums uit waar deze zomer nog gezegd is dat T-mobile er mee bezig is.
Tele2 heeft ook geen ip6.
Daar werken prima mensen die het niet zo op hebben met technieken die geen hond gebruikt.

Als ze nou eens IPvX wel juist maken met een groter nummer (vb: 1024.1024.1024.1024) is dat een hele verbetering. ( heb je 1100 Miljard Adressen ipv 4.3miljard nu)

ipv:
" 2001:0000:3238:DFE1:63:0000:0000:FEFB" is u nummer meneer, onthoud het maar en dat aan de telefoon"
.... HOE DAN! WTF ! WAT?! .... kunt u het nog een keer herhalen??!?!@#$

Dan zullen dan veel meer mensen overstappen.
Daar werken prima mensen die het niet zo op hebben met technieken die geen hond gebruikt.
Je bedoelt prima managers, die geen geld willen uitgeven als de klanten het verschil toch niet merken. Gelijk hebben ze. Vooralsnog. Overigens gebruikt (volgens Google) 35% van de mensen op de wereld inmiddels IPv6. Als er daar prima mensen werken, hebben ze wel al een IPv6 strategie die méér is dan struisvogel-strategie. Oftwel: een strategie om op termijn ook over te schakelen op IPv6.
Als ze nou eens IPvX wel juist maken met een groter nummer (vb: 1024.1024.1024.1024) is dat een hele verbetering. ( heb je 1100 Miljard Adressen ipv 4.3miljard nu)

ipv:
" 2001:0000:3238:DFE1:63:0000:0000:FEFB" is u nummer meneer, onthoud het maar en dat aan de telefoon"
.... HOE DAN! WTF ! WAT?! .... kunt u het nog een keer herhalen??!?!@#$
Dus je hele bezwaar is dat de IPv6 adressen te lang zijn ? Of heb je bezwaar tegen de letters ? Zou je een adres in bijvoorbeeld de volgende vorm meer acceptabel vinden ?:
8193.0.12856.57313.99.0.0.65275
Dan hebben we nog wat meer adresruimte dan in jouw voorbeeld. Méér dan 1100 miljard. Dan kunnen we de komende paar 100 jaar vooruit. Nuttig, zeker omdat binnen een paar decennia iedereen honderden, of misschien wel duizenden IoT apparaatjes in huis zal hebben.

O ja, het bovenstaande adres zonder die letters is exact hetzelfde als het IPv6 adres wat jij noemt, maar dan in decimaal ipv hexadecimaal formaat... Leesbaarder, niet ?

Overigens: een ander IP protocol gaat echt niet gebeuren. Niet voordat IPv6 z'n grenzen bereikt heeft. Dus wen er maar vast aan: het wordt IPv6.
Dan zullen dan veel meer mensen overstappen.
Het boeit de meeste mensen echt niet. Die gebruiken een hostname, die volledig transparant middels DNS vertaald wordt naar een adres in welk formaat dan ook dat courant is. En als dat toevallig IPv6 is dan gebruiken ze dat dus.
Hoe wil je 1024 in 8 bits stoppen? Dat vereist 10 bits en dat gaat dus niet. Dan moet je dus sowieso een incompatible nieuw protocol bedenken. Exact de reden waarom IPv6 is bedacht.

De rest is gewoon een kwestie van notatie. We hebben nu eenmaal afgesproken dat we IPv6 hexadecimaal noteren, dus FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF maar het maakt voor de techniek helemaal niks uit om decimale notatie te gebruiken. Alleen krijgen we dan adressen van het soort 65535:65535:65536:65535:65535:65535:65536:65535. Ben je daarmee echt geholpen?
Ziggo is enkel of puur IPv4, of puur IPv6.
Heb zelf maar mijn VPN zo opgezet dat hij beiden IPv4 en IPv6 kan behandelen...
Ik heb bij Ziggo al geruime tijd dual stack ipv6 en ipv4 fZiggo.

Ds lite is volgens mij voornamelijk in fUPC.
Dat was de laatste keer anders niet het geval.
Zal ik maar weer even moeten navragen, de vorige keer was mijn hele internet dood...

https://community.ziggo.n...dus-connectbox/td-p/20342

Zoals je ziet, ben ik niet de enige destijds die het niet kon.
Is leuk dat je het zegt, maar geruime tijd ?
Nee, in 2020 kon je het ook nog niet, en dat is niet lang geleden...

[Reactie gewijzigd door Power2All op 24 juli 2024 04:12]

Dat gaat dan ook over bridge, dat heb je niet gemeld. Dan is nog steeds alleen ipv4.
tmobile heeft het gewoon glashard uitstaan. alles zit achter een NAT.
Ziggo waarvan modem in bridge mode staat
Hier ook nog geen ipv6, zolang diensten nog bereikbaar zijn via ipv4 ben ik het ook niet nodig voorlopig (T-Mobile glasvezel).

Ik ken ook wel de voordelen van ipv6 als je een serverpark host thuis.

[Reactie gewijzigd door mr_evil08 op 24 juli 2024 04:12]

Dat het bij KPN aan staat is vooral en met name omdat het bij xs4all al jaren aan stond. En ze moesten die gebruikers wel het zelfde bieden toen die over gezet werden naar kpn.

Natuurlijk kan je het ook andersom stellen: Bij xs4all hadden ze het al jaren goed voor elkaar en kpn heeft dat netjes overgenomen en uitgerold naar de rest.

KPN had IPv6 al jaren eerder beschikbaar kunnen hebben. Ook zij hebben er met de pet naar gegooid. Zij hadden de kennis en vaardigheid al jaren eerder bij xs4all vandaan kunnen halen.
Zij hadden de kennis en vaardigheid al jaren eerder bij xs4all vandaan kunnen halen.
Ik kan me niet voorstellen dat een gebrek aan kennis het probleem was. Zo moeilijk is het ook niet.

Het zijn eerder de kosten die beperkend werken: waarom zou je extra geld uitgeven als alles nu, en voor de komende jaren, nog goed genoeg functioneert, de klanten het verschil in de praktijk toch niet merken, en zeker als (m.n. in het begin) IPv6-apparatuur duurder is dan IPv4-only.
alsjeblieft niet,

vorig jaar 2 maanden IPV6 gezeten bij ziggo,

alleen maar problemen en traag internet en disconnects,

Modem snel weer terug laten zetten naar bridge ip mijn IPV4 router en alle issues opgelost.
Dat zal wel door dubbele NAT gekomen zijn, niet IPv6.
nee hoor directe wifi en kabel op de ziggo modem waren net zo brak,,

diverse website zelfde issue voor de eerste keer laden , en Powershell remote sessies waren helemaal een drama ,

ziggo een firmware switch naar bridge uit laten voeren gezien ze daar geen IPv4 leveren en nu geen enkele issue meer zelfs niet met tripple nat achter VM hosts.

zie ook andere reacties van andere tweakers die zelfde issue hadden

[Reactie gewijzigd door Scriptkid op 24 juli 2024 04:12]

alleen maar problemen en traag internet en disconnects,
Wss heb je een Ziggo modemrouter combi met een Puma chipset. Enige manier om die pokke-doosjes enigzins stabiel te krijgen en houden is bridge-mode, zodat het routergedeelte (min of meer) gebypassed wordt.
Bij Ziggo werkt ipv6 gewoon. Kpn heeft het ook voor veel klanten, dan heb je al een aanzienlijk deel van Nederland.
IPv6 puur, zonder IPv6 naar IPv4 bridge.
Gaat bijna heel internet dood omdat je dan niet meer bij de meeste plekken kan komen.
Heb dat zelf gehad toen ik vroeg naar IPv6, na overschakeling deed bijna niks meer, tenzij het IPv6 ondersteuning had....
Dat is vreemd, want bij elke ISP die ik in Nederland gezien hebt, blijf je gewoon IPv4 behouden. Ziggo doet geloof ik DS-LITE daarvoor, maar er zijn andere opties natuurlijk.

Inderdaad zijn veel servers nog steeds niet IPv6-capable, maar dat heeft bij een normale netwerkopstelling geen impact op de bereikbaarheid van domeinen.

Wat ik wel heb gezien bij zo'n "overschakeling" was dat alles implodeerde omdat IPv6 op de client uitstond of verkeerd stond ingesteld om de een of andere reden, en de DNS-server vrolijk op AAAA requests ging antwoorden. Dat werkt natuurlijk voor geen meter, omdat je dan telkens moet wachten op de fallback naar IPv4 (als je applicatie dat al automatisch doet).

Overigens heb ik zelf een publiek IPv4-adres en een IPv6-subnet. Dat kan gewoon prima, maar Ziggo zal daar wel te goedkoop voor zijn.
https://community.ziggo.n...dus-connectbox/td-p/20342

Helaas niet bij Ziggo.
Nou is 2020 wel weer een jaartje geleden, maar daarvoor was het ook al sowieso niet bruikbaar.
In bridge werkt het inderdaad niet, dat is helaas een bekend probleem van Ziggo. Zonder bridge werkt het echter perfect.
Zonder bridge werkt het voor mij niet.
Het is dan echter IPv4 of IPv6, en niet beiden.
Probleem is dat ik met IPv4 en IPv6 servers werk, dus op dit moment gebruik ik een VPN server van mijzelf die IPv6 ondersteuning heeft, zodat ik in ieder geval beide protocollen kan benaderen.
Had liever gezien dat Ziggo beiden zonder problemen ondersteunde.
Heel vreemd, bij diverse Ziggo-klanten in de familie werkt het out of the box. Ik denk dat het Ziggo-netwerk en je apparatuur/configuratie ruzie hebben, want dit is in elk geval niet de normale situatie.
Daar kan ik wellicht mee eens zijn.
Probleem is dat het personeel bij Ziggo er helaas weinig verstand van hebben om het probleem uberhaupt op te lossen. Ik had in het begin toen ze bij mij kabel fixde, 12 monteurs over de vloer gehad in 6 maanden tijd, en dat was vooral het vervangen steeds van kleine onderdelen, een kabel die letterlijk weg gerot was, splitter kast buiten die foutieve aansluitingen hadden (verkeerd om, ik kreeg teveel stroom gestuurd, -_-), en noem maar op.
Toen ik alleen naar IPv6 vroeg hoe dat zat, werd ik meteen zonder dat ik toestemming had gegeven, overgeschakeld, en kon ik geen IPv4 adressen meer benaderen. Van alles geprobeerd op mijn machine en de modem instellingen, maar het werd niet ondersteund. Personeel melde ook dat het of IPv4 alleen, of IPv6 was, en er geen full stack of dual stack aanwezig was voor beiden, en toen maar weer terug naar IPv4 geschakeld. IPv6 moet ik dus nu via een VPN doen, want ik weet tot op heden niet of Ziggo dit nu wel ondersteund, maar gezien de forum post die ik al eerder had gepost ergens, lijkt dat nog niet het geval te zijn, helaas.
Ik denk dat we de komende 10 jaar nog wel aan dual stack vastzitten, heel wat sites en systemen lopen alleen over IPv4
Daar ben ik ook bang voor.
Zelf heb ik mijn servers op IPv4 en IPv6 draaien, en een paar helaas die enkel IPv4 ondersteunen (software), maar goed, ik ben in ieder geval voorbereid :)
Vooral die IP-adressen van IP6 zijn zo werkbaar. Zal me verbazen als het ooit mainstream wordt.
IPv6 support op een platform als Azure is nog huilen met de pet op. Wij doen een overheidsproject op het werk waarbij de data in Nederland moet blijven. Dit kan wel met Azure, maar niet met IPv6. Omdat IPv6 support op Azure App Services beperkt is moet je met complexe constructies zoals Azure Front Door of andere services werken, waarbij je data buiten Nederland kan komen.
Precies dit. Ben nog steeds op zoek naar de beste oplossing voor een eenvoudige "vertaling" van ipv6 naar ons ouderwetse ipv4 netwerk. Upgraden van een vnet is een drama.
Op AWS is het sinds kort wat beter, behalve intern. Vaak eindig je toch in bed met een CDN om van buitenaf over IPv6 bereikbaar te zijn.
IPv6 is bij Microsoft sowieso wel een dingetje.

Vandaag nog een vreemde issue dat een PC weigerde verbinding te maken met een domain controller (dat hele bedrijfsnetwerkje heeft zowel IPv4 als IPv6).

IPv6 uitzetten op de client en poef, er was weer verbinding met de DC en het profiel werd ineens wel geladen.

Gewoon op de meest recente W10 en Windows Server |:(
IPv6 is bij Microsoft sowieso wel een dingetje.

Vandaag nog een vreemde issue dat een PC weigerde verbinding te maken met een domain controller (dat hele bedrijfsnetwerkje heeft zowel IPv4 als IPv6).

IPv6 uitzetten op de client en poef, er was weer verbinding met de DC en het profiel werd ineens wel geladen.

Gewoon op de meest recente W10 en Windows Server |:(
Al sinds een paar jaar een issue.
Vaak niet, en dan ineens weer wel, onbegrijpelijk.
Ik zet tegenwoordig gewoon actief ipv6 uit op de clients waarvan ik zeker weet dat ze het (nog) niet nodig hebben
80% van onze servers gaan onderling prima op ipv6, zolang ze intern blijven ( wat grotendeels ook wel zo is )
Maar zodra er gemengde externe verbindingen komen kijken, heeft MS het niet op orde.

tegen de tijd dat het écht noodzakelijk is, zijn die werkstations al wel weer vervangen ;)
De ervaring leert dat als dit soort 'oplossingen' werkt, dat de IPv6 routering en firewall niet in sync is met de IPv4 versie. Eerste schot: de firewall instellingen. Tweede schot: de routering.

Natuurliijk ligt het dan aan IPv6. Maar vooral omdat het niet is afgeconfigureerd.
wat is het probleem van data not at rest die buiten nederland (EU , lands grenzen zijn zo achterhaald je kunt niet eens veilig 2 datacenters in NL zetten risoco zone is meestal groter dan NL (300KM uit elkaar) als je naar seriueze DC kijkt ) komt ?

Je sluit aan op internet dus per definitie gaat al je data buiten nederland ??
Nu ziggo nog… (bridge mode)
Aangezien Ziggo met DS-LITE werkt, en dus erg afhankelijk is van de clientapparatuur én je geen publiek bereikbaar IPv4-adres meer hebt vanwege CG-NAT, denk ik niet dat het snel bij Ziggo zal komen in bridge mode.

Zonder bridge werkt IPv6 al prima, maar voor veel Tweakers is dat natuurlijk geen optie.
Nederland zit volgens Google op 35% adoptie.
https://www.google.com/in...per-country-ipv6-adoption
En volgens facebook maar op 30%
https://www.facebook.com/ipv6/?tab=ipv6_country

[Reactie gewijzigd door menzo op 24 juli 2024 04:12]

Belgie al tijden over de 50%, nu 54,85%
India zit nu al over de 60%.
In Duitsland 53%. Zal voornamelijk komen door de nieuwe glasaanbieders. Zij leveren primair ipv6. En ipv4 via nat als fallback. 1&1 levert ook ipv6 over het dsl netwerk, samen met een ipv4. Maar hier heeft ipv4 de voorkeur. Natuurlijk kan de gebruiker dit zelf aanpassen, maar de meeste gebruikers is het P&P. Werkt het? ja. Afblijven en nooit meer aankomen.
Jam is geen jam als er te weinig fruit inzit.

Gewoon vastleggen dat alleen een verbinding met IPv6 'internet' mag heten en dat als 'echt internet' vergeleken wordt met een IPv4 verbinding er een disclaimer bij moet in de trant van:
"Deze verbinding is gebaseerd op oude technieken en levert geen volledig internet".

De meeste Telco's/ISPs zijn marketing gedreven. Die willen hun mooie slogans niet bederven met anti-reclame.
Probleem is dat de ISPs er misschien wel niets aan kunnen doen. Ja, ze moeten hun netwerk op IPv6 hebben, maar als er diensten/websites op internet nog enkel IPv4 hebben, dan moet je toch verbinden met IPv4. De provider kan dat zo makkelijk mogelijk maken, maar is toch beperkt door de mogelijkheden van de techniek.

Tegen de tijd dat voldoende websites/diensten IPv6 ondersteunen, zullen providers waarschijnlijk vanzelf gaan adverteren met hun goede IPv6 ondersteuning, als ze weten dat hun concurrent dat niet kan bieden.
Je kunt IPv4 over IPv6 sturen. Dat is makkelijk aan te bieden.
En dual stack is ook prima te doen.
Zegt Ziggo vandaag tegen me, (gezien ik het modem terug wilde naar ipv4)..
ja maar ipv6 is veiliger.. :+

Zit ik naar de ipv6 nummertjes te kijken, denk ik, waarom zie ik dan een ipv6 dat routeerbaar is tot me pc.
Kennelijk kennen ze ULA v6 niet.
Probeer je een poort forwardje in te stellen, kan wel, maar gaat nooit werken, althans, niet bij ziggo.

Als er iets slecht is daar, is het wel de DS-lite ipv6 software in de modems..
Het internet is gebouwd om routeerbaar te zijn tot je PC. Toen de IP-adressen opraakten, is NAT ontwikkeld als hack om te zorgen dat iedereen nog kon internetten.

Oo veel universiteiten krijg je op de WiFi ook gewoon een publiek routeerbaar IP-adres. Daar is niks onveiligs aan, want je hebt toch een firewall nodig.

Heb je geen firewall of staat 'ie uit, dan ben je mogelijk/waarschijnlijk kwetsbaar voor een zogenaamde NAT slipstreaming attack, waarmee een aanvaller in het slechte geval ieder apparaat op je netwerk kan benaderen, en in het beste geval iedere poort op je PC, door simpelweg een script in te laden van een website.

IPv6 is niet veiliger dan IPv4, maar ook weer niet onveiliger. Voor Ziggo is het natuurlijk goedkoper om geen IPv4-adressen uit te delen, en dat zal wel de echte reden zijn dat ze hiervoor pushen.

Met de manier waarop Ziggo dual stack heeft ingesteld gaan port forwards over v4 inderdaad niet werken. Ze zouden theoretisch DS-LITE kunnen doen zonder CG-NAT, maar ze vertikken het gewoon.
Met de manier waarop Ziggo dual stack heeft ingesteld gaan port forwards over v4 inderdaad niet werken.
En daarmee breken ze compatibiliteit met een boel legacy (of zelfs nog vrij recente) software die geen IPv6 ondersteunt en die gebruik maakt van inkomende connecties. Het hele punt van dual stack is nou juist dat je naast de courante IPv6 oplosing voor de toekomst een volwaardige IPv4 connectie kunt handhaven voor backwards compatibility. Zou Ziggo sieren als ze naast dat gammele DS-Lite ook gewoon echt dual-stack aan zouden bieden.
Zou Ziggo sieren als ze naast dat gammele DS-Lite ook gewoon echt dual-stack aan zouden bieden
Voor alle duidelijkheid: uit de reacties van R4gnax begrijp ik dat zijn probleem vooral is dat port-forwarding niet werkt bij Ziggo. Dat is geen probleem van DS-Lite. Dat is een probleem van Ziggo, die in hun netwerk een webserver moeten zetten waarmee hun klanten port-forwarding kunnen configureren. DS-Lite is even gammel, of even goed, als gewoon NAT op je eigen router, en daarop werkt port-forwarding ook gewoon. Ziggo weigert gewoon bepaalde functionaliteit te bieden. Of ze zijn zo dom geweest voor een leverancier te kiezen die dat niet in zijn software ingebouwd heeft.
Het hele punt van dual stack is nou juist dat je naast de courante IPv6 oplosing voor de toekomst een volwaardige IPv4 connectie kunt handhaven voor backwards compatibility.
Het hele punt van IPv6 is nu net dat dat niet kan. De IPv4 adressen zijn op, en dus moeten er truukjes en suboptimale oplossingen gebruikt worden om mensen toch het gevoel te geven dat het hele netwerk dual-stack volwaardig IPv4 is. NAT is één zo'n oplossing, en dat bestaat al jaaaren. Maar dat is niet altijd en overal voldoende. Dus is er nu ook CGNAT, DS-Lite, etc. Allemaal manieren om veel meer dan 4 miljard computers op internet te kunnen aansluiten terwijl er maar 4 miljard adressen zijn. Dan is het onmogelijk om iedereen een volwaardige IPv4 aansluiting te geven. Want daarvan zijn er maar 4 miljard (en in de praktijk zijn er veel minder dan dat werkelijk bruikbaar). Dat je het idee hebt dat jouw NAT configuratie 'volwaardig' is, komt omdat het al lang genoeg bestaat dat er voor alle problemen die de gewone consument tegenkomt een workaround is gemaakt. En omdat je aan de onvolkomenheden en onvolwaardigheden (port-forwarding *kuch*) gewend bent geraakt, en ze als normaal beschouwt.

Edit: foute formulering

[Reactie gewijzigd door RJG-223 op 24 juli 2024 04:12]

Het hele punt van IPv6 is nu net dat dat niet kan. De IPv4 adressen zijn op, en dus moeten er truukjes en suboptimale oplossingen gebruikt worden om mensen toch het gevoel te geven dat het hele netwerk dual-stack volwaardig IPv4 is.
Nee. Je zult voldoende mensen hebben waar volwaardig IPv4 niet noodzakelijk is. Het gros kan makkelijk via 'truukjes' zoals DS-Lite etc. verbinden met legacy IPv4 diensten die enkel outgoing connecties en dat bespaart IPv4 verbindingen die daarna gebruikt kunnen worden in gevallen waar aangegeven wordt dat ook incoming IPv4 connecties nodig zijn, voor een echte dual stack verbinding.
Daar zou een ISP zelfs gewoon een (kleine; bescheiden) meerprijs op kunnen zetten, zodat we niet de situatie krijgen dat iedereen het 'voor de heb' er bij neemt.

[Reactie gewijzigd door R4gnax op 24 juli 2024 04:12]

Nee. Je zult voldoende mensen hebben waar volwaardig IPv4 niet noodzakelijk is. Het gros kan makkelijk via 'truukjes' zoals DS-Lite etc. verbinden met legacy IPv4 diensten die enkel outgoing connecties en dat bespaart IPv4 verbindingen die daarna gebruikt kunnen worden in gevallen waar aangegeven wordt dat ook incoming IPv4 connecties nodig zijn, voor een echte dual stack verbinding.
Daar zou een ISP zelfs gewoon een (kleine; bescheiden) meerprijs op kunnen zetten, zodat we niet de situatie krijgen dat iedereen het 'voor de heb' er bij neemt.
Iets dat met NAT werkt is per definitie niet volwaardig. Het kan zijn dat je in de praktijk geen last hebt van de beperkingen, maar volwaardig is het niet. Dus een thuisnetwerkje met NAT en een enkel publiek IP ook niet. Het probleem waar jij last van hebt is niet DS-Lite, het is het feit dat Ziggo DS-Lite (feitelijk dus CGNAT als ik het goed heb) gebruikt, zonder een manier om port-forwarding op hun CGNAT machine in te stellen. Dan moet je niet DS-Lite afkraken, dan moet je Ziggo afkraken.

En nogmaals: er is volgens mij geen technisch probleem waarom met DS-Lite (of CGNAT) port-forwarding niet kan. Het probleem is alleen dat de ISP een manier moet aanbieden om het in te stellen. En dat doet Ziggo blijkbaar niet. Dat is niet het probleem van DS-Lite of van CGNAT. Het verschil met jouw router, is dat die wél een manier heeft om het in te stellen.

Overigens kan ik (gegeven het feit dat ze voor DS-Lite gekozen hebben) Ziggo wel een beetje begrijpen. Het probleem wat ze hebben, is dat port-forwarding zowel op hun CGNAT systeem als op jouw thuisrouter goed ingesteld moet zijn, anders werkt het niet. Het is voor hun waarschijnlijk makkelijker om het helemaal uit te zetten, dan om continu consumenten aan de lijn te krijgen die het verkeerd hebben ingesteld, en daarover klagen. Dat kost handenvol met geld. Of ze klagen op fora, onterecht over Ziggo, terwijl ze zelf de port-forwarding niet goed ingesteld hebben. Dus ik kan me voorstellen, dat totdat er een protocol geïmplementeerd is waardoor de router de port-forwarding instelling aan het CGNAT systeem kan doorgeven, of andersom, ze het gewoon uit laten staan.
Iets dat met NAT werkt is per definitie niet volwaardig.
De IPv4 verbinding die de ISP levert kan mits zonder CGNAT of DS-Lite geleverd gewoon als 'volwaardig' gezien worden, en vanaf dan is het aan jou wat je er mee doet. Plemp je er direct een PC achter. Gebruik je port-forwarding met een eigen router; gebruik je een DMZ; whatever.

De verbinding is vanuit de eindgebruiker niet meer volwaardig zodra de ISP daar met CGNat of DS-Lite tussen gaat zitten en bepaalde aspecten die noodzakelijk zijn voor het correct functioneren, niet meer toegankelijk maakt.

(Overigens; ik zit bij Ziggo bridged en heb een 'volwaardige' IPv4 verbinding. Geen CGNat wat opbouw van inkomende connecties vernachelt. En daar ben ik blij om, want ik heb het nog steeds nodig voor o.a. de multiplayer van een aantal games.)
De IPv4 verbinding die de ISP levert kan mits zonder CGNAT of DS-Lite geleverd gewoon als 'volwaardig' gezien worden, en vanaf dan is het aan jou wat je er mee doet. Plemp je er direct een PC achter. Gebruik je port-forwarding met een eigen router; gebruik je een DMZ; whatever.
OK, dat klopt strikt genomen. Maar dat lijkt me niet echt relevant als iedereen er in de praktijk meerdere machines achter wil hangen. Dan hebben al die machines geen volwaardige IPv4 verbinding. Het maakt dan niet meer uit of achter de router wel of niet een volwaardige IPv4 verbinding zit. Het gaat er dan om of de gekozen/geboden oplossing in de praktijk dicht genoeg bij een volwaardige IPv4 verbinding komt, dat mensen er niet noemenswaardig last van hebben.
De verbinding is vanuit de eindgebruiker niet meer volwaardig zodra de ISP daar met CGNat of DS-Lite tussen gaat zitten en bepaalde aspecten die noodzakelijk zijn voor het correct functioneren, niet meer toegankelijk maakt.
Inderdaad. En het sleutelgedeelte van die bewering is: en bepaalde aspecten die noodzakelijk zijn voor het correct functioneren, niet meer toegankelijk maakt. Eigenlijk gebeurt zoiets ook al als poort 25 door de provider dicht gezet wordt, bijvoorbeeld. Het probleem is niet DS-Lite of CGNAT, het probleem is dat de provider bepaalde belangrijke aspecten van een volwaardige IPv4 verbinding onmogelijk maakt. Maar dat kan ook evengoed zonder DS-Lite. Bijvoorbeeld als een provider (en die zijn er in de wereld) überhaupt geen (of zeer beperkt) inkomende verbindingen toestaat, en die aan de ingang van het netwerk allemaal blokkeert.
(Overigens; ik zit bij Ziggo bridged en heb een 'volwaardige' IPv4 verbinding. Geen CGNat wat opbouw van inkomende connecties vernachelt. En daar ben ik blij om, want ik heb het nog steeds nodig voor o.a. de multiplayer van een aantal games.)
OK. Ik kreeg de indruk dat je zelf last had van DS-Lite, omdat je er zo negatief over was. Of heb je er bij Ziggo last van gehad ?
Het probleem is niet DS-Lite of CGNAT, het probleem is dat de provider bepaalde belangrijke aspecten van een volwaardige IPv4 verbinding onmogelijk maakt. Maar dat kan ook evengoed zonder DS-Lite.
Klopt. Ik denk dat we het gewoon eens zijn, maar even langs er elkaar heen staken. DS-Lite of CGNAT zijn als standaarden niets mis mee. Het zijn de implementaties onder diezelfde namen bij individuele ISPs, waar de problemen kunnen ontstaan - omdat ISPs al dan niet bewust deze maar half implementeren door belangrijke configuratie-aspecten die het voor meer scenario's werkbaar zouden moeten houden, weg te laten of af te schermen.
OK. Ik kreeg de indruk dat je zelf last had van DS-Lite, omdat je er zo negatief over was. Of heb je er bij Ziggo last van gehad ?
Helemaal in het begin toen ik in mijn woning introk. Zo'n slordige 5-6 jaar geleden. Modem heb ik toen om meer redenen dan enkel het DS-Lite gebeuren in bridge laten zetten (kon je destijds nog niet zelf regelen - moest via de service desk) om van het gedonder af te zijn.
Bij ZIggo werkt maar 1 ding perfect en dat is bridge mode met je eigen router er achter ,
Ook dat is niet perfect. }>
enige wat werkt perfect != is perfect

Op dit item kan niet meer gereageerd worden.