Résumé

  • La RFC 8654 porte de 4 096 à 65 535 octets la taille maximale des messages BGP autres que OPEN et KEEPALIVE, mais un message étendu ne peut être envoyé qu’à un pair ayant annoncé la capacité 6.
  • Cette capacité constitue un engagement de réception sur une session, pas une autorisation globale : un déploiement mixte peut imposer l’abandon d’attributs, la rétention d’une UPDATE ou le retrait d’une route.

Une enveloppe plus grande commence par une promesse bilatérale

La RFC 4271 fixe une base nette : un message BGP n’est traité qu’après réception complète et sa taille maximale est de 4 096 octets. La RFC 8654 relève ce plafond pour les messages autres que OPEN et KEEPALIVE, afin que de nouvelles familles d’adresses et fonctions puissent transporter davantage d’information.

Le chiffre ne gouverne pourtant pas le mécanisme. La négociation le fait. Un équipement capable de recevoir des messages étendus SHOULD annoncer la capacité correspondante au moyen de la RFC 5492. L’IANA l’enregistre sous le code 6. Un émetteur MAY envoyer un message étendu seulement s’il a reçu cette capacité du pair concerné.

L’annonce engage donc réellement l’implémentation : celle-ci MUST pouvoir recevoir jusqu’à 65 535 octets. Inversement, un équipement techniquement capable mais configuré pour ne pas annoncer la capacité MUST NOT accepter un message étendu. La capacité logicielle ne remplace pas la décision explicite de la session.

La RFC 8654 ajoute une limite distincte à l’émission : un message NOTIFICATION envoyé à un pair qui n’a pas annoncé la capacité MUST NOT dépasser 4 096 octets.

La capacité d’un lien ne se propage pas au suivant

Une UPDATE supérieure à 4 096 octets peut entrer par un pair compatible puis devoir sortir vers un voisin qui n’a rien annoncé. La première session autorise la réception ; elle n’accorde aucun droit sur la seconde.

La RFC 8654 indique que l’intermédiaire SHOULD tenter de réduire le message en retirant uniquement les attributs admissibles au traitement « attribute discard » de la RFC 7606. Ces attributs ne doivent pas influencer la sélection ou l’installation de la route. Si le message reste trop grand, il ne peut pas être envoyé. Si le NLRI avait déjà été annoncé à ce voisin, il doit être retiré du service.

Le bénéficiaire est l’application qui peut transporter un ensemble d’attributs ou de NLRI plus volumineux. Le coût peut tomber sur le pair suivant et sur les utilisateurs d’une route qui ne franchit plus la limite de 4 096 octets. La taille devient ainsi une décision de propagation et parfois de joignabilité.

La cohérence interne devient une décision de déploiement

Dans un système autonome, la RFC 8654 ne garantit une vue cohérente que si tous les locuteurs iBGP annoncent la capacité. Sinon, l’opérateur devrait se demander s’il convient de l’annoncer aux pairs externes.

La séquence responsable consiste à inventorier les capacités par session, tester la réception et l’analyse des messages maximaux, mesurer la marge mémoire, repérer les frontières internes et externes, puis surveiller les routes abandonnées et les attributs retirés. Ce n’est qu’ensuite que l’exposition externe peut être décidée.

La RFC 8654 ne résout pas les problèmes de sécurité fondamentaux de BGP. Des tampons plus grands augmentent potentiellement l’exposition à l’épuisement des ressources, volontaire ou accidentel. La capacité ne prouve ni la légitimité d’une route ni l’innocuité du contenu ; elle atteste seulement une capacité de réception déclarée.

Preuves et limites

La RFC 8654 définit la taille, les exceptions, la négociation et le comportement aux frontières. La RFC 4271 fournit la limite initiale. La RFC 5492 définit l’annonce de capacités, la RFC 7606 encadre l’abandon d’attributs et le registre IANA confirme le code 6.

Les sources ne disent pas quels réseaux activent aujourd’hui la fonction, ne chiffrent pas un coût universel en mémoire et ne garantissent pas que l’abandon d’attributs suffit toujours. L’analyse du pouvoir, de l’autorisation, des bénéficiaires, du coût et du contrefactuel est dérivée de ces normes.

Sources