> Je me demande si Orange va également remplacer le serveur DHCPv4 de la Livebox et activer un serveur DHCPv6 ou bien maintenir leur configuration SLAAC.

Dans tous les cas, il leur faudra SLAAC.
DHCPv6 sur un LAN, hors de cas d'usages rares (PXE ou autre), c'est vraiment pour répliquer IPv4... à mon sens, ce n'est pas nécessaire sur une box grand public, à moins que cette box ne fasse PD.

La gestion centralisée de son réseau local par DHCP peut présenter un certain attrait.

Oui, dans des cas très spécifiques. Ou si on veut reproduire ce qui est fait en IPv4 (je ne juge pas, c'est juste un autre paradigme).

L'administrateur réseau peut visualiser les stations connectées et définir des politiques d'administration.

Je peux aussi visualiser les stations connectées en dumpant la table NDP du routeur, ce qui me donne l'association <MAC, IP>.
Si on fait du 802.1X (ethernet) ou WPA-entreprise (wifi), on a la correspondance <MAC, identité> de l'utilisateur.

Pour moi, l'attribution d'un FQDN à une station est un indispensable en IPv6.

J'ai des entrées DNS pour certaines machines adressées en SLAAC sans souci. Je mets à jour le préfixe dans mon registrar DNS quand le préfixe change, c'est assez rare pour que je le fasse manuellement... mais je pourrais le scripter s'il le fallait.
Sinon, il y a l'option client dyndns sur la machine comme tu le dis. Tout cela ne requiert pas DHCPv6.

Note que je n'ai rien contre DHCPv6. C'est juste, à mes yeux, une complexité supplémentaire.

@simon :

Cela m'a fait réaliser que je pouvais simplifier ma configuration. Placer la Livebox (pour le tél) et le décodeur TV (DHCP) dans le même sous-réseau pour éviter d'avoir deux sous-réseaux différents.

En outre, il faudrait que je teste RDNSS et DNSSL (RFC 8106) dans une configuration standard. En faisant abstraction des appareils Orange, c'est-à-dire de l'un des sous-réseaux.

Cela devient assez technique car je projette de faire de l'auto-hébergement avec un VLAN DMZ (nom de domaine non qualifié pour les stations + FQDN différent pour mon serveur Web).

En vrai, presque tout les cas d'usage ou "tu dois connaitre l'ip à l'avance" sont hors d'usage SLAAC. Et il y en a plein...

Si les machines sont des Linux, "ip token", ca marche du feu de Dieu.
Pas besoin de scripter quoi que ce soit, network manager peut être configuré pour : https://mindlesstux.com/2023/06/27/ipv6-token/
Je crois que systemd-networkd supporte également quelque chose comme cela, mais pas sûr.

Beaucoup de systèmes embarqués génèrent d'ailleurs leur IPv6 par SLAAC avec la méthode EUI64, donc on se retrouve avec le même host identifier peu importe le préfixe (cas de mon imprimante et de nombreux systèmes freeBSD que j'ai sur l'étagère derrière moi).

C'est sûr que ca ne répond pas à toutes les situations et architectures (notamment si les machines sont Windows ou MacOS), mais si le besoin est de pouvoir connaître l'IP à l'avance pour mettre à jour une zone DNS lorsqu'un préfixe change, on peut bien souvent s'en sortir sans DHCPv6.
Je ne dis pas qu'il faut le faire, mais que ca permet dans de nombreux cas de grandement simplifier le réseau (pas de conf DHCPv6 à maintenir).

Le bonne nouvelle c'est que tu peux faire à la fois SLAAC et DHCPv6 en parallèle.

C'est sûr. On doit même pouvoir se retrouver avec une config DHCPv6 qui n'attribue des IA_NA que pour certains DUID. Au sujet du DUID, attention à Windows 10 qui régénère son DUID lors de ses mises à jour bi annuelles...