Mal wieder: Kein IPv6 bei Deutsche Glasfaser

Zusätzlich dann noch den output von "ip monitor", dann sollte am Ende alles nachvollziehbar sein.

Zitat von fiberv6

Aktuell befürchte ich, dass es alles noch schlimmer ist als gedacht. Wenn fe80::22 schon Minuten vor dem gescheiterten Renewal nicht mehr auf neighbor solicitations antwortet, ist dann ja schon keine Verbindung mehr gegeben.

In dem Mitschnitt von Luki sieht man, dass fe80::22 immer nur kurz nach den DHCPv6-Exchanges die RS des Routers 2x mit einem RA beantwortet (icmpv6.type==136 || dhcpv6), danach ist dann für etwa T1 (1800) Sekunden Sendepause. fe80::22 sendet sogar niemals RS.

Bei Luki war das Problem wie eingangs bei dir, dass sein PD-LAN-Präfix seitens DG nicht geroutet wurde.

Zitat von ::1

In dem Mitschnitt von Luki sieht man, dass fe80::22 immer nur kurz nach den DHCPv6-Exchanges die RS des Routers 2x mit einem RA beantwortet (icmpv6.type==136 || dhcpv6), danach ist dann für etwa T1 (1800) Sekunden Sendepause. fe80::22 sendet sogar niemals RS.

Bei Luki war das Problem wie eingangs bei dir, dass sein PD-LAN-Präfix seitens DG nicht geroutet wurde.

Habe gerade auch reingeschaut. Sieht noch kaputter aus las bei mir insgesamt. Ich nehme an, dass (unabhängig con dem prefix routing Problem) ipv6 halt überhaupt nicht geht außer kurz nach den funktionierenden Neighbor Advertisements.

Ob es nun richtig ist wie sich der REQUEST nach dem NoBinding verhält bin ich unsicher. Grundsätzlich kann der Server ja Adressen im Request ignorieren. Ist nur ein Hint. Aber es geht halt und ein neues Binding. Die Fritz Box lässt hier ja sogar das prefix hint weg. Kriegt zwar das selbe prefix wieder, aber ich bin mir unsicher ob das die beste Antwort ist.

Aber komplett aufzuhören auf NS zu antworten kann ja wirklich nicht der Weg sein den sich DG überlegt hat um Adressen zu rotieren. Zumal die Adresse dann ja letztendlich gar nicht geändert wird. Ich glaube immer noch nicht an Absicht.

Ergänzung: Dein Internet-Access lebt evtl. noch davon, dass die MAC-Adresse zu fe80::22 hinreichend lang im Neighbor Cache des Router-WAN-Interface verbleibt, bis ein nächster Refresh erfolgt, der ggf. auch durch einen generierten STALE-Eintrag aus einem RA der Gegenstelle generiert wird.

Zitat von fiberv6

Die Fritz Box lässt hier ja sogar das prefix hint weg.

Genau das interpretiere ich als folgerichtig: Indem der Router das tut, erwartet er nicht mehr, dasselbe Prefix zu bekommen, denn zuvor hatte der Server das ja per NoBinding abgewiesen - also prefix hint weglassen in der Erwartung, ein neues/anderes zu bekommen.

Der RFC ist an der Stelle auch nicht sonderlich informativ, was der Client in dem geforderten Request als Reaktion auf den NoBindung genau hineinschreiben soll. Wirkt dann so, dass das vollkommen egal ist ...

Zitat von ::1

Genau das interpretiere ich als folgerichtig: Indem der Router das tut, erwartet er nicht mehr, dasselbe Prefix zu bekommen, denn zuvor hatte der Server das ja per NoBinding abgewiesen - also prefix hint weglassen in der Erwartung, ein neues/anderes zu bekommen.

Der RFC ist an der Stelle auch nicht sonderlich informativ, was der Client in dem geforderten Request als Reaktion auf den NoBindung genau hineinschreiben soll. Wirkt dann so, dass das vollkommen egal ist ...

Ist ja so oder so nur ein Hint welches prefix or IA_NA man gerne hätte. Aus 18.2.3:

Zitat

The server MAY assign different addresses and/or delegated prefixes to an IA than those included within the IA of the client's Request message.

Desegen würde ich halt das bisherige prefix da reinschreiben um die Chance zu erhöhen es zu behalten.

odhcp6c inkludiert dann halt noch die verbleibende Leasedauer, ob das nun richtig ist?

Zitat von ::1

Ergänzung: Dein Internet-Access lebt evtl. noch davon, dass die MAC-Adresse zu fe80::22 hinreichend lang im Neighbor Cache des Router-WAN-Interface verbleibt, bis ein nächster Refresh erfolgt, der ggf. auch durch einen generierten STALE-Eintrag aus einem RA der Gegenstelle generiert wird.

Das werde ich jetzt nächstes mal sehen, weil ich auch Änderungen im neighbor cache jetzt logge.

Die Frage ist warum der DG Router komplett mit ND aufhört. Ist das nur ein Symptom? Selbst wenn ich noch einen Eintrag im Cache habe, vielleicht leitet der DG Router einfach nichts mehr weiter.

Eigentlich musste ich relativ häufig pings von smokeping in meinen Captures sehen, die fehlen aber in diesem Zeitraum. Ich denke mal der neighbor cache hat keinen gültigen Eintrag in dieser Zeit.

Falls sich das bestätigt werde ich mal mit einem statischen Eintrag rumprobieren.

Here we go:

[1790616654.151454] 64 bytes from fe80::22%enp2s0: icmp_seq=1588 ttl=255 time=4.87 ms
[1790616664.162513] 64 bytes from fe80::22%enp2s0: icmp_seq=1589 ttl=255 time=5.61 ms
[1790616674.167477] 64 bytes from fe80::22%enp2s0: icmp_seq=1590 ttl=255 time=5.34 ms
[1790616684.178568] 64 bytes from fe80::22%enp2s0: icmp_seq=1591 ttl=255 time=5.69 ms
[1790616694.182158] 64 bytes from fe80::22%enp2s0: icmp_seq=1592 ttl=255 time=5.02 ms
[1790616704.192717] 64 bytes from fe80::22%enp2s0: icmp_seq=1593 ttl=255 time=5.16 ms
[1790616714.203069] 64 bytes from fe80::22%enp2s0: icmp_seq=1594 ttl=255 time=5.03 ms
[1790616724.213468] 64 bytes from fe80::22%enp2s0: icmp_seq=1595 ttl=255 time=5.62 ms
[1790616734.224414] 64 bytes from fe80::22%enp2s0: icmp_seq=1596 ttl=255 time=5.75 ms
[1790616757.417233] From fe80::ae16:2dff:fe94:e03f%enp2s0 icmp_seq=1598 Destination unreachable: Address unreachable
[1790616767.401028] From fe80::ae16:2dff:fe94:e03f%enp2s0 icmp_seq=1599 Destination unreachable: Address unreachable
[1790616777.449257] From fe80::ae16:2dff:fe94:e03f%enp2s0 icmp_seq=1600 Destination unreachable: Address unreachable
[1790616787.433121] From fe80::ae16:2dff:fe94:e03f%enp2s0 icmp_seq=1601 Destination unreachable: Address unreachable
[1790616797.481113] From fe80::ae16:2dff:fe94:e03f%enp2s0 icmp_seq=1602 Destination unreachable: Address unreachable
[1790616807.465061] From fe80::ae16:2dff:fe94:e03f%enp2s0 icmp_seq=1603 Destination unreachable: Address unreachable
[1790616817.449115] From fe80::ae16:2dff:fe94:e03f%enp2s0 icmp_seq=1604 Destination unreachable: Address unreachable

Es passiert gerade Live. ipv6 funktioniert nicht. Der Lease ist aber noch da. Beim nächste Renewal wird er dann kaputt gehen.

Die perfekte Uhrzeit für kaputtes Internet! Das kann echt nicht Absicht sein.

Und ipv4 funktioniert währenddessen. Meine Wireguard Verbindung über die ich gerade raufschaue läuft über ipv4 zu dem Anschluss.

So... Habe beim renewal jetzt den Nobinding status code bekommen. Dann hat odhcp6c den Request gemacht. Und....... sowohl bei IA_NA und IA_PD die selben Adressen wieder bekommen. Komplett sinnlos.

Ich werde dann mal alle logs zusammensuchen und hier hochladen, dauert aber ein bisschen, sitze gerade im Zug und muss bald umsteigen.

Und sofort antwortet fe80::22 auch wieder.

Diese Verhalten sorgt dann also für 0 bis 30 Minuten kein Internet (bis zum nächsten renewal). Und übliche Router werden diesen Zustand nicht erkennen, da sie in keiner Weise von DG informiert werden. Das prefix und der router bleiben also weiter im LAN announced über RA. Dadurch gehen dann alle Anwendungen nicht die nicht automatisch selber auf ipv4 zurückfallen (z.B. manche OpenVPN clients)

So, hier mal alle Logs

odhcp6c geht gut mit der Situation um. Es kriegt sofort das selbe IA_NA und IA_PD zurück. Aber die ca. 14 Minuten komplett ohne ipv6 von sind seitens DG nicht akzeptabel.

Interessant ist, dass am Ende noch zwei pings an die OLT mac rausgesendet werden, aber keine Antwort kommt. Das deutet darauf hin, dass die Verbindung nicht abbricht nur weil mein Router keinen neighbor cache entry mehr hat. Sondern weil DG die Pakete nicht mehr annimmt oder die Antwort nicht mehr an mich liefert.

Das ist durch ip monitor bestätigt. Die beiden Pings auf die es keine Antwort mehr gibt waren um 19:32:21 und 24. Der neighbor entry von fe80::22 wird von meinem router aber erst um 19:32:28 auf FAILED gestellt:

fe80::22 dev enp2s0 lladdr 20:00:12:42:40:93 router PROBE 
Timestamp: Mon Sep 28 19:31:34 2026 958681 usec
fe80::22 dev enp2s0 lladdr 20:00:12:42:40:93 router REACHABLE 
Timestamp: Mon Sep 28 19:32:16 2026 425071 usec
fe80::22 dev enp2s0 lladdr 20:00:12:42:40:93 router STALE 
Timestamp: Mon Sep 28 19:32:25 2026 129011 usec
fe80::22 dev enp2s0 lladdr 20:00:12:42:40:93 router PROBE 
Timestamp: Mon Sep 28 19:32:28 2026 200974 usec
fe80::22 dev enp2s0 router FAILED 
Timestamp: Mon Sep 28 19:32:33 2026 1210 usec
fe80::22 dev enp2s0 router FAILED 
Timestamp: Mon Sep 28 19:32:37 2026 417147 usec
fe80::22 dev enp2s0 router FAILED 

Es wird also ein statischer Eintrag in den Neighbor Cache nichts bringen. Ich werde es vielleicht trotzdem versuchen um das auszuschließen.

Man erkennt im Trace den Zeitpunkt des Löschens der MAC-Adresse zu fe80::22 aus dem Neighbor-Cache daran, dass die NS deines Routers nicht mehr an fe80::22 (#15494: "Probing" per Unicast) sondern an die aus fe80::22 abgeleitete SNMA ff02::1:ff00:22 (#15495ff: MAC-Adresse per Multicast an die SNMA neu auflösen) gesendet werden. Das passiert um 19:32:27. Die danach folgenden NS bleiben seitens fe80::22 vorerst unbeantwortet.

Erst in #15994 (um 19:46:12) sieht man wieder ein erstes NA von fe80::22, nachdem unmittelbar zuvor ein Renew-Reply(NoBindings)-Request-Reply(Success, aber kürzere Timer) stattgefunden hat.

Auch die Gegenstelle sendet NS bis 19:32:11 (#15482), setzt das aber erst nach dem DHCPv6-Exchange um 19:48:11 (#16074) wieder fort.

In dem "toten" Zeitintervall von 19:32:27 bis 19:46:12 erhält dein Router auch keine RA von fe80::22 (letzter RA davor: #15219, 19:26:01, erster RA danach: #15999, 19:46:13)

Solche Effekte habe ich auch schon in anderen Traces in ähnlicher Form gesehen.

Die IPv6-Gegenstelle ist bezüglich IPv6 eben einfach "kaputt" konfiguriert.

Zitat von fiberv6

Das prefix und der router bleiben also weiter im LAN announced über RA. Dadurch gehen dann alle Anwendungen nicht die nicht automatisch selber auf ipv4 zurückfallen (z.B. manche OpenVPN clients)

Ja, das ist das Gemeine daran - in einer IPv6-Totphase kannst du dazu ja mal den "Happy Eyeballs-Test" laufen lassen.

Solange dieser Zustand des zeitweise nicht funktionierenden IPv6-Zugangs besteht, würde ich daher im Router die RA ins LAN deaktivieren (wodurch alle LAN-Clients auf eine reine IPv4-Konfiguration zurück fallen).

Zitat von ::1

Man erkennt im Trace den Zeitpunkt des Löschens der MAC-Adresse zu fe80::22 aus dem Neighbor-Cache daran, dass die NS deines Routers nicht mehr an fe80::22 (#15494: "Probing" per Unicast) sondern an die aus fe80::22 abgeleitete SNMA ff02::1:ff00:22 (#15495ff: MAC-Adresse per Multicast an die SNMA neu auflösen) gesendet werden. Das passiert um 19:32:27. Die danach folgenden NS bleiben seitens fe80::22 vorerst unbeantwortet.

Kleine Korrekture. 19:32:27 ist ja noch Paket 15494, das an fe80:22 geht. Paket 15495 um 19:32:29 ist die erste NS die an ff02::1:ff00:22 geht. Dann passt es auch mit "ip monitor" überein, das ja das netlink event vom kernel zeigt. Da ändert sich der neighbor cache um genau 19:32:28,200974:

Timestamp: Mon Sep 28 19:32:28 2026 200974 usec
fe80::22 dev enp2s0 router FAILED

Zitat von ::1

Solange dieser Zustand des zeitweise nicht funktionierenden IPv6-Zugangs besteht, würde ich daher im Router die RA ins LAN deaktivieren (wodurch alle LAN-Clients auf eine reine IPv4-Konfiguration zurück fallen).

Ja, so habe ich es aktuell konfiguriert um ein weiteres Problem für die anderen Nutzer zu vermeiden. Einfach in den RAs die router lifetime auf 0 gesetzt. Dadurch haben die Geräte keine ipv6 default route und haben keine Probleme. Bei ein paar Testgeräten füge ich die ipv6 default route halt manuell hinzu.

Ich bin mir jetzt sehr sicher, dass die sich ändernden Präfixe bei diesen neueren Anschlüssen nicht von DG beabsichtigt sind. Sie sind nur ein Symptom vom kaputten ipv6. Der DHCPv6 Server macht den Lease kaputt und gibt die einen neuen (mit möglicherweise anderem prefix) wenn man aus seiner Sicht nicht erreichbar ist (Neighbor Unreachability Detection). Man sieht ja, dass er sich so verhält wenn man IA_NA anfordert aber sich nicht zuweist. Dann gibt es NoBinding beim nächsten renewal.

ipv6 geht ab und zu kaputt, da fe80::22 einfach aufhört zu funktionieren.

Ich zeichne dieses Spiel jetzt mal über ca. 1 Woche auf und probiere dann eine Anfrage bei DG.