IPv6 geht mal und geht mal nicht ...

[BSAfH42]

Moin,

ich habe eine OPNsense hinter einer Fritz!Box mit Telekom/T-Onbline DSL

Konfiguriert nach dieser Anleitung:
https://docs.opnsense.org/manual/how-tos/ipv6_fb.html

Prinzipiell scheint das alles zu gehen.

Nur, was ist das???

Code Select Expand

root@homeassistant:/etc# ping www.heise.de
PING www.heise.de(www.heise.de (2a02:2e0:3fe:1001:7777:772e:2:85)) 56 data bytes
64 bytes from www.heise.de (2a02:2e0:3fe:1001:7777:772e:2:85): icmp_seq=1596 ttl=56 time=9.50 ms
64 bytes from www.heise.de (2a02:2e0:3fe:1001:7777:772e:2:85): icmp_seq=1597 ttl=56 time=9.62 ms
64 bytes from www.heise.de (2a02:2e0:3fe:1001:7777:772e:2:85): icmp_seq=1598 ttl=56 time=13.1 ms
64 bytes from www.heise.de (2a02:2e0:3fe:1001:7777:772e:2:85): icmp_seq=1599 ttl=56 time=9.24 ms
^C
--- www.heise.de ping statistics ---
2161 packets transmitted, 1599 received, 26.0065% packet loss, time 2176441ms
rtt min/avg/max/mdev = 9.075/10.228/36.781/2.420 ms
root@homeassistant:/etc# ifconfig ens3
ens3: flags=4675<UP,BROADCAST,RUNNING,ALLMULTI,MULTICAST>  mtu 1500
        inet 192.168.80.21  netmask 255.255.255.0  broadcast 192.168.80.255
        inet6 2003:ce:7704:e81:229d:d67a:185a:91d4  prefixlen 64  scopeid 0x0<global>
        inet6 fe80::8b35:a12c:e957:3332  prefixlen 64  scopeid 0x20<link>
        inet6 2003:ce:7704:e81::2000:f727  prefixlen 128  scopeid 0x0<global>
        ether 00:a0:98:02:85:96  txqueuelen 1000  (Ethernet)
        RX packets 395363619  bytes 1312399161986 (1.1 TiB)
        RX errors 0  dropped 31745609  overruns 0  frame 0
        TX packets 365170660  bytes 1426783920324 (1.2 TiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

root@homeassistant:/etc# ping www.heise.de
PING www.heise.de(www.heise.de (2a02:2e0:3fe:1001:7777:772e:2:85)) 56 data bytes



Das ist eine VM, das gleiche habe ich aber auch gerade mit einem "normalen" PC gehabt.

Sprich: geht eine ganze Zeit, und dann plötzlich nicht mehr.

Eventuell immer dann, wenn der DHCPv6 Lease erneuert wird (mit der gleichen IP ...), kann aber auch Zufall sein.

Ich habe gleichzeitig mehrere Maschinen, VM und Hardware, bei denen es geht....

aber anscheinend auch nur temporär:

dies hier ist auf einer TrueNAS Scale (also Debian):

Code Select Expand

64 bytes from www.heise.de (2a02:2e0:3fe:1001:7777:772e:2:85): icmp_seq=4351 ttl=56 time=10.4 ms
64 bytes from www.heise.de (2a02:2e0:3fe:1001:7777:772e:2:85): icmp_seq=4352 ttl=56 time=10.3 ms
64 bytes from www.heise.de (2a02:2e0:3fe:1001:7777:772e:2:85): icmp_seq=4353 ttl=56 time=10.6 ms
64 bytes from www.heise.de (2a02:2e0:3fe:1001:7777:772e:2:85): icmp_seq=4354 ttl=56 time=10.7 ms
64 bytes from www.heise.de (2a02:2e0:3fe:1001:7777:772e:2:85): icmp_seq=4355 ttl=56 time=10.4 ms
64 bytes from www.heise.de (2a02:2e0:3fe:1001:7777:772e:2:85): icmp_seq=4356 ttl=56 time=10.5 ms
64 bytes from www.heise.de (2a02:2e0:3fe:1001:7777:772e:2:85): icmp_seq=4357 ttl=56 time=10.3 ms
64 bytes from www.heise.de (2a02:2e0:3fe:1001:7777:772e:2:85): icmp_seq=4358 ttl=56 time=10.4 ms
64 bytes from www.heise.de (2a02:2e0:3fe:1001:7777:772e:2:85): icmp_seq=4359 ttl=56 time=10.5 ms
64 bytes from www.heise.de (2a02:2e0:3fe:1001:7777:772e:2:85): icmp_seq=4360 ttl=56 time=10.2 ms
64 bytes from www.heise.de (2a02:2e0:3fe:1001:7777:772e:2:85): icmp_seq=4361 ttl=56 time=10.8 ms
64 bytes from www.heise.de (2a02:2e0:3fe:1001:7777:772e:2:85): icmp_seq=4362 ttl=56 time=10.3 ms
64 bytes from www.heise.de (2a02:2e0:3fe:1001:7777:772e:2:85): icmp_seq=4363 ttl=56 time=10.7 ms
64 bytes from www.heise.de (2a02:2e0:3fe:1001:7777:772e:2:85): icmp_seq=4364 ttl=56 time=10.5 ms
64 bytes from www.heise.de (2a02:2e0:3fe:1001:7777:772e:2:85): icmp_seq=4365 ttl=56 time=10.4 ms
64 bytes from www.heise.de (2a02:2e0:3fe:1001:7777:772e:2:85): icmp_seq=4366 ttl=56 time=10.4 ms
64 bytes from www.heise.de (2a02:2e0:3fe:1001:7777:772e:2:85): icmp_seq=4367 ttl=56 time=10.4 ms
From OPNsense.hal9000.dedyn.io (2003:ce:7704:e81:921b:eff:fe0c:b068) icmp_seq=4386 Destination unreachable: No route
From OPNsense.hal9000.dedyn.io (2003:ce:7704:e81:921b:eff:fe0c:b068) icmp_seq=4387 Destination unreachable: No route
From OPNsense.hal9000.dedyn.io (2003:ce:7704:e81:921b:eff:fe0c:b068) icmp_seq=4388 Destination unreachable: No route
From OPNsense.hal9000.dedyn.io (2003:ce:7704:e81:921b:eff:fe0c:b068) icmp_seq=4389 Destination unreachable: No route
From OPNsense.hal9000.dedyn.io (2003:ce:7704:e81:921b:eff:fe0c:b068) icmp_seq=4390 Destination unreachable: No route
From OPNsense.hal9000.dedyn.io (2003:ce:7704:e81:921b:eff:fe0c:b068) icmp_seq=4391 Destination unreachable: No route
From OPNsense.hal9000.dedyn.io (2003:ce:7704:e81:921b:eff:fe0c:b068) icmp_seq=4392 Destination unreachable: No route
From OPNsense.hal9000.dedyn.io (2003:ce:7704:e81:921b:eff:fe0c:b068) icmp_seq=4393 Destination unreachable: No route
From OPNsense.hal9000.dedyn.io (2003:ce:7704:e81:921b:eff:fe0c:b068) icmp_seq=4394 Destination unreachable: No route
From OPNsense.hal9000.dedyn.io (2003:ce:7704:e81:921b:eff:fe0c:b068) icmp_seq=4395 Destination unreachable: No route
From OPNsense.hal9000.dedyn.io (2003:ce:7704:e81:921b:eff:fe0c:b068) icmp_seq=4396 Destination unreachable: No route
From OPNsense.hal9000.dedyn.io (2003:ce:7704:e81:921b:eff:fe0c:b068) icmp_seq=4397 Destination unreachable: No route


auf einem RaspberryPi gab's dies zu sehen:

Code Select Expand

64 bytes from www.heise.de (2a02:2e0:3fe:1001:7777:772e:2:85): icmp_seq=2019 ttl=56 time=10.5 ms
64 bytes from www.heise.de (2a02:2e0:3fe:1001:7777:772e:2:85): icmp_seq=2020 ttl=56 time=10.5 ms
64 bytes from www.heise.de (2a02:2e0:3fe:1001:7777:772e:2:85): icmp_seq=2021 ttl=56 time=10.3 ms
64 bytes from www.heise.de (2a02:2e0:3fe:1001:7777:772e:2:85): icmp_seq=2022 ttl=56 time=10.2 ms


64 bytes from www.heise.de (2a02:2e0:3fe:1001:7777:772e:2:85): icmp_seq=2808 ttl=56 time=468 ms
64 bytes from www.heise.de (2a02:2e0:3fe:1001:7777:772e:2:85): icmp_seq=2809 ttl=56 time=10.1 ms
64 bytes from www.heise.de (2a02:2e0:3fe:1001:7777:772e:2:85): icmp_seq=2810 ttl=56 time=10.0 ms
64 bytes from www.heise.de (2a02:2e0:3fe:1001:7777:772e:2:85): icmp_seq=2811 ttl=56 time=11.6 ms
64 bytes from www.heise.de (2a02:2e0:3fe:1001:7777:772e:2:85): icmp_seq=2812 ttl=56 time=10.1 ms


auf der OPNsense passierte derweil während der Pause dies:

Code Select Expand

16 bytes from 2a02:2e0:3fe:1001:7777:772e:2:85, icmp_seq=6155 hlim=57 time=9.364 ms
16 bytes from 2a02:2e0:3fe:1001:7777:772e:2:85, icmp_seq=6156 hlim=57 time=9.358 ms
16 bytes from 2a02:2e0:3fe:1001:7777:772e:2:85, icmp_seq=6157 hlim=57 time=9.577 ms
16 bytes from 2a02:2e0:3fe:1001:7777:772e:2:85, icmp_seq=6158 hlim=57 time=9.372 ms
16 bytes from 2a02:2e0:3fe:1001:7777:772e:2:85, icmp_seq=6159 hlim=57 time=9.219 ms
ping: sendmsg: No route to host
ping6: wrote www.heise.de 16 chars, ret=-1
ping: sendmsg: No route to host
ping6: wrote www.heise.de 16 chars, ret=-1
ping: sendmsg: No route to host
ping6: wrote www.heise.de 16 chars, ret=-1
ping: sendmsg: No route to host
ping6: wrote www.heise.de 16 chars, ret=-1
ping: sendmsg: No route to host
ping6: wrote www.heise.de 16 chars, ret=-1
ping: sendmsg: No route to host
ping6: wrote www.heise.de 16 chars, ret=-1
ping: sendmsg: No route to host
ping6: wrote www.heise.de 16 chars, ret=-1
ping: sendmsg: No route to host
ping6: wrote www.heise.de 16 chars, ret=-1

^C
--- www.heise.de ping6 statistics ---
6765 packets transmitted, 6159 packets received, 9.0% packet loss
round-trip min/avg/max/std-dev = 8.807/9.385/95.847/1.339 ms
root@OPNsense:/usr/local/etc/nut # ping -6 www.heise.de
PING6(56=40+8+8 bytes) 2003:ce:7728:bc00:921b:eff:fe0c:b067 --> 2a02:2e0:3fe:1001:7777:772e:2:85
16 bytes from 2a02:2e0:3fe:1001:7777:772e:2:85, icmp_seq=0 hlim=57 time=10.463 ms
16 bytes from 2a02:2e0:3fe:1001:7777:772e:2:85, icmp_seq=1 hlim=57 time=10.337 ms
16 bytes from 2a02:2e0:3fe:1001:7777:772e:2:85, icmp_seq=2 hlim=57 time=10.122 ms
16 bytes from 2a02:2e0:3fe:1001:7777:772e:2:85, icmp_seq=3 hlim=57 time=10.215 ms
16 bytes from 2a02:2e0:3fe:1001:7777:772e:2:85, icmp_seq=4 hlim=57 time=10.149 ms
16 bytes from 2a02:2e0:3fe:1001:7777:772e:2:85, icmp_seq=5 hlim=57 time=10.383 ms
16 bytes from 2a02:2e0:3fe:1001:7777:772e:2:85, icmp_seq=6 hlim=57 time=10.585 ms
16 bytes from 2a02:2e0:3fe:1001:7777:772e:2:85, icmp_seq=7 hlim=57 time=10.526 ms
16 bytes from 2a02:2e0:3fe:1001:7777:772e:2:85, icmp_seq=8 hlim=57 time=10.643 ms
16 bytes from 2a02:2e0:3fe:1001:7777:772e:2:85, icmp_seq=9 hlim=57 time=11.598 ms
16 bytes from 2a02:2e0:3fe:1001:7777:772e:2:85, icmp_seq=10 hlim=57 time=10.244 ms


Die Telekom meinte offenbar, mir mal wieder neue IP-Adressen geben zu müssen :-(  :-\ :o
Jedenfalls steht in der Fritz!Box jetzt ein "connected since" mit einer Uhrzeit mitten in der Pause. Mit neuer IPv4 Adresse und neuem IPv6 Prefix.

Der Pi hat sich wieder gefangen, bei allen anderen Maschinen geht seit der "Pause" nix mehr.

Bei einigen ging allerdings auch schon vorher nichts mehr, die hatten schon vorher keine Verbindung mehr nach außen bekommen.

Nanu???

Offenbar bekommen die Clients nach einem Wechsel des Prefixes keine neuen IPv6 Adressen zugewiesen - und die alten gehen natürlich nicht mehr

Hier (das ist ein OpenSUSE) steht plötzlich IPv6 Adressen aus zwei verschiedenen Prefixes nebeneinander auf einem Interface:

Code Select Expand

cb-desktop:/etc/ups # ifconfig
eth1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.80.10  netmask 255.255.255.0  broadcast 192.168.80.255
        inet6 2003:ce:7704:e81::2000:4c53  prefixlen 64  scopeid 0x0<global>
        inet6 fe80::db0c:ee9c:6f2e:8c8e  prefixlen 64  scopeid 0x20<link>
        inet6 2003:ce:7704:e81:c203:d011:e523:c7f3  prefixlen 64  scopeid 0x0<global>
        inet6 2003:ce:7728:bc81:4c7a:7b95:9855:b531  prefixlen 64  scopeid 0x0<global>
        ether d8:cb:8a:7c:72:9b  txqueuelen 1000  (Ethernet)
        RX packets 238031070  bytes 45131723171 (42.0 GiB)
        RX errors 0  dropped 4906035  overruns 0  frame 0
        TX packets 200763160  bytes 41026533734 (38.2 GiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0


Code Select Expand


        inet6 2003:ce:7704:e81:c203:d011:e523:c7f3  prefixlen 64  scopeid 0x0<global>
        inet6 2003:ce:7728:bc81:4c7a:7b95:9855:b531  prefixlen 64  scopeid 0x0<global>

Kann man da irgendwas gegen tun?

[meyergru]

Ja. Die verlinkte Anleitung ist leider nicht so toll...

Also erstens: Ja, manche ISPs wechseln den IPv6-Präfix - andere nicht. Wenn der per DHCPv6 gezogene IA_PD Präfix sich ändert, bekommt das zunächst mal die Fritzbox mit. Sie wird dann zukünftig den Clients den neuen Präfix übermitteln, in diesem Fall die OpnSense.

Laut der verlinkten Anleitung soll man den Präfix dann auf seine eigenen Netze aufteilen und per DHCPv6 und SLAAC weiterverteilen (aka "Assisted"). Das ist nicht so toll, weil per DHCPv6 ja eine Lifetime vorgegeben wird, die meist sogar ziemlich lang ist. So wird der neue Präfix erst nach einer Verzögerung verteilt, nämlich, wenn die jeweilige Leasetime eines Clients halb abgelaufen ist. Bis dahin versucht dieser, mit dem alten Präfix zu arbeiten, der nicht mehr gültig ist.

Besser wäre es, mit SLAAC-only zu arbeiten, aka "Unmanaged" oder mindestens den DHCPv6-Service abzuschalten und die "Router Advertisements" auf 200/600 Sekunden einzustellen. Soweit ich weiß, wirkt diese Zeit noch nicht einmal im konkreten Fall, weil beim Wechsel der Interface-IP der radvd neu gestartet wird und somit sofort den neuen Präfix per RA verteilt. Durch diesen Broadcast wird die Änderung viel schneller wirksam als wenn jeder Client erst viel später pollt.

Da der alte Präfix nicht invalidiert wird (da kein "DeprecatePrefix on"), wird er bis zu seinem Ablauf weiterhin vorhanden sein, aber nicht mehr aktiv für neue Verbindungen genutzt.

Der Grund, warum manche Clients bei Dir das besser verkraften als andere, wird genau das sein: Manche Clients "können" DHCPv6 und haben damit einen Nachteil gegenüber solchen, die einfach nur SLAAC machen.
SLAAC ist m.W. der kleinste gemeinsame Nenner, also funktioniert auch weiterhin alles.

Eine kurze Unterbrechung wird sich aber nicht verhindern lassen, das dürfte klar sein.

[mooh]

So wird der neue Präfix erst nach einer Verzögerung verteilt, nämlich, wenn die jeweilige Leasetime eines Clients halb abgelaufen ist. Bis dahin versucht dieser, mit dem alten Präfix zu arbeiten, der nicht mehr gültig ist.

Das verstehe ich nicht. Wenn der Präfix geändert wird, bleibt die Lebensdauer eines Vorgängers davon unberührt. Das neue Präfix wird also bereits verteilt und neue Adressen gebildet, bevor das alte Präfix ungültig wird und evtl nicht mehr geroutet. Dazu gibt es auch einen RFC, 4192 glaube ich.

Ich hatte das vor ein paar Jahren mal mit einem ISP, der zeitweise öfters mal ein neues Präfix zugewiesen hat. Da hatten die Interfaces mit IPv6 regelmäßig mindestens 5 Adressen gleichzeitig, eine link-lokale, und jeweils eine mit und ohne privacy extensions mit neuem und altem Präfix.

[meyergru]

Eben. Der Punkt ist, dass bei IPv6 anders als bei IPv4 der vom ISP geänderte Präfix eine Rolle spielt (der Client benutzt ja die Adresse, die sich bei IPv4 dank NAT aber nicht mit ändert).

Also kommt es darauf an, dem Client möglichst schnell den neuen Präfix zukommen zu lassen. Und da ist es genau, wie Du sagst: Es wäre reiner Zufall, wenn der Ablauf (oder Wegfall) des alten Leases mit der Änderung zusammenfällt. Der DHCP-Client fragt eben erst nach der Hälfte der Leasezeit an - das kann dauern. Und so lange versucht der Client, die alte, inzwischen ungültige Adresse zu nutzen. Er weiß ja nicht, dass es eine neue gibt.

Bei SLAAC dagegen wird anders als per DHCPv6 kein "Polling" durchgeführt, sondern der neue Präfix sofort per "Push" (d.h. Broadcast) verteilt.

Und was im RFC steht, interessiert den ISP oft genug gar nicht. Abgesehen davon kann seine Leasedauer ja ggf. kürzer sein als die, die man selbst konfiguriert hat. Asynchron ist es allemal.

Vor allem ist das alles unerheblich, wenn der neue Präfix gar nicht durch den ISP willkürlich (und gemäß RFC) vergeben wird, sondern, weil die Leitung kurz zusammenbricht oder beim Neustart der Fritzbox oder der OpnSense. Bei SLAAC kein Problem, bei DHCPv6 schon.

Privacy extensions haben damit nichts zu tun, dabei geht es nur darum, welchen Host-Teil sich der Client gerade greift (EUI-64 als festen Teil oder eben einen zufälligen Suffix).

[mooh]

Mehrere Präfixe zeitgleich sollten kein Problem sein. Ein Präfix mit Länge 128 deutet auf eine Vergabe durch einen DHCPv6 Server hin, weil die gesamte Adresse zugewiesen wird, eine Länge von 64 auf SLAAC, weil der Client die restlichen 64 Bits des Suffix selber bildet. Kann es sein, dass auf der OpenSUSE beides betrieben wird?

Man könnte mal probieren, ob es einen Unterschied macht welches Präfix man verwendet, indem man mit ping -I die Source-Adresse vorgibt.

Da während der Unterbrechungen keine Route existiert, würde ich mal nachsehen, ob die OPNsense eine default Route für IPv6 hat, bzw. ob der dort angegebene Router erreichbar ist. Spekulation: Vielleicht ist der Grund für die Präfixwechsel der Ausfall des Upstream-Routers. Bei Störung übernimmt ein anderer, der aus einem anderem Präfix-Pool schöpft. Mir ist die Telekom sonst nicht dafür bekannt häufige Präfixwechsel.


Meyergru, Danke für Deine Antwort. Aber damit komme ich immer noch nicht weiter.

Bei IPv6 kommt es, nach meinem Verständnis, nicht darauf an den Clients möglichst schnell eine neue Adresse / neues Präfix zukommen zu lassen. Dafür haben Präfixe eine "preferred" und eine "valid lifetime". Letztere regelt die Gültigkeit, erstere die Aktualisierung und ist typischerweise erheblich kürzer. Clients sollten nach der halben preferred lifetime damit beginnen ein Präfix zu prüfen/aktualisieren. Die Gültigkeit eines Präfix endet immer erst mit dem Erreichen der valid lifetime, also typischerweise Tage bis Wochen nach der preferred lifetime.

Deswegen muss jeder korrekt implementierte IPv6 Stack mit mehreren, sich zeitlich überlappend, gültigen Präfixen umgehen können. Bestehende Verbindungen können weiter mit alten Präfixen bestehen, während neue das jeweils aktuelle Präfix nutzen sollten.

All das ist unabhängig von SLAAC oder DHCPv6 und daher sehe ich nicht wieso SLAAC bei einem Präfixwechsel Vorteile bieten sollte. Ich lasse hier absichtlich systematisches Fehlverhalten außen vor. Wenn ein DHCPv6 Server Leases rausreicht, die länger gültig sind als das verwendete Präfix, oder Clients sich erst kurz vor Ablauf des Leases um eine Aktualisierung bemühen oder Upstream-Router vor Erreichen der valid lifetime das Routen eines Präfix einstellen, kann natürlich nichts mehr garantiert werden.

[meyergru]

Natürlich sind mehrere IPv6-Präfixe "kein Problem" - wenn sie alle noch funktionieren, was nicht immer der Fall ist, wie Du gleich sehen wirst.


Also, mach mal einfach folgenden Versuch:

Vorbereitung: Schalte den radvd auf Deinem Router ab und DHCPv6 an.

1. Sieh' Dir bei laufender Verbindung auf einem Client die IPv6-Adressen an. Im Idealfall haben die alle den gleichen /64 Präfix.

2. Trenne Deine Internetverbindung am Router. Verbinde ihn erneut. Verifiziere, dass der Präfix sich dort geändert hat (ist bei den meisten ISPs so).

3. Schau nochmal auf Deinem Client nach. Falls dieser seine IPv6 per DHVPv6 bekommen hat, zeigt er nach wie vor nur den alten Präfix.

4. Versuche, "ping -6 www.heise.de" zu machen. Das wird wahrscheinlich nicht funktionieren, bis der Client irgendwann meint, sein Lease sei abgelaufen und den Router explizit nach dem neuen Präfix fragt. Danach bekommt er zusätzlich den neuen Präfix, der dann im Gegensatz zum alten funktioniert.

Jetzt klar?

Der Unterschied zwischen Theorie und Praxis. Es mag sogar sein, dass manche ISPs das alles RFC-konform machen und sich z.B. über die Einwahl hinweg die alten Präfixe merken und diese noch bis zum Ablauf routen - manche tun das halt nicht. Als ich vor Jahren noch bei der Telekom war und die mit IPv6 angefangen haben, taten sie es jedenfalls nicht.

Der OP ist bei der Telekom und die Fehlerbeschreibung passt exakt zu einem solchen Verhalten. Wenn Du eine bessere Erklärung und / oder Problemlösung dafür hast, lass' sie uns hören.

Ich behaupte, dass neue Präfixe per Broadcast schneller den Client erreichen als durch regulären Ablauf per DHVPv5 und dadurch die "Lücken" entfallen oder kürzer ausfallen - schlechter wird es jedenfalls nicht. SLAAC erlaubt es per Lifetime "0" sogar, explizit alte Präfixe zu invalidieren.

[mooh]

Ok, danke. Dann ist das klar. Wenn Upstream jemand entscheidet ein gültiges Präfix nicht mehr zu routen, dann geht natürlich nichts mehr damit. Dann würde ich das erstmal als Fehler melden.

[Bob.Dig]

Aus einem anderen Thread:

but IGMP snooping was enabled all the time,

Ich mache mal hier weiter, weil ich die anderen Threads jeweils nicht kapern möchte. IGMP snooping sagt mir jetzt nichts, aber laut meiner "Recherche (ganz unten)" ist das ein IPv4 only Thema und IPv6 nutzt etwas anderes. Warum soll also genau das einen Unterschied in unserer Problematik machen?
Davon ab meine ich mich auch zu erinnern, dass teilweise nur der IPv6-DNS-Server nicht mehr gültig war, was halt trotzdem kritisch ist. Und ich hasse es, auf IPv6-Adressen zu gucken, d.h. meine Feststellung ist dann einfach, es geht nicht! :) Ich selbst nutze für gewöhnlich SLAAC und DHCPv6. Aber für die meisten Interface halt doch nur IPv4, weil es halt keine Probleme macht bei einem täglichen Prefix-Wechsel.

[meyergru]

Wenn Du in dem anderen Thread genau gelesen hättest, würdest Du feststellen, dass OPNenthu schrieb, dass seine spezifischen Probleme aufhörten, nachdem er IGMP eingeschaltet hatte und der Hersteller seines Switches konkret sagt, dass die Einstellung bei ihm auch auf IPv6 wirkt.

OPNenthru hatte Probleme mit IPv6, obwohl die RAs offenbar korrekt gesendet wurden - seine Clients diese aber offenbar ignorierten, eben weil der Switch sie nicht durchließ. Meine Bemerkung bezieht sich darauf, weil ich mit Unifi-Hardware die Probleme nie hatte und bei mir genau das bewusste Setting immer an war.

Das ganze Thema hatte nur bedingt mit dem hier besprochenen zu tun, nämlich, wie man prinzipiell IPv6 zum Laufen bringt.

Dazu wiederhole ich: Wenn der ISP regelmäßig IPv6-Präfixe wechselt oder die Verbindung abbricht und deswegen ein Wechsel stattfindet, ist SLAAC-only mit kurzer Lifetime (z.B. 200s) die Lösung - vorausgesetzt, dass die RA-Pakete auch wirklich beim Client ankommen (bei Unifi offenbar nur mit bestimmten Einstellungen). Ich bin sowieso ein Fan von SLAAC-only, weil bestimmte Geräte (z.B. Android) gar kein DHCPv6 können. Beiseite gesprochen kann DHCPv6 nur einen einzigen Präfix verteilen, also z.B. auch kein ULA plus GUA.

Noch besser wäre es wahrscheinlich, wenn in der radvd.conf "DeprecatePrefix on" gesetzt wäre, weil dann die alten Präfixe noch schneller invalidiert würden, aber Franco war nicht davon zu überzeugen, dass das keine negativen Effekte hat.

[Bob.Dig]

OPNenthru hatte Probleme mit IPv6, obwohl die RAs offenbar korrekt gesendet wurden - seine Clients diese aber offenbar ignorierten, eben weil der Switch sie nicht durchließ.

Ok. Mein Einsteiger-Switch hat IGMP Snooping aktiv, also dürfte es daran bei mir nicht liegen. Was ich auch meine gesehen zu haben, dass mein Rechner durchaus den neuen Prefix bekommen hat, also da wurde nichts geblockt, aber dass halt der alte Prefix auch noch verwendet wurde... Und das scheint mir weiterhin das Versagen der Sensen zu sein, den veralteten Prefix nicht für die Clients zu invalidieren. Und eine Umgehungslösung nur für SLAAC ist eben auch keine richtige Lösung, wenn es die Fritte doch richtig machen kann. Wobei ich mir jetzt nicht sicher bin, ob die überhaupt DHCPv6 gemacht hat. Generell bin ich als Noob dagegen, irgendwie an Clients herumzufummeln, wenn die Lösung eigentlich auch ohne dies funktionieren müsste. Ich mache halt jetzt meine Switche stromlos, bis die pfSense das gebacken bekommt.   

[meyergru]

Wie ich sagte, das IGMP-Snooping ist nur bei Unifi gleichzeitig für IPv6 zuständig, bei anderen Herstellern normalerweise nicht.

Ich rede auch nicht davon, "an Clients herumzufummeln", sondern davon, in den Einstellungen für die Router Advertisements das Mininum und Maximum Interval auf ein paar Sekunden herunterzudrehen. Das bestimmt nämlich, für wie lange der alte Präfix maximal gilt. Nach dieser Zeit wird der alte Präfix automatisch ungültig, danach funktioniert also alles wieder.

Abgesehen davon sehe ich gerade, dass "DeprecatePrefix On" in der aktuellen OpnSense 25.1.1 bereits gesetzt ist, also sollte das alles sowieso inzwischen funktionieren. Wenn nicht, liegt es entweder daran, dass man eben doch DHVPv6 und nicht SLAAC-only nutzt (warum das mit wechselnden Präfixen nicht klappt, habe ich oben erläutert und meines Wissens nach nutzt die Fritzbox auch nur SLAAC) oder die RAs nicht zu den Clients durchkommen - aus welchen Gründen auch immer.

Und dass die Anleitung nicht so super ist, darauf hatte ich ja bereits hingewiesen... deshalb:

https://forum.opnsense.org/index.php?topic=45822.0

[Bob.Dig]

Und dass die Anleitung nicht so super ist, darauf hatte ich ja bereits hingewiesen

Darauf wollte ich auch überhaupt nicht hinaus, habe gar nicht das Wissen, um mir ein Urteil zu erlauben. Habe gerade in meiner Sense nachgeschaut, auch dort ist DeprecatePrefix on. Ich kann ja mal den Prefix absichtlich ändern (lassen) und gucken, was alles schiefläuft.

Edit: Da scheint das neue KEA in der pfSense noch mehr Probleme zu machen als bisher, DHCPv6 bekommt mein Rechner gerade gar nicht... Also das lasse ich dann an dieser Stelle doch bleiben, weil eh OT, da nicht OPNsense.

[meyergru]

Erste Anlaufstelle, ob Deine Konfiguration passt, wenn's nicht richtig läuft, ist /var/etc/radvd.conf, habe ich auch im HOWTO geschrieben.

[Bob.Dig]

Der Witz ist, jetzt geht es hier wieder. Ich hab mir mit release6/renew6 die Adressen gezogen. Was mich gerade vom Hocker gerissen hat, dass ich trotz meines nächtlichen Stromlosmachens der Switche alte und neue Prefixe hatte und keine DHCPv6-Adresse. Ich wollte ja gerade den vermeintlich guten Vorher-Status ermitteln... Wo ist das Kotz-Emoji.

[Bob.Dig]

Ok, das Problem mit der abgelaufenen DHCPv6-Adresse resultierte wohl aus meiner Deaktivierung von DNS im DHCPv6 Server. Das verstößt wohl gegen RFC und führt dann zu so was...