Résumé

  • Le préfixe IPv6 site-local FEC0::/10 fournissait des adresses internes sans préfixe global, mais l’adresse ne disait pas à quel site elle appartenait.
  • RFC 4193 a remplacé cette dépendance à la frontière du site par des préfixes locaux dont l’unicité est très probable, tandis que le routage reste local.

Analyse

La seconde moitié de l’adresse était sur l’hôte

Une application mémorisait FEC0::1234:5678:9ABC et tentait une connexion. Sur un hôte multirattaché ou mobile, cette chaîne hexadécimale ne suffisait pas toujours : il fallait aussi préciser le site, avec un identifiant de portée tel que %1. Sur une autre instance de l’hôte, le même site pouvait être %2. L’adresse semblait portable ; la moitié manquante dépendait de l’état local de la machine.

Voilà le marché bancal des adresses unicast site-local d’IPv6. Publié en avril 2003, RFC 3513 définissait FEC0::/10 pour communiquer à l’intérieur d’un site sans préfixe global. Suivaient un identifiant de sous-réseau de 54 bits et un identifiant d’interface de 64 bits. Les routeurs ne devaient pas acheminer ces paquets hors du site. Un réseau pouvait donc utiliser IPv6 en interne sans obtenir d’abord un bloc routé mondialement.

Mais l’adresse ne désignait pas le site qui lui donnait son caractère local. FEC0::1 pouvait exister simultanément sur deux sites. Dans RFC 3879, publié en septembre 2004, les conséquences sont très concrètes : les applications devaient gérer un identifiant supplémentaire ; une adresse littérale ne pouvait pas être mémorisée comme destination indépendante de l’hôte ou apprise simplement par DNS ; et les logiciels qui transmettaient des adresses IP pouvaient exporter cette ambiguïté.

Le mot « site » devait porter trop de sens à la fois. Un réseau d’entreprise, un campus, une zone géographique, un domaine de routage, une zone de pare-feu ou une frontière administrative peuvent dessiner des périmètres différents. RFC 3879 cite notamment la sécurité, la joignabilité, le routage, la qualité de service, l’administration et le financement. Une DMZ pouvait être dedans pour une fonction et dehors pour une autre. Le paquet avait une adresse ; l’organisation, plusieurs cartes.

Les routeurs héritaient du débat. Si une même destination site-local dépendait de l’interface d’arrivée du paquet, un routeur desservant plusieurs sites avait besoin de routes propres à chaque site et d’un traitement particulier des tables de transfert. Les tunnels et la virtualisation des tables pouvaient absorber le travail, mais ils ne transformaient pas « site » en unité universelle.

L’avantage était réel : des adresses internes sans préfixe global et une frontière que les routeurs pouvaient filtrer. En 2003, le groupe de travail IPv6 s’est orienté vers un remplacement. RFC 3879 rapporte un accord en mars et sa confirmation en juillet, tout en précisant que le consensus était loin d’être unanime. Le document de septembre 2004 a déprécié FEC0::/10, mais autorisé les déploiements existants à continuer jusqu’à la normalisation d’un remplacement. Le préfixe ne pouvait pas être réattribué sans future décision de normalisation de l’IETF.

RFC 4193 a fourni ce remplacement en octobre 2005. Les adresses IPv6 locales uniques utilisent FC00::/7 ; pour un préfixe attribué localement, un identifiant global de 40 bits est généré de manière pseudo-aléatoire, puis viennent un identifiant de sous-réseau de 16 bits et un identifiant d’interface de 64 bits. « Global » désigne ici l’unicité recherchée du préfixe, pas une promesse d’accès à l’Internet. RFC 4193 parle d’une forte probabilité d’unicité, pas d’une certitude. Ces adresses servent aux communications locales, peuvent être routées entre un nombre limité de sites et ne sont pas censées traverser l’Internet mondial.

Ce changement compte lorsque des réseaux se rejoignent. Des préfixes ULA générés séparément ont peu de chances d’entrer en collision ; une fusion ou une interconnexion privée peut donc souvent éviter la renumérotation. Il faut tout de même configurer les routes entre les sites. L’adresse n’a plus à encoder une définition universelle du « site » : le réseau local décide où ses routes et ses filtres la laissent passer.

En février 2006, RFC 4291 a intégré la dépréciation à l’architecture IPv6 : les nouvelles implémentations ne doivent plus appliquer l’ancien comportement spécial à FEC0::/10. La suite des RFC explique ce changement ; elle ne mesure pas combien de systèmes l’utilisent encore. Il faudrait des mesures récentes sur les hôtes, les routeurs ou le trafic.

Sources