Het grote IPv6 topic

[Hipska]

Misschien beetje laat, maar Belgian IPv6 Council houdt nu een IPv6 101 - Refresher online webinar.

[Roetzen]

Hipska schreef op woensdag 29 april 2020 @ 19:16:
Misschien beetje laat, maar Belgian IPv6 Council houdt nu een IPv6 101 - Refresher online webinar.

"Deze content is alleen beschikbaar voor leden"

En de site is alleen bereikbaar via IPv4...

[Hipska]

Het is een vrije Meetup groep. En ik kan er toch niet aan doen dat Meetup geen v6 doet.. Trouwens de webinar ging via Cisco Webex, en die doet voorlopig ook nog enkel v4.

Ik zal anders de recording hier plaatsen wanneer deze beschikbaar komt.

[Roetzen]

Hipska schreef op woensdag 29 april 2020 @ 21:29:
Het is een vrije Meetup groep. En ik kan er toch niet aan doen dat Meetup geen v6 doet.. Trouwens de webinar ging via Cisco Webex, en die doet voorlopig ook nog enkel v4.

Ik zal anders de recording hier plaatsen wanneer deze beschikbaar komt.

Het is geen verwijt aan jou persoonlijk natuurlijk. Maar ik vind het wel vreemd. Het is een beetje alsof de voorzitter van de club ter bevordering van elektrisch rijden in een stinkende diesel komt aanzetten.

[Hipska]

Ja, wat wil je dat ze doen? Zelf een Meetup platform maken en opzetten? Of gewoon de tools die voor de situatie gebruikelijk zijn gebruiken?

Jij gebruikt ook Tweakers en hier heeft ook ook verdorie lang geduurd eer er IPv6 ondersteuning was. ("Wij stellen technologie op proef")

Soit, terug ontopic dan maar? Ik zal de link naar de presentatie delen, er werd informatie gegeven die voor velen hier interessant kan zijn. Zo ging het bv ook even over NAT64 en DNS64.

[Roetzen]

Hipska schreef op donderdag 30 april 2020 @ 11:28:
Ja, wat wil je dat ze doen? Zelf een Meetup platform maken en opzetten? Of gewoon de tools die voor de situatie gebruikelijk zijn gebruiken?

Met een beetje zoeken is er wel een alternatief voor Meetup te vinden dat wel IPv6 doet.

Soit, terug ontopic dan maar? Ik zal de link naar de presentatie delen, er werd informatie gegeven die voor velen hier interessant kan zijn. Zo ging het bv ook even over NAT64 en DNS64.

Ik zie het met belangstelling tegemoet.

[Dreamvoid]

Roetzen schreef op woensdag 29 april 2020 @ 17:57:
[...]

Maar was dat dan omdat je een uitgaande verbinding opzette, of omdat je in de tijd van de baas je zus aan het helpen was?

Haha nee het was vanwege het opzetten van een uitgaande encrypted tunnel. Wat overigens prima is, ik mag hopen dat er dan rode sirenes gaan zwaaien.

Ik weet niet hoe het bij KPN is tegenwoordig, maar bij Ziggo gaat draaien op de eigen router in elk geval niet. Als je IPv6 wilt, zit je vast aan de door hun verstrekte modem/router en daar zit het niet in.

Ik zit niet in Nederland, dus geen KPN of Ziggo boxes, maar ook mijn providerbox hier doet geen fancy IPv6 dingen als prefix delegation, ICMPv6 firewall rules, 3rd party DNS servers, CLAT of NAT64. Komt nog wel, of ik koop op termijn eentje die het wel kan.

IPv4 only configs zullen er inderdaad wel op voorzienbare termijn uitgaan (alhoewel dat weer een beetje tegenstrijdig is met de stelling dat bedrijven IPv4 only willen aanhouden tot alle IPv4 legacy verdwenen is)

Mijn verwachting is dat de providernetwerken als eerste helemaal single stack IPv6 worden, met IPv4-as-a-service naar de consumenten/bedrijven toe (in de vorm van een v4 tunnel naar de gateway, of NAT64), die dan vervolgens de keus hebben om intern single stack v4, v6 of dual te draaien.

Terzijde merk ik nog op dat je DS-Lite ook als een service kunt zien...

Oh ja, DS-Lite is net als NAT64 ook IPv4-as-a-service, v4 aanbieden over een v6 netwerk. Tunnels versus translation, maar het eind effect is hetzelfde.

Verschil met NAT64 is vooral dat de topografie met DS-Lite wat meer vast ligt: de tunnel loopt altijd van de CPE gateway router naar de AFTR bij de provider.

Met NAT64 ben je iets flexibeler: de uiteindelijke NAT64 kan bij de provider gebeuren, maar ook compleet ergens anders op de wereld, of lokaal op de CPE gateway, het wordt dan net zoiets als DNS eigenlijk.

De 4-naar-6 vertaling kan op applicatie (netwerk API)-level gebeuren, op het device-level (464XLAT), of ergens anders op de route (een router met een CLAT daemon).

Maar dat is geen DS-Lite. CGNAT zonder NAT aan de CPE kant is onderdeel van de DS-Lite spec.

Dan bedoelde ik niet - ik bedoel: bij de meeste implementaties heeft de provider duizenden DS-Lite tunnels achter 1 publiek IPv4 adres op de AFTR zitten. Maar ze kunnen ook achter elk publiek v4 adres maar 1 tunnel zetten. Verschil met de klassieke 1-publiek-IPv4-adres-per-huishouden situatie is dan dat de NAT44 niet op de CPE router gebeurt maar aan het eind van de tunnel op de AFTR. Dit is bv een manier om enterprise klanten toch eigen publieke v4 adressen te kunnen geven, ook al heb je als provider helemaal geen v4 netwerk meer.

Dit is trouwens ook een goeie in de DS-Lite specs, heeft er al 1 provider dit geimplementeerd?

8.5. Port Forwarding / Keep Alive

The PCP working group is standardizing a control plane to the
carrier-grade NAT [LSN-REQS] in the IETF. The Port Control Protocol
(PCP) enables applications to directly negotiate with the NAT to open
ports and negotiate lifetime values to avoid keep-alive traffic.
More on PCP can be found in [PCP-BASE].

[ Voor 3% gewijzigd door Dreamvoid op 30-04-2020 16:20 ]

[ANdrode]

Hipska schreef op woensdag 29 april 2020 @ 21:29:
Het is een vrije Meetup groep. En ik kan er toch niet aan doen dat Meetup geen v6 doet.. Trouwens de webinar ging via Cisco Webex, en die doet voorlopig ook nog enkel v4.

Ik zal anders de recording hier plaatsen wanneer deze beschikbaar komt.

offtopic:
Zoom gebruiken omdat de enige is die dan overblijft als je IPv6 wilt iirc

[Snow_King]

ANdrode schreef op donderdag 30 april 2020 @ 21:37:
[...]

offtopic:
Zoom gebruiken omdat de enige is die dan overblijft als je IPv6 wilt iirc

Zoom doet helaas geen IPv6. Ookal gebruiken ze Amazon EC2 (wat gewoon v6 doet) zijn alle DNS records die ik vind v4-only.

[Dreamvoid]

MS Teams lijkt gewoon te werken over IPv6?

[ANdrode]

Snow_King schreef op vrijdag 1 mei 2020 @ 08:23:
[...]

Zoom doet helaas geen IPv6. Ookal gebruiken ze Amazon EC2 (wat gewoon v6 doet) zijn alle DNS records die ik vind v4-only.

offtopic:
Grappig: Ze lijken inderdaad geen IPv6 te doen. Dat klopt dan wel met EC2.

Amazon EC2 en v6 is een "speciale" combinatie. Dual stack is lastig en extra kosten voor een loadbalancer laag zijn voor zo'n app niet aantrekkelijk. Als je om IPv6 geeft moet je eigenlijk voor GCP gaan.

Zoom gebruikt overigens gedeeltelijk ook Oracle cloud diensten. Weet niet hoe ver de roll-out daarvan is.

[MrNGm]

Toch maar even hier posten. Huidige netwerksetup:
- pfSense firewall/router
- WAN: Ethernet, MTU 1500 (geen PPPoE, gewoon Ethernet)
- LAN: Ethernet, MTU 1500
- gif0: Tunnelbroker, MTU 1480 (op tunnelbroker.net -> Tunnel settings -> Advanced staat dat ook zo)

Op LAN draait RA voor het default /64-subnet. Op m'n laptop (bedraad ethernet):

code:

$ ip -6 a
3: enp0s25: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 3c:etc: brd ff:ff:ff:ff:ff:ff
    inet6 2001:470:1f15:etc:45ea/64 scope global dynamic mngtmpaddr noprefixroute 
       valid_lft 86391sec preferred_lft 14391sec
    inet6 fe80::3e:etc:45ea/64 scope link 
       valid_lft forever preferred_lft forever

Nog niet zo heel spannend. Hiervoor draaide ik op een Mikrotik RB750GL met vrijwel dezelfde config. De issues bestonden toen ook al.

Eerder in dit topic schreef o.a. @Bram D over problemen met het benaderen van TransIP. Ik ervaar hetzelfde probleem, maar kon niet 1-2-3 vinden of de MTU verlagen naar 1480 nou had geholpen.

ICMPv6 staat alle kanten op open, zodat Path MTU discovery kan plaatsvinden:

code:

$ tracepath -6 www.transip.nl
 1?: [LOCALHOST]                        0.020ms pmtu 1500
 1:  kerstkransje.koekjestrommel.local                     0.488ms 
 1:  kerstkransje.koekjestrommel.local                     0.563ms 
 2:  kerstkransje.koekjestrommel.local                     0.505ms pmtu 1480
 2:  tunnelNNN.tunnel.tserv11.ams1.ipv6.he.net             9.112ms 
 3:  no reply
 4:  m6.e1.ams0.transip.net                                6.284ms asymm  7 
 5:  e1-a0.r1.ams0.transip.net                             6.183ms asymm  7 
 6:  no reply
 7:  no reply
 8:  www.transip.nl                                        5.578ms !A
     Resume: pmtu 1480

En toch gaat het soms mis met data uitwisselen richting TransIP. Moet ik m'n LAN MTU verlagen op alle clients, MSS clamping in pfSense aanzetten, tunnel MTU van Tunnelbroker omlaag (zowel aan hun kant als aan de pfSense-kant)... iemand een idee?

Overigens lijkt de internetprovider niet de bottleneck qua IPv4 MTU (er wordt immers getunneld):

code:

$ tracepath -4 www.transip.nl
 1?: [LOCALHOST]                      pmtu 1500
 1:  _gateway                                              0.442ms 
 1:  _gateway                                              0.673ms 
 2:  ip-etc.ip.prioritytelecom.net              39.270ms pmtu 9170
 2?: [LOCALHOST]                      pmtu 1500
 2:  ip-etc.ip.prioritytelecom.net              14.973ms pmtu 9170
 3?: [LOCALHOST]                      pmtu 1500
 3:  ip-etc.ip.prioritytelecom.net               4.603ms 
 3:  ip-etc.ip.prioritytelecom.net               4.134ms 
 4:  asd-tr0021-cr101-be112-2.core.as33915.net             4.510ms asymm  5 
 5:  asd-tr0021-cr101-be112-2.core.as33915.net             5.735ms 
 6:  nl-ams04a-ri3-ae51-0.aorta.net                        4.205ms 
 7:  cr0.nikhef.nl.fusixnetworks.net                       4.624ms 
 8:  fusix-xe0-0-2.e1.ams0.transip.net                     5.380ms 
 9:  e1-a0.r1.ams0.transip.net                             5.234ms 
10:  no reply
11:  no reply
12:  www.transip.nl                                        5.011ms !H
     Resume: pmtu 1500

[Hipska]

Hipska schreef op woensdag 29 april 2020 @ 19:16:
Misschien beetje laat, maar Belgian IPv6 Council houdt nu een IPv6 101 - Refresher online webinar.

En de slides + recording zijn hier beschikbaar: Meetup #2 is behind us.

[Roetzen]

Dreamvoid schreef op donderdag 30 april 2020 @ 16:00:

Eindelijk even tijd om fatsoenlijk te reageren.

Ik zit niet in Nederland, dus geen KPN of Ziggo boxes, maar ook mijn providerbox hier doet geen fancy IPv6 dingen als prefix delegation, ICMPv6 firewall rules, 3rd party DNS servers, CLAT of NAT64. Komt nog wel, of ik koop op termijn eentje die het wel kan.

Ik nam aan dat mijn huidige modem/router (Arris Connectbox) prefix delegation zou ondersteunen, want mijn vorige (Ubee Evw321b) deed dat en gewoonlijk wordt het bij iedere volgende stap beter. Maar een testje met een FritzBox er achter is negatief. Met de Ubee ging het pobleemloos, maar nu krijg ik het niet meer aan de praat Dat is wel een dikke minpunt. IPv6 firewall is ook niet om over naar huis te schrijven.

Mijn verwachting is dat de providernetwerken als eerste helemaal single stack IPv6 worden, met IPv4-as-a-service naar de consumenten/bedrijven toe (in de vorm van een v4 tunnel naar de gateway, of NAT64), die dan vervolgens de keus hebben om intern single stack v4, v6 of dual te draaien.

Ik zie dat voor de vaste netwerken toch nog niet zo heel snel gebeuren hier in Nederland. Ze ondersteunen nu allemaal full Dual Stack Ik zie geen korte termijn meerwaarde in het afbouwen daarvan ten faveure van single stack IPv6 met IPv4 as a service. Voor wie een nieuw netwerk wil starten ligt het anders uiteraard.

Oh ja, DS-Lite is net als NAT64 ook IPv4-as-a-service, v4 aanbieden over een v6 netwerk. Tunnels versus translation, maar het eind effect is hetzelfde.

Verschil met NAT64 is vooral dat de topografie met DS-Lite wat meer vast ligt: de tunnel loopt altijd van de CPE gateway router naar de AFTR bij de provider.

Dat is vast sneller dan via en derde partij. Ik haalde met mijn SixXs en he.net tunnels ook nooit de volle snelheid van IPv4, zelden meer dan de helft.

Met NAT64 ben je iets flexibeler: de uiteindelijke NAT64 kan bij de provider gebeuren, maar ook compleet ergens anders op de wereld, of lokaal op de CPE gateway, het wordt dan net zoiets als DNS eigenlijk.

De 4-naar-6 vertaling kan op applicatie (netwerk API)-level gebeuren, op het device-level (464XLAT), of ergens anders op de route (een router met een CLAT daemon).

Inderdaad flexibeler, maar of dat ook "beter" is? Ik kan het nog niet overzien. .

Dan bedoelde ik niet - ik bedoel: bij de meeste implementaties heeft de provider duizenden DS-Lite tunnels achter 1 publiek IPv4 adres op de AFTR zitten.

Duizenden? Nee, dat denk ik niet. Ik heb vor CGNAT getallen gehoord van 5 tot 20 klanten per publiek IPv4 adres. Met meer kom je al gauw poorten te kort. Ofwel de pool IPv4 adressen is een vijfde tot een twintigste van het aantal klanten, Geen duizendste.

Maar ze kunnen ook achter elk publiek v4 adres maar 1 tunnel zetten. Verschil met de klassieke 1-publiek-IPv4-adres-per-huishouden situatie is dan dat de NAT44 niet op de CPE router gebeurt maar aan het eind van de tunnel op de AFTR. Dit is bv een manier om enterprise klanten toch eigen publieke v4 adressen te kunnen geven, ook al heb je als provider helemaal geen v4 netwerk meer.

Technisch zou het kunnen denk ik. Maar als de klant dan niet bij de NAT tabellen kan, heeft ie er nog iet zo veel aan. Ik zie geen voordelen boven het omgekeerde van wat SixXs en he,net deden en he.net nog steeds doet voor gebruikers die geen native IPv6 va hun provider krijgen. Ipv4 via en 4in6 tunnel. Dan ben je ook weer flexibeler want die service hoef je dan niet bij je eigen provider te betrekken...

Dit is trouwens ook een goeie in de DS-Lite specs, heeft er al 1 provider dit geimplementeerd?

PCP? Nee, niet dat ik weet. Misschien moesten ze dat ook maar niet gaan doen. Om IPv6 te bevorderen is het strategisch handig om geen "leuke dingen" meer aan te bieden met IPv4.

offtopic:
Deden ze met DVBC en breedbeeltelevisie ook. Via analoog kreeg je nepbreedbeeld. Van de 576 voor het beeld bruikbare lijnen werden alleen de middelste 432 gebruikt. Wie echt breedbeeld wilde met de volle 567 lijnen, moest aan de digitale TV. Er was wel een oplossing voor de analoge TV: PALplus, maar dat werd door de kabelboeren niet aangeboden.

http://www.vlist.eu/columns/nepbreedbeeld.htm

Hipska schreef op woensdag 6 mei 2020 @ 09:35:
[...]


En de slides + recording zijn hier beschikbaar: Meetup #2 is behind us.

Dank voor de link.

[ Voor 3% gewijzigd door Roetzen op 06-05-2020 16:51 ]

[jk-5]

Roetzen schreef op woensdag 6 mei 2020 @ 16:50:
[...]
Ik nam aan dat mijn huidige modem/router (Arris Connectbox) prefix delegation zou ondersteunen, want mijn vorige (Ubee Evw321b) deed dat en gewoonlijk wordt het bij iedere volgende stap beter. Maar een testje met een FritzBox er achter is negatief. Met de Ubee ging het pobleemloos, maar nu krijg ik het niet meer aan de praat Dat is wel een dikke minpunt. IPv6 firewall is ook niet om over naar huis te schrijven.

[...]

Hmm, hoi vanaf ipv6 achter een Arris Connectbox. Naar mijn ervaring werken deze zelfs stabieler dan de oudere ubees. Ik heb de ipv6 firewall simpelweg uitgezet en doe alles zelf. Ik krijg een /60 per dhcpv6-pd sessie, eigenlijk zonder moeite (EdgeRouter)

[Roetzen]

jk-5 schreef op woensdag 6 mei 2020 @ 16:53:
[...]


Hmm, hoi vanaf ipv6 achter een Arris Connectbox. Naar mijn ervaring werken deze zelfs stabieler dan de oudere ubees. Ik heb de ipv6 firewall simpelweg uitgezet en doe alles zelf. Ik krijg een /60 per dhcpv6-pd sessie, eigenlijk zonder moeite (EdgeRouter)

Aha. Het ligt dus aan mij. Dat is een opluchting want als het aan mij ligt, kan ik er iets aan doen. Ik begrijp dan even niet waarom de Frizbox wel netjes een /60 kreeg van de Ubee, en dit nu met de connectbox niet lukt, maar nu ik zeker weet dat het kan, heb ik weer moed om verder te gaan zoeken

Bedankt voor de aanvulling.
.

[Dreamvoid]

Roetzen schreef op woensdag 6 mei 2020 @ 16:50:
Duizenden? Nee, dat denk ik niet. Ik heb vor CGNAT getallen gehoord van 5 tot 20 klanten per publiek IPv4 adres. Met meer kom je al gauw poorten te kort. Ofwel de pool IPv4 adressen is een vijfde tot een twintigste van het aantal klanten, Geen duizendste.

Het IETF/IANA draft document over CG-NAT deployment (linkje via google) gaat uit van geschat 3051 adressen per 1 miljoen klanten bij dynamic allocation, dus om eerlijk te zijn - dat 5-20 per klant lijkt me sterk. Ik bedoel, een huis tuin en keuken router met de performance van een keukenwekker doet al NAT voor 20 devices.

[Hipska]

Reken eens uit.. Je hebt het over 20 klanten en je zegt dat die 20 devices hebben, dan kom je al snel op 200 devices die poorten gebruiken.

[Dreamvoid]

Heb je dat IETF document gelezen? Daar werken ze het voorbeeld uit, je hebt 64k poorten per IPv4 adres, en typisch ~100 sessies gelijktijdig per actieve klant (providers beperken doorgaans sowieso het aantal sessies per klant, als beveiliging tegen ddos), plus nog een deel overboeking omdat niet al je klanten tegelijkertijd actief zijn.

Je ziet in de documentatie van Citrix Netscaler servers (die de providers hiervoor gebruiken) ook allemaal voorbeelden met mappings van 1 publiek naar duizenden private adressen.

[ Voor 119% gewijzigd door Dreamvoid op 07-05-2020 01:05 ]

[Hipska]

"Het IETF document"? Er zijn er nogal wat. En nee, ik ga ze niet allemaal lezen.

200 devices met ongeveer 100 sessies, dat maakt een totaal van 20k sessies. Lijkt me een goede marge op 64k poorten. Daarnaast spreek je over dynamische allocatie, dan kan je inderdaad hogere bezetting aan.

[Roetzen]

Dreamvoid schreef op woensdag 6 mei 2020 @ 21:11:
[...]

Het IETF/IANA draft document over CG-NAT deployment (linkje via google) gaat uit van geschat 3051 adressen per 1 miljoen klanten

3051? Niet 3049 of 3053?

Zulke precieze getallen in combinatie met het woord "schatting" laten bij mij de oranje en rode lampjes branden. Nee, ik heb het betreffende document niet gelezen. Ik had geen link.

bij dynamic allocation, dus om eerlijk te zijn - dat 5-20 per klant lijkt me sterk. Ik bedoel, een huis tuin en keuken router met de performance van een keukenwekker doet al NAT voor 20 devices.

Het gaat niet om de beschikbare rekenkracht, maar om het aantal beschikbare poorten. Met 3000 adressen per miljoen klanten deel je een adres ,met iets meer dan 300 anderen. (Geen duizenden) Dan heb je 200 poorten per klant beschikbaar. Dat lijkt me heel krap als die 200 poorten ook nog in het lokale LAN van de klant met meerderen gedeeld moeten worden. Als het dynamisch wordt toegewezen is er meer ruimte, maar dan nog...

OK, 5-20 is misschien aan de ruime kant en dat getal is mogelijk gedateerd,

Hipska schreef op donderdag 7 mei 2020 @ 10:39:
200 devices met ongeveer 100 sessies, dat maakt een totaal van 20k sessies. Lijkt me een goede marge op 64k poorten. Daarnaast spreek je over dynamische allocatie, dan kan je inderdaad hogere bezetting aan.

Het hoeft volgens mij ook helemaal niet zo krap. Ja, de IPv4 adressen zijn op, je kunt geen nieuwe meer krijgen. Maar bij de providers ligt nog wel wat op de plank. Één adres delen met "duizenden" klanten lijkt me onnodig. Met één adres per 20 klanten, kunnen ze het ook nog wel een tijdje volhouden. Misschien zelfs wel tot IPv4 niet meer relevant is...

[ Voor 22% gewijzigd door Roetzen op 07-05-2020 13:09 ]

[Hipska]

Roetzen schreef op donderdag 7 mei 2020 @ 11:26:
Het hoeft volgens mij ook helemaal niet zo krap. Ja, de IPv4 adressen zijn op, je kunt geen nieuwe meer krijgen. Maar bij de providers ligt nog wel wat op de plank. Één adres delen met "duizenden" klanten lijkt me onnodig. Met één adres per 20 klanten, kunnen ze het ook nog wel een tijdje volhouden. Misschien zelfs wel tot IPv4 niet meer relevant is...

Idd, dat probeer ik duidelijk te maken.

[Snow_King]

Roetzen schreef op donderdag 7 mei 2020 @ 11:26:
[...]
Het hoeft volgens mij ook helemaal niet zo krap. Ja, de IPv4 adressen zijn op, je kunt geen nieuwe meer krijgen. Maar bij de providers ligt nog wel wat op de plank. Één adres delen met "duizenden" klanten lijkt me onnodig. Met één adres per 20 klanten, kunnen ze het ook nog wel een tijdje volhouden. Misschien zelfs wel tot IPv4 niet meer relevant is...

Daarom moet de druk ook vanuit de content komen. Want de providers zullen toch niet al te snel bewegen.

[ANdrode]

Roetzen schreef op donderdag 7 mei 2020 @ 11:26:
[...]
Het gaat niet om de beschikbare rekenkracht, maar om het aantal beschikbare poorten. Met 3000 adressen per miljoen klanten deel je een adres ,met iets meer dan 300 anderen. (Geen duizenden) Dan heb je 200 poorten per klant beschikbaar. Dat lijkt me heel krap als die 200 poorten ook nog in het lokale LAN van de klant met meerderen gedeeld moeten worden. Als het dynamisch wordt toegewezen is er meer ruimte, maar dan nog...

Het ligt eraan wat voor soort NAT je doet. Je lijkt nu uit te gaan van full-cone NAT waarbij er voor elke actieve flow een externe poort nodig is. Wanneer je ook de destination host meeneemt (bijvoorbeeld port-restricted cone nat) kan je veel meer flows per IP adres in de pool doen.

Methods of translation:

[Dreamvoid]

200 sessies per klant is vrij normaal. Als je de Citrix documentatie doorkijkt gaan ze in hun voorbeeld configs uit van een port quota van 500 per klant. Uitgaande dat niet iedereen tegelijk zijn quota voltrekt kom je er dan wel in die orde grootte. In dit IETF document gaan ze uit van gemiddeld 400 sessies per klant: https://tools.ietf.org/id...nt-considerations-00.html (paragraaf 5.2)

Ik weet niet zo goed wat ik met deze discussie aanmoet - ik lees al jarenlang in presentaties en papers over orde groottes van duizenden klanten per adres voor CG-NAT44. Dan ben ik gewoon erg verbaasd over een claim van 5-20. Aangezien geen enkele provider publiek gaat vertellen hoe strak hij zijn portquota’s ingesteld heeft, gaan we er zo nooit uitkomen natuurlijk.

[Roetzen]

Hipska schreef op donderdag 7 mei 2020 @ 14:43:
[...]
Idd, dat probeer ik duidelijk te maken.

Maar dat geldt niet voor nieuwkomers die geen restanten IPv4 op de plank hebben liggen Die moeten er zuiniger mee omspringen zou je zeggen. En toch... lees verder...

Snow_King schreef op donderdag 7 mei 2020 @ 15:07:
[
Daarom moet de druk ook vanuit de content komen. Want de providers zullen toch niet al te snel bewegen.

De providers zijn heel traag op gang gekomen, maar ik heb de indruk dart er nu best vaart in is gekomen. Het zijn nu de bedrijven die afwachten...

ANdrode schreef op donderdag 7 mei 2020 @ 18:42:
[...]
Het ligt eraan wat voor soort NAT je doet. Je lijkt nu uit te gaan van full-cone NAT waarbij er voor elke actieve flow een externe poort nodig is. Wanneer je ook de destination host meeneemt (bijvoorbeeld port-restricted cone nat) kan je veel meer flows per IP adres in de pool doen.

Inderdaad , met meer moeite kun je er meer uit slepen. Maar of al die moeite de "winst" rechtvaardigt? als je met 20 klanten per IPv4 adres het met een eenvoudig cone NAT, kunt uitzingen tot het niet meer nodig is, waarom dan al die moeite?

Dreamvoid schreef op vrijdag 8 mei 2020 @ 00:09:

Ik weet niet zo goed wat ik met deze discussie aanmoet - ik lees al jarenlang in presentaties en papers over orde groottes van duizenden klanten per adres voor CG-NAT44. Dan ben ik gewoon erg verbaasd over een claim van 5-20. Aangezien geen enkele provider publiek gaat vertellen hoe strak hij zijn portquota’s ingesteld heeft, gaan we er zo nooit uitkomen natuurlijk.

Ik weet ook niet zo goed wat ik er mee moet. Ik heb even gauw een berekeningetje gemaakt op de achterkant van een bierviltje. Dat is riskant, want er zitten aannames in en aannames zitten er wel eens naast. Ik ging uit van een eenvoudig NAT en een zeer comfortabele marge. Je kan waarschijnlijk met veel minder marge toe als je nog wat trukendozen opentrekt en dynamisch toewijst. Maar of ze dat ook doen en wat minder krenterig zijn met de pool van IPv4 adressen weten we niet. De providers maken inderdaad geen cijfers bekend en gelijk hebben ze want dat is gevoelige informatie die zowel de concurrentie positie als de beurswaarde kan beïnvloeden.

Nu merkten we al op dat het voor een nieuwkomer op de markt anders kan liggen. Die heeft geen restanten IPv4 op de plank liggen. En die wordt ook niet gehinderd door remmende voorsprong. Je zou zeggen, die gaat met een IPv6 only netwerk aan de gang met IPv4 as a service, DNS64/NAT64 ligt dan voor de hand.

Nu wil het geval dart we hier in Nederland een nieuwkomer hebben: Freedom Internet. Opgericht door een aantal enthousiastelingen uit onvrede over het besluit van KPN om Xs4All op te heffen en te integreren in KPN.

Maar Freedom kiest voor de klassieke weg. Ze gaan de klanten een /48 IPv6 plus een publiek routeerbaar IPv4 aanbieden. En wel middels Full Dual Stack. Ze zijn bezig IPv4 in te kopen. Of ze dat allemaal lukt gaan we nog zien, maar ze zijn er zelf behoorlijk optimistisch over,

Opmerkelijk dus dat de enige nieuwkomer die we nu hebben en die niet gehinderd wordt door een bestaande structuur niet kiest voor een IPv6 only netwerk, maar kiest voor Full Dual Stack...

[Paul]

Mwoah, juist bij Freedom (XS4All) zitten de enthousiastelingen. Die hebben bovengemiddeld vaak thuis een server draaien, en zolang IPv6 nog geen gemeengoed (of iig niet genoeg) is, willen die graag bereikbaar zijn op IPv4.

Dan kun je wel (reverse) NAT64 doen zodat mensen met IPv4 bij jouw IPv6 server kunnen, maar je kunt poort 80 of 443 maar één keer uitdelen. Daar kom je als premium provider voor enthousiastelingen niet mee weg.

Was dit de zoveelste Ziggo of KPN-kloon (gericht op de grote massa) dan zou ik het ook een rare keuze vinden. Met de doelgroep die Freedom voor ogen heeft zou ik het raar vinden als ze het niet doen.

[ik222]

Dat is inderdaad compleet logisch, full dual stack is namelijk ook de enige realistische optie voor een premium provider die Freedom wil zijn. Hun klanten laten een provider simpelweg links liggen als ze geen eigen globaal routeerbaar IPv4 adres krijgen direct op hun eigen router.

Dat geldt voor mij trouwens ook, full dualstack is een harde eis voor mij als ik een ISP kies.

[Roetzen]

Paul schreef op vrijdag 8 mei 2020 @ 13:50:
Mwoah, juist bij Freedom (XS4All) zitten de enthousiastelingen. Die hebben bovengemiddeld vaak thuis een server draaien, en zolang IPv6 nog geen gemeengoed (of iig niet genoeg) is, willen die graag bereikbaar zijn op IPv4.

Zoals @Dreamvoid uitgebeid heeft bepleit zijn er meer wegen die naar Rome leiden en Full Dual Stack is maar één van die wegen. En de enthousiastelingen van Xs4All zijn ook degenen die best eens wat nieuws willen proberen in plaats van de gebaande paden.

Dan kun je wel (reverse) NAT64 doen zodat mensen met IPv4 bij jouw IPv6 server kunnen, maar je kunt poort 80 of 443 maar één keer uitdelen. Daar kom je als premium provider voor enthousiastelingen niet mee weg.

Hoeft ook niet. IPv4 as a service hoeft niet in te houden dat de klant geen eigen IPv4 adres heeft. Je kunt IPv4 bijvoorbeeld ook via een tunnel aanbieden. Als dat via de provider gaat, hoeft dat geen merkbare snelheidsvermindering te betekenen. Een andere manier is dat de provider een dienst als feste-ip.net aanbiedt.

ik222 schreef op vrijdag 8 mei 2020 @ 14:11:
Dat is inderdaad compleet logisch, full dual stack is namelijk ook de enige realistische optie voor een premium provider die Freedom wil zijn.

Welnee, zoals gezegd er zijn meer wegen die naar Rome leiden. Dat klassiek Full Dual Stack de enige realistische optie is bestrijd ik. En ik denk dat er genoeg Ex Xs4All klanten zijn die best wel een alternatief willen proberen.

Hun klanten laten een provider simpelweg links liggen als ze geen eigen globaal routeerbaar IPv4 adres krijgen direct op hun eigen router.

Full Dual Stack is niet de enige manier om dat voor elkaar te krijgen en het is mogelijk niet eens de beste manier voor een provider die vanaf nul begint.

Dat geldt voor mij trouwens ook, full dualstack is een harde eis voor mij als ik een ISP kies.

Dan beperk je jezelf wel erg. Het doet me denken aan de discussies over elektrische autos. Daar is ook altijd een harde kern die alleen aan het elektriek wil als die op een acculading net zo ver kan rijden als de diesel die ze nu hebben. Zonder verder oog te hebben voor al de voordelen van elektrisch rijden.

[ Voor 10% gewijzigd door Roetzen op 08-05-2020 14:58 ]

[Paul]

Roetzen schreef op vrijdag 8 mei 2020 @ 14:53:
Zoals @Dreamvoid uitgebeid heeft bepleit zijn er meer wegen die naar Rome leiden

Dat stuk heb ik dan gemist, het gaat de afgelopen maand alleen maar over dual stack of een vorm van NAT?

Dan beperk je jezelf wel erg.

Tja. Als mijn huidige provider nu zou ophouden te bestaan dan zoek ik ook een nieuwe provider waar ik TCP/80 en TCP/443 op IPv4 benaderbaar heb richting mijn server. De gebruikelijke manier daarvoor is een publiek routeerbaar IPv4-adres op je CPE, en de gebruikelijke manier daar weer voor is afaik dual stack (als je ook IPv6 hebt iig, IPv4 only kan natuurlijk ook, al zou dat wel erg jammer zijn anno 2020).

Als het op een andere manier hetzelfde resultaat biedt, prima, zul je mij niet horen, maar voor nu is IPv4 voor mij nog te belangrijk om te laten schieten. Al die voordelen zijn prachtig (voor IPv6, of voor elektrische auto's, maakt niet uit), maar ze moeten wel opwegen tegen de nadelen Voor heel veel mensen doet het dat (of maakt het geen klap uit), maar niet voor iedereen.

[Dreamvoid]

Het is op zich niet zo heel lastig - als je hobbyist bent die een server draait die per se over IPv4 beschikbaar moet zijn (oftewel, voor clients op het deel van het internet dat nog geen IPv6 heeft), dan heb je drie keuzes: host de boel ergens anders (VPS) met een v4 adres, tunnel een publiek v4 adres je huis in via een 3rd party provider, of met een ISP die je een publiek v4 adres geeft.

Maar zodra de clients voor je servers allemaal IPv6 hebben, dan valt die keiharde eis voor dual stack vanzelf weg, ook voor 'power users'. Over een tijdje zijn de mobiele telco's ws allemaal IPv6 (KPN is nu volop aan het uitrollen, en als je andere Europese landen bekijkt zit er aardig vaart achter), dus dat haalt al een stevige beperkende factor weg. Bij de vaste lijn rollen langzaam de oude providerboxen eruit die geen v6 doen.

Mensen die geen servers draaien boeit het weinig of ze achter CG-NAT zitten. 100% van het verkeer over NAT44 sturen is een irritante kostenpost voor de provider, dus die zal je op termijn graag IPv6 geven om zo de load op zijn NAT servers te verlichten, maar we internetten al 25 jaar massaal achter CG-NAT op onze mobieltjes en hoeveel eindgebruikers hoor je erover klagen?

Tja. Als mijn huidige provider nu zou ophouden te bestaan dan zoek ik ook een nieuwe provider waar ik TCP/80 en TCP/443 op IPv4 benaderbaar heb richting mijn server.

Dat hoeft op zich niet je eigen ISP te zijn. Je kan een v4 tunnel (met publiek IPv4 adres en port 80/433 open) vanuit overal ter wereld huren. Op precies dezelfde manier hebben hobbyisten jarenlang IPv6 tunnelproviders gebruikt, om v6 te doen als je provider enkel v4 doet.

Wat mijn eerdere punt een beetje was: waarom een compleet IPv4 circus met DHCP, NAT, portforwarding etc in de lucht blijven houden voor 20 devices op je LAN, als er eigenlijk maar 1 server binnen je LAN staat die een publiek v4 adres nodig heeft (om extern over v4 bereikt te kunnen worden)? Hou de hele boel simpel op single stack v6, en zet specifiek voor die ene server een tunnel op naar een publiek v4 adres.

Daar zijn we nu nog niet, maar het is denk ik wel de moeite waard om het prijsverschil tussen een "full dual stack" provider en een DS-Lite/464XLAT provider plus een aparte v4 tunnel in de gaten te houden.

[ Voor 33% gewijzigd door Dreamvoid op 08-05-2020 17:22 ]

[ANdrode]

Paul schreef op vrijdag 8 mei 2020 @ 13:50:
Was dit de zoveelste Ziggo of KPN-kloon (gericht op de grote massa) dan zou ik het ook een rare keuze vinden. Met de doelgroep die Freedom voor ogen heeft zou ik het raar vinden als ze het niet doen.

Zelfs Ziggo is terug aan het krabbelen van DS-lite. Je ziet nu de uitrol van dual-stack.

Ik zou bij Freedom (of XS4ALL) misschien opt-in voor NAT64 als optie verwachten. Maar dat kost alleen maar meer: Het dual-stack netwerk is voorlopig toch nodig.

offtopic:
Wel zou Freedom mogelijk in hun management vlan's single stack kunnen gaan. We zijn ver genoeg om dat single stack te kunnen doen, alles wat je nu nog koopt kan IPv6, zelfs embedded.

[Dreamvoid]

Wat een provider zelf doet op zijn interne netwerk, dat zie je eigenlijk niet als klant. Of je je IPv4 adres via een tunnel over een verder volledig IPv6 provider netwerk krijgt, of via een volledig 'native' route over een parallel netwerk krijgt aangeboden, dat kom je nooit te weten.

[ Voor 18% gewijzigd door Dreamvoid op 08-05-2020 22:32 ]

[Roetzen]

Paul schreef op vrijdag 8 mei 2020 @ 16:53:

Tja. Als mijn huidige provider nu zou ophouden te bestaan dan zoek ik ook een nieuwe provider waar ik TCP/80 en TCP/443 op IPv4 benaderbaar heb richting mijn server. De gebruikelijke manier daarvoor is een publiek routeerbaar IPv4-adres op je CPE, en de gebruikelijke manier daar weer voor is afaik dual stack (als je ook IPv6 hebt iig,

Nieuwe dingen ontstaan doordat mensen verder kijken dan "de gebruikelijke manier" en eens wat anders proberen. Een 4in6 tunnel is al genoemd. Als het alleen om http(s) gaat, is een application gateway ook een mogelijkheid.

IPv4 only kan natuurlijk ook, al zou dat wel erg jammer zijn anno 2020).

Voor mij kan dat anno 2020 niet meer. Een provider die vandaag de dag geen IPv6 biedt is voor mij meer dan jammer. Die gaat direct van mijn lijstje. Ik heb nu sinds medio 2016 native IPv6. Dat ga ik niet meer opgeven. Niet vrijwillig althans. Als ik moet kiezen tussen tussen een provider die IPv4 only met publiek IPv4 adres aanbiedt of een provider die IPv6 zonder publiek IPv4 adres aanbiedt, dan is voor mij de keuze duidelijk. Dan maar geen publiek IPv4 adres. Geen IPv6 is voor mij geen optie. Noem dat maar een harde harde eis...

Als het op een andere manier hetzelfde resultaat biedt, prima, zul je mij niet horen, maar voor nu is IPv4 voor mij nog te belangrijk om te laten schieten. Al die voordelen zijn prachtig (voor IPv6, of voor elektrische auto's, maakt niet uit), maar ze moeten wel opwegen tegen de nadelen

Het is altijd zinvol het eisenpakket af en toe door te nemen om te zien of je dingen niet anders kan doen zodat het lijstje korter wordt.Wie een nieuwe auto nodig heeft zou zich kunnen afvragen of het echt wel nodig is om in één avond op een tank/acculading van Amsterdam naar Antwerpen en terug te rijden. Of dat je het misschien anders kan doen. Door bijvoorbeeld in Antwerpen te laden. Of helemaal niet naar Antwerpen te gaan en het via Skype te doen. Ik heb drie jaar geleden al eens onderzocht hoe het zou zijn als mijn provider mij op DS-Lite zou zetten.Ik heb zelfs emulaties gedraaid waarbij ik IPv4 in fasen geheel of gedeeltekijk uitgeschakeld heb. Ik liep bij dat proces ook tegen feste-ip.net aan. Mijn conclusie was dat ik wel met DS-Lite zou kunnen leven,

Voor heel veel mensen doet het dat (of maakt het geen klap uit), maar niet voor iedereen.

Een goede vraag die je jezelf zou kunnen stellen is: "als ik extra zou moeten betalen voor een globaal routeerbaar IPv4 adres, hoeveel heb ik er dan voor over?" Ik kom voor mijzelf op €2 per maand.

Dreamvoid schreef op vrijdag 8 mei 2020 @ 17:01:

Mensen die geen servers draaien boeit het weinig of ze achter CG-NAT zitten. 100% van het verkeer over NAT44 sturen is een irritante kostenpost voor de provider, dus die zal je op termijn graag IPv6 geven om zo de load op zijn NAT servers te verlichten, maar we internetten al 25 jaar massaal achter CG-NAT op onze mobieltjes en hoeveel eindgebruikers hoor je erover klagen?

Ik kreeg 6 of 7 jaar geleden van KPN nog een globaal routeerbaar IPv4 adres op mijn laptop met dongeltje. Dus het is iets minder dan 25 jaar. Maar servers draaien op een mobieltje is om diverse redenen niet zo handig, dus niet vreemd dat je er weinig klachten over hoort.

ANdrode schreef op vrijdag 8 mei 2020 @ 21:23:

Zelfs Ziggo is terug aan het krabbelen van DS-lite. Je ziet nu de uitrol van dual-stack.

Dat is wat te snel geconcludeerd. Het beleid van Ziggo in dezen is totaal ondoorzichtig. Het lijkt er inderdaad op dat er in fZiggo gebied wat ruimhartiger Full Stack wordt uitgedeeld dan in fUPC gebied. Maar er zijn ook gevallen gerapporteerd waar klanten van Full Dual Stack op DS-Lite zijn gezet. Dat Ziggo aan het terugkrabbelen is van DS-Lite is te snel geconcludeerd.

Ik zou bij Freedom (of XS4ALL) misschien opt-in voor NAT64 als optie verwachten. Maar dat kost alleen maar meer: Het dual-stack netwerk is voorlopig toch nodig.

Ook dat vind ik te snel geconcludeerd. Ze zouden bijvoorbeeld DS-Lite of NAT64/DNS64 kunnen gaan en wie een globaal IPv4 adres wil dat via een tunnel aan kunnen bieden. Wie dat laatste niet wil krijgt een korting.

offtopic:
Wel zou Freedom mogelijk in hun management vlan's single stack kunnen gaan. We zijn ver genoeg om dat single stack te kunnen doen, alles wat je nu nog koopt kan IPv6, zelfs embedded.

Mijn inmiddels bijna 3 jaar oude Samsung TV doet nog steeds geen IPv6

Dreamvoid schreef op vrijdag 8 mei 2020 @ 22:30:
Wat een provider zelf doet op zijn interne netwerk, dat zie je eigenlijk niet als klant. Of je je IPv4 adres via een tunnel over een verder volledig IPv6 provider netwerk krijgt, of via een volledig 'native' route over een parallel netwerk krijgt aangeboden, dat kom je nooit te weten.

Als je vast zit aan de een door de provider volledig dichtgetimmerde "black box" wordt het inderdaad lastig te zien wat er precies gebeurt. Maar als je (zoals bij KPN en straks Freedom) eigen modem/routers mag inzetten, dan wordt het vrij snel duidelijk als je die gaat configureren lijkt me.

En anders is er naar goed Nederlands gebruik wel ergens een "lek" waardoor het toch bekend wordt,

[ Voor 40% gewijzigd door Roetzen op 09-05-2020 17:26 ]

[Dreamvoid]

Roetzen schreef op zaterdag 9 mei 2020 @ 11:49:
Ik kreeg 6 of 7 jaar geleden van KPN nog een globaal routeerbaar IPv4 adres op mijn laptop met dongeltje. Dus het is iets minder dan 25 jaar. Maar servers draaien op een mobieltje is om diverse redenen niet zo handig, dus niet vreemd dat je er weinig klachten over hoort.

Je kan bij de meeste telco's nog steeds een publiek IPv4 adres krijgen maar dat zijn eigenlijk alleen zakelijke/IoT abonnementen, stervensduur.

Een server hosten via een mobiel netwerk is in theorie wel te doen (ik heb er enige ervaring mee, servertje achter een 4G router), maar doordat je achter CG-NAT hangt moet je niet alleen allerlei trucs uithalen om uberhaupt bij je server te kunnen komen (pick your poison: UDP Hole Punching, v4 tunnel, ssh port forwarding, VPN) maar zit je ook met de port quota op de NAT server van je provider. Als je bijvoorbeeld gecapped bent op 200 open sessies tegelijk, dan wordt de performance van je server nogal heel beroerd zodra je veel clients hebt.

In principe moet hosting op een IPv6 mobiel netwerk, zonder NAT, een stuk minder ellende geven. Tenminste, als die ellendige telco's tenminste niet al het inkomende verkeer gaan firewallen, want dan zijn we weer terug bij af.

Als je vast zit aan de een door de provider volledig dichtgetimmerde "black box" wordt het inderdaad lastig te zien wat er precies gebeurt. Maar als je (zoals bij KPN en straks Freedom) eigen modem/routers mag inzetten, dan wordt het vrij snel duidelijk als je die gaat configureren lijkt me.

Dan ga je ervan uit dat die v4 tunnel of CLAT termineert op je router thuis, maar dat kan natuurlijk ook de wijkcentrale zijn.

[ Voor 19% gewijzigd door Dreamvoid op 09-05-2020 17:48 ]

[Olaf van der Spek]

Dreamvoid schreef op vrijdag 8 mei 2020 @ 17:01:
Mensen die geen servers draaien boeit het weinig of ze achter CG-NAT zitten.

Wat versta je onder servers?
Valt een Call of Duty game (of andere game, ook op een console) hosten, gewoon in de normale client, daar ook onder?
En dat het ze niet boeit betekent niet dat ze er geen nadelen van ondervinden.

[Dreamvoid]

Een game server lijkt me ook een server?

[Olaf van der Spek]

Dreamvoid schreef op zaterdag 9 mei 2020 @ 21:27:
Een game server lijkt me ook een server?

Is / was Skype / AVoIP ook een server dan? Steam? Windows 10 delivery optimization? Een BitTorrent client?
Wie draait er dan geen 'servers'?
Onder een game server draaien versta ik toch iets anders dan gewoon een multiplayer potje hosten.

[ Voor 26% gewijzigd door Olaf van der Spek op 09-05-2020 21:44 ]

[Roetzen]

Dreamvoid schreef op zaterdag 9 mei 2020 @ 17:45:
[...]

Je kan bij de meeste telco's nog steeds een publiek IPv4 adres krijgen maar dat zijn eigenlijk alleen zakelijke/IoT abonnementen, stervensduur.

Ook bij de mobielen? Nou ja, "stervensduur" is voor de particulier toch niet interessant,

In principe moet hosting op een IPv6 mobiel netwerk, zonder NAT, een stuk minder ellende geven. Tenminste, als die ellendige telco's tenminste niet al het inkomende verkeer gaan firewallen, want dan zijn we weer terug bij af.

Hier in Nederland doen ze dat gelukkig (nog) niet, maar in België doet Proximus dat wel, ook op vaste verbindingen. Een Belgische kennis heeft alleen uitgaand IPv6, want poorten openen in de IPv6 firewall in zijn CPE is afgegrendeld met een wachtwoord dat de gewone consument niet krijgt

Dan ga je ervan uit dat die v4 tunnel of CLAT termineert op je router thuis, maar dat kan natuurlijk ook de wijkcentrale zijn.

Inderdaad. Het was niet bij me opgekomen dat een provider zijn netwerk intern IPv6 only met IPv4AAS zou maken, behalve de laatste kilometer. Dat lijkt me onlogisch en inefficiënt.

Bij wat lukraak zoeken op "IPv6" vond ik nog een interessante beschouwing van Iljitstch van Beijnum waar "IPv4 as a service" ook aan de orde komt:

http://www.inet6consult.c...succes-bij-25-procent.php

En nog iets leuks over (een beetje) uitschakelen van IPv4.

http://www.iljitsch.com/2...te-zetten-een-beetje.html

Misschien ga ik op mijn website ook maar eens spelen met dat idee.

[ Voor 54% gewijzigd door Roetzen op 10-05-2020 13:32 ]

[ANdrode]

Roetzen schreef op zondag 10 mei 2020 @ 11:48:
[...]
Inderdaad. Het was niet bij me opgekomen dat een provider zijn netwerk intern IPv6 only met IPv4AAS zou maken, behalve de laatste kilometer. Dat lijkt me onlogisch en inefficiënt.

Het lijkt mij met software defined networking juist een behoorlijk logische aanpak. Afhankelijk van de structuur doe je dit bij de PPPoE BRAS of op de switch bij glasvezel.

offtopic:
Switches zijn écht slim geworden tegenwoordig: Zelfs een volledige BGP tabel zit nu op bepaalde switches

[Roetzen]

ANdrode schreef op zondag 10 mei 2020 @ 15:14:
[...]


Het lijkt mij met software defined networking juist een behoorlijk logische aanpak. Afhankelijk van de structuur doe je dit bij de PPPoE BRAS of op de switch bij glasvezel.

offtopic:
Switches zijn écht slim geworden tegenwoordig: Zelfs een volledige BGP tabel zit nu op bepaalde switches

Ja maar het hele idee van een provider IPv6 only netwerk met IPv4AAS is toch juist dat je enkel een single stack netwerk hoeft te onderhouden in plaats van twee als je Dual Stack doet? En dat je het "service" deel aan de klant kant zo veel mogelijk afschuift op de CPE ? Wat zie ik over het hoofd?

[ANdrode]

Roetzen schreef op zondag 10 mei 2020 @ 17:45:
[...]

Ja maar het hele idee van een provider IPv6 only netwerk met IPv4AAS is toch juist dat je enkel een single stack netwerk hoeft te onderhouden in plaats van twee als je Dual Stack doet? En dat je het "service" deel aan de klant kant zo veel mogelijk afschuift op de CPE ? Wat zie ik over het hoofd?

Bedoel je IPv4 as a service door een externe provider? Of door de provider zelf? En bij extern: wordt dat transit of peering verkeer?

Het probleem is vaak CPE. Die heeft de rekenkracht (en hardware acceleratie) niet om het rekenwerk voor tunneling op line speed te doen. En een klant wentelt de lagere snelheid af op de provider.

offtopic:
Voorbeelden: Ziggo en connectbox, mensen met 1000/1000 en een Unify Security Gateway en niet doorhebben dat deze geen line speed aankan.

Roetzen schreef op zondag 10 mei 2020 @ 11:48:
[...]
http://www.iljitsch.com/2...te-zetten-een-beetje.html

[Afbeelding]

Vond het een leuke blog over de transitie maar hij slaat de vraag of IPv6+IPv4-nat goedkoper is dan dual-nat en of dual-stack. Want daar draait het uiteindelijk om.

offtopic:
Hij noemt trouwens dat hij het IPv6 nummerplan van de rijksoverheid heeft bedacht. Daar wil vast wel iemand over uitleggen waarom het een slecht idee is. Ik heb het verhaal gehoord maar kan het niet reproduceren.

[Dreamvoid]

Ja het is voor mij altijd wat onduidelijk geweest hoeveel cpu overhead tunnels (DS-Lite) hebben boven address translation (NAT44 of CLAT) op de CPE, ik kan daar ook weinig concrete info over vinden.

We weten op zich natuurlijk allang dat address translation goed te doen is op de doorsnee consumentenrouter, dat doen we al dertig jaar.

Is / was Skype / AVoIP ook een server dan? Steam? Windows 10 delivery optimization? Een BitTorrent client?
Wie draait er dan geen 'servers'?
Onder een game server draaien versta ik toch iets anders dan gewoon een multiplayer potje hosten.

Welke van die dingen doen geen IPv6? En bovendien, op 1 of andere manier gamen (en skypen) miljarden mensen al jaren op hun mobieltje achter CG-NAT. Er zijn absoluut scenarios waarbij je een publiek IPv4 adres wil, maar hoeveel procent van de consumenten hebben we het dan over?

[ Voor 73% gewijzigd door Dreamvoid op 12-05-2020 10:46 ]

[Roetzen]

ANdrode schreef op zondag 10 mei 2020 @ 19:02:
[...]


Bedoel je IPv4 as a service door een externe provider? Of door de provider zelf? En bij extern: wordt dat transit of peering verkeer?

Ik dacht aan door de provider zelf, zoals Ziggo doet met DS-Lite. Maar extern kan natuurlijk ook. Of het in dat laatste geval transit of peering verkeer zal zijn? Geen idee, zover heb ik me er nog niet in verdiept

Het probleem is vaak CPE. Die heeft de rekenkracht (en hardware acceleratie) niet om het rekenwerk voor tunneling op line speed te doen. En een klant wentelt de lagere snelheid af op de provider.

Is dat echt een probleem? Het enige voorbeeld uit de praktijk is DS-Lite Ik hoor geen signalen dat IPv4 via DS-Lite significant trager zou zijn dan Full Dual Stack.

Voorbeelden: Ziggo en connectbox, mensen met 1000/1000 en een Unify Security Gateway en niet doorhebben dat deze geen line speed aankan

De connectbox van Ziggo heeft allerlei problemen, maar dat die ie te traag zou zijn voor de DS-Lite tunnel heb ik nog niet gehoord. En ja, wie een eigen router gebruikt is natuurlijk op zichzelf aangewezen, die moet niet bij de provider gaan klagen.

Vond het een leuke blog over de transitie maar hij slaat de vraag of IPv6+IPv4-nat goedkoper is dan dual-nat en of dual-stack. Want daar draait het uiteindelijk om.

Tja, ik denk dat hij het ook nog niet weet. Er is nog te weinig vergelijkingsmateriaal...

Dreamvoid schreef op maandag 11 mei 2020 @ 12:35:
Er zijn absoluut scenarios waarbij je een publiek IPv4 adres wil, maar hoeveel procent van de consumenten hebben we het dan over?

Goede vraag. Ik denk dat je daar pas echt een antwoord op gaat krijgt als de klant een keuze heeft en er een prijskaartje aan hangt. Met een prijskaartje scheidt je het kaf van hen die het willen hebben om de "heb" van het koren van degenen die er echt iets mee doen wat (nog) niet anders kan.

[ Voor 14% gewijzigd door Roetzen op 12-05-2020 11:14 ]

[Maurits van Baerle]

Olaf van der Spek schreef op zaterdag 9 mei 2020 @ 21:36:
[...]

Is / was Skype / AVoIP ook een server dan? Steam? Windows 10 delivery optimization? Een BitTorrent client?
Wie draait er dan geen 'servers'?
Onder een game server draaien versta ik toch iets anders dan gewoon een multiplayer potje hosten.

Ik weet nog wel, jaren geleden inmiddels, dat een Duitse ISP overstapte naar DS-Lite en dat ze dat veel support calls opleverde omdat de PS4 geen DS-Lite slikt. Hij kan geen verbinding maken met de server o.i.d.

Ik weet niet of dat inmiddels is opgelost. De PS4 draait op een variant van FreeBSD en dat was in 2006 een van de eerste OS-en die IPv6 ondersteunde. Best kans dat de PS4 inmiddels ook gewoon IPv6 kan.

[Olaf van der Spek]

Maurits van Baerle schreef op dinsdag 12 mei 2020 @ 19:06:
Ik weet niet of dat inmiddels is opgelost. De PS4 draait op een variant van FreeBSD en dat was in 2006 een van de eerste OS-en die IPv6 ondersteunde. Best kans dat de PS4 inmiddels ook gewoon IPv6 kan.

Maar als jouw vrienden geen IPv6 hebben, heb je daar weinig aan als jij een potje host..

[Maurits van Baerle]

Olaf van der Spek schreef op dinsdag 12 mei 2020 @ 19:08:
[...]

Maar als jouw vrienden geen IPv6 hebben, heb je daar weinig aan als jij een potje host..

Ik weet niet of het technische struikelblok de verbinding tussen de host en de server was of tussen twee hosts. Als het dat eerste was dan zou een PS4 die IPv6 ondersteunt natuurlijk wel een verschil maken, of jouw vrienden nou IPv6 hebben of niet.

[valkenier]

Roetzen schreef op dinsdag 12 mei 2020 @ 10:57:

Goede vraag. Ik denk dat je daar pas echt een antwoord op gaat krijgt als de klant een keuze heeft en er een prijskaartje aan hangt. Met een prijskaartje scheidt je het kaf van hen die het willen hebben om de "heb" van het koren van degenen die er echt iets mee doen wat (nog) niet anders kan.

Voor de prijs die providers vragen kunnen ze best Full Dual Stack leveren. Wat een onzin om er voor te pleiten om daar nou weer extra geld voor te vragen. Voorlopig verwacht ik nog wel een native IPv4, en ja wel graag IPv6 erbij. Je wilt een beetje voor de troepen uit volgens mij. Zolang de IPv6 transitie niet verder is doorgedrongen gaat ben ik nog erg gehecht aan een eigen IPv4. En nee, daar wil ik niet nog eens extra voor betalen.

[Roetzen]

valkenier schreef op dinsdag 12 mei 2020 @ 21:32:
[...]
Voor de prijs die providers vragen kunnen ze best Full Dual Stack leveren. Wat een onzin om er voor te pleiten om daar nou weer extra geld voor te vragen. Voorlopig verwacht ik nog wel een native IPv4, en ja wel graag IPv6 erbij. Je wilt een beetje voor de troepen uit volgens mij. Zolang de IPv6 transitie niet verder is doorgedrongen gaat ben ik nog erg gehecht aan een eigen IPv4. En nee, daar wil ik niet nog eens extra voor betalen.

Ik bepleit ook niet dat jij extra zou moeten betalen voor je publiek IPv4 adres. In tegendeel, afgelopen zaterdag schreef ik nog:

Ze zouden bijvoorbeeld DS-Lite of NAT64/DNS64 kunnen gaan en wie een globaal IPv4 adres wil dat via een tunnel aan kunnen bieden. Wie dat laatste niet wil krijgt een korting.

Het vervelende feit doet zich nu eenmaal voor dat de IPv4 adressen op zijn. Er zijn er niet genoeg meer over om iedereen een publiek IPv4 adres te geven. Er is schaarste. Daar gaan alle providers tegen aan lopen of ze lopen er nu al tegen aan. Daar kun je van alles van vinden, maar dat is de vervelende realiteit. Een beproefd mechanisme om met schaarste om te gaan is beprijzing. Met beprijzing kun je vraag en aanbod sturen. Jij wilt je publiek IPv4 adres behouden. OK, dan gaat de korting aan jouw neus voorbij. Maar heb je het echt nodig, of wil je het alleen maar voor de "heb"? Je kunt argumenteren dat Tweakers juist een publiek IPv4 adres zullen willen hebben. Maar je kunt ook argumenteren dat Tweakers de slimme jongens zijn die manieren vinden om het zonder te doen. Een korting voor degenen die afzien van een publiek IPv4 adres lijkt me heel redelijk. Voor deze slimme jongen is een korting van €5/maand voor het afzien van een publiek IPv4 adres wel bespreekbaar.

[ Voor 3% gewijzigd door Roetzen op 13-05-2020 11:02 ]

[Dreamvoid]

Het lastige is dat veel providers wel denken aan beprijzing, maar dan in segementen: "consumenten hebben als groep minder geld over voor een v4 adres dan enterprise verbindingen of hosting klanten, dus zetten we alle consumenten achter CG-NAT en reserveren onze v4 adressen enkel voor zakelijke klanten".

Zo gaat het namelijk letterlijk bij mobiele netwerken. Ook al is een vast, publiek IPv4 adres (evt tegen een meerprijs) technisch prima mogelijk, gaan de providers dat ook aanbieden? Ik zou persoonlijk graag een publiek v4 adres hebben op mijn 4G router, wil daar ook best wat voor betalen, maar niemand biedt de optie aan onder een consumenten abonnement. Om een idee te krijgen wat het kost voor bedrijven, zie hier deze reseller uit Engeland bv: ~150 euro per maand ex BTW voor 50GB data, auw. Nederlandse aanbieders van 4G-met-IPv4-adres zetten hun aanbiedingen enkel online met "prijs op aanvraag", wat waarschijnlijk al genoeg zegt

[ Voor 11% gewijzigd door Dreamvoid op 13-05-2020 17:26 ]

[ANdrode]

Roetzen schreef op woensdag 13 mei 2020 @ 09:55:
[...]
Je kunt argumenteren dat Tweakers juist een publiek IPv4 adres zullen willen hebben. Maar je kunt ook argumenteren dat Tweakers de slimme jongens zijn die manieren vinden om het zonder te doen. Een korting voor degenen die afzien van een publiek IPv4 adres lijkt me heel redelijk. Voor deze slimme jongen is een korting van €5/maand voor het afzien van een publiek IPv4 adres wel bespreekbaar.

offtopic:
Nee Tweakers doen dit niet. Wie heeft er hier een 50 mbit abonnement met goede QoS… Nee men weet dat het kan maar wil voor de heb dual stack hebben.

De grote kostenbesparing heb je echter pas wanneer je een single stack netwerk kan draaien. Dan bespaar je manuren en die zijn duur.

Tot die tijd wil je vooral klachten over 'slecht netwerk, mijn PUBG werkt niet goed' of helpdesk telefoontjes voorkomen. In een rijk west-europees met hoge uurlonen land zal het daarom lang duren tot IPv4 echt te duur is. Je praat over minder dan EUR 20 per IP (~EUR 14 via RIPE maar twee jaar wachttijd). Dit is erg beperkt ten opzichte van de CAPEX die je per klant doet in andere assets die waarde verliezen.

[Roetzen]

Dreamvoid schreef op woensdag 13 mei 2020 @ 16:54:
Het lastige is dat veel providers wel denken aan beprijzing, maar dan in segementen: "consumenten hebben als groep minder geld over voor een v4 adres dan enterprise verbindingen of hosting klanten, dus zetten we alle consumenten achter CG-NAT en reserveren onze v4 adressen enkel voor zakelijke klanten".

Zo gaat het namelijk letterlijk bij mobiele netwerken.

Ik denk dat je in dezen de mobiele en vaste netwerken apart moet bekijken. Zoals je al opmerkte, de mobile consumenten zijn er aan gewend geen publiek IPv4 adres te hebben. Voor de vaste netwerken ligt dat anders.

Ook al is een vast, publiek IPv4 adres (evt tegen een meerprijs) technisch prima mogelijk, gaan de providers dat ook aanbieden? Ik zou persoonlijk graag een publiek v4 adres hebben op mijn 4G router, wil daar ook best wat voor betalen, maar niemand biedt de optie aan onder een consumenten abonnement.

Ze zullen dat alleen gaan aanbieden als er een verdienmodel aan vast zit. Ik vrees dat jij de uitzondering bent en dat de doelgroep te klein is om de investeringen te rechtvaardigen en het rendabel te maken.

Om een idee te krijgen wat het kost voor bedrijven, zie hier deze reseller uit Engeland bv: ~150 euro per maand ex BTW voor 50GB data, auw. Nederlandse aanbieders van 4G-met-IPv4-adres zetten hun aanbiedingen enkel online met "prijs op aanvraag", wat waarschijnlijk al genoeg zegt

Dat zijn prijzen die zelfs voor het MKB reden zijn om nog eens goed achter de oren te krabben. En "prijs op aanvraag" betekent dat er onderhandelingsmarge is.

ANdrode schreef op woensdag 13 mei 2020 @ 21:11:
[...]
Nee Tweakers doen dit niet. Wie heeft er hier een 50 mbit abonnement met goede QoS… Nee men weet dat het kan maar wil voor de heb dual stack hebben.

Je spreekt voor jezelf, of in elk geval niet namens mij.Ik heb een 50/5 abo. Ik gaf al aan dat voor mij een korting op het afzien van een publiek IPv4 adres bespreekbaar is. Ik heb Dual Stack en ik gebruik het publiek IPv4 adres om servers te draaien, dus ik heb het niet voor de heb. Maar toch ben ik bereid een afweging te maken als er een korting is voor het afzien er van.

De grote kostenbesparing heb je echter pas wanneer je een single stack netwerk kan draaien. Dan bespaar je manuren en die zijn duur.

Een reden om zo snel mogelijk naar single stack IPv6 met IPv4Aas toe te werken zou ik dan zeggen...

Tot die tijd wil je vooral klachten over 'slecht netwerk, mijn PUBG werkt niet goed' of helpdesk telefoontjes voorkomen. In een rijk west-europees met hoge uurlonen land zal het daarom lang duren tot IPv4 echt te duur is.

En de helpdesk naar een lagelonenland verplaatsen is lastig vanwege het taalprobleem, Wijn zijn nu eenmaal opgezadeld met een moedertaal die slechts door één procent van de wereldbevolking verstaan wordt en maar door een half procent actief wordt beheerst. Dus inderdaad, klachten afhandelen is duur.

Je praat over minder dan EUR 20 per IP (~EUR 14 via RIPE maar twee jaar wachttijd). Dit is erg beperkt ten opzichte van de CAPEX die je per klant doet in andere assets die waarde verliezen.

Ik denk dat je gelijk hebt dat het nog wel even gaat duren voordat de gevestigde orde de stap durft te nemen. Maar niet omdat het goedkoper is om het uit te stellen. Maar omdat men de aandeelhouders tevreden wil houden en die kijken alleen naar de korte termijn, net als de CEOs die hun bonussen willen incasseren..

De extra kosten voor het onderhouden van een dual stack netwerk lopen elk jaar door. De investeringen om naar een single stack netwerk te gaan hoeven maar één keer gedaan te worden. En de klachtenregen bij de helpdesk droogt ook op als iedereen er aan gewend is. Dus op de lange termijn is het goedkoper om zo snel mogelijk van Dual Stack af te komen.

Maar zo werkt het dus niet bij de gevestigde orde. Voor Freedom zie ik het als een gemiste kans. Die worden niet gehinderd door de wet van de remmende voorsprong.


.

[CAPSLOCK2000]

Roetzen schreef op donderdag 14 mei 2020 @ 11:40:
[...]

Ik denk dat je in dezen de mobiele en vaste netwerken apart moet bekijken. Zoals je al opmerkte, de mobile consumenten zijn er aan gewend geen publiek IPv4 adres te hebben. Voor de vaste netwerken ligt dat anders.

Ik vrees dat dat het nieuwe normaal gaat zijn. De wereld beweegt steeds meer naar draadloze verbindingen en mobiele apparaten. Steeds meer mensen gebruiken hun telefoon als primaire device en hun mobiele aansluiting is hun primaire of zelfs enige aansluiting.
We zien ook al dat gebruikers in het buitengebied naar mobiele oplosingen worden gestuurd.
Verder zie ik regelmatig dat mensen liever 4G gebruiken dan de lokale WIFI die onbetrouwbaar of overbelast is.

Alles bij elkaar verwacht ik dat de mobiele providers een steeds groter deel van de markt gaan verzorgen en dat daarmee de conventies uit die wereld (zoals CGNAT) de standaard worden. Ik vrees dat daar ook bij hoort is dat inkomende verbindingen gewoon helemaal niet mogelijk zijn, en dat je precies één IPv6-adres gaat krijgen, geen hele range.

[jk-5]

Ik had vanmorgen nog een monteur van ziggo zakelijk aan de telefoon over oplevering van een zakelijke verbinding. Ik vroeg hem iets over de ipv6 verbinding, waarna ik het volgende antwoord kreeg: "Ik heb om eerlijk te zijn geen idee, ik heb weinig kennis over ipv6. Het gaat altijd stuk. Hoe vaak ik of collegas wel niet heen en weer moeten rijden voor een ipv6 storing waar we het allemaal weer uitzetten en op ipv4 zetten."

Voor de goede vrede ben ik hier maar niet op ingegaan. Geeft wel aan hoe erg het (niet) speelt binnen de providers.

[Snow_King]

CAPSLOCK2000 schreef op maandag 18 mei 2020 @ 11:37:
[...]
Alles bij elkaar verwacht ik dat de mobiele providers een steeds groter deel van de markt gaan verzorgen en dat daarmee de conventies uit die wereld (zoals CGNAT) de standaard worden. Ik vrees dat daar ook bij hoort is dat inkomende verbindingen gewoon helemaal niet mogelijk zijn, en dat je precies één IPv6-adres gaat krijgen, geen hele range.

Een mobiele telefoon heeft toch ook niet meer dan één adres nodig? Per SIM-kaart één adres.

Wat ik wel gezien heb is dat DHCPv6-PD (Prefix Delegation) wel geïmplementeerd wordt zodat je met tethering of met een 4G (straks 5G) router nog steeds IPv6 adressen kan uitdelen aan de clients daar achter.

Ik ben het wel met je eens dat ik ook denk dat ze alles op ISP niveau al gaan filteren waardoor je inkomende connecties wel bijna kan vergeten.

jk-5 schreef op maandag 18 mei 2020 @ 12:06:
Ik had vanmorgen nog een monteur van ziggo zakelijk aan de telefoon over oplevering van een zakelijke verbinding. Ik vroeg hem iets over de ipv6 verbinding, waarna ik het volgende antwoord kreeg: "Ik heb om eerlijk te zijn geen idee, ik heb weinig kennis over ipv6. Het gaat altijd stuk. Hoe vaak ik of collegas wel niet heen en weer moeten rijden voor een ipv6 storing waar we het allemaal weer uitzetten en op ipv4 zetten."

Voor de goede vrede ben ik hier maar niet op ingegaan. Geeft wel aan hoe erg het (niet) speelt binnen de providers.

Zucht, ja, helaas wel de waarheid. Er is helemaal niets mis met het protocol, maar wel met de meeste beheerders...

[jk-5]

Snow_King schreef op maandag 18 mei 2020 @ 12:18:
[...]
Een mobiele telefoon heeft toch ook niet meer dan één adres nodig? Per SIM-kaart één adres.

Bij 4G/5G kun je over je mobiele verbinding tegelijk meerdere datasessies actief hebben. Per sessie heb je dan een adres in ipv4/ipv4+ipv6/ipv6 mode. In de praktijk wordt dit bijvoorbeeld gebruikt voor een scheiding tussen internetverkeer en VoLTE verkeer. Bij t-mobile in nederland heb je hiervoor 2 interfaces. De VoLTE interface is ipv6-only. De internet interface is ipv4 only. KPN/Simyo doet ook al al het volte verkeer over ipv6 voor zover ik zelf heb gezien.

Edit: dat laat trouwens ook zien dat t-mobile wel al operationele ervaring heeft met ipv6 op het mobiele netwerk. Ik heb al een poging gedaan meer informatie los te krijgen zonder resultaat: https://community.t-mobil...op-mobiel-internet-323390

[ Voor 16% gewijzigd door jk-5 op 18-05-2020 12:37 ]

[Snow_King]

jk-5 schreef op maandag 18 mei 2020 @ 12:24:
[...]


Bij 4G/5G kun je over je mobiele verbinding tegelijk meerdere datasessies actief hebben. Per sessie heb je dan een adres in ipv4/ipv4+ipv6/ipv6 mode. In de praktijk wordt dit bijvoorbeeld gebruikt voor een scheiding tussen internetverkeer en VoLTE verkeer. Bij t-mobile in nederland heb je hiervoor 2 interfaces. De VoLTE interface is ipv6-only. De internet interface is ipv4 only. KPN/Simyo doet ook al al het volte verkeer over ipv6 voor zover ik zelf heb gezien.

Edit: dat laat trouwens ook zien dat t-mobile wel al operationele ervaring heeft met ipv6 op het mobiele netwerk. Ik heb al een poging gedaan meer informatie los te krijgen zonder resultaat: https://community.t-mobil...op-mobiel-internet-323390

Daar heb je helemaal gelijk in! Ik nam VoLTE even niet mee in mijn gedachtengang.

Maar voor de reguliere data verbinding is één v4 danwel v6 adres voldoende.

Maar het klopt dat telefoons nu twee adressen hebben:

- Data
- VoLTE

Bij Vodafone is alles nog IPv4-only op mijn iPhone 8. Twee Cellular data connecties.

[aawe mwan]

Snow_King schreef op maandag 18 mei 2020 @ 12:18:
[...]
Een mobiele telefoon heeft toch ook niet meer dan één adres nodig? Per SIM-kaart één adres.

Dat is misschien nog niet helemaal zeker. ChromeOS/Android draaien apps in een container en willen elke container een eigen IPv6 adres geven. Lukt dat niet (volgens een standaard die Google ondersteunt), dan is je IPv6 adres voor de apps van Google en verder is er voor geen enkele andere app IPv6 connectiviteit.

[Snow_King]

aawe mwan schreef op maandag 18 mei 2020 @ 18:23:
[...]


Dat is misschien nog niet helemaal zeker. ChromeOS/Android draaien apps in een container en willen elke container een eigen IPv6 adres geven. Lukt dat niet (volgens een standaard die Google ondersteunt), dan is je IPv6 adres voor de apps van Google en verder is er voor geen enkele andere app IPv6 connectiviteit.

Volgens mij werkt DHCPv6-PD wel bij de mobiele providers. Dan is het toch opgelost?

[Roetzen]

Nieuwe metingen:

[Dreamvoid]

Snow_King schreef op maandag 18 mei 2020 @ 12:18:
[...]
Een mobiele telefoon heeft toch ook niet meer dan één adres nodig? Per SIM-kaart één adres.

Tethering gooit hier roet in het eten, je zal ze minimaal een /64 moeten geven

Tethering was overigens ook de reden dat Apple alsnog 464XLAT support heeft toegevoegd aan iOS - de apps op de telefoon hebben het weliswaar niet nodig, maar devices die erachter hangen wel.

[Snow_King]

Dreamvoid schreef op dinsdag 19 mei 2020 @ 16:45:
[...]

Tethering gooit hier roet in het eten, je zal ze minimaal een /64 moeten geven

Tethering was overigens ook de reden dat Apple alsnog 464XLAT support heeft toegevoegd aan iOS - de apps op de telefoon hebben het weliswaar niet nodig, maar devices die erachter hangen wel.

Moet je niet de helft van mijn post quoten hé

Daar schrijf ik concreet:

Wat ik wel gezien heb is dat DHCPv6-PD (Prefix Delegation) wel geïmplementeerd wordt zodat je met tethering of met een 4G (straks 5G) router nog steeds IPv6 adressen kan uitdelen aan de clients daar achter.

[Dreamvoid]

Het was ook geen kritiek ofzo

Ik zou er sowieso niet zo bang voor zijn, er is voor de providers ook geen enkele reden om aan 4G routers niet minimaal een /64 te geven, tis niet alsof ze gebrek aan v6 adresruimte hebben, en als je routers een enkele /128 geeft dan gaat alles op het LAN weer over z'n nek dus bellen de klanten de klachtenlijn weer suf.

Als je het hebt over carrier firewalling, dat kan inderdaad nog wel eens een dingetje gaan worden, al hebben de vaste-lijn providers dit ook een tijd geprobeerd en weer losgelaten.

Als je in het buitenland kijkt (waar 'mobile broadband' veel populairder is dan in het goed bekabelde en dichtbevolkte Nederland) is het een beetje een gemengd verhaal, sommige abonnementen hebben een potdichte firewall en CG-NAT, sommigen hebben een publiek IPv4 adres met de poorten helemaal open. Maar met de komst van 5G gaat het waarschijnlijk een alleen maar grotere vlucht nemen, ik kijk er zelf ook naar uit. Met een goede 5G aanbieding gaat de ADSL er bij mij rap uit, ik ben die 0.8 Mbit upload meer dan zat.

[ Voor 31% gewijzigd door Dreamvoid op 19-05-2020 17:25 ]

[jk-5]

Ik zit een beetje in de documentatie te spitten hoe dit geimplementeerd is in 4G/5G netwerken. Waar komt de info weg dat dhcpv6 (wel of niet -pd) gebruikt wordt in 4G/5G? Ik zie RFC7278 voor ipv6 tethering en dat werkt anders. Sowieso wordt geen gebruik gemaakt van dhcp in mobiele netwerken. Mis ik iets?

https://tools.ietf.org/html/rfc7278

[Snow_King]

Dreamvoid schreef op dinsdag 19 mei 2020 @ 17:11:
Het was ook geen kritiek ofzo

Weet ik! Daarom de smileys er ook bij :-)

Dreamvoid schreef op dinsdag 19 mei 2020 @ 17:11:
Ik zou er sowieso niet zo bang voor zijn, er is voor de providers ook geen enkele reden om aan 4G routers niet minimaal een /64 te geven, tis niet alsof ze gebrek aan v6 adresruimte hebben, en als je routers een enkele /128 geeft dan gaat alles op het LAN weer over z'n nek dus bellen de klanten de klachtenlijn weer suf.

Ik hoop op een /128 op WAN en daarna minimaal /56 via PD. Dan heb je alle space op het device.

Dreamvoid schreef op dinsdag 19 mei 2020 @ 17:11:
Als je het hebt over carrier firewalling, dat kan inderdaad nog wel eens een dingetje gaan worden, al hebben de vaste-lijn providers dit ook een tijd geprobeerd en weer losgelaten.

Als je in het buitenland kijkt (waar 'mobile broadband' veel populairder is dan in het goed bekabelde en dichtbevolkte Nederland) is het een beetje een gemengd verhaal, sommige abonnementen hebben een potdichte firewall en CG-NAT, sommigen hebben een publiek IPv4 adres met de poorten helemaal open. Maar met de komst van 5G gaat het waarschijnlijk een alleen maar grotere vlucht nemen, ik kijk er zelf ook naar uit. Met een goede 5G aanbieding gaat de ADSL er bij mij rap uit, ik ben die 0.8 Mbit upload meer dan zat.

Je ziet dat KPN nu bij hun 4G voor thuis al geen CGNAT doet en je gewoon laat forwarden. Ik denk dat het met 4G/5G met IPv6 ook wel goed komt.

[aawe mwan]

Wanneer gaat T-Mobile eigenlijk IPv6 op mobiel aanzetten?

Op dit moment is de term IPv6 nog niet eens te vinden op t-mobile.nl klantenservice mobiel.
IPv4 wel, want daar moet je je verbinding op vastzetten als je de APN configureert.

[ Voor 3% gewijzigd door aawe mwan op 19-05-2020 18:16 ]

[jk-5]

aawe mwan schreef op dinsdag 19 mei 2020 @ 18:14:
Wanneer gaat T-Mobile eigenlijk IPv6 op mobiel aanzetten?

Op dit moment is de term IPv6 nog niet eens te vinden op t-mobile.nl klantenservice mobiel.
IPv4 wel, want daar moet je je verbinding op vastzetten als je de APN configureert.

Ik heb een poging gedaan daar een vraag over te stellen op de forums, alleen lijken ze niet te reageren. Misschien collectief even dat draadje bumpen, misschien gebeurt er dan iets?

https://community.t-mobil...op-mobiel-internet-323390

[easyriider]

Het fZiggo gebied van Ziggo zat begin dit jaar nog op 45% IPv6, maar is inmiddels gestegen naar boven de 50%.



Bron: https://stats.labs.apnic....3915&c=NL&x=0&s=0&p=0&w=7

[Dreamvoid]

Ik vermoed dat het aan de netwerktechnische kant bij T-Mobile (en Vodafone), op het moment alle hens aan dek is voor de 5G uitrol.

Ik denk ook dat 5G uiteindelijk wel een extra impuls is voor IPv6, want een veelvoud meer data op je netwerk betekent ook dito extra kosten voor NAT en logging.

In Frankrijk heeft de overheid nu als harde eis gesteld dat de toekomstige 5G frequentie winnaars ook verplicht per 31 Dec 2020 IPv6 moeten doen, maar dat zie ik in NL niet zo snel gebeuren.

[Roetzen]

easyriider schreef op dinsdag 19 mei 2020 @ 19:06:
Het fZiggo gebied van Ziggo zat begin dit jaar nog op 45% IPv6, maar is inmiddels gestegen naar boven de 50%.

[Afbeelding]

Bron: https://stats.labs.apnic....3915&c=NL&x=0&s=0&p=0&w=7

Die plotselinge sterke stijging vanaf oktober 2019 is wel spectaculair. Wat is er toen gebeurd? Versnelde uitrol van de ConnectBox?

CAPSLOCK2000 schreef op maandag 18 mei 2020 @ 11:37:
[...]

Ik vrees dat dat het nieuwe normaal gaat zijn. De wereld beweegt steeds meer naar draadloze verbindingen en mobiele apparaten. Steeds meer mensen gebruiken hun telefoon als primaire device en hun mobiele aansluiting is hun primaire of zelfs enige aansluiting.
We zien ook al dat gebruikers in het buitengebied naar mobiele oplosingen worden gestuurd.

En die gebruikers zullen dan verlangen dat ze met hun "vaste" mobiele aansluiting hetzelfde kunnen doen als met een echte vaste aansluiting.

Alles bij elkaar verwacht ik dat de mobiele providers een steeds groter deel van de markt gaan verzorgen en dat daarmee de conventies uit die wereld (zoals CGNAT) de standaard worden. Ik vrees dat daar ook bij hoort is dat inkomende verbindingen gewoon helemaal niet mogelijk zijn, en dat je precies één IPv6-adres gaat krijgen, geen hele range.

Ik hoop echt dat die vrees te pessimistisch is.

Dreamvoid schreef op dinsdag 19 mei 2020 @ 19:49:

[..]
In Frankrijk heeft de overheid nu als harde eis gesteld dat de toekomstige 5G frequentie winnaars ook verplicht per 31 Dec 2020 IPv6 moeten doen, maar dat zie ik in NL niet zo snel gebeuren.

Ik denk ook niet dat het hier nodig is. De grote mobiele providers zijn al met IPv6 bezig.

[ Voor 62% gewijzigd door Roetzen op 20-05-2020 14:47 ]

[CAPSLOCK2000]

Roetzen schreef op woensdag 20 mei 2020 @ 12:43:
En die gebruikers zullen dan verlangen dat ze met hun "vaste" mobiele aansluiting hetzelfde kunnen doen als met een echte vaste aansluiting.

Ik denk dat het voor 90% van de gebruikers geen verschil maakt. Die doen nu ook niet meer dan passief data binnen slurpen van Facebook en Youtube via https.
De vraag is of de overgebleven gebruikers genoeg indruk maken om daar iets voor te regelen. Ik ben bang dat de conclusie gaat zijn dat die gebruikers zich maar moeten aanpassen of een zakelijk abonnement nemen.

[Roetzen]

CAPSLOCK2000 schreef op woensdag 20 mei 2020 @ 14:46:
[...]

De vraag is of de overgebleven gebruikers genoeg indruk maken om daar iets voor te regelen. Ik ben bang dat de conclusie gaat zijn dat die gebruikers zich maar moeten aanpassen of een zakelijk abonnement nemen.

In dat geval is het kaasje voor e-fiber en con sorte die glasvezel proberen aan te leggen, met name in de buitengebieden. Dat loopt nu vaak stuk omdat ze niet kunnen opbieden tegen Ziggo en KPN. Maar als 4G/5G het enige alternatief is, krijgen de glasvezelboeren meer kans.

En die glasvezeljongens leggen tegenwoordig vaak "open glasvezel" aan waarbij de klant de keuze heeft uit meerdere providers. En dan zijn er altijd wel een paar die ook IPv6 aanbieden.

[Dreamvoid]

Roetzen schreef op woensdag 20 mei 2020 @ 12:43:
Ik denk ook niet dat het hier nodig is. De grote mobiele providers zijn al met IPv6 bezig.

Vooralsnog alleen KPN (en dat voor een beperkt aantal devices), en ik verwacht niet dat de twee (of drie, na de 5G veiling?) anderen in 2020 IPv6 gaan uitrollen.

Maar we zullen zien. T-Mobile heeft het in elk geval in zowel de VS (acht jaar geleden al) als in Duitsland (vorig jaar) inmiddels uitgerold, dus het is niet alsof de kennis nog in huis moeten halen. Vodafone lijkt overal achter te lopen qua IPv6.

[Roetzen]

Dreamvoid schreef op woensdag 20 mei 2020 @ 15:57:
[...]

Vooralsnog alleen KPN (en dat voor een beperkt aantal devices), en ik verwacht niet dat de twee (of drie, na de 5G veiling?) anderen in 2020 IPv6 gaan uitrollen.

Waarom niet? Het uitrollen van een nieuw netwerk is immers een uitgelezen gelegenheid om het single stack IPv6 op te zetten met IPv4 Aas. Daar was jij toch een bepleiter van?

Maar we zullen zien. T-Mobile heeft het in elk geval in zowel de VS (acht jaar geleden al) als in Duitsland (vorig jaar) inmiddels uitgerold, dus het is niet alsof de kennis nog in huis moeten halen. Vodafone lijkt overal achter te lopen qua IPv6.

Inderdaad, we zullen het zien. KPN is al bezig met IPv6, zei het dan nog op beperkte schaal, maar ik denk als ze eenmaal op stoom komen dat ze dan wel doorpakken. Waarom T-mobile hier achterblijft bij haar zusters in de rest van de wereld snap ik ook niet zo goed. En Vodafone is ook niet geheel zonder ervaring. Vodafone Portugal staat op 56%

https://www.worldipv6launch.org/measurements/

[jk-5]

Roetzen schreef op woensdag 20 mei 2020 @ 17:37:
[...]

Waarom niet? Het uitrollen van een nieuw netwerk is immers - zoals je zelf betoogd heb - een uitgelezen gelegenheid om het single stack IPv6 op te zetten met IPv4 Aas.

[...]

Inderdaad, we zullen het zien. KPN is al bezig met IPv6, zei het dan nog op beperkte schaal, maar ik denk als ze eenmaal op stoom komen dat ze dan wel doorpakken. Waarom T-mobile hier achterblijft bij haar zusters in de rest van de wereld snap ik ook niet zo goed. En Vodafone is ook niet geheel zonder ervaring. Vodafone Portugal staat op 56%

https://www.worldipv6launch.org/measurements/

Alle providers met eigen netwerk zijn er sowieso mee bezig. KPN heeft het al in productie, T-Mobile gebruikt ipv6 al voor VoLTE, en op het nederlandse vodafone netwerk is een ripe atlas probe actief met werkende ipv6: https://atlas.ripe.net/probes/13308/
Dus inderdaad lijken ze allemaal de kans nu wel aan te grijpen om met de vernieuwing van de netwerkcore meteen afscheid te nemen van een grote CGNAT setup en naar een simpelere ipv6 + nat64/dns64 architectuur te verhuizen voor alle telefoons die dit ondersteunen. (Was ondersteuning voor ipv6 sowieso geen verpichting in de LTE specificatie? Voor 5G geldt die sowieso)

[CAPSLOCK2000]

Ik meen dat de standaard wel IPv6 bevat, maar niet de verplicht. De apparatuur kan het, maar je hoeft het niet te gebruiken.

[jk-5]

CAPSLOCK2000 schreef op woensdag 20 mei 2020 @ 18:26:
Ik meen dat de standaard wel IPv6 bevat, maar niet de verplicht. De apparatuur kan het, maar je hoeft het niet te gebruiken.

Ja dat bedoelde ik inderdaad. Je bent verplicht om het te ondersteunen (als telefoonfabrikant), maar als provider niet verplicht het aan te bieden

[Roetzen]

jk-5 schreef op woensdag 20 mei 2020 @ 18:36:

Ja dat bedoelde ik inderdaad. Je bent verplicht om het te ondersteunen (als telefoonfabrikant), maar als provider niet verplicht het aan te bieden

Maar ja, dan ben je - zeker wanneer de apparatuur het ondersteunt - als provider niet slim bezig als je anno 2020 IPv6 laat liggen en weer een IPv4 only netwerk met CGNAT gaat optuigen...

[jk-5]

Roetzen schreef op woensdag 20 mei 2020 @ 19:17:
[...]

Maar ja, dan ben je - zeker wanneer de apparatuur het ondersteunt - als provider niet slim bezig als je anno 2020 IPv6 laat liggen en weer een IPv4 only netwerk met CGNAT gaat optuigen...

Ja daar heb je gelijk, maar de providers in Nederland lijken op basis van mijn vorige post in ieder geval de 'verstandige' keuze te hebben genomen en zijn alledrie bezig met ipv6

[bundit]

Heeft er toevallig iemand ervaring met MLD-snooping?

Ik ben namelijk benieuwd welke kleine switches dit ondersteunen (mag unmanaged zijn).
Na enige tijd zoeken lijken alleen de Netgear GS108Tv3 en de Linksys LGS308 of LGS318 MLD-snooping te ondersteunen.

Weet iemand er toevallig nog meer die ik mee kan nemen in een vergelijking?

Of is het effect van een switch die MLD-snooping te verwaarlozen indien hier maar enkele clients (tussen de 4 en 16) mee verbonden zijn én kan er net zo goed voor een switch zonder MLD-snooping gekozen worden? Het lijkt mij persoonlijk wel wenselijk omdat er met MLD-snooping ook naar een IPv6 only netwerk gemigreerd kan worden waarin multicast goed werkt.

[Dreamvoid]

Dat ik voorstander van IPv6 betekent niet dat ik verwacht dat het snel uitgerold zal worden Ik bedoel, als ik zie dat Vodafone in Duitsland en Engeland nog niks doet, dan heb ik niet het idee dat ze hier in NL ineens vaart gaan maken. De 5G uitrol zal denk ik eerst de masten worden, en relatief kleine schaal uitrol. Zolang er nog maar kleine hoeveelheden data over 5G gaan is de druk op de NAT44 servers ook niet groot.

[Roetzen]

Dat wens en verwachting niet altijd samenvallen, laat staan overeenkomen met de realiteit is een gegeven. En inderdaad, in het begin zal de belasting op de NAT44 servers wel meevallen als men eerst voor IPv4 only met CGNAT gaat. Maar dat blijft natuurlijk niet zo en aangezien men op termijn toch niet onder IPv6 uitkomt, lijkt het me - zoals ik eerder al opmerkte - niet erg slim om bij de uitrol van een nieuw netwerk niet meteen voor IPv6 met IPv4 Aas te gaan.

Dus ik verwacht dat ze wel slim zijn en meteen voor IPv6 gaan. En niet alleen in Nederland. Ik moet er wel bij zeggen dat ik notoir slecht ben in het voorspellen van de toekomst. We gaan het zien...

[ANdrode]

Dreamvoid schreef op woensdag 20 mei 2020 @ 21:01:
Dat ik voorstander van IPv6 betekent niet dat ik verwacht dat het snel uitgerold zal worden Ik bedoel, als ik zie dat Vodafone in Duitsland en Engeland nog niks doet, dan heb ik niet het idee dat ze hier in NL ineens vaart gaan maken. De 5G uitrol zal denk ik eerst de masten worden, en relatief kleine schaal uitrol. Zolang er nog maar kleine hoeveelheden data over 5G gaan is de druk op de NAT44 servers ook niet groot.

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

[Roetzen]

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.

Ik heb geprobeerd die probe te pingen op p13308.probes.atlas.ripe.net. Maar dat gaat niet. "Onbekende host"

Mijn eigen probe is wel IPv6 pingbaar op p2462.probes.atlas.ripe.net

[Snow_King]

Ik heb nu Ziggo met IPv6 met CGNAT, werkt prima voor mij. Heb de Arris ConnectBox en wil eigenlijk heel graag een Unifi Secure Gateway.

IPv6 werkt volgens mij nog steeds niet bij Ziggo in bridge modus, correct?

[jk-5]

Snow_King schreef op dinsdag 2 juni 2020 @ 20:16:
Ik heb nu Ziggo met IPv6 met CGNAT, werkt prima voor mij. Heb de Arris ConnectBox en wil eigenlijk heel graag een Unifi Secure Gateway.

IPv6 werkt volgens mij nog steeds niet bij Ziggo in bridge modus, correct?

Klopt, maar dhcpv6-pd werkt daarvoor prima. Eigenlijk heb je dan weinig reden meer om bridge mode te willen, als je toch al geen eigen ipv4 meer hebt. Ik weet alleen niet of de USG dat ondersteunt. Ik gebruik zelf een EdgeRouter

[Snow_King]

jk-5 schreef op dinsdag 2 juni 2020 @ 20:17:
[...]


Klopt, maar dhcpv6-pd werkt daarvoor prima. Eigenlijk heb je dan weinig reden meer om bridge mode te willen, als je toch al geen eigen ipv4 meer hebt. Ik weet alleen niet of de USG dat ondersteunt. Ik gebruik zelf een EdgeRouter

De DPI en mooie statistieken van de USG. De ConnectBox doet verder prima de routing.

Wifi im hele huis gaat via Unifi AP Pro’s en een Unifi POE switch. Bridge modus zou leuk zijn, meer niet.

[darkrain]

jk-5 schreef op dinsdag 2 juni 2020 @ 20:17:
[...]


Klopt, maar dhcpv6-pd werkt daarvoor prima. Eigenlijk heb je dan weinig reden meer om bridge mode te willen, als je toch al geen eigen ipv4 meer hebt. Ik weet alleen niet of de USG dat ondersteunt. Ik gebruik zelf een EdgeRouter

Dat doet de USG zeker, ik heb dat nu al een flinke tijd zo draaien en dat gaat uitstekend.

[jk-5]

darkrain schreef op woensdag 3 juni 2020 @ 09:31:
[...]

Dat doet de USG zeker, ik heb dat nu al een flinke tijd zo draaien en dat gaat uitstekend.

Oh nice, dan is het misschien voor mij ook de overweging waard als ze met een geupgrade USG komen. Ik heb lang lang geleden toen het USG platform nog veel minder features had gekozen voor edgemax omdat dat toen veel vollediger was. Inmiddels lijkt de ontwikkeling daaraan vrij stil te liggen, amper nieuwe features, bugs die na jaren nog steeds niet zijn opgelost. Ze lijken nu in ieder geval met de UDMs al de shift aan het maken zijn naar een eigen platform, niet meer op basis van Vyatta/EdgeOS.

[Snow_King]

darkrain schreef op woensdag 3 juni 2020 @ 09:31:
[...]

Dat doet de USG zeker, ik heb dat nu al een flinke tijd zo draaien en dat gaat uitstekend.

Je krijgt dan alleen toch NAT achter NAT met IPv4? Hoe werkt dat in de praktijk?

[darkrain]

Snow_King schreef op woensdag 3 juni 2020 @ 09:46:
[...]

Je krijgt dan alleen toch NAT achter NAT met IPv4? Hoe werkt dat in de praktijk?

Je hebt geen publiek IPv4 adres en dus ook geen instellingen voor port forwarding of dergelijke.
Dat is dus geen issue bij mij, ik heb ook geen enkele behoefte voor inbound poorten open

Voor IPv6 heb ik de firewall op de Connect Box uitgezet, dat kan de USG prima oplossen.

[Roetzen]

Over IPv6 only...

http://www.iljitsch.com/article.php?id=755

[Roetzen]

A.s. maandag 8 juni is er een RIPE on;line education event. Het gaat o.m over "IPv6 only" Ijitsch van Beijnum is één van de deelnemers:

http://www.iljitsch.com/article.php?id=755

[Freeaqingme]

Roetzen schreef op donderdag 4 juni 2020 @ 11:24:
A.s. maandag 8 juni is er een RIPE on;line education event. Het gaat o.m over "IPv6 only" Ijitsch van Beijnum is één van de deelnemers:

http://www.iljitsch.com/article.php?id=755

Jammer alleen dat je je moet registreren via EventBrite, alwaar dit event uitverkocht is

[Vorkie]

Freeaqingme schreef op donderdag 4 juni 2020 @ 11:45:
[...]


Jammer alleen dat je je moet registreren via EventBrite, alwaar dit event uitverkocht is

Misschien maar een /128 subnet

[Snow_King]

Freeaqingme schreef op donderdag 4 juni 2020 @ 11:45:
[...]


Jammer alleen dat je je moet registreren via EventBrite, alwaar dit event uitverkocht is

code:

me@my-laptop:~$ dig +short AAAA eventbrite.com
me@my-laptop:~$

Wel lastig registreren voor zo'n v6-only evenement

[Roetzen]

Freeaqingme schreef op donderdag 4 juni 2020 @ 11:45:
[...]


Jammer alleen dat je je moet registreren via EventBrite, alwaar dit event uitverkocht is

Inderdaad jammer. Maar misschien is aanmelden alleen nodig voor wie actief wil deelnemen aan de discussie en is de live stream wel te bekijken?

[Freeaqingme]

Roetzen schreef op donderdag 4 juni 2020 @ 22:09:
[...]

Inderdaad jammer. Maar misschien is aanmelden alleen nodig voor wie actief wil deelnemen aan de discussie en is de live stream wel te bekijken?

Wie weet. Ik heb ze vanmiddag een mailtje gestuurd met de vraag of de cap er af kan. Nog geen reactie gehad.

[ANdrode]

Freeaqingme schreef op donderdag 4 juni 2020 @ 22:11:
[...]

Wie weet. Ik heb ze vanmiddag een mailtje gestuurd met de vraag of de cap er af kan. Nog geen reactie gehad.

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

[Freeaqingme]

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


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

En ondertussen zit ik maar te wachten op reactie van RIPE. Thanks