Het grote IPv6 topic

[D0ubleD0uble]

juanita schreef op woensdag 16 oktober 2024 @ 15:13:
Zou thuis ook graag de overstap willen maken naar IPv6. Lijkt er alleen helaas op dat er slechts 2 aanbieders van zijn: KPN en Ziggo. Is het echt zo droevig gesteld?

Gelukkig niet. Alle grote ISPs (Ziggo, KPN, Delta) ondersteunen het wel met uitzondering van Odido. Kleinere spelers hangt er een beetje vanaf. Trined doet IPv6 native en IPv4 CGNAT. Via Glasnet hier netjes native IPv6 met bijbehorende native IPv4. Als je het niet online kan vinden of er IPv6 is kan je natuurlijk altijd contact zoeken met de desbetreffende ISP. Heb je misschien een overzicht van welke providers er in jouw gebied beschikbaar zijn?

[juanita]

D0ubleD0uble schreef op woensdag 16 oktober 2024 @ 15:29:
[...]

Gelukkig niet. Alle grote ISPs (Ziggo, KPN, Delta) ondersteunen het wel met uitzondering van Odido. Kleinere spelers hangt er een beetje vanaf. Trined doet IPv6 native en IPv4 CGNAT. Via Glasnet hier netjes native IPv6 met bijbehorende native IPv4. Als je het niet online kan vinden of er IPv6 is kan je natuurlijk altijd contact zoeken met de desbetreffende ISP. Heb je misschien een overzicht van welke providers er in jouw gebied beschikbaar zijn?

Allemaal glasvezel lijkt het. Is DSL dan echt uitgestorven ondertussen? Zit nu bij Odido op DSL, en dat bevalt prima, maar wil toch overwegen over te stappen op IPv6. Evnetueel dan maar glasvezel.

[RobertMe]

D0ubleD0uble schreef op woensdag 16 oktober 2024 @ 15:29:
Alle grote ISPs (Ziggo, KPN, Delta) ondersteunen het wel met uitzondering van Odido. Kleinere spelers hangt er een beetje vanaf. Trined doet IPv6 native en IPv4 CGNAT. Via Glasnet hier netjes native IPv6 met bijbehorende native IPv4.

Delta doet overigens standaard ook CGNAT op IPv4, maar kun je wel uit laten zetten.

[Darses]

juanita schreef op woensdag 16 oktober 2024 @ 15:13:
Zou thuis ook graag de overstap willen maken naar IPv6. Lijkt er alleen helaas op dat er slechts 2 aanbieders van zijn: KPN en Ziggo. Is het echt zo droevig gesteld?

Naast de voorgaande reacties doet ook Freedom Internet native IPv6 en IPv4 (zonder CGNAT).

[Roetzen]

DeCa doet wel IPv6 maar ze moeten nog een paar stappen maken. Zo kun je op hun Nokia XSGPON modem/router nog steeds geen IPv6 pinhole configureren en hun DNS servers zijn nog alleen via IPv4 bereikbaar.

[MORCIK]

juanita schreef op woensdag 16 oktober 2024 @ 15:13:
Zou thuis ook graag de overstap willen maken naar IPv6. Lijkt er alleen helaas op dat er slechts 2 aanbieders van zijn: KPN en Ziggo. Is het echt zo droevig gesteld?

Ik heb Freedom internet met native IPv6 /48 en vast IP-adres. Een aanrader!

[Dreamvoid]

Roetzen schreef op maandag 21 oktober 2024 @ 08:26:
Zo kun je op hun Nokia XSGPON modem/router nog steeds geen IPv6 pinhole configureren

Dus je kan geen servers draaien over IPv6? Da's echt waardeloos idd.

[Roetzen]

Dreamvoid schreef op maandag 28 oktober 2024 @ 15:41:
[...]

Dus je kan geen servers draaien over IPv6? Da's echt waardeloos idd.

Inderdaad, het kan alleen als je een eigen Router en ONT installeert. Voor mij een dikke minpunt!

[aawe mwan]

Vandaag viel me voor het eerst op dat er in fail2ban een IPv6 adres langs kwam, dat niet van mijzelf is.

Dit op het (vaste) IPv6 adres van een server die zelf alleen het internet op gaat voor de Ubuntu updates. Hebben ze nou echt de volledige IPv6 adress space zitten scannen? Of heb ik last van een vulnerability?

[RobertMe]

aawe mwan schreef op dinsdag 29 oktober 2024 @ 18:36:
Vandaag viel me voor het eerst op dat er in fail2ban een IPv6 adres langs kwam, dat niet van mijzelf is.

Dit op het (vaste) IPv6 adres van een server die zelf alleen het internet op gaat voor de Ubuntu updates. Hebben ze nou echt de volledige IPv6 adress space zitten scannen? Of heb ik last van een vulnerability?

Kunnen mogelijk ook andere dingen zijn?

Zelf heb ik op mijn VPS bv SSH alleen via IPv6 open staan, en ook daar komt incidenteel iemand langs (uiteraard veel minder dan IPv4). Is dan wel op het ::1 adres. Maar bv domeinnamen hangen niet aan die ::1.

[Charlie_Root]

RobertMe schreef op dinsdag 29 oktober 2024 @ 19:09:
[...]

Kunnen mogelijk ook andere dingen zijn?

Zelf heb ik op mijn VPS bv SSH alleen via IPv6 open staan, en ook daar komt incidenteel iemand langs (uiteraard veel minder dan IPv4). Is dan wel op het ::1 adres. Maar bv domeinnamen hangen niet aan die ::1.

Ik zie het andersom, veel veel meer portscans en brute-forces op IPv6. Er was laatst iemand mijn /48 aan het scannen en dat zorgde voor 1Gbit/s aan verkeer.

[RobertMe]

Charlie_Root schreef op woensdag 30 oktober 2024 @ 09:55:
[...]


Ik zie het andersom, veel veel meer portscans en brute-forces op IPv6. Er was laatst iemand mijn /48 aan het scannen en dat zorgde voor 1Gbit/s aan verkeer.

Even snel in logs gekeken. Sinds 20 oktober, dus ~10 dagen geleden, zie ik v.w.b. SSH dan 4x een "Connection closed by remote host" zonder dat er iets gebeurt is (tussen veel teveel logging in van succesvolle logins van periodieke backups waarbij via SSH wordt ingelogd om de backup te downloaden).
Terwijl het met IPv4 nog ingeschakeld dan ging om vele pogingen per dag. Maar ik geloof best dat er ook bij IPv6 wel eens op IP basis gebrute-forced / gescand zal worden. Maar dat lijkt mij "op het grote internet" minder voor te komen juist omdat het zoveel minder effectief is doordat er zoveel IPv6 adressen zijn waarvan misschien wel 90% of nog meer niet in gebruik of niet bruikbaar is. En als je dan ook nog rucksichloss een portscan wilt doen (dus 65k "requests" naar hetzelfde IPv6 adres waarvan onbekend is of het in gebruik is) is al helemaal onbegonnen werk. Als er dan al iets via IPv6 gedaan wordt lijkt het mij in eerste instantie dus veel meer gericht gezocht wordt (dus een IP uit DNS gehaald op basis van een bekende domeinnaam (die ook bekend kan zijn geworden doordat je bv enige vorm van SSL/TLS gebruikt en per definitie alle (publiek gegenereerde/uitgegeven) certificaten gepubliceerd worden en daarin dus de domeinnaam staat)). Waarbij dat "gericht" dan ook mogelijk zou kunnen zijn op basis van een bekend adres en dan de volledige /64 of zo (dat nog steeds onbegonnen werk is, is immers nog steeds veel groter dan volledige IPv4 address space).

[Snow_King]

aawe mwan schreef op dinsdag 29 oktober 2024 @ 18:36:
Vandaag viel me voor het eerst op dat er in fail2ban een IPv6 adres langs kwam, dat niet van mijzelf is.

Dit op het (vaste) IPv6 adres van een server die zelf alleen het internet op gaat voor de Ubuntu updates. Hebben ze nou echt de volledige IPv6 adress space zitten scannen? Of heb ik last van een vulnerability?

Ik zie ook wel wat scans op IPv6 voorbij komen.

Je bent niet helemaal anoniem met IPv6:

- Je doet DNS verzoeken
- Je verbind met update servers

Ik zie wel wat scans van Universiteiten voorbij komen. Lijkt alsof ze naar webserver logs kijken en vervolgens daar een scan op starten.

Het ::1 adres uit een subnet krijgt sowieso veel scans, al weet ik niet welk adres jij gebruikt.

[duvekot]

Charlie_Root schreef op woensdag 30 oktober 2024 @ 09:55:
[...]


Ik zie het andersom, veel veel meer portscans en brute-forces op IPv6. Er was laatst iemand mijn /48 aan het scannen en dat zorgde voor 1Gbit/s aan verkeer.

Als dat op je huis aansluiting gebeurt heb je waarschijnlijk niet veel bandbreedte meer over om nog normaal internet te kunnen gebruiken denk ik ....
Hoelang zijn ze bezig geweest dan?

[Snow_King]

Update over de IPv6-only stad in China: https://blog.apnic.net/20...ilding-an-ipv6-only-city/

Zou toch tof zijn als we in Nederland ook deze durf en daadkracht hadden om dergelijke zaken te bouwen.

[Charlie_Root]

duvekot schreef op woensdag 30 oktober 2024 @ 14:04:
[...]

Als dat op je huis aansluiting gebeurt heb je waarschijnlijk niet veel bandbreedte meer over om nog normaal internet te kunnen gebruiken denk ik ....
Hoelang zijn ze bezig geweest dan?

Dit was gelukkig niet op mijn aansluiting thuis. Zo'n hele range scannen duurt al snel een paar uur

[Snow_King]

aawe mwan schreef op dinsdag 29 oktober 2024 @ 18:36:
Vandaag viel me voor het eerst op dat er in fail2ban een IPv6 adres langs kwam, dat niet van mijzelf is.

Dit op het (vaste) IPv6 adres van een server die zelf alleen het internet op gaat voor de Ubuntu updates. Hebben ze nou echt de volledige IPv6 adress space zitten scannen? Of heb ik last van een vulnerability?

Toevallig komt er nu op mijn Synology NAS ook een portscan binnen vanaf een IPv6 adres van Hurrican Electric. Mijn MikroTik router blokkeert het nu. Puur toeval dat ik keek in de logs, was voor iets anders aan het kijken.

Connecties naar de volgende poorten worden geprobeerd:

- 80
- 81
- 110
- 135
- 143

Firewall doet prima zijn werk en houdt het verkeer buiten

[RobertMe]

No NAT November: My Month Without IPv4

An zich een leuk experiment, maar...

spoiler:

Op dag 2 heeft hij al 464XLAT in gebruik.

Wat ik van bij mijzelf weet:

• Geen DuckDuckGo
• Geen GitHub
• Geen Reddit
• Denon versterker (uit 2017) lijkt geen enkel teken van een IPv6 leven te geen. (Vanaf 2020-ish wel op basis van eerdere zoektocht, en support dus blijkbaar niet gebackport naar oudere versies)
• Geen toegang tot test- & productieomgeving van werkgever (zou als developer dus een goede reden zijn om IPv4 te disablen , hoef ik ook geen support te doen)
• Home Assistant + ESPHome lijkt nog IPv4 te gebruiken via mDNS. Ondanks dat er hard gewerkt is aan IPv6 only support (wellicht is de voorkeur er voor IPv4 maar gebruikt die wel IPv6 in IPv6 only omgeving?)
• Ubiquiti UniFi hardware lijkt niet via IPv6 met de controller te kunnen babbelen.

[Snow_King]

RobertMe schreef op woensdag 4 december 2024 @ 07:29:
No NAT November: My Month Without IPv4

An zich een leuk experiment, maar...

spoiler:

Op dag 2 heeft hij al 464XLAT in gebruik.

Wat ik van bij mijzelf weet:

• Geen DuckDuckGo
• Geen GitHub
• Geen Reddit
• Denon versterker (uit 2017) lijkt geen enkel teken van een IPv6 leven te geen. (Vanaf 2020-ish wel op basis van eerdere zoektocht, en support dus blijkbaar niet gebackport naar oudere versies)
• Geen toegang tot test- & productieomgeving van werkgever (zou als developer dus een goede reden zijn om IPv4 te disablen , hoef ik ook geen support te doen)
• Home Assistant + ESPHome lijkt nog IPv4 te gebruiken via mDNS. Ondanks dat er hard gewerkt is aan IPv6 only support (wellicht is de voorkeur er voor IPv4 maar gebruikt die wel IPv6 in IPv6 only omgeving?)
• Ubiquiti UniFi hardware lijkt niet via IPv6 met de controller te kunnen babbelen.

Jammer, maar de realiteit. Niets mis met het protocol zelf, maar wel ontwikkelaars die het allemaal maar half implementeren.

Je moet je spul gewoon eerst op IPv6(only) laten werken en daarna pas over IPv4 nadenken. Dan maak je het beste spul.

Matter/Thread doet dat bijv gewoon veel beter, maakt echt goed gebruik van IPv6. Apple is daar met zijn devices ook al tijden goed mee bezig.

[Snow_King]

nieuws: Microsoft schakelt IPv6 vanaf 1 oktober standaard in bij Exchange Online

Ik ben de test gaan doen. Ik heb 5.000 domeinen opgezocht die gebruik maken van Microsoft Exchange Online (MS365) en ben hun MX-record gaan monitoren om te zien of ze IPv6 hebben of niet.

Dit doe ik op dagelijkse basis en heb nu als resultaten:

- 2024-11-01: 345
- 2024-12-01: 502
- 2024-12-18: 930

Ik zie nu dus al 18% waar IPv6 ingeschakeld is. Ik blijf het rustig aan monitoren, maar dit gaat langzaam aan de goede kant op.

[N3tMonk]

Goedenavond,

Weet iemand hier hoe IPv6 geconfigureerd (static/SLAAC/DHCPv6) dient te worden op een RoutIT-lijn? Ik meen statisch maar ik kan nergens in hun kennisdatabase de gateway vinden die gebruikt zou moeten worden.

[Snow_King]

N3tMonk schreef op woensdag 18 december 2024 @ 18:20:
Goedenavond,

Weet iemand hier hoe IPv6 geconfigureerd (static/SLAAC/DHCPv6) dient te worden op een RoutIT-lijn? Ik meen statisch maar ik kan nergens in hun kennisdatabase de gateway vinden die gebruikt zou moeten worden.

Je WAN kant bedoel je? Dat zal je echt bij hen moeten navragen. Gateway kan wel eens via een Router Advertisement gaan en dat je op de WAN kant niet eens een routeerbaar adres krijgt, alles via Link-Local.

Via DHCPv6 een prefix aanvragen?

graceful schreef op zondag 15 december 2024 @ 19:30:
Langzaamaan kunnen we allemaal onze servers gewoon weer thuis hosten
De meeste providers in DC leveren ook maar 1gb/s. En al die DCs leveren ook stroom op marktprijs tegenwoordig.

Als je tussenstation van je provider dan beetje goed gepostitioneerd is, scheelt het amper nog met glasvezel overal

Mijn antwoord past beter hier vind ik. Dit is juist de kracht van IPv6. Als iedereen thuis een 1Gb/s glasvezel lijn heeft met IPv6 dan kan je inderdaad 'gewoon' weer je servers thuis hosten. Bandbreedte voldoende voor het leeuwendeel van de toepassingen.

Helaas worden websites steeds minder belangrijker en trekt alles naar 'social' media, maar het idee is het zelfde.

IPv6 maakt het internet democratischer, je hoeft niet alles in een DC te hosten. Zeker, thuis is minder betrouwbaar, maar voor veel dingen echt betrouwbaar genoeg. Eventueel met een UPS voor je modem, switches en je servertje.

[Charlie_Root]

RobertMe schreef op woensdag 4 december 2024 @ 07:29:
No NAT November: My Month Without IPv4

An zich een leuk experiment, maar...

spoiler:

Op dag 2 heeft hij al 464XLAT in gebruik.

Wat ik van bij mijzelf weet:

• Geen DuckDuckGo
• Geen GitHub
• Geen Reddit
• Denon versterker (uit 2017) lijkt geen enkel teken van een IPv6 leven te geen. (Vanaf 2020-ish wel op basis van eerdere zoektocht, en support dus blijkbaar niet gebackport naar oudere versies)
• Geen toegang tot test- & productieomgeving van werkgever (zou als developer dus een goede reden zijn om IPv4 te disablen , hoef ik ook geen support te doen)
• Home Assistant + ESPHome lijkt nog IPv4 te gebruiken via mDNS. Ondanks dat er hard gewerkt is aan IPv6 only support (wellicht is de voorkeur er voor IPv4 maar gebruikt die wel IPv6 in IPv6 only omgeving?)
• Ubiquiti UniFi hardware lijkt niet via IPv6 met de controller te kunnen babbelen.

https://whynoipv6.com/

[Roetzen]

Charlie_Root schreef op zondag 22 december 2024 @ 08:07:
[...]


https://whynoipv6.com/

Ik heb wel een duimpje gegeven, het is een leuk initiatief, maar ik vrees dat het verder weinig zal uithalen. Github gaat niet ineens morgen IPv6 doen om dat een of andere nerd op een zolderkamertje in Noorwegen ze op een lijstje heeft gezet. Er zal meer nodig zijn om de achterblijvers mee te krijgen. Het enige wat echt nog helpt zijn maatregelen van de overheid die het de ondernemers in de portemonnee gaat laten voelen vrees ik. Maar dat zie ik in elk geval in Nederland met de huidige regering nog niet gauw gebeuren.

[Charlie_Root]

Roetzen schreef op zondag 22 december 2024 @ 11:13:
[...]

Ik heb wel een duimpje gegeven, het is een leuk initiatief, maar ik vrees dat het verder weinig zal uithalen. Github gaat niet ineens morgen IPv6 doen om dat een of andere nerd op een zolderkamertje in Noorwegen ze op een lijstje heeft gezet. Er zal meer nodig zijn om de achterblijvers mee te krijgen. Het enige wat echt nog helpt zijn maatregelen van de overheid die het de ondernemers in de portemonnee gaat laten voelen vrees ik. Maar dat zie ik in elk geval in Nederland met de huidige regering nog niet gauw gebeuren.

Github is druk bezig met IPv6, we krijgen steeds meer ipv6 traffic van/naar hun toe. Alleen de site github.com zelf nog niet, daar zijn ze mee bezig. Reddit is tegenwoordig ook over naar IPv6. Duurt allemaal wel erg lang, inderdaad.

[Roetzen]

Charlie_Root schreef op zondag 22 december 2024 @ 11:18:
[...]


Github is druk bezig met IPv6, we krijgen steeds meer ipv6 traffic van/naar hun toe. Alleen de site github.com zelf nog niet, daar zijn ze mee bezig. Reddit is tegenwoordig ook over naar IPv6. Duurt allemaal wel erg lang, inderdaad.

Het is mooi dat Github er mee bezig is, maar dat hadden ze tien jaar geleden al moeten doen. Dan was het nu klaar geweest. Ik zal pas tevreden zijn als Github volledige functionaliteit heeft vanuit een IPv6 only omgeving. En dat is nu nog niet het geval.

[Roetzen]

Snow_King schreef op donderdag 19 december 2024 @ 11:24:
[...]

Dit is juist de kracht van IPv6. Als iedereen thuis een 1Gb/s glasvezel lijn heeft met IPv6 dan kan je inderdaad 'gewoon' weer je servers thuis hosten. Bandbreedte voldoende voor het leeuwendeel van de toepassingen.

Daarbij wil ik dan nog opmerken dat er meer aan IPv6 vast zit dan die vinkjes die uitgedeeld worden. Zo heeft de Nokia XS2426G-B modem/router die Caiway en Delta aan haar PON abonnees uitdelen, een jaar en drie maanden nadat ik dat gemeld heb nog steeds geen werkende mogelijkheid om een IPv6 pinhole in de firewall te creëren. Dus daar ga je dan met de mogelijkheid thuis servers te draaien. Ja, ik weet het, dat is op te lossen door een eigen ONT en router aan te sluiten. Maar ik vind dat als je als ISP een modem/router in bruikleen aanbiedt, die dan ook de functionaliteit moet bieden die wordt voorgespiegeld. Maar ja, dat heeft dus bij DeCa kennelijk geen prioriteit.

[Roetzen]

O ja, de DNS servers van DeCa doen het ook niet in een IPv6 only omgeving. Weliswaar hebben hun DNS servers een IPv6 adres, maar ze doen het niet zonder IPv4 verbinding. Nog een mankementje aan hun IPv6 implementatie...

[fagao]

RobertMe schreef op woensdag 4 december 2024 @ 07:29:
No NAT November: My Month Without IPv4

An zich een leuk experiment, maar...

spoiler:

Op dag 2 heeft hij al 464XLAT in gebruik.

Wat ik van bij mijzelf weet:

• Geen DuckDuckGo
• Geen GitHub
• Geen Reddit
• Denon versterker (uit 2017) lijkt geen enkel teken van een IPv6 leven te geen. (Vanaf 2020-ish wel op basis van eerdere zoektocht, en support dus blijkbaar niet gebackport naar oudere versies)
• Geen toegang tot test- & productieomgeving van werkgever (zou als developer dus een goede reden zijn om IPv4 te disablen , hoef ik ook geen support te doen)
• Home Assistant + ESPHome lijkt nog IPv4 te gebruiken via mDNS. Ondanks dat er hard gewerkt is aan IPv6 only support (wellicht is de voorkeur er voor IPv4 maar gebruikt die wel IPv6 in IPv6 only omgeving?)
• Ubiquiti UniFi hardware lijkt niet via IPv6 met de controller te kunnen babbelen.

Ik heb deze week hetzelfde gedaan. Deze tutorial van Ondrej gevolgd:
https://ripe87.ripe.net/archives/video/1136/

IPv6 Mostly draait hier in mijn thuis netwerk op een OpenWRT install op een PI5.
Het werkt perfect. Mijn Apple devices doen allemaal 464Xlat en mijn Windows PC krijgt vrolijk nog IPv4 omdat hij geen CLAT kan.

De NAT64 die mijn router nu doet zou idealiter bij de ISP in het netwerk draaien. Ik ga serieus overwegen dit eens in het lab van eenISP te testen. Ik zie 464Xlat toch wel al eens van de beste transitie technieken.

Na een week draaien heb ik nog geen moment iets tegengekomen wat niet werkt.

[RobertMe]

fagao schreef op vrijdag 24 januari 2025 @ 07:55:
De NAT64 die mijn router nu doet zou idealiter bij de ISP in het netwerk draaien. Ik ga serieus overwegen dit eens in het lab van eenISP te testen.

Eerste wat ik dacht toen ik de notificatie zag "Da's toch die wat bij ... werkt?" Blijkbaar dacht ik juist?

Maar als je dit bij de ISP draait verliest de klant neem ik aan weer de mogelijkheid tot port forwarding etc? Of in ieder geval, dat lijkt mij voor de hand te liggen om dan ook IPv4 adressen te "delen". Het hoeft vast niet, maar als ik de juiste ISP in gedachten heb doen jullie dit sowieso al.

[Roetzen]

Ik heb naar aanleiding van Alex Haydock's artikel ook wat experimentjes gedaan. Maar dan speciaal geöriënteerd op Fidonet ( Ja, het bestaat nog). Ik heb daarover gepupliceerd in Fidonews. Dit was het verhaal:

=== begin ===

IPv6 only experiment
By Michiel van der Vlist, 2:280/5555

In my last week's (or last year's if you want) article *1) I mentioned
Alex Haydock's IPv6 only project. *2) This inspired me to have a look
at how Fidonet systems would behave in such an environment. My conclu-
sion was that the "problem" of literal IPv4 addresses in the nodelist
can be worked around by using binkp.net. At the end of that part I
wrote: "Did I test this? Yes of course! See next week's article..."

So here it is: a report of what I tested and how.

I choose to not build an entire IPv6 only environment like Alex
Haydock did but to use the minumum required for the test I had in
mind. Just a single system with IPv6 only access: The laptop running
my point system. That laptop (a Dell Latitude D620, running WIN7) has
WiFi on board and an RJ45 connector for UTP cable. It has a manual
switch to enable/disble the WiFi. So the first step was to switch off
the WiFi and connect the laptop to the LAN with a cable. This allowed
me to easely switch between the original setup and the IPv6 only
setup. Just plug/unplug the cable and unset/set the WiFi switch.

The second step was to disable IPv4 in the LAN cable interface.

After doing that I found out I no longer had access to the Internet.
It turned out the DNS servers of my provider (Caiway Fiber) do not
work well in an IPv6 only environment. Malus point for Caiway! The DNS
servers of my other provider (Ziggo) do not have that problem. No big
deal because for the test I had in mind, I have to use other DNS
servers anyway. I need DNS64 and NAT64 to be able to access IPv4 only
systems. Contrary to Alex Haydock I do not have a provider that offers
these services so I have to look elsewhere. Instead of building a
NAT64 gateway myself just for this experiment, I decided to make use
of a third party. The free service of Kasper Dupont was not hard to
find. *3) All I had to do was to configure the wired LAN interface to
use he following DNS servers:

2a00:1098:2c::1
2a01:4f8:c2c:123f::1
2a01:4f9:c010:3f02::1

These are DNS64 servers. For accessing IPv4 only systems they refer to
his NAT64 gateway. That is all that is needed to create an IPv6 only
environment with DNS64/NAT64 support.

For details on the working of DNS64/NAT64: Google is your friend! *4)

After configuring the above DNS servers binkd could connect to IPv6
nodes and most IPv4 nodes in the nodelist. IPv6 nodes are connected
as usual and IPv4 only nodes are connected via the NAT64 gateway.
So to the other side they will appear to come from the IPv4 WAN
address of the gateway. 95.216.219.126 in this case. It will back
resolve to nat64.dyndns.dk. So if you have an IPv4 only binkp node
and you see that in your logs with an incoming connection from
2:280/5555.1 that was me testing.

For nodes listed with a literal IPv4 address a work around is still
needed. DSN64/NAT64 does not work with literal IPv4 addresses. The
work around - as mentioned in my previous article *1) - is to use
binkp.net. After manually configuring * for the literal adresses in
binkd.cfg these nodes were connected without further problems.

So running a Fidonet node in an IPv6 only environment is no problem.

There are a few snags though. For one, it is not possible to connect
to nodes that advertise IPv6 connectivity but do not actually support
it. I could not connect to 240/8010. Binkd times out and that's it.
There is no fall back to IPv4 in this configuration. Of course there
isn't! This is IPv6 only remember!? So if we want to prepaire for an
IPv6 only Internet, we'd better get used to that. But for those who
are not quite ready for that there is a work around, but it is a bit
more complicated. Configure [2a00:1098:2c::5:93.236.155.101] as the
literal IPv6 address for binkd to connect. Here we bypass the DNS64
and directly connect to the NAT64 gateway. 2a00:1098:2c::5: is the
prefix used by the NAT64 gateway and 93.236.155.10 is the IPv4 address
of the node in question. Writing the last 32 bits of an IPv6 address
as an IPv4 quad is a legitimate way of writing an IPv6 address though
not all applications may understand it. Apparently the WIn32 version
of binkd does. Your milage may vary.

This method could also be used to connect to IPv4 only nodes with a
literal IPv4 address though it may not be practial.

Authors of scripts that generate a configuration file for binkd from
the nodelist may consider to add either method as an option.

It goes without saying that incoming IPv6 is no problem in this confi-
guration. It works as before.

Incoming IPv4... Well, there isn't. Not in this IPv6 only configura-
tion. In my, now 7+ year old DS-Lite emulation experiments *4-8), I
demonstrated that running an IPv6 node without incoming IPv4 is do-
able. And for those who can not or do not want to renounce incoming
IPv4 yet, there is Feste-ip.net. *7) But maybe we should just forego
incoming IPv4 for a while to entice the IPv4 only sysops of Fidonet to
adopt IPv6. :-)

As a side note: I wonder how long Kasper Dupont will continue this
service. It is free and open to all without any registration or other
authorisation. I feel a bit uncomfortable about that, it looks like a
recipe for abuse. But he has been running it for over five years now,
so it may not be a serious problem. So it feels OK for a short and
simple test.

Another problem with public NAT64 gateways is similar to the problem
with the 6to4 tunnels that some of us are still using: services using
geolocation to grant access may get confused because all traffic seems
to come from the gateway, not from the originator. Not a problem for
Fidonet I'd say, but for other use it may be.

For those and some other reasons I would prefer a NAT64 gateway run
by my provider if I ever start to use this permanently. I have two
providers at the moment and neither of them provides such a service.
I may make that a goal for the coming year. Or next year...


References:

1) FN 41:53 Dec 2024 IPv6 in 2024
2) https://blog.infected.sys...24-12-01-no-nat-november/
3) https://nat64.net/
4) Wikipedia: IPv6 transition mechanism
5) FN 34:31 Jul 2017 DS-Lite emulation experiment v2.0
6) FN 34:37 Sep 2017 DS-Lite emulation experiment 2.0, the results
7) FN 34:33 Aug 2017 DS-Lite: a solution
FN 34:38 Sep 2017 DS-Lite Emulation experiment v2.1

=== einde ===

Ik heb het dus simpel gehouden en heb geen eigen NAT64 gateway opgezet. Maar als een NL provider dat zou doen zou dat voor mij wel een pluspunt zijn als ik weer een ga kijken welke provider het beste bij mij past...

[Roetzen]

RobertMe schreef op vrijdag 24 januari 2025 @ 09:12:
[...]

Maar als je dit bij de ISP draait verliest de klant neem ik aan weer de mogelijkheid tot port forwarding etc? Of in ieder geval, dat lijkt mij voor de hand te liggen om dan ook IPv4 adressen te "delen". Het hoeft vast niet, maar als ik de juiste ISP in gedachten heb doen jullie dit sowieso al.

Tja, als je een IPv6 only omgeving draait moet je inkomend IPv4 gewoon vergeten natuurlijk. Daar willen we immers van af. Inkomend IPv6 is uiteraard geen probleem in zo'n omgeving.

[fagao]

RobertMe schreef op vrijdag 24 januari 2025 @ 09:12:
[...]

Eerste wat ik dacht toen ik de notificatie zag "Da's toch die wat bij ... werkt?" Blijkbaar dacht ik juist?

Maar als je dit bij de ISP draait verliest de klant neem ik aan weer de mogelijkheid tot port forwarding etc? Of in ieder geval, dat lijkt mij voor de hand te liggen om dan ook IPv4 adressen te "delen". Het hoeft vast niet, maar als ik de juiste ISP in gedachten heb doen jullie dit sowieso al.

Klopt, ik doe werk voor AS15435
Het hele idee van IPv6 is dat je geen port forwarding meer hoeft te doen. Als je in IPv4 blijft denken wordt het nooit wat met de transitie. Het voordeel van Ipv6 is dat je thuis gewoon 10 webservers kan draaien die allemaal een eigen adres hebben en port 443 kunnen gebruiken

[RobertMe]

fagao schreef op zaterdag 25 januari 2025 @ 08:54:
Het hele idee van IPv6 is dat je geen port forwarding meer hoeft te doen. Als je in IPv4 blijft denken wordt het nooit wat met de transitie. Het voordeel van Ipv6 is dat je thuis gewoon 10 webservers kan draaien die allemaal een eigen adres hebben en port 443 kunnen gebruiken

Dan noem ik het "poorten open zetten" De exacte techniek doet er niet toe. Of het nu een DNAT regel op IPv4 is of gewoon een open poort in de firewall bij IPv6.

Als je native IPv4 hebt op je router kun je ook een poort open zetten (op IPv4). Als je op de router in een CGNAT zit of NAT64 dan heb je geen publiek IPv4 adres meer en heb je dus ook geen mogelijkheid tot poorten open zetten.

Uiteraard uiteindelijk minder relevant als alles IPv6 ondersteund, dan kun je prima altijd en overal gewoon via IPv6 binnen komen. Maar die tijd is nog niet aangebroken. Niet alle ISPs ondersteunen IPv6 (hallo Odido, bv), laat staan alle mobiele operators (hallo Odido, en ik meen Vodafone ook niet). Dus als je thuis poorten open wilt zetten blijf je afhankelijk van IPv4, met ook een publiek adres op de eigen/lokale router en geen CGNAT / NAT64 bij de ISP.

[StaticZ]

Op CGNAT zou een poort openzetten prima moeten gaan!
Het "forwarden" word wat lastig.

[Snow_King]

fagao schreef op zaterdag 25 januari 2025 @ 08:54:
[...]

Klopt, ik doe werk voor AS15435
Het hele idee van IPv6 is dat je geen port forwarding meer hoeft te doen. Als je in IPv4 blijft denken wordt het nooit wat met de transitie. Het voordeel van Ipv6 is dat je thuis gewoon 10 webservers kan draaien die allemaal een eigen adres hebben en port 443 kunnen gebruiken

Dat laatste stuk vooral, dat is zo mooi en brengt de kracht van het internet terug. Achter je 1Gb glasvezel gewoon direct wat diensten kunnen draaien, ideaal!

Voor mijzelf doe ik dat al met Plex, Nextcloud, Home Assistant, etc. Staat thuis met native v6 van Ziggo Zakelijk en vanaf mijn KPN mobiel kan ik er gewoon bij.

[RobertMe]

Snow_King schreef op zaterdag 25 januari 2025 @ 09:09:
Voor mijzelf doe ik dat al met Plex, Nextcloud, Home Assistant, etc. Staat thuis met native v6 van Ziggo Zakelijk en vanaf mijn KPN mobiel kan ik er gewoon bij.

Ik gebruik daarvoor gewoon een VPN, op de router, dus geen forwards voor nodig. Uiteraard wel een open poort met bestemming router, maar geen DNAT / accept in een forward chain.

En gedeeltelijk valt er natuurlijk ook "omheen" te werken. Nextcloud & Home Assistant is HTTP. Zet er een reverse proxy voor (/zeer grote kans dat je die al hebt) en het zit weer allemaal achter één IP + poort combinatie.

Andere zaken is het wel interessanter. SSH naar meerdere systemen bv. Maar daar kun je weeer jump hosts gebruiken. Connect met A en ga dan van A naar B. Wat ook weer een stukje veiligheid toe kan voegen.

Waarvoor ik IPv6 dan weer wel exclusief gebruik is SSH op mijn VPS. Scheelt extreem veel aan logging v.w.b. failed login attempts. En met Ziggo + KPN mobiel heb ik toch altijd toegang tot IPv6.

[Snow_King]

RobertMe schreef op zaterdag 25 januari 2025 @ 09:27:
[...]

Ik gebruik daarvoor gewoon een VPN, op de router, dus geen forwards voor nodig. Uiteraard wel een open poort met bestemming router, maar geen DNAT / accept in een forward chain.

En gedeeltelijk valt er natuurlijk ook "omheen" te werken. Nextcloud & Home Assistant is HTTP. Zet er een reverse proxy voor (/zeer grote kans dat je die al hebt) en het zit weer allemaal achter één IP + poort combinatie.

Andere zaken is het wel interessanter. SSH naar meerdere systemen bv. Maar daar kun je weeer jump hosts gebruiken. Connect met A en ga dan van A naar B. Wat ook weer een stukje veiligheid toe kan voegen.

Waarvoor ik IPv6 dan weer wel exclusief gebruik is SSH op mijn VPS. Scheelt extreem veel aan logging v.w.b. failed login attempts. En met Ziggo + KPN mobiel heb ik toch altijd toegang tot IPv6.

Ik vind VPN en proxy maar een gedoe. Gewoon directe IP connectie en beveiligen met TLS. Werkt met IPv6 gewoon vlekkeloos.

[RobertMe]

Snow_King schreef op zaterdag 25 januari 2025 @ 13:24:
[...]

Ik vind VPN en proxy maar een gedoe. Gewoon directe IP connectie en beveiligen met TLS. Werkt met IPv6 gewoon vlekkeloos.

Gaat redelijk offtopic. Maar dan moet je er wel op vertrouwen dat die software ook veilig is en geen lekken bevat. TLS beveiligd immers alleen tegen een MITM aanval. Als bv een login formulier hartstikke lek is dan kan een kwaadwillende zo binnen komen, of als er ergens anders een authentication bypass of wat dan ook is (of je gewoon zwakke credentials gebruikt uiteraard). En gezien Nextcloud en Home Assistant en Plex en ... en ... en ... niet "beveiliging" als enige feature hebben is de kans dat daar een fout in zit een stuk groter dan dat een fout zit in een (bekend) VPN pakket (zoals OpenVPN of Wireguard. Of al die moderne hippe (SaaS) oplossingen zoals Cloudflare Tunnels, Tailscale, etc).

En als "TLS" wordt voorzien door een publieke certificate authority (zoals Let's encrypt) ligt de domeinnaam mogelijk ook meteen op straat. Immers dwingt certificate transparency hen om de gegevens van alle gegenereerde certificaten te publiceren. Zie bv https://crt.sh/?q=tweakers.net voor Tweakers (die intussen wel al een flink aantal jaren wildcard certificaten aanvragen waardoor de subdomeinen niet meer onderdeel van het certificaat zijn).

[duvekot]

RobertMe schreef op zaterdag 25 januari 2025 @ 13:43:
Gaat redelijk offtopic. Maar dan moet je er wel op vertrouwen dat die software ook veilig is en geen lekken bevat. TLS beveiligd immers alleen tegen een MITM aanval. Als bv een login formulier hartstikke lek is dan kan een kwaadwillende zo binnen komen, of als er ergens anders een authentication bypass of wat dan ook is (of je gewoon zwakke credentials gebruikt uiteraard). En gezien Nextcloud en Home Assistant en Plex en ... en ... en ... niet "beveiliging" als enige feature hebben is de kans dat daar een fout in zit een stuk groter dan dat een fout zit in een (bekend) VPN pakket (zoals OpenVPN of Wireguard. Of al die moderne hippe (SaaS) oplossingen zoals Cloudflare Tunnels, Tailscale, etc).

offtopic:
Je kan altijd Mutual TLS gebruiken zodat de cliënt ook gecontroleerd moet worden ...

En als "TLS" wordt voorzien door een publieke certificate authority (zoals Let's encrypt) ligt de domeinnaam mogelijk ook meteen op straat. Immers dwingt certificate transparency hen om de gegevens van alle gegenereerde certificaten te publiceren. Zie bv https://crt.sh/?q=tweakers.net voor Tweakers (die intussen wel al een flink aantal jaren wildcard certificaten aanvragen waardoor de subdomeinen niet meer onderdeel van het certificaat zijn).

offtopic:
Dat klinkt als "security through obscurity" .. en hoewel ik eerst ook van mening was dat het niet handig was dat alles publiek beschikbaar was, ben ik omgegaan toen ik ging kijken wat er allemaal nodig was om veilig een eigen CA te gaan draaien.

[RobertMe]

duvekot schreef op zaterdag 25 januari 2025 @ 13:55:
[...]

offtopic:
Je kan altijd Mutual TLS gebruiken zodat de cliënt ook gecontroleerd moet worden ...

offtopic:
Dat is uiteraard een optie. Maar lijkt mij zeker niet makkelijker dan een VPN opzetten. Zeker als die VPN ook iets als Cloudflare Tunnels of Tailscale kan zijn. Dat zou toch makkelijker moeten zijn dan zelf een server opzetten. Bij beiden zul je naar mijn idee een account aanmaken, aan beide kanten software installeren, inloggen en klaar. Dan heb je dus niks te doen met certificaten (OpenVPN) of public/private keys en shared secrets (Wireguard). Dat zit allemaal weggestopt in die software.

[...]

offtopic:
Dat klinkt als "security through obscurity" .. en hoewel ik eerst ook van mening was dat het niet handig was dat alles publiek beschikbaar was, ben ik omgegaan toen ik ging kijken wat er allemaal nodig was om veilig een eigen CA te gaan draaien.

offtopic:
Uiteraard is het security through obscurity En redelijk makkelijk op te lossen door een wildcard aan te vragen. Dan zijn de specifieke subdomeinen niet bekend
En v.w.b. het opzetten van een eigen CA: step-ca server. Ondersteund zelfs ACME. Dus als je certbot draait of welke andere ACME compatible client dan ook kun je die zijn certificaten laten opvragen bij je eigen step-ca server.
Note: ik draai het zelf ook (nog?) niet. LE met wildcard + uberhaupt VPN nodig vind ik wel even voldoende. Maar het staat wel op mijn radar om wellicht ooit op te zetten.

[Snow_King]

RobertMe schreef op zaterdag 25 januari 2025 @ 13:43:
[...]

Gaat redelijk offtopic. Maar dan moet je er wel op vertrouwen dat die software ook veilig is en geen lekken bevat. TLS beveiligd immers alleen tegen een MITM aanval. Als bv een login formulier hartstikke lek is dan kan een kwaadwillende zo binnen komen, of als er ergens anders een authentication bypass of wat dan ook is (of je gewoon zwakke credentials gebruikt uiteraard). En gezien Nextcloud en Home Assistant en Plex en ... en ... en ... niet "beveiliging" als enige feature hebben is de kans dat daar een fout in zit een stuk groter dan dat een fout zit in een (bekend) VPN pakket (zoals OpenVPN of Wireguard. Of al die moderne hippe (SaaS) oplossingen zoals Cloudflare Tunnels, Tailscale, etc).

En als "TLS" wordt voorzien door een publieke certificate authority (zoals Let's encrypt) ligt de domeinnaam mogelijk ook meteen op straat. Immers dwingt certificate transparency hen om de gegevens van alle gegenereerde certificaten te publiceren. Zie bv https://crt.sh/?q=tweakers.net voor Tweakers (die intussen wel al een flink aantal jaren wildcard certificaten aanvragen waardoor de subdomeinen niet meer onderdeel van het certificaat zijn).

Laten we het ontopic houden en wat mijn punt vooral is: Met IPv6 kan het internet weer echt peer-to-peer worden! Je kan gewoon direct diensten bereiken die je thuis hebt draaien achter je verbinding. Zeker met 1Gb/s glasvezel kan dat perfect.

Uiteraard kan je met een firewall bepalen wie er wel en niet bij kan, maar je kan gewoon poort 22, 80, 443, etc gebruiken en hoeft niet te klungelen met verschillende poortnummers e.d.

Dat is de vrijheid en mogelijkheden die IPv6 brengen en dat is echt ideaal.

[Roetzen]

fagao schreef op zaterdag 25 januari 2025 @ 08:54:
[...]

Klopt, ik doe werk voor AS15435

Aha. Ik heb een globalping probe draaien op AS15435.

Het hele idee van IPv6 is dat je geen port forwarding meer hoeft te doen. Als je in IPv4 blijft denken wordt het nooit wat met de transitie.

Precies! Wat dat betreft vind ik het jammer dat Delta naar mijn niet zo bescheiden mening eigenlijk een kans gemist geeft. Ze hadden de nieuw uit te rollen glasvezelnetwerken vanaf het begin kunnen inrichten als IPv6 only met IPv4 As a Service...

[Roetzen]

RobertMe schreef op zaterdag 25 januari 2025 @ 09:03:
[...]

Uiteraard uiteindelijk minder relevant als alles IPv6 ondersteund, dan kun je prima altijd en overal gewoon via IPv6 binnen komen. Maar die tijd is nog niet aangebroken.

Nog niet en het zal ook nog wel een tijdje duren. Maar experimenteren met IPv6 only is best zinvol. Als was het maar om on voor te bereiden op de tijd dat die tijd aanbreekt. En het voortouw nemen kan ook wel eens leuk zijn.

Niet alle ISPs ondersteunen IPv6 (hallo Odido, bv), laat staan alle mobiele operators (hallo Odido, en ik meen Vodafone ook niet).

Misschien moeten we dan ook eens een keer zeggen: "Jammer dan". IPv6 Day ligt al weer meer dan een decennium achter ons en de provider die nu nog een IPv4 only netwerk exploiteert moet dan de blaren maar eens gaan voelen.... Of beter de klanten daarvan moeten het maar eens gaan voelen als ze door de keuze van een IPv4 only provider de IPv6 only servers niet kunnen bereiken...

Dus als je thuis poorten open wilt zetten blijf je afhankelijk van IPv4, met ook een publiek adres op de eigen/lokale router en geen CGNAT / NAT64 bij de ISP.

Het hangt er maar van af wat je wilt. Als je servers draait en die toegankelijk wilt maken voor Jan en Alleman, dan is het misschien te vroeg om af te zien van inkomend IPv4. Als het alleen voor jezelf of voor een bepekt groepje is, dan zou alleen IPv6 genoeg kunnen zijn. En als er op de camping nog geen IPv6 is, en die kans is helaas behoorlijk groot, dan is er altijd nog feste-ip.net om je eigen netwerk via IPv4 te bereiken.

[Roetzen]

fagao schreef op vrijdag 24 januari 2025 @ 07:55:
[...]

De NAT64 die mijn router nu doet zou idealiter bij de ISP in het netwerk draaien. Ik ga serieus overwegen dit eens in het lab van eenISP te testen. Ik zie 464Xlat toch wel al eens van de beste transitie technieken.

Ik zie NAT64/DNS64 ook als een goede transitietechniek en als je het voor elkaar krijgt het bij een ISP te laten draaien waar ik ook toegang toe heb wil ik met genoegen helpen om het te testen.

[Plofkotje]

fagao schreef op zaterdag 25 januari 2025 @ 08:54:
[...]

Klopt, ik doe werk voor AS15435
Het hele idee van IPv6 is dat je geen port forwarding meer hoeft te doen. Als je in IPv4 blijft denken wordt het nooit wat met de transitie. Het voordeel van Ipv6 is dat je thuis gewoon 10 webservers kan draaien die allemaal een eigen adres hebben en port 443 kunnen gebruiken

Ziggo had dit zo draaien in hun former UPC gebieden, IPv6 only naar de klant, translator op het kabelmodem, verkeer tussen het modem en het oude UPC netwerk was voor de rest 100% IPv6, IPv4 ging via de translator in het modem die gewoon DHCPv4 uitdeelde aan clients.

Ik heb echt geen idee waarom Ziggo hiermee gestopt is en gewoon weer volledig dual-stack is gaan draaien, dit werkte echt prima.

[Roetzen]

Plofkotje schreef op zondag 26 januari 2025 @ 17:54:
[...]

Ziggo had dit zo draaien in hun former UPC gebieden, IPv6 only naar de klant, translator op het kabelmodem, verkeer tussen het modem en het oude UPC netwerk was voor de rest 100% IPv6, IPv4 ging via de translator in het modem die gewoon DHCPv4 uitdeelde aan clients.

Dat was geen NAT64/DNA64 maar DS-lite. Daarbij is de verbinding tussen de client en de ISP IPv6 en het IPv4 verkeer wordt via een 4in6 tunnel daar over geleid.

Ik heb echt geen idee waarom Ziggo hiermee gestopt is en gewoon weer volledig dual-stack is gaan draaien, dit werkte echt prima.

Bij DS-Lite heb je geen publiek IPv4 adres, net als bij CGNAT, dus je had kennelijk geen servers draaien anders was je wel tegen dat probleem aan gelopen. Maar de reden dat ze met DS-Lite gestopt zijn is dat ze met DS-Lite om een of andere reden niet konden voldoen aan de door de wet gestelde eis dat klanten een eigen modem/router moeten kunnen aansluiten. Althans dat is wat ik er van begrepen heb.

[jk-5]

Roetzen schreef op zondag 26 januari 2025 @ 18:15:
[...]

Dat was geen NAT64/DNA64 maar DS-lite. Daarbij is de verbinding tussen de client en de ISP IPv6 en het IPv4 verkeer wordt via een 4in6 tunnel daar over geleid.

[...]

Bij DS-Lite heb je geen publiek IPv4 adres, net als bij CGNAT, dus je had kennelijk geen servers draaien anders was je wel tegen dat probleem aan gelopen. Maar de reden dat ze met DS-Lite gestopt zijn is dat ze met DS-Lite om een of andere reden niet konden voldoen aan de door de wet gestelde eis dat klanten een eigen modem/router moeten kunnen aansluiten. Althans dat is wat ik er van begrepen heb.

Dat terwijl het prima mogelijk was om die tunnel op je eigen router te terminaten en zelf het DS-Lite deel te doen. Het adres van de AFTR (uit mijn hoofd aftr2.upc.nl) was zichtbaar in de router en kon je instellen als de andere kant van de 4in6 tunnel. En in de RFC voor DS-Lite staat 192.0.0.0/29 als inner IP range in de tunnel, waarvan je zelf dus de .2 instelt en de .1 je default gateway wordt voor ipv4. Het enige wat dan een probleem zou zijn in mijn ogen is de discovery van de aftr host. Maar ik kan me moeilijk voorstellen dat daar geen DHCPv6 optie voor bestaat

[Roetzen]

jk-5 schreef op maandag 27 januari 2025 @ 08:16:
[...]

Dat terwijl het prima mogelijk was om die tunnel op je eigen router te terminaten en zelf het DS-Lite deel te doen.

Dat lijkt me ook niet zo'n probleem. Uiteraard moet de klant dan wel een router gebruiken die dat ondersteunt maar dat moet voor de Tweaker die een eigen router wil geen hoge drempel zijn lijkt me.

Er schiet me nog iets te binnen. Er was ook iets met bridge mode. Ziggo heeft zich destijds met hand en tand verzet tegen het toestaan van eigen modems. Jarenlang met succes. Ziggo probeerde De definitie van het toegangspunt zo te laten uitvallen dat het niet bij het AOP zou uitkomen maar bij een ethernet poort op het modem. Dan zou ze aan de wettelijke verplichting kunnen voldoen door hun modem in bridge mode te zetten waar de klant dan een eigen router op kon aansluiten en het deel er vóór hield Ziggo dan in eigen hand. Maar Ziggo kon eerst geen IPv6 bieden in bridge mode. Ook daar leek DS-Lite een probleem. Waarom heb ik ook niet begrepen maar toen DS-Lite werd verlaten kon IPv6 toch in bridge mode. Ik weet niet of er een oorzakelijk verband was of een toevallige samenloop van omstandigheden. Het zou ook kunnen dat het probleem van de krapte aan IPv4 minder impact had op Ziggo dan verwacht en dat ze het uiteindelijk makkelijker vonden het hele netwerk op dezelfde manier in te richten en daarbij dan kozen voor Full Dual Stack.

Ziggo moest uiteindelijk toch eigen modems toelaten en toen die kogel na vele jaren strijd uiteindelijk door de kerk was heeft Ziggo ook loyaal meegewerkt. Het aantal klanten met een eigen modem is naar verluid "een paar duizend".

Edit: Alles Full Dual stack is als korte termijn oplossing wel handig voor de klant en ook wel voor Ziggo zelf, maar misschien was afschaffen van DS-Lite toch een gemiste kans voor de langere termijn. DS-Lite heeft als voordeel voor de ISP dat grote delen van het netwerk IPv6 only zijn en voor dat deel er dus ook maar voor één stack resources nodig zijn en onderhoud hoeft te worden gepleegd. Alleen op de grenzen van het netwerk is IPv4 nog aanwezig en naarmate het IPv4 verkeert afneemt zullen daarvoor steeds minder resources nodig zijn. Gunstig op langere termijn en de uiteindelijke transitie naar IPv6 only zal geruislozer en soepeler verlopen.

Edit2: Maar NAT64/DNS64 is misschien nog beter.

[ Voor 17% gewijzigd door Roetzen op 27-01-2025 16:28 ]

[alm]

Vanwege het feit dat 464XLAT/NAT64/DNS64 DNSSEC stuk maakt is een groot nadeel in vergelijking met DS-Lite.

[valkenier]

DS-Lite een gemiste kans? Alsjeblieft zeg, wat een drama. Het is niet voor niks uitgefaseerd. Een hoop gezeik met je eigen systeem niet konden bereiken vanaf een IPv4 only netwerk. IP blokkades obv het adres van de aftr. Ik bedank even voor deze “gemiste kans”.

[Roetzen]

@valkenier
Voor wie persé zijn servers op een IPv6 only of DS-Lite systeem vanaf een IPv4 only systeem bereikbaar wil maken is er altijd nog Feste-IP.net.
Maar ja uiteindelijk moeten we toch van IPv4 af want twee systemen naast elkaar onderhouden is onnodig duur en gecompliceerd. Uiteindelijk is iedereen beter af als we IPv4 laten vallen en het hele internet IPv6 only is. Probleem is dat niemand de eerste wil zijn om IPv4 uit te zetten.

Maar ja, uiteindelijk moet het toch en met andere dingen doen we het wel. Niemand klaagt er nog over dat de telex verdwenen is en dat je geen telegrammen meer kunt sturen. Ik ben zelf al op diverse manieren aan het experimenteren met IPv6 only IPv4 bereikbaarheid is voor mij niet heilig meer en het moment komt steeds dichterbij dat ik ga zeggen: Als jij mij niet meer kunt bereiken met je IPv4 only systeem is het jammer dan.

[Roetzen]

@alm
Is dat echt een probleem? De mobiele providers die IPv6 aanbieden gebruiken NAT64/DNS64 voor IP4. Ik hoor niet dat dat problemen geeft.

[alm]

@Roetzen
Dat veel mensen het niet opmerken wil niet zeggen dat het geen probleem is. Voor wie het wel van belang is, is het wel een probleem. Hangt er ook vanaf wat je achter zo'n verbinding hebt draaien of wat je precies doet vanaf je verbinding. Als ik de keuze heb tussen alleen 464XLAT en DS-Lite dan zou ik eerder voor DS-Lite kiezen omdat het qua techniek veel meer vergelijkbaar is met NAT op een gemiddelde router/firewall.
Voor mij maakt het uit omdat ik me ook zakelijk bezig houd met DNS en DNSSEC en vind het een te groot nadeel dat 464XLAT dat 'stuk' maakt.
Als ik echter kan kiezen voor DS-Full dan kies ik daarvoor, ook omdat ik nog teveel IPv4 diensten moet kunnen gebruiken en het belangrijk vind dat er niet een vreemde op hetzelfde IPv4-adres zit. Ik ben wel voorstander van IPv6, maar zolang er nog teveel IPv4-only is zit wil ik dat graag houden.

[valkenier]

@Roetzen we kennen je missie. Werkelijkheid is dat veel providers IPv6 nog steeds domweg niet aanbieden, wat je daar ook van kan vinden. Zolang dat zo is, is dual stack veel werkbaarder bij providers die het wel aanbieden dan IPv6 only met workarounds als CGNAT en feste Ip. Dat is mijn punt. Maar be my guest, loop ver voor de muziek uit en gooi IPv4 eruit, Maar haal het dan niet stiekem weer binnen met CGNAT en Feste-IP, want dat is toch weer IPv4 omarmen.
Begrijp me goed, ik snap al die weerstand tegen IPv6 doorvoeren ook niet, maar het gaat nu nog niet zonder dual stack.

[Snow_King]

valkenier schreef op woensdag 12 februari 2025 @ 07:10:
@Roetzen we kennen je missie. Werkelijkheid is dat veel providers IPv6 nog steeds domweg niet aanbieden, wat je daar ook kan vinden. Zolang dat zo is, is dual stack veel werkbaarder bij provider die het wel aanbieden dan IPv6 only met workarounds als CGNAT en feste Ip. Dat is mijn punt. Maar be my guest, loop ver voor de muziek uit en gooi IPv4 eruit, Maar haal het dan niet stiekem weer binnen met CGNAT en Feste-IP, want dat is toch weer IPv4 omarmen
Begrijp me goed, ik snap al die weerstand tegen IPv6 doorvoeren ook niet, maar het gaat nu nog niet zonder dual stack.

Eens. Ik zou net zoals @Roetzen graag IPv4 uit zetten, maar het kan gewoon nog niet. Dan maar Dual-Stack.

Zelf bouw ik alles IPv6-only en bereik ik heel veel van mijn servers enkel over IPv6. Vrienden kunnen bij mijn Plex server via IPv6, ideaal! Ze hebben immers allemaal KPN glasvezel of een Ziggo verbinding.

Probleem wat ik vooral vaak zie is dat websites (of apps) nog ergens een hostname/endpoint aanspreken die gaan IPv6 doet en vervolgens gaat de site of app kapot....

[xbeam]

Roetzen schreef op dinsdag 11 februari 2025 @ 22:23:
Als jij mij niet meer kunt bereiken met je IPv4 only systeem is het jammer dan.

Dan ga je van koude kermis thuis komen.
nog steeds is meerderheid van de zakelijke markt ipv4 only

Voor jouw alleen gaan we als providers en beheerders echt niet dubbel boekhouden

[Roetzen]

valkenier schreef op woensdag 12 februari 2025 @ 07:10:
@Roetzen we kennen je missie. Werkelijkheid is dat veel providers IPv6 nog steeds domweg niet aanbieden, wat je daar ook van kan vinden.

Ik vind er uiteraard wel wat van, maar dat hoef ik niet te herhalen want ook dat is inmiddels wel bekend. Er zijn inderdaad helaas nog steeds providers die geen IPv6 aanbieden, maar belangrijker is op hoeveel aansluitingen IPv6 beschikbaar is. En aangezien de meeste grote en middelgrote providers het inmiddels wel leveren is op de meerderheid van de aansluitingen nu wel IPv6 beschikbaar. Het zijn niet meer de providers maar het is het bedrijfsleven dat achter loopt.

Zolang dat zo is, is dual stack veel werkbaarder bij providers die het wel aanbieden dan IPv6 only met workarounds als CGNAT en feste Ip. Dat is mijn punt.

Jawel, maar het probleem, of in elk geval één van de problemen met Full Dual Stack is dat er niet genoeg IPv4 adressen zijn om iedereen in de wereld van een uniek globaal routeerbaar IPv4 adres te voorzien. Dus het blijft hoe dan ook behelpen met IPv4 en de enige manier om van die workarounds af te komen is afscheid te nemen van IPv4.

Maar be my guest, loop ver voor de muziek uit en gooi IPv4 eruit, Maar haal het dan niet stiekem weer binnen met CGNAT en Feste-IP, want dat is toch weer IPv4 omarmen.

Ik bereid me voor op alle scenarios. Alle vele jaren. Ik heb weliswaar - enigszins tegen mijn verwachtingen in moet ik bekennen - nog steeds een volwaardig IPv4 adres maar dat kan veranderen. Dus ik experimenteer met gesimuleerde omgevingen met IPv6 only al dan niet met DNS64/NAT64 en met DS-Lite.

Begrijp me goed, ik snap al die weerstand tegen IPv6 doorvoeren ook niet, maar het gaat nu nog niet zonder dual stack.

Ik ben de pensioengerechtigde leeftijd ruim gepasseerd. Ouderdom komt met gebreken maar het zet me wel in de comfortabele positie dat ik mijn servers alleen nog voor de hobby inzet. Ik hoef geen rekening meer te houden met commerciële belangen en ik kan inderdaad zeggen: "Als je met je IPv4 only omgeving mijn servers niet meer kan bereiken, dan is het jammer dan. Niet mijn probleem". Maar ik begrijp ook best dat dat voor vele anderen nog een brug te ver is.

[Roetzen]

Snow_King schreef op woensdag 12 februari 2025 @ 07:53:
[...]

Eens. Ik zou net zoals @Roetzen graag IPv4 uit zetten, maar het kan gewoon nog niet. Dan maar Dual-Stack.

Zelf bouw ik alles IPv6-only en bereik ik heel veel van mijn servers enkel over IPv6. Vrienden kunnen bij mijn Plex server via IPv6, ideaal! Ze hebben immers allemaal KPN glasvezel of een Ziggo verbinding.

Precies. De meeste consumenten - althans in Nederland - hebben al lang IPv6. Odido is eigenlijk de enige (middel)grote provider die nog achter blijft.

Probleem wat ik vooral vaak zie is dat websites (of apps) nog ergens een hostname/endpoint aanspreken die gaan IPv6 doet en vervolgens gaat de site of app kapot....

Dat is inderdaad irritant. Soms wil een mailtje naar de webmaster wel eens helpen. Het is niet altijd onwil maar soms is het gewoon over het hoofd gezien.

[Roetzen]

xbeam schreef op woensdag 12 februari 2025 @ 13:17:
[...]

Dan ga je van koude kermis thuis komen.
nog steeds is meerderheid van de zakelijke markt ipv4 only

Met die koude kermis zal het voor mij wel meevallen. Zoals gezegd, ik verkeer in de comfortabele positie dat ik geen rekening meer hoef te houden met commerciële belangen. Ik kan me permitteren dat deel van de zakelijke markt dat nog geen IPv6 doet te negeren. Aanbod genoeg...

Voor jouw alleen gaan we als providers en beheerders echt niet dubbel boekhouden

"We?" "Dubbel boekhouden?" O, ja, Dual Stack is inderdaad een vorm van "dubbel boekhouden". Voor mij hoef je het niet te doen hoor. Ik heb keus genoeg. Maar hoe langer je IPv6 voor je uitschuift hoe duurder en lastiger het gaat worden. Ook dat is niet mijn probleem.

[Snow_King]

xbeam schreef op woensdag 12 februari 2025 @ 13:17:
[...]


Dan ga je van koude kermis thuis komen.
nog steeds is meerderheid van de zakelijke markt ipv4 only

Voor jouw alleen gaan we als providers en beheerders echt niet dubbel boekhouden

@Roetzen schrijft dit ook al, het bedrijfsleven loopt nogal achter.

Zo wil ik op 1 van onze kantoren ook IPv6 geactiveerd krijgen. Heel moeilijk verhaal bij die ISP. Ze leveren via KPN glasvezel wholesale en routeren er zelf op. Uiteindelijk moet ik nu zelf een IPv6 /48 blok aanleveren wat ze voor ons gaan announcen.

[Roetzen]

Snow_King schreef op donderdag 13 februari 2025 @ 11:35:
[...]

Uiteindelijk moet ik nu zelf een IPv6 /48 blok aanleveren wat ze voor ons gaan announcen.

Een Provider Independant Range?

[Snow_King]

Roetzen schreef op donderdag 13 februari 2025 @ 11:51:
[...]

Een Provider Independant Block?

Dat zou kunnen, maar we hebben voldoende v6 space. Heb een block uit 1 van onze /29 blokken gepakt en die gaan ze routeren. Maar het was niet makkelijk om bij ze geregeld te krijgen.

Als ik hun AS zie, dan announcen ze ook maar heel weinig IPv6...

[valkenier]

Dat klopt idd, heb net ergens een hagelnieuwe vodafone glasvezel opgeleverd gekregen. No IPv6. Wonderlijk.
Verder doet Vodafone mobile bijvoorbeeld wel CGNAT op IPv4, maar ook geen IPv6 mobiel. Delta is dacht ik ook niet zo scheutig met IPv6.

[Roetzen]

@valkenier Ik wist niet eens dat Vodafone ook glasvezel leverde. Vodafone is toch gekoppeld aan Ziggo? Voor wat mobiel betreft: al zeker tien jaar geeft geen enkele mobiele provider in Nederland nog routeerbaar IPv4 uit. Het is allemaal CGNAT. Er is gewoon niet meer genoeg IPv4 om iedere telefoon of tablet nog een eigen routeerbaar IPv4 adres te geven.

Delta levert voor zo ver ik weet IPv6 op alle coax en glasvezel aansluitingen.

Weet iemand hoe dat zit met Odido “Klik en Klaar”? Is dat ook CGNAT of krijg je daar wel een volwaardig IPv4 adres?

[ Voor 21% gewijzigd door Roetzen op 13-02-2025 15:54 ]

[RobertMe]

valkenier schreef op donderdag 13 februari 2025 @ 15:06:
Delta is dacht ik ook niet zo scheutig met IPv6.

Delta heeft 1 of 2 jaar terug zich zelf in de voet geschoten. Die hadden al lang een beta test lopen met IPv6. Maar op een gegeven moment hadden ze "allemaal" problemen met IPv4 (blokken van overal en nergens gekocht en klanten die "problemen" ervaarde doordat geo-ip databases ze dus in Amerika of zo plaatsten) en heeft toen "snel snel" CGNAT uitgerold. Paar maanden later hebben ze toen wel IPv6 geactiveerd. Denk voor alle klanten, maar onderscheid in coax vs glasvezel zou mogelijk kunnen zijn, weet ik niet.

[valkenier]

@Roetzen Het gaat hier om Vodafone Business. Maar ik wist dat ook niet tot voor kort. Gek genoeg dus helemaal geen IPv6 erbij, itt Ziggo zakelijk.

[Plofkotje]

Roetzen schreef op donderdag 13 februari 2025 @ 15:26:
@valkenier Ik wist niet eens dat Vodafone ook glasvezel leverde. Vodafone is toch gekoppeld aan Ziggo? Voor wat mobiel betreft: al zeker tien jaar geeft geen enkele mobiele provider in Nederland nog routeerbaar IPv4 uit. Het is allemaal CGNAT. Er is gewoon niet meer genoeg IPv4 om iedere telefoon of tablet nog een eigen routeerbaar IPv4 adres te geven.

Delta levert voor zo ver ik weet IPv6 op alle coax en glasvezel aansluitingen.

Weet iemand hoe dat zit met Odido “Klik en Klaar”? Is dat ook CGNAT of krijg je daar wel een volwaardig IPv4 adres?

Odido levert zowel gewoon op mobiele abonnementen als op Klik en Klaar een publiek routeerbaar v4 adres aan elke telefoon. Er zitten wel een zooitje poorten dicht aan de kant van Odido, maar er zit geen NAT tussen.

[alm]

Plofkotje schreef op donderdag 13 februari 2025 @ 17:28:
[...]

Odido levert zowel gewoon op mobiele abonnementen als op Klik en Klaar een publiek routeerbaar v4 adres aan elke telefoon. Er zitten wel een zooitje poorten dicht aan de kant van Odido, maar er zit geen NAT tussen.

Ik heb Odido als mobiele provider en die gebruiken (waar ik woon althans) wel degelijk CGNAT, ik krijg namelijk een 100.92.x.y adres wat in de RFC6598 reeks valt speciaal voor gebruik in CGNAT omgevingen. Als ik via de browser op mijn mobiel het gebruikte IP-adres opvraag krijg ik een publiek adres te zien, maar dat is dus (logisch) een CGNAT-adres. Ze hebben ook geen IPv6 op het mobiele netwerk. E.e.a. is zichtbaar te maken via de Net Analyzer app.

Ik heb ook Odido voor glasvezel gehad en die hebben ook daarop geen IPv6, maar wel een publiek eigen dynamisch IPv4-adres (wijzigt zeer af en toe).

[Dreamvoid]

Plofkotje schreef op donderdag 13 februari 2025 @ 17:28:
Odido levert zowel gewoon op mobiele abonnementen als op Klik en Klaar een publiek routeerbaar v4 adres aan elke telefoon. Er zitten wel een zooitje poorten dicht aan de kant van Odido, maar er zit geen NAT tussen.

Dit klopt niet hoor, telefoons zitten bij Odido gewoon achter CG-NAT.

[ocf81]

Roetzen schreef op dinsdag 11 februari 2025 @ 22:23:
@valkenier
Voor wie persé zijn servers op een IPv6 only of DS-Lite systeem vanaf een IPv4 only systeem bereikbaar wil maken is er altijd nog Feste-IP.net.
Maar ja uiteindelijk moeten we toch van IPv4 af want twee systemen naast elkaar onderhouden is onnodig duur en gecompliceerd. Uiteindelijk is iedereen beter af als we IPv4 laten vallen en het hele internet IPv6 only is. Probleem is dat niemand de eerste wil zijn om IPv4 uit te zetten.

Maar ja, uiteindelijk moet het toch en met andere dingen doen we het wel. Niemand klaagt er nog over dat de telex verdwenen is en dat je geen telegrammen meer kunt sturen. Ik ben zelf al op diverse manieren aan het experimenteren met IPv6 only IPv4 bereikbaarheid is voor mij niet heilig meer en het moment komt steeds dichterbij dat ik ga zeggen: Als jij mij niet meer kunt bereiken met je IPv4 only systeem is het jammer dan.

Een voorbeeld van een halsstarrige weigeraar is bijvoorbeeld Bohemia Interactive, die gewoon net doen alsof IPv4 nooit weg zal gaan. Echt heel vermoeiend. Hoe zou men duidelijk kunnen maken richting dit soort uitgevers en ontwikkelaars dat IPv6 echt wel gewenst is?

[alm]

De noodzaak van IPv6 is er, maar wordt niet vaak gezien zolang er te weinig vraag naar is. Bedrijven kunnen vaak wel een aantal IPv4-adressen krijgen (kopen) van hun ISP en zolang er genoeg klanten zijn met IPv4 maakt men zich geen zorgen, zeker niet als klanten er niet in grote getalen om vragen. Als het geld (omzet) gaat kosten dan komt die noodzaak er wel, maar het duurt lang.

Ik moet toegeven dat we het op mijn werk ook nog niet hebben, krijgen er weinig vraag naar, maar ben wel de theorie weer eens aan het ophalen om dit te kunnen gaan oppakken. Hopelijk krijgen we er genoeg tijd voor dit jaar. Onze ISP ondersteunt het, dus daar ligt het niet aan gelukkig...

[Roetzen]

@ocf81
Ik vrees dat er geen "nette" en effectieve manier is om de bedrijven die doen alsof IPv4 voor de eeuwigheid is te "bekeren". Ze gaan zoals @alm opmerkt waarschijnlijk pas in beweging komen als ze het in de omzet gaan merken. Hier zouden consumenten in theorie invloed kunnen hebben door het op zich machtige wapen van de portemonnee in te zetten. Stemmen met de voeten kan dingen veranderen. Maar als ik in mijn eentje of met een handjevol medestanders webwinkels die alleen via IPv4 bereikbaar zijn ga boycotten zal dat weinig indruk maken en heel de consumentenbond op de barricade krijgen lijkt me ook geen dankbare taak voor iets waarvan de gemiddelde Nederlander geen idee heeft waar het over gaat. "Het werkt toch?" Rest overheidsingrijpen. Maar ook dat heeft met de huidige coalitie weinig kans is mijn inschatting. Helaas...

[alm]

Komt nog bij dat een webwinkel die dienst waarschijnlijk afneemt bij een hostingprovider/webprovider/SaaS-dienst en zelf geen idee heeft van de techniek erachter... Dat de dienst ook bereikbaar moet zijn via IPv6 staat bij de meesten denk ik niet op het eisen-lijstje (simpelweg omdat ze er meestal geen weet van hebben).

[ Voor 8% gewijzigd door alm op 14-02-2025 16:04 ]

[Roetzen]

Wat ook niet helpt is dat bestaande “instituties” die IPv6 promoten er mee gestopt zijn. De IPv6 task force is in 2018 opgeheven. De stichting IPv6 in 2022. Van IPv6 evangelist Iljitsch van Beinum heb ik ook al meer dan twee jaar niets over IPv6 gezien op zijn website. Ook het beleid van de overheid dat webites van overheden via IPv6 bereikbaar moeten zijn lijkt in het slop geraakt. Tja…. 😩

[ocf81]

Met NAT en CGNAT is er eigenlijk zo veel ruimte gemaakt voor het dooremmeren met IPv4 dat voor IPv6 eigenlijk een toepassing die IPv6 écht noodzakelijk maakt ontbreekt. Wat is nu de killer app van IPv6?

[RobertMe]

ocf81 schreef op zaterdag 15 februari 2025 @ 19:55:
Met NAT en CGNAT is er eigenlijk zo veel ruimte gemaakt voor het dooremmeren met IPv4 dat voor IPv6 eigenlijk een toepassing die IPv6 écht noodzakelijk maakt ontbreekt. Wat is nu de killer app van IPv6?

Thuis hosten, op meerdere systemen. En dan publiekelijk dus. Selfhosted services voor eigen gebruik kunnen / horen natuurlijk via een VPN te gaan.

Zeker als je glasvezel hebt dus waarbij 1Gbit/s symmetrisch goed te doen is (en als je all in wilt gaan je tot 8Gbit/s kunt krijgen bij Delta). Waarom zou je dan nog een VPS nemen zeg maar.

[alm]

We zijn zo gewend aan IPv4 dat we de nadelen niet meer zo zien, maar het grote voordeel van IPv6 is natuurlijk dat elke device op de wereld een eigen uniek adres kan krijgen (sterker nog, het zijn meerdere adressen) en deze dus bereikbaar gemaakt kan worden zonder trucs als NAT. Inhoudelijk is IPv6 echt wel beter ontworpen, vaste pakketlengtes bijvoorbeeld, terwijl IPv4 verschillende pakketlengtes heeft wat dus lastiger te verwerken is dan IPv6. IPv6 is daardoor sneller om te verwerken door computers en netwerkapparatuur. Dat zou je dan vooral merken op apparatuur die veel netwerkverkeer verwerkt.

[ocf81]

RobertMe schreef op zaterdag 15 februari 2025 @ 20:19:
[...]

Thuis hosten, op meerdere systemen. En dan publiekelijk dus. Selfhosted services voor eigen gebruik kunnen / horen natuurlijk via een VPN te gaan.

Zeker als je glasvezel hebt dus waarbij 1Gbit/s symmetrisch goed te doen is (en als je all in wilt gaan je tot 8Gbit/s kunt krijgen bij Delta). Waarom zou je dan nog een VPS nemen zeg maar.

Een killer app is een marktterm die wel een bepaalde betekenis heeft. Het gaat dan om een toepassing van een techniek of product welke echt niet zonder de innovatie kan en welke de acceptatie van zo'n techniek een stuk vooruit brengt. De iPhone was de "killer app" die 3G op de markt zette. Het WWW was de killer app die het internet in al onze huizen heeft gebracht. Gaming was de killer app die er voor heeft gezorgd dat er in al onze huizen een computer staat. (waarbij ik het begrip computer even heel breed interpreteer)
Zit er in thuishosting genoeg geld om IPv6 de flinke versnelling te geven die het nodig heeft? Kan je dat echt als een killer app zien?

[ Voor 7% gewijzigd door ocf81 op 16-02-2025 12:38 ]

[Tom Paris]

RobertMe schreef op zaterdag 15 februari 2025 @ 20:19:
[...]

Thuis hosten, op meerdere systemen. En dan publiekelijk dus. Selfhosted services voor eigen gebruik kunnen / horen natuurlijk via een VPN te gaan.

Zeker als je glasvezel hebt dus waarbij 1Gbit/s symmetrisch goed te doen is (en als je all in wilt gaan je tot 8Gbit/s kunt krijgen bij Delta). Waarom zou je dan nog een VPS nemen zeg maar.

Wat wil je thuis hosten dan? Wat de gemiddelde persoon in huis heeft is misschien een NAS en een Eufy-achtig systeem voor camera's en de deurbel. Al die fabrikanten hebben trucs bedacht om mét NAT en zónder port forwarding die devices toch 'buitenshuis' benaderbaar te maken. Zelf hosten is zo'n kleine groep gebruikers, die ook nog technisch prima onderlegd zijn om met of zonder IPv6 te hosten.

[DVX73]

Tom Paris schreef op zondag 16 februari 2025 @ 12:59:
[...]


Wat wil je thuis hosten dan? Wat de gemiddelde persoon in huis heeft is misschien een NAS en een Eufy-achtig systeem voor camera's en de deurbel. Al die fabrikanten hebben trucs bedacht om mét NAT en zónder port forwarding die devices toch 'buitenshuis' benaderbaar te maken. Zelf hosten is zo'n kleine groep gebruikers, die ook nog technisch prima onderlegd zijn om met of zonder IPv6 te hosten.

De oplossing is veelal gebruik maken van de servers van de leverancier. Dit brengt ook weer nadelen met zich mee.

[ed1703]

ocf81 schreef op zondag 16 februari 2025 @ 12:35:
[...]
Zit er in thuishosting genoeg geld om IPv6 de flinke versnelling te geven die het nodig heeft? Kan je dat echt als een killer app zien?

Nee, dan zouden de webshops om dit mogelijk te maken als paddenstoelen op het web oppoppen. Thuishosting is een niche-markt en heeft ook weinig met Ipv6 van doen want men had dit ook al werkend gemaakt via een proxy. Dat dit makkelijker is met v6 is een leuke bijkomstigheid, maar opnieuw vooral vanuit tweakers-ogen gezien en niet voor tientallen procenten van een markt. Welke markt eigenlijk?

[ Voor 16% gewijzigd door ed1703 op 16-02-2025 14:39 ]

[Roetzen]

Ik heb ook niet direct een korte termijn verdienmodel voor IPv6. Maar wel voor de lange termijn. Twee protocollen naast elkaar in de lucht houden is gecompliceerder, foutgevoeliger en duurder dan één. Het is dus zinvol op termijn naar één protocol te gaan: IPv6. Iedere dag dat er twee protocollen naast elkaar in de lucht worden is een dag verspilde moeite.

[Tom Paris]

DVX73 schreef op zondag 16 februari 2025 @ 13:55:
[...]


De oplossing is veelal gebruik maken van de servers van de leverancier. Dit brengt ook weer nadelen met zich mee.

Absoluut, en een deel van het 'Tweaker-publiek' zal die diensten dan ook mijden. Maar voor de meerderheid van de niet-technisch aangelegen mensen is het ideaal. Ik zie bijvoorbeeld liever iemand via Synology Connect zijn NAS 'open' zetten, dan een port-forward maken zonder de risico's daarvan te snappen. Die gebruiker heeft dus geen duidelijke use-case voor IPv6.

[Snow_King]

Roetzen schreef op zondag 16 februari 2025 @ 16:19:
Ik heb ook niet direct een korte termijn verdienmodel voor IPv6. Maar wel voor de lange termijn. Twee protocollen naast elkaar in de lucht houden is gecompliceerder, foutgevoeliger en duurder dan één. Het is dus zinvol op termijn naar één protocol te gaan: IPv6. Iedere dag dat er twee protocollen naast elkaar in de lucht worden is een dag verspilde moeite.

De killerapp gaat zijn:

- Google zegt dat je website een hogere ranking krijgt als deze 100% via IPv6 bereikbaar is
- YouTube (ook Google) kondigt aan dat vanaf 202X hun diensten enkel nog over IPv6 bereikbaar zijn
- Een grote 18+ website biedt hun betaalde content gratis aan voor een jaar over IPv6
- Overheden gaan keiharde verplichtingen stellen

1 van de bovenstaande of een combinatie van. Uit de techniek gaat het niet komen.

[ed1703]

Snow_King schreef op zondag 16 februari 2025 @ 19:25:
[...]

De killerapp gaat zijn:

- Google zegt dat je website een hogere ranking krijgt als deze 100% via IPv6 bereikbaar is
- YouTube (ook Google) kondigt aan dat vanaf 202X hun diensten enkel nog over IPv6 bereikbaar zijn
- Een grote 18+ website biedt hun betaalde content gratis aan voor een jaar over IPv6
- Overheden gaan keiharde verplichtingen stellen

1 van de bovenstaande of een combinatie van. Uit de techniek gaat het niet komen.

Google gaat natuurlijk niet inleveren op haar eigen inkomsten om IPv6 aan de man te brengen. Want dat is wat je nu zegt.

[RobertMe]

ed1703 schreef op zondag 16 februari 2025 @ 20:04:
[...]

Google gaat natuurlijk niet inleveren op haar eigen inkomsten om IPv6 aan de man te brengen. Want dat is wat je nu zegt.

Uiteindelijk wordt het natuurlijk een kosten/baten afweging. En er zal vast een moment komen dat bedrijven van IPv4 afstappen omdat het "te duur" wordt om te onderhouden, of voor een nieuw bedrijf "onbetaalbaar" om te kopen.

In zoverre niet zoveel anders dan bv Google die de ondersteuning voor IE6 / IE11 etc stopt omdat het te duur is om die ondersteuning te behouden terwijl er te weinig gebruikers zijn.

Maar zolang er nog (vele) providers zijn die geen IPv6 doen is het afstappen van IPv4 natuurlijk "lastig". Maar er zal vast een moment komen dat op z'n minst diegene die denken dat ze zonder IPv6 kunnen gedwongen moeten overstappen (als in: gewoon internetgebruikers die ooit IPv6 uit hebben gezet omdat <...> en het vervolgens nooit meer hebben aan gezet).

[ed1703]

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

Uiteindelijk wordt het natuurlijk een kosten/baten afweging. En er zal vast een moment komen dat bedrijven van IPv4 afstappen omdat het "te duur" wordt om te onderhouden, of voor een nieuw bedrijf "onbetaalbaar" om te kopen.

Natuurlijk, maar niet binnen nu en 5 jaar. Dat is veel te kort voor zo'n transitie en kosten voor IPv4? Ik denk dat je het groter voordoet qua kosten dan wat het voor Google op dit moment in laadje brengt. Dat zal niet eerder gebeuren dan IPv6 op minimaal 80-90% global dekking zit.
Met rijksoverheid en gemeentelijke instanties kan je wel schrijven dat IPv6 verplicht is om uit te rollen, maar als daar helemaal geen toetsing en naleving op zit heeft dat ook weinig nut. Leuk dat je het "verplicht" stelt maar zorg dan ook dat zo'n instantie uit DigiD (om maar iets te noemen) gaat als ze hun afspraken niet nakomen.

Het vergelijk met IE6/11 gaat natuurlijk ook mank, want dat was een kwestie van een andere browser installeren c.q. upgraden. Een klant van een ISP kan niet upgraden naar IPv6, hij kan slechts overstappen op een ISP die dat wel heeft.

Ik zie niet 'even' alle klanten van Odido overstappen op een KPN / Ziggo die wel IPv6 doet. Dan kom je in hele andere vervelende situaties terecht dat een KPN en Ziggo zo'n stroom aan nieuwe klanten waarschijnlijk helemaal niet aan kan.

[ Voor 27% gewijzigd door ed1703 op 16-02-2025 20:53 ]

[RobertMe]

ed1703 schreef op zondag 16 februari 2025 @ 20:38:
[...]

Natuurlijk, maar niet binnen nu en 5 jaar. Dat is veel te kort voor zo'n transitie en kosten voor IPv4? Ik denk dat je het groter voordoet qua kosten dan wat het voor Google op dit moment in laadje brengt. Dat zal niet eerder gebeuren dan IPv6 op minimaal 80-90% global dekking zit.

Naast kostenbesparing zijn er wellicht ook nog leuke inkomsten aan te koppelen? Als je er vroeg genoeg vanaf stapt is er vast nog wel een looser die voor veel geld je IPv4 adressen wilt kopen omdat zij ze nog nodig hebben. Odido bv . hetzelfde als dat Delta 1 of 2 jaar terug "van heinde en verre" IPs heeft gekocht, en uiteindelijk op CGNAT is overgestapt.

En specifiek een Google zou natuurlijk ook al veel vroeger kunnen afschalen. Loadbalancers die nog IPv4 doen en de volledige achterkant op IPv6 draaien. Scheelt natuurlijk ook behoorlijk op het aantal benodigde IPv4 adressen. Als... Google niet al IPv6 only draait aan de achterkant. Meen wel al eens zoiets gelezen te hebben, misschien niet specifiek Google, maar dan wel "achterkant IPv6 only" en "voorkant" (loadbalancers / reverse proxies) dual stack.

Edit op gemiste edit:

ed1703 schreef op zondag 16 februari 2025 @ 20:38:
Het vergelijk met IE6/11 gaat natuurlijk ook mank, want dat was een kwestie van een andere browser installeren c.q. upgraden. Een klant van een ISP kan niet upgraden naar IPv6, hij kan slechts overstappen op een ISP die dat wel heeft.

Ik denk dat er in die tijd al geen keuze meer was? Met IE6 kon je niet overstappen op een andere browser omdat je dan een antiek OS had waar geen andere browser op kon? Met IE11 kon het misschien wel, weet ik niet meer. En ik doelde ook meer op het scenario v.w.b. klanten die willens en wetens IPv6 uit zetten, of een eigen router hebben en IPv6 nooit configureren.

Ik zie niet 'even' alle klanten van Odido overstappen op een KPN / Ziggo die wel IPv6 doet. Dan kom je in hele andere vervelende situaties terecht dat een KPN en Ziggo zo'n stroom aan nieuwe klanten waarschijnlijk helemaal niet aan kan.

Vroeger was Odido ook een kleinere speler dus het aantal klanten zal voor KPN/Ziggo geen probleem zijn lijkt mij zo. En daarnaast zijn er nu veel meer spelers. Naast het grotere Delta ook nog de kleinere Freedom, Glasnet, en nog vele anderen.

[ Voor 33% gewijzigd door RobertMe op 16-02-2025 21:01 ]

[ed1703]

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

En specifiek een Google zou natuurlijk ook al veel vroeger kunnen afschalen. Loadbalancers die nog IPv4 doen en de volledige achterkant op IPv6 draaien. Scheelt natuurlijk ook behoorlijk op het aantal benodigde IPv4 adressen. Als... Google niet al IPv6 only draait aan de achterkant. Meen wel al eens zoiets gelezen te hebben, misschien niet specifiek Google, maar dan wel "achterkant IPv6 only" en "voorkant" (loadbalancers / reverse proxies) dual stack.

Alleen is het sentiment hier vaak dat men het nogal richt op hoe het in NL is geregeld. Er zijn echter teveel landen die nog niet op dat treintje zijn gestapt waardoor het allemaal nogal stokt. Bijvoorbeeld HongKong of Zuid Afrika.

Vroeger was Odido ook een kleinere speler dus het aantal klanten zal voor KPN/Ziggo geen probleem zijn lijkt mij zo. En daarnaast zijn er nu veel meer spelers. Naast het grotere Delta ook nog de kleinere Freedom, Glasnet, en nog vele anderen.

Vroeger ja, dat is een Odido allang niet meer. Maar het balletje ligt ook niet zo zeer bij een Google, eerder bij bv inderdaad een Odido en zelfs complete landen die gewoon weinig visie hebben. Als ik de lijsten van Google mag geloven dan hebben we op dit tempo nog wel even te gaan.

[RobertMe]

ed1703 schreef op zondag 16 februari 2025 @ 21:17:
[...]

Vroeger ja, dat is een Odido allang niet meer.

offtopic:
Ik bedoelde dat al die huidige Odido klanten 5 of 10 jaar terug ook nog bij KPN/Ziggo/... zaten. Dus als die weer terug gaan zal dat lijkt mij zo niet ineens heel problematisch zijn. Het is niet een kleine speler met ineens een flinke influx en daardoor uit zijn voegen barst. In ieder geval bij Ziggo is er een terugloop in het aantal klanten, als er een paar duizend (/tienduizend(en)) terug zouden komen zouden ze dat alleen maar toejuichen. Lijkt mij voor de continuïteit geen probleem. Als een Glasnet of andere kleine speler er ineens tienduizend(en) klanten bij zou krijgen zou dat inderdaad wel een probleem op kunnen leveren. Maar voor KPN & Ziggo lijkt mij dat minder een issue.

[Roetzen]

ed1703 schreef op zondag 16 februari 2025 @ 20:04:
[...]

Google gaat natuurlijk niet inleveren op haar eigen inkomsten om IPv6 aan de man te brengen. Want dat is wat je nu zegt.

Een aantal grote spelers waaronder inderdaad Google hebben een paar jaar geleden al het licht gezien en zijn intern al IPv6 only. Voor hen zou de balans best eens in het voordeel kunnen vallen van gebruikers richting IPv6 te stimuleren.

[ed1703]

RobertMe schreef op zondag 16 februari 2025 @ 21:26:
[...]

offtopic:
Ik bedoelde dat al die huidige Odido klanten 5 of 10 jaar terug ook nog bij KPN/Ziggo/... zaten. Dus als die weer terug gaan zal dat lijkt mij zo niet ineens heel problematisch zijn. Het is niet een kleine speler met ineens een flinke influx en daardoor uit zijn voegen barst. In ieder geval bij Ziggo is er een terugloop in het aantal klanten, als er een paar duizend (/tienduizend(en)) terug zouden komen zouden ze dat alleen maar toejuichen. Lijkt mij voor de continuïteit geen probleem. Als een Glasnet of andere kleine speler er ineens tienduizend(en) klanten bij zou krijgen zou dat inderdaad wel een probleem op kunnen leveren. Maar voor KPN & Ziggo lijkt mij dat minder een issue.

Je hebt het over tussen de 1 miljoen en 1,5 miljoen klanten he..
Als daarvan tussen 50 en 75% in een maand overstapt (nu zal een deel ook nog een jaarcontract hebben, dus het zal minder zijn) dan is dat een enorme logistieke operatie. Dan laat ik de klanten die om wat voor reden dan ook een monteur nodig hebben in het midden. Dat doe je niet 'even'. Men denkt hier alleen in capaciteit van de provider zelf, maar daar zit nog veel meer aan vast. Daar ben je maanden mee bezig.
Overigens zullen het er in werkelijk wel meer zijn, want er zijn meer providers die IPv6 'eng' vinden.

Toen de Next (niet de mini dus) vrij te bestellen was wilden ook duizenden klanten dat ding hebben. Dat zorgde bij Ziggo ook voor flinke leveringsproblemen. Ik heb toen ook dik een maand moeten wachten.

Roetzen schreef op zondag 16 februari 2025 @ 22:49:
[...]

Een aantal grote spelers waaronder inderdaad Google hebben een paar jaar geleden al het licht gezien en zijn intern al IPv6 only. Voor hen zou de balans best eens in het voordeel kunnen vallen van gebruikers richting IPv6 te stimuleren.

Er valt niet zoveel te stimuleren als hele landen niet meedoen op die IPv6-trein.
Dan kan je natuurlijk ala ziggo analoge radio in de ban doen (IPv4) en een ontvanger sturen die digitale radio kan ontvangen (soort vergelijk naar IPv6), maar die mogelijkheid is er niet. Bovendien is Google een bedrijf die dikke winsten moet boeken. Dan kan je niet even 50% van je gebruikers missen.
Niemand trekt de kar, een google, fb of apple gaat dat zeker niet doen. Je zou veel meer moeten doen in de richting van RIPE. De RIR's zouden hierin veel meer verantwoordelijkheid moeten nemen en die macht naar zich toe moeten trekken door ISP's een basisarchitectuur op te leggen.

[ Voor 30% gewijzigd door ed1703 op 17-02-2025 08:10 ]

[Roetzen]

[b]ed1703 schreef op maandag 17 februari 2025 @ 07:48:[/

Er valt niet zoveel te stimuleren als hele landen niet meedoen op die IPv6-trein.

Natuurlijk wel. Om te beginnen kun je je richten op de landen waar IPv6 wel beschikbaar is. Ook daar is best nog veel te stimuleren.

Bovendien is Google een bedrijf die dikke winsten moet boeken. Dan kan je niet even 50% van je gebruikers missen.

Stimuleren!=uitsluiten. Die IPv4 gebruikers kunnen gewoon mee blijven doen. Ze krijgen alleen niet de extraatjes die de IPv6 gebruikers krijgen. Ook zonder bonus kaart kun je bij AH boodschappen doen.

Niemand trekt de kar, een google, fb of apple gaat dat zeker niet doen.

Google en Apple doen best veel en laten zien dat ze allebei een lange termijn strategie voor IPv6 hebben. Ik noemde al dat Google intern IPv6 only is. Apple eist dat alle apps in de App Store kunnen werken in een IPv6 only omgeving.

Je zou veel meer moeten doen in de richting van RIPE. De RIR's zouden hierin veel meer verantwoordelijkheid moeten nemen en die macht naar zich toe moeten trekken door ISP's een basisarchitectuur op te leggen.

Ik denk niet dat RIPE of één van de andere RIRs daarvoor de middelen en het mandaat heeft. Maar misschien zie ik wat over het hoofd.

[ed1703]

Roetzen schreef op maandag 17 februari 2025 @ 17:34:
[...]
Stimuleren!=uitsluiten. Die IPv4 gebruikers kunnen gewoon mee blijven doen. Ze krijgen alleen niet de extraatjes die de IPv6 gebruikers krijgen. Ook zonder bonus kaart kun je bij AH boodschappen doen.

dromen mag altijd hoor..
Ik kan inderdaad boodschappen doen zonder bonus kaart.
Maar uitsluiten is niet boodschappen doen zonder bonus kaart. Wat jij wilt is dat huismerk kaas wel te koop is zonder bonuskaart, maar de Milner is niet voor je te koop. Die deur gaat niet open. De vraag is of zoiets uberhaupt wel mag met alle condities die aan een bonus kaart zitten.

Google en Apple doen best veel en laten zien dat ze allebei een lange termijn strategie voor IPv6 hebben. Ik noemde al dat Google intern IPv6 only is. Apple eist dat alle apps in de App Store kunnen werken in een IPv6 only omgeving.

Ja prachtig, maar wat koop ik hier nu voor als inwoner van Zuid-Afrika op mijn IPv4 verbinding?

Ik denk niet dat RIPE of één van de andere RIRs daarvoor de middelen en het mandaat heeft. Maar misschien zie ik wat over het hoofd.

En een Apple of Google heeft dat dus wel denk je door zaken uit te sluiten?
Ik zie de rechtszaken al komen.. En dat gaat een Apple of Google verliezen.

[ Voor 13% gewijzigd door ed1703 op 17-02-2025 18:42 ]

[RobertMe]

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

Google en Apple doen best veel en laten zien dat ze allebei een lange termijn strategie voor IPv6 hebben. Ik noemde al dat Google intern IPv6 only is. Apple eist dat alle apps in de App Store kunnen werken in een IPv6 only omgeving.

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.

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