Mal wieder: Kein IPv6 bei Deutsche Glasfaser

Zitat von Luki

Sehr merkwürdig - ab und zu ist die Verbindung da und ping bring zurück eine richtige und korrekte Rückmeldung, siehe Anhang - die Datei habe ich archiviert, da sie sonst zu lang ist.

Das hatte ich als Möglichkeit in #329 schon in Betracht gezogen - ich kopiere es mal:

"
Noch ein Nachtrag:

Zumindest für kurze Zeit scheint dein IPv6-Access (inbound + outbound) zu funktionieren. Ich vermute immer dann, wenn deine Fritzbox einen RA von der DG-Gegenstelle erhält und daraus die MAC-Adresse 20:00:00:00:20:38 der Gegenstelle lernt. Solange sie diese in ihrem Neighbor-Cache speichert (dürfte allerdings nur ein paar Sekunden sein), kann IPv6-Kommunikation erfolgen. Das könnte man per Dauer-Ping bei gleichzeitigem Langzeit-Paketmitschnitt (~ 2 Stunden) , der ein paar erhaltene RA umfasst, evtl. verifizieren. Zur Ansicht in Wireshark den Filter "icmpv6" setzen.

Nachtrag 2:

Gemäß deinem ersten Mitschnitt empfängst du etwa alle 30 Minuten einen RA (die Router-Lifetime im RA ist mit 4500s recht lang, deshalb auch die großen RA-Zeitabstände). Auch ohne Paketmitschnitt: Wenn Du mal einen IPv6-Dauerping machst, könnte es sein, dass du etwa alle 30 Minuten für ein paar Sekunden Antworten bekommst, wenn meine Annahme zutreffend ist.

"

Deine Datei zeigt Ping-Antworten, z.B. im Zeit-Intervall: 2025-08-12 15:51:59 - 2025-08-12 15:54:55, also für 176 Sekunden - solange hat die Fritzbox vermutlich die MAC-Adresse 20:00:00:00:20:38 der DG-Gegenstelle im Neigbor-Cache des WAN-Ports gespeichert, kurz zuvor hat sie diese wohl über ein von DG erhaltenes RA gelernt. Ich vermute, der Zeitabstand zwischen Ping-Erfolgen entspricht dem Abstand zwischen zwei erhaltenen RA:

2025-08-12 15:51:59
2025-08-12 16:21:58
2025-08-12 16:51:58
2025-08-12 17:21:57
:

Kommt ganz gut hin: RA-Empfang so etwa alle 30 Minuten.

Noch ein Nachtrag:

Ich ergänze nochmal folgenden Auszug aus #372:

"Deine Paketmitschnitte zeigten, dass dein Router outbound keinerlei IPv6-Pakete mit globalen IPv6-Zieladressen senden kann, weil die MAC-Adressauflösung (per NS/NA) der DG-Defaultgateway-Adresse (fe80::22) scheitert: Dein Router sendet ständig NS an die zu fe80::22 gehörende SNMA = ff02::1:ff00:22 ("solicited node mulitcast addess"), die von der Gegenstelle jedoch nicht per NA beantwortet werden. Ausgehende IPv6-Pakete können deshalb nicht in Ethernet-Frames eingepackt werden - dein Router muss sie verwerfen."

Somit hast du nun eine schlüssige Diagnose, die du mit einem deiner Paketmitschnitte (derjenige, der die vielen NS an ff02::1:ff00:22 zeigt, die von der DG-Gegenstelle nicht beantwortet werden) und deiner Textdatei mit dem Ping-Log technisch belegen kannst.

Schön wäre noch ein langer Paketmitschnitt (~2h) am WAN-Port, der die erfolgreichen Pings, die kurz zuvor erhaltenen RA und die dazwischen liegenden NS an ff02::1:ff00:22 bei entsprechender Filtersicht (icmpv6) zeigt.

Kurzes Update meinerseits:

Telefonie geht nun an unseren beiden Anschlüssen, an einem nach Ticket und ca. 5 Tagen warten, am anderen Anschluss erst nach Portierungstag vom Altanbieter (Ticket hing vorher ca. 1 Woche ab). Die Übergangsrufnummer ging nie. Einen Tag nach der Portierung tauchte die Nummer dann auch im Kundenportal auf.

Zurück zum Hauptthema:

• Beim Anschluss mit FB 5690 Pro hinter FiberTwist ist das IPv6-Problemticket noch offen (als "technische Anfrage" vom Telefonsupport aufgenommen). Das Ticket hatte ich durch Anruf eröffnen lassen, nachdem das letzte Ticket davor (Netz 4.0) vor einer Woche kommentarlos geschlossen wurde, und meine selbst eröffneten Tickets davor nur Standardantworten bekommen haben.
• Beim Anschluss mit FB 5690 Pro direkt am Glas hieß das letzte IPv6 Problemticket auch Netz 4.0. Wurde heute Nachmittag kommentarlos (ohne Mail oder so) geschlossen. Grau im Kundenportal, also nicht einsehbar. Angerufen, scheinbar stand da nur dran, dass es wieder ginge. Neues Ticket eröffnet, heißt auch Netz 4.0.

Immerhin ist der Telefonsupport bisher (bis auf eine Ausnahme, die sehr unfreundlich war) sehr freundlich, kann aber solche Probleme natürlich nur aufnehmen. Einen Rückruf von einem Techniker oder so habe ich leider noch nicht erhalten.

Ich bleibe also auch hartnäckig, aber freundlich. Die Fritz!Box habe ich so konfiguriert, dass IPv6 weiterhin an ist, aber intern Router Advertisements und DHCPv6 aus. Damit ist die Box theoretisch von außen per IPv6 pingbar, sobald das Problem gelöst ist, und die Clients im Hausnetz haben keine Probleme, weil sie nichts vom IPv6-Präfix wissen.

Sehr löblich. Es sollte natürlich Standard sein, dass man freundlich und respektvoll miteinander umgeht.

Schade, dass DG das im Moment so wenig beherzigt.

olifre, bist Du auch in NRW und auch noch in der Nähe von 47906 Kempen? Ich auch habe das Problem noch nicht gelöst bekommen, trotz die tägliche oder zweitägigen Telefonate mit Kundendienst.

Die Rufnummer Portierung soll erst am 18.8.25 stattfinden, Ich melde mich danach mit Ergebnissen oder soll ich das liber in einem anderen Thema melden/berichten?

Ein anderer/eigener Thread wäre schon sinnvoll, wenn es um Telefonie und nicht um IPv6-Problematiken geht. Telefonie bei Deutsche Glasfaser ist nach aktuellem Kenntnisstand IPv4-only.

Zitat von HubeBube

Telefonie bei Deutsche Glasfaser ist nach aktuellem Kenntnisstand IPv4-only.

Das wird durch ständige Wiederholung nicht wahrer:

C:\>nslookup
Standardserver:  localhost
Address:  ::1

> set q=SRV
> _sip._udp.dg.voip.dg-w.de
Server:  localhost
Address:  ::1

Nicht autorisierende Antwort:
_sip._udp.dg.voip.dg-w.de       SRV service location:
          priority       = 20
          weight         = 1
          port           = 5060
          svr hostname   = sip20.voip.dg-w.de
_sip._udp.dg.voip.dg-w.de       SRV service location:
          priority       = 10
          weight         = 1
          port           = 5060
          svr hostname   = sip10.voip.dg-w.de
> set q=A+AAAA
> sip10.voip.dg-w.de
Server:  localhost
Address:  ::1

Nicht autorisierende Antwort:
Name:    sip10.voip.dg-w.de
Addresses:  2a00:6020:100:603::186
          185.22.44.186

> sip20.voip.dg-w.de
Server:  localhost
Address:  ::1

Nicht autorisierende Antwort:
Name:    sip20.voip.dg-w.de
Addresses:  2a00:6020:200:603::165
          185.22.45.165

Meine Fritzbox führt als SIP-Client die SIP-Registrierungen per IPv6 durch, auch die Sprachübertragung eines Telefongesprächs via RTP läuft bei mir via IPv6 - alles auch per Paketmitschnitt verifiziert.

In der Rufnummern-Konfiguration der DG-Rufnummern kann man das gewünschte Protokoll (IPv4 und oder IPv6) einstellen.

OK, dann Danke für diese Info und vor allem für die proaktive Überprüfung des Sachverhaltes.

Seit wann die Telefonie ebenfalls via IPv6 möglich ist, weißt Du nicht zufällig?

Es war ja sowieso in einer Dual Stack CGNAT Infrastruktur nicht wirklich nachvollziehbar, warum die Telefonie nur über IPv4 realisiert worden ist.

Zitat von HubeBube

Seit wann die Telefonie ebenfalls via IPv6 möglich ist, weißt Du nicht zufällig?

Mein ältester Paketmitschnitt, in dem ich das verifiziert hatte, stammt vom 01.09.2022. Den Anschluss habe ich seit 10/2021.

Ich vermute mal, die Aussage "geht nur via IPv4" resultiert daraus, dass "dg.voip.dg-w.de" nur nach IPv4 auflöst (185.22.44.186).

Ich habe auch erst durch Paketmitschnitte mitbekommen, dass der SIP-Service via SRV-RR erfragt wird, siehe meine NSLOOKUP-Ausgabe im letzten Post, die das Verhalten der Fritzbox (wie per Paketmitschnitt ermittelt) nachbildet.

Zitat von Luki

olifre, bist Du auch in NRW und auch noch in der Nähe von 47906 Kempen? Ich auch habe das Problem noch nicht gelöst bekommen, trotz die tägliche oder zweitägigen Telefonate mit Kundendienst.

In RLP, aber ganz im Norden, ich kann recht schnell zu Fuß nach NRW laufen. Ist aber eine 53xxx PLZ. Recht neues Anschlussgebiet, es werden auch noch weitere Hausanschlüsse aktiviert, und ich merke, wie die letzte Stelle der IPv6-Adresse, die dem Router zugeteilt wird, bei Neuverbinden manchmal wächst.

Update heute: Wieder wurde ein Ticket geschlossen, das "technische Anfrage"-Ticket, mit "Unsere technische Abteilung hat Ihren Anschluss geprüft und keine Unstimmigkeiten gefunden.". Ich habe diesmal mal per Mail mit einem Traceroute und der Info, dass Pings nicht durchgehen, geantwortet, das geht ja in Textform (Packet Captures kann man ja nicht anhängen).

Das hatte ich schonmal versucht und da nur den Standardtext bekommen, dass es IPv4 per CGNAT und echte IPv6 gibt, also nicht so ganz mit meiner Frage korreliert.

Zitat von olifre

(Packet Captures kann man ja nicht anhängen)

müsste als komprimierte ZIP-Datei schon möglich sein.

Zitat von ::1

müsste als komprimierte ZIP-Datei schon möglich sein.

Oh! Ich hatte übersehen, dass auch ZIP im Kontaktformular geht...

Das ist dann was als Follow-Up für das nächste Ticket, was zugemacht wird, danke für den Hinweis :-). Bin gespannt, ob das hilft, ein Wireshark-Screenshot wurde bei meinem letzten Versuch leider kommentarlos ignoriert.

Es kann auch sinnvoll sein, aus Platzgründen oder weil die Editier-Möglichkeiten im Kontaktformular für die Ticket-Erfassung recht "elementar" sind, das Problem ausführlich in einem Word-Dokument zu beschreiben, das man als PDF speichert und als Attach beifügt. So kann man den Beschreibungstext des Tickets sehr kurz halten und auf die ausführliche Beschreibung im angehängten PDF verweisen.

So bin ich ebenfalls vorgegangen. Alles was in Schriftform vorgelegen hat (Logauszüge, Kommentare/Erklärungen,...) in ein einziges PDF umgewandelt und im Kontaktformular auf die Inhalte der PDF-Datei hingewiesen.

Ob jemand den Text oder die PDF-Datei gelesen oder womöglich sogar verstanden hat, vermag ich nicht zu sagen.

Zitat von HubeBube

[...] Ob jemand den Text oder die PDF-Datei gelesen oder womöglich sogar verstanden hat, vermag ich nicht zu sagen.

Bei meinen Telefonie-Tickets habe ich auch mal einen Screenshot des Kundenportals mitgeschickt und geschrieben, "im Kundenportal (siehe Anhang) sind keine Rufnummern sichtbar". Da eine Standardantwort zurückkam, wie man im Kundenportal an die Stelle kommt, wo ich den Screenshot gemacht habe, weiß ich, dass der Anhang nicht angeschaut wurde...

Zurück zum Thema: Heute wurde mein schriftliches Ticket geschlossen, Anleitung zum ONT-Reset kam zurück (für die Nokia-Modelle, hier ist ein FiberTwist verbaut).

Habe den Reset natürlich brav gemacht, drauf hingewiesen, dass man mir das schonmal empfohlen hat und ich das schonmal gemacht habe, und dass das Problem weiterhin besteht, also ping und traceroute auf die IPv6 von außen nicht gehen. Man hat auch nach der Modem-GPON-SN gefragt, habe ich geschickt.

Sobald wieder etwas mit "Technik hat geprüft, alles ok" geschlossen wird, mache ich auch mal ein PDF, bin aber in der Tat auch skeptisch, dass es gelesen wird.

Zitat von olifre

dass das Problem weiterhin besteht, also ping und traceroute auf die IPv6 von außen nicht gehen

Wäre es evtl. nicht erst mal naheliegender nachzuweisen, dass IPv6 outbound ebenfalls nicht funktioniert?

Möglicherweise hat das ja in deinem Fall dieselben Ursachen, die ich in #381 beschrieben habe. Falls so, wäre es aus meiner Sicht viel effizienter, die eigentliche Ursache des Problems konkret zu benennen: Nämlich, dass die Hardware-Adressauflösung für IPv6 (per NS/NA) outbound nicht funktioniert, weil die DG-Gegenstelle die von deinem Router gesendeten NS nicht per NA beantwortet.

Alles Andere (nämlich, dass IPv6 outbound und inbound nicht oder ggf. nur sporadisch funktionieren) wäre dann nur eine Folge des Kernproblems.

Freilich müsste man das für deinen Fall erst Mal durch einen Paketmitschnitt am WAN-Port verifizieren - möglicherweise liegen deinem Problem ja doch andere Ursachen zugrunde, als dem von Luki .

Zitat von ::1

Wäre es evtl. nicht erst mal naheliegender nachzuweisen, dass IPv6 outbound ebenfalls nicht funktioniert?

Möglicherweise hat das ja in deinem Fall dieselben Ursachen, die ich in #381 beschrieben habe. Falls so, wäre es aus meiner Sicht viel effizienter, die eigentliche Ursache des Problems konkret zu benennen: Nämlich, dass die Hardware-Adressauflösung für IPv6 (per NS/NA) outbound nicht funktioniert, weil die DG-Gegenstelle die von deinem Router gesendeten NS nicht per NA beantwortet.

Ja, das stimmt natürlich. Meine Annahme war, dass "ping von außen geht nicht" einfacher zu reproduzieren ist, damit das Problem als Solches akzeptiert und in die Technik weitergereicht wird.

Zitat von ::1

Freilich müsste man das für deinen Fall erst Mal durch einen Paketmitschnitt am WAN-Port verifizieren - möglicherweise liegen deinem Problem ja doch andere Ursachen zugrunde, als dem von Luki .

Den habe ich schon gemacht, und an ein älteres Ticket bei DG als Wireshark-Screenshot angehangen (und daraufhin die Standardantwort bekommen, dass IPv4 mit CGNAT und echte IPv6 zugeteilt würde, also nicht passend zur Anfrage).

Da ich das noch nicht im Forum geteilt hatte, bei mir sieht man im WAN-Port-Mitschnitt (synchron zu einem ONT-Neustart durchgeführt):

• DHCPv6 Solicit und Reply
• Daraufhin Multicast-Listener-Reports der Fritz!Box an die Gegenstelle
• Ein Router-Advertisement der Gegenstelle
• Outbound IPv6-Traffic der Box z.B. zu IPv6-NTP-Servern, von einem Ping auf `heise.de` den ich gemacht habe etc.

Der Outbound IPv6-Traffic geht korrekt zur MAC der Gegenstelle, die sich als Router announced hat. Es kommt nur Nichts zurück, und dann sieht man Retransmits.

Schließlich schickt die Box einigte NS an die Gegenstelle, und nach dem fünften NS bekommt sie dann auch einen NA von der Gegenstelle zurück.

Bei mir ist das Problem also nicht NA/NS, sondern hier scheint es tatsächlich so zu sein, dass die Pakete hinter der Gegenstelle irgendwo verloren gehen.

Zitat von olifre

Der Outbound IPv6-Traffic geht korrekt zur MAC der Gegenstelle, die sich als Router announced hat. Es kommt nur Nichts zurück, und dann sieht man Retransmits.

Ok - dann ist das Problem hier anders gelagert: Die DG-Infrastruktur routet deine IPv6-Adressen nicht. Hatten wir hier im Forum auch schon.

Zitat von ::1

Ok - dann ist das Problem hier anders gelagert: Die DG-Infrastruktur routet deine IPv6-Adressen nicht. Hatten wir hier im Forum auch schon.

Ja, das passt. Mein Problem scheint sehr analog zu:

Beitrag

RE: Kein Traffic über IPv6 möglich (Deutsche Glasfaser)

gordrin :

Hi again,

ich habe mal, auch weil es mich selbst interessiert, Traceroutes zu diversen DG-IPv6-Zielen an anderen Kundenanschlüssen durchgeführt, und zwar ...

1. ... aus dem Internet von heise online Traceroute
2. ... von meinem Desktop-PC hinter meinem Router am DG-Anschluss.

Als Kandidatenliste von IPv6-Zielen an Kundenanschlüssen habe ich mir RIPE-ATLAS-Probes ausgewählt (solche mit Eintrag 60294 in der Spalte "ASN v6", dann dem Link in der Spalte "ID" folgen, um im "Network"-Tab der…

::1

16. Dezember 2024 um 13:43

zu sein, alle Traceroutes von außen stoppen bei:

[...]
 8  as60294.dusseldorf.megaport.com (2001:7f8:8::eb86:0:1) [*]  6.556 ms * *
 9  2a00:6020:0:b::2 (2a00:6020:0:b::2) [AS8899/AS60294]  7.067 ms 2a00:6020:0:a::2 (2a00:6020:0:a::2) [AS8899/AS60294]  6.586 ms 2a00:6020:0:b::2 (2a00:6020:0:b::2) [AS8899/AS60294]  7.023 ms
10  * * *

Die kommen also nicht durch zum BNG. Von Innen sehe ich gar keine Hops nach der Fritz!Box.

Als ich noch parallel den DSL-Anschluss bei meinem Vorgängerprovider Inexio hatte, der ja inzwischen auch zur DG gehört, endeten Traces von dort zu meinem DG-Anschluss auch bei fc00::1.

Leider war in dem Thread die Lösung aller Threadteilnehmer ja effektiv "warten", aber ich werde hartnäckig dran bleiben, vielleicht hilft es was.

Zitat von olifre

Als ich noch parallel den DSL-Anschluss bei meinem Vorgängerprovider Inexio hatte, der ja inzwischen auch zur DG gehört, endeten Traces von dort zu meinem DG-Anschluss auch bei fc00::1.

Ja, alle alten Inexio-Anschlüsse scheinen in Bezug auf IPv4 zum AS8899 zu gehören, während sie in Bezug auf IPv6 im AS60294 liegen. Die CGNAT-Adressen dieser Anschlüsse scheinen nach meinen Beobachtungen stets im Range "DGW-FTTH-DYNAMIC-FRA1" = 94.31.96.0/20 zu liegen.

Bezüglich der ULA fc00::1 in Traceroutes von "außen" zu DG-Anschlüssen bin ich empirisch inzwischen zu folgender Erkenntnis gelangt:

Für neuere DG-Kundenanschlüsse mit IPv6-Adresszuweisung nach offenbar geändertem/neuen Konzept gilt augenscheinlich, dass in Traceroutes zu diesen Anschlüssen der vorletzte Hop (unmittelbar vor dem Kunden-Router, somit also der BNG) stets mit fc00::1 adressiert ist. Das gilt auch für "funktionierende" DG-Anschlüsse. Man kann aus dem Erscheinen von fc00::1 im Traceroute also nicht auf eine Fehlkonfiguration schließen.

Erstaunlich ist die Sichtbarkeit von IPv6-Paketen mit ULA-Source-Adressen im Internet (hier ICMPv6-Time-Exceeded von fc00::1) allerdings schon: Bei guter Administration des eigenen AS sollten die eigenen eBGP-Router derlei eigentlich filtern bzw. droppen.

Nach meinen Beobachtungen wird derzeit für DG-Kundenanschlüsse in folgenden IPv6-Ranges (ohne Anspruch auf Vollständigkeit) das neue IPv6-Konzept verwendet:

1. 2a00:6020:7380::/41 (PD-Präfixe: 2a00:6020:7380:100::/56 - 2a00:6020:73ff:ff00::/56); WAN-Port-Adresse in 2a00:6020:7380::/112
2. 2a00:6020:7680::/41 (PD-Präfixe: 2a00:6020:7680:100::/56 - 2a00:6020:76ff:ff00::/56); WAN-Port-Adresse in 2a00:6020:7680::/112
3. 2a00:6020:7800::/41 (PD-Präfixe: 2a00:6020:7800:100::/56 - 2a00:6020:787f:ff00::/56); WAN-Port-Adresse in 2a00:6020:7800::/112
4. 2a00:6020:7880::/41 (PD-Präfixe: 2a00:6020:7880:100::/56 - 2a00:6020:78ff:ff00::/56); WAN-Port-Adresse in 2a00:6020:7880::/112
5. 2a00:6020:8f00::/41 (PD-Präfixe: 2a00:6020:8f00:100::/56 - 2a00:6020:8f7f:ff00::/56); WAN-Port-Adresse in 2a00:6020:8f00::/112
6. 2a00:6020:bb00::/41 (PD-Präfixe: 2a00:6020:bb00:100::/56 - 2a00:6020:bb7f:ff00::/56); WAN-Port-Adresse in 2a00:6020:bb00::/112

In diesen Ranges ist der jeweils erste /56-Block ausgenommen, weil aus diesem Range die WAN-Port-Adressen der Kundenrouter gebildet werden. Diese WAN-Port-Adresse ist an funktionierenden Kundenanschlüssen der letzte Hop in Traceroutes - Fritzboxen in der Standardeinstellung liefern hier brav Antworten und sind WAN-seitig auch anpingbar.

Zitat von ::1

Ja, alle alten Inexio-Anschlüsse scheinen in Bezug auf IPv4 zum AS8899 zu gehören, während sie in Bezug auf IPv6 im AS60294 liegen. Die CGNAT-Adressen dieser Anschlüsse scheinen nach meinen Beobachtungen stets im Range "DGW-FTTH-DYNAMIC-FRA1" = 94.31.96.0/20 zu liegen.

Ich hatte damals nach freundlicher Nachfrage noch / wieder eine globale IPv4 bekommen (VPN-Zugang von außen), da zu Vertragsstart noch kein CGNAT gemacht wurde, war man da wohl kulant. Die kam aus 5.100.128.0/22.

Update heute:

• Erneut Mailantwort plus Ticket zu, diesmal wieder mit der Info, ich sollte das ONT resetten. Nun aber Anleitung für den FiberTwist.
  Habe freundlich drauf hingewiesen, dass ich das gestern schon gemacht habe (und auch am 7.8. nach Anruf bei der Hotline), obwohl man mir die andere Anleitung geschickt hatte.
• Habe nun mal ein Ticket als "technische Anfrage" aufgemacht mit Hinweis auf "Problem in der BNG-Konfiguration => kein Routing des Subnetzes", Paketmitschnitt vom WAN-Port als ZIP angehangen, Screenshot vom Heise-Traceroute angehangen. Und Bitte um Weiterleitung in die Technik.

Ich habe wenig Hoffnung, dass sich da was tut, aber immerhin fällt es vielleicht dem First Level schwer, dazu eine Standardantwort auszuwählen. Wenn überhaupt, dann vielleicht wieder die CGNAT-IPv4-IPv6-Standardantwort.