Het grote IPv6 topic

[Snow_King]

_fm schreef op dinsdag 18 augustus 2020 @ 21:03:
Heb je nu full dual stack met modem in bridge mode?

Nee, achter mijn Ziggo ConnectBox.

Deze engineer vertelde mij dat Bridge modus en v6 gewoon werkt. Hij verbaasde zich dat Ziggo het niet aan bood. Maar hij werkt ver weg op de achtergrond bij Ziggo. Hij ging het aankaarten, want het zou gewoon moeten kunnen werken.

Mijn sterke vermoeden is dat DHCPv6 leases worden gegeven op basis van het DOCSIS ID en deze veranderd niet als het modem in bridge staat.

_fm schreef op dinsdag 18 augustus 2020 @ 21:03:

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

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

Het is ook lastig. Ik heb het antwoord niet, dat is aan Ziggo zelf. Ik vond het alleen bizar om te horen dat dit het einde was. Succes er mee, wij kunnen niets meer voor je doen. Terwijl ik een niet functionerende verbinding heb.


EDIT: Ik raak net hier in een discussie verzeild: Wim-Bart in "Mesh v.s. Accesspoints"

Dit geeft voor mij ook nog grotendeels aan waar het probleem zit. Mensen die in de IT zitten die nog steeds IPv6 als een gimmick zien en het niet nodig achten. Zo komen we toch nooit vooruit?

[ Voor 10% gewijzigd door Snow_King op 19-08-2020 15:39 ]

[Roetzen]

Snow_King schreef op woensdag 19 augustus 2020 @ 07:49:
[...]

Nee, achter mijn Ziggo ConnectBox.

Deze engineer vertelde mij dat Bridge modus en v6 gewoon werkt. Hij verbaasde zich dat Ziggo het niet aan bood. Maar hij werkt ver weg op de achtergrond bij Ziggo. Hij ging het aankaarten, want het zou gewoon moeten kunnen werken.

Natuurlijk moet het kunnen werken. Het werkt immers voor het duurste bussines abo van Ziggo ook.
Ik weet ook niet waarom Ziggo het niet aanbiedt voor iedereen.

EDIT: Ik raak net hier in een discussie verzeild: Wim-Bart in "Mesh v.s. Accesspoints"

Dit geeft voor mij ook nog grotendeels aan waar het probleem zit. Mensen die in de IT zitten die nog steeds IPv6 als een gimmick zien en het niet nodig achten. Zo komen we toch nooit vooruit?

Ik verbaas mij daar ook een beetje over. Maar aan de andere kant heb je zulke mensen overal, niet alleen in de IT. Ik ben niet zo pessimistisch wat betreft "zo komen we toch nooit vooruit". De praktijk leert dat zulke mensen de vooruitgang toch niet tegen kunnen houden, hooguit wat vertragen. Uiteindelijk worden ze toch wel ingehaald. Herinner je je deze nog:

"We do not need a telephone system, we have an excellent system of messenger boys"

[Djarune]

Snow_King schreef op woensdag 19 augustus 2020 @ 07:49:
EDIT: Ik raak net hier in een discussie verzeild: Wim-Bart in "Mesh v.s. Accesspoints"

Dit geeft voor mij ook nog grotendeels aan waar het probleem zit. Mensen die in de IT zitten die nog steeds IPv6 als een gimmick zien en het niet nodig achten. Zo komen we toch nooit vooruit?

Volgens mij ziet @Wim-Bart IPv6 niet als gimmick. Waarschijnlijk vindt hij dat iedereen allang op IPv6 zou moeten zitten. Net als jij. We moeten tenslotte allemaal over, maar het ligt in mindere mate aan de consument. Het is aan bijvoorbeeld Ziggo om te voorzien dat er een bridgemodus ook met IPv6 werkt. De gemiddelde actieve Tweaker heeft een betere router dan een crappy connectbox waar men niet eens zelf de DNS servers kan wijzigen zonder DHCP uit te zetten. Ze verlenen gelukkig een bridge service via IPv4 en de consument is weer happy.

Bedrijven die wel besluiten over te stappen schoppen vervolgens weer tegen het zere been van de provider en andersom. Krijg je dit soort taferelen. Ik vind dat Ziggo beter z'n best moet doen. IPv6 uitrollen gaat alleen als iedereen meewerkt, maar bedrijven en providers hebben imho meer macht dan de consument in deze. Die betalen immers al (in mijn ogen teveel) voor Ziggo's service.

[Wim-Bart]

Djarune schreef op maandag 7 september 2020 @ 20:33:
[...]


Volgens mij ziet @Wim-Bart IPv6 niet als gimmick. Waarschijnlijk vindt hij dat iedereen allang op IPv6 zou moeten zitten. Net als jij. We moeten tenslotte allemaal over, maar het ligt in mindere mate aan de consument. Het is aan bijvoorbeeld Ziggo om te voorzien dat er een bridgemodus ook met IPv6 werkt. De gemiddelde actieve Tweaker heeft een betere router dan een crappy connectbox waar men niet eens zelf de DNS servers kan wijzigen zonder DHCP uit te zetten. Ze verlenen gelukkig een bridge service via IPv4 en de consument is weer happy.

Bedrijven die wel besluiten over te stappen schoppen vervolgens weer tegen het zere been van de provider en andersom. Krijg je dit soort taferelen. Ik vind dat Ziggo beter z'n best moet doen. IPv6 uitrollen gaat alleen als iedereen meewerkt, maar bedrijven en providers hebben imho meer macht dan de consument in deze. Die betalen immers al (in mijn ogen teveel) voor Ziggo's service.

Klopt helemaal, maar jaren zie ik dat adoptie van IPv6 totaal niet aan de orde is en daar baal ik van. Heb min of meer ook de hoop opgegeven. Aan de andere kant zie ik voor interne netwerken ook niet echt noodzaak zolang de 10.0.0.0/8 en 192.168.0.0/16 voldoende ruimte bieden.

[Bigs]

Ik ben zelf jaren lang actief geweest om alles in mijn omgeving op IPv6 over te krijgen. Maar dan verschuift de industrie ineens naar Kubernetes waar IPv6 nog alpha is en door de belangrijkste network overlays niet eens wordt ondersteund. Erg verrassend gezien de oorsprong van Kubernetes.

Gevolg is dat applicaties die ik op Kubernetes draai alleen via IPv4 te bereiken zijn.. maarja daar heeft dus echt nog niemand over geklaagd

[Snow_King]

Wim-Bart schreef op dinsdag 8 september 2020 @ 00:25:
[...]

Klopt helemaal, maar jaren zie ik dat adoptie van IPv6 totaal niet aan de orde is en daar baal ik van. Heb min of meer ook de hoop opgegeven. Aan de andere kant zie ik voor interne netwerken ook niet echt noodzaak zolang de 10.0.0.0/8 en 192.168.0.0/16 voldoende ruimte bieden.

Leuk dat je in je LAN die RFC1918 adressen hebt, maar wat heeft dat met IPv6 te maken?

Een node in je LAN moet toch gewoon een connectie met het internet hebben over IPv6? Dat je eindeloos tot in de tijd met RFC1918 blijft praten binnen je LAN is prima.

Het gaat er juist om dat we devices via v6 online het internet op krijgen. Het internet weer Peer-to-Peer kunnen maken zonder allemaal moeilijke dingen waar we om (CG)NAT heen aan het werken zijn.

Zo kan mijn Alarm Systeem thuis niet communiceren met het systeem van de meldkamer omdat poortje 33xxx geforward moet zijn naar dat systeem (Upnp), maar ik heb thuis CGNAT van Ziggo.

Bigs schreef op dinsdag 8 september 2020 @ 09:56:
Ik ben zelf jaren lang actief geweest om alles in mijn omgeving op IPv6 over te krijgen. Maar dan verschuift de industrie ineens naar Kubernetes waar IPv6 nog alpha is en door de belangrijkste network overlays niet eens wordt ondersteund. Erg verrassend gezien de oorsprong van Kubernetes.

Gevolg is dat applicaties die ik op Kubernetes draai alleen via IPv4 te bereiken zijn.. maarja daar heeft dus echt nog niemand over geklaagd

Wat dat betreft lijkt Google wat misstappen te maken. Ook bij GCP mist v6 nog op diverse plekken.

[CAPSLOCK2000]

Wim-Bart schreef op dinsdag 8 september 2020 @ 00:25:
Aan de andere kant zie ik voor interne netwerken ook niet echt noodzaak zolang de 10.0.0.0/8 en 192.168.0.0/16 voldoende ruimte bieden.

Zodra je een VPN nodig hebt wordt het een groot probleem. Die 10/8 en 192.168/16 ranges worden overal gebruikt. Je moet niet de pech hebben dat je werkgever dezelfde range gebruikt als je kabelmodem. (Heb ik geen last van, maar het had gekunt).
Mijn werkgever heeft VPN-verbindingen met tal van partners en die willen ook allemaal gebruik maken van die ranges, en de meesten lijken dan te kiezen voor dezelfde mooie ranges (.0. of .1. of .100) als iedereen. Met onze servers er tussen in die maar moeten weten wanneer ze het ene netwerk nodig hebben en wanneer het andere.

Bij een eerdere werkgever was het zelfs nodig dat twee systemen met elkaar zouden praten terwijl die systemen in verschillende netwerken zaten (bij partners) die dezelfde IP-range gebruikte. Dat was een feest voor liefhebbers van NAT....


Voor IPv6 zijn (ouderwetse) VPNs een drama. Mijn werkgever biedt een VPN aan dat alleen IPv4 ondersteunt. Maar mijn computer geeft de voorkeur aan IPv6 en stuurt een deel van het verkeer dus buiten de tunnel om en dan werkt het niet. Nu ben ik technisch genoeg om zelf m'n DNS en routes te kunnen beinvloeden om het gewenste resultaat te krijgen, maar voor gewone mensen is dat niet te doen.

[ Voor 9% gewijzigd door CAPSLOCK2000 op 08-09-2020 15:29 ]

[Wim-Bart]

Snow_King schreef op dinsdag 8 september 2020 @ 10:48:
[...]

Leuk dat je in je LAN die RFC1918 adressen hebt, maar wat heeft dat met IPv6 te maken?

Een node in je LAN moet toch gewoon een connectie met het internet hebben over IPv6? Dat je eindeloos tot in de tijd met RFC1918 blijft praten binnen je LAN is prima.

Het gaat er juist om dat we devices via v6 online het internet op krijgen. Het internet weer Peer-to-Peer kunnen maken zonder allemaal moeilijke dingen waar we om (CG)NAT heen aan het werken zijn.

Zo kan mijn Alarm Systeem thuis niet communiceren met het systeem van de meldkamer omdat poortje 33xxx geforward moet zijn naar dat systeem (Upnp), maar ik heb thuis CGNAT van Ziggo.


[...]

Wat dat betreft lijkt Google wat misstappen te maken. Ook bij GCP mist v6 nog op diverse plekken.

Het meest mooie is om gewoon IPv4 dood te verklaren en dat grote bedrijven zoals Facebook, Google, Amazon, Microsoft zeggen, we zijn alleen nog via IPv6 te benaderen. Dan moeten er stappen worden ondernomen. Maar ook dan zal je IPv6 over IPv4 zien of andere constructies om bestaande IPv4 netwerken te koppelen. En dat gaat nooit gebeuren. En zolang IPv6 geen noodzaak is, dan vraag ik mij af wanneer IPv6 de standaard wordt en IPv4 de uitzondering.

Ik weet dat ooit XS4All IPv6 uitrolde in plaats van IPv4. Maar wilde je port forwarding, dan werd dat omgezet naar IPv4. Daarna heb ik er nooit meer wat van gehoord.

Wat ik begrijp is dat jij dus met een CGN/LSN zit omdat Ziggo geen IPv4 adressen meer heeft voor jouw regio. Dan vraag ik mij af hoe je dan zoals ik een server thuis kan draaien? En wat zegt Ziggo wanneer je aangeeft dat CGN het probleem is van jouw issues.

[Wim-Bart]

CAPSLOCK2000 schreef op dinsdag 8 september 2020 @ 15:26:
[...]


Zodra je een VPN nodig hebt wordt het een groot probleem. Die 10/8 en 192.168/16 ranges worden overal gebruikt. Je moet niet de pech hebben dat je werkgever dezelfde range gebruikt als je kabelmodem. (Heb ik geen last van, maar het had gekunt).
Mijn werkgever heeft VPN-verbindingen met tal van partners en die willen ook allemaal gebruik maken van die ranges, en de meesten lijken dan te kiezen voor dezelfde mooie ranges (.0. of .1. of .100) als iedereen. Met onze servers er tussen in die maar moeten weten wanneer ze het ene netwerk nodig hebben en wanneer het andere.

Bij een eerdere werkgever was het zelfs nodig dat twee systemen met elkaar zouden praten terwijl die systemen in verschillende netwerken zaten (bij partners) die dezelfde IP-range gebruikte. Dat was een feest voor liefhebbers van NAT....


Voor IPv6 zijn (ouderwetse) VPNs een drama. Mijn werkgever biedt een VPN aan dat alleen IPv4 ondersteunt. Maar mijn computer geeft de voorkeur aan IPv6 en stuurt een deel van het verkeer dus buiten de tunnel om en dan werkt het niet. Nu ben ik technisch genoeg om zelf m'n DNS en routes te kunnen beinvloeden om het gewenste resultaat te krijgen, maar voor gewone mensen is dat niet te doen.

Oplossing is simpel, je termineert alles op een Virtual Server aan de buitenkant in Public IP space en gaat aan de binnenkant door. Ik heb de laatste jaren nog nooit issues gehad met VPN's die conflicteren. En ik durf te stellen, wanneer je via VPN naar bedrijf A gaat en op Netwerk door kan hoppen via de VPN van bedrijf A naar bedrijf B dat je dan een serieus security issue hebt.

[downtime]

Wim-Bart schreef op woensdag 9 september 2020 @ 02:06:
[...]


Ik weet dat ooit XS4All IPv6 uitrolde in plaats van IPv4. Maar wilde je port forwarding, dan werd dat omgezet naar IPv4. Daarna heb ik er nooit meer wat van gehoord.

Ik geloof niet dat XS4ALL ooit IPv6 in plaats van IPv4 uitgerold heeft. Was gewoon dual stack. Ik heb indertijd aan hun IPv6 pilot meegedaan (in 2012 ofzo?) en heb nog steeds IPv6.

[Snow_King]

Zie: nieuws: Smarthomestandaard van Apple, Google en Amazon ligt op koers voor rel...

Daarna: https://github.com/project-chip/connectedhomeip

En dan dus dit plaatje:



IPv6!

[Dreamvoid]

Wim-Bart schreef op woensdag 9 september 2020 @ 02:06:
Het meest mooie is om gewoon IPv4 dood te verklaren en dat grote bedrijven zoals Facebook, Google, Amazon, Microsoft zeggen, we zijn alleen nog via IPv6 te benaderen. Dan moeten er stappen worden ondernomen. Maar ook dan zal je IPv6 over IPv4 zien of andere constructies om bestaande IPv4 netwerken te koppelen. En dat gaat nooit gebeuren. En zolang IPv6 geen noodzaak is, dan vraag ik mij af wanneer IPv6 de standaard wordt en IPv4 de uitzondering.

Er komt geen "big bang", het is gewoon een langzaam, en saai, migratieproces.

Als je kijkt naar hoe de IPv6 deployment bij de eindgebruikers gaat, dat gaat min of meer linear omhoog, van 5% in eind-2014 naar 15% in 2016 naar 25% in 2018 naar ws 35% in 2020. Aan de hosting kant, het % van de top 25000 websites dat IPv6 doet groeit vergelijkbaar mee, die zitten tegen het eind van dit jaar ook op circa 30%.

Wat er nu in de praktijk in ISP land gebeurt is dat niemand veel zin heeft om twee parallele routing stacks te blijven managen, en men dus in eveneens gestaag tempo de ene na de andere ISP de interne routing omgooit van IPv4 (met evt IPv6 eroverheen getunneld, zoals 6rd bv) naar IPv6 met IPv4-as-a-Service eroverheen. IPv4 wordt op die manier meer en meer een situatie van eilandjes, zowel bij de klanten (achter DS-Lite, 4rd, 464XLAT), en bij de hosting klanten (achter IPv4 CDN's/proxies). Eindgebruikers aan beide kanten merken er niks van.

[Snow_King]

Wim-Bart schreef op woensdag 9 september 2020 @ 02:06:
[...]

Ik weet dat ooit XS4All IPv6 uitrolde in plaats van IPv4. Maar wilde je port forwarding, dan werd dat omgezet naar IPv4. Daarna heb ik er nooit meer wat van gehoord.

Wat ik begrijp is dat jij dus met een CGN/LSN zit omdat Ziggo geen IPv4 adressen meer heeft voor jouw regio. Dan vraag ik mij af hoe je dan zoals ik een server thuis kan draaien? En wat zegt Ziggo wanneer je aangeeft dat CGN het probleem is van jouw issues.

Ik draai thuis zeker wel een server met wat VM's. Allemaal IPv6-only. Wanneer ik er vanaf buiten bij moet gaat de VPN aan (die ik op een VM in een datacenter draai met IPv6).

Werkt prima :-)

Wim-Bart schreef op woensdag 9 september 2020 @ 02:10:
[...]

Oplossing is simpel, je termineert alles op een Virtual Server aan de buitenkant in Public IP space en gaat aan de binnenkant door. Ik heb de laatste jaren nog nooit issues gehad met VPN's die conflicteren. En ik durf te stellen, wanneer je via VPN naar bedrijf A gaat en op Netwerk door kan hoppen via de VPN van bedrijf A naar bedrijf B dat je dan een serieus security issue hebt.

Zakelijk hebben wij ook een VPN. Deze OpenVPN server pushed een paar IPv4 routes, maar vooral IPv6 routes. Al het beheer doen wij over IPv6. De DNS entries zijn world-readable, maar afhankelijk van of je vanaf het juiste IP komt (Lees: VPN staat open) mag je wel of niet bij die systemen.

ip6tables, ACL's in routers, diverse dingen die we gebruiken om het boze internet weg te houden.

Geen gedoe met NAT, heel makkelijk alles beheren.

[ANdrode]

Wim-Bart schreef op woensdag 9 september 2020 @ 02:06:
[...]
Het meest mooie is om gewoon IPv4 dood te verklaren en dat grote bedrijven zoals Facebook, Google, Amazon, Microsoft zeggen, we zijn alleen nog via IPv6 te benaderen. Dan moeten er stappen worden ondernomen. Maar ook dan zal je IPv6 over IPv4 zien of andere constructies om bestaande IPv4 netwerken te koppelen. En dat gaat nooit gebeuren. En zolang IPv6 geen noodzaak is, dan vraag ik mij af wanneer IPv6 de standaard wordt en IPv4 de uitzondering.

Daar zitten Amazon innovatie juist in de weg. Bij AWS is het op dit moment praktisch onmogelijk om je diensten op een moderne manier bereikbaar te maken. Ze hebben teveel IPv4 only diensten.

De enige manier om dat voor AWS belangrijk te maken is om het mee te nemen bij vendor selectie. Ik denk dat alleen overheden (en een beperkt aantal andere partijen) dat zouden doen.

Ik weet dat ooit XS4All IPv6 uitrolde in plaats van IPv4. Maar wilde je port forwarding, dan werd dat omgezet naar IPv4. Daarna heb ik er nooit meer wat van gehoord.

Dat is de aanpak (DSLite) die Ziggo nog steeds doet.

[Wim-Bart]

ANdrode schreef op woensdag 9 september 2020 @ 18:45:
[...]


Daar zitten Amazon innovatie juist in de weg. Bij AWS is het op dit moment praktisch onmogelijk om je diensten op een moderne manier bereikbaar te maken. Ze hebben teveel IPv4 only diensten.

De enige manier om dat voor AWS belangrijk te maken is om het mee te nemen bij vendor selectie. Ik denk dat alleen overheden (en een beperkt aantal andere partijen) dat zouden doen.


[...]


Dat is de aanpak (DSLite) die Ziggo nog steeds doet.

Gisteren contact gehad met Ziggo of het mogelijk is om IPv6 te gebruiken naast mijn IPv4. Mijn Orbi ondersteund het, maar was niet mogelijk. Jammer eigenlijk.

[Snake]

Ik draai thuis al een hele tijd IPv6, maar heb een aantal problemen.

IPv6 met prefix delegation op /56 is geen probleem, werkt perfect.

Maar, dan zit ik met een adres dat intern wordt uitgedeelt waar ik niet weet wat bit 56 tot 64 zijn, en de router nam deze random.

Gevolg, om de zoveel tijd ander IPv6 adres.

Dan dat ding op /64 gezet, en dan blijft de boel redelijk statisch, buiten het feit dat mijn provider om de zoveel tijd mijn prefix veranderd.

Om dat op te lossen heb ik een custom startup script geschreven in DD-WRT, wat een 2de set van IP addressen uitdeelt met DNSMASQ, namelijk in de fc00::/7 range.

Dit werkt perfect, buiten het feit dat ik van DD-WRT afwil.

Nu ben ik verhuist en woon in een gebied met een andere provider.

2 vragen:

1) wat is een goede router waarmee ik gemakkelijker dit kan configureren? ER-X lijkt me leuk, maar dan moet ik weer een AP erbij kopen. Een AIO zou leuk zijn.
2) Is er een service die ik kan pingen van mijn machine die mijn IP address opslaat? Zodat ik kan volgen over time wat het is?

[Brahiewahiewa]

Snake schreef op woensdag 9 september 2020 @ 23:33:
...
2) Is er een service die ik kan pingen van mijn machine die mijn IP address opslaat? Zodat ik kan volgen over time wat het is?

Ja, dat heet dynamic DNS

[Snow_King]

Snake schreef op woensdag 9 september 2020 @ 23:33:
Ik draai thuis al een hele tijd IPv6, maar heb een aantal problemen.

IPv6 met prefix delegation op /56 is geen probleem, werkt perfect.

Maar, dan zit ik met een adres dat intern wordt uitgedeelt waar ik niet weet wat bit 56 tot 64 zijn, en de router nam deze random.

Gevolg, om de zoveel tijd ander IPv6 adres.

Dan dat ding op /64 gezet, en dan blijft de boel redelijk statisch, buiten het feit dat mijn provider om de zoveel tijd mijn prefix veranderd.

Welke ISP heb je?

[Dreamvoid]

Brahiewahiewa schreef op donderdag 10 september 2020 @ 03:57:
[...]

Ja, dat heet dynamic DNS

Los daarvan, als je een OneDrive/GoogleDrive/DropBox/iCloud/etc synced folder hebt op die server, kan je ook een simpel scriptje schedulen dat elk uur je IPv4 en IPv6 adres dumpt in een mijn_ip_adressen.txt bestandje.

[Snake]

Brahiewahiewa schreef op donderdag 10 september 2020 @ 03:57:
[...]

Ja, dat heet dynamic DNS

Dan krijg ik nog geen mail als het IP is veranderd!

Snow_King schreef op donderdag 10 september 2020 @ 09:05:
[...]

Welke ISP heb je?

(Ik woon in California)
Spectrum

Dreamvoid schreef op donderdag 10 september 2020 @ 17:39:
[...]

Los daarvan, als je een OneDrive/GoogleDrive/DropBox/iCloud/etc synced folder hebt op die server, kan je ook een simpel scriptje schedulen dat elk uur je IPv4 en IPv6 adres dumpt in een mijn_ip_adressen.txt bestandje.

Dan moet ik er nog manueel doorgaan!

[Dreamvoid]

Snake schreef op donderdag 10 september 2020 @ 17:51:
[...]
Dan krijg ik nog geen mail als het IP is veranderd!

OK, er moet toch wel een niet al te complex scriptje te schrijven zijn die de het IPv6 adres periodiek checkt en bij een verandering een mailtje uitstuurt?

Maar waarom moet het per se een raw IPv6 adres zijn, en is DNS niet goed genoeg?

[ Voor 11% gewijzigd door Dreamvoid op 10-09-2020 18:12 ]

[Snake]

Dreamvoid schreef op donderdag 10 september 2020 @ 18:01:
[...]

OK, er moet toch wel een niet al te complex scriptje te schrijven zijn die de het IPv6 adres periodiek checkt en bij een verandering een mailtje uitstuurt?

Maar waarom moet het per se een raw IPv6 adres zijn, en is DNS niet goed genoeg?

Het is ter validatie dat mijn IP niet veranderd.

Intern deelt de IPv6 announcer het IP adres van de DNS uit.

[Brahiewahiewa]

Snake schreef op donderdag 10 september 2020 @ 21:00:
[...]

Het is ter validatie dat mijn IP niet veranderd.

Intern deelt de IPv6 announcer het IP adres van de DNS uit.

Daarom moet je dus een publieke dyndns provider gebruiken, dan connect je op host name en kun je de lokaal opgeslagen ipv6 historie bekijken

[Snake]

Brahiewahiewa schreef op donderdag 10 september 2020 @ 23:16:
[...]

Daarom moet je dus een publieke dyndns provider gebruiken, dan connect je op host name en kun je de lokaal opgeslagen ipv6 historie bekijken

Dat snap ik niet?

Ik heb een pi-hole met een ipv6 adres, en ik wil dat adres uitdelen aan mijn netwerk.

Probleem is als dat ip adres veranderd. Hoe moet ik mijn clients dyndns uitdelen?

[Brahiewahiewa]

Snake schreef op vrijdag 11 september 2020 @ 00:06:
[...]

Dat snap ik niet?

Ik heb een pi-hole met een ipv6 adres, en ik wil dat adres uitdelen aan mijn netwerk.

Probleem is als dat ip adres veranderd. Hoe moet ik mijn clients dyndns uitdelen?

Doet de pihole dat niet op basis van het delegated ipv6 address?
Dan moet je misschien even een bug report filen bij pihole

[Dreamvoid]

Volgens mij worden in deze discussie prefixes en adressen verward...

[Brahiewahiewa]

Dreamvoid schreef op vrijdag 11 september 2020 @ 19:16:
Volgens mij worden in deze discussie prefixes en adressen verward...

Hmmz, in principe is adres = prefix + suffix; als de prefix verandert, heb je een ander adres
Bovendien zou het maar zo kunnen zijn dat als je dhcp server een nieuwe prefix krijgt, hij ook nieuwe suffixes gaat uitdelen

[linkforsoad]

Toevallig mensen hier ervaring met IPv6 bij Plinq/Compenz? Een van onze locaties ligt in een wijk waar het CAI-netwerk nog steeds van een lokale stichting is. Men is nu glas (GPON) aan het leggen, waar Plinq beheerder en aanbieder op is. Het woord IPv6 lijkt daar nog totaal onbekend, en men lijkt uberhaupt niet eens te beschikken over adresruimte: https://bgp.he.net/net/45.93.40.0/22

Ik ben de laatste jaren zelf voornamelijk over de grens en ben alleen nog beperkt bekend met KPN WBA. Wat is wijsheid, vragen of men als LIR kan zorgen voor IPv6 PI? Omdat er altijd XS4ALL-lijnen gebruikt worden zijn allerlei eigen omgevingen uberhaupt niet of beperkt bereikbaar gemaakt over IPv4, uit gemakzucht en gebrek aan noodzaak. Op deze locatie is wel een XS4ALL DSL-lijn aanwezig, maar de kwaliteit is na vele werkzaamheden nog steeds niet spetterend. Vandaar de wens om DSL hier juist als backup-lijn in te zetten.

[Brahiewahiewa]

linkforsoad schreef op vrijdag 18 september 2020 @ 16:32:
Toevallig ...

Als zo'n partij nu nog moet beginnen met nadenken over ipv6 duurt 't waarschijnlijk jaren voordat het geïmplementeerd is. Het makkelijkste is denk ik als je een tunnel opzet; dat kan via he.net, via een VPS of via één van jouw locaties waar nog wel ip4 aanwezig is

[linkforsoad]

Daar ben ik idd ook erg bang voor, maar wilde het toch hier nog eens opperen voordat we de tunnel-horror-route volgen, dat wordt uiteindelijk vaak toch hoofdpijn. Maar duidelijke taal, dank.

[ANdrode]

Bigs schreef op dinsdag 8 september 2020 @ 09:56:
Ik ben zelf jaren lang actief geweest om alles in mijn omgeving op IPv6 over te krijgen. Maar dan verschuift de industrie ineens naar Kubernetes waar IPv6 nog alpha is en door de belangrijkste network overlays niet eens wordt ondersteund. Erg verrassend gezien de oorsprong van Kubernetes.

Gevolg is dat applicaties die ik op Kubernetes draai alleen via IPv4 te bereiken zijn.. maarja daar heeft dus echt nog niemand over geklaagd

Extern is je loadbalancer echter wel dual stack.

En gebruik je AWS? Tja, AWS is gewoon technisch een matige dienst dan heb je inderdaad geen IPv6 bij non-http loadbalancer...

[linkforsoad]

Brahiewahiewa schreef op zondag 20 september 2020 @ 01:22:
[...]

duurt 't waarschijnlijk jaren voordat het geïmplementeerd is.

Vandaag een monteur gehad, omdat men die per sé mee wilde sturen vanwege ONT en activatie/provisioning daarvan. Krijg slecht contact en antwoord op tickets, dus bij configuratie van eigen router de monteur maar voor het blok gezet 'En de prefix length voor IPv6 dhcp client is...?'. Op die manier kunnen escaleren en men belt waarschijnlijk morgen terug, ving al op dat de engineer die ik even aan de lijn had toch wat mogelijkheden zag. Hoop het van harte

[ijske]

goeiedag, ik ben op zoek naar wat hulp...
ik heb hier thuis de mooiste en beste Telenet modem (de 8560E) welke de opvolger is van wat jullie de ziggo connectbox noemen.. jaaa docsis 3.1 , ik heb het al

nu heeft die de superfunctie van "mac bridging", waarbij ik 1 apparaat dus een extern ip kan laten toekennen (moet je je mac adres opgeven in de servicepagina vd provider en dan krijgt die een extern ipv4)
nu , dat ipv4 werkt in combinatie met mijn cisco rv340 helemaal prima

maar dat IPV6 krijg ik niet aan de praat...
ik heb een IPv6 subnet gekregen van mn provider , volgens mij zelfs een behoorlijk groot subnet
namelijk :

LAN-subnet IPv6 2a02:1810:****:8700:0000:0000:0000:0000/64

de kabelmodem heeft een dan zelf ook een ipv6'je weggesnoept :
IP-adres (IPv6) 2a02:****:1:****:6540:7dac:cf91:4461 (niet in mijn range, ik vermoed dat telenet dit gebruikt om mijn modemstatistieken uit te lezen)

en volgens mij mag ik zelf een subnetje nog verder verdelen naar mn eigen zin
Prefix (IPv6) 2a02:1810:****:8700::/56

ik zie op mijn cisco rv340 dan ook wel netjes IPv6 binnenkomen als SLAAC connectie en die is up. zowel local link als een IP adres in mijn reeksje
helaas ben ik daar een beetje de weg kwijt..
ik heb bij de wan connectie het type op SLAAC laten staan, en DHCP-PD opgezet, zodat hij weet dat hij dit mag verder verdelen ?

bij LAN heb ik op mn test vlan IPV6 geactiveerd, met "prefix from DHCP-PD(WAN1)"
(daar staat dan gelijk "unavailable" bij
prefix length /56 (zodat ie de grootte vh subnet kent neem ik aan)
interface identiefier EUI-64,
DHCP type : server
dan wat ranges en DNS FROM ISP

raar, maar ik krijg dus zelfs geen DNS toegewezen op IPv6, terwijl ik wel de ipv6 dhcp ben van het vlan.
ook gechecked bij acces list en er is maar 1 ipv6 rule, en dat is dat alles mag..

dus ik mis hier vast iets...
thx alvast

[Brahiewahiewa]

ijske schreef op zaterdag 3 oktober 2020 @ 00:22:
goeiedag, ik ben op zoek naar wat hulp...
... een behoorlijk groot subnet namelijk :

LAN-subnet IPv6 2a02:1810:****:8700:0000:0000:0000:0000/64
...

en volgens mij mag ik zelf een subnetje nog verder verdelen naar mn eigen zin
Prefix (IPv6) 2a02:1810:****:8700::/56

Je ziet het verkeerd om: je kunt een /64 niet verdelen in meerdere /56's.
je kunt wel een /56 verdelen in meerdere /64's
Bij subnets geldt dat een lager getal een groter subnet aangeeft

[overhyped]

Een /64 is erg minimaal, in de ipv6 wereld is dat erg karig en geeft aan dat jouw isp de gedachte achter ipv6 niet snapt. Een /64 is precies genoeg om aan 1 enkel subnet te geven. Kleinere netwerken horen in ipv6 niet te bestaan, zelfs voor een point to point link reserveer je een /64.

Officieus is afgesproken om grotere subnetten aan iedere gebruiker te geven zodat je altijd genoeg hebt. Denk aan een netwerk coke intern, voor IOT, voor gasten, etc.

De /56 die je daarna noemt is al normaler om aan een particuliere klant te geven.

Verder: als je voor het eerst met V6 bezig gaat: allereerst welkom een leuke wereld gaat voor je open. Ten tweede: probleer los te laten wat je uit de legacy IP wereld weet. Schaarste: bestaat niet meer. Kleine subnetjes om adressen tr besparen: verleden tijd. Statische adressen? Waarom bestaat (dynamisch) dns. DHCP heeft andere rol, etc etc. Erg leuk, maar besef je dat de wereld anders is

ijske schreef op zaterdag 3 oktober 2020 @ 00:22:
goeiedag, ik ben op zoek naar wat hulp...
ik heb hier thuis de mooiste en beste Telenet modem (de 8560E) welke de opvolger is van wat jullie de ziggo connectbox noemen.. jaaa docsis 3.1 , ik heb het al

nu heeft die de superfunctie van "mac bridging", waarbij ik 1 apparaat dus een extern ip kan laten toekennen (moet je je mac adres opgeven in de servicepagina vd provider en dan krijgt die een extern ipv4)
nu , dat ipv4 werkt in combinatie met mijn cisco rv340 helemaal prima

maar dat IPV6 krijg ik niet aan de praat...
ik heb een IPv6 subnet gekregen van mn provider , volgens mij zelfs een behoorlijk groot subnet
namelijk :

LAN-subnet IPv6 2a02:1810:****:8700:0000:0000:0000:0000/64

de kabelmodem heeft een dan zelf ook een ipv6'je weggesnoept :
IP-adres (IPv6) 2a02:****:1:****:6540:7dac:cf91:4461 (niet in mijn range, ik vermoed dat telenet dit gebruikt om mijn modemstatistieken uit te lezen)

en volgens mij mag ik zelf een subnetje nog verder verdelen naar mn eigen zin
Prefix (IPv6) 2a02:1810:****:8700::/56

ik zie op mijn cisco rv340 dan ook wel netjes IPv6 binnenkomen als SLAAC connectie en die is up. zowel local link als een IP adres in mijn reeksje
helaas ben ik daar een beetje de weg kwijt..
ik heb bij de wan connectie het type op SLAAC laten staan, en DHCP-PD opgezet, zodat hij weet dat hij dit mag verder verdelen ?

bij LAN heb ik op mn test vlan IPV6 geactiveerd, met "prefix from DHCP-PD(WAN1)"
(daar staat dan gelijk "unavailable" bij
prefix length /56 (zodat ie de grootte vh subnet kent neem ik aan)
interface identiefier EUI-64,
DHCP type : server
dan wat ranges en DNS FROM ISP

raar, maar ik krijg dus zelfs geen DNS toegewezen op IPv6, terwijl ik wel de ipv6 dhcp ben van het vlan.
ook gechecked bij acces list en er is maar 1 ipv6 rule, en dat is dat alles mag..

dus ik mis hier vast iets...
thx alvast

[Raven]

overhyped schreef op zaterdag 3 oktober 2020 @ 09:06:
Een /64 is erg minimaal, in de ipv6 wereld is dat erg karig en geeft aan dat jouw isp de gedachte achter ipv6 niet snapt.

Mijn provider voor IPv6 (HE) bied standaard een /64 aan, maar op verzoek een /48, maar ik heb nog niet terug kunnen vinden in hoeverre het opzetten van de tunnel aangepast moet worden Het aanpassen van de radvd config kom ik wel uit, na een subnetcalculator gebruikt te hebben

Heeft iemand daar toevallig al ervaring mee?

[ijske]

@overhyped & @Brahiewahiewa thx alvast

kan het dan zijn dat ik het verkeerd interpreteer , dat ik een /56 subnet heb toegewezen gekregen, en dat mijn modem op lan kant de /64 heeft gekregen ?
dat zou inderdaad wel erg logisch lijken , doch krijg ik het precies niet voor elkaar ze verder te verdelen in mijn router

ik kreeg het idee dat in dat SLAAC protocol de nodige info zou bijzitten welke ip's hij verder mag verdelen/routeren ..

[ Voor 15% gewijzigd door ijske op 03-10-2020 13:14 ]

[Hipska]

@Raven HE biedt standaard een /56 aan. Op verzoek idd een /48

[Vorkie]

Hipska schreef op zaterdag 3 oktober 2020 @ 13:31:
@Raven HE biedt standaard een /56 aan. Op verzoek idd een /48

Nadeel van HE is het gedoe om Netflix werkend te krijgen

@Raven
En als antwoord, het verkeer van je /48 wordt naar je router gestuurd, dus als jij een subnet aanmaakt uit de /48 zal de ::/0 gebruikt worden op je router (naar HeNET).

De weg terug is weer geregeld aan HeNET zijde. (en intern is het weer allemaal afgemonteerd op je eigen router/firewall)

[linkforsoad]

Hipska schreef op zaterdag 3 oktober 2020 @ 13:31:
@Raven HE biedt standaard een /56 aan. Op verzoek idd een /48

Zeker ?

[Brahiewahiewa]

linkforsoad schreef op zaterdag 3 oktober 2020 @ 13:45:
[...]

Zeker ?
[Afbeelding]

Vrij zeker, idd. Om de /48 te krijgen, moet je op assign /48 klikken. Het feit dat die hyperlink er nog staat, betekent dat je er nog niet op geklikt hebt

[linkforsoad]

Brahiewahiewa schreef op zaterdag 3 oktober 2020 @ 14:48:
[...]

Vrij zeker, idd. Om de /48 te krijgen, moet je op assign /48 klikken. Het feit dat die hyperlink er nog staat, betekent dat je er nog niet op geklikt hebt

Het ging mij om die /56 of /64 standaard.

[Brahiewahiewa]

linkforsoad schreef op zaterdag 3 oktober 2020 @ 14:48:
[...]

Het ging mij om die /56 of /64 standaard.

Je hebt nu een /56 en vooralsnog gebruik je waarschijnlijk één /64 maar je kunt er meerdere gebruiken middels prefix delegation

[linkforsoad]

Brahiewahiewa schreef op zaterdag 3 oktober 2020 @ 14:51:
[...]

Je hebt nu een /56 en vooralsnog gebruik je waarschijnlijk één /64 maar je kunt er meerdere gebruiken middels prefix delegation

Ik doe vrij weinig met HE's Tunnelbroker, maar weet niet beter dan dat je standaard een enkele /64 krijgt, en middels de knop in de tunnelinfo idd een /48 kunt bijvragen. Raven geeft aan dat er standaard een /56 wordt gegeven, wat ik zo snel nergens terug kan vinden bij HE. Vandaar de vraag of hij daar zeker van was.

[Brahiewahiewa]

linkforsoad schreef op zaterdag 3 oktober 2020 @ 14:54:
[...]

Ik doe vrij weinig met HE's Tunnelbroker, maar weet niet beter dan dat je standaard een enkele /64 krijgt, en middels de knop in de tunnelinfo idd een /48 kunt bijvragen. Raven geeft aan dat er standaard een /56 wordt gerouteerd, wat ik zo snel nergens terug kan vinden bij HE. Vandaar de vraag of hij daar zeker van was.

Om een standaard /64 te kunnen routeren heb je een /56 nodig.
Kijk FF in de kursus die HE aanbiedt, daar wordt dat allemaal keurig uitgelegd

[linkforsoad]

Ah okay, helder, dank. Heb die ooit wel doorlopen kort na het aanmaken van het account in 2011. Er is niet heel veel van blijven hangen, ben er weinig mee bezig.

[Raven]

linkforsoad schreef op zaterdag 3 oktober 2020 @ 14:54:
Raven geeft aan dat er standaard een /56 wordt gegeven,

Euh, ik? Ik geloof dat je Hipska bedoelt

[ Voor 7% gewijzigd door Raven op 03-10-2020 15:00 ]

[linkforsoad]

Raven schreef op zaterdag 3 oktober 2020 @ 15:00:
[...]

Euh, ik?

Uh, ja, de persoon die op jou reageerde, sorry

[Brahiewahiewa]

ijske schreef op zaterdag 3 oktober 2020 @ 13:12:
@overhyped & @Brahiewahiewa thx alvast

kan het dan zijn dat ik het verkeerd interpreteer , dat ik een /56 subnet heb toegewezen gekregen, en dat mijn modem op lan kant de /64 heeft gekregen ?
dat zou inderdaad wel erg logisch lijken , doch krijg ik het precies niet voor elkaar ze verder te verdelen in mijn router

ik kreeg het idee dat in dat SLAAC protocol de nodige info zou bijzitten welke ip's hij verder mag verdelen/routeren ..

De persoon die de ziggo connectbox heeft gemaakt, heeft ipv6 niet helemaal begrepen.
Daarom is bijv. prefix delegation al jaren stuk op die dingen

Als jouw 8560E door diezelfde persoon is gemaakt, zou dat best wel eens kunnen verklaren waarom je er niet in slaagt om meerdere subnets uit te delen.

Otoh lijkt het er op dat jij nog volgens het oude ipv4 stramien probeert te subnetten. Dat moet je niet doen.
Je hebt waarschijnlijk al 8 /64's

Als bovengenoemde persoon ondertussen iets bijgeleerd heeft, bestaat de kans dat prefix delegation ondertussen werkt. Dan hoef je dat alleen maar aan te zetten op je cisco. Die doet dan een DHCP request en krijgt vervolgens één adres voor z'n upstream en een /64 voor z'n downstream

[ijske]

ik probeer het zo even dan uit te leggen...
http://users.skynet.be/ijsje/ipv6.jpg
(plaatje is te groot om te linken)

moet ik dan op de LAN kant manueel opgeven wat zijn subnet is wat hij mag uitdelen (krijgt hij dat niet auto aangeleverd via SLAAC?)
krijg ik geen ipv6 van mn provider toegewezen helaas op deze manier

[Brahiewahiewa]

ijske schreef op zaterdag 3 oktober 2020 @ 16:03:
ik probeer het zo even dan uit te leggen...
http://users.skynet.be/ijsje/ipv6.jpg
(plaatje is te groot om te linken)

moet ik dan op de LAN kant manueel opgeven wat zijn subnet is wat hij mag uitdelen (krijgt hij dat niet auto aangeleverd via SLAAC?)
krijg ik geen ipv6 van mn provider toegewezen helaas op deze manier

DHCP-PD (prefix delegation) werkt vziw alleen met DHCP, niet met SLAAC

[jurjeno]

Volgens de dienstbeschrijving van Ziggo's "Zakelijk Internet Pro" [1] krijg je met zo'n abonnement in een former-Ziggo-gebied een /29 aan publieke IPv4-adressen én een /48 of /56 (is me niet helemaal duidelijk) aan publieke IPv6-adressen.

Uit dat document wordt me niet duidelijk of het kabelmodem al dan niet in bridge mode wordt gezet. Dat is namelijk wel wat ik graag zou willen. Iemand hier enig idee of bij een "Zakelijk Internet Pro" abonnement de modem in bridge mode kan, waarbij ik dan zelf in mijn eigen router de publieke IPv4- en IPv6-subnetten kan afhandelen?


[1] https://cdn-master.aem.pr...lijk%20internet%20Pro.pdf, te vinden via https://www.ziggo.nl/zakelijk/voorwaarden

[jk-5]

jurjeno schreef op zondag 4 oktober 2020 @ 11:19:
Volgens de dienstbeschrijving van Ziggo's "Zakelijk Internet Pro" [1] krijg je met zo'n abonnement in een former-Ziggo-gebied een /29 aan publieke IPv4-adressen én een /48 of /56 (is me niet helemaal duidelijk) aan publieke IPv6-adressen.

Uit dat document wordt me niet duidelijk of het kabelmodem al dan niet in bridge mode wordt gezet. Dat is namelijk wel wat ik graag zou willen. Iemand hier enig idee of bij een "Zakelijk Internet Pro" abonnement de modem in bridge mode kan, waarbij ik dan zelf in mijn eigen router de publieke IPv4- en IPv6-subnetten kan afhandelen?


[1] https://cdn-master.aem.pr...lijk%20internet%20Pro.pdf, te vinden via https://www.ziggo.nl/zakelijk/voorwaarden

Ik beheer een aantal van deze setups. Ze leveren een modem die altijd (virtueel, hierover later meer) in bridgemode staat. Je krijgt dan een enkel ip of een /29, afhankelijk van de afspraken die je statisch op je interface zet.
Voor ipv6 krijg je altijd een /48. De eerste /64 is de verbinding tussen jou en ziggo. ::1/64 hebben zij op de interface staan, ::2/64 zet je zelf statisch op je interface. De ::1 is dan jouw gateway en zij routen de hele /48 naar ::2 toe.

De manier waarop ze dit implementeren is best interessant. De modem heeft een GRE tunnel naar een router in een RC van ziggo. Het modem heeft dus een intern ip in het netwerk en tunnelt daarover je eigen ip space. Je MTU binnen de tunnel is wel altijd 1500, en qua performance is het absoluut niet voelbaar dat dit gebeurt, de tunnelrouters hangen letterlijk naast de core routers. Daarom zie je naar ziggo zakelijk klanten ook altijd een afwijkende traceroute. Dit stelt ze in staat om hele specifieke routing regels naar klanten te doen zonder in hun lokale RCs/LCs zich druk te hoeven maken om klantspecifieke routing. Het stelt ze ook in staat je je ip space mee te laten verhuizen als je later naar een grootzakelijke glasvezelverbinding van ziggo gaat.

[Dreamvoid]

ijske schreef op zaterdag 3 oktober 2020 @ 16:03:
ik probeer het zo even dan uit te leggen...
http://users.skynet.be/ijsje/ipv6.jpg
(plaatje is te groot om te linken)

moet ik dan op de LAN kant manueel opgeven wat zijn subnet is wat hij mag uitdelen (krijgt hij dat niet auto aangeleverd via SLAAC?)
krijg ik geen ipv6 van mn provider toegewezen helaas op deze manier

In de basis werkt SLAAC: je devices vragen om een Router Advertisement pakketje, je router stuurt een pakketje terug met de eerste 64 bits van het adres, de devices verzinnen de laatste 64 bits zelf. Dit werkt echter alleen op de kleinste segment, een /64, en alleen met adressen, geen subnetten.

Grotere subnetten (/48, /56, etc) worden via DHCP-PD verdeeld van router naar router. Je Ziggo router vraagt om een /56, krijgt de eerste 56 bits terug, en kan daaruit met de volgende 8 bits (57 tm 64) dus 256 verschillende /64 subnetten maken. Je kan in de praktijk ofwel in de router instellen wat die 8 bits zijn, ofwel je router doet dit automatisch, zonder optie om het handmatig te doen.

[ Voor 7% gewijzigd door Dreamvoid op 04-10-2020 11:51 ]

[jurjeno]

jk-5 schreef op zondag 4 oktober 2020 @ 11:30:
[Ziggo Zakelijk Internet Pro in fZiggo gebied]

Ik beheer een aantal van deze setups. Ze leveren een modem die altijd (virtueel, hierover later meer) in bridgemode staat. Je krijgt dan een enkel ip of een /29, afhankelijk van de afspraken die je statisch op je interface zet.
Voor ipv6 krijg je altijd een /48. De eerste /64 is de verbinding tussen jou en ziggo. ::1/64 hebben zij op de interface staan, ::2/64 zet je zelf statisch op je interface. De ::1 is dan jouw gateway en zij routen de hele /48 naar ::2 toe.
[...]

Thanks! Eeuwig aan het Googlen geweest, weetikveel hoeveel posts in het Ziggo forum tegengekomen, Ziggo gebeld ("subnet?") en hier binnen 5 minuten een kristalhelder antwoord.

[jk-5]

jurjeno schreef op zondag 4 oktober 2020 @ 11:55:
[...]


Thanks! Eeuwig aan het Googlen geweest, weetikveel hoeveel posts in het Ziggo forum tegengekomen, Ziggo gebeld ("subnet?") en hier binnen 5 minuten een kristalhelder antwoord.

De monteur heeft bij het opleveren van de verbinding trouwens ook altijd een PDFje bij zich waar de ip space exact staat uitgelegd. Als ze hem niet al aan je geven zal ik ernaar vragen, is super handige informatie.

[ijske]

Dreamvoid schreef op zondag 4 oktober 2020 @ 11:46:
[...]

In de basis werkt SLAAC: je devices vragen om een Router Advertisement pakketje, je router stuurt een pakketje terug met de eerste 64 bits van het adres, de devices verzinnen de laatste 64 bits zelf. Dit werkt echter alleen op de kleinste segment, een /64, en alleen met adressen, geen subnetten.

Grotere subnetten (/48, /56, etc) worden via DHCP-PD verdeeld van router naar router. Je Ziggo router vraagt om een /56, krijgt de eerste 56 bits terug, en kan daaruit met de volgende 8 bits (57 tm 64) dus 256 verschillende /64 subnetten maken. Je kan in de praktijk ofwel in de router instellen wat die 8 bits zijn, ofwel je router doet dit automatisch, zonder optie om het handmatig te doen.

ik heb de wan interface op SLAAC teruggezet inderdaad, en bij LAN-Router Advertisement heb ik gezien dat er automatisch een range is ingevuld / aangemaakt ( een /56 )
router advertisement stond reeds aan voor vlan1 , op unsolicited multicast , en verders RA flags op zowel managed als other gezet.

helaas.. still notting

edit : ook is wireshark getest,en ik zie wel router advertisements, maar allemaal afkomstig van FE80 (wat vermoedelijk local-links zijn
geen aanwezigheid van de provider in wireshark (of ik moet naar iets anders zoeken dan ICMPv6 ?)

[ Voor 9% gewijzigd door ijske op 04-10-2020 20:40 ]

[Snow_King]

ijske schreef op zondag 4 oktober 2020 @ 15:02:
[...]


ik heb de wan interface op SLAAC teruggezet inderdaad, en bij LAN-Router Advertisement heb ik gezien dat er automatisch een range is ingevuld / aangemaakt ( een /56 )
router advertisement stond reeds aan voor vlan1 , op unsolicited multicast , en verders RA flags op zowel managed als other gezet.

helaas.. still notting

edit : ook is wireshark getest,en ik zie wel router advertisements, maar allemaal afkomstig van FE80 (wat vermoedelijk local-links zijn
geen aanwezigheid van de provider in wireshark (of ik moet naar iets anders zoeken dan ICMPv6 ?)

Jouw router krijgt de /56 gerouteerd, het device er achter zou weer een /64 van jouw router moeten krijgen.

Ik vind het alleen even lastig met die MAC bridge, weet niet helemaal hoe dat werkt eigenlijk.

[Groentjuh]

Brahiewahiewa schreef op zaterdag 3 oktober 2020 @ 15:25:
[...]

Als bovengenoemde persoon ondertussen iets bijgeleerd heeft, bestaat de kans dat prefix delegation ondertussen werkt. Dan hoef je dat alleen maar aan te zetten op je cisco. Die doet dan een DHCP request en krijgt vervolgens één adres voor z'n upstream en een /64 voor z'n downstream

Zolang je de gateway ipv6, maar niet monitored in OPNSense (kennelijk reageert die niet op ping), werkt prefix delegation inmiddels. Mijn OPNSense staat natuurlijk als DMZ voor IPv4 en heeft een /60 gekregen van mijn Ziggo Connectbox. Meer krijg ik er niet uit! Helaas is het bij Ziggo nog steeds CB in bridge voor IPv4-only of dubbel nat voor ipv4 + ipv6.

[Brahiewahiewa]

Groentjuh schreef op maandag 5 oktober 2020 @ 11:31:
[...]

Zolang je de gateway ipv6, maar niet monitored in OPNSense (kennelijk reageert die niet op ping), werkt prefix delegation inmiddels. Mijn OPNSense staat natuurlijk als DMZ voor IPv4 en heeft een /60 gekregen van mijn Ziggo Connectbox. Meer krijg ik er niet uit! Helaas is het bij Ziggo nog steeds CB in bridge voor IPv4-only of dubbel nat voor ipv4 + ipv6.

offtopic:
Met de OPNSense als DMZ host heb je geen dubbel NAT

[Vorkie]

Brahiewahiewa schreef op maandag 5 oktober 2020 @ 14:04:
[...]

offtopic:
Met de OPNSense als DMZ host heb je geen dubbel NAT

Care to explain?

Ziggo modem 192.168.178.1 > 192.168.178.2 (OPNSense) > 192.168.11.0/24?

Dat je al het verkeer doorstuurt is nog steeds dNAT naar OPNSense en daarna dNAT naar een interne host.

[Brahiewahiewa]

Vorkie schreef op maandag 5 oktober 2020 @ 14:16:
[...]

Care to explain?

Ziggo modem 192.168.178.1 > 192.168.178.2 (OPNSense) > 192.168.11.0/24?

Dat je al het verkeer doorstuurt is nog steeds dNAT naar OPNSense en daarna dNAT naar een interne host.

offtopic:
De verbinding van de Ziggo modem naar OPNSense is gebridged. Dat kun je zien aan de MTU achter de OPNSense. Bij dubbel NAT zou die 1484 moeten zijn, maar hij is 1492

[jk-5]

Brahiewahiewa schreef op maandag 5 oktober 2020 @ 14:32:
[...]

offtopic:
De verbinding van de Ziggo modem naar OPNSense is gebridged. Dat kun je zien aan de MTU achter de OPNSense. Bij dubbel NAT zou die 1484 moeten zijn, maar hij is 1492

Een verschil in MTU zie je alleen als het verkeer getunneld is. Bij meerdere lagen NAT blijft je MTU altijd gewoon 1500 omdat NAT niet hoeft te betekenen dat het door een tunnel loopt

[Brahiewahiewa]

jk-5 schreef op maandag 5 oktober 2020 @ 14:53:
[...]


Een verschil in MTU zie je alleen als het verkeer getunneld is. Bij meerdere lagen NAT blijft je MTU altijd gewoon 1500 omdat NAT niet hoeft te betekenen dat het door een tunnel loopt

offtopic:
Als je de maximum packet size meet (ping -f -l <size>) naar een host op internet, vind je 1492. Terwijl dat 1484 zou moeten zijn, als er sprake was van dubbel NAT

[jk-5]

Brahiewahiewa schreef op maandag 5 oktober 2020 @ 15:01:
[...]

offtopic:
Als je de maximum packet size meet (ping -f -l <size>) naar een host op internet, vind je 1492. Terwijl dat 1484 zou moeten zijn, als er sprake was van dubbel NAT

NAT tast je MTU niet aan. Het feit dat je 1492 ziet ipv 1500 komt door de DS-Lite tunnel van ziggo. Die tunnelen ipv4 verkeer in ipv6 waardoor je 8 bytes kwijtraakt voor de ipv4 header. Als je modem niet in bridgemode staat heb je dubbel nat, of DMZ nou wel of niet aanstaat

[Brahiewahiewa]

jk-5 schreef op maandag 5 oktober 2020 @ 15:02:
[...]
DS-Lite tunnel van ziggo...

offtopic:
Hûh? Ik heb dual stack

[Vorkie]

Brahiewahiewa schreef op maandag 5 oktober 2020 @ 15:08:
[...]

offtopic:
Hûh? Ik heb dual stack

Maar alsnog veranderd double NAT geen MTU.

[Brahiewahiewa]

Vorkie schreef op maandag 5 oktober 2020 @ 15:10:
[...]

Maar alsnog veranderd double NAT geen MTU.

offtopic:
OK, het was misschien duidelijker geweest als ik meteen over path-MTU begonnen was.
Die path MTU neemt met 8 bytes af voor elke NAT router in het tussenliggende traject.
Dus als ik tussen two hosts een path-MTU meet van 1492, ga ik er van uit dat er tussen die hosts maar één NAT router zit

[jk-5]

Brahiewahiewa schreef op maandag 5 oktober 2020 @ 15:26:
[...]

offtopic:
OK, het was misschien duidelijker als ik meteen over path-MTU begonnen was.
Die path MTU neemt met 8 bytes af voor elke NAT router in het tussenliggende traject.
Dus als ik tussen two hosts een path-MTU meet van 1492, ga ik er van uit dat er tussen die hosts maar één NAT router zit

Path MTU is hetzelfde als MTU. DS-Lite verlaagt de MTU (eenmalig) naar 1480. Met PPPoE krijg je echter wel een MTU van 1492. Welke provider heb je?

[Brahiewahiewa]

jk-5 schreef op maandag 5 oktober 2020 @ 15:29:
[...]


Path MTU is hetzelfde als MTU. DS-Lite verlaagt de MTU (eenmalig) naar 1480. Met PPPoE krijg je echter wel een MTU van 1492. Welke provider heb je?

offtopic:
Ziggo, met dual stack

[borft]

Brahiewahiewa schreef op maandag 5 oktober 2020 @ 15:26:
[...]

offtopic:
OK, het was misschien duidelijker geweest als ik meteen over path-MTU begonnen was.
Die path MTU neemt met 8 bytes af voor elke NAT router in het tussenliggende traject.
Dus als ik tussen two hosts een path-MTU meet van 1492, ga ik er van uit dat er tussen die hosts maar één NAT router zit

Ik heb geen idee wat path mtu is, maar ik zie geen reden waarom NAT de MTU zou veranderen. Doorgaans wordt alle state op de router (die de NAT doet) bijgehouden, en worden de headers aangepast. De payload verandert niet, er is geen encapulatie zoals bij een tunnel, dus ik vraag me af waar die 8 bytes dan voor gebruikt zouden worden.

[jk-5]

@Brahiewahiewa NAT is Network Address Translation, niet Tunneling. Het enige wat het doet is het ipadres in de header vervangen. Daar krijg je nooit een andere MTU door. Als je constateert dat je MTU lager is dan normaal zou hij dat ook zijn zonder nat, en ook met 10 lagen NAT. PMTU == MTU

[jk-5]

@Brahiewahiewa Ik zat nog even na te denken, weet je zeker dat je het niet verwart met IPsec NAT-T? Dat is het tunnelen van IPsec verkeer in UDP, en dat kost je 8 bytes MTU omdat de UDP header zo groot is.

Of misschien simpeler, de ping die je doet, is dat een UDP ping? Dan heb je 1492 bytes beschikbaar, met 8 bytes UDP header erop = 1500 bytes.

[Brahiewahiewa]

jk-5 schreef op maandag 5 oktober 2020 @ 15:40:
@Brahiewahiewa Ik zat nog even na te denken, weet je zeker dat je het niet verwart met IPsec NAT-T? Dat is het tunnelen van IPsec verkeer in UDP, en dat kost je 8 bytes MTU omdat de UDP header zo groot is.

Of misschien simpeler, de ping die je doet, is dat een UDP ping? Dan heb je 1492 bytes beschikbaar, met 8 bytes UDP header erop = 1500 bytes.

offtopic:
Nee, gewoon ICMP

Anyway, tx allen voor het bestrijden van mijn misvattingen
Zullen we het grote IPv6 topic niet verder vervuilen met ip4 geneuzel? ;o)
Prangende vragen en/of opmerkingen kunnen via DM

[ijske]

Snow_King schreef op maandag 5 oktober 2020 @ 11:17:
[...]

Jouw router krijgt de /56 gerouteerd, het device er achter zou weer een /64 van jouw router moeten krijgen.

Ik vind het alleen even lastig met die MAC bridge, weet niet helemaal hoe dat werkt eigenlijk.

lijkt me logisch

mac bridge is een ipv4 only functie dus daar moeten we even niet naar kijken

ik connecteerde gister wel, voor de test, even op de modem zelf en daar zie ik een "router advertisement" packetten....
want het lijkt me nu dat er zich wel een ipv6 vormt, maar zonder router / dns

[Snow_King]

ijske schreef op maandag 5 oktober 2020 @ 19:05:
[...]

lijkt me logisch

mac bridge is een ipv4 only functie dus daar moeten we even niet naar kijken

ik connecteerde gister wel, voor de test, even op de modem zelf en daar zie ik een "router advertisement" packetten....
want het lijkt me nu dat er zich wel een ipv6 vormt, maar zonder router / dns

Ik heb net op mijn Ziggo verbinding (Ik weet, totaal anders) het wel werkend gekregen. Op een Linux host waar ik Docker containers wil draaien voerde ik uit:

code:

dhclient -6 -P -d eth0

Vervolgens kreeg ik een /60 gerouteerd naar mijn host toe. Dat zou bij jou ook moeten werken denk ik. Het gaat er om dat je met Prefix Delegation om een prefix vraagt bij je router.

code:

root@scripts:~# ip -6 addr show dev docker0
3: docker0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP 
    inet6 2001:1c05:10b:xxx::1/80 scope global 
       valid_lft forever preferred_lft forever
    inet6 fe80::42:dcff:fec0:c6a/64 scope link 
       valid_lft forever preferred_lft forever
    inet6 fe80::1/64 scope link 
       valid_lft forever preferred_lft forever
root@scripts:~#

[Brahiewahiewa]

Snow_King schreef op dinsdag 6 oktober 2020 @ 15:19:
[...]

Ik heb net op mijn Ziggo verbinding (Ik weet, totaal anders) het wel werkend gekregen...

Laat je even weten of het blijft werken?
Mijn ervaring is dat het één keer werkt. Maar na een reboot van de router zegt-ie dat er geen lease verkregen kan worden. Kennelijk is de dhcp refresh stuque.
Ook een reboot van de ziggo modem lost dat niet op

[Snow_King]

Brahiewahiewa schreef op dinsdag 6 oktober 2020 @ 16:48:
[...]

Laat je even weten of het blijft werken?
Mijn ervaring is dat het één keer werkt. Maar na een reboot van de router zegt-ie dat er geen lease verkregen kan worden. Kennelijk is de dhcp refresh stuque.
Ook een reboot van de ziggo modem lost dat niet op

Doe ik! Mijn DHCP client draait onder systemd en zal dus netjes zijn lease blijven vernieuwen. Doe je dat ook wel?

Ik heb een ConnectBox, welke router heb jij?

[Brahiewahiewa]

Snow_King schreef op dinsdag 6 oktober 2020 @ 17:30:
[...]

Doe ik! Mijn DHCP client draait onder systemd en zal dus netjes zijn lease blijven vernieuwen. Doe je dat ook wel?

Ik heb een ConnectBox, welke router heb jij?

Ik heb ook een connectbox
M'n router is een ouwe draytek; de ipv6 implementatie lijkt er een beetje aangeknutseld te zijn, idd.
Maar desondanks beweert de router dat-ie geen PD meer van de connectbox krijgt, na een reboot
Als je google raadpleegt vind je meer mensen die dat probleem bevestigen

[Snow_King]

Snow_King schreef op woensdag 24 juni 2020 @ 11:16:
Heeft iemand enig idee of de 4G/LTE backup dienst van KPN-1 wel IPv6 doet? Ik heb zo'n vermoeden van niet namelijk.

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

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

Ik quote mijzelf hier even. Contact gehad met KPN en het antwoord:

code:

Goedemiddag, bij KPN1 werken we vooralsnog alleen met IPv4.

Met NAT is die failover natuurlijk lekker makkelijk te maken. Met IPv6 en Dynamische routing was zoiets ook prima te doen, maar zo zien we weer.

Verkoop van abbo's is belangrijker dan echt IPv6 uitrollen naar klanten.

[KroontjesPen]

Een tijd lang kon ik hoe IPv6 werkte best volgen.
Nu alles maar steeds op de lange baan wordt geschoven raak ik die kennis best wel weer kwijt.
Door hier te lezen hou ik nog minimaal op peil zoals met /56 en /64.
Nu heb je dat als gewone gebruiker, zoals ik, niet echt nodig. Toch is wat kennis erover best fijn.

Nu komt er hier soms een gedachte op dat het misschien nodig is om alsnog een fatale fout in IPv4 te ontdekken die niet in IPv6 zit natuurlijk.
Eentje waardoor financiële transacties niet meer over IPv4 heen mogen gaan bijvoorbeeld.
Dan moet iedereen wel.

[Dreamvoid]

De doorsnee gebruiker gaat er niks van merken. De uitrol gaat gestaag door, langzamerhand krijgt iedereen IPv6 op zijn internet verbinding en zijn mobieltje (we tikken volgens de Google stats wereldwijd de 35% aan binnenkort) en deelt je providerbox op je LAN dual stack v4+v6 uit. Je devices die v6 doen, gaan dat primair gebruiken, met v4 als fallback.

Dat kan tot in de eeuwigheid zo blijven, zelfs al het hele netwerk upstream van je providerbox single stack IPv6 is geworden. “Native” end-to-end IPv4 verdwijnt nu al in rap tempo van het internet, het wordt altijd wel ergens getunneld/NATted over IPv6.

[ Voor 32% gewijzigd door Dreamvoid op 11-10-2020 03:37 ]

[Roetzen]

Dreamvoid schreef op zondag 11 oktober 2020 @ 03:23:

Dat kan tot in de eeuwigheid zo blijven, zelfs al het hele netwerk upstream van je providerbox single stack IPv6 is geworden. “Native” end-to-end IPv4 verdwijnt nu al in rap tempo van het internet, het wordt altijd wel ergens getunneld/NATted over IPv6.

Totdat de providers echt door hun IPv4 heen raken en hun klanten noodgedwongen op DS-Lite zetten. En als er dan problemen ontstaan, hun klanten adviseren IPv4 uit te zetten. Nu wordt bij problemen vaak IPv6 dan maar uit gezet, maar er zal een moment komen dat IPv4 uitzetten de minste van de kwaden is...

[Vorkie]

Roetzen schreef op zondag 11 oktober 2020 @ 09:25:
[...]

Totdat de providers echt door hun IPv4 heen raken en hun klanten noodgedwongen op DS-Lite zetten. En als er dan problemen ontstaan, hun klanten adviseren IPv4 uit te zetten. Nu wordt bij problemen vaak IPv6 dan maar uit gezet, maar er zal een moment komen dat IPv4 uitzetten de minste van de kwaden is...

Ik denk niet dat in ISP land het probleem snel zal gaan ontstaan in NL, maar in DC land, maar die spelers zitten tegenwoordig, zoals Oneprovider, OVH, Microsoft, wereldwijd, dus die kunnen blokken IPv4 verhuizen, daarnaast zie je daar wel steeds meer IPv6 in gebruik zijn, waardoor ook hun meer "over" houden voor distributie.

In NL heb je als ISP een klanten base van max zoveel aansluitingen, iedereen vist in die pot, de grootste ISP's hebben buiten NL ook klanten, dus ook hier geldt, verplaatsen van IP's.

Als in Zwitserland iedereen overstap van Vodafone naar TSystems, zal T-Systems ergens anders zijn adressen vandaan moeten halen en kan Vodafone tegelijkertijd de IP adressen in NL ophogen.

/versimpelde weergave.

/edit

Vergeet niet, ik ben een IPv6 dude, elk netwerk wat ik oplever heeft, of is minimaal aangeboden, een IPv6 backbone.

[ Voor 5% gewijzigd door Vorkie op 11-10-2020 09:41 ]

[aawe mwan]

Toch blijft het maar een moeizaam proces, dat omzetten naar IPv6.

Tot ongeveer een jaar geleden, moest je altijd zorgen dat je IPv6 ondersteuning op nieuwe apparaten uitgeschakeld had, anders ging je gegarandeerd problemen krijgen in je IPv4 netwerkje.

Nu het op dat niveau eindelijk een beetje werkt, ontdek je dat de mensen die het op hogere niveaus geïmplementeerd hebben, IPv6 nog niet begrepen hebben.

In Ubuntu gebeurt het bijvoorbeeld wel eens dat een IPv6 SSH verbinding wegvalt. Het is me een paar keer overkomen tijdens het uitvoeren van een update/upgrade en afgelopen week gebeurde het dat na bepaalde tijd mijn IPv6 adres ineens verdwenen was en mijn SSH verbinding dus blokkeerde. Gelukkig is op die momenten de andere kant nog wel bereikbaar via IPv4.

[Nakebod]

Maak je op dat moment dan niet gebruik van de temporary addresses aka privacy extensions.
Die verlopen na (dacht ik) 7 dagen.

Voor mijn paar Ubuntu VM's heb ik static IPv6 adressen, en nog nooit gehad dat die ineens niet bereikbaar zijn. (Eerder dat ik client IPv6 issues had.)
Al kan ik mij voorstellen dat static assignment niet per se handig is, maar mogelijk dat uitzetten van privacy extensions dan al voldoende is, dan krijg je altijd hetzelfde adres.

[jk-5]

Nakebod schreef op zondag 11 oktober 2020 @ 12:23:
Maak je op dat moment dan niet gebruik van de temporary addresses aka privacy extensions.
Die verlopen na (dacht ik) 7 dagen.

Afhankelijk van de implementatie kunnen ze eerder verlopen, maar wanneer er nog een verbinding actief is op zo'n oud ip blijft hij op je interface staan. Dus het zal nooit tot gedropte verbindingen mogen leiden

[Maurits van Baerle]

Voor zover ik weet is de standaard dat er onder Privacy Extensions iedere 24 uur een nieuw adres wordt toegekend. Het oude adres wordt niet verwijderd maar niet meer gebruikt voor nieuwe verbindingen dus zal vrijwel altijd binnen enkele dagen vervallen wegens onbruik.

[Brahiewahiewa]

aawe mwan schreef op zondag 11 oktober 2020 @ 10:37:
...
Tot ongeveer een jaar geleden, moest je altijd zorgen dat je IPv6 ondersteuning op nieuwe apparaten uitgeschakeld had, anders ging je gegarandeerd problemen krijgen in je IPv4 netwerkje...

Prikkelende stelling. Care to explain?

[Dreamvoid]

Roetzen schreef op zondag 11 oktober 2020 @ 09:25:
Totdat de providers echt door hun IPv4 heen raken en hun klanten noodgedwongen op DS-Lite zetten. En als er dan problemen ontstaan, hun klanten adviseren IPv4 uit te zetten. Nu wordt bij problemen vaak IPv6 dan maar uit gezet, maar er zal een moment komen dat IPv4 uitzetten de minste van de kwaden is...

IPv4 uitzetten op het LAN is nog niet praktisch. Het is niet dat de devices van de klanten het niet aankunnen, maar:
- welke mainstream providers in NL hebben nu DNS64 op hun standaard DNS server, degene die naar je devices gepushed wordt? Volgens mij niemand van de grote jongens nu. Moet je dus een 3rd party DNS server draaien.
- alternatief, welke provider heeft op zijn eigen “box” lokale DNS64 draaien? Antwoord: nog niemand
- welke provider draait een NAT64 server voor zijn vaste-lijn klanten? Antwoord: nog niemand
- welke provider biedt een box aan die zelf NAT64 doet (oftewel, dual stack WAN, v6 LAN)? Antwoord: nog niemand

Je kan het technisch gezien wel doen door de standaard DNS servers te vervangen door een 3rd party DNS64/NAT64 service (ik heb dit een tijdje gedraaid voor de grap, werkt op zich prima), maar dan routeer je al je v4 verkeer ergens via een ander land/provider, dat maakt de boel er ook niet betrouwbaarder op.

[Snow_King]

aawe mwan schreef op zondag 11 oktober 2020 @ 10:37:
Toch blijft het maar een moeizaam proces, dat omzetten naar IPv6.

Tot ongeveer een jaar geleden, moest je altijd zorgen dat je IPv6 ondersteuning op nieuwe apparaten uitgeschakeld had, anders ging je gegarandeerd problemen krijgen in je IPv4 netwerkje.

Nu het op dat niveau eindelijk een beetje werkt, ontdek je dat de mensen die het op hogere niveaus geïmplementeerd hebben, IPv6 nog niet begrepen hebben.

In Ubuntu gebeurt het bijvoorbeeld wel eens dat een IPv6 SSH verbinding wegvalt. Het is me een paar keer overkomen tijdens het uitvoeren van een update/upgrade en afgelopen week gebeurde het dat na bepaalde tijd mijn IPv6 adres ineens verdwenen was en mijn SSH verbinding dus blokkeerde. Gelukkig is op die momenten de andere kant nog wel bereikbaar via IPv4.

Interessant. Ik beheer al sinds 2011 netwerken met IPv6 en de laatste jaren exclusief IPv6. Dan praat je over duizenden servers en honderden switches, allemaal via IPv6. Probeemloos.

Het protocol IPv6 is gewoon stabiel en werkt goed.

Het is echter anders dan IPv4 en daar gaat het vaak mis: Kennis

Mensen maken aannames uit hun IPv4 kennis en vinden het dan apart dat IPv6 anders werkt. Vaak zitten er hele goede redenen achter, maar vaak wordt v6 dan afgeschreven als moeilijk en complex.

[Roetzen]

Dreamvoid schreef op maandag 12 oktober 2020 @ 00:51:
[...]

IPv4 uitzetten op het LAN is nog niet praktisch. Het is niet dat de devices van de klanten het niet aankunnen, maar:
- welke mainstream providers in NL hebben nu DNS64 op hun standaard DNS server, degene die naar je devices gepushed wordt? Volgens mij niemand van de grote jongens nu. Moet je dus een 3rd party DNS server draaien.

Inderdaad, voor zo ver ik weet nog niemand. Idem voor je volgende vragen. En het via een derde partij doen geeft vergelijkbare problemen als nu IPv6 via een tunnel van een derde partij. Het werkt, maar optimaal is het niet. En zelf doen is ook leuk als experiment voor de Tweaker...

Ik keek eigenlijk wat verder vooruit in de toekomst. Ik keek vooruit naar de tijd waarin IPv4 niet veel meerwaarde meer heeft omdat IPv6 wijd verbreid is en dat het daarom voor een provider niet meer de moeite loont nog veel tijd en energie in het oplossen van een specifiek IPv4 probleem te steken. En de provider dan zonder veel gevolgen de klant kan adviseren IPv4 maar uit te zetten bij zo'n probleem.

Misschien tegen beter weten in, ik ben 74, hoop ik dat nog eens mee te maken...

[Snow_King]

Nakebod schreef op zondag 11 oktober 2020 @ 12:23:
Maak je op dat moment dan niet gebruik van de temporary addresses aka privacy extensions.
Die verlopen na (dacht ik) 7 dagen.

Voor mijn paar Ubuntu VM's heb ik static IPv6 adressen, en nog nooit gehad dat die ineens niet bereikbaar zijn. (Eerder dat ik client IPv6 issues had.)
Al kan ik mij voorstellen dat static assignment niet per se handig is, maar mogelijk dat uitzetten van privacy extensions dan al voldoende is, dan krijg je altijd hetzelfde adres.

Ik zet Privacy Extensions vaak uit, maar laat SLAAC wel aan staan.

Zo heeft de node altijd een fixed adres op basis van zijn MAC wat nooit veranderd. Zo kan ik mijn servers altijd bereiken.

Thuis heb ik zo diverse VM's draaien op een Linux host achter mijn Ziggo verbinding. Kan probleemloos bij mijn servers op die manier.

[xbeam]

Snow_King schreef op maandag 12 oktober 2020 @ 11:14:
[...]

Interessant. Ik beheer al sinds 2011 netwerken met IPv6 en de laatste jaren exclusief IPv6. Dan praat je over duizenden servers en honderden switches, allemaal via IPv6. Probeemloos.

Het protocol IPv6 is gewoon stabiel en werkt goed.

Het is echter anders dan IPv4 en daar gaat het vaak mis: Kennis

Mensen maken aannames uit hun IPv4 kennis en vinden het dan apart dat IPv6 anders werkt. Vaak zitten er hele goede redenen achter, maar vaak wordt v6 dan afgeschreven als moeilijk en complex.

Dat lijkt me echt sterk dat je ipv6 only draait (misschien alleen intern voor je beheer netwerk)

Ik heb ook nu nog steeds problemen met ipv6. En kom het nog regelmatig tegen dat bijv webservers van verschillende een mkb’rs wel ipv6 aan hebben staan maar hun service alleen op ipv4 draaien.

Ook bestaan er nog applicaties ipv4 only zijn.
En aangezien ipv6 dan problemen soms onverwacht problemen oplevert zoals inderdaad verlies van verbinding met (in de ogen van mijn klant) omdat bepaalde diensten van hun klant niet goed kunnen bereiken zet ik het eigenlijk standaard uit.

[Dreamvoid]

Snow_King schreef op maandag 12 oktober 2020 @ 11:30:
Ik zet Privacy Extensions vaak uit, maar laat SLAAC wel aan staan.

Zo heeft de node altijd een fixed adres op basis van zijn MAC wat nooit veranderd. Zo kan ik mijn servers altijd bereiken.

Ook met PE aangezet blijft dat vaste adres staan, Privacy Extensions (macOS, Linux) worden in de regel zo geimplementeerd dat het extra adressen zijn, naast de normale EUI-64 (of RFC7217) statische suffix. De PE adressen worden dan by default gebruikt voor uitgaande sessies, terwijl je het vaste adres kan gebruiken voor inkomende verbindingen (of DNS records).

Dat lijkt me echt sterk dat je ipv6 only draait (misschien alleen intern voor je beheer netwerk)

Een IPv6 only LAN is niet zo raar hoor, als je niet te veel oude spullen hebt draaien. Je moet natuurlijk wel DNS64/NAT64 ergens hebben draaien (op je router of extern), anders kan je niet naar v4 websites verbinden.

[ Voor 25% gewijzigd door Dreamvoid op 12-10-2020 11:50 ]

[Snow_King]

xbeam schreef op maandag 12 oktober 2020 @ 11:36:
[...]


Dat lijkt me echt sterk dat je ipv6 only draait (misschien alleen intern voor je beheer netwerk)

Het beheer gaat volledig over IPv6. SSH en SNMP naar switches en routers.

SSH en Monitoring (Zabbix) van Linux servers, allemaal via IPv6.

Internet facing termineren we IPv4 op loadbalancers, maar de rest van de servers draait gewoon IPv6-only en dat doen we al jaren zo.

Zo gebruiken we IPv4 alleen waar het echt nodig is.

Ik heb ook nu nog steeds problemen met ipv6. En kom het nog regelmatig tegen dat bijv webservers van verschillende een mkb’rs wel ipv6 aan hebben staan maar hun service alleen op ipv4 draaien.

xbeam schreef op maandag 12 oktober 2020 @ 11:36:
[...]

Ook bestaan er nog applicaties ipv4 only zijn.
En aangezien ipv6 dan problemen soms onverwacht problemen oplevert zoals inderdaad verlies van verbinding met (in de ogen van mijn klant) omdat bepaalde diensten van hun klant niet goed kunnen bereiken zet ik het eigenlijk standaard uit.

Dat wegvallen ligt echt niet aan IPv6. Vaak zit er een ander onderliggend probleem dan IPv6. Het protocol is gewoon stabiel en volwassen.

IPv6 uit zetten is wat dat betreft 'je kop in het zand steken', want zo voeg je alleen maar meer legacy toe.

Dreamvoid schreef op maandag 12 oktober 2020 @ 11:45:
[...]

Ook met PE aangezet blijft dat vaste adres staan, Privacy Extensions (macOS, Linux) worden in de regel zo geimplementeerd dat het extra adressen zijn, naast de normale EUI-64 (of RFC7217) statische suffix. De PE adressen worden dan by default gebruikt voor uitgaande sessies, terwijl je het vaste adres kan gebruiken voor inkomende verbindingen (of DNS records).

Fair enough. Maar op servers zet ik het uit. Daar is PE niet nodig.

Mijn laptop en andere devices hebben het wel gewoon aan staan.

[ Voor 18% gewijzigd door Snow_King op 12-10-2020 11:58 ]

[xbeam]

Snow_King schreef op maandag 12 oktober 2020 @ 11:57:
[...]

Het beheer gaat volledig over IPv6. SSH en SNMP naar switches en routers.

SSH en Monitoring (Zabbix) van Linux servers, allemaal via IPv6.

Internet facing termineren we IPv4 op loadbalancers, maar de rest van de servers draait gewoon IPv6-only en dat doen we al jaren zo.

Zo gebruiken we IPv4 alleen waar het echt nodig is.

Ik heb ook nu nog steeds problemen met ipv6. En kom het nog regelmatig tegen dat bijv webservers van verschillende een mkb’rs wel ipv6 aan hebben staan maar hun service alleen op ipv4 draaien.


[...]

Dat wegvallen ligt echt niet aan IPv6. Vaak zit er een ander onderliggend probleem dan IPv6. Het protocol is gewoon stabiel en volwassen.

IPv6 uit zetten is wat dat betreft 'je kop in het zand steken', want zo voeg je alleen maar meer legacy toe.


[...]

Fair enough. Maar op servers zet ik het uit. Daar is PE niet nodig.

Mijn laptop en andere devices hebben het wel gewoon aan staan.

Ik zeg ook niet ipv6 niet stabiel alleen voor de eind gebruiker werkt het vaak niet stabiel omdat er partij/bedrijven zijn die het lokaal hun eigen voorraad of onder systeem niet goed hebben ingericht. Dan is bijv de webserver wel op ipv6 berijkbaar maar hebben de api bijv alleen op ipv4 draaien.

Mijn klant ervaart dan een niet werken de verbinding en gaat mij bellen op het op te lossen. Vandaar dat vaak standaart ipv6 uitzet.

Daarnaast zijn ook hardware en software leveranciers waarvan sommige onderdelen ipv4 only zijn. zoals Avast’s secure web gateway voor off side ssl virus inspectie die voor

[Roetzen]

xbeam schreef op maandag 12 oktober 2020 @ 13:01:
[...]


Ik zeg ook niet ipv6 niet stabiel alleen voor de eind gebruiker werkt het vaak niet stabiel omdat er partij/bedrijven zijn die het lokaal hun eigen voorraad of onder systeem niet goed hebben ingericht.

Ik ben al meer dan 10 jaar met IPv6 bezig en heel in het begin was er wel eens het probleem dat een een dienst wel IPv6 adverteerde, maar het in feite niet had. Dat gaf dan hinderlijke vertragingen in de verbinding. Dat probleem heb ik al heel lang niet meer gezien.

Dan is bijv de webserver wel op ipv6 berijkbaar maar hebben de api bijv alleen op ipv4 draaien.
[
Mijn klant ervaart dan een niet werken de verbinding en gaat mij bellen op het op te lossen. Vandaar dat vaak standaart ipv6 uitzet.

Ik denk dat je je klant daar mee op termijn geen dienst bewijst. Ik ben het eens met Snowking: het is struisvogelpolitiek en je kweekt daarmee juist meer legacy.

Daarnaast zijn ook hardware en software leveranciers waarvan sommige onderdelen ipv4 only zijn. zoals Avast’s secure web gateway voor off side ssl virus inspectie die voor

Als het goed geïmplementeerd is zou het geen problemen mogen geven. Als het wel problemen geeft dan zou het reden moeten zijn je klant af te raden dat brakke spul te gebruiken en over te gaan op spul dat het wel goed doet. IPv6 uitschakelen is symptoombestrijding. Een maatregel die ook nog veel te breed is want dan schakel je meteen alle IPv6 uit en wordt het ook misschien nooit meer aan gezet.

[xbeam]

Roetzen schreef op maandag 12 oktober 2020 @ 14:15:
[...]

Ik ben al meer dan 10 jaar met IPv6 bezig en heel in het begin was er wel eens het probleem dat een een dienst wel IPv6 adverteerde, maar het in feite niet had. Dat gaf dan hinderlijke vertragingen in de verbinding. Dat probleem heb ik al heel lang niet meer gezien.

[...]

Ik denk dat je je klant daar mee op termijn geen dienst bewijst. Ik ben het eens met Snowking: het is struisvogelpolitiek en je kweekt daarmee juist meer legacy.

[...]

Als het goed geïmplementeerd is zou het geen problemen mogen geven. Als het wel problemen geeft dan zou het reden moeten zijn je klant af te raden dat brakke spul te gebruiken en over te gaan op spul dat het wel goed doet. IPv6 uitschakelen is symptoombestrijding. Een maatregel die ook nog veel te breed is want dan schakel je meteen alle IPv6 uit en wordt het ook misschien nooit meer aan gezet.

Daar ben ik het mee eens. Alleen makkelijker gezegd dan gedaan. Niet alle branche in Nederland hebben hun zaakjes goed op orde.

Maar zolang niet alle leverancier en klanten van deze klant een goede implementatie van ipv6 kunnen garanderen ga ik geen extra problemen voor mijn klant creëren om het toch aan te zetten. Dan kies ik eieren voor mijn geld en geef ze daarom het advies om het lekker uit te zetten.

[Paul]

Roetzen schreef op maandag 12 oktober 2020 @ 14:15:
Ik denk dat je je klant daar mee op termijn geen dienst bewijst. Ik ben het eens met Snowking: het is struisvogelpolitiek en je kweekt daarmee juist meer legacy.

Uiteindelijk is het (hoop ik) aan de klant:
- Applicatie nu vervangen en IPv6 aan laten staan
- Applicatie vervangen volgens schema, en IPv6 uitzetten
Beide heeft uiteraard zijn eigen voors en tegens.

Op mijn werk hebben we applicaties die alleen al aan licenties meer dan een half miljoen kosten, en daar komt nog hardware, implementatie, migratie, training, etc. etc. bovenop. Dat was toch echt wel een dingetje bij de XP -> Windows 7, en daarna de Windows 7 -> 10 migratie. Geen idee wat ze met die applicaties gedaan hebben (ik zit niet in dat team), maar ik kan me bij dat soort applicaties prima voorstellen dat men besluit IPv6 uit te zetten als dat een probleem geeft, en er ook IPv4-connectiviteit naar die applicaties mogelijk is en blijft.

Uiteraard meld je dat aan de fabrikant in de hoop dat ze de problemen oplossen (bij voorkeur in een patch voor je huidige versie, en niet als feature in die nieuwe versie à €€€€€ ), maar hoe graag we dat in dit topic ook anders zouden zien, voor veruit de meeste bedrijven is IPv6 geen core business.