Beiträge von ::1

Zitat von Spallek

Die Fritz!Box zeigt weiterhin eine IPv4 aus dem Bereich 100.XXX.XXX.XXX an, die nun einmal nicht öffentlich erreichbar sind (Carrier-grade NAT-Bereich).

Vorsicht: 100.0.0.0/10 und 100.128.0.0/9 sind öffentlich, nur eben 100.64.0.0/10 nicht.

Zitat von erasurehead

Danach hat es problemlos geklappt. Anscheinend wird die PPP-Aushandlung über ipv6 abgewickelt.

Nein, aber an einem DS-Lite-Anschluss ohne IPv6 bekommst du eben auch kein IPv4. Die Abhängigkeitskette ist:

PPP -> IPv6 -> IPv4

Zitat von ctr

merkwürdigerweise habe ich seit der Wartung erheblich höhere roundtrips. von (im Tagesmittel zu Cloudflare, Google und Azure, entsprechend der Unifi default checks) 4.3 ms zu 12.7 ms.

vgl. mit "Deutsche Glasfaser Hohe Latenz (Ping) nach Wartungsfenster"

Zur Einordnung, was "gute" Latenzwerte sind, hier vielleicht mal ein paar repräsentative Traceroute-Messungen zur RTT aller RIPE-Atlas-Probes an DG-Anschlüssen für IPv4 (AS8899) und IPv6 (AS60294) zu den "well known"-Zielen "google.com" und "facebook.com":

[Hinweis: Momentaufnahme 13.06.2026 16:30]

• IPv4 (AS8899): google.com: Measurement 86691225 (filtered by ASN 8899): MinRTT Range: ~2,5ms bis ~25ms
• IPv6 (AS60294): google.com: Measurement 86691235 (filtered by ASN 60294): MinRTT Range: ~2,3ms bis ~26ms (1 Ausreißer: 107ms)
• IPv4 (AS8899): facebook.com: Measurement 86710104 (filtered by ASN 8899): MinRTT Range: ~1,5ms bis ~25ms
• IPv6 (AS60294): facebook.com: Measurement 86710364 (filtered by ASN 60294): MinRTT Range: ~2,1ms bis ~26ms

Dabei sind die "Kommerziellen" Google und Facebook weltweit bestens "connected".
Anders sieht das schon für eine NPO wie Wikipedia aus:

• IPv4 (AS8899): wikipedia.org: Measurement 86710103 (filtered by ASN 8899): MinRTT Range: ~5,1ms bis ~27ms
• IPv6 (AS60294): wikipedia.org: Measurement 86710304 (filtered by ASN 60294): MinRTT Range: ~8,1ms bis ~30ms

Die Werte werden bei IPv4 schon ab Hop 2 (100.124.1.92) schlecht. Das ist das BNG der DG, an dem dein Anschluss hängt. Ich gehe davon aus, dass das auch bei IPv6 so ist, auch wenn Hop 2 dort nicht antwortet (bei IPv6 antwortet der BNG nicht bei Outbound-Traceroutes) - denn die Werte ab Hop 4 bzw. Hop 5 sind bei beiden Protokollen etwa gleich schlecht. Wobei das Etikett "schlecht" hier auch nur im Vergleich zu deinen vorherigen Spitzenwerten zu sehen ist.

Es könnte sein, dass dein Anschluss an ein anderes BNG umgehängt wurde. Das könntest du daran erkennen, dass du nun andere IPv6-Adressen (PD-LAN und WAN) hast als in dem Zustand mit den deutlich besseren Latenz-Werten. Bei der WAN-Adresse müssten sich die Werte XY in 2a00:6020:1000:XY::nnnn geändert haben. Beim PD-LAN müssten sich entweder die Werte RS in 2a00:6020:RSTU:: geändert haben, oder RS ist gleich geblieben (nämlich RS=ad) und T ist nun kleiner als 8, wo es zuvor größer als 7 war.

Aus deinen Angaben sehe ich zunächst zweierlei:

Deine IPv6-Adresszuordnung erfolgt offenbar nach dem neuen Vergabe-Konzept, das die DG vorrangig in Südwest-Deutschland einführt. Das erkennt man daran, dass die WAN-Adresse nicht in 2a00:6020:1000::/48 liegt, wie bei der Adressvergabe nach dem alten Vergabe-Konzept, sondern am Beginn des 2a00:6020:7700::/41-Blocks, aus dem auch die LAN-Adressen zugeordnet werden. Habe diesen Präfix in meine Sammlung aufgenommen - daher danke für die Info!

Es ist bekannt, dass bei Anschlüssen nach neuer Vergabe-Methode immer wieder IPv6-Fehler auftreten.

Deine Eventlog-Meldungen (Fehler 4000) der FB bedeuten außerdem, dass der DHCPv6-Server der DG deine DHCPv6-Lease nicht verlängert, die dann regelmäßig nach einer Stunde Leasedauer abläuft. Also erfolgt eine neue DHCPv6-Aushandlung, in der dir der DHCPv6-Server der DG dann doch gnädigerweise dieselben IPv6-Adressen (Nachtrag: manchmal aber andere) zuweist, die er zuvor zu verlängern sich geweigert hat.

Ein Traceroute von außen zu deiner IPv6-Adresse im LAN kommt nur bis zum BNG, an dem dein Anschluss hängt (fc00::1), dein Router wird nicht erreicht:

Aus meiner Sicht mal wieder ein Fall, bei dem das Problem auf der Seite der DG liegt - daher dort Ticket aufmachen.

Ob der ONT was damit zu tun hat und dessen Umgehung durch Direkt-Anschluss der FB an den GFTA per Glasfaser das Problem beseitigen würde, kann ich nicht beurteilen. Ich tippe darauf, dass das Problem dadurch nicht beseitigt wird.

Zitat von DLMttH

Nein, das ist nicht so. Der Haken DS Lite ist bei der Fritz!Box nicht destruktiv. Kriegt man Dual Stack vom Provider, funktioniert dies trotz gesetzten Hakens. Es erzeugt nur die Meldung "Got no AFTR" im Log.

Ok, danke für die Info!

DualStack heißt lediglich, IPv4 und IPv6 als vollständige Protokoll-Stacks parallel im System zu haben. Es gibt keinen "vollen" (oder daraus folgenden "halben") DualStack. Ich suche mal nach einer RFC-Definition und ergänze sie hier...

Über die Art (insbesondere) der IPv4-Adressierung ist damit nichts gesagt.

Dem OP geht es ja auch nur darum, DualStack für sein künftiges Omada-Gateway (im Tauch gegen die aktuelle FB) zu fahren unter der Annahme, dass dieses DS-Lite nicht beherrscht. Ob die IPv4-Adresse dabei öffentlich ist oder nicht, spielt vermutlich nur eine nachgelagerte Rolle.

Nachtrag:

Das DS-Lite-RFC (RFC6333) erwähnt in der Terminology-Section 3: "Dual-stack is defined in [RFC4213]"

In RFC4213 steht schon im Abstract; "Dual stack implies providing complete implementations of both versions of the Internet Protocol (IPv4 and IPv6), ...". Weitere Details dann in Section 2 mit der Überschrift: "Dual IP Layer Operation".

Zitat von gevaugeh

Erkennt die FRITZ!box mit dem Profil die Umstellung automatisch?

Hat denn die Fritzbox ein ISP-Profil für "htp"?

Und selbst wenn, wird dieses wohl nur den Standardfall "DS-Lite" abbilden. Ich denke daher, du wirst ab Umstellung nur noch IPv6 haben (weil für IPv4 ja DS-Lite im Profil konfiguriert ist, was nun nicht mehr richtig ist). Du wirst deine FB dann also manuell ohne Nutzung eines vorgefertigten Profils nachkonfigurieren müssen.

Zitat von pufferueberlauf

Die Nachteile bei vollem DualStack liegen auf ISP Seite, der ISP muss fuer jeden Kunden mit vollem DualStack (mindestens) eine der knappen (sproch teuren) IPv4 Adressen reservieren, waehrend bei IPv4-CG-NAT (was auch fuer DS-lite gilt) eine solche IPv4 Adresse gleichzeitig fuer mehrere Kunden verwendet werden kann.

Veto: DualStack heißt nicht automatisch, dass man eine öffentliche IPv4-Adresse bekommt, es kann auch eine nicht-öffentliche (z.B. aus 100.64.0.0/10) hinter einem CGNAT sein (wie bei DG-Anschlüssen). DS-Lite ist nicht die einzige Zugangsart, die CGNAT nutzt. Bei DS-Lite ist CGNAT allerdings prinzipiell zwingend als "Teilfunktion" des sog. AFTR.

Aber ja, die meisten Leute deuten "DualStack" falsch und implizieren damit fälschlicherweise, zwingend eine öffentliche IPv4-Adresse zu erhalten (kann, muss aber nicht).

Wenn du fertig bis mit deinen Konfigurationen, mach doch bitte mal in einer Windows-Eingabeaufforderung folgende einfachen Tests:

C:\>nslookup heise.de. 185.22.44.50
Server:  dnscache001.dg-w.de
Address:  185.22.44.50

Nicht autorisierende Antwort:
Name:    heise.de
Addresses:  2a02:2e0:3fe:1001:302::
          193.99.144.80


C:\>nslookup heise.de. 185.22.45.50
Server:  dnscache002.dg-w.de
Address:  185.22.45.50

Nicht autorisierende Antwort:
Name:    heise.de
Addresses:  2a02:2e0:3fe:1001:302::
          193.99.144.80


C:\>nslookup heise.de. 2a00:6020:100::1
Server:  dnscache001.dg-w.de
Address:  2a00:6020:100::1

Nicht autorisierende Antwort:
Name:    heise.de
Addresses:  2a02:2e0:3fe:1001:302::
          193.99.144.80


C:\>nslookup heise.de. 2a00:6020:200::1
Server:  dnscache002.dg-w.de
Address:  2a00:6020:200::1

Nicht autorisierende Antwort:
Name:    heise.de
Addresses:  2a02:2e0:3fe:1001:302::
          193.99.144.80

Die Ergebnisse müssen genau so aussehen wie gezeigt.

Zitat von CityCobra

Bei mir war unter „Erweiterte Netzwerkeinstellungen“ und unter IPv6 die Option „DNS-Server und IPv6-Präfix zuweisen aktiviert.
Laut dem von dir verlinkten Wissensdokument habe ich das jetzt geändert in „Nur DNS-Server zuweisen“

Ist egal, was du hier einstellst - die Einstellung "DNS-Server und IPv6-Präfix (IA_PD) zuweisen" ist (aktuell) die Standard-Einstellung, zuvor war "Nur DNS-Server zuweisen" die Standard-Einstellung. Sofern du keinen zweiten Router hinter deiner FB betreibst ("Router-Kaskade"), sind beide Einstellungen gleichwertig - im Effekt werden deinen LAN-Clients per "stateless DHCPv6" lediglich DNS-Server-Adressen zugewiesen.

Genauer: Die Fritzbox weist deinen LAN-Clients ihre eigene (ULA-) IPv6-Adresse (die beginnt immer mit fd..) als DNS-Serveradresse zu, so dass alle DNS-Requests stets bei der FB landen. Die fungiert als "DNS-Forwarder" oder auch "DNS-Proxy" und leitet ihrerseis die DNS-Requests weiter an die (externen) DNS-Server, die bei ihr konfiguriert sind.

Erstaunlich, dass IPv6 bei dir gar nicht zum Tragen kommt, denn laut Default-Prefix Policy Table des Betriebssystems sollte IPv6 gegenüber IPv4 bevorzugt werden - hier die Table unter Windows:

C:\>netsh int ipv6 sh pref
Der aktive Status wird abgefragt...

Vorgänger   Label  Präfix
----------  -----  --------------------------------
        50      0  ::1/128
        40      1  ::/0
        35      4  ::ffff:0:0/96
        30      2  2002::/16
         5      5  2001::/32
         3     13  fc00::/7
         1     11  fec0::/10
         1     12  3ffe::/16
         1      3  ::/96

Hinweis: "Vorgänger" ist eine Falschübersetzung von "Precedence" - korrekt wäre die Übersetzung "Vorrang"; und da ist IPv6 mit dem Vorrang "40" höher eingestuft als IPv4 (dargestellt durch den Präfix ::ffff:0:0/96) mit dessen Vorrang 35.

Es könnte evtl. sein, dass dein IPv6 nicht wirklich sauber funktioniert. Testweise Deaktivierung von IPv6 könnte zu einem besseren Wert der durchschnittlichen Ladedauer (aktuell bei dir 0,294s) führen. Test it ...

Lass doch mal diesen Test (http://he.test-ipv6.com/) mit der Default-Einstellung N=1 bis zu einem Count von 100 laufen und poste dann die Ergebnistabelle.

Bei meinem DG-Anschluss sieht das bspw. so aus:

Bei mir kommt immer IPv6 zum Zug, und das ohne Errors oder Timeouts. Mittlere Ladedauer 0,184s.

Zitat von Edding

Afaik betreibt Die DG aber nur an 2 Standorten BNGs Frankfurt und Düsseldorf.

Gemäß dieser RIPE-DB-Anfrage gibt es noch weitere BNG-Cluster (im angezeigten Suchergebnis nach "BNG" suchen) in (mindestens) Hannover, Hamburg und Nürnberg. Zum BNG-Cluster mit der der Kundenseite zugewandten Adresse 100.124.1.92 (IPv4-Traceroute oben) gehört auf der Internetseite die IPv6-Adresse 2a00:6020:ffff:ffff::58 (die man in Inbound-Traceroutes für IPv6 sieht), und er bedient den IPv6-Block 2a00:6020:ad00::/41 für angeschlossene Kundennetze. Leider ist dieser /41-Block im Suchergebnis der referenzierten RIPE-DB-Anfrage nicht enthalten - insofern ist nicht klar, an welchem BNG der OP hängt. Die vier RIPE-Atlas-Probes #19341, #22558, #29722 und #100625 hängen jedenfalls am selben BNG-Cluster wie der Anschluss des OP und laut MAP für die Lokalisierungen dieser Probes ist der BNG-Cluster Frankfurt naheliegend.

Zitat von Edding

Hmm könntest ipv6 trace nochmal mit Windows versuchen ?
Leider Antwortet HOP2 nicht was wichtig gewesen wäre.

Die BNG der DG antworten in IPv6-Outbound-Traceroutes (leider) grundsätzlich nicht.

Mein DG-Anschluss hängt am BNG Nürnberg. Hier zum Vergleich meine Traceroutes zu heise.de:

C:\>tracert heise.de

Routenverfolgung zu heise.de [2a02:2e0:3fe:1001:302::]
über maximal 30 Hops:

  1     2 ms     4 ms    <1 ms  2a00:6020:47PQ:RS00:e208:55ff:feNN:NNN
  2     *        *        *     Zeitüberschreitung der Anforderung.
  3     *        *        *     Zeitüberschreitung der Anforderung.
  4     5 ms     7 ms     7 ms  2a00:6020:0:33::2
  5     *        *        *     Zeitüberschreitung der Anforderung.
  6     5 ms     6 ms     6 ms  ae2-2025.fra30.core-backbone.com [2a01:4a0:0:2025::31]
  7     6 ms     *        8 ms  2a01:4a0:1338:95::2
  8     6 ms     7 ms     7 ms  2a02:2e0:14:6::1
  9     6 ms     8 ms     6 ms  2a02:2e0:3fe:0:c::1
 10     7 ms     6 ms     6 ms  redirector.heise.de [2a02:2e0:3fe:1001:302::]

Ablaufverfolgung beendet.

C:\>tracert -4 heise.de

Routenverfolgung zu heise.de [193.99.144.80]
über maximal 30 Hops:

  1    <1 ms    <1 ms    <1 ms  fritz.box [192.168.178.1]
  2     3 ms     2 ms     3 ms  100.124.1.26
  3     *        *        *     Zeitüberschreitung der Anforderung.
  4     *        *        *     Zeitüberschreitung der Anforderung.
  5     9 ms     7 ms     7 ms  ipv4.de-cix.fra.de.as12306.plusline.net [80.81.192.132]
  6     8 ms     7 ms     7 ms  82.98.102.71
  7     7 ms     5 ms     7 ms  212.19.61.13
  8     9 ms     5 ms     9 ms  redirector.heise.de [193.99.144.80]

Ablaufverfolgung beendet.

Da liege ich mit 6-8 ms wohl im Mittelfeld.

Bspw. Probe #19341 zeigt jedenfalls auch einen Latenzanstieg zu Well-known-Zielen ab etwa heute 07:40 (UTC):

Hier zur Illustration mal der Paketmitschnitt eines etwa 6-stündigen Kampfes meiner damaligen Fritzbox 7590 um den Bezug von IPv6-Adressen (IPv4 war damals ebenfalls betroffen). Ich hatte vorab (30.09.2022, ~20:00) bemerkt, dass die IPv4- bzw. IPv6-Internetverbindungen (zeitlich abwechselnd) zur DG zickten und geistesgegenwärtig den FB-Paketmitschnitt gestartet, um das Drama als Beweisstück live mitzuschneiden:

(Wireshark-Ansichtsfilter: "dhcpv6.xid==0x1bb801" + obfuscated):
No.	Time						Source						Destination					Protocol	Length	Info
57	2022-09-30 22:51:45,913383	fe80::9a9b:cbff:feNN:NNNN	ff02::1:2					DHCPv6		181		Solicit XID:   0x1bb801 CID: 00030001989bcbNNNNNN 
58	2022-09-30 22:51:46,965400	fe80::9a9b:cbff:feNN:NNNN	ff02::1:2					DHCPv6		181		Solicit XID:   0x1bb801 CID: 00030001989bcbNNNNNN 
59	2022-09-30 22:51:48,993437	fe80::9a9b:cbff:feNN:NNNN	ff02::1:2					DHCPv6		181		Solicit XID:   0x1bb801 CID: 00030001989bcbNNNNNN 
60	2022-09-30 22:51:53,141353	fe80::9a9b:cbff:feNN:NNNN	ff02::1:2					DHCPv6		181		Solicit XID:   0x1bb801 CID: 00030001989bcbNNNNNN 
61	2022-09-30 22:52:01,373383	fe80::9a9b:cbff:feNN:NNNN	ff02::1:2					DHCPv6		181		Solicit XID:   0x1bb801 CID: 00030001989bcbNNNNNN 
	[Internetverbindung IPv6 konnte nicht hergestellt werden: Keine Antwort vom DHCPv6-Server (SOL)]
62	2022-09-30 22:52:17,757382	fe80::9a9b:cbff:feNN:NNNN	ff02::1:2					DHCPv6		181		Solicit XID:   0x1bb801 CID: 00030001989bcbNNNNNN 
63	2022-09-30 22:52:50,557403	fe80::9a9b:cbff:feNN:NNNN	ff02::1:2					DHCPv6		181		Solicit XID:   0x1bb801 CID: 00030001989bcbNNNNNN 
64	2022-09-30 22:53:56,149385	fe80::9a9b:cbff:feNN:NNNN	ff02::1:2					DHCPv6		181		Solicit XID:   0x1bb801 CID: 00030001989bcbNNNNNN 
65	2022-09-30 22:56:07,357499	fe80::9a9b:cbff:feNN:NNNN	ff02::1:2					DHCPv6		181		Solicit XID:   0x1bb801 CID: 00030001989bcbNNNNNN 
67	2022-09-30 23:00:29,789523	fe80::9a9b:cbff:feNN:NNNN	ff02::1:2					DHCPv6		181		Solicit XID:   0x1bb801 CID: 00030001989bcbNNNNNN 
69	2022-09-30 23:09:14,685490	fe80::9a9b:cbff:feNN:NNNN	ff02::1:2					DHCPv6		181		Solicit XID:   0x1bb801 CID: 00030001989bcbNNNNNN 
70	2022-09-30 23:26:44,509363	fe80::9a9b:cbff:feNN:NNNN	ff02::1:2					DHCPv6		181		Solicit XID:   0x1bb801 CID: 00030001989bcbNNNNNN 
74	2022-10-01 00:01:44,189357	fe80::9a9b:cbff:feNN:NNNN	ff02::1:2					DHCPv6		181		Solicit XID:   0x1bb801 CID: 00030001989bcbNNNNNN 
75	2022-10-01 00:58:32,317417	fe80::9a9b:cbff:feNN:NNNN	ff02::1:2					DHCPv6		181		Solicit XID:   0x1bb801 CID: 00030001989bcbNNNNNN 
76	2022-10-01 01:02:32,337991	fe80::ff:fe05:101			fe80::9a9b:cbff:feNN:NNNN	DHCPv6		100		Advertise XID: 0x1bb801 CID: 00030001989bcbNNNNNN 
77	2022-10-01 02:00:30,057495	fe80::9a9b:cbff:feNN:NNNN	ff02::1:2					DHCPv6		181		Solicit XID:   0x1bb801 CID: 00030001989bcbNNNNNN 
	[Internetverbindung IPv6: DHCPv6-Fehler mit Fehlergrund 8 ()]
78	2022-10-01 02:58:00,285604	fe80::9a9b:cbff:feNN:NNNN	ff02::1:2					DHCPv6		181		Solicit XID:   0x1bb801 CID: 00030001989bcbNNNNNN 
	[Internetverbindung IPv6 konnte nicht hergestellt werden: Keine Antwort vom DHCPv6-Server (SOL)]
79	2022-10-01 03:57:15,293478	fe80::9a9b:cbff:feNN:NNNN	ff02::1:2					DHCPv6		181		Solicit XID:   0x1bb801 CID: 00030001989bcbNNNNNN 
80	2022-10-01 04:58:33,057486	fe80::9a9b:cbff:feNN:NNNN	ff02::1:2					DHCPv6		181		Solicit XID:   0x1bb801 CID: 00030001989bcbNNNNNN 
81	2022-10-01 04:58:33,073026	fe80::ff:fe05:101	fe80::9a9b:cbff:feNN:NNNN			DHCPv6		223		Advertise XID: 0x1bb801 CID: 00030001989bcbNNNNNN IAA: 2a00:6020:1000:42::WXYZ 
82	2022-10-01 04:58:33,073502	fe80::9a9b:cbff:feNN:NNNN	ff02::1:2					DHCPv6		227		Request XID:   0x1bb801 CID: 00030001989bcbNNNNNN IAA: 2a00:6020:1000:42::WXYZ 
83	2022-10-01 04:58:34,021499	fe80::9a9b:cbff:feNN:NNNN	ff02::1:2					DHCPv6		227		Request XID:   0x1bb801 CID: 00030001989bcbNNNNNN IAA: 2a00:6020:1000:42::WXYZ 
85	2022-10-01 04:58:34,238941	fe80::ff:fe05:101	fe80::9a9b:cbff:feNN:NNNN			DHCPv6		223		Reply XID:     0x1bb801 CID: 00030001989bcbNNNNNN IAA: 2a00:6020:1000:42::WXYZ 
	[Internetverbindung IPv6 wurde erfolgreich hergestellt. IP-Adresse: 2a00:6020:1000:42::WXYZ]
	[IPv6-Präfix wurde erfolgreich bezogen. Neues Präfix: 2a00:6020:46PQ:RS00::/56]

Besonderheiten:

• Die Eventlog-Messages meiner Fritzbox habe ich jeweils in [ ] unter die Mitschnitt-Zeilen geschrieben, deren Uhrzeit mit der Uhrzeit der Eventlog-Message übereinstimmen.
• Die "Advertise"-Message (No. 76) enthielt den DHCPv6-Status-Code "UnspecFail"

Man sieht sehr schön, dass die Fritzbox die Zeitabstände, beginnend mit 1s, zwischen den Wiederholungen ihrer DHCPv6-Solicits stets verdoppelt ("exponential backoff": 1, 2, 4, 8, 16, ..., 2048) und anschließend (ab No. 75) in konstanten Abständen von ~1h sendet.

Ob die Eventlog-Message "DHCPv6-Fehler mit Fehlergrund 8" (No. 77), die auch der OP erwähnt, in meinem Fall aufgrund des vorangegangenen "UnspecFail"-Advertise oder aufgrund der schon lange verstrichenen Zeit (~3,5h) erfolgloser Bemühung angezeigt wird, vermag ich nicht zu beurteilen. Überhaupt ist das Fehlermitteilungsverhalten der Fritzbox sehr sparsam und kryptisch ...

Ich hatte den DG-GF-Anschluss damals seit etwa einem Jahr - in dieser Zeit kam es gelegentlich zu solchen Ausfällen, deshalb war ich auch schon entsprechend sensibilisiert. Seitdem läuft mein Anschluss aber stabil, und ich hoffe, das bleibt auch so (klopf auf Holz).

Zitat von CityCobra

IPv6-Adresse: 2a00:6020:1000:xxx
IPv6-Präfix: 2a00:6020:b40f:da00::/56

Der Anschluss müsste somit am "BNG-Cluster 4" Düsseldorf hängen ("alte" IPv6-Provisionierung, u.a. auch zuständig für den Block 2a00:6020:b400::/41) - dieser taucht in Inbound-Traceroutes mit der Adresse 2a00:6020:ffff:ffff::3 auf.

Die WAN-Adresse müsste genauer in 2a00:6020:1000:1a::/112 liegen (die letzten 4 Ziffern sind individuell für deinen Anschluss, genauso wie die Ziffern "0f:da" deines Anschlusses im /56-Präfix)

Nachtrag:

Dieser Traceroute bestätigt es:

Dein WAN-Interface lässt sich auch anpingen - Standard bei Fritzboxen.

Zitat von pufferueberlauf

Dass die DG momentan ihre IPv6-Provisionierung aendert ist kein Geheimnis und auch nicht, dass das nicht so geschmeidig und unauffaellig ablaeuft wie man sich das wuenschen wuerde.

Nach meinen Beobachtungen aufgrund der vielen Fälle, die wir hier im Forum schon hatten, stellt man bisher offenbar keine Bestands-Anschlüsse um, die nach alter IPv6-Provisionierung funktionieren (erkennbar an den WAN-Port-Adressen aus 2a00:6020:1000::/48 bzw. genauer 2a00:6020:1000:XX::/112, wobei XX eine spezifische 2-stellige Kennung des BNG-Clusters ist).

Die neue Provisionierung erfolgt bisher offenbar nur für IPv6-Ranges, die bisher nicht für Bestandsanschlüsse mit Alt-Provisionierung verwendet wurden - hier eine (sicherlich unvollständige) Liste aus meiner Statistik (wie bei der Alt-Provisionierung sind es jeweils /41-Ranges pro BNG-Cluster), Stand 07.08.2026:

Diese Ranges kommen vorrangig in BW, teilweise auch in RP und SL zum Einsatz, also grob im Südwesten der Republik.

Ob IPv6 beim Anschluss des OP nach neuer IPv6-Provisionierung erfolgt, wissen wir leider nicht, solange der zugeordnete IPv6-Präfix bzw. die WAN-Port-Adresse nicht bekannt sind.

Nachtrag 20.06.2026:

Entgegen meiner Aussage oben scheint DG nun doch auch Bestandsanschlüsse mit "alter" IPv6-Adress-Provisionierung" auf die "neue" umzustellen. Das kann man z.B. an der RIPE-Atlas-Probe #53717 (NW: PLZ 41472) sehen, die heute um ~ 08:10 (UTC) vom alten IPv6-Präfix 2a00:6020:a302:5100::/56 (am BNG 100.124.1.60/2a00:6020:ffff:ffff::41) auf den Präfix 2a00:6020:6940:9::/64 (!) umgestellt wurde (/64 statt /56 folgere ich mit hoher Wahrscheinlichkeit aus der "kaputten" ":9::" im Präfix - neue IPv6-Adress-Provisionierung aus dem Auftauchen der "BNG-Verschleierungsadresse" fc00::1 in Traceroutes "von außen" zur Netzadresse des Anschlusses)

Prompt sendet die Probe ab Umstellung keine IPv6-Daten mehr:

Zitat von ctr

Meine Interface IP hat sich vom Block `2a00:6020:1000:41::` in `2a00:6020:1000:40::`und das announcte Präfix von `2a00:6020:5080::/41` in `2a00:6020:5000::/41` (41bit maske laut info von user ::1) geändert

Wie man mit dieser RIPE-Abfrage ermitteln kann, werden beide Blöcke (aggregiert: 2a00:6020:5000::/40) durch den "Frankfurt-BNG-Cluster1" bedient:

Die Wartung bestand wohl u.a. darin, die DG-Kundenanschlüsse Cluster-intern umzuverteilen ...

Diese RIPE-Atlas-Probe (2a00:6020:50c7:5f00:a2f3:c1ff:fec4:5c01) müsste am selben BNG (2a00:6020:ffff:ffff::e, 100.124.1.11) hängen wie dein Anschluss - sie ist allerdings "connected" und liefert IPv6-results. Es scheinen also nicht alle Anschlüsse an diesem BNG betroffen zu sein.