Résumé

  • RFC 3359 dressait une carte commune des valeurs TLV d’IS-IS pour éviter les collisions, tout en affirmant que le document n’était ni une norme ni une autorité d’attribution.
  • RFC 3563 a ensuite confié provisoirement le registre à l’IANA avec expertise désignée ; une ligne enregistrée coordonne un nom, mais ne prouve ni logiciel, ni déploiement, ni résultat réseau.

Une collision de protocole peut naître sans négligence. Deux équipes examinent chacune leur propre documentation, trouvent la même valeur apparemment libre et l’emploient pour deux extensions différentes. Le paquet n’est pas illisible : il est trop lisible, mais de deux façons incompatibles.

RFC 3359, publié dans la catégorie Information en août 2002, proposait une mémoire partagée pour cet espace. Le texte de T. Przygienda rassemblait les valeurs TLV de premier niveau alors utilisées ou prévues dans IS-IS. Il indiquait leur présence possible dans les IIH, LSP et SNP, ainsi qu’une origine générale.

Le tableau racontait une histoire institutionnelle composite. ISO 10589 côtoyait les extensions IP de RFC 1195, plusieurs projets IETF, un élément DECnet qualifié d’ancien et des valeurs propriétaires Lucent et Nortel. L’occupation d’un numéro n’avait donc pas un statut normatif uniforme. Le tableau ne transformait pas une pratique propriétaire en norme ; il signalait qu’une autre signification existait déjà sur le fil.

Cette hétérogénéité créait le besoin. Le cœur d’IS-IS appartenait au travail ISO, les extensions Internet au travail IETF, tandis que des implémentations avaient déjà leur propre empreinte. Une seule valeur de huit bits traversait pourtant toutes ces frontières. Chaque communauté pouvait être cohérente en interne et produire ensemble une collision.

Le RFC formule sa limite avec une rare netteté. Il veut éviter de futurs conflits, mais ne constitue ni une norme ni une autorité d’attribution. Les numéros circulaient sur une base informationnelle partagée entre ISO, SIF et les groupes IETF. ISO ne fournissait pas d’autorité de numérotation et la responsabilité de l’IANA était alors décrite comme limitée aux codes liés à IP. Aucune autorité centrale plausible ne se présentait.

La liste agissait donc par visibilité. Un auteur d’extension pouvait constater qu’une case était occupée ou promise et en choisir une autre. Sa force ne venait pas d’une sanction, mais de l’intérêt commun à éviter que deux logiciels attribuent des comportements différents au même octet.

Le document ne prétendait pas être complet. Il ne donnait pas la référence précise de chaque usage et ne réglait pas les sous-TLV. Il prévoyait des versions nouvelles ou le remplacement par un registre officiel. Une ligne empêchait une réutilisation imprudente ; elle ne fournissait pas tout le dossier de provenance.

RFC 3232 venait justement de remplacer la réédition périodique du catalogue général Assigned Numbers par une base en ligne. Une base vivante convenait mieux à un espace évolutif. Pour IS-IS, il fallait encore résoudre la frontière entre les institutions responsables du cœur et des extensions Internet.

RFC 3563 a publié cette réparation en 2003. L’accord entre ISOC/IETF et ISO/IEC JTC1/SC6 séparait les champs de travail, organisait leur coopération et demandait à l’IANA de maintenir provisoirement le registre TLV jusqu’à ce que JTC1 fournisse ce service.

Le mot « provisoirement » interdit de raconter une souveraineté permanente. L’accord envisageait le transfert de l’autorité d’attribution à JTC1, tandis que l’IANA pouvait conserver une copie informationnelle. L’hébergement du registre, la décision d’attribuer et la maintenance de la norme restaient trois fonctions distinctes.

L’état initial devait être synchronisé avec RFC 3359. Le relevé sans autorité n’a pas été effacé ; il est devenu l’évidence de départ du processus formel. Les nouvelles valeurs nécessitaient l’accord d’un expert désigné par l’IESG. L’IETF informait JTC1/SC6, et JTC1/SC6 renvoyait ses demandes vers la procédure IANA.

Ce passage au registre ne certifiait pas les implémentations. Il donnait une entrée commune et maintenue. Un document devait toujours définir la syntaxe. Un logiciel devait l’implémenter. Un opérateur devait l’activer. Deux voisins devaient encore se comprendre.

Le schéma du registre a lui-même évolué. RFC 6233 a ajouté une colonne Purge afin d’indiquer quels TLV pouvaient apparaître dans un LSP purgé. La colonne n’est pas décorative : le contexte PDU participe à la validité. Elle reste toutefois un résumé, tandis que le RFC de définition conserve la règle complète.

RFC 7370 a raffiné la gouvernance en 2014. Il a regroupé des registres de sous-TLV destinés au même espace et encadré l’attribution avant publication d’un RFC. La demande devait normalement venir d’un document adopté par un groupe de travail ou parrainé par un directeur de zone. L’expert vérifiait consensus ou approbation, examinait la valeur technique sans renverser le consensus IETF, puis appliquait expiration et désallocation si le texte n’aboutissait pas.

RFC 7120 fournit la discipline générale des allocations anticipées, tandis que RFC 7370 adapte le chemin aux registres sous Expert Review. RFC 8126 nomme les politiques modernes d’enregistrement. Ces noms décrivent les conditions d’ouverture d’une case ; aucun ne garantit la qualité d’un produit qui l’utilise.

Une procédure trop stricte crée son propre risque. En 2024, RFC 9650 a remplacé Standards Action par Expert Review pour un registre de bits d’attribut de lien. La barrière empêchait les protocoles expérimentaux d’obtenir une valeur et augmentait le risque de codepoint squatting. Si l’entrée légitime devient impossible, l’expérimentation peut se déplacer hors de la carte commune.

La bonne politique rend la coordination plus simple et plus crédible que la réutilisation silencieuse. Trop peu de contrôle gaspille l’espace et crée des ambiguïtés. Trop de contrôle rend le registre aveugle aux essais réels. L’expertise bornée, la référence visible et l’expiration cherchent un équilibre.

La page IANA actuelle est le résultat vivant de cette histoire. Elle contient des registres imbriqués, des colonnes et des politiques absentes du tableau de 2002. La présente recherche en fige une date, sans prétendre que cette forme existait dès RFC 3359 ou qu’elle demeurera immuable.

Enfin, une ligne du registre n’est pas du code en fonctionnement. Elle prouve une association enregistrée entre valeur, nom, référence et politique. Elle ne prouve pas que le parseur reconnaît la valeur, que le contexte PDU est correct, que deux constructeurs interopèrent, que la fonction est activée, qu’une route est installée ou qu’un paquet est livré.

Ces résultats exigent des reçus ultérieurs : documentation de capacité, tests, configuration, capture, journaux, état de base et essai de trafic. Le registre permet de comparer les observations. Il ne les remplace pas.

Deux essais de Lu Heng servent de lentilles éditoriales déclarées. « Minimum Initial Specification » éclaire l’utilité d’une petite table commune avant que sa garde institutionnelle soit réglée. « Reality Layers » sépare numéro, spécification, implémentation, déploiement et résultat. Ils n’ajoutent pas une intention aux auteurs du RFC.

La liste n’avait aucun pouvoir d’attribution. Elle disposait toutefois d’un fait commun publié avant le choix, et ce fait pouvait suffire à empêcher deux mondes privés cohérents de produire un fil public incompatible.

Sources