Merkwürdiges IPv6-Verhalten bei DG mit zu geringer Leasetime

  • Seit Monaten kämpfe ich mit Verbindungsproblemen auf meinem Xiaomi Redmi 14 - spontan in ca. ~30% der Fälle ist, wenn ich das Smartphone entsperre, ein schönes Ausrufezeichen im WLAN-Symbol zu sehen und die WLAN-Verbindung funktioniert erst wieder, wenn ich das Handy neu verbinde.

    Ich habe alles mögliche ausprobiert und/oder im Verdacht gehabt - Handy zurückgesetzt, sämtliche Einstellungen der WLAN-APs hin- und her-verstellt, sämtliche Einstellungen im Handy hin- und her-verstellt, und so weiter.

    Mittlerweile habe ich den Verdacht, dass es an der Konfiguration der DG liegt.

    Die DG verhält sich ja, was IPv6 angeht schon immer etwas komisch (z. B. dass in den ersten ~10 Minuten nach Herstellen der Internetverbindung kein IPv6-Traffic funktioniert) und ich vermute dass die IPv6-Konfiguration der DG auch meine Probleme erklärt. Schalte ich testweise IPv6 in meinem Netzwerk komplett ab und verwende nur noch IPv4 durch das CGNAT, habe ich diese Verbindungsprobleme mit dem Smartphone nicht mehr.

    Ich habe mir in der Einstellungs-Datei der Fritzbox die Einstellungen zu den IPv6-Router-Advertisements angeschaut und dann mit denen verglichen, die ein "radvdump" anzeigt (also die Werte, die die Fritzbox tatsächlich ins Netzwerk schickt).

    Dabei ist es so, dass alle Einstellungen zur AdvValidLifetime o.ä. die man in der Konfig vornehmen kann (im Abschnitt "radv"), sich ausschließlich auf die ULA beziehen. Die Einstellungen zur Lebenszeit der öffentlichen IPv6-Adressen und Präfixe werden dabei vom ISP übernommen. D.h. die Gültigkeitsdauer, die in der Fritzbox unter "Internet, IPv6" zu sehen ist, entspricht auch der, die die Fritzbox dann in den RAs für das entsprechende Präfix an die Endgeräte kommuniziert.

    Klingt ja erstmal sinnvoll, und mit den meisten Geräten scheint das auch zu funktionieren.

    Problem ist dann nur RFC4862 Abschnitt 5.5.3e, welches beschreibt, wie genau ein Endgerät diese RAs zu verarbeiten hat. Dort steht nämlich drin: "If RemainingLifetime is less than or equal to 2 hours, ignore the Prefix Information option with regards to the valid lifetime, ...".

    Das bedeutet, der DHCP6-Server der DG nutzt merkwürdig kurze Lease-Zeiten sowohl für die WAN-IPv6 als auch für das Präfix, die Fritzbox übernimmt diese Lease-Zeiten dann für das Router Advertisement, und die (meiner Meinung nach standardkonformen) Endgeräte verwerfen diese dann, weil die verbleibende Laufzeit zu kurz ist; und verlieren dementsprechend dann irgendwann ihre IPv6-Verbindung. Dann ist die Verbindung irgendwann "weg", und mit Empfang der nächsten RA irgendwann später wird sie dann wiederhergestellt.

    Hat mit einem ähnlichen Problem schonmal jemand Erfahrungen gesammelt? Interpretiere ich diesen Abschnitt aus dem RFC korrekt und das könnte tatsächlich der Grund für die Probleme mit IPv6 in meinem Setup sein? Hat zufällig noch jemand ein Redmi Note 14 an einem DG-Anschluss in Betrieb?

    Und ist das wirklich Standardkonform was die DG da tut? Die verbleibende Zeit tickt dann herunter bis auf 1800, dann fragt die Fritzbox das Präfix erneut an, die Zeit verlängert sich auf 3600 Sekunden (1 Stunde) und die Fritzbox schickt ein neues RA mit Laufzeit von 3600 Sekunden ins Netzwerk und das Spiel geht von vorne los.

    Wenn ich die RFCs richtig lese dann sind eher so 7 Tage (Preferred Lifetime) bzw. 30 Tage (Valid Lifetime) empfohlen (RFC4861). In RFC8978 gibt es die Angabe, dass man unter bestimmten Umständen das auf bis zu 5400 Sekunden reduzieren kann, dass es dabei aber zu Problemen bei mobilen Geräten mit Batteriesparmodi kommen kann.

    Die DG unterschreitet mit ihren 1800 Sekunden diese Mindest-Untergrenze nochmal deutlich, und ich vermute dass das dann diese Probleme verursacht.

    Gibt es technische Gründe für diesen Quatsch? Ich habe noch nie erlebt, dass sich mein IPv6-Präfix ändert, wenn nicht die Fritzbox eine neue Verbindung aufbaut.

    Und gibt es irgendeine Möglichkeit für mich, falls das tatsächlich die Ursache meiner Verbindungsprobleme sein sollte, das abzuschaffen? Die DG wird wohl kaum für mich mal eben eine längere Leasetime in ihren DHCP6-Servern einstellen; und in den Fritzbox-Einstellungen habe ich nichts gefunden, wie man diese Laufzeit überschreiben kann, weder in der Weboberfläche noch direkt in der Konfigdatei.

    Einmal editiert, zuletzt von Leseratte10 (4. August 2025 um 20:09)

  • Viele Anbieter arbeiten mit dynamischen IP-Adressen, wie sollen die denn auf diese Lifetimes kommen? Prefixes im LAN zu verteilen, die länger gültig sind, als die WAN Adresse macht wohl auch keinen Sinn.

    Und 5.5.3e Satz 1 ist doch wahr in dem Fall, oder?

    Zitat
    Code
    1.  If the received Valid Lifetime is greater than 2 hours or
              greater than RemainingLifetime, set the valid lifetime of the
              corresponding address to the advertised Valid Lifetime.
  • Wie andere ISPs es machen, gute Frage. Habe gerade keinen Zugriff auf Anschlüsse mit Fritzbox und anderem ISP, aber ich habe mal die Google-Bildersuche bemüht und nach Screenshots der Fritzbox-Oberfläche gesucht. Die paar wenigen Screenshots die ich mit Google gefunden habe, haben alle deutlich längere Zeiten (24h/4h bei Netcologne, mindestens 22h/9h bei O2, Telekom auch mindestens 4h ...), und die ändern auch ab und zu mal das IPv6-Präfix. Nur bei der DG findet man so kurze Werte von 0.5h.

    Und was Satz 1 angeht - die DG-Leasetime läuft von 3600 Sekunden runter bis auf 1800 und wird dann verlängert und springt wieder auf 3600. D.h. ja, vermutlich würde das Smartphone die Zeit wieder auf 3600 (bzw. den empfangenen Wert zwischen 1800 und 3600) setzen, wenn ein neues RA empfangen wird, während der Wert auf dem Smartphone schon unterhalb von 1800 liegt. Das ist vermutlich auch der Grund, warum die Internetverbindung überhaupt (meistens) funktioniert und es nur zu diesen Aussetzern kommt.

    Das Problem ist dann vermutlich, wenn die Zeit auf 1800 (30 Minuten) runter läuft, die Fritzbox eh schon nur recht selten die RAs verschickt (teilweise alle 10 Minuten oder so?) und dann durch die ganzen WLAN-Energiesparmechanismen in modernen Handys die nächsten zwei RAs verschluckt werden / nicht empfangen werden / sonstwas. Anscheinend verschlucken Smartphones gerne mal eingehenden Multicast, wenn sie sich im Tiefschlaf befinden. Und wenn die Verbindung dann einmal "weg" ist wird sie auch nicht mit Empfang des nächsten RA wiederhergestellt, sondern erst wenn das Handy wieder eingeschaltet wird und *dann* das nächste RA ankommt (oder ich halt genervt die WLAN-Verbindung trenne und neu aufbaue).

    Habe ich das Handy dauerhaft am Strom angeschlossen und den Bildschirm eingeschaltet, taucht das Problem auch nicht auf. Das macht leider auch das Debugging und die Fehlersuche verdammt schwierig, wenn sich das Problem bei angeschlossenem Kabel (für ADB) nicht reproduzieren lässt.

    Ich versuche mal zum Testen Zugriff zu bekommen auf ein Netzwerk wo ich die RA-Timer komplett selbst einstellen kann (Opnsense oder so) und stelle sie dann explizit mal an einem nicht-DG-Anschluss auf 1800/3600 und schaue mal ob ich das Problem damit reproduziert bekomme ...

  • Tipp: Jetzt kostenlos registrieren, mitmachen und das Forum ohne Werbebanner nutzen.
  • Das Problem ist dann vermutlich, wenn die Zeit auf 1800 (30 Minuten) runter läuft, die Fritzbox eh schon nur recht selten die RAs verschickt (teilweise alle 10 Minuten oder so?)

    Das Endgerät kann ja eine Solicitation rausschicken.

    und dann durch die ganzen WLAN-Energiesparmechanismen in modernen Handys die nächsten zwei RAs verschluckt werden / nicht empfangen werden / sonstwas.

    Auch das kann eigentlich nicht passieren, denn dafür wird die Verbindung aufgeweckt. Darüber hinaus würde das Problem sich unabhängig von der Lifetime auswirken. Paketverluste können natürlich auftreten, aber die würden sich auch anderweitig auswirken.

    Anscheinend verschlucken Smartphones gerne mal eingehenden Multicast, wenn sie sich im Tiefschlaf befinden.

    Wenn das passiert, ist es eindeutig ein Fehler des Endgeräts. Ansonsten würde es das Prinzip von Multicasts komplett ad absurdum führen, und gerade IPv6 würde über WLAN gar nicht funktionieren.

    Habe ich das Handy dauerhaft am Strom angeschlossen und den Bildschirm eingeschaltet, taucht das Problem auch nicht auf.

    Was ja dann auch beweist, dass die RAs an sich nicht das Problem sind.

  • Interpretiere ich diesen Abschnitt aus dem RFC korrekt und das könnte tatsächlich der Grund für die Probleme mit IPv6 in meinem Setup sein?

    Ich glaube nicht!

    Grund: 5.5.3e - 2 tritt erst ein, wenn 5.5.3e - 1 nicht eingetreten ist:

    5.5.3e - 1: If the received Valid Lifetime is greater than 2 hours or
    greater than RemainingLifetime, set the valid lifetime of the
    corresponding address to the advertised Valid Lifetime.

    Bei DG ist "received Valid Lifetime" bei meinem Anschluss maximal 3600s = 2 1 hours, aber eben also nicht "greater than 2 hours". Allerdings wird in der Regel "received Valid Lifetime" (3600 bzw. Restlaufzeit der WAN-seitigen DHCPv6-Lease, diese ist i.d.R. per DHCPv6 Renew nie kleiner als 1800s) greater than "RemainingLifetime" sein. Also wird im Normalfall die "valid lifetime of the
    corresponding address" aus dem RA (advertised Valid Lifetime = 3600 bzw. Restlaufzeit der WAN-seitigen DHCPv6-Lease) übernommen.

    5.5.3e - 2: If RemainingLifetime is less than or equal to 2 hours, ignore
    the Prefix Information option with regards to the valid
    lifetime, unless the Router Advertisement from which this
    option was obtained has been authenticated (e.g., via Secure
    Neighbor Discovery [RFC3971]). If the Router Advertisement
    was authenticated, the valid lifetime of the corresponding
    address should be set to the Valid Lifetime in the received
    option.

    Damit 5.5.3e - 1 _NICHT_ zutrifft: müssen folgende Bedingungen gleichzeitig vorliegen:.

    • received Valid Lifetime <= min { 2 hours, RemainingLifetime }

    Die valid lifetime wird in diesem Fall nur dann durch den kleineren Wert "received Valid lifetime" aus dem RA überschrieben, wenn der RA per SeND authentisiert ist. SeND setzt meines Wissens aber niemand auf dieser Welt ein. Deshalb wird dann weitergereicht zu

    5.5.3e - 3: Otherwise, reset the valid lifetime of the corresponding
    address to 2 hours.

    "Otherwise" bedeutet hier "kein SeND", also wird im Fall received Valid Lifetime <= min { 2 hours, RemainingLifetime } die valid lifetime der Adresse auf "2 hours" gesetzt.

    6 Mal editiert, zuletzt von ::1 (5. August 2025 um 00:27) aus folgendem Grund: Korrekturen vorgenommen (Vorversionsteile durchgestrichen)

  • Ein Home-Router ist nach der reinen Lehre weder "Fisch noch Fleisch" sprich weder ein reiner Router noch ein reiner Host, sondern von jedem etwas (am WAN-Port ist er z.B. eher ein Host, LAN-seitig ein Router - bei IPv6 kommt noch der Mechanismus DHCPv6 PD hinzu, der eigens für dynamisch konfigurierte Home-Router ersonnen wurde).

    Deshalb gibt es auch eine gesonderte Beschreibung für diese Zwitterwesen: RFC7084 in Verbindung mit RFC6092.

  • Tipp: Jetzt kostenlos registrieren, mitmachen und das Forum ohne Werbebanner nutzen.
  • Das bedeutet, der DHCP6-Server der DG nutzt merkwürdig kurze Lease-Zeiten sowohl für die WAN-IPv6 als auch für das Präfix, die Fritzbox übernimmt diese Lease-Zeiten dann für das Router Advertisement, und die (meiner Meinung nach standardkonformen) Endgeräte verwerfen diese dann, weil die verbleibende Laufzeit zu kurz ist; und verlieren dementsprechend dann irgendwann ihre IPv6-Verbindung.

    Nein, die LAN-seitigen VL- und PL-Werte in RA für SLAAC sind standardkonform und werden von standardkonformen Geräten auch nicht verworfen. Die Leasezeiten sind auch nicht "merkwürdig" - im Grunde sind die absoluten Werte ziemlich irrelevant. Entscheidend ist, dass die Refresh-Mechanismen hinreichend oft funktionieren. Das tun sie aber, weil die Refresh-Raten mit den absoluten Leasedauer-Werten bzw. VL/PL-Werten skalieren.

    Schau dir an einem Windows-PC in deinem LAN mal eine halbe Stunde (z.B. alle 5 Minuten) lang den Output des folgenden Kommandos an:

    netsh int ipv6 sh addr

    Sieht bei mir so aus:

    Da kannst du wunderschön die VL- und PL-Werte anschauen, wie sie abnehmen und etwa alle 10 Minuten durch empfangene RA aktualisiert werden. Die VL/PL-Werte der GUA (2a00:6060...) sinken dabei minimal auf ~30 Minuten und werden dann wieder auf 60 Minuten hochgesetzt (dies im Rhythmus der DHCPv6-Renews am WAN-Interface der FB, die alle 30 Minuten die Leasedauer wieder auf 60 Minuten hochsetzen). Die ULA werden hingegen ~ alle 10 Minuten (Intervall zwischen 2 RA) wieder auf ihren Maximalwert (~ 2h) gesetzt - dort ist die FB selbst der Herr der Dinge.

    Du kannst dabei parallel im Windows einen Wireshark mitlaufen lassen und dir die empfangenen RA mit dem Anzeigefilter icmpv6.type==134 darstellen lassen - du siehst dann sehr gut, wie die per RA gelieferten PL/VL-Timer mit der Anzeige der PL/VL-Werte der Adressen korrespondieren.

  • frank_m: Ja, das Endgerät kann eine RS rausschicken, aber anscheinend tut es das nicht. Und dass Smartphones im Tiefschlaf manchmal Multicasts verschlucken ist nichts neues, siehe hier (gleiches Problem mit einem Xiaomi-Endgerät) und hier (Probleme mit Multicast auf mobilen Geräten mit Energiesparmodus generell) und hier (explizit in Situationen mit recht kurzen RA-Timern unter Android).

    Ja, vermutlich ist die Ursache der Energiesparmodus im Handy, wenn es mit eingeschaltetem Bildschirm keine Probleme gibt. Am Handy kann ich aber nix verändern um das zu lösen, und an anderen Internetanschlüssen hatte ich noch nie Probleme mit diesem Handy, nur an meinem DG-Anschluss.

    Allerdings wird in der Regel "received Valid Lifetime" (3600 bzw. Restlaufzeit der WAN-seitigen DHCPv6-Lease, diese ist i.d.R. per DHCPv6 Renew nie kleiner als 1800s) greater than "RemainingLifetime" sein. Also wird im Normalfall die "valid lifetime of the
    corresponding address" aus dem RA (advertised Valid Lifetime = 3600 bzw. Restlaufzeit der WAN-seitigen DHCPv6-Lease) übernommen.

    Ja, natürlich wird diese Restlaufzeit aus dem WAN-Lease übernommen, aber meiner Meinung nach ist das immer noch zu kurz. Im schlimmsten Fall hat das Smartphone gerade noch ein RA mit 1801 Sekunden mitbekommen bevor der Lease verlängert wurde, dann schickt die Fritzbox alle ~10 Minuten oder so ein RA raus, d.h. es wird schon kritisch wenn 2-3 hintereinander "verschluckt" werden.

    Was ja dann auch beweist, dass die RAs an sich nicht das Problem sind.

    Das kommt drauf an wie man "Problem" definiert :) - die RAs an sich mögen vielleicht Standardkonform sein und ja, vermutlich ist das Handy bzw. dessen Firmware blöd implementiert - aber die RAs werden vermutlich die einzige Stelle sein, an welcher ich schrauben kann um das Problem zu verhindern.

    Entscheidend ist, dass die Refresh-Mechanismen hinreichend oft funktionieren. Das tun sie aber, weil die Refresh-Raten mit den absoluten Leasedauer-Werten bzw. VL/PL-Werten skalieren

    Genau das ist aber ja die Frage - ist es hinreichend oft? Die Fritzbox sendet nur alle 10 Minuten ein RA, wie in den oben geposteten Links erkennbar verschlucken Android-Geräte im Standby gerne mal RAs (ob standardkonform oder nicht), und damit gibt es dann Probleme.

    Den von dir genannten Test habe ich auch schon durchgeführt, nur mit einem Linux-Gerät und mit "ip -6 a". Da sehe ich genau diese ablaufende Zeit die immer von 3600 runterzählt und genau die Werte hat, die auch mit radvdump oder in Wireshark sichtbar sind. Der Desktop-PC hat aber halt auch keinen Energiesparmodus, der mal eben Pakete verwirft ...

  • Und dass Smartphones im Tiefschlaf manchmal Multicasts verschlucken ist nichts neues, siehe hier (gleiches Problem mit einem Xiaomi-Endgerät) und hier (Probleme mit Multicast auf mobilen Geräten mit Energiesparmodus generell) und hier (explizit in Situationen mit recht kurzen RA-Timern unter Android).

    Und in allen Artikeln wird ja auch schön deutlich, dass es sich um "herstellerspezifische Hacks" (Zitat) handelt. Strafe muss sein. Mein Samsung Smartphone hat noch nie im Standby die IPv6 Verbindung verloren, es sendet allerdings auch eine RS raus, wenn es das für richtig hält (hab ich gestern noch in Wireshark gesehen).

    Das kommt drauf an wie man "Problem" definiert :) - die RAs an sich mögen vielleicht Standardkonform sein und ja, vermutlich ist das Handy bzw. dessen Firmware blöd implementiert - aber die RAs werden vermutlich die einzige Stelle sein, an welcher ich schrauben kann um das Problem zu verhindern.

    Nein, wirst du nicht. Du wirst das Problem dadurch nur verschieben. Die Situation der verpassten, entscheidenden RAs wird nur nach hinten geschoben, tritt dann aber genauso ein. Und meiner Meinung nach macht es keinen Sinn, RAs mit höherer Gültigkeitsdauer, als die des zugrundeliegenden WAN Prefixes, zu verteilen. An DG Anschlüssen mag es noch gehen, an Anschlüssen mit dynamischen IPv6 Prefixes kommst du da in Teufels Küche.

  • Tipp: Jetzt kostenlos registrieren, mitmachen und das Forum ohne Werbebanner nutzen.
  • Leseratte10 : Wie du ja auch schon erwähnt hast, ist für mich die Frage, wie sich dein Smartphone im Sleep-Modus verhält: Empfängt und verarbeitet es in diesem Zustand keinerlei WLAN-Traffic, insbesondere auch keine IPv6-RA, dann wird es nach hinreichend langem Schlaf beim Aufwachen natürlich keine valide IPv6-Adresse (Timeout VL bei Konfiguration via SLAAC) bzw. auch keine valide IPv4-Adresse (Timeout der DHCP-Leasedauer) mehr haben.

    In dem Fall muss das Interface halt neu initialisiert werden. Das scheint dem Phone per IPv4 offenbar schnell zu gelingen, nicht jedoch für IPv6. Für mich sieht das nach einem Bug in deinem Phone aus. Lange VL/PL stellen hier nur einen Workaround dar, lösen das grundsätzliche Problem aber nicht.

    Vielleicht kannst du das Problem mittels Paketmitschnitt in der Fritzbox (WLAN-Schnittstelle), durchgeführt während einer Aufwachphase deines Phones, näher analysieren? Dein Phone sollte nach dem Aufwachen IPv6-RS (Router Solicitations) senden - tut es das nicht, dann liegt das Problem beim Phone.