Résumé

  • La RFC 8097 définit une communauté étendue non transitive qui transporte l’état Valid, NotFound ou Invalid d’une route au sein d’un système autonome.
  • Cet état renseigne la politique sans l’exécuter : l’échange EBGP est désactivé par défaut, la validation déléguée exige de la confiance et la décision reste locale et explicite.

Trois valeurs transportent un résultat, pas un ordre

La RFC 6811 définit le calcul : Valid signifie qu’au moins une charge ROA validée couvre le préfixe, autorise sa longueur et correspond à l’AS d’origine ; NotFound qu’aucune ne le couvre ; Invalid qu’une charge le couvre sans qu’aucune ne corresponde. La RFC 8097 encode ces états par 0, 1 et 2 dans une communauté opaque non transitive. L’IANA attribue le sous-type 0x00 sous le type 0x43. La norme impose d’envoyer les champs réservés à zéro et de les ignorer à la réception.

Un routeur configuré devrait, selon la recommandation normative, joindre la communauté aux UPDATE destinées aux pairs IBGP. Sans état calculé localement, le destinataire devrait de même le déduire de la communauté présente. Il reçoit un résultat, pas la preuve que le cache est frais, que le chemin complet est valide ou qu’il faut accepter la route.

La RFC 6811 conserve l’autorité locale : sans configuration explicite, il est normativement interdit d’exclure une route d’Adj-RIB-In ou du processus de décision du seul fait de son état. L’étiquette alimente la politique ; elle ne la remplace pas.

La frontière de confiance s’arrête à EBGP par défaut

Par défaut, la RFC 8097 impose de supprimer sans traitement la communauté reçue d’un pair EBGP et recommande de ne pas l’envoyer à EBGP. Une configuration peut autoriser l’échange, notamment entre AS placés sous une même administration, mais il s’agit d’une décision positive de confiance.

Le schéma externalise la validation d’un routeur vers un autre. Les participants doivent donc disposer d’une relation de confiance appropriée et protéger leur transport. La communauté transporte un résultat de validation sans être elle-même authentifiée cryptographiquement ; elle peut être falsifiée, périmée ou attachée par le mauvais équipement. La validation d’origine ne valide pas tout le chemin AS.

Le support mixte impose une traduction de politique

Si certains routeurs internes ne prennent pas en charge la RFC 8097, la norme recommande à l’opérateur de définir une politique qui lit la communauté et positionne un autre attribut BGP influençant la sélection de la même façon. Sans cela, une même route peut avoir des effets différents dans la topologie.

La norme recommande de ne pas envoyer plusieurs instances. Si plusieurs arrivent, elle impose d’ignorer toutes sauf la valeur numérique la plus élevée. Pour une valeur supérieure à 2, elle impose de supprimer la communauté erronée selon une approche analogue à la RFC 7606, mais recommande seulement de journaliser l’erreur. Cette défense contient un état malformé ; elle ne certifie pas la route restante.

Preuves et limites

La RFC 8097 définit le transport, les valeurs, les défauts EBGP, le déploiement mixte et la confiance déléguée. La RFC 6811 définit le calcul et garde l’action sous politique locale. Les RFC 7606 et 7454 cadrent l’erreur et le transport ; l’IANA confirme le sous-type.

Les sources ne disent pas quels réseaux utilisent aujourd’hui la communauté, ne chiffrent pas un gain universel et ne garantissent pas que deux validateurs partagent les mêmes données. Pouvoir, autorisation, bénéficiaires, coût et contrefactuel sont des analyses tirées des normes.

Sources