Het grote IPv6 topic

[ANdrode]

Brahiewahiewa schreef op vrijdag 27 september 2019 @ 15:59:
[...]
Hmmz, het goede nieuws is dat prefix delegation werkt. Het slechte nieuws is dat m'n router kennelijk niet geoptimaliseerd is voor ipv6. Hij komt niet verder dan 40 Mbps terwijl hij op ipv4 de 250 Mbps achteloos vol trekt. Misschien moet ik niet zeuren; 't is nog steeds drie keer zo snel als de HE tunnel ;o)

Ligt de snelheid van de HE tunnel mogelijk ook aan de router?

* ANdrode haalt via een HE tunnel 100 mbit

[Brahiewahiewa]

ANdrode schreef op vrijdag 27 september 2019 @ 17:52:
[...]


Ligt de snelheid van de HE tunnel mogelijk ook aan de router?

* ANdrode haalt via een HE tunnel 100 mbit

't Zou kunnen, alhoewel ik met een FreeBSD machine ook niet veel verder kwam.
Anyway, de router is een vigor 2130; die haalt z'n troughput uit hardware-NAT en we hebben NAT min-of-meer afgeschaft met ipv6

[ANdrode]

Brahiewahiewa schreef op zaterdag 28 september 2019 @ 08:23:
[...]
't Zou kunnen, alhoewel ik met een FreeBSD machine ook niet veel verder kwam.

Het zal ook zeker van het moment en de routing liggen.
Mijn test gisteren: vanaf T-Mobile thuis naar de HE tunnel server in Amsterdam om +- 17:50. iperf3 als test.

[St00mwals]

nieuws: KPN begint met overzetten mobiele klanten naar ipv6

KPN is maandag begonnen met het overzetten van mobiele klanten van ipv4 naar ipv6. De provider bood al langer een ipv6-optie voor klanten met een vaste internetverbinding thuis, maar was nog niet begonnen met ipv6 aanbieden in zijn mobiele netwerk.

[borft]

Brahiewahiewa schreef op zaterdag 28 september 2019 @ 08:23:
[...]

't Zou kunnen, alhoewel ik met een FreeBSD machine ook niet veel verder kwam.
Anyway, de router is een vigor 2130; die haalt z'n troughput uit hardware-NAT en we hebben NAT min-of-meer afgeschaft met ipv6

Ik heb een hele oude WNDR3700 (Netgear), met OpenWRT, en een simpele Curl vanaf een Linux doos die daarachter hangt, haalt rond de 120Mbps, ksoftirqd trekt dan 90% CPU op de router, dus ik denk dat die dan de bottleneck is (ik zit op een 250Mbps ziggo lijntje). Exact dezelfde Curl, over IPv4 doet 200Mbps.

[St00mwals]

@Roetzen Je bent beroemd:

Hoe ver is de uitrol van IPv6 gevorderd?
Er worden geen exacte cijfers gedeeld over welk percentage van onze klanten gebruik kunnen maken van IPv6. Naar schatting is dit ongeveer 30%. In Het grote IPv6 topic op tweakers.net deelt gebruiker Roetzen periodiek statistieken over de uitrol bij KPN en Ziggo.

[Snow_King]

St00mwals schreef op maandag 30 september 2019 @ 14:02:
nieuws: KPN begint met overzetten mobiele klanten naar ipv6


[...]

Iemand met KPN mobiel die inmiddels al v6 heeft?

[St00mwals]

Snow_King schreef op dinsdag 1 oktober 2019 @ 11:11:
[...]

Iemand met KPN mobiel die inmiddels al v6 heeft?

1: Ik heb Telfort, wel KPN, maar toch ook weer net niet...
2: Ik heb een iPhone, en laat die nu nog buiten de boot vallen

[ANdrode]

Het is zo ver.

---

RIPE heeft hun laatste aaneengesloten /22 blok uitgegeven en heeft nog +- 1 miljoen adressen in /23's en /24's.

Er zijn meer aanmeldingen voor nieuwe ripe leden (Local Internet Registries) dan er /22's in deze pool beschikbaar zijn. Niet alle aanmeldingen op de wachtlijst zullen een /22 krijgen.

Update: Approaching IPv4 Run-out
Today we allocated the last of our contiguous /22 IPv4 address blocks. We still have approximately one million addresses available, in the form of /23s and /24s, and we will continue making /22-equivalent allocations made up of these smaller blocks. Once we can no longer allocate the equivalent of a /22, we will announce that we have reached run-out. We expect this to occur in November 2019.

Following our last update in August, we received a very high number of new LIR applications. We have now reached a point where the number of LIRs waiting to be activated is larger than the number of /22-equivalents remaining. This means that some of these LIRs will only be eligible to request a /24 via the waiting list by the time they are activated. We alerted these applicants to this possibility during the application process.

Due to the number of new LIR applications still to be processed, we estimate that it could be around eight weeks before we get to an application that is submitted today. To ensure fairness, we are processing all LIR applications (and IPv4 requests) in the order they were received.

It is important to note that the delay is only with LIR applications - not IPv4 requests. Existing members can still request their final /22 allocations, provided we still have addresses available

[Maasluip]

Van 1 oktober 2018 tot 1 oktober 2019 zijn er 6.31 miljoen adressen uitgegeven, met die snelheid zit RIPE in ruwweg 2 maanden zonder IPv4.

[ Voor 9% gewijzigd door Maasluip op 03-10-2019 14:24 ]

[Roetzen]

Maasluip schreef op donderdag 3 oktober 2019 @ 14:24:
Van 1 oktober 2018 tot 1 oktober 2019 zijn er 6.31 miljoen adressen uitgegeven, met die snelheid zit RIPE in ruwweg 2 maanden zonder IPv4.

Er zou een run kunnen ontstaan op de laatste kruimeltjes, dus misschien gaat het harder.

[Maasluip]

Nou, sterker nog: ze zeggen dat ze nu al meer aanvragen hebben dan ze ruimte hebben. Dus het ligt vooral aan hun toekenningsproces hoe lang het duurt voordat ze op zijn.
Virtueel zijn ze al op. Een nieuwe aanvrager zal op de wachtlijst komen te staan.

[CAPSLOCK2000]

Zo'n nieuwe aanvrager kan ook niet meer dan een /24 aanvragen.
Is er hier iemand goed op de hoogte van de globale routering van internet verkeer?
Een paar jaar geleden was het namelijk praktisch gezien niet mogelijk om een /24 laten routeren, routers hadden niet genoeg geheugen om al die kleine netwerken bij te houden.
Hoe staat dat er tegenwoordig voor?

[ik222]

CAPSLOCK2000 schreef op donderdag 3 oktober 2019 @ 15:57:
Zo'n nieuwe aanvrager kan ook niet meer dan een /24 aanvragen.
Is er hier iemand goed op de hoogte van de globale routering van internet verkeer?
Een paar jaar geleden was het namelijk praktisch gezien niet mogelijk om een /24 laten routeren, routers hadden niet genoeg geheugen om al die kleine netwerken bij te houden.
Hoe staat dat er tegenwoordig voor?

Al enige tijd kun je alles t/m een /25 probleemloos aankondigen / routeren. Niet voor niets zijn de volledige IPv4 routetabellen ook stukken groter worden de afgelopen jaren...

Kleinere subnets willen routeren is overigens niet alleen een gevolg van versplintering door het tekort aan IPv4 adressen, het is bijvoorbeeld ook handig voor bepaalde vormen van DDoS mitigatie.

[Roetzen]

Maasluip schreef op donderdag 3 oktober 2019 @ 15:37:
Nou, sterker nog: ze zeggen dat ze nu al meer aanvragen hebben dan ze ruimte hebben. Dus het ligt vooral aan hun toekenningsproces hoe lang het duurt voordat ze op zijn.

Die vertraging in is voor de verwerking van de aanmelding van nieuwe leden. Bestaande leden die nog geen laatste /22 aangevraagd hebben kunnen dat alsnog doen en dat wordt dan "direct" toegewezen.

Virtueel zijn ze al op. Een nieuwe aanvrager zal op de wachtlijst komen te staan.

Inderdaad virtueel zijn ze op. Wie zich nu nog niet als lid aangemeld heeft vangt bot.

[Dreamvoid]

St00mwals schreef op maandag 30 september 2019 @ 14:02:
nieuws: KPN begint met overzetten mobiele klanten naar ipv6

Wat voor IPv6 implementatie gebruikt KPN eigenlijk voor mobiel: DS-Lite, DNS64/NAT64 of 464XLAT? En is de verbinding CG-firewalled of kan je van buiten ook naar je 4G router toe?

[ Voor 11% gewijzigd door Dreamvoid op 04-10-2019 20:41 ]

[jk-5]

Dreamvoid schreef op vrijdag 4 oktober 2019 @ 20:34:
[...]

Wat voor IPv6 implementatie gebruikt KPN eigenlijk voor mobiel: DS-Lite, DNS64/NAT64 of 464XLAT? En is de verbinding CG-firewalled of kan je van buiten ook naar je 4G router toe?

In de mobiele wereld is nat64/dns64 de standaard. Bij android zit een 464XLAT CLAT ingebouwd voor applicaties die alleen met ipv4 sockets overweg kunnen. Apple forceert al jaren lang dat alle iOS applicaties ipv6 sockets moeten ondersteunen, dus dit werkt met nat64 zonder 464xlat nodig te hebben.

Echte dual stack is op LTE niet eens mogelijk. LTE heeft geen next protocol header zoals ethernet waar aangegeven kan worden of het packet ipv4 of ipv6 is. Dus afhankelijk van hoe je apparaat is aangemeld op het netwerk moet al het verkeer over ipv4 of alles over ipv6. De enige manier om dus nog ipv4 connectivity te krijgen op een ipv6 LTE verbinding is dus via nat64

[Dreamvoid]

jk-5 schreef op zaterdag 5 oktober 2019 @ 00:46:
In de mobiele wereld is nat64/dns64 de standaard. Bij android zit een 464XLAT CLAT ingebouwd voor applicaties die alleen met ipv4 sockets overweg kunnen. Apple forceert al jaren lang dat alle iOS applicaties ipv6 sockets moeten ondersteunen, dus dit werkt met nat64 zonder 464xlat nodig te hebben.

Ik begrijp dat iOS inmiddels ook CLAT heeft en een aantal providers 464XLAT doen ipv DNS64/NAT64? Maar KPN is daar dan blijkbaar niet eentje van.

Maar hoe zit de firewalling, worden alle poorten carrier-side dichtgetimmerd of gebeurt de firewalling client-side zoals bij IPv6 op DSL/glas/kabel? Ik heb nu een 4G router (niet bij KPN overigens) en ik zit hard te hopen op zsm IPv6 zodat ik weer van buiten naar mijn LAN kan.

Echte dual stack is op LTE niet eens mogelijk. LTE heeft geen next protocol header zoals ethernet waar aangegeven kan worden of het packet ipv4 of ipv6 is.

Is dat bij 5G ook zo?

[darkrain]

Gisteren aan Ziggo gevraagd om de connectbox uit Bridge te halen zodat ik native IPv6 zou krijgen. Dat is gelukt, ik heb nu native IPv6.

Ziggo zei dat ik een /56 Prefix Delegation zou krijgen, maar dat bleek een /60 te zijn, maakt voor mij persoonlijk niet uit maar ik deel de ervaring hier even. Het werkte niet, dus eerst een factory reset van de connectbox nodig gehad voor er überhaupt een prefix kwam, daarna via Wireshark kunnen zien dat de prefix geen /56 was maar /60 (Dit heeft me wel wat uurtjes gekost in totaal).

Nu 3 VLAN's van IPv6 voorzien via de Unifi Security Gateway doormiddel van Prefix Delegation (aandachtspunt, zet rapid commit op disabled).

Tot nu toe werkt het prima en 20/20 op ipv6-test.com.

[ Voor 18% gewijzigd door darkrain op 06-10-2019 16:30 ]

[Roetzen]

darkrain schreef op zondag 6 oktober 2019 @ 16:21:
Gisteren aan Ziggo gevraagd om de connectbox uit Bridge te halen zodat ik native IPv6 zou krijgen. Dat is gelukt, ik heb nu native IPv6.

Gefeliciteerd!

Full Dual Stack of DS-Lite?

Ziggo zei dat ik een /56 Prefix Delegation zou krijgen, maar dat bleek een /60 te zijn,

Dat is vreemd. Het is voor het eerst dat iemand dat rapporteert. Tot dusver was het altijd en /56. Welke connectbox? Arris of Coompal? fZiggo gebied of fUPC?

[darkrain]

Roetzen schreef op zondag 6 oktober 2019 @ 16:47:
[...]

Gefeliciteerd!

Full Dual Stack of DS-Lite?

[...]

Dat is vreemd. Het is voor het eerst dat iemand dat rapporteert. Tot dusver was het altijd en /56. Welke connectbox? Arris of Coompal? fZiggo gebied of fUPC?

Full Dual Stack (zit in fZiggo).

Compal Connectbox.

[easyriider]

darkrain schreef op zondag 6 oktober 2019 @ 16:21:
Ziggo zei dat ik een /56 Prefix Delegation zou krijgen, maar dat bleek een /60 te zijn, maakt voor mij persoonlijk niet uit maar ik deel de ervaring hier even.

Het modem krijgt een /56 van Ziggo, maar die deelt aan één of meerdere aangesloten routers een /60 uit.

[darkrain]

easyriider schreef op zondag 6 oktober 2019 @ 17:37:
[...]

Het modem krijgt een /56 van Ziggo, maar die deelt aan één of meerdere aangesloten routers een /60 uit.

Ah kijk aan, dat verklaart natuurlijk wel het 1 en ander. Dank voor de verheldering.

[Dutch2007]

darkrain schreef op zondag 6 oktober 2019 @ 16:52:
[...]


Full Dual Stack (zit in fZiggo).

Compal Connectbox.

Heeft niets meer te zeggen, mn broertje (en ik ook) zitten ook in fZiggo gebied, had m'n broertje op IPv6 uit gezet, kreeg ie DS-lite, weet alleen niet welk type connect box hij heeft.

En volgens mij kan het alleen met een connect box toch?

Heb nog een Technicolor 7210, op dat type heeft fziggo in 't verleden ook IPv6 op gehad (dual stack)

[Roetzen]

Dutch2007 schreef op zondag 6 oktober 2019 @ 22:33:
En volgens mij kan het alleen met een connect box toch?

Heb nog een Technicolor 7210, op dat type heeft fziggo in 't verleden ook IPv6 op gehad (dual stack)

Ik weet niet hoe de situatie nu is. Ik heb hier in fZiggo gebied een half jaar Dual Stack gehad met een test firmware voor een Cisco. Die test is beëindigd .Daarna bijna twee jaar Dual Stack met een Ubee EVW321 die ik van marktplaats had gehaald, Toen die kuren kreeg werd hij in maart van dit jaar vervangen door een Arris Connectbox en weer Full Dual Stack.

In elk geval heeft (nog) niet iedereen met een Connectbox IPv6. Mijn buren links en rechts hebben beiden een connectbox, maar die zijn (nog) IPv4 only.

[Paul]

Dutch2007 schreef op zondag 6 oktober 2019 @ 22:33:
Heeft niets meer te zeggen, mn broertje (en ik ook) zitten ook in fZiggo gebied, had m'n broertje op IPv6 uit gezet, kreeg ie DS-lite, weet alleen niet welk type connect box hij heeft.

Zoals een moderator op het Ziggo-forum het me twee weken geleden uitlegde:

Wat jij nu ervaart is ook mijn conclusie (na deductie van enkele praktijkgevallen). Als je op het moment dat Full-DS werd uitgerold (op jouw modemtype) een IPv4 voorkeursregel in je abonnement had staan, dan heb je destijds geen Full-DS profiel gekregen en krijg je nu een DS-Lite profiel zodra we de IPv4 voorkeursregel verwijderen. Ik heb helaas geen kennis van het systeem hierachter, ik kan alleen de schakelaar omzetten en kijken naar de uitkomst.

Helaas heb ik geen mogelijkheid om je van DS-Lite naar Full-DS te krijgen, dat is wel het streven in de toekomst (alles naar Full-DS).

Bij bridge heb je automatisch een IPv4 voorkeursregel, en als je die nu weg laat halen dan kan het dus ook bij een oud abonnement in fZiggo zo zijn dat je DS-Lite krijgt.

[Roetzen]

Roetzen schreef op zondag 6 oktober 2019 @ 23:21:
[...]

In elk geval heeft (nog) niet iedereen met een Connectbox IPv6. Mijn buren links en rechts hebben beiden een connectbox, maar die zijn (nog) IPv4 only.

Aanvulling en correctie:

Mijn buurman stroomafwaarts heeft nu toch ook IPv6. Full Dual Stack Compal Connectbox. Heeft nooit in bridge gestaan. De andere buurman kan ik nu niet zien. Maar ze lijken nu dus aan het uitrollen voor bestaande klanten.

[Dutch2007]

Paul schreef op maandag 7 oktober 2019 @ 10:15:
[...]

Zoals een moderator op het Ziggo-forum het me twee weken geleden uitlegde:

[...]
Bij bridge heb je automatisch een IPv4 voorkeursregel, en als je die nu weg laat halen dan kan het dus ook bij een oud abonnement in fZiggo zo zijn dat je DS-Lite krijgt.

Waarschijnlijk 't geval, ik heb voordat ik deze TC had altijd een modem only ubee gehad en daarna maar heel even de TC7210 in normale modus gehouden (zonder IPv6 d'r op actief).

En omdat ik geen NAT over NAT wil hebben, staat ie bij mij in bridge modus

[Snow_King]

Heeft iemand enig idee of er bij Sony / Playstation al wat vordering is rondom IPv6?

[silexh]

Voor de personen met Tweak. Op hun spiksplinternieuwe forum heb ik een draadje geopend: https://forum.tweak.nl/t/...annen-voor-native-ipv6/48

Ze willen graag weten of en waarom er behoefte aan is, dus laat het vooral weten!

[Snow_King]

silexh schreef op donderdag 10 oktober 2019 @ 14:53:
Voor de personen met Tweak. Op hun spiksplinternieuwe forum heb ik een draadje geopend: https://forum.tweak.nl/t/...annen-voor-native-ipv6/48

Ze willen graag weten of en waarom er behoefte aan is, dus laat het vooral weten!

Same story: We vinden het veel werk, allemaal lastig, kost tijd, levert geen klanten op, dus we doen het niet.

Same shit, different day.

Deze excuses horen we nu echt al jaaaaaaaaaaren van iedereen. Wordt er een beetje moe van.

[Dreamvoid]

Ik begrijp van dat forum dat de klanten wel al IPv6 hebben, maar dat Tweak dit op hun interne netwerk via een 6rd tunnel doet ipv native. Dat is meer vervelend voor Tweak zelf (die moeten een border relay server in de lucht houden) dan voor de klanten lijkt me?

[beekjo]

hoe kan ik een nieuwe private ip krijgen met een kpn prepaid sim?
werkt opwaarderen ook?

[Dreamvoid]

KPN rolt op het moment alleen IPv6 uit voor abonnementen (en Android-only).

Wanneer vindt de activatie van IPv6 voor KPN mobiel internet postpaid precies plaats?
We starten vanaf 30 september 2019, en zal gefaseerd worden uitgerold.

Voor welke klanten van KPN Mobiel activeert KPN IPv6?
Alle klanten van KPN (zowel consumenten als zakelijke klanten) die een mobiel abonnement gebruiken. De Prepaid dienst zal in een later stadium aangepast worden voor IPv6.

Wat merk ik als klant van KPN Mobiel van de overgang naar IPv6?
Klanten merken niets van de overgang naar IPv6.

Zijn er websites die alleen bereikbaar zijn met IPv6?
Nee, er zijn nog geen websites die alleen met IPv6 bereikbaar zijn. Dit wordt wel getest, maar nog niet gebruikt. Wel zijn er meerdere zogenaamde dual stack sites. Deze zijn zowel bereikbaar met IPv4 als met IPv6. Steeds meer bedrijven gaan over op deze dual stack sites.

Hoe weet ik als ik een mobieltje bij KPN koopt, of deze geschikt is voor IPv6?
Alle Android smartphones die we verkopen zijn geschikt voor IPv6. Na certificeren door Apple zijn Apple devices ook geschikt voor IPv6. Dit geldt voor alle iPhones en iPads die later in 2019 nog een update naar iOS 13 gaan krijgen.

Wordt het straks mogelijk om een vast IP adres met IPv6 te bestellen?
Voorlopig is dit niet mogelijk.

Het lijkt erop dat IPv6 adressen bij KPN Mobiel dynamisch gaan zijn, maar we zullen in de praktijk wel zien hoevaak dat verandert. Vanuit KPN gezien is het simpelste om klanten een vaste te geven, voor de logging.

Heeft er iemand trouwens al ervaring met IPv6 op het KPN Mobiel netwerk? APN settings? Krijg je een /56 in een 4G router? Carrier-Grade firewalling ja of nee?

[ Voor 12% gewijzigd door Dreamvoid op 15-10-2019 16:09 ]

[Roetzen]

Nieuwe metingen:






Toch weer een klein beetje er bij

[St00mwals]

Roetzen schreef op woensdag 16 oktober 2019 @ 15:42:
Nieuwe metingen:


[Afbeelding]

[Afbeelding]

Toch weer een klein beetje er bij

Wat is KPN toch aan het uitspoken, die grafiek gaat compleet de verkeerde kant op...

[Dreamvoid]

Nee dan de Franse DSL/glas provider Free:



Overigens zijn er op de Franse forums heel interessante discussies gaande - oa over hoe de drie grote providers totaal verschillend denken over IPv6 security:

- provider Free zet standaard geen firewall aan op hun "Freebox", en hanteert het motto: firewalling doet de gebruiker maar lekker zelf door in de settings van de Freebox te duiken, een router ertussen te zetten of op elke endpoint een firewall te draaien, standaard sturen we je open en bloot het IPv6 internet op
- provider Orange zet standaard een firewall op hun "Livebox" aan, waar je 1 voor 1 handmatig poorten open kan zetten, met als filosofie "zo dicht mogelijk aansluiten bij de IPv4 NAT situatie"
- provider Bouygues met hun "BBox" en "4GBox" zet aan de provider kant een firewall neer met alle ingaande poorten dicht, nul configuratie opties voor de abonnee, wat min of meer neerkomt op: klanten die servers willen draaien, die willen we niet

[ Voor 78% gewijzigd door Dreamvoid op 16-10-2019 22:16 ]

[lonaowna]

St00mwals schreef op woensdag 16 oktober 2019 @ 16:15:
Wat is KPN toch aan het uitspoken, die grafiek gaat compleet de verkeerde kant op...

Komt wellicht omdat hun nieuwe modem (Experia Box V10a) geen IPv6 doet:

Op dit moment ondersteunen de KPN Experia Box V8, V9 en V10 IPv6. De KPN Experia Box V10a is hiervoor ook geschikt, maar de huidige software van deze Experia Box ondersteunt dit nog niet.

[Dreamvoid]

Is er al iemand met IPv6 op het KPN mobiele netwerk? Ben wel benieuwd of ze de boel carrier-grade firewalled hebben.

Op het KPN forum weten ze het niet: https://forum.kpn.com/mob...etwerk-479605/index2.html

[ Voor 35% gewijzigd door Dreamvoid op 20-10-2019 11:05 ]

[CAPSLOCK2000]

St00mwals schreef op woensdag 16 oktober 2019 @ 16:15:
Wat is KPN toch aan het uitspoken, die grafiek gaat compleet de verkeerde kant op...

Ik zie op andere plekken helaas hetzelfde verschijnsel. Ik begin me de laatste maanden af te vragen of het project nu alsnog aan het mislukken is. Ik wil nog niet zeggen dat het aan het krimpen is, maar de groei lijkt flink afgenomen, terwijl juist in deze periode van het jaar internet als geheel flink groeit. Natuurlijk is het logisch dat op enig moment de groei afremt omdat iedereen al is overgestapt, maar volgens mij zijn we daar nog lang niet.

[Brahiewahiewa]

CAPSLOCK2000 schreef op zondag 20 oktober 2019 @ 14:03:
[...]


Ik zie op andere plekken helaas hetzelfde verschijnsel. Ik begin me de laatste maanden af te vragen of het project nu alsnog aan het mislukken is. Ik wil nog niet zeggen dat het aan het krimpen is, maar de groei lijkt flink afgenomen, terwijl juist in deze periode van het jaar internet als geheel flink groeit. Natuurlijk is het logisch dat op enig moment de groei afremt omdat iedereen al is overgestapt, maar volgens mij zijn we daar nog lang niet.

KPN (any ISP) geeft alleen maar de mogelijkheid om ipv6 te gebruiken; ze stellen het niet verplicht.
Als hun users het vervolgens niet gebruiken ga je het niet terugzien in de grafieken

[Snow_King]

lonaowna schreef op zondag 20 oktober 2019 @ 08:01:
[...]


Komt wellicht omdat hun nieuwe modem (Experia Box V10a) geen IPv6 doet:


[...]

v6 heeft dus geen prio. Want als v4 het niet zou doen zou die Box nooit bij klanten terecht komen.

IPv6 wordt dus nog steeds niet serieus genomen.

[Dreamvoid]

IPv6 is inmiddels onstopbaar, de mobiele telco’s gaan nu 1 voor 1 over naar een IPv6-only netwerk, en de vaste ook, te beginnen met hun interne netwerk. We zijn nu al bijna op het punt beland dat die transitie technieken als dual stack, DS-Lite en 464XLAT niet eens meer nodig zijn en je direct naar single stack IPv6+NAT64 kan gaan, wat veel zinniger is voor de providers. Hoe langer je wacht, hoe makkelijker de transitie.

Als je bv naar die Free stats kijkt, daar had je ook jarenlang schommelingen van plus en min tien procent, totdat ze ineens bij iedereen default IPv6 aanzetten in 1 klap en naar 90+ procent gaan.

[ Voor 8% gewijzigd door Dreamvoid op 25-10-2019 11:07 ]

[Snow_King]

Dreamvoid schreef op vrijdag 25 oktober 2019 @ 11:04:
IPv6 is inmiddels onstopbaar, de mobiele telco’s gaan nu 1 voor 1 over naar een IPv6-only netwerk, en de vaste ook, te beginnen met hun interne netwerk. We zijn nu al bijna op het punt beland dat die transitie technieken als dual stack, DS-Lite en 464XLAT niet eens meer nodig zijn en je direct naar single stack IPv6+NAT64 kan gaan, wat veel zinniger is voor de providers. Hoe langer je wacht, hoe makkelijker de transitie.

Als je bv naar die Free stats kijkt, daar had je ook jarenlang schommelingen van plus en min tien procent, totdat ze ineens bij iedereen default IPv6 aanzetten in 1 klap en naar 90+ procent gaan.

Uhm, welke mobiele providers? In NL zou KPN er mee bezig zijn, maar verder zie ik niets.

Heb jij andere informatie die ik niet heb? Bij Vodafone heb ik nog steeds geen IPv6.

[Dreamvoid]

Er zijn meer landen dan Nederland, de ene na de andere Europese telco gaat nu over. Swisscom, Orange, Bouygues, T-Mobile, Telenor, EE, de trend is overduidelijk. Net als met VoLTE en Wifi Calling lopen de Nederlandse providers ietwat achter maar ze volgen uiteindelijk allemaal.

Je gaat er niet echt iets van merken alleen, op mobiele telefoons draai je doorgaans geen servers ofzo dus het feit dat je direct routeerbaar bent heeft niet echt veel praktisch nut. Grootste voordeel is er voor huishoudens achter 4G/5G routers met thuisservers.

[ Voor 60% gewijzigd door Dreamvoid op 25-10-2019 20:28 ]

[Vorkie]

Zie inderdaad de laatste tijd ook steeds meer IPv6 verkeer naar de websites en ook zelfs overheden en Office365 mailservers mail afleveren op IPv6

Moet niet gekker worden toch

[Snow_King]

Dreamvoid schreef op vrijdag 25 oktober 2019 @ 20:11:
Er zijn meer landen dan Nederland, de ene na de andere Europese telco gaat nu over. Swisscom, Orange, Bouygues, T-Mobile, Telenor, EE, de trend is overduidelijk. Net als met VoLTE en Wifi Calling lopen de Nederlandse providers ietwat achter maar ze volgen uiteindelijk allemaal.

Ah, juist! Dat is goed nieuws.

Want dan zullen Google en Facebook ook veel meer v6 gaan zien op al hun diensten.

Nu mag Microsoft nog even zorgen dat alles over v6 werkt :-)

[Dreamvoid]

Wat werkt er bij MS niet over IPv6?

[Snow_King]

Dreamvoid schreef op vrijdag 25 oktober 2019 @ 20:28:
Wat werkt er bij MS niet over IPv6?

Moet ik even opzoeken, maar toen ik van de week keek waren er nog oa mail services die geen AAAA record hebben.

[Vorkie]

Snow_King schreef op vrijdag 25 oktober 2019 @ 21:22:
[...]

Moet ik even opzoeken, maar toen ik van de week keek waren er nog oa mail services die geen AAAA record hebben.

Klopt, ik heb nog geen uitgaande e-mail gezien die afgeleverd werd bij een AAAA MX record, maar zoals ik aangaf, wordt er vanuit sommige tenants wel mail afgeleverd met een IPv6 adres uit diverse MS IPv6 reeksen zoals 2a01:111:f400::/48

[Dreamvoid]

Ik weet niet of het al langsgekomen was, maar Wit-Rusland is het eerste land wat IPv6 wettelijk verplicht stelt bij elke internet aansluiting, uiterlijk per 1 Januari 2020.

https://www.zdnet.com/art...-ipv6-mandatory-for-isps/

Of dit ook mobiele netwerken betreft is dan weer minder duidelijk.

[darkrain]

Snow_King schreef op vrijdag 25 oktober 2019 @ 20:23:
[...]

Ah, juist! Dat is goed nieuws.

Want dan zullen Google en Facebook ook veel meer v6 gaan zien op al hun diensten.

Nu mag Microsoft nog even zorgen dat alles over v6 werkt :-)

Sinds IPv6 day in 2012 werken de meeste van de service van deze providers al via IPv6. Alle services die ik gebruik van Google (en dat zijn er nogal wat) werken prima via IPv6.

Oh wacht ik begreep je verkeerd, je hebt natuurlijk gelijk. Als mobiele providers ook IPv6 doen zal het enorm stijgen.

[ Voor 11% gewijzigd door darkrain op 26-10-2019 10:09 . Reden: fout gelezen ]

[Dreamvoid]

Bij provider Free in Frankrijk (de vaste aansluitingen dan, DSL en glas) hebben ze bij de laatste update van hun Freebox overigens de optie weggehaald om IPv6 uit te zetten. Iedereen dual stack, geen uitzondering. Da’s ook een manier om de boel vooruit te duwen.

[ Voor 10% gewijzigd door Dreamvoid op 26-10-2019 17:53 ]

[Maurits van Baerle]

De Franse ISP’s zijn goed bezig. Mijn ouders in Frankrijk hebben eerder dit jaar hun Orange Livebox moeten vervangen voor de Livebox 4 (omdat de oude kapot was) en sindsdien hebben ze netjes dual stack op hun DSL.

[Snow_King]

Dat zijn goede verhalen!

Recentelijk dacht ik er over na een ISP te starten met glasvezel aanleg in mijn buurt. Doet er verder niet toe hoe en wat.

Probleem is wel: IPv4

Nu nog een ISP starten is gewoon erg lastig, want je kan geen v4 space meer krijgen. Je investering in v4 (lucht) is torenhoog en je zal wel CGNAT moeten toepassen.

SIDN heeft dit al eerder aangehaald. Het uitblijven van v6 is obstructie van concurrentie.

[Dreamvoid]

Nou ja, IPv4 CG-NAT werkt op zich prima natuurlijk, talloze providers overal ter wereld gebruiken het.

[Roetzen]

CGNAT werkt alleen prima voor degenen die hun verbinding gebruiken op client-server basis. Maar dat is niet zoals het internet oorspronkelijk bedoeld was. Het is ontworpen voor volledige end to end verbindingen.

[Dreamvoid]

Daar heb je dan weer IPv6 voor

Al moeten we nog maar zien hoe dat de komende jaren gaat, sommige providers passen carrier-grade firewalling toe op IPv6 waardoor je alsnog geen end-to-end verbindingen kan opzetten.

[St00mwals]

Ik zou nog ff terugkomen op de Ziggo-verbinding van mijn schoonouders:

- Ze hebben een connectbox (weet niet welk model).
- IPv6 adres: 2001:1c06:10c9:*
- IPv4 adres: 217.123.*

Ik heb verder niet ingelogd in het modem en heb dus verder helaas geen info.

[FlowChef]

Hier in Groningen blijkt IPv6 icm Ziggo een groot probleem te worden, Meerdere ziggo klanten hebben geen internet waarbij alleen een switch naar IPv4 een oplossing biedt! Probleem is tot dusver nog niet opgelost.

[Brahiewahiewa]

FlowChef schreef op maandag 28 oktober 2019 @ 16:11:
Hier in Groningen blijkt IPv6 icm Ziggo een groot probleem te worden, Meerdere ziggo klanten hebben geen internet waarbij alleen een switch naar IPv4 een oplossing biedt! Probleem is tot dusver nog niet opgelost.

Hûh? Hebben ze in Groningen een andere ipv6 dan in de rest van Nederland?

[valkenier]

FlowChef schreef op maandag 28 oktober 2019 @ 16:11:
Hier in Groningen blijkt IPv6 icm Ziggo een groot probleem te worden, Meerdere ziggo klanten hebben geen internet waarbij alleen een switch naar IPv4 een oplossing biedt! Probleem is tot dusver nog niet opgelost.

“Geen internet”? Kun je wat specifieker zijn? Daar houden wij tweakers wel van. DNS issues?Alleen IPv6 adressen te bereiken? Alleen IPv4 te bereiken? Geen van beide? Zijn ze gemigreerd naar Full Dual Stack of DS-lite?

Kortom wat is het probleem?

[FlowChef]

valkenier schreef op maandag 28 oktober 2019 @ 16:35:
[...]


“Geen internet”? Kun je wat specifieker zijn? Daar houden wij tweakers wel van. DNS issues?Alleen IPv6 adressen te bereiken? Alleen IPv4 te bereiken? Geen van beide? Zijn ze gemigreerd naar Full Dual Stack of DS-lite?

Kortom wat is het probleem?

Hoopte meer dat jullie dit herkenden of misschien nieuwe gesprekstof zou aansporen zodat ik het beter begreep wat er aan de hand is. Nee, ik kreeg een Ziggo medewerker over de vloer die het probleem herkende. IPv4 adressen waren wel te bereiken, maar het leek er vooral op dat de modem hiervan in de war raakte waardoor de modem constant offline-online ging.

[valkenier]

FlowChef schreef op maandag 28 oktober 2019 @ 16:39:
[...]


Hoopte meer dat jullie dit herkenden of misschien nieuwe gesprekstof zou aansporen zodat ik het beter begreep wat er aan de hand is. Nee, ik kreeg een Ziggo medewerker over de vloer die het probleem herkende. IPv4 adressen waren wel te bereiken, maar het leek er vooral op dat de modem hiervan in de war raakte waardoor de modem constant offline-online ging.

Aha, beetje flauw, maar dus tot nu ben jij de enige hier uit Groningen met issues? Ik begreep dat heel Groningen plat lag
Ben benieuwd of er meer Groningers zijn met problemen nav IPV6.

[Dreamvoid]

Met Ziggo's IPv6 heb je tegelijk ook IPv4 dus het is ietwat onduidelijk waar het aan ligt dan. Bug in de router/modem of problemen met het netwerk?

[ Voor 21% gewijzigd door Dreamvoid op 28-10-2019 16:55 ]

[Brahiewahiewa]

valkenier schreef op maandag 28 oktober 2019 @ 16:50:
[...]
Ben benieuwd of er meer Groningers zijn met problemen nav IPV6.

Volgens allestoringen.nl een stuk of 5; Groningen is dunbevolkt ;o)

[Dreamvoid]

Dreamvoid schreef op vrijdag 25 oktober 2019 @ 22:57:
Wit-Rusland is het eerste land wat IPv6 wettelijk verplicht stelt bij elke internet aansluiting, uiterlijk per 1 Januari 2020.

https://www.zdnet.com/art...-ipv6-mandatory-for-isps/

Hierop terugkomend: aangezien de IPv6 adoptie daar op het moment <1% schijnt te zijn, lijkt het me nogal optimistisch dat deze wettelijke deadline over twee maanden wordt gehaald

[Jaap-Jan]

Dreamvoid schreef op maandag 28 oktober 2019 @ 17:46:
[...]

Hierop terugkomend: aangezien de IPv6 adoptie daar op het moment <1% schijnt te zijn, lijkt het me nogal optimistisch dat deze wettelijke deadline over twee maanden wordt gehaald

Ach, zodra hun great firewall ondersteuning heeft voor IPv6 kan het hard gaan. /s

[Snow_King]

Dreamvoid schreef op maandag 28 oktober 2019 @ 11:31:
Nou ja, IPv4 CG-NAT werkt op zich prima natuurlijk, talloze providers overal ter wereld gebruiken het.

Is zo, maar je moet nog wel steeds aan IPv4-space komen. Die moet je dus gaan kopen.

[Freeaqingme]

Snow_King schreef op dinsdag 29 oktober 2019 @ 07:30:
[...]

Is zo, maar je moet nog wel steeds aan IPv4-space komen. Die moet je dus gaan kopen.

Ik denk dat je met exact 1 /24 al een heel eind komt voor een serieuze CGNat setup. Niet dat ik het fijn vind, maar /24's zullen echt nog wel een tijd te krijgen zijn; alleen betaal je als je pech hebt er 15K voor over een jaar of 2. Voor de serieuzere onderneming is dat prima te betalen, voor de kleine ondernemer wel meteen een flink bedrag.

Daarmee wil ik niet zeggen dat het een gewenst scenario is, maar helaas wel een stukje realiteit waardoor het tekort aan IPv4 niet direct dergelijke toko's noopt tot IPv6.

[Paul]

Ik ben benieuwd hoeveel klanten CG-NAT kwijt kan op één IP-adres.

Wij zijn een redelijk klein ziekenhuis en hebben al port exhaustion als we ons gastenwifi achter één IP hiden, al kan dat natuurlijk ook aan de manier waarop onze firewall dat doet liggen. Als die alles op poort-niveau doet ipv de ip-poort-combi dan ben je na ~64514 (65535-1024) connecties wel klaar.

[Roetzen]

Paul schreef op dinsdag 29 oktober 2019 @ 08:48:
Ik ben benieuwd hoeveel klanten CG-NAT kwijt kan op één IP-adres.

Tussen de 10 en de 100?

Wij zijn een redelijk klein ziekenhuis en hebben al port exhaustion als we ons gastenwifi achter één IP hiden, al kan dat natuurlijk ook aan de manier waarop onze firewall dat doet liggen. Als die alles op poort-niveau doet ipv de ip-poort-combi dan ben je na ~64514 (65535-1024) connecties wel klaar.

Het blijft natuurlijk geklungel, Regel gewoon een IPv6 aansluiting. Dan kun je je gastnetwerk op een eigen /64 zetten. Je zult dan zien dat 95% van het verkeer op het gastnetwerk via IPv6 gaat. Probleem opgelost.

[Paul]

Roetzen schreef op dinsdag 29 oktober 2019 @ 11:01:
Het blijft natuurlijk geklungel, Regel gewoon een IPv6 aansluiting.

Dat lost het probleem maar ten dele op. Die NAT-regel blijft nodig, en daarmee de problematiek die ermee gepaard gaat. Je overschat schromelijk hoeveel diensten er al IPv6 gebruiken. 95% van de bandbreedte? Prima, met de YouTubes en Netflixen van de wereld wil ik daar wel in mee. 95% van de connecties? Echt niet...

[ Voor 14% gewijzigd door Paul op 29-10-2019 12:38 ]

[Roetzen]

Paul schreef op dinsdag 29 oktober 2019 @ 11:58:
[...]
Oh wacht, je bent serieus? Laat ik nog harder gaan lachen...

Ik ben bloedserieus

Precies hoe verwacht je met een IPv6-aansluiting met IPv4-websites te verbinden? Die NAT-regel blijft nodig, en daarmee de problematiek die ermee gepaard gaat.

De NAT regel blijft nodig, maar er zal veel minder verkeer overheen gaan en dus zullen de poorten niet zo gauw op zijn.

Je overschat schromelijk hoeveel diensten er al IPv6 gebruiken.

Ik kijk naar de indicator van 6ORNOT in mijn browser en ik zie dat er best veel diensten via IPv6 bereikbaar zijn. Alle grote jongens en veel overheidsdiensten zijn "om".

95% van de bandbreedte? Prima, met de YouTubes en Netflixen van de wereld wil ik daar wel in mee. 95% van de connecties? Echt niet...

Er is een verband tussen de hoeveelheid verkeer en het aantal gelijktijdige connecties. Weinig verkeer is kortdurende connecties.

En bovendien... Er zal een natuurlijke selectie optreden als er op het IPv4 NAT toch een tekort aan poorten ontstaat. Als IPv4 only diensten minder goed bereikbaar zijn, zullen gebruikers die gaan mijden ten faveure van diensten die wel via IPv6 bereikbaar zijn. Precies wat we willen. Toch?

[Paul]

Roetzen schreef op dinsdag 29 oktober 2019 @ 12:53:
Ik kijk naar de indicator van 6ORNOT in mijn browser en ik zie dat er best veel diensten via IPv6 bereikbaar zijn. Alle grote jongens en veel overheidsdiensten zijn "om".

Maar met genoeg mensen ga je toch ook naar een heleboel kleintjes

Er is een verband tussen de hoeveelheid verkeer en het aantal gelijktijdige connecties. Weinig verkeer is kortdurende connecties.

Ook kortdurende connecties hebben tijd nodig om poorten weer vrij te geven.

Als IPv4 only diensten minder goed bereikbaar zijn, zullen gebruikers die gaan mijden ten faveure van diensten die wel via IPv6 bereikbaar zijn.

Nah, ze gaan vooral zeuren bij de netwerkbeheerder of zetten 4G aan ipv Wifi.

Mensen gaan naar die website met een reden. Misschien omdat ze daar hun mail lezen, misschien omdat het resultaat van hun zoekopdracht daar naartoe wijst, who knows. Maar als het niet werkt dan denken ze niet of dat misschien door IPv4 / IPv6 komt, dan bellen ze de servicedesk dat de wifi brak is.

Hoe graag je het ook zou willen, maar IPv4 is NIET dood, en de problemen die daarbij kijken dus ook niet. En totdat het wel dood is, is IPv6 gebruiken dus niet overal de oplossing voor. Een mitigerende maatregel? Prima. De oplossing? Nope. Daarvoor heb ik te weinig invloed op de rest van het internet.

[Olaf van der Spek]

Paul schreef op dinsdag 29 oktober 2019 @ 14:34:
Ook kortdurende connecties hebben tijd nodig om poorten weer vrij te geven.

Is het aantal beschikbare poorten überhaupt een issue?

Een TCP verbinding is een ip:port - ip:port tupel. Als dst.port bijvoorbeeld 80 443 is, kun je nog steeds 65536 verbindingen naar één dst.ip hebben. En 65536 naar elk ander dst.ip. Dat mag dus geen issue zijn.
Voor UDP geldt eigenlijk hetzelfde.

Maar dat wist je zelf ook al. Paul in "Het grote IPv6 topic"

[ Voor 43% gewijzigd door Olaf van der Spek op 29-10-2019 14:53 ]

[Paul]

I don't know, ik ben niet de officiële firewall-beheerder (heb helaas ook geen beslissingsbevoegdheid mbt implementatie IPv6), laat staan de expert, dus ik heb het ook maar gehoord van mijn collega. Meer IP-adressen gebruiken om de verbindingen achter te hiden was wel de oplossing

[Roetzen]

Paul schreef op dinsdag 29 oktober 2019 @ 14:34:

Mensen gaan naar die website met een reden. Misschien omdat ze daar hun mail lezen, misschien omdat het resultaat van hun zoekopdracht daar naartoe wijst, who knows. Maar als het niet werkt dan denken ze niet of dat misschien door IPv4 / IPv6 komt, dan bellen ze de servicedesk dat de wifi brak is.

De gebruikers hoeven ook helemaal niets te weten van IPv4 of IPv6. Het ging om het gastnetwerk toch? Ik neem aan dat het gratis is? Als ze gaan klagen bij de beheerder van de WiFi, dan kan die aantal dingen doen:

1) Hij kan zeggen, "klopt, nu.nl werkt hier niet zo goed, ga maar naar nos.nl., die doet het hier wel goed.

2) Als ze dan blijven doorzeuren, kan hij iets roepen over een gegeven paard en zo. Gaan ze dan naar 4G, ook goed toch?

Hoe graag je het ook zou willen, maar IPv4 is NIET dood, en de problemen die daarbij kijken dus ook niet. En totdat het wel dood is, is IPv6 gebruiken dus niet overal de oplossing voor.

Ik zeg toch ook niet dat IPv4 dood is? Ik zeg toch ook niet dat IPv6 de oplossing is voor alle problemen? Ik probeer alleen maar duidelijk te maken dat jouw specifieke probleem - opraken van poorten in het NAT van het gastnetwerk- verlicht kan worden door IPv6 aan te bieden. Misschien wel zo veel verlicht dat men het niet meer merkt. Het gaat van nu af aan dan in elk geval alleen maar beter worden, want het aantal sites dat alleen via IPv4 bereikbaar is neemt af.

Maar ja, als je alles bij voorbaat afwijst, zul je het nooit weten...

[Paul]

Roetzen schreef op dinsdag 29 oktober 2019 @ 15:14:
De gebruikers hoeven ook helemaal niets te weten van IPv4 of IPv6. Het ging om het gastnetwerk toch? Ik neem aan dat het gratis is? Als ze gaan klagen bij de beheerder van de WiFi, dan kan die aantal dingen doen:

Er zijn meer opties, zoals wat trots hebben op je werk en het probleem fixen.

Maar ja, als je alles bij voorbaat afwijst, zul je het nooit weten...

Ik wijs niet IPv6 af, ik wijst jouw mening dat een tried and proven oplossing gebruiken "geklungel" is, en dat het de oplossing is voor het probleem. Je omzeilt misschien het probleem, wat in veel gevallen ook goed is, maar het is zeker niet gezegd dat we daarmee het probleem helemaal niet meer hebben. Het is goed mogelijk dat met het offloaden van een deel van de connecties naar IPv6 we nog steeds boven de limiet zitten.

Los daarvan is het lekker makkelijk roepen (en de manier waarop...), maar zo werkt de wereld niet. Je neemt niet "gewoon" een IPv6-aansluiting. Als dat zo was dan bestond dit hele topic niet... Maar dat wilde je vorig jaar ook al niet horen dus waarom reageer ik nog?

[Dreamvoid]

Freeaqingme schreef op dinsdag 29 oktober 2019 @ 08:10:
Ik denk dat je met exact 1 /24 al een heel eind komt voor een serieuze CGNat setup. Niet dat ik het fijn vind, maar /24's zullen echt nog wel een tijd te krijgen zijn; alleen betaal je als je pech hebt er 15K voor over een jaar of 2. Voor de serieuzere onderneming is dat prima te betalen, voor de kleine ondernemer wel meteen een flink bedrag.

Als je de boel met 464XLAT inricht kan je er zelfs veel meer kwijt. Dan moet je aan je klanten wel een modem/router uitdelen die dat ondersteunt (CLAT), maar je hebt aan de provider kant vervolgens maar 1 IPv4 adres nodig voor je PLAT server. Elk huishouden zit dan lekker op zijn eigen 192.168.x.x (of andere private range).

[ Voor 5% gewijzigd door Dreamvoid op 29-10-2019 16:18 ]

[Olaf van der Spek]

Dreamvoid schreef op dinsdag 29 oktober 2019 @ 15:59:
[...]

Als je de boel met 464XLAT inricht kan je er zelfs veel meer kwijt. Dan moet je aan je klanten wel een modem/router uitdelen die dat ondersteunt, maar je hebt aan de provider kant vervolgens maar 1 IPv4 adres nodig voor je PLAT server.

Zijn 464XLAT en CGNAT niet equivalent in hoeveel ze ondersteunen?

[Dreamvoid]

Goede vraag maar ik begreep dat 1 van de grote praktische voordelen voor (mobiele) providers van 464XLAT was er veel minder NAT servers nodig waren, door 'port overloading' kan je zelfs meer dan 64.000 connecties per IPv4 adres hangen, terwijl er bij CG-NAT doorgaans een expliciete mapping van 1 poort naar 1 private IP adres (=klant) is.

Plus dat de PLAT aan de provider-kant niets anders is dan de NAT64/DNS64 server die ze toch al draaien voor native IPv6 clients. Je hebt voor je IPv4 klanten dus geen extra IPv4 adressen nodig dan je toch al nodig hebt voor je NAT64.

Da's het mooie aan 464XLAT, de provider hoeft eigenlijk niks extra te doen om IPv4 functionaliteit te behouden, enkel ervoor zorgen dat aan de client kant (een telefoon of een router) een CLAT draait. Voor de rest is alles native IPv6, nul extra infra nodig. Het hele legacy IPv4 probleem wordt compleet naar de client-side afgewenteld.

[ Voor 78% gewijzigd door Dreamvoid op 29-10-2019 17:38 ]

[Snow_King]

Paul schreef op dinsdag 29 oktober 2019 @ 14:34:
Hoe graag je het ook zou willen, maar IPv4 is NIET dood, en de problemen die daarbij kijken dus ook niet. En totdat het wel dood is, is IPv6 gebruiken dus niet overal de oplossing voor. Een mitigerende maatregel? Prima. De oplossing? Nope. Daarvoor heb ik te weinig invloed op de rest van het internet.

Eens! Echter, zet dan vooral IPv6 aan jouw kant wél aan. Dan ligt het in ieder geval niet aan julle stuk van het internet. Jullie zijn dan IPv6-ready en hebt je steentje bijgedragen.

Afwachten heeft geen nut. Implementeer gewoon IPv6 en je hebt dat stuk iig gehad.

Zeker op een Guest WiFi is IPv6 aan zetten echt goed te doen.

- YouTube
- Google
- Facebook
- WhatsApp
- Instagram
- Gmail
- Hotmail/Outlook

Gaat dan allemaal over IPv6. En dat is best een groot deel van je traffic.

[Paul]

Eens. Maar dat is niet aan mij helaas...

[Dreamvoid]

Het probleem is niet zozeer het bestaan van IPv4 websites, daar kom je via de NAT64/DNS64 van je provider wel bij, ook al heb je single-stack IPv6.

Het transitieprobleem zit hem in legacy applicaties op je eigen LAN die (lowlevel) IPv4 code bevatten.

[ Voor 13% gewijzigd door Dreamvoid op 30-10-2019 12:54 ]

[Roetzen]

Dreamvoid schreef op woensdag 30 oktober 2019 @ 12:03:
Het probleem is niet zozeer het bestaan van IPv4 websites, daar kom je via de NAT64/DNS64 van je provider wel bij ook al heb je single-stack IPv6, het transitieprobleem zit hem in legacy applicaties op je eigen LAN die IPv4 nodig hebben.

1) Daar zul je op een gastnetwerk van een ziekenhuis of een camping niet of nauwelijks mee te maken hebben,

2) IPv6 is niet van gisteren. Dat de IPv4 adressen zouden opraken en IPv4 niet tot in de eeuwigheid zou blijven werken zoals we het gewend waren, is ook niet iets dat we pas gisteren wisten. Iedereen heeft al minstens tien jaar de tijd gehad om er zich op voor te bereiden. Maar men schuift het probleem maar steeds voor zich uit. ESDB..

[ Voor 5% gewijzigd door Roetzen op 30-10-2019 13:42 ]

[Dreamvoid]

Ik heb niet het idee dat men werkelijk het probleem niet ziet, het is vooral dat de providers begrijpelijk liever geen complexe dual stack (full of lite) willen draaien, en een totale overgang naar single stack IPv6 (+NAT64) elke maand makkelijker wordt met het langzaam wegvallen van legacy applicaties bij de klanten, oude routers, oude pre-Android 4.3 telefoons/tablets, pre-iOS 9 iPhones, etc, dus uitstel is te 'rechtvaardigen'.

Het is echt een gemiste kans dat KPN/Ziggo/XS4ALL etc hun IPv6-compatible boxes niet direct uitgerust hebben met een optionele CLAT, dat zou hun uiteindelijke move naar single stack IPv6 zoveel eenvoudiger maken, terwijl die providers nu door twee transities heen moeten, eerst het interne netwerk en alle thuis-routers klaar maken voor DS of DS-Lite, en niet veel later weer opnieuw wijzigen naar de eindsituatie van 464XLAT of IPv6+NAT64.

[Roetzen]

Dreamvoid schreef op woensdag 30 oktober 2019 @ 14:09:
Ik heb niet het idee dat men werkelijk het probleem niet ziet, het is vooral dat de providers begrijpelijk liever geen complexe dual stack (full of lite) willen draaien, en een totale overgang naar single stack IPv6 (+NAT64) elke maand makkelijker wordt met het langzaam wegvallen van legacy applicaties bij de klanten, oude routers, oude pre-Android 4.3 telefoons/tablets, pre-iOS 9 iPhones, etc, dus uitstel is te 'rechtvaardigen'.

Voor mobiele providers is direct van single stack IPv4 naar single stack IPv6 +NAT64 waarschijnlijk wel te doen. Die bieden toch al jaren IPv4 achter CGNAT en smartohones, tablets en laptops gaan geen 20 jaar mee. Dus weinig problemen met legacy spul.

Het is echt een gemiste kans dat KPN/Ziggo/XS4ALL etc hun IPv6-compatible boxes niet direct uitgerust hebben met een optionele CLAT, dat zou hun uiteindelijke move naar single stack IPv6 zoveel eenvoudiger maken, terwijl die providers nu door twee transities heen moeten, eerst het interne netwerk en alle thuis-routers klaar maken voor DS of DS-Lite, en niet veel later weer opnieuw wijzigen naar de eindsituatie van 464XLAT of IPv6+NAT64.

Ik denk niet dat voor vaste providers het overslaan van Dual Stack geen reële optie is. Zoals Paul al opmerkte IPv4 is nog niet dood. Je kunt niet in één klap alles omschakelen. Er moet een overgansperiode zijn waarin IPv6 en IPv4 naast elkaar gebruikt kunnen worden. En wel met publieke IPv4 adressen voor wie dat nog nodig heeft. Daarnaast zie ik niet direct wat het - als men DS-Lite heeft - het nog voor meerwaarde heeft om nog een transitie te maken naar single stack IPv6+NAT64. DS-Lite is op IP niveau tock ook al single stack. De IPv4 gaat via een 4over6 tunnel.

Als IPv4 in onbruik raakt kan men de 4over6 tunnels laten versterven of uitzetten en dan is er een IPv6 only netwerk.

[Freeaqingme]

Roetzen schreef op donderdag 31 oktober 2019 @ 00:29:
[...]
Ik denk niet dat voor vaste providers het overslaan van Dual Stack geen reële optie is.

Onbedoelde dubbele ontkenning?

[jk-5]

Dreamvoid schreef op woensdag 30 oktober 2019 @ 14:09:
[...]

Het is echt een gemiste kans dat KPN/Ziggo/XS4ALL etc hun IPv6-compatible boxes niet direct uitgerust hebben met een optionele CLAT, dat zou hun uiteindelijke move naar single stack IPv6 zoveel eenvoudiger maken, terwijl die providers nu door twee transities heen moeten, eerst het interne netwerk en alle thuis-routers klaar maken voor DS of DS-Lite, en niet veel later weer opnieuw wijzigen naar de eindsituatie van 464XLAT of IPv6+NAT64.

Maar 464XLAT heeft niet minder infrastructuur nodig dan DS-Lite. Bij 464XLAT heb je alsnog de DNS64 en NAT64 infra nodig, dus al het verkeer moet dan alsnog langs een converter. Of je het dan tunnelt over ipv6 (DS-Lite), of omschrijft naar ipv6 (NAT64/464XLAT) is een implementatiedetail waarbij het enige voordeel voor NAT64/464XLAT is dat je MTU in stand blijft. Voor de implementatie op de modems is DS-Lite simpeler, omdat dit gewoon ipip6 encapsulation is, een CLAT is ingewikkelder.

Wel schuif je bij NAT64/464XLAT veel verkeer naar ipv6 van clients die het wel ondersteunen, waar je bij ds-lite dit over ipv4 laat lopen.

Een ander ding is dat DS-Lite en CGNAT vaak als hetzelfde worden gezien, maar je kunt op een AFTR prima statische NAT voor een bepaald endpoint doen dat deze altijd op hetzelfde ipv4 adres uitkomt, net als hoe dit in NAT64 ook mogelijk is (bijvoorbeeld tayga)

[Roetzen]

jk-5 schreef op donderdag 31 oktober 2019 @ 11:45:
[...]
Maar 464XLAT heeft niet minder infrastructuur nodig dan DS-Lite. Bij 464XLAT heb je alsnog de DNS64 en NAT64 infra nodig, dus al het verkeer moet dan alsnog langs een converter. Of je het dan tunnelt over ipv6 (DS-Lite), of omschrijft naar ipv6 (NAT64/464XLAT) is een implementatiedetail waarbij het enige voordeel voor NAT64/464XLAT is dat je MTU in stand blijft.

Daar staat dan weer een ander nadeel van NAT64 tegenover:

"Not every type of resource is accessible with NAT64. Protocols that embed IPv4 literal addresses, such as SIP and SDP, FTP, WebSocket, Skype, MSN, and any other content with IPv4 literals are excluded, "

(Wikipedia)

[jk-5]

Roetzen schreef op donderdag 31 oktober 2019 @ 12:56:
[...]

Daar staat dan weer een ander nadeel van NAT64 tegenover:

"Not every type of resource is accessible with NAT64. Protocols that embed IPv4 literal addresses, such as SIP and SDP, FTP, WebSocket, Skype, MSN, and any other content with IPv4 literals are excluded, "

(Wikipedia)

Ja daar heb je gelijk in inderdaad, maar daar heb je dan de 464XLAT CLAT voor om dat op te lossen

[Dreamvoid]

jk-5 schreef op donderdag 31 oktober 2019 @ 11:45:
Maar 464XLAT heeft niet minder infrastructuur nodig dan DS-Lite. Bij 464XLAT heb je alsnog de DNS64 en NAT64 infra nodig, dus al het verkeer moet dan alsnog langs een converter. Of je het dan tunnelt over ipv6 (DS-Lite), of omschrijft naar ipv6 (NAT64/464XLAT) is een implementatiedetail waarbij het enige voordeel voor NAT64/464XLAT is dat je MTU in stand blijft. Voor de implementatie op de modems is DS-Lite simpeler, omdat dit gewoon ipip6 encapsulation is, een CLAT is ingewikkelder.

Ik kan het fout hebben, maar bij DS-Lite heb je binnen het providernetwerk toch nog een NAT46 nodig die de IPv4 adressen aan de individuele aansluitingen uitdeelt? Bij 464XLAT draait dit deel bij de client router (de CLAT).

[jk-5]

Dreamvoid schreef op donderdag 31 oktober 2019 @ 15:51:
[...]

Ik kan het fout hebben, maar bij DS-Lite heb je binnen het providernetwerk toch nog een NAT46 nodig die de IPv4 adressen aan de individuele aansluitingen uitdeelt? Bij 464XLAT draait dit deel bij de client router (de CLAT).

Ja klopt, dit component heet bij DS-Lite de AFTR. (Address Family Translation Router).
Deze heeft een publiek ipv6 adres waar de ipv6-encapsulated ipv4 op binnenkomt. De AFTR heeft dan een pool met ipv4 adressen welke deze gebruikt om de verbindingen heen te vertalen. De manier waarop dit vertalen plaatsvindt is echter niet vast gespecificeerd. Ziggo implementeert het bijvoorbeeld dat al het verkeer vanaf een bepaald ipv6 endpoint wordt vertaald naar hetzelfde ipv4 adres, mogelijk gedeeld met andere klanten. Dit zou ook een statische 1:1 NAT kunnen zijn.

Fun fact: De DS-Lite verbindingen hoeven niet verplicht vanaf je ziggo modem te komen, je kunt zelf ook een DS-Lite tunnel opzetten vanaf je eigen router. Hiervoor maak je een ipv4-in-ipv6 tunnel met als remote endpoint aftr01.upc.nl (2001:730:2000:2::31). Op deze tunnel interface configureer je als adres 192.0.0.2/29. Je kunt dan een default route toevoegen naar 192.0.0.1/29 (Deze /29 range staat in de RFC voor DS-Lite).

Bijvoorbeeld voor de Edgerouter:

edit interfaces ipv6-tunnel v6tun0
set address 192.0.0.2/29
set encapsulation ipip6
set local-ip <externe ipv6 adres van je router>
set multicast disable
set remote-ip '2001:730:2000:2::31'
set ttl 64
top
set protocols static route 0.0.0.0/0 next-hop 192.0.0.1

Daarna kun je dhcp4 uitzetten en heb je niks meer te maken met 192.168.178.0/24

[Dreamvoid]

Voor zover ik het kan zien neemt een overgang van DS-Lite naar 464XLAT voor de provider dan in elk geval de moeite van het opzetten/beheren van die ATFR's weg, dat was eigenlijk mijn punt. Gaat er namelijk met de AFTR iets mis, dan zijn alle aansluitingen die erachter hangen de klos, gaat op 1 individuele router bij de klant iets mis met CLAT dan heeft de rest er iig geen last van.

Je duwt met 464XLAT feitelijk het IPv4 deel helemaal naar de klant toe, buiten zijn eigen LAN bestaat IPv4 dan niet meer. Als ik een startende provider was, zou ik niet eens meer beginnen aan DS-Lite, stuur een modem/router met CLAT naar je klanten (geef die optie een vinkje in de router instellingen "legacy IPv4 support yes/no"), en gaan met die (IPv6) banaan.

[ Voor 33% gewijzigd door Dreamvoid op 31-10-2019 17:15 ]

[Roetzen]

Dreamvoid schreef op donderdag 31 oktober 2019 @ 17:00:
Voor zover ik het kan zien neemt een overgang van DS-Lite naar 464XLAT voor de provider dan in elk geval de moeite van het opzetten/beheren van die ATFR's weg, dat was eigenlijk mijn punt. Gaat er namelijk met de AFTR iets mis, dan zijn alle aansluitingen die erachter hangen de klos, gaat op 1 individuele router bij de klant iets mis met CLAT dan heeft de rest er iig geen last van.

Maar ja, als je DS-Lite eenmaal hebt weegt het voordeel van het wegnemen van die kleine en theoretische kwetsbaarheid dan wel op tegen de inspanning van het weer ombouwen van alles?

Je duwt met 464XLAT feitelijk het IPv4 deel helemaal naar de klant toe, buiten zijn eigen LAN bestaat IPv4 dan niet meer. Als ik een startende provider was, zou ik niet eens meer beginnen aan DS-Lite, stuur een modem/router met CLAT naar je klanten (geef die optie een vinkje in de router instellingen "legacy IPv4 support yes/no"), en gaan met die (IPv6) banaan.

Voor een provider die van nul af aan begint zou dat inderdaad best eens een optie kunnen zijn. Tip voor de nieuwe provider die Xs4All gaat vervangen?

Maar ja, zoals Snow_King al opmerkte, nieuwe providers zitten wel met het probleem dat ze heel moeilijk aan IPv4 adressen kunnen komen. En ook met DS-Lite of 464XLAT/NAT64 heb je IPv4 adressen nodig.

[Dreamvoid]

Roetzen schreef op donderdag 31 oktober 2019 @ 17:57:
Maar ja, zoals Snow_King al opmerkte, nieuwe providers zitten wel met het probleem dat ze heel moeilijk aan IPv4 adressen kunnen komen. En ook met DS-Lite of 464XLAT/NAT64 heb je IPv4 adressen nodig.

Niet echt, ja je hebt er eentje nodig voor je NAT64 server, maar die heb je toch al nodig. De adressen die de CLAT uitdeelt zijn allemaal private (10.x of 192.x)

[ Voor 3% gewijzigd door Dreamvoid op 31-10-2019 18:06 ]

[Roetzen]

Dreamvoid schreef op donderdag 31 oktober 2019 @ 18:03:
[...]

Niet echt, ja je hebt er eentje nodig voor je NAT64 server,

Eéntje maar voor al je anderhalf miljoen klanten? Dat moet ik nog zien werken...

De adressen die de CLAT uitdeelt zijn allemaal private (10.x of 192.x)

Of in de 100.64.0.0/10 range. Die is gereserveerd voor CGNAT.

[Dreamvoid]

Klopt maar CLAT is geen CG-NAT - voor zover ik het gezien heb bij providers met 464XLAT deelt de CLAT binnen het LAN een 192.x range uit, geen 100.64.x, aangezien de meeste endpoints (pc's, camera's, iot devices etc) niet echt een IP adres in die range verwachten, normaal gesproken ziet enkel je modem/router zo'n soort adres, aan de WAN kant.

Anderhalf miljoen lijkt me idd wat optimistisch, maar ik had wel begrepen dat je veel meer klanten achter een NAT64 kan hangen dan achter een NAT44, en een provider als XS4ALL heeft geloof ik maar iets van 40.000 klanten? Plus dat je die IPv4 adres(sen) voor je NAT64 server(s) sowieso al nodig hebt, ook al hebben 100% van je klanten IPv6 apparatuur en doe je uberhaupt geen DS, DS-Lite of 464XLAT.

[ Voor 50% gewijzigd door Dreamvoid op 31-10-2019 19:28 ]

[Roetzen]

Dreamvoid schreef op donderdag 31 oktober 2019 @ 19:17:
Klopt maar CLAT is geen CG-NAT - voor zover ik het gezien heb bij providers met 464XLAT deelt de CLAT binnen het LAN een 192.x range uit, geen 100.64.x, aangezien de meeste endpoints (pc's, camera's, iot devices etc) niet echt een IP adres in die range verwachten, normaal gesproken ziet enkel je modem/router zo'n soort adres, aan de WAN kant.

De range 100.64.0.0/10 is geen WAN adres. Aperatuur die dat als WAN adres ziet heeft een update nodig. Die range is een Pvt range die niet op het publieke netwerk geroute moet worden, net als FRFC1918 adressen. de reden dat er een nieuwe reeks voor gereserveerd is is om adres conflicten in en NAT achter NAT situatie te vermijden. https://tools.ietf.org/html/rfc6598

Anderhalf miljoen lijkt me idd wat optimistisch, maar ik had wel begrepen dat je veel meer klanten achter een NAT64 kan hangen dan achter een NAT44, en een provider als XS4ALL heeft geloof ik maar iets van 40.000 klanten?

Het was ook en beetje gechargeerd.
Maar het brengt wel een probleem mee voor de voorgestelde opvolger van Xs4All. Die 40.000 klanten zijn "verwend" met Full Dual Stack. Nu heeft Xs4All genoeg IPv4, maar KPN gaat die IPv4 adressen vast niet als afscheidkadotje aan de beoogde opvolger van Xs4All meegeven. Dus ik ben benieuwd hoe dat gaat uitpakken, Zullen de klanten van die nieuwe ISP genoegen nemen met DS-Lite, of IP6+464XLAT?