Delegated IPv6 Präfix wird sehr zeitverzögert aktualisiert

[meyergru]

Ich erinnere mich dunkel, dass ich früher damit auch mal Probleme hatte - da lag es daran, dass dummerweise bei der Neuvergabe von IPv6 die inzwischen verworfenen Adressen normalerweise bestehen bleiben.

Grundsätzlich ist die Annahme bei IPv6 zum einen, dass mehrere Präfixe gleichzeitig gelten dürfen (Beispiel ULA vs. GUA, aber eben auch mehrere GUAs) und dass zum anderen kein Mangel an Adressen herrscht. Die RFCs sehen also den Fall "dynamischer Präfix unter Wegfall des alten Präfix" gar nicht so richtig vor.

Einen Trick, den man bei SLAAC anwenden kann, ist, dass man ein RA schickt, mit dem der alte Präfix invalidiert wird, bevor man einen neuen annonciert. Dadurch würden die Clients ihre alten GUAs aufgeben. Voraussetzung ist, dass der Router das so macht und derweil die alte (noch) und neue Adresse (schon) kennt. Resettet man z.B. den Router einfach, bleiben die alten Clients lange noch auf der falschen GUA hängen.

Ich mache deshalb typischerweise nur SLAAC mit sehr kurzen Gültigkeiten, damit veraltete Adressen schnellstmöglich verworfen werden. Ich kann es aktuell aber gar nicht testen, weil mein ISP IPv4 dynamisch, aber IPv6 GUAs quasi-statisch vergibt.

[Cyberturtle]

Du sprichst von dem AdvDeprecatePrefix oder?
Ich kann ja mal nen Screenshot posten, wie ich die Zeiten eingestellt habe. Ich habe ebenfalls kurze Zeiten gewählt, damit die Präfixe schnell aktualisiert werden. Habe aktuell allerdings keine nächtliche Zwangstrennung mehr. Nur noch sporadisch, wenn der DSLAM mal wieder thermische Probleme hat.

Edit: Hier der Screenshot. Neue Präfixe werden ja nur bevorzugt, wenn sie größer als 2h sind. Die PreferredTime ist gerade bei iOS Clients wichtig.

[meyergru]

Aus meiner Erinnerung ist es so, dass ein solcher RA einfach eine neue Lifetime von 0 für den alten Präfix vorgibt, damit wird er am Client sofort invalidiert. Danach wird dann der neue Präfix annonciert.

Ich kenne aber die RADVD Parameter dafür nicht, bzw. ich weiß gar nicht, ob der so etwas kann. Die Fritzbox nutzt m.W. auch keinen RADVD, sondern eine eigene Implementierung dafür. Mir ist aber klar, dass es da (leider) für manche Parameter Untergrenzen gibt, damit sie überhaupt berücksichtigt werden. Das Thema wurde auch schon mal hier diskutiert: https://forum.opnsense.org/index.php?topic=21682.0

Leider ist es so, dass die Client-Implementierungen z.T. auch abweichende Interpretationen machen, wie Du richtig schreibst. Ohne Ausprobieren kommt man also nicht viel weiter - und wie gesagt, ich kann derzeit nicht konkret helfen.

[Cyberturtle]

Dann meinen wir dasselbe. Mit dem DeprecatePrefix Parameter wird die Zero PreferredLifetime und ValidLifetime mit etwas mehr als zwei Stunden verteilt, damit der (Zero)Prefix nicht ignoriert wird. Ich glaube das war Kapitel 5.5.3 in der RFC dazu. Bin mir aber nicht sicher ob der Parameter nur beim Shutdown berücksichtigt wird.

[franco]

RADVD ist ja SLAAC, DHCPv6 ist DHCPv6...

Ich muss mich korrigieren. Gestern Abend habe ich mit "Neu verbinden" dann doch das gleiche Szenario gehabt wie bei einer Trennung vom DSL.

Ich weiss jetzt nicht genau ob ein RA hier was ausrichten kann, vielleicht eher RS. Die Frage ist ja eher was tut man in dem Fall die Lease ist nicht abgelaufen aber wird vom Server nicht mehr geführt?  Für so was würde man ja idealerweise eine Broadcast-Nachricht abgesetzt die sagt "Ich bin ein neuer Router. Wer mich kennt soll sich bitte jetzt neu anmelden per DHCPv6". Gibt es diese Nachricht nicht muss es über Plan B abgebildet werden:

Wir führen ein RENEW eben alle 5 Minuten aus. Das sieht unschön aus, aber hätte eine relativ rasche Neuvergabe der Lease zur Folge. Dann machen wir irgendwie DHCPv6 zu SLAAC.

Capture wäre eine Variante. Ich kann das morgen mal prüfen nach dem 23.1.8 Release heute welches Vorrang hat.
 

Grüsse
Franco

[Cyberturtle]

Moin zusammen,

habe heute früh die 23.1.8 eingespielt. Das Update lief ohne Probleme durch und im Gegensatz zur 23.1.7_3 wollte es auch einen Neustart haben.
Nachdem Neustart waren die Clients stellenweise noch bis zu 30 Minuten mit den alten IPv6-Adressen bzw. Präfixen unterwegs. Ich vermute, das liegt dann wirklich an der PreferredLifetime. Ich möchte vermeiden das RA auf 300s oder niederiger zu setzen, denn so häufig verliere ich dann auch nicht den DSL-Sync. Vermutlich liegt's aber auch daran, dass während des Updates ja die Patches zurückgesetzt werden und daher das RENEW etc. nicht sauber lief oder Tracking ausblieb. Ich habe heute noch den AdvDeprecatePrefix auf on gesetzt, in der Hoffnung, dass es mit der Zero-Lifetime etwas bringt.

Zur Fritzbox: ich habe gestern mal bei einem Bekannten schauen dürfen. Die Fritzbox scheint in einem solchen Fall tatsächlich ein Zero Valid-Lifetime RA rumzuschicken, selbst wenn der Präfix eigentlich noch seine Gültigkeite hätte, aber eben nicht mehr geführt wird, weil sich durch den Reconnect eben der Präfix geändert hat oder eine neue Lifetime bekommen hat (falls nochmal der alte rumgeschickt wird).
Mein Vorschlag wäre daher bei jedem Reconnect/PPPoE-Loss einfach einen RA mit der Zero-Valid Lifetime zu senden und anschileßend den neuen (manchmal ist's auch wieder der alte) Präfix zu verteilen.

Ich hoffe, ich hab mich da verständlich ausgedrückt. Das dürfte dann die sauberste Lösung sein.

Wie seht ihr das?

Beste Grüße
Cyberturtle

Edit: Nach einem Reboot, meine ich gestern übrigens auch ein RA mit Zero-Lifetime in der Fritzbox gesehen zu haben und dann im Anschluss wurde die neue IPv6-Adresse bei meinem Bekannten verteilt.

[franco]

Moin,

Nun ja das RA ist ja nur für SLAAC. Ob wir da jetzt WAN-seiting mit dem Hilfsmode SLAAC das eigentliche DHPCv6 "nachsteuern" wollen ist eine schwierige Frage... es wird zu vermehrten Verbindungsabbrüchen/Neuverbinden führen. Meine Frage war ja ob wir innerhalb DHCPv6 Möglichkeiten haben oder ob das schlicht nicht im RFC/Standard verankert ist.

LAN-seitig senden wir das entsprechende RA sofern nach dem Reconnect ein neuer Prefix gesetzt wird, sonst eben nicht. Ich sehe da kein Problem aktuell, bzw. keins das nicht schon gelöst wurde in 23.1.x. Aber auch hier betrifft das nur SLAAC/radvd und nicht DHCPv6 clients im LAN.

Das Update spielt zwar manuelle Patches zurück aber das RENEW/REBIND ist ja drin sowie alle dhcp6c Verbesserungen ausser dem letzten um mit Upstream-Verbindungsabbruch besser (bzw. überhaupt) klar zu kommen.

[meyergru]

Nun ja das RA ist ja nur für SLAAC. Ob wir da jetzt WAN-seiting mit dem Hilfsmode SLAAC das eigentliche DHPCv6 "nachsteuern" wollen ist eine schwierige Frage... es wird zu vermehrten Verbindungsabbrüchen/Neuverbinden führen. Meine Frage war ja ob wir innerhalb DHCPv6 Möglichkeiten haben oder ob das schlicht nicht im RFC/Standard verankert ist.

...was bei mir schon vor OpnSense der Hauptgrund war, nur SLAAC zu machen. Ich nutze IPv6 schon sehr lange und anfangs konnten die meisten Clients DHCPv6 noch gar nicht. Der Vorschlag von Cyberturtle, auf jeden Fall ein RA von 0 zu machen, wenn sich der Präfix ändert, kann m.E. nicht schaden (außer, wenn sich der Präfix NICHT ändert). Ich nehme an, das war der Grund für AVM, das so zu machen.

Was ich aber nicht wirklich weiß und aktuell eben auch dank statischer IPv6 Präfixe nicht ausprobieren kann, ist, ob man den RADVD zu diesem Verhalten bringen kann. Ich glaube nämlich, dass der bei Beendigung keinen RA 0 schickt und auch durch andere Signale oder bei Präfix-Änderungen immer nur den aktuellsten Präfix schickt.

Die Verkürzung der Lifetime darf man m.W. auch nicht zu weit treiben, da gibt es Minimalwerte für manche Parameter. Als ich vor kurzem mal mit den advanced Werten gespielt habe, war mein IPv6 prompt gestört.

[Cyberturtle]

Ja, die Zeiten muss man im Blick behalten. AVM schickt das Zero RA auch mit ner ValidLifetime mit etwas mehr als 7200s, damit das Ganze gemäß RFC läuft.
Bei 6to4, wo bspw. die IPv4 ebenfalls dynamisch ist und sich noch die IPv6 Adresse davon ableitet, werden sogar sehr kurze RAs nebst kurzen Lifetimes empfohlen. Da ist’s letztlich egal, ob ein alter Prefix bis um Ende seiner Laufzeit läuft, wenn er eh nur 300s mit Gültigkeit verschickt wird. Das habe ich auch hier mal getestet und lief auch vielversprechend.
Gleichzeitig muss man dann RDNSS (Max. 2-3x Max interval) im Blick behalten.

Ich habe bei mir auch nur Unmanged ohne DHCPv6 fürs LAN.

[franco]

Ich glaube wir sind hier etwas zu weit von der Realität im Code entfernt.

Fakten die wir in 23.1.x gelernt haben:

radvd SIGHUP sendet kein Zero Lifetime RA für den Prefix, ein Neustart des Daemons aber schon (bzw. der Exit).

SIGHUP hatten wir ja in 23.1.4 eingeführt und hat nicht richtig funktioniert wegen anderen radvd Problem. in 23.1.5 wurde das dann gelöst.

Nur SIGHUP war aber nicht praktikabel weil der Prefix nicht verschwindet. Dann wurde in 23.1.7 nachgebessert:

o dhcp: restart radvd on config changes, otherwise keep SIGHUP

Ich denke das funktioniert auch jetzt sinnvoll und hat früher schon so funktioniert. 23.1.4 bis 23.1.6 waren da ungeeignet, vielleicht waren das auch genau die Versionen die hier vordergründig angeschaut wurden.

Jetzt kommt aber noch die Ausnahme: DeprecatePrefix darf nicht auf "off" stehen. Das muss es aber z.B. im CARP Setup (Source Address mit CARP VIP). Das muss im Einzelfall beachtet werden weil dann die Grundvoraussetzung nicht gegeben ist.


Grüsse
Franco

[franco]

PS: DHCPv6 im LAN macht hautsächlich für Downstream-Router Sinn, v.a. wenn man einen Prefix delegieren will. Da gehe ich mit. Im WAN Bereich sind wir aber auf DHCPv6 als Client angewiesen aus bekannten Gründen. 

[Cyberturtle]

Mal ganz doof gefragt: was macht denn der Mitbewerber mit dem N im Namen mit der Plus-Version anders? Dort musste ich jedenfalls nicht die Zeiten im RA anpassen und es hat sich für mich wie die Fritzbox verhalten, wenn's ne neue Verbindung gab oder neue Präfixe. Dafür lief mir zu viel anderes nicht (MTU-Probleme, Shaper etc.).
Dort waren die Standardzeiten fürs Lease mit teilweise 86400 und 14400 Sekunden konfiguriert. Ich hab's seinerzeit leider nicht mitgeschnitten, ob da nen Deprecate mit Zero Lifetime rumgeschickt wird.

Nach den ganzen Patches, die mit 23.1.8 jetzt gekommen sind, sollte ich hier auch mal auf die Standardzeiten stellen oder versprecht ihr euch davon weniger?

Beste Grüße
Cyberturtle

[Cyberturtle]

Heute standen meine Interfaces leider wieder auf track6. :-(

Im Log finde ich auch keine Infos zu einem Renew oder force.

Edit: Gerade half auch kein reconnect oder sowas. Ich musste tatsächlich den Router neustarten, damit die Geräte wieder mit IPv6 versorgt wurden. Irgendwas scheint da noch nicht ganz zu passen und ich weiß nicht was. Ich habe nun auch mal wieder "Prevent release" aktiviert. Sollte ich das Gateway Monitoring für IPv6 auch mal aktivieren?

Edit2: Im Log stand tatsächlich doch etwas.

Code: [Select]

dhcp6c_script: RELEASE on pppoe0 executing kurz nach dem Neuaufbau der Verbindung. Ich hatte vor 23.1.8. auch Prevent Release aktiv. Es scheint wohl irgendwie das Häkchen abhanden gekommen zu sein. Kann das mit dem track6 daran liegen? Evtl. hat der ISP auf das RELEASE reagiert und dann hat sich keine neue IPv6 Adresse zuweisen lassen?

[franco]

Ohne dhcp6 (debug) Logs kann man da nichts sagen. Und https://github.com/opnsense/dhcp6c/commit/555bdcdef is ja auch noch offen...


Grüsse
Franco

[Cyberturtle]

Hey Franco,
wie wäre deine Empfehlung mit der 23.1.9 in Kombination „prevent Release“ zu testen?
Habe mich heute sehr über die Ankündigung der 23.1.9 gefreut (im RSS Feed).
Beste Grüße