Résumé

  • La RFC 9072 emploie le type de paramètre optionnel 255 et une longueur sur deux octets pour permettre à un OPEN BGP de dépasser 255 octets de paramètres optionnels.
  • Cette enveloppe plus grande n’accorde aucune capacité générale. Un pair qui ne comprend pas l’extension doit normalement la rejeter ; le franchissement de la limite exige donc une interopérabilité démontrée.

La limite d’origine est collective

Le message OPEN fixe les conditions dans lesquelles deux locuteurs BGP vont tenter d’établir une session. Les capacités y sont transportées dans des paramètres optionnels, mais la RFC 4271 donne à toute cette zone un champ de longueur d’un seul octet. Quel que soit le nombre de capacités annoncées, leur encodage cumulé doit tenir dans 255 octets.

La contrainte reste souvent invisible. Chaque nouvelle capacité est modeste et chaque décision locale paraît indépendante. Pourtant, la somme d’options parfaitement valides peut devenir impossible à représenter dans le format de base, sans qu’aucune option soit fautive.

La RFC 9072 modifie l’enveloppe. Le type 255 signale le format étendu : après les champs placés comme dans l’ancien format vient une longueur étendue sur deux octets, et chaque paramètre porte lui aussi une longueur sur deux octets. L’espace disponible augmente, mais la signification des capacités ne change pas.

Davantage de place ne donne pas davantage d’autorité sur le voisin. L’émetteur peut proposer un ensemble plus riche ; le récepteur conserve le pouvoir de décider quelle syntaxe et quelles capacités il accepte. L’établissement effectif de la session reste la preuve observable que les deux extrémités ont pu lire cette négociation.

Le type 255 ouvre l’enveloppe et révèle l’incompatibilité

Dans le format étendu, l’ancien champ de longueur devrait valoir 255 et ne doit jamais valoir zéro. L’octet suivant, situé à la place d’un type normal, doit lui aussi valoir 255. Il ordonne alors au pair compatible de lire la longueur étendue et la suite de paramètres.

Si l’ensemble ne dépasse pas 255 octets, le format de base devrait rester la norme. Une configuration peut forcer le format étendu à des fins de test, et une implémentation conforme doit l’accepter même lorsque le contenu aurait tenu dans le format court. Au-delà de 255 octets, le format étendu devient obligatoire.

C’est là que se situe le véritable point de contrôle. Sous la limite, l’opérateur conserve une représentation courte pendant qu’il teste le nouveau parseur. Au-dessus, le même ensemble ne possède plus de représentation compatible avec l’ancien format. Le pair accepte l’extension, l’émetteur retire certaines capacités, ou la session échoue.

La rétrocompatibilité est explicitement fermée. Un pair qui ignore la RFC 9072 devrait voir le type 255 comme un paramètre non reconnu et fermer la connexion avec l’erreur Unsupported Optional Parameters. Le même type employé ailleurs doit être traité comme non reconnu. L’incompatibilité devient donc visible au lieu d’être silencieusement réinterprétée.

La croissance des capacités devient un budget commun

Les bénéficiaires sont les réseaux dont l’ensemble légitime de capacités ne tient plus dans l’enveloppe d’origine. Ils peuvent conserver leurs fonctions au lieu d’en supprimer uniquement pour satisfaire un champ trop court. Le coût se déplace toutefois vers la coordination.

Chaque capacité consomme une part d’un budget OPEN partagé jusqu’au passage au format étendu. L’équipe qui ajoute une fonction n’est pas forcément celle qui exploite la relation de peering touchée par le dernier octet. Sans inventaire commun, une modification ordinaire peut imposer soudain l’extension et révéler une implémentation ancienne à l’autre bout.

Forcer le format étendu avant d’atteindre 255 octets permet de tester le parseur sans pression de capacité. Il faut conserver la taille exacte du message, l’encodage choisi, la version du pair, l’erreur éventuelle et toute modification du jeu de capacités lors d’un nouvel essai.

L’extension n’authentifie pas le voisin, ne protège pas l’OPEN, ne valide pas la politique de routage et ne garantit pas le traitement futur des UPDATE. La RFC 9072 ne change pas les propriétés de sécurité et de confidentialité de BGP. Assimiler une grande enveloppe à une préparation globale donnerait au mécanisme un pouvoir qu’il n’a pas.

Preuves et limites

La RFC 9072 définit l’indicateur 255, les longueurs sur deux octets, les règles de choix du format et le comportement attendu d’un ancien pair. La RFC 4271 fournit le modèle OPEN, la RFC 5492 le cadre des capacités, l’IANA l’enregistrement et la RFC 4272 le contexte de sécurité. L’idée d’un budget de compatibilité est une analyse.

Les sources ne prouvent le déploiement d’aucun opérateur ou fournisseur nommé, ne mesurent pas la population de pairs incompatibles et ne donnent aucun nombre universel de capacités avant saturation. Une session réussie prouve le franchissement du parseur, pas la correction de la politique ou des UPDATE ultérieurs.

Sources