Het grote IPv6 topic

[Roetzen]

Dreamvoid schreef op vrijdag 19 januari 2024 @ 17:51:
[...]


IPX/SPX was een LAN routing protocol, dus er was niet echt een "internet" dat kon verdwijnen, alleen lokale LAN eilandjes. Maar het werkt wel nog steeds als je wil: https://www.dosbox.com/wiki/Connectivity

IPX/SPX is nog tot en met Windows XP door Microsoft ondersteund.

En er was een manier om IPX/SPX te tunnelen over TCP/IP, dus om zulke eilandjes aan elkaar te knopen. (TCP/IP noemen we nu IPv4).

Maar zolang er 1 persoon IPv4 routeert over IPv6, dan werkt het IPv4 internet nog.

Er zullen ongetwijfeld nog heel lang kleine eilandjes blijven bestaan waar IPv4 wordt bedreven en mogelijk zullen er mensen zijn die een paar van die eilandjes met elkaar verbinden via tunnels. Ik sluit niet uit dat zo iets ook nog bestaat voor IPX/SPX.

Maar dat noem ik niet "het IPv4 internet bestaat nog". Als het niet meer algemeen beschikbaar is en alleen nog op die manier voor een paar nerds, nee, dat is geen IPv4 internet.

Net als met de uitvinding van de auto: natuurlijk, je ziet weinig paarden meer. Maar ze bestaan nog wel. Al dan niet "getunneld" (= in een paardentrailer) over het autonetwerk.

Die vergelijking gaat mank. Of misschien juist niet. Ja, er zijn nog paarden. Maar als transportmiddel heeft het paard afgedaan. Het paard is lading geworden. Als het paard in de paardentrailer gaat, blijft de ruiter niet zitten en/of de kar aangespannen. De ruiter stapt in de auto. Er zijn geen postkoetsen en trekschuiten meer en ook geen stations waar je verse paarden kunt krijgen. Die hele infrastructuur is verdwenen. Paarden zijn er alleen nog voor de lol.(in elk geval in Nederland) En zo zal het IPv4 ook vergaan.

[Roetzen]

ANdrode schreef op vrijdag 19 januari 2024 @ 22:02:
[...]

Als gebruiker is NAT64 met DNS64 of 464XLAT amper te onderscheiden. Toch geven allebei in de praktijk problemen waardoor ik het als ISP niet zou willen uitrollen boven DS-lite of CGNAT.

Toch is NAT64/DNS64 precies hoe de mobiele providers het doen.

[ANdrode]

Roetzen schreef op zaterdag 20 januari 2024 @ 13:00:
[...]
Toch is NAT64/DNS64 precies hoe de mobiele providers het doen.

En dat geeft bij desktop-gebruik problemen . Daarom kan je bij KPN ook kiezen voor een APN waar je een publiek IPv4 adres (geen NAT) krijgt.

Case:

• Werk VPN voor een applicatie op publiek IP adres
• Applicatie buiten primaire werk-domein waardoor DNS niet via VPN gaat
• Happy eyeballs: voorkeur voor NAT64 gateway icm DNS64 boven route via gateway
• Verkeer komt vanaf verkeerde bron, applicatie zegt nee.

Is de applicatie hier verkeerd bezig? Een beetje. Is dit lastig te debuggen? Zeker.

[RobertMe]

Roetzen schreef op zaterdag 20 januari 2024 @ 12:31:
[...]

IPX/SPX aanmerken als een protocol dat alleen door een paar nerds werd gebruikt is te kort door de bocht. IPX/SPX was het protocol dat door Novell werd gebruikt en Novell was toen dè markleider in netwerken. Op elke netwerkkaart van een merk dat mee wilde tellen was een driehoekige rode sticker geplakt met "It works with Novell". Oftewel: ondersteunt IPX/SPX. Bij het bedrijf waar ik toen werkte was ik de eerste die het "rode boek" uit had en dus werd ik gebombardeerd tot systeembeheerder van het netwerk. En daarbij had ik te maken met IPX/SPX. Ik heb geen concrete getallen maar met alle Novell (personal) netwerk gebruikers reduceren tot "een paar nerds" doe je ze geen recht.

Je snap heust wel wat ik bedoel. Dit is grotendeels uit de tijd dat de PC nog niet bestond, en dan bedoel ik dus de personal computer die mensen thuis hadden staan. Ik weet dat "wij" thuis vroeger al een PC met DOS of Windows 3.11(?)/hadden. En dat was vrij zeldzaam en dat was AFAIK een afdankertje uit bedrijfsleven. Internet thuis kreeg je pas met inbellen en wat later DSL / Docsis. En ik kan mij niet indenken dat de protocollen die jij benoemd ooit relevant zijn geweest bij prive gebruik. Dit was allemaal meteen IP based.
En tuurlijk had je daarvoor al andere oplossingen om te netwerken. Maar dat was veelal bedrijfsmatig, of echte enthousiastelingen die dat prive/in huis hadden. Oftewel: early adopters, zowel zakelijk als prive, en bij zakelijk zeer waarschijnlijk omdat het zakelijk vereist was of een voordeel opleverde. Als dan een nieuw protocol om de hoek komt zullen degene die gebruik maakten van deze protocollen een stuk eerder getriggerd zijn om over te stappen.

Kijk je dan nu naar IPv4 vs IPv6 zal het Henk en Ingrid allemaal worst zijn. Die nemen een internet abonnement, steken een kabel in en willen dat het werkt. Die hebben echt geen idee van dat IPv6 beter is en gebruikt zou moeten worden. En als die for whatever reason ooit wel eens een artikeltje (op internet) gevolgd hebben om het een of ander aan IPv4 in te stellen, of dat het handige neefje ooit in een ver verleden een eigen router heeft neer gezet die alleen voor IPv4 is ingesteld zullen zij geen weet hebben van het feit dat ze "achter blijven". Dus totaal niet te vergelijken met de tijd waarin er nog concurrerende netwerken / protocollen waren en internet "the next best thing" was en bedrijven en consumenten op die hype trein sprongen en daadwerkelijk "er mee bezig waren" en up to date bleven.

[nero355]

RobertMe schreef op zaterdag 20 januari 2024 @ 16:45:
Kijk je dan nu naar IPv4 vs IPv6 zal het Henk en Ingrid allemaal worst zijn.
Die nemen een internet abonnement, steken een kabel in en willen dat het werkt.

Die hebben echt geen idee van dat IPv6 beter is en gebruikt zou moeten worden.

En daarom zullen we nog heel lang IPv4 en IPv6 naast elkaar moeten draaien!

Verder heb ik een Novell based netwerk onderhouden en die was toch echt gewoon TCP/IP based en kwam geen IPX/SPX bij kijken dus zelfs die gaste wisten al heel vroeg dat IPX/SPX niet echt bepaald een succes was geworden!

* nero355 zou tegenwoordig nog steeds veel liever GroupWise gebruiken i.p.v. die Microsoft Outlook/Exchange troep als het kon!

[RobertMe]

nero355 schreef op zaterdag 20 januari 2024 @ 19:12:
[...]

En daarom zullen we nog heel lang IPv4 en IPv6 naast elkaar moeten draaien!

That's what I said

En zo zijn er wel meer antieke dingen die ik niet snel zie verdwijnen. Mobiel internet via 2G bv (slimme energiemeters die het gebruiken, en veel meer "connected" apparaten); 2,4GHz wifi (veel te veel IoT spul dat daar op zit); om er eens twee te noemen.

[nero355]

RobertMe schreef op zaterdag 20 januari 2024 @ 19:16:
That's what I said

Vond de reacties van de laatste tijd een hoog "Hash & Rehash" gehalte hebben dus dacht gooi er een streep onder

En zo zijn er wel meer antieke dingen die ik niet snel zie verdwijnen.

Ongetwijfeld

Mobiel internet via 2G bv (slimme energiemeters die het gebruiken, en veel meer "connected" apparaten)

Was het niet zo dat die voor ons ging verdwijnen om zodoende alleen voor die energiemeters over te blijven

2,4GHz wifi (veel te veel IoT spul dat daar op zit)

Dat is echt iets wat dood moet wat mij betreft !!!

Waarom men bij 802.11ax ervoor heeft gekozen om die troep te blijven gebruiken is mij echt een serieus raadsel in de categorie "W-T-F ?!?!"

Maar goed...

Er zijn er ook wel leuke Legacy dingen opzich, maar die bloeden vaak juist WEL dood gek genoeg!

[ed1703]

nero355 schreef op zaterdag 20 januari 2024 @ 19:12:
[...]

En daarom zullen we nog heel lang IPv4 en IPv6 naast elkaar moeten draaien!

Ik krijg sterk de indruk dat de discussie over het uitfaseren van IPv4 en alleen nog IPv6 gebruiken zich hier elke 3 maanden aan het herhalen is. Ik begrijp ook wel dat we de kant van IPv6-only op moeten, maar begin dan maar eens met alle ISP's en hardwareleveranciers (Hallo IoT!!) op deze wereld de neuzen dezelfde kant op te krijgen via regelgeving dat op z'n minst beide ondersteund moet worden.
Ik zie hier vooral posts die zich nogal beperken tot nederlandse ISP's, maar dat is natuurlijk niet genoeg.
Met name RIPE bijvoorbeeld zou hier veel meer een trekkersrol in moeten nemen.

[ Voor 13% gewijzigd door ed1703 op 20-01-2024 21:14 ]

[Roetzen]

ANdrode schreef op zaterdag 20 januari 2024 @ 15:04:
[...]


En dat geeft bij desktop-gebruik problemen . Daarom kan je bij KPN ook kiezen voor een APN waar je een publiek IPv4 adres (geen NAT) krijgt.

Ik ben benieuwd hoe lang ze dat nog gaan blijven aanbieden. Het is in feite een stap terug.

Case:

• Werk VPN voor een applicatie op publiek IP adres
• Applicatie buiten primaire werk-domein waardoor DNS niet via VPN gaat
• Happy eyeballs: voorkeur voor NAT64 gateway icm DNS64 boven route via gateway
• Verkeer komt vanaf verkeerde bron, applicatie zegt nee.

En dat probleem is er niet met DS-Lite waarbij de client een CGNAT adres heeft?

Is de applicatie hier verkeerd bezig? Een beetje. Is dit lastig te debuggen? Zeker.

Ik zou zeggen dat een applicatie die voor de authorisatie gebruik maakt van het IP adres van de bron niet meer van deze tijd is. Met al het gehannes met IP adressen om IPv4 nog in de lucht te houden is dat niet meer werkbaar.

Lastig te debuggen? Ja, vast wel. Voor mij is het alleen nog maar weer een extra argument om zo snel mogelijk te stoppen met IPv4.

[Roetzen]

RobertMe schreef op zaterdag 20 januari 2024 @ 16:45:
[...]

Kijk je dan nu naar IPv4 vs IPv6 zal het Henk en Ingrid allemaal worst zijn. Die nemen een internet abonnement, steken een kabel in en willen dat het werkt

En als het dan niet meer werkt gaan ze terug naar de winkel en dan krijgen ze te horen dat hun PC, TV of smart broodrooster te oud is en dat ze beter een nieuwe kunnen kopen. En dat doen ze dan braaf. Ze zijn immers ook al gewend om elke twee jaar een nieuwe telefoon te moeten kopen. Henk en Ingrid spelen geen rol in deze.

Het probleem ligt eerder bij de Nerds die alles uit de kast halen om legacy spul nog aan de praat te houden en bij de bedrijven waar bij het management een middellange termijn visie ontbreekt.

[Roetzen]

nero355 schreef op zaterdag 20 januari 2024 @ 19:12:
[...]

En daarom zullen we nog heel lang IPv4 en IPv6 naast elkaar moeten draaien!

De grote jongens als Google en facebook draaien hun interne netwerken al lang IPv6 only.

Verder heb ik een Novell based netwerk onderhouden en die was toch echt gewoon TCP/IP based en kwam geen IPX/SPX bij kijken

Dat was dan waarschijnlijk wat later dan waar ik het over heb. Toen ik het betreffende bedrijf medio 1996 verliet draaide het Novell netwerk aldaar nog steeds op IPX/SPX.

dus zelfs die gaste wisten al heel vroeg dat IPX/SPX niet echt bepaald een succes was geworden!

IPX/SPX was wel degelijk een succes, maar succes is nu eenmaal nooit voor de eeuwigheid. IPX/SPX en TCP/IP hadden nog een eeuwigheid als "dual stack" naast elkaar kunnen blijven bestaan. Maar ze kwamen er achter dat het niet handig is twee protocollen naast elkaar tot in de eeuwigheid te laten bestaan. En dus werd IPX/SPX uitgefaseerd. Dat zal ook vast wel wat wrijvingen hier en daar hebben gegeven. Maar het gebeurde wel.

Maar illustreert dat nu niet precies mijn punt? Het is niet handig IPv4 en IPv6 lang naast elkaar te laten bestaan. Het is handiger IPv4 zo snel mogelijk uit te faseren. Ondanks dat dat hier en daar wat wrijvingen geeft.

[ Voor 5% gewijzigd door Roetzen op 21-01-2024 11:49 ]

[Roetzen]

RobertMe schreef op zaterdag 20 januari 2024 @ 19:16:
[...]

En zo zijn er wel meer antieke dingen die ik niet snel zie verdwijnen. Mobiel internet via 2G bv (slimme energiemeters die het gebruiken, en veel meer "connected" apparaten); 2,4GHz wifi (veel te veel IoT spul dat daar op zit); om er eens twee te noemen.

2G? Echt niet.. Met de miljardenbedragen die er betaald moeten worden voor frequentieruimte gaan de providers 2G echt niet nog tien jaar in de lucht houden. Jammer voor die slimme meters, hadden ze maar wat verder vooruit moeten kijken. Maar wat heeft dat met IPv6 te maken?

[Roetzen]

ed1703 schreef op zaterdag 20 januari 2024 @ 21:04:
[...]

Met name RIPE bijvoorbeeld zou hier veel meer een trekkersrol in moeten nemen.

Wat zou RIPE volgens jou dan nog meer moeten/kunnen doen om de transitie naar IPv6 te versnellen?

[ed1703]

Roetzen schreef op zondag 21 januari 2024 @ 11:34:
[...]

Wat zou RIPE volgens jou dan nog meer moeten/kunnen doen om de transitie naar IPv6 te versnellen?

Verbod introduceren op verkoop of koop van IPv4 van andere partijen dan RIPE. Nieuwe leden mogen alleen van RIPE en andere RIR's afnemen met daarbij de verplichting om IPv6 af te nemen en het ook daadwerkelijk te gebruiken. Zoals het nu is, is het veel te vrijblijvend. Dat is geen gangbare weg, er is helemaal geen stip op de horizon. Je hoeft nu namelijk helemaal geen IPv6 af te nemen bij RIPE als je dat niet wilt en gaan shoppen langs diverse bedrijven en ISP's of er nog iemand wat in de verkoop heeft.
Daarin neem je ook toelating mee dat hardwareproducten alleen verkocht mogen worden als ze zowel IPv4 als IPv6 ondersteunen in de firmware/software. Je kan daar dan ook nog de verplichting aan toevoegen dat elke grote website IPv6 moet gebruiken en configureren. Zelfs de grootste webshops van dit land gebruiken geen IPv6.. (BOL, CB)

[ Voor 3% gewijzigd door ed1703 op 21-01-2024 12:48 ]

[nero355]

Roetzen schreef op zondag 21 januari 2024 @ 11:22:
De grote jongens als Google en facebook draaien hun interne netwerken al lang IPv6 only.

Dat is leuk voor hen, maar als er twee bedrijven zijn aan wie ik geen voorbeeld zou willen nemen dan zijn het die twee wel : Pure Evil Corp gewoon!

Roetzen schreef op zondag 21 januari 2024 @ 11:31:
2G? Echt niet...

Echt wel dus !!

Met de miljardenbedragen die er betaald moeten worden voor frequentieruimte gaan de providers 2G echt niet nog tien jaar in de lucht houden.

Jammer voor die slimme meters, hadden ze maar wat verder vooruit moeten kijken.

Voor zover ik weet worden juist alle consumenten van de 2G gekickt om ruimte te maken voor dergelijke toepassingen!

Iets van een maand geleden werd hier in de buurt aan de masten gerommeld en sindsdien word ik "Denied" op het moment dat ik via 2G verbonden wil zijn om zodoende mijn batterij minder te belasten.
Ik baal daar eigenlijk wel van, want als straks ook 3G geen optie meer is dan wordt het gewoon niet meer leuk als je ziet hoe snel je batterij leeg is op 4G/4G+/5G

[ Voor 16% gewijzigd door nero355 op 21-01-2024 15:17 ]

[Roetzen]

ed1703 schreef op zondag 21 januari 2024 @ 12:46:
[...]

Daarin neem je ook toelating mee dat hardwareproducten alleen verkocht mogen worden als ze zowel IPv4 als IPv6 ondersteunen in de firmware/software.

Daar gaat RIPE niet over. Misschien de ACM? Een verplichting om zowel IPv6 als IPv4 te ondersteunen in producten vind ik onnodig en onwenselijk. Als een producent iets wil maken wat alleen IPv6 doet mag ie van mij zijn gang gaan. Een verplichting om ook IPv4 te ondersteunen kan op termijn weer voor vertraging zorgen bij de uitfasering van IPv4. Onwenselijk dus. Overigens ondersteunt bijna alles wat vandaag de dag op de markt komt zo langzamerhand wel IPv6. Maar niet alles. Ik ben nog steeds op zoek naar een vervanger van nijn SPA 112 VOIP adapter die ook IPv6 doet. Nog niet gevonden.

Apple geeft overigens al jaren het goede voorbeeld. Apps voor de app store moeten niet alleen IPv6 ondersteunen, het gaat nog een stapje verder: ze moeten ook kunnen werken in een IPv6 only omgeving. Apple kijkt echt wel vooruit.

Je kan daar dan ook nog de verplichting aan toevoegen dat elke grote website IPv6 moet gebruiken en configureren. Zelfs de grootste webshops van dit land gebruiken geen IPv6.. (BOL, CB)

Je moet wel oppassen dat je geen regels uitvaardigt die niet te handhaven zijn. Maar er mag inderdaad nog wel een tandje bij. Heel veel veelbezochte websites doen inmiddels wel IPv6 maar inderdaad bol.com niet nu.nl ook niet. Gelukkig hebben wij consumenten een ijzersterk middel in handen om invloed uit te oefenen: we kunnen stemmen met de portemonnee. Ik koop niets bij bol.com en de adverteerders bij nu.nl verdienen aan mij ook niets.

[ Voor 11% gewijzigd door Roetzen op 21-01-2024 15:41 ]

[ANdrode]

Roetzen schreef op zondag 21 januari 2024 @ 10:57:
[...]
En dat probleem is er niet met DS-Lite waarbij de client een CGNAT adres heeft?

CGNAT + normale DNS, geen synthetisch DNS64 adres voor een IPv4 only service.

Herinner hierbij hoe happy eyeballs werkt: De eerste poging om te verbinden gaat via IPv6. Daardoor gaat het verkeer niet via de route die je verwacht.

Overigens krijgen getetherde apparaten bij KPN wel een privaat IPv4 adres. Ik weet niet waar de translatie gebeurt maar dat maakt eigenlijk niet uit.

Ik zou zeggen dat een applicatie die voor de authorisatie gebruik maakt van het IP adres van de bron niet meer van deze tijd is. Met al het gehannes met IP adressen om IPv4 nog in de lucht te houden is dat niet meer werkbaar.

En ik geef dat aan.

Maar goed, zolang mensen ontkennen dat dual-stack op dit moment de geschikte techniek is een rijk westers land blijft IPv6 een slechte reputatie houden. Het purisme zorgt voor problemen en support calls.

"Ach spotify werkt niet meer in de app, maar je gebruikt wel een CLAT"

Dit probleem kan je in een technische community misschien verkopen. Maar als ISP levert het je gewoon telefoontjes op die je niet wilt hebben.

ed1703 schreef op zondag 21 januari 2024 @ 12:46:
[...]
Je kan daar dan ook nog de verplichting aan toevoegen dat elke grote website IPv6 moet gebruiken en configureren. Zelfs de grootste webshops van dit land gebruiken geen IPv6.. (BOL, CB)

Hier maken cloudproviders het erg lastig. Diensten zijn nog niet volledig IPv6 klaar. En elke keer dat je tegen zo'n issue aan loopt heeft het een hoge opportunity cost; je bent veel uur kwijt voor iets dat bij IPv4 "gewoon werkt".

En als je intern IPv6 wilt doen is het nog lastiger. Kubernetes en IPv6? Lastige grap.

Doordat de grote providers genoeg IPv4 hebben verzameld lijkt er geen haast te bestaan om IPv6 de hoogste prioriteit te geven. En als je het bij MVP's overslaat dan duurt het daarna vaak een tijd voordat er parity is (als die er al komt).

[ Voor 25% gewijzigd door ANdrode op 21-01-2024 16:19 ]

[ed1703]

Roetzen schreef op zondag 21 januari 2024 @ 15:27:
[...]

Gelukkig hebben wij consumenten een ijzersterk middel in handen om invloed uit te oefenen: we kunnen stemmen met de portemonnee. Ik koop niets bij bol.com en de adverteerders bij nu.nl verdienen aan mij ook niets.

Ijzersterk ja, maar het boeit (om maar even een tekst van @RobertMe aan te halen) Henk & Ingrid geen ene zak of iets met IPv4 of IPv6 werkt. Ook doet men geen selectie op providers die dat wel of niet ondersteunen.
Dat gaat misschien eens gebeuren als zaken daadwerkelijk niet meer goed werken. 75% van de ISP klanten weet niet eens wat een ipadres is of doet. Overigens doet nu.nl al een tijdje IPv6 hoor

[Raven]

nero355 schreef op zondag 21 januari 2024 @ 15:16:
Iets van een maand geleden werd hier in de buurt aan de masten gerommeld en sindsdien word ik "Denied" op het moment dat ik via 2G verbonden wil zijn om zodoende mijn batterij minder te belasten.
Ik baal daar eigenlijk wel van, want als straks ook 3G geen optie meer is dan wordt het gewoon niet meer leuk als je ziet hoe snel je batterij leeg is op 4G/4G+/5G

offtopic:
Buiten dat, de ondersteuning voor VoLTE is nog steeds om te huilen bij Simyo, de lijst met geschikte telefoons (die sinds online zetten 5 jaar terug nooit bijgewerkt is) is inmiddels verwijdert, waarschijnlijk na ingediende commentaar over de steeds maar herhaalde leugen dat die regelmatig bijgewerkt zou worden.

Ben inmiddels rond aan het kijken naar een nieuwe(re) smartphone voor moeders, maar dat lijkt vanwege prijskaartje of V&A of refurbished te worden, tenzij iemand Simyo zover weet te krijgen smartphones van Oppo te ondersteunen.

[Roetzen]

nero355 schreef op zondag 21 januari 2024 @ 15:16:
[...]

Dat is leuk voor hen, maar als er twee bedrijven zijn aan wie ik geen voorbeeld zou willen nemen dan zijn het die twee wel : Pure Evil Corp gewoon!

Met die gevoelens kan ik wat deze twee bedrijven betreft wel ten dele meegaan,maar dat staat los van de gebruikte techniek en die is toch echt richting intern IPv6 only en dat is niet beperkt tot deze twee voorbeelden.

[Dreamvoid]

ANdrode schreef op zondag 21 januari 2024 @ 16:08:
[...]
Overigens krijgen getetherde apparaten bij KPN wel een privaat IPv4 adres. Ik weet niet waar de translatie gebeurt maar dat maakt eigenlijk niet uit.

CLAT op de telefoon.

Maar goed, zolang mensen ontkennen dat dual-stack op dit moment de geschikte techniek is een rijk westers land blijft IPv6 een slechte reputatie houden. Het purisme zorgt voor problemen en support calls.

Ik denk dat de discussie vooral vertroebeld wordt over welk deel van het netwerk we het hebben.

• op het LAN bij de consument thuis is dual stack noodzakelijk, dat is geen discussie. Er zijn teveel apparaten nog in omloop die zonder IPv4 niet werken, neem bv de Nintendo Switch, die in zo'n beetje elk huishouden met kinderen te vinden is
• aan de WAN kant kan je inderdaad als provider tegenwoordig IPv6-only gaan: DS-Lite, NAT64, MAP-T/E, kies maar uit. De klant merkt daar niets van. Maar de meeste providers met IPv6 hebben nog een IPv4 underlay netwerk liggen, dus dan kan je net zo goed dual stack aan de WAN kant blijven doen, al dan niet met de IPv4 achter CG-NAT.
• Voor een bedrijfsnetwerk hangt het af wat je daar nog hebt draaien - een Nintendo Switch of Spotify is niet zo relevant, dus wellicht kan je daar eerder al richting IPv6-only gaan. Maar ook daar kan je tegen dingetjes aanlopen - er staat ergens op internet een grappig verhaal over een network admin die alle software zorgvuldig geinvetariseerd dacht te hebben en IPv4 uitschakelde, waarna hij erachter kwam dat de 'connected' fitness apparaten in de bedrijfs fitness ruimte niet meer werkten

[ Voor 18% gewijzigd door Dreamvoid op 22-01-2024 12:18 ]

[Roetzen]

ANdrode schreef op zondag 21 januari 2024 @ 16:08:
[...]


CGNAT + normale DNS, geen synthetisch DNS64 adres voor een IPv4 only service.

Herinner hierbij hoe happy eyeballs werkt: De eerste poging om te verbinden gaat via IPv6. Daardoor gaat het verkeer niet via de route die je verwacht.

Happy eyeballs... Het probleem dat bij deze "oplossing" hoorde was dat er nogal wat websites waren die door een AAAA record aan de hostnaam te koppelen voorgaven IPv6 te doen maar dat in feite niet deden wat tot onaangename vertragingen in het laden van webpaginas leidde. Ik vrees dat er nog steeds zulke websites zijn dus Happy Eyeballs uitschakelen is misschien nog geen optie.

Hier hebben we dus de ironische situatie dat een maatregel die bedacht is om de transitie van IPv4 naar IPv6 te versoepelen een latere maatregel met hetzelfde doel in de wielen rijdt.

Wat ik nog niet begrijp is waarom NAT64/DNS64 alleen problemen geeft bij desktops en niet bij de mobiele telefoons. Komt dat soms omdat de applicaties waar het om gaat niet worden gedraaid op telefoons?

Maar goed, zolang mensen ontkennen dat dual-stack op dit moment de geschikte techniek is een rijk westers land blijft IPv6 een slechte reputatie houden. Het purisme zorgt voor problemen en support calls.

"Ach spotify werkt niet meer in de app, maar je gebruikt wel een CLAT"

Dit probleem kan je in een technische community misschien verkopen. Maar als ISP levert het je gewoon telefoontjes op die je niet wilt hebben.

Begrijpelijk, maar IPv4 met stoom en kokend water nog tot St Juttemis aan de praat houden kost ook veel menskracht.

[...]
Hier maken cloudproviders het erg lastig. Diensten zijn nog niet volledig IPv6 klaar. En elke keer dat je tegen zo'n issue aan loopt heeft het een hoge opportunity cost; je bent veel uur kwijt voor iets dat bij IPv4 "gewoon werkt".

Dat zal allemaal wel maar wat ik hier nu allemaal aan issues zie zijn niet zo zeer issues met IPv6 zelve maar met de transitie. Veel problemen zijn het gevolg van het per sé nog in de lucht willen houden van IPv4. Die problemen bestaan niet langer in een IPv6 only omgeving. Als we het met z'n alleen 10 jaar geleden wat daadkrachtiger hadden aangepakt dan hadden we al dat gedoe achter ons gehad.

En als je intern IPv6 wilt doen is het nog lastiger. Kubernetes en IPv6? Lastige grap.

En toch gaan veel grote platforms naar intern IPv6 only. Die gebruiken dan zeker wat anders/beters dan Kubernetes.

Doordat de grote providers genoeg IPv4 hebben verzameld lijkt er geen haast te bestaan om IPv6 de hoogste prioriteit te geven.

Dat lijkt in tegenstrijd met de observatie dat juist de twee grootste providers, KPN en Ziggo, in de voorste rij staan met IPv6.

En als je het bij MVP's overslaat dan duurt het daarna vaak een tijd voordat er parity is (als die er al komt).

Zo lijkt het bij DeCa (= Delta/Cayway) en Odido te gaan. Die hadden de kans om met een nog van de grond af aan nieuw aan te leggen netwerk direct IPv6 te gaan doen, maar begonnen met IPv4 only. DeCa is nu bezig met IPv6 uit te rollen maar hun Nokia modem.router die op het nieuwe XS-GPON netwerk wordt geleverd heeft nog kinderziekten in de IPv6 implementatie.

[Roetzen]

Dreamvoid schreef op maandag 22 januari 2024 @ 11:32:

Ik denk dat de discussie vooral vertroebeld wordt over welk deel van het netwerk we het hebben.

op het LAN bij de consument thuis is dual stack noodzakelijk, dat is geen discussie. Er zijn teveel apparaten nog in omloop die zonder IPv4 niet werken, neem bv de Nintendo Switch, die in zo'n beetje elk huishouden met kinderen te vinden is.

Ik heb geen kinderen en ik ben er bijna. Ik zoek nog een opvolger voor mijn SPA 112 VOIP adapter.

Maar de meeste providers met IPv6 hebben nog een IPv4 underlay netwerk liggen, dus dan kan je net zo goed dual stack aan de WAN kant blijven doen, al dan niet met de IPv4 achter CG-NAT.

Dat geldt dus niet voor DeCa en Oidido die nieuwe glasvezelnetwerken aanleggen. Maar die hebben de IPv6 only boot voorbij laten gaan...

en IPv4 uitschakelde, waarna hij erachter kwam dat de 'connected' fitness apparaten in de bedrijfs fitness ruimte niet meer werkten

Ik had het dan wel geweten: laat die fitness apparaten dan maar mooi "unconnected".

[Roetzen]

ed1703 schreef op zondag 21 januari 2024 @ 16:19:
Overigens doet nu.nl al een tijdje IPv6 hoor

Dat heb ik dan gemist. Ik had al een tijdje niet meer gekeken. Beter laat dan nooit zullen we dan maar zeggen.

Nu security.nl nog

[ Voor 9% gewijzigd door Roetzen op 22-01-2024 16:24 ]

[Dreamvoid]

Roetzen schreef op maandag 22 januari 2024 @ 13:59:
Wat ik nog niet begrijp is waarom NAT64/DNS64 alleen problemen geeft bij desktops en niet bij de mobiele telefoons. Komt dat soms omdat de applicaties waar het om gaat niet worden gedraaid op telefoons?

Op mobiel heb je maar twee OSen (Android en iOS), en die kunnen allebei "gegarandeerd" in een IPv6-only omgeving werken:

• sinds 2016 moet elke applicatie in Apple's App Store zonder IPv4 kunnen werken, dus er zijn inmiddels geen incompatible apps meer over in het iPhone/iPad ecosysteem
• Android forceert het niet, maar alle Android versies sinds 2013 doen CLAT, dit presenteert een virtueel IPv4 adres aan applicaties die dat nodig hebben, het OS vertaalt het naar een IPv6 adres en stuurt het naar de NAT64 gateway van de provider
• er zijn verder nog allerlei 4G/5G routers aka "mobile hotspots", als die IPv6 ondersteunen, dan is het ook altijd met CLAT

Als Windows CLAT zou doen, dan zou dit in principe de problemen met IPv4-only applicaties oplossen, er is dan immers altijd een IPv4 stack, daar zorgt het OS voor.

Op het moment doet Windows alleen CLAT op mobiele netwerken (laptops met SIM kaart), niet op WiFi of Ethernet netwerken. Zodra Windows dit doet (en bv ook Linux), neemt dit inderdaad een grote barriere voor IPv6-only LANs weg. Wat dan nog wel overblijft zijn oudere IoT dingen, smart tv's, game consoles, etcetera.

Als je overigens eens wil proberen of je zonder IPv4 kan: stel je DNS server (op de router of op Windows/Linux/macOS) in op een van de DNS servers uit deze lijst, zet IPv4 uit (of de DHCP server) en kijk wat er niet meer werkt.

[ Voor 14% gewijzigd door Dreamvoid op 22-01-2024 18:04 ]

[aawe mwan]

ed1703 schreef op zondag 21 januari 2024 @ 16:19:
[...]
Overigens doet nu.nl al een tijdje IPv6 hoor

Is het gewoon normaal IPv6 wat ze hebben bij nu.nl?

Afgelopen weekend zat ik door omstandigheden op een Windows 10 PC zonder IPv4. Wat gelijk opviel, was dat nu.nl daar niet op werkte. Maar tweakers.net werkte wel gewoon, net als het updaten van Windows. Samsung Magician kon dan weer wel zien dat er een update beschikbaar was, maar het downloaden van die update was niet mogelijk op IPv6.

Mijn conclusie was dat er toch nog een heleboel dingen gewoon niet werken, als je alleen IPv6 hebt.

Op mijn normale PC zag ik later inderdaad met een ping nu.nl dat ze wel een IPv6 adres hebben.

[ Voor 5% gewijzigd door aawe mwan op 22-01-2024 18:51 ]

[ANdrode]

aawe mwan schreef op maandag 22 januari 2024 @ 18:44:
[...]
Mijn conclusie was dat er toch nog een heleboel dingen gewoon niet werken, als je alleen IPv6 hebt.

Op mijn normale PC zag ik later inderdaad met een ping nu.nl dat ze wel een IPv6 adres hebben.

Welke browser gebruikte je?

Dit kan zo'n edge case zijn waar pakketten niet doorkomen doordat ze te groot zijn. In zo'n situatie heb je bij QUIC (door lagere MTU) vaak een betere kans dan het werkt dan HTTP omdat path MTU detectie vaak stuk is.

Helaas is dit allemaal vrij hels om te debuggen

[Roetzen]

aawe mwan schreef op maandag 22 januari 2024 @ 18:44:
[...]


Is het gewoon normaal IPv6 wat ze hebben bij nu.nl?

Afgelopen weekend zat ik door omstandigheden op een Windows 10 PC zonder IPv4. Wat gelijk opviel, was dat nu.nl daar niet op werkte. Maar tweakers.net werkte wel gewoon, net als het updaten van Windows. Samsung Magician kon dan weer wel zien dat er een update beschikbaar was, maar het downloaden van die update was niet mogelijk op IPv6.

Mijn conclusie was dat er toch nog een heleboel dingen gewoon niet werken, als je alleen IPv6 hebt.

Dat is helaas niets nieuws. Dit rapport van SIDN is al twee jaar oud, maar echt heel veel is er nog niet veranderd volgens de auteur. Daarom ook geen update.

Op mijn normale PC zag ik later inderdaad met een ping nu.nl dat ze wel een IPv6 adres hebben.

Een IPv6 adres hebben betekent helaas niet altijd dat IPv6 ook daadwerkelijk ondersteund wordt.

Toevallig liep ik vandaag op mijn eigen systeem tegen een gevalletje aan waarbij IPv6 wel en IPv4 nou net niet gewoon werkte.

Ik heb toen de glasvezel hier werd aangelegd mijn Ziggo aansluiting nog even aangehouden voor de zekerheid. Omdat ik het maximale uit die dubbele aansluiting wilde halen heb ik het systeem waar mijn servers op draaien voorzien van een tweede netwerkkaart. Maar dat werkt niet helemaal lekker. Als ik beide aansluitingen actief heb loopt het systeem bij tijd en wijle vast. Om de fout te lokaliseren heb ik eerst de glaszezel aansluiting afgeschakeld. Op de ziggo aansluiting werkt het stabiel. Dus nu is de glasvezel aansluiting aan de beurt. Met alleen de glasvezel aansluiting lijkt het systeem voorlopig ook stabiel. Maar vanwege dat Nokia ding heb ik nu even geen inkomend IPv6. Dus heb ik het AAAA record ook maar even weg gehaald. En tot mijn verrassing kon ik toen mijn eigen servers ook niet op IPv4 bereiken. Het duurde even voordat het kwartje viel. Dat Nokia ding heeft geen NAT loopback. En dus zijn mijn eigen servers niet bereikbaar vanuit mijn eigen LAN. Ik was dat helemaal vergeten omdat ik het met IPv6 niet merk. Met het AAAA record er bij gaat het weer wel. Ook zijn de servers nog steeds van buitenaf bereikbaar. Happy Eyeballs werkt!.

Dus: mijn servers hebben een IPv6 adres, maar zijn nu voor de duur van dit experiment even niet via IPv6 bereikbaar. Waarvan akte...

[Dreamvoid]

aawe mwan schreef op maandag 22 januari 2024 @ 18:44:
Afgelopen weekend zat ik door omstandigheden op een Windows 10 PC zonder IPv4. Wat gelijk opviel, was dat nu.nl daar niet op werkte. Maar tweakers.net werkte wel gewoon, net als het updaten van Windows. Samsung Magician kon dan weer wel zien dat er een update beschikbaar was, maar het downloaden van die update was niet mogelijk op IPv6.

Was dit IPv6 zonder NAT64 of met?

[The Genie]

aawe mwan schreef op maandag 22 januari 2024 @ 18:44:
[...]


Is het gewoon normaal IPv6 wat ze hebben bij nu.nl?

Afgelopen weekend zat ik door omstandigheden op een Windows 10 PC zonder IPv4. Wat gelijk opviel, was dat nu.nl daar niet op werkte. Maar tweakers.net werkte wel gewoon, net als het updaten van Windows. Samsung Magician kon dan weer wel zien dat er een update beschikbaar was, maar het downloaden van die update was niet mogelijk op IPv6.

Mijn conclusie was dat er toch nog een heleboel dingen gewoon niet werken, als je alleen IPv6 hebt.

Op mijn normale PC zag ik later inderdaad met een ping nu.nl dat ze wel een IPv6 adres hebben.

Beetje krom van nu.nl. nu.nl zelf geeft inderdaad een IPv6 adres terug, maar www.nu.nl heeft alleen een A record....

[nero355]

ANdrode schreef op zondag 21 januari 2024 @ 16:08:
"Ach spotify werkt niet meer in de app, maar je gebruikt wel een CLAT"

Dit probleem kan je in een technische community misschien verkopen. Maar als ISP levert het je gewoon telefoontjes op die je niet wilt hebben.

Heel eerlijk gezegd is het gewoon de schuld van Spotify en misschien wel nog meer al die mensen die het zo graag gebruiken en het een populaire dienst hebben laten worden, terwijl het qua Client Applicatie een absolute ramp is gewoon !!!

Er is zoveel mis mee en het Spotify Forum staat vol met klachten van mensen over de meest basis dingen waarop dus echt 0,0 reactie komt vanuit Spotify zelf...

Om maar te zwijgen over het feit dat het niet eens een echte Client Applicatie heeft en je in feite opzadelt met een veredelde browser window en dus Electron troep!

Raven schreef op zondag 21 januari 2024 @ 17:17:

offtopic:
Buiten dat, de ondersteuning voor VoLTE is nog steeds om te huilen bij Simyo, de lijst met geschikte telefoons (die sinds online zetten 5 jaar terug nooit bijgewerkt is) is inmiddels verwijdert, waarschijnlijk na ingediende commentaar over de steeds maar herhaalde leugen dat die regelmatig bijgewerkt zou worden.

offtopic:
Tja, moet je maar naar de echte provider overstappen en niet die budget troepdingen!

offtopic:
Ben inmiddels rond aan het kijken naar een nieuwe(re) smartphone voor moeders, maar dat lijkt vanwege prijskaartje of V&A of refurbished te worden, tenzij iemand Simyo zover weet te krijgen smartphones van Oppo te ondersteunen.

offtopic:
Tegenwoordig heb je zelfs telefoons die minder dan € 100 kosten dus gewoon zoiets voor moeders kopen en klaaaar!!!

Dreamvoid schreef op maandag 22 januari 2024 @ 11:32:
Op het LAN bij de consument thuis is dual stack noodzakelijk, dat is geen discussie.
Er zijn teveel apparaten nog in omloop die zonder IPv4 niet werken, neem bv de Nintendo Switch, die in zo'n beetje elk huishouden met kinderen te vinden is.

Of dat zo is valt te betwisten, maar misschien zou het weleens tijd worden dat het Console merk waarvan de games de langste periode idioot duur blijven aan de gang gaat om hun firmware met IPv6 uit te rusten

Des te meer klachten, des te sneller dat gebeurt!

Er staat ergens op internet een grappig verhaal over een network admin die alle software zorgvuldig geinvetariseerd dacht te hebben en IPv4 uitschakelde, waarna hij erachter kwam dat de 'connected' fitness apparaten in de bedrijfs fitness ruimte niet meer werkten.

100% dit =>

Roetzen schreef op maandag 22 januari 2024 @ 14:09:
Ik had het dan wel geweten: laat die fitness apparaten dan maar mooi "unconnected".

Vooral als je ziet wat dergelijke gadgets kosten!

Al die merken moeten maar eens gewoon hun shit fixen!

Dreamvoid schreef op maandag 22 januari 2024 @ 17:37:
Op mobiel heb je maar twee OSen (Android en iOS), en die kunnen allebei "gegarandeerd" in een IPv6-only omgeving werken.

Je vergeet er een paar :
- UBPorts Ubuntu Touch
- Jolla SailFish
- PostmarketOS

Je weet wel...

De ECHTE Linux telefoons die ook nog eens niet al je data aan alles en iedereen verkopen!

Als Windows CLAT zou doen, dan zou dit in principe de problemen met IPv4-only applicaties oplossen, er is dan immers altijd een IPv4 stack, daar zorgt het OS voor.

Ik vraag me vooral af hoeveel ellende het dan wel mij dan wel de makers van de applicaties gaat opleveren op het moment dat je dingen aan Windows overlaat...

Ik word er nou al gek van qua "Dat bepaal ik wel voor jou!" gedrag a.k.a. "features"

Wat dan nog wel overblijft zijn oudere IoT dingen, smart tv's, game consoles, etcetera.

Allemaal zooi die je makkelijk EOL kan verklaren, want op een gegeven moment moet dat toch wel gebeuren of bepaalt een Microsoft of Sony of de makers van de games dat voor jou wel uiteindelijk...

Als je overigens eens wil proberen of je zonder IPv4 kan: stel je DNS server (op de router of op Windows/Linux/macOS) in op een van de DNS servers uit deze lijst, zet IPv4 uit (of de DHCP server) en kijk wat er niet meer werkt.

Als je zelf een Unbound instance draait zou je hem een lokaal IPv6 pootje kunnen geven en het op dezelfde manier testen!

ANdrode schreef op maandag 22 januari 2024 @ 20:33:
Dit kan zo'n edge case zijn waar pakketten niet doorkomen doordat ze te groot zijn. In zo'n situatie heb je bij QUIC (door lagere MTU) vaak een betere kans dan het werkt dan HTTP omdat path MTU detectie vaak stuk is.

Helaas is dit allemaal vrij hels om te debuggen

QUIC zou één van de eerste dingen die je sloopt in je browser moeten zijn, want uiteindelijk bestaat het alleen maar omdat een bepaalde grote adverteerder het oh zo graag in zijn eigen browser wilde hebben...

Roetzen schreef op maandag 22 januari 2024 @ 21:40:
Dat Nokia ding heeft geen NAT loopback. En dus zijn mijn eigen servers niet bereikbaar vanuit mijn eigen LAN.

Grappig :

Zeuren over IPv4 werkende blijven houden hacks en vervolgens afhankelijk willen zijn van één van de ranzigste hacks die ooit heeft bestaan : Reverse NAT/NAT Loopback

[Roetzen]

nero355 schreef op dinsdag 23 januari 2024 @ 15:27:
[...]
Grappig :

Zeuren over IPv4 werkende blijven houden hacks en vervolgens afhankelijk willen zijn van één van de ranzigste hacks die ooit heeft bestaan : Reverse NAT/NAT Loopback

"Ranzigste hacks" is te veel eer. Het is gewoon één van de spelden en paperclips waarmee IPv4 in de lucht wordt gehouden. Ik ben er niet van afhankelijk. Het viel me alleen op omdat ik inkomend IPv6 voor de test even uitgeschakeld had. Ik merkte juist op dat het geen punt meer zou zijn in een IPv6 only omgeving.

[nero355]

Roetzen schreef op dinsdag 23 januari 2024 @ 15:50:
"Ranzigste hacks" is te veel eer.

De populairste door gebruikers misbruikte veiligheidsrisico mag ook hoor!

[Dreamvoid]

nero355 schreef op dinsdag 23 januari 2024 @ 15:27:
[...]
Of dat zo is valt te betwisten, maar misschien zou het weleens tijd worden dat het Console merk waarvan de games de langste periode idioot duur blijven aan de gang gaat om hun firmware met IPv6 uit te rusten

Des te meer klachten, des te sneller dat gebeurt!

Zou moeten, maar de realiteit is dat klanten verwachten dat hun huidige spullen werken, die willen niet van hun provider horen dat hun gloednieuwe Switch niet werkt. En de provider wil al die support telefoontjes niet. En aangezien die provider zonder moeite dual stack bij de klant kan aanbieden is dat wat in de praktijk gebeurt.

Je vergeet er een paar :
- UBPorts Ubuntu Touch
- Jolla SailFish
- PostmarketOS

Devices die geen IPv6 kunnen, die kan je als mobiele operator een IPv4 APN geven, da's niet zo lastig.

Ik vraag me vooral af hoeveel ellende het dan wel mij dan wel de makers van de applicaties gaat opleveren op het moment dat je dingen aan Windows overlaat...

Ik word er nou al gek van qua "Dat bepaal ik wel voor jou!" gedrag a.k.a. "features"

Applicatie vertrouwen nu ook al op de netwerk stacks van Windows, dus daar verandert weinig.

Allemaal zooi die je makkelijk EOL kan verklaren, want op een gegeven moment moet dat toch wel gebeuren of bepaalt een Microsoft of Sony of de makers van de games dat voor jou wel uiteindelijk...

Als het heel simpel is om dual stack aan te bieden, dan gaat dat ook gebeuren. Dit is de klant zijn eigen netwerk, een Ziggo of KPN geeft standaard IPv4 + IPv6, dan geef je de klant de optie om IPv6-only te doen als hij dat kan.

[Roetzen]

Dreamvoid schreef op dinsdag 23 januari 2024 @ 16:12:
[...]

Zou moeten, maar de realiteit is dat klanten verwachten dat hun huidige spullen werken, die willen niet van hun provider horen dat hun gloednieuwe Switch niet werkt. En de provider wil al die support telefoontjes niet. En aangezien die provider zonder moeite dual stack bij de klant kan aanbieden is dat wat in de praktijk gebeurt.

Als autofabrikanten verplicht kunnen worden autos die na een bepaalde datum van de band rollen te voorzien van derde remlichten, airbags en ABS, waarom kunnen fabrikanten van netwerkspul dan niet verplicht worden IPv6 te ondersteunen?

[Raven]

nero355 schreef op dinsdag 23 januari 2024 @ 15:27:
[...]

offtopic:
Tja, moet je maar naar de echte provider overstappen en niet die budget troepdingen!

offtopic:
Maar dan krijgen we geen extra data/belminuten i.v.m. KPN glas en Simyo compleet

nero355 schreef op dinsdag 23 januari 2024 @ 15:27:
[...]

offtopic:
Tegenwoordig heb je zelfs telefoons die minder dan € 100 kosten dus gewoon zoiets voor moeders kopen en klaaaar!!!

offtopic:
* Raven ziet alleen een paar feature phones en een merk dat ie nog nooit in smartphoneland heeft gezien

[RobertMe]

Roetzen schreef op dinsdag 23 januari 2024 @ 17:17:
[...]

Als autofabrikanten verplicht kunnen worden autos die na een bepaalde datum van de band rollen te voorzien van derde remlichten, airbags en ABS, waarom kunnen fabrikanten van netwerkspul dan niet verplicht worden IPv6 te ondersteunen?

Omdat ABS & 3de remlicht om veiligheid gaan. Maar jij gaat vast aandragen dat IPv6 ook veiliger dan IPv4 is. En dan ook niet alleen voor jijzelf maar ook voor andere verkeersdeelnemers.

En daarnaast kan IPv4 en IPv6 naast elkaar en zit er een bepaalde mate van marktwerking in. Wel en geen ABS kan niet naast elkaar en 2 en 3 remlichten kan ook alleen volgens Schrödinger (totdat je remt heeft de auto zowel 2 als 3 remlichten ).

[Dreamvoid]

Roetzen schreef op dinsdag 23 januari 2024 @ 17:17:
[...]

Als autofabrikanten verplicht kunnen worden autos die na een bepaalde datum van de band rollen te voorzien van derde remlichten, airbags en ABS, waarom kunnen fabrikanten van netwerkspul dan niet verplicht worden IPv6 te ondersteunen?

Netwerkspul als switches en routers is het probleem ook niet echt meer, het zijn applicaties en endpoint devices.

Met auto’s heb je een vergelijkbaar voorbeeld - het duurt decennia voordat oude auto’s die niet aan de huidige normen voldoen allemaal van de weg zijn.

[Roetzen]

RobertMe schreef op dinsdag 23 januari 2024 @ 17:33:
[...]

Omdat ABS & 3de remlicht om veiligheid gaan. Maar jij gaat vast aandragen dat IPv6 ook veiliger dan IPv4 is. En dan ook niet alleen voor jijzelf maar ook voor andere verkeersdeelnemers.

Ik ga niet beweren dat IPv6 veiliger is dan IPV4 maar ik denk dat er wel een case te maken is tegen het naast elkaar laten bestaan van beiden. Een dubbele infrastructuur heeft een tweemaal zo groot aanvalsoppervlak, en is daardoor onveiliger. Maar daar wilde ik eigenlijk niet naar toe.

En daarnaast kan IPv4 en IPv6 naast elkaar en zit er een bepaalde mate van marktwerking in. Wel en geen ABS kan niet naast elkaar en 2 en 3 remlichten kan ook alleen volgens Schrödinger (totdat je remt heeft de auto zowel 2 als 3 remlichten ).

Autos met en zonder ABS kunnen zonder problemen door elkaar van dezelfde wegen gebruik maken en een derde remlicht achteraf toevoegen is met de oudere autos die het nog niet hebben vrij eenvoudig. ABS later inbouwen is lastiger, maar ik weet nog niet of ik het heb of niet. Volgens het boekje wel, maar ik heb nog nooit zo hard hoeven remmen dat het in werking trad. Vertel dat maar aan de kat.

Maar als we met autos vergelijken dan denk ik eerder aan elektrisch vs fossiele brandstof. Net als IPv4 en IPv6 over dezelfde coaxkabel of glasvezel kunnen gaan, kunnen elektrische autos en fossiele brandstof autos dezelfde wegen door elkaar rijden. Maar je moet er wel twee aparte infrastructuren voor in de lucht houden om ze van "brandstof" te voorzien. Om die fossiele brandstofautos aan het rijden te houden moet je een heel systeem van raffinaderijen, binnenvaartschepen, tankwagens en tankstations in de lucht houden.

[Roetzen]

Dreamvoid schreef op dinsdag 23 januari 2024 @ 18:23:
[...]

Netwerkspul als switches en routers is het probleem ook niet echt meer, het zijn applicaties en endpoint devices.

Ik drukte mij wat ongelukkig uit met het woord "netwerkspul". Ik bedoelde "spul dat van een netwerk gebruik maakt".

Met auto’s heb je een vergelijkbaar voorbeeld - het duurt decennia voordat oude auto’s die niet aan de huidige normen voldoen allemaal van de weg zijn.

Ik verwacht dat het met de benzine cq diesel autos sneller zal gaan. Als er geen nieuwe benzineautos meer verkocht (mogen) worden zullen er minder van op de weg komen en dan zullen de benzinestations gaan verdwijnen. En dan kan het vrij hard gaan. Als de benzinerijder 50 km moet gaan omrijden om te tanken, dan is dat best een aansporing om toch maar over te gaan op elektrisch want die kan ie op zijn eigen oprit aan de laadpaal hangen.

Als de tankstations verdwijnen zijn de benzineautos nog niet meteen allemaal verdwenen, maar, maar je zult ze dan alleen nog zien bij evenementen.

En met die vergelijking komt nog een andere vergelijking naar boven. We hadden al vijftien jaar geleden moeten beginnen met IPv6. Voor de energietransitie moet het elektriciteitsnet verzwaard worden. Ook daar hadden we vijftien jaar geleden al mee moeten beginnen in plaats van het maar steeds voor ons uit te schuiven.

[Dreamvoid]

Da's niet helemaal hetzelfde - vijftien jaar geleden had het sowieso niet gekund met volledig electrische auto's - de accutechnologie is pas recent ver genoeg gevorderd om volledig electrisch te rijden. Bedenk dat de eerste (kleine) Lithium-Ion batterij pas in 1991 op de markt kwam, de technische ontwikkeling heeft veel tijd gekost.

Electrisch rijden was vijftien jaar geleden al wel razend populair, maar als hybride met lood of nikkel accu's. Volledig electrische auto's waren er toen ook al, maar met te hoog gewicht en beperkte capaciteit werden ze maar mondjesmaat gekocht. Direct zodra grootschalige goedkope productie van Lithium accu's mogelijk was, ging het als een speer met volledig electrische auto's.

[hcQd]

Dreamvoid schreef op woensdag 24 januari 2024 @ 13:07:
vijftien jaar geleden had het sowieso niet gekund met volledig electrische auto's - de accutechnologie is pas recent ver genoeg gevorderd om volledig electrisch te rijden.

offtopic:
Baker Electric produceerde ruim honderd jaar geleden al volledig electrische autos.

[nero355]

Dreamvoid schreef op dinsdag 23 januari 2024 @ 18:23:
Netwerkspul als switches en routers is het probleem ook niet echt meer, het zijn applicaties en endpoint devices.

Caiway/Delta is het niet met je eens, want hun verklaring voor het niet hebben van IPv6 op hun AON netwerk is dat de aan de klanten uitgedeelde Genexis 7840 niet het probleem is en juist de apparatuur die de verbinding verzorgt richting de klant het probleem is, want geen tot buggy IPv6 Support

Met auto’s heb je een vergelijkbaar voorbeeld - het duurt decennia voordat oude auto’s die niet aan de huidige normen voldoen allemaal van de weg zijn.

Ik zou die hele vergelijking met auto's niet willen maken, want dat is een heel raar verhaal opzich als je daar echt diep op in zou gaan...

En bovendien "Rules of The Internet" en geen vergelijkingen met auto's maken en zo

Roetzen schreef op woensdag 24 januari 2024 @ 12:23:
Als de benzinerijder 50 km moet gaan omrijden om te tanken, dan is dat best een aansporing om toch maar over te gaan op elektrisch want die kan ie op zijn eigen oprit aan de laadpaal hangen.

Als iemand die regelmatig moest omrijden/zijn route vooraf goed plannen om zodoende de auto van fatsoenlijke Euro 98 te kunnen voorzien van de BP zie ik daar helemaal geen probleem in eerlijk gezegd

En de LPG rijders zullen er ongetwijfeld ook hetzelfde over denken!

[Roetzen]

nero355 schreef op woensdag 24 januari 2024 @ 14:25:

Ik zou die hele vergelijking met auto's niet willen maken, want dat is een heel raar verhaal opzich als je daar echt diep op in zou gaan...

Vergelijkingen gaan altijd mank als je ze te ver doortrekt. Dat moet je dan ook niet doen. Als degene aan wie je de vergelijking voorlegt niet ziet wat je er mee wil zeggen, kun je het beter laten rusten.

Als iemand die regelmatig moest omrijden/zijn route vooraf goed plannen om zodoende de auto van fatsoenlijke Euro 98 te kunnen voorzien van de BP zie ik daar helemaal geen probleem in eerlijk gezegd

En de LPG rijders zullen er ongetwijfeld ook hetzelfde over denken!

Dan ben jij de uitzondering die de regel bevestigt en LPG is al lang op z'n retour.

[nero355]

Roetzen schreef op woensdag 24 januari 2024 @ 14:43:
Dan ben jij de uitzondering die de regel bevestigt en LPG is al lang op z'n retour.

Mwa, als ik zo eens rondkijk in Het grote LPG topic dan zit daar nog genoeg leven in denk ik

[Roetzen]

Dreamvoid schreef op woensdag 24 januari 2024 @ 13:07:
Da's niet helemaal hetzelfde - vijftien jaar geleden had het sowieso niet gekund met volledig electrische auto's - de accutechnologie is pas recent ver genoeg gevorderd om volledig electrisch te rijden. Bedenk dat de eerste (kleine) Lithium-Ion batterij pas in 1991 op de markt kwam, de technische ontwikkeling heeft veel tijd gekost.

Klopt maar de elektrische auto is niet de enige reden waarom het elektriciteitsnet verzwaard moet worden en dat hadden we vijftien jaar geleden heus wel kunnen zien aankomen.

Maar goed, ik haalde autos er bij omdat het me opviel dat het kennelijk bij autos wel mogelijk is dwingende maatregelen te nemen. Tot zelfs een aankomend verbod op de verkoop van autos met een interne verbrandingsmotor.

Het was de aanloop naar een pleidooi voor bijvoorbeeld een verplichting apparatuur van IPv6 te voorzien en mogelijk zelfs - en daar begon deze draad mee - op termijn afschakelen van IPv4 op dat deel van het internet waar de overheid het directe beheer over heeft.

Nu is er bij sommigen - vooral bij bedrijven - nog steeds de neiging om te wachten met de invoering van IPv6 tot het niet anders kan. Iedereen kan denk ik wel zien dat op de lange termijn iedereen beter af is met een IPv6 only internet. Maar op de korte termijn is het niet in het voordeel daar als eerste mee te beginnen. Overheidsdwang met termijnen kan daarbij helpen want dat creëert wat dat aspect betreft een gelijk speelveld.

[Hipska]

Zoals door @St00mwals eerder al aangehaald heeft de Tsjechische overheid beslist om IPv4 uit te zetten voor hun publieke diensten in 2032. Er is zelfs een aftelwebsite: https://konecipv4.cz/en/

Als andere overheden dit voorbeeld volgen zullen netwerkleveranciers snel volgen met IPv6 compatible hard-/software.

[Freee!!]

Roetzen schreef op woensdag 24 januari 2024 @ 11:54:
[...]
ABS later inbouwen is lastiger, maar ik weet nog niet of ik het heb of niet. Volgens het boekje wel, maar ik heb nog nooit zo hard hoeven remmen dat het in werking trad.

offtopic:
Prijs jezelf gelukkig. Bij mij is het wel eens in werking getreden en het is een apart gevoel.

[Snow_King]

Roetzen schreef op woensdag 24 januari 2024 @ 15:27:
[...]

Het was de aanloop naar een pleidooi voor bijvoorbeeld een verplichting apparatuur van IPv6 te voorzien en mogelijk zelfs - en daar begon deze draad mee - op termijn afschakelen van IPv4 op dat deel van het internet waar de overheid het directe beheer over heeft.

Nu is er bij sommigen - vooral bij bedrijven - nog steeds de neiging om te wachten met de invoering van IPv6 tot het niet anders kan. Iedereen kan denk ik wel zien dat op de lange termijn iedereen beter af is met een IPv6 only internet. Maar op de korte termijn is het niet in het voordeel daar als eerste mee te beginnen. Overheidsdwang met termijnen kan daarbij helpen want dat creëert wat dat aspect betreft een gelijk speelveld.

Laten we vooral inderdaad maar beginnen met IPv4 uit te zetten, top zet van Tsjechië! Hopelijk volgt Nederland al in 2030!

Nu graag dat Google, Netflix en Meta ook aankondigen dat hun diensten alleen bereikbaar zijn via IPv6 vanaf 2030.

Ik vind de uitrol vooral op servers de laatste tijd bedroevend.

Veel websites hebben IPv6 aan staan doordat ze achter bijv CloudFlare of Akamai zitten, maar:

- MX record heeft enkel A
- login.domein.tld enkel A (voorbeeld)
- API is enkel IPv4
- De externe content op de pagina is ook IPv4-only

Ook bij bedrijven die net starten en online gaan, IPv4-only website. Zo zonde.

[Dreamvoid]

Niet te vroeg juichen, Tsjechie zet geen IPv4 uit in het hele land, alleen bij de overheid. Oftewel, dat betekent dat IPv6 nodig is om overheidswebsites te bezoeken, en zelfs dat alleen als de overheid die IPv6-only infrastructuur niet achter een dual stack CDN zet.

[Hipska]

Ook een interessant artikel van SIDN: We zijn het zicht op de IPv6-adoptie in Nederland kwijtgeraakt

[nero355]

Snow_King schreef op donderdag 25 januari 2024 @ 15:36:
Nu graag dat Google, Netflix en Meta ook aankondigen dat hun diensten alleen bereikbaar zijn via IPv6 vanaf 2030.

JAAA!!!

Dan blijf ik wel op IPv4 hangen en dan weet ik gelijk ook 100% zeker dat ik nooit meer contact met ze maak !!! PERFECT !!!

[Roetzen]

Snow_King schreef op donderdag 25 januari 2024 @ 15:36:
[...]

Laten we vooral inderdaad maar beginnen met IPv4 uit te zetten, top zet van Tsjechië! Hopelijk volgt Nederland al in 2030!

Als Nederland al in 2030 doet wat Tsjechië in 2032 doet is het niet "volgen".

Van mij mag de NL overheid het al in 2026 doen. Maar ik vrees dat dat niet zal gebeuren. We hebben hier helaas een overheid gekregen die problemen liever voor zich uit schuift dan daadkracht te tonen. Ooit waren we een land dat in allerlei zaken graag "het voortouw nam". Maar die tijd lijkt voorbij. Dus ik frees met grote frezen.

Nu graag dat Google, Netflix en Meta ook aankondigen dat hun diensten alleen bereikbaar zijn via IPv6 vanaf 2030.

Dat gaan ze niet doen als dat klanten gaat kosten. Probleem is dat ondanks alle plakband en paperclips IPv4 het nog altijd best goed doet. Het werkt nog "gewoon". Het zou eigenlijk eens goed fout moeten gaan...

Ik vind de uitrol vooral op servers de laatste tijd bedroevend.

Veel websites hebben IPv6 aan staan doordat ze achter bijv CloudFlare of Akamai zitten, maar:

- MX record heeft enkel A
- login.domein.tld enkel A (voorbeeld)
- API is enkel IPv4
- De externe content op de pagina is ook IPv4-only

Dat komt allemaal helaas nog heel veel voor. Zelfs nos.nl zal nog steeds niet lekker werken in een IPv6 only omgeving. https://cdn.nos.nl is ipv4.

Er zou bij het beoordelen van websites verder gekeken moet worden dan alleen de voorkant.

[Roetzen]

Hipska schreef op donderdag 25 januari 2024 @ 21:30:
Ook een interessant artikel van SIDN: We zijn het zicht op de IPv6-adoptie in Nederland kwijtgeraakt

Erg vrolijk wordt ik er niet van. Maar het verbaast me niet zo heel erg. We hadden kunnen weten dat we dit soort problemen niet aan de markt kunnen over laten. We zijn van "voortouwland" verworden tot een land waar je 15 cent statiegeld op een blikje moet zetten om mensen zo ver te krijgen de blikjes netje af te voeren. En dan nog gaat het moeizaam.

De overheid heeft het laten liggen. IPv6 ondersteuning had al lang verplicht moeten zijn. En nu is het zo ver gekomen dat we het niet meer weten...

[Snow_King]

Dreamvoid schreef op donderdag 25 januari 2024 @ 17:04:
Niet te vroeg juichen, Tsjechie zet geen IPv4 uit in het hele land, alleen bij de overheid. Oftewel, dat betekent dat IPv6 nodig is om overheidswebsites te bezoeken, en zelfs dat alleen als de overheid die IPv6-only infrastructuur niet achter een dual stack CDN zet.

Dat zou kunnen, maar het is al goed dat de discussie aan de gang is.

Roetzen schreef op vrijdag 26 januari 2024 @ 15:36:
[...]

Als Nederland al in 2030 doet wat Tsjechië in 2032 doet is het niet "volgen".

Van mij mag de NL overheid het al in 2026 doen. Maar ik vrees dat dat niet zal gebeuren. We hebben hier helaas een overheid gekregen die problemen liever voor zich uit schuift dan daadkracht te tonen. Ooit waren we een land dat in allerlei zaken graag "het voortouw nam". Maar die tijd lijkt voorbij. Dus ik frees met grote frezen.

[...]


Dat gaan ze niet doen als dat klanten gaat kosten. Probleem is dat ondanks alle plakband en paperclips IPv4 het nog altijd best goed doet. Het werkt nog "gewoon". Het zou eigenlijk eens goed fout moeten gaan...

[...]

Dat komt allemaal helaas nog heel veel voor. Zelfs nos.nl zal nog steeds niet lekker werken in een IPv6 only omgeving. https://cdn.nos.nl is ipv4.

Er zou bij het beoordelen van websites verder gekeken moet worden dan alleen de voorkant.

IPv4 werkt zeker nog voor het consumeren van diensten als YT en Netflix en dat gaat zo nog wel even door ben ik bang...

Triest dat de NOS niet bij Scalia (partij achter CDN) wat druk zet.

Wij zijn Scalia, de go-to Cloud Hosting Infrastructuur, Content
Delivery Network (CDN) en Managed Service Partner voor media
en e-commerce bedrijven.

Wij staan voor zorgeloze schaalbaarheid en maken de (groei)
ambities van uw missie kritische websites en applicaties waar.

Nou, kom op! Zet IPv6 aan.

[Roetzen]

Snow_King schreef op vrijdag 26 januari 2024 @ 16:02:
[...]

Dat zou kunnen, maar het is al goed dat de discussie aan de gang is.

Jawel, maar "in geouwehoer kun je niet wonen". (Jan Schaefer)

IPv4 werkt zeker nog voor het consumeren van diensten als YT en Netflix en dat gaat zo nog wel even door ben ik bang...

Tja, hun serverparken intern IPv6 only maken willen ze wel, want dat heeft voordelen, en als IPv6 klant zou je in theorie dan een licht voordeel hebben, maar klanten zonder IPv6 uitsluiten willen ze niet want dat is inkomstenderving. Ze zullen hun diensten via IPv4 bereikbaar houden tot er zo weinig IPv4 only klanten over blijven dat de inkomsten die ze genereren niet meer opwegen tegen de kosten om IPv4 in de lucht te houden. En dat gaat nog wel even duren.

Zonder dwang van de overheid zal het niet gaan. Maar ik zie IPv6 niet op de lijst van punten op de formatietafel staan....

[Roetzen]

Een IPv6 only stad?

https://blog.apnic.net/20...-ipv6-city-xiongan-china/

[ANdrode]

Dreamvoid schreef op donderdag 25 januari 2024 @ 17:04:
Niet te vroeg juichen, Tsjechie zet geen IPv4 uit in het hele land, alleen bij de overheid. Oftewel, dat betekent dat IPv6 nodig is om overheidswebsites te bezoeken, en zelfs dat alleen als de overheid die IPv6-only infrastructuur niet achter een dual stack CDN zet.

Als je dit strak toepast (DNS, mail, web single stack IPv6) best een prikkel.

Snow_King schreef op vrijdag 26 januari 2024 @ 16:02:
[...]
Triest dat de NOS niet bij Scalia (partij achter CDN) wat druk zet.

Dit is onacceptabel. Er zijn zat Europese CDNs met IPv6.

Roetzen schreef op zondag 28 januari 2024 @ 09:48:
Een IPv6 only stad?

https://blog.apnic.net/20...-ipv6-city-xiongan-china/

Vergeet als je zoiets lees niet dat er zelfs in de EU (België iirc) limieten zijn op het aantal gebruikers dat je per IPv4 adres mag NAT-en in verband met traceerbaarheid. Over Iran heb ik hetzelfde gehoord (en ironisch genoeg werd IPv6 op Irancel uitgezet tijdens protesten).

Het is niet puur positief. Voor wat betreft pseudonimiteit is CGNAT een goede techniek. DHCPc6 is wat privacy betreft een probleem en zou gewoon niet ondersteund moeten worden.


@Snow_King snap jij de SRv6 push? Ik kan het (a) niet uitleggen en zie (b) de voordelen niet voor 99% van de use cases. "Ik wil het fysieke pad door een buur-netwerk willen kunnen plannen met mijn controller" is een niche?

[ Voor 7% gewijzigd door ANdrode op 28-01-2024 14:40 ]

[Snow_King]

Roetzen schreef op zondag 28 januari 2024 @ 09:48:
Een IPv6 only stad?

https://blog.apnic.net/20...-ipv6-city-xiongan-china/

Wat ik zo interessant vind hier aan: In China is er veel uitrol van IPv6, maar als ik 'chineze troep' zie hier op de markt dan ondersteund het vaak allemaal geen IPv6.

ANdrode schreef op zondag 28 januari 2024 @ 14:38:
[...]


@Snow_King snap jij de SRv6 push? Ik kan het (a) niet uitleggen en zie (b) de voordelen niet voor 99% van de use cases. "Ik wil het fysieke pad door een buur-netwerk willen kunnen plannen met mijn controller" is een niche?

Nee, ik ken SRv6 eigenlijk niet. Mijn ervaring zit hem vooral in BGP+EVPN+VXLAN in cloud omgevingen.

Het liefste met een IPv6 underlay, maar die is vaak nog IPv4. Wel BGP Unnumbered met BGP sessie over IPv6 Link-Local met een extended nexthop waarin we IPv4 verkeer kunnen routeren via een IPv6 BGP sessie.

[ Voor 47% gewijzigd door Snow_King op 29-01-2024 09:08 ]

[Roetzen]

Snow_King schreef op maandag 29 januari 2024 @ 09:06:
[...]

Wat ik zo interessant vind hier aan: In China is er veel uitrol van IPv6, maar als ik 'chineze troep' zie hier op de markt dan ondersteund het vaak allemaal geen IPv6.

Ze houden het goede spul voor zichzelf?

[Dreamvoid]

ANdrode schreef op zondag 28 januari 2024 @ 14:38:
Als je dit strak toepast (DNS, mail, web single stack IPv6) best een prikkel.

Denk ik ook, maar laten we wel zijn, als er anno 2032 nog een significante groep burgers in Tsjechie is die geen IPv6 heeft, is het voor de overheid wel heel makkelijk om een simpele IPv4 CDN ervoor te zetten, in een kosten/baten afweging is dat een vrij eenvoudige keuze: een paar duizend euro voor een Cloudflare abo'tje versus ladingen kwaaie burgers.

Als het doel is om alle burgers op IPv6 te zetten, dan is het eenvoudiger om een wet aan te nemen dat IPv6 verplicht beschikbaar moet zijn voor alle consumenten aansluitingen (mobiel en vast) in 2032.

Deze initiatieven om de overheid op IPv6 te zetten is in het algemeen bedoeld om de overheid van de legacy infrastructuur af te helpen (vanuit security/complexiteit/kosten oogpunt), niet het hele land. Idem wat de VS nu doet met hun IPv6 mandaat bij de overheid - het is een intern overheids project, doet niets voor de internet aansluiting van de burger.

[ Voor 34% gewijzigd door Dreamvoid op 29-01-2024 13:27 ]

[Roetzen]

Dreamvoid schreef op maandag 29 januari 2024 @ 13:22:
[...]

Denk ik ook, maar laten we wel zijn, als er anno 2032 nog een significante groep burgers in Tsjechie is die geen IPv6 heeft, is het voor de overheid wel heel makkelijk om een simpele IPv4 CDN ervoor te zetten, in een kosten/baten afweging is dat een vrij eenvoudige keuze: een paar duizend euro voor een Cloudflare abo'tje versus ladingen kwaaie burgers.

Die paar k€ zijn alleen de directe kosten van de hardware. Je moet het ook onderhouden, dat kost al gauw veel meer dan een paar k€/jaar.

Als het doel is om alle burgers op IPv6 te zetten, dan is het eenvoudiger om een wet aan te nemen dat IPv6 verplicht beschikbaar moet zijn voor alle consumenten aansluitingen (mobiel en vast) in 2032.

Daar moeten ze dan niet mee wachten tot 2032. Dat moet en kan veel eerder.

Deze initiatieven om de overheid op IPv6 te zetten is in het algemeen bedoeld om de overheid van de legacy infrastructuur af te helpen (vanuit security/complexiteit/kosten oogpunt), niet het hele land. Idem wat de VS nu doet met hun IPv6 mandaat bij de overheid - het is een intern overheids project, doet niets voor de internet aansluiting van de burger.

Klopt, maar het geeft wel een belangrijk signaal af.

[Snow_King]

Roetzen schreef op maandag 29 januari 2024 @ 14:44:
[...]

Klopt, maar het geeft wel een belangrijk signaal af.

Je kan niet meer aan de VS overheid leveren als jouw dienst of product geen IPv6 ondersteund. Daarmee moeten heel veel vendoren dus wel aan de slag.

Zo heb ik gezien dat bepaalde storage appliances van een leverancier geen IPv6 deden voor hun NFS en iSCSI, maar sindskort doen ze dat wel. Precies vanwege het feit dat ze anders nooit meer aan de US overheid konden leveren.

[Dreamvoid]

Roetzen schreef op maandag 29 januari 2024 @ 14:44:
Die paar k€ zijn alleen de directe kosten van de hardware. Je moet het ook onderhouden, dat kost al gauw veel meer dan een paar k€/jaar.

Er is geen hardware, alleen een DNS record die naar Cloudflare wijst. Je eigen infrastructuur blijft IPv6-only.

[ Voor 6% gewijzigd door Dreamvoid op 29-01-2024 16:12 ]

[zx9r_mario]

Een IPv4 naar IPv6 reverse proxy met nginx (met $ssl_preread_server_name en $ssl_preread) werkt ook goed voor webbased applicaties. Ik gebruik het al meer dan 1 jaar voor IPv6 only servers. De IPv6 servers zelf gebruiken NAT64/DNS64.

[Roetzen]

10 jaar geleden werd er al serieus nagedacht over IPv6 only. Dit verhaal uit 2013 is nog best redelijk actueel als je de bedragen een beetje aanpast.

https://ipv6.br/media/ipv...l-IPv6-Forum-Dec-2013.pdf

[RobertMe]

Kan "dit probleem" een oorzaak hebben in het gebrek aan volledige IPv6? (/gebrek aan een GUA)

Situatie: ik heb hier al eens aangegeven een EdgeRouter bij familie te beheren die geen IPv6 doet, ook omdat die nog achter een oud Ziggo modem zonder IPv6 zit (geheel of in bridge, geen idee, maakt verder ook niet uit).
Wat ik wel heb gedaan is een Wireguard tunnel opzetten met ULAs. Zelf heb ik alles op fd00:<vlan id>:... hangen (gebruik ik intern ook voor DNS en andere statische adressering). Aan de andere kant heb ik op één VLAN (het "prive" VLAN met PCs etc) gebruik gemaakt van fd01:<vlan id>.
Vervolgens heb ik daar ook een OrangePi met ARMBian (/Debian) liggen die backups maakt van mijn systemen op basis van het fd00:... adres. Dit werkt prima en routeert netjes over de tunnel.
Op een laptop, met Win 11, en een PC, met Win 10, staan SyncThing, deze syncen alleen met een server bij mij (niet onderling), ook weer op basis van fd00:... gaat dit over de tunnel heen. Voor de laptop lijkt dit altijd goed te gaan, voor de PC niet, altijd. Waarbij een reboot van de PC het oplost (een pause => resume in SyncThing dus niet). Foutmelding dan dat andere eind niet bereikbaar is (specifiek "i/o timeout").
Net gepoogd te debuggen (op afstand, niet aan Windows gezeten, alleen SSH naar de router) maar ik snap er niks van. Op de EdgeRouter zie ik met tcpdump wel verkeer naar de server gaan, en verkeer terugkomen, maar het terugkomende verkeer lijkt in rook op te gaan. Ik zie het dus wel op de wg interface binnen komen, maar niet op de eth1.8 interface naar buiten gaan. logging enablen op de zeldzame drop rules toont ook niks aan, dus verkeer lijkt niet gedropt te worden. Terwijl op hetzelfde moment de laptop ook aan stond en die werkte prima (verkeer heen en weer). Wat foute firewall rules op de ER dan ook uitsluit. PC opnieuw opgestart, en er is meteen verbinding.

Mijn vermoeden is nu dat het mogelijk een Windows 10 quirk is, door het gebrek aan een GUA en wellicht daardoor het IP niet wordt vastgelegd in de ARP tabel van de router (/PC die niet antwoord op ARP requests), lijkt mij alleen nogal gek, want ARP kan ook gevuld worden op basis van binnenkomende verkeer (PC stuurt immers wel verkeer naar de server, alleen verdwijnt het terugkomende verkeer ergens nadat het op de wg interface binnen komt). En nog "gekker", IPv6 heeft geen ARP, maar NDP?
Alleen heb ik verder dus geen idee wat hier aan de hand kan zijn en welke voodoo er al dan niet voor zorgt dat de ER voor één systeem geen verkeer kan afleveren of iets dergelijks. En zou die, gezien er maar 1 poort is met dat subnet, eigenlijk niet sowieso het verkeer daarop naar buiten moeten sturen? Het IP adres moet zich toch daar bevinden gezien het in het subnet van die interface valt.

En wat ik de volgende keer nog eens kan laten proberen is een ipconfig /release / ipconfig /renew I guess (/even opzoeken of dat ook IPv6 meeneemt).
En bijkomende dan de vraag: verklaard het ontbreken van een GUA mogelijk dit gedrag? En is dit daarmee een mooi moment om IPv6 te regelen en te kijken om een nieuw modem te ontvangen voor een met IPv6 (in bridge) support.

Edit:
Ter verduidelijking, of zo . Ook met volledige IPv6 "aan die kant" zou ik nog steeds dezelfde setup blijven hanteren overigens. Dus een site-to-site VPN met ULA addressen.

[watabstract]

Het is toch best bizar dat IPv6 na zoveel jaren nog steeds een veelbesproken item is. Het had natuurlijk allang de wereldwijde standaard moeten zijn voor al het internetverkeer. Ik heb van de week IPv6 maar weer eens aangezet op de router. Het werkt nu eigenlijk gewoon prima. Alle devices krijgen/genereren netjes 1 of meerdere adressen. Ik heb alleen even een kunstgreep uitgehaald om de router geen IPv6 DNS server te laten broadcasten zodat DNS requests naar de lokale pi hole via IPv4 blijven lopen. Dat is geen enkel probleem. Met deze router gaat IPv4 op het lokale netwerk nooit uit dus dat is een robuuste oplossing. De reden is dat de pi 3 overdreven veel neighbor calls bleef doen op het LAN na een snelle check met Wireshark. Ik vond niet zo snel een oplossing en dus heb ik maar besloten om IPv6 op de pi uit te zetten. Daarnaast blijft de enige Windows-machine in huis een probleem hebben: binnen 10 minuten verliest de laptop zijn IPv6-adres en stopt alle connectiviteit over dat protocol. Dit herhaalt zich als de wifi-kaart even uitgezet wordt of als de laptop wordt herstart. Meerdere online tips en een reeks commando's later is het probleem niet opgelost. Geen idee wat er aan de hand is maar deze 2 issues geven wel aan dat anno 2024 IPv6 nog steeds geen 100% betrouwbaar protocol is. En dat is heel heel triest. Het voelt nog steeds teveel als een beta-feature, in 2024...

[Snow_King]

watabstract schreef op maandag 5 februari 2024 @ 00:53:
Het is toch best bizar dat IPv6 na zoveel jaren nog steeds een veelbesproken item is. Het had natuurlijk allang de wereldwijde standaard moeten zijn voor al het internetverkeer. Ik heb van de week IPv6 maar weer eens aangezet op de router. Het werkt nu eigenlijk gewoon prima. Alle devices krijgen/genereren netjes 1 of meerdere adressen. Ik heb alleen even een kunstgreep uitgehaald om de router geen IPv6 DNS server te laten broadcasten zodat DNS requests naar de lokale pi hole via IPv4 blijven lopen. Dat is geen enkel probleem. Met deze router gaat IPv4 op het lokale netwerk nooit uit dus dat is een robuuste oplossing. De reden is dat de pi 3 overdreven veel neighbor calls bleef doen op het LAN na een snelle check met Wireshark. Ik vond niet zo snel een oplossing en dus heb ik maar besloten om IPv6 op de pi uit te zetten. Daarnaast blijft de enige Windows-machine in huis een probleem hebben: binnen 10 minuten verliest de laptop zijn IPv6-adres en stopt alle connectiviteit over dat protocol. Dit herhaalt zich als de wifi-kaart even uitgezet wordt of als de laptop wordt herstart. Meerdere online tips en een reeks commando's later is het probleem niet opgelost. Geen idee wat er aan de hand is maar deze 2 issues geven wel aan dat anno 2024 IPv6 nog steeds geen 100% betrouwbaar protocol is. En dat is heel heel triest. Het voelt nog steeds teveel als een beta-feature, in 2024...

Die laatste mening met je deel ik niet. Bugs komen overal in voor. Met IPv4 heb ik ook nog steeds wel eens rare dingen waar ze uitvallen. Dat ligt niet aan het protocol :-)

IPv6 gewoon aan zetten en laten staan.

Dat v6 nog steeds niet overal is komt omdat er gewoon heel veel mensen gewoon niet technisch genoeg zijn om het echt te begrijpen. Het begint met educatie.

[Vorkie]

watabstract schreef op maandag 5 februari 2024 @ 00:53:
Het is toch best bizar dat IPv6 na zoveel jaren nog steeds een veelbesproken item is. Het had natuurlijk allang de wereldwijde standaard moeten zijn voor al het internetverkeer. Ik heb van de week IPv6 maar weer eens aangezet op de router. Het werkt nu eigenlijk gewoon prima. Alle devices krijgen/genereren netjes 1 of meerdere adressen. Ik heb alleen even een kunstgreep uitgehaald om de router geen IPv6 DNS server te laten broadcasten zodat DNS requests naar de lokale pi hole via IPv4 blijven lopen. Dat is geen enkel probleem. Met deze router gaat IPv4 op het lokale netwerk nooit uit dus dat is een robuuste oplossing. De reden is dat de pi 3 overdreven veel neighbor calls bleef doen op het LAN na een snelle check met Wireshark. Ik vond niet zo snel een oplossing en dus heb ik maar besloten om IPv6 op de pi uit te zetten. Daarnaast blijft de enige Windows-machine in huis een probleem hebben: binnen 10 minuten verliest de laptop zijn IPv6-adres en stopt alle connectiviteit over dat protocol. Dit herhaalt zich als de wifi-kaart even uitgezet wordt of als de laptop wordt herstart. Meerdere online tips en een reeks commando's later is het probleem niet opgelost. Geen idee wat er aan de hand is maar deze 2 issues geven wel aan dat anno 2024 IPv6 nog steeds geen 100% betrouwbaar protocol is. En dat is heel heel triest. Het voelt nog steeds teveel als een beta-feature, in 2024...

Ik gok dat je juist wat basisfuncties van IPv6 hebt gesloopt met je kunstgrepen

Ik zit alweer wat jaartjes in zakelijke en prive IPv6 omgevingen en zulke dingen hierboven gebeuren echt nooit.

Wel dat dingen zoals Router advertisements die verkeerd stonden, of per ongeluk dubbele routers met dezelfde PRIO had geadverteerd.

Maar ik ben het niet eens met je statement in ieder geval. Het voelt juist als de next-gen die al jaren ligt te verstoffen, want eng.

[Dreamvoid]

watabstract schreef op maandag 5 februari 2024 @ 00:53:
Ik heb alleen even een kunstgreep uitgehaald om de router geen IPv6 DNS server te laten broadcasten zodat DNS requests naar de lokale pi hole via IPv4 blijven lopen.

Kan je niet gewoon de router het IPv6 adres van de Pi laten adverteren als DNS server? Dan hoef je geen kunstgrepen uit te halen.

[RobertMe]

Dreamvoid schreef op maandag 5 februari 2024 @ 11:25:
[...]

Kan je niet gewoon de router het IPv6 adres van de Pi laten adverteren als DNS server? Dan hoef je geen kunstgrepen uit te halen.

De Pi heeft geen IPv6 adres:

De reden is dat de pi 3 overdreven veel neighbor calls bleef doen op het LAN na een snelle check met Wireshark. Ik vond niet zo snel een oplossing en dus heb ik maar besloten om IPv6 op de pi uit te zetten.

[Roetzen]

RobertMe schreef op maandag 5 februari 2024 @ 12:36:
[...]

De Pi heeft geen IPv6 adres:

[...]

Omdat ie dat uitgezet heeft. Tja, dat had ie dus niet moeten doen....

[ Voor 16% gewijzigd door Roetzen op 05-02-2024 12:49 ]

[Snow_King]

RobertMe schreef op maandag 5 februari 2024 @ 12:36:
[...]

De Pi heeft geen IPv6 adres:

[...]

En als deze veel ARP IPv4 requests zou doen, zou je hem dan ook uitzetten?

Die ND requests kunnen heel veel redenen hebben.

[RobertMe]

Roetzen schreef op maandag 5 februari 2024 @ 12:46:
[...]

Omdat ie dat uitgezet heeft. Tja, dat had ie dus niet moeten doen....

Snow_King schreef op maandag 5 februari 2024 @ 12:48:
[...]

En als deze veel ARP IPv4 requests zou doen, zou je hem dan ook uitzetten?

Die ND requests kunnen heel veel redenen hebben.

To be clear, ik vind het ook helemaal geen logische zet, en een raar betoog.

[Snow_King]

RobertMe schreef op maandag 5 februari 2024 @ 12:57:
[...]


[...]

To be clear, ik vind het ook helemaal geen logische zet, en een raar betoog.

Ah, check. Antwoord blijft het zelfde :-) Stukje van de quote miste dan denk ik.

[Roetzen]

watabstract schreef op maandag 5 februari 2024 @ 00:53:
Het is toch best bizar dat IPv6 na zoveel jaren nog steeds een veelbesproken item is. Het had natuurlijk allang de wereldwijde standaard moeten zijn voor al het internetverkeer. Ik heb van de week IPv6 maar weer eens aangezet op de router.

"Maar weer eens aan gezet". Dus je had het weer eens uit staan. Ik heb ook ooit een keer IPv6 aan gezet. Dat zal een jaar of vijftien geleden zijn geweest. Bij WinXp stond het niet bij default aan, je moest het expliciet aan zetten. Daarna heb ik het nooit meer uit gezet.

Maar jij hebt het blijkbaar vaker uit gezet en je zet het nu pas weer aan. En dan ben je verbaasd dat het nog geen wereldwijde standaard is.

Het werkt nu eigenlijk gewoon prima. Alle devices krijgen/genereren netjes 1 of meerdere adressen. Ik heb alleen even een kunstgreep uitgehaald om de router geen IPv6 DNS server te laten broadcasten zodat DNS requests naar de lokale pi hole via IPv4 blijven lopen. Dat is geen enkel probleem. Met deze router gaat IPv4 op het lokale netwerk nooit uit dus dat is een robuuste oplossing.

Een oplossing voor welk probleem? En zo robuust is jouw oplossing niet als het afhankelijk is van het "eeuwig" in de lucht houden van IPv4.

De reden is dat de pi 3 overdreven veel neighbor calls bleef doen op het LAN na een snelle check met Wireshark.

En wat is precies het probleem?

Ik vond niet zo snel een oplossing en dus heb ik maar besloten om IPv6 op de pi uit te zetten.

Ik vermoed dat het middel erger is dan de kwaal.

[watabstract]

Mensen hier lezen niet allemaal even goed. 🙈 IPv6 op de laptop met Windows 11 heb ik niets in aangepast. Dat werkt gewoon out of the box niet. De Pi heb ik IPv6 bewust op uitgezet vanwege de bizarre aantallen neighbor ICMP calls. Uiteraard werkt IPv6 daarop niet meer maar dat is dus juist de bedoeling.

IPv6 op de laptop werkte al voor alle kunstgrepen niet meer. Dat is juist de aanleiding geweest om het LAN verkeer eens wat te analyseren. Die aanpassingen hebben niks kapot gemaakt. Wat niet werkte werkte daarvoor al niet, en wat al werkte dat werkt gewoon nog steeds.

[watabstract]

Roetzen schreef op maandag 5 februari 2024 @ 14:47:
[...]

"Maar weer eens aan gezet". Dus je had het weer eens uit staan. Ik heb ook ooit een keer IPv6 aan gezet. Dat zal een jaar of vijftien geleden zijn geweest. Bij WinXp stond het niet bij default aan, je moest het expliciet aan zetten. Daarna heb ik het nooit meer uit gezet.

Maar jij hebt het blijkbaar vaker uit gezet en je zet het nu pas weer aan. En dan ben je verbaasd dat het nog geen wereldwijde standaard is.

[...]

Een oplossing voor welk probleem? En zo robuust is jouw oplossing niet als het afhankelijk is van het "eeuwig" in de lucht houden van IPv4.

[...]

En wat is precies het probleem?

[...]

Ik vermoed dat het middel erger is dan de kwaal.

Aangezet op de router. Die is een paar jaar geleden nieuw gekocht en IPv6 staat daarop standaard uit. Dus dat heb ik bewust aan moeten zetten.

[watabstract]

Snow_King schreef op maandag 5 februari 2024 @ 09:17:
[...]

Die laatste mening met je deel ik niet. Bugs komen overal in voor. Met IPv4 heb ik ook nog steeds wel eens rare dingen waar ze uitvallen. Dat ligt niet aan het protocol :-)

IPv6 gewoon aan zetten en laten staan.

Dat v6 nog steeds niet overal is komt omdat er gewoon heel veel mensen gewoon niet technisch genoeg zijn om het echt te begrijpen. Het begint met educatie.

Ik bedoel niet dat het protocol zelf beta is. Mag hopen van niet decennia later.. Nee de implementatie ervan in Windows lijkt buggy. Er is 1 device op het LAN waarop IPv6 niet werkt en dat is op een laptop met Windows 11. Alle andere (Ubuntu, Android) hebben nergens last van. Ik heb IPv6 'gewoon' aangezet en de Windows laptop doet het 'gewoon' niet als enige. En als je na meerdere pogingen op de laptop zelf het niet aan de praat stabiel krijgt dan ga je je netwerk analyseren. Zo kwam ik er onder andere achter dat mijn router zichzelf als IPv6 DNS server adverteert en dat wil ik helemaal niet. Dus heb ik dat met een simpel scriptje uitgezet. Als je dual stack draait dan kun je prima zonder een IPv6 DNS server.

[watabstract]

Nog even voor de goede orde: er spelen 2 problemen. Het belangrijkste probleem is dat Windows 11 telkens binnen een paar minuten na verbinden het IPv6-adres verliest. Dat is het probleem dat ik probeer te tacklen. Daarnaast stuurt de Pi 3 met Raspberry OS overmatig veel neighbor calls het netwerk op. Ik heb geen idee waarom en dat ga ik tzt ook nog een keer uitzoeken. Vanwege het probleem met Windows 11 heb ik in het geval van de Pi voor een workaround gekozen door op de Pi IPv6 tijdelijk uit te schakelen en de router met een simpel scriptje even geen IPv6 DNS server te laten broadcasten. Die aanpassing werkt prima. Alle apparaten met een stabiele IPv6 verbinding kunnen nog prima IPv6 verbindingen opzetten. Ze doen alleen DNS requests naar de Pi via IPv4 maar dat is voor nu OK.

[Roetzen]

watabstract schreef op maandag 5 februari 2024 @ 21:49:
[...]

Aangezet op de router. Die is een paar jaar geleden nieuw gekocht en IPv6 staat daarop standaard uit. Dus dat heb ik bewust aan moeten zetten.

Hmmm... Bij mij zouden er dan al een paar lampjes gaan branden. Als op een router IPv6 bij verstek uitgeschakeld is, wat is er dan nog meer niet ingeschakeld waarvan ik zou verwachten dat het aanstaat? De firewall? Ook van een vier jaar oude router verwacht ik gewoon dat IPv6 per default aan staat. Zo niet dan word ik wantrouwend.
In 2009 heb ik al besloten geen nieuw netwerkspul meer te kopen dat geen IPv6 ondersteunt. Begin dit jaar heb ik dat aangescherpt met de eis dat het moet kunnen werken in een IPv6 only omgeving. Dus ik kan leven met een router waarbij IPv4 bij default uit staat. Dan weet ik dat ie getest is in een IPv6 only omgeving.

[Roetzen]

watabstract schreef op maandag 5 februari 2024 @ 21:56:
[...]

Ik bedoel niet dat het protocol zelf beta is. Mag hopen van niet decennia later.. Nee de implementatie ervan in Windows lijkt buggy. Er is 1 device op het LAN waarop IPv6 niet werkt en dat is op een laptop met Windows 11.

Ik heb geen ervaring met Win 11, ik ben nog even steken bij Win 10, maar ik heb wel wat moeite met de aanname dat het probleem bij Windows zit. Dan zou dat toch al lang bekend zijn geworden.

Alle andere (Ubuntu, Android) hebben nergens last van. Ik heb IPv6 'gewoon' aangezet en de Windows laptop doet het 'gewoon' niet als enige. En als je na meerdere pogingen op de laptop zelf het niet aan de praat stabiel krijgt dan ga je je netwerk analyseren.

En dan zou mijn verdenking toch als eerste op die router vallen. Daar is bij mij dus al een lampje gaan branden. Heb je die laptop al eens op een ander netwerk getest? Bij de buurman? Op het werk? Heb je dan ook problemen met IPv6?

Zo kwam ik er onder andere achter dat mijn router zichzelf als IPv6 DNS server adverteert en dat wil ik helemaal niet. Dus heb ik dat met een simpel scriptje uitgezet.

Waarom? Wat is er mis met een router die als eerste een DNS verzoek in ontvangst neemt? Waarom wil je dat niet?

Als je dual stack draait dan kun je prima zonder een IPv6 DNS server.

Het moet wel kunnen, maar je moet het helemaal niet willen. Een deel van het werk weer via IPv4 laten afwikkelen is een stap terug. Dual stack is niet het einddoel, Dual Stack is halverwege. Uiteindelijk moeten we naar IPv6 only.

[Jef61]

Roetzen schreef op dinsdag 6 februari 2024 @ 14:15:
[...]

Ik heb geen ervaring met Win 11, ik ben nog even steken bij Win 10, maar ik heb wel wat moeite met de aanname dat het probleem bij Windows zit. Dan zou dat toch al lang bekend zijn geworden.

Idd, ik heb verschillende Win11 laptop's / PC's thuis in mijn netwerk staan (werk en privé) maar deze werken allemaal vlekkeloos met IPv6. Ik heb in de browsers zo'n IPvFoo icoontje staan en zie meteen als IPv6 het niet meer doet (bv als ik zelf of mijn provider zit te klooien met de IPv6 settings).

[watabstract]

Roetzen schreef op dinsdag 6 februari 2024 @ 14:01:
[...]

Hmmm... Bij mij zouden er dan al een paar lampjes gaan branden. Als op een router IPv6 bij verstek uitgeschakeld is, wat is er dan nog meer niet ingeschakeld waarvan ik zou verwachten dat het aanstaat? De firewall? Ook van een vier jaar oude router verwacht ik gewoon dat IPv6 per default aan staat. Zo niet dan word ik wantrouwend.
In 2009 heb ik al besloten geen nieuw netwerkspul meer te kopen dat geen IPv6 ondersteunt. Begin dit jaar heb ik dat aangescherpt met de eis dat het moet kunnen werken in een IPv6 only omgeving. Dus ik kan leven met een router waarbij IPv4 bij default uit staat. Dan weet ik dat ie getest is in een IPv6 only omgeving.

Dit is een prima functionerende Asus ET8 mesh router (zonder mesh want hangt nu geen extra node aan). Daar draait AsusWRT-Merlin op en daarop staat IPv6 out of the box uit. Of je dat per se moet wantrouwen lijkt me beetje overdreven. Er zijn immers verschillende implementaties (stateful, stateless, native, 64tunnel etc). Dus lijkt mij niet zo gek dat het standaard uit staat.

[watabstract]

Roetzen schreef op dinsdag 6 februari 2024 @ 14:15:
[...]

Ik heb geen ervaring met Win 11, ik ben nog even steken bij Win 10, maar ik heb wel wat moeite met de aanname dat het probleem bij Windows zit. Dan zou dat toch al lang bekend zijn geworden.

Dit kan prima een uitzonderlijk geval zijn. Ik rapporteer slechts wat ik ervaar op dit systeem.

[...]

En dan zou mijn verdenking toch als eerste op die router vallen. Daar is bij mij dus al een lampje gaan branden. Heb je die laptop al eens op een ander netwerk getest? Bij de buurman? Op het werk? Heb je dan ook problemen met IPv6?

Ik werk 100% thuis (werkgever zit over de grens) en ik kan het niet even in de buurt ergens anders testen dus helaas.

[...]

Waarom? Wat is er mis met een router die als eerste een DNS verzoek in ontvangst neemt? Waarom wil je dat niet?

Dat heb ik al vrij uitvoerig beschreven toch? Ik gebruik een pi hole voor mijn DNS. In de router staat geen IPv6 DNS server ingesteld en dan adverteert de router zichzelf als zodanig. Dat wil ik niet want alle DNS requests moeten naar de pi (hole).

[...]

Het moet wel kunnen, maar je moet het helemaal niet willen. Een deel van het werk weer via IPv4 laten afwikkelen is een stap terug. Dual stack is niet het einddoel, Dual Stack is halverwege. Uiteindelijk moeten we naar IPv6 only.

Uiteraard maar 1 ding tegelijk. Ik wil eerst die Windows laptop vlot trekken.

[Jerrythafast]

Zou het kunnen zijn dat Windows de IPv6 connectiviteit weer uitschakelt als blijkt dat er geen DNS server bereikbaar is over IPv6? (Geen idee of dat logisch is hoor, ik doe maar een gok...)

[Dreamvoid]

Dat zou niet zo logisch zijn, een IPv6 DNS server heeft niets te maken met IPv6 connectiviteit.

[RobertMe]

Dreamvoid schreef op vrijdag 9 februari 2024 @ 15:32:
Dat zou niet zo logisch zijn, een IPv6 DNS server heeft niets te maken met IPv6 connectiviteit.

Niet logisch, wellicht, maar ook niet onmogelijk.

Ik heb hier zelf vorig jaar ergens geschreven dat ik ook zo'n soort quirk in Android gevonden heb. Ik heb een VLAN dat over een VPN naar buiten gaat. Dit gebruik ik af en toe ook om semi anoniem te kunnen internetten. De VPN geeft hiervoor een ULA adres uit, en zelf heb ik op het VLAN ook weer een ULA die ik doe NATen. Mijn DNS servers heb ik echter in Docker draaien waarbij Docker een eigen ULA range gebruikt (per host). De Docker host stuurt ook netjes een RA met routing informatie ("subnet X is bij mij te vinden"). En deze RA communiceert ook de DNS server die dus naar het andere subnet verwijst. Op alle VLANs en alle apparaten werkt dit ook prima. Bv het prive VLAN zit op fd00:10::/64, en daarnaast ISP prefix met ID 10, de router heeft vervolgens ook een fd00:10:1::/64 voor de Docker containers die aan (/achter) het prive VLAN hangen en de DNS server voor het prive VLAN is fd00:10:1::53 (dn hetzelfde doe ik op de "server", alleen dan met fd00:10:2::/64). Dit werkt dus ook prima op Android en de DNS server is netjes bereikbaar. Op dit specifieke VLAN dat over een VPN gaat zit echter geen GUA prefix (wat dus überhaupt niet door de VPN server wordt uitgegeven, en doordat ik het nig eens (dubbel) NAT). IPv6 connectiviteit op Android is er prima, behalve... dat die de IPv6 DNS server niet accepteert Deze staat in ieder geval niet bij de netwerk eigenschappen / status, en ik twijfel nu even of ik met network tools (Net Analyzer app) wel of niet een DNS query naar dat IPv6 adres kan doen.

[Vorkie]

Jerrythafast schreef op woensdag 7 februari 2024 @ 10:56:
Zou het kunnen zijn dat Windows de IPv6 connectiviteit weer uitschakelt als blijkt dat er geen DNS server bereikbaar is over IPv6? (Geen idee of dat logisch is hoor, ik doe maar een gok...)

Nee dat maakt echt niets uit

Ik heb use cases gehad (helaas) waar IPv6 aanstond op het subnet van de clients, maar op de server subnetten niet, waaronder de AD controllers.

De clients kregen dus geen DNS servers op IPv6 aangeboden, alleen op de IPv4 stack waren er DNS servers configureert in de DHCP scope.

Desalniettemin deed IPv6 connectiviteit precies wat het moest doen naar het internet, met IPv4 only DNS servers op de IPv4 stack.

Als je dan AAAA responses uitzet op je DNS server, is het een andere zaak

[watabstract]

Jerrythafast schreef op woensdag 7 februari 2024 @ 10:56:
Zou het kunnen zijn dat Windows de IPv6 connectiviteit weer uitschakelt als blijkt dat er geen DNS server bereikbaar is over IPv6? (Geen idee of dat logisch is hoor, ik doe maar een gok...)

Dat zou bijzonder vreemd zijn maar het wegvallen van een IPv6-adres na enige tijd is niet minder vreemd dus ik sluit niks uit. Ik ga dit binnenkort wel eens testen want ik wil dit zeker wel uittesten. Bedankt voor de tip!

Ik heb nog eens met Wireshark gekeken maar er zijn voldoende router advertisements (pakweg elke 10 seconde, beetje veel maar dat lijkt een AsusWRT dingetje te zijn) met valide inhoud (juiste prefix, 600 seconde geldigheid etc) en tóch negeert Windows die compleet. Ik heb ook de firewall rules nagekeken maar die laten alle inkomende ICMPv6 verkeer expliciet toe. Het is me echt een raadsel.

Ik ben zelfs zover gegaan om de Mediatek netwerkkaart te vervangen door een Intel AX210. Datzelfde type doet in een laptop met Linux feilloos IPv6 maar helaas lost ook dat het probleem niet op.

Ik probeer sowieso de suggestie van @Jerrythafast en daarnaast maak ik binnenkort eens een Kubuntu live USB stick om mee te booten en te kijken of het echt niet aan de hardware ligt. Als het daarmee gewoon werkt dan blijft Windows 11 toch echt over als de schuldige. Helaas zijn de berichten rondom dit probleem schaars en nogal obscuur. Gelukkig is IPv6 nog geen halszaak maar dat het nog steeds zoveel gedoe op kan leveren is wel een dingetje.

[watabstract]

Ik kan inmiddels rapporteren dat IPv6 met Linux (Kubuntu) vanaf een live USB feilloos werkt en blijft werken. Na ongeveer een uur is de IPv6-verbinding nog steeds intact. De Tweakers frontpage laadt middels IPv6 volgens de Firefox network monitor en ook website v6.testmyipv6.com blijft het doen. Met de hardware is er dus niets aan de hand.

[FutureCow]

Ik probeer ook voor het eerst een IPv6 netwerk op te zetten thuis. Maar loop een beetje vast.
In het kort mij instellingen:
EdgeRouter die via DHCPv6 een IPv6 adres en een prefix krijgt. Via slaac wordt deze prefix doorgegeven aan de rest van de devices in het netwerk. Dit werkt ondertussen allemaal prima. Om dit werkend te krijgen heb ik wel de MTU voor de WAN moeten aanpassen naar 1420 en die van PPPoE verbinding naar 1412, mss hierbij op 1372 gezet.
Alle apparaten in het netwerk krijgen dan een mooi global IPv6 adres, ik kan naar alle apparaten pingen, ook naar verschillende adressen werkt het zonder problem en krijg ik netjes een response terug.
Als ik naar google.com ga, is dit geen enkel probleem, pagina wordt geopend en ik kan zoeken zonder problemen. Maar de meeste andere pagina's (bijv tweakers.net) blijven heel lang laden, zonder dat er een pagina komt. Mijn idee was dat dit een MTU probleem was, dus wat verschillende lagere waarden getest, tot 1288/1280/1240 (wan/PPPoE/mss) aan toe. Helaas blijven de pagina's niet openen. Ook een curl -v eindigt in een time-out. Wat kan ik verder proberen om te kunnen kijken wat er fout gaat?

ipv6-test.com werkt bijvoorbeeld ook niet, traceroute laat dit zien:

code:

traceroute -6 ipv6-test.com
traceroute to ipv6-test.com (2001:41d0:701:1100::29c8), 30 hops max, 80 byte packets
 1  2a0d:x:x:1:x:x:x:x (2a0d:x:x:1:x:x:x:x)  0.409 ms  0.491 ms  0.549 ms
 2  2a05:3600:0:29::2 (2a05:3600:0:29::2)  3.274 ms  3.537 ms  3.760 ms
 3  2a05:3600:0:29::1 (2a05:3600:0:29::1)  3.089 ms  3.474 ms  3.571 ms
 4  2a05:3600:0:28::1 (2a05:3600:0:28::1)  3.392 ms  3.451 ms  3.857 ms
 5  * * *
 6  2001:41d0:aaaa:100::17 (2001:41d0:aaaa:100::17)  14.679 ms  26.028 ms 2001:41d0:aaaa:100::3 (2001:41d0:aaaa:100::3)  13.181 ms
 7  2001:41d0:aaaa:100::13 (2001:41d0:aaaa:100::13)  15.900 ms 2001:41d0:aaaa:100::3 (2001:41d0:aaaa:100::3)  22.787 ms 2001:41d0:aaaa:100::11 (2001:41d0:aaaa:100::11)  18.434 ms
 8  2001:41d0:aaaa:100::8 (2001:41d0:aaaa:100::8)  3.224 ms *  3.021 ms
 9  * * *
10  2001:41d0:0:50::5:f943 (2001:41d0:0:50::5:f943)  11.450 ms 2001:41d0:0:50::5:f945 (2001:41d0:0:50::5:f945)  11.291 ms  11.027 ms
11  2001:41d0:0:50::5:38fd (2001:41d0:0:50::5:38fd)  11.270 ms 2001:41d0:0:50::5:3901 (2001:41d0:0:50::5:3901)  11.120 ms 2001:41d0:0:50::5:38fd (2001:41d0:0:50::5:38fd)  11.299 ms
12  2001:41d0:0:1:3::4883 (2001:41d0:0:1:3::4883)  11.013 ms 2001:41d0:0:1:3::45bf (2001:41d0:0:1:3::45bf)  11.219 ms 2001:41d0:0:1:3::4881 (2001:41d0:0:1:3::4881)  11.003 ms
13  2001:41d0:0:1:3::48af (2001:41d0:0:1:3::48af)  12.478 ms  12.636 ms 2001:41d0:0:1:3::48b1 (2001:41d0:0:1:3::48b1)  12.532 ms
14  2001:41d0:0:1:3::4aed (2001:41d0:0:1:3::4aed)  11.285 ms  11.076 ms  11.016 ms
15  * * *
16  2001:41d0:701:1100::29c8 (2001:41d0:701:1100::29c8)  11.315 ms  11.006 ms  11.071 ms

[ Voor 42% gewijzigd door FutureCow op 14-02-2024 23:20 ]

[Charlie_Root]

FutureCow schreef op woensdag 14 februari 2024 @ 22:59:
Ik probeer ook voor het eerst een IPv6 netwerk op te zetten thuis. Maar loop een beetje vast.
In het kort mij instellingen:
EdgeRouter die via DHCPv6 een IPv6 adres en een prefix krijgt. Via slaac wordt deze prefix doorgegeven aan de rest van de devices in het netwerk. Dit werkt ondertussen allemaal prima. Om dit werkend te krijgen heb ik wel de MTU voor de WAN moeten aanpassen naar 1420 en die van PPPoE verbinding naar 1412, mss hierbij op 1372 gezet.
Alle apparaten in het netwerk krijgen dan een mooi global IPv6 adres, ik kan naar alle apparaten pingen, ook naar verschillende adressen werkt het zonder problem en krijg ik netjes een response terug.
Als ik naar google.com ga, is dit geen enkel probleem, pagina wordt geopend en ik kan zoeken zonder problemen. Maar de meeste andere pagina's (bijv tweakers.net) blijven heel lang laden, zonder dat er een pagina komt. Mijn idee was dat dit een MTU probleem was, dus wat verschillende lagere waarden getest, tot 1288/1280/1240 (wan/PPPoE/mss) aan toe. Helaas blijven de pagina's niet openen. Ook een curl -v eindigt in een time-out. Wat kan ik verder proberen om te kunnen kijken wat er fout gaat?

ipv6-test.com werkt bijvoorbeeld ook niet, traceroute laat dit zien:

code:

traceroute -6 ipv6-test.com
traceroute to ipv6-test.com (2001:41d0:701:1100::29c8), 30 hops max, 80 byte packets
 1  2a0d:x:x:1:x:x:x:x (2a0d:x:x:1:x:x:x:x)  0.409 ms  0.491 ms  0.549 ms
 2  2a05:3600:0:29::2 (2a05:3600:0:29::2)  3.274 ms  3.537 ms  3.760 ms
 3  2a05:3600:0:29::1 (2a05:3600:0:29::1)  3.089 ms  3.474 ms  3.571 ms
 4  2a05:3600:0:28::1 (2a05:3600:0:28::1)  3.392 ms  3.451 ms  3.857 ms
 5  * * *
 6  2001:41d0:aaaa:100::17 (2001:41d0:aaaa:100::17)  14.679 ms  26.028 ms 2001:41d0:aaaa:100::3 (2001:41d0:aaaa:100::3)  13.181 ms
 7  2001:41d0:aaaa:100::13 (2001:41d0:aaaa:100::13)  15.900 ms 2001:41d0:aaaa:100::3 (2001:41d0:aaaa:100::3)  22.787 ms 2001:41d0:aaaa:100::11 (2001:41d0:aaaa:100::11)  18.434 ms
 8  2001:41d0:aaaa:100::8 (2001:41d0:aaaa:100::8)  3.224 ms *  3.021 ms
 9  * * *
10  2001:41d0:0:50::5:f943 (2001:41d0:0:50::5:f943)  11.450 ms 2001:41d0:0:50::5:f945 (2001:41d0:0:50::5:f945)  11.291 ms  11.027 ms
11  2001:41d0:0:50::5:38fd (2001:41d0:0:50::5:38fd)  11.270 ms 2001:41d0:0:50::5:3901 (2001:41d0:0:50::5:3901)  11.120 ms 2001:41d0:0:50::5:38fd (2001:41d0:0:50::5:38fd)  11.299 ms
12  2001:41d0:0:1:3::4883 (2001:41d0:0:1:3::4883)  11.013 ms 2001:41d0:0:1:3::45bf (2001:41d0:0:1:3::45bf)  11.219 ms 2001:41d0:0:1:3::4881 (2001:41d0:0:1:3::4881)  11.003 ms
13  2001:41d0:0:1:3::48af (2001:41d0:0:1:3::48af)  12.478 ms  12.636 ms 2001:41d0:0:1:3::48b1 (2001:41d0:0:1:3::48b1)  12.532 ms
14  2001:41d0:0:1:3::4aed (2001:41d0:0:1:3::4aed)  11.285 ms  11.076 ms  11.016 ms
15  * * *
16  2001:41d0:701:1100::29c8 (2001:41d0:701:1100::29c8)  11.315 ms  11.006 ms  11.071 ms

Lijkt wel echt iets met MTU/tcp-mss6


Ik heb het volgende op mijn Edgerouter:
MTU 1512 op interface
MTU 1508 op vlan 6
MTU 1500 op pppoe0

Firewall options voor mss:

code:

 mss-clamp {
     interface-type pppoe
     mss 1452
 }
 mss-clamp6 {
     interface-type pppoe
     mss 1280
 }

[FutureCow]

Charlie_Root schreef op donderdag 15 februari 2024 @ 09:21:
[...]


Lijkt wel echt iets met MTU/tcp-mss6


Ik heb het volgende op mijn Edgerouter:
MTU 1512 op interface
MTU 1508 op vlan 6
MTU 1500 op pppoe0

Firewall options voor mss:

code:

 mss-clamp {
     interface-type pppoe
     mss 1452
 }
 mss-clamp6 {
     interface-type pppoe
     mss 1280
 }

mss-clamp6 op 1280 was uiteindelijk de truc, MTU voor eth0/pppoe konden op 1420/1412 blijven staan. Bedankt!

[iworx]

Voor de Belgische Telenet klanten die IPv6 gebruiken op hun eigen OPNsense / PFsense / ... router :

Telenet wijzigt de Prefix Delegation Size van 60 naar 57. Die komt live na een rollende firmware update.

[Snow_King]

iworx schreef op donderdag 7 maart 2024 @ 10:19:
Voor de Belgische Telenet klanten die IPv6 gebruiken op hun eigen OPNsense / PFsense / ... router :

Telenet wijzigt de Prefix Delegation Size van 60 naar 57. Die komt live na een rollende firmware update.

Is er ook een reden bekend van deze aanpassing in subnet grootte?

[Dreamvoid]

iworx schreef op donderdag 7 maart 2024 @ 10:19:
Voor de Belgische Telenet klanten die IPv6 gebruiken op hun eigen OPNsense / PFsense / ... router :

Telenet wijzigt de Prefix Delegation Size van 60 naar 57. Die komt live na een rollende firmware update.

Een /57 is vrij ongebruikelijk, is het geen /56?

[iworx]

Snow_King schreef op donderdag 7 maart 2024 @ 10:38:
[...]

Is er ook een reden bekend van deze aanpassing in subnet grootte?

Zo zou je telkens dezelfde /57 krijgen voor de router.

Dreamvoid schreef op donderdag 7 maart 2024 @ 10:46:
[...]

Een /57 is vrij ongebruikelijk, is het geen /56?

Heel zeker dat het 57 is

code:

root@opn:~ # ifctl -6pi igc0
2a02:1810:xxxx:xxxx::/57

[Dreamvoid]

interessant - gebruiken ze de andere /57 voor IPTV ofzo?