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]
Dabei sind die "Kommerziellen" Google und Facebook weltweit bestens "connected".
Anders sieht das schon für eine NPO wie Wikipedia aus:
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.
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".
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.
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.80Die Ergebnisse müssen genau so aussehen wie gezeigt.
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 ::/96Hinweis: "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.
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.
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:
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).
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.
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 05.06.2026:
| PD-Block (/56) aus: | WAN-Port-Adresse aus: |
|---|---|
| 2a00:6020:5380::/41 | 2a00:6020:53c0::/112 |
| 2a00:6020:5c80::/41 | 2a00:6020:5c80::/112 |
| 2a00:6020:6900::/41 | 2a00:6020:6900::/112 |
| 2a00:6020:7300::/41 | 2a00:6020:7300::/112 |
| 2a00:6020:7380::/41 | 2a00:6020:7380::/112 |
| 2a00:6020:7680::/41 | 2a00:6020:7680::/112 |
| 2a00:6020:7700::/41 | 2a00:6020:7700::/112 |
| 2a00:6020:7800::/41 | 2a00:6020:7800::/112 |
| 2a00:6020:7880::/41 | 2a00:6020:7880::/112 |
| 2a00:6020:8f00::/41 | 2a00:6020:8f00::/112 |
| 2a00:6020:9100::/41 | 2a00:6020:9100::/112 |
| 2a00:6020:9400::/41 | 2a00:6020:9400::/112 |
| 2a00:6020:9480::/41 | 2a00:6020:9480::/112 |
| 2a00:6020:9800::/41 | 2a00:6020:9800::/112 |
| 2a00:6020:9a80::/41 | 2a00:6020:9a80::/112 |
| 2a00:6020:9c80::/41 | 2a00:6020:9c80::/112 |
| 2a00:6020:bb00::/41 | 2a00:6020:bb00::/112 |
| 2a00:6020:c700::/41 | 2a00:6020:c700::/112 |
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:
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.
Derzeit habe ich noch eine Interface IP aus dem 2a00:6020:1000:41:: Block und quasi-statische IPv6.
Da müsstest du so im PLZ-Gebiet 66xxx/67xxx (SL/RP) liegen (IPv6-Range 2a00:6020:5080::/41) - ich habe noch nicht gesehen, dass dort auf das "neue" Adresskonzept umgestellt wird.
Korrektur:
In SL gibt es tatsächlich eine RIPE-Atlas-Probe (#29306), die an einem DG-Anschluss mit "neuem" Adresskonzept hängt (IPv6-Range 2a00:6020:5380::/41).
Die Gegenstelle sendet NS und und NA
Ist denn in den NA der Gegenstelle das R-Flag gesetzt? Ich vermute mal, nein. Denn andernfalls hätte die Unify-Selbst-Konstruktion der Gateway-Adresse evtl. funktioniert.