Mon blog

Cette norme modifie le protocole BGP (RFC 4271) pour ajouter une nouvelle option, qui est plutôt une méta-option, permettant de décrire des capacités optionnelles d'un pair BGP.

Sans ce système de capacités (Capabilities), deux routeurs BGP peuvent annoncer des options lors de la négociation de la session mais tous ces paramètres bien mal nommés « optionnels » sont obligatoires. Si un seul d'entre eux n'est pas reconnu par le pair, celui-ci doit refuser la session (RFC 4271, section 6.2). Cela rendrait très difficile de déployer de nouvelles options. D'où le paramètre optionnel CAPABILITIES que décrit notre RFC et qui est le seul que les routeurs doivent connaitre. Il permet de décrire des options qui sont réellement facultatives (section 1).

La section 3 explique comment utiliser ce paramètre. En gros, une capacité peut être utilisée si les deux pairs l'ont publiée dans un paramètre CAPABILITIES. Si ce paramètre lui-même n'est pas géré, notre RFC conseille de réessayer sans lui. Naturellement, un routeur BGP est toujours libre de ne pas établir de session s'il manque une capacité qu'il juge indispensable (le RFC cite l'exemple des extensions multiprotocole du RFC 4760, section 8, indispensables pour un routeur IPv6). La section 5 revient sur ce sujet en spécifiant les comportements possibles en cas d'erreur.

Et la section 4 décrit précisement le paramètre CAPABILITIES, qui porte le numéro 2 parmi les paramètres optionnels de BGP. Les capacités sont encodées en TLV par un code (1 pour les extensions multiprotocoles du RFC 4760, ou 65 pour les AS sur quatre octets du RFC 6793), une longueur et une valeur. Les codes sont enregistrés à l'IANA. (Leur procédure d'enregistrement a été modifiée par la suite, dans le RFC 8810.)

Ce RFC remplace son prédécesseur, le RFC 3392. Les changements, décrits dans l'annexe B, sont peu nombreux et consistent surtout en un durcissement de certaines règles, maintenant que tous les routeurs BGP gèrent CAPABILITIES.