Het grote IPv6 topic

[Roetzen]

ANdrode schreef op vrijdag 5 juni 2020 @ 21:20:
[...]


Ik heb gisteren niet gekeken maar nu zijn er in ieder geval plaatsen vrij

Ik heb mij met succes aangemeld.

[CAPSLOCK2000]

Omdat @overhyped verstandig is repliceer ik een stukje uit [Freedom] Ervaringen & Discussie om hier verder te discussieren.

CAPSLOCK2000 schreef op zaterdag 6 juni 2020 @ 12:30:
[...]
Ik heb mijn netwerk statisch geconfigureerd en draai een dummy dhcp die af en toen een DHCPv6-PD verzoek stuurt om de server tevreden te houden. Dat zou moeten werken bij iedere provider die statische adressen levert.

overhyped schreef op zaterdag 6 juni 2020 @ 14:27:
Een beetje off-topic, maar waar[om] zou je?

Zodat ik statische adressen kan gebruiken voor mijn routers, switches, servers en firewalls. De kunstgreep is eenvoudiger dan de "correcte" oplossing. Zo'n dummy dhcp client is super eenvoudig. De dhcp-software moet je toch wel draaien, ik heb alleen het stuk van de config weggegooid dat iets doet met de lease, veel simpeler dan dat wordt een configuratie niet.
De "correcte" oplossing waarbij alles dynamisch is en adressen (in theorie) op ieder moment kunnen veranderen is een stuk ingewikkelder om te beheren en/of gaat stuk als je internetverbinding uitvalt.

overhyped schreef op zaterdag 6 juni 2020 @ 16:12:
Alleen als de internet verbinding langer uit valt dan dat de lease geldig is dan klopt dat ja. Ik zal de discussie over de (on)zin van statische adressering in zowel legacy, als ipv6 voor een ander moment bewaren

@overhyped, ik ben wel benieuwd naar jouw visie op de (on)zin van statische adressen.

Ik zal zelf maar beginnen met met mijn eigen positie uit te leggen, namelijk dat de wereld nog niet klaar is voor volleidig dynamische adressen voor routers, switches, firewalls en andere netwerkcomponenten. Voor eindpunten (telefoons & pcs) werkt dynamisch prima. De nadruk ligt daarbij op adressen die veranderen. DHCP gebruiken om steeds dezelfde adressen toe te kennen is wel te doen (maar ik vind het niet nuttig).

Idealiter zou alles dynamisch werken, maar hoe meer bewegende onderdelen iets heeft, hoe fragieler het wordt. Ik zie het niet zitten om mijn firewalls zo op te zetten dat de regels dynamisch worden aangepast als een van m'n servers een ander IP-adres krijgt. Het is in theorie mogelijk, maar mij veel te complex en fragiel.

Er is een school die zegt dat je IP-adressen helemaal los moet laten als beveiligingsmiddel. Daar ben ik het op zich mee eens, maar mijn netwerk is daar nog niet klaar voro. Mijn switches kunnen niet allemaal overweg met dynamische adressen, en het oplossen van storingen en problemen wordt ook erg lastig als ik die apparatuur niet terug kan vinden op vaste adressen, zeker als ik er niet bij kan met een seriele kabel. Dat is vast op te lossen door nieuwe switches te kopen maar ik geef al meer uit aan IT dan menig klein bedrijf.

Als ik dynamische adressen zou gebruiken voor dit soort apparatuur wordt het ook belangrijk om high-available DHCP & dynamische DNS-diensten te hebben en dat maakt de boel weer complexer. In alle eerlijkheid heb ik die systemen al, maar als virtuele machines. De servers waar de VM's op draaien kan ik dus moeilijk via DHCP configureren.

Ik wil overigens niet zeggen dat een volledig dynamische situatie onbereikbaar is. Een fulltime team professionele beheerders met voldoende tijd en budget zal het vast wel lukken, maar dat heb ik niet bij mij thuis

Als ik langer nadenk over hoe ik bij mij thuis kan overschakelen naar dynamische adressen dan kom ik uit bij private vlans. Dan heb je zeg maar 1 vlan per apparaat en bepaal je met ACLs wie met wie mag praten. Op het eerste gezicht is dat een mooie oplossing, maar uiteindelijk is het vooral het verschuiven van het probleem. Waar je voorheen 1 vast adres per apparaat had, heb je nu 1 vlan per apparaat. Waar je voorheen firewall ACLs (L3) had heb je nu switch ACLs (L2), die een stuk minder expressief zijn.

Maar goed, ik ben meer benieuwd naar andere visies en hoe je zo'n dynamisch systeem wel goed opzet.

[overhyped]

Ik loop nu met m’n vriendin in een pretpark (ideaal zo tijdens Corona, lekker rustig) maar ga even de tijd nemen thuis achter m’n PC om een reactie waardig aan deze post te geven

CAPSLOCK2000 schreef op zondag 7 juni 2020 @ 13:02:
Omdat @overhyped verstandig is repliceer ik een stukje uit [Freedom] Ervaringen & Discussie om hier verder te discussieren.


[...]


[...]


[...]


[...]


@overhyped, ik ben wel benieuwd naar jouw visie op de (on)zin van statische adressen.

Ik zal zelf maar beginnen met met mijn eigen positie uit te leggen, namelijk dat de wereld nog niet klaar is voor volleidig dynamische adressen voor routers, switches, firewalls en andere netwerkcomponenten. Voor eindpunten (telefoons & pcs) werkt dynamisch prima. De nadruk ligt daarbij op adressen die veranderen. DHCP gebruiken om steeds dezelfde adressen toe te kennen is wel te doen (maar ik vind het niet nuttig).

Idealiter zou alles dynamisch werken, maar hoe meer bewegende onderdelen iets heeft, hoe fragieler het wordt. Ik zie het niet zitten om mijn firewalls zo op te zetten dat de regels dynamisch worden aangepast als een van m'n servers een ander IP-adres krijgt. Het is in theorie mogelijk, maar mij veel te complex en fragiel.

Er is een school die zegt dat je IP-adressen helemaal los moet laten als beveiligingsmiddel. Daar ben ik het op zich mee eens, maar mijn netwerk is daar nog niet klaar voro. Mijn switches kunnen niet allemaal overweg met dynamische adressen, en het oplossen van storingen en problemen wordt ook erg lastig als ik die apparatuur niet terug kan vinden op vaste adressen, zeker als ik er niet bij kan met een seriele kabel. Dat is vast op te lossen door nieuwe switches te kopen maar ik geef al meer uit aan IT dan menig klein bedrijf.

Als ik dynamische adressen zou gebruiken voor dit soort apparatuur wordt het ook belangrijk om high-available DHCP & dynamische DNS-diensten te hebben en dat maakt de boel weer complexer. In alle eerlijkheid heb ik die systemen al, maar als virtuele machines. De servers waar de VM's op draaien kan ik dus moeilijk via DHCP configureren.

Ik wil overigens niet zeggen dat een volledig dynamische situatie onbereikbaar is. Een fulltime team professionele beheerders met voldoende tijd en budget zal het vast wel lukken, maar dat heb ik niet bij mij thuis

Als ik langer nadenk over hoe ik bij mij thuis kan overschakelen naar dynamische adressen dan kom ik uit bij private vlans. Dan heb je zeg maar 1 vlan per apparaat en bepaal je met ACLs wie met wie mag praten. Op het eerste gezicht is dat een mooie oplossing, maar uiteindelijk is het vooral het verschuiven van het probleem. Waar je voorheen 1 vast adres per apparaat had, heb je nu 1 vlan per apparaat. Waar je voorheen firewall ACLs (L3) had heb je nu switch ACLs (L2), die een stuk minder expressief zijn.

Maar goed, ik ben meer benieuwd naar andere visies en hoe je zo'n dynamisch systeem wel goed opzet.

[ANdrode]

CAPSLOCK2000 schreef op zondag 7 juni 2020 @ 13:02:
Als ik dynamische adressen zou gebruiken voor dit soort apparatuur wordt het ook belangrijk om high-available DHCP & dynamische DNS-diensten te hebben en dat maakt de boel weer complexer. In alle eerlijkheid heb ik die systemen al, maar als virtuele machines. De servers waar de VM's op draaien kan ik dus moeilijk via DHCP configureren.

Tel je SLAAC mee als dynamische adressen?
En kan je met link local adressen uit tijdens het bootstrap proces?

Want hoewel je geen IPv6 adressen wilt onthouden zijn ze tijdens het bootstrappen wel voorspelbaar.

[CAPSLOCK2000]

overhyped schreef op zondag 7 juni 2020 @ 14:53:
Ik loop nu met m’n vriendin in een pretpark (ideaal zo tijdens Corona, lekker rustig) maar ga even de tijd nemen thuis achter m’n PC om een reactie waardig aan deze post te geven

Top!

ANdrode schreef op zondag 7 juni 2020 @ 15:02:
Tel je SLAAC mee als dynamische adressen?
En kan je met link local adressen uit tijdens het bootstrap proces?

Want hoewel je geen IPv6 adressen wilt onthouden zijn ze tijdens het bootstrappen wel voorspelbaar.

Goede vraag, SLAAC zit inderdaad een beetje op het randje.
Ik heb hier een Paniek & Recovery document met de adressen en wachtwoorden van de belangrijkste apparaten, zodat ik op afstand kan recoveren van de meeste dingen die fout kunnen gaan. (Dit is mijn hobbie-omgeving, fouten en storingen zijn gegarandeerd).

SLAAC-adressen zijn afhankelijk van de hardware. Als een apparaat stuk gaat en vervangen wordt dan zal het SLAAC-adres ook veranderen, vanuit dat oogpunt is het niet statisch. Van de andere kant is het relatief zeldzaam dat er hardware vervangen moet worden en als dat gebeurt dan weet ik het ook wel.
Nog een stap verder denkend is het waarschijnlijker dat ik vergeet om een SLAAC-adres te updaten in mijn documentatie dan dat ik vergeet om een statisch adres te vervangen, want dan werkt het apparaat gewoon niet.

Lastiger zijn firewalls en andere IP-gebaseerde beveiliging. Ik weet dat dat gezien wordt als een verouderde vorm van beveiliging die makkelijk te misleiden is, maar ik vind het nog steeds nuttig. In een aantal gevallen zie ook geen alternatief, zoals bij verschillende IoT(achtige) apparaten, bv mijn televisie. In theorie zou ik die apparaten moeten vervangen door een veilig alternatief, maar die zijn er niet of zijn onbetaalbaar. Ik heb net een televisie gekocht met de prijs van een kleine auto, maar die heeft geen mogelijkheid om veilig te verbinden met mijn NAS.

PS. Ik heb geen probleem met het onthouden van statische IPv6-adressen in mijn eigen netwerk. Die zijn kort en min of meer logisch ( <prefix>:<vlan>::1 => router ). In grotere netwerken schaalt dat niet, maar hier thuis is het goed te doen.


Maaar, dit hele verhaal focust op het kunnen onthouden/voorspellen van adressen in een nood-situatie. Dat is eigenlijk niet waar ik met mijn eerste opmerkingen op doelde.

Wat ik bedoel is dat ik mijn ip-adressen en subnetten op talloze plaatsen heb ingevuld of geconfigureerd, en die automatisch aan laten passen is voor mij niet te doen.

Zo staat in de DNS-records van mijn domein het IP-adres van mijn mailserver.
Als ik via DHCP opeens een andere range zou doorkrijgen dan moet mijn DHCP-server dus doorgeven aan mijn DNS-server dat het IP-adres van de mailserver moet veranderen (en misschien ook wel het IP-adres van de DNS-server zelf). Vervolgens moet de configuratie van mijn mailserver worden aangepast om mail vanaf de nieuwe IP-adressen te accepteren. Dan moet de firewall van de mailserver worden aangepast, net als de firewall van mijn DNS-servers en de firewall van de andere mailserver. Uiteraard moet dat allemaal in de juiste volgorde gebeuren anders valt de verbinding weg.
Dit is 1 voorbeeld, ik kan er nog wel 20 bedenken.

In theorie is het prima mogelijk, maar je zal fors moeten investeren in slimme managementsystemen om dat te bouwen. Ik ben behoorlijk bedreven met Puppet, bash en heb mijn hele infrastructuur geautomatiseerd, maar hier durf ik niet aan te beginnen. De meeste onderdelen (zoals dat DHCP en DNS met elkaar communiceren) heb ik al, maar het veranderen van het (enige) ip-adres van een systeem en het in de juiste volgorde herconfigureren van alle software is mij te complex. Zeker omdat we het over een zeer theoretisch situatie hebben. Ik heb al bijna 10 jaar dezelfde IP-adressen. Hoeveel werk wil je steken in het automatiseren van iets dan minder dan eens in de 10 jaar voorkomt?

Nu kun je zeggen dat het vrij theoretisch is dat die adressen ooit zomaar veranderen zolang ik de rekening van mijn ISP betaal en dat ik het overdrijf. Dat klopt, maar als je aanneemt dat die adressen nooit veranderen, dan heeft het ook geen zin om een dynamische infrastructuur te bouwen. Dan kom je uit bij mijn oplossing: een statische netwekconfiguratie met dummy-dhcp-client om m'n ISP tevreden te te houden.

[ Voor 6% gewijzigd door CAPSLOCK2000 op 08-06-2020 12:38 ]

[Roetzen]

Roetzen schreef op vrijdag 5 juni 2020 @ 22:26:
[...]

Ik heb mij met succes aangemeld.

Het is niet of nauwelijks te volgen via dat adobeconnect.

[Dreamvoid]

CAPSLOCK2000 schreef op maandag 8 juni 2020 @ 12:30:
Nu kun je zeggen dat het vrij theoretisch is dat die adressen ooit zomaar veranderen zolang ik de rekening van mijn ISP betaal en dat ik het overdrijf. Dat klopt, maar als je aanneemt dat die adressen nooit veranderen, dan heeft het ook geen zin om een dynamische infrastructuur te bouwen. Dan kom je uit bij mijn oplossing: een statische netwekconfiguratie met dummy-dhcp-client om m'n ISP tevreden te te houden.

Is het geen idee om op je eigen LAN zoveel mogelijk gewoon met mDNS te werken? Ben je van de hele handmatige IPv6-adres administratie af.

In de regel heb je niet enorme aantallen servers op je LAN met publieke DNS records, en doorgaans support elke domain toko wel een tooltje waarmee je je servers zelf automatisch hun AAAA record kan laten updaten als ze detecteren dat ze een nieuwe hebben gekregen.

[CAPSLOCK2000]

Is het geen idee om op je eigen LAN zoveel mogelijk gewoon met mDNS te werken?

mDNS is leuk, maar mijn netwerkapparatuur ondersteunt dat niet, en volgens mij zijn er ook niet veel switches die dat wel doen. Daarbij werkt mDNS volgens mij alleen binnen een subnet.

In de regel heb je niet enorme aantallen servers op je LAN met publieke DNS records, en doorgaans support elke domain toko wel een tooltje waarmee je je servers zelf automatisch hun AAAA record kan laten updaten als ze detecteren dat ze een nieuwe hebben gekregen.

Ik heb het concreet over mijn eigen servers en niet alleen over publieke DNS. De meeste van mijn records zijn alleen voor intern gebruik, ook al zitten er globale IP-adressen aan vast.

Tooltjes om DNS-records aan te passen heb ik, dat is het probleem niet. Het probleem zit in de hele keten aan software die er gebruik van maakt zonder dat er een directe dependency is. Een ander probleem is dat ik dat soort tools niet kan installeren op alle aparatuur, mijn TV kan dat bijvoorbeeld niet. Overigens ben ik ook niet zo'n van fan het model dat servers zelf direct mijn DNS-server manipuleren. Dan moet je toch weer authenticatie gaan regelen en wordt het snel complex.


Maar laat ik het eens omdraaien. Wat zou het voordeel zijn van adressering dynamisch maken in een complex netwerk? Ik snap het voor (delen van) je netwerk waar gastgebruikers op zitten of om een andere reden veel veranderingen optreden. In mijn gebruikers-netwerk bied ik dan ook gewoon DHCP aan, maar voor servers en zeker voor netwerkapparatuur zie ik geen voordelen, alleen maar nadelen.

[ Voor 25% gewijzigd door CAPSLOCK2000 op 08-06-2020 18:06 ]

[jk-5]

Ik heb hier een andere oplossing voor thuis. Ik heb een bepaalde ULA prefix waar elk vlan een /64 uit krijgt. Die prefixes veranderen nooit dus heb ik die gewoon statisch ingevuld in de interne dns. Alle interne communicatie verloopt daar dus langs. Daarnaast komt de ziggo prefix binnen via dhcpv6-pd en deze wordt gewoon door slaac uitgedeeld intern. Als deze prefix verandert hoef ik maar een paar dns records aan te passen in de publieke dns, wat niet zo vaak voorkomt. In mijn geval werkt dit perfect, misschien heb je er wat aan.

[Dreamvoid]

Ja inderdaad, voor die dingen is ULA bedoeld. Dat kan je mooi statisch houden.

mDNS is inderdaad alleen op een subnet, dus als het interne netwerk wat complexer wordt, dan is dat niet de beste oplossing.

[Tobias.db]

Hallo, weet niet of dit de goede plek is om dit te vragen, if not let me know please.

In Zwitserland heb ik een ISP gevonden die pay-as-you-go aanbied, specifiek InterXS. Van de ISP zou ik dan een IPv6 /64 block krijgen. Nou ben ik zelf niet zo'n fan van die addressen, moeilijk te onthouden etc. Ik zou graag op mijn internet netwerk dus IPv4 gebruiken. In hoeverre is dit mogelijk? als dit uberhaubt al mogelijk is.

Daarnaast is er nog een tweede kwestie, ik wil graag mijn VPN naar huis kunnen gebruiken, thuis ontvang ik van T-Mobile alleen een IPv4 address, ook is al mijn infrastructuur thuis alleen IPv4. Gaat dit problemen opleveren? Het eind doel is om een T-Mobile set-top box te hebben in Zwitserland, die denkt dat hij in Nederland op mijn thuisnetwerk zit.

Ik denk dit te kunnen doen door op het uiteinde in Zwitserland dus een VPN client neer te zetten, die alles over een bepaalde interface door die VPN stuurt, kan dit als de "VPN Side" IPv4 is, en de "Internet Side" IPv6 is?

Edit: de router die ik in Zwitserland wil gebruiken zal VyOS draaien.

Dank

[ Voor 3% gewijzigd door Tobias.db op 15-06-2020 22:18 ]

[Paul]

Je kunt prima op je interne (niet internet) netwerk een ander protocol gebruiken dan je internetprovider aanbiedt. Zelf IPv4 opzetten en van je provider IPv6 krijgen kan gewoon. Echter, het lijkt me erg sterk dat je helemaal geen IPv4 krijgt van ze, het is veel waarschijnlijker dat je geen publiek routeerbaar IPv4-adres krijgt.

Maar waarom zou je adressen onthouden? Als je DNS goed inricht kun je alles op naam bereiken

Re: VPN: Ik neem aan dat je provider zorgt dat je ook IPv4 adressen kunt bereiken, dus je zou gewoon in Zwitserland met een VPN-client moeten kunnen verbinden met een IPv4-only VPN-server in Nederland.

[Dreamvoid]

Tobias.db schreef op maandag 15 juni 2020 @ 22:17:
In Zwitserland heb ik een ISP gevonden die pay-as-you-go aanbied, specifiek InterXS. Van de ISP zou ik dan een IPv6 /64 block krijgen. Nou ben ik zelf niet zo'n fan van die addressen, moeilijk te onthouden etc. Ik zou graag op mijn internet netwerk dus IPv4 gebruiken. In hoeverre is dit mogelijk? als dit uberhaubt al mogelijk is.

Dit staat op hun website:

“Due to the scarcity of IPv4 addresses, we use a (private, and therefore not externally accessible) Carrier Grade NAT-IPv4 address. This means that services such as Portforwarding are not possible. You will receive a fixed /64 IPv6 address from us.”

Oftewel, je krijgt dual stack, IPv4 en IPv6, waarbij je een publiek IPv4 adres deelt met vele anderen. Dit betekent dat je geen servers kan hosten over IPv4, maar uitgaand verkeer (zeg maar normaal internetten etc) werkt prima. De router zal intern op het LAN zowel IPv4 als IPv6 adressen uitdelen aan je devices.

Daarnaast is er nog een tweede kwestie, ik wil graag mijn VPN naar huis kunnen gebruiken, thuis ontvang ik van T-Mobile alleen een IPv4 address, ook is al mijn infrastructuur thuis alleen IPv4. Gaat dit problemen opleveren? Het eind doel is om een T-Mobile set-top box te hebben in Zwitserland, die denkt dat hij in Nederland op mijn thuisnetwerk zit.

Ik denk dit te kunnen doen door op het uiteinde in Zwitserland dus een VPN client neer te zetten, die alles over een bepaalde interface door die VPN stuurt, kan dit als de "VPN Side" IPv4 is, en de "Internet Side" IPv6 is.

Ja dat is idd een goede optie. Je kan aan de Zwitserse kant geen server draaien (want je hebt geen eigen publiek IPv4 adres om naartoe te verbinden), maar wel een client. De VPN server draait dan bij je thuis in NL, waar je wel een eigen publiek IPv4 adres hebt.

Andere optie is Zerotier, waarbij er geen centrale VPN server is, maar alle clients met elkaar een “virtueel LAN” vormen.

[SparTi]

VNG Realisatie geeft voor diverse gemeentes/overheden webinars over IPv6. Met name de bedoeling om overheid websites en mailvoorzieningen over te krijgen op IPv6.

Agenda komende tijd:
https://www.vngrealisatie.nl/agenda

[Roetzen]

Nieuwe metingen




Allebei wat gezakt...

[Out.of.Control]

Ik zie nu (en volgens mij is dat voor het eerst) dat ik op mijn mobiel nu ook een IPv6 adres heb (KPN abonnement).
Hoe zit dat bij andere mobiele providers?

[Roetzen]

Out.of.Control schreef op dinsdag 23 juni 2020 @ 13:19:
Ik zie nu (en volgens mij is dat voor het eerst) dat ik op mijn mobiel nu ook een IPv6 adres heb (KPN abonnement).

Wat voor abo? Zakelijk?

Hoe zit dat bij andere mobiele providers?

Nog niet...

[Out.of.Control]

Geen zakelijk, gewoon een particulier abonnement. Het is een 'Zorgeloos standaard' abonnement uit 2017.

Nog even getest op test-ipv6.com en krijg een 10/10 score. Adres is uit de 2a02:a420:20::/48 range.

[Bigs]

Out.of.Control schreef op dinsdag 23 juni 2020 @ 13:19:
Ik zie nu (en volgens mij is dat voor het eerst) dat ik op mijn mobiel nu ook een IPv6 adres heb (KPN abonnement).
Hoe zit dat bij andere mobiele providers?

Gaaf. KPN is de enige die het tot nu toe heeft aangekondigd en de uitrol gaat zeer langzaam. Maar het gebeurt dus wel!

[Roetzen]

KPN gaf aan de zakelijke abos eerst te doen. Maar nu zijn kennelijk de gewone abos ook aan de beurt. Dus met dat "langzaam" valt het wel mee...

[St00mwals]

Out.of.Control schreef op dinsdag 23 juni 2020 @ 13:33:
Geen zakelijk, gewoon een particulier abonnement. Het is een 'Zorgeloos standaard' abonnement uit 2017.

Nog even getest op test-ipv6.com en krijg een 10/10 score. Adres is uit de 2a02:a420:20::/48 range.

Dan heb je waarschijnlijk geen iPhone, want die waren volgens mij nog niet gecertificeerd bij KPN.
Op mijn iPhone heb ik in elk geval nog geen IPv6

[Out.of.Control]

@St00mwals Klopt, ik heb een Nokia 8.1.

[easyriider]

Out.of.Control schreef op dinsdag 23 juni 2020 @ 13:19:
Ik zie nu (en volgens mij is dat voor het eerst) dat ik op mijn mobiel nu ook een IPv6 adres heb (KPN abonnement).
Hoe zit dat bij andere mobiele providers?

Hier met een ex-Telfort abonnement en nu dus volledig KPN nog steeds geen IPv6. Heb het alleen op m'n telefoon als ik thuis verbonden ben met het Ziggo netwerk.

[St00mwals]

easyriider schreef op dinsdag 23 juni 2020 @ 18:11:
[...]

Hier met een ex-Telfort abonnement en nu dus volledig KPN nog steeds geen IPv6. Heb het alleen op m'n telefoon als ik thuis verbonden ben met het Ziggo netwerk.

Volgens mij ben je administratief volledig over, maar technisch niet.
Er waren een aantal opties waar je met een Telfort sim geen gebruik van kunt maken, waaronder VoLTE. Zodra je gratis een vervangende KPN Sim aanvraagt krijg je deze opties wel, heb ik zelf ook gedaan (gewoon omdat het kon).
Misschien geldt dit ook wel voor IPv6.

[Dreamvoid]

Roetzen schreef op zaterdag 20 juni 2020 @ 14:10:
Nieuwe metingen

Allebei wat gezakt...

Mensen gaan weer naar kantoor, waar doorgaans een IPv4 LAN ligt.

[Snow_King]

Heeft iemand enig idee of de 4G/LTE backup dienst van KPN-1 wel IPv6 doet? Ik heb zo'n vermoeden van niet namelijk.

Met IPv4 kan je dmv NAT heel makkelijk over schakelen naar een andere WAN verbinding. Met v6 is het ook mogelijk, maar het vereist iets meer werk.

Ik heb zo'n donkerbruin vermoeden dat als je hier voor kiest dat KPN IPv6 voor je uit zet.

[Freeaqingme]

@Snow_King Heb je sales van KPN al benaderd hiervoor? Ik gok dat ze geen idee hebben, maar het kan natuurlijk zijn dat je geluk hebt en iemand wel een zinvol antwoord kan geven. Daarnaast helpt 't qua statistiek mee om dit soort dingen op de radar te zetten.

[Snow_King]

Freeaqingme schreef op woensdag 24 juni 2020 @ 11:28:
@Snow_King Heb je sales van KPN al benaderd hiervoor? Ik gok dat ze geen idee hebben, maar het kan natuurlijk zijn dat je geluk hebt en iemand wel een zinvol antwoord kan geven. Daarnaast helpt 't qua statistiek mee om dit soort dingen op de radar te zetten.

Nee, dat heb ik niet gedaan. Ik was benieuwd of iemand het hier toevallig in gebruik heeft.

Interesse in de dienst heb ik ook niet, maar ik vroeg het mij af toen ik de reclame's hoorde/zag.

[Roetzen]

Dreamvoid schreef op woensdag 24 juni 2020 @ 11:07:
[...]

Mensen gaan weer naar kantoor, waar doorgaans een IPv4 LAN ligt.

Ja, dat zou het (gedeeltelijk) kunnen verklaren. Alhoewel....

http://www.iljitsch.com/2...9-christmas-everyday.html

Het lijkt me wat te vroeg om het nu al in de metingen van de afgelopen maand te kunnen zien.

[easyriider]

St00mwals schreef op dinsdag 23 juni 2020 @ 22:06:
[...]

Volgens mij ben je administratief volledig over, maar technisch niet.
Er waren een aantal opties waar je met een Telfort sim geen gebruik van kunt maken, waaronder VoLTE. Zodra je gratis een vervangende KPN Sim aanvraagt krijg je deze opties wel, heb ik zelf ook gedaan (gewoon omdat het kon).
Misschien geldt dit ook wel voor IPv6.

Nog bedankt voor deze gouden tip. Heb de nieuwe simkaart ontvangen en in m'n telefoon, met de wifi uitgeschakeld krijg ik nu een IPv6 adres van KPN mobiel.

Alleen IPv6, dus geen dual-stack.

[jk-5]

easyriider schreef op vrijdag 26 juni 2020 @ 15:05:
[...]

Nog bedankt voor deze gouden tip. Heb de nieuwe simkaart ontvangen en in m'n telefoon, met de wifi uitgeschakeld krijg ik nu een IPv6 adres van KPN mobiel.

Alleen IPv6, dus geen dual-stack.

[Afbeelding]

Wat raar, dat impliceert dat er zelfs geen DNS64/NAT64 setup werkend is? Je kunt dus geen ipv4-only sites bereiken?

[easyriider]

Zo had ik het nog niet eens bekeken, maar helaas tweakers.net laadt gewoon maar bij hardware.info krijg ik de melding dat er geen internetverbinding is.

[jk-5]

easyriider schreef op vrijdag 26 juni 2020 @ 15:34:
Zo had ik het nog niet eens bekeken, maar helaas tweakers.net laadt gewoon maar bij hardware.info krijg ik de melding dat er geen internetverbinding is.

Heb je toevallig zelf een DNS server gedefinieerd, waardoor je telefoon niet de DNS64 servers gebruikt en dus geen verbinding heeft?

[easyriider]

Ja, dat is het, ik had hem op NextDNS ingesteld. Nu automatisch gezet en ipv6-test geeft ook een IPv4 adres.

[Vorkie]

Kun je nagaan hoeveel PTR records KPN heeft voor hun IPv6 mobiele gebruikers...

ja bulk import, maar toch

[ik222]

Vorkie schreef op vrijdag 26 juni 2020 @ 15:44:
Kun je nagaan hoeveel PTR records KPN heeft voor hun IPv6 mobiele gebruikers...

ja bulk import, maar toch

Ik denk eerder dat die dynamisch gegenereerd worden door de authorative servers op het moment dat een verzoek binnenkomt

Een DB is niet zo efficiënt met IPv6

[ Voor 5% gewijzigd door ik222 op 26-06-2020 15:51 ]

[jk-5]

Jup, hartstikke dynamisch. Zo dynamisch dat ze niet eens afhandelen dat je een ongeldig ipv6 adres geeft, en je dus een SERVFAIL krijgt ipv NXDOMAIN:

code:

jeffrey ~ $ dig +short 351f-fa89-3a2c-b3dc-8c08-7c07-e32d-5099.mobile6.kpn.net AAAA
351f:fa89:3a2c:b3dc:8c08:7c07:e32d:5099

jeffrey ~ $ dig test.mobile6.kpn.net AAAA

; <<>> DiG 9.11.13-RedHat-9.11.13-2.fc30 <<>> test.mobile6.kpn.net AAAA
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 30855
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1452
;; QUESTION SECTION:
;test.mobile6.kpn.net.          IN      AAAA

;; Query time: 125 msec
;; SERVER: 172.24.136.1#53(172.24.136.1)
;; WHEN: Fri Jun 26 15:54:37 CEST 2020
;; MSG SIZE  rcvd: 49

[Hipska]

Deze had ik nog getest:

$ host 2a02:a420::
0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.4.a.2.0.a.2.ip6.arpa domain name pointer 2a02-a420--.mobile6.kpn.net.
$ host 2a02:a420::c16c:44eb:e246
6.4.2.e.b.e.4.4.c.6.1.c.0.0.0.0.0.0.0.0.0.0.0.0.0.2.4.a.2.0.a.2.ip6.arpa domain name pointer 2a02-a420--c16c-44eb-e246.mobile6.kpn.net.

Best grappig, ze vervangen de colon dus door een dash. Zoals @jk-5 opmerkte, zelfs als het adres niet bestaat.

[ Voor 6% gewijzigd door Hipska op 26-06-2020 16:28 ]

[jk-5]

Hipska schreef op vrijdag 26 juni 2020 @ 16:26:
Deze had ik nog getest:

$ host 2a02:a420::
0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.4.a.2.0.a.2.ip6.arpa domain name pointer 2a02-a420--.mobile6.kpn.net.
$ host 2a02:a420::c16c:44eb:e246
6.4.2.e.b.e.4.4.c.6.1.c.0.0.0.0.0.0.0.0.0.0.0.0.0.2.4.a.2.0.a.2.ip6.arpa domain name pointer 2a02-a420--c16c-44eb-e246.mobile6.kpn.net.

Best grappig, ze vervangen de colon dus door een dash.

Oh best lelijk dan, dat je gewoon meerdere dashes krijgt als er meerdere nullen aaneenvolgend staan. Ziggo doet het anders, die vullen gewoon alle nullen in

[Hipska]

Hierbij een artikel met uitleg voor IPv6 commando's op de 3 grote besturingssystemen die kunnen helpen bij het foutopsporen bij connectieproblemen: Updated: Basic IPv6 Troubleshooting Commands / IPv6 Rosetta Stone 2019

Samenvatting:

[ANdrode]

ANdrode schreef op donderdag 21 mei 2020 @ 12:07:
[...]


Vodafone heeft kennelijk IPv6. Zelf niet getest maar er is een Atlas probe die aangeeft liveipv6test1.vodafone.nl als apn te gebruiken.

Geen IPv6 bij deze APN bij een kleine test (iOS 13). Iemand anders wél IPv6 bij Vodafone?

[Vorkie]

ANdrode schreef op maandag 29 juni 2020 @ 20:28:
[...]


Geen IPv6 bij deze APN bij een kleine test (iOS 13). Iemand anders wél IPv6 bij Vodafone?

Nee, doet niets hier

[CAPSLOCK2000]

Vandaag een gevalletje 'verdenking van fraude' waarbij de verdachten hetzelfde IP-adres bleken te hebben. Toen waren ze natuurlijk helemaal verdacht. Nu blijkt het een CGNAT-adres van een grote provider te zijn. IPv6 had hier een hoop tijd gespaard.

[Snow_King]

CAPSLOCK2000 schreef op dinsdag 30 juni 2020 @ 17:32:
Vandaag een gevalletje 'verdenking van fraude' waarbij de verdachten hetzelfde IP-adres bleken te hebben. Toen waren ze natuurlijk helemaal verdacht. Nu blijkt het een CGNAT-adres van een grote provider te zijn. IPv6 had hier een hoop tijd gespaard.

Andersom zie ik juist tips rond gaan om te zorgen dat je IPv6 uit zet als je het internet op gaat en een ISP met CGNAT moet nemen om zo je criminele activiteiten nog verder te kunnen verbergen.

Interpol en de Politie in NL roepen daarom ook al langer dat IPv6 nu echt sneller moet.

Toevallig heb ik hier Donderdag 2 Juli een gesprek over met Justitie.

[Dreamvoid]

Dat helpt niet echt, providers loggen (als het goed is) elke sessie nu, die weten dus wie er op welk moment verbinding maakte met welke server. Is meer werk, maar de data is er wel. Maar goed, je moet idd dan wel logs hebben aan de andere kant die dat exacte tijdstip hebben.

Als 99% over is naar IPv6, dan wordt IPv4 loggen ook alleen maar makkelijker.

[ Voor 42% gewijzigd door Dreamvoid op 02-07-2020 08:49 ]

[ANdrode]

Dreamvoid schreef op donderdag 2 juli 2020 @ 08:45:
Dat helpt niet echt, providers loggen (als het goed is) elke sessie nu, die weten dus wie er op welk moment verbinding maakte met welke server. Is meer werk, maar de data is er wel. Maar goed, je moet idd dan wel logs hebben aan de andere kant die dat exacte tijdstip hebben.

Als 99% over is naar IPv6, dan wordt IPv4 loggen ook alleen maar makkelijker.

En logs aan de andere kant die ook de remote poort loggen… Waardoor je voor regelmatig gebruikte diensten niet meer op detailniveau kan traceren.

Kan mij ontzettend goed voorstellen dat veel partijen dat _gelukkig niet doen.

[ Voor 14% gewijzigd door ANdrode op 02-07-2020 09:26 ]

[easyriider]

easyriider schreef op vrijdag 26 juni 2020 @ 15:41:
Ja, dat is het, ik had hem op NextDNS ingesteld. Nu automatisch gezet en ipv6-test geeft ook een IPv4 adres.

Heb nu IPv6 uitgeschakeld bij de APN instellingen. Ook andere DNS-over-TLS providers werkten niet, maar ook speciale apps hiervoor zoals Adguard en Blokada werkten niet bij IPv6 via KPN Mobiel. Ik ga er maar van uit dat de fout bij KPN ligt.

Dus voorlopig heb ik nog niets aan de nieuwe simkaart van KPN.

[jk-5]

easyriider schreef op donderdag 2 juli 2020 @ 12:06:
[...]

Heb nu IPv6 uitgeschakeld bij de APN instellingen. Ook andere DNS-over-TLS providers werkten niet, maar ook speciale apps hiervoor zoals Adguard en Blokada werkten niet bij IPv6 via KPN Mobiel. Ik ga er maar van uit dat de fout bij KPN ligt.

Dus voorlopig heb ik nog niets aan de nieuwe simkaart van KPN.

Nope, de fout daarvan ligt niet bij KPN. Een voorwaarde van NAT64/DNS64 is dat je de DNS server van je provider gebruikt, voor de DNS64 vertaling. Omdat de nat64 prefix gestandaardiseerd is (64:ff9b::/96) zijn er wel andere providers die ook een dns64 dienst aanbieden, en wat ook werkt. Bijvoorbeeld google heeft naast de welbekende public dns ook een public dns64. Die werkt hier dus wel mee: https://developers.google.com/speed/public-dns/docs/dns64

Als je dus per se een custom dns provider wil gebruiken, moet deze wel ondersteuning bieden voor dns64 met deze gestandaardiseerde prefix. Anders werkt ipv4 inderdaad niet. De 464XLAT CLAT wordt ook pas geactiveerd nadat hij DNS64 detecteert, dus ook die gaat je in dit geval niet helpen

[Dreamvoid]

ANdrode schreef op donderdag 2 juli 2020 @ 09:25:
[...]En logs aan de andere kant die ook de remote poort loggen…

Dat hoeft op zich niet - zelfs als die logs enkel zeggen “ipv4 adres w.x.y.z bezocht website ABC op 3 Mei 13h34m15s” dan kan de provider met zijn session logs in principe zien wie dat waren, want hij logt welke users op dat moment een session hadden naar die website ABC. Daar hoef je de port niet voor te weten, al helpt dat natuurlijk nog wel extra.

Overigens, met IPv6 heb je hetzelfde issue maar dan met NAT64, als je een legacy IPv4 site bezoekt gaat dat ook via een CG-NAT server, en de provider zal die ook moeten blijven loggen op session niveau.

[ Voor 19% gewijzigd door Dreamvoid op 02-07-2020 12:51 ]

[Dreamvoid]

easyriider schreef op donderdag 2 juli 2020 @ 12:06:
Heb nu IPv6 uitgeschakeld bij de APN instellingen. Ook andere DNS-over-TLS providers werkten niet,

Als je een IPv4 DNS server invult bij je DoT/DoH instellingen dan werkt het niet, je moet een IPv6+DNS64 nameserver pakken.

Als je overigens niet alleen de DNS maar ook de NAT64 service van je provider niet wil gebruiken maar van iemand anders, er zijn ook DNS64 servers die een andere prefix gebruiken dan de standaard 64:ff9b::/96, en zo je naar-v6-vertaalde IPv4 verkeer via een 3rd party NAT64 server leiden, zoals bij deze gozer uit Denemarken: https://nat64.net/

[ Voor 34% gewijzigd door Dreamvoid op 02-07-2020 14:23 ]

[ANdrode]

Dreamvoid schreef op donderdag 2 juli 2020 @ 12:38:
[...]

Dat hoeft op zich niet - zelfs als die logs enkel zeggen “ipv4 adres w.x.y.z bezocht website ABC op 3 Mei 13h34m15s” dan kan de provider met zijn session logs in principe zien wie dat waren, want hij logt welke users op dat moment een session hadden naar die website ABC. Daar hoef je de port niet voor te weten, al helpt dat natuurlijk nog wel extra.

Je krijgt alleen vrij veel connecties naar hetzelfde IP. "Deze set gebruikers verbond met deze CDN frontend/TOR pluggable transport host/TURN server".

Natuurlijk kan je sessies gaan correleren maar de vraag is wat er nodig is voor een tapverzoek.

offtopic:
En dan denk ik vooral aan politie, niet aan de diensten

[Bigs]

Snow_King schreef op dinsdag 30 juni 2020 @ 19:39:
[...]

Andersom zie ik juist tips rond gaan om te zorgen dat je IPv6 uit zet als je het internet op gaat en een ISP met CGNAT moet nemen om zo je criminele activiteiten nog verder te kunnen verbergen.

Interpol en de Politie in NL roepen daarom ook al langer dat IPv6 nu echt sneller moet.

Toevallig heb ik hier Donderdag 2 Juli een gesprek over met Justitie.

Vreemd.. een goede CGNAT implementatie is deterministisch zoals beschreven in RFC 7422 zodat dat weinig effect zou moeten hebben. Bij Juniper en Cisco is het in ieder geval standaard inzetbaar.

[Dreamvoid]

ANdrode schreef op donderdag 2 juli 2020 @ 14:45:
[...]


Je krijgt alleen vrij veel connecties naar hetzelfde IP. "Deze set gebruikers verbond met deze CDN frontend/TOR pluggable transport host/TURN server".

Natuurlijk kan je sessies gaan correleren maar de vraag is wat er nodig is voor een tapverzoek.

offtopic:
En dan denk ik vooral aan politie, niet aan de diensten

Ik weet het niet, typisch heeft een actieve user iets van 200 open sessies, dus met 64k poorten heb je als provider zo'n 300 klanten gelijktijdig achter dat ene CG-NAT ip nummer zitten (niet iedereen is uiteraard tegelijkertijd actief dus dat zijn er veel meer over een dag, maar op 1 moment niet heel veel). Hoe groot is de kans dat meer dan 1 van die 300 willekeurige telefoongebruikers in NL tegelijkertijd naar die ene TOR node verbindt?

Kijk als je het over google.com hebt waar vrijwel elke internet gebruiker een sessie naartoe heeft lopen, ok dan wordt het lastiger identificeren. Of niet, want Google weet toch al precies wie je bent

[ Voor 10% gewijzigd door Dreamvoid op 02-07-2020 16:25 ]

[Freeaqingme]

Dreamvoid schreef op donderdag 2 juli 2020 @ 16:11:
[...]

Ik weet het niet, typisch heeft een actieve user iets van 200 open sessies

Heb je daar een bron van? Ik denk dat het voor de gemiddelde gebruiker veel is. Die heeft netflix en facebook open staan, en that's it. Wellicht voor een paar bewoners, maar dan houdt 't wel op.

Is niet per se de bedoeling om een discussie over te voeren, maar als je een bron hebt voor dat getal van 200 zou ik dat graag eens lezen

[Dreamvoid]

Facebook alleen heeft al tientallen sessies draaien.Hier hebben ze het over een typisch scenario van 400 sessies per user, maar we draaien sinds 2010 op onze telefoons (en PC's/IoT devices) een stuk meer applicaties/services tegelijkertijd. Ik heb altijd begrepen dat de typische mobiele telco een per-user session limit van 200-300 aanhoudt voor CG-NAT zodat 1 klant niet de complete NAT server voltrekt (dat zie je oa in de Cisco Netscaler documentatie terug), wat in de praktijk betekent dus een app die een extra sessie wil openen moet wachten tot een andere proces een van zijn sessies dicht gooit.

Anyway, al hebben we het over 100 concurrent sessions per user, dan nog is het lijkt me vrij onwaarschijnlijk dat er uit een subset van 600 van de ~10 miljoen actieve NL telefoons, er twee tegelijk naar hetzelfde verdachte ip nummer verbinden.

[ Voor 14% gewijzigd door Dreamvoid op 02-07-2020 17:05 ]

[ANdrode]

Dreamvoid schreef op donderdag 2 juli 2020 @ 16:11:
[...]
Kijk als je het over google.com hebt waar vrijwel elke internet gebruiker een sessie naartoe heeft lopen, ok dan wordt het lastiger identificeren. Of niet, want Google weet toch al precies wie je bent

Ik denk inderdaad aan facebook/twitter (bedreigingen) of google (vanwege tor pluggable transport). Als je van tevoren een tapverzoek hebt dan kan je de flows vanaf de user zelf volgen.

Die partijen moeten dan dus wel in alle lagen van hun stack de poort gaan loggen. Je kan de poort eventueel in een IPv6 range encoden omdat je toch IPv6 gebruikt in een moderne L4 loadbalancing setup maar voor traceability is het veel makkelijker als je één legacy ip per user hebt ipv veel users naar één service met CGNAT

[Roetzen]

Snow_King schreef op dinsdag 30 juni 2020 @ 19:39:
[...]

Interpol en de Politie in NL roepen daarom ook al langer dat IPv6 nu echt sneller moet.

Toevallig heb ik hier Donderdag 2 Juli een gesprek over met Justitie.

En?

[Dreamvoid]

Twitter is denk ik eenvoudiger, je hebt daar nl een account, dus ook een grote hoeveelheid aan sessies in je logs voor die user. Met zoveel combo’s van tijdstip/ipv4 nr moet je de boel wel vrij snel terug kunnen brengen tot 1 telefoon lijkt me. Maar goed, ik ben ook maar een gozer op een webforum.

[Casmow]

Vandaag nieuwe KPN sim ontvangen (na verlenging van Telfort->KPN) en heb op mobiel nu IPv6 iig.

Nu nog wachten tot er op m'n Telfort thuis verbinding nog IPv6 komt. En dan nog maar eens zien hoe ik dat op m'n OPNsense box werkende krijg (ipv m'n huidige HE IPv6 tunnel...)

[Roetzen]

Nieuwe metingen:

[Snow_King]

Ik heb thuis een raar probleem waar mijn iPhone 8 met de laatste versie iOS continue zijn IPv6 verliest.

De iPhone SE2020 en iPad die we ook nog in huis hebben werken probleemloos, evenals mijn laptop met Ubuntu.

Mijn iPhone 8 krijgt netjes een IPv6 adres en deze werkt ook. Ik kan http://test-ipv6.com/ bezoeken en ook mijn iPhone pingen.

Na 5 a 10 minuten stopt IPv6 met werken op mijn iPhone. Als ik WiFi uit zet en weer aan werkt het weer.

In huis hangen 6 Unifi AC Pro Access Points verbonden aan de Ziggo ConnectBox in reguliere router modus.

Het rare is dus dat enkel mijn iPhone dit probleem heeft. Andere apparaten hebben hier geen last van.

Het lijkt er op alsof de Neighbor Solliciations niet door komen richting mijn iPhone waardoor andere devices deze niet meer kunnen bereiken.

Iemand enig idee?

[Dreamvoid]

Ik zou eerst testen met een ander accesspoint (bv die Unifi’s tijdelijk uitzetten en direct op de Ziggo box)? Dat zou iig al 1 factor elimineren.

[ Voor 13% gewijzigd door Dreamvoid op 16-07-2020 15:37 ]

[MetalfanBlackness]

Zojuist gehoord dat mijn mogelijk toekomstige provider SNLR (via e-fiber) ipv6 gaat ondersteunen op alle nieuwe verbindingen (als alles lukt annuleer ik deze bestelling en ga ik naar freedom, als dat niet kan, dan blijf ik een jaar bij SNLR en ga daarna naar freedom.
Ik ben er achter gekomen dat SNLR een zuster bedrijf is van Trined.

Zijn er meer mensen die iets gehoord hebben dat kleinere ISP's (ook) begonnen zijn met het aanbieden van ipv6? Hoe meer er mee doen hoe beter, liever natuurlijk de grote providers, maar "wie het kleine niet eert"

[Snow_King]

Dreamvoid schreef op donderdag 16 juli 2020 @ 15:37:
Ik zou eerst testen met een ander accesspoint (bv die Unifi’s tijdelijk uitzetten en direct op de Ziggo box)? Dat zou iig al 1 factor elimineren.

Nee, dat moet ik nog geen proberen. Ziggo WiFi staat wel aan, maar gebruik ik gewoon niet.

Het probleem speelt zich echt alleen af op mijn iPhone 8. Meerdere keren reboot geprobeerd, maar blijft spelen.

[Dreamvoid]

Zou ik eens proberen.

WiFi bugs zijn irritant - ik heb zelf ook een probleem met een Zyxel router - op 1 of andere manier werken LAN games op iOS devices niet (server discovery werkt via Bonjour multicast). Andere devices met multicast: geen probleem. Ander WiFi access point: geen probleem.

[jk-5]

Zijn hier meer mensen bij Ziggo overgezet van DS-Lite naar DS? Bij een bekende in Hengelo is gisteren de verbinding overgegaan naar full DS, met eigen publieke ipv4 op een Arris Connectbox, zonder enige verandering aan zijn kant.

Bij mij verandert een aantal maanden lang mijn DS-Lite ipv4 niet meer. Vroeger (Voor Maart ergens) veranderde deze bijna dagelijks.

[Roetzen]

jk-5 schreef op dinsdag 4 augustus 2020 @ 17:12:

Bij mij verandert een aantal maanden lang mijn DS-Lite ipv4 niet meer. Vroeger (Voor Maart ergens) veranderde deze bijna dagelijks.

Wat bedoel je in dit verband met "DS-Lite IPv4"? Bij DS-Lite heb je gen publiek IPv4 adres. Althans niet eentje voor jezelf. Je aangesloten apparaten krijgen een CGNAT adres.

Dus:

1) Het IPv4 adres dat je ziet met bijvoorbeeld https://www.watismijnipadres.nl/

2) Het IPv4 adres in de Pvt range wat aan je apparaat wordt toegewezen?

[jk-5]

Roetzen schreef op zaterdag 8 augustus 2020 @ 10:48:
[...]

Wat bedoel je in dit verband met "DS-Lite IPv4"? Bij DS-Lite heb je gen publiek IPv4 adres. Althans niet eentje voor jezelf. Je aangesloten apparaten krijgen een CGNAT adres.

Dus:

1) Het IPv4 adres dat je ziet met bijvoorbeeld https://www.watismijnipadres.nl/

2) Het IPv4 adres in de Pvt range wat aan je apparaat wordt toegewezen?

Ja het CGNAT adres dus. Die veranderde vroeger bijna dagelijks maar is inmiddels al sinds begin April hetzelfde

[Roetzen]

jk-5 schreef op zaterdag 8 augustus 2020 @ 10:59:
[...]


Ja het CGNAT adres dus. Die veranderde vroeger bijna dagelijks maar is inmiddels al sinds begin April hetzelfde

Puur uit nieuwsgierigheid: in welke range valt dat adres?

10.0.0.0/8

192.168.nnn.0/24

100.64.0.0/10.

Anders.

[jk-5]

Roetzen schreef op zaterdag 8 augustus 2020 @ 16:36:
[...]

Puur uit nieuwsgierigheid: in welke range valt dat adres?

10.0.0.0/8

192.168.nnn.0/24

100.64.0.0/10.

Anders.

Met het CGNAT adres bedoel ik het publieke (gedeelde) ip naar buiten toe. Verder heeft het modem geen adressen in de ranges die je benoemt omdat dat allemaal over ipv6 loopt of getunneld wordt naar de AFTR. Het interne tunnel adres van het modem in deze tunnel is 192.0.0.2/29, maar dat is voor iedereen hetzelfde.

Overigens terminate ik zelf de DS-Lite tunnel op mijn edgerouter. Is een gewone ipip6 tunnel. Remote tunnel endpoint is het AFTR adres wat in het modem zichtbaar is. Daardoor heeft deze router op zijn externe interface alleen een ipv6 adres, en doe ik dus niks met het 192.168.178.0/24 subnet. Voordelen over je modem gewoon het ipv4 verkeer laten tunnelen heeft het niet, maar wel leuk dat het werkt

[Roetzen]

jk-5 schreef op zaterdag 8 augustus 2020 @ 16:43:
[...]


Met het CGNAT adres bedoel ik het publieke (gedeelde) ip naar buiten toe

OK, misverstandje opgehelderd.

Verder heeft het modem geen adressen in de ranges die je benoemt omdat dat allemaal over ipv6 loopt of getunneld wordt naar de AFTR. Het interne tunnel adres van het modem in deze tunnel is 192.0.0.2/29, maar dat is voor iedereen hetzelfde.

Duidelijk.
Maar wat ik bedoelde met de vraag over de IPv4 adres ranges is, in welke adres range de IPv4 adressen vallen die aan je eindapparaten in je LAN worden toegewezen. Ik neem tenminste aan dat die eindapparaten een IPv4 adres krijgen zodat ze verbinding kunnen maken met het IPv4 internet.

Overigens terminate ik zelf de DS-Lite tunnel op mijn edgerouter. Is een gewone ipip6 tunnel. Remote tunnel endpoint is het AFTR adres wat in het modem zichtbaar is. Daardoor heeft deze router op zijn externe interface alleen een ipv6 adres, en doe ik dus niks met het 192.168.178.0/24 subnet. Voordelen over je modem gewoon het ipv4 verkeer laten tunnelen heeft het niet, maar wel leuk dat het werkt

Ik wist niet dat dat kon, maar het is inderdaad wel leuk en dit soort experimenten geeft inzicht in hoe DS-Lite in elkaar steekt.

[jk-5]

jk-5 schreef op dinsdag 4 augustus 2020 @ 17:12:
Zijn hier meer mensen bij Ziggo overgezet van DS-Lite naar DS? Bij een bekende in Hengelo is gisteren de verbinding overgegaan naar full DS, met eigen publieke ipv4 op een Arris Connectbox, zonder enige verandering aan zijn kant.

Bij mij verandert een aantal maanden lang mijn DS-Lite ipv4 niet meer. Vroeger (Voor Maart ergens) veranderde deze bijna dagelijks.

10 dagen nadat deze bekende is overgezet van DS-Lite naar Dualstack heb ik sinds vandaag in Emmen ook full dual stack met eigen ipv4. Geen DS-Lite meer!

Edit: En deze verandering heeft geen effect gehad op mijn ipv6 prefix, die is gelijk gebleven

[ Voor 7% gewijzigd door jk-5 op 14-08-2020 13:24 ]

[Snow_King]

jk-5 schreef op dinsdag 4 augustus 2020 @ 17:12:
Zijn hier meer mensen bij Ziggo overgezet van DS-Lite naar DS? Bij een bekende in Hengelo is gisteren de verbinding overgegaan naar full DS, met eigen publieke ipv4 op een Arris Connectbox, zonder enige verandering aan zijn kant.

Bij mij verandert een aantal maanden lang mijn DS-Lite ipv4 niet meer. Vroeger (Voor Maart ergens) veranderde deze bijna dagelijks.

Nee. Maar ik heb wel al een week serieuze problemen (Venlo) met IPv4.

code:

Computers-iMac:~ xx$ curl -I -4 www.nos.nl
curl: (7) Failed to connect to www.nos.nl port 80: Connection refused
Computers-iMac:~ xx$ curl -I -4 www.ziggo.nl
curl: (7) Failed to connect to www.ziggo.nl port 80: Connection refused
Computers-iMac:~ xx$

Ik krijg dan van 192.0.0.1 terug:

code:

08:55:48.108982 IP 192.0.0.1 > 192.168.178.2: ICMP host 209.84.3.123 unreachable - admin prohibited filter, length 36

Op drukke momenten gebeurd dit. Lijkt alsof de CGNAT router van Ziggo het niet meer aan kan.

[jk-5]

Snow_King schreef op vrijdag 14 augustus 2020 @ 14:04:
[...]

Nee. Maar ik heb wel al een week serieuze problemen (Venlo) met IPv4.

code:

Computers-iMac:~ xx$ curl -I -4 www.nos.nl
curl: (7) Failed to connect to www.nos.nl port 80: Connection refused
Computers-iMac:~ xx$ curl -I -4 www.ziggo.nl
curl: (7) Failed to connect to www.ziggo.nl port 80: Connection refused
Computers-iMac:~ xx$

Ik krijg dan van 192.0.0.1 terug:

code:

08:55:48.108982 IP 192.0.0.1 > 192.168.178.2: ICMP host 209.84.3.123 unreachable - admin prohibited filter, length 36

Op drukke momenten gebeurd dit. Lijkt alsof de CGNAT router van Ziggo het niet meer aan kan.

Dat heb ik zelf nog nooit echt meegemaakt, maar dat klinkt wel echt als een groot probleem. Kan zijn dat je per regio een andere AFTR hebt (hoewel volgensmij overal de hostnaam aftr01.upc.nl wordt gebruikt). Dat zal ook vast de reden zijn dat ze nu weer de move naar full-DS aan het maken zijn. DS-Lite klint leuk als het ipv4 volume afneemt, alleen als die afname minder hard gaat dan verwacht is dat toch duur om te onderhouden. Los van alle klachten van klanten over CGNAT, lagere MTU en ander 'gezeur' waar je met full-DS geen last van hebt.

Ik hoop echt dat jij binnenkort ook full-DS krijgt

[Snow_King]

jk-5 schreef op vrijdag 14 augustus 2020 @ 14:15:
[...]


Dat heb ik zelf nog nooit echt meegemaakt, maar dat klinkt wel echt als een groot probleem. Kan zijn dat je per regio een andere AFTR hebt (hoewel volgensmij overal de hostnaam aftr01.upc.nl wordt gebruikt). Dat zal ook vast de reden zijn dat ze nu weer de move naar full-DS aan het maken zijn. DS-Lite klint leuk als het ipv4 volume afneemt, alleen als die afname minder hard gaat dan verwacht is dat toch duur om te onderhouden. Los van alle klachten van klanten over CGNAT, lagere MTU en ander 'gezeur' waar je met full-DS geen last van hebt.

Ik hoop echt dat jij binnenkort ook full-DS krijgt

Internet verbinding is praktisch onbruikbaar. Ik kom er achter dat veel devices ondanks dat ze IPv6 hebben toch nog over IPv4 checks doen.

Mijn LG WebOS TV heeft IPv6, maar Netflix werkt niet. Omdat er blijkbaar ook een check over v4 wordt gedaan en daar komt dat ICMP packet terug.

Tweakers doet IPv6, dus mijn Linux laptop en Apple iMac werken prima, ik kan dit bericht gewoon typen.

Servers die ik beheer via IPv6 werken ook allemaal probleemloos.

Maar Spotify op de Sonos werkt niet, ga zo maar door.

Bij Ziggo kom je er gewoon niet doorheen. De helpdesk zegt: Vraag het maar op de community, want dit weet ik niet.

Als iemand een ingang bij Ziggo zou hebben zou ik heel blij zijn.

[Roetzen]

jk-5 schreef op vrijdag 14 augustus 2020 @ 14:15:
[...]

Als Ziggo inderdaad systematisch klanten van DS;Lite naar Fulld DS aan het migreren is, vind ik dat opmerkelijk. Ik had het omgekeerde verwacht. Ik heb mij er al lang op voorbereid dat ik vanwege de schaarste aan IPv4 adressen een keer van Full DS naar DS-Lite zou worden gedegradeerd en dat in de niet zo verre toekomst een publiek IPv4 adres alleen beschikbaar zou zijn voor wie er (flink) voor zou willen betalen.

Dat heb ik zelf nog nooit echt meegemaakt, maar dat klinkt wel echt als een groot probleem. Kan zijn dat je per regio een andere AFTR hebt (hoewel volgensmij overal de hostnaam aftr01.upc.nl wordt gebruikt). Dat zal ook vast de reden zijn dat ze nu weer de move naar full-DS aan het maken zijn. DS-Lite klint leuk als het ipv4 volume afneemt, alleen als die afname minder hard gaat dan verwacht is dat toch duur om te onderhouden. Los van alle klachten van klanten over CGNAT, lagere MTU en ander 'gezeur' waar je met full-DS geen last van hebt.

Dat het IPv4 verkeer niet afneemt, daar zijn Ziggo en con sorte natuurlijk zelf voor een deel debet aan. Ze bieden steeds hogere snelheden aan en verleiden ons om steeds meer data heen en weer te pompen. Maar ze zijn veel te traag en te laks geweest met IPv6. Niet alleen had de uitrol vijf jaar geleden al klaar moeten zijn, ze hadden ook het gebruik actief moeten promoten. Nu lijken ze dus klem te komen zitten tussen enerzijds een schaarste aan IPv4 adressen aan de ene kant en een toenemende druk op het CGNAT systeem aan de andere kant. ESDB...

[ed1703]

Roetzen schreef op vrijdag 14 augustus 2020 @ 15:59:
[...]
Dat het IPv4 verkeer niet afneemt, daar zijn Ziggo en con sorte natuurlijk zelf voor een deel debet aan. Ze bieden steeds hogere snelheden aan en verleiden ons om steeds meer data heen en weer te pompen. Maar ze zijn veel te traag en te laks geweest met IPv6.

Logisch. Als je met z'n allen door hetzelfde kanaal vaart en niemand neemt de leiding om te zeggen dat je vanaf 2025 alleen nog toegang krijgt als je op z'n minst je eigen IPv6 uitrol op orde hebt en voor een minimaal percentage af hebt, dan komt er natuurlijk ook niets van terecht als het allemaal maar een vrijblijvend feestje is.

[jk-5]

Roetzen schreef op vrijdag 14 augustus 2020 @ 15:59:
[...]

Als Ziggo inderdaad systematisch klanten van DS;Lite naar Fulld DS aan het migreren is, vind ik dat opmerkelijk. Ik had het omgekeerde verwacht. Ik heb mij er al lang op voorbereid dat ik vanwege de schaarste aan IPv4 adressen een keer van Full DS naar DS-Lite zou worden gedegradeerd en dat in de niet zo verre toekomst een publiek IPv4 adres alleen beschikbaar zou zijn voor wie er (flink) voor zou willen betalen.

Het komt echter niet geheel onverwacht. Ik wist zeker dat ik het ergens had gelezen maar ik kon het niet zo snel terugvinden. Nu heb ik het gevonden:

https://community.ziggo.n...?postid=390245#post390245
https://community.ziggo.n...?postid=390408#post390408

Dat zou dus wel erg mooi nieuws zijn als we nu midden in die uitrol beland zijn.

[Roetzen]

jk-5 schreef op vrijdag 14 augustus 2020 @ 16:32:
[...]


Het komt echter niet geheel onverwacht. Ik wist zeker dat ik het ergens had gelezen maar ik kon het niet zo snel terugvinden. Nu heb ik het gevonden:

https://community.ziggo.n...?postid=390245#post390245

Nu je het zegt herinner ik me vaag dat al eens eerder gezien te hebben. Ik was het vergeten.

Dat zou dus wel erg mooi nieuws zijn als we nu midden in die uitrol beland zijn.

Ik kijk er met gemengde gevoelens tegen aan.

Voor de gebruiker is Full DS op dit moment zeker te prefereren boven DS-Lite. Je kunt dan zonder problemen servers draaien en de problemen die @Snow_King en anderen ondervinden zijn verdwenen. En ik hoef me er geen zorgen over te maken dat ik ineens op DS-Lite gezet wordt en dat er dan iets hier niet meer werkt wat nu wel werkt. Ja, het zou mooi zijn als iedereen klant Full DS krijgt.

Dat is de ene kant van het verhaal. Aan de andere kant...

Ds-Lite en Full DS zijn niet het einddoel. Het zijn overgangsmechanismen. Het onderhouden van twee systemen is duur en foutgevoelig. Uiteindelijk wil je uitkomen op één protocol en wel IPv6. Daartoe is het niet alleen nodig dat je iedereen aan de IPv6 krijgt, je moet ook van IPv4 af. En ook dat gaat nog niet best.

Als je met IPvFox of 6orNot kijkt naar wat er op een IPv6 site allemaal open staat dat kijk je er van op hoeveel IPv4 er nog actief is op een site die via IPv6 bereikbaar is. Hier op Tweakers:

https://gathering.tweakers.net 2001:9a8:0:e:1337:0:80:2
https://sb.scorecardresearch.com 95.100.130.220
https://www.google-analytics.com 2a00:1450:400e:809::200e
https://tweakers.net 2001:9a8:0:e:1337:0:80:2

Dat valt dus mee, maar in een IPv6 only omgeving werkt zelfs tweakers niet feilloos. het kan erger: nos.nl:

https://nos.nl 2a02:458:101:28:100:29:0:72
https://fonts.googleapis.com 2a00:1450:400e:805::200a
https://static.chartbeat.com 2600:9000:21c7:e00:18:1fcd:34e:d2a1
https://polyfill.io 2a04:4e42:200::621
https://nos-component-renderer.nos.chp.npohosting.nl 18.158.111.139
https://s.nos.nl 2a02:458:101:28:100:28:0:b6
https://static.nos.nl 2a02:458:101:28:100:28:0:af
https://atconnect.npo.nl 52.212.62.24
https://cookies.nos.nl 2a02:458:101:28:100:29:0:88
https://ping.chartbeat.net 34.192.124.255
https://ads-ster.adhese.com 35.205.232.200
https://xb.lc188.226.198.146
https://adscience-nocookie.nl 94.228.133.213

Bijna de helft van alles wat open staat is nog IPv4. Daar moet aan gewerkt worden. Het moet beheerders van sites die pretenderen IPv6 te ondersteunen ontmoedigd worden te "deep linken" naar IPv4. Een effectieve manier om dat te doen is zorgen dat de gebruikers er last van hebben zodat die gaan klagen.

Maar door de gebruikers die er last van hebben dan maar van DS-Lite naar Full DS om te zetten ontneem je dus beheerders van IPv6 websites een reden om iets aan dat "verstopte IPv4" te doen. IPv6 only is weer wat verder weg.

Op die manier bekeken is van DS-Lite naar Full DS dus een stap terug...

[ Voor 11% gewijzigd door Roetzen op 15-08-2020 12:23 ]

[Maurits van Baerle]

@Roetzen Grotendeels met je eens, meer DS-lite bespoedigd juist de overgang naar IPv6 only.

Maar wat die voorbeelden van sites betreft, ik zou daar van eindgebruikers niet teveel verwachten. Het zijn in jouw voorbeeld vrijwel allemaal marketing en analyse tools die nog IPv4 draaien en ik denk dat het de gemiddelde bezoeker aan zijn/haar reet zal roesten dat de sitebeheerders hun heatmaps en re-targetting nog uitsluitend via IPv4 doen.

Sterker nog, ik denk dat als een eindgebruiker IPv4 helemaal uit zet en dan naar Nos.nl gaat dat ze het niet eens merken. Behalve misschien dat de site sneller laadt 😉

[Snow_King]

Roetzen schreef op vrijdag 14 augustus 2020 @ 15:59:
[...]

Als Ziggo inderdaad systematisch klanten van DS;Lite naar Fulld DS aan het migreren is, vind ik dat opmerkelijk. Ik had het omgekeerde verwacht. Ik heb mij er al lang op voorbereid dat ik vanwege de schaarste aan IPv4 adressen een keer van Full DS naar DS-Lite zou worden gedegradeerd en dat in de niet zo verre toekomst een publiek IPv4 adres alleen beschikbaar zou zijn voor wie er (flink) voor zou willen betalen.

[...]

Dat het IPv4 verkeer niet afneemt, daar zijn Ziggo en con sorte natuurlijk zelf voor een deel debet aan. Ze bieden steeds hogere snelheden aan en verleiden ons om steeds meer data heen en weer te pompen. Maar ze zijn veel te traag en te laks geweest met IPv6. Niet alleen had de uitrol vijf jaar geleden al klaar moeten zijn, ze hadden ook het gebruik actief moeten promoten. Nu lijken ze dus klem te komen zitten tussen enerzijds een schaarste aan IPv4 adressen aan de ene kant en een toenemende druk op het CGNAT systeem aan de andere kant. ESDB...

Ik heb dus op de Ziggo community een topic gemaakt: https://community.ziggo.n...of-no-route-to-host-60371

De helpdesk zegt simpelweg tegen mij: Dit is een te technisch probleem, hier kan ik u niet mee helpen.

Ze kunnen verder niets dan een modem reset voor je uitvoeren. That's it. Escaleren kunnen/willen ze niet. Mijn modem is online, dus tja, dat was het dan.

Mijn frustratie niveau begint behoorlijk op te lopen. Sonos/Spotify doen het half/half.

IPv6 diensten werken prima, maar dat snappen ze bij de helpdesk niet. Hun idee was om mij dan terug te zetten naar IPv4-only om mijn probleem op te lossen Ik had natuurlijk het keyword 'IPv6' genoemd en dan is hun script denk ik: IPV6 UITZETTEN!

We hebben echt nog een lange weg te gaan. En wat zou ik graag bij Ziggo vertrekken.

[ed1703]

Snow_King schreef op zaterdag 15 augustus 2020 @ 13:30:
[...]

Ik heb dus op de Ziggo community een topic gemaakt: https://community.ziggo.n...of-no-route-to-host-60371

De helpdesk zegt simpelweg tegen mij: Dit is een te technisch probleem, hier kan ik u niet mee helpen.

Dat is bij vrijwel elke helpdesk. Het enige waar je op kan hopen is dat een Ziggo-medewerker op de community het oppakt en dit doorzet naar 2e-lijns en mogelijk zelfs naar de engineers. Maar dat is bij een ISP lastig, voor hoger dan 2e lijns zijn klanten eng.

[Roetzen]

Snow_King schreef op zaterdag 15 augustus 2020 @ 13:30:
[...]

Ik heb dus op de Ziggo community een topic gemaakt: https://community.ziggo.n...of-no-route-to-host-60371

De helpdesk zegt simpelweg tegen mij: Dit is een te technisch probleem, hier kan ik u niet mee helpen.

Ik zie dat op het community forum toch wel activiteit die hoop geeft dat er maandag actie zal plaatsvinden. We gaan het zien...

Ik had natuurlijk het keyword 'IPv6' genoemd en dan is hun script denk ik: IPV6 UITZETTEN!

Tja...

We hebben echt nog een lange weg te gaan. En wat zou ik graag bij Ziggo vertrekken.

Inderdaad, we hebben nog een lange weg te gaan. deze kinderziektes hadden er al lang uitgehaald moeten zijn. En vertrekken bij Ziggo is hier ook niet echt een optie. Vanwege het 75+ jaar oude PTT koper is DSL geen volwaardig alternatief en glasvezel is nog ver uit zicht...

[Snow_King]

ed1703 schreef op zaterdag 15 augustus 2020 @ 13:42:
[...]

Dat is bij vrijwel elke helpdesk. Het enige waar je op kan hopen is dat een Ziggo-medewerker op de community het oppakt en dit doorzet naar 2e-lijns en mogelijk zelfs naar de engineers. Maar dat is bij een ISP lastig, voor hoger dan 2e lijns zijn klanten eng.

Uiteindelijk heb ik via mijn zakelijke contacten een engineer bij Ziggo kunnen bereiken. Hij heeft mijn verbinding naar Full DualStack gezet en mijn problemen zijn nu 1,5 week later verholpen.

Ik vind het gewoon beschamend dat je met een helpdesk bellen er niet uit komt en het antwoord krijgt: "Uw probleem is te technisch, daar kan ik u niet mee helpen"

Maar ondertussen heb je al ruim een week bijna gaan internet.

Roetzen schreef op zondag 16 augustus 2020 @ 13:05:
[...]

Ik zie dat op het community forum toch wel activiteit die hoop geeft dat er maandag actie zal plaatsvinden. We gaan het zien...

[...]

Tja...

[...]

Inderdaad, we hebben nog een lange weg te gaan. deze kinderziektes hadden er al lang uitgehaald moeten zijn. En vertrekken bij Ziggo is hier ook niet echt een optie. Vanwege het 75+ jaar oude PTT koper is DSL geen volwaardig alternatief en glasvezel is nog ver uit zicht...

Hier het zelfde. Het is Ziggo of 8Mbt ADSL. Dan moet ik dus wel Ziggo nemen.

Ik heb nu dus Full Dual-Stack en dat lost mijn probleem op. Maar ik vermoed dat er heel wat klanten hier ongemerkt tegenaan lopen.

[Dreamvoid]

Dat is het probleem met CG-NAT inderdaad, de ISP's stellen per user een max aantal actieve sessies (200?) zodat een paar gebruikers niet de complete NAT server kan monopoliseren, en de server dropt daarboven gewoon elke nieuwe connectie. Dat werkt al jaren zo op mobiele netwerken, maar nu steeds meer huishoudens (met een heel LAN erachter, die veel meer open sessies draaien) ook achter CG-NAT worden gezet, krijg je dus steeds meer drops.

[ Voor 14% gewijzigd door Dreamvoid op 17-08-2020 11:43 ]

[Snow_King]

Dreamvoid schreef op maandag 17 augustus 2020 @ 11:38:
Dat is het probleem met CG-NAT inderdaad, de ISP's stellen per user een max aantal actieve sessies (200?) zodat een paar gebruikers niet de complete NAT server kan monopoliseren, en de server dropt daarboven gewoon elke nieuwe connectie. Dat werkt al jaren zo op mobiele netwerken, maar nu steeds meer huishoudens (met een heel LAN erachter, die veel meer open sessies draaien) ook achter CG-NAT worden gezet, krijg je dus steeds meer drops.

In mijn LAN zijn 26 devices actief. Geen idee of het daar aan lag/ligt. Nu ik gewoon Dual-Stack heb is het probleem verholpen.

Het is alleen wel heel irritant dat bijvoorbeeld mijn LG WebOS TV wel netjes IPv6 ondersteund, maar de Netflix app toch nog het een en ander over IPv4 doen.

[valkenier]

Snow_King schreef op maandag 17 augustus 2020 @ 12:29:
[...]

In mijn LAN zijn 26 devices actief. Geen idee of het daar aan lag/ligt. Nu ik gewoon Dual-Stack heb is het probleem verholpen.

Het is alleen wel heel irritant dat bijvoorbeeld mijn LG WebOS TV wel netjes IPv6 ondersteund, maar de Netflix app toch nog het een en ander over IPv4 doen.

Je probleem was natuurlijk super irritant. Maar wel heel mooi dat je nu gewoon eventjes Full DS hebt gekregen! Ik ben het wel volledig met je eens dat de Ziggo helpdesk volledig incapabel is. Dat is al veel vaker gebleken.

[Roetzen]

Snow_King schreef op maandag 17 augustus 2020 @ 10:32:
[...]

Uiteindelijk heb ik via mijn zakelijke contacten een engineer bij Ziggo kunnen bereiken. Hij heeft mijn verbinding naar Full DualStack gezet

Het kan dus wel...

Ik vind het gewoon beschamend dat je met een helpdesk bellen er niet uit komt en het antwoord krijgt: "Uw probleem is te technisch, daar kan ik u niet mee helpen"

Dat is inderdaad heel slecht geregeld. Natuurlijk hoeven de 1ste lijn helpers niet alles te weten. Maar dan moet er wel een mogelijkheid tot inroepen de 2de lijn hulp zijn.

Ik heb nu dus Full Dual-Stack en dat lost mijn probleem op. Maar ik vermoed dat er heel wat klanten hier ongemerkt tegenaan lopen.

Ja, jij bent geholpen, maar het onderliggende systeemprobleem is niet opgelost...

Dreamvoid schreef op maandag 17 augustus 2020 @ 11:38:
Dat is het probleem met CG-NAT inderdaad, de ISP's stellen per user een max aantal actieve sessies (200?) zodat een paar gebruikers niet de complete NAT server kan monopoliseren, en de server dropt daarboven gewoon elke nieuwe connectie. Dat werkt al jaren zo op mobiele netwerken, maar nu steeds meer huishoudens (met een heel LAN erachter, die veel meer open sessies draaien) ook achter CG-NAT worden gezet, krijg je dus steeds meer drops.

Het is dus eigenlijk een kwestie van een veel te krap opgezette AFTR. Een publiek IP adres wordt met te veel gebruikers gedeeld waardoor er te weinig sessies per huishouden overblijven. 200 sessies per huishouden is veel te weinig. We hebben het hier een tijdje geleden al eens over gehad toen iemand stelde dat een publiek IPv4 adres met duizenden abonnees gedeeld werd en ik stelde dat duizenden veel te veel is omdat er dan te weinig sessies per abonnee overblijven.

Jammer. Op zich is DS-Lite een goed overgangs mechanisme naar IPv6 only. Maar ja, dan moet je het daar niet bij laten en wel vaart maken met het uitfaseren van IPv4...
.

[Dreamvoid]

Roetzen schreef op maandag 17 augustus 2020 @ 12:42:
Het is dus eigenlijk een kwestie van een veel te krap opgezette AFTR. Een publiek IP adres wordt met te veel gebruikers gedeeld waardoor er te weinig sessies per huishouden overblijven. 200 sessies per huishouden is veel te weinig. We hebben het hier een tijdje geleden al eens over gehad toen iemand stelde dat een publiek IPv4 adres met duizenden abonnees gedeeld werd en ik stelde dat duizenden veel te veel is omdat er dan te weinig sessies per abonnee overblijven.

Inderdaad - de meeste ervaring bij de providers is met CG-NAT op mobiel, maar daar heb je maar 1 telefoon per klant, geen compleet LAN.

Jammer. Op zich is DS-Lite een goed overgangs mechanisme naar IPv6 only. Maar ja, dan moet je het daar niet bij laten en wel vaart maken met het uitfaseren van IPv4...

Daar kan de ISP weinig aan doen natuurlijk - je bent afhankelijk van wat de grote content providers doen.

DS-Lite lijkt nu toch na een tiental jaren uitrol wat probleempjes te hebben, het is oa inefficient voor verkeer binnen je provider netwerk: verkeer van de ene naar de andere Ziggo klant tunnelt nu eerst naar de AFTR op de rand van het Ziggo netwerk en vervolgens weer terug het Ziggo netwerk in. Verder doe je eigenlijk liever de NAT op de klantenrouter, dat scheelt server load. Er zijn nu nieuwere concepten voor IPv4-over-v6 die providers nu aan het proberen zijn: 4rd (gepusht door de Franse provider Free), lw4o6 (van Deutsche Telekom) en 464XLAT (sijpelt via mobiele telco's langzaam naar vaste lijn). Grootste probleem schijnt de implementatie op consumenten-routers te zijn.

[NaliXL]

Een heel erg n00b vraag misschien, maar toch:

Stel, mijn provider (t-mobile thuis in dit geval) biedt nog geen IPV6. Ik koop elders een VPS of andere dienst, en ik krijg daar een IPV6 adresblok bij. Zou ik dan dat blok kunnen gebruiken om de apparaten op mijn LAN (inclusief eigen router) te voorzien van een publiek IPV6 adres?

Edit: even mijzelf verduidelijken. Ik bedoel dus het simpelweg toewijzen van de IP adressen binnen mijn LAN, zonder gebruik van een tunnel.

[ Voor 17% gewijzigd door NaliXL op 17-08-2020 14:14 ]

[BAJansen]

NaliXL schreef op maandag 17 augustus 2020 @ 13:44:
Een heel erg n00b vraag misschien, maar toch:

Stel, mijn provider (t-mobile thuis in dit geval) biedt nog geen IPV6. Ik koop elders een VPS of andere dienst, en ik krijg daar een IPV6 adresblok bij. Zou ik dan dat blok kunnen gebruiken om de apparaten op mijn LAN (inclusief eigen router) te voorzien van een publiek IPV6 adres?

Met een tunnel tussen je VPS en je thuisnetwerk moet dat kunnen ja. Of het praktisch handig werkt is waarschijnlijk wel afhankelijk van de grootte van het IPv6 subnet dat je tot je beschikking krijgt.

[Roetzen]

BAJansen schreef op maandag 17 augustus 2020 @ 13:49:
[...]

Met een tunnel tussen je VPS en je thuisnetwerk moet dat kunnen ja. Of het praktisch handig werkt is waarschijnlijk wel afhankelijk van de grootte van het IPv6 subnet dat je tot je beschikking krijgt.

Als het alleen gaat om IPv6 voor thuis lijkt het me handiger om een tunnel te nemen bij he.net of een soortgelijke aanbieder. Dan krijg je een /48.

https://tunnelbroker.net/

[Dreamvoid]

Op zich wel ja, zal je een VPN server op de VPS moeten installeren.
- optie 1: clients verbinden individueel naar die VPN server, en die krijgen een (publiek routable) IPv6 adres
- optie 2: je zet een router in je LAN, die legt een VPN verbinding met de VPS, krijgt via prefix delegation een /64 subnet, en maakt zo het hele thuis LAN IPv6

Ik moet wel zeggen, je wil nog wel eens rare dingen krijgen met geo-locatie enzo als je IPv4 verkeer via een totaal andere provider/land loopt als je IPv6 verkeer.

[ Voor 19% gewijzigd door Dreamvoid op 17-08-2020 13:57 ]

[Raven]

Dreamvoid schreef op maandag 17 augustus 2020 @ 13:54:
Ik moet wel zeggen, je wil nog wel eens rare dingen krijgen met geo-locatie enzo als je IPv4 verkeer via een totaal andere provider/land loopt als je IPv6 verkeer.

Daar weet ik helaas alles van, ik heb IPv6 op deze pc uit moeten zetten omdat anders Facebook denkt dat ik vanuit DE inlog en vanwege dat dingen vertaald naar het Duits en notificaties/suggesties geeft van events in DE die "in de buurt" zouden zijn

Het vreemde is, is dat ik niet één geo-locatie database heb kunnen vinden die aangeeft dat mijn IPv6-adressen in DE gebruikt worden , ik heb nog niet kunnen vinden welke door Facebook gebruikt wordt en Facebook heeft geen klantenservice/techsupport...
edit: Oh wacht, ik had er toen wel één met een locatie in DE gevonden en dat was gefixed, maar dat loste het probleem bij Facebook niet op.

[ Voor 8% gewijzigd door Raven op 17-08-2020 14:15 ]

[Dreamvoid]

Dit is overigens wel een interessante memo voor de liefhebbers: https://tools.ietf.org/id...sition-comparison-04.html Staat werkelijk alles in besproken: het probleem van te weinig sessies-per-klant, de diverse alternatieven voor DS-Lite, praktijkervaringen, extern toegankelijke servers draaien, etc. Zoals deze quote:

On the one hand, the "lack of ports" situation may cause serious problems in the operation of certain applications. For example, Miyakawa has demonstrated the consequences of the session number limitation due to port number shortage on the example of Google Maps. When the limit was 15, several blocks of the map were missing, and the map was unusable. This study also provided several examples for the session numbers of different applications (the highest one was Apple's iTunes: 230-270 ports).

The port number consumption of different applications is highly varying and e.g. in the case of web browsing it depends on several factors, including the choice of the web page, the web browser, and sometimes even the operating system. For example, under certain conditions, 120-160 ports were used (URL: sohu.com, browser: Firefox under Ubuntu Linux), and in some other cases it was only 3-12 ports (URL: twitter.com, browser: Iceweasel under Debian Linux).

There may be several users behind a CE router, especially in the broadband case (e.g. Internet is used by different members of a family simultaneously), so sufficient ports must be allocated to avoid impacting user experience.

[ Voor 31% gewijzigd door Dreamvoid op 17-08-2020 14:54 ]

[Groentjuh]

Hmmm net eens gekeken en ik lijk inderdaad geen DS-lite meer, maar inderdaad Full-DS te hebben?!
Ziggo (in Den Haag)

IPv4 adres: 94.209.x.x met een lease van 7 dagen en ook IPv6 heeft een adres. Ik kan DMZ instellen voor IPv4 en IPv6.

Dan mag ik gaan klussen met mijn OPNSense om daar op te acteren.

[Roetzen]

Dreamvoid schreef op maandag 17 augustus 2020 @ 13:24:
[...]

DS-Lite lijkt nu toch na een tiental jaren uitrol wat probleempjes te hebben, het is oa inefficient voor verkeer binnen je provider netwerk: verkeer van de ene naar de andere Ziggo klant tunnelt nu eerst naar de AFTR op de rand van het Ziggo netwerk en vervolgens weer terug het Ziggo netwerk in.

Klopt, maar dat is uiteraard alleen van toepassing tussen DS-Lite en IPv4 only klanten. Het is nu blijkbaar zo dat iedere klant die een nieuw modem krijgt, nu ook direct IPv6 krijgt. DS-Lite of Full DS. het verkeer tussen die klanten onderling gaat dan via IPv6 en dat belast de AFTR dus niet. Maar het duurt natuurlijk nog wel een paar jaar voordat iedere klant een IPv6 capable modem heeft. Waren ze vijf jaar eerder begonnen met de uitrol va IPv6, dan was dat nu niet meer aan de orden geweest.

Verder doe je eigenlijk liever de NAT op de klantenrouter, dat scheelt server load. Er zijn nu nieuwere concepten voor IPv4-over-v6 die providers nu aan het proberen zijn: 4rd (gepusht door de Franse provider Free), lw4o6 (van Deutsche Telekom) en 464XLAT (sijpelt via mobiele telco's langzaam naar vaste lijn). Grootste probleem schijnt de implementatie op consumenten-routers te zijn.

Heel goed mogelijk dat die alternatieven beter zijn dan DS-Lite. Ik weet het niet. Maar ja, voordat dat weer uitgerold is zijn we weer zo vijf jaar verder.

Wat ik wel weet is dat deze problemen er niet zouden zijn als men 10 jaar eerder was begonnen met de uitrol van IPv6 zodat bijna iedereen het had voordat het gebrek aan IPv4 adressen een rol ging spelen. Dan was nu IPv4 al wel zo ver uitgestorven dat het het nog resterende IPv4 verkeer makkelijk opgevangen zou kunnen worden met DS-Lite of een ander overgangsmechanisme.

Overigens staan de ISPs niet geheel machteloos in het bemoedigen van het gebruik van IPv6 en het ontmoedigen van IPv4, Niet alleen kunnen ze de uitrol van IPv6 opschalen, ze kunnen IPv4 helpen afbouwen door met de prijzen te spelen. Maak bij snelheidsverhogingen onderscheid tussen IPv4 en IPv6. Verhoog bijvoorbeeld bij de volgende ronde alleen de snelheid voor IPv6. Biedt abonnementen aan met een korting voor een lagere IPv4 snelheid. Geef bij peering overeenkomsten voorrang aan IPv6. zo maar wat losse ideeën...

[Dreamvoid]

Dat zou helpen als de klanten een keus hadden tussen een website via IPv4 of IPv6 bezoeken, maar ten eerste weten ze dit niet, en ten tweede hebben ze geen keus, de site die ze willen bezoeken of de applicatie die ze gebruiken doet onder de motorkap IPv6 of niet.

Overigens waren er tien jaar terug al routers/modems met IPv6 uitgerold, maar de eisen veranderen - anno 2020 hebben de ISP’s meer eisen dan ze tien jaar terug voorzagen, waardoor die routers niet voldoen: prefix delegation, NAT64, CLAT, B4, lwB4, 4rd, etc.

[ Voor 33% gewijzigd door Dreamvoid op 18-08-2020 14:03 ]

[Snow_King]

Dreamvoid schreef op dinsdag 18 augustus 2020 @ 13:56:
Dat zou helpen als de klanten een keus hadden tussen een website via IPv4 of IPv6 bezoeken, maar ten eerste weten ze dit niet, en ten tweede hebben ze geen keus, de site die ze willen bezoeken of de applicatie die ze gebruiken doet onder de motorkap IPv6 of niet.

Overigens waren er vijf jaar terug al routers/modems met IPv6 uitgerold, maar de eisen veranderen - anno 2020 hebben de ISP’s meer eisen dan ze tien jaar terug voorzagen, waardoor die routers niet voldoen: prefix delegation, NAT64, CLAT, B4, lwB4, 4rd, etc.

Eerlijk is eerlijk: Mensen willen gewoon werkend internet. Punt uit.

Ik pak mijn vrouw vaak als voorbeeld: Ze wil gewoon kunnen internetten. Het boeit haar niet (nofi) hoe het werkt, als het maar gewoon werkt. Betrouwbaar en snel.

Het is aan ons techneuten om het ook werkend te hebben. Als dat DS-Lite of Dual-Stack is doet er niet toe.

Dat gedoe wat ik heb gehad met CGNAT zorgde voor een niet werkende dienst.

Maar de eindgebruiker heeft niets met v4 of v6.

[_fm]

Heb je nu full dual stack met modem in bridge mode?

Eigenlijk wil je dit als je heel zeker weet wat er aan de hand is: https://xkcd.com/806/

Iets wat er op lijkt bestaat soms wel, in ieder geval bij xs4all. (freedom vast ook?) Maar voor de iets grotere ISPs zou ik geen manieren andere dan via-via/persoonlijke contacten weten, terwijl ze er misschien wel zijn?
Als dat te breed bekend wordt, hoe houd je dat dan effectief? (sorteren onzin/echte problemen)