Ma question est peut-être naïve. J'essaye de dissocier au mieux la source des dysfonctionnements.

Comment constates tu que la Livebox (re)lance ses clients DHCP après 9min30? Les livebox sont connues pour être lentes à démarrer, mais 9 minutes me semble extreme. Tu as une capture ?

Pour ton souci d'OpenWRT, j'opterai pour un problème de configuration :
Wed Aug 21 13:34:20 2024 daemon.notice netifd: Network device 'eth1' link is up
Wed Aug 21 13:34:20 2024 daemon.notice netifd: 8021q 'eth1.832' link is up
Wed Aug 21 13:34:20 2024 daemon.notice netifd: Interface 'wan6' has link connectivity
Wed Aug 21 13:34:20 2024 daemon.notice netifd: Interface 'wan6' is setting up now
Wed Aug 21 13:34:20 2024 kern.info kernel: [   48.374977] mtk_soc_eth 15100000.ethernet eth1: Link is Up - 2.5Gbps/Full - flow control off
L'interface vient d'être configurée et le lien vient de monter.


Wed Aug 21 13:34:20 2024 daemon.err odhcp6c[3062]: Failed to send RS (Address not available)
Wed Aug 21 13:34:21 2024 daemon.err odhcp6c[3062]: Failed to send SOLICIT message to ff02::1:2 (Address not available)
Wed Aug 21 13:34:22 2024 daemon.err odhcp6c[3062]: Failed to send SOLICIT message to ff02::1:2 (Address not available)
J'ai aussi ces messages et pour moi, si ils n'apparaissent que temporairement après la configuration d'une interface, ils sont sans danger.

Pour envoyer un router sollicitation, odhcp6c a besoin qu'une adresse source link local soit configurée sur l'interface.
Or, pendant les premières secondes suivant le passage en up de l'interface, une telle adresse est bien automatiquement générée par le kernel, mais elle n'est pas tout de suite utilisable : le processus de Duplicate Address Detection vérifie d'abord qu'elle n'existe pas déjà sur le lien. Ce processus prend environ 1-2s, et tant qu'il n'est pas fini, les tentatives d'émission avec cette adresse source échouent avec Address not available.

Une fois le processus terminé, si l'adresse est bien unique sur le lien, les tentatives d'émission n'auront pas d'erreur.

Wed Aug 21 13:34:30 2024 daemon.notice netifd: Interface 'wan6' is now up
Wed Aug 21 13:34:30 2024 user.notice firewall: Reloading firewall due to ifup of wan6 (eth1.832)
Wed Aug 21 13:34:30 2024 daemon.notice netifd: wan6 (3062): Cannot find device "wan6"
Wed Aug 21 13:34:30 2024 daemon.notice netifd: wan6 (3062): Cannot find device "wan6"
Wed Aug 21 13:34:39 2024 daemon.notice netifd: Network device 'lan1' link is down
netifd a un souci avec la configuration de wan6, et potentiellement de lan1 également. N'aurais tu pas confondu ou interverti wan6 et lan1 dans un fichier de configuration ?
Tu peux éventuellement poster /etc/config/network ici, en omettant tes chaines d'authentification DHCP.

package network

config interface 'loopback'
option device 'lo'
option proto 'static'
option ipaddr '127.0.0.1/8'
option ip6addr '::1/128'

config globals 'globals'
option ula_prefix 'fd65:c6ad:93db::/48'

config device
option name 'br-lan'
option type 'bridge'
list ports 'lan1'
list ports 'lan2'
list ports 'lan3'
list ports 'lan4'
list ports 'sfp2'
list ports 'wan'

config interface 'lan'
option device 'br-lan'
option proto 'static'
option ipaddr '192.168.1.1/24'
option ip6assign '60'

config device
option type '8021q'
option ifname 'eth1'
option vid '832'
option name 'eth1.832'
list egress_qos_mapping '6:6'

config interface 'wan'
option device 'eth1.832'
option proto 'dhcp'
option vendorid 'sagem'
option reqopts '1 3 6 15 28 51 58 59 90 119 120 125'
option sendopts '77:2b46535644534c5f6c697665626f782e496e7465726e65742e736f66746174686f6d652e4c697665626f7835 90:0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000'
option clientid '1512372786bc5'
option disabled '1'

config interface 'wan6'
option device 'eth1.832'
option proto 'dhcpv6'
option reqaddress 'none'
option reqprefix 'auto'
option sendopts '11:00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 15:FSVDSL_livebox.Internet.softathome.Livebox5 16:0000040e0005736167656d'
option noclientfqdn '1'
option clientid '00030001512372786bc5'

config device
option name 'eth1'
option macaddr '51:23:72:78:6B:C5'

Je reçois bien les paramètres de configuration DHCPv6. L'interface br-lan reçoit une adresse unicast globale (GUA). Mais pas ma station ni l'interface eth1.832.
Je pense que le problème vient d'ailleurs comme l'a indiqué @simon, l'interface br-lan et lan1.

@simon :

C'est une carte de développement : le Bananapi BPI-R3. Il a deux ports SFP. Une des cages SFP est reliée à une MAC (eth1) et l'autre au commutateur interne (eth0).
Le port wan est un port du commutateur et peut servir soit pour une connexion wan ou alors lan. Mais cela m'étonnerait beaucoup que le problème vienne de là.
Je crois qu'on peut faire abstraction de tout cela à cause de la technologie Distributed Switch Architecture.

C'est vraiment bizarre !

L'autre jour, tout fonctionnait correctement en IPv6 sur ce routeur. Ensuite, j'ai modifié régulièrement la configuration pour réaliser d'autres tests. J'essayais d'intégrer un correctif dans
le client DHCPv4 udhcpc de OpenWrt pour modifier la priorité interne des paquets DHCPv4. Pour être sûr, j'ai également vérifié l'état de la carte SD (cela semble OK).

Ma configuration personnalisée faisait appel à odhcpd et unbound. J'ai recommencé les tests avec dnsmasq et odhcpd-ipv6 sur OpenWrt v23.05.4.

Tu peux executer les commandes suivantes et poster leur resultat ?
ip a
ip -6 r
ip n
ps w

Super.
Côté IPv6, tout semble en ordre :
- odhcp6c est lancé sur eth1.832 et tu obtiens bien un /56 (2001:db8:7d8b:c65b::/56),
- le premier /64 est assigné à br-lan (2001:db8:7d8b:c65b::/64), et le routeur s'assigne 2001:db8:7d8b:c65b::1 sur cette interface,
- le routeur d'Orange est joignable sur eth1.832 (fe80::ba0:bab dev eth1.832 lladdr 1b:c2:52:4e:22:3a),
- odhcpd est lancé, il devrait annoncer 2001:db8:7d8b:c65b::/64 sur br-lan et ses ports associés,
- la résolution NDP marche bien côté LAN, puisque la MAC de ta station est bien dans le cache.

-> à priori, la connectivité IPv6 devrait être OK. Est-ce que des adresses IPv6 se configurent bien sur ta/tes stations ? Tu peux rejouer ip a et ip -6 r sur cette station pour voir (linux), ifconfig -a (macOS) ou encore ipconfig /all (windows).
Tu peux aussi faire des traceroute/tracert/mtr pour regarder ou ca coince, et poster ici le résultat si besoin.

Pour écarter tout souci, je commenterai la section
config globals 'globals'
option ula_prefix 'fd65:c6ad:93db::/48'
du fichier /etc/config/network si tu n'as pas l'utilité d'un préfixe ULA, ou au moins juste le temps de faire tes tests.

Si des adresses IPv6 sont bien configurées sur les stations, tu peux regarder du côté du firewall du routeur éventuellement (il ne faut pas le désactiver, hein :-) mais vérifier que les règles sont cohérentes).

En IPv4, le client DHCPv4 ne tourne pas et tu n'as pas d'adresse IPv4 publique. Tu n'as donc pas de connectivité IPv4.
Vu que tu utilises dnsmasq et qu'Orange n'annonce pas encore de DNS IPv6 par DHCPv6, la résolution DNS ne va pas fonctionner en tant que tel.

En partant du principe que tu n'as pas volontairement désactivé IPv4, je me demande tout de même si l'interface physique 'wan' et la connectivité IPv4 'wan' ne se marchent pas dessus, vu qu'elles ont le même nom.
Peux-tu faire un ifstatus wan et poster le résultat ici?

Ensuite, pourrais-tu tenter de renommer la configuration IPv4 en 'wan4'? i.e.
config interface 'wan'
option device 'eth1.832'
devient
config interface 'wan4'
option device 'eth1.832'

attention: l'interface physique wan ne change pas.

Il faudra potentiellement ajuster des règles de firewall suite à ce changement, même si je pense que luci fait bien les choses.