Mal wieder: Kein IPv6 bei Deutsche Glasfaser

hier beide Dateien archiviert in einer ZiP Datei

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

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

::1,

da ist die Datei

Zitat

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

Das ist verdächtig, damit will mich jetzt aber nicht beschäftigen, viel dringender ist Raspberry über IPv6 zu erreichen, da DG CGNAT benutzt und damit keine IPv4 DNS-Einträge funktionieren, darum soll ich die Raspberry über IPv6 konfigurieren. Das soll die Vaultwarden Datenbank (und die komplette Anwendung) sein.

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?

Das ist was ich ausgewellt habe.

Ich mache das noch einmal.

In dem Mitschnitt sind auch keine Ping Pakete.

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 ::1

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.

Das ist für mich beispielsweise ein Grund, auf Provider ONT komplett zu verzichten. Der soll nur als Medienwandler/Bridge arbeiten. Und sonst überhaupt nichts ...

Danke für Deine Zeit und Effort, ::1!

Zitat von Schnurz

Das ist für mich beispielsweise ein Grund, auf Provider ONT komplett zu verzichten. Der soll nur als Medienwandler/Bridge arbeiten. Und sonst überhaupt nichts ...

ONT ist nicht in Anwendung, ich habe den Router gerade auf Werkseinstellungen zurückgesetzt und nach Anweisungen neu eingerichtet für DG über GPON SFP. Was ich zusätzlich getestet habe ist, IPv4 Adapter auszuschalten und dadurch ist kein Internet mehr verfügbar: die WEB-Seite "ipv6.google.com" ist weder bei Namen, noch bei IP [2a00:1450:4001:831::200e] erreichbar.

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.

Welche Schlussfolgen bring dies mit - ?

Fritzbox wurde mit 2 SFPs geliefert - GPON und AON.

Nach Internetrecherche habe ich den GPON angeschlossen und das "Power" LED leuchtete dauerhaft, was für eine Kompatibilität spricht.

hier den Absatz aus der AVM-Seite:

"Falls Sie nicht wissen, um was für einen Glasfaseranschluss es sich handelt, testen Sie die SFP-Module aus dem Lieferumfang Ihrer FRITZ!Box nacheinander. Die Power/Internet-LED der FRITZ!Box leuchtet durchgehend, sobald die FRITZ!Box mit dem richtigen SFP-Modul mit dem Glasfaseranschluss verbunden wurde"

soll ich den GPON mit AON ersetzen oder einen weiteren GPON kaufen?

Mach doch mal Fotos von dem Anschluss und wie er mit der Firtzbox verbunden ist.

Hast du den ONT mal resettet, wie empfohlen?

Zitat von frank_m

Hast du den ONT mal resettet, wie empfohlen?

Ich nutze das integrierte Glasfasermodul der FRITZ!Box, also habe ich keinen externen ONT.

FritzBox habe ich, wie oben geschrieben, zurück auf Werkseinstellungen gebracht und neu konfiguriert.

Zitat von bgers

Mach doch mal Fotos von dem Anschluss und wie er mit der Firtzbox verbunden ist.

ONT ist SFP Modul ust ist in dem Fritzbox eingesteckt wie auf der angehängten Grafik dargestellt angeschlossen.

Bilder sind bei sowas immer hilfreich, auch vom ONT, auch screenshots der Einstellungen....

Zitat von Luki

Ich nutze das integrierte Glasfasermodul der FRITZ!Box, also habe ich keinen externen ONT.

Woher kommen dann die Nachrichten vom Nokia-ONT in deinen Traces?