Het grote IPv6 topic

[iworx]

Dreamvoid schreef op donderdag 7 maart 2024 @ 10:58:
interessant - gebruiken ze de andere /57 voor IPTV ofzo?

Zou die niet gewoon op de modem zelf landen? We gebruiken bridge mode om de router aan een IP te helpen maar je kan op de andere poorten nog gewoon IPv4 NAT & IPv6 gebruiken.

[Dreamvoid]

Nee ik bedoel meer, als ze een /56 per klant reserveren, dan bieden ze de helft (de eerste /57) aan de router, en hou je een /57 over die je kan tunnelen, bv om IPTV verkeer gescheiden te houden (dus een TV box heeft een encrypted IPv6 tunnel naar de provider waar de TV streams over lopen).

[ Voor 19% gewijzigd door Dreamvoid op 07-03-2024 11:16 ]

[iworx]

Dreamvoid schreef op donderdag 7 maart 2024 @ 11:14:
Nee ik bedoel meer, als ze een /56 per klant reserveren, dan bieden ze de helft (de eerste /57) aan de router, en hou je een /57 over die je kan tunnelen, bv om IPTV verkeer gescheiden te houden (dus een TV box heeft een encrypted IPv6 tunnel naar de provider waar de TV streams over lopen).

Niet direct -- de Telenet TV box zit gewoon achter mijn OPNsense in het IoT vlan en krijgt daar een adres uit de /64.

[HollowGamer]

Is het mogelijk om IPv6 te gebruiken, maar niet voor het LAN (of juist wel)?

Situatie:
- Ziggo-modem (bridge-mode)
- ASUS AX58U met Merlin firmware
- rPi met AdguardHome

Ik heb de DNS voor de DHCP op Merlin omgezet naar die van AdguardHome.
Dat werkt allemaal prima.

Op dit moment staat IPv6 uit op mijn Merlin router, zodat ik zeker weet dat het verkeer naar AdguardHome gaat en deze ook een vast IPv4 adres heeft.
Is het mogelijk om toch IPv6 in te schakelen, en dan het niet voor het LAN gebruiken (enkel uitgaand)? Of dat je ook static gaan zetten op IPv6 addressen, zodat die ook AdguardHome als DNS gebruiken?

Gekke vragen, maar ben verre van een netwerk man. Al heb ik wel mijn Cisco's CCNA diploma's van jaren geleden.

Thanks!

[D0ubleD0uble]

HollowGamer schreef op zondag 24 maart 2024 @ 12:23:
Is het mogelijk om IPv6 te gebruiken, maar niet voor het LAN (of juist wel)?

Situatie:
- Ziggo-modem (bridge-mode)
- ASUS AX58U met Merlin firmware
- rPi met AdguardHome

Ik heb de DNS voor de DHCP op Merlin omgezet naar die van AdguardHome.
Dat werkt allemaal prima.

Op dit moment staat IPv6 uit op mijn Merlin router, zodat ik zeker weet dat het verkeer naar AdguardHome gaat en deze ook een vast IPv4 adres heeft.
Is het mogelijk om toch IPv6 in te schakelen, en dan het niet voor het LAN gebruiken (enkel uitgaand)? Of dat je ook static gaan zetten op IPv6 addressen, zodat die ook AdguardHome als DNS gebruiken?

Gekke vragen, maar ben verre van een netwerk man. Al heb ik wel mijn Cisco's CCNA diploma's van jaren geleden.

Thanks!

Er zit geen verschil in het IPv6 adres van een apparaat binnen een LAN en zijn globale GUA adres. AdGuardHome werkt overigens prima met IPv6. Je kan gewoon een statische IPv6 instellen voor je adguardhome. Je prefix bij Ziggo is dan wel dynamisch (de eerste helft als het ware van je IPv6) maar in de meeste gevallen veranderd deze bij Ziggo niet. en de tweede helft is voor je apparaat. Deze kan je statisch aanwijzen of je zou ook SLAAC kunnen gebruiken. In sommige gevallen wordt dan het MAC adres gebruikt, in andere gevallen (iig op Linux servers) krijg je privacy extensions stable, deze addressen zijn willekeurig maar veranderen alleen als je prefix wijzigt. Je hebt ook nog de mogelijkheid tot zogeheten ULA adressen, die zijn een beetje vergelijkbaar met je RFC1918 (lokale IPv4 adressen)
Als je je Adguardhome een (statisch) IPv6 adres geeft en deze in de DNS stopt, zou het gewoon moeten werken

[HollowGamer]

D0ubleD0uble schreef op zondag 24 maart 2024 @ 12:38:
[...]


Er zit geen verschil in het IPv6 adres van een apparaat binnen een LAN en zijn globale GUA adres. AdGuardHome werkt overigens prima met IPv6. Je kan gewoon een statische IPv6 instellen voor je adguardhome. Je prefix bij Ziggo is dan wel dynamisch (de eerste helft als het ware van je IPv6) maar in de meeste gevallen veranderd deze bij Ziggo niet. en de tweede helft is voor je apparaat. Deze kan je statisch aanwijzen of je zou ook SLAAC kunnen gebruiken. In sommige gevallen wordt dan het MAC adres gebruikt, in andere gevallen (iig op Linux servers) krijg je privacy extensions stable, deze addressen zijn willekeurig maar veranderen alleen als je prefix wijzigt. Je hebt ook nog de mogelijkheid tot zogeheten ULA adressen, die zijn een beetje vergelijkbaar met je RFC1918 (lokale IPv4 adressen)
Als je je Adguardhome een (statisch) IPv6 adres geeft en deze in de DNS stopt, zou het gewoon moeten werken

Weet je toevallig ook hoe ik een static IPv6 LAN kan instellen voor de LAN-clients?

Ik zie dit namelijk wel allemaal terugkomen voor IPv4, maar voor IPv6 lijkt dit stukken ingewikkelder.


Ik denk dat het de bedoeling is, hier dan het IPv6 te zetten van de rPi.
Alleen krijg je onder Manually Assigned IP around the DHCP list, enkel weer IPv4 addressen te zien.

Dat maakt het best verwarrend allemaal.

[ Voor 14% gewijzigd door HollowGamer op 24-03-2024 12:47 ]

[D0ubleD0uble]

HollowGamer schreef op zondag 24 maart 2024 @ 12:43:
[...]

Weet je toevallig ook hoe ik een static IPv6 LAN kan instellen voor de LAN-clients?

Ik zie dit namelijk wel allemaal terugkomen voor IPv4, maar voor IPv6 lijkt dit stukken ingewikkelder.

[Afbeelding]
Ik denk dat het de bedoeling is, hier dan het IPv6 te zetten van de rPi.
Alleen krijg je onder Manually Assigned IP around the DHCP list, enkel weer IPv4 addressen te zien.

Dat maakt het best verwarrend allemaal.

Ik heb even zitten te graven in de documentatie van AGH omdat ik wist dat Pi-Hole voor dit probleem een oplossing heeft, en AGH gelukkig ook! Zie hier de DHCP/SLAAC opties voor AGH je kan deze het beste op ra_slaac_only zetten. Dit is vergelijkbaar met AGH die nu je DHCP afhandelt. AGH zal dan Router Advertisements het netwerk insturen zodat clients verbinding kunnen maken, en hierbij zal dan als het goed is ook gelijk AdGuardHome zelf direct als de DNS worden ingesteld voor IPv6

[HollowGamer]

D0ubleD0uble schreef op zondag 24 maart 2024 @ 13:05:
[...]


Ik heb even zitten te graven in de documentatie van AGH omdat ik wist dat Pi-Hole voor dit probleem een oplossing heeft, en AGH gelukkig ook! Zie hier de DHCP/SLAAC opties voor AGH je kan deze het beste op ra_slaac_only zetten. Dit is vergelijkbaar met AGH die nu je DHCP afhandelt. AGH zal dan Router Advertisements het netwerk insturen zodat clients verbinding kunnen maken, en hierbij zal dan als het goed is ook gelijk AdGuardHome zelf direct als de DNS worden ingesteld voor IPv6

Het klinkt allemaal erg ingewikkeld, maar ga het eens op mijn gemak nalezen.

ty

[Dreamvoid]

HollowGamer schreef op zondag 24 maart 2024 @ 12:23:
Is het mogelijk om IPv6 te gebruiken, maar niet voor het LAN (of juist wel)?

Situatie:
- Ziggo-modem (bridge-mode)
- ASUS AX58U met Merlin firmware
- rPi met AdguardHome

Ik heb de DNS voor de DHCP op Merlin omgezet naar die van AdguardHome.
Dat werkt allemaal prima.

Op dit moment staat IPv6 uit op mijn Merlin router, zodat ik zeker weet dat het verkeer naar AdguardHome gaat en deze ook een vast IPv4 adres heeft.
Is het mogelijk om toch IPv6 in te schakelen, en dan het niet voor het LAN gebruiken (enkel uitgaand)? Of dat je ook static gaan zetten op IPv6 addressen, zodat die ook AdguardHome als DNS gebruiken?

Gekke vragen, maar ben verre van een netwerk man. Al heb ik wel mijn Cisco's CCNA diploma's van jaren geleden.

Thanks!

Je maakt het moeilijker dan het is. Stel het IP adres van de rPi in als IPv6 DNS server op de Asus router. Vervolgens gebruiken alle clients de Pi als DNS server.

[HollowGamer]

Dreamvoid schreef op maandag 25 maart 2024 @ 13:56:
[...]

Je maakt het moeilijker dan het is. Stel het IP adres van de rPi in als IPv6 DNS server op de Asus router. Vervolgens gebruiken alle clients de Pi als DNS server.

Thanks!

Het is inmiddels gelukt, maar ik vind helaas niet om de optie voor een static IPv6 adres in Merlin.
Ik heb nu het IPv6 van de interface eraan gekoppeld.

Ik hoop dus dat het op basis van IPv4 + MAC-address gaat?

[ Voor 5% gewijzigd door HollowGamer op 26-03-2024 14:21 ]

[Dreamvoid]

Het is inmiddels gelukt, maar ik vind helaas niet om de optie voor een static IPv6 adres in Merlin.
Ik heb nu het IPv6 van de interface eraan gekoppeld.

Een static adres waar - LAN interface? WAN interface? Normaal gesproken heb je op de WAN zijde niets te doen, dat wordt door je provider gedaan. De LAN side heeft de router een link-local adres + een GUA adres.

Ik hoop dus dat het op basis van IPv4 + MAC-address gaat?

Misschien ben ik niet helemaal 100% vandaag, maar wat is "het" hier?

[ Voor 5% gewijzigd door Dreamvoid op 26-03-2024 14:24 ]

[HollowGamer]

Dreamvoid schreef op dinsdag 26 maart 2024 @ 14:24:
[...]

Een static adres waar - LAN interface? WAN interface? Normaal gesproken heb je op de WAN zijde niets te doen, dat wordt door je provider gedaan. De LAN side heeft de router een link-local adres + een GUA adres.


[...]

Misschien ben ik niet helemaal 100% vandaag, maar wat is "het" hier?

Ik krijg inderdaad een WAN-address native van Ziggo, maar je hebt dus ook nog intern IPv6 LAN.
Je kan schijnbaar de optie DHCP-PD daarvoor uitzetten?

Ik bedoel dat je in de LAN-DHCP optie enkel het basis van IPv4 + MAC-address kan selecteren.
Er staat daar geen optie om een statisch IPv6 adres te koppelen.

Of is het beter om IPv6 uit te zetten voor het LAN (als dat gaat)?

[Dreamvoid]

DHCP-PD (Prefix delegation) is voor als je een extra downstream routers achter die Asus wil gaan zetten, niet voor endpoints zoals de Pi.

Met IPv6 gebruik je geen DHCP meer om adressen 1 voor 1 aan clients uit te delen, het gaat simpeler dan dat: de router adverteert enkel een /64 prefix naar de clients, en die creeeren hun eigen adres daarmee.

Of is het beter om IPv6 uit te zetten voor het LAN (als dat gaat)?

Als je IPv6 uitzet op het LAN heb je helemaal geen IPv6 connectiviteit meer, da's geen goed plan.

[ Voor 3% gewijzigd door Dreamvoid op 26-03-2024 14:58 ]

[jghaanstra]

Ik kan wat hulp gebruiken bij het inschakelen van IPv6 op mijn Edgerouter X.

De situatie:

• Ik heb zelf maar weinig netwerk kennis
• KPN glasvezel
• Edgerouter X rechtstreeks gekoppeld aan NTU
• Edgerouter X oorspronkelijk alleen ingesteld voor IPv4
• DNS server ingesteld op Pi-Hole in een docker container en via macvlan beschikbaar op 192.168.0.198
• Er hangt een Ubiquity switch aan eth1 waar weer 3 Ubiquity access points aan hangen.
• IPv4 config met Pi-Hole heeft altijd prima gewerkt.
• Geprobeerd IPv6 te activeren met deze instructies.
• IPv4 config met Pi-Hole werk nog steeds prima maar er is geen volledige IPv6 actief.
• Er staat bij eth1 (de switch) nu een IPv6 adres range
• Er staat bij pppoe0 nu een link-local IPv6 adres onder mijn externe ipv4 adres

Hieronder een afbeelding van het dashboard van de Edgerouter X en hier een link naar naar de config.boot. Hulp wordt zeer gewaardeerd!

[ Voor 3% gewijzigd door jghaanstra op 26-03-2024 21:12 ]

[Darses]

jghaanstra schreef op dinsdag 26 maart 2024 @ 21:11:
Ik kan wat hulp gebruiken bij het inschakelen van IPv6 op mijn Edgerouter X.

Zelf heb ik geen Edgerouter, maar wel KPN. Dat je bij de WAN een link-local ziet klopt (bij PPPoE).

Dat er bij eth1 nu een (global) IPv6 subnet lijkt te betekenen dat je Edgerouter op een juiste manier IPv6 subnetten uitdeelt op van de gedelegeerde reeks die je vanuit de WAN (KPN) krijgt. Wat mij wel opvalt in de 'ethernet eth1 ipv6' sectie van je config, is dat je Google DNS (2001:4860:4860::8888 en 2001:4860:4860::8844) instelt in plaats van je eigen pi-hole server. Dit staat zowel bij name-server als bij radvd-options (wat waarschijnlijk dubbelop is).

Als ik je bericht goed lees krijgen je clients in het LAN (eth1) wel gewoon een IPv6-adres. Dus als je vanaf dat netwerk naar ipv6-test.com gaat, klopt het dat je dan groene vinkjes krijgt? Of zitten de clients in het 'LAN'/switch0 gedeelte, waar nu nog geen IPv6-subnet aan gekoppeld is?

EDIT: Het lijkt erop dat je nu IPv6 geconfigureerd hebt op interface eth1, maar dat je dit eigenlijk op de bridge over alles eth* interfaces wilt toepassen. In je config is dat switch 'switch0'. Je moet de IPv6 configuratie dus verplaatsen van eth1 naar switch0. En als dat eenmaal werkt, dan moet je daarna nog de DNS aanpassen naar het IPv6-adres van de Pi-Hole.

Verder zou ik ook eens naar deze handleiding kijken voor het configureren van IPv6 via de GUI: https://blog.gruby.com/2018/03/15/ipv6-on-usg/.

[ Voor 19% gewijzigd door Darses op 26-03-2024 22:07 ]

[jghaanstra]

Darses schreef op dinsdag 26 maart 2024 @ 21:51:
EDIT: Het lijkt erop dat je nu IPv6 geconfigureerd hebt op interface eth1, maar dat je dit eigenlijk op de bridge over alles eth* interfaces wilt toepassen. In je config is dat switch 'switch0'. Je moet de IPv6 configuratie dus verplaatsen van eth1 naar switch0. En als dat eenmaal werkt, dan moet je daarna nog de DNS aanpassen naar het IPv6-adres van de Pi-Hole.

Thanx, ik heb de IPv6 config van eth1 verplaatst naar switch0 en IPv6 lijkt nu goed te werken. Een externe IP check geeft nu ook het IPv6 adres terug en apparaten in mijn LAN krijgen ook een IPv6 adres.

Nu uitzoeken hoe ik de Docker container van Pi-Hole een IPv6 adres kan geven.

[duvekot]

jghaanstra schreef op dinsdag 26 maart 2024 @ 23:04:
Nu uitzoeken hoe ik de Docker container van Pi-Hole een IPv6 adres kan geven.

De "consensus" is dat docker en ipv6 niet echt lekker samen werken .. zeker niet met veranderende prefixes etc .. omdat de configuratie vrij statisch is .. of afhankelijk van NAT tussen de host IPv6 en het Docker interne IPv6 netwerk ...

Dus dan kan je beter docker op IPv4 laten .. en een reverse proxy op IPv6 laten draaien die "aan de achterkant" naar de IPv4 docker containers gaat

[RobertMe]

duvekot schreef op woensdag 27 maart 2024 @ 11:45:
[...]

De "consensus" is dat docker en ipv6 niet echt lekker samen werken .. zeker niet met veranderende prefixes etc .. omdat de configuratie vrij statisch is .. of afhankelijk van NAT tussen de host IPv6 en het Docker interne IPv6 netwerk ...

Met macvlan spelen die problemen volgens mij niet. Maar dan moet het macvlan netwerk wel zijn aangemaakt met IPv6 ingeschakeld neem ik aan. Enige risico is dan nog de veranderde prefix waardoor je het DNS server adres moet aanpassen.

* RobertMe heeft een LUA subnet per VLAN en met Docker nog eens een subnet "daaronder". Dus bv mijn "prive" VLAN is fd00:10::/64. Docker containers op mijn (zelfbouw) router in het "prive" netwerk gebruiken fd00:10:1::/64 en Docker containers op de server in het "prive" netwerk gebruiken fd00:10:2::/64. De Docker host stuurt vervolgens op het prive VLAN ook een router advertisement uit v.w.b. "fd00:10:x::/64 is hier te vinden". IPv6 connectiviteit naar buiten toe doe ik dan weer NATen (dus de Unbound container die een IPv6 DNS server benaderd gaat via het IP adres van de router / server door NAT op de host dus).

[HollowGamer]

duvekot schreef op woensdag 27 maart 2024 @ 11:45:
[...]

De "consensus" is dat docker en ipv6 niet echt lekker samen werken .. zeker niet met veranderende prefixes etc .. omdat de configuratie vrij statisch is .. of afhankelijk van NAT tussen de host IPv6 en het Docker interne IPv6 netwerk ...

Dus dan kan je beter docker op IPv4 laten .. en een reverse proxy op IPv6 laten draaien die "aan de achterkant" naar de IPv4 docker containers gaat

Wat bedoel je precies met het laatste?

Want ik zit met hetzelfde. Ik gebruik Podman containers, maar volgens mij hebben die standaard IPv6 ook uitstaan. Ik neem aan dat je voor IPv6 DHCP - niet een IPv6-adres als DNS-server kan opgeven (zoals de Pi)?

[babbelbox]

Ik heb IPv6 volgens mij prima werken in docker (op een raspberry-pi, niet persé gerelateerd aan pi-hole)
In m'n docker config heb ik IPv6 enable dmv de volgende regels

code:

    enable_ipv6: true
    ipam:
      config:
        - subnet: 2a10:xxxx:yyyy:d0c1::/64
          gateway: 2a10:xxxx:yyyy:d0c1::1

Daarbij is dus 2a10:xxxx.yyyy het /48 subnet wat ik van m'n provider krijg.
Al m'n containers krijgen dan een 2a10:xxx:yyy:d0c1::/64 adres en hebben IPv6 connectiviteit.
Enige wat ik wel het gedaan is een extra route op m'n ISP connected router gezet voor het subnet, met als nexthop het IPv6 address van m'n raspberrypi zelf
[edit]
Ter verduidelijking:
M'n raspberry pi heeft dus een SLAAC IPv6 in subnet 2a10:xxxx:yyyy:1234::/64
In m'n ISP router heb ik dus een route voor 2a10:xxxx:yyyy:d0c1::/64 naar het GUA adres van m'n raspberry

[ Voor 14% gewijzigd door babbelbox op 27-03-2024 14:30 ]

[Snow_King]

babbelbox schreef op woensdag 27 maart 2024 @ 14:28:
Ik heb IPv6 volgens mij prima werken in docker (op een raspberry-pi, niet persé gerelateerd aan pi-hole)
In m'n docker config heb ik IPv6 enable dmv de volgende regels

code:

    enable_ipv6: true
    ipam:
      config:
        - subnet: 2a10:xxxx:yyyy:d0c1::/64
          gateway: 2a10:xxxx:yyyy:d0c1::1

Daarbij is dus 2a10:xxxx.yyyy het /48 subnet wat ik van m'n provider krijg.
Al m'n containers krijgen dan een 2a10:xxx:yyy:d0c1::/64 adres en hebben IPv6 connectiviteit.
Enige wat ik wel het gedaan is een extra route op m'n ISP connected router gezet voor het subnet, met als nexthop het IPv6 address van m'n raspberrypi zelf
[edit]
Ter verduidelijking:
M'n raspberry pi heeft dus een SLAAC IPv6 in subnet 2a10:xxxx:yyyy:1234::/64
In m'n ISP router heb ik dus een route voor 2a10:xxxx:yyyy:d0c1::/64 naar het GUA adres van m'n raspberry

Zo heb ik het ook gedaan! Mijn provider (Ziggo Zakelijk) geeft mij een vaste prefix en hierdoor heb ik nooit last van een wijziging van het subnet.

[StaticZ]

Ik heb mijn docker containers in een macvlan netwerk gezet welke is gekoppeld aan mijn interne netwerk.
Klein stukje v4 (/27) en de volledige v6 /64 van dat netwerk.
Zo kan alles rechtstreeks zonder router met elkaar babbelen!

@RobertMe find and replace is toch ook zo klaar?

[ Voor 10% gewijzigd door StaticZ op 27-03-2024 14:45 ]

[RobertMe]

babbelbox schreef op woensdag 27 maart 2024 @ 14:28:
Ik heb IPv6 volgens mij prima werken in docker (op een raspberry-pi, niet persé gerelateerd aan pi-hole)
In m'n docker config heb ik IPv6 enable dmv de volgende regels

code:

    enable_ipv6: true
    ipam:
      config:
        - subnet: 2a10:xxxx:yyyy:d0c1::/64
          gateway: 2a10:xxxx:yyyy:d0c1::1

Daarbij is dus 2a10:xxxx.yyyy het /48 subnet wat ik van m'n provider krijg.
Al m'n containers krijgen dan een 2a10:xxx:yyy:d0c1::/64 adres en hebben IPv6 connectiviteit.
Enige wat ik wel het gedaan is een extra route op m'n ISP connected router gezet voor het subnet, met als nexthop het IPv6 address van m'n raspberrypi zelf
[edit]
Ter verduidelijking:
M'n raspberry pi heeft dus een SLAAC IPv6 in subnet 2a10:xxxx:yyyy:1234::/64
In m'n ISP router heb ik dus een route voor 2a10:xxxx:yyyy:d0c1::/64 naar het GUA adres van m'n raspberry

Dit zal inderdaad ook gewoon werken, zolang de prefix niet veranderd (afhankelijk van ISP / type abo / ... heb je "garantie" dat het hetzelfde blijft). Maar had Docker bv niet ook nog quirks met mogelijk wijzigende IPs (afhankelijk van volgorde opstarten en/of MAC dat wijzigt na een recreate)? Zelf heb ik alles in Docker een static IP gegeven. Dus als de prefix zou veranderen zou ik al mijn compose files moeten nalopen

[RobertMe]

StaticZ schreef op woensdag 27 maart 2024 @ 14:38:
@RobertMe find and replace is toch ook zo klaar?

Meerdere files op meerdere systemen Eerste kan worden opgelost met een env variabele en die gebruiken in de docker-compose files.

Maar... als Ziggo mijn IP veranderd blijkt dat 's morgens vroeg. Niet het moment dat ik "mijn internet wil fixen" zeg maar

[babbelbox]

StaticZ schreef op woensdag 27 maart 2024 @ 14:38:
Ik heb mijn docker containers in een macvlan netwerk gezet welke is gekoppeld aan mijn interne netwerk.
Klein stukje v4 (/27) en de volledige v6 /64 van dat netwerk.
Zo kan alles rechtstreeks zonder router met elkaar babbelen!

@RobertMe find and replace is toch ook zo klaar?

Heb me nog niet verdiept in macvlan stuff, maar staat nog wel op de lijst.

[jghaanstra]

Even een status update naar aanleiding van mijn oorspronkelijke vraag. Volgens mij krijgt de Pi-Hole Docker container nu ook via een macvlan netwerk een IPv6 adres. Ik heb het link local IPv6 adres (fe80::42:c0ff:fea8:c6) vervolgens in de DNS config van de IPv6 config van switch0 op de Edgerouter toegevoegd. Alles lijkt nog te werken ...

Of dit zo blijft ga ik meemaken.

Hieronder een stukje van de relevante docker-compose file:

code:

version: '3.8'
services:
  pihole:
    environment:
      - FTLCONF_LOCAL_IPV4=192.168.0.198
      - FTLCONF_LOCAL_IPV6=fe80::42:c0ff:fea8:c6
    .........
    networks:
      pihole_network:
        ipv4_address: 192.168.0.198
        ipv6_address: fe80::42:c0ff:fea8:c6
      default:
        ipv4_address: 172.33.0.198

networks:
  default:
    name: ipv4_default
    external: true
  pihole_network:
    driver: macvlan
    driver_opts:
      parent: eth0
    enable_ipv6: true
    ipam:
      config:
        - subnet: 192.168.0.0/24
          gateway: 192.168.0.1
          ip_range: 192.168.0.198/32
        - subnet: fe80::/10
          gateway: fe80::265a:4cff:fe15:2def

[babbelbox]

Ik weet dat het eigenlijk off-topic is, maar kun je met macvlan ook IP adressen vanuit een centrale DHCP server (router) adressen laten uitdelen aan de containers?

[RobertMe]

babbelbox schreef op woensdag 27 maart 2024 @ 18:29:
Ik weet dat het eigenlijk off-topic is, maar kun je met macvlan ook IP adressen vanuit een centrale DHCP server (router) adressen laten uitdelen aan de containers?

Kort antwoord: ja (dat is de hele bedoeling van macvlan). Lang antwoord kun je krijgen in [Docker] [alle OS] Het grote Docker ervaringen en tips topic

[babbelbox]

RobertMe schreef op woensdag 27 maart 2024 @ 18:37:
[...]

Kort antwoord: ja (dat is de hele bedoeling van macvlan). Lang antwoord kun je krijgen in [Docker] [alle OS] Het grote Docker ervaringen en tips topic

Ik ben bang dat ik je verwezen topic maar even moet gaan doorspitten, want als ik de (korte) tutorial op de docker website volg, krijg ik alleen IPv6 goed, maar geen IPv4 vanuit m'n DHCP

[DaveFlash]

hmm, ik krijg vandaag melding van https://ipv6-test.com dat ipv6 van kpn niet meer actief is, meer mensen last van?


IPv6 Not supported

Browser
Default IPv4
Fallback No

DNS4 + IP6 Unreachable
DNS6 + IP4 Reachable
DNS6 + IP6 Unreachable

alle browsers getest, ook getest op iphone, zelfde slechte resultaten momenteel...

[DaveFlash]

raar, after 2 reboots van kpn box 12 werkt het wel weer. maar de router was van de week ook al nog gereboot geweest

[DaveFlash]

kan het kwaad om in de kpn box 12 firewall op low te zetten, zodat IPv6 / ICMPv6 ongefilterd door komt? bij de https://ipv6-test.com kwam er altijd een score uit van 18/20 en bij ICMP als 'filtered'.

Bij het instellen op 'low' in de kpn box, komt ICMP wel volledig door voor IPv6. Mijn setup overigens is Linux en macOS / iPad / iPhones. Geen Windows bakken hier, behalve als VM's.

Dus kan het dan kwaad, of is het zetten van de firewall van kpn box 12 op 'low' niet erg?

[Snow_King]

DaveFlash schreef op woensdag 1 mei 2024 @ 20:33:
kan het kwaad om in de kpn box 12 firewall op low te zetten, zodat IPv6 / ICMPv6 ongefilterd door komt? bij de https://ipv6-test.com kwam er altijd een score uit van 18/20 en bij ICMP als 'filtered'.

Bij het instellen op 'low' in de kpn box, komt ICMP wel volledig door voor IPv6. Mijn setup overigens is Linux en macOS / iPad / iPhones. Geen Windows bakken hier, behalve als VM's.

Dus kan het dan kwaad, of is het zetten van de firewall van kpn box 12 op 'low' niet erg?

Over het algemeen denk ik dat het weinig kwaad kan. Als op je Mac en de Linux systemen gewoon de host based firewalls aan staan is er niets aan de hand.

Overigens hebben Windows systemen ook vaak een host based firewall.

In de basis sta ik er zo in dat een systeem zichzelf moet kunnen verdedigen en niet afhankelijk moet zijn van een firewall ergens in een netwerk.

[DaveFlash]

Snow_King schreef op woensdag 1 mei 2024 @ 21:10:
[...]

Over het algemeen denk ik dat het weinig kwaad kan. Als op je Mac en de Linux systemen gewoon de host based firewalls aan staan is er niets aan de hand.

Overigens hebben Windows systemen ook vaak een host based firewall.

In de basis sta ik er zo in dat een systeem zichzelf moet kunnen verdedigen en niet afhankelijk moet zijn van een firewall ergens in een netwerk.

yeah systeem firewalls staan altijd aan hier, op ios is dat sws best goed verborgen maar ook die staat default aan. come to think of it, ik weet niet eens waar in ios je dat kunt aan passen...

[DaveFlash]

yes net opgezocht, 'Firewall' geeft geeneens resultaten als ik zoek in Settings op iPhone, dus daar is dit iig niet user configurable en always-on, neem ik aan

[D0ubleD0uble]

DaveFlash schreef op woensdag 1 mei 2024 @ 20:33:
kan het kwaad om in de kpn box 12 firewall op low te zetten, zodat IPv6 / ICMPv6 ongefilterd door komt? bij de https://ipv6-test.com kwam er altijd een score uit van 18/20 en bij ICMP als 'filtered'.

Die test moet je niet zo letterlijk nemen. ICMPv6 verkeer dat daadwerkelijk nodig is wordt altijd wel doorgelaten door de router, alleen ICMPv6 echo requests/replies worden met goede reden geweigerd. Echter gebruikt deze test dus een ICMPv6 ping om deze score te bepalen. Firewall gewoon lekker op normal of high houden.

[RobertMe]

TIL: het open source analytics platform Matomo doet IPv6 adressen maskeren/anonimiseren op een /48, terwijl dit bij een IPv4 adres op /16 is. Dus een IPv4 adres wordt weergegeven / opgeslagen als X.Y.0.0. Terwijl dat bij een IPv6 adres XXXX:YYYY:ZZZZ:: is. Dat betekend dus dat bij een ISP die een /48 uitdeelt aan klanten 0 bits gemaskeerd worden, en bij een ISP die een /54 uitdeelt dus maar 8 bits gemaskeerd worden (vs 16 bits bij IPv4 dus). Dus bij een /48 prefix is het zichtbare IPv6 adres letterlijk dat van de bezoeker / aansluiting, en weet je alleen het specifieke systeem niet. En bij een /54 prefix is er nog steeds een kans van 1 op 256 dat bij een "dubbel" (gemaskeerd) adres het dus dezelfde bezoeker / aansluiting is.

Edit:
Blijkbaar kun je configureren hoeveel bytes geanonimiseerd moeten worden (wat default dan 2 bytes zullen zijn). Waarbij ze bij IPv6 dus ogenschijnlijk 8 bytes + geconfigureerd aantal bytes anonimiseren. Waarbij er dus geen rekening mee wordt gehouden dat er semi de verplichting is dat een ISP een /54 of /48 uitdeelt (dus dat de ISP de mogelijkheid moet geven om meerdere /64s aan te maken onder de prefix). Dus als de ISP dan 1 "byte" aan prefix ruimte geeft is dat alweer 1 byte die van de "geanonimiseerde" bytes af gaat.

[ Voor 25% gewijzigd door RobertMe op 10-05-2024 19:45 ]

[Dreamvoid]

ISPs delen typisch een /48 uit op business abonnement, /56 op vaste lijn internet, en /64 voor mobiel. Dat maakt het lastig om analytics te doen, tenminste, zonder een database die bijhoudt wat voor klanten allocatie elke ISP doet op hun diverse ranges.

Voor IPv4 heb je een vergelijkbaar probleem - soms zit er achter een /32 1 gebruiker, soms een dozijn, en soms een paar honderd.

[RobertMe]

Dreamvoid schreef op maandag 13 mei 2024 @ 18:26:
ISPs delen typisch een /48 uit op business abonnement, /56 op vaste lijn internet, en /64 voor mobiel. Dat maakt het lastig om analytics te doen, tenminste, zonder een database die bijhoudt wat voor klanten allocatie elke ISP doet op hun diverse ranges.

Voor IPv4 heb je een vergelijkbaar probleem - soms zit er achter een /32 1 gebruiker, soms een dozijn, en soms een paar honderd.

Maar dat laatste is dan weer meer relevant als je specifiek wilt targetten. Terwijl Matomo juist wilt anonimiseren. En anonimiseren op /64 + 0 / 1 / 2 bytes met 2 bytes als default lijkt mij dan nogal beperkt. Aangezien je dan juist een best groot risico hebt dat je nog steeds een specifieke aansluiting opslaat / volgt. En het niet een geanonimiseerd groter subnet met duizenden aansluitingen is. Immers zullen /48s en /56s in het wild zeer vaak voorkomen. En als je het maximale aantal bytes (2 dus) doet anonimiseren bij een /48 zijn er dus 0 bytes van "de aansluiting" geanonimiseerd, en bij een /56 maar 1 byte dus is er nog steeds een kans van 1 op 255 dat hetzelfde geanonimiseerde adres bij dezelfde aansluiting behoort.

IMO zouden er dus (by default) van een IPv6 adres dus meer bytes geanonimiseerd mogen worden (/die 0 / 1 / 2 bytes anonimiseren bovenop 17 of 18 bytes en niet bovenop 16 bytes). Aangezien het vrij normaal is dat een aansluiting (veel) meer IP adressen tot zijn beschikking heeft dan puur de /64 (/16 bytes) die zij nu als basis nemen.
Terwijl je bij IPv4 wel redelijk zeker kunt zijn dat 1 IP bij 1 aansluiting hoort en er niet 2 naastgelegen IPs bij dezelfde aansluiting horen (uitzonderingen daargelaten met zakelijk en meerdere IPs etc). Terwijl bij IPv6 2 naastgelegen /64 subnets zeer waarschijnlijk juist wel onder dezelfde aansluiting vallen (omdat de aansluiting een /48 of /56 heeft).
En dat uiteraard gecombineerd met "privacy friendly". Nouja, zo privacy friendly is het niet als IPv6 adressen eigenlijk niet echt (heel erg) geanonimiseerd worden opgeslagen in veel gevallen.

[Dreamvoid]

RobertMe schreef op maandag 13 mei 2024 @ 18:56:
[...]

Maar dat laatste is dan weer meer relevant als je specifiek wilt targetten. Terwijl Matomo juist wilt anonimiseren. En anonimiseren op /64 + 0 / 1 / 2 bytes met 2 bytes als default lijkt mij dan nogal beperkt. Aangezien je dan juist een best groot risico hebt dat je nog steeds een specifieke aansluiting opslaat / volgt. En het niet een geanonimiseerd groter subnet met duizenden aansluitingen is. Immers zullen /48s en /56s in het wild zeer vaak voorkomen. En als je het maximale aantal bytes (2 dus) doet anonimiseren bij een /48 zijn er dus 0 bytes van "de aansluiting" geanonimiseerd, en bij een /56 maar 1 byte dus is er nog steeds een kans van 1 op 255 dat hetzelfde geanonimiseerde adres bij dezelfde aansluiting behoort.

IMO zouden er dus (by default) van een IPv6 adres dus meer bytes geanonimiseerd mogen worden (/die 0 / 1 / 2 bytes anonimiseren bovenop 17 of 18 bytes en niet bovenop 16 bytes). Aangezien het vrij normaal is dat een aansluiting (veel) meer IP adressen tot zijn beschikking heeft dan puur de /64 (/16 bytes) die zij nu als basis nemen.
Terwijl je bij IPv4 wel redelijk zeker kunt zijn dat 1 IP bij 1 aansluiting hoort en er niet 2 naastgelegen IPs bij dezelfde aansluiting horen (uitzonderingen daargelaten met zakelijk en meerdere IPs etc). Terwijl bij IPv6 2 naastgelegen /64 subnets zeer waarschijnlijk juist wel onder dezelfde aansluiting vallen (omdat de aansluiting een /48 of /56 heeft).

/64s zijn inderdaad veel te specifiek, maar het lastige is dus dat je afhankelijk van de IP range verschillend moet anonymiseren: voor mobiele telefonie is een /56 voldoende om op 256 gebruikers te anonymiseren, voor een vaste aansluiting moet je dat op een /48 doen.

Voor IPv4 zou het equivalent zijn om te anonymiseren op /24 voor vaste aansluitingen en op /32 voor mobiel.

[watabstract]

De provider hier (Digi in Spanje) heeft momenteel een routing issue. Na lang klooien met de router settings ontdek ik net dat domeinen niet bereikbaar zijn als er geen IPv6-adres aan hangt. Oftewel alleen IPv6 werkt momenteel. IPv4 ligt plat. En dan kom je er achter hoeveel diensten nog geen IPv6 ondersteunen. Zelfs het grote speedtest.net doet het nu niet. En helaas is mijn werk hierdoor ook onbereikbaar. Datacenters in Nederland vinden het blijkbaar ook niet belangrijk om IPv6 te ondersteunen. Onbegrijpelijk anno 2024.

[RobertMe]

watabstract schreef op maandag 20 mei 2024 @ 21:54:
De provider hier (Digi in Spanje) heeft momenteel een routing issue. Na lang klooien met de router settings ontdek ik net dat domeinen niet bereikbaar zijn als er geen IPv6-adres aan hangt. Oftewel alleen IPv6 werkt momenteel. IPv4 ligt plat. En dan kom je er achter hoeveel diensten nog geen IPv6 ondersteunen. Zelfs het grote speedtest.net doet het nu niet. En helaas is mijn werk hierdoor ook onbereikbaar. Datacenters in Nederland vinden het blijkbaar ook niet belangrijk om IPv6 te ondersteunen. Onbegrijpelijk anno 2024.

Vinden datacenters het niet belangrijk, vinden de klanten van de datacenters het niet belangrijk, of vinden de klanten van de klanten van de datacenters het niet belangrijk?

Ik denk dat de datacenters wel IPv6 ondersteunen. De dienstverleners die er in zitten ook wel (in ieder geval de grotere). Maar dat betekend niet dat de daadwerkelijke afnemers het ook willen / gebruiken.

Case in point: bedrijf waar ik werk neemt twee managed servers af bij True. De staging server is wel (op aanvraag van "ons") IPv6 op geactiveerd (of in ieder geval op 1 domein). De productie server doet helemaal geen IPv6 (bij mijn weten). Dus True ondersteund het prima, alleen vragen "wij" als klant er blijkbaar niet naar.
Heb er zelf ook wel eens vaker op gewezen, maar dan komt eigenlijk nooit een reactie.

[watabstract]

RobertMe schreef op maandag 20 mei 2024 @ 22:13:
[...]

Vinden datacenters het niet belangrijk, vinden de klanten van de datacenters het niet belangrijk, of vinden de klanten van de klanten van de datacenters het niet belangrijk?

Ik denk dat de datacenters wel IPv6 ondersteunen. De dienstverleners die er in zitten ook wel (in ieder geval de grotere). Maar dat betekend niet dat de daadwerkelijke afnemers het ook willen / gebruiken.

Case in point: bedrijf waar ik werk neemt twee managed servers af bij True. De staging server is wel (op aanvraag van "ons") IPv6 op geactiveerd (of in ieder geval op 1 domein). De productie server doet helemaal geen IPv6 (bij mijn weten). Dus True ondersteund het prima, alleen vragen "wij" als klant er blijkbaar niet naar.
Heb er zelf ook wel eens vaker op gewezen, maar dan komt eigenlijk nooit een reactie.

Des te erger als niemand in de hele keten erom vraagt. Opvallend veel websites ondersteunen geen IPv6. Daardoor kan ik nu online heel veel niet meer. Toch wel jammer als je het thuis wel gewoon netjes voor elkaar hebt. Ik snap dat IPv6 implementeren een boel nieuwe routing rules e.d. kan betekenen maar anno 2024 is er wat mij betreft geen enkel excuus meer. IPv6 bestaat al minstens 30 jaar. Als het nog steeds zo weinig is doorgedrongen dan kunnen we denk ik wel de conclusie trekken dat het nooit wat wordt.

[babbelbox]

Meerdere mensen met een Freedom aansluiting bij wie de IPv6 DNS servers niet meer op ping reageren?
Heb een smokeping dockertje draaien en daar bleek zojuist dat er al langer dan 10 dagen geen reply (meer) is.
Heb zojuist vanuit diverse devcies in m'n interne network geprobeerd maar geen van allen krijgt een reply.
traceroute geeft ook slechts een klein aantal hops

code:

 1  2a10-<intern>.connected.by.freedominter.net (2a10:<intern>::1)  0.036 ms  0.027 ms  0.019 ms
 2  2a10-<intern>.connected.by.freedominter.net (2a10:<intern>::1)  0.288 ms  0.279 ms  0.282 ms
 3  2a10:3780::230 (2a10:3780::230)  3.286 ms  3.354 ms  3.137 ms
 4  ae0-1000.core0.fi001.nl.freedomnet.nl (2a10:3780:1::1e)  3.016 ms  3.220 ms  3.304 ms
 5  *  *  *
 6  *  *  *

[Dreamvoid]

watabstract schreef op dinsdag 21 mei 2024 @ 13:21:
Des te erger als niemand in de hele keten erom vraagt. Opvallend veel websites ondersteunen geen IPv6. Daardoor kan ik nu online heel veel niet meer. Toch wel jammer als je het thuis wel gewoon netjes voor elkaar hebt. Ik snap dat IPv6 implementeren een boel nieuwe routing rules e.d. kan betekenen maar anno 2024 is er wat mij betreft geen enkel excuus meer. IPv6 bestaat al minstens 30 jaar. Als het nog steeds zo weinig is doorgedrongen dan kunnen we denk ik wel de conclusie trekken dat het nooit wat wordt.

Het halve internet draait er inmiddels op, dus dat lijkt me nogal overdreven.

Punt is meer dat niemand IPv6 uitrolt zonder bijbehorende backwards compatibility (dual stack, DS-Lite tunnel, NAT64/MAP translation), dus dan gaat iedereen op het internet ervan uit dat een fallback naar IPv4 altijd werkt. En krijg je problemen als je in de situatie belandt waar je backwards compatibility niet werkt.

[watabstract]

Dreamvoid schreef op donderdag 23 mei 2024 @ 11:08:
[...]

Het halve internet draait er inmiddels op, dus dat lijkt me nogal overdreven.

Punt is meer dat niemand IPv6 uitrolt zonder bijbehorende backwards compatibility (dual stack, DS-Lite tunnel, NAT64/MAP translation), dus dan gaat iedereen op het internet ervan uit dat een fallback naar IPv4 altijd werkt. En krijg je problemen als je in de situatie belandt waar je backwards compatibility niet werkt.

Tja ik heb het zelf ervaren de afgelopen dagen. Gelukkig is het inmiddels gefixt. Ik kon bijv geen VPN applicatie installeren omdat Windows Smartscreen niet bereikbaar was om de installer te checken. Speedtest werkt alleen via IPv4. Zelfs de website van de provider waar je kunt chatten met support ondersteunt geen IPv6. Tweakers deed het wel maar bijv nu.nl en enkele kranten sites waren onbereikbaar. Helaas ondersteunt onze bedrijfsserver het ook niet, ondanks mijn verzoek enkele jaren geleden. Die commerciële vpn dienst wilde ik installeren om een tunnel op te zetten via IPv6 zodat ik daarmee het hele internet alsnog zou kunnen bereiken maar installeren wilde dus niet. En ik kan smartscreen niet tijdelijk uitzetten want dat is gelockt door de beheerder van de laptop. Geen idee waarom dat overdreven zou zijn als ik hierdoor simpelweg m'n werk niet kon doen.

[watabstract]

watabstract schreef op maandag 12 februari 2024 @ 02:40:
Ik kan inmiddels rapporteren dat IPv6 met Linux (Kubuntu) vanaf een live USB feilloos werkt en blijft werken. Na ongeveer een uur is de IPv6-verbinding nog steeds intact. De Tweakers frontpage laadt middels IPv6 volgens de Firefox network monitor en ook website v6.testmyipv6.com blijft het doen. Met de hardware is er dus niets aan de hand.

@Roetzen @Jerrythafast @Dreamvoid @Snow_King @RobertMe

Om even op een post van mezelf te reageren enkele maanden geleden: ik kan inmiddels met enige zekerheid zeggen dat het een specifiek Windows 11 probleem is. Ik kan er alleen de vinger niet op leggen. Online kom ik vrij weinig bronnen tegen.

Ik heb de Asus ET8 router inmiddels met zowel de stock firmware (laatste versie) als de Merlin-variant getest. Na elke flash heb ik deze gereset en vervolgens heb ik alleen de wifi ingesteld en (native) IPv6 ingeschakeld. Verder geen aanpassingen, geen alternatieve DNS-servers en geen eigen scripts. Het probleem blijft bestaan. Na enkele minuten verliest Windows het IPv6-adres. Ik heb nu de router van de provider weer neergezet, die overigens gelukkig wel wifi AX ondersteunt met 160 MHz maar helaas geen 6 GHz (slechts dual band). Met deze router blijft het IPv6-adres wel in de lijst staan in Windows 11 maar ook dan zijn na verloop van tijd IPv6-adressen niet meer routeerbaar. Alleen link-local fe80:: blijft in alle situaties werken.

Deze problemen doen zich alleen voor op de laptop met Windows 11. Vier Android devices en een laptop met Kubuntu houden gewoon hun IPv6 connecties. En in de herhaling: als de Windows-laptop wordt opgestart met een Kubuntu USB-stick dan gaat het dus ook gewoon goed dus een hardwareprobleem lijkt uitgesloten. Windows 11 lijkt dus echt de spelbreker te zijn maar ik krijg het helaas niet gedebugged.

[Jef61]

watabstract schreef op donderdag 23 mei 2024 @ 14:46:
[...]
Windows 11 lijkt dus echt de spelbreker te zijn maar ik krijg het helaas niet gedebugged.

Ik zou het als volgt debuggen:
Eerst 100% zeker zijn dat het probleem in windows zit, met de laptop naar vrienden/kenissen (met IPv6 in hun netwerk) en testen. Gaat het hier ook fout dan een clean install van windows. Een variatie is een laptop van vrienden/kenissen in jouw netwerk zetten en kijken wat er gebeurd.

Of heb je dit allemaal al geprobeerd?

Wat gebeurt er eigenlijk als je je windows laptop voorziet van een statisch IPv6 adres?

[watabstract]

Jef61 schreef op donderdag 23 mei 2024 @ 18:14:
[...]

Ik zou het als volgt debuggen:
Eerst 100% zeker zijn dat het probleem in windows zit, met de laptop naar vrienden/kenissen (met IPv6 in hun netwerk) en testen. Gaat het hier ook fout dan een clean install van windows. Een variatie is een laptop van vrienden/kenissen in jouw netwerk zetten en kijken wat er gebeurd.

Of heb je dit allemaal al geprobeerd?

Wat gebeurt er eigenlijk als je je windows laptop voorziet van een statisch IPv6 adres?

Ik heb het inmiddels met 3 verschillende routers getest dus ik zie niet wat het nut is om de laptop ergens anders te testen. Het IP adres is in feite al statisch want dit wordt opgebouwd obv de prefix en het Mac adres. Nu kan ik misschien het adres er in zijn geheel wel hard inzetten maar dat is helaas geen oplossing want de prefix is zelf niet statisch in de router maar verandert na een router reboot.

Uiteraard hou ik het in de gaten als ik elders een keer een IPv6 adres zie langskomen maar ik verwacht geen wonder.

[Jef61]

watabstract schreef op vrijdag 24 mei 2024 @ 00:37:
[...]

Ik heb het inmiddels met 3 verschillende routers getest dus ik zie niet wat het nut is om de laptop ergens anders te testen. Het IP adres is in feite al statisch want dit wordt opgebouwd obv de prefix en het Mac adres. Nu kan ik misschien het adres er in zijn geheel wel hard inzetten maar dat is helaas geen oplossing want de prefix is zelf niet statisch in de router maar verandert na een router reboot.

Uiteraard hou ik het in de gaten als ik elders een keer een IPv6 adres zie langskomen maar ik verwacht geen wonder.

Dat bedoel ik idd, hard een IPv6 ades erin zetten, dat doe je met een server in je netwerk toch ook?
Prefix gedeelte is vast van je provider, dan je eigen subnetting en nog een host adres. Dit is niet bedoeld als een oplossing maar als debugging, Je zult moeten gaan uitsluiten waar het probleem niet zit.

Maar ik begrijp uit je verhaal dat je er zeker van bent dat het aan windows ligt, heb je die dan al een clean install gegeven?

[watabstract]

Jef61 schreef op vrijdag 24 mei 2024 @ 08:45:
[...]

Dat bedoel ik idd, hard een IPv6 ades erin zetten, dat doe je met een server in je netwerk toch ook?
Prefix gedeelte is vast van je provider, dan je eigen subnetting en nog een host adres. Dit is niet bedoeld als een oplossing maar als debugging, Je zult moeten gaan uitsluiten waar het probleem niet zit.

Maar ik begrijp uit je verhaal dat je er zeker van bent dat het aan windows ligt, heb je die dan al een clean install gegeven?

Dat laatste is geen optie helaas. Dit is een managed device van werk. Maar stel ik zet er een vast v6 adres in en het werkt? En dan? Waar het wellicht fout gaat, is het stukje met router advertisements. Als daar een bug zit dan ga ik er weinig aan kunnen oplossen met een hard v6 adres erin toch? Prefix delegation is een nogal essentieel onderdeel van het geheel.

[Jef61]

watabstract schreef op vrijdag 24 mei 2024 @ 09:50:
[...]

Dat laatste is geen optie helaas. Dit is een managed device van werk. Maar stel ik zet er een vast v6 adres in en het werkt? En dan? Waar het wellicht fout gaat, is het stukje met router advertisements. Als daar een bug zit dan ga ik er weinig aan kunnen oplossen met een hard v6 adres erin toch? Prefix delegation is een nogal essentieel onderdeel van het geheel.

Ah, een 'managed device van het werk', dan zou ik stoppen met zoeken. Toevallig zelf meegemaakt (al wat langer geleden) dat ze IPv6 hadden uitgezet want moeilijk enz. VPN naar het werk zou ook nog kunnen waardoor IPv6 wordt uitgeschakeld.

[RobertMe]

watabstract schreef op vrijdag 24 mei 2024 @ 09:50:
[...]

Dat laatste is geen optie helaas. Dit is een managed device van werk. Maar stel ik zet er een vast v6 adres in en het werkt? En dan? Waar het wellicht fout gaat, is het stukje met router advertisements. Als daar een bug zit dan ga ik er weinig aan kunnen oplossen met een hard v6 adres erin toch? Prefix delegation is een nogal essentieel onderdeel van het geheel.

"En dan?". Dan heb je een aanknopingspunt waar het probleem zich bevindt en kun je specifieker zoeken (/Googlen/...) naar een probleem daarmee. Of een bug report doen bij Microsoft, of de specifiekere probleemstelling hier voorleggen, of....

Met de informatie die je nu hebt kom je blijkbaar sowieso niet verder. Als je weet dat een static adres wel/niet werkt ben je in ieder geval zelf weer een stukje verder in het achterhalen van het probleem / de oorzaak. En wellicht kom je bij het instellen van een static IP er wel achter dat een andere instelling scheef staat. Of zie je iets (een instelling) die je opvalt omdat bv iets afwijkt met wat je ergens anders hebt gezien (op internet, een gelijksoortige instelling in de router, ...).

[watabstract]

Jef61 schreef op vrijdag 24 mei 2024 @ 10:00:
[...]

Ah, een 'managed device van het werk', dan zou ik stoppen met zoeken. Toevallig zelf meegemaakt (al wat langer geleden) dat ze IPv6 hadden uitgezet want moeilijk enz. VPN naar het werk zou ook nog kunnen waardoor IPv6 wordt uitgeschakeld.

Ok bedankt! Ik sluit niet helemaal uit dat het daaraan ligt inderdaad. Alleen werkt IPv6 dus wel tijdelijk als de wifi verbinding is opgezet. Het staat ook gewoon enabled in de netwerkadapter. Ik heb geen ander Windows device in huis om mee te testen. Prive is alles Android en Linux maar misschien swap ik de SSD een keer in deze laptop en zet ik er zelf Windows 11 op om te testen.

[watabstract]

RobertMe schreef op vrijdag 24 mei 2024 @ 10:01:
[...]

"En dan?". Dan heb je een aanknopingspunt waar het probleem zich bevindt en kun je specifieker zoeken (/Googlen/...) naar een probleem daarmee. Of een bug report doen bij Microsoft, of de specifiekere probleemstelling hier voorleggen, of....

Met de informatie die je nu hebt kom je blijkbaar sowieso niet verder. Als je weet dat een static adres wel/niet werkt ben je in ieder geval zelf weer een stukje verder in het achterhalen van het probleem / de oorzaak. En wellicht kom je bij het instellen van een static IP er wel achter dat een andere instelling scheef staat. Of zie je iets (een instelling) die je opvalt omdat bv iets afwijkt met wat je ergens anders hebt gezien (op internet, een gelijksoortige instelling in de router, ...).

Thanks! Ik heb al uitvoerig gekeken naar router advertisements op het netwerk of ik daar iets geks zie maar dat is niet het geval. De laptop verliest z'n IPv6 adres terwijl er nog steeds prefix delegations worden verzonden. Inmiddels heb ik ook al gezien dat het niet router afhankelijk is. Het gaat altijd mis en alleen met deze ene laptop. Alle andere apparaten in huis doen het goed. Instellingen ben ik ook al paar keer nagelopen. Het moet haast wel ergens in het DHCP mechanisme zitten. Verder weet ik niet zo goed hoe ik dit moet rapporteren. Ik ben niet zo thuis in Windows en de kanalen waar je moet zijn richting Microsoft. Liefst zou ik eerst een ander Windows device testen maar die heb ik niet. Zoals hierboven geschreven swap ik de SSD wel een keer en zet ik er zelf een nieuwe W11 installatie op om te kijken wat er dan gebeurt.

[D0ubleD0uble]

watabstract schreef op vrijdag 24 mei 2024 @ 10:06:
[...]

Ok bedankt! Ik sluit niet helemaal uit dat het daaraan ligt inderdaad. Alleen werkt IPv6 dus wel tijdelijk als de wifi verbinding is opgezet. Het staat ook gewoon enabled in de netwerkadapter. Ik heb geen ander Windows device in huis om mee te testen. Prive is alles Android en Linux maar misschien swap ik de SSD een keer in deze laptop en zet ik er zelf Windows 11 op om te testen.

Router Advertisements kunnen soms heel erg venijnig zijn waardoor je apparaten de verbinding verliezen. Ik heb een soortgelijk probleem gehad onder Android en iOS apparaten. Androids verliezen in standy doodleuk hun IPv6 adres (opgelost door IPv6-Only te draaien) maar hierdoor krijgen iOS apparaten juist problemen. Uiteindelijk lag de fix hem in de RDNSS lifetimes die ze kregen vanuit de RAs. Deze heb ik op 604800 (een week) gezet en sindsdien verliezen apparaten nooit meer hun adres.

[watabstract]

D0ubleD0uble schreef op vrijdag 24 mei 2024 @ 10:43:
[...]

Router Advertisements kunnen soms heel erg venijnig zijn waardoor je apparaten de verbinding verliezen. Ik heb een soortgelijk probleem gehad onder Android en iOS apparaten. Androids verliezen in standy doodleuk hun IPv6 adres (opgelost door IPv6-Only te draaien) maar hierdoor krijgen iOS apparaten juist problemen. Uiteindelijk lag de fix hem in de RDNSS lifetimes die ze kregen vanuit de RAs. Deze heb ik op 604800 (een week) gezet en sindsdien verliezen apparaten nooit meer hun adres.

Dan ga ik dat ook zeker proberen! Hopelijk kan ik het aanpassen in de Asus router.

[watabstract]

D0ubleD0uble schreef op vrijdag 24 mei 2024 @ 10:43:
[...]

Router Advertisements kunnen soms heel erg venijnig zijn waardoor je apparaten de verbinding verliezen. Ik heb een soortgelijk probleem gehad onder Android en iOS apparaten. Androids verliezen in standy doodleuk hun IPv6 adres (opgelost door IPv6-Only te draaien) maar hierdoor krijgen iOS apparaten juist problemen. Uiteindelijk lag de fix hem in de RDNSS lifetimes die ze kregen vanuit de RAs. Deze heb ik op 604800 (een week) gezet en sindsdien verliezen apparaten nooit meer hun adres.

Helaas. Ik heb de lease time op 1 week gezet in de router maar na enige tijd is de Windows laptop weer de enige die de IPv6-verbinding verliest. Ik hou het voorlopig maar op een misconfiguratie ergens door de beheerder. Misschien test ik dit weekend al een keer een verse Windows 11 installatie op een andere SSD. Ben wel benieuwd of het dan wel goed gaat.

[Snow_King]

NOS lijkt naar een nieuw CDN te zijn gegaan, het valt mij op dat cdn.nos.nl en static.nos.nl nu wel IPv6 hebben! Dit was vorige week niet zo.

nos.nl had al wel IPv6, maar niet alles dus. Dit is nu opgelost.

[RobertMe]

Blijkbaar kun je in Firefox "happy eyeballing" uit zetten, in about:config met de network.http.fast-fallback-to-IPv4 flag. Iemand dit wel eens geprobeerd?

* RobertMe zag net in IPvFoo dat die Tweakers in IPv4 zat te browsen, "dat kan niet de bedoeling zijn"

[ANdrode]

Snow_King schreef op woensdag 5 juni 2024 @ 16:47:
NOS lijkt naar een nieuw CDN te zijn gegaan, het valt mij op dat cdn.nos.nl en static.nos.nl nu wel IPv6 hebben! Dit was vorige week niet zo.

nos.nl had al wel IPv6, maar niet alles dus. Dit is nu opgelost.

Wel interessant dat ze een nationaal CDN kiezen.

Natuurlijk zijn de cloud-providers relatief duur. En bekende CDN namen ook nog. Maar wat zal vanaf daar het gat naar de Nederlandse partij zijn?

De bandbreedte is relatief voorspelbaar. Eigenlijk zou je hier een prijs in megabits kunnen bedenken in plaats van in GBs.

[aawe mwan]

Ik ben overgestapt van mobiele provider en nu heb ik eindelijk IPv6 op mijn telefoon.
Dit werkt: via een terminal app kan ik vanaf de telefoon inloggen op mijn server thuis via IPv6.

Maar nu het volgende probleem: ik zou deze mobiele IPv6 ook dit ook graag op mijn laptop kunnen gebruiken. Helaas blijkt dat zowel "USB tethering" als "Mobile Hotspot" alleen een IPv4 verbinding maken tussen de telefoon en de laptop. Bestaat hier al een oplossing voor?

Mijn telefoon is een Pixel 8a onder Android 14 op het KPN netwerk, mijn laptop draait Linux Mint 21.3

[Snow_King]

aawe mwan schreef op zaterdag 22 juni 2024 @ 18:08:
Ik ben overgestapt van mobiele provider en nu heb ik eindelijk IPv6 op mijn telefoon.
Dit werkt: via een terminal app kan ik vanaf de telefoon inloggen op mijn server thuis via IPv6.

Maar nu het volgende probleem: ik zou deze mobiele IPv6 ook dit ook graag op mijn laptop kunnen gebruiken. Helaas blijkt dat zowel "USB tethering" als "Mobile Hotspot" alleen een IPv4 verbinding maken tussen de telefoon en de laptop. Bestaat hier al een oplossing voor?

Mijn telefoon is een Pixel 8a onder Android 14 op het KPN netwerk, mijn laptop draait Linux Mint 21.3

Dat lijkt een ding van je telefoon. Met mijn iPhone 13 bij KPN heb ik op mijn laptop wel IPv6

[davegriffejoen]

aawe mwan schreef op zaterdag 22 juni 2024 @ 18:08:
Ik ben overgestapt van mobiele provider en nu heb ik eindelijk IPv6 op mijn telefoon.
Dit werkt: via een terminal app kan ik vanaf de telefoon inloggen op mijn server thuis via IPv6.

Maar nu het volgende probleem: ik zou deze mobiele IPv6 ook dit ook graag op mijn laptop kunnen gebruiken. Helaas blijkt dat zowel "USB tethering" als "Mobile Hotspot" alleen een IPv4 verbinding maken tussen de telefoon en de laptop. Bestaat hier al een oplossing voor?

Mijn telefoon is een Pixel 8a onder Android 14 op het KPN netwerk, mijn laptop draait Linux Mint 21.3

Kan het zijn dat je telefoon nog met de WiFi verbonden is? Als ik dan de mobile hotspot inschakel krijg ik ook alleen een ipv4 adres. Met wifi uit lukt ipv6 wel.

[aawe mwan]

davegriffejoen schreef op zaterdag 22 juni 2024 @ 21:03:
[...]
Kan het zijn dat je telefoon nog met de WiFi verbonden is? Als ik dan de mobile hotspot inschakel krijg ik ook alleen een ipv4 adres. Met wifi uit lukt ipv6 wel.

Ik heb het voor de zekerheid geprobeerd door eerst WiFi te verbreken, dan pas mobiele data aan te zetten en pas dan tethering aan te zetten.

Dat werkte in eerste instantie nog niet, maar even later zag ik ineens dat mijn computer wel IPv6 adressen had. En nu is het een kwestie van de tethering uit en aan zetten en steeds krijgt hij direct weer IPv6 adressen. Ik zie 10/10 op https://test-ipv6.com/ dus alle problemen lijken opgelost.

In het scherm "Over de telefoon" zie je soms maar 1 mobiel IPv6 adres staan, dus wat je daar ziet is niet belemmerend voor USB tethering.

[ Voor 104% gewijzigd door aawe mwan op 22-06-2024 22:17 ]

[aawe mwan]

Nu ik IPv6 werkend heb met KPN op mijn telefoon, ben ik ook nog eens gaan kijken naar de Archer MR200 mobiele router. De website zegt "Supports IPv4 and IPv6". Maar IPv6 heb ik tot nu toe nog niet werkend gekregen. Ik heb er 2 jaar geleden al eens een vraag over gesteld:

aawe mwan schreef op vrijdag 13 mei 2022 @ 17:00:
[...] heb ik voor mobiel internet nu ook een nieuwe SIM gekregen op het KPN netwerk. Die gebruik ik in een pricewatch: TP-Link Archer MR200 V4.

Ik heb "PDP Type" ingesteld op "IPv4 & IPv6" en de APN op "internet", maar dan krijgt hij nog steeds alleen een IPv4 adres. Ga ik naar test-ipv6.com dan zie ik daar "Geen IPv6 adres gedetecteerd".[...]

Op andere forums heb ik gelezen dat deze router IPv6 alleen ondersteunt via een "tunnel".
Die moet je na elke reboot opnieuw handmatig aanzetten op de router. De 3 mogelijkheden:

• "6rd" de laptop krijgt alleen een fe80 adres
• "6to4" de laptop krijgt een fe80 adres en twee 2002 adressen
• "DS-Lite" deze keuze is grijs in het menu en ik kan hem niet selecteren

Helaas ook na het inschakelen van een "tunnel" geen IPv6 hosts op internet benaderen via deze router. Ik heb het geprobeerd met nu.nl en met mijn eigen IPv6 homeserver bij XS4ALL. Zou dat wel moeten werken?

[Dreamvoid]

Dit is een oude router zonder native IPv6 support inderdaad, gaat niet werken op Nederlandse mobiele netwerken, die doen allemaal native IPv6, geen tunneling.

Verbaast me overigens dat je met 6to4 een 2000::/3 adres krijgt, aangezien 6to4 al bijna tien jaar obsoleted is.

Kan je IPv6 adressen (dus niet hostnames) pingen? Bv de Google DNS server 2001:4860:4860::8888 ?

[ Voor 6% gewijzigd door Dreamvoid op 06-07-2024 15:09 ]

[Jef61]

aawe mwan schreef op zaterdag 6 juli 2024 @ 11:03:
Ik heb het geprobeerd met nu.nl en met mijn eigen IPv6 homeserver bij XS4ALL. Zou dat wel moeten werken?

Ik zou even opletten om te testen met nu.nl, die krijg ik ook nooit goed binnen via IPv6.
Dat is altijd een vreemde mix van IPv4 en IPv6:

[RobertMe]

Krijg je op mobiele netwerken eigenlijk altijd dezelfde IPv6 prefix? Of kan die elke keer dat je verbindt anders zijn? Of in andere woorden: kun je bv IP whitelisting doen op basis van de prefix die je op het mobiele netwerk krijgt?

Zou in mijn eigen geval om Simyo gaan.

[Dreamvoid]

Voor zover ik weet krijg je bij alle IPv6 mobiele netwerken in Europa een dynamische /64, behalve bij 4G/5G router abonnementen. Maar ik moet toegeven, ik heb ze niet allemaal getest.

In NL is er voorlopig alleen KPN met IPv6 op het mobiele net, zijn er evaringen?

[ Voor 60% gewijzigd door Dreamvoid op 07-07-2024 21:38 ]

[St00mwals]

Dreamvoid schreef op zondag 7 juli 2024 @ 21:36:
[...]
In NL is er voorlopig alleen KPN met IPv6 op het mobiele net, zijn er evaringen?

Niet verder dan dat ik geen problemen ervoor met mobiel internet op KPN.
Zie wel bij speedtests e.d. netjes een IPv6 adres geregistreerd staan, maar op basis van welke techniek als dat dat is....

[RobertMe]

Dreamvoid schreef op zondag 7 juli 2024 @ 21:36:
In NL is er voorlopig alleen KPN met IPv6 op het mobiele net, zijn er evaringen?

En @St00mwals. Ik had zaterdag dus even een testje gedaan met telefoon via mobiele netwerk (Simyo dan) en vervolgens USB tethering, en kreeg (zoals verwacht?) op de laptop een GUA adres toegekend. Verder niet echt gekeken.

Wel een beetje op internet gezocht en blijkbaar werkt het bij mobiel iets anders dan "gewoon". Vanuit telefonie netwerk zeg maar (/opzetten data verbinding) wordt een prefix gecommuniceerd en het toestel kiest dus een IP adres binnen die prefix (+ zal deze prefix dan ook hanteren voor router advertisements met hotspot / tethering). Terwijl je "gewoon" (vaste aansluiting, router achter ISP modem / ISP modem/router combi) dus een WAN en LAN kant hebt en de WAN IP vanuit een router advertisement uit het WAN netwerk van de ISP komt en je aan LAN kant dus met DHCP-PD werkt.

En lang geleden ook eens een "CGNAT" test gedaan op mobiel. Op IPv6 ging dat gewoon prima (geen CGNAT), IPv4 was wel duidelijk CGNAT.

[Dreamvoid]

Er valt niet zoveel met DHCPv6-PD aan de LAN kant te doen bij mobiele tethering, want een /64 is al de kleinst mogelijke prefix.

[RobertMe]

Dreamvoid schreef op maandag 8 juli 2024 @ 11:41:
Er valt niet zoveel met DHCPv6-PD aan de LAN kant te doen bij mobiele tethering, want een /64 is al de kleinst mogelijke prefix.

Dat is ook niet perse wat ik bedoelde, maar inderdaad

Ik bedoelde gewoon "het werkt allemaal net wat anders blijkbaar op technisch niveau". Want de prefix komt uit de telefonie techniek zeg maar. En je hebt dus ook geen onderscheid tussen WAN & LAN. En eigenlijk is het in 99% van de gevallen natuurlijk ook belachelijk dat je een volledige /64 krijgt toegekend terwijl je maar 1 IP nodig hebt (als in: zoals bij een vaste aansluiting met de WAN poort zou je ook in een netwerk van alle telefoons/modems geplaats kunnen worden waarin iedereen dus dezelfde prefix heeft). Want die hele /64 is natuurlijk eigenlijk alleen interessant als je een hotspot opzet / USB tethering gebruikt.

[DDX]

Microsoft een stap verder in ipv6 implementatie bij toegang tot sql server/databases op Azure :



Klik je op 'add your client ipv4 adres' krijg je natuurlijk nog wel de melding :
IP address must be a valid IPv4 address.

[RobertMe]

Weet iemand of het onder Linux mogelijk is om de privacy extension (/temporary address) toe te passen op een per prefix basis? Ik werk intern zowel met een GUA als een ULA adres. En zou graag willen dat (bv) mijn server(tje) naar het internet babbelt met een temporary address, maar intern wel een "vast" IP adres gebruikt. Dit dus zodat het IP adres naar het internet willekeurig is, maar ik intern, naar een ULA adres dus, wel gewoon zijn vaste ULA kan zien / gebruiken (bv voor auditing of firewalling).

Op het servertje gebruik ik systemd-networkd voor het networking verhaal. En wat ik nu heb is:

INI:

...

[Network]
...
Address fd00:1::40/64
IPv6PrivacyExtensions=true

[IPv6AcceptRA]
PrefixDenyList=fd00:1::/64

Dit levert als GUA netjes 2 semi willekeurige adressen op (een vaste via SLAAC, en dan een temporary address), alleen levert het dus ook 2 ULA adressen op, de statisch geconfigureerde fd00:1::40, maar ook een temporary address. En verkeer naar andere fd00:1::/64 adressen verloopt vervolgens dus ook over dit temporary address. En dat is nu juist niet mijn bedoeling. Uiteraard kan ik ook de routing tabel er op aanpassen, dat die het statische IP adres als source moet gebruiken, maarja, met een stuk of 10 routing tabellen schiet dat ook niet echt op :x. Liefst heb ik dus gewoon 1 adres in de fd00:1::/64 ULA.

Note: ik ben dus niet perse op zoek naar een oplossing voor systemd-networkd, maar meer of het uberhaupt mogelijk is. Dan heb ik in ieder geval een startpunt om verder te zoeken naar een oplossing. Uiteraard mag een kant en klaar antwoord ook gewoon. Maar ik verwacht dat de meeste in ieder geval op gewone clients iets als NetworkManager gebruiken. En op servers gebruiken de meeste distros ook geen systemd-networkd naar mijn idee.

[Dennisweb]

Is er iemand die een EdgeRouter 4 heeft en weet waarom de HE Tunnel niet helemaal goed werkt? Ik kan prima IPv6 pingen vanuit de EdgeRouter zelf. Ik krijg wel een IPv6-adres van de router op mijn MacBook Pro, maar ik kan geen enkel IPv6 adres pingen. Het pingen van de router lijkt wel. Lijkt me een firewall dingetje. Kan iemand even meedenken of me even helpen, eventueel tegen betaling? Als ik Google ping, zie ik wel dat de host wordt omgezet naar een IPv6 adres. Maar pingen lukt niet.

Ik wil liever niet wachten totdat Odido ook eens met zijn tijd meegaat...

[RobertMe]

Dennisweb schreef op maandag 15 juli 2024 @ 20:29:
Is er iemand die een EdgeRouter 4 heeft en weet waarom de HE Tunnel niet helemaal goed werkt? Ik kan prima IPv6 pingen vanuit de EdgeRouter zelf. Ik krijg wel een IPv6-adres van de router op mijn MacBook Pro, maar ik kan geen enkel IPv6 adres pingen. Het pingen van de router lijkt wel. Lijkt me een firewall dingetje.

Niet met HE, recentelijk wel IPv6 op gezet op een ER4.
Welk IPv6 adres krijg je op de MacBook? Krijg je daar een GUA adres (AFAIK nu nog altijd beginnende met 2...)? Niet dat je alleen een link local address krijgt (fe80:...), want daarmee kun je niet het internet op. Je moet dus minimaal 2 adressen hebben, een fe80:... adres en een 2...:.... adres (waarschijnlijk heb je "zelfs" 2 publieke adressen met 2...:..., een vaste en een tijdelijke middels de "IPv6 privacy extension").

Als ik Google ping, zie ik wel dat de host wordt omgezet naar een IPv6 adres. Maar pingen lukt niet.

Dat is DNS, en aan een via IPv4 bereikbare DNS server kun je prima een AAAA adres voor IPv6 opvragen, ook als je een IPv4 only internet verbinding hebt. DNS is gewoon een "telefoonboek". En aan dat "telefoonboek" kun je prima vragen naar het IPv6 "telefoonnummer" van google.com. Of je dat "telefoonnummer" vervolgens ook kunt "bellen" staat daar buiten.

Ik wil liever niet wachten totdat Odido ook eens met zijn tijd meegaat...

Het gebruik van een tunnel kan wel ook weer problemen opleveren. Immers is het gewoon een VPN like oplossing. Mogelijk (/zeer waarschijnlijk) dat er dus ook websites zijn die je gaan blokkeren of soortgelijke. Immers zal, bv, Netflix "zien" dat je een VPN gebruikt en dus ook de daarbij behorende restricties toepassen (IIRC is dat dat je alleen content kunt kijken die niet regio gebonden is, dus waarschijnlijk alleen content van Netflix zelf waar ze dus wereldwijd de rechten op hebben). En andere diensten kunnen dus ook "gewoon" de toegang blokkeren op grond van toepassen van een VPN.
Overigens begrijp ik je beweegredenen wel, maar HE (/eender welke tunnel) gebruiken kan juist nog meer problemen opleveren.

[MaartenBW]

RobertMe schreef op zondag 14 juli 2024 @ 16:06:


Note: ik ben dus niet perse op zoek naar een oplossing voor systemd-networkd, maar meer of het uberhaupt mogelijk is. Dan heb ik in ieder geval een startpunt om verder te zoeken naar een oplossing. Uiteraard mag een kant en klaar antwoord ook gewoon. Maar ik verwacht dat de meeste in ieder geval op gewone clients iets als NetworkManager gebruiken. En op servers gebruiken de meeste distros ook geen systemd-networkd naar mijn idee.

Ik kwam dit nog tegen:
https://wiki.archlinux.or...#Stable_private_addresses

Misschien heb je er iets aan voor deze uitdaging.

[Snow_King]

nieuws: Microsoft schakelt IPv6 vanaf 1 oktober standaard in bij Exchange Online

Eindelijk! Het werd tijd. Hoef ik dit niet meer zelf te doen.

[Gijs007]

Heb hier OPNsense 24.7.3_1 draaien (met de laatste IPv6 fix), i.c.m. Freedom Internet.
Met de track interface optie krijgen clients ook een IPv6 address, en kunnen daarmee naar buiten toe.

Echter ik loop nog tegen twee problemen aan.

1. Ik mis de mogelijkheid om een DNS server mee te geven met een IPv6 adres, heeft iemand daar tips voor?
Wat ik al heb geprobeerd is om d.m.v Router Advertisement en/of DHCPv6 configuratie in OPNsense, een IPv6 DNS server mee te geven. Maar de Windows 11 clients lijken hier niks mee te doen...

2.
Verder loop ik nog tegen een ander probleem aan;

Veel clients verliezen hun IPv6 connectiviteit na een korte tijd (5-10 minuten schat ik), het IPv6 adres wordt nog wel genoemd (ipconfig /all), maar de pings stoppen plotseling. Het lijkt erop alsof de clients een deel van hun IPv6 routes kwijt zijn.
Ook bij het opnieuw verbinden met WiFi of kabel, komt de IPv6 connectiviteit dan niet meer terug. Alleen het herstarten van de Router Advertisement service in OPNsense lijkt dit tijdelijk op te lossen.

Ik zou denken dat het probleem in OPNsense zit. Gezien alle devices tegen dit probleem aan lopen en allemaal geen IPv6 adressen meer krijgen tot de Router Advertisement service weer is herstart. (deze draait echter nog wel volgens OPNsense...)

Het vreemde is dat bekabelde clients hier minder last van lijken te hebben, die houden wel hun connectiviteit.
Echter als de interface even down is geweest, dan krijgen ze na het opnieuw inschakelen geen IPv6 connectiviteit meer.

Achtergrond info:
Het betreft een bridge interface in OPNsense, IPv6 link-local staat aan. Ik zie ook dat het link-local verkeer door blijft lopen in Wireshark.

De bridge bestaat uit twee adapters, welke in Proxmox d.m.v. Virtual Functions en een VLAN filter zijn gedefinieerd. Deze VF's worden met SR-IOV doorgezet naar de OPNsense VM. Dit zou verder niet uit moeten maken, IPv4 connectiviteit gaat immers wel goed.

[valkenier]

@Gijs007 Misschien maar even aanhaken op het opnsense forum. Er is een of ander security fix vanuit FreeBSD meegekomen, die grotendeels leunt op een stuk code uit 2009(!) heb ik begrepen. En dat maakt sommige dingen stuk. Er is al verbetering met 24.7.3, maar nog niet alles is volledig gefixed, geloof ik. Er is veel discussie over.

Ik merk er hier in de praktijk nog weinig van, zal er eens induiken. Kan maar zo zijn dat ik ook af en toe terugval naar IPv4 zonder dat ik het heb gemerkt. Kom erop terug.

[Gijs007]

Ahh, ik dacht dat alles al gefixed was in deze versie 24.7.3.1. Ik zal even verder zoeken op het OPNsense forum.
Heb vannacht even opnieuw getest op de WiFi, ik zie ongeveer 26% packetloss op IPv6, maar hij pakt de verbinding dus wel weer terug:

[valkenier]

Er speelt in elk geval nog iets met dhcp6c. Ik doe niks met dhcp6.

Ik heb net even een lange IPv6 ping laten lopen waarvan hier het staartje:

code:

64 bytes from g2a02-26f0-b200-0000-0000-0000-58dd-198a.deploy.static.akamaitechnologies.com (2a02:26f0:b200::58dd:198a): icmp_seq=7426 ttl=58 time=13.8 ms
64 bytes from g2a02-26f0-b200-0000-0000-0000-58dd-198a.deploy.static.akamaitechnologies.com (2a02:26f0:b200::58dd:198a): icmp_seq=7427 ttl=58 time=14.2 ms
64 bytes from g2a02-26f0-b200-0000-0000-0000-58dd-198a.deploy.static.akamaitechnologies.com (2a02:26f0:b200::58dd:198a): icmp_seq=7428 ttl=58 time=14.3 ms
64 bytes from g2a02-26f0-b200-0000-0000-0000-58dd-198a.deploy.static.akamaitechnologies.com (2a02:26f0:b200::58dd:198a): icmp_seq=7429 ttl=58 time=14.7 ms
^C
--- tweakers.net ping statistics ---
7429 packets transmitted, 7429 received, 0% packet loss, time 7439491ms
rtt min/avg/max/mdev = 11.851/14.551/52.426/1.201 ms

En even korter naar het door jou gebruikte IP:

code:

64 bytes from 2606:4700::1111: icmp_seq=92 ttl=57 time=16.1 ms
64 bytes from 2606:4700::1111: icmp_seq=93 ttl=57 time=14.8 ms
^C
--- 2606:4700::1111 ping statistics ---
93 packets transmitted, 93 received, 0% packet loss, time 92130ms
rtt min/avg/max/mdev = 13.016/14.642/18.898/0.921 ms

Zie geen issues hier, alles rond de 14 15 ms. versie 24.7.3.1 op Ziggo modem in bridge

[ Voor 18% gewijzigd door valkenier op 30-08-2024 12:38 ]

[Gijs007]

valkenier schreef op vrijdag 30 augustus 2024 @ 12:31:
Er speelt in elk geval nog iets met dhcp6c. Ik doe niks met dhcp6.

Ik heb net even een lange IPv6 ping laten lopen waarvan hier het staartje:

code:

64 bytes from g2a02-26f0-b200-0000-0000-0000-58dd-198a.deploy.static.akamaitechnologies.com (2a02:26f0:b200::58dd:198a): icmp_seq=7426 ttl=58 time=13.8 ms
64 bytes from g2a02-26f0-b200-0000-0000-0000-58dd-198a.deploy.static.akamaitechnologies.com (2a02:26f0:b200::58dd:198a): icmp_seq=7427 ttl=58 time=14.2 ms
64 bytes from g2a02-26f0-b200-0000-0000-0000-58dd-198a.deploy.static.akamaitechnologies.com (2a02:26f0:b200::58dd:198a): icmp_seq=7428 ttl=58 time=14.3 ms
64 bytes from g2a02-26f0-b200-0000-0000-0000-58dd-198a.deploy.static.akamaitechnologies.com (2a02:26f0:b200::58dd:198a): icmp_seq=7429 ttl=58 time=14.7 ms
^C
--- tweakers.net ping statistics ---
7429 packets transmitted, 7429 received, 0% packet loss, time 7439491ms
rtt min/avg/max/mdev = 11.851/14.551/52.426/1.201 ms

En even korter naar het door jou gebruikte IP:

code:

64 bytes from 2606:4700::1111: icmp_seq=92 ttl=57 time=16.1 ms
64 bytes from 2606:4700::1111: icmp_seq=93 ttl=57 time=14.8 ms
^C
--- 2606:4700::1111 ping statistics ---
93 packets transmitted, 93 received, 0% packet loss, time 92130ms
rtt min/avg/max/mdev = 13.016/14.642/18.898/0.921 ms

Zie geen issues hier, alles rond de 14 15 ms. versie 24.7.3.1 op Ziggo modem in bridge

Maak jij ook gebruik van IPv6 die via PPPoE binnenkomt en met interface tracking wordt uitgedeeld?
Of werkt dit bij Ziggo anders?

[RobertMe]

Gijs007 schreef op vrijdag 30 augustus 2024 @ 18:41:
[...]

Maak jij ook gebruik van IPv6 die via PPPoE binnenkomt en met interface tracking wordt uitgedeeld?
Of werkt dit bij Ziggo anders?

Ziggo gebruikt nooit PPPoE. Router zelf krijgt een IPv6 adres via SLAAC in een Ziggo netwerk. Router stel je vervolgens in om DHCPv6-PD te doen om een een prefix op te halen die die dan weer via Router Advertisements lokaal uitstuurt voor SLAAC.

[valkenier]

@Gijs007 Het klopt wat @RobertMe zegt. Geen PPPoE hier.

Lijkt het bij jou op dit?: https://forum.opnsense.org/index.php?topic=42556.0

[ Voor 40% gewijzigd door valkenier op 30-08-2024 21:15 ]

[Gijs007]

valkenier schreef op vrijdag 30 augustus 2024 @ 21:09:
@Gijs007 Het klopt wat @RobertMe zegt. Geen PPPoE hier.

Lijkt het bij jou op dit?: https://forum.opnsense.org/index.php?topic=42556.0

Dat was ook mijn gedachten gang, dat zou hetzelfde probleem kunnen zijn.
Alleen geeft die persoon aan dat het helemaal niet werkt.

[Charlie_Root]

Gijs007 schreef op vrijdag 30 augustus 2024 @ 11:11:
Ahh, ik dacht dat alles al gefixed was in deze versie 24.7.3.1. Ik zal even verder zoeken op het OPNsense forum.
Heb vannacht even opnieuw getest op de WiFi, ik zie ongeveer 26% packetloss op IPv6, maar hij pakt de verbinding dus wel weer terug:

[Afbeelding]

Je kunt beter met MTR testen om te zien waar je precies packetloss hebt.

code:

mtr -6 cloudflare.com

[tomdh76]

Ik probeer mijn wireguard connectie over ipv6 te laten verlopen met OPNsense maar het lukt niet.
Ipv4 werkt wel waarbij ik de client als endpoint het publieke ipv adres invul. Op de OPNsense heb ik een port forward om poort 443 (die wordt niet geblokkeerd) naar wireguard te zetten.

Ik zag in dit topic dat ik voor ipv6 het LAN ipv4 adres als endpoint kon opgeven (= 2a02:xxxx:xxxx:1:xxxx:5cff:fea0:6f44:443. Dit ip adres vul ik ook in voor de port forward.

Maar ik krijg dan een error 'no route to host'
Zou ik nog andere dingen moeten aanpassen bijvoorbeeld in de 'allowed ips'? of in het tunnel adres van de wireguard op OPNSense? Ik zie ik staan dat ik een ULA adres moet aanmaken maar geen idee welke dan?

[Roetzen]

Is het inmiddels mogelijk een IPv6 poort te openen op de Nokia XS-2426G-B modem/router van Delta/Caiway? En zo ja, hoe gaat het dan? Ik kan het niet vinden

[St00mwals]

Forum Standaardisatie, een dienst/onderdeel van de Rijksoverheid houdt een consultatie over IPv6.

Voor meer informatie en de consultatie zelf, zie deze link:

https://www.forumstandaar...e-aandacht-geef-uw-mening

[tomdh76]

Ik ben nog aan het stoeien met een wireguard ipv6 connectie naar een OPNsense firewall. De clients gebruiken als endpoint 2a02:xxxx:xxxx:xxxx:xxxx:51821. Dit is het adres wat ik krijg op de LAN interface. Als ik met mijn telefoon op op mijn wifi zit dan maakt hij verbinding en werkt het. Echter als ik op 5g zit dan is er een error 'no route to host'. Het lijkt mij dat er een firewall rule in OPNsense het verkeer aan de WAN kant moet toe laten maar als ik op de WAN interface een rule maak met allow source any , destination port 51821 zie ik niets in de firewall log. Ik heb ook de rule aangemaakt op de LAN interface zonder verschil. Als ik naar https://port.tools/port-checker-ipv6/ ga dan staat er dat de port is blocked, maar dan zie ik wel in de firewall log dat er data binnenkomt en wordt toegestaan. Weet iemand waar ik het moet zoeken? Kan ik wel een ipv6 adres in wireguard zetten of moet het een domein naam zijn ?

[RobertMe]

tomdh76 schreef op donderdag 19 september 2024 @ 08:57:
Ik ben nog aan het stoeien met een wireguard ipv6 connectie naar een OPNsense firewall. De clients gebruiken als endpoint 2a02:xxxx:xxxx:xxxx:xxxx:51821. Dit is het adres wat ik krijg op de LAN interface. Als ik met mijn telefoon op op mijn wifi zit dan maakt hij verbinding en werkt het. Echter als ik op 5g zit dan is er een error 'no route to host'. Het lijkt mij dat er een firewall rule in OPNsense het verkeer aan de WAN kant moet toe laten maar als ik op de WAN interface een rule maak met allow source any , destination port 51821 zie ik niets in de firewall log. Ik heb ook de rule aangemaakt op de LAN interface zonder verschil. Als ik naar https://port.tools/port-checker-ipv6/ ga dan staat er dat de port is blocked, maar dan zie ik wel in de firewall log dat er data binnenkomt en wordt toegestaan. Weet iemand waar ik het moet zoeken? Kan ik wel een ipv6 adres in wireguard zetten of moet het een domein naam zijn ?

1. Heb je via mobiel uberhaupt IPv6? Volgens mij doen nog niet alle providers dat? (Ik meen zelfs eens gelezen te hebben dat alleen KPN op zijn netwerk IPv6 doet).
2. Wireguard gebruikt UDP, en alleen UDP. Testen of een poort open staat kan o.a. om die reden niet. Immers wordt er bij UDP geen verbinding op gezet. Er wordt een pakketje via UDP gestuurd en misschien komt er een pakketje terug, maar misschien ook niet. Combineer dat met dat Wireguard alleen "antwoord" op valide verkeer en de rest negeert (dat is inclusief het niet antwoorden op verkeer dat een verkeerde sleutel etc gebruikt) en je kunt gewoon echt niet testen of het verkeer aan komt.

Edit:
Overigens v.w.b. 1. Je kunt prima via IPv4 met de wireguard server verbinden en vervolgens IPv6 verkeer over de tunnel heen sturen. Dus het is leuk om de verbinding met de server via IPv6 op te zetten, maar verder levert het 0,0 extra mogelijkheden op. En gezien je vast niet overal buiten de deur IPv6 beschikbaar hebt zou ik ook ten alle tijden ervoor zorgen dat het ook via IPv4 kan. Immers mis je er niks mee, maar zorgt het er wel voor dat het "overal" werkt.

[ Voor 12% gewijzigd door RobertMe op 19-09-2024 09:33 ]

[tomdh76]

RobertMe schreef op donderdag 19 september 2024 @ 09:30:
[...]

1. Heb je via mobiel uberhaupt IPv6? Volgens mij doen nog niet alle providers dat? (Ik meen zelfs eens gelezen te hebben dat alleen KPN op zijn netwerk IPv6 doet).
2. Wireguard gebruikt UDP, en alleen UDP. Testen of een poort open staat kan o.a. om die reden niet. Immers wordt er bij UDP geen verbinding op gezet. Er wordt een pakketje via UDP gestuurd en misschien komt er een pakketje terug, maar misschien ook niet. Combineer dat met dat Wireguard alleen "antwoord" op valide verkeer en de rest negeert (dat is inclusief het niet antwoorden op verkeer dat een verkeerde sleutel etc gebruikt) en je kunt gewoon echt niet testen of het verkeer aan komt.

Edit:
Overigens v.w.b. 1. Je kunt prima via IPv4 met de wireguard server verbinden en vervolgens IPv6 verkeer over de tunnel heen sturen. Dus het is leuk om de verbinding met de server via IPv6 op te zetten, maar verder levert het 0,0 extra mogelijkheden op. En gezien je vast niet overal buiten de deur IPv6 beschikbaar hebt zou ik ook ten alle tijden ervoor zorgen dat het ook via IPv4 kan. Immers mis je er niks mee, maar zorgt het er wel voor dat het "overal" werkt.

Dank !
Geen idee of mijn 5g provider (odido) ipv6 heeft....
Ik begon me ook steeds meer af te vragen wat ik in godsnaam aan het proberen was. Wireguard ipv4 werkt prima. Ik dacht een beetje gericht op de toekomst...?

Als ik 1 wireguard tunnel heb waar ik ook ipv6 over wil laten lopen wat moet ik dan extra doen? Het endpoint blijft gewoon het ipv4 adres neem ik aan. Bij de allowed ip's ::/0 erbij. En de client ip blijft dan (in mijn geval 10.0.0.x/32? DNS nog een ipv6 adres erbij?

[RobertMe]

tomdh76 schreef op donderdag 19 september 2024 @ 10:46:
[...]


Dank !
Geen idee of mijn 5g provider (odido) ipv6 heeft....

Odido is de enige (grote) ISP die nog niet eens IPv6 over het vaste netwerk doet. Dus ik zou er zeker niet vanuit gaan dat ze IPv6 op mobiel doen. Maar, je kunt het snel genoeg testen, door bv http://ipv6-test.com te openen

Ik begon me ook steeds meer af te vragen wat ik in godsnaam aan het proberen was. Wireguard ipv4 werkt prima. Ik dacht een beetje gericht op de toekomst...?

Er is natuurlijk niks mis mee om het alvast op te zetten. Maar ik zou toch echt IPv4 ernaast houden. Zelf heb ik het ook via beide beschikbaar. Alleen... kun jij het dus niet/lastiger testen. Daar waar mijn provider wel IPv6 doet (Simyo dus KPN netwerk).

Als ik 1 wireguard tunnel heb waar ik ook ipv6 over wil laten lopen wat moet ik dan extra doen? Het endpoint blijft gewoon het ipv4 adres neem ik aan. Bij de allowed ip's ::/0 erbij. En de client ip blijft dan (in mijn geval 10.0.0.x/32? DNS nog een ipv6 adres erbij?

Je zult dan bij "alle" opties ook een IPv6 adres moeten opnemen ja. Dus minimaal AllowedIPs (op de telefoon dan ::/0 inderdaad als je alle verkeer over de tunnel wilt sturen), een statisch IP adres dat de telefoon (& server) zichzelf geven. De server moet bij AllowedIPs dan ook de .../128 van de telefoon hebben. DNS server is optioneel ook IPv6, maar niet vereist zolang je er ook nog een via IPv4 bereikbaar hebt natuurlijk.
Waarbij de IP adressen die je kiest (voor de server en telefoon) dus in hetzelfde subnet moeten zijn maar niet in het subnet kunnen zijn dat je dus al gebruikt. Dus als je van de ISP de prefix 2001:db8:1234:5600::/56 krijgt en bv jou LAN heeft dan 2001:db8:1234:5678::/64 dan kun je voor Wireguard 2001:db8:1234:56xx::/64 gebruiken met een xx naar keuze maar niet 78 dus, want die is al in gebruik.
En jip, dat betekent dus ook dat als de ISP je een andere prefix geeft je de volledige client en server moet aanpassen op deze nieuwe prefix.

[Dreamvoid]

tomdh76 schreef op donderdag 19 september 2024 @ 10:46:
Geen idee of mijn 5g provider (odido) ipv6 heeft....

Odido heeft geen IPv6, niet mobiel, niet vast. KPN wel.

[tomdh76]

Dreamvoid schreef op donderdag 19 september 2024 @ 14:56:
[...]

Odido heeft geen IPv6, niet mobiel, niet vast. KPN wel.

Ja ik ben er achter dat dat het probleem was. Ik was juist naar KPN glasvezel overgestapt maar mijn mobiel kon nog niet over...

[databeestje]

St00mwals schreef op maandag 16 september 2024 @ 21:54:
Forum Standaardisatie, een dienst/onderdeel van de Rijksoverheid houdt een consultatie over IPv6.

Voor meer informatie en de consultatie zelf, zie deze link:

https://www.forumstandaar...e-aandacht-geef-uw-mening

Dat is wel fijn, bijdrage gedaan. Ik zoek een overheid breed meldpunt zodat er met meer kluit een statement naar een leverancier wordt gemaakt.

Ik ben nu afzonderlijk problemen bij leveranciers aan het melden, maar het aantal "we hebben hier niet veel ervaring mee", "dat moet ik navragen" tot zelfs een "zet IPv6 uit". Als enkele speler heb je weinig in de melk te brokkelen.

Maar als zelfs Palo Alto meer dan 2 jaar een Feature Enhancement open heeft staan voor IPv6 ondersteuning in de Geo Locatie zakt mijn broek wel af. (en geen zicht op wanneer). brandhout.

Ik heb er zelf iets voor gemaakt. https://iserv.nl/files/edl/feed.php

Op dit moment 3 actieve issues met nul voortgang sinds kruik

[juanita]

Zou thuis ook graag de overstap willen maken naar IPv6. Lijkt er alleen helaas op dat er slechts 2 aanbieders van zijn: KPN en Ziggo. Is het echt zo droevig gesteld?