Beiträge von ::1

Zitat von vrcca

Es ist nicht möglich ein IPv6 zu bekommen (Ich habe versucht DHCPv6 zu konfigurieren, aber ohne Erfolg), nur IPv4.

Bei IPv6 Connection statt "SLAAC" mal "DHCPv6" ausprobieren?

Zitat von ::1

Du bekommst nach einem Reconnect wieder dieselben IPv6-Adresswerte zugewiesen (WAN: 2a00:6020:9a80::172, LAN: 2a00:6020:9ac3:6b00::/56). Ist das immer so, oder wechseln Adressen auch mal?

Zitat von Slience

Meinst du die IPV6 Adresse (Präfix) bei der Fritzbox unter Verbindungsdetails (diese hat sich von ....:6boo::/56 zu b800::/56 geändert oder wo finde ich die für LAN?

Deine FB-Ereignisanzeige in #427 gibt die Antwort:

• 10.10.25 15:07:44 IPv6-Präfix konnte nicht bezogen werden, Fehlergrund: 4000 (lease timed out)
• 10.10.25 15:07:44 IPv6-Präfix wurde erfolgreich bezogen. Neues Präfix: 2a00:6020:9ac3:b100::/56
  
• 10.10.25 16:07:44 IPv6-Präfix konnte nicht bezogen werden, Fehlergrund: 4000 (lease timed out)
• 10.10.25 16:07:44 Internetverbindung IPv6 wurde erfolgreich hergestellt. IP-Adresse: 2a00:6020:9a80::330
• 10.10.25 16:07:44 IPv6-Präfix wurde erfolgreich bezogen. Neues Präfix: 2a00:6020:9ac3:7500::/56
  
• 10.10.25 17:07:44 IPv6-Präfix konnte nicht bezogen werden, Fehlergrund: 4000 (lease timed out)
• 10.10.25 17:07:44 IPv6-Präfix wurde erfolgreich bezogen. Neues Präfix: 2a00:6020:9ac3:b800::/56

Du bekommst ständig wechselnde /56-LAN-Präfixe. Ob sich die WAN-Adressen auch ändern, kann ich leider nicht sehen, da die FB diese nur einmal anzeigt (2a00:6020:9a80::330).

Wie du siehst, passieren diese Fehlereinträge (Fehlergrund: 4000 (lease timed out)) exakt in Stundenabständen.

Ursache:

Die deinem Router per DHCPv6 zugewiesenen IPv6-Adressen (WAN-Adresse + /56-LAN-Präfix) werden seitens DG nicht verlängert (die FB versucht vor Ablauf der Leasedauer durch Senden von "DHCPv6-Renew" und ggf. zusätzlich "DHCPv6-Rebind", die Leasedauer der zuletzt erhaltenen IPv6-Adressen zu verlängern, der DHCPv6-Server der DG beantwortet diese Verlängerungsversuche jedoch nicht).

Die Leasedauer beträgt bei DG 3600s = 1h. Läuft sie ab, erzeugt die FB in ihrem Event-Log den Eintrag "IPv6-Präfix konnte nicht bezogen werden, Fehlergrund: 4000 (lease timed out)". Anschließend fordert sie in einer neuen DHCPv6-Transaktion eine neue DHCPv6-Lease an.

Dass die DHCPv6-Leases nicht verlängert werden, ist ein weiterer Fehler seitens DG. Und dass du jedes Mal neue IPv6-Adressen bekommst, ist ebenfalls nicht normal.

Insofern gilt das Fazit des ähnlich gelagerten Falles #93 analog auch für dich - ich kopier's dir nochmal hierher und passe es unter Ergänzung des DHCPv6-Problems für deinen Fall an:

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:9a80::/41 mit WAN-Adressen in 2a00:6020:9a80::/112), in denen DG aktuell ein neues Adressierungsschema einführt.
• Die Versuche des Routers, die IPv6-Adressen für LAN und WAN vor Ablauf der Leasedauer (1h) per DHCPv6-Renew bzw. ggf. zusätzlich per DHCPv6-Rebind zu verlängern, werden seitens der DG-Gegenstelle (DG-DHCPv6-Server) nicht beantwortet. In der Folge laufen die DHCPv6-Leases nach Ablauf einer Stunde regelmäßig aus. Der Router fordert anschließend in einer neuen DHCPv6-Transaktion eine neue Lease an, erhält dabei in der Regel allerdings andere Adressen, als die jeweils vorherigen Lease. Auch dieses Verhalten deutet erfahrungsgemäß auf einen seitens DG nicht funktionierenden IPv6-Zugang hin.
• 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).

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.

Habe deine Mitschnitt.zip mal mit dem Ansichts-Filter ipv6 || dhcp angeschaut (Screenshot-Datei und pcap für die Filtersicht als ZIP im Anhang):

Das ist ziemlich identisch zu #93 (Analyse des Paketmitschnitts) in Verbindung mit #91 (Wireshark-Darstellung des Paketmitschnitts) und #88 (Beschreibung des Ablaufs für die Erstellung des Paketmitschnitts).

Der Fazit-Block in #93 (Analyse des Paketmitschnitts) passt auch für deinen Fall, allerdings mit folgenden Unterschieden:

• Du bekommst nach einem Reconnect wieder dieselben IPv6-Adresswerte zugewiesen (WAN: 2a00:6020:9a80::172, LAN: 2a00:6020:9ac3:6b00::/56). Ist das immer so, oder wechseln Adressen auch mal? Falls nicht, gilt der erste Aufzählungspunkt des Fazits in #93 nicht für deinen Fall - du wärst dann in der schon besseren Situation, wenigstens stets dieselben IPv6-Adresswerte zu bekommen.
• Aber auch deine IPv6-Adressen liegen in einem Block, in dem DG ein neues Adresszuweisungskonzept einführt; es ist nur ein anderer Block als im Fall #93, nämlich 2a00:6020:9a80::/41 (LAN-Adressbereich für Kundenanschlüsse 2a00:6020:9a80:100::/56 - 2a00:6020:9aff:ff00::/56, WAN-Adressen in 2a00:6020:9a80::/112, also Adressen der Form 2a00:6020:9a80::xxxx). IPv6-Ranges dieser Art sind offenbar anfällig für IPv6-Probleme.

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.

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.

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.

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).

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

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.

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 ...

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

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.

Zitat von maik6849

Weil es eine einzelne Adresse ist.

ja klar, aber wenn sie per SLAAC aus den RA der FB gebildet wurde, müsste sie einen /64 aufweisen.

zu "mngtmpaddr" siehe hier. Werde allerdings auch nicht recht schlau daraus ...

Auffällig noch:

inet6 2a00:6020:x000:xx00:0000:x000:x00x:4977/128 scope global dynamic

Wieso /128 und nicht /64?

Zitat von Xonic207

Ja, das scheint so der Fall zu sein, zwar ist es ein Feld in dem man auch selbst "reinschreiben" kann, aber dann kommt die Meldung: "Keine Übereinstimmungen".

Die Bereitstellung eines ordentlichen Manuals für das "UGOS Pro"-OS des NAS scheint der Hersteller wohl nicht für nötig zu halten (fragt auch der User "Merkur" im Ugreen-Forum)?

Zitat von pufferueberlauf

??? Wenn das NAS sich die IPv6 per DHCPv6 zuweisen laesst, warum kann dann nicht der Router eine solche zuweisen?

Vergleiche hier: Da habe ich so eine dynamische Konfiguration unter [1.] beschrieben.

Es wurde alles schon mal diskutiert - nur nicht in diesem Thread ...

Zitat von Xonic207

bzw. den Post von ::1 anschauen.

das wäre kein Hexenwerk.

Vergleiche hier: Da habe ich so eine statische Konfiguration (für ein QNAP-NAS) beispielhaft unter [2.] beschrieben.

Siehe auch diesen Thread zum Thema.

Zitat von HubeBube

Nichts, außer dem schon erwähnten und die Vergesslichkeit, falls sich doch der Präfix irgendwann ändern sollte.

Ja, aber ich sehe auch keinen besseren Vorschlag, außer es ganz sein zu lassen - bzw. es weiterhin via VPN zu betreiben (was im übrigen auch deutlich sicherer ist).