Deutsche Glasfaser: IPv6 seit Wartung (19.05.2026) weg

ctr

Nach dem ich jetzt fast 2 Monate ohne Probleme (mal von den gelegentlichen Wartungsarbeiten abgesehen) IPv4/IPv6 Glasfaser-Internet bei der DG hatte, habe ich jetzt auf einmal (nach den angekündigten Wartungsarbeiten heute/19.05.26 00:00-01:00) kein IPv6 mehr. Ich nutze ein UniFi Gateway Lite (UXG) und hatte vorher DHCPv6 auf dem WAN Interface angeschaltet (komischerweise entgegen der Beschreibung hier Cloud Gatway Ultra, Deutsche Glasfaser, Einstellungen WAN). Damit hat die Firewall auf eth1 ein ipv6/128 bekommen und ein /56er Präfix, dass ich per PD nach innen verteilt habe. Die default route kam trotzdem per RA, Stand gestern:

Code

default via fe80::ff:fe01:102 dev eth1 table 201.eth1 proto ra metric 512 mtu 1500 pref medium

Seit heute (also seitdem es nach der Wartung wieder geht) bekomme ich zwar weiterhin per DHCPv6 Interface-Adresse und ein /56 Präfix (sogar jeweils die gleichen wir früher), aber mein gegenüber spricht kein RA mehr - ich bekomme keine default route.

manuell angetriggert über rdisc6 kommen nur timeouts.

Die UniFi konstruiert sich dann selbst eine Default route:

Code

May 19 17:28:55 firewall01 ubios-udapi-server[2069]: dhcp-client: [RA-absent] Using SERVER address as gateway: fe80::ff:fe01:101 on eth1
May 19 17:28:55 firewall01 ubios-udapi-server[2069]: dhcp-client: Adding PD address: {
May 19 17:28:55 firewall01 ubios-udapi-server[2069]: dhcp-client:  "cidr": "2a00:6020:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx/128",
May 19 17:28:55 firewall01 ubios-udapi-server[2069]: dhcp-client:  "origin": "dhcp",
May 19 17:28:55 firewall01 ubios-udapi-server[2069]: dhcp-client:  "type": "dynamic",
May 19 17:28:55 firewall01 ubios-udapi-server[2069]: dhcp-client:  "version": "v6"
May 19 17:28:55 firewall01 ubios-udapi-server[2069]: dhcp-client: } to dhcp address list on eth1
May 19 17:28:55 firewall01 ubios-udapi-server[2069]: WAN-Diag(eth1): res-interfaces: Adding new dynamic route ::/0 via fe80::ff:fe01:101/eth1 in table 201 (DHCP)

resultierend in

Code

default via fe80::ff:fe01:101 dev eth1 table 201.eth1 proto dhcp metric 200 pref medium

Aber auch mit der so konstruierten Default Route funktioniert kein IPv6. Ausgehend sehe ich nur link-local Traffic (neighbor advertisement/neighbor solicitation, aber eben kein router advertisment) und natürlich meine ausgehenden IPv6 Verbindungsversuche auf die aber keine Antwort kommt. Auch ankommend (auf die benannten Adresse) kommt nichts.

Habe schon eine Störung aufgemacht, woraufhin mein ONT rebootet wurde (was überraschenderweise nichts geändert hat). Jetzt warte ich ja nur darauf, dass sie mir entweder was vom Kabel erzählen oder das es natürlich an meinem Router liegt...

Sato

Das sind meine UniFi Einstellungen und von meiner Seite aus noch keine Probleme damit gehabt

ctr

genau so hatte ich es auch immer (nur mit 56 statt 64, weil ich mehrere Netze brauche) - aber seit der Wartung gehts halt nicht mehr, vorher schon (ohne Änderungen meinerseits)

::1

Zitat von ctr

Die default route kam trotzdem per RA

Wieso "trotzdem"? In Verbindung mit DHCPv6 (das im Gegensatz zu DHCPv4 keine "Gateway-Option" kennt), muss die Default-Route immer aus RA gelernt werden. Wenn die Gegenstelle keine sendet (=> Problem liegt auf DG-Seite), dann hast du eben kein Default-Gateway.

Sendet die Gegenstelle denn NS und antwortet sie mit NA auf die von deinem Router gesendeten NS?

ctr

"trotzdem" im Sinne von eben nicht per DHCPv6 (weil es ja per DHCPv6 auch gar nicht geht). Ich wollte hier nur den IPv6-unkundingen Leser nicht verwirren (insbesondere in Hinblick auf den Routingeintrag der dhcp suggeriert aber eben anderweitig aus dem Userspace kommt).

Die Gegenstelle sendet NS und und NA, aber keine RA. manuelle default route auf Gegenstelle liefert die Pakete an die Gegenstelle, aber es kommt nichts zurück.

Habe gerade mal ein traceoute von "draußen" auf mein Präfix gesendet und sehe so etwas lustiges wie:

Code

 1:  gateway                                               0.905ms 
 2:  2a00:d0c0:200::1                                      0.719ms 
 3:  2a00:d0c0:c:100::2                                   85.737ms 
 4:  fd00:bb:bb:7141:1142::1                               0.956ms 
 5:  no reply
 6:  no reply

Ich befürchte im Rahmen der Wartung (morgen geht es weiter: 6h vom 20.05.2026 um 12.30 Uhr bis zum 21.05.2026 06.00 Uhr!) wird auf die neue Struktur umgestellt von der hier ja verschiedentlich auch die Rede war. Derzeit habe ich noch eine Interface IP aus dem 2a00:6020:1000:41:: Block und quasi-statische IPv6.

::1

Zitat von ctr

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.

::1

Zitat von ctr

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).

::1

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.

ctr

Zitat von ::1

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.

doch ist gesetzt

Code

No.     Time                          Source                Destination           Protocol Length Info
      5 2026-05-19 12:25:19,653599    fe80::xxxx:xxxx:xxxx:xxxx fe80::ff:fe01:101     ICMPv6   86     Neighbor Advertisement fe80::xxxx:xxxx:xxxx:xxxx (rtr, sol, ovr) is at 16:3c:60:xx:xx:xx

Frame 5: Packet, 86 bytes on wire (688 bits), 86 bytes captured (688 bits)
Ethernet II, Src: 16:3c:60:xx:xx:xx (16:3c:60:xx:xx:xx), Dst: 02:00:00:01:01:01 (02:00:00:01:01:01)
Internet Protocol Version 6, Src: fe80::xxxx:xxxx:xxxx:xxxx, Dst: fe80::ff:fe01:101
Internet Control Message Protocol v6
    Type: Neighbor Advertisement (136)
    Code: 0
    Checksum: 0xfe32 [correct]
    [Checksum Status: Good]
    Flags: 0xe0000000, Router, Solicited, Override
        1... .... .... .... .... .... .... .... = Router: Set
        .1.. .... .... .... .... .... .... .... = Solicited: Set
        ..1. .... .... .... .... .... .... .... = Override: Set
        ...0 0000 0000 0000 0000 0000 0000 0000 = Reserved: 0
    Target Address: fe80::xxxx:xxxx:xxxx:xxxx
    ICMPv6 Option (Target link-layer address : 16:3c:60:xx:xx:xx)
        Type: Target link-layer address (2)
        Length: 1 (8 bytes)
        Link-layer address: 16:3c:60:xx:xx:xx (16:3c:60:xx:xx:xx)

Alles anzeigen

und die "Unify-Selbst-Konstruktion der Gateway-Adresse" funktioniert ja auch (das war der routing Eintrag mit "dhcp" nebst dem dazugehörigen Log, das genau das gesagt hat. d.h. ich habe eine default route - aber sie funktioniert nicht.

Zitat von ::1

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.

Nein in 61xxx (HE) genau gesagt diesem Wartungsgebiet:

JavaScript

{
  "category": "Wartung",
  "area": [
    "Hessen"
  ],
  "subject": "Wartung TV, Internet, Festnetz: Hessen - Bad Homburg vor der Höhe, Butzbach, Glashütten (Taunus), Grävenwiesbach, Neu-Anspach, Ober-Mörlen, Oberursel (Taunus), Schmitten (Hochtaunus), Usingen, Wehrheim, Wöllstadt, Weilrod",
  "description": "<p>Betroffenes Gebiet: Hessen - Bad Homburg vor der H&ouml;he, Butzbach, Glash&uuml;tten (Taunus), Gr&auml;venwiesbach, Neu-Anspach, Ober-M&ouml;rlen, Oberursel (Taunus), Schmitten (Hochtaunus), Usingen, Wehrheim, W&ouml;llstadt, Weilrod</p>\r\n\r\n<p>Wartungsbeginn:&nbsp;20.05.2026, 12:30 Uhr<br />\r\nWartungsende:&nbsp;21.05.2026, 06:00 Uhr<br />\r\nAusfallzeit:&nbsp;360 Minuten<br />\r\n&nbsp;</p>\r\n\r\n<p>Auf Grund einer geplanten Wartung stehen alle Dienste in dem angegebenen Zeitraum nicht zur Verf&uuml;gung.</p>\r\n\r\n<p>Sollten Sie nach Ende der Wartung weiterhin Probleme&nbsp;mit Ihrer Verbindung haben, f&uuml;hren Sie bitte einen Neustart&nbsp;durch. Dazu trennen Sie Ihre&nbsp;Ger&auml;te kurz vom Strom.</p>\r\n\r\n<p>Wir danken&nbsp;f&uuml;r Ihr Verst&auml;ndnis.</p>\r\n\r\n<p>Ihr Deutsche Glasfaser Team</p>\r\n\r\n<p>&nbsp;</p>",
  "affectedProducts": [
    "TV",
    "Internet",
    "Festnetz"
  ],
  "start": "2026-05-20T12:30:00+02:00",
  "end": "2026-05-21T06:00:00+02:00",
  "updatedAt": "2026-05-06T14:47:16.276423+02:00"
}

Alles anzeigen

ctr

Es geht wieder (ohne Änderungen meinerseits), default route kommt über RA rein.

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

::1

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 ...

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.

::1

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"