Résumé

  • La RFC 1887 ne promettait pas une solution gratuite au multihébergement : elle décrivait quatre manières de déplacer un coût réel entre le site, ses fournisseurs et le reste du système de routage.
  • La RFC 2073 a inscrit des identifiants de registre, de fournisseur et d’abonné dans un format d’adresse; la RFC 2374 a retiré les bits du registre, puis la RFC 3587 a rendu historique la structure TLA/NLA.
  • Cette révision n’a pas supprimé la hiérarchie des préfixes. Elle a reconnu qu’une politique d’allocation doit pouvoir évoluer sans être confondue avec la sémantique permanente d’une adresse.

Une économie réalisée loin du client

La RFC 1887, publiée en décembre 1995, partait d’un problème collectif. Si chaque domaine de routage devait être annoncé séparément, les routeurs éloignés devraient conserver, échanger et recalculer une liste toujours plus longue. L’attribution de blocs contigus permettait à un fournisseur de résumer de nombreux clients par un seul préfixe.

Le bénéfice principal ne se trouvait donc pas chez l’abonné. Il apparaissait dans les équipements de tous ceux qui n’avaient plus à mémoriser ses routes une par une. Les RFC 1518 et 1519 avaient déjà installé cette logique classless pour IPv4. Avec IPv6, l’espace immense ne supprimait pas la contrainte : la ressource rare devenait l’état global de routage.

La RFC 1887 formulait le conflit sans détour : efficacité contre contrôle décentralisé. Pour agréger, l’adresse devait suivre la topologie. Or une entreprise, un pays, un fournisseur et une route physique ne dessinent pas toujours les mêmes frontières. L’administration pouvait être distribuée; la connectivité restait une réalité que le plan d’adressage ne pouvait pas voter.

Quatre solutions, quatre factures

Le multihébergement rendait la contradiction observable. Une organisation pouvait obtenir un préfixe indépendant de ses fournisseurs. Son plan interne demeurait stable et sa destination se résumait en une seule annonce. Mais cette annonce devenait une exception que des opérateurs du monde entier devaient conserver.

Elle pouvait aussi recevoir un préfixe différent à chaque raccordement. L’agrégation de chaque fournisseur restait propre et le trafic pouvait entrer près de sa destination. En revanche, la rupture d’un lien menaçait les adresses issues de ce lien; changer de connectivité obligeait à changer des adresses internes.

La troisième solution choisissait un fournisseur principal et ne diffusait certaines routes plus précises qu’à un ensemble limité. La quatrième imaginait un préfixe commun pour les clients qui partageaient exactement la même paire de fournisseurs. Chaque montage réduisait l’état à un endroit pour ajouter de la coordination ailleurs.

La conclusion de la RFC 1887 mérite d’être lue comme un compte de résultat. Chaque solution imposait un coût « réel », donc financier, aux organisations multihébergées et aux domaines de transit, y compris ceux sans relation commerciale avec elles. Les règles d’acceptation d’un préfixe non local n’étaient pas un détail administratif : elles déterminaient qui supportait cette facture.

Quand l’institution devint un champ

La RFC 2073 donna en janvier 1997 une forme matérielle à cette architecture. Après un préfixe de format de trois bits venaient cinq bits de Registry ID, puis un Provider ID, un Subscriber ID et une partie locale de 64 bits.

IANA y était le registre principal et pouvait déléguer. Le texte attribuait des valeurs à IANA, RIPE NCC, INTERNIC et APNIC. Les registres organisaient les espaces de fournisseurs et d’abonnés; le fournisseur structurait ses abonnés; le site disposait de sa partie interne.

Mais un routeur ne devait pas interpréter ces noms institutionnels. Il appliquait la correspondance au préfixe le plus long. Le texte n’excluait pas d’autres formats et admettait qu’un abonné obtienne un espace indépendant directement auprès d’un registre. Les cinq bits décrivaient une place dans une méthode d’allocation, pas un titre de propriété ni la preuve d’un chemin actif.

En juillet 1998, la RFC 2374 remplaça ce format. Elle supprima les bits de registre parce qu’ils n’étaient pas nécessaires à l’agrégation. À leur place, elle proposa les niveaux TLA, NLA et SLA, distingua topologie publique, topologie du site et identifiant d’interface, et ajouta l’agrégation par point d’échange.

Un site raccordé à un échange pouvait, en principe, changer de transporteur longue distance sans renumérotation et utiliser plusieurs transporteurs sans recevoir un préfixe de chacun. Mais le document excluait les mécanismes de sélection et de portabilité. Une possibilité dans le dessin ne constituait donc pas encore une procédure exécutable.

La politique remplaça la géométrie fixe

La RFC 3587 franchit une autre étape en août 2003. Elle rendit historique la RFC 2374 et sa structure TLA/NLA. Le texte expliquait qu’une politique coordonnée des RIR l’avait remplacée, que cette géométrie n’était peut-être pas la meilleure au stade atteint par le déploiement et que la politique évoluerait probablement.

La forme restante était générale : préfixe global de routage, identifiant de sous-réseau, identifiant d’interface. Le préfixe pouvait toujours être organisé hiérarchiquement par les RIR et les fournisseurs; le site structurait son sous-réseau. L’objectif opérationnel subsistait, mais la norme ne consacrait plus chaque niveau administratif dans un champ nommé.

Ce déplacement est subtil. Confier l’allocation à une politique ne rend pas le pouvoir inexistant. Il le rend visible comme politique, donc datable, contestable et révisable. Une institution ne reçoit pas une autorité éternelle parce qu’une ancienne figure l’a placée entre deux barres verticales.

Renuméroter sans jour J ne veut pas dire sans coût

La RFC 4192 a montré comment maintenir simultanément ancien et nouveau préfixes pour déplacer DNS, configurations et trafic avant la rupture. C’est une vraie capacité de continuité. Ce n’est pas l’effacement du travail.

La RFC 4984 a relevé plus tard que les adresses vivent aussi dans des listes de contrôle d’accès, des applications et des outils de supervision. Pour certains sites, ces dépendances rendaient la renumérotation pratiquement impossible. Le préfixe indépendant évitait ce verrouillage mais ajoutait une route globale; le préfixe fourni s’agrégeait, mais pouvait se désagréger lorsqu’il était annoncé par un autre opérateur.

Le rapport nommait le conflit structurel : l’adresse sert à la fois de localisateur, qui devrait suivre la topologie, et d’identifiant, que l’organisation voudrait stable. Cette surcharge explique pourquoi aucune nomenclature de champs n’a pu solder la question.

Même la recommandation générale d’un /48 de la RFC 3177 fut revue. La RFC 6177 écarta en 2011 le modèle unique et avertit que quelques frontières fixes risquaient d’être codées comme de nouvelles classes. Elle conserva le droit pratique à un espace suffisant, mais rendit la taille exacte au jugement opérationnel.

Ce que la trace permet d’affirmer

Le préfixe indique une destination dans une décision de routage. Le registre documente une allocation. L’annonce BGP montre un origine observée depuis un point de vue. Le contrat désigne une relation commerciale. Le journal applicatif rapporte un résultat. Aucun de ces éléments ne remplace les autres.

L’histoire de 1995 à 2003 ne démontre ni que l’agrégation a échoué, ni que les institutions d’allocation sont superflues. Elle montre mieux : la contrainte technique peut durer tandis que son découpage institutionnel change. Pour conserver cette liberté, il faut enregistrer séparément préfixe, source d’allocation, origine annoncée, politique d’acceptation, fournisseur contractuel, dépendances de renumérotation et résultat observé.

Une route peut être résumée. Une chaîne d’autorité ne doit pas l’être.

Sources