Deutsche Glasfaser: Keine IPv6-Adresse

Formal sieht das gut aus!

Allerdings scheinst du mit jedem Reconnect neue IPv6-Adressen zu bekommen - nach bisherigen Erfahrungen ist das kein gutes Zeichen!

Mach bitte mal Folgendes:

• Starte einen Paketmitschnitt am WAN-Port deiner FB
• Führe an einem deiner PC im LAN folgende PING-Tests aus:
  - ping -6 google.com
  - ping -6 facebook.com
  - ping -6 wikipedia.org
• Stoppe den Paketmitschnitt und poste hier dessen Ergebnis mit dem Ansichtsfilter "icmpv6"

Ich erwarte, dass im Mitschnitt nur ausgehende Pings zu sehen sind, jedoch keine Antworten.

Die Ausgabe bleibt bei allen drei pings stets gleich:

"Ping wird ausgeführt für google.com [2a00:1450:4001:810::200e] mit 32 Bytes Daten:
Zielhost nicht erreichbar.
Zeitüberschreitung der Anforderung.
Zielhost nicht erreichbar.
Zeitüberschreitung der Anforderung.

Ping-Statistik für 2a00:1450:4001:810::200e:
Pakete: Gesendet = 4, Empfangen = 0, Verloren = 4
(100% Verlust)"

Okay, der Mitschnitt zeigt leider nicht, wie erhofft, die ausgehenden Pings (das wären ICMPv6-Pakete des Typs 128 (echo), Wireshark-Filter icmpv6.type==128). Das liegt vermutlich daran, dass deine FB diese Pings nicht Richtung DG senden kann, weil ihr dazu die MAC-Adresse der DG-Gegenstelle fehlt - die braucht sie als Ethernet-Zieladresse für die ausgehenden Ping-Pakete. Stattdessen sieht man nur, wie deine FB ständig NS (Neighbor Solicitation) an die Gegenstelle sendet (genauer: an die aus deren Adresse fe80::22 abgeleitete SNMA-Adresse ff02::1:ff00:22), um eben genau diese fehlende MAC-Adresse der Gegenstelle aufzulösen. Leider antwortet die Gegenstelle nicht mit einem NA (Neighbor Advertisement).

Nach einer Neuverbindung deiner FB mit dem Internet hat sie diese MAC-Adresse aus den erhaltenen RA noch für etwa 2 Minuten in einem Cache. Wenn du innerhalb dieser Zeitspanne nach einer Neuverbindung diese Pingtests durchführst, dürftest du in einem Paketmitschitt diese ausgehenden Pings (als ICMPv6-Pakete des Typs 128) noch sehen - müsstest nur schnell genug sein. Beantwortet würden sie allerdings vermutlich nicht, so dass die Pings auch hier fehlschlagen würden.

Danke für die Erläuterung! Das mit dem Paketmitschnitt bekomme ich jetzt nicht mehr hin. Im Zusammenhang mit der Neuverbindung erzeugt die FB entweder eine eth-Datei oder eine eth.part mit 0 Bytes oder eine kleine Datei mit paar Hundert Bytes, die als offener Download hängen bleibt, x-fach probiert. Ohne Neuverbindung ist die Erzeugung der eth kein Problem. Es war gestern schon so, dass es mit einer Neuverbindung "dazwischen" höchstens jede 10. mal funktioniert.
Gibt es denn anhand der bislang verfügbaren Mitschnitte eine Idee, weswegen es mit IPv6 nicht funktionieren will?

Möglicherweise hast du vergessen auf der FB-Seite die Stopptaste zu drücken?

So, jetzt den Mitschnitt unmittelbar nach Neuverbindung gestartet.

Zitat von Phino

Möglicherweise hast du vergessen auf der FB-Seite die Stopptaste zu drücken?

Nein, immer gemacht. Es hängt definitiv mit der Neuverbindung während des Mitschnitts zusammen.

Ruf die Paketmitschnitt-Seite deiner Fritzbox bitte mal über ihre IPv4-Adresse auf:

http://192.168.178.1/html/capture.html (Adresse ggf. anpassen)

Dann sollte es mit dem Speichern der Capture-Datei unfallfrei klappen.

Mich würde die Sichtbarkeit der ausgehenden Pings im Mitschnitt in den ersten 2 Minuten nach einem Reconnect schon interessieren.

Ich denke, die Reihenfolge sollte wie folgt sein:

1. Starte an einem LAN-PC eine Eingabeaufforderung und setzte dort einen Dauerping auf Google ab: ping -6 -t google.com. . Starte optionial pro weiterem Ziel (z.B. facebook.com) jeweils eine weitere Eingabeaufforderung, um dort einen analogen Dauerping abzusetzen.
2. Starte den Paketmitschnitt http://192.168.178.1/html/capture.html (Adresse ggf. anpassen)
3. Führe in der Fritzbox (zweite Anmeldung in einem separaten Browser-Fenster: http://192.168.178.1 ) einen Reconnect ("Neu verbinden") durch.
4. Lass den Paketmitschnitt etwa 5 Minuten laufen.

Zeige das Wireshark-Ergebnis mit dem Ansichtsfilter icmpv6

Ja, das Speichern der Datei auf dem LAN-Rechner bricht ab, wenn die Verbindung zwischen Windows-PC und FB über IPv6 erfolgt. Mit Auslösen von "Neu verbinden" zieht man sich quasi die IPv6-Verbindung selbst weg (Absägen des Astes, auf dem man sitzt). Mit IPv4 kann das nicht passieren, da die RFC1918-Adressen bei einem Reconnect ja erhalten bleiben.

Aber dein letztes Wireshark-Bild zeigt nun ja das gewünschte Ergebnis ...

Bzw. mach doch nochmal das, was ich eben schrieb (Dauerping und 5 Minuten laufen lassen) - will sehen, ob so nach etwa 2 Minuten keine ausgehenden Ping-Versuche mehr im Mitschnitt zu sehen sind.

Ich schreibe nachher noch was zur Analyse ...

Zitat von JaFr

Gibt es denn anhand der bislang verfügbaren Mitschnitte eine Idee, weswegen es mit IPv6 nicht funktionieren will?

Eine Zwischenbilanz:

1. DG scheint den IPv6-Range (/56-PD-Block für das LAN, WAN-Adresse), den es deiner FB zuweist, nicht zu routen. Beleg dafür sind die IPv6-Pings, die deine FB von deinem LAN-PC über den WAN-Link zu DG routet, die aber sämtlich nicht beantwortet werden (Mitschnitt: no response found!).
2. DG weist dir keine festen IPv6-Adressen für WAN und LAN zu - diese ändern sich mit jedem Reconnect. Normalerweise sind die zugewiesenen IPv6-Adressen auch an Privatanschlüssen konstant (wenn auch nicht garantiert, erfahrungsgemäß aber über sehr lange Zeiträume). In allen, hier im Forum zu findenden Fällen mit gleichem Verhalten an DG-Anschlüssen gab es stets IPv6-Probleme. Insofern kann man im Umkehrschluss annehmen, dass mit jedem Reconnect wechselnde IPv6-Adressen mit hoher Wahrscheinlichkeit auf ein seitens DG nicht funktionierendes IPv6 hinweisen.
3. Der letzte Paketmitschnitt zeigt, dass von deiner FB gesendete NS (Neighbor Solicitations) an die Unicast-Adresse (fe80::22) der DG-Gegenstelle von dieser mit NA (Neigbor Advertisment) beantwortet werden. NS/NA via Unicast sind aber lediglich Bestätigungen dafür, dass die im Neigbor Cache der FB befindliche MAC-Adresse der DG-Gegenstelle (20:00:00:00:32:26) noch aktuell ist, denn andernfalls würden die NS per Unicast (also in Ethernet mit der MAC-Zieladresse 20:00:00:00:32:26 enkapsuliert) die DG-Gegenstelle gar nicht erreichen.
   
   Wird die MAC-Adresse im Neighbor Cache der FB nach kurzer Zeit der Inaktivität gelöscht, so kann sie anschließend durch Senden von NS an die aus der IPv6-Adressen fe80::22 abgeleitete SNMA ff02::1:ff00:22 der DG-Gegenstelle nicht mehr aufgelöst werden, weil die Gegenstelle diese NS nicht per NA beantwortet (vorletzter Paketmitschnitt). In der Folge kann kein IPv6-Paket mehr ausgehend über den WAN-Link zu DG gesendet werden.
4. Die dir zugewiesenen IPv6-Adressen liegen in einem der IPv6-Ranges, in denen DG ein gegenüber älteren Anschlüssen geändertes IPv6-Adressvergabe-Schema einführt (hier: /56-LAN-Präfix aus 2a00:6020:9480::/41, WAN-Adresse in 2a00:6020:9480::/112). Es wurden in diesem Forum schon viele IPv6-Problemfälle diskutiert, die ebenfalls in IPv6-Ranges mit "neuem" IPv6-Adressvergabe-Schema liegen. DG-seitig scheint da noch vieles "im Argen" zu liegen.

Vielen Dank für die ausführliche Analyse! Fragt sich nur, was ich mit der Diagnose anfangen kann, außer der DG kontinuierlich Störungsmeldungen zu schicken, in der Hoffnung , dass sich irgendwann irgendjemand von der DG erbarmt und es evtl. hinbekommt, den Fehler zu beheben?
Mit dem Aufruf der Fritzbox über die IPv4-Adresse funktionierte das Speichern der Capture-Datei. Anbei der gewünschte Paketmitschnitt mit dem Dauerping.

Ich schaue mir die letzten Paketmitschnitte heute abend nochmal an und ergänze/modifiziere ggf. noch die Fehlerdiagnose um weitere Erkenntnisse.

Das Verhalten der DG im Umgang mit solchen Fehlern ist ein anderes Thema, da kann sich jeder seinen Teil denken.
Du kannst allenfalls eine Frist zur Behebung setzen mit Androhung der Halbierung des Monatsbetrags (für das halbe Internet, das du bekommst) bis hin zur Kündigungsdrohung. Falls du aber keine Alternativen zur DG-Glasfaser hast, hast du die A....karte - DG weiß das sicherlich ganz genau.

Zitat von JaFr

Anbei der gewünschte Paketmitschnitt mit dem Dauerping.

Zitat von ::1

Ich schaue mir die letzten Paketmitschnitte heute abend nochmal an und ergänze/modifiziere ggf. noch die Fehlerdiagnose um weitere Erkenntnisse.

Die aktuellen Mitschnitte bringen keine wirklich neuen Erkenntnisse, bestätigen aber das bisherige Bild. Man kann noch herauslesen, dass sich die MAC-Adresse der DG-Gegenstelle (20:00:00:00:32:26) offenbar für etwa 40 Sekunden (siehe 13.) im Neighbor Cache für den WAN-Port der FB befindet:

1. Pakete 1404-1475:
   
   Die von der FB an die SNMA ff02::1:ff00:22 der DG-Gegenstelle (abgeleitet aus deren IPv6-Adresse fe80::22) gesendeten NS (Neighbor Solicitations) bleiben von der DG-Gegenstelle unbeantwortet (Fehler seitens DG). Die FB sendet die NS per Multicast an die SNMA der DG-Gegenstelle, weil sie zu diesen Zeitpunkten deren MAC-Adresse 20:00:00:00:32:26 nicht (mehr) kennt, da sie sich nicht mehr im Neighbor Cache für den WAN-Port der FB befindet.
   
2. Pakete 1490-1500:
   
   Von dir ausgelöster Reconnect der FB: Die FB autokonfiguriert sich ihre linklokale IPv6-Adresse fe80::e72:74ff:fec7:97e6 und führt für diese eine DAD (duplicate address detection) durch: Pakete 1490-1491. Anschließend sendet sie RS (Pakete 1492-1495) und MLD-Reports (Pakete 1499-1500). Soweit alles normal/korrekt.
   
3. Paket 1504:
   
   Bravo: Die DG-Gegenstelle sendet ein RA (wenigstens das - immerhin) als Antwort auf die von der FB gesendeten RS:
   
   Dies hat zwei Aspekte zur Folge:
   Die FB lernt daraus die IPv6-Adresse der DG-Gegenstelle als Standardgateway (fe80::22).
   Eine im RA enthaltene Option teilt der FB auch die zugehörige MAC-Adresse der DG-Gegenstelle (20:00:00:00:32:26) mit.
   Diese speichert die FB in ihrem Neighbor Cache (dort wird sie allerdings irgendwann gelöscht, wenn sie zwischendurch nicht von der DG-Gegenstelle bestätigt wird, z.B. weil die FB nicht aktiv per NS nachfragt, nachdem eine Weile kein ausgehender IPv6-Unicast Traffic mehr auftritt).
   
4. Paket 1840:
   
   Die FB hat jetzt alle Informationen, um das erste PINGv6-Paket zu senden: Sie verpackt das ausgehenden IPv6-Paket in einen Ethernet-Frame mit der Ethernet-Zieladresse 20:00:00:00:32:26 der DG-Gegenstelle, die sie aus ihrem Neighbor Cache auslesen kann.
   
5. Paket 2459-2460:
   
   Da die FB die MAC-Adresse der DG-Gegenstelle nur "als Beifang" aus dem RA erhalten hat, muss sie diese durch eine NS/NA-Transaktion verifizieren. Sie sendet die NS per Unicast an die IPv6-Adresse fe80::22 der DG-Gegenstelle (verpackt in einen Ethernet-Frame mit der Zieladresse 20:00:00:00:32:26 der DG-Gegenstelle). Die DG-Gegenstelle antwortet mit NA - ebenfalls per Unicast. Soweit normal.
   
6. Pakete 4312-33307:
   
   Die FB sendet weitere PINGv6-Pakete im Zeitabstand von 5 Sekunden. Alle PINGv6-Paket bleiben unbeantwortet. Die DG-Infrastruktur scheint entweder die ausgehenden PINGs nicht korrekt zum Ziel (hier: Facebook) oder aber die PING-Antworten vom Ping-Ziel nicht korrekt zurück zur FB zu routen (Fehler seitens DG).
   
7. Pakete 33308-41163:
   
   Weitere ausgehende Pings, die unbeantwortet bleiben - eingestreut immer wieder NS/NA-Transaktionen (vgl. 5) zur Bestätigung der MAC-Adresse der DG-Gegenstelle. Jede NA-Antwort setzt den Timeout für die Verweildauer des Neighbor Cache-Eintrags (fe80::22 -> 20:00:00:00:32:26) wieder auf ihren Maximalwert (müssten etwa 40 Sekunden sein, s.u.)
   
8. Pakete 41346-41347:
   
   NS/NA mal umgekehrt! Die DG-Gegenstelle fe80::22 möchte die zur globalen IPv6-Adresse deiner FB (2a00:6020:9480::86) gehörende MAC-Adresse deiner FB (0c:72:74:c7:97:e6) bestätigt bekommen. Einkommende NS per Unicast (Paket 41346) wird von der FB ordnungsgemäß mit einem NA per Unicast zurück an fe80::22 beantwortet (Paket 41347).
   
9. Pakete 41360-42528:
   
   wie 7.
   
10. Pakete 42529-42530:
    
    Letzte NS/NA-Transaktion, die von der DG-Gegenstelle beantwortet wird! Der Timeout für die Verweildauer der MAC-Adresse der DG-Gegenstelle im Neighbor Cache wird zum Zeitpunkt ~210s nochmal auf ihren Maximalwert gesetzt.
    
11. Pakete 42559-44549:
    
    Weitere ausgehende, aber unbeantwortete Pings.
    
12. Pakete 44550-44690:
    
    Interessant: Die FB sendet erneut mehrmals NS für fe80::22 zur Bestätigung der MAC-Adresse der Gegenstelle. Nun werden diese aber nicht von der der DG-Gegenstelle beantwortet (Fehler seitens DG)!
    
13. Pakete 44700ff:
    
    Zum Zeitpunkt ~250s (Paket 44700) scheint der Cache-Timeout (der sich aus der Differenz 250s - 210s (siehe 10.) zu ~40s ergibt) abgelaufen zu sein: Die MAC-Adresse 20:00:00:00:32:26 der DG-Gegenstelle befindet sich ab nun nicht mehr im Neighbor Cache. Die FB muss sie also durch Senden von NS an die SNMA ff02::1:ff00:22 der DG-Gegenstelle neu ermitteln. Aber wie schon in 1. festgestellt, beantwortet die DG-Gegenstelle NS, die an ihre SNMA gesendet werden, nicht.
    
    Da die FB nun nicht mehr über die Ziel-MAC-Adresse der DG-Gegenstelle verfügt, kann sie auch keine ausgehenden Pings mehr senden, da sie diese nicht mehr in Ethernet-Frames verpacken kann (es kann keine Ethernet-Zieladresse eingetragen werden). Deshalb sieht man im Mitschnitt auch keine ausgehenden Pings mehr.
    
    Der Mitschnitt endet im Nirwana mit nur noch ausgehenden NS an die SNMA der DG-Gegenstelle, die von dieser aber nicht beantwortet werden.
    

Fazit:

Zusammenfassend lassen sich folgende Fehler festhalten, für die allein DG verantwortlich ist:

• Es gelingt zwar, dem Router IPv6-Adressen zuzuweisen - diese wechseln jedoch mit jedem Reconnect. An DG-Privatanschlüssen sind die IPv6-Adressen quasistatisch (aber nicht garantiert), ein Wechsel der Adressen bei jedem Reconnect deutet erfahrungsgemäß auf einen seitens DG nicht funktionierenden IPv6-Zugang hin. Auffällig sind hier immer wieder jene IPv6-Ranges (hier 2a00:6020:9480::/41 mit WAN-Adressen in 2a00:6020:9480::/112), in denen DG aktuell ein neues Adressierungsschema einführt.
• Die DG-Gegenstelle (hier fe80:22) beantwortet generell keine NS, die per Multicast an ihre SNMA (solicited node multicast address, hier: ff02::1:ff00:22) gesendet werden. NS, die sie per Unicast (an fe80::22) erhält, werden offenbar nach einer bestimmten Zeit ebenfalls nicht mehr beantwortet. Dies führt dazu, dass dem Kundenrouter die MAC-Adresse der DG-Gegenstelle abhanden kommt, und er in der Folge keine IPv6-Unicast-Pakete mehr ausgehend Richtung Internet senden kann.
• Da erfolgreich an die DG übermittelte PINGv6-Pakete (ICMPv6 Echo Request) zu allgemein pingbaren Internet-Zielen (z.B. facebook.com = 2a03:2880:f176:181:face:b00c:0:25de) nicht per ICMPv6 Echo Reply beantwortet werden, ist anzunehmen, dass die IPv6-Adressen des Kundenanschlusses innerhalb der DG-Netzinfrastruktur nicht korrekt geroutet werden (vermutlich nicht funkionierende IPv6-Rückwärts-Routen zum Kundenanschluss).

Puh. Nochmals vielen herzlichen Dank für die ausführliche Erläuterung! Darf ich deine Ausführungen für eine weitere Beschwerde (die 4.) bei der DG verwenden?

Zitat von JaFr

Darf ich deine Ausführungen für eine weitere Beschwerde (die 4.) bei der DG verwenden?

Na klar - nur zu! Würde mich freuen, wenn das bei DG zu deinem Vorteil tatsächlich eine Wirkung hätte. Ich befürchte nur, dass man dich am anderen Ende nicht zu jenem Backend-Support durchlassen wird, der diese Analyse nachvollziehen könnte. Abgesehen davon, dass man DG-seitig ein hauseigenes Problem ungern zugeben wird, sonst kommen die betroffenen Kunden noch auf die dumme Idee, Regressforderungen zu stellen.

Danke, mache ich und gebe hier auch gerne Rückmeldung bzgl. des weiteren Verlaufs. Laut letzter Antwort der DG soll die Ursache bei meinen Routereinstellungen liegen:

"Ihnen steht bei Deutsche Glasfaser ein CGN Dualstack Lite Anschluss zur Verfügung. IPV4 im NAT und eine semistatische IPV6, die IPV6 kann durch ggf. Wartungen und Stromverlust wechseln. Die Einrichtung findet per DHCP an Ihrem Anschluss statt. Das bedeutet, dass die notwendigen Adressen automatisch zugewiesen werden. Sollte Ihr Router keine IPv6-Adresse erhalten, kontrollieren Sie bitte die Einstellungen. Weitere Informationen dazu finden Sie in der Anleitung des Herstellers."

Zitat von JaFr

Ihnen steht bei Deutsche Glasfaser ein CGN Dualstack Lite Anschluss zur Verfügung

Das ist falsch! Es ist ein Dualstack-Anschluss, allerdings mit IPv4 hinter einem CGNAT und daher einer nicht-öffentlichen IPv4-Adresse für deinen Router aus 100.64.0.0/10 (= Range 100.64.0.0 - 100.127.255.255).

Bei einem DS-Lite-Anschluss hätte dein Router gar keine IPv4-Adresse.

DG sollte seine Textbausteine überarbeiten.

Vielleicht noch folgende Tipps für dein nächstes Ticket an die DG:

• Ich würde meinen Fazit-Block in #93 kopieren und direkt in das Ticket schreiben. Als Referenz würde ich Links auf #93 (Analyse des Paketmitschnitts), #91 (Wireshark-Darstellung des Paketmitschnitts) und #88 (Beschreibung des Ablaufs für die Erstellung des Paketmitschnitts) beifügen.
• Den Paketmitschnitt würde ich als ZIP-Datei beifügen - allerdings nicht die vollständige eth-Datei, sondern nur den extrahierten View des Ansichtsfilters "icmpv6": Menü Datei | Ausgewählte Pakete exportieren: Im angezeigten Dialog alle Voreinstellungen belassen und Namen für die zu speichernde Datei mit der voreingestellten Erweiterung .pcap speichern. Diese Datei anschließend zippen und die ZIP-Datei dem Ticket beifügen.

Danke, die Meldung an die DG war aber leider schon raus. Zusammenfassung des Ablaufs, dein Fazit und die beiden Screenshots. Die Nachrichtenlänge ist bei der DG auf 2000 Zeichen begrenzt, nicht viel um einen komplexen Sachverhalt darzustellen. Ich hoffe mal, dass jetzt was anderes kommt, als die Behauptung, dass seitens der DG alles ordnungsgemäß funktioniert und ein Hinweis auf meine Routerkonfiguration. Nötigenfalls muss ich halt noch ein Ticket aufmachen und die ZIP-Datei und die Links nachliefern. Jetzt erst mal abwarten, ich melde mich.

Zitat von JaFr

Die Nachrichtenlänge ist bei der DG auf 2000 Zeichen begrenzt, nicht viel um einen komplexen Sachverhalt darzustellen.

Naja, den Sachverhalt könntest du ja umfänglicher mit einer Textverarbeitung erstellen, als PDF speichern und als Attach anfügen. Im Ticket selbst dann nur eine Zusammenfassung mit Verweis auf den Anhang.