Le DHCP est utile à ceux qui en ont besoin. Et les besoins varient. SLAAC, c'est bien pour les besoins qu'il vise, DHCP aussi. Ceux qui n'ont pas besoin de DHCP n'ont qu'à pas l'utiliser. De toutes façon, pas défaut, DHCPv6 n'est probablement jamais activé sur les routeurs, donc pour moi ce n'est pas un problème. Si Google avait implémenté le DHCPv6, ça n'aurait rien enlevé à ceux qui n'en veulent pas. Que Google ne l'implémente pas enlève des possibilités à ceux qui en veulent.

"Pour moi, le DHCPv6 est utile à ceux pour qui c'est confortable de croire qu'ils vont pouvoir faire comme en IPv4, sans évoluer."

L'étiquetage sur la volonté 'd'évoluer' évacue un peu vite les réalités de l'ingénierie système au profit d'un jugement de valeur. En plus, s'il s'agit d'un jugement de valeur, chacun fait bien comme il veut. Et puis, peut être que quelqu'un qui "ne veut pas évoluer" va juste se contenter de ne rien toucher, et laisser SLAAC (comportement par défaut des routeurs en V6 apparemment).

"SLAAC a été pensé pour couvrir 100% des besoins"

Je suis pas vraiment d'accord :
- Dans le cas où on veut se connecter à une machine locale en ipv6, il est difficile de le faire en ciblant une ipv6 générée via SLAAC, car en SLAAC privacy le suffixe change régulièrement pour "préserver" la vie privée lors de la navigation avec une efficacité assez théorique. Et en plus de ça, le préfixe WAN peut éventuellement lui aussi changer en fonction des rotations de préfixe du FAI (sans parler du multi-wan). Il faut donc soit générer un DNS dynamique si on veut pouvoir identifier une machine du réseau local, soit utiliser mDNS avec l'éventuelle surface d'attaque supplémentaire que cela peut apporter. Il est difficile de mettre à jour un DNS local avec une IP dynamique en SLAAC privacy même si c'est possible. Après on peut imaginer des solutions ToutEnUn (SLAAC+ dns dynamique) dans un routeur, mais même avec un DNS dynamique, soit on met un TTL court (beaucoup de requêtes), soit le DNS peut être invalide de temps en temps. Il y a aussi SLAAC standard (EUI-64), basée aussi sur le préfixe WAN, qui a un suffixe stable basé sur l'adresse MAC. On peut donc le calculer, mais c'est pas pratique, et le problème du préfixe changeant n'est pas résolu. De plus, on ne peut pas fixer l'adresse IP à distance si on a envie de changer l'architecture des réseaux. C'est cette IP là, et pas une autre, d'autant que l'adresse MAC peut être une donnée confidentielle en tant que telle, et donc, elle ne devrait pas forcément se retrouver dans l'IP elle même, IP pouvant être visible sur internet donc.
- Si le WAN tombe, en mode strict, le RA (Routeur Advertisement) n'annonce plus de préfixe aux clients locaux, ou annonce un préfixe local ULA fd00::/8, mais là encore, tout ça fait que c'est pas facile d'atteindre une machine locale avec une ipv6 changeante. Donc, s'il faut faire tourner des services en local uniquement en V6, ça ne me semble pas bien simple pour rendre la chose robuste.

En résumé, pour avoir une IP fixe en SLAAC, il faut soit désactiver les extensions de confidentialité (ce qui pose un problème de vie privée), soit configurer manuellement l'interface de chaque appareil (impossible à grande échelle) ou utiliser des scripts complexes. DHCPv6 (avec réservation d'adresse basée sur l'identifiant DUID ou MAC) reste la méthode la plus simple pour la gestion centralisée des adresses fixes, même en IPv6.

En DHCPv6, avec un NPTv6, on peut totalement décorréler le réseau local du réseau publique. Ainsi on a une adresse ULA (fd00::/8) en locale stable et qu'on a défini soit même (si c'est ce qu'on souhaite), et en sortant du WAN, on peut se contenter de changer le préfixe ULA par un préfixe WAN (c'est totalement transparent). Ca fonctionne avec WAN, et sans WAN, c'est assez modulaire de ce point de vue. Je sais bien que certains argumentent que l'ipv6 n'a pas été conçu pour ça, sauf que c'est pas vrai vu que le NPTv6 existe (donc il a bien été conçu aussi pour ça). Je sais bien que l'argument est dire "c'est pas la philosophie du V6". SLAAC est effectivement plus aligné avec la vision initiale "minimaliste" de l'IPv6, mais DHCPv6 répond à des besoins opérationnels concrets (gestion d'entreprise, services hébergés). L'encapsulation est d'ailleurs assez importante et récurrente en informatique. Bien, sûr, il faut manier ça uniquement en fonction des besoins, car le NPTv6 est une couche assez inutile dans la plupart des cas. Mais au moins, le découplage du LAN avec le WAN permet d'avoir des ipv6 stables en préfixe comme en suffixe, lorsque cela est nécessaire pour certains VLAN regroupant certains services qu'on pourrait vouloir faire tourner avec WAN, en îlot en permanence, lors d'une panne WAN, ou lors d'une attaques extérieure. Et ça gère très bien le muli-wan, aucun soucis de ce côté.

"si le serveur DHCP tombe, plus de réseau fonctionnel"

si on part du principe que le serveur DHCPv6 est le routeur lui même, et si on part du principe que le routeur tombe, il n'y a pas non plus d'annonce RA par le routeur, et donc pas de SLAAC non plus. Et si le service DHCPv6 du routeur tombe, on peut aussi partir du principe que le service RA peut tomber aussi. Pour moi, ça n'ajoute pas forcément d'SPOF supplémentaire par rapport à SLAAC, c'est équivalent. De plus, avec un DHCP, on peut faire une carte du réseau, et en cas d'audit de sécurité, c'est plus facile de schématiser les réseaux, et aussi de dire quelle machine a le droit de se connecter à quelle autre machine, sur quel port... Et dans les cas d'usage de service locaux avec et/ou sans WAN, DHCPv6+NPTv6 est plus robuste ici que SLAAC, même si encore une fois, il ne faut pas le généraliser aveuglément. C'est juste qu'il faut penser en terme d'usage et pas en terme de généralités.

SLAAC est une solution d'auto-configuration. DHCPv6 est un outil de gestion. On ne choisit pas l'un parce qu'on est 'moderne', on choisit l'un ou l'autre (ou les deux en mode assisté) selon qu'on veut de l'automatisation totale ou du contrôle granulaire.

"Objectivement, DCHPv6 n'est en rien indispensable."

Je n'ai lu nul part que le DHCPv6 était indispensable. -> homme de paille

Il ne faut pas non plus tout activer. Le "Redirect" n'est pas forcément une bonne idée par exemple.

"icmp redirect est dangereux quelle que soit la version d'ip, mais bon, on ne doit pas en avoir dans un réseau maillé en principe." -> oui, je n'ai jamais dit le contraire, mais comme on parlait d'IPv6, je n'ai pas évoqué IPv4.