Après des heures de galère et la LB reset... J'ai enfin du ping qui arrive sur mon préfixe délégué \o/ J'ai aussi essayé un port sur l'adresse WAN de l'openwrt, ça marche, sauf que là c'est lui qui refuse la connexion (j'ai testé avec SSH, j'ai pourtant bien ajouté la règle dans son parefeu, sans doute un truc qui m'échappe)

Par contre, il y a encore un bug très bizarre, car j'ai cru que ça ne fonctionnait pas au début... Il ne faut pas que je coche tous les protocoles, en particulier AH et GRE pour que ça fonctionne. Dès que un des deux est coché, le ping ne passe plus. Ou alors c'est un spécial Livebox 4 ?

On va finir par leur faire tout le debug gratos 
02:46:42.296795 IP6 2a01:cbxx:xxx:xx00:79c2:8517:3db9:6d8 > 2a01:cbxx:xxx:xxea::1: ICMP6, echo request, seq 1, length 64
02:46:42.297355 IP6 2a01:cbxx:xxx:xxea::1 > 2a01:cbxx:xxx:xx00:79c2:8517:3db9:6d8: ICMP6, echo reply, seq 1, length 64
02:46:43.292621 IP6 2a01:cbxx:xxx:xx00:79c2:8517:3db9:6d8 > 2a01:cbxx:xxx:xxea::1: ICMP6, echo request, seq 2, length 64
02:46:43.293011 IP6 2a01:cbxx:xxx:xxea::1 > 2a01:cbxx:xxx:xx00:79c2:8517:3db9:6d8: ICMP6, echo reply, seq 2, length 64

EDIT : la connexion SSH marche si je joins le routeur par le préfixe délégué, peut-être le fait de l'adresse SLAAC côté WAN (ou une restriction en dur quelque part, car le port est techniquement ouvert, il répond un connection refused, sinon rien ne se passe). Du coup, plus besoin des règles de ports, vu qu'on ouvre tout le préfixe par les protocoles, nickel.

pour résumer:

* entre livebox et openwrt: c'est ok tu as 3 prefixes et ca route bien
* entre openwrt et autre routeur coté lan: tu n'arrives pas a déléguer automatiquement

donc c'est un problème (ou une limitation) d'odhcpd. t'as des logs en principe (logread -e dhcp) ? y'a quoi dans ton /etc/config/dhcp ? que donne 'ubus call dhcp ipv6leases' ?

Testé avec un 2nd openwrt en VM et une Linux mint derrière ça marche nickel, accès SSH validé. Et après plusieurs essais, j'ai enfin compris la logique du parefeu de la LB : pour que tout marche dans tous les cas il ne faut pas cocher TCP/UDP dans les protocoles sur LB monitor et faire les ouvertures de port une par une... Car si on regarde bien, TCP et UDP ne sont pas dans la liste des protos sur la LB, ceci explique sans doute cela.

Chose que je n'ai pas compris par contre, il a fallut que je définisse manuellement la route par défaut, alors que le SLAAC est bien actif côté WAN. Avec les tests sur ma debian un peu plus tôt, la route était bien mise en place comme n'importe quel hôte. Ou c'est lié au préfixe absent, y'a peut-être une mise en place automatique quand celui-ci est reçu.

EDIT : En comparant avec le routeur principal, il n'y a pas de route par défaut tout court, uniquement en fonction du préfixe, ce qui explique pourquoi elle était inexistante sur la VM. Il faut donc bien que le préfixe soit reçu sur le WAN.

Si j'arrive la mettre en place rapidement, je testerais aussi la délégation derrière la VM, peut-être que la version de mon routeur est trop ancienne (19.07), odhcpd a peut-être eu des MAJ depuis le temps.

Comment le routeur demandant un préfixe sait-il que d'autres préfixes proviennent tous du même préfixe délégué (par un autre moyen) ?

je ne comprend pas bien la question.

le routeur "demandant" ne connait rien. il fait un broadcast sur son interface wan et si y'a au moins un serveur dhcpv6-pd dessus, il aura une réponse.

@renaud07

J'ai testé avec une VM openwrt a jour. il y a bien une limitation : un /64 reçu delegation ne peut être redonné entièrement a un autre routeur.

Si on lui donne un /63 il saura donner 2 /64. c'est une limitation dans le code , le cas n'est pas prévu car en général quand on recoit un /64 c'est pour l'utiliser localement sur un autre interface (en général son LAN) et pas pour la re-déléguer a un autre équipement.

j'ai fait un peu le tour du sujet.
le principe de fonctionnement est:

client dhcpv6 sur wan: odhcp6c, il est basic, a chaque évènement dhcp il reconfigure l'interface.
pour les prefixes reçus en délégation, il appele la function proto_add_ipv6_prefix de netifd

on peut donc retrouver cette info dans netifd avec  ubus:

ubus  call network.interface.wan6 statuson trouvera dans le résultat:
        "ipv6-prefix": [
                {
                        "address": "2a01:xxxx:xxxx:78d1::",
                        "mask": 64,
                        "preferred": 588,
                        "valid": 86388,
                        "class": "wan6",
                        "assigned": {

                        }
                }
        ],
la "class" correspond a "ip6class" dans uci et "IPv6 prefix filter" dans luci.  Ca permet coté downstream de choisir ou pas cet upstream. Dans openwrt c'est le nom de l'interface donc. (cas ou on a plusieurs wan par exemple et qu'on veut controler qui delegue vers ou).

Une delegation s'applique localement sur une interface avec "ipassign".

En server de delegation odhcpd n'a pas beaucoup de configuration et documentation. il lit les infos via ubus mais ce sait pas donner un /64 depuis un /64 (je ne sais meme pas si la norme autorise cela d'ailleurs)

odhcpd a un attribut d'interface non documenté c'est "pd_manager" qui permet de préciser un socket (local ou réseau) vers un autre programme qui va fournit les prefixes a déléguer. Mais je n'ai rien trouver en ligne ou dans les packages openwrt qui correspondrait.
Il serait a priori pas trop compliquer d'écrire un programme compatible avec ce truc...

mais il y aussi les autres packages dhcp server dans openwrt, notamment isc et kia. ce sont un peu les "standards" dans le monde Linux donc ca vaut peut-etre le coup de tenter avec eux plutot que d'utiliser odhcpd. j'ai souvent utiliser isc mais pas dans ce contexte. jamais kia encore.

on peut aussi ouvrir un ticket https://github.com/openwrt/odhcpd/issues (ou voir si y'a deja une demande identique).

@kgersen :

Je croyais que l'idée était de fabriquer un préfixe pour parvenir à le déléguer. Combiner, par exemple, quatre /64 pour former un /62.

Si on lui donne un /63 il saura donner 2 /64. C'est une limitation dans le code , le cas n'est pas prévu car en général quand on recoit un /64 c'est pour l'utiliser localement sur un autre interface (en général son LAN) et pas pour la re-déléguer a un autre équipement.

Très étrange !

Exemple avec quatre routeurs R0, R1, R2, R3 :

R0 délègue un préfixe /64 à R1.
R1 délègue à nouveau ce préfixe /64 à R2.
R2 ne délègue pas ce préfixe /64 à R3.

Désolé mais je ne comprend rien a ce que tu essais de dire...

Le serveur DHCP de la Livebox délègue un préfixe /64 à OpenWrt. Le serveur DHCP de OpenWrt devrait potentiellement déléguer ce préfixe /64 à un autre routeur.
Donc, le serveur DHCP de ce routeur pourrait-il déléguer à nouveau ce préfixe /64 à un autre routeur ? Et ainsi de suite...

Il me semble qu'il serait impossible de déléguer un préfixe /64 (non assigné à une interface) à plusieurs routeurs successifs. Je ne comprends pas la logique. Dans le
cas d'un préfixe de longueur inférieure à 64 bits, pour du routage statique, chaque interface se voit assigner un préfixe. Une partie de sa plage d'adresse est réallouée
à un client DHCP (requesting router) associé à une de ses interfaces.

P.S. : Si on ne comprend pas ce que j'essaye de dire, alors j'arrête. De mon côté, c'est inutile de persister à tourner en boucle. Et de votre côté, inutile de me répondre.