Résumé

  • Dans la RFC 4193, un identifiant global pseudo-aléatoire de 40 bits rend deux préfixes ULA créés séparément très probablement distincts ; il ne les attribue pas et ne les certifie pas.
  • « Global » qualifie l’ambition d’unicité, pas l’accessibilité sur Internet. Le routage d’une ULA doit rester local ou résulter d’un accord intersite explicite.
  • Lors d’une fusion ou d’un VPN, il faut donc confronter les préfixes réels, borner routes et DNS, dissocier la sécurité de l’adressage et prévoir le renumérotage.

Dans un dossier de fusion, une adresse commençant par fd peut donner une impression de dossier clos. Les deux entreprises utilisent des préfixes différents ; le risque de chevauchement paraît écarté ; le tunnel peut être ouvert.

Ce raisonnement saute précisément l’étape que le mécanisme permet de rendre peu coûteuse : vérifier.

Publiée en octobre 2005, la RFC 4193 est une norme proposée signée Robert Hinden et Brian Haberman. Elle définit les adresses IPv6 locales uniques, ou ULA, dans FC00::/7. Leur structure réunit un bit L, un identifiant global de 40 bits, un identifiant de sous-réseau de 16 bits et un identifiant d’interface de 64 bits. La valeur L=1 désigne la génération locale prévue par le texte, d’où l’usage actuel de l’espace FD00::/8.

L’innovation n’est pas de transformer l’adressage interne en service d’attribution mondial. Elle consiste à permettre à chaque site de choisir un identifiant sans consultation préalable, tout en rendant le même choix indépendant extrêmement rare. La RFC interdit les suites séquentielles et les valeurs connues. Elle propose de mêler une indication temporelle à un identifiant propre au système, d’appliquer SHA-1 et de conserver les 40 bits de poids faible.

SHA-1 n’est ici ni une signature ni une serrure. La procédure ne prouve pas l’identité de l’opérateur, ne protège pas le préfixe et ne confère aucun titre de propriété. Elle distribue des choix locaux dans un espace assez vaste pour que la coordination préalable devienne généralement inutile.

Les probabilités publiées fixent la bonne lecture. Pour deux identifiants générés indépendamment, la RFC évalue le risque de collision à environ 1,81 × 10^-12. Avec 10 000 identifiants, l’estimation atteint environ 4,54 × 10^-5. Ce sont des résultats de modèle, pas un relevé des réseaux existants. « Très improbable » reste une catégorie différente de « impossible ».

Le nom du champ entretient une autre confusion. L’identifiant est « global » parce qu’il vise une unicité au-delà d’un seul site administratif. Le mot ne rend pas l’adresse mondialement joignable. Le registre actuel des adresses IPv6 à usage spécial de l’IANA classe fc00::/7 comme utilisable en source et en destination, et comme transférable par un routeur, mais non globalement accessible. Le registre rappelle en outre qu’une inscription ne garantit la routabilité dans aucun contexte particulier.

Une frontière écrite dans les politiques, pas dans l’octet

La RFC 4193 limite normalement la propagation d’une ULA au site ou à des sites reliés par un accord explicite. Les systèmes de routage Internet doivent ignorer FC00::/7 par défaut. Aux frontières, routes et paquets ULA sont filtrés dans les deux sens. Une dérogation intersite devrait nommer les /48 précis, ou des routes plus spécifiques, au lieu d’ouvrir la classe entière.

Une ULA n’est donc pas « privée » par nature physique. Un routeur sait la transporter, un VPN peut l’encapsuler et une redistribution mal réglée peut la diffuser. La portée naît de la configuration et de la topologie. Sans filtre, le premier octet ne forme aucune enceinte.

Le DNS ajoute sa propre limite. La RFC déconseille de publier les enregistrements AAAA et PTR associés dans le DNS mondial, car l’unicité n’est pas absolue. Les requêtes inverses concernant des ULA ne doivent pas gagner l’infrastructure DNS globale. Une fusion doit ainsi inventorier les zones internes, les vues séparées, les redirecteurs et les dépendances de résolution, pas seulement comparer deux fichiers de routes.

Le préfixe ne distribue pas davantage les adresses. Les annonces de routeur, DHCPv6, la configuration manuelle, le plan de sous-réseaux et le nommage restent des décisions séparées. La RFC 5375 souligne qu’une ULA peut cohabiter avec des adresses IPv6 globales. Elle ne recommande pas de recréer la traduction d’adresses d’IPv4.

La sécurité doit rester dans un autre registre. Un service doit encore authentifier, autoriser et journaliser. Un pare-feu doit encore définir un flux. Un opérateur doit encore décider quelle source de route mérite confiance. La RFC 4193 ne présente aucune sécurité intrinsèque de l’ULA. La provenance apparente d’une adresse ne prouve ni l’identité d’un hôte ni son droit d’accès.

Ce que les 40 bits corrigent vraiment

La RFC 3879 permet de mesurer le progrès. Elle a abandonné les anciennes adresses « site-local » parce que le mot site n’avait pas de frontière stable. Une organisation répartie sur plusieurs implantations pouvait interpréter différemment la portée ; les préfixes pouvaient fuir ; les applications choisissaient mal ; deux réseaux réunis ne possédaient aucun signe permettant de distinguer leurs blocs locaux.

L’identifiant généré résout cette dernière difficulté sans imposer un répartiteur universel. Des sites autonomes se numérotent, puis se relient avec une forte présomption que leurs préfixes diffèrent. La RFC 5375 cite l’intérêt lors de fuites ou de fusions : le risque d’un renumérotage immédiat diminue.

Il ne disparaît pas. La RFC 4193 déconseille un routage ULA mondial parce qu’aucune autorité n’en garantit l’unicité et qu’aucune agrégation pratique n’existe. Si la collision survient entre deux réseaux désormais connectés, le trafic peut échouer ou atteindre le mauvais système. Une faible probabilité ne plafonne pas la gravité.

Le rôle de Brian Haberman doit lui aussi rester correctement attribué. Hinden cosigne la RFC et le document remercie une communauté plus large. La page photographique officielle du groupe IPv6 de l’IETF identifie Haberman et rappelle qu’il présidait ce groupe avec Hinden. En août 2026, l’Internet Society le présentait comme président de son conseil, ingénieur distingué chez Fastly, membre de la gouvernance de NetDev et contributeur de longue date à l’IETF. Cette biographie situe son expérience ; la norme fournit les faits techniques.

Construire le reçu qui manque

Pour relier deux réseaux, le bon document n’est pas un faux certificat d’ULA. C’est un dossier de contrôle court et vérifiable.

Il commence par tous les /48 actifs et réservés : production, laboratoires, nuages privés, reprise après sinistre, partenaires VPN et préfixes inscrits en dur dans des applications. Les deux listes doivent être comparées valeur par valeur. La probabilité justifie l’optimisme avant la collecte ; elle ne remplace pas la comparaison une fois les données disponibles.

Le dossier indique ensuite l’origine de chaque préfixe : méthode, date approximative, classe d’identifiant système et équipe responsable. Il n’est pas nécessaire d’exposer une donnée matérielle sensible. Il faut en revanche pouvoir repérer un préfixe copié dans un modèle puis réutilisé par plusieurs filiales, ce qui n’est plus une génération indépendante.

Vient l’admission de routes. Le dossier nomme l’interconnexion, les préfixes permis, les prochains sauts, les filtres d’importation et d’exportation, le responsable de surveillance et l’action de retrait. Un test confirme que le reste de FC00::/7 est refusé et qu’aucune ULA n’est annoncée à un pair Internet.

Le DNS et la sélection d’adresse sont testés séparément. Quelles zones font autorité ? Quelles vues sont internes ? Où partent les requêtes inverses ? Une application préfère-t-elle une ULA injoignable à une adresse globale valide ? Deux Global ID différents n’empêchent ni une collision de noms ni une préférence d’adresse défectueuse.

La sécurité possède enfin ses propres preuves : identité de service, règle de pare-feu, contrôle de source de route, journaux et propriétaire d’incident. La mention ULA n’en tient lieu pour aucune.

La sortie est décidée avant l’ouverture. Une collision impose éventuellement de renuméroter. Une annonce externe inattendue entraîne le retrait. Une fuite DNS isole un chemin de résolution. Une application remplie d’adresses littérales peut retarder la fusion. Le retour arrière n’est pas un aveu d’échec ; c’est la condition qui rend l’essai responsable.

La primauté du code en fonctionnement, défendue par Heng Lu, replace alors la preuve au bon endroit : tables de routage, parcours de paquets, réponses DNS et tests d’applications valent davantage qu’un schéma déclaré. Sa notion de spécification initiale minimale invite à demander juste assez de preuves communes pour préserver les choix locaux et pouvoir les défaire.

Les 40 bits réussissent parce qu’ils laissent les réseaux s’organiser eux-mêmes. Leur réussite ne dispense pas de coordination ; elle permet de réserver cette coordination au moment où une frontière devient réellement partagée.

Sources