Résumé

  • RFC 2042 réservait la valeur 255 au développement de nouveaux types d’attributs BGP. Pour un usage réel sur Internet, l’attribut devait être décrit dans un RFC, recevoir un code unique de l’IANA, puis voir sa documentation et son code mis à jour.
  • Le texte refuse expressément de découper l’espace en zones publiques et privées, ou en zones Internet et OSI. Observer 255 ne prouve donc ni extension propriétaire, ni interopérabilité, déploiement, adoption, sécurité, compatibilité ou autorisation.

La différence entre une étiquette d’atelier et une plaque d’immatriculation tient moins à leur forme qu’au registre qui les rend interprétables. RFC 2042 fait de 255 la première, jamais la seconde.

Publié en janvier 1997 comme RFC informatif, ce court mémo appartient aujourd’hui au flux Legacy du RFC Editor. L’IETF Datatracker précise qu’il n’est pas approuvé par l’IETF et n’a pas de statut formel dans son processus de normalisation. Il faut donc le lire comme une pièce historique de coordination, pas comme un mandat moderne extensible à volonté.

Une valeur volontairement non unique

Le problème partait de RFC 1771, alors spécification de BGP-4, qui décrivait le mécanisme des attributs de chemin et les types existants. Comment expérimenter un attribut supplémentaire sans lui attribuer prématurément un numéro public ? RFC 2042 choisit une réponse minimale : pendant le développement, employer l’octet réservé 255.

Ce choix n’identifie pas l’expérience. Deux équipes peuvent donner à 255 des charges utiles, des longueurs et des significations incompatibles. Dans un banc d’essai fermé, une convention préalable suffit à distinguer les deux. Dans une capture isolée, le nombre ne dit pas quelle convention s’applique. Il atteste tout au plus qu’un émetteur a placé cet octet à cet endroit.

La collision potentielle est donc une propriété utile du mécanisme. Elle évite d’encombrer le registre avec chaque prototype et oblige le développeur à ne pas confondre essai local et identité publique. Elle devient dangereuse seulement lorsque 255 franchit une frontière où le contexte commun n’est plus garanti.

RFC 2042 décrit alors le passage nécessaire. L’attribut destiné à Internet doit être documenté dans un RFC et recevoir de l’IANA un type code unique. Après l’attribution, documentation et base de code doivent adopter la valeur autorisée. Le numéro, le texte et l’exécutable sont trois objets liés ; aucun ne prouve à lui seul que les deux autres ont été correctement actualisés.

Ce que le mémo exclut

Une phrase empêche de transformer 255 en territoire propriétaire : les auteurs ne voulaient découper l’espace ni en sections publique et privée, ni en sections Internet, OSI ou autres. Il ne s’agit donc pas d’un numéro d’extension fournisseur. Il n’existe pas davantage, dans ce texte, de droit à conserver 255 durablement entre partenaires commerciaux.

Le registre IANA actuel des BGP Path Attributes conserve cette lecture. La ligne 255 y porte toujours la mention « Reserved for development » et cite RFC 2042. Ce registre ne comporte pas de plage Private Use. D’autres registres de la collection BGP Parameters peuvent avoir des politiques vendor-specific ou private-use ; elles restent attachées à leur registre précis et ne se transfèrent pas aux attributs de chemin.

Cette distinction paraît administrative, mais elle détermine l’interprétation des traces. Dire seulement « 255 dans BGP » efface le nom du registre et peut importer une politique étrangère. Une preuve fiable doit nommer la table, la ligne, la date de consultation et le document qui en contrôle le sens.

Le registre contemporain indique aussi une procédure Standards Action, avec RFC 4271 comme référence. RFC 8126 définit ensuite le vocabulaire moderne de ces politiques. Ce sont des faits actuels, non les mots employés par RFC 2042 en 1997. Une histoire rigoureuse ne remplace pas le mécanisme d’époque par sa gouvernance ultérieure.

L’attribution ne fait pas tourner le protocole

Un code IANA unique résout un conflit d’identité publique. Il ne compile aucun logiciel, ne déploie aucun routeur et ne démontre aucun échange réussi. Un RFC peut décrire le format ; un registre peut attacher ce format à un numéro ; seule une autre chaîne de preuves montre qu’un binaire l’émet, qu’un pair le comprend et qu’un opérateur l’accepte.

Le passage hors de 255 mérite ainsi un journal précis : version de la spécification, enregistrement IANA, commit qui change la constante, jeux de test, version du dissecteur, build livré et observation en production. Si le document passe au nouveau numéro tandis que le code reste sur 255, l’identité annoncée diffère des octets. Si le code change avant les pairs, un attribut valablement assigné peut encore être rejeté.

La pensée de Heng Lu sur la primauté du code en fonctionnement aide à formuler cette limite, sans devenir une exigence de l’IETF. La publication et l’enregistrement relèvent d’une réalité institutionnelle ; le binaire relève d’une réalité exécutable ; le déploiement et le comportement du pair relèvent d’une réalité opérationnelle. Les confondre transforme une décision de coordination en garantie technique.

Une correction éditoriale, pas un changement de règle

Le seul erratum officiel de RFC 2042, l’Errata ID 3681, corrige la référence consacrée à la réflexion de routes BGP : il fallait citer RFC 1966 et non RFC 1998. Classé Editorial et « Held for Document Update », il ne modifie ni la fonction de 255, ni le processus d’attribution, ni le refus d’une partition public/privé.

La faute visible dans le mot anglais « documentation » n’est pas l’objet de cet erratum. Ce détail rappelle une discipline essentielle : rapporter ce que la source de correction vérifie réellement, et non l’erreur qui attire le plus facilement le regard.

La faiblesse utile du marqueur

255 était pratique parce qu’il promettait peu. Il laissait les prototypes évoluer sans distribuer une identité publique à chaque branche abandonnée. Mais cette liberté supposait une limite locale, un schéma connu des participants et une date de retrait.

L’espace commun n’avait besoin que d’une règle déterministe : les identités publiques doivent être documentées et uniques. L’expérimentation, l’implémentation, le calendrier d’adoption et l’autorisation de déploiement restaient des décisions distinctes.

Le registre peut dire quel numéro désigne publiquement quel attribut. Il ne peut pas dire si l’attribut fonctionne. Et 255, volontairement partagé, ne pouvait même pas dire quelle expérience il désignait.

Sources