Odido is echt raar bezig: IPv4 only
KPN houdt het bij de bodem, waarom iets veranderen (=kosten) als er geen voordeel is.
IPv4 is voldoende (en intern doen ze niet meer…), IPv6 als je dat zo erg moet… kan het
Ziggo ging hier ook raar mee om…, Eerst NIET, rond 2016 - 2020 iets in aanbouw na een paar maanden opnieuw jaar begonnen. en weer, en weer… daarna schoorvoetend als je er op stond… nu kan het geloof ik standaard maar dat volg ik niet meer.
Ik vermoed dat KPN ook de meerwaarde in dat soort dingen niet zit, ik geloof dat XS4ALL ook wereldwijd wat in de melk te brokkelen had op basis van “technical merits” .
noot: ik heb de oplossing weer uitgezet, zodat noot 11 is de juiste link.
Ziggo is willekeur.
Ligt er aan waar je woont.
Voor een paar jaar terug, was ik bij iemand die IPv6 only had.
IPv4 ging via een tunnel.
Je kon een vast IPv4 krijgen, tot het moment dat je een kwartier offline was.
IPv6 moet je tijd, geld en moeite insteken.
Het zal nooit de norm worden, totdat het verplicht wordt.
In Nederland lopen we voorop.
XS4ALL was heel vroeg met IPv6
Wat IP adressen betreft, is dit niet overal gelijk in Europa.
In Duitsland hebben ze nog steeds de verplichte IP wissel iedere nacht.
Met als gevolg, iedere nacht een korte onderbreking.
De IPv6 adoptie is hier inderdaad slecht, zeker bij Ziggo is die echt brak. Als netwerknerd heb ik inderdaad al vroeg met de tunnel van XS4ALL geëxperimenteerd, die tunnel heeft gewerkt tot ik over ging naar Freedom
. Aan de andere kant krijg je van KPN op je mobiel standaard alleen nog IPv6 en geen IPv4 meer.
Een andere leuke talk op de WHY was “The state of IPv6”:
Hij benoemd het niet in het verhaal, maar op het kaartje om NL er inderdaad niet erg best uit.
Ik heb Youfone(kpn) en zover ik zie, is mobiel gewoon dualstack.
Dat youfone gebruik maakt van het mobiele netwerk van KPN betekend nogniet dat ze ook gebruik maken van de internet infra van KPN.
Op mijn eigen mobiel (KPN en de APN internet) geeft IPv6 only en is IPv4 bereikbaar via CLAT/464XLAT:
CLAT/464XLAT wordt niet door KPN gedaan verwacht ik, maar door je eigen hardware. KPN doet waarschijnlijk NAT64 en DNS64. Sommige modem chipsets hebben CLAT/464XLAT ingebouwd. Zonder CLAT/464XLAT ondersteuning (goedkopere Chinese MiFi routers bieden dat bijvoorbeeld niet) zal IPv4 niet beschikbaar zijn, maar merk je daar in de praktijk alleen wat van voor dingen die niet van DNS gebruik maken.
CLAT (het client deel) doet je device inderdaad zelf, op m’n sailfish telefoon zie ik daar netjes een daemon voor draaien die gestart wordt als ik de verbinding maak. Er is echter ook een provider deel (PLAT) wat ze wel moeten faciliteren.
Wat voor maatregelen er zijn genomen voor devices die dat niet ondersteunen weet ik niet, dat is geen situatie die zich bij mij voordoet.
Gelukkig heeft Telekom dat ondertussen afgeschaft. Dat viel als ik mij goed herinner samen met de migratie van telefonie over POTS/ISDN naar VoIP.
De term PLAT kende ik niet, maar ik kwam dit tegen:
To enable CLAT, an IPv6-only node needs to discover the PLAT-side translation IPv6 prefix, also known as the NAT64 prefix (see Section 6.3 of [RFC6877]). The PREF64 Router Advertisement (RA) option ([RFC8781]) provides that information and can be used as a strong indication that the network supports PLAT (NAT64) functionality.
Het gaat dus om NAT64, maar ook die PREF64 RA optie. Doorgaans wordt 64:ff9b:: gebruikt. Mooi dat het in Sailfish goed werkt!
Ik gok dat er in ieder geval synthetische AAAA records worden ingevoegd door de DNS server voor DNS64.
CLAT en PLAT horen bij elkaar en vormen samen 464XLAT. Als gebruiker zie je PLAT alleen niet, CLAT wel. In mijn geval komt er een (virtuele) interface bij waarop m’n telefoon denkt IPv4 connectiviteit te hebben. Dat daar een dubbele NAT achter zit (CLAT en PLAT) heeft ie niet eens door, de default gateway voor IPv4 staat daar naartoe.
Klinkt aannemelijk. Het lastige is alleen dat ze dat voor klanten zonder CLAT wel moeten doen, en voor klanten met CLAT support juist niet, daar moet een query gewoon een IPv4 adres opleveren als dat beschikbaar is.
Het lastige is alleen dat ze dat voor klanten zonder CLAT wel moeten doen, en voor klanten met CLAT support juist niet, daar moet een query gewoon een IPv4 adres opleveren als dat beschikbaar is.
CLAT zal soms niet per verbinding gaan. Het kan zijn dat een router het niet ondersteunt, maar een device erachter zelf weer wel. Mijn gok is dat DNS64 altijd wordt ingezet. Kan je een DNS query doen vanaf die verbinding om te kijken wat je terugkrijgt? Bijvoorbeeld naar ip4.me?
De DNS tools op de telefoon zijn wat beperkt (geen dig of nslookup), dus het enige wat ik doe is ping -4 en ping -6 om te zien naar welk adres iets resolved.
Ik heb gekeken naar community.freedom.nl en de adressen zijn identiek aan die ik terug krijg op m’n desktop (aan de freedom verbinding). ip4.me heb ik ook geprobeerd en daar komt nu 34.160.111.145 uit, de whois daarvan komt bij google uit
. Maar goed dat ik inmiddels al een tijdje IPv6 VPN naar huis opzet
.
Er zijn ook telefoons met WiFi waarbij je een verbinding kan delen. In principe zouden alle apparaten dan een eigen IPv6 adres moeten krijgen als de uplink IPv6 is.
Werkt ping -6 ip4.me? Dan zou ik verwachten dat er een synthetisch AAAA record tevoorschijn komt.
Echt werken doet de ping niet, ik ga geen data naar google sturen (dus ook geen ping), maar het resolved inderdaad wel naar een adres behorend bij 464XLAT, met de prefix 64:ff90:: en dan het IPv4 adres in hex vorm.
Dan heb je inderdaad een NAT64 adres te pakken. Als je apparaat geen IPv4 ondersteunt danwel geen 464XLAT, zal de verbinding vanuit dat oogpunt helemaal over IPv6 lopen.