Het grote IPv6 topic

[Roetzen]

RobertMe schreef op maandag 17 februari 2025 @ 18:24:
[...]

Dat van de Apple app store heb ik ook vaker gelezen. Toch is op mijn werk de server alleen bereikbaar via IPv4 en staat er een app in de store. Lijkt mij dus dat dat getest wordt in een xlat omgeving, en dus niet echt IPv6 only met ook geen xlat op netwerk niveau.

Ik denk dat je even twee dingen door elkaar haalt. De regel gaat niet over de bereikbaarheid van de App Store en de mogelijkheden van downloaden van apps maar over het functioneren van de apps zelf. Die moeten (ook) kunnen werken in een IPv6 only omgeving. Hoe dat precies getest wordt weet ik natuurlijk niet. Maar Apple kennende verwacht ik niet dat een app die het niet 100% doet in een volledige IPv6 only omgeving de App Store haalt.

[mrdemc]

Roetzen schreef op maandag 17 februari 2025 @ 19:52:
[...]

Ik denk dat je even twee dingen door elkaar haalt. De regel gaat niet over de bereikbaarheid van de App Store en de mogelijkheden van downloaden van apps maar over het functioneren van de apps zelf. Die moeten (ook) kunnen werken in een IPv6 only omgeving. Hoe dat precies getest wordt weet ik natuurlijk niet. Maar Apple kennende verwacht ik niet dat een app die het niet 100% doet in een volledige IPv6 only omgeving de App Store haalt.

Dat zegt @RobertMe toch? De backend server die zij gebruiken voor de door hun gepubliceerde app is alleen bereikbaar via IPv4. Toch, dus ondanks dat de server voor die App alleen via IPv4 werkt, staat deze als download in de Store.
Dus dat staat haaks tegenover hetgeen jij zegt.

[RobertMe]

Roetzen schreef op maandag 17 februari 2025 @ 19:52:
[...]

Ik denk dat je even twee dingen door elkaar haalt. De regel gaat niet over de bereikbaarheid van de App Store en de mogelijkheden van downloaden van apps maar over het functioneren van de apps zelf. Die moeten (ook) kunnen werken in een IPv6 only omgeving. Hoe dat precies getest wordt weet ik natuurlijk niet. Maar Apple kennende verwacht ik niet dat een app die het niet 100% doet in een volledige IPv6 only omgeving de App Store haalt.

Exact wat @mrdemc aangeeft. De server waarmee de app communiceert is IPv4 only. Toch staat de app in de store. Dus als de IPv6 verplichting er is (en ik heb volgens mij al vaker er van gelezen, niet alleen jouw posts) dan zal het wel eerder neerkomen op dat die niet mag crashen in een IPv6 only omgeving en/of moet werken in een XLAT omgeving en/of de app is helemaal niet zo strict gereviewd (aangezien alles achter een login zit).

Note overigens: ik beheer niet de server (en heb ooit wel regelmatiger IPv6 support aangekaart. Maarja, kan net zo goed tegen een muur praten), en heb ook niet de app ontwikkeld (noch ingediend bij de app stores).

[Roetzen]

RobertMe schreef op maandag 17 februari 2025 @ 20:48:
[...]

Exact wat @mrdemc aangeeft. De server waarmee de app communiceert is IPv4 only. Toch staat de app in de store. Dus als de IPv6 verplichting er is (en ik heb volgens mij al vaker er van gelezen, niet alleen jouw posts) dan zal het wel eerder neerkomen op dat die niet mag crashen in een IPv6 only omgeving en/of moet werken in een XLAT omgeving en/of de app is helemaal niet zo strict gereviewd (aangezien alles achter een login zit).

Ah, ik had het niet goed begrepen. Ja als die app met die IPv4 server en alleen met die server samen werkt dan kun je je afvragen wat er dan precies “IPv6 only getest is. Hmmm…

[Roetzen]

@ed1703
Je blijft maar volhouden dat ik het zou hebben over uitsluiten, maar dat is niet het geval. Verder discussiëren is voor mij dan niet zinvol dus stop ik er met deze subthread.

[Roetzen]

@RobertMe
Of misschien is het met die IPv6 only eis van Apple net als met het CE label. De maker van de app wordt op zijn blauwe ogen geloofd als hij verklaart dat de app kan functioneren in een IPv6 only omgeving. Er wordt niet pro actief op getest bij toelating tot de App Store.

Dat neemt niet weg dat ook al is de handhaving niet 100% de regel er wel degelijk is en dat geeft aan dat Apple een beleid voert dat IPv6 stimuleert.

Verder werd Freedom genoemd waar we niet zo veel meer van horen. Klopt, ze zijn een beetje stil. Mag ook want ze leveren al vanaf het prille begin volwaardig IPv6 aan alle klanten. Goede wijn behoeft geen krans. Probleem met Freedom is dat ze relatief duur zijn.

[Snow_King]

Roetzen schreef op dinsdag 18 februari 2025 @ 11:59:
@RobertMe
Of misschien is het met die IPv6 only eis van Apple net als met het CE label. De maker van de app wordt op zijn blauwe ogen geloofd als hij verklaart dat de app kan functioneren in een IPv6 only omgeving. Er wordt niet pro actief op getest bij toelating tot de App Store.

Dat neemt niet weg dat ook al is de handhaving niet 100% de regel er wel degelijk is en dat geeft aan dat Apple een beleid voert dat IPv6 stimuleert.

Verder werd Freedom genoemd waar we niet zo veel meer van horen. Klopt, ze zijn een beetje stil. Mag ook want ze leveren al vanaf het prille begin volwaardig IPv6 aan alle klanten. Goede wijn behoeft geen krans. Probleem met Freedom is dat ze relatief duur zijn.

De eis is dat je geen IPv4 adressen in je app hardcoded mag zetten, moeten URLs zijn.

Je moet API's gebruiken die je een IPv4 of IPv6 adres kunnen terug geven en daar moet je app mee overweg kunnen.

Als je een IP-adres ergens verwerkt, dan moet je tooling van Apple gebruiken die valideert of het een goed adres is.

Dergelijke eisen zitten er in de App Store, maar hoe precies weet ik ook niet. ChatGPT verteld mij:

Since June 1, 2016, Apple has required that all apps submitted to the App Store must work in IPv6-only network environments. Specifically, this means your app must not rely on IPv4-specific APIs, hard-coded IP addresses, or other assumptions about available transport. Instead, you should use high-level networking frameworks (for example, NSURLSession, CFNetwork, or URLSession in Swift) that automatically handle both IPv4 and IPv6 under the hood. Apple tests new app submissions in NAT64-only (i.e., IPv6-only) environments, and an app may be rejected if it fails to function over IPv6.

[Roetzen]

Snow_King schreef op dinsdag 18 februari 2025 @ 13:41:
[...]

De eis is dat je geen IPv4 adressen in je app hardcoded mag zetten, moeten URLs zijn.

Aha. Dat maakt een aantal dingen duidelijk. Misschien is het beter te zeggen dat de apps moeten kunnen werken middels een IPv6 only transportmiddel. Aangevuld met DNS64/NAT64. Maar zonder CLAT. Want dat is hoe de netwerken van de mobiele providers die IPv6 aanbieden momenteel werken. De apps in de App Store worden gebruikt op telefoons en tablets en die gebruiken de mobiele netwerken. IOS ondersteunt wel NAT64/DNS64 maar geen CLAT. Dar verklaart het verbod op hardcoded IPv4 adressen.

Je moet API's gebruiken die je een IPv4 of IPv6 adres kunnen terug geven en daar moet je app mee overweg kunnen.

Ok…

Als je een IP-adres ergens verwerkt, dan moet je tooling van Apple gebruiken die valideert of het een goed adres is.

Jaja….

Dergelijke eisen zitten er in de App Store, maar hoe precies weet ik ook niet. ChatGPT verteld mij:

Mijn vertrouwen in ChatGPT is beperkt maar het klinkt redelijk logisch. We zijn weer een stukje wijzer geworden denk ik 😀
Dank voor je toelichting.

[tomdh76]

Ik probeer af en toe wat met ipv6 maar blijf het lastig vinden.

Nu heb ik de volgende uitdaging. Ik wil een plex server via ipv6 beschikbaar maken op mydomain.com. Ik heb een OPNsense met HAproxy als reverse proxy die prima werkt voor ipv4. Voor ipv6 maak een AAAA record aan in cloudflare die ik dacht naar het publieke ipv6 adres van de plex server moest verwijzen maar dan zit HA proxy er natuurlijk niet tussen. En die HAproxy gebruik ik ook voor certificaten. Dus nu laat ik het AAAA record naar de publieke IPV6 van opnsense verwijzen. Daarop luistert dan HAproxy op [::]:443. Dit lijkt het te doen. Maar ik heb ook eerder begrepen dat het publieke IPV6 van de firewall telkens verandert. (kan ook natuurlijk met ipv4 maar dat gebeurt minder vaak?)

Is dit nu de goede methode of doe ik het verkeerd?

[RobertMe]

tomdh76 schreef op donderdag 20 februari 2025 @ 14:19:
Ik probeer af en toe wat met ipv6 maar blijf het lastig vinden.

Nu heb ik de volgende uitdaging. Ik wil een plex server via ipv6 beschikbaar maken op mydomain.com. Ik heb een OPNsense met HAproxy als reverse proxy die prima werkt voor ipv4. Voor ipv6 maak een AAAA record aan in cloudflare die ik dacht naar het publieke ipv6 adres van de plex server moest verwijzen maar dan zit HA proxy er natuurlijk niet tussen. En die HAproxy gebruik ik ook voor certificaten. Dus nu laat ik het AAAA record naar de publieke IPV6 van opnsense verwijzen. Daarop luistert dan HAproxy op [::]:443. Dit lijkt het te doen. Maar ik heb ook eerder begrepen dat het publieke IPV6 van de firewall telkens verandert. (kan ook natuurlijk met ipv4 maar dat gebeurt minder vaak?)

Is dit nu de goede methode of doe ik het verkeerd?

Als het werkt kan het de juiste methode zijn

Dat continu veranderen zou alleen mogen komen door de IPv6 privacy extension. Maar, bii IPv6 is het ook normaal om meerdere adressen te hebben. Als OPNSense al gebruikt maakt van de privacy extension (en dat lijkt me onwaarschijnlijk) dan zijn er twee IPv6 adressen, eentje die vaak veranderd, en eentje die statisch is. Waarbii statisch uiteraard afhankelijk is van de ISP. Bij een Ziggo heb je geen statisch adres. Maar in de 2 jaar dat ik mijn huidige router heb is noch het IPv4 adres noch de IPv6 prefix veranderd.

Waar je echter ook nog rekening mee moet houden is dat een router aan de WAN kant een totaal ander IPv6 adres heeft dan aan de LAN kant. Aan de WAN kant is het immers een gewone "client" in het subnet van de ISP en bepaalt die via SLAAC een IPv6 adres binnen de prefix die de ISP gebruikt. Aan de LAN kant wordt echter via DHCP PD een volledige prefix opgehaald, zal de LAN interface mogelijk zichzelf een ::1 adres geven binnen die prefix, etc.

[tomdh76]

RobertMe schreef op donderdag 20 februari 2025 @ 15:11:
[...]

Als het werkt kan het de juiste methode zijn

Dat continu veranderen zou alleen mogen komen door de IPv6 privacy extension. Maar, bii IPv6 is het ook normaal om meerdere adressen te hebben. Als OPNSense al gebruikt maakt van de privacy extension (en dat lijkt me onwaarschijnlijk) dan zijn er twee IPv6 adressen, eentje die vaak veranderd, en eentje die statisch is. Waarbii statisch uiteraard afhankelijk is van de ISP. Bij een Ziggo heb je geen statisch adres. Maar in de 2 jaar dat ik mijn huidige router heb is noch het IPv4 adres noch de IPv6 prefix veranderd.

Waar je echter ook nog rekening mee moet houden is dat een router aan de WAN kant een totaal ander IPv6 adres heeft dan aan de LAN kant. Aan de WAN kant is het immers een gewone "client" in het subnet van de ISP en bepaalt die via SLAAC een IPv6 adres binnen de prefix die de ISP gebruikt. Aan de LAN kant wordt echter via DHCP PD een volledige prefix opgehaald, zal de LAN interface mogelijk zichzelf een ::1 adres geven binnen die prefix, etc.

Als ik van internet naar de plex server wil heb ik toch alleen de WAN ipv6 adres nodig? Die heb ik via de shell van OPNsense gevonden via curl -6 icanhazip.com. Ik snap je opmerking dus niet over waarom ik rekening moet houden met de Ipv6 van de router in het lan.

[Snow_King]

tomdh76 schreef op donderdag 20 februari 2025 @ 17:14:
[...]


Als ik van internet naar de plex server wil heb ik toch alleen de WAN ipv6 adres nodig? Die heb ik via de shell van OPNsense gevonden via curl -6 icanhazip.com. Ik snap je opmerking dus niet over waarom ik rekening moet houden met de Ipv6 van de router in het lan.

Klopt, maar het WAN adres van je Plex server, die is ander dan die van je OPNsense router :-)

[duvekot]

tomdh76 schreef op donderdag 20 februari 2025 @ 17:14:
[...]


Als ik van internet naar de plex server wil heb ik toch alleen de WAN ipv6 adres nodig? Die heb ik via de shell van OPNsense gevonden via curl -6 icanhazip.com. Ik snap je opmerking dus niet over waarom ik rekening moet houden met de Ipv6 van de router in het lan.

Deel eens een plaatje van je netwerk .. dus met je router, ha-proxy en de feitelijke Plex server ...en laat eens zien welke IPv6 adressen er aan al die servers/hosts/machines zijn toegewezen (GUA/ULA/LLA)

Misschien dat je dan duidelijk krijgt welke adressen je waarvoor kan gebruiken.

[tomdh76]

duvekot schreef op donderdag 20 februari 2025 @ 17:55:
[...]

Deel eens een plaatje van je netwerk .. dus met je router, ha-proxy en de feitelijke Plex server ...en laat eens zien welke IPv6 adressen er aan al die servers/hosts/machines zijn toegewezen (GUA/ULA/LLA)

Misschien dat je dan duidelijk krijgt welke adressen je waarvoor kan gebruiken.

Bij deze. Ik weet niet of je het hele ipv6 adres zo maar op internet mag zetten? Dit zijn de publieke adressen. Of wil je de link local adressen?

Internet
|
|-- OPNsense Router (2a02:a469 xxxxxxxxxx)
|
|-- HAProxy (luistert op [::]:80 en [::]:443
|
|-- Plex Server (2a02:a469:68e9 xxxxxxxxxxx)

[tomdh76]

Snow_King schreef op donderdag 20 februari 2025 @ 17:35:
[...]

Klopt, maar het WAN adres van je Plex server, die is ander dan die van je OPNsense router :-)

Zeker maar het verkeer loopt via de HAproxy want die moet een certificaat maken voor de plex server

[valkenier]

tomdh76 schreef op donderdag 20 februari 2025 @ 14:19:
Ik probeer af en toe wat met ipv6 maar blijf het lastig vinden.

Nu heb ik de volgende uitdaging. Ik wil een plex server via ipv6 beschikbaar maken op mydomain.com. Ik heb een OPNsense met HAproxy als reverse proxy die prima werkt voor ipv4. Voor ipv6 maak een AAAA record aan in cloudflare die ik dacht naar het publieke ipv6 adres van de plex server moest verwijzen maar dan zit HA proxy er natuurlijk niet tussen. En die HAproxy gebruik ik ook voor certificaten. Dus nu laat ik het AAAA record naar de publieke IPV6 van opnsense verwijzen. Daarop luistert dan HAproxy op [::]:443. Dit lijkt het te doen. Maar ik heb ook eerder begrepen dat het publieke IPV6 van de firewall telkens verandert. (kan ook natuurlijk met ipv4 maar dat gebeurt minder vaak?)

Is dit nu de goede methode of doe ik het verkeerd?

Ik denk dat je even dit soort handleidingen moet raadplegen: https://webhostinggeeks.c...aproxy-with-ipv6-support/

[duvekot]

tomdh76 schreef op donderdag 20 februari 2025 @ 18:52:
[...]


Bij deze. Ik weet niet of je het hele ipv6 adres zo maar op internet mag zetten? Dit zijn de publieke adressen. Of wil je de link local adressen?

Internet
|
|-- OPNsense Router (2a02:a469 xxxxxxxxxx)
|
|-- HAProxy (luistert op [::]:80 en [::]:443
|
|-- Plex Server (2a02:a469:68e9 xxxxxxxxxxx)

Draait de Ha-proxy op de OPNsense Router?

En wat is de toegevoegde waarde van die Ha-proxy? Heb je twee Plex servers waar je een load balancing of HA opzet voor nodig hebt?

Welke firewall rules heb je op de router staan?

Met IPv6 kan je natuurlijk gewoon rechtstreeks naar die Plex Server als je zou willen .. je hebt gewonnen publieke IP adressen en geen NAT meer nodig.

[RobertMe]

tomdh76 schreef op donderdag 20 februari 2025 @ 18:52:
[...]


Bij deze. Ik weet niet of je het hele ipv6 adres zo maar op internet mag zetten? Dit zijn de publieke adressen. Of wil je de link local adressen?

Internet
|
|-- OPNsense Router (2a02:a469 xxxxxxxxxx)
|
|-- HAProxy (luistert op [::]:80 en [::]:443
|
|-- Plex Server (2a02:a469:68e9 xxxxxxxxxxx)

Als HAProxy luistert op :: dan luistert die dus op alle interfaces en adressen. Oftewel: luistert niet alleen op "OPNsense Router (2a02:a469 xxxxxxxxxx)" maar ook op een van de in "2a02:a469:68e9 xxxxxxxxxxx". Welke je vervolgens gebruikt is aan jou, dat was een beetje mijn punt. Je hoeft niet het GUA van het WAN interface te gebruiken, je kunt ook de GUA van (een van de) LAN interfaces pakken.

@duvekot , de reden van HAProxy staat al benoemd. SSL termination. Zelf draai ik geen Plex, maar ik kan mij zomaar indenken dat die geen SSL doet. Daarom dat HAProxy er voor is gezet.
Maarja, wat SSL echt toevoegt? Nog steeds kan de hele wereld verbinden, alleen kan niet de hele wereld meekijken. Ik zou er gewoon lekker een VPN voor gebruiken. Dan kunnen alleen die met VPN toegang verbinden. En SSL doet er dan een stuk minder toe.

[ed1703]

RobertMe schreef op donderdag 20 februari 2025 @ 19:36:
[...]

Zelf draai ik geen Plex, maar ik kan mij zomaar indenken dat die geen SSL doet. Daarom dat HAProxy er voor is gezet.
Maarja, wat SSL echt toevoegt? Nog steeds kan de hele wereld verbinden, alleen kan niet de hele wereld meekijken. Ik zou er gewoon lekker een VPN voor gebruiken. Dan kunnen alleen die met VPN toegang verbinden. En SSL doet er dan een stuk minder toe.

Plex kan gewoon SSL doen, maar als je op je HAproxy al je SSL verkeer al termineert heeft dat apart op Plex gaan doen ook weinig nut natuurlijk.

[tomdh76]

RobertMe schreef op donderdag 20 februari 2025 @ 19:36:
[...]

Als HAProxy luistert op :: dan luistert die dus op alle interfaces en adressen. Oftewel: luistert niet alleen op "OPNsense Router (2a02:a469 xxxxxxxxxx)" maar ook op een van de in "2a02:a469:68e9 xxxxxxxxxxx". Welke je vervolgens gebruikt is aan jou, dat was een beetje mijn punt. Je hoeft niet het GUA van het WAN interface te gebruiken, je kunt ook de GUA van (een van de) LAN interfaces pakken.

@duvekot , de reden van HAProxy staat al benoemd. SSL termination. Zelf draai ik geen Plex, maar ik kan mij zomaar indenken dat die geen SSL doet. Daarom dat HAProxy er voor is gezet.
Maarja, wat SSL echt toevoegt? Nog steeds kan de hele wereld verbinden, alleen kan niet de hele wereld meekijken. Ik zou er gewoon lekker een VPN voor gebruiken. Dan kunnen alleen die met VPN toegang verbinden. En SSL doet er dan een stuk minder toe.

Ah ok, dan zou HA proxy dus inderdaad ook op het ipv6 moeten luisteren van Plex. Dan zet ik mijn AAAA record in cloudflare weer terug naar plex ipv6.

Wbt VPN: het mooie aan die HAproxy config op OPNsense vind ik dat je kan instellen dat alleen bepaalde ip adressen publieke toegang hebben. (https://forum.opnsense.org/index.php?topic=23339.555)

[RobertMe]

tomdh76 schreef op donderdag 20 februari 2025 @ 20:08:
[...]


Ah ok, dan zou HA proxy dus inderdaad ook op het ipv6 moeten luisteren van Plex. Dan zet ik mijn AAAA record in cloudflare weer terug naar plex ipv6.

Ik bedoelde niet het Plex adres, maar het adres in hetzelfde subnet, dat de (V)LAN interface in OPNSense heeft. (En dat is dus een ander /64 subnet dan wat de WAN interface heeft).

[tomdh76]

RobertMe schreef op donderdag 20 februari 2025 @ 20:16:
[...]

Ik bedoelde niet het Plex adres, maar het adres in hetzelfde subnet, dat de (V)LAN interface in OPNSense heeft. (En dat is dus een ander /64 subnet dan wat de WAN interface heeft).

Dank voor je snelle reply; ik zat weer naar een cloudflare error te kijken; website is down...
Het lijkt met het ipv6 adres van de lan vooralsnog te werken

Dank allen!

[Noahlvb]

Iemand ervaring met clat (specifiek op almalinux / RHEL)? Ik probeer het nu voor enkele IPv6 only server bij Hetzner in te regelen maar dat lukt niet. Op mijnlaptop thuis die Fedora draait heb ik het zelfde euvel. Clatd meld dat alles goed gaat maar al het IPv4 verkeer dat dus vertaald zou moeten worden is unreachable. Ik probeer gebruik te maken van de publieke nat64 servers van nat64.net.

[Roetzen]

Noahlvb schreef op vrijdag 28 februari 2025 @ 14:39:
Iemand ervaring met clat (specifiek op almalinux / RHEL)? Ik probeer het nu voor enkele IPv6 only server bij Hetzner in te regelen maar dat lukt niet. Op mijnlaptop thuis die Fedora draait heb ik het zelfde euvel. Clatd meld dat alles goed gaat maar al het IPv4 verkeer dat dus vertaald zou moeten worden is unreachable. Ik probeer gebruik te maken van de publieke nat64 servers van nat64.net.

Met CLAT heb ik geen ervaring maar wel met de NAT64/DNS64 van nat64.net. Dat doet voor mij wat het moet doen, dus daar ligt het denk ik niet aan.

[Noahlvb]

Als toelichting: clat is wanneer je een nat64 gebruikt zonder de dns64 (met name zodat dnssec niet breekt). Clat maakt dan een interface aan met een default route voor ipv4, waardoor ipv4 verkeer dan vervolgens over ipv6 naar de nat64 server wordt getransporteerd.

[Roetzen]

Hmm.... Ik dacht dat CLAT een oplossing was om te voorzien in het probleem dat DNS64 niet werkt met hard coded IPv4 adressen...

[Noahlvb]

Ja idd die use case heb je ook nog.

[Noahlvb]

Recent was ik opzoek naar een internet provider die IPv6 leverd. Van KPN en Ziggo wist ik dat ze dat doen maar dat zijn nou net clubs die ik net wat te duur vond. Nergens online kon ik een goed overzicht vinden en de providers zelf hebben het vaak ook schaars op hun site. Dus ik heb een heel erg 2000 siteje gemaakt met een overzicht. Ik vul deze nogsteeds aan want mijn zoektocht is nog niet over. Schijnbaar kan het per postcode gebied verschillen. Dus misschien heeft iemand wat aan de info en als je aanvullende info hebt is het altijd welkom.
https://nederland-ipv6.noahlvb.nl

[RobertMe]

Noahlvb schreef op maandag 10 maart 2025 @ 22:01:
Recent was ik opzoek naar een internet provider die IPv6 leverd. Van KPN en Ziggo wist ik dat ze dat doen maar dat zijn nou net clubs die ik net wat te duur vond. Nergens online kon ik een goed overzicht vinden en de providers zelf hebben het vaak ook schaars op hun site. Dus ik heb een heel erg 2000 siteje gemaakt met een overzicht. Ik vul deze nogsteeds aan want mijn zoektocht is nog niet over. Schijnbaar kan het per postcode gebied verschillen. Dus misschien heeft iemand wat aan de info en als je aanvullende info hebt is het altijd welkom.
https://nederland-ipv6.noahlvb.nl

Wellicht ook "shamen"? Niet om het shamen, wel om duidelijk te zien in wie het dus niet doet. Nu zie je niet of een ISP geen IPv6 doet of dat die simpelweg ontbreekt. (Misschien denkt nu iemand dat Odido toch wellicht IPv6 doet).

En v.w.b. een niet uitputtelijke lijst aan ISPs kun je wellicht iets vinden op de websites van KPN WBA, Delta Netwerk, ODF, ...? Een provider die ik in ieder geval "mis" is Glasnet. Ook zij leveren IPv6. Zelfs een statisch IP/prefix, dat wellicht ook een leuk gegeven is? De standaard zegt dan wel dat een prefix vast moet staan. Maar dat betekent niet dat een ISP zich daar aan houdt.

En bij mobiele providers heb je nu KPN staan. Maar dat geldt in ieder geval ook voor dochters Simyo & Youfone, kan ik uit eigen ervaring vertellen.

Houd je ook bij of de pagina via IPv6 vs IPv4 wordt bezocht?

[Maasluip]

RobertMe schreef op maandag 10 maart 2025 @ 23:10:
[...]

Wellicht ook "shamen"?

Ik zou zeker een lijstje maken met

ongeschikt

geschikt

[Roetzen]

@Noahlvb
Caiway geeft een “persistent” IPv6 prefix. In de 18 maanden dat ik IPv6 van Caiway heb, is de prefix niet gewijzigd.

[RobertMe]

Roetzen schreef op dinsdag 11 maart 2025 @ 19:40:
@Noahlvb
Caiway geeft een “persistent” IPv6 prefix. In de 18 maanden dat ik IPv6 van Caiway heb, is de prefix niet gewijzigd.

Maar ze kennen er geen toe toch? Het is geen statische prefix. Alleen veranderd die niet zo vaak.

Sinds ik 2 jaar terug mijn router vervangen heb heeft die ook hetzelfde IPv4 adres + IPv6 prefix, van Ziggo. Totdat ik afgelopen weekend een reboot van beiden deed. En toen was het IPv4 adres ineens veranderd. Maar de IPv6 prefix dus niet (en ook het IPv6 adres op de WAN interface niet, for that matter).

[Snow_King]

RobertMe schreef op dinsdag 11 maart 2025 @ 20:33:
[...]

Maar ze kennen er geen toe toch? Het is geen statische prefix. Alleen veranderd die niet zo vaak.

Sinds ik 2 jaar terug mijn router vervangen heb heeft die ook hetzelfde IPv4 adres + IPv6 prefix, van Ziggo. Totdat ik afgelopen weekend een reboot van beiden deed. En toen was het IPv4 adres ineens veranderd. Maar de IPv6 prefix dus niet (en ook het IPv6 adres op de WAN interface niet, for that matter).

Een prefix die je via DHCPv6 krijgt kan nog steeds statisch zijn, is gewoon afhankelijk van wat er in de DB van de DHCP server staat.

In DOCSIS netwerken kan je bijv de subscriber-id pakken als DHCP server en dan krijg je als klant altijd de zelfde prefix, ook als je je router vervangt.

[RobertMe]

Snow_King schreef op dinsdag 11 maart 2025 @ 21:21:
[...]
Een prefix die je via DHCPv6 krijgt kan nog steeds statisch zijn, is gewoon afhankelijk van wat er in de DB van de DHCP server staat.

In DOCSIS netwerken kan je bijv de subscriber-id pakken als DHCP server en dan krijg je als klant altijd de zelfde prefix, ook als je je router vervangt.

Klopt uiteraard. Maar er zit natuurlijk een verschil tussen een ISP die zegt "zal nooit veranderen" en de observatie "is nog nooit veranderd". En naar mijn idee doet @Roetzen het laatste. "Is nog nooit veranderd", maar dat betekent dus niet dat de ISP garandeert dat die niet veranderd. En waar die nu "in 18 maanden" nog niet veranderd is kan die volgende week 3x veranderen.

En nouja, het gaat over Caiway, die opgaat in Delta (/sowieso 2 namen op 1 toko zijn). En daarvan heb ik een tijd terug gelezen dat zakelijke klanten met een statistisch IP adres (daadwerkelijk de feature dus, die alleen bij de duurste zakelijke abos te krijgen is) bericht kregen dat op datum X hun IP adres zou veranderen (waarbij ik twijfel of het nieuwe IP al bekend was/in de mail stond). Dus zelfs een gegarandeerd statisch IP adres statement van hun hoort een asterisk bij dat het toch niet zo gegarandeerd is.

[Snow_King]

RobertMe schreef op dinsdag 11 maart 2025 @ 21:31:
[...]

Klopt uiteraard. Maar er zit natuurlijk een verschil tussen een ISP die zegt "zal nooit veranderen" en de observatie "is nog nooit veranderd". En naar mijn idee doet @Roetzen het laatste. "Is nog nooit veranderd", maar dat betekent dus niet dat de ISP garandeert dat die niet veranderd. En waar die nu "in 18 maanden" nog niet veranderd is kan die volgende week 3x veranderen.

En nouja, het gaat over Caiway, die opgaat in Delta (/sowieso 2 namen op 1 toko zijn). En daarvan heb ik een tijd terug gelezen dat zakelijke klanten met een statistisch IP adres (daadwerkelijk de feature dus, die alleen bij de duurste zakelijke abos te krijgen is) bericht kregen dat op datum X hun IP adres zou veranderen (waarbij ik twijfel of het nieuwe IP al bekend was/in de mail stond). Dus zelfs een gegarandeerd statisch IP adres statement van hun hoort een asterisk bij dat het toch niet zo gegarandeerd is.

Eens hoor. Het kan zo maar zijn dat bij een migratie je v6 subnet toch ineens veranderd.

Ik heb Ziggo Zakelijk Internet Pro en daar heb ik in mijn oplever documenten hardcoded een IPv4 /30 en IPv6 /48 subnet geleverd gekregen.

Hier zal ook vast een asterisk bij mogen, maar ik mocht deze adressen wel gewoon hardcoded in mijn MikroTik router zetten, want DHCP is daar niet beschikbaar.

Wat dat betreft ben ik prima tevreden met mijn Ziggo 1000/100 verbinding. Dat stuk hebben ze prima geregeld.

[Roetzen]

@RobertMet
Delta cq Caiway zegt zelf dat hun IPv6 prefixen “persistent” zijn. Dat is geen 100% garantie dat het nooit zal veranderen maar wel dat je er van uit kunt gaan dat het niet zo maar willekeurig verandert. En mijn observatie bevestigt dat. Overigens lijkt Ziggo ook die kant op te gaan al willen die dat nog niet hardop zeggen.

[Noahlvb]

Thanks voor alle feedback en reacties. Ik heb een boel verwerkt inmiddels. Ik heb ook een kolom toegevoegd met of de prefix vast is of niet.

RobertMe schreef op maandag 10 maart 2025 @ 23:10:
[...]

Wellicht ook "shamen"? Niet om het shamen, wel om duidelijk te zien in wie het dus niet doet. Nu zie je niet of een ISP geen IPv6 doet of dat die simpelweg ontbreekt. (Misschien denkt nu iemand dat Odido toch wellicht IPv6 doet).

En v.w.b. een niet uitputtelijke lijst aan ISPs kun je wellicht iets vinden op de websites van KPN WBA, Delta Netwerk, ODF, ...? Een provider die ik in ieder geval "mis" is Glasnet. Ook zij leveren IPv6. Zelfs een statisch IP/prefix, dat wellicht ook een leuk gegeven is? De standaard zegt dan wel dat een prefix vast moet staan. Maar dat betekent niet dat een ISP zich daar aan houdt.

En bij mobiele providers heb je nu KPN staan. Maar dat geldt in ieder geval ook voor dochters Simyo & Youfone, kan ik uit eigen ervaring vertellen.

Houd je ook bij of de pagina via IPv6 vs IPv4 wordt bezocht?

Thanks voor je input ik heb het verwerkt. Ik had al een goeie lijst ISP's maar toch nog wat extra door weten te spitten. Ik houd niet bij of de website vanaf v4 of v6 wordt bezocht want ik gebruik plausible voor stats en die is bets privacy vriendelijk.

[Jerrythafast]

Noahlvb schreef op maandag 10 maart 2025 @ 22:01:
Recent was ik opzoek naar een internet provider die IPv6 leverd. Van KPN en Ziggo wist ik dat ze dat doen maar dat zijn nou net clubs die ik net wat te duur vond. Nergens online kon ik een goed overzicht vinden en de providers zelf hebben het vaak ook schaars op hun site. Dus ik heb een heel erg 2000 siteje gemaakt met een overzicht. Ik vul deze nogsteeds aan want mijn zoektocht is nog niet over. Schijnbaar kan het per postcode gebied verschillen. Dus misschien heeft iemand wat aan de info en als je aanvullende info hebt is het altijd welkom.
https://nederland-ipv6.noahlvb.nl

Ik was toevallig ook op zoek en heb op GoT gevraagd in het Youfone topic en Budget topic of IPv6 ondersteund wordt.

Budget: Wel, maar schijnbaar niet op het providermodem:
Jerrythafast in "[Budget Alles-in-1] Ervaringen & discussie - Deel 2"

Youfone: Wel
Jerrythafast in "[Youfone Internet/TV] Ervaringen & Discussie"


Wat info uit eigen ervaring:

KPN: Wel, maar Experiabox v10 heeft momenteel een IPv6-bug:
https://community.kpn.com...4-12-11-628721?tid=628721
Inderdaad "praktisch" vast, maar toen de firmware met deze bug werd uitgerold werd de delegated prefix wel veranderd van 2a02:xxxx:yyyy:1:/64 naar 2a02:xxxx:yyyy:0:/64. En die kun je nu op de nieuwe firmware niet (meer?) wijzigen. (De bug is trouwens dat hij wel RA's verstuurt voor :1: maar die zijn niet routeerbaar van/naar het internet.)

RobertMe schreef op maandag 10 maart 2025 @ 23:10:
En bij mobiele providers heb je nu KPN staan. Maar dat geldt in ieder geval ook voor dochters Simyo & Youfone, kan ik uit eigen ervaring vertellen.

Hier kan ik ook aan toevoegen, uit eigen ervaring
Simpel (op Odido netwerk): Nee

[davegriffejoen]

@Noahlvb op je site staat Youfone op nee, maar is qua internet (ook ipv6) exact hetzelfde als kpn.

[Noahlvb]

davegriffejoen schreef op woensdag 12 maart 2025 @ 21:23:
@Noahlvb op je site staat Youfone op nee, maar is qua internet (ook ipv6) exact hetzelfde als kpn.

Thanks voor de info ga het erop zetten. Kon er online niks over vinden tot op heden. Enige idee wat voor prefix ze leveren?

[RobertMe]

Noahlvb schreef op woensdag 12 maart 2025 @ 21:42:
[...]

Thanks voor de info ga het erop zetten. Kon er online niks over vinden tot op heden. Enige idee wat voor prefix ze leveren?

Ik denk dat het antwoord op die vraag zit in de "exact hetzelfde als KPN"

[davegriffejoen]

@Noahlvb zoals RobertMe aangeeft. Precies hetzelfde als KPN, dus /48 en praktisch vast.

[Noahlvb]

davegriffejoen schreef op donderdag 13 maart 2025 @ 06:28:
@Noahlvb zoals RobertMe aangeeft. Precies hetzelfde als KPN, dus /48 en praktisch vast.

Ja thanks voor de info, even overheen gelezen. Is bijgewerkt.

[Roetzen]

Niet alleen is de prefix bij Delta/Caiway "persistent", het lijkt op een of andere manier aan mij persoonlijk gekoppeld. Ik ben van Caiway naar Delta overgestapt. Met het hele circus van ander XS2426G-B modem installeren en zo. Mijn abbo bij Delta is vanochtend vroeg in gegaan. En tot mijn stomme verbazing zie ik dat ik van Delta DEZELFDE IPv6 PREFIX heb gekregen als die ik eerst van Caiway had. Die prefix is zo "persistent" dat ie de overstap van Caiway naar Delta heeft overleeft. Wonderlijk!

[Roetzen]

De “baas” van ip6.me is overleden. Het zou jammer zijn als het weg valt. Wie neemt het over?

Notice: The owner of ip4.me/ip6.me, Kevin Loch, passed away.
The Kevin M Loch Estate will be shutting down Kevin's websites in the near future (4/1/2025).
Inquiries for purchasing Kevin's domains may be sent to [e-mail].

Click this link to continue to your ip4/ip6 address reporting Website

List of Websites impacted: ip4.me, ip4only.me
ip6addr.com, ip6addr.net, ip6addr.org
ip6.me, ip6only.me
ipv6addr.com, ipv6addr.net, ipv6addr.org
onlyip4.me, onlyip6.me
whatismyipv6address.com, whatismyipv6address.net, whatismyipv6address.org
whatismyv6.com, whatismyv6.net, whatismyv6.

[MOmax]

Noahlvb schreef op maandag 10 maart 2025 @ 22:01:... Ik vul deze nogsteeds aan want mijn zoektocht is nog niet over. Schijnbaar kan het per postcode gebied verschillen. Dus misschien heeft iemand wat aan de info en als je aanvullende info hebt is het altijd welkom.
https://nederland-ipv6.noahlvb.nl

Solcon: https://www.solcon.nl/eig...1b7770d9c031a2d6387e5732d

Zou per gebied verschillend kunnen zijn.

[RobertMe]

Roetzen schreef op donderdag 13 maart 2025 @ 10:21:
Niet alleen is de prefix bij Delta/Caiway "persistent", het lijkt op een of andere manier aan mij persoonlijk gekoppeld. Ik ben van Caiway naar Delta overgestapt. Met het hele circus van ander XS2426G-B modem installeren en zo. Mijn abbo bij Delta is vanochtend vroeg in gegaan. En tot mijn stomme verbazing zie ik dat ik van Delta DEZELFDE IPv6 PREFIX heb gekregen als die ik eerst van Caiway had. Die prefix is zo "persistent" dat ie de overstap van Caiway naar Delta heeft overleeft. Wonderlijk!

Ben je door Delta / Caiway (administratief) gemigreerd op basis van het opheffen van de Caiway naam? Of heb je zelf een abo bij Delta afgesloten en Caiway opgezegd?
In geval van het laatste lijkt het mij nogal "bijzonder". En daar waar je bij AON nog kunt zeggen dat de prefix wellicht aan de switch poort gekoppeld is zal dat bij XGS-PON niet gaan. Immers is het abo daar aan het serienummer van de ONT gekoppeld. En gezien je die vervangen hebt.... Is het ook al niet alleen een administratieve verhuizing tussen beide naampjes

[Roetzen]

RobertMe schreef op donderdag 13 maart 2025 @ 11:12:
[...]
En daar waar je bij AON nog kunt zeggen dat de prefix wellicht aan de switch poort gekoppeld is zal dat bij XGS-PON niet gaan. Immers is het abo daar aan het serienummer van de ONT gekoppeld. En gezien je die vervangen hebt...

Toch maar eens even gekeken.

Er staan drie barcodes met bijbehorende "nummers" op de onderkanten van oude en het nieuwe modem. Het eerste en het derde (MAC en S/N) zijn verschillend. Maar het middelste (ONT P/N) is hetzelfde...

[Freeaqingme]

Ik heb me nu toch een slechte ervaring met Ziggo. Ik ben recentelijk verhuisd. In het oude huis had ik Ziggo Zakelijk Internet Pro met vast ip-adres. In het nieuwe huis had ik (tijdens de verbouwing enzo) een normaal consumentenlijntje.

Vandaag was de dag dat het Pro abbonement zou verhuizen naar het nieuwe huis en de consumentenlijn stopte met werken. Alle ip-adressen zouden hetzelfde blijven. Nou had iemand bij Ziggo een foutje gemaakt, waardoor de administratieve overgangsddatum vandaag was, maar zou iemand de routering pas de 26e omtypen. Vandaag na het nodige bellen is het dan toch vandaag nog omgetypt.

Aan de telefoon wordt mij m'n nieuwe nummer gegeven. Ik: "Die zou toch niet veranderen?". Ziggo: "Ja meneer u bent nu naar fUPC gebied gegaan, dus kan niet hetzelfde blijven. Nouja, prima.

Eerst vertelt de beste man mij m'n IPv4-adres. Vraag ik 'm naar het IPv6-adres, blijkt dat niet te kunnen in fUPC gebied. Ze doen dus wel IPv6 in fUPC gebied, maar alleen niet voor de Internet Pro klanten...

[valkenier]

Dat bevreemd mij, dat IPv6 niet zou kunnen. Bij zakelijk pro. Maar ik heb geen ervaring met fUPC.

[RobertMe]

Ik heb een "vreemd" dingetje waarbij hier iemand wellicht toe kan lichten of ik verkeerd denk of iets verkeerd doe

Ik heb al een tijd een VPS bij partij A. Hierbij krijg ik een /64 IPv6 adres. Voor zover ik kan zien heb ik hier niks speciaals voor gedaan en in de netwerk configuratie staat gewoon "gebruik adres a:b:c:d::/72". De /72 gebruik ik hierbij omdat ik Docker gebruik en (bepaalde) Docker netwerken IPv6 ingeschakeld hebben en dus een ander subnet binnen de prefix /64 gebruiken. Dat werkt allemaal prima. En de Docker containers zijn dus rechtstreeks over IPv6 te bereiken. (De "host" forward het verkeer gewoon over de bridge heen, geen NAT of whatever).

Nu ben ik aan het kijken om over te stappen naar een andere VPS provider. Ook daar krijg ik een /64. Echter, werkt hetzelfde daar niet. De boel connect niet, en een ping naar een willekeurige suffix binnen de gebruikte /72 werkt ook niet en komt geen ping voor aan. Dus als de VPS IP a:b:c:d::1 heeft kan ik die pingen. Maar a:b:c::2 zie ik niet eens in een tcpdump voorbij komen. En het is ook een ander/afwijkend IP adres dat de unreachable antwoord.

Dus op de oude VPS als ik ::2 ping dan zie ik de ICMP6 echo request voorbij komen (en gaat er uiteindelijk een unreachable antwoord terug). Op de nieuwe VPS is dat echter niet het geval. Daar komt "in de plaats" een neigbor solicit voorbij op het ::2 adres. Dus de router van de provider gaat het netwerk "scannen" / "bevragen" waar <mijn prefix>::2 zich bevindt. Waar mijn VPS natuurlijk niet op antwoord (tenzij ik het als additioneel IP toevoeg natuurlijk).

Mijn conclusie is dus dat bij de oude provider hun router weet "alle verkeer binnen prefix X::/64 moet gestuurd worden naar VPS Y". Terwijl de nieuwe provider deze informatie ontbreekt, en die in de plaats een neigbor solicit doet. En dat vind ik, nogal raar? En lijkt mij dat hetgeen dat de oude provider doet / lijkt te doen ook hetgeen is hoe het zou moeten werken? Want nu zou zelfs mijn VPS kunnen reageren op een neigbor solicit van een IP dat niet mijn "eigendom" is (/niet tot mijn VPS behoort)?!

En concreet v.w.b. mijn probleem zou ik mogelijk twee dingen kunnen doen / overwegen / proberen? Of ik ga doodleuk router advertisements uitsturen, dat bv a:b:c:c:8000::/72 te bereiken is "via mij" (of mogelijk zelfs a:b:c:d::/64 gewoon in totaliteit, dat zou leiden tot hetzelfde als dat ik zou verwachten dat de provider zelf automatisch regelt). Of, volgens mij is er software / zijn er oplossingen om neighbor solicits etc te relayen? Waarna de solicit op de "WAN" poort (/fysieke ethernet zeg maar) geforward kan worden naar de Docker bridge(s) en er (mogelijk) een container is die antwoord op die solicit en die relay software dan vast het antwoord aanpast en uit stuurt (juiste MAC? invoegt, dat van de "WAN" poort dus?). Maar beiden lijken mij gewoon niet de bedoeling? En dus lijkt mij dat dit iets is dat de provider goed moet inregelen.

"Leuke" was dus ook dat ik met een tcpdump allemaal solicits voorbij zien komen van totaal andere prefixes. "Iemand" die binnen de prefix "c0de::cafe" gebruikte bv. Lijkt mij toch allemaal niet de bedoeling? .

[Noahlvb]

Robert, jij lijkt geen namen te willen noemen. Maar nu jij deze toestand zo omschrijft denk ik dat ik bij Liteserver tegen precies het zelfde aanloop. Mocht het relevante info zijn, bij Liteserver kon ik tot op heden alleen extra IPv6 gebruiken op mijn VM nadat ik in het control panel het betreffende adres had opgegeven.

[RobertMe]

Noahlvb schreef op zondag 23 maart 2025 @ 16:13:
Robert, jij lijkt geen namen te willen noemen. Maar nu jij deze toestand zo omschrijft denk ik dat ik bij Liteserver tegen precies het zelfde aanloop. Mocht het relevante info zijn, bij Liteserver kon ik tot op heden alleen extra IPv6 gebruiken op mijn VM nadat ik in het control panel het betreffende adres had opgegeven.

Het leek mij an zich niet zo relevant om namen te benoemen. Maar momenteel zit ik bij Contabo (en daar gaat het goed), en zit te kijken bij Netcup (waar het niet goed gaat).

V.w.b. controle panel zie ik ook niks. Alleen een "tabel" waar je PTR kunt beheren. Gewoon één invoerveld voor IPv4 en een "plus knop" met dan IPv6 adres + domeinnaam voor IPv6. Staat verder geen indicatie bij dat het ook betrekking heeft op routing. Dus dat lijkt mij ook niet het geval. En als het via control panel geregeld moet worden verwacht ik nog steeds geen neigbor solicit voorbij te zien komen (incl dus neigbor solicits van IPs buiten mijn prefix (maar ik neem aan op dezelfde host / in hetzelfde rack / in hetzelfde DC).

Maar ik ben eigenlijk meer nieuwsgierig naar "hoe zou het uberhaupt moeten werken?". Gewoon dus naar de algemene werking van IPv6 en hoe je dan prefixes toekent aan systemen en de routering doet. Lijkt mij persoonlijk toch dat de enige juiste/aanbevolen manier is om in de router/... een harde koppeling te maken tussen de prefix en "het systeem". En dus gewoon alles binnen de /64 naar de VPS te sturen en die mag het uitzoeken. En dus niet met neigbor solicits gaan zitten werken, en ook niet met een statische lijst van specifieke IPs ingevoerd door de klant in een control panel.

offtopic:
Het zijn nog wel wat dingetjes die mij niet bevallen bij Netcup (leuk een 2,5Gbit/s link, en dat halen in iperf3 tests, maar iperf3 naar mij thuis of de Contabo VPS zou in beide gevallen 200Mbit/s (download in ieder geval) moeten doen. En bij de eerste de beste scp kwam die niet boven de 2,xMB/s, en iperf3 tussen thuis en Contabo komt eigenlijk niet boven de 100Mbit/s. Aangekaart bij support, die hebben VPS verplaatst, en daarna "nog een wijziging gedaan" maar zonder resultaat. Werd doorgezet naar de netwerk afdeling, en intussen 2 weken verder en geen reactie meer gehad. Dus v.w.b. dit al zowel technisch als qua support iffy (naast "geen reactie meer" ook elke keer 24 uur voordat er een reactie kwam. En dat was inclusief "mogen we systeem rebooten naar rescue systeem", binnen een uur "ja" antwoorden, en dan 24 uur later pas weer reactie). En daarnaast gaat mijn Ziggo internetverkeer vanuit Zuid Limburg naar de VPS in Netcups DC in Amsterdam ook naar een AS van Vodafone Zakelijk in Amsterdam (prima), en dan naar een Liberty Global AS in Wenen?! (WTF, Oostenrijk?!), en dan over 3 hops in Duitsland terug naar Amsterdam), ping tijd? 50ms. Ping tijd Contabo in Duitsland? 20-25 ms (neemt in Weert bij (/binnen?) Ziggo een afslag naar Duitsland, niet eens naar Amsterdam dus). Dus denk dat ik nog maar even binnen de "niet tevreden kun je binnen 30 dagen annuleren en krijg je geld terug" inzet. Performance, van goedkoopste ARM VPS, lijkt dan weer wel veel beter te zijn (/de oudere Contabo VPS, gewoon x64, is grote crap als je gaat benchmarken "NVMe SSD" is trager dan SATA en ook wat CPU benchmarks zijn in vergelijking vele malen slechter (uberhaupt, waar je ook mee vergelijkt, ook x64 bij Netcup, Hetzner, ... als je online vergelijkt)).

[Noahlvb]

Voor zover mijn kennis gaat klopt jou aanname over hoe het zou moeten werken. Je hebt twee smaken als het gaat om subnets afleveren. De eerste is gewoon een heel subnet routen naar een bepaalde machine, meestal via het link-local adres. De twee smaak (vaker toegepast bij isps) is dat je machine of router een ip uit een /64 krijgt en dat er volgens een subnet naar dat ene ip wordt gerouteerd.

Betreft namen noemen, bedoel ik niet om te blamen. Maar meer voor de vindbaarheid in de zoekmachine en Google mochten mensen vergelijkbare problemen hebben en zoeken naar een oplossen.

[Charlie_Root]

RobertMe schreef op zondag 23 maart 2025 @ 13:39:
Ik heb een "vreemd" dingetje waarbij hier iemand wellicht toe kan lichten of ik verkeerd denk of iets verkeerd doe

Ik heb al een tijd een VPS bij partij A. Hierbij krijg ik een /64 IPv6 adres. Voor zover ik kan zien heb ik hier niks speciaals voor gedaan en in de netwerk configuratie staat gewoon "gebruik adres a:b:c:d::/72". De /72 gebruik ik hierbij omdat ik Docker gebruik en (bepaalde) Docker netwerken IPv6 ingeschakeld hebben en dus een ander subnet binnen de prefix /64 gebruiken. Dat werkt allemaal prima. En de Docker containers zijn dus rechtstreeks over IPv6 te bereiken. (De "host" forward het verkeer gewoon over de bridge heen, geen NAT of whatever).

Nu ben ik aan het kijken om over te stappen naar een andere VPS provider. Ook daar krijg ik een /64. Echter, werkt hetzelfde daar niet. De boel connect niet, en een ping naar een willekeurige suffix binnen de gebruikte /72 werkt ook niet en komt geen ping voor aan. Dus als de VPS IP a:b:c:d::1 heeft kan ik die pingen. Maar a:b:c::2 zie ik niet eens in een tcpdump voorbij komen. En het is ook een ander/afwijkend IP adres dat de unreachable antwoord.

Dus op de oude VPS als ik ::2 ping dan zie ik de ICMP6 echo request voorbij komen (en gaat er uiteindelijk een unreachable antwoord terug). Op de nieuwe VPS is dat echter niet het geval. Daar komt "in de plaats" een neigbor solicit voorbij op het ::2 adres. Dus de router van de provider gaat het netwerk "scannen" / "bevragen" waar <mijn prefix>::2 zich bevindt. Waar mijn VPS natuurlijk niet op antwoord (tenzij ik het als additioneel IP toevoeg natuurlijk).

Mijn conclusie is dus dat bij de oude provider hun router weet "alle verkeer binnen prefix X::/64 moet gestuurd worden naar VPS Y". Terwijl de nieuwe provider deze informatie ontbreekt, en die in de plaats een neigbor solicit doet. En dat vind ik, nogal raar? En lijkt mij dat hetgeen dat de oude provider doet / lijkt te doen ook hetgeen is hoe het zou moeten werken? Want nu zou zelfs mijn VPS kunnen reageren op een neigbor solicit van een IP dat niet mijn "eigendom" is (/niet tot mijn VPS behoort)?!

En concreet v.w.b. mijn probleem zou ik mogelijk twee dingen kunnen doen / overwegen / proberen? Of ik ga doodleuk router advertisements uitsturen, dat bv a:b:c:c:8000::/72 te bereiken is "via mij" (of mogelijk zelfs a:b:c:d::/64 gewoon in totaliteit, dat zou leiden tot hetzelfde als dat ik zou verwachten dat de provider zelf automatisch regelt). Of, volgens mij is er software / zijn er oplossingen om neighbor solicits etc te relayen? Waarna de solicit op de "WAN" poort (/fysieke ethernet zeg maar) geforward kan worden naar de Docker bridge(s) en er (mogelijk) een container is die antwoord op die solicit en die relay software dan vast het antwoord aanpast en uit stuurt (juiste MAC? invoegt, dat van de "WAN" poort dus?). Maar beiden lijken mij gewoon niet de bedoeling? En dus lijkt mij dat dit iets is dat de provider goed moet inregelen.

"Leuke" was dus ook dat ik met een tcpdump allemaal solicits voorbij zien komen van totaal andere prefixes. "Iemand" die binnen de prefix "c0de::cafe" gebruikte bv. Lijkt mij toch allemaal niet de bedoeling? .

Welke versie van Docker gebruik je? Kun je eens kijken of deze waarde is ingeschakeld (sysctl):

code:

net.bridge.bridge-nf-call-ip6tables

Heb je verder een firewall actief op de nieuwe VM?

code:

ip6tables -L

En wat heb je ingesteld in

code:

/etc/docker/daemon.json

[RobertMe]

Charlie_Root schreef op maandag 24 maart 2025 @ 05:33:
[...]


Welke versie van Docker gebruik je?

"Docker version 28.0.2, build 0442a73".

Kun je eens kijken of deze waarde is ingeschakeld (sysctl):

code:

net.bridge.bridge-nf-call-ip6tables

sudo sysctl net.bridge.bridge-nf-call-ip6tables
sysctl: cannot stat /proc/sys/net/bridge/bridge-nf-call-ip6tables: No such file or directory

Heb je verder een firewall actief op de nieuwe VM?

code:

ip6tables -L

Ja. nftables. Maar ik heb ook tijdelijk alles op "accept" gehad, en dat maakte geen verschil.

En wat heb je ingesteld in

code:

/etc/docker/daemon.json

JSON:

{
    "iptables": false,
    "ip6tables": false,
    "ipv6": true,
    "fixed-cidr-v6": "<knip>:0100::/72"
}

Maar die kernel setting is an zich wel interessant, op basis van het lezen van de naam (behalve dan "ip6tables" ). Alleen gek dat die niet bestaat? En voordat je vraagt: "Linux <knip> 6.1.0-32-arm64 #1 SMP Debian 6.1.129-1 (2025-03-06) aarch64 GNU/Linux" Debian, Bookworm, dus.

[Snow_King]

RobertMe schreef op zondag 23 maart 2025 @ 13:39:
Ik heb een "vreemd" dingetje waarbij hier iemand wellicht toe kan lichten of ik verkeerd denk of iets verkeerd doe

Ik heb al een tijd een VPS bij partij A. Hierbij krijg ik een /64 IPv6 adres. Voor zover ik kan zien heb ik hier niks speciaals voor gedaan en in de netwerk configuratie staat gewoon "gebruik adres a:b:c:d::/72". De /72 gebruik ik hierbij omdat ik Docker gebruik en (bepaalde) Docker netwerken IPv6 ingeschakeld hebben en dus een ander subnet binnen de prefix /64 gebruiken. Dat werkt allemaal prima. En de Docker containers zijn dus rechtstreeks over IPv6 te bereiken. (De "host" forward het verkeer gewoon over de bridge heen, geen NAT of whatever).

Nu ben ik aan het kijken om over te stappen naar een andere VPS provider. Ook daar krijg ik een /64. Echter, werkt hetzelfde daar niet. De boel connect niet, en een ping naar een willekeurige suffix binnen de gebruikte /72 werkt ook niet en komt geen ping voor aan. Dus als de VPS IP a:b:c:d::1 heeft kan ik die pingen. Maar a:b:c::2 zie ik niet eens in een tcpdump voorbij komen. En het is ook een ander/afwijkend IP adres dat de unreachable antwoord.

Dus op de oude VPS als ik ::2 ping dan zie ik de ICMP6 echo request voorbij komen (en gaat er uiteindelijk een unreachable antwoord terug). Op de nieuwe VPS is dat echter niet het geval. Daar komt "in de plaats" een neigbor solicit voorbij op het ::2 adres. Dus de router van de provider gaat het netwerk "scannen" / "bevragen" waar <mijn prefix>::2 zich bevindt. Waar mijn VPS natuurlijk niet op antwoord (tenzij ik het als additioneel IP toevoeg natuurlijk).

Mijn conclusie is dus dat bij de oude provider hun router weet "alle verkeer binnen prefix X::/64 moet gestuurd worden naar VPS Y". Terwijl de nieuwe provider deze informatie ontbreekt, en die in de plaats een neigbor solicit doet. En dat vind ik, nogal raar? En lijkt mij dat hetgeen dat de oude provider doet / lijkt te doen ook hetgeen is hoe het zou moeten werken? Want nu zou zelfs mijn VPS kunnen reageren op een neigbor solicit van een IP dat niet mijn "eigendom" is (/niet tot mijn VPS behoort)?!

En concreet v.w.b. mijn probleem zou ik mogelijk twee dingen kunnen doen / overwegen / proberen? Of ik ga doodleuk router advertisements uitsturen, dat bv a:b:c:c:8000::/72 te bereiken is "via mij" (of mogelijk zelfs a:b:c:d::/64 gewoon in totaliteit, dat zou leiden tot hetzelfde als dat ik zou verwachten dat de provider zelf automatisch regelt). Of, volgens mij is er software / zijn er oplossingen om neighbor solicits etc te relayen? Waarna de solicit op de "WAN" poort (/fysieke ethernet zeg maar) geforward kan worden naar de Docker bridge(s) en er (mogelijk) een container is die antwoord op die solicit en die relay software dan vast het antwoord aanpast en uit stuurt (juiste MAC? invoegt, dat van de "WAN" poort dus?). Maar beiden lijken mij gewoon niet de bedoeling? En dus lijkt mij dat dit iets is dat de provider goed moet inregelen.

"Leuke" was dus ook dat ik met een tcpdump allemaal solicits voorbij zien komen van totaal andere prefixes. "Iemand" die binnen de prefix "c0de::cafe" gebruikte bv. Lijkt mij toch allemaal niet de bedoeling? .

Niet elke provider routeert een subnet naar jouw VM toe. Dat je oude provider dit wel doet is tof, maar het is zeker niet de standaard.

Bij je nieuwe provider is het LAN een /64 en via een RA (vermoed ik) krijg je VM een adres in die /64. Deze /64 deel je met alle andere VPS'en in het zelfde VLAN/L2-segment. Uiteindelijk heeft je VPS maar een /128 (een enkel adres).

Je zal dus aan de provider moeten vragen OF ze een subnet naar je VM kunnen routeren, maar dat betwijfel ik eigenlijk.

Bij een partij als Vultr kan je zelfs BGP met hun netwerk praten, maar dan moet je wel eigen IPv6 space hebben. Denk aan een IPv6 PI /48 blok.

[bart.koppers]

RobertMe schreef op zondag 23 maart 2025 @ 16:39:
[...]

Het leek mij an zich niet zo relevant om namen te benoemen. Maar momenteel zit ik bij Contabo (en daar gaat het goed), en zit te kijken bij Netcup (waar het niet goed gaat).

V.w.b. controle panel zie ik ook niks. Alleen een "tabel" waar je PTR kunt beheren. Gewoon één invoerveld voor IPv4 en een "plus knop" met dan IPv6 adres + domeinnaam voor IPv6. Staat verder geen indicatie bij dat het ook betrekking heeft op routing. Dus dat lijkt mij ook niet het geval. En als het via control panel geregeld moet worden verwacht ik nog steeds geen neigbor solicit voorbij te zien komen (incl dus neigbor solicits van IPs buiten mijn prefix (maar ik neem aan op dezelfde host / in hetzelfde rack / in hetzelfde DC).

Maar ik ben eigenlijk meer nieuwsgierig naar "hoe zou het uberhaupt moeten werken?". Gewoon dus naar de algemene werking van IPv6 en hoe je dan prefixes toekent aan systemen en de routering doet. Lijkt mij persoonlijk toch dat de enige juiste/aanbevolen manier is om in de router/... een harde koppeling te maken tussen de prefix en "het systeem". En dus gewoon alles binnen de /64 naar de VPS te sturen en die mag het uitzoeken. En dus niet met neigbor solicits gaan zitten werken, en ook niet met een statische lijst van specifieke IPs ingevoerd door de klant in een control panel.

offtopic:
Het zijn nog wel wat dingetjes die mij niet bevallen bij Netcup (leuk een 2,5Gbit/s link, en dat halen in iperf3 tests, maar iperf3 naar mij thuis of de Contabo VPS zou in beide gevallen 200Mbit/s (download in ieder geval) moeten doen. En bij de eerste de beste scp kwam die niet boven de 2,xMB/s, en iperf3 tussen thuis en Contabo komt eigenlijk niet boven de 100Mbit/s. Aangekaart bij support, die hebben VPS verplaatst, en daarna "nog een wijziging gedaan" maar zonder resultaat. Werd doorgezet naar de netwerk afdeling, en intussen 2 weken verder en geen reactie meer gehad. Dus v.w.b. dit al zowel technisch als qua support iffy (naast "geen reactie meer" ook elke keer 24 uur voordat er een reactie kwam. En dat was inclusief "mogen we systeem rebooten naar rescue systeem", binnen een uur "ja" antwoorden, en dan 24 uur later pas weer reactie). En daarnaast gaat mijn Ziggo internetverkeer vanuit Zuid Limburg naar de VPS in Netcups DC in Amsterdam ook naar een AS van Vodafone Zakelijk in Amsterdam (prima), en dan naar een Liberty Global AS in Wenen?! (WTF, Oostenrijk?!), en dan over 3 hops in Duitsland terug naar Amsterdam), ping tijd? 50ms. Ping tijd Contabo in Duitsland? 20-25 ms (neemt in Weert bij (/binnen?) Ziggo een afslag naar Duitsland, niet eens naar Amsterdam dus). Dus denk dat ik nog maar even binnen de "niet tevreden kun je binnen 30 dagen annuleren en krijg je geld terug" inzet. Performance, van goedkoopste ARM VPS, lijkt dan weer wel veel beter te zijn (/de oudere Contabo VPS, gewoon x64, is grote crap als je gaat benchmarken "NVMe SSD" is trager dan SATA en ook wat CPU benchmarks zijn in vergelijking vele malen slechter (uberhaupt, waar je ook mee vergelijkt, ook x64 bij Netcup, Hetzner, ... als je online vergelijkt)).

Zoals al uitgelegd (of geprobeerd..) in het vps-topic, pakt deze hoster het wat anders aan.

Ik gebruik ook Liteserver net als @Noahlvb, en de oplossing was om een bridge (br0) op te zetten icm ndp. Daarmee zijn de IPs binnen subnet bereikbaar, overigens zonder dat ik deze moet opgeven in hun controlpanel.

[Snow_King]

bart.koppers schreef op maandag 24 maart 2025 @ 14:06:
[...]


Zoals al uitgelegd (of geprobeerd..) in het vps-topic, pakt deze hoster het wat anders aan.

Ik gebruik ook Liteserver net als @Noahlvb, en de oplossing was om een bridge (br0) op te zetten icm ndp. Daarmee zijn de IPs binnen subnet bereikbaar, overigens zonder dat ik deze moet opgeven in hun controlpanel.

Dat laatste is wel raar, want je neem dan dus gewoon "een adres" aan. Lijkt er dus op dat de hoster geen source filtering doet en je dus gewoon toe staat elk random adres te pakken.

Dat is een leuke om even voor paar minuten een adres te pakken, wat sneakys te doen en vervolgens adres te droppen.

[RobertMe]

Snow_King schreef op maandag 24 maart 2025 @ 13:58:
Bij je nieuwe provider is het LAN een /64 en via een RA (vermoed ik) krijg je VM een adres in die /64. Deze /64 deel je met alle andere VPS'en in het zelfde VLAN/L2-segment. Uiteindelijk heeft je VPS maar een /128 (een enkel adres).

Ik krijg wel een /64, deze staat ook gewoon in het control panel en kan ik prima zelf instellen in het OS (ook zelf geïnstalleerd en geconfigureerd, niet een pre-install) met dan een willekeurige suffix (en ik kan ook gewoon meerdere IPs op dezelfde interface zetten en die zijn dan ook allemaal bereikbaar). En in het control panel kan ik ook zelf specifieke IPs invoeren om de bijbehorende domeinnaam op te geven (voor reverse DNS dan). Meerdere IPs is het probleem dus niet. Het subnet is "van mij" en kan ik prima zelf uit kiezen.
Maar verkeer wordt vanuit hun gerouteerd naar de VPS op basis van neighbor solicit, i.p.v. van een statische routing ("alles naar IP a:b:c:d::/64 afleveren bij <(link local) address>" (/op interface X op het host systeem wat dan "virtueel" gekoppeld is aan de interface in de VPS)).

[Snow_King]

RobertMe schreef op maandag 24 maart 2025 @ 14:20:
[...]

Ik krijg wel een /64, deze staat ook gewoon in het control panel en kan ik prima zelf instellen in het OS (ook zelf geïnstalleerd en geconfigureerd, niet een pre-install) met dan een willekeurige suffix (en ik kan ook gewoon meerdere IPs op dezelfde interface zetten en die zijn dan ook allemaal bereikbaar). En in het control panel kan ik ook zelf specifieke IPs invoeren om de bijbehorende domeinnaam op te geven (voor reverse DNS dan). Meerdere IPs is het probleem dus niet. Het subnet is "van mij" en kan ik prima zelf uit kiezen.
Maar verkeer wordt vanuit hun gerouteerd naar de VPS op basis van neighbor solicit, i.p.v. van een statische routing ("alles naar IP a:b:c:d::/64 afleveren bij <(link local) address>" (/op interface X op het host systeem wat dan "virtueel" gekoppeld is aan de interface in de VPS)).

Ja, maar toch lijk je dit subnet te delen met andere gebruikers. Wat is je IPv4 prefix? Want beiden deel je lijkt het.

In die zelfde IPv6 /64 zitten denk ik ook gewoon andere gebruikers. Ook hier lijken ze geen source filtering toe te passen en mag je gewoon pakken wat je wil. Je zal denk ik ook het adres van een buurman kunnen overnemen.

Ze routeren gewoon geen subnet naar jouw VPS waar jij dus de "next-hop" bent voor een bepaald subnet.

[RobertMe]

Snow_King schreef op maandag 24 maart 2025 @ 14:45:
[...]

Ja, maar toch lijk je dit subnet te delen met andere gebruikers. Wat is je IPv4 prefix? Want beiden deel je lijkt het.

Dit is wat ik in in het control panel onder "Network" zie:

Het verborgen IPv4 stukje is dus een specifiek nummer (geen .0 of zo). En dit is ook het IP adres dat ik als static IP heb opgegeven in het OS.
Het verborgen IPv6 stukje is dan ook een "blokje" (tussen twee : in dus), waarmee dus de eerste 64 bits de prefix zijn en 64 bits zelf te kiezen. Waarbij ik de ::1 als static IP heb ingesteld.

In die zelfde IPv6 /64 zitten denk ik ook gewoon andere gebruikers. Ook hier lijken ze geen source filtering toe te passen en mag je gewoon pakken wat je wil. Je zal denk ik ook het adres van een buurman kunnen overnemen.

Nee. Ik heb nu een tcpdump op de "fysieke" interface gedaan, en krijg echt een shitload aan neighbor solicits te zien. Echter zijn die allemaal voor andere prefixes. Dus wel "2a0a:4cc0:40:" maar dan gevolgd door een ander "blokje" en niet dat wat bij mij in de interface staat.
Vervolgens dus wel "ja", ze doen geen source filtering, I guess. Zeker gezien een tcpdump doen op mijn Contabo VPS gewoon helemaal niks oplevert.

Ze routeren gewoon geen subnet naar jouw VPS waar jij dus de "next-hop" bent voor een bepaald subnet.

Zover was duidelijk . Maar de reden daarvan is dus niet "want je hebt helemaal geen eigen subnet" (voor zover ik kan zien).

Edit:
Stukje Netcup documentatie v.w.b. "additioneel IP adres": https://helpcenter.netcup.com/en/wiki/server/ip

Execute the following command:

nano /etc/network/interfaces

Add the following line:

iface eth0 inet6 static address 2a03:4000:2:11c5::1 netmask 64 gateway fe80::1

Please replace "2a03:4000:2:11c5::1" with the desired IPv6 address from the assigned /64 subnet.

Hierin zijn ze dus ook niet echt duidelijk in dat je een willekeurige suffix zou moeten gebruiken omdat je binnen een gedeeld subnet zit, zoals jij suggereert. En daarnaast dus ook niet "je moet SLAAC gebruiken" om gegarandeerd een uniek adres te hebben.
And last but not least, spreken ze ook (duidelijk) over dat je een IPv4 adres of IPv6 subnet koopt. En dus geen IPv6 adres.

[ Voor 18% gewijzigd door RobertMe op 24-03-2025 16:24 ]

[bart.koppers]

@RobertMe, je hebt het vlgs mij aan de praat!

[RobertMe]

Even als losse post, want "antwoord op mijn eigen vraag / probleem / ..."

De oplossing is dus..., en dat is wat @bart.koppers wellicht ook bedoelde?, het gebruik van de Linux ingebakken NDP proxy (of het gebruik van een losse / user space NDP proxy die flexibeler etc etc is).

Met deze twee simpele dingen "werkt het":

echo 1 | sudo tee /proc/sys/net/ipv6/conf/all/proxy_ndp
sudo ip -6 neigh add proxy <knip>:8000::443 dev wan

Als nu op interface "wan" (i.p.v. eth0 / en... heb ik de link naar "wan" hernoemd) een NDP solicit langs komt voor <prefix>:8000::443 dan antwoord de Linux kernel daar op, dat het verkeer "naar hem" moet komen (/MAC adres van de wan interface dus). Vervolgens wordt het verkeer dus bij hem afgeleverd "zoals ik verwacht". Ik weet alleen niet of ik dat nu... heel logisch vind.

Daarnaast had ik ook even deze tool geprobeerd: https://github.com/DanielAdolfsson/ndppd/tree/0.2.5 (zit ook in Debian) en die werkt dus ook, en is wat flexibeler in dat die hele subnets ondersteund. Een gestripte werkende config hierbij is:

code:

route-ttl 30000

proxy wan {
   router yes
   timeout 500
   ttl 30000
   rule <prefix>:8000::/72 {
      iface br-web
   }
}

For some reason werkte de auto optie in het rule blok niet. Maar met een statische iface werkt die dus wel. De genoemde iface is de naam van de bridge die docker heeft aangemaakt en een container in hangt met dus :8000::443 als static IP.

Note: in werkelijkheid heb ik hier en daar wat met IPs zitten te wijzigen tussen het gebruik van de kernel feature en ndppd. Dit om dus te "forceren" dat het een ander IP is en de Netcup router niet de route / neighbor onthouden heeft en er daadwerkelijk ook weer een nieuwe solicit vanaf de Netcup router binnen komt, waar de kernel proxy / user-space ndppd op reageert.

Maar, dit voelt dus best wel, vies. Want ik kan dus net zo goed of de kernel feature of de user space variant gewoon op willekeurige IPs laten antwoorden. En zoals aangegeven, ik zie dus een hele shitload aan 2a0a:4cc0:40:X:: adressen voorbij komen, met dus vele verschillende "X"en wat dus allemaal andere VPSen zullen zijn.
Daarnaast zat ik nog even te kijken naar de "afzender" van de solicits. Veel leek van een IP (link local) afkomstig te zijn, maar niet alles. Maar met een snelle scan lijken het 3 verschillende link local adressen te zijn. Hopelijk dat dit dus 3 (failover) routers van Netcup zijn. En niet "buurman VPSen" die ook leuk zitten te scannen of zo (en ja, ik lijk ook iets van een IP scan "op te vangen").

[RobertMe]

bart.koppers schreef op maandag 24 maart 2025 @ 17:27:
@RobertMe, je hebt het vlgs mij aan de praat!

Je hebt voorspellende gave? Want toen jij postte had ik wel het wel aan de praat maar was ik nog aan bovenstaande bericht bezig. Bij mijn post daarvoor had ik het zeer zeker nog niet aan de praat.

[bart.koppers]

RobertMe schreef op maandag 24 maart 2025 @ 17:31:
[...]

Je hebt voorspellende gave? Want toen jij postte had ik wel het wel aan de praat maar was ik nog aan bovenstaande bericht bezig. Bij mijn post daarvoor had ik het zeer zeker nog niet aan de praat.

Nee, meer dat ik je (denk)stappen in de post zag / herkende en wist dat je op goede weg zat

Je hoeft natuurlijk niet deze dynamische route te volgen - je kan bv ook alle /128 adressen die je gaat gebruiken toevoegen. Maar minder luie optie.

Overigens zie ik dat je bij deze hoster een /22 subnet krijgt (koopt?) voor IPv4. Best mooi.
En dat je in de webtool ook zelf te routeren (want gateway in te stellen) IPv6 adressen kan instellen.
Vrij flexibel!
Heb je deze laatste optie wel geprobeerd?

[RobertMe]

bart.koppers schreef op maandag 24 maart 2025 @ 18:31:
Je hoeft natuurlijk niet deze dynamische route te volgen - je kan bv ook alle /128 adressen die je gaat gebruiken toevoegen. Maar minder luie optie.

Het blijft in beide gevallen IMO nogal shitty. Zelfs de "je moet het in control panel van de provider instellen" route zoals Liteserver blijkbaar heeft vind ik beter te begrijpen/volgen dan "dit".

Overigens zie ik dat je bij deze hoster een /22 subnet krijgt (koopt?) voor IPv4.

Is inderdaad gewoon 1 IP adres . /22 is het subnet waarin die zit, gedeeld met andere VPSen. Daarom ook dat ik aangaf dat het gemaskeerde een specifiek adres was, en niet .0 of zo. Daar waar bij IPv6 die wel eindigt op ::/64 en dus daadwerkelijk een "leeg" stuk.

En dat je in de webtool ook zelf te routeren (want gateway in te stellen) IPv6 adressen kan instellen.
Vrij flexibel!
Heb je deze laatste optie wel geprobeerd?

Het is niet "gateway in te stellen", het is rDNS, alleen dan zonder enige labeling bij IPv6 (bij IPv4 staat het wel in een "rDNS" kolom). Beetje slechte user interface dus, je moet het nu maar "raden" op basis van de "your.host.name" dus (gecombineerd met "rDNS" vermeld bij IPv4 dus). Met hun crappy gesplitste admin / control panels. In het "customer control center" (op een totaal eigen domein...) heet het wel gewoon "rDNS" zag ik net. Daar is een heel tabje met de naam "rDNS" met alleen de rDNS regels voor het IPv4 adres en zelf op te voegen IPv6 adressen (met dus dezelfde info als in het "server control panel".

En gezien ik nogal aan het crossposten was. Verdere discussie over Netcup an zich kan dus bij RobertMe in "[VPS] Opzetten en onderhouden" . Waar ook staat dat ik de VPS net heb geannuleerd (en ook al niet meer toegankelijk is).

[bart.koppers]

Snow_King schreef op maandag 24 maart 2025 @ 14:17:
[...]

Dat laatste is wel raar, want je neem dan dus gewoon "een adres" aan. Lijkt er dus op dat de hoster geen source filtering doet en je dus gewoon toe staat elk random adres te pakken.

Dat is een leuke om even voor paar minuten een adres te pakken, wat sneakys te doen en vervolgens adres te droppen.

Dat lukt vlgs mij niet - alleen bij adressen uit het eigen (/48) subnet.

[RobertMe]

bart.koppers schreef op maandag 24 maart 2025 @ 19:12:
[...]


Dat lukt vlgs mij niet - alleen bij adressen uit het eigen (/48) subnet.

Als Netcup het verkeer gewoon stuurt naar degene die met het IP adres adverteert zal dat wel lukken. En gezien Netcup het broadcast verkeer niet filtert (wat moet mijn VPS met NDP solicits voor andere prefixes?) is er ook geen enkele indicatie dat het "normale" (unicast) verkeer wel correct gefilterd wordt.

[Snow_King]

RobertMe schreef op maandag 24 maart 2025 @ 16:21:
[...]

Dit is wat ik in in het control panel onder "Network" zie:
[Afbeelding]
Het verborgen IPv4 stukje is dus een specifiek nummer (geen .0 of zo). En dit is ook het IP adres dat ik als static IP heb opgegeven in het OS.
Het verborgen IPv6 stukje is dan ook een "blokje" (tussen twee : in dus), waarmee dus de eerste 64 bits de prefix zijn en 64 bits zelf te kiezen. Waarbij ik de ::1 als static IP heb ingesteld.


[...]

Nee. Ik heb nu een tcpdump op de "fysieke" interface gedaan, en krijg echt een shitload aan neighbor solicits te zien. Echter zijn die allemaal voor andere prefixes. Dus wel "2a0a:4cc0:40:" maar dan gevolgd door een ander "blokje" en niet dat wat bij mij in de interface staat.
Vervolgens dus wel "ja", ze doen geen source filtering, I guess. Zeker gezien een tcpdump doen op mijn Contabo VPS gewoon helemaal niks oplevert.


[...]

Zover was duidelijk . Maar de reden daarvan is dus niet "want je hebt helemaal geen eigen subnet" (voor zover ik kan zien).

Edit:
Stukje Netcup documentatie v.w.b. "additioneel IP adres": https://helpcenter.netcup.com/en/wiki/server/ip

[...]

Hierin zijn ze dus ook niet echt duidelijk in dat je een willekeurige suffix zou moeten gebruiken omdat je binnen een gedeeld subnet zit, zoals jij suggereert. En daarnaast dus ook niet "je moet SLAAC gebruiken" om gegarandeerd een uniek adres te hebben.
And last but not least, spreken ze ook (duidelijk) over dat je een IPv4 adres of IPv6 subnet koopt. En dus geen IPv6 adres.

Je zit wel in het zelfde VLAN/L2 segment als alle andere VM's, te zien aan het feit dat je een in een /22 IPv4 zit.

Nu vermoed ik dat deze partij dan heel veel /64 subnets configureerd op hun routers, voor elke VM 1. Geen idee hoe ze dat precies aanpakken, maar het kan prima. Ze hebben dan fe80::1 als gateway adres staan.

Wellicht doen ze iets aan filteren zodat je dus de gehele /64 op jouw VM mag configureren, maar ze routeren hem niet naar je zoals je zelf al merkte. Je moet inderdaad met die proxy gaan werken.

[RobertMe]

Snow_King schreef op maandag 24 maart 2025 @ 20:18:
[...]

Je zit wel in het zelfde VLAN/L2 segment als alle andere VM's, te zien aan het feit dat je een in een /22 IPv4 zit.

Maar dat moet (bij v4) toch sowieso? Want er is maar 1 IP adres, en het is wel handig als de default gateway in hetzelfde segment zit En bij Contabo is IPv4 zelfs met een /21, nog groter segment dus.

Nu vermoed ik dat deze partij dan heel veel /64 subnets configureerd op hun routers, voor elke VM 1. Geen idee hoe ze dat precies aanpakken, maar het kan prima. Ze hebben dan fe80::1 als gateway adres staan.

Deze partij als in Netcup? Ze zouden natuurlijk ook qua binnenkomend "groter" kunnen werken, met een /56 of /48 (per DC of wat ook dan, want zo'n subnet over DCs heen zal wel lastig gaan Tenzij een deel weer over het internet naar een ander DC sturen). En intern lijken ze met die /64 dus weinig te doen. Of in ieder geval routeren ze de /64 subnets dus niet naar een VM .
Bij Contabo lijken ze die /64 dan wel te gebruiken, en routeren ze het direct naar de "juiste" VPS (van de klant waarbij ze hebben aangegeven dat die /64 van hem is). En ook daar is de gateway fe80::1 (vast een standaard dus).

Wellicht doen ze iets aan filteren zodat je dus de gehele /64 op jouw VM mag configureren

Ik heb er eigenlijk sterk mijn twijfels bij. Maar gezien de VPS al is opgezegd kan ik het niet proberen, en ik weet ook niet of het echt slim is om te proberen (alhoewel je vast "per ongeluk" een typo kunt maken als je het static address instelt ).

[ed1703]

RobertMe schreef op maandag 24 maart 2025 @ 20:34:
[...]

Maar dat moet (bij v4) toch sowieso? Want er is maar 1 IP adres, en het is wel handig als de default gateway in hetzelfde segment zit En bij Contabo is IPv4 zelfs met een /21, nog groter segment dus.

Ik zit zelf bij Transip, een CIDR van niet groter dan een /23 vind ik wel best practice voor end-nodes.

Deze partij als in Netcup? Ze zouden natuurlijk ook qua binnenkomend "groter" kunnen werken, met een /56 of /48 (per DC of wat ook dan, want zo'n subnet over DCs heen zal wel lastig gaan Tenzij een deel weer over het internet naar een ander DC sturen).

Je kan prima met bridge-groups je verschillende vlan's over DC's heen trekken, doen wij zelf ook.
Ik ben er echter niet zo'n fan van, al is het alleen al omdat ik het vooral richting access wel vervelend vind.
Ik hou van duidelijk gelijk zien waar een node uithangt.

[jefjef]

Ik heb dus een een fritzbox 7590 (en een glasvezelverbinding KPN) en kijkende hierin zag ik dat bij toegangsgegevens als standaard Ipv4 is aangevinkt. kijkende op IP6.nl blijkt dat mijn verbinding wel een Ipv6 is. Nu is het zo dat ik juist op mijn iphone, de rest van de fam heeft een samsung, sommige paginas langzaam laden of helemaal niet. Terwijl de samsung bezitters dit niet hebben. Wanneer ik de fritzbox op ipv4 laat staan zal dat de verbindingen verbeteren? En wanneer ik ipv6 selecteer heb ik keuze uit een aantal mogelijkheden: Native Ipv6 gebruiken enwel of niet aanvinken: Ipv4 verbinding tot stand brengen via DS-Lite met daaronder weer een aantal mogelijkheden: AFTR adres automatisch bepalen via DHCPv6 of AFTR adres opgeven → Ipv6…..(adres invullen) of → FQDN….(adres invullen)

Of selecteren: Alleen Ipv6 gebruiken.

Of selecteren: IPv6 met tunnelingprotocol gebruiken.

Help wat moet ik kiezen?

[ReBr]

Volgens mij gebruiken die Samsung bezitters de Google DNS servers, en jouw iphone de DNS servers, welke via je Fritz worden aangeboden (die van KPN, welke momenteel bij enkele gebruikers niet echt vlot werken)

Instellingen selecteren:

Native IPv6-verbinding gebruiken

Globaal adres afleiden uit het toegewezen prefix

DHCPv6 rapid-commit gebruiken

Overige opties niet aanvinken, bovenstaande is voldoende.

Ook kan je bij DNS-Server kiezen voor een andere DNS-V4, en DNS-V6 server. Dit kan ik je wel aanraden.
Hierna heb je een perfect werkende verbinding.

jefjef schreef op zondag 20 april 2025 @ 10:48:
Ik heb dus een een fritzbox 7590 (en een glasvezelverbinding KPN) en kijkende hierin zag ik dat bij toegangsgegevens als standaard Ipv4 is aangevinkt. kijkende op IP6.nl blijkt dat mijn verbinding wel een Ipv6 is. Nu is het zo dat ik juist op mijn iphone, de rest van de fam heeft een samsung, sommige paginas langzaam laden of helemaal niet. Terwijl de samsung bezitters dit niet hebben. Wanneer ik de fritzbox op ipv4 laat staan zal dat de verbindingen verbeteren? En wanneer ik ipv6 selecteer heb ik keuze uit een aantal mogelijkheden: Native Ipv6 gebruiken enwel of niet aanvinken: Ipv4 verbinding tot stand brengen via DS-Lite met daaronder weer een aantal mogelijkheden: AFTR adres automatisch bepalen via DHCPv6 of AFTR adres opgeven → Ipv6…..(adres invullen) of → FQDN….(adres invullen)

Of selecteren: Alleen Ipv6 gebruiken.

Of selecteren: IPv6 met tunnelingprotocol gebruiken.

Help wat moet ik kiezen?

[jefjef]

ReBr schreef op zondag 20 april 2025 @ 13:19:
Volgens mij gebruiken die Samsung bezitters de Google DNS servers, en jouw iphone de DNS servers, welke via je Fritz worden aangeboden (die van KPN, welke momenteel bij enkele gebruikers niet echt vlot werken)

Instellingen selecteren:

Native IPv6-verbinding gebruiken

Globaal adres afleiden uit het toegewezen prefix

DHCPv6 rapid-commit gebruiken

Overige opties niet aanvinken, bovenstaande is voldoende.

Ook kan je bij DNS-Server kiezen voor een andere DNS-V4, en DNS-V6 server. Dit kan ik je wel aanraden.
Hierna heb je een perfect werkende verbinding.


[...]

Dank! Ga het instellen en uitproberen

[CloudPrutser]

Lieve mensen,

Ik heb een vraag waarvan ik besef dat het niveau wel echt heel laag is, maar toch heb ik een antwoord nodig. Ik ben programmeur en geen professioneel netwerkbeheerder.

Wat ik graag zou willen bereiken: al het IPv6-netwerkverkeer ontvangen op een VPS, en het verkeer doorsturen naar mijn IPv4 consumentenrouter zodat ik gewoon de huidige port-forwarding config kan blijven gebruiken.

Iemand hier al tegenaan gelopen?

ChatGPT begint over dingen zoals socat, reverse SSH-tunnel, TCP-proxy met HAproxy en kernel-level DNAT met nftables.

Wat zouden jullie adviseren? Het lijkt alsof HAProxy het meest gangbaar is hier.

[ Voor 19% gewijzigd door CloudPrutser op 06-05-2025 11:44 ]

[Tom Paris]

CloudPrutser schreef op dinsdag 6 mei 2025 @ 11:37:
Wat ik graag zou willen bereiken: al het IPv6-netwerkverkeer ontvangen op een VPS, en het verkeer doorsturen naar mijn IPv4 consumentenrouter zodat ik gewoon de huidige port-forwarding config kan blijven gebruiken.

Welk probleem wil je precies oplossen? Heb je een provider zonder IPv6 (Odido), of heb je CG-NAT? Maakt het makkelijker een oplossing te verzinnen...

[bart.koppers]

CloudPrutser schreef op dinsdag 6 mei 2025 @ 11:37:
Lieve mensen,

Ik heb een vraag waarvan ik besef dat het niveau wel echt heel laag is, maar toch heb ik een antwoord nodig. Ik ben programmeur en geen professioneel netwerkbeheerder.

Wat ik graag zou willen bereiken: al het IPv6-netwerkverkeer ontvangen op een VPS, en het verkeer doorsturen naar mijn IPv4 consumentenrouter zodat ik gewoon de huidige port-forwarding config kan blijven gebruiken.

Iemand hier al tegenaan gelopen?

ChatGPT begint over dingen zoals socat, reverse SSH-tunnel, TCP-proxy met HAproxy en kernel-level DNAT met nftables.

Wat zouden jullie adviseren? Het lijkt alsof HAProxy het meest gangbaar is hier.

Doorsturen klinkt idd als proxy - kan met Traefik of andere smaken als HAProxy, of zelfs Nginx, Caddy etc

Een proxy per dienst (service)/poort, bedoel je denk ik (gezien portforwarding)?

(Alles doorsturen - ongeacht aard - klinkt in ieder geval bij mij als lastiger te regelen ..)

Bedenk me net: met Cloudflare kan je dit ook prima voor elkaar krijgen - just an idea

[ Voor 3% gewijzigd door bart.koppers op 06-05-2025 14:35 ]

[Roetzen]

CloudPrutser schreef op dinsdag 6 mei 2025 @ 11:37:

Wat ik graag zou willen bereiken: al het IPv6-netwerkverkeer ontvangen op een VPS, en het verkeer doorsturen naar mijn IPv4 consumentenrouter zodat ik gewoon de huidige port-forwarding config kan blijven gebruiken.

Ik begrijp niet goed wat je probleem is en wat je nu wilt. Als je je interne netwerk IPv4 only wilt houden en toch met de buitenwereld via IPv6 kunnen communiceren dan zeg ik: dat moet je helemaal niet willen want dan mis je veel van de voordelen van IPv6. Gewoon je interne netwerk aanvullen met IPv6. Dan kun je nog steeds voor IPv4 de port forwarding config laten voor wat ie is. Je moet het dan alleen aanvullen met pinholing voor IPv6. Dat is echt niet moeilijk en consumentenrouters die ook IPv6 doen zijn er tegenwoordig te kust en te keur voor niet al te veel geld.

[ Voor 6% gewijzigd door Roetzen op 06-05-2025 16:47 ]

[Snow_King]

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!

[CloudPrutser]

Tom Paris schreef op dinsdag 6 mei 2025 @ 13:11:
[...]


Welk probleem wil je precies oplossen? Heb je een provider zonder IPv6 (Odido), of heb je CG-NAT? Maakt het makkelijker een oplossing te verzinnen...

Nee, ik heb zelfs native IPv4 én IPv6. Gewoon vast. Het echte probleem is dat ik de ballen verstand van zaken heb, want ik loop echt achter helaas.

Ik heb vermoedelijk al een oplossing gevonden met socat, die IPv6-verkeer vanaf een VPS doorstuurt naar mijn IPv4-router. Dat zou wellicht kunnen werken voor nu.

[CloudPrutser]

Roetzen schreef op dinsdag 6 mei 2025 @ 16:30:
[...]

Ik begrijp niet goed wat je probleem is en wat je nu wilt. Als je je interne netwerk IPv4 only wilt houden en toch met de buitenwereld via IPv6 kunnen communiceren dan zeg ik: dat moet je helemaal niet willen want dan mis je veel van de voordelen van IPv6. Gewoon je interne netwerk aanvullen met IPv6. Dan kun je nog steeds voor IPv4 de port forwarding config laten voor wat ie is. Je moet het dan alleen aanvullen met pinholing voor IPv6. Dat is echt niet moeilijk en consumentenrouters die ook IPv6 doen zijn er tegenwoordig te kust en te keur voor niet al te veel geld.

Het ding is een beetje dat er een DMZ zit tussen zowel mijn privenetwerk als het Proxmox-netwerk.

Dat betekent dat je enkel vanuit de DMZ IPv6-connected bent; alles dat hier achter zit weet niet beter dan IPv4.

Maargoed, het probleem ben ik zelf dus in dit geval.

[Roetzen]

CloudPrutser schreef op vrijdag 9 mei 2025 @ 11:53:
[...]

Het ding is een beetje dat er een DMZ zit tussen zowel mijn privenetwerk als het Proxmox-netwerk.

Dat betekent dat je enkel vanuit de DMZ IPv6-connected bent; alles dat hier achter zit weet niet beter dan IPv4.

Maargoed, het probleem ben ik zelf dus in dit geval.

Maar dat laatste, daar valt gelukkig wat aan te doen.
Toen ik begon met IPv6, inmiddels al weer meer dan vijftien jaar geleden dacht ik ook dat het wel makkelijk zou zijn om aan de rand van mijn systeem alles van IPv6 naar IPv4 te vertalen en door te geven zodat de rest van mijn systeem gewoon IPv4 kon blijven. Zo dacht ik ook dat het voor providers - gezien het feit dat er geen tekort is aan IPv6 adressen - wel doenlijk zou zijn meer dan één IPv6 adres aan een klant te geven. Een stuk of vijftien leek me wel leuk om te hebben... Tja, al doende leert men en de leercurve van IPv4 naar IPv6 is niet altijd vlak. Het vergt even een andere manier van denken. Maar het loont echt de moeite om er in te duiken en na de eerste hobbel, het afstand nemen van "IPv4 think" wordt het makkelijker. Vergeet dat plan om van IPv6 naar IPv4 om te zetten en ga je verdiepen in IPv6. Er is genoeg lesmateriaal te vinden en uiteraard staan we hier ook klaar om je verder te helpen.

Les 1: bij IPv6 heb je geen NAT (nodig) en DMZ is ook een typische IPv4 constructie. Gewoon vergeten en opnieuw beginnen.

[CloudPrutser]

Roetzen schreef op vrijdag 9 mei 2025 @ 12:36:
[...]

Maar dat laatste, daar valt gelukkig wat aan te doen.
Toen ik begon met IPv6, inmiddels al weer meer dan vijftien jaar geleden dacht ik ook dat het wel makkelijk zou zijn om aan de rand van mijn systeem alles van IPv6 naar IPv4 te vertalen en door te geven zodat de rest van mijn systeem gewoon IPv4 kon blijven. Zo dacht ik ook dat het voor providers - gezien het feit dat er geen tekort is aan IPv6 adressen - wel doenlijk zou zijn meer dan één IPv6 adres aan een klant te geven. Een stuk of vijftien leek me wel leuk om te hebben... Tja, al doende leert men en de leercurve van IPv4 naar IPv6 is niet altijd vlak. Het vergt even een andere manier van denken. Maar het loont echt de moeite om er in te duiken en na de eerste hobbel, het afstand nemen van "IPv4 think" wordt het makkelijker. Vergeet dat plan om van IPv6 naar IPv4 om te zetten en ga je verdiepen in IPv6. Er is genoeg lesmateriaal te vinden en uiteraard staan we hier ook klaar om je verder te helpen.

Les 1: bij IPv6 heb je geen NAT (nodig) en DMZ is ook een typische IPv4 constructie. Gewoon vergeten en opnieuw beginnen.

Allright, goed dan, ik ga opnieuw beginnen.

Ik snap dat ik niet meer achter kan blijven. Ik zal met de tijd met erin gaan verdiepen, maar het kan echt wel een paar maanden gaan duren voordat ik er echt goed voor kan gaan zitten.

Dus voorlopig is mijn hack even afdoende.

[CloudPrutser]

Hoe gaat het trouwens met de transitie? Wat is de status van IPv6 adoptie in Nederland en de rest van de wereld?

[RobertMe]

CloudPrutser schreef op vrijdag 9 mei 2025 @ 17:05:
Hoe gaat het trouwens met de transitie? Wat is de status van IPv6 adoptie in Nederland en de rest van de wereld?

Op welk gebied?

ISPs is de enige uitzondering die het niet doet op vaste aansluitingen Odido. Ziggo, KPN, Delta, Freedom, Glasnet, ... doen allemaal gewoon IPv6. En bij Delta krijg je standaard zelfs geen publiek IPv4 adres meer (maar zit je achter CGNAT, dat je wel uit kunt laten schakelen waarna je weer een eigen IPv4 adres krijgt en port forwards etc weer mogelijk zijn).
Aan de mobiele kant is KPN (en dochters) dan weer de uitzondering dat ze het wel doen naar wat ik begrepen heb. Odido en Vodafone dan dus niet.

En ik denk dat aan de server kant de meeste hosting partijen het wel ondersteunen? En bij VPSen/servers je soms zelfs kunt kiezen voor IPv6 only met een kleine korting.

En de adoptie is natuurlijk ook weer niet heel interessant gok ik. Zolang dual stack maar kan / beschikbaar is. IPv6 only gaat je vast nog niet lukken.

[CloudPrutser]

Allright, zoals ik het dus begrijp heb je miljarden adressen tot je beschikking op een aansluiting. Je eigen interne machines zijn bereikbaar met een publiekelijk adres die onder jouw subnet vallen.

Wellicht kan iemand het een heel klein beetje voorkauwen voor mij; dan ben ik gelijk een heel stuk verder voor nu: is er een manier om interne machines achter een tweede consumentenrouter toegang te laten krijgen tot IPv6 internet?
Ik hoorde over een soort IPv6 DHCP relay waarbij het apparaat te horen krijgt tot welk subnet het behoort en zichzelf hierin een eigen adres toewijst.

Dit klinkt alsof ik dat minimaal wil hebben op mijn netwerk.

[duvekot]

CloudPrutser schreef op zondag 11 mei 2025 @ 08:54:
Allright, zoals ik het dus begrijp heb je miljarden adressen tot je beschikking op een aansluiting. Je eigen interne machines zijn bereikbaar met een publiekelijk adres die onder jouw subnet vallen.

Wellicht kan iemand het een heel klein beetje voorkauwen voor mij; dan ben ik gelijk een heel stuk verder voor nu: is er een manier om interne machines achter een tweede consumentenrouter toegang te laten krijgen tot IPv6 internet?
Ik hoorde over een soort IPv6 DHCP relay waarbij het apparaat te horen krijgt tot welk subnet het behoort en zichzelf hierin een eigen adres toewijst.

Dit klinkt alsof ik dat minimaal wil hebben op mijn netwerk.

In de meeste consumenten routers werkt eea bijna plug en play .. maar is ook afhankelijk van welke provider je hebt. Heb je al gekeken wat voor een IPv6 adressen en subnet grote je krijgt van je ISP.

En waarom een tweede consumenten router? Kan dat niet makkelijker met maar 1 router?

[RobertMe]

duvekot schreef op zondag 11 mei 2025 @ 09:09:
En waarom een tweede consumenten router? Kan dat niet makkelijker met maar 1 router?

Het kan natuurlijk om een eigen router achter een ISP modem/router gaan? Een situatie die nooit echt ideaal is/was. Maar als het goed is bij IPv6 beter zou moeten werken. Omdat in theorie die eigen router via DHCP6 PD een prefix kan opvragen voor zijn LAN en de ISP modem/router die PD request relayd naar de ISP en het resultaat ook zelf verwerkt door een extra route vast te leggen (voor dat specifieke subnet naar de router die de PD request heeft gedaan). Alleen schijnt het nogal eens voor te komen dat die ISP modem/routers of helemaal geen relaying doen of de route niet vastleggen.

Beste blijft dus gewoon geen router achter router gebruiken. Ook i.v.m. firewalling natuurlijk (poorten in 2 routers moeten open zetten).

[Roetzen]

CloudPrutser schreef op zondag 11 mei 2025 @ 08:54:
Allright, zoals ik het dus begrijp heb je miljarden adressen tot je beschikking op een aansluiting. Je eigen interne machines zijn bereikbaar met een publiekelijk adres die onder jouw subnet vallen.

Je krijgt inderdaad héél véél IPv6 adressen. De kleinste eenheid is een /64. Oftewel een subnet met 2^64 adressen. Van de meeste providers in Nederland krijg je een /56 bij een consumenten aansluiting. Oftewel goed voor 2^(128-64-56)=256 subnetten.Bij sommige providers zoals Freenet krijg je een /48. Ofwel 65536 subnetten. Meer dan genoeg dus.

Wellicht kan iemand het een heel klein beetje voorkauwen voor mij; dan ben ik gelijk een heel stuk verder voor nu: is er een manier om interne machines achter een tweede consumentenrouter toegang te laten krijgen tot IPv6 internet?
Ik hoorde over een soort IPv6 DHCP relay waarbij het apparaat te horen krijgt tot welk subnet het behoort en zichzelf hierin een eigen adres toewijst.

Ja, dat kan. Je kunt bij IPv6 routers achter elkaar hangen. Van de /56 die je van de provider krijgt kun je subnetten gaan verdelen. De eerste router pakt meestal meteen de eerste /64 in voor zijn eigen subnet. Soms ook een tweede voor een gastnetwerk. Blijven er nog genoeg subnetten over. Als je er dan een tweede router acher hangt kan die via zogenaamde prefix delegation aan de eerste router een kleiner blok uit de resterende subnetten vragen. Bijvoorbeeld een /60. Dus 16 subnetten van /64. Daarvan kan hij er een aantal voor "eigen"gebruik" innemen. Een derde router die achter de tweede hangt kan aan de tweede weer een blok aanvragen middels prefix delegation. Bijvoorbeeld een /62. Vier /64 subnetten. Enzovoort. Je kunt in principe routers cascaderen tot alles verdeeld is.

Maar je kunt met een beetje geavanceerde router ook zonder cascadering subnetten uitdelen. Bij mijn Mikrotik hEX routerje kan ik aan elk van de vier LAN poorten een eigen /64 subnet toewijzen als ik zou willen.

Dit klinkt alsof ik dat minimaal wil hebben op mijn netwerk.

Ja, zoals ik het lees wil je tenminste twee min of meer gescheiden subnetten hebben. Eén voor privé en een voor de rest. Dat kan allemaal met IPv6. Maar helaas ondersteunen de meeste routers die je van de provider in bruikleen krijgt dat niet of slechts gebrekkig. De zwarte Sagemcom van Ziggo ondersteunt geen prefix delegation en de Nokia XS-2426 van Delta ook niet. De Fritz!box van Freedom doet het dacht ik wel.

Je zult dus mogelijk wel aan een eigen router moeten voor wat je wilt.

[CloudPrutser]

Vandaag even een beginnetje maken: die tweede router er tussenuit slopen.

[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...