Beiträge von ::1

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.

Zitat von Luki

da ist die Datei

Hm, du scheinst den Trace für die falsche Schnittstelle in der Fritzbox durchgeführt zu haben, ich sehe jedenfalls nur LAN-internen Traffic.

Du musst den Trace für die Schnittstelle "1. Internetverbindung" (erster Eintrag) durchführen.

Kannst du das bitte nochmal machen?

Nur mal auf die Schnelle: Ich sehe in den Paket-Mitschnitten nicht, dass du tatsächlich ein "Neu verbinden" durchgeführt hast (es fehlen entsprechende "DHCP-Releases"), macht jetzt aber nichts, dafür sieht man DHCP-Renews - da sehe ich keine Auffälligkeiten.

Auch RA kommen von der DG ordentlich.

Ich sehe aber keine Test-Pings zu externen Zielen, z.B. Google.

Kannst du bitte nochmal einen Paket-Mitschnitt (ohne "Neu verbinden") machen, während du am Windows-PC in mehreren Powershells einen Dauerping auf einige Ziele durchführst?

ping -6 -t google.com.
ping -6 -t facebook.com. 
ping -6 -t wikipedia.org.

Ich sehe nur ein interessantes Paket nach außen: Die Fritzbox sendet von ihrer WAN-Adresse 2a00:6020:bb00::6 ein ICMPv6 Destination unreachable an 2a06:4880:2000::32, offenbar nachdem diese externe Adresse versucht hat, deine LAN-Adresse 2a00:6020:bb40:f00:9209:d0ff:fe02:b03a aus dem Internet zu kontaktieren (dieses Inbound-Paket ist allerdings aufgrund der Filteransicht nicht zu sehen, war sicherlich ein TCP-Connect-Versuch von außen, den die Fritzbox geblockt hat).

Nachtrag: Der Connect-Versuch von außen war ein TCP-Connect (SYN) 2a06:4880:2000::32 -> [2a00:6020:bb40:f00:9209:d0ff:fe02:b03a]:30555

Das Ziel deutet auf eine Synology-NAS-Box in deinem LAN hin. Zur Quelladresse siehe https://apps.db.ripe.net/db-web-ui/quer…:32&source=RIPE

Zitat von Luki

O, man, jetzt sagt mir der Forum, .pcap ist eine ungültige Dateiendung.

Was soll ich machen? Dateien archivieren?

Packe sie in eine ZIP-Datei

Zitat von Luki

Was soll ich jetzt mit der Datei tun um testen zu können, ob die IPv6 Anfragen aus LAN-Geräten richtig durch den FB geführt sind?

Es ist zwar offensichtlich, dass bei "neu verbinden", das Interface für kürzere Zeit IPv6 Anfragen richtig empfängt, aber einen NAchweiß, sowohl f+r AVM, als auch für DG ein Versuchswert ist.

Was du tun solltest, habe ich in #268 beschrieben. Insbesondere:

Am Ende wäre es schön, wenn du die Anzeige deines Paketmitschnitts in Wireshark in der Filtersicht icmpv6 || dhcpv6 hier im Forum zur weiteren Analyse posten würdest.

Da kann ich erst mal sehen, was genau abläuft. Der Nachweis, dass das Problem bei DG liegt, wäre z.B.

• Du erhältst keine valides RA von der DG -> Es fehlt dann ein IPv6-Default-Gateway und deine Fritzbox könnte keinen IPv6-Traffic raussenden.
• Du hast ein IPv6-Defaultgateway und siehst auch, dass IPv6-Pakete (ping zu Google als Test) rausgehen, diese bleiben aber unbeantwortet.
• ...

Luki :

Nochmal zum Scheitern des Paketmitschnitts in der Fritzbox (siehe auch #271) :

Ich vermute, es liegt daran, dass die TCP-Connection zwischen Fritzbox und deinem Windows-PC zum Speichern der Mitschnitt-Datei über IPv6 erfolgt (und zwar mit der DG-GUA 2a00:6020:...). Die bricht natürlich in dem Moment weg, wo du in der Fritzbox auf "Neu verbinden" klickst.

Deshalb muss dafür gesorgt werden, dass die TCP-Connection zwischen Fritzbox und deinem Windows-PC zum Speichern der Mitschnitt-Datei über IPv4 erfolgt. In #271 habe ich dafür eine Lösung aufgezeigt (Modifikation der HOSTS-Datei am Windows-PC).

Es würde m.E. aber auch einfach ausreichen, wenn du die Fritzbox im Browser über ihre IPv4-Adresse ansprichst (Zertifikatsfehler ignorieren): https://192.168.178.1

Einen Versuch wäre es nochmal wert.

Zitat von Luki

Die Message ist zu lang für den Chat, deswegen habe ich jede Meldung nur einmal erscheinen, ist aber merkwürdig, da die Verbindung für 1-3 Minuten an war und ich konnte die IPv6 Adresse im Internet anpingen. Danach ist es wieder verschwunden.

Ja, genau so einen Effekt (geht - geht nicht - geht - geht nicht ...) und das im Rhythmus von DHCPv6-Renews hatten wir hier auch schon beobachtet.

Wie gesagt, ein Paketmitschnitt wäre Gold wert.

Zitat von Luki

Leider ohne Erfolg - egal wie, die Datei lässt sich nicht vernünftig speichern.

Hast Du's mal mit der modifizierten HOSTS-Datei gemäß #271 versucht?

Zitat

das sage ich ja: Ich habe die Option wie angewiesen geändert und den Adapter neu initialisiert.

Ok, sorry - hatte den Bezug zu meinem Post nicht erkannt, zumal du auch keine Daten zur Fritzbox gezeigt hast.

WAN 2a00:6020:bb00::/64 - wie von mir vorher gesagt, hast du nun tatsächlich eine andere WAN-Adresse aus 2a00:6020:bb00::/112 bekommen. So sollte es sein.

Aber damit kommst du immer noch nicht per IPv6 ins Internet?

Ansonsten zu deinen IPv6-Einstellungen in der Fritzbox:

• Du solltest am DG-Anschluss die Einstellung "Native IPv4-Anbindung" verwenden - bitte umstellen. Das ändert nur die Reihenfolge der Adresszuweisung: Erst IPv4, dann IPv6. Das geht bei DG erfahrungsgemäß schneller als andersherum (wie es mit "Native IPv6-Anbindung" der Fall ist)
• Du vergibst IPv6-Adressen an die LAN-Clients per DHCPv6 (DNS-Server, Präfix (IA_PD) und IPv6-Adresse (IA_NA) zuweisen). Das ist zwar möglich, aber standardmäßig würde man SLAAC verwenden. Das kannst du durch Auswahl von "Nur DNS-Server zuweisen" oder ggf. auch "DNS-Server und IPv6-Präfix (IA_PD) zuweisen" (falls du im LAN nachgelagerte Router hast, die du mit IPv6 per PD beglücken willst) ändern. Würde ich tatsächlich umstellen. Ist aber deine Entscheidung und wird dein IPv6-Verbindungsproblem mit dem Internet auch nicht lösen.

Falls also dein Problem immer noch besteht, versuch es bitte nochmal mit dem Paketmitschnitt gemäß #268 und beachte zuvor meine Punkte aus #271.

Würdest du deine Aufmerksamkeit bitte diesem Punkt zuwenden:

Hier liegt die Krux: Deaktiviere in der Fritzbox bitte mal die Option "Globale Adresse aus dem zugewiesenen Präfix ableiten". Wähle stattdessen "Globale Adresse automatisch aushandeln"

Zitat von Luki

verbunden seit 02.08.2025, 00:43 Uhr, Deutsche Glasfaser
IPv6-Adresse: 2a00:6020:bb40:900::1/64, Gültigkeit: 2468/2468s
IPv6-Präfix: 2a00:6020:bb40:900::/56, Gültigkeit: 2468/2468s

Hier liegt die Krux: Deaktiviere in der Fritzbox bitte mal die Option "Globale Adresse aus dem zugewiesenen Präfix ableiten". Wähle stattdessen "Globale Adresse automatisch aushandeln"

Du solltest danach am WAN-Port anstelle der aktuellen Adresse 2a00:6020:bb40:900::1 eine IPv6-Adresse aus 2a00:6020:bb00::/112 sehen, so meine diesbezüglichen Erfahrungen auch hier ihre Anwendung finden.

Zitat von Luki

Connection-specific DNS Suffix . : fritz.box
IPv6 Address. . . . . . . . . . . : 2a00:6020:bb40:901:2f63:ead8:9116:7842
IPv6 Address. . . . . . . . . . . : 2a00:6020:bb40:901:97e9:345d:3d8f:9d22

Das ist jetzt auch schon wieder "komisch": Woher kommen denn zwei "non-temporary" IPv6-Adressen auf demselben Adapter?