Date de publication du RFC : Février 2017
Auteur(s) du RFC : J. Snijders (NTT)
Chemin des normes
Réalisé dans le cadre du groupe de travail IETF idr
Première rédaction de cet article le 17 février 2017
Ce très court RFC ne fait pas grand'chose : il marque juste comme « à ne pas utiliser » (deprecated) un certain nombre d'attributs BGP.
BGP est le protocole de routage de l'Internet. En permanence, les routeurs s'envoient des annonces de routes, annonces portant certains attributs (RFC 4271, section 5) qui précisent des caractéristiques de la route. La liste de ces attributs figure dans un registre IANA. Les attributs cités dans ce RFC sont marqués comme officiellement abandonnés. Ce n'est pas qu'ils ne servaient pas : au contraire, ils étaient « squattés » en étant annoncés bien qu'ils n'aient jamais fait l'objet d'un enregistrement formel. Mieux valait donc les marquer dans le registre.
Mais pourquoi est-ce que des gens peuvent utiliser des attributs non enregistrés ? Parce qu'il n'y a pas de police de l'Internet (en dépit de raccourcis franchements abusifs, par exemple de certains journalistes qui écrivent que « l'ICANN est le régulateur de l'Internet »). Personne ne peut donner des ordres à tous les routeurs, et les faire appliquer.
Bref, il y a des mises en œuvre de BGP qui fabriquent des
annonces avec des attributs non enregistrés. C'est la vie. Mais
c'est ennuyeux car cela peut entrainer des collisions avec de
nouveaux attributs qui, eux, suivent les règles. C'est ainsi que
l'attribut LARGE_COMMUNITY
du RFC 8092 avait d'abord reçu la valeur numérique 30 avant
qu'on s'aperçoive que cette valeur était squattée par un autre
attribut (merci, Huawei)... Résultat, les routeurs squatteurs, quand ils
recevaient des annonces avec un attribut
LARGE_COMMUNITY
ne lui trouvaient pas la
syntaxe attendue et retiraient donc la route de leur table de
routage (conformément au RFC 7606). LARGE_COMMUNITY
a donc dû
aller chercher un autre numéro (32), et 30 a été ajouté au
registre, pour indiquer « territoire dangereux, squatteurs ici
». Le même traitement a été appliqué aux attributs 31, 129, 241,
242 et 243, qui étaient également squattés.
Le groupe de travail à l'IETF s'est demandé s'il n'aurait pas mieux valu « punir » les squatteurs en allouant délibérement le numéro officiel pour un autre attribut que le leur mais cela aurait davantage gêné les utilisateurs de l'attribut légitime que les squatteurs, qui avaient déjà une base installée.
Version PDF de cette page (mais vous pouvez aussi imprimer depuis votre navigateur, il y a une feuille de style prévue pour cela)
Source XML de cette page (cette page est distribuée sous les termes de la licence GFDL)