Kein Traffic über IPv6 möglich (Deutsche Glasfaser)

  • ::1 Danke für deinen Input. Meine Fritzbox hat ein Site2Site VPN zu einem VPS bei Hetzner. Die 100er IP war die der FB hinter dem CGNat. Warum die Box allerdings die 10.8.0.1 (VPN-IP des VPS) über die WAN-Schnittstelle anpingt, wissen vermutlich nur der liebe Gott und AVM. Vielleicht Fehlrouting meiner Uptime Kuma-Instanz zuhause, als nach dem Reconnect der Tunnel noch nicht oben war? Bzgl. Erreichbarkeit ist es möglich, dass IPv6 als du es versucht hast, schon wieder deaktiviert war. Die Androids bei uns im Haus wollen ja gefühlt alle IPv6 sprechen sobald sie eine valide IP erhalten haben, aber viele Apps funktionieren dann nicht mehr, da ja nichts über IPv6 zu uns rein kommt :D Hatte es aber getestet und WAN-IF ist über IPv6 erreichbar.

    Nachdem meiner letztes Ticket geschlossen wurde mit der Begründung: "Ihre Schuld, weil Sie ein Eigengerät nutzen", hab ich mal wieder ein neues Ticket bei DG aufgemacht, noch bevor du mir geantwortet hast. Da hab ich u.a. das hier geschrieben:


    Desweiteren hatte ich noch ein Ticket mit gleicher Problematik (auch im Dorf bei uns) bei meinen Schwiegereltern offen. Dort aber mit Leihgerät (Fritzbox). Da kam folgende Antwort gestern:

    Zitat


    Wir haben Ihren Anschluss erneut überprüft und können derzeit keine netzseitige Störung feststellen.

    Bitte prüfen Sie die IPv6-Einstellungen Ihrer FRITZ!Box wie folgt:

    1. Öffnen Sie die Benutzeroberfläche, indem Sie http://fritz.box im Browser eingeben.
    2. Melden Sie sich mit Ihrem FRITZ!Box-Passwort an.
    3. Gehen Sie zu Internet → Zugangsdaten → IPv6.
    4. Aktivieren Sie IPv6:
      • Setzen Sie ein Häkchen bei „IPv6-Unterstützung aktiv“.
      • Wählen Sie „Native IPv6-Anbindung verwenden“.
      • Falls diese Option nicht angezeigt wird, wählen Sie „IPv6-Anbindung über Tunnelprotokoll“ (z. B. 6to4).
    5. Klicken Sie anschließend auf „Übernehmen“.


    Das hatte ich ja aber alles schon an meinem Anschluss durch und ist nicht die Lösung.

    Die Nummer mit IPv6 ist für mich eher so ein prinzipielles Ding geworden, da ich es eigentlich nicht brauche aufgrund des VPS. Aber dass sich hier alle im Ort beschweren wie lahm das Internet der DG ist und ich schon mehreren sagen musste "Schalt einfach IPv6 aus momentan", ist halt auch einfach traurig. Und da da auch viele dabei sind, die einfach null technische Kenntnis haben, gibt es auch keine Ticketflut, so dass da mal einer bei der DG drauf kommen könnte, dass es sich um ein zentrales Problem handeln könnte.

    Die Frage ist, ob man da einfach abwartet, weil das Netz noch frisch ist, oder weiterzieht. Lustigerweise ist meine MVLZ nach Anpassung, wie hier im Forum erwähnt, zeitglich zu meiner Aktivierung, d.h. ich könnte bereits jetzt schon wieder kündigen und zu 1&1 gehen, die bereits alle hier im Ort angeschrieben haben. Aber ob man da nicht vom Regen in die Traufe kommt?

    3 Mal editiert, zuletzt von sh0rty (23. Februar 2026 um 14:47)

  • Ich will jetzt nicht belehrend wirken, aber einige Punkte deiner Darstellung sind nicht so ganz eindeutig oder ein Fehler:

    Zitat

    3. Gateway fe80::22 (MAC: 20:00:10:38:40:93) leitet KEINE Pakete weiter

    Kann sein (in ausgehender Richtung zum Internet). Möglich ist aber auch, dass das Gateway deine ausgehenden Daten zum Internet-Ziel weiterleitet, aber die Antworten vom jeweiligen Internet-Server zwar bis zum AS60294 der DG zurück gelangen, im Netz der DG aber nicht zu deinem BNG/Anschluss zurück geroutet werden.

    Zitat

    5. Ständige Neighbor Solicitation-Wiederholungen

    Das ist kein Fehler.

    Zitat

    Das Gateway antwortet auf Neighbor Discovery, aber routet keine Pakete.
    Dies ist ein BNG/ONT-Konfigurationsproblem, NICHT ein Router-Problem.

    wie oben (5.) Es ist vermutlich auch kein BNG/ONT-Problem, sondern ein (Rückwärts-)Routing-Problem innerhalb des DG-Netzes (aus deiner Sicht "hinter" dem BNG)

    Nachtrag:

    Insbesondere wäre auch der /64 als PD-LAN-Präfix zu monieren (sollte doch wohl ein /56 sein), und die extrem kurzen Leasedauern von nur 10min für WAN-IPv4 und WAN-IPv6/PD-LAN - das ist nicht normal.

    Einmal editiert, zuletzt von ::1 (23. Februar 2026 um 14:59)

  • Alles gut. Am Ende ist mir wichtig, dass da überhaupt mal jemand drauf schaut, der über den 1st Level Support hinaus geht. Denn ich bin mir nicht sicher, ob die bisherigen Anfragen zur Thematik einen richtigen Techniker von denen jemals erreicht haben. Ich habe deine Anmerkungen/Korrekturen mal mit ins Ticket gepackt. Mal sehen was als nächstes kommt...und danke für deine kompetente Hilfe und Einschätzung!

    3 Mal editiert, zuletzt von sh0rty (23. Februar 2026 um 16:55)

  • Tipp: Jetzt kostenlos registrieren, mitmachen und das Forum ohne Werbebanner nutzen.
  • ::1 Nach Wiedereröffnung des Tickets und übersenden der Mitschnitte hat sich bei DG was getan. IPv6 funktioniert nun reibungslos, wenn auch mit den von dir in Frage gestellten Parametern (/64 LAN Präfix + Leasedauer 600s). Mein Nachbar konnte diese Werte an seinem Anschluss ebenfalls bestätigen an seinem Unifi Cloud Gateway.

    Danke für deine Hilfe!

  • @ bei der kurzen Leasedauer, bekommst du da neue IP-Adressen oder wird die nur wieder neu gesetzt?
    Das erste wäre ja extremer Stress für alle Beteiligten, das zweite unnötiger Traffic am Server, an dem ja Tausende Endkunden hängen.

  • @ bei der kurzen Leasedauer, bekommst du da neue IP-Adressen oder wird die nur wieder neu gesetzt?
    Das erste wäre ja extremer Stress für alle Beteiligten, das zweite unnötiger Traffic am Server, an dem ja Tausende Endkunden hängen.

    Nein IP bleibt tatsächlich gleich, zumindest seitdem ich gestern IPv6 wieder aktiviert habe.

  • Tipp: Jetzt kostenlos registrieren, mitmachen und das Forum ohne Werbebanner nutzen.
  • In der Fritze siehst Du die Leasedauer mittlerweile leider nur noch mit dem Ist/Aktuellem-Wert. Schau mal da nach. Momentan weiß ich nicht (mehr), ob der Sollwert bei 3600 oder 1800 Sekunden liegt.

  • Zur DHCPv6-Leasedauer:

    An meinem DG-Anschluss (nach "altem" Adress-Standard) zeigt ein Paketmitschnitt den folgenden Inhalt einer DHCPv6-Reply-Message:

    Sowohl für die WAN-Port-Adresse des Routers (IA_NA) als auch für den LAN-PD-Block (IA_PD) gilt:

    Leasedauer = "Preferred lifetime" = "Valid lifetime" = 3600s.

    Laut DHCPv6-Standard ergeben sich daraus die folgenden Werte für den ...

    • Renew-Timer T1 = 0.5 * Leasedauer = 1800s
    • Rebind-Timer T2 = 0.8 * Leasedauer = 2880s

    Die IA_PD "Prefix length" beträgt standardmäßig /56

    Zur Erinnerung:

    Um zu verhindern, dass die Leasedauer abläuft und die IPv6-Adressen damit ungültig werden, sendet der Router rechtzeitig (nach Ablauf von T1) einen DHCPv6-Renew-Request, der vom DHCPv6-Server (der die Lease zugeteilt hat - wie unter "Server Identifier" angegeben) üblicherweise mit einem DHCPv6-Reply beantwortet wird. Das setzt die Leasedauer wieder auf den Maximalwert.

    Erhält der Router keine Antwort, so sendet er nach Ablauf von T2 einen DHCPv6-Rebind-Request, der sich diesmal jedoch unspezifisch an alle erreichbaren DHCPv6-Server richtet (sofern es mehrere gibt), in der Hoffnung, dass evtl. ein anderer DHCPv6-Server die Lease verlängert (habe ich in Paketmitschnitten am DG-Anschluss auch schon gesehen).

    Erst wenn auch ein DHCPv6-Rebind-Request unbeantwortet bleibt, läuft die Leasedauer ab, und der Router verliert seine IPv6-Adressen. Er startet anschließend einen neuen DHCPv6-Exchange - aber es kommt bis zum Erhalt neuer Adressen zu einer Netzunterbrechung.

    Eine kurze Leasedauer von 600s skaliert entsprechend auch T1 (300s) und T2 (480s) nach unten. Es läuft dann im Vergleich zum Standardfall eben alles 6-fach öfter.

    ----------------------------------------------------------------------------------

    Warum DG an neueren Anschlüssen die Leasedauer so signifikant absenkt und auch nur noch einen LAN-PD-Block der Größe /64 spendiert, erscheint mir rätselhaft. Auch die quasi-permanente Adresszuweisung scheint hier wegzufallen, alle paar Tage werden geänderte Adressen zugewiesen.

  • Eine kurze Leasedauer von 600s skaliert entsprechend auch T1 (300s) und T2 (480s) nach unten. Es läuft dann im Vergleich zum Standardfall eben alles 6-fach öfter.

    Vielleicht wollte einer etwas Gutes tun und eigentlich 6000s eintragen. Das sind mitunter so die kleinen Fehler, die sich einschleichen. Das Problem: Man müsste diejenigen kontaktieren können, die die Konfig schreiben, die dann über das Netz ausgerollt wird.

    Jedenfalls machen solch kurze Zeiten keinen Sinn und nur eine unnötige Last im System.

  • Tipp: Jetzt kostenlos registrieren, mitmachen und das Forum ohne Werbebanner nutzen.
  • Vielleicht wollte einer etwas Gutes tun und eigentlich 6000s eintragen. Das sind mitunter so die kleinen Fehler, die sich einschleichen. Das Problem: Man müsste diejenigen kontaktieren können, die die Konfig schreiben, die dann über das Netz ausgerollt wird.

    Das glaube ich nicht, dass das ein Versehen war.

    Jedenfalls machen solch kurze Zeiten keinen Sinn und nur eine unnötige Last im System.

    Doch, macht sogar viel Sinn. Wenn pro versorgtem Segment plötzlich mehrere BNG im Einsatz sind, und zur Wartung oder aus anderen Gründen ein anderer BNG die Sessions übernehmen muss, können geringere Leasetimes von großem Vorteil sein. Es könnte sich hier auch um eine temporäre Verkürzung der Leasetimes über den BNG handeln, dieser kann dort auch steuernd eingreifen, ohne das Veränderungen am DHCP-Server selbst (sofern der BNG nicht selbst sogar den DHCP-Service bereitstellt) notwendig wären. Wir hatten das regelmäßig vor Updates bzw. Schwenks auf andere BNGs vor Wartungsarbeiten runter gesetzt.

  • Tipp: Jetzt kostenlos registrieren, mitmachen und das Forum ohne Werbebanner nutzen.
  • Wann kommt endlich IPv8?

    Spoiler anzeigen

    ISP: HTP Surf & Fon 1.000 MBit/s Download / 500 MBit/s Upload (Glasfaser)

    Router: MikroTik CCR2004-16G-2S+ (RouterOS 7.22.1) + Genexis Fibertwist F2110-2 (Rev2.0) @ AON (1000BASE-BX)

    VoIP: Gigaset N670 IP Pro Mini Multicell (Firmware 2.67.0), Cisco ATA-191-MPP 2-Port Phone Adapter (Firmware 11-3-2MPP0001-225), Gigaset Fusion (Firmware 2.0.1)

    Handset: Gigaset SL800H Pro (Firmware 131.013.04)