Je suis très curieux de la production de vos "bonnes" pratiques puisque une autorité (l'IETF), elle, quand elle doit résoudre ce problème de délégation d'un seul et même préfixe à la fois au routeur et au reste de l'environnement du client ne préconise pas l'absence d'adresse de portée globale au routeur mais l'introduction d'une option DHCP pour détacher une sous-partie du préfixe pour pouvoir la fournir au routeur (rfc 6603).
Dans le cadre de Free, le travail est déjà pré-mâché puisque les segments sont déjà individualisés (et qu'on n'utilise pas DHCP pour la délégation).

pas vraiment d'accord la mais on part un peu en hors sujet.

la préco de l'IETF c'est de ne pas utiliser un prefix délegué sur l'interface qui sert au DHCP:

ce que dit la rfc 3633:

   with the following exception: the requesting router MUST
   NOT assign any delegated prefixes or subnets from the delegated
   prefix(es) to the link through which it received the DHCP message
   from the delegating router.

c'est sur le lien qui sert a la réception des messages DHCPv6-PD qu'il ne faut pas utiliser un des prefix.

D'ailleurs la livebox par exemple respecte cette norme: elle n'a pas de GUA coté WAN, elle y recoit un /56 via DHCPv6-PD mais ne configure pas de /64 (de ce /56) sur son WAN car elle respecte cette rfc.

autrement dit: si on veut une GUA sur son WAN il fallait utiliser autre chose que de s'approprier un prefix recu par dhcp-v6 sur son WAN SI aussi on redistribue les prefixes recues comme serveur dhcpv6-pd (le SI est important). Pourquoi ? parce que, entre autres, cela crée 2 routes pour le routeur en amont ce qui dans certaines config (notamment en partage de connexion via un mobile par exemple) pose probleme.

la rfc6603 permet de palier a cette contrainte en permettant d'exclure un /64 qui pourra faire l'objet d'une telle utilisation.
rfc 6603:

The OPTION_PD_EXCLUDE option
   allows prefix delegation where a requesting router is delegated a
   prefix (e.g., /56) and the delegating router uses one prefix (e.g.,
   /64) on the link through which it exchanges DHCPv6 messages with the
   requesting router with a prefix out of the same delegated prefix set.

mais c'est une option quand on veut vraiment faire cette double utilisation particulière d'une délégation. Ce n'est pas a généraliser pour toute les configs dhcpv6-pd.

De toute façon, il ne faut pas avoir une connaissance intime de la mécanique des OS pour réaliser que dissocier adresse (liée à une interface) et l'interface de transit n'est pas l'option de traitement idéale tant en sécurité qu'en performance. Là où ça prend encore de l'ampleur c'est quand on préconise des contortions pour ipv6 quand de toute manière IPv4 sera frontal et que le routeur en question sera déjà, par essence, filtrant (à état qui plus est).

pourquoi ? niveau sécurité c'est mieux de ne pas avoir de GUA coté WAN (le routeur peut avoir une GUA coté LAN ou en loopback interne  pour termination VPN par exemple).

niveau performance / routage je ne vois pas trop ou est le probleme.

Il n'y pas de contorsions, c'est plutôt standard en IPv6.

Je serais curieux d'avoir plus de détails la.
 

pas vraiment d'accord la mais on part un peu en hors sujet.

la préco de l'IETF c'est de ne pas utiliser un prefix délegué sur l'interface qui sert au DHCP:

ce que dit la rfc 3633:
c'est sur le lien qui sert a la réception des messages DHCPv6-PD qu'il ne faut pas utiliser un des prefix.

D'ailleurs la livebox par exemple respecte cette norme: elle n'a pas de GUA coté WAN, elle y recoit un /56 via DHCPv6-PD mais ne configure pas de /64 (de ce /56) sur son WAN car elle respecte cette rfc.

autrement dit: si on veut une GUA sur son WAN il fallait utiliser autre chose que de s'approprier un prefix recu par dhcp-v6 sur son WAN SI aussi on redistribue les prefixes recues comme serveur dhcpv6-pd (le SI est important). Pourquoi ? parce que, entre autres, cela crée 2 routes pour le routeur en amont ce qui dans certaines config (notamment en partage de connexion via un mobile par exemple) pose probleme.

la rfc6603 permet de palier a cette contrainte en permettant d'exclure un /64 qui pourra faire l'objet d'une telle utilisation.
rfc 6603:mais c'est une option quand on veut vraiment faire cette double utilisation particulière d'une délégation. Ce n'est pas a généraliser pour toute les configs dhcpv6-pd.
pourquoi ? niveau sécurité c'est mieux de ne pas avoir de GUA coté WAN (le routeur peut avoir une GUA coté LAN ou en loopback interne  pour termination VPN par exemple).

J'entends bien ce que vous dites mais je n'en comprends pas la finalité par rapport aux points précédents:
- L'affirmation que l'absence de GUA sur patte WAN relève des "meilleures pratiques"
- Le fait qu'un utilisateur du fil (avec Orange) ne dispose pas d'une telle adresse en uplink ne justifie pas la pratique, que c'est la contrainte ou les caractéristiques de déploiement de son opérateur qui le place dans cette position et que, dans sa situation, si l'opérateur suivait la rfc 6603, il serait dans un cas proche de celui présentement chez Free avec une sous partie du préfixe délégué utilisable sur l'uplink.
Il n'y a pas de logique à faire valoir un point de rfc antérieure n'indiquant pas que la patte WAN ne doit pas recevoir d'adresse globale (d'un autre prefixe ou du même préfixe puisque justement mise à jour par une autre rfc depuis 10 ans quand même)
Nonobstant le fait que la délégation de préfixe au travers de la box Orange n'est pas vraiment un exemple en l'état actuel, les dispositions particulières d'un opérateur ne font pas loi pour les autres. C'est précisément un des cas d'espèce ici.
Pour éviter de rendre l'avis personnel, je vais simplement me retirer de l'équation en tant que noname random du forum. Le RIPE non seulement recommande l'affectation d'adresse globale sur l'uplink mais indique également que c'est le cas le plus fréquemment déployé. Précisément dans ses "bonnes pratiques". Alors ils ont peut-être tort, peut-être même que tout le monde ne pense pas pareil au sein du RIPE, ce n'est d'ailleurs pas un diktat, peut-être que tous ceux en Europe déployant ainsi (avec un autre préfixe dédié ou issu du même préfixe), majoritaires, n'ont pas la meilleure approche mais pour l'évaluer ou le savoir il faudrait avoir accès à un argumentaire étayant l'affirmation contraire stipulée plus avant dans ce fil. Or ce n'est pas le cas.

oui personne n'a dit ca.

si l'opérateur suivait la rfc 6603, il serait dans un cas proche de celui présentement chez Free avec une sous partie du préfixe délégué utilisable sur l'uplink

Free ne faisant pas de DHCPv6-PD la comparaison ne sert a pas a grand chose. D'autant qu'on compare une situation différente: dans le cas d'Orange qu'on mentionne on remplace la livebox , dans le cas présent on garde la freebox.
Si on cherche a remplacer la Freebox on ne sait toujours pas (a ma connaissance) comment faire pour le moment et si ou non y'a du DHCPv6-PD entre la freebox et le réseau de Free ?

Pour ce qui est de la rfc6603 je ne sais meme pas quel systeme la supporte dans un cadre "hors mobile". C'est une rfc pondue par des équipementiers mobiles (Nokia,Ericsson,Cisco) pour un usage avant tout mobile. Je ne sais pas si les implémentations classiques, non spécifiquement mobile, de DHCPv6-PD supportent cette rfc.

Le RIPE non seulement recommande l'affectation d'adresse globale sur l'uplink mais indique également que c'est le cas le plus fréquemment déployé.

source ?
Le RIPE a peut être une reco pour des cas 'entreprises' ou d'opérateurs Internet ?

je ne pense qu'il faille avoir avec un 'dogme' ou une "bonne pratique" trop générale. Dans plein de cas simples (particulier, soho, petite site remote, etc) il n'a y quasi pas d'utilité à avoir une GUA sur le WAN. Ca marche sans donc les gens font sans. Pourquoi ajouter de la complexité ou y'en a pas besoin ?

En général, la simplicité dicte les bonnes pratiques.

Probablement https://www.ripe.net/publications/docs/ripe-690

In order to facilitate troubleshooting and have a future proof network, you should consider numbering the WAN links using GUAs, using a /64 prefix out of a dedicated pool of IPv6 prefixes. If you decide to use /127 for each point-to-point link, it is advisable to allocate a /64 for each link and just use one /127 out of it.

4.1. Numbering the WAN link (interconnection between the network and the end-user CPE)

4.1.1. /64 prefix from a dedicated pool of IPv6 prefixes

Using a /64 prefix from a dedicated pool of IPv6 prefixes is the most common scenario and currently the best practice. A separate block of IPv6 space is allocated for the WAN links to the end customer CPEs, so that when CPE connects to the network and performs router discovery, a /64 prefix is used to number both ends of the connection.