Beiträge von ::1

Zitat von oggear51

Nach Deaktivierung von Ipv6 habe ich jetzt keine Probleme mehr, dass Internet läuft einwandfrei

Genau das war erwartbar. IPv4 ist ok. IPv6 ist kaputt. Wird nicht einfach, das der DG zu verklickern.

Zitat von HubeBube

Immer noch verblüffen mich die zugewiesenen DNS-Server. Dies sollten die folgenden sein:

Ein weiteres Indiz einer DG-seitig fehlerhaften Konfiguration des Kundenzugangs.

Zitat von oggear51

Meine Verbindung wird alle 12 Std getrennt.

Die Meldungen sind harmlos, sie bedeuten lediglich, dass deine DHCPv4-Leasedauer wieder auf den Maximalwert (3600s) verlängert wird. Das passiert alle 30 Minuten, die FB loggt das allerdings nur alle 12 Stunden - warum, weiß nur AVM.

Ich habe das Eventlog der FRITZ!Box (im folgenden "FB") (siehe #37) nun mal analysiert:

Es erstreckt sich über den Zeitraum 26.05.2025 20:49:23 - 01.07.25 17:21:37 und zerfällt in Abschnitte, die jeweils durch ein manuelles Neuverbinden in der FB (Internet | Online-Monitor | TAB "Verbindungsdetails" | Schaltfläche "Neu verbinden") ausgelöst wurden. Dies ist im Eventlog daran erkennbar, dass die beiden Ereignisse ...

• Internetverbindung IPv6 wurde getrennt, Präfix nicht mehr gültig.
• Internetverbindung wurde erfolgreich hergestellt. IP-Adresse: ...

... im Abstand von nur wenigen Sekunden auftreten - es werden also stets sowohl IPv4-WAN-Adresse als auch IPv6-Adressen (WAN-Adresse und PD-Präfix) neu bezogen.

Abgesehen von irrelevanten Abschnitten, in denen experimentiert wurde (DS-Lite/AFTR, 6to4, "Globale Adresse aus dem zugewiesenen Präfix ableiten"), gibt es bezogen auf IPv6 zwei spezifische Abschnittstypen mit unterschiedlichen Charakteristika:

1. Einen Abschnitt (26.05.2025 20:49:23 - 27.05.2025 12:49:24), der von DHCPv6 Lease-Timeouts dominiert wird.
2. Alle übrigen Abschnitte (außer denen mit Konfigurations-Experimenten, s.o.), die sich bzgl. IPv6 wie folgt charakterisieren lassen: Während die eingangs neu (aber jedes Mal geänderte) WAN-Adresse in dem Abschnitt konstant bleibt, wechselt (vermutlich im Rahmen von DHCPv6-Renews) das PD-Präfix in unregelmäßigen Zeitabständen zwischen 0,5h und maximal ~56h (allerdings beendet durch manuelles Neuverbinden). Die Zeiträume eines konstanten PD-Präfix sind immer Vielfache von 0,5h (DHCPv6-Renew-Time T1: 1800s), was darauf hindeutet, dass die PD-Präfix-Änderungen im Rahmen von DHCPv6-Renews erfolgen.

Die Lease-Timeouts des Abschitt-Typs 1 tauchen regelmäßig jede Stunde auf, weil dann jeweils die Leasedauer abläuft. DHCPv6-Renews und -Rebinds scheiterten also in dieser Phase. Immerhin wurden aber im Rahmen eines sich anschließenden neuen DHCPv6-Exchanges dieselben IPv6-Adressen (WAN-Adresse und PD-Präfix) zugewiesen.

Das änderte sich nach Ende des ersten Abschnitts dann wie folgt:

• Es folgt ein "experimenteller" Abschnitt (27.05.2025 12:51:13 - 27.05.2025 12:51:21) mit einer DS-Lite-Konfiguration. Die lieferte noch dieselben IPv6-Adressen wie im voran gegangenen Abschnitt 1.
• Der nächste Abschnitt mit (vermutlich) korrekter Standardkonfiguration (27.05.2025 12:54:58 - 27.05.2025 12:55:16) liefert nun erstmals neue IPv6-Adressen (WAN-Adresse und PD-Präfix).
• Es folgt noch ein "experimenteller" Abschnitt (27.05.2025 12:56:56 - 27.05.2025 12:56:58) mit "6to4"

Alle folgenden Abschnitte (ab 27.05.2025 12:57:50) sind jetzt nur noch vom Typ 2. Gelegentlich treten auch innerhalb eines solchen Abschnitts DHCPv6 Lease-Timeouts auf, die (im Unterschied zu Abschnitt 1) auch jeweils geänderte IPv6-Adressen (WAN-Adresse und PD-Präfix) nach sich ziehen (Abschnitte 27.05.2025 12:57:50 - 27.05.2025 14:28:05, 28.05.2025 07:15:38 - 31.05.2025 22:47:54, 08.06.2025 13:28:46 - 08.06.2025 17:29:04). Gelegentlich tritt auch der Fehler "IPv6-Präfix konnte nicht bezogen werden, Fehlergrund: 4001 (server failure: requested IA_PD not provided)" auf, der aber nur eine kurze Verzögerung bis zum Bezug eines PD-Präfix bewirkt.

Man könnte jetzt vermuten, dass DG mit diesem neuen "Konzept" möglicherweise versucht, von quasi-statischen IPv6-Adressen für Privatanschlüsse wegzukommen, um echte statische Adressen den Business-Anschlüssen vorzubehalten.

Es ist aus meiner Sicht aber keine gute Idee, einen PD-Präfix "unter Tage" zu tauschen, indem man den altem Präfix entzieht und einen neuen zuweist - das ist der Tod für jede bestehende Netzverbindung (insbesondere TCP-Verbindungen), der Anwender wird das als Netzwerkunterbrechung wahrnehmen.

Ich gehe also davon aus, dass die hohe "IPv6-Dynamik" ein Indiz für eine Fehlkonfiguration bei DG darstellt.

Zudem scheint es so zu sein, dass ein gerade neu zugewiesenen PD-Präfix nur eine begrenzt lange Zeit (lt. Anwenderangabe etwa 20-30 Minuten) im DG-Backend tatsächlich auch geroutet wird. Das bedeutet, dass bis zur nächsten Zuweisung eines (geänderten) PD-Präfix das bestehende Präfix im Kundennetz zwar noch announced wird, aber längst schon nicht mehr funktioniert - das ist ziemlich tödlich für eine "IPv6 User Experience".

Eine Validierung dieser These erfordert allerdings einen Paket-Mitschnitt am WAN-Port der FB (während eines Dauerpings auf eine IPv6-Adresse im Internet). Der wäre auch sehr aufschlussreich für die Analyse, wie genau der PD-Präfixwechsel erfolgt und wie lange das neue Präfix bei DG auch geroutet wird.

Ergänzung:

Die nach Anwender-Beobachtung ausbleibende IPv6-Erreichbarkeit des Internets (keine IPv6-Ping-Antworten) kann evtl. auch dadurch begründet werden, dass zwar mit Neuzuweisung eines PD-Präfix für kurze Zeit auch gültige Router-Advertisements (RA) mit einer Router-Lifetime von 1800s gesendet werden, danach jedoch nicht mehr, so dass die IPv6-Defaultroute nach einem Timeout von 30 Minuten ungültig wird. Oder es werden nach einer Weile fehlkonfigurierte unsolicited RA mit einer Router-Lifetime=0 gesendet, die die IPv6-Defaultroute sofort ungültig werden lassen. Auch derlei würde man nur in einem Paketmitschnitt sehen können.

Zitat von HubeBube

Palo Altos Global Connect funktioniert sehr gut in dem Dual Stack mit CGNAT Netz von Deutsche Glasfaser.

Ist das als Bestätigung für OpenVPN zu verstehen - weil Global Connect auf OpenVPN zu basieren scheint (siehe hier, würde ich jetzt allerdings nicht unter "Allgemeinwissen" verbuchen)? Andernfalls weiß ich nicht, ob ZTNA mit Palo Altos Prisma Access hier für das Umfeld des OP in Frage kommt, ist doch eher was für "big enterprises" - oder ordne ich das jetzt falsch ein, bzw. für welchen evtl. anderen Use Case nutzt du Global Connect?

Vorschlag:

Deaktiviere vorerst IPv6 in der Fritzbox für ein paar Tage. Beobachte, ob wenigstens IPv4 konstant/stabil läuft - inklusive guter Performance beim Laden von Websites etc. Bei IPv4 zeigt die FB in der Ereignisanzeige auch die Leaseverlängerungen der IPv4-Adresse etwa 2x am Tag an. Wäre interessant, ob die IPv4-Adresse dabei konstant bleibt oder sich auch regelmäßig ändert - dies aber nur nebenbei.

Danach könnte man IPv6 wieder aktivieren, um einen geeigneten Paketmitschnitt am WAN-Port der FB durchzuführen, der das IPv6-Fehlverhalten mitschneidet. Wenn du willst kann ich dich dabei unterstützen (muss mir noch überlegen, wie man das "am dümmsten" macht), so dass du der DG in einem Ticket das Problem auch technisch fundiert nachweisen kannst. Dann wärst du in jedem Fall auf der sicheren Seite - auch wenn im DG-Support erst mal keiner Paketmitschnitte lesen kann und du vermutlich 10 Tickets aufmachen musst, bis dir evtl. geholfen wird.

Und das hier ist auch witzig:

"Internetverbindung wurde erfolgreich erneuert. IP-Adresse: 100.102.133.109, DNS-Server: 185.22.44.50 und 185.22.44.50, Gateway: 100.102.128.1"

Der DHCP-Server weist zweimal 185.22.44.50 als DNS-Server zu. Sollte eigentlich so aussehen: "DNS-Server: 185.22.44.50 und 185.22.45.50"

Auch deine IPv4-Adresse wechselt recht oft - sollte eigentlich auch über sehr lange Zeiträume konstant sein.

Ja, IPv6 funktioniert nach Zuweisung eines Präfix eine Weile, danach dann aber nicht mehr - bis wieder eine neues Präfix zugewiesen wird. Das Log zeigt auch Lease-Timeouts, es gibt also gelegentlich Probleme, eine Lease zu verlängern. Stattdessen weist DG einfach ein neues zu, dass dann wieder eine Weile funktioniert.

Kritisch wird es dann (schlechte "User experience" bei dir), wenn dein Router das letzte zugewiesene Präfix im LAN noch propagiert, dieses im DG-Backend (vermutlich) aber nicht mehr geroutet wird. Das sind die Phasen, wo der Dauerping in deinem Test vorhin keine Antworten geliefert hat.

Danke für die TXT-Datei!

Muss ich erst mal analysieren, um Muster zu erkennen.

Eine Zeile sticht aber hervor: "Internetverbindung IPv6: AFTR konnte nicht bezogen werden: Grund 7 (got no aftr)"

Wie sieht denn die IPv6-Konfiguration in deiner FB aus?

Du solltest am DG-Anschluss _nicht_ "DS-Lite" konfiguriert haben!

Idealerweise sollte "Native IPv4-Anbindung verwenden" konfiguriert sein.

Zitat von oggear51

das ipv6 Präfix wurde nur einmal um 17:21:37 Uhr aktualisiert und um 16:51:37 Uhr neu Bezogen aber das habe ich verursacht

Egal, ob "aktualisiert" oder "von dir verursacht": Wird dabei jedes Mal ein anderes LAN-Präfix 2a00:6020:91WX:YZ00::/56 zugeordnet, oder bleibt der Teil WX:YZ konstant?

Würdest du außerdem sagen: Die Pings lieferten immer dann (für etwa 20-30 Minuten) Antworten, nachdem gerade ein neues LAN-Präfix zugeordnet wurde?

Zitat von oggear51

So knapp 2 stunden später die Antworten kommen und gehen ich würd sagen in 20-30 min Takt

Naja, das scheint meine Vermutung, die ich oben formuliert habe, offenbar zu bestätigen.

Wenn du mal in die Fritzbox-Ereignisanzeige schaust: Korreliert diese mit dem 20-30 min Takt dahingehend, dass etwa alle 40-60 Min ein neues IPv6-Präfix zugewiesen wird?

einfach weiterlaufen lassen, ob irgendwann Ping-Antworten kommen. Und falls ja, dann immer noch weiterlaufen lassen, um zu sehen, ob Antworten irgendwann danach wieder ausbleiben. Deshalb mal so 2 Stunden beobachten

Zitat von UschiM

Leider verstehe ich bei der Analyse nur Bahnhof. Kann mir vielleicht einer der Experten erklären, ob ich bei einer Standard-Fritzbox die Möglichkeit habe, per geänderter Einstellung eine IPv6-Adresse zu bekommen?

Die Analyse bezog sich auf die Art und Weise, welche Variante (da gibt es 4 Stück) der sog. DUID im Rahmen der DHCPv6-Kommunikation zwischen Router und dem DHCPv6-Server der DG zum Einsatz kommt. Mit einer Fritzbox als Router ist das für dich irrelevant, weil die Fritzbox eine Variante verwendet, die durch den DHCPv6-Server der DG unterstützt wird (du könntest den DUID-Typ in der Fritzbox auch gar nicht konfigurieren).

Zitat von UschiM

Was ich soeben getestet habe: Ich habe die Option "Nur IPv6 verwenden" ausgewählt, um zu verhindern, dass zunächst per IPv4 kommuniziert wird. Das hat aber nicht geklappt: ich hatte dann gar keine Internet-Verbindung mehr und bin daher auf die Option "Native IPv6-Anbindung verwenden" zurückgewechselt.

Ja, das ist klar: Wenn du nur IPv6 anforderst, das DG dir nicht liefert, dann endet das eben im Nichts.

Du solltest aber besser die Option "Native IPv4-Anbindung verwenden" verwenden: Die beiden Einstellungen bestimmen nur die Reihenfolge, mit der IPv4 und IPv6 angefordert werden:

• "Native IPv4-Anbindung verwenden": Es wird zuerst IPv4, dann IPv6 angefordert - das führt bei DG erfahrungsgemäß deutlich schneller zum Erfolg und ist deshalb die empfohlene Variante.
• "Native IPv6-Anbindung verwenden": Es wird zuerst IPv6, dann IPv4 angefordert - dauert bei DG erfahrungsgemäß deutlich länger, deshalb nicht zu empfehlen - insbesondere in deinem Fall nicht, wo du gar kein IPv6 bekommst.

Zitat

Im übrigens wurde gestern mein 3. Ticket zu dem IPv6-Problem geschlossen mit dem Hinweis, dass kein IPv6-Problem erkannt wurde.

Hier im Forum wird von bis zu 10 Versuchen gesprochen, um dort den Einäugigen zu finden, der in der Lage ist mehr zu erkennen.

Bitte eins nach dem anderen und Glaube hilft ohne Verifikation nicht weiter. Ich bin noch bei IPv6: Was ist bei dem Ping-Test heraus gekommen?

oggear51 : Wenn es tatsächlich so ist, dass die FRITZ!Box der LAN-Umgebung (zeitweise) eine IPv6-Verfügbarkeit vorgaukelt, die im DG-Backend nicht mehr gegeben ist, dann führt das zu einer schlechten "user experience", wie von dir beschrieben.

In diesem Fall hilft es nur noch, die IPv6-Unterstützung in der FRITZ!Box abzuschalten und ausschließlich mit IPv4 zu arbeiten - dass sollte dann eine spürbare Verbesserung mit sich bringen.

Deine IPv6-PD-Blöcke (/56) für das LAN und deine IPv6-Adressen am Glasfaser-Port stammen offenbar aus den beiden folgenden IPv6-Blöcken:

An der WAN-Port-Adresse ist erkennbar, dass auch dieser Range vermutlich zu jenen gehört, in denen DG ein neues IPv6-Adressierungsschema einführt, und die hier im Forum schon relativ oft mit IPv6-Problemen aufgefallen sind. Weitere IPv6-Ranges dieser Art habe ich hier mal zusammengetragen.

Mach doch mal bitte so etwa 2 Stunden einen Dauer-Ping unter Windows:

ping -t 2a00:1450:4001:81d::200e

(das ist die IPv6-Adresse von google.com)

Wenn meine Vermutung richtig ist, sollte der eine Weile funktionieren (Präfix funktioniert noch), dann eine Weile nicht (Präfix wird bei DG nicht mehr geroutet, ist deinem Anschluss aber noch zugeordnet), dann wieder doch (neues Präfix bekommen, das wieder eine Weile funktioniert) usw.

LOOP:

Ich glaube, dein IPv6 Präfix wird bei DG ungültig, während es deinem Anschiuss noch zugeordnet ist (Eyeball-Test: nur IPv4). Dann weist dir DG einen neuen IPv6-Präfix zu (man sollte eigentlich immer denselben bekommen, das ist nicht normal), der eine Weile funktioniert (Eyeball-Test: auch IPv6), bis das Spiel wieder von vorne beginnt.

GOTO LOOP

Zitat von pufferueberlauf

Das koennte eine IPv6/Happy Eyeballs Problem sein

Dafür gäbe es einen Test unter http://he.test-ipv6.com/

Zur Info und passend zum Thema:

Es ist soeben RFC9797 erschienen: "Randomized and Changing Media Access Control (MAC) Addresses: Context, Network Impacts, and Use Cases". Es behandelt unter dem Kürzel RCM (Randomized and Changing MAC addresses) das, was hier im Thread in Apple's Implementierung als "Private WLAN-Adressen" referenziert wurde und dessen Charakteristika vermutlich durch Appendix A3 des RFC abgedeckt sind.

Insbesondere behandelt Chapter 6 in Bezug auf Network Services die damit einher gehenden Probleme ("loss of device identification" bei Wechsel der MAC-Adresse).

Es geht in dem RFC allerdings _nicht_ um IPv6-Interface-IDs (IID) - bezügliche RFC (RFC7217 und RFC8981) werden zwar als Informative References benannt, im RFC-Text jedoch in einem Kontext zitiert, der nichts mit dem in diesem Thread behandelten Problem zu tun hat, nämlich dass ein stable IID laut RFC7217 vom LAN-Präfix abhängt, für das er generiert wird.

Oder anders formuliert:

RCM verschärfen das Problem mit daraus abgeleiteten stable IPv6 IIDs zwar, die Abschaltung von RCM (aka "Private WMAN-Adressen" bei Apple) löst es allein aber nicht, da es zusätzlich durch die Abhängigkeit des Generierungs-Algorithmus von stable IIDs vom LAN-Präfix (mit-) verursacht wird.