Mal wieder: Kein IPv6 bei Deutsche Glasfaser

Bedeutet dies nun dass die aktuelle Version 262 dieses Problem nicht mehr aufweist oder wird an einer Lösung noch gearbeitet?

systemd 262 folgt damit immer noch nicht RFC9915. Aber sollte trotzdem relativ schnell einen neuen Lease bekommen (getestet habe ich das natürlich nicht...)

Das passiert, wenn bei Linux zum x-ten mal wieder das Rad neu erfunden wurde. Und wem sollte das auffallen? Auf der Standard-OpenWrt-Box läuft eben odhcp6c.

Zitat von Funker

Das passiert, wenn bei Linux zum x-ten mal wieder das Rad neu erfunden wurde. Und wem sollte das auffallen? Auf der Standard-OpenWrt-Box läuft eben odhcp6c.

Dann benutze ich ja jetzt den "richtigen" DHCPv6 client. dhcpcd läuft jetzt und hat das /48 bekommen. Released in 1996, ipv6 support seit 2012. Also älter als systemd-networkd oder odhcp. Muss dann ja objektiv der beste DHCPv6 Client sein😜.

Mal schauen wie das jetzt beim nächsten NoBinding abläuft. Wenn das getestet ist gibt es noch die Option IA_NA wegzulassen, es hat sich ja letztes mal nur IA_NA geändert. Vielleicht lässt sich in der Kombination /48 und kein IA_NA das ganze Spiel komplett vermeiden. Habe auch trotz anderem DUID (ist Standardmäßig Type 1 bei dhcpcd) immer noch das selbe /48.

Es gibt noch "dhclient" aus der DHCP-Referenz-Implementierung vom ISC.

Zitat von ::1

Ja, ich frage mich auch, ob das der mustergültige Weg für die Zuteilung neuer IPv6-Adressen ist.

Als Antwort auf den Rebind könnte der DHCPv6-Server in den IA-Optionen die alten Adressen bestätigen, allerdings deren Timer-Werte für Preferred und Valid Lifetime auf 0 setzen. Damit würden sie für den DHCPv6-Client sofort ungültig und er muss sie entfernen.

Zugleich könnte der DHCPv6-Server zwei zusätzliche IA-Optionen (IA_NA und IA_PD) mit neuen Adressdaten ergänzen.

Das erscheint mir als der bessere Weg.

So scheint es auch laut RFC9915 zu sein. Zitat letzter Absatz des Kapitels 5.1:

Zitat

Each address or delegated prefix assigned to the client has associated preferred and valid lifetimes specified by the server. To request an extension of the lifetimes assigned to an address or delegated prefix, the client sends a Renew message to the server. The server sends a Reply message to the client with the new lifetimes, allowing the client to continue to use the address or delegated prefix without interruption. If the server is unable to extend the lifetime of an address or delegated prefix, it indicates this by returning the address or delegated prefix with lifetimes of 0. At the same time, the server may assign other addresses or delegated prefixes.

Zitat von ::1

So scheint es auch laut RFC9915 zu sein. Zitat letzter Absatz des Kapitels 5.1:

Ja, sehe ich auch so. 18.3.4 ist auch sehr auf den Punkt:

Zitat

For each IA for which the server cannot find a client entry, the server has the following choices, depending on the server's policy and configuration information:

• If the server is configured to create new bindings as a result of processing Renew messages, the server SHOULD create a binding and return the IA with assigned addresses or delegated prefixes with lifetimes and, if applicable, T1/T2 times and other information requested by the client. If the client included the IA Prefix option within the IA_PD option (see Section 21.21) with a zero value in the "IPv6-prefix" field and a non-zero value in the "prefix-length" field, the server MAY use the "prefix-length" value as a hint for the length of the prefixes to be assigned (see [RFC8168] for further details on prefix-length hints).
• If the server is configured to create new bindings as a result of processing Renew messages but the server will not assign any leases to an IA, the server returns the IA option containing a Status Code option (see Section 21.13) with the NoAddrsAvail or NoPrefixAvail status code and a status message for a user.
• If the server does not support creation of new bindings for the client sending a Renew message or if this behavior is disabled according to the server's policy or configuration information, the server returns the IA option containing a Status Code option with the NoBinding status code and a status message for a user.

Ich verstehe es so, dass ein guter DHCP Server es unterstützt ein neues Binding zu erstellen und dann als REPLY auf den RENEW zum Client zu schicken. Nur ein Server der das nicht unterstützt nutzt als Fallback den letzten Punkt: Nobinding. Das sorgt dann dafür, dass der Client einen neuen Request sendet, damit der Server den dann "normal" abarteiten kann. Damit ist relativ klar, dass systemd-networkd nicht korrekt mit der Situation umgeht. Aber ein "guter" DHCP Server würde es halt gar nicht zu dieser Fallback Situation kommen lassen.

Es stellt sich natürlich noch die Frage, warum der Server kein Client Entry findet? Ist das Absicht oder eine Misskonfiguration/Fehlverhalten?

Ein paar Zeilen früher steht auch

Zitat

The server may choose to change the list of addresses or delegated prefixes and the lifetimes in IAs that are returned to the client.

Verstehe ich so, dass der Server einfach das alte Präfix durch ein neues ersetzen kann. Ohne großes hin und her mit neuem Request. Aber in meinem letzten Fall habe ich ja hinterher sogar dasselbe Präfix bekommen...

Das Zitat aus 5.1 beschreibt noch einen etwas anderen Fall. Einen bei dem der DHCP Server den Client kennt und aus irgendeinem Policy Grund den Lease nicht verlängert (Grund: wir möchten mehr Geld!)

Das Zitat aus 18.3.4 beschreibt den Fall wo der DHCP Server den Client überhaupt nicht kennt. Nur dann ist dir NoBinding response auf RENEW richtig (und dann auch nur wenn der Server die Erstellung eines neuen Bindings nicht als REPLY auf RENEW unterstützt)

Warum kennt der Server die DUID plötzlich nicht mehr? Das finde ich extrem merkwürdig.

Zitat von fiberv6

Ich verstehe es so, dass ein guter DHCP Server es unterstützt ein neues Binding zu erstellen und dann als REPLY auf den RENEW zum Client zu schicken. Nur ein Server der das nicht unterstützt nutzt als Fallback den letzten Punkt: Nobinding. Das sorgt dann dafür, dass der Client einen neuen Request sendet, damit der Server den dann "normal" abarteiten kann. Damit ist relativ klar, dass systemd-networkd nicht korrekt mit der Situation umgeht. Aber ein "guter" DHCP Server würde es halt gar nicht zu dieser Fallback Situation kommen lassen.

Es stellt sich natürlich noch die Frage, warum der Server kein Client Entry findet? Ist das Absicht oder eine Misskonfiguration/Fehlverhalten?

Würde ich auch so deuten.

Zu deiner Frage:

Vielleicht ist das die seitens DG vorgesehene Vorgehensweise bzw. im DHCPv6-Server konfigurierte Policy: Nach Ablauf einer Zeit, nach der DG meint, es sei ein Adresswechsel nötig, löschen sie "mit der Holzhammermethode" einfach die IA-Einträge des Clients. 😒

Es gab ein neues NoBinding event. dhcpcd hat sich nicht so verhalten wie ich dachte, oder wie es RFC9915 sagt.

Anbei der Capture. Habe noch nicht genau geschaut, aber es gab ein SOLICIT.

Als nächstes Teste ich dann das Verhalten von odhcp6c.

Zitat von fiberv6

Anbei der Capture. Habe noch nicht genau geschaut, aber es gab ein SOLICIT.

Der Client (neue Version?) startet nun halt nach dem NoBindung-Reply direkt einen Standard-Austausch Solicit-Advertise-Request-Reply.

Ansonsten ist mir aufgefallen, dass deine IAID nun "00000000" lautet (irgendeine Neuinitialisierung der Interfaces vorgenommen?)

Zitat von ::1

Der Client (neue Version?) startet nun halt nach dem NoBindung-Reply direkt einen Standard-Austausch Solicit-Advertise-Request-Reply.

Ansonsten ist mir aufgefallen, dass deine IAID nun "00000000" lautet (irgendeine Neuinitialisierung der Interfaces vorgenommen?)

Das ist jetzt halt dhcpcd und nicht mehr systemd-networkd. Der nutzt IAID 0 als default. Ich hatte aber eigentlich mit korrektem Verhalten gerechnet. Es ist jetzt zumindest nicht 30 Minuten ipv6 weg sondern nur ca. 1 Sekunde.

Habe gerade odhcp6c compiled und teste den als nächstes (dhcpv6 Client von OpenWrt).

Der Wechsel zu odhcp6c hat nicht gleich gut geklappt. Ich lasse jetzt erstmal die alte Lease ablaufen. Sehr merkwuerdige Exchanges. Aber zumindest kann man schon sehen, dass dieser Client korrekt REQUEST nach NoBinding macht.

Zitat von fiberv6

Aber zumindest kann man schon sehen, dass dieser Client korrekt REQUEST nach NoBinding macht.

Ja, in Paket 12 sendet er einen Request für die Restlaufzeit (300s) der Preferred/Valid Lifetime. Ich hatte oben vermutet, er würde die IA-Address bzw. IA-Prefix Suboptionen wie bei einem Solicit senden. Aber was wir hier in Paket 12 sehen, erscheint tatsächlich sinnvoller.

Allerdings sehen wir beim nächsten Renew (14) mit NoBinding-Reply in 17 ein anderes Verhalten: Es folgen unbeantwortete Renews gefolgt von Rebinds. Möglicherweise eine Folge des Rebind/Reply-Exchanges in 15/16 (in 16: IA-Address bzw. IA-Prefix Suboptionen mit Preferred/Valid Lifetime=0) - warum nur hat der Client diesen Exchange quasi gleichzeitig zu 14/17 durchgeführt?