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
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
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.
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.
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.
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?
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:
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"
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.
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?
vergiss bitte KI, die ist dumm und käut nur "Angelesenes" unverstanden wieder.
Versuch bitte nochmal einen Paketmitschnitt und beachte vorher die Dinge meines letzen Posts
Ändere doch bitte mal im Browser deiner Wahl die Grundeinstellung dahingehend, dass er Downloads per Default nicht einfach im Standard-Download-Ordner von Windows ablegt, sondern dass er dich zuvor fragt, in welchem Ordner er die Datei ablegen soll:
Edge: edge://settings/downloads: Aktiviere "Vor dem Download fragen, wo die einzelnen Dateien gespeichert werden sollen"
Chrome: chrome://settings/downloads: Aktiviere "Vor dem Download von Dateien nach dem Speicherort fragen"
Firefox: about:preferences#general: Dateien und Anwendungen | Downloads | Aktiviere "Jedes Mal nachfragen, wo eine Datei gespeichert werden soll"
Nach Start des Paketmitschnitts klicke bitte erst dann auf auf "Neu verbinden", nachdem du den Speicherort der Mitschnitt-Datei bestimmt hast. Zum Beenden des Paketmitschnitts auf "Stopp" klicken und warten, bis die Anzeige dort wieder auf "Start" wechselt (das kann eine Weile dauern - hier bitte nicht ungeduldig werden und keinesfalls mehrfach auf "Stopp" und/oder "Start" klicken!). Erst dann ist der Mitschnitt beendet. Bitte keinesfalls vorher den Browser-TAB schließen - dadurch würde die Mitschnitt-Datei gelöscht.
Noch ein Nachtrag:
Ich habe über einen lokalen Paketmitschnitt an meinem Windows-PC eben eruiert, wie der Datentransport der Mitschnitt-Daten von der Fritzbox zum Speicherort der Mitschnitt-Datei auf meinem PC funktioniert: Dies erfolgt über eine HTTPS-Verbindung, die mein PC zur Fritzbox über IPv4 aufbaut. Daher bleibt diese Verbindung auch bestehen, wenn man in der Fritzbox auf "Neu verbinden" klickt. Die Verbindung würde auch mittels IPv6-ULA bestehen bleiben. Nur falls dummerweise diese Verbindung mit den globalen IPv6-Adressen aus dem PD-LAN-Block erfolgen würde, würde sie natürlich mit Klick auf "Neu verbinden" wegbrechen - da hätte man sich dann den Ast abgesägt, auf dem man sitzt.
Noch ein Nachtrag:
Wenn man zur DNS-Auflösung die Fritzbox-Adresse als DNS-Server verwendet, dann liefert die Fritzbox für die Auflösung ihres Namens "fritz.box" alle 3 LAN-Adressen zurück: IPv4, ULA und IPv6-GUA. Es besteht daher tatsächlich die Gefahr, dass man für den Paket-Mitschnitt die IPv6-GUA verwendet, so dass es bei Klick auch "Neu verbinden" zu einem Abbruch des Paket-Mitschnitts kommt.
Um das zu verhindern, würde ich an dem Windows-PC die HOSTS-Datei wie folgt modifizieren:
Kommandos wie folgt eingeben:
C:\Windows\System32>cd drivers\etc
C:\Windows\System32\drivers\etc>notepad hosts
Wenn man nun per Browser auf die Fritzbox zugreift, erfolgt dies nur noch via IPv4, weil die Auflösung von "fritz.box" nun per HOSTS-Datei in den "DNS-Auflösungscache" vorgeladen wird und daher nicht mehr aktiv aufgelöst werden muss.
Luki : Also, wenn du genau wissen willst, was los ist, kommst du um einen Paketmitschnitt nicht herum.
Ich kopiere mal alles aus anderen Beiträgen zusammen:
An einem beliebigen Windows-PC in deinem LAN:
Um dort "den Wald vor lauter Bäumen" zu finden, solltet du in der oberen Zeile "Anzeigefilter anwenden" die folgenden Ansichtsfilter eingeben: icmpv6 || dhcpv6 || icmp || arp || dhcp. Das sollte reichen, um IPv4- und IPv6-Reconnect anzuzeigen. Für IPv6 alleine wäre der Filter icmpv6 || dhcpv6 ausreichend (entsprechend für IPv4 der Filter icmp || arp || dhcp).
Falls du aus der ursprünglichen Mitschnitt-Datei nur die durch den Filter icmpv6 || dhcpv6 || icmp || arp || dhcp generierte Ansicht in einer separaten Datei speichern möchtest:
Das ergibt eine schön kleine Datei.
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.
Ggf. kannst du dann Screenshot und die PCAP-Datei des Mitschnitts in einem Ticket an die DG senden.
Das zeigt dass die Konfiguration und die Verkabelung und allgemein alles stimmt und liegt nicht an dem FritzBox - das sind zwei Fritzboxen - 5690 für DG und 6660 für Vodafone, identisch konfiguriert
Ui - dann hast du eine Multihoming-Situation: Die wird leider nicht ordentlich mit IPv6 funktionieren (du kannst nicht sicherstellen, dass je nach Quell-IPv6-Adressauswahl an deinem PC das jeweils dazu passende IPv6-Gateway genommen wird: Vodofone wird keine DG-Quelladressen akzeptieren/routen und umgekehrt wird DG keine Vodafone-Quelladressen akzeptieren/routen).
Bzgl. IPv6 musst du dich für einen Anbieter entscheiden. Am anderen Router musst du dann IPv6 deaktivieren.
was mir sofort auffällt: Du hast zwei IPv6-Default-Gateways:
fe80::ab6...
fe80::223...
Da sind also zwei IPv6-Router im LAN, die beide Router-Advertisements (RA) announcen.
Stelle sicher, dass nur ein IPv6-Default-Gateway (fe80-LAN-Adresse deiner Fritzbox) im Netz vorhanden ist, bzw. stelle das Senden von RA am anderen Router ab!
in dem Fritzbox 5690 Pro Oberfläche ist alles im grünen Bereich, sowohl IPv4 als auch IPv6, die Geräte im lokalen Netz bekommen alle ihre IPv6 Adressen, leider sind die IPv6 Adressen im INternet nicht pingbar und die Geräte im eigenen Netz aus dem INternet ebenso nicht erreichbar.
Ich würde erst Mal gerne deine Aussagen validieren, und zwar vorerst nur IPv6 outbound:
1&1 übernimmt den Kunden-Traffic auf Layer 2. Layer 3 wäre bereits die IP-Adresse.
DG stellt demnach die Konnektivität im (G/XGS)-PON bereit und übergibt den gesamten Datenstrom unverändert je Kunde an das Netz von 1&1.
Der DG-Support kann bekanntermaßen mit L3 (IPv4, IPv6) nichts anfangen - wäre für mich tatsächlich ein Grund, zu 1&1 zu wechseln, in der Hoffnung, bei Problemlagen ab L3 auf kompetenteren Support zu treffen, bzw. bestenfalls den Support gar nicht erst zu benötigen, weil 1&1 hoffentlich "Internet einfach besser kann" als DG. Umgekehrt wird's dann aber bei L2-Problemen blöd, weil 1&1 nicht der L2-Betreiber, sondern nur der Vermittler "in the middle" zu DG ist.
Warum gibt es so wenige bzw. keine symmetrischen Privatkundentarife, zumindest keine ohne extra Gebühr für dieses Feature?
Die Forderung nach "Symmetrie" impliziert den Bedarf für größere Upload-Bandbreite. Unter den Gründen für diesen Mehrbedarf mögen aus Sicht der ISP einige dabei sein, die sie an Privatkunden-Anschlüssen nicht so gerne sehen, z.B. den Betrieb von Webservern. Dafür benötigte Features (hohe Upload-Raten nebst festen IP-Adressen) möchten sie doch gerne den Business-Anschlüssen vorbehalten und dafür gerne mehr kassieren.
Das war die von mir verkürzte Dauer, um den Renewal zu provozieren.
Ist trotzdem nicht zielführend - es sollte da keine lokal konfigurierte Leasetime zurück kommen. Aber ich wiederhole mich hier schon mehrfach.
