Het grote IPv6 topic

[Dreamvoid]

aawe mwan schreef op zondag 29 november 2020 @ 10:24:
Wat ik bijvoorbeeld verwacht had, was dat mijn computer gewoon standaard een "pooltje" aan IPv6 adressen zou krijgen van de router, die hij naar eigen inzicht zou kunnen verdelen over zijn virtuele machines, containers en ook de computers waarmee het internet gedeeld wordt. In plaats daarvan vraagt/krijgt (?) Ubuntu 20.04 maar 1 of 2 /64 IPv6 adressen van mijn router. Dat is toch veel te weinig?

Dat is exact hoe het werkt, je computer zou ook een pool moeten krijgen. Een /64 is alleen niet een enkel adres, dat is een compleet netwerk segment, waar je 2^64 adressen in kan hebben, dus dat is wel genoeg

Bij IPv6 beschrijft de eerste 64 bit het netwerk, de laatste 64 bit het device = een 128 bit adres. Je Ubuntu PC vraagt en krijgt de /64 prefix van de router, vertelt die aan de Pi zodra die zich meldt, en de Pi neemt die 64 bits, plakt daar zelf een zelfverzonnen 64-bit suffix aan vast, voila: een 128 bit IPv6 adres, plus een route naar het internet.

Probleem is hier dat je geen /64 van je router krijgt. Ubuntu vraagt er wel om, maar krijgt m niet. Veel standaard provider boxes doen geen prefix delegation aan de LAN kant, en veel (iets oudere) routers ook niet.

[ Voor 15% gewijzigd door Dreamvoid op 29-11-2020 21:47 ]

[aawe mwan]

@Dreamvoid @Muis666 : nu ik weet dat het "prefix delegation" heet wat ik mis, ben ik gaan zoeken op de website van de fabrikant van de router en het blijkt dat ik de volgende twee instellingen moest aanzetten:

1. Allow IPv6 prefixes announced by other IPv6 routers in the home network
2. Assign DNS server, prefix (IA_PD) and IPv6 address (IA_NA)

Na deze aanpassing in de router raakte de WiFi afdeling van Ubuntu 20.04 compleet van slag: hij probeerde het driftig maar hij kon geen verbinding meer maken. Gelukkig was dit opgelost met opnieuw opstarten.

En nu werkt het inderdaad: ik heb op de Raspberry Pi een werkend IPv4 adres en IPv6 adres met connectiviteit naar internet, als volgt te zien vanaf de Pi:

$ ip addr show eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether dc:a6:32:xx:yy:zz brd ff:ff:ff:ff:ff:ff
    inet 10.42.0.253/24 brd 10.42.0.255 scope global dynamic eth0
       valid_lft 2001sec preferred_lft 2001sec
    inet6 2001:uuuu:vvvv:fc:dea6:32ff:fexx:yyzz/64 scope global dynamic mngtmpaddr noprefixroute 
       valid_lft 5539sec preferred_lft 1939sec
    inet6 fe80::dea6:32ff:fexx:yyzz/64 scope link 
       valid_lft forever preferred_lft forever

Dat moet je dus wel even weten, voordat je het vinkje "Shared to other computers" aan zet bij IPv6.
Dank voor jullie verwijzing in de juiste richting!

[Dreamvoid]

Mooi dat het werkt! En hopelijk hebben andere mensen hier ook wat aan, dit gaat de komende jaren ws nog wel vaker langskomen.

[St00mwals]

Ik heb bij KPN de vraag neergelegd wanneer ze verwachten IPv6 te kunnen leveren op de nieuwe Box12:

Wordt aan gewerkt. In de loop van volgend jaar komt er een update aan waarna het beschikbaar is.

Toch jammer dat dat zo lang moet duren voor een nieuw apparaat is voorzien van IPv6.

[Lawrentium]

Ik ben op zoek naar een managed switch. Hoeft niets bijzonders te zijn, als deze maar VLAN's en IGMP snooping ondersteund. Mijn oog is gevallen op de bekende Netgear GS108E v3. Deze ondersteund alleen IPv6 passthrough. Wat betekend dit precies? Dat de management interface alleen via v4 werkt?

Het gaat mij er vooral om dat VLAN's op beide protocollen werken. IGMP snooping zal voorlopig een minder groot probleem zijn tenzij IPTV op korte termijn ook via v6 gaat.

[Snow_King]

Lawrentium schreef op dinsdag 1 december 2020 @ 11:50:
Ik ben op zoek naar een managed switch. Hoeft niets bijzonders te zijn, als deze maar VLAN's en IGMP snooping ondersteund. Mijn oog is gevallen op de bekende Netgear GS108E v3. Deze ondersteund alleen IPv6 passthrough. Wat betekend dit precies? Dat de management interface alleen via v4 werkt?

Het gaat mij er vooral om dat VLAN's op beide protocollen werken. IGMP snooping zal voorlopig een minder groot probleem zijn tenzij IPTV op korte termijn ook via v6 gaat.

Wat zijn je verdere eisen? Je kan kijken naar een HP Aruba J9775A. Doet SSH en SNMP over IPv6. Gebruiken wij op het werk heel veel als edge-switches en beheren ze enkel via IPv6.

Of een refurbished Juniper EX3200-48T. Die koop je al voor 90 euro.

[jk-5]

Lawrentium schreef op dinsdag 1 december 2020 @ 11:50:
Ik ben op zoek naar een managed switch. Hoeft niets bijzonders te zijn, als deze maar VLAN's en IGMP snooping ondersteund. Mijn oog is gevallen op de bekende Netgear GS108E v3. Deze ondersteund alleen IPv6 passthrough. Wat betekend dit precies? Dat de management interface alleen via v4 werkt?

Het gaat mij er vooral om dat VLAN's op beide protocollen werken. IGMP snooping zal voorlopig een minder groot probleem zijn tenzij IPTV op korte termijn ook via v6 gaat.

Mijn ervaringen met de GS108Ev3 zijn vrij slecht. Ik heb zo'n 10 van die dingen bij verschillende mensen liggen. Na verloop van tijd loopt de cpu vast waardoor de management interface niet bereikbaar is. Zelfs al eens meegemaakt dat bepaalde poorten stoppen met forwarden wat alleen door reboot gefixt kan worden.

Ik ben zelf erg enthousiast over de zyxel 1900-8, maar die is wel wat duurder

[Lawrentium]

Snow_King schreef op dinsdag 1 december 2020 @ 12:17:
[...]

Wat zijn je verdere eisen? Je kan kijken naar een HP Aruba J9775A. Doet SSH en SNMP over IPv6. Gebruiken wij op het werk heel veel als edge-switches en beheren ze enkel via IPv6.

Meer eisen heb ik niet. Het is gewoon voor thuisgebruik, om IoT en IPTV apparaten te scheiden via verschillende VLAN's.

jk-5 schreef op dinsdag 1 december 2020 @ 12:23:
[...]


Mijn ervaringen met de GS108Ev3 zijn vrij slecht. Ik heb zo'n 10 van die dingen bij verschillende mensen liggen. Na verloop van tijd loopt de cpu vast waardoor de management interface niet bereikbaar is. Zelfs al eens meegemaakt dat bepaalde poorten stoppen met forwarden wat alleen door reboot gefixt kan worden.

Wanneer gebeuren deze vastlopers? Bij het benaderen van de management interface? Of zelfs tijdens normaal gebruik?

[Snow_King]

Lawrentium schreef op dinsdag 1 december 2020 @ 12:32:
[...]

Meer eisen heb ik niet. Het is gewoon voor thuisgebruik, om IoT en IPTV apparaten te scheiden via verschillende VLAN's.

Ah, ok. Ik werk in een datacenter business en kom dus eerder met die switches in contact.

Heb je anders al gekeken naar spullen van MikroTik?

[jk-5]

Lawrentium schreef op dinsdag 1 december 2020 @ 12:32:
[...]

Meer eisen heb ik niet. Het is gewoon voor thuisgebruik, om IoT en IPTV apparaten te scheiden via verschillende VLAN's.


[...]

Wanneer gebeuren deze vastlopers? Bij het benaderen van de management interface? Of zelfs tijdens normaal gebruik?

Ook tijdens normaal gebruik. Als je hem een aantal maanden (soms zelfs weken) aan hebt staan gaat er vanzelf iets stuk

[Jef61]

jk-5 schreef op dinsdag 1 december 2020 @ 12:38:
[...]


Ook tijdens normaal gebruik. Als je hem een aantal maanden (soms zelfs weken) aan hebt staan gaat er vanzelf iets stuk

Misschien een keertje de firmware updaten?
Ik heb in het begin idd wel eens vastlopers gehad op het management maar na firmware update draaien de twee van mij probleemloos. Zitten nu op firmware 2.06.14

IPv6 is verder geen probleem, management doet alleen IPv4.

[Lawrentium]

Jef61 schreef op dinsdag 1 december 2020 @ 13:01:
[...]
IPv6 is verder geen probleem, management doet alleen IPv4.

Ook in combinatie met VLAN's etc?

[jk-5]

Jef61 schreef op dinsdag 1 december 2020 @ 13:01:
[...]

Misschien een keertje de firmware updaten?
Ik heb in het begin idd wel eens vastlopers gehad op het management maar na firmware update draaien de twee van mij probleemloos. Zitten nu op firmware 2.06.14

IPv6 is verder geen probleem, management doet alleen IPv4.

Ja goed punt, als dat het oplost neem ik terug wat ik heb gezegd.

Lawrentium schreef op dinsdag 1 december 2020 @ 13:11:
[...]

Ook in combinatie met VLAN's etc?

Een switch werkt tussen de poorten volledig op layer 2, en ipv4/ipv6 is een layer 3 ding. Daarom ondersteunt deze switch zonder enige moeite ipv6 (of ipv7). De management interface is alleen benaderbaar vanaf ipv4

[Jef61]

Lawrentium schreef op dinsdag 1 december 2020 @ 13:11:
[...]

Ook in combinatie met VLAN's etc?

Geen probleem, zoals @jk-5 al geantwoord heeft speelt vlan zich af op laag 2.
@Lawrentium Let wel op, het is een switch, routeren tussen de vlans kan ie niet.

[ Voor 14% gewijzigd door Jef61 op 01-12-2020 13:34 ]

[Lawrentium]

Jef61 schreef op dinsdag 1 december 2020 @ 13:25:
[...]


Geen probleem, zoals @jk-5 al geantwoord heeft speelt vlan zich af op laag 2.
@Lawrentium Let wel op, het is een switch, routeren tussen de vlans kan ie niet.

Uiteraard Daar hebben we een router voor. Ik denk dat voor mijn gebruik de GS108E volstaat. Bedankt voor de antwoorden.

[Snow_King]

Ik heb bij Ziggo ineens een nieuw IPv4 adres en een nieuw IPv6 subnet gekregen. Hebben andere mensen dit ook al eens mee gemaakt?

Ik dacht dat het v6 subnet wel redelijk stabiel was.

[Roetzen]

Snow_King schreef op donderdag 3 december 2020 @ 10:20:
Ik heb bij Ziggo ineens een nieuw IPv4 adres en een nieuw IPv6 subnet gekregen. Hebben andere mensen dit ook al eens mee gemaakt?

Het IPv4 adres verandert zeer zelden. In principe alleen als het MAC adres van de CPE verandert, Maar op 24 oktober j.l. veranderde het spontaan toen midden in de nacht de netspaning in de wijk een paar uur uitviel en de voeding van mijn coax versterker het begaf, vermoedelijk bij het weer inkomen. Bij het terugkomen van de netspanning kreeg het modem daardoor geen signaal en bleef het maar proberen totdat ik het ontdekte en het probleem oploste. Dat uren lang zonder signaal was kennelijk een trigger voor een nieuw IPv4 adres.

Ik dacht dat het v6 subnet wel redelijk stabiel was.

Dat is het ook wel, maar het verandert toch wel af en toe spontaan. Soms met een zichtbare aanleiding, bijvoorbeeld een firmware update of een spanningsonderbreking, soms zonder zichtbare aanleiding. Ik heb het bij gehouden. Ik heb dit modem sinds maart 2019 en sindsdien is het acht maal gebeurd dat ik een nieuwe IPv6 prefix kreeg.

[Snow_King]

Roetzen schreef op donderdag 3 december 2020 @ 11:56:
[...]

Dat is het ook wel, maar het verandert toch wel af en toe spontaan. Soms met een zichtbare aanleiding, bijvoorbeeld een firmware update of een spanningsonderbreking, soms zonder zichtbare aanleiding. Ik heb het bij gehouden. Ik heb dit modem sinds maart 2019 en sindsdien is het acht maal gebeurd dat ik een nieuwe IPv6 prefix kreeg.

8x is best wel veel eigenlijk. Jammer. Want ik heb nogal wat DNS entries er naartoe verwijzen. Mijn vorige ISP (Delta/ZeelandNet) zette je /48 vast op het modem zijn MAC en veranderde dan nooit. Je kon ze zelfs vragen het subnet mee te nemen als je een nieuw modem kreeg.

[jk-5]

Roetzen schreef op donderdag 3 december 2020 @ 11:56:
[...]

Dat is het ook wel, maar het verandert toch wel af en toe spontaan. Soms met een zichtbare aanleiding, bijvoorbeeld een firmware update of een spanningsonderbreking, soms zonder zichtbare aanleiding. Ik heb het bij gehouden. Ik heb dit modem sinds maart 2019 en sindsdien is het acht maal gebeurd dat ik een nieuwe IPv6 prefix kreeg.

Die acht keer is wel erg veel. Ik woon hier nu anderhalf jaar en heb nu nog steeds exact dezelfde prefix als anderhalf jaar geleden. Zelfs toen ik ben omgezet van DS-Lite naar full dualstack is mijn ipv6 prefix gelijk gebleven. Het heeft zoals je beschreef waarschijnlijk te maken met stabiliteit van de verbinding in de wijk, of andere factoren die wij niet zien.

Ziggo is namelijk de laatste jaren bezig alle CMTSes te vervangen door nieuwe varianten (om Docsis 3.1 te kunnen ondersteunen). Daarbij heb ik wel eens meegemaakt dat alle ipv4 en ipv6 prefixes veranderden, waarschijnlijk omdat ze segment voor segment de boel omhingen van de oude naar de nieuwe CMTS.

[Roetzen]

Snow_King schreef op donderdag 3 december 2020 @ 13:58:
[...]
8x is best wel veel eigenlijk. Jammer. Want ik heb nogal wat DNS entries er naartoe verwijzen.

Ik heb ook nogal wat werk iedere keer als het verandert. Best hinderlijk inderdaad. Maar het is ook weer net te weinig om zo hinderlijk te zijn om gemotiveerd te zijn om er tijd in te steken om het te automatiseren.

Mijn vorige ISP (Delta/ZeelandNet) zette je /48 vast op het modem zijn MAC en veranderde dan nooit. Je kon ze zelfs vragen het subnet mee te nemen als je een nieuw modem kreeg.

Ik zou graag zien dat Ziggo dat ook zo deed. Met een IPv6 prefix die technisch gezien dynamisch is, maar in de praktijk net zo statisch is als het IPv4 adres kan ik best leven...

Maar waarom ben je eigenlijk weg gegaan bij Zeelandnet?

jk-5 schreef op donderdag 3 december 2020 @ 14:15:
[...]
Die acht keer is wel erg veel. Ik woon hier nu anderhalf jaar en heb nu nog steeds exact dezelfde prefix als anderhalf jaar geleden. Zelfs toen ik ben omgezet van DS-Lite naar full dualstack is mijn ipv6 prefix gelijk
gebleven.

Ik had er natuurlijk meteen bij moeten zeggen dat ik in fZiggo gebied zit. Dat zou best verschil kunnen maken.

Het heeft zoals je beschreef waarschijnlijk te maken met stabiliteit van de verbinding in de wijk, of andere factoren die wij niet zien.

Ziggo is namelijk de laatste jaren bezig alle CMTSes te vervangen door nieuwe varianten (om Docsis 3.1 te kunnen ondersteunen). Daarbij heb ik wel eens meegemaakt dat alle ipv4 en ipv6 prefixes veranderden, waarschijnlijk omdat ze segment voor segment de boel omhingen van de oude naar de nieuwe CMTS.

Hier (Driebergen) zijn meer dan een jaar geleden de versterkers en verdelers in de straatkasten al vervangen in voorbereiding op DOCSIS 3.1.. Ik vermoed de CMTS ook al, maar dat is een aanname, geen vastgesteld feit. DOCSUS 3.1 wordt hier nog niet aangeboden, maar dat zegt verder niet zo veel.

Het beleid van Ziggo ten aanzien van het veranderen van IPv6 pefix is ondoorgrondelijk. Ik kan er geen touw aan vast knopen. Soms geeft een soft restart van het modem een nieuwe prefix, soms ook niet. Soms geeft een power down een nieuwe prefix, soms niet. Soms verandert het spontaan. Schiet mij maar lek...

[Paul]

Snow_King schreef op donderdag 3 december 2020 @ 13:58:
ik heb nogal wat DNS entries er naartoe verwijzen

Ik heb daarvoor een dynamic dns dienst ingeregeld (bij DNSExit geloof ik). Al heb ik vijf jaar geleden op mijn (toen) nieuwe router geen DynDNS-client heb gezet, dus blijkbaar verandert mijn IP niet zo vaak

[Snow_King]

Paul schreef op donderdag 3 december 2020 @ 16:20:
[...]
Ik heb daarvoor een dynamic dns dienst ingeregeld (bij DNSExit geloof ik). Al heb ik vijf jaar geleden op mijn (toen) nieuwe router geen DynDNS-client heb gezet, dus blijkbaar verandert mijn IP niet zo vaak

Ik draai enkele Virtual Machines en Docker containers thuis. Die moet ik nu allemaal opnieuw configgen. Dat is zonde van het werk.

DNS draai ik zelf op een VM in Amsterdam, moet ik dus weer even uit gaan zoeken.

[aawe mwan]

Snow_King schreef op donderdag 3 december 2020 @ 18:19:
[...]
Ik draai enkele Virtual Machines en Docker containers thuis. Die moet ik nu allemaal opnieuw configgen. Dat is zonde van het werk.

Kan je niet een Ansible playbook maken om de IPv6 configuratie naar die machines door te zetten?

(De voorwaarde om Ansible te kunnen gebruiken is dat ze nog wel per SSH bereikbaar zijn vanaf de machine waar je het playbook op draait.)

[Dreamvoid]

Wees blij dat we niet in Duitsland zitten, daar moeten de providers de prefixes verplicht regelmatig wijzigen, uit privacy oogpunt. Dat is mooi, maar wel hoofdpijn voor thuishosters.

[Maurits van Baerle]

Dreamvoid schreef op donderdag 3 december 2020 @ 22:32:
Wees blij dat we niet in Duitsland zitten, daar moeten de providers de prefixes verplicht regelmatig wijzigen, uit privacy oogpunt. Dat is mooi, maar wel hoofdpijn voor thuishosters.

Dat wist ik niet, vervelend voor thuishosters inderdaad maar wel mooi vanuit een privacy oogpunt.

Nou bieden IPv6 Privacy Extensions je al vrij goede privacy maar dit is een aardig schepje er bovenop.

[overhyped]

Dreamvoid schreef op donderdag 3 december 2020 @ 22:32:
Wees blij dat we niet in Duitsland zitten, daar moeten de providers de prefixes verplicht regelmatig wijzigen, uit privacy oogpunt. Dat is mooi, maar wel hoofdpijn voor thuishosters.

Het zou toch mooi zijn als er een soort automatische vertaling was van ip adressen naar handige namen. en als dan een router ook nog eens automatisch een deel van z'n allocatie door kan sturen naar een andere router.

Mischien moeten we het "Domain Name System" noemen om die namen te vertalen naar adressen, en dan kunnen we het andere mischien "prefix deligation" noemen, omdat een prefix zeg maar "deligated" kan worden..

[Snow_King]

aawe mwan schreef op donderdag 3 december 2020 @ 18:29:
[...]


Kan je niet een Ansible playbook maken om de IPv6 configuratie naar die machines door te zetten?

(De voorwaarde om Ansible te kunnen gebruiken is dat ze nog wel per SSH bereikbaar zijn vanaf de machine waar je het playbook op draait.)

Uiteraard mogelijk. Vanmorgen uiteindelijk 17 DNS records om moeten zetten. Best vervelend.

In een ideale situatie zou ik zelfs BGP praten met mijn ISP en mijn eigen /48 adverteren naar mijn ISP. Dat is alleen niet echt betaalbaar voor een thuis verbinding.

overhyped schreef op vrijdag 4 december 2020 @ 12:19:
[...]


Het zou toch mooi zijn als er een soort automatische vertaling was van ip adressen naar handige namen. en als dan een router ook nog eens automatisch een deel van z'n allocatie door kan sturen naar een andere router.

Mischien moeten we het "Domain Name System" noemen om die namen te vertalen naar adressen, en dan kunnen we het andere mischien "prefix deligation" noemen, omdat een prefix zeg maar "deligated" kan worden..

Een IP-wijziging is ook niet erg, daar is DNS ook voor. Het is wel irritant als het plots gebeurd en je dus alles moet omnummeren.

Ik heb thuis nu eenmaal een 19" rack met daar in een NAS + Server waarop ik diverse VM's draai. Die wil ik vanaf buiten kunnen bereiken.

[elsinga]

Om dit soort praktijken doe ik ddns op mijn eigen domeinen. Kwartier na een wijziging staat nieuwe IP in de nameserver, TTL is 1 uur, dus na max een uur en een kwartier werkt alles weer.

[Dreamvoid]

overhyped schreef op vrijdag 4 december 2020 @ 12:19:
Het zou toch mooi zijn als er een soort automatische vertaling was van ip adressen naar handige namen. en als dan een router ook nog eens automatisch een deel van z'n allocatie door kan sturen naar een andere router.

Mischien moeten we het "Domain Name System" noemen om die namen te vertalen naar adressen, en dan kunnen we het andere mischien "prefix deligation" noemen, omdat een prefix zeg maar "deligated" kan worden..

Haha natuurlijk is dat er al, maar DNS werkt toch niet zo heel lekker met instabiele prefixes/adressen, dan moet je weer een DDNS systeem gaan optuigen, liever doen mensen dat toch niet.

[ANdrode]

Dreamvoid schreef op vrijdag 4 december 2020 @ 16:58:
[...]

Haha natuurlijk is dat er al, maar DNS werkt toch niet zo heel lekker met instabiele prefixes/adressen, dan moet je weer een DDNS systeem gaan optuigen, liever doen mensen dat toch niet.

Terraform met één van de ondersteunde DNS providers to the rescue

offtopic:
Maar serieus: Veel records updaten is wel ideaal via dat mechanisme

[elsinga]

Bij mij worden voor 3 domains elk 1 A record geupdate, de rest van de entries zijn een ALIAS voor die records. De <domain> wijzigt per DDNS en www.<domain> volgt wel.

[Roetzen]

elsinga schreef op zaterdag 5 december 2020 @ 09:53:
Bij mij worden voor 3 domains elk 1 A record geupdate, de rest van de entries zijn een ALIAS voor die records. De <domain> wijzigt per DDNS en www.<domain> volgt wel.

Voor alleen IPv4 is het niet zo moeilijk. Maar bij IPv6 heb je al gauw veel meer dan één adres in gebruik en vaak ook navenant veel hostnamen. Dat los je niet op met een paar aliassen.

[elsinga]

Klopt. Mijn situatie is redelijk eenvoudig: thuis een NAS die ook als webserver dienst doet voor een beperkt aantal sites. Ook voor IPv6 (wat ik helaas niet heb, want Ziggo met Connectbox in bridge... ) zou dat net zo eenvoudig zijn, want als ik al extra apparatuur vanaf buiten wil benaderen, dan loopt dat nog steeds door mijn reverse proxy. Net als nu met IPv4 trouwens.

Heb je in een netwerk echter meer apparatuur die via IPv6 direct benaderbaar moet/wil/kan zijn, dan heb je meer ddns entries nodig. Kan bij mijn dns provider overigens prima, maar is meer werk. Met name omdat elk apparaat zijn eigen ddns query moet doen (bij mijn dns provider is dat een HTTP GET naar een speciale URL en het IP adres wat de dns provider dan ziet wordt het A/AAAA record)..

[Roetzen]

elsinga schreef op zaterdag 5 december 2020 @ 13:18:
Klopt. Mijn situatie is redelijk eenvoudig: thuis een NAS die ook als webserver dienst doet voor een beperkt aantal sites. Ook voor IPv6 (wat ik helaas niet heb, want Ziggo met Connectbox in bridge... )

Tja, als je zelf geen IPv6 hebt wodt het minder makkelijk meepraten...

Heb je in een netwerk echter meer apparatuur die via IPv6 direct benaderbaar moet/wil/kan zijn, dan heb je meer ddns entries nodig. Kan bij mijn dns provider overigens prima, maar is meer werk. Met name omdat elk apparaat zijn eigen ddns query moet doen (bij mijn dns provider is dat een HTTP GET naar een speciale URL en het IP adres wat de dns provider dan ziet wordt het A/AAAA record)..

Daar zitten toch nog wel een paar addertjes onder het gras. Om te beginnen zal niet ieder device waar je eventueel een hostnaam aan zou willen koppelen een HTTP GET kunnen uitvoeren. Voor een PC, tablet of smart phone zal het wel lukken, maar ik heb geen idee hoe ik mijn RIPE ATLAS probe zo ver zou kunnen krijgen. In dit geval geen probleem want RIPE zorgt voor een hostnaam gekoppeld aan het probe nummer, dus daar kan ik een ALIAS aan koppelen. Maar als ik nog een een slimme koelkast of een bewakingscamera krijg, hoe ga ik dat oplossen?

Verder heeft bij IPv6 een device of nauwkeuriger gezegd een interface meestal meerder publieke adressen. Het adres waarmee het een uitgaande verbinding maakt is lang niet altijd het adres waarop ik het wil benaderen.

In plaats van elk device afzonderlijk de DDNS procedure te laten doorlopen zou je eigenlijk voor het hele 2nd level domain in één klap van alle in gebruik zijnde adressen het prefix gedeelte willen aanpassen. Dat is namelijk wat verandert als je van je provider een nieuwe prefix krijgt, de rest verandert gewoonlijk niet.

[darkrain]

Vorige week ineens een nieuwe IPv6 prefix gekregen van Ziggo, waardoor het internet slecht functioneerde. Dit gedeeltelijk op kunnen lossen door de eigen router achter het Ziggo modem te herstarten, maar bleef niet top.

Dit kwam door de firewall regels welke de oude prefix ingesteld hadden, hoe gaan jullie hiermee om?
Na het aanpassen draait nu alles weer als een zonnetje, maar toch wel een aandachtspunt..

[Snow_King]

Hier weer een nieuwe prefix! Mijn IPv6 werkte deze ochtend niet meer. Ik op het modem inloggen, zie ik ineens het UPC logo staan.

Modem een herstart gegeven, heb ik weer een nieuwe prefix. Super fijn dit van Ziggo.

[Brahiewahiewa]

darkrain schreef op maandag 7 december 2020 @ 09:38:
Vorige week ineens een nieuwe IPv6 prefix gekregen van Ziggo, waardoor het internet slecht functioneerde. Dit gedeeltelijk op kunnen lossen door de eigen router achter het Ziggo modem te herstarten, maar bleef niet top.

Dit kwam door de firewall regels welke de oude prefix ingesteld hadden, hoe gaan jullie hiermee om?
Na het aanpassen draait nu alles weer als een zonnetje, maar toch wel een aandachtspunt..

Geen firewall draaien ;o)
Met de komst van ipv6 veranderen de paradigma's op het gebied van netwerken. Er is geen NAT meer. Er zijn privacy extensions. En je prefix kan dus zomaar opeens veranderen
De doorsnee windows, mac of linux machine kan hier prima mee omgaan. Maar de archaïsche firewall niet, idd
Dus het wordt tijd om die te updaten naar iets wat aan de moderne maatstaven kan voldoen, of om te besluiten dat je geen centrale firewall meer nodig hebt

[darkrain]

Brahiewahiewa schreef op maandag 7 december 2020 @ 10:09:
[...]

Geen firewall draaien ;o)
Met de komst van ipv6 veranderen de paradigma's op het gebied van netwerken. Er is geen NAT meer. Er zijn privacy extensions. En je prefix kan dus zomaar opeens veranderen
De doorsnee windows, mac of linux machine kan hier prima mee omgaan. Maar de archaïsche firewall niet, idd
Dus het wordt tijd om die te updaten naar iets wat aan de moderne maatstaven kan voldoen, of om te besluiten dat je geen centrale firewall meer nodig hebt

Ehm, ik heb diverse VLAN's en daartussen zit een firewall. Dat gaat niet veranderen met de komst van IPv6, die firewall blijft. Simpelweg vanwege het feit dat er geen toegang moet zijn tussen sommige VLAN's en anderen weer wel (IoT hoeft niet bij mijn NAS bijvoorbeeld).

Ben toch benieuwd op welke moderne manier ik dit dan zou moeten doen...

[Keiichi]

Volgens mij zou het veranderen van de prefix (v6 subnet) hetzelfde zijn als het veranderen van je ipv4 subnet. Als m'n netwerk hier opeens veranderd, dan zal m'n netwerk in ieder geval voor de leaseduur van een IP adres van dhcp lichtelijk bokken.
Heb met v6 het ook gehad, m'n netwerk een andere prefix gegeven, m'n systemen hadden toen opeens adressen in 2 subnets. Dat zorgde ook voor onderbrekingen, omdat het oude subnet niet routable meer gemaakt had.

[overhyped]

darkrain schreef op maandag 7 december 2020 @ 10:24:
[...]

Ehm, ik heb diverse VLAN's en daartussen zit een firewall. Dat gaat niet veranderen met de komst van IPv6, die firewall blijft. Simpelweg vanwege het feit dat er geen toegang moet zijn tussen sommige VLAN's en anderen weer wel (IoT hoeft niet bij mijn NAS bijvoorbeeld).

Ben toch benieuwd op welke moderne manier ik dit dan zou moeten doen...

De 2020 manier is natuurlijk om naar zero trust te kijken: waar het netwerk niet meer een factor is voor beveiliging. Maar dat is vaak een bridge to far. Wat nu wel zou moeten kunnen is niet op basis van fixed prefix rules maken, maar op basis van <deligatie>:subnetbits. Dan veranderen de rules automatisch mee met de prefix.

En als jouw firewall dat niet ondersteund dan is die niet helemaal geschikt voor een IPv6 netwerk met prefix delegation.

[darkrain]

overhyped schreef op maandag 7 december 2020 @ 10:35:
[...]


De 2020 manier is natuurlijk om naar zero trust te kijken: waar het netwerk niet meer een factor is voor beveiliging. Maar dat is vaak een bridge to far. Wat nu wel zou moeten kunnen is niet op basis van fixed prefix rules maken, maar op basis van <deligatie>:subnetbits. Dan veranderen de rules automatisch mee met de prefix.

En als jouw firewall dat niet ondersteund dan is die niet helemaal geschikt voor een IPv6 netwerk met prefix delegation.

Firewall is een Unifi USG, zal eens onderzoeken of dat gaat. Dank je wel voor de hint.

[xbeam]

darkrain schreef op maandag 7 december 2020 @ 10:52:
[...]

Firewall is een Unifi USG, zal eens onderzoeken of dat gaat. Dank je wel voor de hint.

De usg kan ipv6 prefix alleen werkt de standaard gui configure niet met KPN ( pppoe vage sizzel) je moet daar dus een aanpassing via de json configure doen

[Dreamvoid]

darkrain schreef op maandag 7 december 2020 @ 09:38:
Dit kwam door de firewall regels welke de oude prefix ingesteld hadden, hoe gaan jullie hiermee om?
Na het aanpassen draait nu alles weer als een zonnetje, maar toch wel een aandachtspunt..

Firewall regels zijn inderdaad een dingetje, zowel vanwege dynamische prefixes als veranderende device id's. Bij bedrijfsnetwerken is de prefix altijd wel constant, maar bij consumenten is dat geen garantie.

Met SLAAC zit je sowieso met Privacy Extension adressen waar de device id elke 24u verandert, en nu tegenwoordig elk OS (Linux, Android, Windows, macOS, iOS) is afgestapt van EUI-64 en in plaats daarvan 'opaque' stable adressen maakt (RFC7217, of vergelijkbaar) betekent een nieuwe prefix ook automatisch een nieuwe device id. Hier wordt al veel over geklaagd, bij pfSense bijvoorbeeld: https://redmine.pfsense.org/issues/6626

Eigenlijk twee opties:
- een firewall waar je wildcards voor the prefix kan instellen, en dan de device id's constant houden door ofwel adressen centraal uitdelen met DHCPv6, ofwel handmatig op elk device een static token (een constante device id) instellen of terug forceren naar EUI-64.
- een firewall die rules kan maken op basis van MAC adres, dat blijft namelijk wel altijd gelijk, wat je prefix of device id ook is. Nadeel: werkt alleen binnen een /64 segment, zodra er een router tussen zit ziet de firewall het source-MAC adres niet meer.

[ Voor 8% gewijzigd door Dreamvoid op 07-12-2020 11:30 ]

[jk-5]

xbeam schreef op maandag 7 december 2020 @ 11:04:
[...]


De usg kan ipv6 prefix alleen werkt de standaard gui configure niet met KPN ( pppoe vage sizzel) je moet daar dus een aanpassing via de json configure doen

Voor zover ik weet ondersteunt de PPPoE client implementatie in UniFi en EdgeOS uberhaupt geen ipv6. In Unifi dus ook niet met custom json config. Als ik geen gelijk heb hoor ik het graag.

Ik heb dit weekend trouwens ook een raar ding meegemaakt met DHCPv6-PD bij ziggo. Ziggo geeft een /56 aan het modem waarvan hij zelf de eerste /60 reserveert, waarvan het 'normale' netwerk de eerste /64 krijgt. Daarmee zijn er nog 15 /60s over.

Mijn eigen (oude) router kreeg de laatste /60 van de modem. Ik heb een nieuwe router (Mikrotik RB4011) en dacht hem er gewoon naast te kunnen hangen, en daarop ook dhcpv6-pd te activeren zodat beide routers een prefix hadden. Deze sessie kwam niet up. Toen ik wireshark ertussen hing bleek dat het modem zei 'No more prefixes available'.

Het blijkt dus dat ziggo (in ieder geval op de Arris connectbox) maar 1 /60 prefix kan uitdelen. Daarmee houd je in feite 14 /60s ongebruikt op je modem. De enige manier om en werkende prefix op de nieuwe router te krijgen was het releasen van de dhcpv6-pd lease op de oude router.

[Dreamvoid]

jk-5 schreef op maandag 7 december 2020 @ 11:22:
[...]
Het blijkt dus dat ziggo (in ieder geval op de Arris connectbox) maar 1 /60 prefix kan uitdelen. Daarmee houd je in feite 14 /60s ongebruikt op je modem. De enige manier om en werkende prefix op de nieuwe router te krijgen was het releasen van de dhcpv6-pd lease op de oude router.

Raar eigenlijk - is daar een reden voor te bedenken?

[jk-5]

Dreamvoid schreef op maandag 7 december 2020 @ 11:23:
[...]

Raar eigenlijk - is daar een reden voor te bedenken?

Ja dat heb ik me ook al zitten afvragen. Ik kan geen geldige reden bedenken. In de tijd dat de ziggo modems nog /59s uitdeelden (inmiddels al een paar jaar geleden) kon je zonder problemen extra prefixes aanvragen

[xbeam]

jk-5 schreef op maandag 7 december 2020 @ 11:22:
[...]


Voor zover ik weet ondersteunt de PPPoE client implementatie in UniFi en EdgeOS uberhaupt geen ipv6. In Unifi dus ook niet met custom json config. Als ik geen gelijk heb hoor ik het graag.

Ik heb dit weekend trouwens ook een raar ding meegemaakt met DHCPv6-PD bij ziggo. Ziggo geeft een /56 aan het modem waarvan hij zelf de eerste /60 reserveert, waarvan het 'normale' netwerk de eerste /64 krijgt. Daarmee zijn er nog 15 /60s over.

Mijn eigen (oude) router kreeg de laatste /60 van de modem. Ik heb een nieuwe router (Mikrotik RB4011) en dacht hem er gewoon naast te kunnen hangen, en daarop ook dhcpv6-pd te activeren zodat beide routers een prefix hadden. Deze sessie kwam niet up. Toen ik wireshark ertussen hing bleek dat het modem zei 'No more prefixes available'.

Het blijkt dus dat ziggo (in ieder geval op de Arris connectbox) maar 1 /60 prefix kan uitdelen. Daarmee houd je in feite 14 /60s ongebruikt op je modem. De enige manier om en werkende prefix op de nieuwe router te krijgen was het releasen van de dhcpv6-pd lease op de oude router.

Alstublieft voor de edge en de usg json

code:

configure
 
set interfaces ethernet eth0 vif 6 pppoe 0 ipv6 enable
set interfaces ethernet eth0 vif 6 pppoe 0 ipv6 address autoconf
set interfaces ethernet eth0 vif 6 pppoe 0 ipv6 dup-addr-detect-transmits 1
 
set interfaces ethernet eth0 vif 6 pppoe 0 dhcpv6-pd no-dns
set interfaces ethernet eth0 vif 6 pppoe 0 dhcpv6-pd pd 0 interface eth1 prefix-id :1
set interfaces ethernet eth0 vif 6 pppoe 0 dhcpv6-pd pd 0 interface eth1 service slaac
set interfaces ethernet eth0 vif 6 pppoe 0 dhcpv6-pd pd 0 prefix-length /48
set interfaces ethernet eth0 vif 6 pppoe 0 dhcpv6-pd rapid-commit disable
 
set protocols static interface-route6 ::/0 next-hop-interface pppoe0
 
commit
save
exit

De unifi usg heeft zeker wel ipv6 en firewall vanuit de controller.
Alleen de pppoe moet je even handmatig fixen.

Je moet zel alleen nog even de regels maken voor je firewall binding

code:

set interfaces ethernet eth0 vif 6 pppoe 0 firewall in ipv6-name WANv6_IN ([b]deze opeen usg anders [/b] 
set interfaces ethernet eth0 vif 6 pppoe 0 firewall local ipv6-name WANv6_LOCAL ([b]deze opeen usg anders [/b]

[ Voor 12% gewijzigd door xbeam op 07-12-2020 11:34 ]

[overhyped]

Je kan je ook afvragen of devices met een verschillende security policy in het zelfde subnet moeten.

Wanneer alleen inbound 80 en 443 open moeten naar een subnet, dan is het device is in eens niet meer boeiend. Net als met outbound: andere policy, ander subnet.

End user tracking kan dan met een combinatie van 802.1x aan de user kant met het loggen van de IP/user combinaties. Eventuele kan je (afhankelijk van welke netwerk vendor die je gebruikt) iets als trustsec gebruiken om niet op IP adressen te hoeven filteren.

Hoe lang het duurt is natuurlijk de vraag, maar de tijd van IP adressen gebruiken als security entitlement is wel eindig.

Dreamvoid schreef op maandag 7 december 2020 @ 11:15:
[...]

Firewall regels zijn inderdaad een dingetje, zowel vanwege dynamische prefixes als veranderende device id's. Bij bedrijfsnetwerken is de prefix altijd wel constant, maar bij consumenten is dat geen garantie.

Met SLAAC zit je sowieso met Privacy Extension adressen waar de device id elke 24u verandert, en nu tegenwoordig elk OS (Linux, Android, Windows, macOS, iOS) is afgestapt van EUI-64 en in plaats daarvan 'opaque' stable adressen maakt (RFC7217, of vergelijkbaar) betekent een nieuwe prefix ook automatisch een nieuwe device id. Hier wordt al veel over geklaagd, bij pfSense bijvoorbeeld: https://redmine.pfsense.org/issues/6626

Eigenlijk twee opties:
- een firewall waar je wildcards voor the prefix kan instellen, en dan de device id's constant houden door ofwel adressen centraal uitdelen met DHCPv6, ofwel handmatig op elk device een static token (een constante device id) instellen of terug forceren naar EUI-64.
- een firewall die rules kan maken op basis van MAC adres, dat blijft namelijk wel altijd gelijk, wat je prefix of device id ook is. Nadeel: werkt alleen binnen een /64 segment, zodra er een router tussen zit ziet de firewall het source-MAC adres niet meer.

[Dreamvoid]

overhyped schreef op maandag 7 december 2020 @ 12:59:
Hoe lang het duurt is natuurlijk de vraag, maar de tijd van IP adressen gebruiken als security entitlement is wel eindig.

Het was zelfs met IPv4 al risky, immers - je kan triviaal elk willkeurig IPv4 adres instellen voor je devices. Maar goed, veel hobby/thuis spul werkt met IP-adres rules.

De IPv6 firewall in mijn provider box is echt waardeloos overigens. Je kan geen IPv6 adressen invullen, enkel uit de lijst van devices kiezen. Die dynamische lijst wordt bijgehouden op basis van IPv6 adressen die de router ziet langskomen, oftewel: elk device staat erin met zijn Privacy Extensions adres van vandaag. Je kan wel raden wat er na 24u gebeurt: juist ja, de firewall rule is niet meer geldig. Oplossing: Privacy Extensions uitschakelen op het device, dan de firewall rule aanmaken in de router, en PE weer aanzetten.

[Raven]

Weet iemand hoe het met ondersteuning van IPv6 is gesteld in Android 8 (Galaxy S7)? Ik heb ooit eens IPv6 geprobeerd op een van mijn vorige telefoons (S4/S2) maar van wat ik mij kan herinneren werkte IPv6 zó goed onder Android, dat ik die op wifi uit had geschakeld omdat je dat onder Android niet kan doen.

Sinds kort heb ik een /48 en heb de 4 verschillende netwerken elk hun eigen /64 gegeven in radvd.conf. Alle niet-Android apparaten werken (weer) prima met IPv6, mijn S7 niet echt.

Ik zie nog wel eens timeouts en langere laadtijden sinds IPv6 actief is, wat volgens Google 2 dingen zouden kunnen zijn:
- Het blokkeren van ICMPv6, niet het geval:

code:

add rule ip6 filter input meta l4proto ipv6-icmp counter accept
add rule ip6 filter forward meta l4proto ipv6-icmp counter accept
add rule ip6 filter output meta l4proto ipv6-icmp counter accept

- Geen RDNSS optie in radvd.conf, staat er wel degelijk in, met IPv6 adres van RPi met PiHole.

Alle apparaten waar ik de DNS servers op kan vragen, geven (zoals verwacht) zowel het IPv4 als IPv6 adres van de RPi met Pi-Hole weer als DNS servers, onder Android kan ik in verschillende netwerkinfo-apps alleen het IPv4 adres terugvinden, geen vermelding van een IPv6 DNS server.

PiHole geeft in ieder geval wel zowel AAAA als A requests van die telefoon weer (met zowel IPv6 als IPv4 adres als bron), waarbij elke domeinnaam 2 keer voorbij lijkt te komen, zowel AAAA als A request met dezelfde timestamp.

Voordat ik IPv6 mogelijk weer uit ga zetten op wifi (tenzij het specifiek op die telefoon uitgezet kan worden), heeft iemand toevallig nog tips voor troubleshooting op een niet-geroote Android telefoon?

edit: Test-ipv6.com geeft overigens 10/10 score.

[Dreamvoid]

Het verwarrende is dat een IPv4 DNS server (zeg maar een pi-hole op 192.168.1.5) op zich prima AAAA records (IPv6 adressen) kan doorgeven. Zolang je LAN dual stack is hoef je in principe helemaal geen IPv6 DNS server te hebben.

[Raven]

I know, maar RDNSS wordt op verschillende sites als oplossing genoemd voor problemen onder Android.

[Dreamvoid]

Klopt, het zou idd in principe moeten werken met RDNSS. Raar probleem idd - Android zelf doet prima IPv6, er zijn inmiddels mobiele telco's die al tien jaar IPv6-only netwerken draaien.

Maar ik bedoel meer, het is geen drama om enkel DNS-over-IPv4 te hebben draaien op een dual stack LAN.

Ik zou eens packet inspection doen op die RA/RDNSS messages, het ruikt toch naar dat er daar iets niet lekker zit.

[Raven]

Als het daar niet lekker zit, dan zouden andere apparaten er toch ook last van moeten hebben? Het is net als de vorige keer dat IPv6 op wifi actief was weer Android. Andere OSsen zoals Windows, Ubuntu en Mobian vertonen helemaal geen problemen.

[Dreamvoid]

Maar als je naast RDNSS ook DNS-via-DHCPv6 doet, dan gebruiken die devices waarschijnlijk dat, alleen Android heeft RDNSS nodig.

[Raven]

Hoe bedoel je dat precies? Buiten radvd is er bij mijn weten niets actief dat iets met IPv6 DNS toewijzen doet.

[Dreamvoid]

Heb je geen provider router draaien die toevallig met DHCPv6 zijn DNS uitdeelt?

[Raven]

Dreamvoid schreef op maandag 14 december 2020 @ 00:28:
Heb je geen provider router draaien die toevallig met DHCPv6 zijn DNS uitdeelt?

Nope, heb nog nooit de router van providers gebruikt. Mijn router-pc zit rechtstreeks op de glasvezelmodem/FTU die niets meer doet dan als media converter dienen.

[Raven]

Sinds gisteren pikt PiHole via een paar virtuele interfaces met VLAN ID ook MAC-adressen van apparaten buiten het subnet op, zodat ie op basis daarvan clients herkend en wisselende IPv6 adressen van apparaten kan onderscheiden en IPv4 en IPv6 adressen van dezelfde client kan koppelen.

Nu het vreemde: Apparaten met IPv4 adres zijn geen probleem, in alle subnets wordt netjes het MAC-adres herkend, maar bij apparaten met IPv6-adres wordt het MAC-adres alleen herkend wanneer deze in hetzelfde subnet zit, niet in andere subnets. Iets dat ip neigh duidelijk laat zien:

code:

pi@Willow ~ $ ip -6 neigh | grep 2001
2001:*:*:25:*:*:*:* dev eth0  FAILED
2001:*:*:1:*:*:*:* dev eth0 lladdr *MAC* STALE
2001:*:*:25:*:*:*:* dev eth0  FAILED
2001:*:*:25:*:*:*:* dev eth0  FAILED
2001:*:*:25:*:*:*:* dev eth0  FAILED
2001:*:*:1:*:*:*:* dev eth0 lladdr *MAC* STALE
2001:*:*:1:*:*:*:* dev eth0 lladdr *MAC* STALE
pi@Willow ~ $

Weet iemand toevallig in welke hoek de mogelijke oorzaak zit? De firewall op de router-PC met Debian zou het volgens mij niet moeten zijn door

code:

add rule ip6 filter forward meta l4proto ipv6-icmp counter accept
add rule ip6 filter forward iifname { $LAN , $WIFI } oifname { $LAN , $WIFI } counter accept

[Dreamvoid]

Raven schreef op zondag 27 december 2020 @ 11:24:
Sinds gisteren pikt PiHole via een paar virtuele interfaces met VLAN ID ook MAC-adressen van apparaten buiten het subnet op, zodat ie op basis daarvan clients herkend en wisselende IPv6 adressen van apparaten kan onderscheiden en IPv4 en IPv6 adressen van dezelfde client kan koppelen.

Nu het vreemde: Apparaten met IPv4 adres zijn geen probleem, in alle subnets wordt netjes het MAC-adres herkend, maar bij apparaten met IPv6-adres wordt het MAC-adres alleen herkend wanneer deze in hetzelfde subnet zit, niet in andere subnets. Iets dat ip neigh duidelijk laat zien:

code:

pi@Willow ~ $ ip -6 neigh | grep 2001
2001:*:*:25:*:*:*:* dev eth0  FAILED
2001:*:*:1:*:*:*:* dev eth0 lladdr *MAC* STALE
2001:*:*:25:*:*:*:* dev eth0  FAILED
2001:*:*:25:*:*:*:* dev eth0  FAILED
2001:*:*:25:*:*:*:* dev eth0  FAILED
2001:*:*:1:*:*:*:* dev eth0 lladdr *MAC* STALE
2001:*:*:1:*:*:*:* dev eth0 lladdr *MAC* STALE
pi@Willow ~ $

Weet iemand toevallig in welke hoek de mogelijke oorzaak zit? De firewall op de router-PC met Debian zou het volgens mij niet moeten zijn door

code:

add rule ip6 filter forward meta l4proto ipv6-icmp counter accept
add rule ip6 filter forward iifname { $LAN , $WIFI } oifname { $LAN , $WIFI } counter accept

Ik zou het er even in gooien op de pi-hole github of op reddit, deze group-by-MAC feature is pas net toegevoegd dus grote kans dat het nog niet helemaal 100% werkt. Deze nieuwe feature is sowieso een beetje een rommeltje, na twee weken zijn die lijsten met IPv6 adressen bv ellenlang geworden omdat pi-hole alle tijdelijke IPv6 adressen van alle devices blijft onthouden.

[Raven]

Dreamvoid schreef op zondag 27 december 2020 @ 16:13:
[...]

Ik zou het er even in gooien op de pi-hole github of op reddit, deze group-by-MAC feature is pas net toegevoegd dus grote kans dat het nog niet helemaal 100% werkt.

Ik ben er niet zo zeker van dat het aan PiHole ligt, gezien ip -6 neigh (waar PiHole volgens mij de data weghaalt) de MAC's al niet eens weergeeft bij adressen buiten het subnet.

Dreamvoid schreef op zondag 27 december 2020 @ 16:13:
Deze nieuwe feature is sowieso een beetje een rommeltje, na twee weken zijn die lijsten met IPv6 adressen bv ellenlang geworden omdat pi-hole alle tijdelijke IPv6 adressen van alle devices blijft onthouden.

Waarom denk je dat die feature is doorgevoerd , om in ieder geval te kunnen zien bij welke client die adressen horen. Ik heb er ook de nodige in de lijst staan, maar allemaal apart omdat ze niet op basis van MAC bij elkaar gezet kunnen worden.

[Dreamvoid]

Je krijgt alleen een onbruikbare lijst met duizend adressen na een paar maanden op die manier, het is zinniger denk ik om alleen het statische en het laatst gebruikte dynamische adres te laten zien in de Clients lijst - wil je gedetailleerder dan kan je altijd de logs in duiken.

[Raven]

Zou iemand de coronatestuitslag-website via IPv6 willen proberen te openen? Ik krijg hier

Error 1020 Thu, 31 Dec 2020 10:32:44 GMT
Serverfout / Server error
Wat is er gebeurd?

Er is een fout opgetreden. Indien dit probleem blijft bestaan neem dan contact op met je systeembeheerder.
What happened?

An error occured. If this problem persists, please contact your system administrator.

maar als ik IPv6 uitschakel lijkt de website het wél te doen

[Vorkie]

Raven schreef op donderdag 31 december 2020 @ 11:34:
Zou iemand de coronatestuitslag-website via IPv6 willen proberen te openen? Ik krijg hier

[...]
maar als ik IPv6 uitschakel lijkt de website het wél te doen

Werkt hier gewoon, staat je MTU goed? Of heb je zelf er niets aan gedaan?

Non-authoritative answer:
Name: coronatest.nl
Addresses: 2606:4700::6812:f45
2606:4700::6812:e45

[Raven]

Vorkie schreef op donderdag 31 december 2020 @ 11:39:
[...]


Werkt hier gewoon, staat je MTU goed? Of heb je zelf er niets aan gedaan?


[...]

Heb niet aan de MTU gezeten, misschien komt het omdat ik een IPv6-tunnel gebruik?

[Vorkie]

Raven schreef op donderdag 31 december 2020 @ 11:42:
[...]

Heb niet aan de MTU gezeten, misschien komt het omdat ik een IPv6-tunnel gebruik?

Nou, die tunnel staat, als je HE-net hebt, volgens mij op MTU 1280, heb je dat ook ingesteld?

Of gebruik je een andere tunnel.

[Raven]

Vorkie schreef op donderdag 31 december 2020 @ 11:43:
[...]


Nou, die tunnel staat, als je HE-net hebt, volgens mij op MTU 1280, heb je dat ook ingesteld?

Of gebruik je een andere tunnel.

Hurricane Electric inderdaad, ik heb dit commando gebruikt om de tunnel op te zetten:

Bash:

nmcli connection add type ip-tunnel con-name he-ipv6 ifname he-ipv6 mode sit remote $IPv4Endpoint -- ipv4.method disabled ipv6.method manual ipv6.address $IPv6Address ipv6.gateway $IPv6Gateway

Er kwam geen MTU instelling bij kijken.

edit: @Vorkie Volgens nmcli staat de MTU op 1480.

[ Voor 4% gewijzigd door Raven op 31-12-2020 11:49 ]

[borft]

Hier precies hetzelfde probleem (ook een HE tunnel). Zou het komen omdat sommige geoip db's niet snappen dat het subnet in Nederland is? Andere ipv6 sites werken prima

[Vorkie]

Raven schreef op donderdag 31 december 2020 @ 11:47:
[...]

Hurricane Electric inderdaad, ik heb dit commando gebruikt om de tunnel op te zetten:

Bash:

nmcli connection add type ip-tunnel con-name he-ipv6 ifname he-ipv6 mode sit remote $IPv4Endpoint -- ipv4.method disabled ipv6.method manual ipv6.address $IPv6Address ipv6.gateway $IPv6Gateway

Er kwam geen MTU instelling bij kijken.

edit: @Vorkie Volgens nmcli staat de MTU op 1480.

1480 is inderdaad de standaard tegenwoordig bij HEnet, net even een tunnel aangemaakt. Hoogstens dat je IPv6 via USA wordt gerouteerd door Cloudfare en je dus naar een mtu van 1280 moet gaan.

[Toxic Waste]

ik vermoed dat dit de beste plaats is om mijn vraag te stellen, situatie is de volgende thuis. Heb een HGW van Telenet, mij een /56 prefix geeft.

Mijn eigen router is een Ubiquiti UDM pro, aan de WAN kant ondersteunt hij DHCPv6 om een adres in te stellen, of static. Aan de LAN kant kan je verder kiezen voor prefix delegation of Static.

Volgende problemen heb ik de laatste 2 dagen tegengekomen:

- Al mijn pogingen om beide kanten static te gebruiken, zijn mislukt. Als ik een /64 aan de wankant instel, en een andere /64 aan de LAN kant, dan (wat me ook logisch lijkt), weet de HGW van Telenet volgens mij niet naarwaar hij dit subnet moet routeren. Ik kan perfect in men LAN pingen naar men gateway, men UDM pro kent de route naar beide /64s, maar als ik traceroute van buitenaf, stopt het op men HGW.

- Stap ik over op DHCPv6 aan de WAN kant en prefix-delegation aan de LAN kant, dan lijkt het wel correct te werken. Het probleem bevindt zich dan bij men servers thuis. Als ik daar probeer een static ipv6 adres in te stellen, dan kan deze prima naar de gateway pingen, kan hij google op ipv6 bereiken, maar retour traffic lijkt alweer een probleem te zijn, niet bereikbaar van buitenaf. Heb ik een server die een statisch IP heeft EN een IP heeft gekregen via de prefix delegation vermoed ik, dan kan ik er wel van buitenaf aan.

Kan iemand mij verder helpen met hoe ik mijn server statische IPv6s kan geven, dat ze vanbuiten af bereikbaar zijn op ipv6? Blijkbaar niet simpel met gewoon een ipv6 + subnet + default gateway..

[jk-5]

Toxic Waste schreef op zondag 17 januari 2021 @ 10:48:
ik vermoed dat dit de beste plaats is om mijn vraag te stellen, situatie is de volgende thuis. Heb een HGW van Telenet, mij een /56 prefix geeft.

Mijn eigen router is een Ubiquiti UDM pro, aan de WAN kant ondersteunt hij DHCPv6 om een adres in te stellen, of static. Aan de LAN kant kan je verder kiezen voor prefix delegation of Static.

Volgende problemen heb ik de laatste 2 dagen tegengekomen:

- Al mijn pogingen om beide kanten static te gebruiken, zijn mislukt. Als ik een /64 aan de wankant instel, en een andere /64 aan de LAN kant, dan (wat me ook logisch lijkt), weet de HGW van Telenet volgens mij niet naarwaar hij dit subnet moet routeren. Ik kan perfect in men LAN pingen naar men gateway, men UDM pro kent de route naar beide /64s, maar als ik traceroute van buitenaf, stopt het op men HGW.

- Stap ik over op DHCPv6 aan de WAN kant en prefix-delegation aan de LAN kant, dan lijkt het wel correct te werken. Het probleem bevindt zich dan bij men servers thuis. Als ik daar probeer een static ipv6 adres in te stellen, dan kan deze prima naar de gateway pingen, kan hij google op ipv6 bereiken, maar retour traffic lijkt alweer een probleem te zijn, niet bereikbaar van buitenaf. Heb ik een server die een statisch IP heeft EN een IP heeft gekregen via de prefix delegation vermoed ik, dan kan ik er wel van buitenaf aan.

Kan iemand mij verder helpen met hoe ik mijn server statische IPv6s kan geven, dat ze vanbuiten af bereikbaar zijn op ipv6? Blijkbaar niet simpel met gewoon een ipv6 + subnet + default gateway..

Meestal hebben de routers van de internetproviders een ipv6 firewall die al het verkeer van buitenaf blokkeren. Je zou eens kunnen kijken in de instellingen van de HGW of deze inderdaad aanstaat en of je die uit kan zetten. De laatste setup (DHCPv6 + PD) lijkt mij de beste optie, en ik zie daar verder geen problemen in je setup.

[Toxic Waste]

jk-5 schreef op zondag 17 januari 2021 @ 10:50:
[...]


Meestal hebben de routers van de internetproviders een ipv6 firewall die al het verkeer van buitenaf blokkeren. Je zou eens kunnen kijken in de instellingen van de HGW of deze inderdaad aanstaat en of je die uit kan zetten. De laatste setup (DHCPv6 + PD) lijkt mij de beste optie, en ik zie daar verder geen problemen in je setup.

Die heb ik inderdaad al uitgezet, men testen hebben al end to end gewerkt, mits die firewall af en de UDM pro firewall open. Mijn pihole DNS server (die meer dan 1 ipv6 heeft, dus DHCPv6 of SLAAC hier) bv, kon ik perfect pingen vanuit buiten het netwerk, maar men Tor Relay (die puur statisch geconfigureerd is) kon ik van buiten af niet bereiken voor een of andere reden, op het lokale netwerk geen issue om beiden te pingen..

Daarom dat ik een beetje voor een raadsel sta, mis ik een configuratie iets op men Tor Relay dat men pihole via SLAAC/DHCPv6 heeft gekregen?

[Roetzen]

Nieuwe metingen:

[Snow_King]

Roetzen schreef op maandag 18 januari 2021 @ 22:45:
Nieuwe metingen:

...
...

KPN gaat lekker! Echter vind ik het heel jammer dat hun KPN 1-MKB dus geen IPv6 doet...

[Roetzen]

KPN gaat inderdaad lekker. Ik ben niet bekend met de pakketen die KPN aanbiedt, ik weet dus ook niet wat KPN 1-MKB is, Maar als ze IPv6 (nog?) niet op alle pakketten aanbieden is dat inderdaad jammer.

[Muis666]

KPN heeft nog geen IPv6 op zijn laatste router (Box 12)
Er zijn nog veel voormalige Telfort klanten zonder IPv6.
Dus er zijn nog steeds grote stappen te maken...

[xbeam]

Snow_King schreef op dinsdag 19 januari 2021 @ 08:54:
[...]

KPN gaat lekker! Echter vind ik het heel jammer dat hun KPN 1-MKB dus geen IPv6 doet...

Hier ook zakelijk ip4 only. En zakelijk gezien logisch. Aangezien wanneer je ipv6 only bent 69% van internet en wereld niet kan bereiken. En nog zo weinig ipv6 dat veel bedrijven het ook gewoon uit/zetten/niet gebruiken wanneer de provider het aanbiedt. Het zorgt zakelijk ook weer dubbel beheer en extra kosten

[ Voor 19% gewijzigd door xbeam op 19-01-2021 15:45 ]

[Roetzen]

xbeam schreef op dinsdag 19 januari 2021 @ 15:40:
[...]


Hier ook zakelijk ip4 only. En zakelijk gezien logisch. Aangezien wanneer je ipv6 only bent 69% van internet en wereld niet kan bereiken.

Onzin. Je bent namelijk nooit IPv6 only, Je hebt op zijn minst DS-Lite en bij KPN voor zo ver ik weet full Dual Stack.

En nog zo weinig ipv6 dat veel bedrijven het ook gewoon uit/zetten/niet gebruiken wanneer de provider het aanbiedt. Het zorgt zakelijk ook weer dubbel beheer en extra kosten

En dat is dus korte termijn politiek. Het is het probleem vooruit schuiven. Maar ja, zo gaat het helaas vaak in het bedrijfsleven. Het management is voornamelijk geïnteresseerd in wat er aan het eind van het jaar onder de streep staat en wat de bonus wordt. Lange termijn problemen zijn voor de volgende. Ja, inderdaad, in de overgangs periode heb je meer beheer en extra kosten. Maar daar zul je toch een keer doorheen moeten en hoe langer je wacht hoe duurder het wordt. Eeuwig doorgaan met alleen IPv4 is geen optie.

[xbeam]

Roetzen schreef op dinsdag 19 januari 2021 @ 16:11:
[...]

Onzin. Je bent namelijk nooit IPv6 only, Je hebt op zijn minst DS-Lite en bij KPN voor zo ver ik weet full Dual Stack.

[...]

I know, maar er zijn hier een paar op dit forum de beweren al jaren ipv6 only te zijn

En dat is dus korte termijn politiek. Het is het probleem vooruit schuiven. Maar ja, zo gaat het helaas vaak in het bedrijfsleven. Het management is voornamelijk geïnteresseerd in wat er aan het eind van het jaar onder de streep staat en wat de bonus wordt. Lange termijn problemen zijn voor de volgende. Ja, inderdaad, in de overgangs periode heb je meer beheer en extra kosten. Maar daar zul je toch een keer doorheen moeten en hoe langer je wacht hoe duurder het wordt. Eeuwig doorgaan met alleen IPv4 is geen optie.

Maar die overgang duurt nu al 10 jaar en om nu nog eens 10 jaar met dubbele beheer te zitten, Bedrijven willen niet nodeloos wachten en gaan ze gaan ons ook niet voor wachten betalen. Daarom gaan wel lekker over zodra we ipv4 kunnen laten vallen tot tijd blijven we lekker ip4 only.

[ed1703]

xbeam schreef op dinsdag 19 januari 2021 @ 16:59:

Maar die overgang duurt nu al 10 jaar en op nog eens 10 jaar dubbele beheer zitten bedrijven niet te wachten en gaan ze ons ook niet betalen. Daarom gaan wel lekker over zodra we ipv4 kunnen laten vallen tot tijd blijven we lekker ip4 only.

Zie hier waarom ipv6 dus nooit iets gaat worden vanuit deze wereldwijde mentaliteit.
Ik merk dit bij ons overigens ook hoor, daar niet van.

[xbeam]

ed1703 schreef op dinsdag 19 januari 2021 @ 17:20:
[...]

Zie hier waarom ipv6 dus nooit iets gaat worden vanuit deze wereldwijde mentaliteit.
Ik merk dit bij ons overigens ook hoor, daar niet van.

Eens maar. Maar zolang de schaarste mee valt en niemand een ip bij Patrica hoeft zoeken om de problemen op te lossen gaat ipv6 nog lang verhaal worden en niet it bedrijven willen 2 dingen niet en dat is gezeik met hun netwerk en een ip in een donker hoekje van het internet moeten gaan zoeken met risico op reputatie schade. Omdat deze geassocieerd wordt met iets wat je ouders niet verteld 🤷‍♀️

[ Voor 23% gewijzigd door xbeam op 19-01-2021 17:51 ]

[Roetzen]

xbeam schreef op dinsdag 19 januari 2021 @ 16:59:
[...]

I know, maar er zijn hier een paar op dit forum de beweren al jaren ipv6 only te zijn

En dat zijn bedrijven? Je had het namelijk over bedrijven...

Maar die overgang duurt nu al 10 jaar en om nu nog eens 10 jaar met dubbele beheer te zitten, Bedrijven willen niet nodeloos wachten en gaan ze gaan ons ook niet voor wachten betalen.

De extra inspanning voor het overgaan op IPv6 zit hem voornamelijk in het aanleren van de nieuwe truukjes. Als je daar eenmaal doorheen bent, is het echt niet zo moeilijk meer. Het is heus niet nog jaar in, jaar uit dubbele kosten van beheer.

Daarom gaan wel lekker over zodra we ipv4 kunnen laten vallen tot tijd blijven we lekker ip4 only.

Je klaagt er over dat het zo lang duurt tot IPv6 doorbreekt, maar de ironie is dat nu de ISPs eindelijk op stoom komen, het juist de bedrijven zijn die met die houding de uitrol van IPv6 vertragen. Tijdens de eerste lockdown nam het IPv6 verkeer toe vanwege de thuiswerkers die op de zaak geen IPv6 hadden, maar thuis wel.

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

[xbeam]

Roetzen schreef op dinsdag 19 januari 2021 @ 17:57:
[...]

En dat zijn bedrijven? Je had het namelijk over bedrijven...

[...]

Ken zelf een kleine isp (nood gedwongen omdat ruzie maken hun leverancier) . Maar hier zijn het gebruikers

De extra inspanning voor het overgaan op IPv6 zit hem voornamelijk in het aanleren van de nieuwe truukjes. Als je daar eenmaal doorheen bent, is het echt niet zo moeilijk meer. Het is heus niet nog jaar in, jaar uit dubbele kosten van beheer.

[...]

Tuurlijk wel, wat denk je dat een bedrijf aan extra beheer kosten heeft door alleen al de dubbele firewall regels die ze moeten onderhouden. En daar komen ook alle dubbele kosten voor interne diensten en beheer/beveiliging en monitoring van het netwerk bij

Je klaagt er over dat het zo lang duurt tot IPv6 doorbreekt, maar de ironie is dat nu de ISPs eindelijk op stoom komen, het juist de bedrijven zijn die met die houding de uitrol van IPv6 vertragen. Tijdens de eerste lockdown nam het IPv6 verkeer toe vanwege de thuiswerkers die op de zaak geen IPv6 hadden, maar thuis wel.

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

Jouw artikel laat inderdaad juist zien hoeveel bedrijven ipv6 gelijk weer uitzetten bij hun thuiswerkers dat het piekje tijdens de eerste lockdown gelijk ongedaan wordt gemaakt door dalingen die daarna volgen. Is terecht en zolang niet iedere thuiswerken ipv6 heeft gaat een bedrijf niet 2 vpn ingang of secure web proxy’s beheren. Je wil je attack surface zo klein mogelijk houden en die wordt door al dat thuiswerken al enorm en die ga dus niet nog eens met 2 vermenigvuldigen door ook nog eens ipv6 te gebruiken. Je hebt handen al vol van ipv4 wat betreft de beveiliging en kosten

Daarnaast gaat hebt de afgelopen 1.5 jaar en maanden niet heel hard als we huidige trend volgen gaat het inderdaad nog jaren duren om überhaupt op 50% te komen. En terecht de kosten wegen momenteel gewoon niet op tegen voordelen

[ Voor 33% gewijzigd door xbeam op 19-01-2021 18:49 ]

[hkoster1]

Roetzen schreef op dinsdag 19 januari 2021 @ 10:31:
KPN gaat inderdaad lekker. Ik ben niet bekend met de pakketen die KPN aanbiedt, ik weet dus ook niet wat KPN 1-MKB is, Maar als ze IPv6 (nog?) niet op alle pakketten aanbieden is dat inderdaad jammer.

Ik ben sinds gisteren overgestapt naar KPN Mobiel op mijn iPhone, en ja hoor: een IPv6-adres in het mobiele netwerk en geen IPv4-adres. Waarschijnlijk wel CG-NAT.

[Roetzen]

hkoster1 schreef op dinsdag 19 januari 2021 @ 21:02:
[...]

Ik ben sinds gisteren overgestapt naar KPN Mobiel op mijn iPhone, en ja hoor: een IPv6-adres in het mobiele netwerk en geen IPv4-adres. Waarschijnlijk wel CG-NAT.

Geen CGNAT, maar wel iets wat hetzelfde effect heeft. Je kunt IPv4 sites bereiken via IPv4AAS. Zoek maar eens naar DNS64/NAT64.

[xbeam]

hkoster1 schreef op dinsdag 19 januari 2021 @ 21:02:
[...]

Ik ben sinds gisteren overgestapt naar KPN Mobiel op mijn iPhone, en ja hoor: een IPv6-adres in het mobiele netwerk en geen IPv4-adres. Waarschijnlijk wel CG-NAT.

Je krijgt van kpn gewoon een ipv4 naast je ipv6


Sorry van de scramble maar alles wat ik upload word automatisch geblunderd op gevoelige info door de foto app

[ Voor 18% gewijzigd door xbeam op 20-01-2021 02:59 ]

[Roetzen]

xbeam schreef op woensdag 20 januari 2021 @ 02:52:
[...]

Je krijgt van kpn gewoon een ipv4 naast je ipv6

Niet "gewoon". Die 77.63.39.18 is een|het IPv4 adres van de NAT64 gateway van KPN, niet het IPv4 adres van de telefoon.

[Snow_King]

xbeam schreef op dinsdag 19 januari 2021 @ 16:59:
[...]

I know, maar er zijn hier een paar op dit forum de beweren al jaren ipv6 only te zijn

[...]

Ik voel mij lichtelijk aangesproken

Wij bouwen al jaren een IPv6-only infra op de achtergrond. IPv4 is voor ons als hosting bedrijf duur en schaars. Ik kan mijn IPv4 adres beter verkopen aan een klant bij een VPS dan voor een machine van mijzelf gebruiken waar ik niets aan het adres verdien.

Wij hebben tienduizenden IPv4 adressen in gebruik voor diensten van klanten, maar het is echt op. Recentelijk moest ik een /25 zoeken binnen onze subnets om die ergens heen te kunen routeren. Geloof mij, dat was echt uren zoeken met twee man tot we iets gevonden hadden. Routing policies aanpassen en ongeveer een dag later werkte het.

IPv6 draaide op die locatie met een eigen /48 al vrolijk, IPv4 was echt veel tijd.

Ja, IPv4 kost mij als bedrijf echt veel geld en tijd.

Om je een indruk te geven van het netwerk waar we over praten:

- Hosten ~2 miljoen websites
- Enkele duizenden servers
- Tientallen Juniper routers
- Ruim 100TB aan RAM en >3PB aan opslag
- 6 datacenters in Amsterdam

Niet een klein hobby netwerk, maar een serieus productie netwerk.

SSH en SNMP beheer gaat exclusief via IPv6. Her en der nog wat legacy die langzaam af sterft, maar verder niets.

xbeam schreef op dinsdag 19 januari 2021 @ 18:15:
[...]

Ken zelf een kleine isp (nood gedwongen omdat ruzie maken hun leverancier) . Maar hier zijn het gebruikers

[...]

Tuurlijk wel, wat denk je dat een bedrijf aan extra beheer kosten heeft door alleen al de dubbele firewall regels die ze moeten onderhouden. En daar komen ook alle dubbele kosten voor interne diensten en beheer/beveiliging en monitoring van het netwerk bij

Wij hebben dus juist enkele firewall regels. Als beheer komen wij uit een /40 subnet. Dat subnet mag SSH connecties maken met de apparatuur en verder niemand. In dat subnet zitten de VPN servers en ook enkele SSH jump hosts.

Hele simpele firewall policies dus. Geen dubbele regels.

[hkoster1]

Roetzen schreef op woensdag 20 januari 2021 @ 10:54:
[...]

Niet "gewoon". Die 77.63.39.18 is een|het IPv4 adres van de NAT64 gateway van KPN, niet het IPv4 adres van de telefoon.

Klopt. Ik heb een paar keer een Wireguard VPN verbinding opgezet vanaf mijn iPhone naar het IPv4-adres van mijn VPS, en dan op de VPS gecheckt waar die verbinding vandaan komt. Dat is steeds een ander IPv4-adres, zoals 77.63.103.181 en 31.161.221.211.

[Roetzen]

xbeam schreef op dinsdag 19 januari 2021 @ 18:15:


Tuurlijk wel,

Tuurlijk niet. Uiteraard zijn er dingen verschillend tussen IPv6 en IPv4 en dat kan wat extra werk en kosten geven. Maar ook heel veel is hetzelfde en als je echt jarenlang twee keer zo veel werk en kosten hebt voor het onderhouden van IPv6, dan doe je iets helemaal verkeerd. Zie ook de post van Snow_King

Jouw artikel laat inderdaad juist zien hoeveel bedrijven ipv6 gelijk weer uitzetten bij hun thuiswerkers dat het piekje tijdens de eerste lockdown gelijk ongedaan wordt gemaakt door dalingen die daarna volgen. Is terecht en zolang niet iedere thuiswerken ipv6 heeft gaat een bedrijf niet 2 vpn ingang of secure web proxy’s beheren

Ik zie niets van dien aard. Wat ik zie is een piek rond Kerst 2019. Ze zijn thuis en niet op het werk en hebben daar IPv6 en op het werk niet. IPv6 gaat omhoog. In januari gaan ze weer naar het werk en IPv6 daalt weer een beetje. Heeft niks te maken met bedrijven die IPv6 gauw weer uitschakelen. Eind maart, begin april zie ik weer een opleving van IPv6, De mensen zijn thuis en daar hebben ze IPv6 die ze op het werk niet hadden. Die stijging in IPv6 komt niet doordat ze via IPv6 contact met het bedrijf maken, dat kan immers niet, de bedrijven hebben immers geen IPv6. Het komt omdat de mensen die thuis zijn, hun verbinding gebruiken voor andere dingen. Dingen die wél via IPv6 gaan. Dat extra IPv6 gebruik neemt in de loop van de volgende maanden langzaam af omdat het thuiswerken weer afneemt.

Leuk die theorie over bedrijven die flux IPv6 weer uitzetten als hun medewerkers gaan thuiswerken, maar die theorie is niet verenigbaar met de waargenomen feiten. Die bedrijven zetten IPv6 niet uit, ze hebben het nooit aan gehad.

Daarnaast gaat hebt de afgelopen 1.5 jaar en maanden niet heel hard als we huidige trend volgen gaat het inderdaad nog jaren duren om überhaupt op 50% te komen. En terecht de kosten wegen momenteel gewoon niet op tegen voordelen

Het kon beter, maar er begint nu best wat schot in te komen. Die 50% wordt heus wel gehaald binnenkort. Alle grote jongens zijn al om. Dat is niet omdat ze denken dat de kosten niet opwegen tegen de voordelen. Wie denkt op termijn goedkoper uit te zijn door IPv6 uit te stellen of die zelfs denkt er helemaal onderuit te komen, doet iets verkeerd. Zie ook de post van Snow_King. De IPv4 adressen zijn op, IPv6 is onontkoombaar. Daar helpt geen lieve moeder aan. Hoe langer gewacht, hoe duurder het wordt.

[xbeam]

Roetzen schreef op woensdag 20 januari 2021 @ 13:03:
[...]

Tuurlijk niet. Uiteraard zijn er dingen verschillend tussen IPv6 en IPv4 en dat kan wat extra werk en kosten geven. Maar ook heel veel is hetzelfde en als je echt jarenlang twee keer zo veel werk en kosten hebt voor het onderhouden van IPv6, dan doe je iets helemaal verkeerd. Zie ook de post van Snow_King

[...]

Ik zie niets van dien aard. Wat ik zie is een piek rond Kerst 2019. Ze zijn thuis en niet op het werk en hebben daar IPv6 en op het werk niet. IPv6 gaat omhoog. In januari gaan ze weer naar het werk en IPv6 daalt weer een beetje. Heeft niks te maken met bedrijven die IPv6 gauw weer uitschakelen. Eind maart, begin april zie ik weer een opleving van IPv6, De mensen zijn thuis en daar hebben ze IPv6 die ze op het werk niet hadden. Die stijging in IPv6 komt niet doordat ze via IPv6 contact met het bedrijf maken, dat kan immers niet, de bedrijven hebben immers geen IPv6. Het komt omdat de mensen die thuis zijn, hun verbinding gebruiken voor andere dingen. Dingen die wél via IPv6 gaan. Dat extra IPv6 gebruik neemt in de loop van de volgende maanden langzaam af omdat het thuiswerken weer afneemt.

Leuk die theorie over bedrijven die flux IPv6 weer uitzetten als hun medewerkers gaan thuiswerken, maar die theorie is niet verenigbaar met de waargenomen feiten. Die bedrijven zetten IPv6 niet uit, ze hebben het nooit aan gehad.

[...]

Het kon beter, maar er begint nu best wat schot in te komen. Die 50% wordt heus wel gehaald binnenkort. Alle grote jongens zijn al om. Dat is niet omdat ze denken dat de kosten niet opwegen tegen de voordelen. Wie denkt op termijn goedkoper uit te zijn door IPv6 uit te stellen of die zelfs denkt er helemaal onderuit te komen, doet iets verkeerd. Zie ook de post van Snow_King. De IPv4 adressen zijn op, IPv6 is onontkoombaar. Daar helpt geen lieve moeder aan. Hoe langer gewacht, hoe duurder het wordt.

Hier in het westen hebben we nog genoeg IPv4 adressen bij organisaties op de plank liggen alleen de blokken worden steeds kleiner en hier de EU en VS en tegen wordt de UK weer apart bezitten veel kleinen it bedrijfjes grote ip blokken. Daarnaast zou je door de oneerlijke verdeling (in het begin te ruim hartig met uitdelen geweest ) denken dat Afrika wat achteraan in rij met uitdelen heeft gestaan voorop zou lopen met ipv6 maar ook daar is de nood niet extreem hoog omdat er nog genoeg rek in het huidige ipv4 systeem/werkwijze zit.

Spreek nog wel mensen daar, isp gebruiken daar soms nog liever een RFC 1918 dan ipv6 en niet omdat er geen ipv6 of kennis maar omdat ip4v gewoon voldoet. Oplossing als nat en gcnat werken prima en hebben een positief bijwerking dat Ze je online privacy beter beschermen.

ik ben niet tegen ipv6 maar probeer alleen de discussie aan te wakkeren of trage acceptatie niet gewoon komt omdat er tot op heden weinig technische noodzaak is en dat de ipv4 schaarste tot op heden eigenlijk alleen een papieren en administrative schaarste is.

En ja de bedrijven zetten het niet uit bij hun zelf maar bij de medewerkers thuis grapjas met ze hebben het nooit aangehad ;-)

Om eerlijk te zijn ken geen ik enkel bedrijf dat een echt een noodzakelijke rede voelt om over te gaan. behalve trained omdat die van wege een conflict hun ipv4 block terug moesten geven en dus daardoor in eens zonder zit. En ik voel hem ook niet voor onze klanten. De enige rede die ik heb en voel is dat het leuk/ Nice to is als we nu eindelijk een met de hele wereld over gaan.

Maar leg uit ik leer graag hoe kan ik ipv6 gebruiken zonder dubbele firewalls te hoeve inrichting en te onderhouden? Aangezien dat nu al met ip4 al een dag taak is met alle changes en implementaties bij klanten.
Leer ik graag hoe dat makkelijker kan

[ Voor 9% gewijzigd door xbeam op 20-01-2021 18:17 ]

[xbeam]

Roetzen schreef op woensdag 20 januari 2021 @ 10:54:
[...]

Niet "gewoon". Die 77.63.39.18 is een|het IPv4 adres van de NAT64 gateway van KPN, niet het IPv4 adres van de telefoon.

Dat is altijd al zo geweest vanaf dag 1 sinds de introductie van gprs. Het mobile netwerk heeft nooit anders gewerkt omdat het gsm netwerk van oudsher geen interne ip adressen kent en gebruikt voor de communicatie met je handset

[xbeam]

Snow_King schreef op woensdag 20 januari 2021 @ 11:42:
[...]

Ik voel mij lichtelijk aangesproken

Wij bouwen al jaren een IPv6-only infra op de achtergrond. IPv4 is voor ons als hosting bedrijf duur en schaars. Ik kan mijn IPv4 adres beter verkopen aan een klant bij een VPS dan voor een machine van mijzelf gebruiken waar ik niets aan het adres verdien.

Wij hebben tienduizenden IPv4 adressen in gebruik voor diensten van klanten, maar het is echt op. Recentelijk moest ik een /25 zoeken binnen onze subnets om die ergens heen te kunen routeren. Geloof mij, dat was echt uren zoeken met twee man tot we iets gevonden hadden. Routing policies aanpassen en ongeveer een dag later werkte het.

IPv6 draaide op die locatie met een eigen /48 al vrolijk, IPv4 was echt veel tijd.

Ja, IPv4 kost mij als bedrijf echt veel geld en tijd.

Om je een indruk te geven van het netwerk waar we over praten:

- Hosten ~2 miljoen websites
- Enkele duizenden servers
- Tientallen Juniper routers
- Ruim 100TB aan RAM en >3PB aan opslag
- 6 datacenters in Amsterdam

Niet een klein hobby netwerk, maar een serieus productie netwerk.

SSH en SNMP beheer gaat exclusief via IPv6. Her en der nog wat legacy die langzaam af sterft, maar verder niets.


[...]

Wij hebben dus juist enkele firewall regels. Als beheer komen wij uit een /40 subnet. Dat subnet mag SSH connecties maken met de apparatuur en verder niemand. In dat subnet zitten de VPN servers en ook enkele SSH jump hosts.

Hele simpele firewall policies dus. Geen dubbele regels.

Dat klink leuk maar voor jullie als data center zijn ip adressen handel, je hebt er dus nooit genoeg. Maar probeer dit concept maar eens uit te rollen bij bijv een ziekenhuis dan wegen de voordelen echt niet meer op tegen de kosten en voldoet rfc1918 en een x aantal public ipv4 prima. En ook niet elke gps heeft een eigen public nodig (het fijn en makkelijk ) ook daar kan je vaak prima overweg met een 1918 de meeste vps ( voor ons ) zijn alleen een verlengstuk van onze interne en achter een ha-ip in een private netwerk

[ Voor 6% gewijzigd door xbeam op 20-01-2021 18:44 ]

[Toxic Waste]

Toxic Waste schreef op zondag 17 januari 2021 @ 11:15:
[...]


Die heb ik inderdaad al uitgezet, men testen hebben al end to end gewerkt, mits die firewall af en de UDM pro firewall open. Mijn pihole DNS server (die meer dan 1 ipv6 heeft, dus DHCPv6 of SLAAC hier) bv, kon ik perfect pingen vanuit buiten het netwerk, maar men Tor Relay (die puur statisch geconfigureerd is) kon ik van buiten af niet bereiken voor een of andere reden, op het lokale netwerk geen issue om beiden te pingen..

Daarom dat ik een beetje voor een raadsel sta, mis ik een configuratie iets op men Tor Relay dat men pihole via SLAAC/DHCPv6 heeft gekregen?

Ondertussen heb ik het werkende gekregen op men jails, puur om de optie van AUTO_LINKLOCAL te activeren op de interface.

Kan iemand met meer verstand van ipv6 mij uitleggen, hoe een IP via internet niet bereikbaar is zonder een link-local adres ? Ik had een ipv6 adres en een default gateway, uitgaande verkeer was al mogelijk, maar inkomend dus pas met het link-local adres..

Anyone that can explain that one?

[Freeaqingme]

Toxic Waste schreef op woensdag 20 januari 2021 @ 23:15:
[...]


Anyone that can explain that one?

Hoe zou jouw gateway moeten weten welk mac adres er hoort bij packets met jou ip als destination? Via ARP. Alleen is ARP ipv4, en gebeurt dat bij ipv6 over link local ip's.

[Toxic Waste]

Freeaqingme schreef op donderdag 21 januari 2021 @ 00:30:
[...]


Hoe zou jouw gateway moeten weten welk mac adres er hoort bij packets met jou ip als destination? Via ARP. Alleen is ARP ipv4, en gebeurt dat bij ipv6 over link local ip's.

Dus het link-local adres dat mijn VM aanmaakt, zorgt dat mijn router weet naar waar hij de packets moet sturen die van buiten de firewall komen? En pre die link-local heeft hij geen besef op layer 2 naar waar ze moeten?

[Snow_King]

Toxic Waste schreef op woensdag 20 januari 2021 @ 23:15:
[...]


Ondertussen heb ik het werkende gekregen op men jails, puur om de optie van AUTO_LINKLOCAL te activeren op de interface.

Kan iemand met meer verstand van ipv6 mij uitleggen, hoe een IP via internet niet bereikbaar is zonder een link-local adres ? Ik had een ipv6 adres en een default gateway, uitgaande verkeer was al mogelijk, maar inkomend dus pas met het link-local adres..

Anyone that can explain that one?

Neighbor discovery gaat via Link-Local Multicast en om die reden heb je een Link-Local nodig.

Zonder Link-Local werkt IPv6 gewoon niet. Net zoals dat ICMPv6 mandatory is, zonder ICMP geen IPv6.

[webfreakz.nl]

Toxic Waste schreef op donderdag 21 januari 2021 @ 11:01:
[...]


Dus het link-local adres dat mijn VM aanmaakt, zorgt dat mijn router weet naar waar hij de packets moet sturen die van buiten de firewall komen? En pre die link-local heeft hij geen besef op layer 2 naar waar ze moeten?

Klopt, in de IPv6 wereld is het geen ARP maar Neighbor Discovery:

https://blog.apnic.net/20...-ipv6-neighbor-discovery/
Wikipedia: Neighbor Discovery Protocol

In IPv4 zit ARP direct op Ethernet. In IPv6 gaat het via ICMPv6 (ICMP over IPv6) en multicast (vaak gewoon broadcast hoor).

[ Voor 9% gewijzigd door webfreakz.nl op 21-01-2021 11:47 ]

[Toxic Waste]

webfreakz.nl schreef op donderdag 21 januari 2021 @ 11:46:
[...]


Klopt, in de IPv6 wereld is het geen ARP maar Neighbor Discovery:

https://blog.apnic.net/20...-ipv6-neighbor-discovery/
Wikipedia: Neighbor Discovery Protocol

In IPv4 zit ARP direct op Ethernet. In IPv6 gaat het via ICMPv6 (ICMP over IPv6) en multicast (vaak gewoon broadcast hoor).

Ok, nu is het met duidelijk waarom het daardoor niet werkt, ik schaam me een beetje als netwerk engineer zijnde, dringend meer met ipv6 gaan spelen

Bedankt voor de hulp people!

[Snow_King]

Toxic Waste schreef op donderdag 21 januari 2021 @ 12:14:
[...]


Ok, nu is het met duidelijk waarom het daardoor niet werkt, ik schaam me een beetje als netwerk engineer zijnde, dringend meer met ipv6 gaan spelen

Bedankt voor de hulp people!

Graag gedaan!

Wat je veelal ook zal zien is dat het Link-Local adres van de router als gateway gebruikt wordt. Je hoeft dus niet ::1 of ::2 ofzo in te stellen op de router. Vaak heeft de router niet eens een adres uit de /64

De router stuurt Router Advertisements uit welke het kernel leert en gebruikt als default gateways.

Op een Linux machine:

code:

me@crew:~$ ip -6 route show default
default via fe80::212:f2ff:fe9c:3300 dev eth0  proto ra  metric 1024  expires 46sec hoplimit 64 pref medium
default via fe80::20c:dbff:fef9:cf00 dev eth0  proto ra  metric 1024  expires 51sec hoplimit 64 pref medium
me@crew:~$

Twee routers in dit geval aanwezig in dit netwerk. Beide een lifetime van 60 seconde en een interval van 10 seconde voor hun RA.