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]

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]

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]

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]

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 :-( 
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]

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]

        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.