Beiträge von ::1

Zitat von HubeBube

Telefonie bei Deutsche Glasfaser ist nach aktuellem Kenntnisstand IPv4-only.

Das wird durch ständige Wiederholung nicht wahrer:

C:\>nslookup
Standardserver:  localhost
Address:  ::1

> set q=SRV
> _sip._udp.dg.voip.dg-w.de
Server:  localhost
Address:  ::1

Nicht autorisierende Antwort:
_sip._udp.dg.voip.dg-w.de       SRV service location:
          priority       = 20
          weight         = 1
          port           = 5060
          svr hostname   = sip20.voip.dg-w.de
_sip._udp.dg.voip.dg-w.de       SRV service location:
          priority       = 10
          weight         = 1
          port           = 5060
          svr hostname   = sip10.voip.dg-w.de
> set q=A+AAAA
> sip10.voip.dg-w.de
Server:  localhost
Address:  ::1

Nicht autorisierende Antwort:
Name:    sip10.voip.dg-w.de
Addresses:  2a00:6020:100:603::186
          185.22.44.186

> sip20.voip.dg-w.de
Server:  localhost
Address:  ::1

Nicht autorisierende Antwort:
Name:    sip20.voip.dg-w.de
Addresses:  2a00:6020:200:603::165
          185.22.45.165

Meine Fritzbox führt als SIP-Client die SIP-Registrierungen per IPv6 durch, auch die Sprachübertragung eines Telefongesprächs via RTP läuft bei mir via IPv6 - alles auch per Paketmitschnitt verifiziert.

In der Rufnummern-Konfiguration der DG-Rufnummern kann man das gewünschte Protokoll (IPv4 und oder IPv6) einstellen.

Zitat von Luki

Sehr merkwürdig - ab und zu ist die Verbindung da und ping bring zurück eine richtige und korrekte Rückmeldung, siehe Anhang - die Datei habe ich archiviert, da sie sonst zu lang ist.

Das hatte ich als Möglichkeit in #329 schon in Betracht gezogen - ich kopiere es mal:

"
Noch ein Nachtrag:

Zumindest für kurze Zeit scheint dein IPv6-Access (inbound + outbound) zu funktionieren. Ich vermute immer dann, wenn deine Fritzbox einen RA von der DG-Gegenstelle erhält und daraus die MAC-Adresse 20:00:00:00:20:38 der Gegenstelle lernt. Solange sie diese in ihrem Neighbor-Cache speichert (dürfte allerdings nur ein paar Sekunden sein), kann IPv6-Kommunikation erfolgen. Das könnte man per Dauer-Ping bei gleichzeitigem Langzeit-Paketmitschnitt (~ 2 Stunden) , der ein paar erhaltene RA umfasst, evtl. verifizieren. Zur Ansicht in Wireshark den Filter "icmpv6" setzen.

Nachtrag 2:

Gemäß deinem ersten Mitschnitt empfängst du etwa alle 30 Minuten einen RA (die Router-Lifetime im RA ist mit 4500s recht lang, deshalb auch die großen RA-Zeitabstände). Auch ohne Paketmitschnitt: Wenn Du mal einen IPv6-Dauerping machst, könnte es sein, dass du etwa alle 30 Minuten für ein paar Sekunden Antworten bekommst, wenn meine Annahme zutreffend ist.

"

Deine Datei zeigt Ping-Antworten, z.B. im Zeit-Intervall: 2025-08-12 15:51:59 - 2025-08-12 15:54:55, also für 176 Sekunden - solange hat die Fritzbox vermutlich die MAC-Adresse 20:00:00:00:20:38 der DG-Gegenstelle im Neigbor-Cache des WAN-Ports gespeichert, kurz zuvor hat sie diese wohl über ein von DG erhaltenes RA gelernt. Ich vermute, der Zeitabstand zwischen Ping-Erfolgen entspricht dem Abstand zwischen zwei erhaltenen RA:

2025-08-12 15:51:59
2025-08-12 16:21:58
2025-08-12 16:51:58
2025-08-12 17:21:57
:

Kommt ganz gut hin: RA-Empfang so etwa alle 30 Minuten.

Noch ein Nachtrag:

Ich ergänze nochmal folgenden Auszug aus #372:

"Deine Paketmitschnitte zeigten, dass dein Router outbound keinerlei IPv6-Pakete mit globalen IPv6-Zieladressen senden kann, weil die MAC-Adressauflösung (per NS/NA) der DG-Defaultgateway-Adresse (fe80::22) scheitert: Dein Router sendet ständig NS an die zu fe80::22 gehörende SNMA = ff02::1:ff00:22 ("solicited node mulitcast addess"), die von der Gegenstelle jedoch nicht per NA beantwortet werden. Ausgehende IPv6-Pakete können deshalb nicht in Ethernet-Frames eingepackt werden - dein Router muss sie verwerfen."

Somit hast du nun eine schlüssige Diagnose, die du mit einem deiner Paketmitschnitte (derjenige, der die vielen NS an ff02::1:ff00:22 zeigt, die von der DG-Gegenstelle nicht beantwortet werden) und deiner Textdatei mit dem Ping-Log technisch belegen kannst.

Schön wäre noch ein langer Paketmitschnitt (~2h) am WAN-Port, der die erfolgreichen Pings, die kurz zuvor erhaltenen RA und die dazwischen liegenden NS an ff02::1:ff00:22 bei entsprechender Filtersicht (icmpv6) zeigt.

Zitat von neisbe

... die in #1 -#3 erläuterten Verfahren nicht mehr funktionieren.

Der Link aus #3 (https://www.telekom.de/hilfe/apps-die…dresse-behalten) führt auf eine Telekom-Hilfeseite mit dem Hinweis "In den ersten 150 Tagen nach der Kündigung können Sie über die Seite "Wechsel auf Freemail" Ihre E-Mail-Adresse selbst umstellen." Der enthaltene Link führt dich dann zum Login deines Telekom-Kundencenters, wo du den "Wechsel auf Freemail" beauftragen können solltest (ich kann's nur halt nicht mehr verifizieren, weil ich nach meiner Umstellung nun in meinem Freemail-Kundencenter lande, wo mir die Meldung "Die Vertragsumstellung ist nicht mehr möglich" und weiterer Erklärungstext angezeigt wird).

neisbe :

Du könntest dich ja hier erst Mal bei Freemail registrieren und eine noch freie E-Mail-Adresse anlegen.

Dann gehst du in die Mail-Verwaltung deines noch bestehenden Telekom-Vertrags, legst dort einen Mail-Alias an und wandelst diesen in die Hauptadresse des Kontos um. Dadurch wird deine bisherige Hauptadresse ihrerseits zum Alias.

Den gibst du im Anschluss frei, und zwar mit sofortiger Wirkung (ohne Sperre!)

Jetzt wechselst du in deine Freemail-Verwaltung und legst dort die eben freigegebene Adresse sofort als Alias wieder an. Anschließend machst du sie zur Hauptadresse deines Freemail-Kontos, wodurch die bisher dort definierte Adresse zum Alias wird - den kannst du dann auch ggf. löschen.

Im Endeffekt hättest du so deine bestehende T-Online-Adresse aus dem alten Vertrag herausgelöst und in eine Freemail-Adresse umgewandelt.

Das war die Alternativ-Variante, die ich mir seinerzeit überlegt hatte, bevor ich die elegantere Methode gemäß #3 entdeckte.

Zitat von Luki

Das Problem ist, dass man auf dem FB die IPv6 (Präfix) Adresse schon sieht, nur die Anfragen von FB gehen ins Nirvana, aber DG wäscht ihren Händen mit dem "eigenen" Router Entschuldigung.

Das Problem ist, es DG zu beweisen.

Deine Paketmitschnitte zeigten, dass dein Router outbound keinerlei IPv6-Pakete mit globalen IPv6-Zieladressen senden kann, weil die MAC-Adressauflösung (per NS/NA) der DG-Defaultgateway-Adresse (fe80::22) scheitert: Dein Router sendet ständig NS an die zu fe80::22 gehörende SNMA = ff02::1:ff00:22 ("solicited node mulitcast addess"), die von der Gegenstelle jedoch nicht per NA beantwortet werden. Ausgehende IPv6-Pakete können deshalb nicht in Ethernet-Frames eingepackt werden - dein Router muss sie verwerfen.

Wenn du der DG so einen Paketmitschnitt schickst, wird der 1st-Level-Support damit allerdings nichts anfangen können, weil ... (such dir einen passenden Grund aus). Er diente vor allem dem Zweck, dass du dir sicher sein kannst, dass das Problem nicht bei deinem Router liegt.

DG muss das leisten, was in seiner Leistungsbeschreibung steht, siehe insbesondere 5.2:

Zitat

Deutsche Glasfaser richtet einen Internet-Zugang mit IPv6 IP-Ad-
ressen ein. Für IPv4 stellt Deutsche Glasfaser eine private Netz-
werkadresse bereit die von Carrier Grade Network Address Trans-
lation (CGN) auf eine öffentliche Adresse umgeschrieben wird. ...

Zitat von Phino

Ich meinte die Kombi aus Mobil IP (RFC 6275) und IPSec.

Achso - ja, da gebe ich dir Recht! Es gibt im IPv6-Bereich einige Fehlentwicklungen, die sich ein der Praxis nicht durchgesetzt haben. Mobile IPv6 scheint dazuzugehören, weshalb ich mich auch nie näher damit befasst habe.

Andere Fehlentwicklungen sind bspw. SeND und CGA - aber vielleicht wird das in den Netzen von Geheimdiensten verwendet - ich habe so etwas in freier Wildbahn jedenfalls noch nie gesehen.

Zitat von pufferueberlauf

O2 macht IPv4 via PPPoE und dann IPv6 ueber DHCPv6

Jo, liegt in der Natur der Sache: Das in PPP enthaltene NCP (Network Contol Protocol) kann nur im Falle von IPv4 (NCP = IPCP) auch eine globale IP-Adresse zuweisen, nicht jedoch im Fall von IPv6 (NCP = IPV6CP). Wozu IPV6CP gut ist, kann man hier nachlesen (in Kurzform: Es wird nur ein 64-Bit Interface-Identifer ausgehandelt, mit dem der Router dann seine eine linklokale fe80-Adresse am WAN-Port bildet).

Für die dynamische Zuweisung einer IPv6-GUA am WAN-Port des Heim-Routers braucht es dort also entweder SLAAC oder DHCPv6. Ein IPv6-Präfix für's LAN geht dynamisch ohnehin nur via DHCPv6-PD. Da man um DHCPv6 also nicht herumkommt, wird man naheliegenderweise also auch den WAN-Port per DHCPv6 mit einer IPv6-GUA beglücken, beides kann man innerhalb desselben DHCPv6-Requests durch Anforderung von IA_NA (WAN-Port) und IA_PD (LAN-Präfix) erledigen.

Zitat von pufferueberlauf

weshalb Firewalls wohl oft nur den RFC Bereich fc00::/6 fuer DHCPv6

Hä? Also fc00::/7 ist der Range für ULA, in der Praxis fd00::/8 (fc00::/8 ist "special"). Und ja, Home-Router, wie die Fritzbox, vergeben zusätzlich zum LAN-Präfix des ISP noch ULA-Adressen (per DHCPv6 oder eher SLAAC), die dann sogar bevorzugt für die LAN-interne Kommunikation genutzt werden und auch dann noch funktionieren, wenn der IPv6-Internetzugang und damit das LAN-Präfix des ISP wegbricht.

Zitat von pufferueberlauf

Anfang des Jahres als die DHCP Antwort von Prefix 0:80fe:: kam statt des erwarteten Prefix fe80:: *

Also "fe80::*" wird niemals via DHCPv6 angeboten.

Zitat von Phino

Beispiel: Ein für Firmen/Universitäten möglicherweise interessante Teil ist, dass man mit einer IPv6 Adresse aus seinem "Heimat"-Netz überall in der Welt sich in anderen IPv6-Netzen anmelden kann und damit automatisch ein verschlüsselter Tunnel ins heimische Netz aufgebaut wird, ohne weiteres dazutun, ist ja Teil des Protokolls.

Ähm - nein. Ich weiß nicht genau, wovon du bei "automatisch ein verschlüsselter Tunnel" sprichst, ich vermute du meinst IPsec-im Transport Modus. Das ginge im Übrigen prinzipiell auch mit IPv4, allerdings nicht " überall in der Welt", denn leider haben wir mit IPv4 ja kein Ende-zu-Ende.

Der Unterschied bzgl. IPsec ist hier: Bei IPv4 war IPsec nur ein optionales Addendum. Bei IPv6 ist es integraler Bestandteil der Protokoll-Definition. Die Funktionsweise von IPsec ist für beide Protokolle gleich.

Aber ich gebe dir Recht: IPsec im Transport-Modus ist "mal nicht eben einfach so" und schon gar nicht automatisch verfügbar. Man muss hier nämlich u.a. was für die gegenseitige Authentisierung der IPsec-Peers tun, und das bedeutet einigen Aufwand (unabhängig davon, ob man das für IPv4 oder IPv6 umsetzen will). Will man hier nicht "pre shared key" verwenden, gilt es, stattdessen zertifikats-basiert zu arbeiten und dafür (zumindest Unternehmens-intern) eine PKI-Struktur zu betreiben.

Generell:

IPv6 macht funktional genau dasselbe wie IPv4, nur mit verbesserten Möglichkeiten. Bei einigen Dingen, wie bspw. dynamischer Adress-Konfiguration (SLAAC gibt es bei IPv4 nicht, DHCPv6 arbeitet anders als DHCPv4, Adresszuweisungsmethoden sind bei IPv6 additiv, bei IPv4 "one of", die Existenz mehrerer IP-Adressen auf einem Netz-Interface ist bei IPv4 zumindest unüblich, temporäre IP-Adressen gibt es bei IPv4 nicht, ...) muss man halt umdenken - viele machen hier den Fehler, ihr IPv4-Wissen 1 zu 1 auf IPv6 zu übertragen und beklagen sich im Falle des Scheiterns über dessen "Komplexität".

Nachtrag zu Unterhaltung: Hier trifft "alte IPv4-Denke" auf IPv6:

Zitat von mbo77

Eingehende Verbindungen sind ebenfalls auf IPv6 angewiesen, da man nur eine private Adresse bei DG erhält.

Das machen doch nur ein paar Freaks, die sich dann in Foren wie bspw. diesem hier miteinander unterhalten. Und ISP-seitig sieht man das an Privat-Anschlüssen auch nicht so gerne, möchte man das doch lieber den hochpreisigen Business-Anschlüssen vorbehalten.

Die große Mehrheit will doch bloß Videos streamen, Social Media nutzen und online shoppen - und denen ist auch egal, ob das via IPv4 oder IPv6 (IP was ...?) erfolgt, dafür hat sie ohnehin keine Awareness.

Zitat von mbo77

Was wäre, wenn IPv6-only Dienste gäbe?

Davon sind wir zumindest in Deutschland noch einigermaßen weit entfernt:

Den zwar aktuell etwa 75% IPv6-sprechenden Clients (Link) steht service-seitig nur ein ziemlicher Flickenteppich IPv6-fähiger Web-Services (Auswahl aus Alexa-Liste) gegenüber (Link). Ein deutscher IPv6-only-Dienst wäre aktuell für 25% der deutschen Nutzer nicht erreichbar, das kann sich kein Dienste-Anbieter leisten.

Auf der Internationalen Bühne haben wir gar nur etwa 45% IPv6-sprechender Clients (Link) - ein IPv6-only-Dienst wäre folglich für 55% der Internet-nutzenden Weltbevölkerung nicht erreichbar.

Zitat von olifre

Aktuell hoffe ich einfach, dass die Routing-Regeln gesetzt aber nicht aktiv geschaltet haben und das bei der nächsten Wartung in der Region passiert, bei Einigen scheint eine solche Problematik ja nach einer Wartung der DG verschwunden zu sein.

Das ist wahrscheinlich die nerven-schonendste Variante - glücklicherweise kommt man als reiner Internet-Konsument noch ohne IPv6 aus, ohne IPv4 wäre es umgekehrt allerdings eine Katastrophe.

Problematisch ist allerdings die Situation für deine LAN-Clients, denn die gehen von einem funktionierenden IPv6 aus.

Schau dir dazu mal die Ergebnisse dieser Seite an: http://he.test-ipv6.com/

Ich würde empfehlen, die IPv6-Unterstützung der Fritzbox vorerst abzuschalten. Du kannst sie ja ab und zu aktivieren, um zu testen, ob es irgendwann funktioniert.

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.

Was auch sehr interessant ist:

Der folgende Screenshot stammt aus einem Paketmitschnitt, der irrtümlich am LAN-Port der Fritzbox aufgezeichnet wurde:

Man sieht hier in den LAN-RA der Fritzbox, dass diese zwei GUAs (2a00:6020:bb40:f00::/64 und 2a00:6020:bb40:1000::/64) mit unterschiedlichen Lifetimes (1h, 0.5h) announced, die aus unterschiedlichen PD-Blöcken (2a00:6020:bb40:f00::/56 und 2a00:6020:bb40:1000::/56) stammen.

Sieht irgendwie kaputt aus.

Eine weitere Auffälligkeit sehe ich in den folgenden "ICMPv6 Destination Unreachables", die die FB an den LAN-Client 2a00:6020:bb40:1000:50f4:7e02:b8ec:2a73 sendet:

Das aus meiner Sicht Merkwürdige ist die Quelladresse der ICMPv6 Destination Unreachables: Diese kommen von der WAN-Adresse der Box und nicht von deren LAN-Adresse, wie ich es erwarten würde. Aber gut, muss nichts heißen.

Die per DHCPv6 von DG zugewiesenen IPv6-Adressen scheinen auch öfter zu wechseln:

LAN: 2a00:6020:bb40:f00::/56 + WAN: 2a00:6020:bb00::6
LAN: 2a00:6020:bb40:1000::/56 + WAN: 2a00:6020:bb00::5
LAN: 2a00:6020:bb40:1300::/56 + WAN: 2a00:6020:bb00::?

Das scheint mir inzwischen auch ein relativ sicheres Indiz dafür zu sein, dass die DG-seitige IPv6-Konfiguration des Kundenanschlusses fehlerhaft ist.

Zitat von Leseratte10

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:

C:\>netsh int ipv6 sh addr

Interface 1: Loopback Pseudo-Interface 1

Addr Type  DAD State   Valid Life Pref. Life Address
---------  ----------- ---------- ---------- ------------------------
Other      Preferred     infinite   infinite ::1

Interface 10: Ethernet

Addr Type  DAD State   Valid Life Pref. Life Address
---------  ----------- ---------- ---------- ------------------------
Public     Preferred       50m54s     50m54s 2a00:6020:47XX:XXXX:692:26ff:feYY:YYYY
Temporary  Preferred       50m54s     50m54s 2a00:6020:47XX:XXXX:6010:f5db:c80a:f8ae
Public     Preferred     1h59m40s     59m40s fd0d:cf1e:63ee:0:692:26ff:feYY:YYYY
Temporary  Preferred     1h59m40s     59m40s fd0d:cf1e:63ee:0:6010:f5db:c80a:f8ae
Other      Preferred     infinite   infinite fe80::692:26ff:feYY:YYYY%10

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.

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.

Zitat von Leseratte10

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.

Ich habe mir nochmal die DHCPv4- und DHCPv6-Transaktionen angeschaut. Die sind insofern beide ungewöhnlich, als sich Dein Nokia-ONT aktiv dazwischen zu hängen scheint:

DHCPv4:

Auffällig hier: DHCP ACKs kommen vom Nokia-ONT (MAC-Adresse 80:b9:46:f0:0d:32) mit dem DHCP Server Identifier 192.168.101.1. Hier sollten eigentlich MAC-Adresse und Server-Identifier des DHCPv4-Servers der DG direkt drin stehen.

DHCPv6:

Auffällig hier: Die Transaktionen folgen dem Muster "Renew Reply Request Reply" mit folgender Besonderheit:

• In beiden Replies entspricht der Server Identifier dem Nokia-ONT und nicht dem DHCPv6-Server der DG
• Der erste Reply ist nicht erfolgreich, Status: "NoBinding" - erst mit dem zweiten Request wird die Lease neu zugeteilt.

Normalerweise wird ein DHCPv6-Renew unmittelbar vom DHCPv6-Server der DG mit einem Reply verlängert.

Tja, tut mir leid, aber in deinem Paket-Mitschnitt sieht man keinen einzigen Ping, der ausgehend vom WAN-Port der Fritzbox Richtung Internet weitergeleitet würde.

Aus dem RA, den die Fritzbox von der DG-Gegenstelle empfängt (habe im letzten Mitschnitt allerdings keines mehr gesehen), lernt die Fritzbox das IPv6-Standardgateway der DG: fe80::22. Aus der "Source link-layer address"-Option im RA lernt sie auch dessen zugehörige MAC-Adresse: 20:00:00:00:20:38. Die scheint sie jedoch nicht im IPv6-Neighbor-Cache des WAN-Ports zu speichern, oder eben nur für kurze Zeit, denn dein Mitschnitt zeigt, dass die Fritzbox permanent versucht, die zum Gateway fe80::22 gehörige MAC-Adresse per "Neigbor Solicitations" an die SNMA-Adresse des Gateways (abgeleitet aus fe80:22 --> SNMA = ff02::1:ff00:22) zu ermitteln. Leider kommt von der DG-Gegenstelle keine Antwort: Es müsste ein Neigbor-Advertisement (NA) zurückkommen, in dem die MAC-Adresse 20:00:00:00:20:38 mitgeteilt wird. In der Folge werden alle deine ausgehenden IPv6-Pakete in der Warteschlange deiner Fritzbox gedropt, da sie diese wegen fehlender MAC-Adresse der DG-Gegenstelle nicht in Ethernet-Frames einpacken und losschicken kann.

Es sieht so aus, als hätte die DG-Gegenstelle die zu ihrer IPv6-Adresse fe80::22 gehörende SNMA-Adresse ff02::1:ff00:22 nicht registriert (per Multicast-Join), deshalb reagiert sie nicht auf die NS-Requests deiner Fritzbox zur MAC-Adressauflösung.

Ist aus meiner Sicht ein Beleg, dass auf der DG-Gegenseite keine korrekte Interface-Konfiguration vorliegt.

Folgende Merkwürdigkeit ist mir außerdem noch aufgefallen:

Dein Nokia-ONT (so deutet es zumindest Wireshark aufgrund dessen MAC-Adresse 80:b9:46:f0:0d:32 = Nokia_f0:0d:32) fragt per ARP-Unicast anstelle der DG-Gegenstelle nach der MAC-Adresse, die zur IPv4-WAN-Port-Adresse (100.104.176.193) deiner Fritzbox gehört. Das ist nach meinem Verständnis ungewöhnlich: Der ONT sollte nach meinem Verständnis völlig unsichtbar sein! ARP-Requests sollten ausschließlich von der DG-Gegenstelle kommen.

Vielleicht würde tatsächlich mal ein ONT-Reset helfen.

Noch ein Nachtrag:

Zumindest für kurze Zeit scheint dein IPv6-Access (inbound + outbound) zu funktionieren. Ich vermute immer dann, wenn deine Fritzbox einen RA von der DG-Gegenstelle erhält und daraus die MAC-Adresse 20:00:00:00:20:38 der Gegenstelle lernt. Solange sie diese in ihrem Neighbor-Cache speichert (dürfte allerdings nur ein paar Sekunden sein), kann IPv6-Kommunikation erfolgen. Das könnte man per Dauer-Ping bei gleichzeitigem Langzeit-Paketmitschnitt (~ 2 Stunden) , der ein paar erhaltene RA umfasst, evtl. verifizieren. Zur Ansicht in Wireshark den Filter "icmpv6" setzen.

Nachtrag 2:

Gemäß deinem ersten Mitschnitt empfängst du etwa alle 30 Minuten einen RA (die Router-Lifetime im RA ist mit 4500s recht lang, deshalb auch die großen RA-Zeitabstände). Auch ohne Paketmitschnitt: Wenn Du mal einen IPv6-Dauerping machst, könnte es sein, dass du etwa alle 30 Minuten für ein paar Sekunden Antworten bekommst, wenn meine Annahme zutreffend ist.