Beiträge von ::1

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?

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

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 fiberv6

Das Verhalten des DHCPv6 Servers bleibt immer noch seltsam. Warum dieses Spiel mit NoBinding,

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.

Oder man bedient den Reconfigure-Weg, nur fürchte ich diesbezüglich mangelnde Unterstützung auf Home-Router-Seite.

Zitat von ::1

Das sieht ehrlich gesagt nicht sonderlich "gesund" aus - ich kann allerdings ohne Tiefenanalyse von RFC9915 aktuell nicht bewerten, welche Seite hier genau was falsch macht.

Habe ich nun mal versucht.

Zunächst zwecks Vergleich ein Auszug aus Paket #4 mit der letzten erfolgreichen Lease-Verlängerung:

Identity Association for Non-temporary Address
    Option: Identity Association for Non-temporary Address (3)
    Length: 40
    IAID: 5de26c15
    T1: 1800
    T2: 2880
    IA Address
        Option: IA Address (5)
        Length: 24
        IPv6 address: 2a00:61e0:9d00::3c
        Preferred lifetime: 3600
        Valid lifetime: 3600
Identity Association for Prefix Delegation
    Option: Identity Association for Prefix Delegation (25)
    Length: 41
    IAID: 5de26c15
    T1: 1800
    T2: 2880
    IA Prefix
        Option: IA Prefix (26)
        Length: 25
        Preferred lifetime: 3600
        Valid lifetime: 3600
        Prefix length: 56
        Prefix address: 2a00:61e0:9d40:d00::

Nun im Vergleich dazu die beiden IA-Optionen aus dem Paket #6:

Identity Association for Non-temporary Address
    Option: Identity Association for Non-temporary Address (3)
    Length: 28
    IAID: 5de26c15
    T1: 0
    T2: 0
    Status code
        Option: Status code (13)
        Length: 12
        Status Code: NoBinding (3)
        Status Message: No binding
Identity Association for Prefix Delegation
    Option: Identity Association for Prefix Delegation (25)
    Length: 28
    IAID: 5de26c15
    T1: 0
    T2: 0
    Status code
        Option: Status code (13)
        Length: 12
        Status Code: NoBinding (3)
        Status Message: No binding

Hier sind die Renew- und Rebind-Timer (T1, T2) jeweils 0. Und anstelle der "IA address"- bw. "IA Prefix"-Sub-Optionen ist jeweils der Status Code "NoBinding" enthalten.

Jetzt habe ich RFC9915 angeschaut, um zu eruieren, was der DHCPv6-Client in dieser Situation tun sollte:

Fündig wird man in Section 18.2.10. Ich kopiere daraus mal (mit Weglassungen) die Textpassagen, die m. E. zutreffend sind:

18.2.10. Receipt of Reply Messages

Upon the receipt of a valid Reply message in response to a ... Renew ... message, the client extracts the top-level Status Code option (see Section 21.13) if present.

Kommentar: keine "top-level Status Code option" in Paket #6 enthalten

...

Otherwise (no status code or another status code), the client processes the Reply as described below based on the original message for which the Reply was received.

...

18.2.10.1. Reply for Solicit (with Rapid Commit), Request, Renew, or Rebind

...

In dem Unterkapititel 18.2.10.1 heißt es nun weiter:

If the Reply was received in response to a ... Renew ... message, the client
updates the information it has recorded about IAs from the IA options contained
in the Reply message:

  ...

Im folgenden gibt es nun zwei Handlungsoptionen, bei denen mir nicht eindeutig klar ist, welche die zutreffende Variante ist:

Erste Variante:

If the Reply message contains any IAs but the client finds no usable addresses and/or delegated prefixes in any of these IAs, the client may either try another server (perhaps restarting the DHCP server discovery process) or use the Information-request message to obtain other configuration information only.

Zweite Variante:

When the client receives a Reply message in response to a Renew or Rebind message, the client:

o Sends a Request message to the server that responded if any of the IAs in 
  the Reply message contain the NoBinding status code. The client places 
  IA options in this message for all IAs.

Die erste Variante trifft zu, wenn man den Passus "client finds no usable addresses and/or delegated prefixes" als zutreffend interpretiert, denn anstelle der "IA address"- bw. "IA Prefix"-Sub-Optionen sind jeweils die Status Codes "NoBinding" enthalten.

Man könnte diesen Passus aber auch so interpretieren, dass zwar "IA address"- bw. "IA Prefix"-Sub-Optionen vorhanden sind, diese jedoch "Null"-Adressen enthalten (wie bei einem DHCPv6-Solicit: keine "IA address"-Option in IA_NA, "Prefix address" = :: in IA_PD).

Weil das aber in unserem Fall nicht zutrifft, wäre bei dieser Deutung dann die zweite Variante zutreffend, die explizit auf den NoBinding-Status eingeht (erscheint mir plausibler):

Demnach sollte der DHCPv6-Client einen Request ähnlich einem DHCPv6 Solicit senden, in dem allerdings abweichend von einem "echten" Solicit eine "Server Identifier"-Option des Servers enthalten ist, von dem Paket #6 gesendet wurde.

Das käme im Grunde dem sofortigen Start eines neuen Exchanges (Solicit - Advertise - Request -Reply) gleich, nur eben mit keinem allgemeinen Solicit an beliebige (ungenannte) DHCPv6-Server, sondern an den einen, der zuvor Paket #6 gesendet hat.

Dein DHCPv6-Client scheint mehr der ersten Variante zu folgen, indem er den Passus the client may either try another server (perhaps restarting the DHCP server discovery process) (zunächst) durch das Senden von DHCPv6-Rebinds umsetzt.

Zitat von fiberv6

2a00:1f38::/32 und 2a0f:f140::/29 scheint aber nicht announced zu werden

Gibt es eine Pflicht, eigene Präfixe zu announcen, wenn diese ggf. nur einen Reserve-Status haben, also aktuell nicht genutzt werden?

Also laut meiner Statistik sind das die IPv6-DG-Netze:

IPv6-Count:
2a00:1f38::/32				netname: DE-DGW-20100415			 1x /32
2a00:6020::/32				netname: DE-DGW-20130322			 1x /32
2a00:61e0::/32				netname: DE-DGW-20130326			 1x /32
2a03:fc0::/32				netname: DE-DGW-20121010			 1x /32
2a03:1d60::/32				netname: DE-DGBUSINESS-20140731		 1x /32
2a0f:f140::/29				netname: DE-DGBUSINESS-20200928		 8x /32
-----------------------------------------------------------------------
																13x /32

Mit dieser RIPE-DB-Anfrage ermittelt:

Zitat von fiberv6

denke ich mal, dass da "Profis" am Werk sind.

Vielleicht können die sich keinen Nokia-Consultant leisten, der ihnen die Handhabung der gekauften Plattform erklärt.

Zitat von fiberv6

Habe nochmal spaßeshalber nach /44 gefragt, dann bekomme ich aber immer nur ein /48.

Genau das hätte ich sinngemäß auch für die Konstellation /48 (statt /44) in Verbindung mit /56 (statt /48) erwartet.

Dass du tatsächlich auch einen /48 bekommst, würde ich als Fehl-Konfiguration des DG-DHCPv6-Servers deuten - da sind wohl die entsprechenden Vergabe-Richtlinien nicht korrekt implementiert.

Deine WAN-Adresse scheint nochmal gewechselt zu haben (von ::71 auf ::82)? Zumindest laut keycdn-Traceroute, wenn ich dort den /48 aus deinem Paketmitschnitt eingebe. Der /48 wird offenbar auch zu deinem Anschluss geroutet.

Was man bei DG so alles erlebt - von /64-Beschränkungen bis /48-Großzügigkeiten. Was ist da nur los?

Zitat von fiberv6

Einen anderes DHCPv6 client probieren und den mal ein paar Tage laufen lassen um zu beobachten wie der damit umgeht

Gute Idee!

Zitat von fiberv6

Also müssten die mehrere Kunden in einem /48 haben und die dann jeweils da durch-rotieren. Dann müssen sie ja immer in jedem /48 ein bisschen Platz lassen um die Möglichkeit zu haben einen Kunden von seinem /56 zu vertreiben. (Aber vielleicht bekomme ich ja irgendwann noch ein /56 von einem anderen /48?)

So würde ich das auch sehen.

Zitat von fiberv6

Einfach mal das gesamte /48 anfordern?

Dürfte sinnlos sein, wird der DHCPv6-Server abweisen.

Schau die mal die Connection History dieser Ripe-Atlas Probes an DG-Anschlüssen an, bei denen wie bei deinem ab und zu die IPv6-Adressen wechseln: #29306, #53014, #1001325, #1014833. Das dauert häufig nur wenige Sekunden. Außer bei #1001325 sind da Fritzboxen im Einsatz.

Zitat von fiberv6

Aber das liegt daran, dass mein DHCPv6 client nicht sofort einen neuen Solicit startet. Das ist also meine Schuld.

Liegt es in deiner Macht, das Verhalten zu beeinflussen?

Zitat von fiberv6

Anbei der Mitschnitt vom Verlust heute 17:33:30 UTC.

Finde ich schon interessant:

• #6 17:02:20,061: Das letzte Renew wird mit Status code 13 NoBinding (3), den Timern T1=T2=0 und ohne IPv6-Leasedaten abgewiesen. Jetzt ist die Deutung schwierig, was lt. Standard nun das richtige Folgeverhalten ist.
• #7 17:02:28,608: Dein Router sendet einen Rebind (sollte er das?)
• #8 17:02:28,647: Der Rebind wird mit Reply beantwortet, es stehen sogar die gewünschten IPv6-Adressen darin, einen Status-Code gibt es nicht. ABER: T1=T2=0, somit keine verwendbare Lease! Diese Antwort wirkt merkwürdig.
• #9 - #16: 17:02:37,729 - 17:28:45,295: Fast eine halbe Stunde sinnloses Senden von Rebinds (mit exponential backoff, d.h. der Zeitabstand zwischen zwei aufeinander folgenden Rebinds verdoppelt sich jeweils), die nicht beantwortet werden!
• #17 17:33:30,859 - ein erlösender neuer Exchange beginnt: Solicit - Advertise - Request - Reply - Endlich neue Lease ab 17:33:3,975 mit geänderten IPv6-Werten.

Das sieht ehrlich gesagt nicht sonderlich "gesund" aus - ich kann allerdings ohne Tiefenanalyse von RFC9915 aktuell nicht bewerten, welche Seite hier genau was falsch macht.

Zitat von fiberv6

Ein quasi statisches Präfix verursacht ja keinerlei weitere Kosten beim ISP.

Nein, aber vielleicht möchte dich DG dazu bringen, einen Business-Anschluss zu ordern 😉

Kannst du mir bitte noch verraten, wie genau der Verlust der Lease abläuft?

1. Wird ein Renew (oder ggf. Rebind) explizit mit einem NAK abgelehnt?
2. Oder läuft einfach der Leasetimer (1h) ab?

Du hast allerdings keinen Anspruch auf quasi-statische IPv6-Adressen. Das ist seitens DG nur ein "nice to have" (in der Regel bei älteren Anschlüssen).

Zitat von fiberv6

Aber das verlieren des DHCPv6 Lease nervt mich.

Ich denke, du meinst eher den Zeitpunkt des Lease-Verlustes (während üblicher Internet-Nutzungszeiten), nicht den Verlust als solchem mit Zuweisung geänderter Adressen?

Zitat von fiberv6

Danke für die Infos. Das überschneidet sich alles mit dem was ich hier sehe.

Hier noch die Vergleichsquelle:

Thread "Kein Traffic über IPv6 möglich (Deutsche Glasfaser)" vom 01.11.2024.

Dort der Fall von sh0rty beginnend mit #115 am 23.01.2026 und sein Paket-Mitschnitt in #119.