suivant la version de systemd, les options peuvent changer avec le temps.

regarde la doc: https://www.freedesktop.org/software/systemd/man/latest/systemd.network.html

ClientIdentifier est spécifique a DHCPv4 (donc le truc que j'ai posté en 2023 est faux ou fonctionnait a l'époque).

Oui pas de soucis, j'ai bien vu la doc. Je postais pour prévenir les gens que la conf n'était pas parfaitement fonctionnelle.

si tu n'as pas de 2 eme interface qui a "DHCPPrefixDelegation=yes" il faut forcer la demande de préfix en ajoutant sur ton interface wan:

Code: [Sélectionner]

[Network]
DHCPPrefixDelegation=yes
[DHCPPrefixDelegation]
UplinkInterface=:self

sinon par défaut ca fait une requête d'adresse (IA_NA) et une requete de prefixe (IA_PD) d'ou la réponse recu.

Dans le paquet Solicit envoyé, il y a ça, c'est déjà IA_PD, non ?
Identity Association for Prefix Delegation
    Option: Identity Association for Prefix Delegation (25)
    Length: 12
    IAID: <un ID>
    T1: 0
    T2: 0

Je retesterai tout à l'heure les options que tu donnes mais aussi en ajoutant un prefix hint car il est mentionné sur OpenWRT et sur Mikrotik RouterOS. J'ajouterai aussi une délégation sur une seconde interface pour voir ce que ça donne.

Concernant le DUID, dans le topic le topic OpenWRT et celui sur Ubiquiti, il est question de mettre un préfixe de 00:03:00:01, ce qui correspond à du DUID-LL avec hardware type ethernet 00:01. Pourtant, dans testdhcpv6pd, tu utilises DUID-LLT. Est-ce que le routeur Bouygues accepterait les deux types de DUID ? Faut-il en préférer un ?

testdhcpv6pd permet l'un ou l'autre (option -cll) donc tu peux éventuellement tester directement avec pour savoir la bonne config. ensuite la mettre dans systemd (DUIDType).

Même avec l'option -cll, le script utilise DUID-LLT, jamais DUID-LL :
./testdhcpv6pd -cll 9C:24:72:XX:XX:XX enp2s0.100
2025/01/29 21:44:35 Sending a DHCPv6-PD Solicit on interface enp2s0.100
[dhcpv6] 2025/01/29 21:44:35 sent message: Message{
  MessageType=SOLICIT
  TransactionID=0x47771f
  Options: [
    Client ID: DUID-LLT{HWType=Ethernet HWAddr=9c:2d:cd:xx:xx:xx Time=791498675}
    Requested Options: DNS, Domain Search List
    Elapsed Time: 0s
    IAPD: IAID=0x01000000 T1=0s T2=0s Options=[
      IA Prefix: {PreferredLifetime=0s, ValidLifetime=0s, Prefix=::/64, Options={[]}}
    ]
    Client Link-Layer Address: Type=Ethernet LinkLayerAddress=9c:24:72:xx:xx:xx
  ]
}

La seule différence est qu'il ajoute l'option Client Link-Layer Address.

J'ai patché vite fait mal fait le code pour qu'il envoie un DUID-LL et ça fonctionne aussi.
diff --git a/main.go b/main.go
index 7723f93..cc6c58d 100644
--- a/main.go
+++ b/main.go
@@ -160,9 +160,8 @@ func main() {
                if err != nil {
                        log.Fatal(err)
                }
-               modifiers = append(modifiers, dhcpv6.WithClientID(&dhcpv6.DUIDLLT{
+               modifiers = append(modifiers, dhcpv6.WithClientID(&dhcpv6.DUIDLL{
                        HWType:        iana.HWTypeEthernet,
-                       Time:          dhcpv6.GetTime(),
                        LinkLayerAddr: mac,
                }))
        }
@@ -202,9 +201,8 @@ func main() {
 // derive the IAID in the IA_NA option.
 // same as nclient6/NewSolicit but without IAID
 func NewSolicit(hwaddr net.HardwareAddr, modifiers ...dhcpv6.Modifier) (*dhcpv6.Message, error) {
-       duid := &dhcpv6.DUIDLLT{
+       duid := &dhcpv6.DUIDLL{
                HWType:        iana.HWTypeEthernet,
-               Time:          dhcpv6.GetTime(),
                LinkLayerAddr: hwaddr,
        }
        m, err := dhcpv6.NewMessage()

D'ailleurs ça marche même avec ma vraie MAC dans le DUID. On dirait qu'une fois que j'ai reçu un préfixe avec un DUID, il faut attendre un certain temps pour que le routeur me répondre à nouveau si je prends un autre DUID.

J'imagine que quand j'aurai le routeur, avec la délégation sur la patte LAN, ce sera le LAN qui portera l'IPv6 publique pour y accéder ? Je ne vais pas faire de la délégation à la fois sur le LAN et sur le WAN juste pour une seule IP ?

oui en principe y'a pas besoin de GUA (ip public) sur le wan.

pour testdhcpv6pd y'a surement un bug merci du retour.

pour info, mise a jour de testdhcpv6p en version 1.0.5, l'url a aussi changé: https://github.com/nspeed-app/testdhcpv6pd

on peut maintenant spécifier correctement le DUID selon la norme ((type 1, 3 ou 4) et aussi demander plusieurs préfixes en meme temps (pas testé avec une bbox mais ca "fonctionne" avec une livebox).

non mis en oeuvre le type 2 (entreprise) et supprimer le 'client link layer option" (rfc6939) qui est plutot utilisé pour les relais dhcpv6.

bon je viens de tenter les nouvelles conf mais je n'ai pas plus de succès

par rapport à ta conf wobble
j'ai juste une erreur sur l'option IPv6Forwarding qui n'éxiste pas sur debian12 (v252 de systemd) mais de ce que j'en comprend ça ne devrait pas pose de soucis

ma conf :
[Match]
Name=enp4s0f1.100
Type=vlan

[Network]
DHCP=yes
IPv6Forwarding=yes
IPv6AcceptRA=yes
DHCPPrefixDelegation=yes

[DHCPPrefixDelegation]
UplinkInterface=:self

[DHCPv6]
# Ne pas envoyer IA_NA
UseAddress=no
WithoutRA=solicit
DUIDType=link-layer
PrefixDelegationHint=::/64
IAID=1

[IPv6AcceptRA]
UseDNS=no
3: enp4s0f1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 34:53:d2:0d:**** brd ff:ff:ff:ff:ff:ff permaddr 54:80:28:4f:****
    inet6 fe80::3653:d2ff:****/64 scope link
       valid_lft forever preferred_lft forever
4: enp4s0f1.100@enp4s0f1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 34:53:d2:0d:**** brd ff:ff:ff:ff:ff:ff
    inet 89.81.****/20 metric 1024 brd 89.81.**** scope global dynamic enp4s0f1.100
       valid_lft 7194sec preferred_lft 7194sec
    inet6 fe80::3653:d2ff:****/64 scope link
       valid_lft forever preferred_lft forever

bon je viens de tenter les nouvelles conf mais je n'ai pas plus de succès

par rapport à ta conf wobble
j'ai juste une erreur sur l'option IPv6Forwarding qui n'éxiste pas sur debian12 (v252 de systemd) mais de ce que j'en comprend ça ne devrait pas pose de soucis

En effet, ajouté en v256 dit https://www.freedesktop.org/software/systemd/man/latest/systemd.network.html#IPv6Forwarding=
Si tu as mis les sysctl à la main, ça revient au même. J'ai juste décidé de faire plus « moderne » en laissant SystemD le faire

Content qu'on soit deux chez qui ça fonctionne !