Het grote IPv6 topic

[Nakebod]

Hier hebben we er niets aan maar... Frankrijk heeft sinds 2 dagen 85% IPv6 verkeer bij Google: Free Mobile heeft IPv6 nu standaard voor iedereen aangezet. Zo te lezen hadden ze het al langer, maar moesten gebruikers het handmatig aanzetten.

Nu nog in Nederland. Ooit

[Snow_King]

Nakebod schreef op maandag 19 mei 2025 @ 21:20:
Hier hebben we er niets aan maar... Frankrijk heeft sinds 2 dagen 85% IPv6 verkeer bij Google: Free Mobile heeft IPv6 nu standaard voor iedereen aangezet. Zo te lezen hadden ze het al langer, maar moesten gebruikers het handmatig aanzetten.

Nu nog in Nederland. Ooit

Odido and Vodafone have left the chat...

KPN heeft het op vast en mobiel goed voor elkaar. Ziggo op vast ook, maar Odido en Vodafone blijven een ramp.

[Blokker_1999]

Wel grappig om te zien hoe we in Belgie zijn blijven stilstaan. Jarenlang waren we koploper in IPv6 adoption nadat de twee grote ISPs hun vaste aansluitingen IPv6 capable hadden gemaakt, maar sindsdien is er weinig veranderd hier en worden we dus ingehaald door andere landen.

[ed1703]

Blokker_1999 schreef op donderdag 22 mei 2025 @ 06:22:
Wel grappig om te zien hoe we in Belgie zijn blijven stilstaan. Jarenlang waren we koploper in IPv6 adoption nadat de twee grote ISPs hun vaste aansluitingen IPv6 capable hadden gemaakt, maar sindsdien is er weinig veranderd hier en worden we dus ingehaald door andere landen.

Tja, in Nederland is dat toch wel hetzelfde verhaal. Je kan nog zo mooi met alle ISP's IPv6 gaan aanzetten (waarbij oa ziggo op hun mainwebsite ook geen IPv6 aan heeft staan), maar als grote partijen zoals bol.com, coolblue en marktplaats er niets mee doen schiet je er ook weinig mee op.
Managers kijken vooral wat het gaat opleveren en wat het kost aan geld en uren om het aan te zetten zodat het ook volledig zonder IPv4 kan draaien. Als het resultaat hetzelfde is als zonder, sta je als IT afdeling al gelijk met 1-0 achter en komt het er gewoonweg niet, want het werkt zonder ook. Blik naar die toekomst is er niet, er zijn andere prioriteiten en dus ook geen uren.

[Roetzen]

ed1703 schreef op donderdag 22 mei 2025 @ 07:58:
[...]

Managers kijken vooral wat het gaat opleveren en wat het kost aan geld en uren om het aan te zetten zodat het ook volledig zonder IPv4 kan draaien. Als het resultaat hetzelfde is als zonder, sta je als IT afdeling al gelijk met 1-0 achter en komt het er gewoonweg niet, want het werkt zonder ook. Blik naar die toekomst is er niet, er zijn andere prioriteiten en dus ook geen uren.

Het zijn nu de bedrijven die de zaak ophouden en inderdaad, lange termijn visie ontbreekt. Als we IPv4 zouden kunnen uitschakelen en alleen nog IPv6 zouden hebben zou het voor iedereen goedkoper en makkelijker zijn. Dual Stack is inefficient, je moet twee systemen naast elkaar onderhouden. Het zou veel goedkoper en efficiënter zijn als er maar één systeem was. Maar ja, zo lang dat nog niet zo is, is het voor niemand in de korte termijn aantrekkijk om te investeren. Het werkt toch? Hier zou een overheid in kunnen sturen. Maar helaas zie ik dat met de huidige regering niet gebeuren.

[bart.koppers]

Roetzen schreef op donderdag 22 mei 2025 @ 17:59:
[...]

Het zijn nu de bedrijven die de zaak ophouden en inderdaad, lange termijn visie ontbreekt. Als we IPv4 zouden kunnen uitschakelen en alleen nog IPv6 zouden hebben zou het voor iedereen goedkoper en makkelijker zijn. Dual Stack is inefficient, je moet twee systemen naast elkaar onderhouden. Het zou veel goedkoper en efficiënter zijn als er maar één systeem was. Maar ja, zo lang dat nog niet zo is, is het voor niemand in de korte termijn aantrekkijk om te investeren. Het werkt toch? Hier zou een overheid in kunnen sturen. Maar helaas zie ik dat met de huidige regering niet gebeuren.

Veranderen is moeilijk, zeker als techniek het gewoon doet.
(“If it aint broken, why fix it?”)

Zakelijk houdt hier niks tegen in mijn optiek - de voordelen zijn simpelweg niet groot genoeg. Zakelijk kijkt naar kosten icm de baten en naar langere termijn.
En zolang er geen groot probleem is, vindt de verandering daarom geleidelijk plaats.

Er is helemaal geen politiek nodig (ajb niet…) voor deze verandering. Waarom zou je? IPv4 adressen worden vanzelf eenvoudigweg te duur.

De drijvende kracht bestaat uit meer kans op kostenbesparingen met IPv6, icm een beter serviceniveau.

En minder luie systeembeheerders misschien 🤔 😜

Komt goed.

[Roetzen]

bart.koppers schreef op zaterdag 24 mei 2025 @ 12:11:
[...]


Veranderen is moeilijk, zeker als techniek het gewoon doet.
(“If it aint broken, why fix it?”)

Omdat het niet zo blijft. IPv4 zal het niet "gewoon" blijven doen en eigenlijk doet het dat nu al niet meer nu sommige NL providers overgestapt zijn op CGNAT. Dan zit de eindgebruiker achter dubbel NAT en dat werkt niet echt lekker voor sommige toepassingen. Vooralsnog bieden de providers die op CGNAT over zijn gegaan hun klanten nog de mogelijkheid tot een "dynamisch" adres en zelfs nog gratis, maar voor hoe lang nog?

Zakelijk houdt hier niks tegen in mijn optiek - de voordelen zijn simpelweg niet groot genoeg. Zakelijk kijkt naar kosten icm de baten en naar langere termijn.

Dat van die "lange termijn" val behoorlijk tegen. Ik heb nog een aardige anekdote uit 1992. Een speciaal meetapparaat waarvan de hardware en de software door mij was ontworpen was bijna klaar. Nog een paar testjes. Mijn baas kwam in mijn nek hijgen en vroeg wat ik aan het doen was. Ik zei: "ik doe nog even wat testjes om zeker te weten dat het na 1 jan 2000 ook nog goed werkt." WAT? Dat is over ACHT jaar!. Werkt het verder goed? "Ja" zei ik. Stop daar dan mee., pak het in en verstuur het naar de klant zodat ik kan faktureren! Dat is meer dan 30 jaar geleden maar ik vrees dat er wat die houding betreft niet heel veel veranderd is. Het management kijkt bijna alleen naar de korte termijn.

En zolang er geen groot probleem is, vindt de verandering daarom geleidelijk plaats.

Geleidelijk... Ja het ging een tijd geleidelijk omhoog. Maar nu is de vaart er echt uit. Het staat nagenoeg stil.

Er is helemaal geen politiek nodig (ajb niet…) voor deze verandering. Waarom zou je? IPv4 adressen worden vanzelf eenvoudigweg te duur.

De prijs van IPv4 is al lang weer over de piek heen. Het stond ooit tegen de €60 per adres maar nu is het gezakt tot rond de €40. Voor providers die tienduizenden adressen nodig hebben nog steeds erg duur maar voor de rest die aan één of een handjevol adressen genoeg heeft geen groot probleem.

De drijvende kracht bestaat uit meer kans op kostenbesparingen met IPv6, icm een beter serviceniveau.

Tja, veel is er van die drijvende kracht op dit moment niet te merken helaas...

[Roetzen]

John Vanderaart beklaagt zich in zijn column van vandaag dat hij in zijn verblijf in Frankrijk wel goedkoop internet heeft, maar geen "normaal" IP adres. Het wordt door provider SFR middels een "handige manier" door meerdere routers gedeeld. Wat zou hij daar mee bedoelen? De enige manier die ik ken is CGNAT.

Maar het lijkt er dus op dat John nog nooit van IPv6 heeft gehoord?

https://www.pcactive.nl/u...-column-goedkoop-internet

[Jerrythafast]

Hij moest eens weten hoe makkelijk het zou zijn geweest om via zijn "Goedkope internet" in Frankrijk te verbinden met die "internetservice" als die service van 'm via IPv6 te bereiken was. Poortje open in de firewall en gaan

Maar misschien (altijd van het positieve uitgaan hè) was dat "andere protocol" waar hij midden in de nacht over dacht wel iets met een 6...

[Snow_King]

Ik heb sinds vorige week een iPad Pro met 5G, daarbij heb ik van KPN Mobiel Internet genomen, een data-only pakket met een 097-nummer.

Het is even een omweg, want je krijgt een fysieke SIM en wil je naar eSIM dan moet je een telefoon gebruiken om de SIM te activeren en daarna via de KPN app op de iPad daar de eSIM installeren. Hiervoor moet je dan een SMS ontvangen op de telefoon waar de SIM in zit.

Goed, ik heb dus GEEN IPv6 op deze eSIM bij KPN en dat lijkt heel sterk hier op: https://community.kpn.com...nternet-abonnement-614483

Ik heb contact gehad met KPN en het antwoord is: We hebben geen idee, ik kan dit niet in ons ticketsysteem aanmaken. Of ik een topic op de KPN community wil aanmaken met de hoop dat iemand het daar ziet die er iets aan kan doen voor mij. Heel vreemd…

Ergens zou de eSIM niet goed geprogrammeerd zijn waardoor er iets ontbreekt en ik dus geen IPv6 heb. Daar baal ik dus wel van, want mijn Homeassistant thuis is enkel via IPv6 bereikbaar evenals mijn NAS en Nextcloud die ik thuis heb draaien.

[duvekot]

Snow_King schreef op zondag 22 juni 2025 @ 19:56:
Ik heb sinds vorige week een iPad Pro met 5G, daarbij heb ik van KPN Mobiel Internet genomen, een data-only pakket met een 097-nummer.

Het is even een omweg, want je krijgt een fysieke SIM en wil je naar eSIM dan moet je een telefoon gebruiken om de SIM te activeren en daarna via de KPN app op de iPad daar de eSIM installeren. Hiervoor moet je dan een SMS ontvangen op de telefoon waar de SIM in zit.

Goed, ik heb dus GEEN IPv6 op deze eSIM bij KPN en dat lijkt heel sterk hier op: https://community.kpn.com...nternet-abonnement-614483

Ik heb contact gehad met KPN en het antwoord is: We hebben geen idee, ik kan dit niet in ons ticketsysteem aanmaken. Of ik een topic op de KPN community wil aanmaken met de hoop dat iemand het daar ziet die er iets aan kan doen voor mij. Heel vreemd…

Ergens zou de eSIM niet goed geprogrammeerd zijn waardoor er iets ontbreekt en ik dus geen IPv6 heb. Daar baal ik dus wel van, want mijn Homeassistant thuis is enkel via IPv6 bereikbaar evenals mijn NAS en Nextcloud die ik thuis heb draaien.

Klinkt alsof je een medewerker had die ff niet weet wat en hoe .. had je al nog een keertje gebeld in de hoop een andere medewerker te pakken te krijgen?

Of anders morgen naar een KPN winkel .. wie weet dat ze daar je ook eea kan regelen.

Ook wel bijzonder dat je niet rechtstreeks naar een eSIM kan .. en zorg dat je ergens die QR code voor je eSIM als backup hebt liggen. Bij Vodafone moet je een eSIM op een nieuwe toestel via de App instaleren .. maar dat is bij mij al een paar keer mis gegaan . Maar met de QR code echt nooit een probleem mee gehad.

[Snow_King]

duvekot schreef op zondag 22 juni 2025 @ 20:41:
[...]

Klinkt alsof je een medewerker had die ff niet weet wat en hoe .. had je al nog een keertje gebeld in de hoop een andere medewerker te pakken te krijgen?

Of anders morgen naar een KPN winkel .. wie weet dat ze daar je ook eea kan regelen.

Ook wel bijzonder dat je niet rechtstreeks naar een eSIM kan .. en zorg dat je ergens die QR code voor je eSIM als backup hebt liggen. Bij Vodafone moet je een eSIM op een nieuwe toestel via de App instaleren .. maar dat is bij mij al een paar keer mis gegaan . Maar met de QR code echt nooit een probleem mee gehad.

Dat idee had ik ook, maar ik wil ook niet eindeloos aan de telefoon hangen. Ik ga maar een nieuw topic openen en kijken wat er gaat gebeuren.

Bij KPN kan je geen backup van een QR-code maken omdat ik een fysieke SIM heb gekregen. Je moet dan via de post weer wat opnieuw opvragen bij ze.

[duvekot]

Snow_King schreef op maandag 23 juni 2025 @ 09:43:
[...]

Dat idee had ik ook, maar ik wil ook niet eindeloos aan de telefoon hangen. Ik ga maar een nieuw topic openen en kijken wat er gaat gebeuren.

Succes .. ik ben benieuwd

Bij KPN kan je geen backup van een QR-code maken omdat ik een fysieke SIM heb gekregen. Je moet dan via de post weer wat opnieuw opvragen bij ze.

Ik lees dat ze voor particulieren geen QR code doen "omdat het fraude gevoelig" zou zijn . Maar voor zakelijke klanten kan je wel een QR code genereren waarmee een eSIM op een ander toestel geïnstalleerd kan worden door een scan.

En die fysieke SIM wordt volgens mij direct gedeactiveerd als je er een eSIM van gemaakt hebt ..

[Snow_King]

duvekot schreef op maandag 23 juni 2025 @ 09:58:
[...]

Succes .. ik ben benieuwd

[...]

Ik lees dat ze voor particulieren geen QR code doen "omdat het fraude gevoelig" zou zijn . Maar voor zakelijke klanten kan je wel een QR code genereren waarmee een eSIM op een ander toestel geïnstalleerd kan worden door een scan.

En die fysieke SIM wordt volgens mij direct gedeactiveerd als je er een eSIM van gemaakt hebt ..

Inmiddels reactie van KPN op het forum en met die instructies een ticket laten aanmaken via de telefonische helpdesk. Ticket is aangemaakt en nu is het wachten.

Ik wil juist bij mijn NAS, HomeAssistant en Nextcloud kunnen die ik heel bewust IPv6-only gemaakt heb. Draaien thuis en via mijn 5G met KPN kan ik er overal bij. En uiteraard vanaf kantoor en andere plekken waar ik gewoon native IPv6 heb.

Wat wel jammer is: Hotels of andere public WiFi heb ik nog nooit IPv6 gehad...

[duvekot]

Snow_King schreef op donderdag 26 juni 2025 @ 09:52:
[...]

Inmiddels reactie van KPN op het forum en met die instructies een ticket laten aanmaken via de telefonische helpdesk. Ticket is aangemaakt en nu is het wachten.

Ik wil juist bij mijn NAS, HomeAssistant en Nextcloud kunnen die ik heel bewust IPv6-only gemaakt heb. Draaien thuis en via mijn 5G met KPN kan ik er overal bij. En uiteraard vanaf kantoor en andere plekken waar ik gewoon native IPv6 heb.

Wat wel jammer is: Hotels of andere public WiFi heb ik nog nooit IPv6 gehad...

Voor alles buiten de deur heb ik een Wireguard VPN naar huis (via IPv4 .. IPv6 Wireguard nog niet getest) .. zodat ik zelfs in Australië gewoon NL Ziet kan kijken of via WiFi bellen gewoon bereikbaar ben op mijn Nederlandse nummer zonder roaming.

[RobertMe]

Snow_King schreef op donderdag 26 juni 2025 @ 09:52:
Wat wel jammer is: Hotels of andere public WiFi heb ik nog nooit IPv6 gehad...

Wat @duvekot aangeeft. Gewoon een VPN gebruiken dan. Wireguard kan prima overweg met IPv4 & IPv6, zowel om met het endpoint te babbelen als om te tunnelen. En doordat het IPv6 is heb je dus ook geen verschil tussen intern en extern, geen NAT, etc etc.. Maar snijdt natuurlijk aan twee kanten. Doordat je de tunnel hebt kun je IPv6 gebruiken en dus ook via IPv6 verbinden met apparaten thuis of extern die alleen IPv6 doen. Maar doordat je de tunnel naar thuis al hebt zou je de apparaten thuis ook via een intern (al dan niet IPv4) adres kunnen benaderen. Via beide routes geeft een VPN dus een oplossing voor dat probleem.

Enige dingetje is dan dat Wireguard met static IPs werkt. En wil je via IPv6 "naar buiten toe" moet (/"moet") je dus ook een GUA instellen (of de "server" moet NAT doen ), terwijl je waarschijnlijk geen static IP/prefix krijgt van de ISP. Potentieel moet je dan dus periodiek alle endpoints (/"servers" en "clients") nalopen om het IP adres aan te passen.

[Roetzen]

Snow_King schreef op donderdag 26 juni 2025 @ 09:52:
[...]

Wat wel jammer is: Hotels of andere public WiFi heb ik nog nooit IPv6 gehad...

Camping Boszicht in Laag Soeren en het H.F. Witte centrum in de Bilt

Ze hebben allebei IPv6 op de Wifi. De eerste (via KPN) waarschijnlijk bij toeval, de tweede (via Ziggo) omdat de HCC daar vaak bijeenkomsten heeft en de HCC het heeft "geregeld".

Dat zijn tot dusver de enige (semi) openbare WiFi netwerken waar ik IPv6 heb gevonden.

[RobertMe]

In de horecazaak van familie van mij is IPv6 ook beschikbaar op het (gasten) wifi netwerk.

Mogen jullie raden wie daar het netwerk beheert

[Snow_King]

RobertMe schreef op donderdag 26 juni 2025 @ 11:23:
[...]

Wat @duvekot aangeeft. Gewoon een VPN gebruiken dan. Wireguard kan prima overweg met IPv4 & IPv6, zowel om met het endpoint te babbelen als om te tunnelen. En doordat het IPv6 is heb je dus ook geen verschil tussen intern en extern, geen NAT, etc etc.. Maar snijdt natuurlijk aan twee kanten. Doordat je de tunnel hebt kun je IPv6 gebruiken en dus ook via IPv6 verbinden met apparaten thuis of extern die alleen IPv6 doen. Maar doordat je de tunnel naar thuis al hebt zou je de apparaten thuis ook via een intern (al dan niet IPv4) adres kunnen benaderen. Via beide routes geeft een VPN dus een oplossing voor dat probleem.

Enige dingetje is dan dat Wireguard met static IPs werkt. En wil je via IPv6 "naar buiten toe" moet (/"moet") je dus ook een GUA instellen (of de "server" moet NAT doen ), terwijl je waarschijnlijk geen static IP/prefix krijgt van de ISP. Potentieel moet je dan dus periodiek alle endpoints (/"servers" en "clients") nalopen om het IP adres aan te passen.

Ik snap hoe VPN's werken :-)

Mijn punt was meer dat ik daar IPv6 gewoon nooit tegen kom. Dan moet ik een VPN aanzetten. Maar moet zeggen dat ik in het buitenland veelal gewoon op 4G/5G blijf met mijn telefoon en vanaf nu dus ook iPad. Geen gedoe met WiFi aanslingeren.

[bart.koppers]

RobertMe schreef op donderdag 26 juni 2025 @ 11:23:
[...]

Enige dingetje is dan dat Wireguard met static IPs werkt. En wil je via IPv6 "naar buiten toe" moet (/"moet") je dus ook een GUA instellen (of de "server" moet NAT doen ), terwijl je waarschijnlijk geen static IP/prefix krijgt van de ISP. Potentieel moet je dan dus periodiek alle endpoints (/"servers" en "clients") nalopen om het IP adres aan te passen.

Je bedoelt met dan “enig dingetje” dan dat de Wireguard (server) een fixed GUA moet hebben, zodat de verbinding gelegd kan worden?
(En de firewall de UDP poort open heeft staan etc etc).

Of begrijp ik je/het verkeerd?

Op zichzelf is dat al wat onhandig (poorten openzetten, fixed IP), vind ik, dus geef voorkeur aan Zerotier, Netbird en (oke beetje dan, evt) Tailscale.

[RobertMe]

bart.koppers schreef op vrijdag 27 juni 2025 @ 16:14:
[...]


Je bedoelt met dan “enig dingetje” dan dat de Wireguard (server) een fixed GUA moet hebben, zodat de verbinding gelegd kan worden?
(En de firewall de UDP poort open heeft staan etc etc).

Of begrijp ik je/het verkeerd?

Op zichzelf is dat al wat onhandig (poorten openzetten, fixed IP), vind ik, dus geef voorkeur aan Zerotier, Netbird en (oke beetje dan, evt) Tailscale.

Niet alleen de server*. Daar waar bv OpenVPN gewoon DHCP doet richting de clients en de clients dus een IP vanaf de server krijgen moet je bij Wireguard zowel bij elke "node" een hardcoded IP adres instellen en ook "aan de nadere kant" bij elke peer instellen welk verkeer (/IP adressen) gerouteerd moeten worden naar die peer, dat dus potentieel alleen dat unieke IP is**. Dus op het moment dat ik op mijn telefoon een GUA instel, dat dus een GUA in een /64 binnen de prefix die ik van de ISP krijg is, dan ben ik afhankelijk van dat die GUA niet wijzigt. Wijzigt die wel moet ik zowel in de telefoon als in de router dat IP adres aanpassen (in de telefoon dus het "statische IP adres" voor de Wireguard interface, in de router de "AllowedAddress"). En "uiteraard" kan ik ook geen GUA gebruiken waarmee ik niet afhankelijk ben van wijzigingen aan de prefix, maar..., dan zou ik dus geen IPv6 connectiviteit hebben, of in ieder geval niet "het internet op" (tenzij ik de router / "server" zou laten NATen).

* Of nouja, Wireguard heeft geen server. Alle "nodes" zijn gelijk, alleen hebben sommigen een fixed port en mogelijk dat andere nodes een endpoint ingesteld naar hun IP + fixed port, maar ook beide uiteinden kunnen naar elkaar verwijzen met een endpoint, en elk endpoint kan meerdere peers hebben met een endpoint. Zo heb ik een mesh tussen mijn router thuis, die router bij familie, en een VPS. Dus mijn router verbind zowel rechtstreeks met de router bij familie als met de VPS. En de router bij familie verbind ook rechtstreeks met de router bij mij als met de VPS. Er is dus geen "server" en alle peers zijn gelijk.

** Mijn router met Wireguard hoeft alleen verkeer met bestemming het IP van mijn telefoon naar mijn telefoon te sturen, en geen ander verkeer. Terwijl in het geval van het "mesh" tussen de 2 routers en VPS naast het IP adres van de peer ook nog volledige subnets (de gewone ULA subnets aan die kant) over de tunnel worden gerouteerd.

Edit:
Even naar Netbird gekeken. Ik ken het project half, maar gezien ik een werkend mesh en zo heb niet echt naar gekeken. (+ dat ik in mijn geval het vast niet op een EdgeRouter kan zetten, terwijl WG zelf er wel op kan). Eerste DuckDuckGo hit is dit issue uit 2021, dat nog steeda open staat: https://github.com/netbirdio/netbird/issues/46 niet perse hoopvol. Maar er staat ook een verwijzing naar https://github.com/netbirdio/netbird/pull/1459 (gemerged in augustus 2024) dat weer wel iets doet. Waarbij Netbird een willekeurige ULA verzint en clients ook een IP binnen die ULA krijgen. Maar dan heb je dus wel alleen verbinding onderling en ik neem aan geen IPv6 internet connectiviteit (de situatie v.w.b. "telefoon die verbing opzet en ook internet op wilt).
Terwijl Netbird onderwater gewoon Wireguard als tunnel gebruikt en WG dus prima IPv6 doet. En Netbird dus puur een beheer laag er overheen is. I.p.v. dat je op meerdere systemen handmatig WG config files moet aanpassen / config moet doorvoeren, je handmatig public keys moet uitwisselen (en private keys genereren), adressen moet verzinnen en op meerdere plekken moet instellen, .... Heeft Netbird dus een management / configuratie deel op een hoger niveau. Waarbij private & public keys door Netbird worden uitgewisseld tussen de systemen, configuratie automatisch wordt toegepast, de control server een IP adres "bedenkt" voor de "client" en dat overal correct toepast, .... En AFAIK werkt Tailscale hetzelfde. Puur een laag over Wireguard heen die het management deel uit handen haalt.

[ Voor 24% gewijzigd door RobertMe op 27-06-2025 17:24 ]

[bart.koppers]

RobertMe schreef op vrijdag 27 juni 2025 @ 16:44:
[...]

Niet alleen de server*. Daar waar bv OpenVPN gewoon DHCP doet richting de clients en de clients dus een IP vanaf de server krijgen moet je bij Wireguard zowel bij elke "node" een hardcoded IP adres instellen en ook "aan de nadere kant" bij elke peer instellen welk verkeer (/IP adressen) gerouteerd moeten worden naar die peer, dat dus potentieel alleen dat unieke IP is**. Dus op het moment dat ik op mijn telefoon een GUA instel, dat dus een GUA in een /64 binnen de prefix die ik van de ISP krijg is, dan ben ik afhankelijk van dat die GUA niet wijzigt. Wijzigt die wel moet ik zowel in de telefoon als in de router dat IP adres aanpassen (in de telefoon dus het "statische IP adres" voor de Wireguard interface, in de router de "AllowedAddress"). En "uiteraard" kan ik ook geen GUA gebruiken waarmee ik niet afhankelijk ben van wijzigingen aan de prefix, maar..., dan zou ik dus geen IPv6 connectiviteit hebben, of in ieder geval niet "het internet op" (tenzij ik de router / "server" zou laten NATen).

* Of nouja, Wireguard heeft geen server. Alle "nodes" zijn gelijk, alleen hebben sommigen een fixed port en mogelijk dat andere nodes een endpoint ingesteld naar hun IP + fixed port, maar ook beide uiteinden kunnen naar elkaar verwijzen met een endpoint, en elk endpoint kan meerdere peers hebben met een endpoint. Zo heb ik een mesh tussen mijn router thuis, die router bij familie, en een VPS. Dus mijn router verbind zowel rechtstreeks met de router bij familie als met de VPS. En de router bij familie verbind ook rechtstreeks met de router bij mij als met de VPS. Er is dus geen "server" en alle peers zijn gelijk.

** Mijn router met Wireguard hoeft alleen verkeer met bestemming het IP van mijn telefoon naar mijn telefoon te sturen, en geen ander verkeer. Terwijl in het geval van het "mesh" tussen de 2 routers en VPS naast het IP adres van de peer ook nog volledige subnets (de gewone ULA subnets aan die kant) over de tunnel worden gerouteerd.

Edit:
Even naar Netbird gekeken. Ik ken het project half, maar gezien ik een werkend mesh en zo heb niet echt naar gekeken. (+ dat ik in mijn geval het vast niet op een EdgeRouter kan zetten, terwijl WG zelf er wel op kan). Eerste DuckDuckGo hit is dit issue uit 2021, dat nog steeda open staat: https://github.com/netbirdio/netbird/issues/46 niet perse hoopvol. Maar er staat ook een verwijzing naar https://github.com/netbirdio/netbird/pull/1459 (gemerged in augustus 2024) dat weer wel iets doet. Waarbij Netbird een willekeurige ULA verzint en clients ook een IP binnen die ULA krijgen. Maar dan heb je dus wel alleen verbinding onderling en ik neem aan geen IPv6 internet connectiviteit (de situatie v.w.b. "telefoon die verbing opzet en ook internet op wilt).
Terwijl Netbird onderwater gewoon Wireguard als tunnel gebruikt en WG dus prima IPv6 doet. En Netbird dus puur een beheer laag er overheen is. I.p.v. dat je op meerdere systemen handmatig WG config files moet aanpassen / config moet doorvoeren, je handmatig public keys moet uitwisselen (en private keys genereren), adressen moet verzinnen en op meerdere plekken moet instellen, .... Heeft Netbird dus een management / configuratie deel op een hoger niveau. Waarbij private & public keys door Netbird worden uitgewisseld tussen de systemen, configuratie automatisch wordt toegepast, de control server een IP adres "bedenkt" voor de "client" en dat overal correct toepast, .... En AFAIK werkt Tailscale hetzelfde. Puur een laag over Wireguard heen die het management deel uit handen haalt.

Bij WG hoeft op de client (de verbindende peer zo je wil) voorzover ik weet geen GUA IPv6 ingesteld te worden? ULA lijkt voldoende.

Zie bv de handleiding inz OPNsense op https://docs.opnsense.org...tos/wireguard-client.html
(Even roadwarrior als voorbeeld dan, heb het niet over s2s vpn)

En idd Netbird en Tailscale zijn eigenlijk integratie-lagen over het noise-protocol (van Wireguard).
Geen idee hoe die omgaan met ipv6 over wireguard - heb het vermoeden dat het niet fullblown/via GUA wordt gebruikt, maar daar kan een ander vast meer over zeggen.

Moet wel zeggen dat eea bijv bij zerotier veel simpeler gedaan kan worden - het is alleen wat minder bekend (en heeft - net als beide voorgaande - natuurlijk wel centrale hubs nodig om de initiele verbindingen te leggen - bij zerotier zijn dat de “planets”, en/of evt “moons”)

Wil je helemaal “los” van andere, en alles echt helemaal zelf organiseren/inregelen, dan zijn er vlgs mij ook opties - maar valt misschien wat al te buiten ipv6 topic hier.

[RobertMe]

bart.koppers schreef op vrijdag 27 juni 2025 @ 21:48:
[...]


Bij WG hoeft op de client (de verbindende peer zo je wil) voorzover ik weet geen GUA IPv6 ingesteld te worden? ULA lijkt voldoende.

Een GUA hoeft inderdaad niet. Maar als je IPv6 wilt internetten..., is een GUA "wel handig". Anders internet je alsnog via IPv4 en heb je IPv6 alleen om te "LANen". (Of je moet dus NAT doen op de "server")

[Jerrythafast]

Ik vind bovenstaande over WireGuard wel een interessante discussie. Was afgelopen week in de US voor een congres en ben het grootste deel van de tijd via WireGuard met mijn thuisnetwerk verbonden gebleven, via ingebouwde WireGuard ondersteuning van Fritz!OS 8.02. De 'buitenkant' van de tunnel liep voor zover ik heb gezien steeds over IPv4 (helemaal geen IPv6 gezien daar... ping was overigens ~100ms vanuit Boston naar mijn KPN-lijn thuis, voor de geïnteresseerden).

Internetten via de WG tunnel ging alleen via IPv4, maar "LANen" ging wel prima via IPv6, omdat mijn devices een (fixed en ook niet in de FritzBox interface aanpasbaar) ULA adres (/128) kregen. De FritzBox kan op IPv6 (nog) niet NATen om toch IPv6 internettoegang te geven via WireGuard. En er is ook nergens een optie om een GUA in te vullen, dus het kan ook (nog) niet zónder NAT.

Schijnt wel aan gewerkt te worden volgens dit artikel. Dat is een beetje het nadeel van de "gebruiksvriendelijke" aanpak van de FritzBox firmware, je wordt beperkt in het aanpassen en kunt dus eigenlijk niks stukmaken, maar bent dus ook wel afhankelijk van wat ze zelf out of the box aan de praat hebben gekregen.

[bart.koppers]

RobertMe schreef op vrijdag 27 juni 2025 @ 23:04:
[...]

Een GUA hoeft inderdaad niet. Maar als je IPv6 wilt internetten..., is een GUA "wel handig". Anders internet je alsnog via IPv4 en heb je IPv6 alleen om te "LANen". (Of je moet dus NAT doen op de "server")

Tot nu toe heb ik met IPv6 icm Wireguard beperkt goede ervaringen.
Want heb je als “client” echt alleen IPv6, dan *moet* je een GUA hebben om de peer (server) ook op IPv6 (op UDP poort met die GUA) te bereiken.

Het scheelt dan misschien een (1 regel) voor port-forward op een firewall.

Tegelijk moet de WG-peer/server waar je mee verbindt dan een fixed GUA hebben, én de poort moet naar die GUA openstaan.

De vraag komt vlgs neer op: hoe gebruik je de tunnel?
En kan/moet deze tunnel dan met IPv6 kunnen werken, zoals in geval er helemaal geen IPv4 is.

Qua “internetten” (tikje onduidelijke term..):
Als de peer de andere peer (server) kan bereiken via IPv6 is er geen garantie dat het verkeer wordt doorgegeven via IPv6 vanaf de server.

Want de instellingen op de server (zoals forwarding, evt NAT in meerdere vormen, firewall) bepalen hoe packets verder verwerkt worden

Bv als je alleen de tunnel gebruikt voor louter bereiken van het andere netwerk, is ook geen forwarding nodig.

Wireguard(protocol) is handig, maar doordat het werkt op L3 zijn er behoorlijk wat hoepels waar je door moet springen.
Geef mij dan maar een interface die op L2 zit.

[Snow_King]

Ik heb inmiddels van KPN een antwoord waarom IPv6 niet werkt op mijn Data-only SIM:

Onderzoek
We hebben navraag gedaan bij onze netwerkspecialisten.
Op dit moment is dit het design van Data only simkaarten. De APN van Data only nummers is IPv4 Only. Data/Voice abonn. beschikken wel over IPv4/IPv6 (dual stack).

Ik vind het een nogal vreemd antwoord, maar dit is waar ik het voor nu mee moet doen.

[Hipska]

Dus in feite is het een "Legacy data only" SIM kaart.

[c-nan]

Snow_King schreef op woensdag 7 mei 2025 @ 08:20:
In een nieuwe woning heb ik een Ziggo verbinding genomen, modem in Bridge en er een Unifi Express met twee AP's er achter. Dat werkt tegenwoordig echt heel soepel met Unifi. IPv6 aanzetten en het werkt gewoon per direct.

De Unifi UI laat nu al tijden ook de gedetecteerde IPv6 adressen zien van de clients, ik moet zeggen dat het allemaal erg soepel werkte. Had al een tijdje zo'n nieuwe installatie niet gedaan.

10/10 op https://test-ipv6.com/ zoals het hoort!

Onlangs heb ik mijn router vervangen, maar ik krijg IPv6 niet meer werkend. Welke instellingen heb jij ingesteld?

Met het volgende krijg ik geen IPv6:

[Snow_King]

c-nan schreef op dinsdag 22 juli 2025 @ 18:04:
[...]

Onlangs heb ik mijn router vervangen, maar ik krijg IPv6 niet meer werkend. Welke instellingen heb jij ingesteld?

Met het volgende krijg ik geen IPv6:
[Afbeelding]

Modem staat nog wel in bridge?

Dan is de instelling DHCP en verder klopt alles lijkt het. Heb je in het netwerk IPv6 ook wel aan staan zodat daar adressen aan de clients worden uitgedeeld?

[c-nan]

Snow_King schreef op dinsdag 22 juli 2025 @ 18:06:
[...]

Modem staat nog wel in bridge?

Dan is de instelling DHCP en verder klopt alles lijkt het. Heb je in het netwerk IPv6 ook wel aan staan zodat daar adressen aan de clients worden uitgedeeld?

Ja, ik heb enkel mijn router vervangen. Modem is niks aan gewijzigd. Wel heb ik een nieuw IPv4 gekregen, maar dat komt vanwege een nieuw mac adres denk ik.

In mijn netwerk heb ik altijd IPv6 devices gehad. Daar is ook niks veranderd.

/edit
DHCPv6 werkt wel, SLAAC niet. Ik dacht dat ik 'm in de vorige router als SLAAC had.

[ Voor 7% gewijzigd door c-nan op 22-07-2025 18:08 ]

[alm]

Europa loopt achter met IPv6, zie dit artikel: https://www.sidn.nl/nieuw...-apac-regio-de-50-procent
Alleen Afrika doet het nog slechter dan Europa. 😭

[Snow_King]

alm schreef op woensdag 30 juli 2025 @ 11:54:
Europa loopt achter met IPv6, zie dit artikel: https://www.sidn.nl/nieuw...-apac-regio-de-50-procent
Alleen Afrika doet het nog slechter dan Europa. 😭

Nederland zou een grote stap kunnen zetten als Odido en Vodafone eens wat doen. Daarnaast zijn er nog veel kleine ISP's die op FttH geen IPv6 leveren, echt heel jammer.

Ik krijg ODF later dit jaar. Wacht een jaar en ga dan naar Freedom, want Odido komt er niet in.

[RobertMe]

Hmm. Na het updaten van Debian naar Trixie op mijn "servertje" werkte IPv6 niet meer. Blijkt er in systemd-networkd, dat ik gebruik, een "vervelende" change te zitten: als je instelt om RAs te verzenden worden by default geen RAs meer ontvangen, iets dat voorheen wel het geval was (IPv6AcceptRA was standaard yes/true tenzij het een bridge betrof of forwarding aan staat, nu is het default true tenzij het een bridge is, of IPv6SendRA of ip forwarding aan staan).

Reden dat ik zowel RAs accept als RAs send is omdat het ook mijn Docker host is. En Docker netwerken een eigen ULA gebruiken en middels forwarding (dat ik niet expliciet genoeg aan heb gezet blijkbaar? ) het verkeer naar de container gaat. Waarbij het "servertje" dus ook een RA stuurt puur om de route te adverteren (uiteraard geen prefix etc, puur "subnet X is bereikbaar via mij").

En daarmee dus ook een kleine heads up voor anderen die mogelijk een dergelijke setup hebben (Debian, systemd-networkd voor network management, en zowel RAs sturen als willen ontvangen op dezelfde interface).

[St00mwals]

Mocht het IPv6 gebruik bij KPN ineens minder zijn, dan is dat verklaarbaar.
Op mijn Experia Box v10 staat sinds 2 dagen ineens mijn IPv6 uit (browser extension IPvFoo bleef ineens rood).
Na het opnieuw aanzetten blijft alles verder gewoon werken, dus waarom deze bij mij ineens is uitgezet?

[Shinji]

Hier mensen nog ipv6 werkend van kpn glasvezel op een fortigate (7.4.8)?

Ik kom diverse config voorbeelden tegen maar krijg maar geen ip.

[alm]

Shinji schreef op woensdag 24 september 2025 @ 21:21:
Hier mensen nog ipv6 werkend van kpn glasvezel op een fortigate (7.4.8)?

Ik kom diverse config voorbeelden tegen maar krijg maar geen ip.

Hoe gebruik je het? Ik heb met een FortiGate met 7.2.x wel IPv6 werkend gekregen achter de ExperiaBox 12, maar moest wel tijdelijk de SuperWiFi AP even uitzetten omdat er maar één delegated blok werd uitgekeerd.

[Shinji]

alm schreef op vrijdag 26 september 2025 @ 22:14:
[...]


Hoe gebruik je het? Ik heb met een FortiGate met 7.2.x wel IPv6 werkend gekregen achter de ExperiaBox 12, maar moest wel tijdelijk de SuperWiFi AP even uitzetten omdat er maar één delegated blok werd uitgekeerd.

Geen xperiabox, RJ45 van de ONT naar de WAN.

Komende week ga ik weer even verder zoeken en troubleshooten

[VHware]

Stomme Windows doet het nog steeds niet goed: https://learn.microsoft.c...-10-to-windows-11-ipv6-rf

DNS Servers uit Router Advertisements gebruiken is moeilijk blijkbaar. Linux en iOS doen het prima.

[duvekot]

VHware schreef op zondag 5 oktober 2025 @ 14:38:
Stomme Windows doet het nog steeds niet goed: https://learn.microsoft.c...-10-to-windows-11-ipv6-rf

DNS Servers uit Router Advertisements gebruiken is moeilijk blijkbaar. Linux en iOS doen het prima.

Dat is een bericht uit 2022 ... En na een upgrade van W10 naar W11 ... Waar staat dat het op een nieuwe W11 ook niet werkt? En met een upgrade van de huidige laatste W10 naar W11 ook nog steeds niet?

[VHware]

duvekot schreef op zondag 5 oktober 2025 @ 16:08:
[...]

Dat is een bericht uit 2022 ... En na een upgrade van W10 naar W11 ... Waar staat dat het op een nieuwe W11 ook niet werkt? En met een upgrade van de huidige laatste W10 naar W11 ook nog steeds niet?

Dat het bericht uit 2022 is klopt, maar merk het zelf met W11 dat dit nog steeds zo is.

[Xanthorax]

VHware schreef op zondag 5 oktober 2025 @ 17:14:
[...]

Dat het bericht uit 2022 is klopt, maar merk het zelf met W11 dat dit nog steeds zo is.

RDNSS werkt prima in Windows 11, wel vanaf 24H2 en nieuwer. Nu is het vooral wachten op werkende een CLAT stack en dan kunnen we ipv6-mostly eens testen.

[ Voor 15% gewijzigd door Xanthorax op 06-10-2025 09:11 ]

[VHware]

Ja ik zit met Win11 Enterprise 23H2 en daarmee is het dus nog niet goed

[Xanthorax]

Eindelijk iets van voortgang op dit vlak Windows CLAT Enters Private Preview: A Milestone for IPv6 Adoption, ben benieuwd wanneer het in een release preview build gaat komen.

Lokaal alles al werkend via pfSense (DHCP option 108, RA met PREF64 en NAT64) en kunnen testen via Android (welke dit al tijden ondersteund)

[ Voor 18% gewijzigd door Xanthorax op 19-11-2025 12:18 ]

[Jay-B]

Voor UDM pro / SE gebruikers is er extra support gekomen voor IPv6 in UniFi Network Application 10.0.160:

Improved IPv6 address reporting and support.

• Added IPv6 Prefix to the Internet and Gateway side panel, displaying the prefix obtained from the ISP.
• Added IPv6 Subnet column to Settings Overview and Networks pages.
• Adjusted DNS Server validation to allow entering IPv4-mapped IPv6 addresses under Network Settings.
• Added the Additional IPs option to the VLAN Network IPv6 Settings to add multiple IPv6 addresses, including ULA (Unique Local Address).
• Added IPv6 Address and IPv6 Link Local columns to the Client Devices page.

Ik ben postitief verrast.

[Snow_King]

quote: https://blog.apnic.net/20...eports-major-ipv6-growth/

China’s IPv6 Development Report (2025), released by the Expert Committee for Promoting Large-Scale IPv6 Deployment and Application, details rapid progress in IPv6 deployment and integration across China’s Internet infrastructure, services, and industries.

The report outlines substantial growth in users and traffic, widespread upgrades to network and application infrastructure, and deepening adoption of IPv6-based innovation and standards. It states that as of September 2025, China reported 865 million active IPv6 users, accounting for 77% of Internet users, nearly 300 times greater than the number reported in 2017 (Figure 1). IPv6 traffic share reached 34% of total Internet traffic, with mobile networks averaging 69% and fixed networks 31%

Wat ik vooral zie is dat servers in China nog geen IPv6 hebben, maar de clients wel. Bijvoorbeeld wechat.com is nog enkel IPv4-only.

[Flappie]

Heeft iemand hier Delta Fiber IPv6 werkend icm OPNsense?
Ik heb een Nokia XS-010 modem in bridge met daarchter dus OPNsense.
Ik heb op de WAN interface IPv6 aangezet.

Op deze manier:


En daarna op mijn public wifi IPv6 aangezet met deze opties (als prefix heb ik even een random nummer gekozen)


Ik krijg op zowel een laptop als een telefoon een IPv6 adres. Echter op de telefoons heb ik wel een werkende verbinding en op mijn laptop (Windows) werkt het niet

[ Voor 5% gewijzigd door Flappie op 16-12-2025 20:53 ]

[Xanthorax]

Flappie schreef op dinsdag 16 december 2025 @ 20:52:
Heeft iemand hier Delta Fiber IPv6 werkend icm OPNsense?
Ik heb een Nokia XS-010 modem in bridge met daarchter dus OPNsense.
Ik heb op de WAN interface IPv6 aangezet.

Op deze manier:
[Afbeelding]

En daarna op mijn public wifi IPv6 aangezet met deze opties (als prefix heb ik even een random nummer gekozen)
[Afbeelding]

Ik krijg op zowel een laptop als een telefoon een IPv6 adres. Echter op de telefoons heb ik wel een werkende verbinding en op mijn laptop (Windows) werkt het niet

Ik heb alleen ervaring met pfSense, maar op de WAN hoef je geen IPv6 te hebben, alleen een PD en je LAN moet de WAN tracken hierna moet je iets met Router Advertisements doen op je LAN op de PD te verdelen.

ps. SLAAC is goed genoeg, mits je Windows > 24h2 draait anders moet je ook DHCPv6 gebruiken op je LAN (althands als je werkende DNS wilt)

Ik heb mijn pfSense config (basics) globaal hier staan https://github.com/bschapendonk/pfsense-delta-xgs-pon

[ Voor 6% gewijzigd door Xanthorax op 17-12-2025 08:24 ]

[tomdh76]

Flappie schreef op dinsdag 16 december 2025 @ 20:52:
Heeft iemand hier Delta Fiber IPv6 werkend icm OPNsense?
Ik heb een Nokia XS-010 modem in bridge met daarchter dus OPNsense.
Ik heb op de WAN interface IPv6 aangezet.

Op deze manier:
[Afbeelding]

En daarna op mijn public wifi IPv6 aangezet met deze opties (als prefix heb ik even een random nummer gekozen)
[Afbeelding]

Ik krijg op zowel een laptop als een telefoon een IPv6 adres. Echter op de telefoons heb ik wel een werkende verbinding en op mijn laptop (Windows) werkt het niet

Ik ben nog steeds aan het kloten met ipv6 op windows. Ik gebruik OPNSense met DNSmasq waarin ook die router advertisement zit. Op iphones werkt alles prima maar op windows soms ipv6, dan weer niet, dan weer heel traag internet.... Ik gebruik ra-stateless modus. Of moet ik ook slaac erbij zetten? Is het jou gelukt?

[d3vlin]

Ik kreeg Dnsmaq RA ook niet stabiel en gebruik daarom sindsdien Dnsmasq DHCP voor IPv4 en radvd (Services/Router Advertisements) voor IPv6.

[tomdh76]

d3vlin schreef op donderdag 12 februari 2026 @ 10:46:
Ik kreeg Dnsmaq RA ook niet stabiel en gebruik daarom sindsdien Dnsmasq DHCP voor IPv4 en radvd (Services/Router Advertisements) voor IPv6.

Dank ga ik ook doen, ik hoop alleen dat die RADVD blijft bestaan, nu ze alles naar dnsmasq willen hebben lijkt het

[Flappie]

tomdh76 schreef op donderdag 12 februari 2026 @ 10:38:
[...]


Ik ben nog steeds aan het kloten met ipv6 op windows. Ik gebruik OPNSense met DNSmasq waarin ook die router advertisement zit. Op iphones werkt alles prima maar op windows soms ipv6, dan weer niet, dan weer heel traag internet.... Ik gebruik ra-stateless modus. Of moet ik ook slaac erbij zetten? Is het jou gelukt?

Mijn probleem zat hem erin dat in mijn UniFi netwerk unicast traffic geblokkeerd werd. Daarna werkte het prima. Je zou eens bekabeld kunnen testen om specifieke WiFi settings uit te sluiten.

[Darses]

tomdh76 schreef op donderdag 12 februari 2026 @ 11:25:
[...]

Dank ga ik ook doen, ik hoop alleen dat die RADVD blijft bestaan, nu ze alles naar dnsmasq willen hebben lijkt het

Volgens mij is de wens in ISC DHCP uit te faseren en te vervangen door Kea. Vanwege de ontbrekende functies in Kea is daarom dnsmasq ernaast gezet.

Ik heb zelf geen Windows systeem in huis, maar OPNSense met IPv6 werkt hier zonder grote problemen. Na de OPNSense 27.1 editie werkt Android zelfs zonder problemen op IPv6-mostly. Na wat gedoe met Kea zit ik nog op ISC DHCP, maar dat migratie ga ik binnenkort weer eens proberen.

[StaticZ]

Hier ook OPNSense 26.1.1 draaien.
Nog de oude ISC DHCPv6 en Radvd draaien en geen problemen met IPv6. ("Windows, Android, Iphone")

Duurt volgens mij ook nog wel even voordat deze uit de plugins worden gehaald.

[tomdh76]

Flappie schreef op donderdag 12 februari 2026 @ 12:17:
[...]

Mijn probleem zat hem erin dat in mijn UniFi netwerk unicast traffic geblokkeerd werd. Daarna werkte het prima. Je zou eens bekabeld kunnen testen om specifieke WiFi settings uit te sluiten.

Met dnsmasq en windows computers?
Ik zie unicast traffic blok niet 1,2,3 staan in mijn settings, wel dat multicast naar unicast wordt gebroadcast.

[Raven]

Weet iemand toevallig iets over hoe KPN IPv6 levert? Mijn Debian-router babbelt wel met de PPPoE-server over fe80-adressen en er wordt ook een IPv6-route met fe80 adres aangemaakt, maar niks over publieke IPv6-adressen en de packet counters van de regels om DHCPv6 toe te staan blijven op 0 staan.

Bash:

AP authentication succeeded
peer from calling number 60:7E:CD:57:77:4A authorized
sent [IPCP ConfReq id=0x1 <addr 0.0.0.0> <ms-dns1 0.0.0.0> <ms-dns2 0.0.0.0>]
sent [IPV6CP ConfReq id=0x1 <addr fe80::3c7f:9872:e4d8:d15c>]
rcvd [IPCP ConfReq id=0x1 <addr 195.190.228.60>]
sent [IPCP ConfAck id=0x1 <addr 195.190.228.60>]
rcvd [IPV6CP ConfReq id=0x1 <addr fe80::627e:cdff:fe57:774a>]
sent [IPV6CP ConfAck id=0x1 <addr fe80::627e:cdff:fe57:774a>]
rcvd [IPCP ConfNak id=0x1 <addr 81.*.*.*> <ms-dns1 195.121.1.34> <ms-dns2 195.121.1.66>]
sent [IPCP ConfReq id=0x2 <addr 81.*.*.*> <ms-dns1 195.121.1.34> <ms-dns2 195.121.1.66>]
nm-ppp-plugin: status 8 / phase 'running'
rcvd [IPV6CP ConfAck id=0x1 <addr fe80::3c7f:9872:e4d8:d15c>]
local  LL address fe80::3c7f:9872:e4d8:d15c
remote LL address fe80::627e:cdff:fe57:774a
nm-ppp-plugin: interface name changed from 'ppp7' to 'enp0s31f6.6.ppp'
nm-ppp-plugin: ip6-up event
nm-ppp-plugin: sending IPv6 config to NetworkManager...
Script /etc/ppp/ipv6-up started (pid 91892)
rcvd [IPCP ConfAck id=0x2 <addr 81.*.*.*> <ms-dns1 195.121.1.34> <ms-dns2 195.121.1.66>]
Script /etc/ppp/ip-pre-up started (pid 91895)
Script /etc/ppp/ip-pre-up finished (pid 91895), status = 0x0
local  IP address 81.*.*.*
nm-ppp-plugin: ip-up event
remote IP address 195.190.228.60
nm-ppp-plugin: sending IPv4 config to NetworkManager...
primary   DNS address 195.121.1.34
secondary DNS address 195.121.1.66
Script /etc/ppp/ip-up started (pid 91898)
Script /etc/ppp/ipv6-up finished (pid 91892), status = 0x0
Script /etc/ppp/ip-up finished (pid 91898), status = 0x0

[davegriffejoen]

@Raven via de opgebouwde ppp verbinding via DHCPv6. Ik gebruik op Debian wide-dhcpcv6 client.

[Raven]

@davegriffejoen Ik heb nmcli gebruikt voor de netwerkconfig, waaronder opzetten PPPoE waarbij ipv6.method op auto staat.

Mocht wide-dhcpcv6 client. wel werken, als ie NetworkManager niet in de weg gaat zitten (die managed alle interfaces), dan ben ik alsnog benieuwd wat wide-dhcpcv6 client.anders doet dan de NetworkManager.

[Raven]

davegriffejoen schreef op vrijdag 20 februari 2026 @ 18:04:
@Raven via de opgebouwde ppp verbinding via DHCPv6. Ik gebruik op Debian wide-dhcpcv6 client.

Wat een geweldig programma, beide config files ingesteld, verwijzen naar de juiste interface, start ie niet. Er wordt verwezen naar journalctl, maar zelfs met debug=2 zie ik geen oorzaak van het niet willen starten....

edit oh wacht, keek specifiek naar wide-dhcpv6-client, nu ook dhcp6c

Bash:

dhcp6c[244543]: extracted an existing DUID from /var/lib/dhcpv6/dhcp6c_duid: 00:01:00:01:*:*:*:*:*:*:*:*:*:*
dhcp6c[244543]: bind: Address already in use

edit2: IPv6 in nmtui uitgeschakeld, denkend dat die in de weg zit:

Bash:

dhcp6c[244657]: <3>[prefix-interface] (16)
dhcp6c[244657]: <5>[enp0s31f6.6.ppp] (15)
dhcp6c[244657]: <3>begin of closure [{] (1)
dhcp6c[244657]: <3>comment [# Internal interface to assign prefix] (37)
dhcp6c[244657]: <3>[sla-id] (6)
dhcp6c[244657]: <3>[1] (1)
dhcp6c[244657]: <3>end of sentence [;] (1)
dhcp6c[244657]: <3>[sla-len] (7)
dhcp6c[244657]: <3>[8] (1)
dhcp6c[244657]: <3>end of sentence [;] (1)
dhcp6c[244657]: <3>end of closure [}] (1)
dhcp6c[244657]: <3>end of sentence [;] (1)
dhcp6c[244657]: <3>end of closure [}] (1)
dhcp6c[244657]: <3>end of sentence [;] (1)
dhcp6c[244657]: cannot find interface information for enp0s31f6.6.ppp
dhcp6c[244657]: failed to get default IF ID for enp0s31f6.6.ppp
dhcp6c[244657]: called
dhcp6c[244657]: failed to parse configuration file
wide-dhcpv6-client[244654]: Starting WIDE DHCPv6 client: dhcp6c failed!
systemd[1]: wide-dhcpv6-client.service: Control process exited, code=exited, status=1/FAILURE

[ Voor 67% gewijzigd door Raven op 23-02-2026 07:44 ]

[borft]

Raven schreef op maandag 23 februari 2026 @ 07:32:
[...]
Wat een geweldig programma, beide config files ingesteld, verwijzen naar de juiste interface, start ie niet. Er wordt verwezen naar journalctl, maar zelfs met debug=2 zie ik geen oorzaak van het niet willen starten....

edit oh wacht, keek specifiek naar wide-dhcpv6-client, nu ook dhcp6c

Bash:

dhcp6c[244543]: extracted an existing DUID from /var/lib/dhcpv6/dhcp6c_duid: 00:01:00:01:*:*:*:*:*:*:*:*:*:*
dhcp6c[244543]: bind: Address already in use

edit2: IPv6 in nmtui uitgeschakeld, denkend dat die in de weg zit:

Bash:

dhcp6c[244657]: <3>[prefix-interface] (16)
dhcp6c[244657]: <5>[enp0s31f6.6.ppp] (15)
dhcp6c[244657]: <3>begin of closure [{] (1)
dhcp6c[244657]: <3>comment [# Internal interface to assign prefix] (37)
dhcp6c[244657]: <3>[sla-id] (6)
dhcp6c[244657]: <3>[1] (1)
dhcp6c[244657]: <3>end of sentence [;] (1)
dhcp6c[244657]: <3>[sla-len] (7)
dhcp6c[244657]: <3>[8] (1)
dhcp6c[244657]: <3>end of sentence [;] (1)
dhcp6c[244657]: <3>end of closure [}] (1)
dhcp6c[244657]: <3>end of sentence [;] (1)
dhcp6c[244657]: <3>end of closure [}] (1)
dhcp6c[244657]: <3>end of sentence [;] (1)
dhcp6c[244657]: cannot find interface information for enp0s31f6.6.ppp
dhcp6c[244657]: failed to get default IF ID for enp0s31f6.6.ppp
dhcp6c[244657]: called
dhcp6c[244657]: failed to parse configuration file
wide-dhcpv6-client[244654]: Starting WIDE DHCPv6 client: dhcp6c failed!
systemd[1]: wide-dhcpv6-client.service: Control process exited, code=exited, status=1/FAILURE

verkeerde interface naam? is ie wel al up?

[Raven]

@borft Naam is correct, als IPv6 in nmtui aan is gezet (method auto) dan ziet wide-dhcpv6-client 'm wel maar klaagt over address already in use, zet ik IPv6 in nmtui op disabled dan pikt ie 'm niet op.

[Bigs]

Ik heb onlangs, na lang IPv6 gebruik in mijn huis, helaas IPv6 uit moeten zetten

De reden is de nieuwe DrayTek router voor mijn KPN glasvezel verbinding. De router ondersteunt geen 'mini-jumbo' op de WAN interface waardoor mijn PPPoE verbinding een MTU van 1492 heeft ipv 1500. En dat is waar het mis gaat.

Ik heb met Wireshark zitten kijken en alhoewel de router netjes 'Packet too big' ICMPv6 berichten aan de clients verzendt worden deze niet goed verwerkt, waardoor SSL verbindingen (waarbij de te verzenden handshake vaak groter dan 1492 bytes is) niet tot stand komen. Na enige vertraging wordt er teruggevallen op IPv4, en voor andere devices leidt het tot onoverkomelijke problemen waardoor ze totaal niet meer willen verbinden. Erg jammer. Ik heb het maar opgegeven. Eigenlijk mis ik in de praktijk ook niets zonder IPv6.

[Muis666]

Bigs schreef op vrijdag 27 februari 2026 @ 10:45:
Ik heb onlangs, na lang IPv6 gebruik in mijn huis, helaas IPv6 uit moeten zetten

De reden is de nieuwe DrayTek router voor mijn KPN glasvezel verbinding. De router ondersteunt geen 'mini-jumbo' op de WAN interface waardoor mijn PPPoE verbinding een MTU van 1492 heeft ipv 1500. En dat is waar het mis gaat.

Ik heb met Wireshark zitten kijken en alhoewel de router netjes 'Packet too big' ICMPv6 berichten aan de clients verzendt worden deze niet goed verwerkt, waardoor SSL verbindingen (waarbij de te verzenden handshake vaak groter dan 1492 bytes is) niet tot stand komen. Na enige vertraging wordt er teruggevallen op IPv4, en voor andere devices leidt het tot onoverkomelijke problemen waardoor ze totaal niet meer willen verbinden. Erg jammer. Ik heb het maar opgegeven. Eigenlijk mis ik in de praktijk ook niets zonder IPv6.

Vreemd. Mijn OpenWRT router gaf recent geen enkel probleem met een MTU van 1492 en IPv6. En ik zit ook bij KPN. Inmiddels wel mijn MTU opgehoogd maar weken gedraaid met 1492.

[Bigs]

Muis666 schreef op vrijdag 27 februari 2026 @ 10:50:
[...]

Vreemd. Mijn OpenWRT router gaf recent geen enkel probleem met een MTU van 1492 en IPv6. En ik zit ook bij KPN. Inmiddels wel mijn MTU opgehoogd maar weken gedraaid met 1492.

Ja ik snap er niets van. Het lijkt alsof er iets niet klopt aan de ICMPv6 pakketten die hij verstuurt, maar ik heb de dumps inmiddels weggegooid. Het is helaas niet het enige issue met de DrayTek router. Ik had er meer van verwacht moet ik eerlijk zeggen.

[Raven]

Bigs schreef op vrijdag 27 februari 2026 @ 10:52:
[...]


Ja ik snap er niets van. Het lijkt alsof er iets niet klopt aan de ICMPv6 pakketten die hij verstuurt, maar ik heb de dumps inmiddels weggegooid.

Zou het kunnen dat de firewall te strikt staat afgesteld en bepaalde ICMPv6 pakketten blokkeert?

Over ICMPv6 gesproken, ik heb captures van tussen mijn Debian-router en de ONT en van tussen KPN's EB en de ONT.

Volgens de eigen router pdf van KPN maken zij gebruik van DHCPv6-PD, ik zie echter voornamelijk NDP gerelateerde pakketten (ICMPv6 types 133, 134, 135 en 136) en in veel mindere mate DHCPv6, waar de capture i.c.m. mijn router-pc een paar ICMPv6 133 laat zien en verder helemaal niets m.b.t. IPv6 adres toewijzing.

Nou ken ik de technische kant van IPv6 niet zodanig goed dat ik weet of DHCPv6-PD afhankelijk is van NDP. Maar wat ik afgaand op de captures wel snap is dat NDP niet lijkt te werken, al wisselen Debian en de PPPoE-server (aldus journalctl) wel fe80-adressen uit, maar of dit ook de oorzaak is van dat DHCPv6-PD niet werkt.... geen idee.

Bigs schreef op vrijdag 27 februari 2026 @ 10:52:
. Het is helaas niet het enige issue met de DrayTek router. Ik had er meer van verwacht moet ik eerlijk zeggen.

Ik vond één consumentenrouter meer dan genoeg, daarna overgestapt op een pc en nooit meer teruggekeken

[ Voor 4% gewijzigd door Raven op 27-02-2026 19:59 ]

[Jerrythafast]

@Bigs Daarop staat een licht gewijzigde firmware: specifiek is de wijziging dat de pagina waarop je IPv6 zou kunnen aanzetten aan de WAN-kant eruit is gehaald. Ik begin nu te vermoeden waarom ze die optie hebben weggehaald uit de Budget-firmware

[ Voor 17% gewijzigd door Jerrythafast op 27-02-2026 21:09 ]

[tomdh76]

Ik heb iets geks met 1 laptop waarbij ik af en toe alleen een ipv6 adres krijg en geen ipv4 adres. Ik heb een OPNsense installatie en alle devices krijgen prima ipv6 en ipv4. Echter bij 1 laptop vervalt soms na een paar dagen ipv4. ipv6 werkt dan nog wel. Als ik dan laptop paar uur uitzet en weer aan dan werkt het meestal wel. Op zich zou het prima zijn als ik een tijdje enkel met ipv6 werk maar ik merk dat sommige websites dan heel langzaam laden.

1) Heeft iemand een idee waarom ipv4 soms niet werkt?
2) als ik puur met ipv6 werk waarom laden websites dan langzaam?

[thof]

tomdh76 schreef op woensdag 4 maart 2026 @ 10:13:
Ik heb iets geks met 1 laptop waarbij ik af en toe alleen een ipv6 adres krijg en geen ipv4 adres. Ik heb een OPNsense installatie en alle devices krijgen prima ipv6 en ipv4. Echter bij 1 laptop vervalt soms na een paar dagen ipv4. ipv6 werkt dan nog wel. Als ik dan laptop paar uur uitzet en weer aan dan werkt het meestal wel. Op zich zou het prima zijn als ik een tijdje enkel met ipv6 werk maar ik merk dat sommige websites dan heel langzaam laden.

1) Heeft iemand een idee waarom ipv4 soms niet werkt?
2) als ik puur met ipv6 werk waarom laden websites dan langzaam?

Geen idee, maar als het een Windows laptop is al eens in de event viewer gekeken of daar iets bijzonders te vinden is? Klinkt alsof een DHCP lease niet op tijd vernieuwd is.

[tomdh76]

thof schreef op vrijdag 6 maart 2026 @ 16:49:
[...]


Geen idee, maar als het een Windows laptop is al eens in de event viewer gekeken of daar iets bijzonders te vinden is? Klinkt alsof een DHCP lease niet op tijd vernieuwd is.

Thx, niet aan gedacht. Ik zal volgende keer daar kijken. Wbt Ipv6 traagheid heb ik probleem ontdekt. Het lijkt erop dat de DNS niet goed doorkomt van mijn adguard home die op OPNsense staat. Als ik namelijk in ipv6 handmatig een publieke ipv6 dns zet is ok. Nu dus aan het proberen DNS van adguard naar clienten te pushen. Best lastig met ULA etc.

[Raven]

davegriffejoen schreef op vrijdag 20 februari 2026 @ 18:04:
@Raven via de opgebouwde ppp verbinding via DHCPv6. Ik gebruik op Debian wide-dhcpcv6 client.

borft schreef op woensdag 25 februari 2026 @ 16:27:
[...]

verkeerde interface naam? is ie wel al up?

Het heeft even geduurd, druk met huis uit gaan enzo. Inmiddels IPv6 op de Debian router werkend.

De config van wide-dhcpcv6 client ziet er nu zo uit:

Bash:

# Default dhpc6c configuration: it assumes the address is autoconfigured using
# router advertisements.

#profile default
#{
#  information-only;
#
#  request domain-name-servers;
#  request domain-name;
#
#  script "/etc/wide-dhcpv6/dhcp6c-script";
#};

interface enp0s31f6.6.ppp {
    #send ia-na 0;    # Request IPv6 Address
    send ia-pd 0;    # Request Prefix Delegation
    request domain-name-servers;
    request domain-name;
    script "/etc/wide-dhcpv6/dhcp6c-script";
};

id-assoc na 0 {
    # Empty block to trigger request
};

id-assoc pd 0 {
    #prefix-interface enp0s31f6.6.ppp { # Internal interface to assign prefix
    #    sla-id 1;
    #    sla-len 16;
    #};
};

send ia-na 0 -> weggecomment
prefix-interface enp0s31f6.6.ppp -> weggecomment (geen idee waarom die daar stond, denk foute doc gelezen ergens).

Daarna /etc/wide-dhcpv6/dhcp6c-script voorzien van een stukje code om de prefix uit journalctl-output te halen, moet ook met door wide-dhcpcv6 client aangemaakte environment variables kunnen maar daar is een compleet gebrek aan documentatie over. Er is wel documentatie, maar de prefix-specifieke variables zijn standaard niet aanwezig, sommige distro devvers hebben dit wel toegevoegd maar documenteren ho maar. Ik weet dat het bestaat omdat het in broncode is terug te vinden, maar verder....

Nadat het script de prefix heeft weten op te halen is het samenstellen van een adres met zelf gekozen /64 subnet zo gebeurt, dan met ip-commando toepassen.

[tomdh76]

Zoals eerder hier gemeld heb ik op mijn laptop een raar issue dat af en toe na een paar dagen mijn ipv4 ermee stopt, computer uit voor een halve dag en dan doet hij het weer (in eventviewer windows zie ik niet veel bijzonders). Dus ik dacht ik ga met die laptop volledig over op ipv6. Dat lukt aardig nu (met statische ULA's naar servers). Maar wat ik niet kan vinden is mdns over verschillende vlans in IPV6. Ik wil graag mijn Roon core (muziekstreamer) aansturen via laptop maar die staat in een ander VLAN. Heeft iemand mdns werken over verschillende VLANS in IPV6 of is dit gewoon niet mogelijk?

[Jef61]

Ik heb er sinds enkele weken last van dat de Tweakers website niet vlot reageert. Vandaag er eens in gedoken en de betreffende IP-nummers in de monitoring opgenomen, mijn IPv6 verbinding naar Tweakers (trafficmanager van Akamai?) blijkt niet stabiel te zijn. Ik vermoed dat dit probleem niet bij mij zit omdat de IPv6 ping naar bv Google DNS wel stabiel is (zie grafiek).

Ben ik de enige die hier last van heeft of is dit misschien een probleem bij mijn provider? Kan iemand eens een ping6 test doen naar Tweakers? Een wat langere test is wel nodig omdat het zomaar weer 15 minuten goed kan gaan. IPv4 naar Tweakers is in orde

Ping naar Google DNS, Tweakers IPv6 en Tweakers IPv4:

code:

[jef@cachyos-x8664 ~]$ ping -O 2a02:26f0:c900:b::5f65:4a2f
PING 2a02:26f0:c900:b::5f65:4a2f (2a02:26f0:c900:b::5f65:4a2f) 56 data bytes
64 bytes from 2a02:26f0:c900:b::5f65:4a2f: icmp_seq=1 ttl=57 time=3.54 ms
64 bytes from 2a02:26f0:c900:b::5f65:4a2f: icmp_seq=2 ttl=57 time=3.73 ms
64 bytes from 2a02:26f0:c900:b::5f65:4a2f: icmp_seq=3 ttl=57 time=3.48 ms
64 bytes from 2a02:26f0:c900:b::5f65:4a2f: icmp_seq=4 ttl=57 time=3.61 ms
64 bytes from 2a02:26f0:c900:b::5f65:4a2f: icmp_seq=5 ttl=57 time=13.2 ms
64 bytes from 2a02:26f0:c900:b::5f65:4a2f: icmp_seq=6 ttl=57 time=3.49 ms
64 bytes from 2a02:26f0:c900:b::5f65:4a2f: icmp_seq=7 ttl=57 time=3.58 ms
64 bytes from 2a02:26f0:c900:b::5f65:4a2f: icmp_seq=8 ttl=57 time=3.51 ms
64 bytes from 2a02:26f0:c900:b::5f65:4a2f: icmp_seq=9 ttl=57 time=3.53 ms
64 bytes from 2a02:26f0:c900:b::5f65:4a2f: icmp_seq=10 ttl=57 time=3.51 ms
64 bytes from 2a02:26f0:c900:b::5f65:4a2f: icmp_seq=11 ttl=57 time=3.47 ms
64 bytes from 2a02:26f0:c900:b::5f65:4a2f: icmp_seq=12 ttl=57 time=3.66 ms
64 bytes from 2a02:26f0:c900:b::5f65:4a2f: icmp_seq=13 ttl=57 time=5.23 ms
64 bytes from 2a02:26f0:c900:b::5f65:4a2f: icmp_seq=14 ttl=57 time=3.44 ms
64 bytes from 2a02:26f0:c900:b::5f65:4a2f: icmp_seq=15 ttl=57 time=4.44 ms
64 bytes from 2a02:26f0:c900:b::5f65:4a2f: icmp_seq=16 ttl=57 time=3.55 ms
64 bytes from 2a02:26f0:c900:b::5f65:4a2f: icmp_seq=17 ttl=57 time=3.54 ms
64 bytes from 2a02:26f0:c900:b::5f65:4a2f: icmp_seq=18 ttl=57 time=3.48 ms
64 bytes from 2a02:26f0:c900:b::5f65:4a2f: icmp_seq=19 ttl=57 time=3.51 ms
64 bytes from 2a02:26f0:c900:b::5f65:4a2f: icmp_seq=20 ttl=57 time=3.52 ms
64 bytes from 2a02:26f0:c900:b::5f65:4a2f: icmp_seq=21 ttl=57 time=3.68 ms
no answer yet for icmp_seq=22
no answer yet for icmp_seq=23
no answer yet for icmp_seq=24
no answer yet for icmp_seq=25
no answer yet for icmp_seq=26
no answer yet for icmp_seq=27
no answer yet for icmp_seq=28
no answer yet for icmp_seq=29
no answer yet for icmp_seq=30
no answer yet for icmp_seq=31
no answer yet for icmp_seq=32
no answer yet for icmp_seq=33
no answer yet for icmp_seq=34
no answer yet for icmp_seq=35
no answer yet for icmp_seq=36
no answer yet for icmp_seq=37
no answer yet for icmp_seq=38
no answer yet for icmp_seq=39
no answer yet for icmp_seq=40
no answer yet for icmp_seq=41
no answer yet for icmp_seq=42
no answer yet for icmp_seq=43
no answer yet for icmp_seq=44
no answer yet for icmp_seq=45
no answer yet for icmp_seq=46
no answer yet for icmp_seq=47
no answer yet for icmp_seq=48
no answer yet for icmp_seq=49
no answer yet for icmp_seq=50
no answer yet for icmp_seq=51
no answer yet for icmp_seq=52
no answer yet for icmp_seq=53
no answer yet for icmp_seq=54
no answer yet for icmp_seq=55
no answer yet for icmp_seq=56
64 bytes from 2a02:26f0:c900:b::5f65:4a2f: icmp_seq=57 ttl=57 time=3.36 ms
64 bytes from 2a02:26f0:c900:b::5f65:4a2f: icmp_seq=58 ttl=57 time=3.39 ms
64 bytes from 2a02:26f0:c900:b::5f65:4a2f: icmp_seq=59 ttl=57 time=3.35 ms
64 bytes from 2a02:26f0:c900:b::5f65:4a2f: icmp_seq=60 ttl=57 time=3.55 ms
64 bytes from 2a02:26f0:c900:b::5f65:4a2f: icmp_seq=61 ttl=57 time=4.63 ms
^C
--- 2a02:26f0:c900:b::5f65:4a2f ping statistics ---
61 packets transmitted, 26 received, 57.377% packet loss, time 60887ms

[Vorkie]

Jef61 schreef op zaterdag 21 maart 2026 @ 13:00:
Ik heb er sinds enkele weken last van dat de Tweakers website niet vlot reageert. Vandaag er eens in gedoken en de betreffende IP-nummers in de monitoring opgenomen, mijn IPv6 verbinding naar Tweakers (trafficmanager van Akamai?) blijkt niet stabiel te zijn. Ik vermoed dat dit probleem niet bij mij zit omdat de IPv6 ping naar bv Google DNS wel stabiel is (zie grafiek).

Ben ik de enige die hier last van heeft of is dit misschien een probleem bij mijn provider? Kan iemand eens een ping6 test doen naar Tweakers? Een wat langere test is wel nodig omdat het zomaar weer 15 minuten goed kan gaan. IPv4 naar Tweakers is in orde

Ping naar Google DNS, Tweakers IPv6 en Tweakers IPv4:
[Afbeelding]

code:

[jef@cachyos-x8664 ~]$ ping -O 2a02:26f0:c900:b::5f65:4a2f
PING 2a02:26f0:c900:b::5f65:4a2f (2a02:26f0:c900:b::5f65:4a2f) 56 data bytes
64 bytes from 2a02:26f0:c900:b::5f65:4a2f: icmp_seq=1 ttl=57 time=3.54 ms
64 bytes from 2a02:26f0:c900:b::5f65:4a2f: icmp_seq=2 ttl=57 time=3.73 ms
64 bytes from 2a02:26f0:c900:b::5f65:4a2f: icmp_seq=3 ttl=57 time=3.48 ms
64 bytes from 2a02:26f0:c900:b::5f65:4a2f: icmp_seq=4 ttl=57 time=3.61 ms
64 bytes from 2a02:26f0:c900:b::5f65:4a2f: icmp_seq=5 ttl=57 time=13.2 ms
64 bytes from 2a02:26f0:c900:b::5f65:4a2f: icmp_seq=6 ttl=57 time=3.49 ms
64 bytes from 2a02:26f0:c900:b::5f65:4a2f: icmp_seq=7 ttl=57 time=3.58 ms
64 bytes from 2a02:26f0:c900:b::5f65:4a2f: icmp_seq=8 ttl=57 time=3.51 ms
64 bytes from 2a02:26f0:c900:b::5f65:4a2f: icmp_seq=9 ttl=57 time=3.53 ms
64 bytes from 2a02:26f0:c900:b::5f65:4a2f: icmp_seq=10 ttl=57 time=3.51 ms
64 bytes from 2a02:26f0:c900:b::5f65:4a2f: icmp_seq=11 ttl=57 time=3.47 ms
64 bytes from 2a02:26f0:c900:b::5f65:4a2f: icmp_seq=12 ttl=57 time=3.66 ms
64 bytes from 2a02:26f0:c900:b::5f65:4a2f: icmp_seq=13 ttl=57 time=5.23 ms
64 bytes from 2a02:26f0:c900:b::5f65:4a2f: icmp_seq=14 ttl=57 time=3.44 ms
64 bytes from 2a02:26f0:c900:b::5f65:4a2f: icmp_seq=15 ttl=57 time=4.44 ms
64 bytes from 2a02:26f0:c900:b::5f65:4a2f: icmp_seq=16 ttl=57 time=3.55 ms
64 bytes from 2a02:26f0:c900:b::5f65:4a2f: icmp_seq=17 ttl=57 time=3.54 ms
64 bytes from 2a02:26f0:c900:b::5f65:4a2f: icmp_seq=18 ttl=57 time=3.48 ms
64 bytes from 2a02:26f0:c900:b::5f65:4a2f: icmp_seq=19 ttl=57 time=3.51 ms
64 bytes from 2a02:26f0:c900:b::5f65:4a2f: icmp_seq=20 ttl=57 time=3.52 ms
64 bytes from 2a02:26f0:c900:b::5f65:4a2f: icmp_seq=21 ttl=57 time=3.68 ms
no answer yet for icmp_seq=22
no answer yet for icmp_seq=23
no answer yet for icmp_seq=24
no answer yet for icmp_seq=25
no answer yet for icmp_seq=26
no answer yet for icmp_seq=27
no answer yet for icmp_seq=28
no answer yet for icmp_seq=29
no answer yet for icmp_seq=30
no answer yet for icmp_seq=31
no answer yet for icmp_seq=32
no answer yet for icmp_seq=33
no answer yet for icmp_seq=34
no answer yet for icmp_seq=35
no answer yet for icmp_seq=36
no answer yet for icmp_seq=37
no answer yet for icmp_seq=38
no answer yet for icmp_seq=39
no answer yet for icmp_seq=40
no answer yet for icmp_seq=41
no answer yet for icmp_seq=42
no answer yet for icmp_seq=43
no answer yet for icmp_seq=44
no answer yet for icmp_seq=45
no answer yet for icmp_seq=46
no answer yet for icmp_seq=47
no answer yet for icmp_seq=48
no answer yet for icmp_seq=49
no answer yet for icmp_seq=50
no answer yet for icmp_seq=51
no answer yet for icmp_seq=52
no answer yet for icmp_seq=53
no answer yet for icmp_seq=54
no answer yet for icmp_seq=55
no answer yet for icmp_seq=56
64 bytes from 2a02:26f0:c900:b::5f65:4a2f: icmp_seq=57 ttl=57 time=3.36 ms
64 bytes from 2a02:26f0:c900:b::5f65:4a2f: icmp_seq=58 ttl=57 time=3.39 ms
64 bytes from 2a02:26f0:c900:b::5f65:4a2f: icmp_seq=59 ttl=57 time=3.35 ms
64 bytes from 2a02:26f0:c900:b::5f65:4a2f: icmp_seq=60 ttl=57 time=3.55 ms
64 bytes from 2a02:26f0:c900:b::5f65:4a2f: icmp_seq=61 ttl=57 time=4.63 ms
^C
--- 2a02:26f0:c900:b::5f65:4a2f ping statistics ---
61 packets transmitted, 26 received, 57.377% packet loss, time 60887ms

Lijkt wel specifiek naar de voordeur van Akamai - bij Nu.nl zie ik het ook, maar naar KPN.com niet.

@Kees misschien meer inzicht

[Jef61]

Vorkie schreef op zaterdag 21 maart 2026 @ 14:41:
[...]

Lijkt wel specifiek naar de voordeur van Akamai - bij Nu.nl zie ik het ook, maar naar KPN.com niet.

@Kees misschien meer inzicht

Oh idd, dezelfde problemen bij nu.nl, was me nog niet opgevallen.

code:

[jef@cachyos-x8664 ~]$ ping nu.nl -O
PING nu.nl (2a02:26f0:c900:b::5f65:4a06) 56 data bytes
64 bytes from g2a02-26f0-c900-000b-0000-0000-5f65-4a06.deploy.static.akamaitechnologies.com (2a02:26f0:c900:b::5f65:4a06): icmp_seq=1 ttl=57 time=3.60 ms
64 bytes from g2a02-26f0-c900-000b-0000-0000-5f65-4a06.deploy.static.akamaitechnologies.com (2a02:26f0:c900:b::5f65:4a06): icmp_seq=2 ttl=57 time=3.62 ms
64 bytes from g2a02-26f0-c900-000b-0000-0000-5f65-4a06.deploy.static.akamaitechnologies.com (2a02:26f0:c900:b::5f65:4a06): icmp_seq=3 ttl=57 time=3.61 ms
64 bytes from g2a02-26f0-c900-000b-0000-0000-5f65-4a06.deploy.static.akamaitechnologies.com (2a02:26f0:c900:b::5f65:4a06): icmp_seq=4 ttl=57 time=3.77 ms
64 bytes from g2a02-26f0-c900-000b-0000-0000-5f65-4a06.deploy.static.akamaitechnologies.com (2a02:26f0:c900:b::5f65:4a06): icmp_seq=5 ttl=57 time=3.59 ms
64 bytes from g2a02-26f0-c900-000b-0000-0000-5f65-4a06.deploy.static.akamaitechnologies.com (2a02:26f0:c900:b::5f65:4a06): icmp_seq=6 ttl=57 time=3.64 ms
64 bytes from g2a02-26f0-c900-000b-0000-0000-5f65-4a06.deploy.static.akamaitechnologies.com (2a02:26f0:c900:b::5f65:4a06): icmp_seq=7 ttl=57 time=3.59 ms
64 bytes from g2a02-26f0-c900-000b-0000-0000-5f65-4a06.deploy.static.akamaitechnologies.com (2a02:26f0:c900:b::5f65:4a06): icmp_seq=8 ttl=57 time=3.63 ms
64 bytes from g2a02-26f0-c900-000b-0000-0000-5f65-4a06.deploy.static.akamaitechnologies.com (2a02:26f0:c900:b::5f65:4a06): icmp_seq=9 ttl=57 time=3.54 ms
no answer yet for icmp_seq=10
no answer yet for icmp_seq=11
no answer yet for icmp_seq=12
no answer yet for icmp_seq=13
no answer yet for icmp_seq=14
no answer yet for icmp_seq=15
no answer yet for icmp_seq=16
no answer yet for icmp_seq=17
no answer yet for icmp_seq=18
no answer yet for icmp_seq=19
no answer yet for icmp_seq=20
no answer yet for icmp_seq=21
no answer yet for icmp_seq=22
64 bytes from g2a02-26f0-c900-000b-0000-0000-5f65-4a06.deploy.static.akamaitechnologies.com (2a02:26f0:c900:b::5f65:4a06): icmp_seq=23 ttl=57 time=3.56 ms
64 bytes from g2a02-26f0-c900-000b-0000-0000-5f65-4a06.deploy.static.akamaitechnologies.com (2a02:26f0:c900:b::5f65:4a06): icmp_seq=24 ttl=57 time=3.62 ms
64 bytes from g2a02-26f0-c900-000b-0000-0000-5f65-4a06.deploy.static.akamaitechnologies.com (2a02:26f0:c900:b::5f65:4a06): icmp_seq=25 ttl=57 time=3.68 ms
64 bytes from g2a02-26f0-c900-000b-0000-0000-5f65-4a06.deploy.static.akamaitechnologies.com (2a02:26f0:c900:b::5f65:4a06): icmp_seq=26 ttl=57 time=3.58 ms
64 bytes from g2a02-26f0-c900-000b-0000-0000-5f65-4a06.deploy.static.akamaitechnologies.com (2a02:26f0:c900:b::5f65:4a06): icmp_seq=27 ttl=57 time=3.66 ms
64 bytes from g2a02-26f0-c900-000b-0000-0000-5f65-4a06.deploy.static.akamaitechnologies.com (2a02:26f0:c900:b::5f65:4a06): icmp_seq=28 ttl=57 time=3.60 ms
64 bytes from g2a02-26f0-c900-000b-0000-0000-5f65-4a06.deploy.static.akamaitechnologies.com (2a02:26f0:c900:b::5f65:4a06): icmp_seq=29 ttl=57 time=3.59 ms
^C
--- nu.nl ping statistics ---
29 packets transmitted, 16 received, 44.8276% packet loss, time 28340ms
rtt min/avg/max/mdev = 3.536/3.616/3.766/0.051 ms

[StaticZ]

Hier op een KPN glasvezelverbinding 100 ping requests zonder problemen.

code:

64 bytes from g2a02-26f0-fe00-0000-0000-0000-0213-c258.deploy.static.akamaitechnologies.com (2a02:26f0:fe00::213:c258): icmp_seq=100 ttl=60 time=5.98 ms
^C
--- tweakers.net ping statistics ---
100 packets transmitted, 100 received, 0% packet loss, time 99168ms
rtt min/avg/max/mdev = 5.087/5.972/6.869/0.277 ms

64 bytes from g2a02-26f0-fe00-0000-0000-0000-0213-c221.deploy.static.akamaitechnologies.com (2a02:26f0:fe00::213:c221): icmp_seq=103 ttl=60 time=7.98 ms
^C
--- nu.nl ping statistics ---
103 packets transmitted, 103 received, 0% packet loss, time 102193ms
rtt min/avg/max/mdev = 7.599/8.312/9.205/0.314 ms

[Vorkie]

StaticZ schreef op zaterdag 21 maart 2026 @ 15:22:
Hier op een KPN glasvezelverbinding 100 ping requests zonder problemen.

code:

64 bytes from g2a02-26f0-fe00-0000-0000-0000-0213-c258.deploy.static.akamaitechnologies.com (2a02:26f0:fe00::213:c258): icmp_seq=100 ttl=60 time=5.98 ms
^C
--- tweakers.net ping statistics ---
100 packets transmitted, 100 received, 0% packet loss, time 99168ms
rtt min/avg/max/mdev = 5.087/5.972/6.869/0.277 ms

64 bytes from g2a02-26f0-fe00-0000-0000-0000-0213-c221.deploy.static.akamaitechnologies.com (2a02:26f0:fe00::213:c221): icmp_seq=103 ttl=60 time=7.98 ms
^C
--- nu.nl ping statistics ---
103 packets transmitted, 103 received, 0% packet loss, time 102193ms
rtt min/avg/max/mdev = 7.599/8.312/9.205/0.314 ms

Jij pingt - 2a02:26f0:fe00::213:c221, die gaat hier ook goed.

Wij pingen;
2a02:26f0:c900:b::5f65:4a06 & 2a02:26f0:c900:b::5f65:4a2f

Hier trouwens ook KPN.

Ondertussen is Tweakers.net nu bij mij; 2a02:26f0:1180:35::210:6ad4 & 2a02:26f0:6100::6861:eab: en nu.nl 2a02:26f0:1180:35::210:6acc

Misschien dat ze de fout hebben gevonden en dat subnet hebben aangepast?

[Jef61]

Vorkie schreef op zaterdag 21 maart 2026 @ 15:29:
[...]


Jij pingt - 2a02:26f0:fe00::213:c221, die gaat hier ook goed.

Wij pingen;
2a02:26f0:c900:b::5f65:4a06 & 2a02:26f0:c900:b::5f65:4a2f

Hier trouwens ook KPN.

Ondertussen is Tweakers.net nu bij mij; 2a02:26f0:1180:35::210:6ad4 & 2a02:26f0:6100::6861:eab: en nu.nl 2a02:26f0:1180:35::210:6acc

Misschien dat ze de fout hebben gevonden en dat subnet hebben aangepast?

Als ik een andere DNS-server kies resolved het naar een ander IPv6 subnet (welke geen ping problemen heeft):

code:

[jef@cachyos-x8664 ~]$ nslookup tweakers.net 8.8.8.8
Server:         8.8.8.8
Address:        8.8.8.8#53
Non-authoritative answer:
Name:   tweakers.net
Address: 2a02:26f0:c900:b::5f65:4a0a
Name:   tweakers.net
Address: 2a02:26f0:c900:b::5f65:4a2f

[jef@cachyos-x8664 ~]$ nslookup tweakers.net 9.9.9.9
Server:         9.9.9.9
Address:        9.9.9.9#53
Non-authoritative answer:
Name:   tweakers.net
Address: 2a02:26f0:6d00:2a::210:1b84
Name:   tweakers.net
Address: 2a02:26f0:6d00:2a::210:1ba1

[jef@cachyos-x8664 ~]$ nslookup tweakers.net 1.1.1.1
Server:         1.1.1.1
Address:        1.1.1.1#53
Non-authoritative answer:
Name:   tweakers.net
Address: 2a02:26f0:1180:35::210:6ad4
Name:   tweakers.net
Address: 2a02:26f0:1180:35::210:6acd

[ Voor 14% gewijzigd door Jef61 op 21-03-2026 17:49 ]

[Jef61]

Quick en dirty oplossing is dus een andere DNS-server gebruiken?

Edit:
Cloudfare DNS nu ingesteld op de pihole, geen onderbrekingen tot nu toe (rare oplossing dit).

[ Voor 131% gewijzigd door Jef61 op 21-03-2026 18:26 ]

[Jef61]

Redelijk kansloos denk ik maar ik heb er een mailtje aan gewaagd naar Akamai support. Wel netjes al een casenummer teruggekregen.

[HarmoniousVibe]

Ik ben bezig om (bijna) alles dual stack te maken. Heb KPN FttH met een /48 prefix en heb OPNsense met een EdgeSwitch en wat UniFi AP's, gesegmenteerd in een aantal VLANs

Dit gaat op zich vrij soepel. Omdat ik netjes overal "VLAN 20 network" gebruik ipv een hardcoded IPv4 range, hoefde ik eigenlijk nauwelijks mijn firewall-regels aan te passen. Ik moest me even inlezen in Router Advertisements / radvd en de diverse flags, maar ik denk dat ik het redelijk onder de knie heb nu.

Mijn dilemma gaat eigenlijk over mijn WireGuard "Road Warrior" setup, zodat ik altijd van buiten mijn thuisnetwerk veilig kan benaderen. Aangezien WG point-to-point is, gaat het hele idee van RA niet op, dus in feite werk je altijd met statische assignments voor de tunnel (net als bij IPv4). Prima, maar mijn vraag is als volgt: is het beter om een GUA uit mijn prefix te gebruiken voor de tunnel, of om 2 fd00::/7-adressen te pakken? Als het er toe doet, ik wil enkel bij mijn eigen netwerk kunnen komen; ik hoef niet via de tunnel het internet op vanuit mijn netwerk.

En in bredere zin, hoe gaan jullie om met veranderende prefixes? Nu gebeurt dat volgens mij bijna nooit bij KPN, maar je weet maar nooit.. Voorheen had ik zowel een GUA als een ULA voor bijna alles, maar dat zorgde voor broadcastproblemen met NDP icm mijn UniFi APs. Het werkte lange tijd goed, maar op een gegeven moment had ik geen werkende ipv6 meer over wifi, tenzij ik handmatig een entry toevoegde aan de NDP table.. of mijn ULA stack weggooide, wat ik toen maar heb gedaan.

Enfin, nu heeft elk device dus een GUA uit mijn KPN-prefix. Werkt prima, maar wat als de prefix wijzigt? Wat wel goed gaat (volgens mij):

Mijn (V)LAN-interfaces tracken mijn WAN-interface, dus als ik via DHCPv6 een nieuwe prefix krijg, zouden de interfaces en de radvd automatisch mee moeten veranderen.

OPNsense heeft voor in de firewall "dynamic IPv6 host aliases" zodat ik enkel de laatste paar hextets hoef te hardcoden, dus die zijn prefix-independent.

Maar ik heb bijvoorbeeld ook een aantal AAAA-records in mijn Unbound. Volgens mij ontkom ik er niet echt aan om daar de prefix ook in te hardcoden. Dit probleem had ik met ULA uiteraard niet, omdat ik dan van begin tot eind het ip kon bepalen.

En wellicht zie ik zo nog dingen over het hoofd die ook misgaan als mijn prefix wjizigt..

Hoe kan ik dit het beste aanvliegen?

[RobertMe]

HarmoniousVibe schreef op donderdag 16 april 2026 @ 10:50:
Mijn dilemma gaat eigenlijk over mijn WireGuard "Road Warrior" setup, zodat ik altijd van buiten mijn thuisnetwerk veilig kan benaderen. Aangezien WG point-to-point is, gaat het hele idee van RA niet op, dus in feite werk je altijd met statische assignments voor de tunnel (net als bij IPv4). Prima, maar mijn vraag is als volgt: is het beter om een GUA uit mijn prefix te gebruiken voor de tunnel, of om 2 fd00::/7-adressen te pakken? Als het er toe doet, ik wil enkel bij mijn eigen netwerk kunnen komen; ik hoef niet via de tunnel het internet op vanuit mijn netwerk.

Ikzelf gebruik beide. Heb intern sowieso overal ULAs in gebruik. En voor Wireguard stel ik zowel handmatig een ULA als GUA in. Maar als je alleen met je LAN verbinding wilt maken is het ook prima om alleen een ULA te gebruiken. Een GUA is immers alleen een vereiste als je het internet op wilt.

En in bredere zin, hoe gaan jullie om met veranderende prefixes? Nu gebeurt dat volgens mij bijna nooit bij KPN, maar je weet maar nooit.. Voorheen had ik zowel een GUA als een ULA voor bijna alles, maar dat zorgde voor broadcastproblemen met NDP icm mijn UniFi APs. Het werkte lange tijd goed, maar op een gegeven moment had ik geen werkende ipv6 meer over wifi, tenzij ik handmatig een entry toevoegde aan de NDP table.. of mijn ULA stack weggooide, wat ik toen maar heb gedaan.

Ik heb al langer een UniFi stack dan dat ik IPv6 gebruik. Zelfs kortstondig met een USG gedraaid met zowel een ULA als GUA in gebruik op de VLANs (maar doordat de UniFi firewall toen op IP adres/subnet basis was was dat totaal onwerkbaar met dual stack v4 en v6 + een GUA die potentieel kan veranderen en je dus alle v6 regels zou moeten aanpassen ben ik toen overgestapt naar een andere, volledig zelfbouw (plain Debian) router).

Jouw problemen dat zowel een ULA als GUA naast elkaar niet werken herken ik dus niet.

[HarmoniousVibe]

Het heeft voor mij een hele tijd ook gewoon gewerkt naast elkaar, maar op een gegeven moment is dat gewoon gestopt met werken. Ik zou kunnen experimenteren met oudere firmwareversies van UniFi, maar daar zit ik ook niet echt op te wachten

[Raven]

HarmoniousVibe schreef op donderdag 16 april 2026 @ 10:50:
En in bredere zin, hoe gaan jullie om met veranderende prefixes?

Enfin, nu heeft elk device dus een GUA uit mijn KPN-prefix. Werkt prima, maar wat als de prefix wijzigt? Wat wel goed gaat (volgens mij):

Toen ik een tijdje terug probeerde uit te vogelen hoe de /48 op mijn Debian-router te krijgen, zat ik ook in gedachten met een potentieel wijzigende prefix.

Ik gebruik wide-dhcpv6-client om de /48 toegewezen te krijgen, die wordt dan (bij elke start van de client) door een commando in /etc/wide-dhcpv6/dhcp6c-script uit het logboek gevist, dus niet opgeslagen ergens. Daarna gebruikt dat script die /48 om de router-pc zelf van een IPv6-adres uit een /64 te voorzien, om daarna een radvd-config met meerdere VLAN's te genereren op basis van de verkregen /48.

Dat eerste, de router-pc zelf voorzien van IPv6, werkt , de door dat script gegenereerde radvd.conf (met zowel GUA als ULA config) moet ik nog testen.

Mocht de /48 veranderen, even wide-dhcpv6-client herstarten en het zou automatisch moeten werken, incl radvd.conf voor het netwerk achter de router-pc.

[Noahlvb]

HarmoniousVibe schreef op donderdag 16 april 2026 @ 10:50:
En in bredere zin, hoe gaan jullie om met veranderende prefixes? Nu gebeurt dat volgens mij bijna nooit bij KPN, maar je weet maar nooit.. Voorheen had ik zowel een GUA als een ULA voor bijna alles, maar dat zorgde voor broadcastproblemen met NDP icm mijn UniFi APs. Het werkte lange tijd goed, maar op een gegeven moment had ik geen werkende ipv6 meer over wifi, tenzij ik handmatig een entry toevoegde aan de NDP table.. of mijn ULA stack weggooide, wat ik toen maar heb gedaan.

Ik ben ook tegen die probleem aangelopen en al mijn bevindingen en oplossingen hier opgeschreven. Misschien heb jij er wat aan in jou setup?

[duvekot]

Raven schreef op donderdag 16 april 2026 @ 12:04:
[...]
Mocht de /48 veranderen, even wide-dhcpv6-client herstarten en het zou automatisch moeten werken, incl radvd.conf voor het netwerk achter de router-pc.

Van een werkende verbinding zal het subnet niet snel veranderen denk (hoop?) ik .. maar bij een herstart zou het wel kunnen .. maar dan krijg je in jou opstelling natuurlijk direct bij het opstarten al een andere prefix dus zou het toch automatisch goed moeten gaan toch?

Mijn vraag bij veranderende prefixes is voornamelijk op DNS gebied. Maken jullie ook DNS registraties aan voor de interne machines met het GUA adres? En OOK voor het ULA?

[Raven]

@duvekot Ik zit bij KPN, daar verandert die als het goed is (hopelijk) niet, maar ik dacht laat ik het gelijk ff goed doen

"Maken jullie ook DNS registraties aan voor de interne machines met het GUA adres"
Dat doe ik alleen met IPv4-addressen, niet IPv6. Bij GUA loop je al gauw tegen privacy extensions aan (het random veranderen van IPv6 adres), voor lokaal zou je denk ik dan beter fd00-adressen kunnen opzetten, die blijven (van wat ik lees) wel hetzelfde.

[RobertMe]

Raven schreef op donderdag 16 april 2026 @ 14:02:
"Maken jullie ook DNS registraties aan voor de interne machines met het GUA adres"
Dat doe ik alleen met IPv4-addressen, niet IPv6. Bij GUA loop je al gauw tegen privacy extensions aan (het random veranderen van IPv6 adres), voor lokaal zou je denk ik dan beter fd00-adressen kunnen opzetten, die blijven (van wat ik lees) wel hetzelfde.

ULAs en GUAs werken in mijn ervaring hetzelfde. Voor beide varianten van prefixes wordt zowel een vaste als een tijdelijke (dynamische) suffix gebruikt.

Per prefix zijn er dus 2 IP-adressen. Eentje die vast is en bedoeld is voor inkomend verkeer en eentje die dynamisch is en bedoeld is voor uitgaand verkeer (en daarmee dus ook bedoeld is voor retour verkeer van diegene waar je de verbinding mee op zet).

Maar zelf heb ik op mijn "servers" een statische "token" ingesteld. Deze hebben dus een "vast" IP adres binnen de prefix. Dus token "::2" zorgt voor fd00:db8::2 en 2001:db8::2. En als de prefix zou veranderen blijft het altijd ::2. In combinatie met een ULA is dat dus goed genoeg om in de DNS op te nemen. Waarbij ik intern ook helemaal geen IPv4 gebruik. Al mijn interne services zijn expliciet alleen via IPv6 bereikbaar (doordat ze niet luisteren op IPv4 en/of de firewall IPv4 niet toestaat).

[HarmoniousVibe]

Uit nieuwsgierigheid heb ik mijn AP's (UniFi U6-LR) gedowngrade naar de laatste 6.6-versie. Nu werken GUA en ULA wel weer langs elkaar zonder dat de AP overijverig probeert broadcastverkeer te voorkomen. Ik heb het sterkte vermoeden dat dit probleem in de allerlaatste versie is ontstaan (6.7.41). Lees er meer over in diverse fora. Niet alleen met ipv6, maar ook bepaalde (IoT) chipsets/devices ofzo

Nu hebben de meeste devices dus deze IP's:
- IPv4 (RFC1918)
- IPv6 GUA EUI-64 of RFC 7217 Stable Privacy (Apple)
- IPv6 GUA Privacy Extension address (standaardadres om naar buiten te treden)
- IPv6 ULA EUI-64 of RFC 7217 Stable Privacy (Apple)

Dan pakken sommige clients (Linux) via SLAAC ook nog een ULA Privacy Extension address. Weet niet goed wat het nut daarvan zou zijn (in mijn geval), maar goed, het kan ook geen kwaad volgens mij. Hooguit als ik iets in de firewall wil doen met die interface als src zou het wat lastig kunnen worden.

En dan heb ik voor sommige interfaces nog een static ULA gedefineerd om het mooi/kort/mac-adresonafhankelijk te houden. Deze staat gewoon naast de bovenstaande.

Qua domeinen zet ik een static ULA in (iets met ::2 meestal). Omdat ik alles via WireGuard doe heb ik behalve voor de tunnel zelf niet echt direct GUAs nodig om naar binnen te komen.

[duvekot]

HarmoniousVibe schreef op donderdag 16 april 2026 @ 17:21:
Uit nieuwsgierigheid heb ik mijn AP's (UniFi U6-LR) gedowngrade naar de laatste 6.6-versie. Nu werken GUA en ULA wel weer langs elkaar zonder dat de AP overijverig probeert broadcastverkeer te voorkomen. Ik heb het sterkte vermoeden dat dit probleem in de allerlaatste versie is ontstaan (6.7.41). Lees er meer over in diverse fora. Niet alleen met ipv6, maar ook bepaalde (IoT) chipsets/devices ofzo

Nu hebben de meeste devices dus deze IP's:
- IPv4 (RFC1918)
- IPv6 GUA EUI-64 of RFC 7217 Stable Privacy (Apple)
- IPv6 GUA Privacy Extension address (standaardadres om naar buiten te treden)
- IPv6 ULA EUI-64 of RFC 7217 Stable Privacy (Apple)

Dan pakken sommige clients (Linux) via SLAAC ook nog een ULA Privacy Extension address. Weet niet goed wat het nut daarvan zou zijn (in mijn geval), maar goed, het kan ook geen kwaad volgens mij. Hooguit als ik iets in de firewall wil doen met die interface als src zou het wat lastig kunnen worden.

En dan heb ik voor sommige interfaces nog een static ULA gedefineerd om het mooi/kort/mac-adresonafhankelijk te houden. Deze staat gewoon naast de bovenstaande.

Qua domeinen zet ik een static ULA in (iets met ::2 meestal). Omdat ik alles via WireGuard doe heb ik behalve voor de tunnel zelf niet echt direct GUAs nodig om naar binnen te komen.

Had je ook gelezen wat @Noahlvb beschreven had in zijn post? Deze pagina dus

[HarmoniousVibe]

duvekot schreef op donderdag 16 april 2026 @ 17:42:
[...]

Had je ook gelezen wat @Noahlvb beschreven had in zijn post? Deze pagina dus

Yup, die stonden bij mij al goed. Je zou denken dat met multicast “enhancement” en proxy ARP uit alles zou moeten werken, maar ik was al met die settings bezig geweest toen bij mij ipv6 eruit knalde en ik er achter kwam dat NDP basically niet meer werkte. Ik had toen ook meerdere posts gelezen van mensen die problemen hadden met broadcast en NDP.

[Raven]

@davegriffejoen Hmm, er gaat met wide-dhcpcv6 client iets mis met de renewal. In de journalctl-output zie ik dat de renewal goed gaat, maar ik zie wel dit:

Bash:

ay 03 19:15:23 PlrtzGlrb dhcp6c[825246]: get DHCP option IA_PD prefix, len 25
May 03 19:15:23 PlrtzGlrb dhcp6c[825246]:   IA_PD prefix: 2a02:*:*::/48 pltime=172800 vltime=259200
.............
May 03 19:15:23 PlrtzGlrb dhcp6c[825246]: update a prefix 2a02:*:*::/48 pltime=93943819838208, vltime=93943819924608

* Raven doet even wat rekenen.....
In de buurt van 3 miljoen jaar als ik het goed heb gedaan

Echter verdwijnt na 2 dagen het IPv6-adres dat door dhcp6c-script wordt toegewezen aan de PPPoE-interface. Heb een script dat elke minuut door cronjob wordt gerund, die checkt of er een publiek IPv6-adres is toegewezen. Nee? -> herstart wide-dhcpcv6 client waarna dhcp6c-script de /48 uit journalctl-output vist en op basis daarvan weer een IPv6 adres toewijst, en dat dus elke 2 dagen opnieuw.

[davegriffejoen]

@Raven laat je firewall de renew wel door? Upd port 546 uit mijn hoofd.

[Raven]

@davegriffejoen Check

Bash:

iifname "enp0s31f6.6.ppp" udp sport 547 udp dport 546 counter packets 80 bytes 14665 accept
oifname "enp0s31f6.6.ppp" udp sport 546 udp dport 547 counter packets 185 bytes 25299 accept

maar volgens het log gaat het wel goed:

Bash:

May 03 19:15:23 PlrtzGlrb dhcp6c[825246]: IA timeout for PD-0, state=ACTIVE
May 03 19:15:23 PlrtzGlrb dhcp6c[825246]: reset a timer on enp0s31f6.6.ppp, state=RENEW, timeo=0, retrans=9915
May 03 19:15:23 PlrtzGlrb dhcp6c[825246]: a new XID (c246f1) is generated
May 03 19:15:23 PlrtzGlrb dhcp6c[825246]: set client ID (len 14)
May 03 19:15:23 PlrtzGlrb dhcp6c[825246]: set server ID (len 14)
May 03 19:15:23 PlrtzGlrb dhcp6c[825246]: set elapsed time (len 2)
May 03 19:15:23 PlrtzGlrb dhcp6c[825246]: set option request (len 4)
May 03 19:15:23 PlrtzGlrb dhcp6c[825246]: set IA_PD prefix
May 03 19:15:23 PlrtzGlrb dhcp6c[825246]: set IA_PD
May 03 19:15:23 PlrtzGlrb dhcp6c[825246]: send renew to ff02::1:2%enp0s31f6.6.ppp
May 03 19:15:23 PlrtzGlrb dhcp6c[825246]: receive reply from fe80::627e:cdff:fe57:774a%enp0s31f6.6.ppp on enp0s31f6.6.ppp
May 03 19:15:23 PlrtzGlrb dhcp6c[825246]: get DHCP option client ID, len 14
May 03 19:15:23 PlrtzGlrb dhcp6c[825246]:   DUID: 00:01:00:01:31:2e:ae:46:80:ee:73:da:bd:ee
May 03 19:15:23 PlrtzGlrb dhcp6c[825246]: get DHCP option server ID, len 14
May 03 19:15:23 PlrtzGlrb dhcp6c[825246]:   DUID: 00:01:00:06:09:55:c0:05:10:51:72:26:11:e5
May 03 19:15:23 PlrtzGlrb dhcp6c[825246]: get DHCP option IA_PD, len 54
May 03 19:15:23 PlrtzGlrb dhcp6c[825246]:   IA_PD: ID=0, T1=86400, T2=138240
May 03 19:15:23 PlrtzGlrb dhcp6c[825246]: get DHCP option IA_PD prefix, len 25
May 03 19:15:23 PlrtzGlrb dhcp6c[825246]:   IA_PD prefix: 2a02:*:*::/48 pltime=172800 vltime=259200
May 03 19:15:23 PlrtzGlrb dhcp6c[825246]: get DHCP option status code, len 9
May 03 19:15:23 PlrtzGlrb dhcp6c[825246]:   status code: success
May 03 19:15:23 PlrtzGlrb dhcp6c[825246]: get DHCP option DNS, len 32
May 03 19:15:23 PlrtzGlrb dhcp6c[825246]: nameserver[0] 2a02:a47f:e000::54
May 03 19:15:23 PlrtzGlrb dhcp6c[825246]: nameserver[1] 2a02:a47f:e000::53
May 03 19:15:23 PlrtzGlrb dhcp6c[825246]: update an IA: PD-0
May 03 19:15:23 PlrtzGlrb dhcp6c[825246]: update a prefix 2a02:*:*::/48 pltime=93943819838208, vltime=93943819924608
May 03 19:15:23 PlrtzGlrb dhcp6c[825246]: status code for PD-0: success
May 03 19:15:23 PlrtzGlrb dhcp6c[825246]: removing an event on enp0s31f6.6.ppp, state=RENEW
May 03 19:15:23 PlrtzGlrb dhcp6c[825246]: executes /etc/wide-dhcpv6/dhcp6c-script
May 03 19:15:23 PlrtzGlrb dhcp6c[825246]: script "/etc/wide-dhcpv6/dhcp6c-script" terminated
May 03 19:15:23 PlrtzGlrb dhcp6c[825246]: got an expected reply, sleeping.

buiten die 3 miljoen jaar dan

[Jerrythafast]

172800 seconden is 48 uur, dat klinkt plausibel.
259200 seconden is 72 uur, ook plausibel.
Dit zijn duidelijk de bedoelde waardes.
Nu komt het: als je die getallen opschrijft in base 16 wordt het 0x0002A300 en 0x0003F480.
En die twee hele grote getallen? 0x55710002A300 en 0x55710003F480. Ergens haalt hij er nog wat bytes bij, namelijk 0x5571. Geen idee wat het betekent verder, maar het ziet eruit als een pointer cast bug in ieder geval

[Raven]

@Jerrythafast Ben benieuwd wat de maintainer er van zegt, vond emailadres en had daar al mailtje heen gestuurd. Anders maar bug-report indienen, bij Debian geloof ik nog nooit gedaan, althans niet dat ik mij kan herinneren

Gelijk in die mail gevraagd waarom de enige plek waar die prefix voorbij komt journalctl is, de slecht gedocumenteerde environment variable blijkt in Debian niet te bestaan, dan maar greppen in de output van journalctl....

[duvekot]

Raven schreef op dinsdag 5 mei 2026 @ 22:03:
@Jerrythafast Ben benieuwd wat de maintainer er van zegt, vond emailadres en had daar al mailtje heen gestuurd. Anders maar bug-report indienen, bij Debian geloof ik nog nooit gedaan, althans niet dat ik mij kan herinneren

Gelijk in die mail gevraagd waarom de enige plek waar die prefix voorbij komt journalctl is, de slecht gedocumenteerde environment variable blijkt in Debian niet te bestaan, dan maar greppen in de output van journalctl....

Is het deze bug?:

https://bugs.launchpad.ne.../wide-dhcpv6/+bug/1559741

Lijkt er dus al een tijdje in te zitten als dat het zelfde is 🤔

[Raven]

@duvekot Hmm, die heeft er wel wat van weg ja. Ik zat op https://bugs.debian.org/c...cpv6-client;dist=unstable te kijken

[Snow_King]

Mooie mijlpaal en ook gewoon leuk: Google ziet inmiddels net iets meer dan 50% van hun verkeer via IPv6 binnen komen, zie het zelf op: https://www.google.com/intl/en/ipv6/statistics.html

APNIC heeft er ook een blog over geschreven: https://blog.apnic.net/2026/04/28/google-hits-50-ipv6/

We zijn er nog niet, maar dit is wel weer mooi! 50% moet snel een 60 a 70% worden!

[Roetzen]

@Snow_King We zijn er inderdaad nog lang niet en het heeft ook wel erg lang geduurd. Plus dat het ook niet alles zegt. Hier in Nederland lopen we best achter. We hebben nota bene nog een grote provider die nog helemaal geen IPv6 aanbiedt. De dag dat we IPv4 kunnen uitschakelen ligt nog ver in de toekomst. Dus er is nog werk aan de winkel!

[duvekot]

vandaag ook maar aan de slag gegaan met het maken van een IPv6 ONLY netwerk hier in huis ... dus dan ook echt zonder transitie oplossingen etc .. en dan maar kijken waar het schip strand ... eerste horde .. RPi connect (wel zo handig om "iets" in dat netwerk te hebben waar je eenvoudig bij kan) .. die laat wel zien dat de RPi online is .. maar je kan er geen verbinding mee maken. De ICE (nee . niet die van Trump) pairs werken niet als je browser op een IPv4 netwerk zit .. dus de TURN servers van RPi Connect doen geen IPv4 <-> IPv6 vertaling voor je ...
ook maar even op het forum gemeld

[Roetzen]

Waar IPv6 in Nederland nog nauwelijks aanwezig is zijn de (semi) publieke Wifi netwerken. Supermarkten, bibliotheken, ziekenhuizen, campings, in de bus en in de trein, bijna overal is het IPv4 only. In meer dan drie jaar overal waar er publiek Wifi is, even kijken, heb ik er maar twee gezien waar er IPv6 is. Camping Boszicht in Laag Soeren en het H. F. Witte Centrum in De Bilt. Die laatste is niet heel vreemd want de Wifi wordt aldaar verzorgd door de HCC. Maar qua (semi) publiek Wifi is er dus nog veel werk aan de winkel.