Ne pas chercher a répliquer ce qu'on fait en IPv4. IPv6 n'aurait pas du s'appeler IPv6, ce n'est pas une "évolution" d'IPv4 c'est différent.
Il faut bien 'reset ses réflexes' et "penser" IPv6 et pas transposer IPv4.
600+ postes ... si y'a des sous-réseaux il faut distribuer des préfixes avec du DHCPv6-PD entre routeurs de facon a propager automatiquement tout changement du prefix racine fournit par l'opérateur. Mais dans le cadre d'une entreprise on peut aussi
demander un bloc ASSIGNED PI (provider independant) directement pour soi et le faire router par un ou plusieurs opérateurs (ce qui permet de la redondance de routage et/ou du load balancing). Comme ça le bloc est lié a jamais a la société et ne changera pas avec l'opérateur. La demande d'un ASSIGNED PI se fait via son opérateur ou dans certains cas directement avec le RIPE. Cela a surtout un intérêt si on héberge des services accessibles de l'extérieur sans utiliser un cloud public ou un service frontal comme Cloudflare (ou solution maison de reverse proxy).
Ensuite on distribue des sous-préfixes de son bloc via DHCPv6-PD.
Ne pas faire de DHCPv6 statefull pour les postes ou sauf si vraiment on n'a pas le choix.
SLAAC + éventuellement DHCPv6 stateless (mais que si besoin des options non supportées par SLAAC, genre des options Active Directory ou de téléphonie).
SLAAC avec "ip token" pour les VMs/serveurs.
Ne pas hésiter à mettre plusieurs GUA ou ULA sur une même machine (on ne manque pas d'IPv6 meme publiques...).
On peut 'bind' chaque service a une IPv6 dédiée plutôt que bind a toutes les IPs de la machine comme on fait souvent par défaut. Cela permet de lier un service a une adresse et déplacer le service sur une autre machine sans changer l'adresse (plus de délai cache dns , mémorisation).
ULA+GUA permet aussi de faire de la sécurité simple: on ouvrira (bind) un serveur intranet que sur sa LUA par exemple et pas sur sa GUA. Avoir 2 GUA, une que pour un service en écoute l'autre pour sortir sur le Net permet aussi d'avoir plus de sécurité (l'adresse d'écoute est offusquée et peut-être géré sur le firewall différemment de l'autre adresse).
Il faut juste 'repenser' le tout avant et faire attention comment on lance les services sensibles qui écoutent sur des ports.
Utiliser des "reverse proxy" en amont simplifient les choses aussi.
Apres rien n'oblige à faire ULA+GUA, on peut tout faire en GUA et gérer la sécurité au(x) 'border(s)' du réseau (firewall & vpn notamment) ou a niveau applicatif. C'est souvent plus simple et sur. Choisir une stratégie de sécurité avant de faire un plan d'adressage.
Bref cela dépend beaucoup du contexte de chaque entreprise.
De plus en plus de sociétés n'ont quasi plus que des postes & imprimantes sur leur LAN donc pas la peine de faire compliquer (ca peut faire peur d'exposer son serveur Intranet en IPv6 public mais avec une bonne authentification 2FA cela n'est pas moins sécurisé qu'un accès VPN sur un serveur intranet avec IP privée comme on voit trop souvent en ce moment- c'est en fait comparable a GDrive ou OneDrive). Internet au début était comme cela, toutes les machines avaient une IPv4 public. C'est l'invention du NAT qui a introduit de la confusion et ce mélange malsain sécurité/ip privées/NAT/plan d'adressage réseau.
Du coup pour le télétravailleur chez lui ou au bureau c'est pareil au niveau de son poste.Y'a pas de session VPN (et de coûts associés) ou autres. Les locaux physiques ou chez soi c'est pareil vu des ressources serveurs.
Franchement la sécurité au niveau 3 (IP) via des cloisonnement d'adresses privées et/ou des access-list c'est un peu le passé vu l'évolution des architectures et des usages. Prendre cela en compte en passant a IPv6 permet de simplifier son déploiement.
Dernier point: le dual stack n'est pas forcement ce qu'il y a de mieux. Passer a IPv6 en gardant IPv4 n'apporte pas grand chose si ce n'est du travail en double a tout les niveaux. Pas mal de sociétés attendent (certaines se lancent déjà même) de faire de l'"IPv6 pur" avec éventuellement un sous LAN 'IPv4 only' pour les équipements & services non compatibles et une passerelle DNS64+NAT64 pour y accéder.