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

Hatte heute Zeit:

• ONT Reset hatte keine Auswirkungen, IPv6 ging wie erwarten danach auch nicht
• FritzBox umgestellt auf die Verwendung einer vorhandenen WAN Verbindung (statt Deutsche Glasfaser als ANbieter) hatte keine Auswirkung, Internet ging, aber kein IPv6.
• FritzBox direkt an die Glasfaser angeschlossen (Provisionierung hatte ich vor einigen Monaten schon gemacht) hatte keine Auswirkung, Internet ging, aber kein IPv6.

Nachdem ich jedoch nur ein GPON Modul in der FritzBox habe, jedoch XGPON scheinbar in der Infrastruktur von Deutscher Glasfaser verwendet wird, habe ich jetzt erstmal wieder den ONT von DG in Verwendung und meine FritzBox dahinter mit DG als Anbieter eingestellt und IPv6 nativ.

Ich hatte bei allen Test Cases die FritzBox wieder auf native Ipv6 umgestellt und jeweils kurz gewartet.

Seltsam ist, bei meinem Bruder (wohnt im gleichen Ort) der am Freitag erst seinen Anschluss bekommen hat funktioniert es. Er hat wie ich den ONT von DG und in seinem Fall einen Asus Router den er in dem Fall nur als Firewall verwendet.

Es deutet also darauf hin, dass das Problem meine Hardware/Anschluss betrifft. Vielleicht müsste DG einfach mal meine Geräte aus deren Infrastruktur reseten?

Zitat von gordrin

Vielleicht müsste DG einfach mal meine Geräte aus deren Infrastruktur reseten?

Ich denke nicht, dass die DG pro Kunde dedizierte "Geräte in ihrer Infrastrukur" betreibt. Auch der "letzte" Router Richtung Kunden-Access-Struktur wird vermutlich mehrere Kundenanschlüsse aggregieren. Es ist vermutlich eher ein Konfigurationsproblem in deren Infrastruktur, wie ich's oben schon mal formuliert habe:

Zitat von ::1

Meine Interpretation: DG schafft es nicht, für deinem Anschluss feste (oder sagen wir: "quasistatische", denn echt "fest" ist nicht garantiert) IPv6-Adressen (IA_NA, IA_PD) zu reservieren, geschweige denn, in der DG-Netzinfrastruktur für den jeweils zugewiesenen PD-Block bzw. die WAN-Port-Adresse eine (Rückwärts-)Route über deine WAN-Leitung zu deinem Router zu generieren.

Das ist zumindest das, was man aus dem bei dir sicht- und analysierbaren Verhalten an deinem Anschluss folgern kann.

Das Problem wird sein, den DG-Support davon zu überzeugen, dass die Problemlösung in deren Infrastruktur zu suchen und zu beheben ist.

Zitat von HubeBube

In meiner Region hatte ich vor ein paar Tagen einen fast 24-stündigen Totalausfall. PON war in Ordnung, jedoch lieferte die DHCP Infrastruktur weder IPv4 noch IPv6 Adressen (natürlich auch kein RA) aus.

Die berichtete Häufung dieser Störung lassen auf große Änderungen in der Infrastruktur schließen. Schließlich will man Equipment von Ekinops integrieren, dazu noch großangelegtes Whitelisting von GPON Endgeräten.

Nachtrag: Ich habe nach dem Ausfall ein traceroute6 angefertigt. Die Änderungen sind im Gegensatz zu hier: RE: Deutsche Glasfaser - Probleme mit einigen Android Apps jedoch minimal und meiner Meinung nach nicht aussagekräftig:

Gibt es Neuigkeiten zum Ausbau von Ekinops? Seit der Ankündigung in den Medien vor einem Jahr habe ich nichts Weiteres darüber gehört.

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 probe-site deren IPv6-Adresse zu erfahren, manche sind sogar von außen anpingbar).

Ergebnisse:

Im Fall 1 (heise online-Traceroutes aus dem Internet) sehe ich stets ...

• ... an Position 5 des Traceroutes eine Adresse aus 2a00:6020::/48 (z.B. 2a00:6020:0:c::2 oder 2a00:6020:0:d::2). Dies dürfte der Übergangspunkt zu DG im DE-CIX Frankfurt sein. In der RIPE-DB wird dieser Block als "InfrastructureGermany" bezeichnet.
• ... an Position 6 des Traceroutes eine Adresse aus 2a00:6020:ffff:ffff::/64 (z.B. 2a00:6020:ffff:ffff::23, 2a00:6020:ffff:ffff::41, 2a00:6020:ffff:ffff::58). In der RIPE-DB wird dieser Block als "BNG-Cluster-DHCPv6-Link-Address" bezeichnet. BNG steht hier vermutlich für "Broadband Network Gateway"

Im Fall 2 (Traceroute von meinem Desktop-PC am DG-Kundenanschluss) sehe ich stets ...

• ... an Position 3 jeweils dieselbe Adresse aus dem Block "BNG-Cluster-DHCPv6-Link-Address", die beim Traceroute von heise online an Position 6 auftaucht, s.o.

Wenn ich nun die beiden Traceroute-Varianten für deine IPv6-Adresse am WAN-Port deiner Fritzbox durchführe (wie in einem früheren Post erwähnt, kann ich die jeweils aktuelle ermitteln), komme ich abweichend zu folgenden Ergebnissen:

Im Fall 1 (heise online-Traceroutes aus dem Internet) sehe ich ...

• ... der Trace endet in Position 5 bei 2a00:6020:0:c::2, kommt also über den Übergangspunkt zur DG im DE-CIX Frankfurt nicht hinaus.

Im Fall 2 (Traceroute von meinem Desktop-PC am DG-Kundenanschluss) sehe ich ...

• ... in Position 3 anstelle einer Adresse aus dem Block "BNG-Cluster-DHCPv6-Link-Address" nur die ominöse ULA-Adresse fc00::1, an dem der Trace endet (bzw. kommen danach nur noch Timeouts)

Das betätigt nochmals aus einer weiteren Perspektive, dass in der DG-Netzinfrastruktur (zumindest) das Rückwärts-Routing zu den IPv6-Adressen an deinem DG-Anschluss nicht funktioniert.

Hi danke für die weitere Analyse und die damit verbundenen Informationen.

Beunruhigt bin ich ein wenig über die tatsache, dass du meine IPv6 immer herausfindest. War in dem Wireguard mitschnitt meine fritz dyndns Adresse mit drin nicht wahr?

Beruhigt bin ich aber weil es nicht mein Fehler ist. Jetzt muss ich das nur dem Kundenservice verständlich machen.

Viele Grüße Stefan

Hallo, zusammen.

Solltet ihr irgendwie weiterkommen oder sogar einen Erfolg erzielen, gebt es bitte hier weiter. Auch ich beiße bei der DG auf Granit, absolut gleiches Problem (IPv6 erhalten, IPv6-Kommunikation nicht möglich; IPv4 ohne Probleme).

Viele Grüße

Zitat von geckoespresso

Hallo, zusammen.

Solltet ihr irgendwie weiterkommen oder sogar einen Erfolg erzielen, gebt es bitte hier weiter. Auch ich beiße bei der DG auf Granit, absolut gleiches Problem (IPv6 erhalten, IPv6-Kommunikation nicht möglich; IPv4 ohne Probleme).

Viele Grüße

Ich habe das selbe Problem wie du auch und ich habe seit dem 09.01.2025 keine Antwort mehr bekommen auf die Wiedereröffnung meines Tickets.

Seit Anfang Dezember letztes Jahr wurde mein Ticket dazu bereits 4 mal als "erledigt" geschlossen, dabei hat sich rein gar ncihts getan. Es wurde auch gar nie auf meinen Fehler eingegangen, ich habe immer nur Standardtexte zum Thema Dual Stack und IPv6 bekommen.

Ich habe bei meinem offenen Ticket gestern nochmal eine Nachfrage zum Stand der Bearbeitung gestellt und nach einem Rückruf von einem Techniker gebeten, nach diesem bettele ich aber schon seit 4 Wochen.... angerufen hat allerdings nie jemand.

Bisher leider nichts neues. Woher kommt ihr beiden. In einem anderen thread hier im Forum hat sich herausgestellt, dass ein anderer betroffener auch aus 72..... Kommt, gleicher Ort wir ich.

Viele Grüße

Ich komme aus 79.... (Landkreis Emmendingen), also nicht aus deiner unmittelbaren Nähe aber auch aus B-W.

Hallo,
mal etwas konkreter: Ich komme aus 79336.
In unserem Ort wurden die Anschlüsse im November geschaltet. Geschwindigkeit passt, aber:

Seit Beginn kein IPv6 wie im Beitrag oben beschrieben. Es ist nicht einmal ein V6-ping zum DNS-Server der DG möglich. Das gleiche Problem besteht bei allen anderen Anschlüssen im Ort, die ich bei Freunden testen konnte.
Ich habe das Problem bereits seit Dezember gemeldet. Die DG reagiert seit ca. 3 Wochen nicht mehr. In der Zwischenzeit sind zwei Tickets offen. Ich habe bereits die Bundesnetzagentur informiert und bin kurz davor einen Anwalt einzuschalten, da IPv6 eindeutig in den Leistungsbeschreibungen der DG steht. Insbesondere den Zugriff von außen benötige ich dringend.

Vielleicht hilft es, wenn auch weitere Betroffene die Bundesnetzagentur hinzuziehen!

Viele Grüße

Willkommen im Forum!

Wie wäre es hiermit? RE: Mal wieder: Kein IPv6 bei Deutsche Glasfaser

Mittlerweile kommen mehrere Rückmeldungen, daß das Problem behoben sei. (Hier und hier.)

Schaut mal nach, ob es vielleicht jetzt geht, und gebt Rückmeldung. Danke!

MM-DG

Ich habe es zwischenzeitlich so gelöst, funktioniert problemlos:

Thema

IPv4-Erreichbarkeit via VPS und VPN (WireGuard)

Einleitung

Da es immer wieder Thema ist, möchte ich hier die Chance nutzen, Möglichkeiten aufzuzeigen, wie eine Erreichbarkeit via IPv4 erreicht werden kann, wenn man bei einem Provider ist, der einem keinen vollwertigen IPv4-Zugang mehr anbietet, sondern Techniken wie CG-NAT oder DS-Lite nutzt.

Hintergrund

Im ersten Beispiel greife ich eine Konfiguration auf, wie sie zuletzt diskutiert wurde. Dabei geht es darum, das Heimnetzwerk mithilfe eines VPS für IPv4-Clients verfügbar zu machen. Die…

mbo77

28. Oktober 2023 um 15:41

Hallo zusammen. Nun bin ich wohl an der Reihe. PLZ-Gebiet 41... Aktivierung in 09/2025 in einem seitens DG neu ausgebauten Gebiet. Nutze eine FB7590AX als Eigengerät hinter dem NT. Zunächst hatte ich gar keine IPv6 wie alle bei uns im Ort. Mehrere Tickets dazu liefen ins Leere. Am 20.01.26 meldete die FB dann jedoch den erfolgreichen Verbindungsaufbau über IPv6. Nur leider kann ich nicht zugreifen auf die Aussenwelt über IPv6. Es scheint mir aber so, das inbound Verbindungen klappen. Nur outbound nicht. Bin mir nicht sicher, ob es sich um ein Problem im Netz der DG handelt oder doch in meiner FB.

traceroute von meinem Hetzner VPS auf die IP der FB:

traceroute to 2a00:6020:5c80::XXX (2a00:6020:5c80::XXX), 30 hops max, 80 byte packets
1  _gateway (fe80::1%eth0)  8.739 ms  9.630 ms  9.741 ms
2  17501.your-cloud.host (2a01:4f8:0:e0c0::482b)  2.256 ms  2.620 ms  2.171 ms
3  * * *
4  spine4-rdev2.cloud1.nbg1.hetzner.com (2a01:4f8:0:e0c0::a18d)  4.192 ms spine4-rdev1.cloud1.nbg1.hetzner.com (2a01:4f8:0:e0c0::a189)  4.302 ms spine4-rdev2.cloud1.nbg1.hetzner.com (2a01:4f8:0:e0c0::a18d)  4.769 ms
5  core-spine-rdev2.cloud1.nbg1.hetzner.com (2a01:4f8:cfff:1::f000:f035)  4.014 ms core-spine-rdev1.cloud1.nbg1.hetzner.com (2a01:4f8:cfff:1::f000:f039)  4.098 ms core-spine-rdev2.cloud1.nbg1.hetzner.com (2a01:4f8:cfff:1::f000:f03d)  4.627 ms
6  core11.nbg1.hetzner.com (2a01:4f8:0:3::2a1)  4.580 ms core11.nbg1.hetzner.com (2a01:4f8:0:e0c0::a1e1)  3.140 ms  3.101 ms
7  core0.fra.hetzner.com (2a01:4f8:0:3::351)  6.129 ms core4.fra.hetzner.com (2a01:4f8:0:3::f5)  3.927 ms core4.fra.hetzner.com (2a01:4f8:0:3::1d)  4.266 ms
8  * * *
9  * * *
10  2a00:6020:5c80::XXX (2a00:6020:5c80::XXX)  9.773 ms !X  8.626 ms !X  8.374 ms !X

ping von meinem Hetzner VPS auf die IP der FB:

PING 2a00:6020:5c80::XXX (2a00:6020:5c80::XXX) 56 data bytes
64 bytes from 2a00:6020:5c80::XXX: icmp_seq=1 ttl=53 time=9.82 ms
64 bytes from 2a00:6020:5c80::XXX: icmp_seq=2 ttl=53 time=8.75 ms
64 bytes from 2a00:6020:5c80::XXX: icmp_seq=3 ttl=53 time=8.66 ms
64 bytes from 2a00:6020:5c80::XXX: icmp_seq=4 ttl=53 time=8.52 ms
64 bytes from 2a00:6020:5c80::XXX: icmp_seq=5 ttl=53 time=8.62 ms
^C
--- 2a00:6020:5c80::XXX ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4006ms
rtt min/avg/max/mdev = 8.522/8.874/9.819/0.477 MS

Tracert aus dem Heimnetz nach aussen (KeyCDN als Test):

tracert -6 2a00:1450:400a:804::2004
Routenverfolgung zu pnzrha-aj-in-x04.1e100.net [2a00:1450:400a:804::2004]
über maximal 30 Hops:

 1    <1 ms    <1 ms    <1 ms  fritz.box [2a00:6020:5cc0:144:52e6:36ff:fed3:f242]
 2     3 ms     2 ms     2 ms  fc00::1
 3     *        *        *     Zeitüberschreitung der Anforderung.
 4     *        *        *     Zeitüberschreitung der Anforderung.

Netzwerkconfig eines Beispielclients im Heimnetz:

  IPv6-Adresse. . . . . . . . . . . : 2a00:6020:5cc0:144:674f:124b:1226:56bc(Bevorzugt)
  IPv6-Adresse. . . . . . . . . . . : fd4c:1b2c:73a5:0:2bc8:7fd2:4413:fdf8(Bevorzugt)
  Temporäre IPv6-Adresse. . . . . . : 2a00:6020:5cc0:144:b918:f7ed:7ead:d92a(Bevorzugt)
  Temporäre IPv6-Adresse. . . . . . : fd4c:1b2c:73a5:0:b918:f7ed:7ead:d92a(Bevorzugt)
  Verbindungslokale IPv6-Adresse  . : fe80::af68:20:52ab:e25b%9(Bevorzugt)
  IPv4-Adresse  . . . . . . . . . . : 192.168.2.50(Bevorzugt)
  Subnetzmaske  . . . . . . . . . . : 255.255.255.0
  Lease erhalten. . . . . . . . . . : Freitag, 23. Januar 2026 10:10:40
  Lease läuft ab. . . . . . . . . . : Montag, 2. Februar 2026 10:10:39
  Standardgateway . . . . . . . . . : fe80::52e6:36ff:fed3:f242%9
                                      192.168.2.1
  DHCP-Server . . . . . . . . . . . : 192.168.2.1
  DHCPv6-IAID . . . . . . . . . . . : 83637399
  DHCPv6-Client-DUID. . . . . . . . : 00-01-00-01-2D-1B-85-CC-FC-34-97-9E-3F-28
  DNS-Server  . . . . . . . . . . . : fd4c:1b2c:73a5:0:52e6:36ff:fed3:f242
                                      2a00:6020:5cc0:144:52e6:36ff:fed3:f242
                                      192.168.2.1
                                      fd4c:1b2c:73a5:0:52e6:36ff:fed3:f242
                                      2a00:6020:5cc0:144:52e6:36ff:fed3:f242

tes-ipv6.com:

Test mit IPv4 DNS-Eintrag	 	
					Okay (0.379s) verwende ipv4
Test mit IPv6 DNS-Eintrag	 						
Zeitüberschreitung (15.005s)
Test mit Dual Stack DNS-Eintrag	 					
Okay (0.778s) verwende ipv4
Prüfung auf Dual-Stack-DNS und große Pakete	 		
Okay (0.712s) verwende ipv4
Großes IPv6-Paket testen	 						
Zeitüberschreitung (15.009s)
Prüfen, ob der DNS-Server Ihres ISPs IPv6 unterstützt	 	
Okay (0.643s) verwende ipv4
IPv4-Dienstleister finden	 	
					Okay (0.526s) verwende ipv4 ASN 60294
IPv6-Dienstleister finden	 	
					Zeitüberschreitung (15.014s)

Grundsätzlich ist mir IPv6 egal, weil ich bei Hetzner schon ewig ne VPS habe und die für Wireguard als Jumphost nutze seit ich DG habe.
Aber einige Apps auf Android funktionieren nicht mehr sauber da sie Inhalte nicht laden können, wenn IPv6 aktiv ist. Sobald ich IPv6 in der FB deaktiviere, funktioniert alles logischerweise reibungslos weil keine IPv6 Anfragen mehr in einen Timeout laufen.
Habe es in der FB sowohl mit Native IPv6-Anbindung verwenden als auch Native IPv4-Anbindung verwenden versucht mit gleichem Ergebnis.

Vielleicht hat ja wer einen Tipp für mich?

Dein Anschluss scheint an einem BNG-Cluster der DG zu hängen, auf dem sie ihr "neues" IPv6-Adresskonzept anwendet, welches hier im Forum schon öfter durch Nicht-Funktionieren von IPv6 aufgefallen ist. Das sehe ich anhand der WAN-Adresse deines Routers, die im ersten /56-Block (genauer: im Block 2a00:6020:5c80::/112) des übergeordneten Block 2a00:6020:5c80::/41 liegt, aus dem die DG ihren Kunden an diesem BNG-Cluster die /56-Blöcke für das LAN zuweist (bei dir: 2a00:6020:5cc0:100::/56). In Traceroutes zeigen sich die BNG-Cluster mit "neuem" Adresskonzept stets mit der Adresse "fc00::1"

Ich kann von meiner Seite (auch DG-Anschluss, aber nach "altem" Adress-Konzept) z.B. die WAN-Adresse 2a00:6020:5c80::100 pingen - vielleicht ist das ja sogar dein Anschluss.

Dein Test zeigt, dass "inbound-IPv6" nur bis zum WAN-Port funktioniert. Ob auch dein LAN dahinter von außen erreichbar ist, müsstest du mal durch Öffnen der FB-Firewall (z.B. für ein ICMPv6 echo/Pingv6) für ein LAN-Gerät deiner Wahl testen.

Etwas merkwürdig finde ich die Wahl des /64 für dein LAN aus dem 2a00:6020:5cc0:100::/56-Block: Dies ist bei dir der Index 44, so dass sich daraus eine LAN-Adresse 2a00:6020:5cc0:144::/64 ergibt. Normalerweise würde eine FB den Index 00 wählen, so dass sich die LAN-Adresse 2a00:6020:5cc0:100::/64 (und 2a00:6020:5cc0:101::/64 für das Gäste-LAN) ergäbe. Es sei denn, du hast eine Router-Kaskade, und deine FB ist der nachgelagerte Router, an den du einen Teilblock aus 2a00:6020:5cc0:100::/56 per DHCPv6-PD delegiert hast (z.B. 2a00:6020:5cc0:144::/62). Liege ich da evtl. richtig?

Wenn outbound-IPv6 nicht funktioniert, dann liegt das vermutlich daran, dass dein Router/FB keine IPv6-RA (Router-Advertisments) von der DG-Gegenstelle (eben dem BNG) erhält, so dass keine IPv6-Default-Route gelernt werden kann. Das müsste man durch einen Paketmitschnitt am WAN-Port eruieren.

Nachtrag:

Sorry, habe ich übersehen:

Laut deiner FB-Ereignisanzeige weist dir DG gar kein /56 zu, sondern nur explizit den /64: 2a00:6020:5cc0:144::/64. Also wenn das jetzt Teil des "neuen" IPv6-Adresskonzepts ist, wäre das gelinde gesagt doch etwas "sparsam". Laut meinen Beobachtungen an einem anderen DG-Anschluss (dieser hier: RIPE-Atlas Probe #1001325) scheinen auch die zugewiesenen IPv6-Adressen nicht mehr "quasi-statisch" zu sein, die wechseln bei Neuverbindungen öfters.

Zitat von ::1

Dein Anschluss scheint an einem BNG-Cluster der DG zu hängen, auf dem sie ihr "neues" IPv6-Adresskonzept anwendet, welches hier im Forum schon öfter durch Nicht-Funktionieren von IPv6 aufgefallen ist. Das sehe ich anhand der WAN-Adresse deines Routers, die im ersten /56-Block (genauer: im Block 2a00:6020:5c80::/112) des übergeordneten Block 2a00:6020:5c80::/41 liegt, aus dem die DG ihren Kunden an diesem BNG-Cluster die /56-Blöcke für das LAN zuweist (bei dir: 2a00:6020:5cc0:100::/56). In Traceroutes zeigen sich die BNG-Cluster mit "neuem" Adresskonzept stets mit der Adresse "fc00::1"

Ich kann von meiner Seite (auch DG-Anschluss, aber nach "altem" Adress-Konzept) z.B. die WAN-Adresse 2a00:6020:5c80::100 pingen - vielleicht ist das ja sogar dein Anschluss.

Dein Test zeigt, dass "inbound-IPv6" nur bis zum WAN-Port funktioniert. Ob auch dein LAN dahinter von außen erreichbar ist, müsstest du mal durch Öffnen der FB-Firewall (z.B. für ein ICMPv6 echo/Pingv6) für ein LAN-Gerät deiner Wahl testen.

Etwas merkwürdig finde ich die Wahl des /64 für dein LAN aus dem 2a00:6020:5cc0:100::/56-Block: Dies ist bei dir der Index 44, so dass sich daraus eine LAN-Adresse 2a00:6020:5cc0:144::/64 ergibt. Normalerweise würde eine FB den Index 00 wählen, so dass sich die LAN-Adresse 2a00:6020:5cc0:100::/64 (und 2a00:6020:5cc0:101::/64 für das Gäste-LAN) ergäbe. Es sei denn, du hast eine Router-Kaskade, und deine FB ist der nachgelagerte Router, an den du einen Teilblock aus 2a00:6020:5cc0:100::/56 per DHCPv6-PD delegiert hast (z.B. 2a00:6020:5cc0:144::/62). Liege ich da evtl. richtig?

Wenn outbound-IPv6 nicht funktioniert, dann liegt das vermutlich daran, dass dein Router/FB keine IPv6-RA (Router-Advertisments) von der DG-Gegenstelle (eben dem BNG) erhält, so dass keine IPv6-Default-Route gelernt werden kann. Das müsste man durch einen Paketmitschnitt am WAN-Port eruieren.

Nachtrag:

Sorry, habe ich übersehen:

Laut deiner FB-Ereignisanzeige weist dir DG gar kein /56 zu, sondern nur explizit den /64: 2a00:6020:5cc0:144::/64. Also wenn das jetzt Teil des "neuen" IPv6-Adresskonzepts ist, wäre das gelinde gesagt doch etwas "sparsam". Laut meinen Beobachtungen an einem anderen DG-Anschluss (dieser hier: RIPE-Atlas Probe #1001325) scheinen auch die zugewiesenen IPv6-Adressen nicht mehr "quasi-statisch" zu sein, die wechseln bei Neuverbindungen öfters.

Alles anzeigen

Nein, ich nutze keine Router-Kaskade. Die Erreichbarkeit von Clients im LAN sowie Paketmitschnitt muss ich am Wochenende in betriebsarmer Zeit mal testen. Danke für deine Tipps und Hinweise!

Zitat von ::1

Dein Anschluss scheint an einem BNG-Cluster der DG zu hängen, auf dem sie ihr "neues" IPv6-Adresskonzept anwendet, welches hier im Forum schon öfter durch Nicht-Funktionieren von IPv6 aufgefallen ist. Das sehe ich anhand der WAN-Adresse deines Routers, die im ersten /56-Block (genauer: im Block 2a00:6020:5c80::/112) des übergeordneten Block 2a00:6020:5c80::/41 liegt, aus dem die DG ihren Kunden an diesem BNG-Cluster die /56-Blöcke für das LAN zuweist (bei dir: 2a00:6020:5cc0:100::/56). In Traceroutes zeigen sich die BNG-Cluster mit "neuem" Adresskonzept stets mit der Adresse "fc00::1"

Ich kann von meiner Seite (auch DG-Anschluss, aber nach "altem" Adress-Konzept) z.B. die WAN-Adresse 2a00:6020:5c80::100 pingen - vielleicht ist das ja sogar dein Anschluss.

Dein Test zeigt, dass "inbound-IPv6" nur bis zum WAN-Port funktioniert. Ob auch dein LAN dahinter von außen erreichbar ist, müsstest du mal durch Öffnen der FB-Firewall (z.B. für ein ICMPv6 echo/Pingv6) für ein LAN-Gerät deiner Wahl testen.

Etwas merkwürdig finde ich die Wahl des /64 für dein LAN aus dem 2a00:6020:5cc0:100::/56-Block: Dies ist bei dir der Index 44, so dass sich daraus eine LAN-Adresse 2a00:6020:5cc0:144::/64 ergibt. Normalerweise würde eine FB den Index 00 wählen, so dass sich die LAN-Adresse 2a00:6020:5cc0:100::/64 (und 2a00:6020:5cc0:101::/64 für das Gäste-LAN) ergäbe. Es sei denn, du hast eine Router-Kaskade, und deine FB ist der nachgelagerte Router, an den du einen Teilblock aus 2a00:6020:5cc0:100::/56 per DHCPv6-PD delegiert hast (z.B. 2a00:6020:5cc0:144::/62). Liege ich da evtl. richtig?

Wenn outbound-IPv6 nicht funktioniert, dann liegt das vermutlich daran, dass dein Router/FB keine IPv6-RA (Router-Advertisments) von der DG-Gegenstelle (eben dem BNG) erhält, so dass keine IPv6-Default-Route gelernt werden kann. Das müsste man durch einen Paketmitschnitt am WAN-Port eruieren.

Nachtrag:

Sorry, habe ich übersehen:

Laut deiner FB-Ereignisanzeige weist dir DG gar kein /56 zu, sondern nur explizit den /64: 2a00:6020:5cc0:144::/64. Also wenn das jetzt Teil des "neuen" IPv6-Adresskonzepts ist, wäre das gelinde gesagt doch etwas "sparsam". Laut meinen Beobachtungen an einem anderen DG-Anschluss (dieser hier: RIPE-Atlas Probe #1001325) scheinen auch die zugewiesenen IPv6-Adressen nicht mehr "quasi-statisch" zu sein, die wechseln bei Neuverbindungen öfters.

Alles anzeigen

Das klingt ganz nach meinem Problem. Ich habe hier im Forum dazu einen Thread hier aufgemacht: Deutsche Glasfaser IPv6 Routing Problem

::1 Sorry für die späte Antwort. Hier ist der Paketmitschnitt.

sh0rty :

Habe deinen Paketmitschnitt angeschaut.

Ergebnisse:

• Deine Router-WAN-Adresse ist vermutlich von außen erreichbar - ich konnte es allerdings nicht verifizieren. Möglicherweise, weil dein WAN-Interface keine Pings beantwortet, oder weil die WAN-Adresse aus dem Paketmitschnitt nicht mehr aktuell ist.
• Dein LAN-Präfix scheint hingegen in der DG-Infrastruktur nicht zu dem BNG geroutet zu werden, an dem dein Anschluss hängt. Folgen: Dein LAN ist von außen nicht erreichbar und ausgehender IPv6-Traffic zu Internet-Zielen wird von denen sicherlich beantwortet, gleichwohl "versacken" die Antworten in der DG-Infrastruktur, weil sie dort eben nicht zu deinem BNG/Anschluss geroutet werden. Sämtliche Pings zu "dns.nextdns.io", die du gesendet hast, bleiben also unbeantwortet.

Ansonsten sehr ungewöhnlich:

Du bekommst für's LAN nur einen PD-Block der Größe /64 - üblich wäre ein /56. Auch sind die Leasedauern für WAN-Adresse und LAN-Präfix mit 600s (10min) extrem kurz, so dass sie alle paar (5) Minuten per DHPv6-Renew erneuert werden müssen.

DHCPv6-Verlauf und RS/RA (Router lifetime = 4500s, M-Flag gesetzt) sind soweit normal, da gäbe es nichts zu beanstanden - allenfalls, dass das erste (und im Mitschnitt einzige) RA erst nach 16s zu sehen ist, nachdem dein Router 4 RS im Abstand von 4s gesendet hat.

Nachtrag:

• In deinem LAN scheint es ein Gerät zu geben, das 1x pro Sekunde einen Ping auf 10.8.0.1 absetzt - solche Pings Richtung Internet sind natürlich sinnlos.
• Auch bei IPv4 ist die DHCP-Leasedauer für die WAN-IPv4-Adresse mit 600s (10min) gleich kurz wie bei DHCPv6/IPv6.