Mehrere IPv6 Routen auf meinen Endgeräten nach Prefixänderung duch ISP

Diese Webseite finanziert sich ausschließlich durch freiwillige Spenden. Dank der Unterstützung unserer Nutzer können wir die Inhalte werbefrei und unabhängig anbieten. Jetzt Unterstützen

    Hallo zusammen,

    ich habe ein Problem mit meiner UDM Pro und IPv6 SLAAC: Nach einem Prefix-Wechsel (per DHCPv6-PD von meinem ISP 1&1) bleiben alte /64-Prefixes auf meinen Endgeräten aktiv, obwohl ein neues Prefix verfügbar ist. Die Geräte können dann nicht mehr ins Internet, bis sie neu starten oder ich manuell die alten Routen entferne.

    Folgendes verhalten sehe ich dann an meinen Endgeräten (Hier am beispiel Linux):

    Code
    ip -6 route

2001:9e8:d586:4701::/64 dev eth0 proto kernel metric 256 expires 85098sec pref medium
2001:9e8:d586:4b01::/64 dev eth0 proto kernel metric 256 expires 86044sec pref medium
fe80::/64 dev eth0 proto kernel metric 256 pref medium
default via fe80::dab3:70ff:fe1b:d8a6 dev eth0 proto ra metric 1024 expires 1444sec hoplimit 64 pref high

    Für mich sieht es so aus, als würde SLAAC das alte Prefix nicht invalidieren oder die Lifetime ist zu hoch. Leider habe ich auch keinen weg gefunden, wie ich das beheben könnte.

    Hier einmal die WAN Konfiguration (UDM Pro hinter Vigor 167 Modem):


    Und hier eins meiner VLANs

    Hat jemand von euch auch das Problem oder eine Idee, wie ich es lösen kann?

    Edited once, last by Ka-get (June 21, 2026 at 12:43 PM).

    Quote from Ka-get

    2001:9e8:d586:4701::/64 dev eth0 proto kernel metric 256 expires 85098sec pref medium
    2001:9e8:d586:4b01::/64 dev eth0 proto kernel metric 256 expires 86044sec pref medium

    Diese beiden Präfixe werden offenbar mit der Preferred Lifetime von 24 Stunden announciert. Das sieht für mich erstmal korrekt aus und häufiger als das sollte 1&1 Dir ja auch nicht die Präfixe unterm Hintern wegziehen.

    Kannst Du das Phänomen auf verschiedenen Clients mit verschiedenen Betriebsystemen nachstellen? Ich habe diesbezüglich noch in keiner Umgebung ein vergleichbares Problem gesehen.
    Weil Du schreibst, die Clients kämen nicht mehr ins Internet: Betreibst Du reine v6-Netze? Ansonsten sollte ja jederzeit der Dualstack-Fallback auf v4 erfolgen, wenn es auf v6 Konnektivitätsprobleme gibt.

    Firmware von UDM Pro und "Network" sind aktuell?

    P.S.: Herzlich willkommen in der Community! :)

    Hi Networker,

    Quote

    Diese beiden Präfixe werden offenbar mit der Preferred Lifetime von 24 Stunden announciert. Das sieht für mich erstmal korrekt aus und häufiger als das sollte 1&1 Dir ja auch nicht die Präfixe unterm Hintern wegziehen.

    ich vermute mal dass er die Prefixe erst kürlich erneuert hat und dann neue zugewiesen bekommt.

    Ich kann mal morgen nochmal die Routen ausgeben wenn ich das Problem nicht provuziere sondern wenn es natürlich auftritt.

    Quote

    Kannst Du das Phänomen auf verschiedenen Clients mit verschiedenen Betriebsystemen nachstellen? Ich habe diesbezüglich noch in keiner Umgebung ein vergleichbares Problem gesehen.

    Leider habe ich gerade nur Linux im "Dauerbetrieb" aber ich teste es morgen mal mit Windows. Konkret habe ich das problem mit meinen Servern, das Prefix wird, so glaube ich zumindest, nachts rotiert.

    Quote

    Weil Du schreibst, die Clients kämen nicht mehr ins Internet: Betreibst Du reine v6-Netze? Ansonsten sollte ja jederzeit der Dualstack-Fallback auf v4 erfolgen, wenn es auf v6 Konnektivitätsprobleme gibt.

    Hier gehe ich einfach davon aus, dass wenn eine IPv6 Adresse via DNS Verfügbar ist, versucht er die zu gehen, aber immer stehts über eine falsche route (Bsp.: Hetzner). Die Hosts versuchen garnicht erst, auf IPv4 zurückzufallen.

    Quote

    Firmware von UDM Pro und "Network" sind aktuell?

    UniFi OS 5.1.19, Network 10.4.57 (Keine ausstehenden Updates)

    Quote from Networker

    P.S.: Herzlich willkommen in der Community! :)

    Danke :)

    Quote from Ka-get

    Hier gehe ich einfach davon aus, dass wenn eine IPv6 Adresse via DNS Verfügbar ist, versucht er die zu gehen, aber immer stehts über eine falsche route (Bsp.: Hetzner). Die Hosts versuchen garnicht erst, auf IPv4 zurückzufallen.

    Hmm, das geht alles etwas durcheinander. Wir reden also sowohl von Endgeräten (Clients) die keine Verbindung raus bekommen als auch Hosts (mit eingehendem Verkehr), die nicht mehr erreichbar sind? Das muss man jetzt erstmal auseinander halten und ggf. getrennt angehen.

    Ein Client mit aktivem v4/v6-Dualstack sollte immer automatisch auf das jeweils andere Protokoll wechseln, wenn eines von beiden den Verbindungsversuch nicht erfolgreich abschließen kann. Dies kann teilweise ein paar Sekunden dauern, insbesondere wenn Dein OS oder Deine Applikation "Happy Eyeballs" nicht unterstützt.

    Bei einem Host ist die Logik (eingehende Verbindungen) natürlich anders, denn ohne entsprechendes Monitoring bzw. eigene abgehende Anfragen kann er eigentlich nicht bemerken, dass sein Präfix vor Ablauf der Valid Lifetime ungültig geworden ist.
    Bei vom Host abgehenden Verbindungen funktioniert das Prizip aber genauso wie auf Clients.

    So grade mal die PPP Verbindung gekappt und neu eingewählt...
    (UDM SE, 5.1.20 und 10.5.43)

    Hier ein Debian 13

    Code
    ip -6 route
2003:105:bf19:e800::/64 dev enp0s3 proto kernel metric 256 expires 11935sec pref medium
2003:105:bf19:e800::/64 dev enp0s3 proto ra metric 1002 mtu 1500 pref high
2003:105:bf20:8800::/64 dev enp0s3 proto kernel metric 256 expires 14263sec pref medium
2003:105:bf20:8800::/64 dev enp0s3 proto ra metric 1002 mtu 1500 pref high
fe80::/64 dev enp0s3 proto kernel metric 256 pref medium
default via fe80::d021:f9ff:fe81:ede2 dev enp0s3 proto ra metric 1002 mtu 1500 pref high
default via fe80::d021:f9ff:fe81:ede2 dev enp0s3 proto ra metric 1024 expires 1739sec hoplimit 64 pref high

    die "2003:105:bf20:8800" ist das Aktuelle Prefix. Default Route ist wie vorher auch via Lokal Link.

    Die alten alten "2003:105:bf19:e800" IP sind auch deprecated
    während des neu einwählen hat die Büchse noch dazu ne ULA IP gezogen (woher auch immer, schein ne art failback von unifi zu sein(
    (die FDEC Adressen, waren vorher nicht da und bei der Lebenszeit auch gleich wieder weg)


    Doppelte und dreifachen IPt6 weil alle ja immer Privacy Extensions pauschal mit anhaben die benutzt wird.

    Ja Internet vorhanden...

    Code
    ping -6 heise.de
PING heise.de (2a02:2e0:3fe:1001:302::) 56 data bytes
64 bytes from redirector.heise.de (2a02:2e0:3fe:1001:302::): icmp_seq=1 ttl=58 time=12.4 ms
64 bytes from redirector.heise.de (2a02:2e0:3fe:1001:302::): icmp_seq=2 ttl=58 time=11.8 ms

    Schaut alles gut aus. Ähnliches auf macOS würde also sagen funktioniert so wie es soll...
    (gut forcierter neueinwahl ist ggf noch was anderes als Leasetime abgelaufen, da hat die telekom aber mit 180 Tagen
    etwas was ich noch die gesehen habe weil Updates eh schon vorher zum Neustart verpflichten :-)

    Hast du Irgendwelche FW Reglen oder Locale Firewalreglen auf den Host die das beeinflussen könnten ?
    Die alten IPv4 Profis fummeln ja gerne an ICMP 4 rum und töten das komplett, was tödlich ist bei Ipv6...

    Sonst keien Ahnung...

    Quote from Networker

    Ein Client mit aktivem v4/v6-Dualstack sollte immer automatisch auf das jeweils andere Protokoll wechseln, wenn eines von beiden den Verbindungsversuch nicht erfolgreich abschließen kann. Dies kann teilweise ein paar Sekunden dauern, insbesondere wenn Dein OS oder Deine Applikation "Happy Eyeballs" nicht unterstützt.

    Das ist leider sehr hofft das es bei den App hängt.

    Bei IPv6 holt sich z.B. Chrome selber IPv6 Adressen für Verbindung zu Google Dienste. Google pusht ja IPv6 schon lange.

    Wenn ich meinen PC nächsten Tag wieder nutze und nach der Zwangstrennung wieder, die noch offenen Chrome-Tabs nutze, hat er Probleme damit. Häufig hilft es nur, dass ich Chrome neu starte. alte Tabs werden dann zügig neu gestartet.

    Das selbe bei Thunderbird. 10 E-Mail Konten.

    Die zwei Google Konten werden nicht neu geladen nach IPv6 Wechsel. Auch da Thunderbird Neustart hilft.

    Das ganze ist meistens ein DNS Problem. Wenn ich dem Host/Client ein öffentliche IPv6 DNS gebe passiert es nicht.

    Quote from phino

    Wenn ich dem Host/Client ein öffentliche IPv6 DNS gebe passiert es nicht.

    Das macht kein Sinn... Warum sollte ein "meinedomain.tld" mit einem AAA Einrag auf deinen Client besser funktionieren.
    Der Client hat möglicherweise einen Host und Domain Namen aber der wird bei HTTP/IMAP/POP/SMTP eher nicht mitgesendet ?
    Max der PRT record währe interessant, den kann man aber eher selten beinflussen bei einen 08/15 Internetzugang...

    Erstmal ein Update: Irgendwie geht nun alles wieder, ich habe zwar nachwievor 2 IPv6 Routen aber ich kann von einem betroffenen Gerät alles anpingen/erreichen.

    Quote from Networker


    Hmm, das geht alles etwas durcheinander. Wir reden also sowohl von Endgeräten (Clients) die keine Verbindung raus bekommen als auch Hosts (mit eingehendem Verkehr), die nicht mehr erreichbar sind? Das muss man jetzt erstmal auseinander halten und ggf. getrennt angehen.

    Sorry, da hab ich ein paar Begriffe durcheinandergeworfen. Als Beispiel hatte ich ein Problem, von einem betroffenen Gerät api.hetzner.cloud zu erreichen (Ping). Probleme mit eingehendem Verkehr hatte ich nicht.


    Aber vielleicht nochmal als abschließende Frage für euch: Eine möglichkeit, die Lifetimes für die RA herunterzusetzen gibt es nicht, oder?

    Mhhh

    Unifi verteilt das:

    Einstellbar ist das nicht über die GUI.

    die Config dafür liegt in /run/dnsmasq.dhcp.conf.d/dhcp.dhcpServers-net_XXXXX_IPV6.conf
    XXX ist dabei ne Mischung aus VLAn name, Bridgeinterface und IPv4 Adresse.

    Man könnte nen Script Schreiben das die ra-param=br0,high,600,1800 anpasst und jedesmal ausgeführt wird
    wenn du irgendwas am DNS anpasst und die Datei neugeschrieben wird.
    Alternativ auf SLAAC verzichten und per DHCP verteilen, das kann man die lease die angeben..

    Sinnvoll ist beides nicht :-) aber jeder wie er es braucht....

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!

Register Yourself Login