Je viens de faire la modif sur mon routeur et redémarrer, honnêtement en pratique je ne vois aucune différence mais tu t'y connais plus que moi donc je mets à jour le fichier dans mon post en prenant en compte ta remarque 

@bigboo @Oxgrm :

L'ordre compte mais pas toujours. En l'occurrence, je me suis trompé.

Ma formation en informatique est éparse. Lorsque de mon initiation à nftables, je n'avais pas encore abordé la couche transport TCP/UDP.

Hyperlien : Questions about nftables and rule processing order

Ma réponse était ambivalente.

Il faut placer les règles ci-dessous en premier.

oifname "wan.832" ip dscp set cs0
oifname "wan.832" ip6 dscp set cs0

Sinon, le trafic DHCP & Co. devant être en cs6 sera retaggé en cs0. J'ai mélangé le rôle de la politique par défaut de la chaîne avec une déclaration finale « verdict » ACCEPT dans une règle.

@nando11 :

L'application d'un correctif à odhcpd a abouti sur une cascade de modifications : DUID global + IAID. Pour en savoir plus, lire le commentaire de Noltari dans le ticket « 25.12.0-rc3 breaks static DHCP from network ».

dhcp.sh

Code: [Sélectionner]

[ -z "$clientid" ] && clientid="$(proto_dhcp_get_default_clientid "$iface")"
[ -n "$clientid" ] && clientid="-x 0x3d:${clientid//:/}"

Commit e24ac1c (odhcp6c)

Code: [Sélectionner]

diff --git a/src/dhcpv6.c b/src/dhcpv6.c
index fa0c2a1..2075006 100644
--- a/src/dhcpv6.c
+++ b/src/dhcpv6.c
@@ -479,9 +479,11 @@ static void dhcpv6_send(enum dhcpv6_msg type, uint8_t trid[3], uint32_t ecs)
        ia_na_entries /= sizeof(*e);
 
        struct dhcpv6_ia_hdr hdr_ia_na = {
-               htons(DHCPV6_OPT_IA_NA),
-               htons(sizeof(hdr_ia_na) - 4),
-               htonl(1), 0, 0
+               .type = htons(DHCPV6_OPT_IA_NA),
+               .len = htons(sizeof(hdr_ia_na) - 4),
+               .iaid = htonl(ifindex),
+               .t1 = 0,
+               .t2 = 0,
        };
 
        struct dhcpv6_ia_addr pa[ia_na_entries];
@@ -1156,7 +1158,7 @@ static int dhcpv6_handle_reply(enum dhcpv6_msg orig, _unused const int rc,
                                        continue;
 
                                // Test ID
-                               if (ia_hdr->iaid != htonl(1) && otype == DHCPV6_OPT_IA_NA)
+                               if (ia_hdr->iaid != htonl(ifindex) && otype == DHCPV6_OPT_IA_NA)
                                        continue;
 
                                uint16_t code = DHCPV6_Success;


En résumé, il n'y a que le changement de DUID qui est potentiellement impactant. Dans la requête d'intégration, on voit que la modif. correspond à IA_NA et pas à IA_PD.

Édit : D'ailleurs c'est assez curieux que IA_PD ne soit pas traité. Un oubli ?

Merci pour l'info.
Au final, après avoir débranché l'ONT un bon quart d'heure, l'ipv6 est de retour.
Sans ajout de l'option iaid ni suppression de la nouvelle option 'dhcp_default_duid' comme je pensais le faire au début.
Bref, j'ai laissé la chaîne générée par défaut.

config globals 'globals'
        option dhcp_default_duid '***'
Je pense que le fait d'avoir éteint momentanément l'ONT a dû aider.
Testé avec deux routeurs (mips et x86-64)

@nando11 :

Le nouveau DUID est global, de type UUID. Et dorénavant, le client DHCPv4 utilise le même DUID que le client DHCPv6 par défaut.
OpenWrt permet de définir le clientid (DUID) comme indiqué dans le tutoriel. On a une référence au DUID dans mise en conformité
protocolaire Orange. Pas de changement DUID pour les gens ayant suivi le tutoriel. L'IAID doit changer à chaque Release.

---

TLDR;

Le sujet est assez complexe.

Un IA_PD peut être associé au client, un ensemble d'interfaces, ou exactement une interface spécifique. Les IAID sont uniques pour
un type donné. Une interface peut se constituer un groupe contenant plusieurs IA_PD ou n'allouer qu'un seul IA_PD selon le routeur.

12. Identity Association

The IAID uniquely identifies the IA and MUST be chosen to be unique among the IAIDs for that IA type on the client [...]

One IA_PD can be associated with the client, with a set of interfaces, or with exactly one interface. A client configured to request delegated prefixes must create at
least one distinct IA_PD. It may associate a distinct IA_PD with each of its downstream network interfaces and use that IA_PD to obtain a prefix for that interface
from the server. [...]

If the client wishes to obtain a distinctly new address or prefix and deprecate the existing one, the client sends a Release message to the server for the IAs using
the original IAID. The client then creates a new IAID, to be used in future messages to obtain leases for the new IA.

RFC 9915 -- PAGE 31

Le client peut demander plusieurs IA_PD dans le même message DHCPv6.

An IA_PD option may only appear in the options area of a DHCP message. A DHCP message may contain multiple IA_PD options (though each must have a unique IAID).

RFC 9915 -- PAGE 95

13.2. Assignment of Prefixes for IA_PD

The mechanism through which the server selects prefix(es) for delegation is not specified in this document. Examples of ways in which the server might select prefix(es) for
a client include static assignment based on subscription to an ISP, dynamic assignment from a pool of available prefixes, and selection based on an external authority such
as a RADIUS server using the Framed-IPv6-Prefix option as described in [RFC3162].

RFC 9915 -- PAGE 32