Résumé

  • La RFC 5492 place une liste de capacités optionnelles dans le message OPEN. Une capacité ne peut être employée sur la session que si les deux pairs l'ont annoncée. Une capacité reçue mais inconnue doit être ignorée; une capacité nécessaire au but local de la session, mais absente chez le pair, peut justifier une fermeture motivée.
  • Le dossier public de John Scudder relie ce mécanisme à la RFC 8810, qui répare un espace de codes privés devenu source de collisions, puis à la RFC 9072, coécrite avec Enke Chen, qui agrandit l'enveloppe de 255 octets des paramètres OPEN sans inventer une compatibilité là où l'ancien parseur ne peut plus suivre.

La poignée de main n'était pas encore un accord

Avant la première route, BGP échange des messages OPEN. Deux machines peuvent avoir franchi toutes les étapes inférieures — lien, IP, TCP — puis découvrir à cet instant qu'elles ne disposent pas du même langage optionnel. La difficulté n'est pas exceptionnelle: un protocole vivant doit pouvoir ajouter des fonctions sans exiger que tous les voisins du monde soient mis à jour le même soir.

Le comportement de base rappelé par la RFC 5492 était rigoureux mais coûteux. Un paramètre optionnel inconnu dans OPEN entraînait la fin du peering. L'ambiguïté était évitée, mais une seule nouveauté pouvait emporter avec elle les échanges ordinaires que les deux routeurs savaient encore assurer.

L'annonce de capacités réduit la portée du désaccord. Le message OPEN peut contenir un paramètre Capabilities; celui-ci énumère des extensions. Un pair qui comprend ce contenant n'est pas obligé de comprendre chaque élément. Il peut laisser inerte ce qui lui est inconnu et préserver le socle commun.

John Scudder et Ravi Chandra sont les auteurs de la RFC 5492. Scudder signe ensuite la RFC 8810, consacrée aux règles d'enregistrement des Capability Codes, et partage avec Enke Chen la RFC 9072, qui étend la longueur des paramètres optionnels d'OPEN. Son profil IETF Datatracker confirme cette trace publique et fournit le portrait de référence.

L'attribution reste bornée. Ces documents sont des productions collectives de l'IETF, examinées par un groupe de travail et mises en œuvre par des acteurs indépendants. Un nom d'auteur établit une participation documentée; il ne confère ni propriété de BGP, ni contrôle d'un produit, ni responsabilité automatique pour le résultat d'un réseau.

Un contenant commun qui ne gouverne pas son contenu

Chaque capacité est décrite par un triplet. Capability Code, sur un octet, identifie la fonction. Capability Length, également sur un octet dans cette structure, borne la valeur. Capability Value porte les données dont le sens appartient au document qui définit ce code.

La couche commune est volontairement mince. Elle rend les objets séparables et interprétables, sans prétendre prévoir toutes les extensions futures. Si une capacité permet plusieurs valeurs sous un même code, sa propre spécification doit en fixer le traitement. Des implémentations indépendantes peuvent ainsi lire l'enveloppe avant de savoir agir sur chaque contenu.

Cette construction empêche aussi de confondre syntaxe et vérité. Un code enregistré indique quelle spécification consulter; il n'authentifie pas le pair. Une longueur correcte protège le découpage du message; elle ne prouve pas que l'implémentation du contenu est juste. Une valeur décodable n'indique pas encore que l'opérateur souhaite l'utiliser avec ce voisin.

La RFC recommande de regrouper les TLV de capacité dans un seul paramètre Capabilities. Elle oblige cependant le récepteur à accepter plusieurs paramètres de ce type pour préserver les anciennes formes d'encodage. Les doublons identiques n'ajoutent aucun sens, mais ne doivent pas casser le parseur. Le contrat public porte sur la signification de l'ensemble accepté, non sur l'unique forme émise par un constructeur.

La fonction n'existe pour la session qu'après deux annonces

La règle décisive est simple: une capacité peut être utilisée sur un peering si elle a été annoncée par les deux pairs. Si l'un ne l'a pas annoncée, elle ne peut pas être employée.

Cette exigence vaut davantage qu'une fiche produit. Un logiciel peut contenir le code d'une fonction et ne pas l'activer pour ce voisin. Le choix peut dépendre de la configuration, de la famille d'adresses, du rôle de la session ou d'une contrainte de déploiement. Le message OPEN renseigne ce que ce routeur en exécution a effectivement déclaré à cet autre routeur à cet instant.

La règle limite aussi l'action unilatérale. L'annonce d'un côté n'est pas une autorisation implicite donnée à l'autre. L'attribution d'un numéro par IANA n'active rien. La spécification définit une sémantique, l'implémentation offre une possibilité, l'opérateur décide de l'exposer; l'usage sur cette relation nécessite encore les deux déclarations.

Il faut néanmoins conserver les valeurs et les directions. Certaines capacités définissent un comportement asymétrique ou lié à un rôle. Un tableau de bord qui fusionne tout sous supporté détruit précisément la provenance bilatérale créée par OPEN.

Ignorer une nouveauté, refuser une absence

La RFC 5492 impose d'ignorer une capacité reçue que l'on ne connaît pas ou que l'on ne prend pas en charge. Il est interdit de produire Unsupported Capability ou de fermer la session pour ce seul motif.

C'est le prix raisonnable de l'évolution progressive. L'ancien logiciel ne simule pas une compréhension, mais la nouveauté n'acquiert pas non plus le pouvoir de faire tomber le socle partagé. La capacité inconnue reste sans effet local.

La situation inverse répond à une autre question. Le routeur local peut avoir besoin d'une capacité précise pour accomplir l'objet du peering. Si le pair ne l'a pas annoncée, le routeur peut envoyer une NOTIFICATION Unsupported Capability et terminer la relation. Le message doit nommer la ou les capacités dont l'absence fonde la décision.

Le caractère indispensable est un choix local. Une session destinée à une famille d'adresses particulière peut être sans objet si l'extension correspondante manque. Après une fermeture de ce type, la RFC déconseille une reconnexion automatique: réexécuter sans cesse la même négociation ne change ni le logiciel, ni la configuration, ni le besoin.

Il faut donc lire deux cas qui semblent voisins mais conduisent à des actions opposées. «Le pair annonce quelque chose que je ne comprends pas» doit préserver la session de base. «Le pair n'annonce pas ce dont mon service dépend» peut l'arrêter. Une alerte générique de mismatch efface cette distinction et rend les automatismes dangereux.

Le repli vers l'ancien BGP ne restaure pas forcément le service

Un pair plus ancien encore peut rejeter le paramètre Capabilities lui-même par Unsupported Optional Parameter. La RFC 5492 recommande alors de tenter une nouvelle connexion sans ce paramètre.

Ce repli protège un terrain commun avec les anciennes implémentations. Il ne certifie pas que la mission initiale est remplie. Une session IPv4 élémentaire peut suffire dans un cas; dans un autre, l'absence d'une famille ou d'une fonction rend l'état Established trompeur.

L'exploitation doit donc enregistrer les deux tentatives: le premier OPEN et son refus, le second sans capacités, les fonctions perdues et les routes réellement échangées. Si le suivi ne conserve que le dernier état, une dégradation devient une guérison fictive.

La compatibilité descendante n'est pas l'obligation d'abaisser toute nouvelle relation au plus petit dénominateur. Elle permet de continuer quand le sous-ensemble commun est suffisant et de s'arrêter proprement quand il ne l'est pas.

Un numéro privé cesse de l'être à l'interconnexion

La première organisation de la RFC 5492 réservait les codes 128 à 255 à l'usage privé. La RFC 8810 rapporte qu'avec l'expérience, cette zone s'est révélée inutile et activement déroutante pour les développeurs.

Deux constructeurs peuvent attribuer le même nombre à deux fonctions différentes dans des laboratoires séparés. Chacun fonctionne jusqu'au jour où les produits se rencontrent. Le code n'emporte pas son contexte privé sur le câble; chaque pair lui donne alors un sens différent. Le mécanisme censé exposer une compatibilité devient la source d'une fausse reconnaissance.

La RFC 8810 réorganise l'espace: 1–63 restent soumis à IETF Review; 64–238 relèvent de First Come First Served; 239–254 sont réservés à Experimental Use; 255 reste réservé. Les codes expérimentaux sont destinés au développement initial, pas à un usage durable ni aux produits livrés.

Le registre exerce ici une fonction étroite. Il protège l'unicité du nom et fournit une référence. Il ne décide pas si une capacité doit être déployée, ne mesure pas sa qualité et n'ordonne à aucun opérateur de l'accepter.

La transition garde une limite historique. Une enquête a recherché les usages privés connus avant de peupler plusieurs entrées préstandard. Le texte ne prétend pas avoir tout découvert. Des collisions résiduelles restent possibles et doivent être traitées comme des faits opérationnels, non niées parce que le tableau administratif a changé.

L'enveloppe de négociation a, elle aussi, atteint sa limite

Le champ qui donnait la longueur totale des Optional Parameters d'OPEN ne mesurait qu'un octet. La totalité était donc limitée à 255 octets. À mesure que les capacités se multipliaient, l'endroit prévu pour déclarer l'évolution devenait lui-même trop petit.

La RFC 9072 conserve normalement l'ancien format lorsque le total ne dépasse pas 255. Au-delà, le type 255 sert de marqueur distinctif; un champ de longueur totale sur deux octets suit, et la longueur de chaque Optional Parameter passe elle aussi à deux octets. Une implémentation nouvelle doit accepter cette forme étendue même lorsqu'elle transporte une petite quantité de données.

La compatibilité avec un ancien pair dépend donc du contenu réel. Tant que le nouvel équipement tient dans l'ancienne enveloppe, aucun problème supplémentaire ne se pose. Dès qu'il a besoin de plus de 255 octets, il doit employer la forme étendue. L'ancien pair interprète alors 255 comme un type inconnu et devrait fermer avec Unsupported Optional Parameters.

Cette fermeture est une frontière honnête. Tronquer silencieusement le message laisserait les deux côtés croire à des ensembles de capacités différents. La compatibilité préserve ce que les deux parseurs comprennent; elle ne fabrique pas une compétence dans l'ancien code.

La RFC 9072 précise enfin qu'elle ne modifie pas les problèmes de sécurité ou de confidentialité propres à BGP. Une enveloppe plus grande ne rend pas la déclaration authentique.

La norme minimale doit rester comptable devant le code en service

L'essai ultérieur de Lu Heng, Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption, offre à Sofia Ren une grille de lecture. Le commun tient dans un contenant interprétable, des codes uniques, une condition bilatérale, des erreurs bornées et une longueur extensible. Le sens propre à chaque capacité et la décision de l'exiger restent près des acteurs qui en supportent les conséquences.

Cette grille date de 2026; elle n'est pas une preuve de l'intention privée de Scudder, Chandra, Chen ou de l'IETF. Les trois RFC demeurent les sources normatives.

Running-Code Primacy complète le test. OPEN est une meilleure preuve qu'un catalogue parce qu'il enregistre ce que deux équipements actifs se sont déclaré. Il ne prouve toujours que la déclaration. L'état négocié, les messages acceptés, les routes, la NOTIFICATION, la récupération et le transfert effectif doivent confirmer le résultat.

L'annonce de capacités ne fait pas du registre un souverain du protocole. Elle permet à deux systèmes indépendants de nommer leur terrain commun, de laisser l'inconnu sans effet et de montrer ce qui manque quand la relation ne peut poursuivre son but. La force du mécanisme vient de cette modestie vérifiable.

Sources