Het grote IPv6 topic

[Dreamvoid]

Misschien begrijp ik je probleemstelling verkeerd, maar als er een firewall draait die inkomende verbindingen dropt zijn de adressen daarachter logischerwijs niet bereikbaar van buiten.

[videopionier]

Nee @Dreamvoid, dat is ook niet de bedoeling, maar het moet voor de clients achter de Draytek uiteraard wel mogelijk zijn om zelf ipv6 sessies op te zetten.
Ok. ik begrijp de verwarring. Ik ben wellicht niet helemaal duidelijk geweest. De situatie is als volgt.
Ik heb op de 1e locatie 2 consumenten BVVDSL modems, die niet in bridged mode kunen, waaronder een V10. Deze zijn verbonden met een dual WAN Draytek 2925 router. Daarachter diverse kassa's, PIN apparaten, (muziek) computers en accesspoints voor de smartphones van staf, spelers en supporters. Dat betekent dus dubbel NAT, en dus ook zwaar werk voor de CPU van de router, vooral op de speeldagen.
Het is me in deze situatie gelukt om dubbel NAT te omzeilen door gebruik te maken van ipv6 (dual stack). Dat werkt omdat het V10 modem (het routergedeelte althans), in samenspraak met de Draytek, global ipv6 adressen (WAN en LAN) en LAN subnetprefixen uitdeelt aan de Draytek. Zodra de 4 (virtuele) LANs een global adress hebben, deelt de Draytek dan de global ipv6 adressen (in het door de V10 toegewezen subnet) uit aan de clients aan de LAN zijde. Tevens wordt de routing verzorgd, wat weer terug te zien is in de ipv6 routing table van de Draytek. Ik heb begrepen dat dit proces wordt verzorgd door het Router Advertisement en Prefix Delegation protocol. De clients kunnen nu zelf hun sessies opzetten over ipv4 en ipv6 en in de praktijk gaat nu zo'n 60% van het dataverkeer over ipv6.
So far so good. Maar ... als ik in een vergelijkbare situatie, met dezelfde instellingen in de router, dit probeer met een V10A en een iets nieuwere Draytek (2926 ipv 2925) dan werkt dit mechanisme niet.

Ik heb aan de hand van het bovenstaande 2 conclusies getrokken.
1) Het RA en PD protocol gaan buiten de firewal om. Anders zou Draytek daar wel voor waarschuwen in hun ipv6 HowTo. https://www.draytek.com/support/knowledge-base/5969. Deze tutorial gaat er echter vanuit dat de Draytek zelf direct aan het internet hangt, met een bridged modem.
2) Router Advertisement en Prefix Delegation naar onderliggen routers (router achter router) is kennelijk nog niet geinplementeerd in de V10A. Elke client achter de V10A krijgt wel (meerdere) /64 global ipv6 adressen met subnetID 0. De Draytek krijgt een GUA adh van het MAC adress van de WAN poort.

Natuurlijk kan ik wachten tot dit wel werkt. Maar wellicht kan ik dat zelf ook oplossen?
Dit heb ik al geprobeerd: zelf global adressen toewijzen aan de LAN poorten (adhv het MAC adres) in het zelfde subnet als de WAN zijde van de Draytek. De router deelt dan keurig ipv6 adressen uit met de juiste prefix en in hetzelfde subnet als alle andere clients die direct aan de V10A hangen.
De routing lijkt ook in orde als ik naar de routing table kijk, maar de clients aan de Draytek kunnen geen ipv6 sessie opzetten en vallen na enige seconden terug op ipv4.

[Maurits van Baerle]

@videopionier Dit is misschien een domme vraag maar heb je wel eens overwogen de modems te vervangen? Kun je die ExperiaBox niet vervangen door iets wat beter werkt met IPv6?

Ik heb zelf bijvoorbeeld (maar niet bij KPN) mijn ISP modem vervangen door een Draytek V130 en die stuurt geheel transparant het rauwe PPPoE signaal door naar de router die er achter staat. Die router zet vervolgens zelf de PPPoE verbinding op zodat de router externe IPv4 en IPv6 IP’s op de WAN interface heeft. Geen extra firewall of NAT er tussen en veel overzichtelijker.

[videopionier]

Neen dat is geen domme vraag @Maurits van Baerle Dank voor je advies.
Ja dat heb ik zeker overwogen, echter dat is in het geval van de vereniging niet praktisch. De modems (de verbindingen eigenlijk) hebben regelmatig support nodig van de KPN/XS4all monteurs vanwege het wegvallen van lijnen door bv lijnkaping en storing (van ADSL modems, overspraak!). Ook het migreren naar VVDSL was een drama.
Zodra een modem wegvalt signaleer ik dat naar de mensen daar en die verzorgen de ontvangst en begeleiding van de monteurs. Die moeten dan weer zorgen voor een goedwerkende verbinding en alles achter het modem is mijn pakkie an. Werkt eigenlijk al 4 jaar probleemloos. En vergeet ook niet de STBoxen van de TVs, die zijn uiteraard rechtstreeks aangesloten op het modem van KPN. Ook gedaan ivm de support.
Ik moet wel zeggen dat na de migratie naar (B)VVDSL en het vervangen van de Fritzbox door XS4all de zaak zeer robuust is gebleken. Vooral de KPN blinkt uit, afgezien van een periode in de zomer waar ik de ipv6 support op de router moest uitzetten door ipv6 netwerkproblemen bij KPN. De FritzBox verliest random (om de 2 a 3 weken) de verbinding om die vervolgens weer na enige minuten te herstellen. De FB is backup en voor de diverse VOIP telefoonlijnen (via DECT), dus is wel nuttig. En er is voldoende bandbreedte: 2 x 220 Mbit down en 2 x 60 Mbit up, wellicht nodig voor de toekomst?
Ook de V10A kan ik niet vervangen, die is van de buren en is backup voor mijn Ziggo verbinding.

[ Voor 0% gewijzigd door videopionier op 25-12-2019 13:42 . Reden: typos ]

[kw4h]

Dreamvoid schreef op donderdag 19 december 2019 @ 15:16:
Ik had begrepen dat die KPN boxes een prefix krijgen via DHCPv6-PD richting KPN, maar dat vervolgens op het LAN alle endpoints hun adres via SLAAC krijgen (en uiteraard hun DNS via DHCPv6) - maar klopt dat niet en krijgen de clients hun adres via DHCPv6?

Ik heb net een tcpdump laten luisteren naar icmpv6 RA berichten, en de advertisements van de router hebben de 'other' en 'stateful' flags aan staan. Voor zover ik heb kunnen lezen geeft de 'stateful' flag aan dat er via DHCPv6 adressen worden uitgedeeld, en er dus geen SLAAC actief is.

Nog een fun fact: De router is niet het enige apparaat dat Router Advertisements uitgeeft. Mijn Nest thermostaat (pre-google) doet dat ook. Ik heb mijn Windows laptop er eerder vandaag al op betrapt aardig wat adressen te hebben. 1 link-local, 3 voor router netwerk (1 normaal, 2 random), en ook 3 voor het 'Nest' netwerk.

[Dreamvoid]

Ah, creatieve manier om info te verzamelen voor Google over LAN topografie...heeft zo’n Nest een eigen (getunnelde) VPN verbinding en IPv6 prefix naar Google, waardoor je devices dus ongemerkt deel zijn van een tweede LAN met de Nest als gateway naar Google? Of krijgen ze dezelfde KPN prefix?

Maar DHCP adresuitgifte betekent dus dat je ergens in de KPN routerinterface ook kan specificeren welk adres naar welk MAC adres gaat?

[ Voor 38% gewijzigd door Dreamvoid op 27-12-2019 22:42 ]

[kw4h]

Dreamvoid schreef op vrijdag 27 december 2019 @ 22:38:
Maar DHCP adresuitgifte betekent dus dat je ergens in de KPN routerinterface ook kan specificeren welk adres naar welk MAC adres gaat?

Helaas alleen voor ipv4, ook als ipv6 aan staat.



Inmiddels denk ik nu dat IP adres toewijzing toch wel via SLAAC gaat. Mijn Linux apparaten (android telefoon, en Debian server) hebben ip-adressen met 'FF:FE' erin, en de 7e bit van het adresgedeelte staat op 1 (https://en.wikipedia.org/wiki/IPv6_address#Modified_EUI-64). Windows laptop werkt met random identifiers, waardoor ik dit eerder niet had gezien.

Verder zien de ipv6 instellingen er zo uit: https://imgur.com/DufqkmJ.

Ik ga ipv6 nu nog even uitzetten, want qua configuratie is het op dit moment erg karig. Het lijkt er nu op alsof ipv6 als losse module naast de rest van de router draait, als een soort van 'afterthought'. Als de integratie wat beter is geworden zal ik het weer eens proberen.

[Dreamvoid]

kw4h schreef op maandag 30 december 2019 @ 10:53:
Ik ga ipv6 nu nog even uitzetten, want qua configuratie is het op dit moment erg karig. Het lijkt er nu op alsof ipv6 als losse module naast de rest van de router draait, als een soort van 'afterthought'. Als de integratie wat beter is geworden zal ik het weer eens proberen.

Het is niet zozeer de netwerkcode, alswel de management UI, ik verbaas me er altijd over hoe slecht dat bij de meeste routers is gedaan. Het zou zo logisch zijn om ipv4 en ipv6 instellingen zij-aan-zij in twee kolommen te tonen, maar vrijwel altijd moet je dezelfde functionaliteit in compleet verschillende menu’s vinden.

[Snow_King]

Ik had nog een leuke!

Iemand bleef op zijn kantoor (Met HE tunnel) maar IPv6 problemen hebben, connecties vielen weg en het werkte bagger: IPv6 is kl*te!!

Zijn HE tunnel werd getermineerd op een Juniper router welke vrolijk RA's stond uit te sturen met een MTU van 1500 terwijl de tunnel 1280 aan kan.

Even geholpen door in de Juniper configuratie aan te passen dat de RA's die de router uit stuurt een MTU van 1280 hebben en probleem opgelost!

Alle clients leerden nu dan de MTU 1280 was en niemand heeft nog problemen met IPv6 op kantoor.

Het is nu hopen dat hun ISP (Vodafone glasvezel) een beetje snel native IPv6 kan leveren op kantoor.

[Roetzen]

Nieuwe metingen:




Liberty Global blijft gestaag klimmen. KPN vult het dal van eind verleden jaar weer op.weer op...

Volgens APNIC doet Nederland als geheel het niet zo heel slecht meer:

https://stats.labs.apnic.net/ipv6/NL

ASN	AS Name	IPv6 Capable	IPv6 Preferred	Samples
AS1136	KPN This macro reflects our filtering-policy on	29.32%	29.22%	10,190
AS33915	TNF-AS	45.37%	45.02%	6,963
AS6830	LGI-UPC formerly known as UPC Broadband Holding B.V.	36.15%	35.83%	5,040

[ANdrode]

Roetzen schreef op dinsdag 18 februari 2020 @ 21:26:
Liberty Global blijft gestaag klimmen. KPN vult het dal van eind verleden jaar weer op.weer op...

Volgens APNIC doet Nederland als geheel het niet zo heel slecht meer:

https://stats.labs.apnic.net/ipv6/NL

ASN	AS Name	IPv6 Capable	IPv6 Preferred	Samples
AS1136	KPN This macro reflects our filtering-policy on	29.32%	29.22%	10,190
AS33915	TNF-AS	45.37%	45.02%	6,963
AS6830	LGI-UPC formerly known as UPC Broadband Holding B.V.	36.15%	35.83%	5,040

Wat ik vandaag zag: De RIPE atlas probe die iemand noemde als voorbeeld van een probe op een 4G verbinding heeft dual stack.
_{Een iPhone hier op Vodafone heeft het juist weer niet.}

Maar dat zou het hoge getal van AS33915 verklaren.

offtopic:
Even onder de aanname dat AS33915 echt voor mobiele klanten is.

[jk-5]

ANdrode schreef op dinsdag 18 februari 2020 @ 22:33:
[...]


Wat ik vandaag zag: De RIPE atlas probe die iemand noemde als voorbeeld van een probe op een 4G verbinding heeft dual stack.
_{Een iPhone hier op Vodafone heeft het juist weer niet.}

Ook niet met die APN die daar genoemd wordt?

[ANdrode]

jk-5 schreef op dinsdag 18 februari 2020 @ 22:51:
[...]


Ook niet met die APN die daar genoemd wordt?

Scherp! Niet getest.

[St00mwals]

Heeft er hier al iemand ervaring of is er iemand die meer weet over IPv6 op het mobiele netwerk van KPN?
Op het KPN-forum hierover wordt niet heel erg veel info gedeeld.

[jk-5]

St00mwals schreef op woensdag 19 februari 2020 @ 08:29:
Heeft er hier al iemand ervaring of is er iemand die meer weet over IPv6 op het mobiele netwerk van KPN?
Op het KPN-forum hierover wordt niet heel erg veel info gedeeld.

In het KPN mobiel forum staan wel een aantal posts hierover:

ikbenjoeri in "[KPN Mobiel] Ervaringen & Discussie - Deel 2"
ikbenjoeri in "[KPN Mobiel] Ervaringen & Discussie - Deel 2"
ikbenjoeri in "[KPN Mobiel] Ervaringen & Discussie - Deel 2"
ikbenjoeri in "[KPN Mobiel] Ervaringen & Discussie - Deel 2"
ikbenjoeri in "[KPN Mobiel] Ervaringen & Discussie - Deel 2"

[stormfly]

https://blogs.akamai.com/...vels-of-ipv6-traffic.html

[Nakebod]

Even een CGNAT vraagje.
Op het werk merken wij dat er steeds meer mensen met Ziggo en IPv6 zijn, die achter een CGNAT zitten.

Op het werk hebben wij momenteel alleen IPv4. IPv6 staat wel op mijn roadmap, hebben al een /48 maar nog niet geïmplementeerd.
Laatste keer dat ik er even mee aan het spelen was ging het niet helemaal goed. Of KPN routeert het subnet niet goed, of onze firewall snapt de KPN implementatie niet helemaal en lijkt alleen de eerste /64 uit de /48 te pakken. Maar dat is een ander probleem.

Waarom merken wij dat deze mensen IPv6 hebben?
Mensen met Ziggo CGNAT kunnen niet naar onze Citrix omgeving verbinden. Ze loggen in op de webinterface, verbinding start, maar start niet door / krijgt uiteindelijk een timeout.

Naar mijn idee gebeurt er het volgende:
IPv6 gebruiker > CGNAT > IPv4 naar citrix > Start sessie > Stuur data terug naar CGNAT IPv4 adres > Doei.

Klopt mijn gedachte dat dit door CGNAT komt?
En kunnen wij dit voorkomen, behalve zelf IPv6 implemteren?

Zojuist ook een melding dat SfB gesprekken niet lukken, en ik gok dezelfde oorzaak.
Zelf heb ik XS4ALL en gewoon correcte IPv6 implementatie en ervaar geen enkel probleem.

[Snow_King]

Nakebod schreef op dinsdag 17 maart 2020 @ 11:42:
Even een CGNAT vraagje.
Op het werk merken wij dat er steeds meer mensen met Ziggo en IPv6 zijn, die achter een CGNAT zitten.

Op het werk hebben wij momenteel alleen IPv4. IPv6 staat wel op mijn roadmap, hebben al een /48 maar nog niet geïmplementeerd.
Laatste keer dat ik er even mee aan het spelen was ging het niet helemaal goed. Of KPN routeert het subnet niet goed, of onze firewall snapt de KPN implementatie niet helemaal en lijkt alleen de eerste /64 uit de /48 te pakken. Maar dat is een ander probleem.

Sowieso IPv6 implementeren!

Maar het klopt dat je uit de /48 de eerste /64 pakt. Voor een VLAN is het normaal een /64 te pakken. Hierna heb je nog ~64k subnets over om te gebruiken voor andere VLAN's.

Welke router heb je op kantoor waar je Citrix systeem achter zit?

[Paul]

Nakebod schreef op dinsdag 17 maart 2020 @ 11:42:
Naar mijn idee gebeurt er het volgende:
IPv6 gebruiker > CGNAT > IPv4 naar citrix > Start sessie > Stuur data terug naar CGNAT IPv4 adres > Doei.

Nope Je gebruiker start de sessie, en over die sessie stuurt de ADC / Gateway ook alle retourverkeer.

Weet je zeker dat je Receiver (of hoe heet dat ding tegenwoordig) vindt dat je gebruiker extern zit? Mogelijk resolved er iets naar een AAAA-adres en probeert de verbinding je Gateway te omzeilen?

[bartvb]

Krijg net mail van Freedom Internet, daar krijgt straks iedereen een vast IPv4 adres en dual-stack. Netjes :j

[Roetzen]

Nakebod schreef op dinsdag 17 maart 2020 @ 11:42:
Even een CGNAT vraagje.
Op het werk merken wij dat er steeds meer mensen met Ziggo en IPv6 zijn, die achter een CGNAT zitten.

Dat heet DS-Lite. Tja, de IPv4 adressen zijn op en Ziggo is kennelijk door zijn voorraad heen en gaat klanten op DS-Lite zetten. Dat zat er al jaren aan te komen...

Op het werk hebben wij momenteel alleen IPv4. IPv6 staat wel op mijn roadmap,

We roepen hier al jaren dat bedrijven IPv6 moeten implementeren en niet moeten wachten tot het niet anders meer kan, want dan wordt het alleen maar moeilijker en duurder...

hebben al een /48 maar nog niet geïmplementeerd.
Laatste keer dat ik er even mee aan het spelen was ging het niet helemaal goed.

Dat is te verwachten. Veel dingen zijn met IPv6 hetzelfde, maar ook zijn veel dingen anders. Je moet weer opnieuw door wat de Engelstaligen de "learning curve" noemen. En dat kost tijd.

Of KPN routeert het subnet niet goed, of onze firewall snapt de KPN implementatie niet helemaal en lijkt alleen de eerste /64 uit de /48 te pakken. Maar dat is een ander probleem.

De eerste /64 uit de /48 pakken is normaal. Je kunt meer gebruiken dan de ene .64, maar dat is voor gevorderen..

Waarom merken wij dat deze mensen IPv6 hebben?
Mensen met Ziggo CGNAT kunnen niet naar onze Citrix omgeving verbinden. Ze loggen in op de webinterface, verbinding start, maar start niet door / krijgt uiteindelijk een timeout.

Dat riekt naar een klassiek kinderziekte probleem met IPv6. Je klant heeft IPv6 en de server die hij probeert te bereiken, lijkt het ook te hebben. Dus wordt geprobeerd een IPv6 verbinding op te bouwen. Maar de server heeft geen IPv6 of heeft het niet goed geimplementeerd, of de est van het netwerk heeft het niet.Een klassieke beginnersfout. Degenen die wel vijf jaar geleden met IPv6 zijn begonnen hebben dit soort aanloopproblemen achter de rug...

Naar mijn idee gebeurt er het volgende:
IPv6 gebruiker > CGNAT > IPv4 naar citrix > Start sessie > Stuur data terug naar CGNAT IPv4 adres > Doei.

Klopt mijn gedachte dat dit door CGNAT komt?

Naar mijn inschatting niet.

En kunnen wij dit voorkomen, behalve zelf IPv6 implemteren?

Je kunt een hoop problemen die op je af gaan komen voorkomen door nu zo snel mogelijk IPv6 te implementeren.

Maar kijk eerst eens of die server een IPv6 adres presenteer aan de buitenwereld..

[Nakebod]

Snow_King schreef op dinsdag 17 maart 2020 @ 11:44:
[...]

Sowieso IPv6 implementeren!

Maar het klopt dat je uit de /48 de eerste /64 pakt. Voor een VLAN is het normaal een /64 te pakken. Hierna heb je nog ~64k subnets over om te gebruiken voor andere VLAN's.

Welke router heb je op kantoor waar je Citrix systeem achter zit?

Implementatie komt eraan, liever gister dan vandaag zelfs. Alleen nu met 90% thuiswerkers ga ik even weinig met de internetverbinding/firewall spelen

Router is een Cisco ASR1001 die KPN in beheer heeft.
Verder hebben wij een Sophos UTM firewall, en voor spielerij heb ik ook zo een goedkoop ding thuis
Daardoor weet ik an sich, theoretisch hoe ik IPv6 daarop moet configureren.
Dat je de eerste /64 pakt uit de /48 klopt ook, en dat gedeelte ging zover ik weet ook goed. Vanaf de WAN interface kon ik IPv6 adressen pingen, en vanaf buitenaf kon ik het WAN adres pingen.

Neem als voorbeeld mijn thuisverbinding:


WAN heeft netjes een IP (In dit geval handmatig, kan ook via DHCP), krijgt een /48 subnet en een /48 delegated prefix. Mijn LAN, Domotica VLAN en Guest VLAN hebben een eigen /64. Werkend etc. Ik blij.

Ik ben even vergeten screenshots te nemen tijdens de test paar weken terug, dus het is even uit mijn hoofd.
Schakel ik IPv6 in op het werk, krijgt de WAN geen delegated prefix te zien. Ik twijfel even of het subnet wel een /48 liet zien, of alleen een /64.

Globaal genomen, heb ik op het werk dezelfde dingen geconfigureerd als op mijn firewall thuis, met het verschil dat thuis iedere /64 werkend te krijgen is, en op het werk alleen de 1e /64.

Paul schreef op dinsdag 17 maart 2020 @ 12:08:
[...]
Nope Je gebruiker start de sessie, en over die sessie stuurt de ADC / Gateway ook alle retourverkeer.

Weet je zeker dat je Receiver (of hoe heet dat ding tegenwoordig) vindt dat je gebruiker extern zit? Mogelijk resolved er iets naar een AAAA-adres en probeert de verbinding je Gateway te omzeilen?

Ding heet tegenwoordig Workspace
Er zijn geen AAAA records aangemaakt, niet extern en ook niet intern.

@Roetzen
CGNAT en DS-Lite is toch hetzelfde?
De beschrijving van het IPv4 adres volgens RIPE is iig:
descr: Ziggo LGi internal CGNAT for IPv4-IPv6 AFTR

De eerste /64 uit de /48 pakken is normaal. Je kunt meer gebruiken dan de ene .64, maar dat is voor gevorderen..

Dat principe snap ik gelukkig nog Gelukkig niet helemaal onbekend met IPv6

Dat riekt naar een klassiek kinderziekte probleem met IPv6. Je klant heeft IPv6 en de server die hij probeert te bereiken, lijkt het ook te hebben. Dus wordt geprobeerd een IPv6 verbinding op te bouwen. Maar de server heeft geen IPv6 of heeft het niet goed geimplementeerd, of de est van het netwerk heeft het niet.Een klassieke beginnersfout. Degenen die wel vijf jaar geleden met IPv6 zijn begonnen hebben dit soort aanloopproblemen achter de rug...

De klant, dat ben ik
En ik snap je punt dat er vaak slechte IPv6 implementaties zijn, vaak genoeg prive al tegengekomen.
Maar dat is hier niet het geval gezien er nog geen implementatie is aan onze kant / op de firewall. _{Ok, dat is an sich wel een slechte implementatie te noemen, maar toch}

Maar kijk eerst eens of die server een IPv6 adres presenteer aan de buitenwereld..

In ieder geval geen interne of externe AAAA DNS records aanwezig.
De netscaler servers hebben geen eigen IPv6 adres, maar wel een fe80 LL-adres. Net zoals de Citrix VDA's, maar die zitten in een ander VLAN. Binnen hetzelfde VLAN uiteraard wel pingbaar op LL, maar niet buiten hun VLAN. Wat correct is naar mijn idee.

Maar als er al iets van IPv6 ergens gepubliceerd zou zijn, dan zou ik verwachten dat ik met XS4ALL ook problemen zou hebben.

[jk-5]

Nakebod schreef op dinsdag 17 maart 2020 @ 14:23:
[...]

CGNAT en DS-Lite is toch hetzelfde?
De beschrijving van het IPv4 adres volgens RIPE is iig:
descr: Ziggo LGi internal CGNAT for IPv4-IPv6 AFTR

[...]

Niet helemaal. DS-Lite is een manier om ipv4 verkeer over ipv6 te tunnelen, waarbij op de AFTR (Address family translation router) CGNAT wordt toegepast om adressen te besparen. CGNAT is dus gewoon nat, maar dan op grote schaal bij providers

[Roetzen]

Nakebod schreef op dinsdag 17 maart 2020 @ 14:23:
[...]

Implementatie komt eraan, liever gister dan vandaag zelfs. Alleen nu met 90% thuiswerkers ga ik even weinig met de internetverbinding/firewall spelen

Een stortbui is natuurlijk niet het beste moment om het dak te repareren. Het dak repareer je het best als de zon schijnt. Dit illustreert maar weer eens waarom w al jaren tegen bedrijven roepen dat ze niet met IPv6 moeten wachten tot het echt gaat nijpen.

.
@Roetzen
CGNAT en DS-Lite is toch hetzelfde?

Nee, DS-Lite maakt gebruk van CGNAT, maar CGNAT wordt ook zonder DS-Lite gebruikt. Bijvoorbeeld op de meeste mobiele netywerken krijg je tegenwoordig een IPv4 adres in de private range, maar zonder IPv6 er bij.

Maar als er al iets van IPv6 ergens gepubliceerd zou zijn, dan zou ik verwachten dat ik met XS4ALL ook problemen zou hebben.

Inderdaad. En bij Xs4All heb je volledig Dual Stack, dus geen CGNAT en dus wijst het toch in de richting van een CGNAT gerelateerd probleem.

Maar wact even... DS-Lite is niet zo maar CGNAT, het is ook IPv4 tunnelen over IPv6. Nu heb ik daar geen ervaring mee, maar wel met het omgekeerde: IPv6 tunnelen over IPv4. Ik heb jarenlang IPv6 gedaan via een 6in4 tunnel.

Een tunnel heeft wat overhead. Het gevolg is dat de MTU wat lager is dan bij een recht toe recht aan verbinding, Zo is het althans met IPv6 over IPv4. Verlagen van de IPv6 MTU loste wel eens problemen op.

Ik zou me kunnen voorstellen dat het met IPv4 tunnelen over IPv4 ook zo is. Probeer eens wat te spelen met de IPv4 MTU...

[Snow_King]

Nakebod schreef op dinsdag 17 maart 2020 @ 14:23:
[...]

Implementatie komt eraan, liever gister dan vandaag zelfs. Alleen nu met 90% thuiswerkers ga ik even weinig met de internetverbinding/firewall spelen

Router is een Cisco ASR1001 die KPN in beheer heeft.
Verder hebben wij een Sophos UTM firewall, en voor spielerij heb ik ook zo een goedkoop ding thuis
Daardoor weet ik an sich, theoretisch hoe ik IPv6 daarop moet configureren.
Dat je de eerste /64 pakt uit de /48 klopt ook, en dat gedeelte ging zover ik weet ook goed. Vanaf de WAN interface kon ik IPv6 adressen pingen, en vanaf buitenaf kon ik het WAN adres pingen.

Neem als voorbeeld mijn thuisverbinding:
[Afbeelding]

WAN heeft netjes een IP (In dit geval handmatig, kan ook via DHCP), krijgt een /48 subnet en een /48 delegated prefix. Mijn LAN, Domotica VLAN en Guest VLAN hebben een eigen /64. Werkend etc. Ik blij.

Ik ben even vergeten screenshots te nemen tijdens de test paar weken terug, dus het is even uit mijn hoofd.
Schakel ik IPv6 in op het werk, krijgt de WAN geen delegated prefix te zien. Ik twijfel even of het subnet wel een /48 liet zien, of alleen een /64.

Globaal genomen, heb ik op het werk dezelfde dingen geconfigureerd als op mijn firewall thuis, met het verschil dat thuis iedere /64 werkend te krijgen is, en op het werk alleen de 1e /64.

Als je in je LAN al IPv6 hebt, dan kan je toch de Citrix server in zijn LAN ook een Ipv6 adres geven en dan werkt het?

[Roetzen]

Nieuwe metingen:

[ANdrode]

Iets meer IPv6 gebruik de afgelopen week, waarschijnlijk door thuiswerken: The Register: Freed from the office, home workers roam sunlit uplands of IPv6... 2 metres apart

[Roetzen]

Opmerkelijk. Bij de thuisgebruiker is meer IPv6 in gebruik dan bij de bedrijven...

[Freeaqingme]

Roetzen schreef op dinsdag 24 maart 2020 @ 14:15:
Opmerkelijk. Bij de thuisgebruiker is meer IPv6 in gebruik dan bij de bedrijven...

Is dat heel gek? Bij bedrijven heb je vaak netwerken die door 3e partijen gemanaged worden. Die vinden IPv6 maar eng. En voorzover het niet eng is "kost het extra tijd" om een extra stack te maintainen en te troubleshooten.

Een KPN en een Ziggo daarentegen werken met allemaal standaardapparatuur, en hoeven slechts eenmalig een werkende config te pushen (waarom duurt die uitrol dan eigenlijk zo lang?...). Daarnaast heb je een hoop consumentendiensten zoals Facebook en Youtube die allemaal via IPv6 benaderbaar zijn, waar dat voor veel B2B-diensten niet geldt.

Daarom ben ik niet erg verrast dat IPv6 nu in een keer nog een paar tandjes harder loopt.

[CAPSLOCK2000]

Roetzen schreef op dinsdag 24 maart 2020 @ 14:15:
Opmerkelijk. Bij de thuisgebruiker is meer IPv6 in gebruik dan bij de bedrijven...

Als je de IPv6-grafiekjes een beetje volgt is dit geen nieuws. IPv6-verkeer correleert direct met wanneer mensen thuis zijn. In de weekends en vakanties gaat het om hoog, door de week omlaag.

Een beetje pijnlijk is het dat het vooral lijkt te berusten op onwetendheid en onwil.
Consumenten weten van niks en vertrouwen blind op wat hun ISP levert, daar zit eigenlijk geen eigen keuze in.
Bedrijven (of hun techneuten) hebben er wel van gehoord maar reageren krampachtig met "vooral niks veranderen, het werkt net". Dat we steeds meer outsourcen, inclusief netwerkbeheer, maakt het alleen maar erger doordat alles direct moet worden afgerekend en er dus nog meer naar de korte termijn wordt gekeken

Freeaqingme schreef op dinsdag 24 maart 2020 @ 16:18:
[...]
Een KPN en een Ziggo daarentegen werken met allemaal standaardapparatuur, en hoeven slechts eenmalig een werkende config te pushen (waarom duurt die uitrol dan eigenlijk zo lang?...).

Zolang de reuzen wel IPv4-adressen hebben en nieuwe concurrenten niet kan ik wel begrijpen dat ze weinig haast maken.

Daarnaast heb je een hoop consumentendiensten zoals Facebook en Youtube die allemaal via IPv6 benaderbaar zijn, waar dat voor veel B2B-diensten niet geldt.

Dat zijn dan ook nog eens sites die veel data verstoken. Voor een enkel filmpje van een paar minuten op youtube moet je heel wat excel spreadsheets vol tikken.

[ Voor 29% gewijzigd door CAPSLOCK2000 op 24-03-2020 16:31 ]

[ik222]

Roetzen schreef op dinsdag 24 maart 2020 @ 14:15:
Opmerkelijk. Bij de thuisgebruiker is meer IPv6 in gebruik dan bij de bedrijven...

Dit is denk ik grotendeels Youtube en Netflix verkeer, dat zijn beide data grootverbruikers die volledig dualstack zijn. En net dat soort dienten worden nu overdag veel meer gebruikt nu mensen en vooral ook alle kinderen thuis zijn.

[darkrain]

Freeaqingme schreef op dinsdag 24 maart 2020 @ 16:18:
[...]


Is dat heel gek? Bij bedrijven heb je vaak netwerken die door 3e partijen gemanaged worden. Die vinden IPv6 maar eng. En voorzover het niet eng is "kost het extra tijd" om een extra stack te maintainen en te troubleshooten.

Klopt, ik heb zelfs geen IPv6 op het VLAN waar mijn zakelijk laptop en telefoon op zitten, als ik dat wel doe gaan er allerlei dingen stuk... Aangezien dit iets is wat gewoon moet werken dan maar op IPv4. Voor de mensen die voorbeelden willen, denk aan VPN en DNS (wat via één of andere secure proxy loopt).

De zaak is er simpelweg nog niet klaar voor, helaas..

[ Voor 4% gewijzigd door darkrain op 25-03-2020 08:38 ]

[XVI]

KPN (telfort) lijkt nu (misschien al sinds een tijdje?) eindelijk zelf een 6to4 server te hebben (ipv6-test identificeert die server als mijn eigen IPv4 adres, wat wel weer een interessante implementatie is).
Helaas is m'n IPv6 nu om te huilen.

Leuk dat ze (klant) IPv6 eindelijk een beetje serieus nemen, maar dit schiet natuurlijk niet op.
Wat het erger maakt is dat firefox ineens IPv6 prefereert zodra er een pakketje doorkomt, terwijl dit normaliter met 6to4 niet het geval is (DOH?!), wat leidt tot (enkele) trage en hangende sites.
Heb al een tijdje niet meer naar m'n routertunnel gekeken dus misschien ligt het daaraan.
Zien anderen hetzelfde?

Heb een testpagina verkeerd geïnterpreteerd en denk dat de (brakke) relay nog steeds buiten het kpn-netwerk zit.

[ Voor 45% gewijzigd door XVI op 29-03-2020 10:32 ]

[joopv]

CAPSLOCK2000 schreef op dinsdag 24 maart 2020 @ 16:28:
[...]
Zolang de reuzen wel IPv4-adressen hebben en nieuwe concurrenten niet kan ik wel begrijpen dat ze weinig haast maken.[...]

Amazon heeft vorig jaar nog een /10 gekocht voor meer dan 10 dollar per adres. https://www.ampr.org/amprnet/
(het exacte bedrag kan ik zo niet terugvinden) Kleingeld voor zo'n organisatie.
En ik lees op reddit dat er een /8 beschikbaar komt.

[aawe mwan]

In de startpost staat "het host deel van je global IPv6 adres kan je zelf te bepalen" en daar ben ik mee bezig. Van XS4ALL heb ik een /48 adres en de FRITZ!Box maakt daar een /64 van, ik heb dus nog 4 blokjes om zelf in te vullen. Ik ben op zoek naar simpele, praktische tips daarvoor.

Is het bijvoorbeeld handig om deze 4 blokken te vullen met het IPv4 adres in BCD?
Is het handig om hetzelfde adres op meerdere interfaces te zetten (op ethernet en wlan bijvoorbeeld)?

Bij XS4ALL kan ik een naam instellen voor mijn globale IPv4 adres (als subdomein van xs4all.nl) en dat is handig. Hoe krijg ik die naam gekoppeld aan het IPv6 adres dat ik ga kiezen voor mijn jumperserver? Want bijvoorbeeld traceroute6 geeft nu "unknown host".

[jurry]

aawe mwan schreef op zondag 29 maart 2020 @ 10:10:
Is het handig om hetzelfde adres op meerdere interfaces te zetten (op ethernet en wlan bijvoorbeeld)?

Je bedoelt toch niet hetzelfde IP adres op twee verschillende interfaces? Misschien dat je iets met keepalived kunt doen.

Als jumphost heb ik hier een RaspberryPi waarbij ik de optie voor slaac in /etc/dhcpcd.conf gewijzigd in hwaddr en vervolgens in een eigen domeinnaam een AAAA record aangemaakt. Dan heb je een vast IPv6 adres via DHCP en hoef je verder geen administratie van handmatige IP adressen bij te houden. Nadeel is dat als je van hardware wisselt je een ander IP adres krijgt maar dat is dan één wijziging in DNS.

[Vorkie]

joopv schreef op zondag 29 maart 2020 @ 00:56:
[...]

Amazon heeft vorig jaar nog een /10 gekocht voor meer dan 10 dollar per adres. https://www.ampr.org/amprnet/
(het exacte bedrag kan ik zo niet terugvinden) Kleingeld voor zo'n organisatie.
En ik lees op reddit dat er een /8 beschikbaar komt.

Als je iets zegt, zoals,

En ik lees op reddit dat er een /8 beschikbaar komt.

Misschien kan je er dan een link bij doen? Er zijn namelijk vrij weinig /8 subnetten over

Zoals je weer hier kan lezen:

Wikipedia: List of assigned /8 IPv4 address blocks

En welke ook niet klopt zie ik, want bijvoorbeeld 53.0.0.0/8 is compleet aan Daimler AG toebedeeld.

[ Voor 19% gewijzigd door Vorkie op 29-03-2020 11:12 ]

[Maurits van Baerle]

@Vorkie Ik neem aan dat hij dit verhaal bedoelt.

Internet samurai says he'll sell 14,700,000 IPv4 addresses worth $300m-plus, plow it all into Asia-Pacific connectivity

[Vorkie]

Maurits van Baerle schreef op zondag 29 maart 2020 @ 11:18:
@Vorkie Ik neem aan dat hij dit verhaal bedoelt.

Internet samurai says he'll sell 14,700,000 IPv4 addresses worth $300m-plus, plow it all into Asia-Pacific connectivity

Ah ja, met wat lezen zie ik dat er al lang delen uit deze /8 zijn uitgedeeld, om het in Reddit stijl te houden:

https://www.reddit.com/r/networking/comments/fol5qf/430008/

Just for reference, it’s not the whole /8, it’s “unallocated portions” of the /8. APNIC re-purposed the piece it was given originally and was allocating it to new networks about 5 years ago. There’s about 3000 routes in the global table in this /8 :-)
Source: We got a /22 from 43/8 about 5 years ago...

https://www.bigdatacloud.com/network-lookup/43.0.0.0/8

En hier al een beetje de adressen die zijn uitgedeeld

Dus in Asia komen er inderdaad nog wat blokken vrij

Dus dat helpt ons nog niet en het wordt weer gebruikt om IPv6 verder uit te stellen.

[CAPSLOCK2000]

joopv schreef op zondag 29 maart 2020 @ 00:56:
Amazon heeft vorig jaar nog een /10 gekocht voor meer dan 10 dollar per adres. https://www.ampr.org/amprnet/
(het exacte bedrag kan ik zo niet terugvinden) Kleingeld voor zo'n organisatie.
En ik lees op reddit dat er een /8 beschikbaar komt.

Met meer dan 10 dollar adres kom je al snel boven de 50 miljoen. Voor Amazon inderdaad kleingeld, maar voor het gemiddelde bedrijf een onoverkomelijk groot bedrag. Niet verkeerd voor adressen die gratis zijn weggegeven.

[Roetzen]

Vorkie schreef op zondag 29 maart 2020 @ 11:27:

Dus in Asia komen er inderdaad nog wat blokken vrij

Dus dat helpt ons nog niet en het wordt weer gebruikt om IPv6 verder uit te stellen.

Ik denk dat het met dat uitstel wel mee valt. In Azië hadden ze al langer een groot tekort, dus die blokken zijn in een paar maanden weer opgesoupeerd. Plus dat ze in Azië al aardig op weg zijn met IPv6.

[Vorkie]

Roetzen schreef op zondag 29 maart 2020 @ 17:19:
[...]

Ik denk dat het met dat uitstel wel mee valt. In Azië hadden ze al langer een groot tekort, dus die blokken zijn in een paar maanden weer opgesoupeerd. Plus dat ze in Azië al aardig op weg zijn met IPv6.

Ik begrijp je punt, maar als Azië dus steeds meer op IPv6 overstapt, gaan ze waarschijnlijk (ja vermoedelijk, onderbuik.. helaas) ook blokken verkopen naar Europa / USA, want die betalen toch wel....

Laten wij hopen dat IPv6 nou eens doorgang vindt, kom nog steeds teveel IPv4 only bedrijven en websites tegen.

[Roetzen]

Vorkie schreef op zondag 29 maart 2020 @ 17:21:
[...]

Ik begrijp je punt, maar als Azië dus steeds meer op IPv6 overstapt, gaan ze waarschijnlijk (ja vermoedelijk, onderbuik.. helaas) ook blokken verkopen naar Europa / USA, want die betalen toch wel....

Ik verwacht niet dat dat op grote schaal zal gaan gebeuren. In Azië hebben ze niets "over" Wie nog IPv4 heeft zal zo lang mogelijk dual stack willen blijven ondersteunen .

Laten wij hopen dat IPv6 nou eens doorgang vindt, kom nog steeds teveel IPv4 only bedrijven en websites tegen.

Wat de providers betreft gaat het inmiddels wel de goede kant op. Het zijn de bedrijven die nu achter blijven. Ook de overheid mag er wel eens aan gaan trekken. Mijn gemeente doet het goed (heuvelrug.nl) maar de sites van de RDW en de belastingdienst zijn nog steeds IPv4.:)

[Dreamvoid]

Azie in zijn algemeenheid is niet zozeer grote voorloper met IPv6 alswel dat ze minder IPv4 space hebben en er meer IPv4 achter CG-NAT zit dan in Europa/VS, waar grote hoeveelheden particulieren nog steeds een eigen IPv4 adres hebben, bv. Als ze daar massaal overschakelen naar IPv6 (in de vorm van DS-Lite, 464XLAT, NAT64, etc) dan verandert er dan voor de ISP’s niet zoveel qua IPv4 adresgebruik, IPv4 zit nog steeds achter dezelfde CG-NAT. En eventueel vrijkomende IPv4 ruimte gaat ws eerder naar de groeiende lokale servermarkt dan naar Europa (wat ook behoorlijke fragmentatie zou geven qua routing).

Maar low-traffic websites die nog IPv4 zijn, dat is niet het probleem. Zelfs in een wereld waar iedereen op single stack IPv6 zit, werken die nog wel. Alles draait bij de uitrol van IPv6 nu om de gebruikers, en de grote content networks. Als de website de gemeente geen AAAA record heeft, dat merkt niemand.

Bedrijfsnetwerken blijven idd achter, voornamelijk vanwege legacy intranet spul, en niemand wil een dual stack LAN beheren.

[Roetzen]

Dreamvoid schreef op zondag 29 maart 2020 @ 20:11:
Maar low-traffic websites die nog IPv4 zijn, dat is niet het probleem. Zelfs in een wereld waar iedereen op single stack IPv6 zit, werken die nog wel. Alles draait bij de uitrol van IPv6 nu om de gebruikers, en de grote content networks. Als de website de gemeente geen AAAA record heeft, dat merkt niemand.

Het gaat natuurlijk ook om het signaal. De overheid heeft een voorbeeldfunctie.

Bedrijfsnetwerken blijven idd achter, voornamelijk vanwege legacy intranet spul, en niemand wil een dual stack LAN beheren.

Ze zullen er toch een keer aan moeten en - het is al zo vaak gezegd - hoe langer men wacht, hoe moeilijker en hoe duurder het wordt.

[Dreamvoid]

Roetzen schreef op maandag 30 maart 2020 @ 17:59:
Ze zullen er toch een keer aan moeten en - het is al zo vaak gezegd - hoe langer men wacht, hoe moeilijker en hoe duurder het wordt.

In de regel, hoe langer je wacht hoe eenvoudiger het wordt, elk jaar vallen er meer IPv4-only legacy applicaties weg uit je business. Zodra de laatste weg is, kan je in 1 klap over naar single stack IPv6 (met DNS64/NAT64). Hoe langer je wacht, hoe korter de periode is dat je dat vervelende dual stack moet gaan doen.

[Freeaqingme]

Wat ik overigens opvallend vind, is dat de prijs van ipv4-adressen al een tijd stabiel lijkt te blijven, ook sinds het opraken van de pool bij RIPE. En ook dat de waiting list bij RIPE op 0 dagen staat, en er zowaar ipv4-adressen beschikbaar zijn. Dat impliceert voor mij toch dat de vraag/noodzaak voor ipv4-adressen lijkt af te nemen voor veel bedrijven.

[CAPSLOCK2000]

Freeaqingme schreef op dinsdag 31 maart 2020 @ 13:50:
Wat ik overigens opvallend vind, is dat de prijs van ipv4-adressen al een tijd stabiel lijkt te blijven, ook sinds het opraken van de pool bij RIPE. En ook dat de waiting list bij RIPE op 0 dagen staat, en er zowaar ipv4-adressen beschikbaar zijn. Dat impliceert voor mij toch dat de vraag/noodzaak voor ipv4-adressen lijkt af te nemen voor veel bedrijven.

Een paar opmerkingen over de adressen bij RIPE.
RIPE heeft inderdaad weer wat adressen op voorraad maar die kun je alleen onder strenge voorwaarden krijgen. Het komt er op neer dat nieuwe ISPs en vergelijkbare organisaties eenmaalig een /24 kunnen krijgen voor compatibility doeleinden. Als je geen netwerkbedrijf bent of al adressen hebt dan kom je eigenlijk niet in aanmerking.

Uit de wachtrij grafiek kun je ook aflezen dat er begin december meer dan 100 organisaties in de wachtrij stonden om een schamele /24 te krijgen. Bij mij thuis is een /24 eigenlijk al niet genoeg (omdat ik verschillende vlans en subnetten gebruik). Dat blokje kun je eigenlijk aalleen gebruiken om een IPv6<->IPv4 service op te draaien.

Ergens in december heeft RIPE een paar blokjes teruggekregen waarmee wachters geholpen zijn, maar die hebben eerst een tijd moeten wachten.


Op die veilingsite zie ik dat ze zo'n 20 dollar per IP-adres vragen. Ongeveer jaar geleden was dat nog zo'n 10 dollar per IP, dat is toch wel een forse stijging. Al kan het zijn dat het beeld vertekent wordt omdat er alleen adressen in die lijst staan die nog niet zijn verkocht. Wellicht is die prijs dus te hoog.

[Freeaqingme]

Ik ben het met je eens dat je aan een /24 niet heel veel hebt, maar iets is beter dan niets. Als een (nieuw) bedrijf toch eigen IPv6-adressen wil hebben moeten ze zelf een RIPE membership afsluiten. Als ze dat dan doen dan is 't een kleine moeite er ook meteen een IPv4-range bij te 'bestellen'. Kennelijk gebeurt dat toch niet heel veel.

Dat gezegd hebbende, het is niet alleen voor ISP's of netwerkbedrijven. In principe kan iedereen RIPE member worden en zo'n /24 krijgen.

Ergens in december heeft RIPE een paar blokjes teruggekregen waarmee wachters geholpen zijn, maar die hebben eerst een tijd moeten wachten.

Er zijn er in december maar echt heel weinig bijgekomen (zo'n 50K denk ik), het grootste deel komt omdat RIPE teruggegeven ranges 12 maanden ofzo in quarantine houdt. Daarvan zijn er een paar vrijgekomen:

CAPSLOCK2000 schreef op dinsdag 31 maart 2020 @ 17:14:
[...]

Op die veilingsite zie ik dat ze zo'n 20 dollar per IP-adres vragen. Ongeveer jaar geleden was dat nog zo'n 10 dollar per IP, dat is toch wel een forse stijging. Al kan het zijn dat het beeld vertekent wordt omdat er alleen adressen in die lijst staan die nog niet zijn verkocht. Wellicht is die prijs dus te hoog.

Ik zie op diezelfde site historische prijzen van 12 manden oud waar ze ook 20 USD zijn. Ik weet niet of die prijs 'dus te hoog' is. Dat lijkt me bij uitstek een kwestie van vraag en aanbod?

Overigens is ook bij ARIN de waiting list vrij beperkt, waarbij de een na oudste aanmelding van 5 maart lijkt te zijn.

Ik ben het met je eens dat die losse /24's niet zo heel veel zoden aan de dijk zetten, maar als IPv4 nog heel populair zou zijn, dan zou je verwachten dat de waiting list steeds voller werd (menig bedrijf heeft voldoende BV'tjes om ripe members mee op te kunnen zetten, en deden dat ook toen er nog 4 /24's werden uitgedeeld) of de prijs steeds hoger zou worden. Beiden vallen mee.

[CAPSLOCK2000]

Her gaat inderdaad vrij langzaam. Overigens is RIPE niet gratis, het kost zo'n e1500 per jaar, oftewel 6 euro per adres per jaar (voor een /24). Kopen op de markt is dan al snel voordeliger.

[Freeaqingme]

Klopt. En new member fee is iets van 2K. Voor het eerste jaar kom je dan op 3500 euro uit. Pas na 2 jaar mag je een range transferren, dus dan zit je op 3500+2x1500 = 6500e voordat je deze kan verkopen, of bijv. kan verplaatsen naar een holding (zou je een concern hebben met heel veel onderliggende bv's). Toen er nog een /22 werd uitgedeeld (of 4x /24's) was dat sommetje nog wat interessanter.

Tegelijkertijd is 't zo dat je die membership fee sowieso moet betalen als je IPv6-adressen wil bezitten. Wat dat betreft is de situatie voor IPv6 niet anders dan zeg 10 jaar geleden voor IPv4.

CAPSLOCK2000 schreef op dinsdag 31 maart 2020 @ 18:48:
Her gaat inderdaad vrij langzaam. Overigens is RIPE niet gratis, het kost zo'n e1500 per jaar, oftewel 6 euro per adres per jaar (voor een /24). Kopen op de markt is dan al snel voordeliger.

En toch ook niet helemaal. Want om deze 'op naam' te zetten moet je dan alsnog RIPE member zijn. En als mensen die kosten/baten-afweging zouden maken dan zou je verwachten dat de vraag op de markt groter wordt, en de prijs omhoog zou gaan. Ook dat lijkt niet te gebeuren.

Overigens, fun fact, ook particulieren mogen RIPE member worden. Beetje dure aangelegenheid, maar ik vond 't een bijzonder iets.

[ANdrode]

Freeaqingme schreef op dinsdag 31 maart 2020 @ 19:17:
Klopt. En new member fee is iets van 2K. Voor het eerste jaar kom je dan op 3500 euro uit. Pas na 2 jaar mag je een range transferren, dus dan zit je op 3500+2x1500 = 6500e voordat je deze kan verkopen, of bijv. kan verplaatsen naar een holding (zou je een concern hebben met heel veel onderliggende bv's). Toen er nog een /22 werd uitgedeeld (of 4x /24's) was dat sommetje nog wat interessanter.

Concludeer jij dan ook dat de prijs van IPv4 nu de prijs van ranges voor nieuwe RIPE leden begint te benaderen? 2^(32-8) * EUR 20 zit in de buurt van EUR 3500 + 1500?

offtopic:
Ik typte eerste 6500 over maar dan zou je na drie jaar kunnen transferen ipv twee?

Tegelijkertijd is 't zo dat je die membership fee sowieso moet betalen als je IPv6-adressen wil bezitten. Wat dat betreft is de situatie voor IPv6 niet anders dan zeg 10 jaar geleden voor IPv4.

Voor provider independent space?

En toch ook niet helemaal. Want om deze 'op naam' te zetten moet je dan alsnog RIPE member zijn. En als mensen die kosten/baten-afweging zouden maken dan zou je verwachten dat de vraag op de markt groter wordt, en de prijs omhoog zou gaan. Ook dat lijkt niet te gebeuren.

Bij legacy/provider independent space hoef je toch geen local internet registry te worden? Waarschijnlijk heeft provider independent space wel een (grote) meerprijs.

[aawe mwan]

jurry schreef op zondag 29 maart 2020 @ 11:01:
[...]
Als jumphost heb ik hier een RaspberryPi waarbij ik de optie voor slaac in /etc/dhcpcd.conf gewijzigd in hwaddr en vervolgens in een eigen domeinnaam een AAAA record aangemaakt. Dan heb je een vast IPv6 adres via DHCP en hoef je verder geen administratie van handmatige IP adressen bij te houden. Nadeel is dat als je van hardware wisselt je een ander IP adres krijgt maar dat is dan één wijziging in DNS.

Een van de redenen waarom ik zelf IPv6 adressen wil toekennen, is dat ik liever niet met een adres het internet op wil gaan dat gebonden is aan hardware. Als ik het dan wat logischer/handiger kan maken, is dat mooi meegenomen, vandaar BCD. Is er niet gewoon een handige guide voor geschreven?

Ik heb nu dit draaien op de jumpserver:
(ip neigh; ip -r neigh) | awk '{print $4=="lladdr"?$5:"x",$1}' | sort -u
en zodoende zie ik dat er in de loop van een dag meer verandert op mijn netwerk dan wat ik verwacht had.

Zet je dat AAAA record bij XS4ALL? Want voor IPv4 kan ik de hostnaam gewoon via de webinterface instellen, via IPv6 lijkt het ineens niet meer te kunnen. Da's raar toch?

[Dreamvoid]

Normaal gesproken met SLAAC zet je PC met het telkens veranderende dynamische adres (privacy extensions) uitgaande verbindingen op, je vaste adres gebruik je voor inkomende verbindingen (DNS). Uiteraard, als je privacy extensions op je PC hebt uitgezet dan niet meer, maar dat lijkt me praktischer dan de boel handmatig lopen doen.

[jurry]

aawe mwan schreef op dinsdag 31 maart 2020 @ 22:14:
Zet je dat AAAA record bij XS4ALL? Want voor IPv4 kan ik de hostnaam gewoon via de webinterface instellen, via IPv6 lijkt het ineens niet meer te kunnen. Da's raar toch?

Hiervoor gebruik ik een andere domeinnaam gehost bij een andere partij dan XS4ALL. Nadeel is dat reverse DNS lookups niet werken al schijn je dat wel via mail te kunnen aanvragen bij XS4ALL.

[Roetzen]

Dreamvoid schreef op dinsdag 31 maart 2020 @ 13:15:
[...]
In de regel, hoe langer je wacht hoe eenvoudiger het wordt, elk jaar vallen er meer IPv4-only legacy applicaties weg uit je business. Zodra de laatste weg is, kan je in 1 klap over naar single stack IPv6 (met DNS64/NAT64). Hoe langer je wacht, hoe korter de periode is dat je dat vervelende dual stack moet gaan doen.

Hoe graag ik het ook anders zou willen: IPv4 blijft nog wel even bij ons. Ook al is IPv6 het dominante protocol, dan zijn we nog niet meteen van IPv4 af. Dual Stack overslaan, lijkt me geen reële optie. Ook al zou je van alle IPv4 only legacy applicaties af zijn voordat je echt niet meer om IPv6 heem kunt, dan nog lijkt het me niet doenlijk om in één nacht alles om te zetten van IPv4 only naar IPv6 only (met DNS64/NAT64) Dat lijkt me een rampscenario. Of was dit een wat vroeg gelanceerde aprilgrap?

Freeaqingme schreef op dinsdag 31 maart 2020 @ 13:50:
Wat ik overigens opvallend vind, is dat de prijs van ipv4-adressen al een tijd stabiel lijkt te blijven, ook sinds het opraken van de pool bij RIPE.

Inderdaad opvallend. Dat de prijs stabiel is, betekent dat vraag en aanbod in balans zijn. Ik had verwacht dat de prijs nog wel even zou blijven stijgen.

En ook dat de waiting list bij RIPE op 0 dagen staat, en er zowaar ipv4-adressen beschikbaar zijn. Dat impliceert voor mij toch dat de vraag/noodzaak voor ipv4-adressen lijkt af te nemen voor veel bedrijven.

Dat zou je dan denken ja. Dus wie nog een voorraadje heeft: Nu verkopen...

[Dreamvoid]

Single stack IPv6 ligt echt niet zo ver weg hoor. Als bedrijf kan je bv het wifi VLAN/ssid die je naar je iPhones pusht nu al volledig op IPv6+DSN64/NAT64 zetten.

Voor je vaste PC’s zal je een inventarisatie moeten doen welke applicaties op je client PC’s draaien, maar als je veel met moderne cloud services werkt en niet veel legacy intranet servers draait dat IPv4-literals nodig heeft kan je op zich prima intern op single stack IPv6 draaien, uiteraard wel met DNS64/NAT64 op de edge.

Ik zie de toekomst van bedrijfsnetwerken als grote IPv6-only VLANs, met eilandjes van IPv4 VLANs voor de laatste legacy servers.

[ Voor 11% gewijzigd door Dreamvoid op 02-04-2020 15:22 ]

[Snow_King]

Dreamvoid schreef op donderdag 2 april 2020 @ 14:26:
Single stack IPv6 ligt echt niet zo ver weg hoor. Als bedrijf kan je bv het wifi VLAN/ssid die je naar je iPhones pusht nu al volledig op IPv6+DSN64/NAT64 zetten.

Voor je vaste PC’s zal je een inventarisatie moeten doen welke applicaties op je client PC’s draaien, maar als je veel met moderne cloud services werkt en niet veel legacy intranet servers draait dat IPv4-literals nodig heeft kan je op zich prima intern op single stack IPv6 draaien, uiteraard wel met DNS64/NAT64 op je edge router.

Eens. Wij draaien een groot deel van ons netwerk en servers al helemaal v6-only. Dan praat je niet over een paar servers, maar over enkele honderden servers en switches.

Beheer doen we allemaal over v6-only. SSH, SNMP, etc.

Onze kantoren en thuis verbindingen hebben grotendeels IPv6 en indien nodig is het een kwestie van de OpenVPN tunnel aan zetten en je hebt dan alsnog v6.

Waarom we dit doen? Het gaat ons in de toekomst heel veel werk schelen en nu hoeven we ook maar één protocol te onderhouden.

Onze hypervisors, storage nodes, switches zijn dus allemaal v6-only. IPv4 komt pas om de hoek binnen de Virtual Machines waar applicaties voor klanten draaien (indien nodig).

De MySQL (MariaDB) databases voor onze klanten zijn ook v6-only. v4 draait enkel op de webserver en die kan via v6 bij de MySQL servers.

Scheelt ons gewoon heel veel werk.

[Dreamvoid]

Exact, dual stack is bij beheerders erg impopulair, en da’s ook terecht in mijn ogen. Het is lastig troubleshooten, en een security risico in de zin dat je twee netwerken parallel moet houden, en ervoor zorgen dat als je iets in IPv4 blokkeert of monitort, je eraan moet blijven denken dat ook over v6 te doen. Het is helaas menselijk dat dit nogal foutgevoelig is.

De grote ISP's in Europa zijn op hun eigen netwerken ook eigenlijk allemaal bezig met een transitie naar single-stack IPv6, met IPv4 ofwel translated (464XLAT, DNS64/NAT64, op mobiele netwerken) ofwel tunneled (DS-Lite, bij glas/kabel/DSL) over een IPv6 infrastructuur.

Wat wel jammer is, is dat je op Windows 10 de CLAT niet kan aanzetten op de wifi/ethernet verbinding, dat is nu beperkt tot de WWAN (4G) interface. Zodra MS dat toelaat, kan je ook PC’s met v4 legacy applicaties in een single stack LAN duwen.

[ Voor 17% gewijzigd door Dreamvoid op 02-04-2020 15:50 ]

[Roetzen]

Dreamvoid schreef op donderdag 2 april 2020 @ 15:29:
Exact, dual stack is bij beheerders erg impopulair, en da’s ook terecht in mijn ogen. Het is lastig troubleshooten, en een security risico in de zin dat je twee netwerken parallel moet houden, en ervoor zorgen dat als je iets in IPv4 blokkeert of monitort, je eraan moet blijven denken dat ook over v6 te doen. Het is helaas menselijk dat dit nogal foutgevoelig is.

Ik snap waarom Dual Stack lastig te onderhouden is. Maar het probleem van overslaan van Dual Stack blijft dat je dan in één nacht alles moet overzetten van IPv4 naar IPv6. En dat is m.i. vragen om problemen.

De grote ISP's in Europa zijn op hun eigen netwerken ook eigenlijk allemaal bezig met een transitie naar single-stack IPv6, met IPv4 ofwel translated (464XLAT, DNS64/NAT64, op mobiele netwerken)

Dat konden ze pas doen nadat oudere mobiel apparaten die geen 464LAT, DNS64/NAT64 ondersteunen waren uitgestorven.

[Dreamvoid]

Roetzen schreef op vrijdag 3 april 2020 @ 13:18:
[...]

Ik snap waarom Dual Stack lastig te onderhouden is. Maar het probleem van overslaan van Dual Stack blijft dat je dan in één nacht alles moet overzetten van IPv4 naar IPv6. En dat is m.i. vragen om problemen.

Dat hoeft toch niet? Je kan met je group policies gewoon PC voor PC IPv4 uitzetten en IPv6 aanzetten. De oude houd je op een IPv4 VLAN. Op een gegeven moment zijn ze allemaal over. Kan zelfs zonder group policies met DHCP: geef devices die op IPv6 kunnen gewoon geen IPv4 adres meer, en vice versa. Dat soort gafaseerde migraties doen IT beheerders regelmatig, bv de overgang van Windows 7 naar Windows 10 gaat meestal in batches.

Zo doen de telco's het feitelijk ook: mobiel bestaat alleen maar single stack, telefoons die IPv6 ondersteunen krijgen een andere APN gepushed dan IPv4 telefoons.

Dat konden ze pas doen nadat oudere mobiel apparaten die geen 464LAT, DNS64/NAT64 ondersteunen waren uitgestorven.

En daar is idd het wachten op, het moment dat de laatste bedrijfsapplicaties die geen IPv6 en DNS64/NAT64 doen wegvallen. De OSsen en browsers (Windows 10, macOS, Linux en Safari/Firefox/Edge/Chrome) zijn al klaar, dat is het probleem niet, het zijn de legacy applicaties die nog IPv4 literals gebruiken. En als het OS zelf een CLAT kan draaien (zoals bv Linux), dan hoef je daar zelfs niet op te wachten.

[ Voor 5% gewijzigd door Dreamvoid op 03-04-2020 14:28 ]

[Tomsworld]

Ik wacht ook met smart op ipv6 alle grote ips's hebben het hier ( Proximus, Telenet, Voo, Edpnet ) maar Orange blijft maar duren het komt ooit.

En ook geen enkele tunnelbroker die nog ipv6 tunnels aanbied met Belgische ranges ( ook via ovh niet mogelijk ipv6 is niet geolocalized ).

[Dreamvoid]

Kan je niet switchen naar een andere ISP?

[Roetzen]

Dreamvoid schreef op vrijdag 3 april 2020 @ 14:14:
[...]

Alles in één keer moeten omzetten...

Dat hoeft toch niet? Je kan met je group policies gewoon PC voor PC IPv4 uitzetten en IPv6 aanzetten. De oude houd je op een IPv4 VLAN. Op een gegeven moment zijn ze allemaal over.

En zo lang ze nog niet allemaal over zijn, zit je toch met een netwerk waar zowel IPv4 als IPv6 over gaat. Zit je toch weer met (een deel) van de problemen van dubbel onderhoud en meer kans op fouten, net als bij Dual Stack. Dus is dat nu werkelijk handiger?

En als dat dan zo is, waarom moet je dan wachten tot alle legacy applicaties verdwenen zijn? Die laat je dan toch met group policies op IPv4 staan tot ze weg zijn? Wat mis ik?

[Roetzen]

Nieuwe metingen:

[Snow_King]

Roetzen schreef op dinsdag 21 april 2020 @ 20:53:
Nieuwe metingen:

[Afbeelding]

[Afbeelding]

Zie ook: https://www.sidn.nl/nieuw...-het-internet-op-via-ipv6

Denk dat meer mensen achter hun Ziggo lijn werken. En volgens mij hebben veel meer thuis verbindingen inmiddels v6 dan kantoren.

[Dreamvoid]

Roetzen schreef op zaterdag 4 april 2020 @ 12:40:
En zo lang ze nog niet allemaal over zijn, zit je toch met een netwerk waar zowel IPv4 als IPv6 over gaat. Zit je toch weer met (een deel) van de problemen van dubbel onderhoud en meer kans op fouten, net als bij Dual Stack. Dus is dat nu werkelijk handiger?

Beetje late reactie maar persoonlijk beheer ik liever single stack IPv4 VLAN plus single stack IPv6+NAT64 VLAN (en migreer de clients in batches van 4 naar 6), dan alles in een dual stack VLAN. Zo doen de mobiele telco's het feitelijk ook.

Overigens, als ik prive kijk is het opzetten van een single-stack IPv6+NAT64 LAN nog niet zo makkelijk: mijn provider heeft geen NAT64 server beschikbaar voor klanten op het vaste netwerk.

https://www.sidn.nl/nieuw...-het-internet-op-via-ipv6

Dit artikel slaat inderdaad de spijker op de kop, al wordt het wel een hele opvoedings klus om gamers uit te leggen dat hun spel niet meer automatisch via UPnP/NAT-PMP poorten kan openen, maar nu handmatig in hun firewall settings moeten duiken. Blijft toch jammer dat PCP zo weinig gebruikt wordt.

Onlangs sprak netwerkspecialist Iljitsch van Beijnum de verwachting uit dat de volgende (wereldwijde) push naar IPv6 komt van grote telecom en access providers die grote aantallen gebruikers op IPv6-only hebben zitten. Hun verkeer naar IPv4-only aanbieders moet immers op de NAT64 gateways vertaald worden – iets dat vooral voor multimedia content aanzienlijke verwerkingskracht vereist.

Het sterk toegenomen gebruik van streaming-diensten en het toegenomen gebruik van IPv6 maken dat access providers eerder aan de content providers zullen vragen om hun systemen (ook) via IPv6 bereikbaar te maken. Daarmee lijkt de corona-uitbraak de toekomst voor wat betreft IPv6 een stuk dichterbij te hebben gebracht.

Dit inderdaad - de grote druk om servers naar IPv6 te pushen komt niet vanaf de gebruikers, maar vanaf de ISP's

[ Voor 6% gewijzigd door Dreamvoid op 22-04-2020 15:26 ]

[Freeaqingme]

ANdrode schreef op dinsdag 31 maart 2020 @ 21:11:
[...]


Concludeer jij dan ook dat de prijs van IPv4 nu de prijs van ranges voor nieuwe RIPE leden begint te benaderen? 2^(32-8) * EUR 20 zit in de buurt van EUR 3500 + 1500?

offtopic:
Ik typte eerste 6500 over maar dan zou je na drie jaar kunnen transferen ipv twee?

In de categorie 'beter laat dan nooit'; je sommetje volg ik niet helemaal dus durf ik niets over te zeggen. Reden dat ik uit ging van 6500 is dat je pas _na_ 2 jaar mag transferen. Dus stel dat je op 1 januari 2020 ip-adressen koopt, dan mag je die pas op 2 januari 2022 verkopen volgens mij. Dan betaal je dus:
- 01-01-2020: 2000 euro Signup-fee
- 01-01-2020: 1500 euro membership fee
- 01-01-2021 1500 euro membership fee
- 01-01-2022 1500 euro membership fee
- 02-01-2022: IP space mag verhandeld worden.

Overigens hield ik 1500 euro aan, ik zie dat 't op de afgelopen factuur 1400 euro was, waarbij je ook nog iets van 350 euro tegoed kreeg. Daarmee liggen de echte getallen iets lager.

ANdrode schreef op dinsdag 31 maart 2020 @ 21:11:
[...]


Voor provider independent space?


[...]


Bij legacy/provider independent space hoef je toch geen local internet registry te worden? Waarschijnlijk heeft provider independent space wel een (grote) meerprijs.

Durf ik je niet precies te zeggen. Ik werk zelf veel meer aan de ISP kant, en die gebruiken - denk ik - allemaal PA-space. Op Wikipedia lees ik dat er geen PI space meer uitgedeeld wordt voor IPv4. Of je voor PI space LIR moe(s)t zijn durf ik niet te zeggen.

---

Verder kwam ik in de nieuwsbrief van RIPE nog dit artikel tegen: https://labs.ripe.net/Mem...oning/do-we-need-a-new-ip

Huawei stelt alvast de volgende IP-standaard voor. Ik wil het nog aandachtig gaan lezen, maar wellicht vindt iemand het alvast leuk.

[Roetzen]

Snow_King schreef op woensdag 22 april 2020 @ 09:01:
[...]

Zie ook: https://www.sidn.nl/nieuw...-het-internet-op-via-ipv6

Denk dat meer mensen achter hun Ziggo lijn werken. En volgens mij hebben veel meer thuis verbindingen inmiddels v6 dan kantoren.

Ik vermoed dat de (middelgrote) kantoren en bedrijven minstens net zo veel IPv6 aangeboden krijgen van de provider als particulieren. Maar dat het bij de bedrijven vaak bij niet verder komt dan het modem en dat ze het interne LAN IPv4 only houden zolang het nog enigszins gaat.

Misschien dat de IPv6 thuiswerkers hun bazen kunnen overtuigen dat het toch echt beter gaat als ze ook de overstap naar IPv6 maken.

Dreamvoid schreef op woensdag 22 april 2020 @ 13:34:
[...]

Beetje late reactie maar persoonlijk beheer ik liever single stack IPv4 VLAN plus single stack IPv6+NAT64 VLAN (en migreer de clients in batches van 4 naar 6), dan alles in een dual stack VLAN. Zo doen de mobiele telco's het feitelijk ook.

Maar hoe moet ik me dat "single stack IPv4 VLAN plus single stack IPv6+NAT64 VLAN" dan voorstellen? Heb je twee fysiek gescheiden netwerken? Want als het over hetzelfde kabeltje of hetzelfde WiFi signaal gaat heb je nog steeds op een bepaald level IPv4 en IPv6 naast elkaar en kun je ongewenste interacties krijgen.

Overigens, als ik prive kijk is het opzetten van een single-stack IPv6+NAT64 LAN nog niet zo makkelijk: mijn provider heeft geen NAT64 server beschikbaar voor klanten op het vaste netwerk.

Dan zul je een andere NAT64 server moeten zien te vinden. Of toch maar Dual Stack doen..

Dit artikel slaat inderdaad de spijker op de kop, al wordt het wel een hele opvoedings klus om gamers uit te leggen dat hun spel niet meer automatisch via UPnP/NAT-PMP poorten kan openen, maar nu handmatig in hun firewall settings moeten duiken. Blijft toch jammer dat PCP zo weinig gebruikt wordt.

Daar leren ze van. Ik geef de controle over de poorten liever niet uit handen. En zo moeilijk is het handmatig instellen nu ook weer niet. Ik heb PnP hier ook uit staan.

[linkforsoad]

Heb het hier al vaker zien passeren, maar ook ik blijf me verbazen over de hoeveelheid ICT-dienstverleners aan het MKB die beginnen met handeling #1 IPv6 uitschakelen. Is eng en niet nodig. Zelfs grotere en professionelere clubs.

[BCC]

Ik vind het vrij logisch - het zorgt voor meer storingen en je moet actief 2 stacks beheren, een ipv6 stack en een ipv4 stack.. als de klant er niet om vraagt, waarom zou je dat dan doen?

[Dreamvoid]

Idd, maar goed ik schrijf dan ook net hierboven een vurig pleidooi voor single-stack Binnen je LAN IPv6 (of IPv4) uitschakelen. Voor servers op het internet zal je uiteraard wel dual stack willen doen.

Dan zul je een andere NAT64 server moeten zien te vinden. Of toch maar Dual Stack doen..

Idd, ik hang nu aan full dual stack nu, met publiek IPv4 adres. Is op zich niks mis mee verder, maar ik zou graag het hele LAN IPv6-only maken, scheelt me werk Een 3rd party DNS64/NAT64 server dat heeft ws nogal wat snelheids implicaties.

[ Voor 82% gewijzigd door Dreamvoid op 23-04-2020 15:40 ]

[BCC]

Ja, idd. Ik heb een hele tijd dual stack gedraait hier lokaal, maar toen sixt ermee stopte was dat niet meer te doen.

Dreamvoid schreef op woensdag 22 april 2020 @ 13:34:
[...]
Dit artikel slaat inderdaad de spijker op de kop, al wordt het wel een hele opvoedings klus om gamers uit te leggen dat hun spel niet meer automatisch via UPnP/NAT-PMP poorten kan openen, maar nu handmatig in hun firewall settings moeten duiken. Blijft toch jammer dat PCP zo weinig gebruikt wordt.

Gewoon zeggen dat het sneller is

[ Voor 11% gewijzigd door BCC op 23-04-2020 15:51 ]

[jk-5]

- sorry, verkeerde topic -

[ Voor 121% gewijzigd door jk-5 op 23-04-2020 16:12 ]

[Roetzen]

BCC schreef op donderdag 23 april 2020 @ 15:17:
Ik vind het vrij logisch - het zorgt voor meer storingen en je moet actief 2 stacks beheren, een ipv6 stack en een ipv4 stack.. als de klant er niet om vraagt, waarom zou je dat dan doen?

Omdat het een kwestie van tijd is voordat er iemand wel om vraagt en goed ondernemerschap impliceert dat je anticipeert op de wensen van de klant?

Dreamvoid schreef op donderdag 23 april 2020 @ 15:24:

Idd, ik hang nu aan full dual stack nu, met publiek IPv4 adres. Is op zich niks mis mee verder, maar ik zou graag het hele LAN IPv6-only maken, scheelt me werk Een 3rd party DNS64/NAT64 server dat heeft ws nogal wat snelheids implicaties.

Als IPv4 wat trager wordt is dat een aansporing om over te gaan op IPv6.

[linkforsoad]

BCC schreef op donderdag 23 april 2020 @ 15:17:
Ik vind het vrij logisch - het zorgt voor meer storingen en je moet actief 2 stacks beheren, een ipv6 stack en een ipv4 stack.. als de klant er niet om vraagt, waarom zou je dat dan doen?

Daar kan ik mij zeker in vinden, en dat lijkt me een valide uitleg. De verwondering van mij is meer het automatisme om het uit te zetten, louter omdat men er onbekend mee is. Dat vind ik erg gemakzuchtig, vooral wanneer er daarna goede redenen zijn om (gedeeltelijk) IPv6 te willen doen maar men dat niet durft om voorgaande reden.

[St00mwals]

Wat heel veel beheerders/bedrijven ook vergeten is dat de grote jongens zoals Microsoft alles testen met IPv6 aan. Loop jij dan tegen problemen aan en ze komen er niet uit dan krijg je vrolijk te horen:

Please enable IPv6 and call again.

[dovo]

Azure en ipv6 is nochtans een totale grap. Je kan geen publieke ipv6 op een VM krijgen, en egress v6 is gebaseerd op NAT66. Ze hebben zelfs het concept private IPv6 uitgevonden wat niet eens bestaat.(ULA != RFC1918) Probeer je een v6 only interface te maken, dan krijg je

code:

Failure sending request: StatusCode=400 -- Original Error: Code="AtleastOneIpV4RequiredForIpV6NicIpConfiguration" Message="At least one IPv4 ipConfiguration is required for an IPv6 ipConfiguration on the network interface

Op hun loadbalancers kan je dus enkel een publiek IPv6 krijgen, waar je zelfs evenveel betaald voor één IPv6 als voor IPv4.

Microsoft is dus alles behalve een voorbeeld als het om IPv6 gaat.

[ANdrode]

Freeaqingme schreef op woensdag 22 april 2020 @ 22:04:
[...]
In de categorie 'beter laat dan nooit'; je sommetje volg ik niet helemaal dus durf ik niets over te zeggen. Reden dat ik uit ging van 6500 is dat je pas _na_ 2 jaar mag transferen. Dus stel dat je op 1 januari 2020 ip-adressen koopt, dan mag je die pas op 2 januari 2022 verkopen volgens mij. Dan betaal je dus:
- 01-01-2020: 2000 euro Signup-fee
- 01-01-2020: 1500 euro membership fee
- 01-01-2021 1500 euro membership fee
- 01-01-2022 1500 euro membership fee
- 02-01-2022: IP space mag verhandeld worden.

Overigens hield ik 1500 euro aan, ik zie dat 't op de afgelopen factuur 1400 euro was, waarbij je ook nog iets van 350 euro tegoed kreeg. Daarmee liggen de echte getallen iets lager.

Ik ging uit van twee jaar membership fee. Drie jaar membership fee zou de kosten wat veranderen ja .

Durf ik je niet precies te zeggen. Ik werk zelf veel meer aan de ISP kant, en die gebruiken - denk ik - allemaal PA-space. Op Wikipedia lees ik dat er geen PI space meer uitgedeeld wordt voor IPv4. Of je voor PI space LIR moe(s)t zijn durf ik niet te zeggen.

Als ik het goed begrijp dan kan je PI space laten 'sponsoren' om van het contract van een LIR gebruik te maken. Legacy space is helemaal vrij. Het stond in een boekje en soms is er een contract.

Het lijkt mij dat legacy duurder is dan PI en PI duurder dan PA. Maar misschien is het prijsverschil heel klein: Als je de ruimte nodig hebt dan ben je waarschijnlijk zelf LIR.

---

Verder kwam ik in de nieuwsbrief van RIPE nog dit artikel tegen: https://labs.ripe.net/Mem...oning/do-we-need-a-new-ip

Huawei stelt alvast de volgende IP-standaard voor. Ik wil het nog aandachtig gaan lezen, maar wellicht vindt iemand het alvast leuk.

Een gecentraliseerd model in plaats van een decentraal model. Weet niet wat ik er van moet vinden. Het gaat sowieso even duren om dit uit te rollen .

Er zijn wel incentives voor providers om naar een gecentraliseerd model te gaan: ISPs willen eigenlijk dat er voor verkeer betaald wordt en dat is lastig…

[Snow_King]

BCC schreef op donderdag 23 april 2020 @ 15:17:
Ik vind het vrij logisch - het zorgt voor meer storingen en je moet actief 2 stacks beheren, een ipv6 stack en een ipv4 stack.. als de klant er niet om vraagt, waarom zou je dat dan doen?

Omdat je de verantwoordelijkheid hebt een goede dienst te leveren. Als ICT branche dragen we ook de verantwoordelijkheid dat we nu én in de toekomst een fatsoenlijke dienst kunnen leveren.

Dat kunnen we niet zonder iPv6 waar we alles maar achter CGNAT weg stoppen.

[Dreamvoid]

Je hebt grofweg drie opties als ICT dienstverlener om het LAN in te richten voor een zakelijke klant met een dual stack internet lijn:

1. ouderwets IPv4 nu en de migratie naar IPv6 "later"
2. dual stack: ouderwets IPv4 en daarnaast parallel IPv6 zonder DNS64/NAT64, en de migratie naar optie 3 "later"
3. single stack IPv6 met DNS64 enabled op je interne DNS server en NAT64 op de edge router

De keuze is niet altijd heel eenvoudig.

[ Voor 18% gewijzigd door Dreamvoid op 27-04-2020 11:07 ]

[Snow_King]

Dreamvoid schreef op maandag 27 april 2020 @ 10:20:
Je hebt grofweg drie opties als ICT dienstverlener om het LAN in te richten voor een zakelijke klant met een dual stack internet lijn:

1. ouderwets IPv4 nu en de migratie naar IPv6 "later"
2. dual stack: ouderwets IPv4 en daarnaast parallel IPv6 zonder DNS64/NAT64, en de migratie naar optie 3 "later"
3. single stack IPv6 met DNS64 enabled op je interne DNS server en NAT64 op de edge router

De keuze is niet altijd heel eenvoudig.

Ik zou nu altijd kiezen voor 2. Hebben wij op onze kantoren en thuis ook. Werkt prima.

[Dreamvoid]

Het nadeel is denk ik vooral dat het altijd complexer/duurder zal zijn dan opties 1 en 3.

Als je geen legacy dingen draait kan je anno 2020 naar optie 3, als ik een betere DSL modem/router had zou ik het thuis al doen.

[ Voor 43% gewijzigd door Dreamvoid op 27-04-2020 11:36 ]

[Vorkie]

Dreamvoid schreef op maandag 27 april 2020 @ 11:27:
Het nadeel is denk ik vooral dat het altijd complexer/duurder zal zijn dan opties 1 en 3.

Hoezo complexer / duurder?

Met een soort van logica inbouwen kom je aardig end;

VLAN 10 = xxxx:xxxx:xxxx:10::/64 en en 10.0.10.0/24
VLAN 1337 = xxxx:xxxx:xxxx:1337::/64 en 10.13.37.0/24

loadbalancer uit VLAN90 (DMZ)
front http binding:
10.9.4.80/32
xxxx:xxxx:xxxx:90::80/128
front https binding
10.9.4.43/32
xxxx:xxxx:xxxx:90::443/128

loadbalancer uit VLAN91 (DMZ)
front http binding:
10.9.14.80/32
xxxx:xxxx:xxxx:91::80/128
front https binding
10.9.14.43/32
xxxx:xxxx:xxxx:91::443/128

etc...

Verder DNS goed op orde hebben!

Een nieuw VLAN bekend maken komt dan niet heel veel bij; bij het aanmaken van het netwerk weet je bijna automatisch welk IPv6 subnet het wordt

bovenstaande is maar een idee, ieder zijn eigen ideeën lijkt mij

[Dreamvoid]

Complexer in de zin dat je alles moet doen wat je voor single stack IPv4 moet doen, plus IPv6 daar bovenop, en de twee in sync houden (niet alleen qua adressering, maar ook de firewall, DNS, filtering etc). Hoeveel complexer en hoeveel het extra kost is natuurlijk de hamvraag, maar ik denk niet dat je kan ontkennen dat het per definitie meer werk is dan single stack?

Laat ik het zo zeggen: ik ben nu bezig met single stack IPv6 testing, en ik word daar toch wel erg blij van moet ik zeggen. Hoe sneller ik dat kan uitrollen, hoe beter.

[ Voor 28% gewijzigd door Dreamvoid op 27-04-2020 12:07 ]

[dovo]

Dreamvoid schreef op maandag 27 april 2020 @ 11:53:
ontkennen dat het per definitie meer werk is dan single stack?

De vraag is eerder, wat is het kostenplaatje / werk effort van IPv6 achteraf te retrofitten in plaats van het mee op te nemen in het initiële design. Wat is de kostprijs van CGNAT gateways, en wat zijn de legal kosten bij abuse uit de pool van de CGNAT gateway. Ik kan zo nog een heleboel redenen opsommen waarom IPv6 eergisteren uitrollen goedkoper is dan morgen. De dag van vandaag probeert men IPv4-only vaak te beargumenteren vanuit het agile principe iets werkend is beter dan een goed product. En als je core business is om zo snel mogelijk elke geïnvesteerde euro te verdubbelen dan is een goed product hebben niet zo belangrijk, echter zijn dit soort bedrijfjes de eerste die met een crisis zoals de huidige kopje onder gaan.
Het zal altijd een afweging zijn, maar zomaar blind zijn voor de hele context om vandaag een paar cent meer te maken is het niet waard om morgen irrelevant te zijn.

[ik222]

Snow_King schreef op maandag 27 april 2020 @ 11:10:
[...]
Ik zou nu altijd kiezen voor 2. Hebben wij op onze kantoren en thuis ook. Werkt prima.

Ik ook, vooral in de ISP / hosting wereld is dat eigenlijk de enige goede optie momenteel wat mij betreft.

De migratie naar single stack IPv6 zodra dat realistisch is wordt dan feitelijk ook niet meer dan IPv4 uitfaseren.

[Dreamvoid]

ik222 schreef op maandag 27 april 2020 @ 12:28:
De migratie naar single stack IPv6 zodra dat realistisch is wordt dan feitelijk ook niet meer dan IPv4 uitfaseren.

Het is wel iets meer werk dan dat - doorgaans rolt men IPv6 in een dual stack LAN uit zonder DNS64/NAT64, dus dat zal je wel nog moeten inrichten.

In de hosting wereld is inderdaad dual stack de 'eindoplossing' aangezien je maar zelden wil dat je server alleen over IPv6 bereikbaar is.

De vraag is eerder, wat is het kostenplaatje / werk effort van IPv6 achteraf te retrofitten in plaats van het mee op te nemen in het initiële design.

Dat niet zozeer, het plan is sowieso om naar IPv6 te gaan. De grootste vraag is of je van single stack IPv4 via een dual stack overgangsperiode naar single stack IPv6 gaat, of de dual stack stap wil overslaan. Allebei is een valide manier om het te doen.

[ Voor 44% gewijzigd door Dreamvoid op 27-04-2020 12:52 ]

[Roetzen]

Dreamvoid schreef op maandag 27 april 2020 @ 12:45:
[...]

Het is wel iets meer werk dan dat - doorgaans rolt men IPv6 in een dual stack LAN uit zonder DNS64/NAT64, dus dat zal je wel nog moeten inrichten.

Niet als je - en ik denk dat ik222 dat bedoelt - direct van Dual Stack naar IPv6 only gaat en zodoende DNS64/NTA64 overslaat.

Dat gaat nog wel even duren natuurlijk...

[Dreamvoid]

IPv6 zonder NAT64 is niet te doen, dan is het complete v4 internet onbereikbaar.

[Roetzen]

Dreamvoid schreef op maandag 27 april 2020 @ 13:46:
IPv6 zonder NAT64 is niet te doen, dan is het complete v4 internet onbereikbaar.

Er komt een tijd dat je "het complete V4 Internet" niet meer nodig hebt. Gaat zoals gezegd nog even duren, maar het gaat gebeuren...

[ Voor 4% gewijzigd door Roetzen op 27-04-2020 13:57 ]

[ik222]

Precies, ik zie geen reden voor de stap DNS64 / NAT64. Ik zou gewoon dualstack aanhouden zolang IPv4 toegang nog relevant is en het daarna uitzetten.

Dualstack hoeft wat mij betreft ook niet meer werk, complex of foutgevoeliger te zijn. Dat kun je voorkomen door goede automatisering in je netwerk.

[Dreamvoid]

NAT64 is geen ‘stap’ in de transitie van je lokale netwerk, het is een service voor remote v4 over IPv6 voor die eenvoudig aan of uit kan of extern kan draaien.

[ Voor 24% gewijzigd door Dreamvoid op 27-04-2020 14:33 ]

[Roetzen]

Dreamvoid schreef op maandag 27 april 2020 @ 14:17:
NAT64 is geen ‘stap’ in de transitie van je lokale netwerk, het is een service voor remote v4 over IPv6 voor die eenvoudig aan of uit kan of extern kan draaien.

Hoe je het noemt, een stap, een optie, een service, het maakt niet zo veel uit. DNS64/NAT64 is iets dat je moet installeren, configureren en onderhouden. Dat overslaan en van Dual Stack direct naar IPv6 single stack gaan door IPv4 geheel uit te schakelen als het niet meer relevant is, is ook een valide optie.

Of dat te verkiezen is boven wat jij optie 3 noemt hangt af van de situatie zou ik zeggen.

[ Voor 7% gewijzigd door Roetzen op 27-04-2020 17:03 ]

[Dreamvoid]

DNS64/NAT64 is iets dat je moet installeren, configureren en onderhouden.

Hangt ervan af of je zelf je DNS en NAT server wilt doen (die heb je IPv4 of dual stack ook draaien, overigens, dat is niet meer werk), je kan ook gewoon de DNS64/NAT64 van je provider of een 3rd party gebruiken, je hoeft dat niet zelf te doen.

De situatie is meer, je kan zonder NAT64 ergens in 2035 ofzo. Waar je nu praktisch gezien in 2020 in je LAN deployment voor kan kiezen, als je IPv6 wilt, is optie 2 (en over 2-3 jaar naar optie 3) of direct optie 3.

Upstream bij de providers transitioneert vrijwel iedereen nu naar "optie 3", met een IPv6-only infrastructuur met IPv4-as-a-service (tunneled naar de edge in de vorm van DS-Lite, translated in de vorm van NAT64) er bovenop.

[ Voor 81% gewijzigd door Dreamvoid op 27-04-2020 17:22 ]

[Roetzen]

Dreamvoid schreef op maandag 27 april 2020 @ 17:04:
De situatie is meer, je kan zonder NAT64 ergens in 2035 ofzo. Waar je nu praktisch gezien in 2020 in je deployment voor kan kiezen, is optie 2 of optie 3.

2035 lijkt me wat pessimistisch. Niet dat ik verwacht dat IPv4 dan al eerder echt helemaal verdwenen zal zijn, maar wel dat er nog maar zo weinig alleen met IPv4 te bereiken is dat het niet meer de moeite waard is daarvoor IPv4 nog in de lucht te houden. Maar ik ben notoir slecht in de toekomst voorspellen.

Upstream transitioneert iedereen nu naar optie 3, met een IPv6-only infrastructuur met IPv4-as-a-service (tunneled in de vorm van DS-Lite, translated in de vorm van NAT64) er bovenop.

Voor "upstream" lijkt met dat een goede keuze. Daar zit je niet met legacy spul. Maar voor "downstream"? Wat heet trouwens legacy? Mijn nog geen drie jaar oude Samsung TV doet alleen IPv4. Terwijl ik nota bene 10 jaar geleden al had gezegd dat ik geen nieuw netwerk spul meer zou kopen dat geen IPv6 ondersteunt, In mijn enthousiasme had ik even oven het hoofd gezien dat een smart TV ook "netwerkspul" is en daar kwam ik te laat achter Voor bij mij thuis is optie 3 dus geen optie, want ik zit nog even met "legacy" spul. Hier draait het lokale netwerk Dual Stack. Al bijna een decennium...

[ Voor 8% gewijzigd door Roetzen op 27-04-2020 17:40 ]

[Dreamvoid]

Bij mij ook En dual stack is leuk om mee te spelen. Maar om eerlijk te zijn, als dit een bedrijfs LAN was, had ik IPv6 waarschijnlijk uitgeschakeld totdat mijn laatste IPv4 device weg was, en was ik daarna single stack IPv6 gegaan.

Ik kan in principe nu single stack gaan (hebt het ook getest), maar ik heb niet de optie om NAT64 op de DSL/router providerbox te draaien, mijn provider doet geen NAT64 voor consumenten, en 3rd party DNS64/NAT64 vertrouw ik niet zo (plus ik heb er een paar geprobeerd, en ineens denken alle geo-locatie algo's dat mijn v4-verkeer uit een ander land komt dan mijn v6 verkeer). Ik moet eigenlijk nog eens testen of ik de DNS server van de mobiele tak van mijn provider kan gebruiken, op hun mobiele netwerk doen ze wel NAT64.

[ Voor 17% gewijzigd door Dreamvoid op 27-04-2020 17:42 ]

[Roetzen]

Dreamvoid schreef op maandag 27 april 2020 @ 17:39:
Bij mij ook En dual stack is leuk om mee te spelen. Maar om eerlijk te zijn, als dit een bedrijfs LAN was, had ik IPv6 waarschijnlijk uitgeschakeld totdat mijn laatste IPv4 device weg was, en was ik daarna single stack IPv6 gegaan.

Ik vraag me af of het met het opkomen van thuiswerken wel haalbaar is om IPv6 op het bedrijf nog zo lang uit te stellen. De thuiswerkers moeten vanuit hun huis toegang kunnen krijgen tot de servers op het bedrijf en dat zal met hun Dual Stack resp.DS-Lite huisaansluitng niet zo;n probleem zijn, maar ook het omgekeerde zal zich dan voordoen. Als ze even op kantoor zijn, zullen ze soms toegang nodig hebben tot iets wat nog bij hen thuis staat. En dat is dan een probleem als ze thuis DS-Lite hebben en op de zaak er alleen IPv4 is...

Ik kan in principe nu single stack gaan (hebt het ook getest), maar ik heb niet de optie om NAT64 op de DSL/router providerbox te draaien,

Hoe precies heb je het getest dan?

mijn provider doet geen NAT64 voor consumenten,

Ik verwacht ook niet dat ze daar aan gaan beginnen. Ze hebben nu al drie configuraties te onderhouden voor consumenten: Ipv4 only, Dual Stack en DS-Lite. Nog één er bij zullen ze echt niet op zitten te wachten. Te meer daar dat dan maar voor een kleine doelgroep zal zijn.

en 3rd party DNS64/NAT64 vertrouw ik niet zo (plus ik heb er een paar geprobeerd, en ineens denken alle geo-locatie algo's dat mijn v4-verkeer uit een ander land komt dan mijn v6 verkeer).

Dat ken ik uit de tijd van minj he.net tunnel. Mijn IPv6 werd meestal in de VS gelokaliseerd, terwijl de tunnel toch echt bij een server in Amsterdam uitkwam...

Ik moet eigenlijk nog eens testen of ik de DNS server van de mobiele tak van mijn provider kan gebruiken, op hun mobiele netwerk doen ze wel NAT64.

Dat zou wel een interessant experiment zijn. Misschien dat je dan ook tegen de nadelen van DNS64/NAT64 aanloopt. Zoals niet werkende DNSSEC en vaste IPv4 adressen...

[Dreamvoid]

Roetzen schreef op dinsdag 28 april 2020 @ 14:15:

Ik vraag me af of het met het opkomen van thuiswerken wel haalbaar is om IPv6 op het bedrijf nog zo lang uit te stellen. De thuiswerkers moeten vanuit hun huis toegang kunnen krijgen tot de servers op het bedrijf en dat zal met hun Dual Stack resp.DS-Lite huisaansluitng niet zo;n probleem zijn, maar ook het omgekeerde zal zich dan voordoen. Als ze even op kantoor zijn, zullen ze soms toegang nodig hebben tot iets wat nog bij hen thuis staat. En dat is dan een probleem als ze thuis DS-Lite hebben en op de zaak er alleen IPv4 is...

Klopt, al weet ik niet hoeveel het voorkomt dat bedrijven het toestaan om vanuit kantoor naar prive netwerken te tunnelen. Ik kreeg in elk geval direct een waarschuwing aan de broek toen ik vorig jaar een remote desktop (Quick Assist) sessie naar mijn zus opende om haar helpen, dat werd direct opgepikt

Hoe precies heb je het getest dan?

Er zijn third party DNS64 en NAT64 servers om te testen. De meesten (zoals de DNS64 servers van Google en Cloudflare) genereren enkel AAAA records voor lokale routing ("well known prefix" oftewel, zij doen de DNS64, maar jij zelf moet NAT64 op je LAN regelen).

Maar sommige DNS64 testservers (ik vond er eentje in New Jersey) genereren DNS64 records met een global routable prefix, en dan gebruik je een NAT64 server buiten je eigen LAN.

Zet het v6 adres van die DNS64 server in je router, dat adres wordt netjes via de RA's verdeeld over je LAN.

Ik heb die NAT64 server natuurlijk liever op mijn eigen router draaien (dan hoeft dat verkeer niet via New Jersey), maar het werkt wel. Da's wel het elegante ervan, je hebt de keuze om de je legacy IPv4 support gewoon helemaal te outsourcen.

Ik verwacht ook niet dat ze daar aan gaan beginnen. Ze hebben nu al drie configuraties te onderhouden voor consumenten: Ipv4 only, Dual Stack en DS-Lite.

Veel providers hebben NAT64 servers al draaien voor hun mobile netwerken. En IPv4-only en dual stack configs gaan er overal uit. We gaan rap naar een wereld waar de hele route tot aan de edge IPv6 is, en de provider ofwel IPv4 verkeer tunnelt naar een NAT44 server ver upstream (DS-Lite), ofwel vertaalt op een NAT64 server even ver upstream.

Dat zou wel een interessant experiment zijn. Misschien dat je dan ook tegen de nadelen van DNS64/NAT64 aanloopt. Zoals niet werkende DNSSEC en vaste IPv4 adressen...

Vaste IPv4 adressen kunnen gewoon met stateless NAT64 natuurlijk (1:1), of een vast IPv4 adres per /48 of /56 prefix, dat is maar hoe je het wil inrichten. Met DS-Lite kan dat ook, overigens. Providers doen het niet, maar niets houdt ze tegen om elke klant zijn eigen publiek v4 adres te geven aan het eind van de tunnel.

DNSSEC issues ben ik nog niet tegenaan gelopen, aangezien de meeste servers die modern genoeg zijn om dat te doen, in de regel ook gewoon een AAAA record hebben. Doordat er anno 2020 al honderden miljoenen users achter NAT64 zitten en dat aantal alleen maar groeit, is het praktisch gezien ook nogal tricky om aan te nemen dat DNSSEC+IPv4 altijd moet werken.

[ Voor 6% gewijzigd door Dreamvoid op 28-04-2020 18:02 ]

[Roetzen]

Dreamvoid schreef op dinsdag 28 april 2020 @ 17:52:
[...]
Klopt, al weet ik niet hoeveel het voorkomt dat bedrijven het toestaan om vanuit kantoor naar prive netwerken te tunnelen. Ik kreeg in elk geval direct een waarschuwing aan de broek toen ik vorig jaar een remote desktop (Quick Assist) sessie naar mijn zus opende om haar helpen, dat werd direct opgepikt

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?

Er zijn third party DNS64 en NAT64 servers om te testen. De meesten (zoals de DNS64 servers van Google en Cloudflare) genereren enkel AAAA records voor lokale routing ("well known prefix" oftewel, zij doen de DNS64, maar jij zelf moet NAT64 op je LAN regelen).

Die van Google had ik al ontdekt. En ook dat je dan zelf de NAT64 moet doen.

Maar sommige DNS64 testservers (ik vond er eentje in New Jersey) genereren DNS64 records met een global routable prefix, en dan gebruik je een NAT64 server buiten je eigen LAN.

Zet het v6 adres van die DNS64 server in je router, dat adres wordt netjes via de RA's verdeeld over je LAN.

Dat had ik nog niet ontdekt

Ik heb die NAT64 server natuurlijk liever op mijn eigen router draaien (dan hoeft dat verkeer niet via New Jersey), maar het werkt wel.

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.

Da's wel het elegante ervan, je hebt de keuze om de je legacy IPv4 support gewoon helemaal te outsourcen.

Dat kan inderdaad een aantrekkelijke optie zijn. Misschien iets voor feste-ip.net om in het gat te springen?

Veel providers hebben NAT64 servers al draaien voor hun mobile netwerken.

Lang niet alle providers hebben een mobiele tak. Of ze hebben alleen maar een zakelijk verband (Vodafone-Ziggo) en zijn de netwerken gescheiden.

En IPv4-only en dual stack configs gaan er overal uit. We gaan rap naar een wereld waar de hele route tot aan de edge IPv6 is, en de provider ofwel IPv4 verkeer tunnelt naar een NAT44 server ver upstream (DS-Lite), ofwel vertaalt op een NAT64 server even ver upstream.

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) maar dual stack zie ik voor SOHO nog niet zo snel verdwijnen. Wie nog een publiek IPv4 adres heeft zal daar niet zo gauw vrijwillig afstand van willen doen. Niet altijd om goede technische redenen, soms speelt emotie ook een rol, maar toch. En voor SOHO is Dual Stack is dan toch de eenvoudigste manier, want dat is er al.

Voor de grote jongens zie ik IPv6 only met aan de rand NAT64 wel als de nabije toekomst.

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

Vaste IPv4 adressen kunnen gewoon met stateless NAT64 natuurlijk (1:1), of een vast IPv4 adres per /48 of /56 prefix, dat is maar hoe je het wil inrichten.

Met DS-Lite kan dat ook, overigens. Providers doen het niet, maar niets houdt ze tegen om elke klant zijn eigen publiek v4 adres te geven aan het eind van de tunnel.

Uiteraard is het technisch mogelijk via een 4in6 tunnel één of meer publieke IPv4 adressen aan de klant te verstrekken. Net als een 6in4 tunnel over een IPv4 only verbinding zoals SixXs dat deed en he.net nog steeds doet. Er zijn zelfs third parties waar je op die manier één of meer publieke IPv4 adressen kunt krijgen. (niet gratis) Maar dat is geen DS-Lite. CGNAT zonder NAT aan de CPE kant is onderdeel van de DS-Lite spec.

Uit RFC6333:

A DS-Lite CPE SHOULD NOT operate a NAT function between an internal
interface and a B4 interface, as the NAT function will be performed
by the AFTR in the service provider's network. This will avoid
accidentally operating in a double-NAT environment.

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

DNSSEC issues ben ik nog niet tegenaan gelopen, aangezien de meeste servers die modern genoeg zijn om dat te doen, in de regel ook gewoon een AAAA record hebben. Doordat er anno 2020 al honderden miljoenen users achter NAT64 zitten en dat aantal alleen maar groeit, is het praktisch gezien ook nogal tricky om aan te nemen dat DNSSEC+IPv4 altijd moet werken.

Daar heb je wel een punt. En aangezien IPv4 toch een aflopende zaak is moet wie DNSSEC wil dan maar snel aan de IPv6 gaan.