Si on veut régénérer les chaînes d'auth, c'est probablement le plus pragmatique. Je suis de ton avis: modifier les chaînes d'auth en milieu de bail n'est pas une bonne idée.

Bonjour

Cela fonctionnerait (de changer les chaine en milieu de bail) mais la logique du DHCP est de garder les mêmes identifiant sur la session.

Il est mieux (mais pas impératif) de garder les info d'auth cohérente sur les deux stack sur la durée de la session dans le BNG. Mais là aussi ce n'est pas impératif dans l'implémentation actuelle.

Pour rappel, une session BNG est ouverte à la monté du premier stack v4 ou v6.
Et est fermée à la cloture (RELEASE ou DECO par timer) du dernier stack.
Entre l'ouverture et la fermeture du contexte BNG, on peut avoir autant de START/STOP des stack v4 ou v6 à la condition que l'un des deux reste connecté.
Le BNG considère qu'un client est "vivant" tant que l'un au moins des stack v4 ou v6 est en vie.
C'est le comportement de 3 des 4 fournisseurs de BNG, dont celui que l'on utilise chez Orange. Le dernier est un peu différent mais je ne me souviens plus du détail.

LeVieux

Donc si je comprends bien on renouvelle les valeurs au boot du routeur, ou lors d'une déco complète (qd on retire la fibre ?) ?

C'est l'idée, où quand tu relances tes deux stack v4 v6 si tu as besoin.
Là tu seras déco par les 2 releases et effectivement tu n'auras plus de contexte sur ton BNG

LeVieux

J'ai étudié en détail divers RFC pour intégrer proprement le mécanisme d'authentification dans OpenWrt.

Force est de constater que ce n'est pas conforme aux standards même en faisant des concessions sur l'usage du
protocole CHAP pour générer dynamiquement le jeton de configuration.

Le protocole « Token Configuration » du RFC3118 (DHCPv4) n'est pas été porté en DHCPv6 comme ce fut le cas pour
le protocole « Delayed Authentication » dans le RFC3315 (mais rendu obsolète depuis le RFC8415). Je trouve que c'est
plutôt embêtant d'inclure une extension propriétaire dans le client DHCPv6 odhcp6c de prplos puis OpenWrt.

Il faut tout de même reconnaître que le format de l'option d'authentification reste identique au standard et que cette
extension n'est pas aberrante.

De plus, on ne devrait pas spécifier l'option 11 dans l'Option Request Option car c'est formellement interdit par le RFC9915.
Je suppose qu'il en est de même pour l'option 90 dans la Parameter Request List en DHCPv4 même si ce n'est pas spécifié.

The Option Request option MUST NOT include the following option codes:
...
Authentication (see Section 21.11)
...

Hyperlien : https://www.rfc-editor.org/rfc/rfc9915.html#name-option-request-option

Si je fais ces remarques c'est parce que j'aurais voulu intégrer officiellement le support du protocole dans les serveurs DHCP
d'OpenWrt pour pouvoir activer la Livebox derrière mon routeur pour la téléphonie fixe. Cela aurait pu être valable si c'était
conforme aux standards sinon l'intérêt de le supporter est moindre dans le sens général.