Deutsche Glasfaser: IPv6 seit Wartung (19.05.2026) weg

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:

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:

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

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

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)

"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:

 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.

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

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)

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:

{
  "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"
}

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

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.