Beiträge von fiberv6

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

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

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.

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

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.

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

Looking through the source of systemd-networkd 255 actually basically ignores the IA completely with the NoBinding. That's why it gets stuck in this rebind loop for 30 minutes. It's acting like it didn't get a response at all.

Current main branch systemd-networkd should go into a completely new SOLICIT based on the source.

dhcpcd looks to actually follow our expectations exactly. It should be doing a REQUEST for all IAs.

(lol, sorry für Englisch, passiert mir manchmal automatisch)

Werde mal dhcpcd testen.

Zitat von ::1

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

Zumahl heute morgen ja das Präfix nichtmal geändert wurde. Warum also NoBinding für IA_PD? Macht überhaupt keinen Sinn. Und die zufälligen Uhrzeiten und Zeitabstände in denen das passiert.

Ich glaube nicht, dass das tatsächlich ein absichtliches Verhalten ist.

Ich werde später heute entweder wide dhcpv6 oder odhcp ausprobieren. Obwohl ich gerne nochmal aufgenommen hätte welche RAs mein Router in den 30 Minuten auf LAN Seite sendet. Sehr nervig für jedes Experiment 1 bis 7 Tage warten zu müssen.

Und wenn ich es korrekt verstehe kann mein Client die IA_NA und IA_PD währenddessen auch noch weiter verwenden, da die lifetime ja nicht auf 0 gesetzt ist. Lediglich T1 und T2 sind 0. Lifetime ist gar nicht vorhanden.

Das Verhalten des DHCPv6 Servers bleibt immer noch seltsam. Warum dieses Spiel mit NoBinding, nur um mir immer noch das selbe /48 zu geben und lediglich die IA_NA zu ändern (immer noch aus dem selben /64).

Zitat von ::1

Zweite Variante:

Code

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.

Ich habe nochmal intensiv RFC9915 gelesen. Und ich lese es so, dass Variante 2 die richtige ist. Hauptsächlich, weil die spezifischer den vorliegenden Fall beschreibt. Variante 1 lese ich mehr als "catch-all".

Lese gerade den Quellcode für systemd-netword um festzustellen wie das intern genau funktioniert in diesem Fall.

Werde jetzt nochmal zusätzlich alle RAs in meinem LAN mitschneiden..... Mehr monitoring ist immer besser!😜

Edit: Letzter Post wahrscheinlich nicht richtig, der 30 Minuten Bereich hat vielleicht doch 100% packet loss. Muss ich mir später anschauen.

Das mit kein failover zu IPv4 wäre merkwürdig. Ich bin mir relativ sicher das die RAs den clients bei dem gefailten Renewal klar machen das keine IPv6 default route mehr da ist. Zumindest mein Linux smokeping kriegt es mit (Uhrzeit in UTC):

Kein packet loss, über die 30 Minuten (in denen mein DHCP Server leider nicht gleich den neuen solicit started), sondern halt keine Verbindung. Bei 100% packet loss währe das rot markiert.

Als Vergleich hier smokeping für IPv4 in dem Zeitraum:

Kurzer Morgen-Post: (Lese den Beitrag von ::1 später, habe nur kurz Zeit):

Heute morgen (ca. 7:30) hat der Renewal wieder nicht funktioniert, obwohl ich hinterher wieder genau das selbe /48 Prefix bekommen habe (die WAN /128 hat sich allerdings geändert).

Dieses mal hatte es aber tatsächlich Auswirkungen auf die Homeoffice OpenVPN Verbindung von meiner Mutter. Also das wäre tatsächlich der Fall den man auch dem Level 1 Support schildern kann und ist nicht einmal ausgedacht.

Bin mit OpenVPN nicht so vertraut, warum läuft das als Client nicht wenn IPv6 weg ist? Muss sich das per STUN/ICE verbinden und der CGNAT ist symmetrisch? Das wäre jetzt meine schnelle Vermutung. Weil als normaler IPv4 Client sollte ja weiterhin alles funktionieren. Oder vielleicht hat der Laptop noch eine zugewiesene IPv6 und failed nicht over?

Bin später heute allerdings wieder an dem Standort und schaue mir mal per Capture an, was der OpenVPN Client macht.

Zitat von ::1

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

Ich denke mal nicht. Allerdings stellt sich bei Nichtbenutzung über Jahre die Frage ob dann vielleicht nicht verlängert wird:

Zitat

RIRs will generally renew licenses automatically, provided requesting organisations are making a “good faith” effort at meeting the criteria under which they qualified for or were granted an allocation or assignment. However, in those cases where a requesting organisation is not using the address space as intended, or is showing bad faith in following through on the associated obligation, RIRs reserve the right to not renew the license.

Zitat

To qualify for an initial allocation of IPv6 address space, an LIR must have a plan for making sub-allocations to other organisations and/or End Site assignments within two years.

Aber es ist natürlich nicht so, dass ein unbenutztes /29 irgendwie entscheidend ist.

Zitat von ::1

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

Code

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:

https://apps.db.ripe.net/db-web-ui/quer…&types=inet6num

2a00:1f38::/32 und 2a0f:f140::/29 scheint aber nicht announced zu werden: https://bgp.he.net/AS60294#_prefixes6

Das letzte mal war 2a0f:f140::/29 durch AS41776 verwendet. Das war aber 2023.

Zitat von Funker

Das macht heutzutage der LLM-Agent. Da kommt genau sowas bei raus.

Das kann sehr gut sein. Gerade die 192.168.101.1...

Nachdem ich das ganze für ein bisschen beobachtet habe werde ich mir überlegen wie ich DG das ganze melde. Wenn die diese Konfiguration über das gesamte Netz verteilen.... oder "modernisieren" könnte das ein echtes Problem sein.

Wenn jede Fritz Box ein /48 anfordert (ist aber hoffentlich nicht die Werkseinstellung) kann das halt ein richtig schöner DOS für das gesamte Netz sein. Es gibt halt nur genügend /48 für ca 25% der Kunden.

Aber erstmal möchte ich sehen ob das /48 stabil ist.

Unabhängig davon finde ich es merkwürdig das DG 4 /32 hat, die nicht contiguous sind. Die hätten von RIPE NCC auch ein /29 (8 /32) bekommen können ohne weitere Dokumentation. Die sorgen so halt für 3 unnötige Eintrage in der ipv6 route table.

Zitat von ::1

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.

Ja, die IA_NA ist jetzt ::82. Und das /48 ist komplett geroutet. Ich habe sowohl 2a00:61e0:9d41:0000::/64 und 2a00:61e0:9d41:ffff::/64 getestet und es geht traffic sowohl raus als auch wieder rein.

Zitat von ::1

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

Zusammen mit DHCP Server bei 192.168.101.1 denke ich mal, dass da "Profis" am Werk sind.