Résumé

  • RFC 8654 permet à un récepteur d’annoncer qu’il accepte jusqu’à 65 535 octets, sauf pour OPEN et KEEPALIVE ; l’émetteur ne peut utiliser cette enveloppe qu’après avoir reçu la capacité du voisin.
  • La promesse s’arrête à cette session. Vers un pair resté à 4 096 octets, seuls les attributs étroitement éligibles à attribute discard peuvent disparaître ; sinon l’annonce n’est pas envoyée et une route déjà publiée doit être retirée.
  • Un déploiement sûr rend l’iBGP cohérent avant de créer une dépendance externe, mesure la taille encodée et la pression sur les ressources, puis conserve une représentation compatible avec le retour arrière.

Le premier test paraît parfait. Deux locuteurs affichent la capacité 6, la session reste établie et un UPDATE dépassant 4 096 octets entre dans la RIB. Mais un autre bord du même AS ne peut pas l’annoncer. Son voisin n’a pas déclaré Extended Message et l’ensemble des attributs ne tient pas dans l’enveloppe historique. Le succès local a créé une attente que le chemin ne partage pas.

RFC 4271 encode la longueur dans deux octets, tout en bornant le message valide entre 19 et 4 096 octets. RFC 8654 porte le maximum à 65 535 pour les messages négociés. Elle crée une capacité de longueur nulle, code 6. L’annonce signifie : « je peux recevoir et traiter cette taille ». Ce n’est ni une propriété du produit entier, ni une autorisation transitive.

Le sens compte. Un locuteur peut émettre un message étendu seulement s’il a reçu la capacité de ce pair. Les règles générales de RFC 5492 font d’une capacité un accord de session : si l’un ne l’annonce pas, la session ne peut pas s’en servir. L’opérateur reste libre d’exiger la fonction et de refuser un voisin qui ne la possède pas.

Une implémentation capable mais configurée pour ne pas annoncer la fonction ne doit pas accepter généreusement un grand message. Cette interdiction protège la décision locale. Le voisin ne peut pas parier sur une tolérance cachée.

OPEN et KEEPALIVE restent hors du mécanisme. OPEN porte justement les capacités avant qu’elles soient convenues ; KEEPALIVE demeure un message fixe de 19 octets. RFC 9072 traite un autre plafond : le champ d’un octet qui bornait à 255 octets les paramètres optionnels d’OPEN. Son format étendu utilise le type 255 et une longueur sur deux octets. Il n’autorise pas les UPDATE de 65 535 octets.

Cette distinction évite un faux positif fréquent. Une trace peut montrer un OPEN riche, encodé selon RFC 9072, alors que la capacité 6 n’est pas active. Inversement, un OPEN ordinaire peut parfaitement négocier RFC 8654. Les deux preuves doivent rester séparées.

Le plafond n’est pas une cible

65 535 octets constituent une borne de réception, non une taille recommandée. Chaque application qui injecte des données dans BGP doit respecter le plafond applicable et l’opérateur peut fixer un budget inférieur.

Plusieurs fonctions consomment ce budget. RFC 4271 permet d’empaqueter plusieurs préfixes partageant les mêmes attributs. ADD-PATH ajoute quatre octets de Path Identifier par NLRI. Chaque Large Community transporte douze octets de sémantique opérateur, auxquels s’ajoute l’encadrement de l’attribut. VPN, ingénierie de trafic et autres extensions enrichissent encore la représentation.

Ces données ne sont pas du remplissage. Une communauté peut piloter un export, un identifiant ADD-PATH distingue des candidats et un attribut optionnel peut servir à un consommateur aval. Supprimer pour gagner des octets exige une analyse de sens.

Le découpage a une limite. Lorsque les attributs sont petits, un émetteur peut répartir les NLRI sur plusieurs UPDATE. Quand le bloc d’attributs dépasse à lui seul 4 096 octets, diviser les préfixes ne change rien. TCP peut segmenter le flux en paquets, mais ne transforme pas un UPDATE sémantique en plusieurs annonces indépendantes.

Le plus petit voisin conserve un droit de veto

À la frontière historique, RFC 8654 autorise d’abord une réduction très encadrée. L’émetteur peut retirer les seuls attributs auxquels RFC 7606 applique attribute discard. Cette catégorie ne couvre pas un attribut qui affecte, ou pourrait affecter, la sélection ou l’installation. Une policy locale peut d’ailleurs donner du poids à un attribut normalement neutre.

Si l’annonce reste trop grande, elle n’est pas envoyée. Si le NLRI avait déjà été annoncé au pair, il faut le retirer du service. La norme préfère une absence explicite à une route amputée de signification.

La conséquence est opérationnelle. Une route peut sortir par un border et manquer sur un autre. Deux route reflectors peuvent fabriquer des vues externes différentes. Un backup sélectionnable peut devenir impossible à annoncer précisément au moment du failover. Tester uniquement des routes ordinaires ne révèle pas cette dépendance.

RFC 8654 demande donc une vue iBGP cohérente. Si tous les locuteurs internes pertinents n’annoncent pas la capacité, l’AS ne peut pas garantir la même représentation à ses sorties. L’activation externe avant l’uniformité interne crée une topologie invisible de capacité documentaire.

Une enveloppe plus grande élargit le coût du parseur

Annoncer la capacité engage buffers, files d’entrée, temps de parsing, validation des attributs, policy, logs et réplication. Un seul UPDATE bénin ne mesure pas la contrainte. Le scénario sérieux multiplie les messages proches du plafond par le nombre de peers et le travail en attente.

RFC 8654 signale le risque d’épuisement de ressources, accidentel ou intentionnel. Reformater une grande annonce pour plusieurs sorties legacy coûte aussi du CPU. Une session authentifiée ne rend pas ses messages gratuits : un voisin autorisé peut envoyer des données valides et coûteuses.

La documentation FRRouting cite RFC 8654 parmi les RFC implémentées. BIRD 3.3.0 expose des options distinctes pour activer ou exiger Extended Messages, et indique qu’un changement provoque un redémarrage de session. Ces déclarations ouvrent le test ; elles ne prouvent ni la négociation réelle, ni les marges de mémoire, ni la compatibilité de chaque sortie.

Prouver une annonce, pas une case cochée

La preuve doit appartenir à une époque de session. Conserver les capacités locales et reçues, l’identité du pair, le rôle, l’AFI/SAFI et la version en exécution. Pour une route proche du plafond, relever la longueur encodée en entrée, la taille des attributs, le nombre de NLRI et l’encodage de sortie pour chaque voisin matériel.

Le résultat doit distinguer repacking, suppression d’attribut autorisée, non-annonce, retrait, Bad Message Length et rejet de policy. Une vue RIB située derrière l’entrée étendue ne témoigne pas pour la sortie legacy.

Enfin, un UPDATE reçu ne prouve pas le forwarding. Il faut encore vérifier sélection, résolution recursive, FIB ou ASIC et paquets. La primauté du code en exécution place la trace encodée au-dessus de la configuration, puis le transfert observé au-dessus de la seule trace BGP.