Voici le résultat des tests :

Pour la partie dynamique, rien. J'ai vérifié que je n'avais aucun firewall actif (ni sur la Bbox, ni sur la gateway). J'ai connecté une machine sur le réseau de la Bbox (donc *devant* la gateway, avec une adresse en 2001:xxxx:xxxx:xxx0:/64) et tenté de pinguer une machine derrière la gateway (donc sur le subnet 2001:xxxx:xxxx:xxx3:/64). Pas de réponse au ping et rien d'observable via tcpdump sur la gateway. Pour moi, il n'y a donc pas de trafic qui passe ; c'est la Bbox qui est en cause et qui ne route pas correctement le trafic. 
Il y a d'ailleurs une vraie cafouillage entre la Bbox et la gateway : j'avais demandé à déléguer le préfixe 2001:xxxx:xxxx:xxx1:/64, mais la gateway utilise sur son port WAN le préfixe 2001:xxxx:xxxx:xxx3:/64. Il y a donc une incompréhension manifeste entre les deux.

En version statique : 
J'ai configuré la Bbox avec une délégation statique pour un préfixe 2001:xxxx:xxxx:xxx1:/64. J'ai configuré la partie WAN en DHCPv6, mais il est impossible de demander un simple réseau /64 ; je me suis donc rabattu sur un préfixe /64. 
La partie LAN est également configurée en statique avec le même préfixe (2001:xxxx:xxxx:xxx1:/64), comme indiqué. Ici non plus, rien ne fonctionne : je n'arrive même pas à obtenir une adresse IPv6 sur le port WAN de la gateway.

Au final, la seule configuration qui "fonctionne" est de supprimer tout type de délégation de préfixe sur la Bbox, de repasser la sécurité en mode normal, et de configurer la gateway avec :
- sur la partie WAN : SLAAC en mode "single network",
- sur la partie LAN : idem, "single network".

Dans ce cas, je retrouve le même préfixe (2001:xxxx:xxxx:xxx1:/64) aussi bien du côté de la Bbox que de celui de la gateway. Donc pas de séparation de sous-réseau entre avant et après la gateway.

Ma conclusion à ce stade est la suivante: 
L'absence de DUID au niveau de la Bbox signifie qu'aucune délégation de préfixe (dynamique ou statique) ne fonctionne. Cela semble confirmé par la RFC 8415, sections 6.1 et 11 (en tout cas pour le mode dynamique selon la RFC, et également en statique d'après mes tests). 
Même en parvenant via un appel API à contourner le refus de l'interface graphique pour une délégation statique, cela ne semble rien apporter (d'ailleurs, une simple désactivation de la règle — sans suppression via l'interface graphique — remet la MAC adresse de destination à vide).

Ce qui reste ouvert pour moi :
- Pourquoi la Bbox refuse-t-elle obstinément de générer un DUID pour ma gateway alors que tcpdump montre que la gateway fournit bien sa MAC adresse ?
- Est-ce que je tente de *spoofer* la MAC adresse d'une machine qui négocie correctement un DUID avec la Bbox, pour ensuite essayer de faire de la délégation de préfixe sur cette entrée spoofée avec la MAC de ma gateway ?

J'ai passé beaucoup trop de temps à essayer de faire fonctionner quelque chose qui, en théorie, devrait être simple. J'ai fini par faire de la rétro-ingénierie pour arriver à mes fins (délégation statique via API), utilisé tcpdump pour analyser les échanges réseau, pour finalement aboutir à rien.

À ce stade, je suis intimement convaincu que c'est la Bbox qui est fautive (sans toutefois en avoir une preuve absolue). 
J'ai une solution de repli qui me donne de l'IPv6 derrière la gateway (SLAAC en single network), et j'arrête les frais ici. 
Si je retrouve un peu de motivation, je tenterai peut-être du spoofing de MAC, et dans tous les cas, je réessaierai ponctuellement lors de la sortie d'une nouvelle version de firmware pour la Bbox ou la gateway.

Dans tous les cas, un grand merci à @kgersen pour toutes ses informations éclairantes !

Au final, la seule configuration qui "fonctionne" est de supprimer tout type de délégation de préfixe sur la Bbox, de repasser la sécurité en mode normal, et de configurer la gateway avec :
- sur la partie WAN : SLAAC en mode "single network",
- sur la partie LAN : idem, "single network".

Dans ce cas, je retrouve le même préfixe (2001:xxxx:xxxx:xxx1:/64) aussi bien du côté de la Bbox que de celui de la gateway. Donc pas de séparation de sous-réseau entre avant et après la gateway.

...

J'ai une solution de repli qui me donne de l'IPv6 derrière la gateway (SLAAC en single network), et j'arrête les frais ici.

t'as aussi xxxx1 sur l'interface wan en slaac ?

Le meme /64 de chaque coté (lan et wan) ca ne peut fonctionner sauf à faire du "ndproxy".

donc si ca fonctionne avec xxxx1 coté LAN c'est que tu es en délégation statique. un appareil en wifi sur la bbox est en xxxx1 ou autre chose ?

sinon ce n'est pas tres clair...

Désolé, je n'étais pas claire.

La configuration qui fonctionne me donne du 2001:xxxx:xxxx:xxx0:/64 (j'ai écris pas erreur dans mon post précédent 2001:xxxx:xxxx:xxx1:/64) aussi bien derrière la bbox (et donc devant la gateway) comme par exemple pour la BouygeTV. Ma gateway elle a une adresse WAN sur le subnet 2001:xxxx:xxxx:xxx0:/64 et le même préfixe est utilisé sur la partie LAN (derrière la gateway donc). Au final cette configuration fonctionne et j'ai tout le monde sur 2001:xxxx:xxxx:xxx0:/64. Pour moi cela signifie que c'est la bbox qui distribue les IPv6 à tout le monde y inclus derrière la gateway car dans la bbox il n'y a aucune délégation de préfixe demandé (ni statique, ni dynamique).

J'espère que c'est plus claire ainsi.

ah curieux que ca fonctionne 

Pourquoi étrange ? C'est le mode "normal" de l'ipv6 sur bbox qui fait des annonces RA en utilisant le ::0/64 dès qu'elle reçoit son prefix /60 du serveur DHCPv6 de Bouygues.

Ce n'est pas ca qui est curieux.

Ce qui est curieux c'est son routeur qui fait du NDProxy (ou alors c'est du bridge) entre son LAN et son WAN.

bbox -- lan 1 (xxx:0::/64) -- routeur -- lan 2 (xxx:0::/64) -- pc


Il a 2 LAN avec le meme préfixe.

Y'a forcement une config sur le UnifiClougGateway Max qui soit proxy soit laisse passer les annonces RA, soit bridge pour que ce soit le cas... Du coup les périphériques du lan recoivent toute l'annonce RA ? Y compris le DNS ipv6 de Bouygues ?

oui on peut présumer cela mais comme Ubiquiti et la doc technique précise ca fait 4 ...

Mes observations sur la délégation de prefixe en /60 chez Bouygues FTTH derrière la Bbox.
- un prefixe délégué /64 par MAC, c'est à dire un par port de la Bbox dans la limite de 3 (le 1er /64 est utilisé par Bbox).
- sous Linux, par exemple OpenWRT, on peut utiliser 3 adaptateur WAN6, en MACVLAN mode VEPA avec interface en DHCPv6c, demandant un prefixe chacun. Le préfixe peut être suggéré par OpenWRT, et/ou mis en static dans l'interface Bbox. En clair, un port de la Bbox suffit à faire passer les 3 préfixes /64, à l'aide d'adresse MAC différentes permis par 3 interfaces  WAN configurés en IPv6.
- il reste à utiliser ces 3 préfixes dans max 3 interfaces IPv6 /64 ou dual stack IPv4/IPv6 (LAN, IOT, Kubernetes, ...), en filtrant le préfixe dans OpenWRT (j'ai pas testédans une distro linux ce point).
- A noter on peut utiliser les 3 préfixes sur 1 interface par exemple pour de la redondance d'adresses GUA avec cette technique et 2 Boxes... (Cf fin de ce message)

FreeBSD n'a pas ces drivers MACVLAN, et c'est difficile de faire le portage, donc PfSense et dérivés n'ont pas ce luxe, et pour faire la même chose, il faut se passer de la Bbox (ce qui est hasardeux car pas supporté), ou changer d'opérateur pour avoir un préfixe délégué plus grand en un bloc.

RouterOS peut le faire normalement, j'ai pas été plus loin qu'un seul préfixe dans ce cas.

MAIS, depuis un an, j'ai des problèmes de routage fréquents en IPv6, et de moins en moins de problème pour récupérer les plages d'adresses DHCPv6.
Dans ce cas avec l'adressage GUA du réseau est partiellement ou complètement KO. Pour le failover (communiquer en local en IPv6) il faut donc en parallèle un adressage LUA.
Dans Mikrotik/OpenWRT c'est possible, + simple dans OpenWRT.
Dans PfSense et dérivés, il faut passer attribuer une Virtual IP sur les subnets de type LAN ("fd..."), pour que le routeur ait sa propre LUA. Et si on utilise DNS Resolver (Unbound), il y a cette Virtual IP qui apparait par magie en interface entrante Unbound (fallait le savoir).