Résumé

  • La RFC 8092 définit un attribut optionnel et transitif dont chaque valeur comporte un espace Global Administrator et deux champs définis par l’opérateur.
  • Une valeur valide peut décrire ou demander une politique, mais elle n’authentifie pas son auteur, n’en garantit pas l’intégrité et n’oblige pas l’AS destinataire.

Plus d’espace, la même question de gouvernance

La communauté BGP classique offrait une étiquette de 32 bits, souvent divisée entre un ASN sur deux octets et une valeur locale. L’arrivée des ASN sur quatre octets a rendu cette convention insuffisante. La RFC 8092 introduit une valeur de douze octets : quatre pour le Global Administrator, puis quatre pour chacune des deux parties locales. L’attribut peut contenir un ensemble non ordonné de ces valeurs.

Le format redonne de la place au signal opérateur et trace un espace de noms. Lorsque le premier champ est un ASN, son propriétaire définit le sens des deux autres. La représentation canonique utilise trois entiers décimaux séparés par des deux-points, sans zéro initial. L’ordre ne compte pas ; les doublons ne doivent pas être émis et sont supprimés silencieusement à la réception.

Ces règles ne décident pas qui peut demander une action. La RFC 8195 distingue les communautés informatives — origine, relation, audience — des communautés d’action, qui peuvent demander une modification de propagation, de préférence locale, de next hop ou de prepend. Dans chaque cas, la politique de l’AS visé donne un effet au signal.

Un espace de noms n’est pas un mandat

Global Administrator ne signifie pas compte administrateur. Le champ indique qui documente le vocabulaire, non qui contrôle le routeur distant. Un client peut employer l’ASN de son fournisseur pour demander une action publiée ; n’importe quel AS peut aussi joindre cette valeur. Le destinataire doit donc vérifier le voisin, la route, les droits associés et l’ordre de traitement.

La frontière d’autorisation est locale. L’émetteur exprime une intention ; le destinataire l’exécute, la transforme ou l’ignore. Un fournisseur peut accepter une demande d’un client et rejeter la même valeur reçue d’un pair non autorisé. Un serveur de routes peut exposer des commandes de distribution tout en gardant des protections contre les effets croisés entre clients.

Les bénéficiaires sont les clients, pairs, fournisseurs et équipes d’exploitation qui obtiennent un vocabulaire portable pour l’automatisation, le diagnostic et la planification. Leur bénéfice dépend pourtant d’une sémantique publiée et de contrôles observables, pas du seul numéro.

Transitivité sans intégrité

L’attribut est transitif, mais la RFC 8092 précise qu’il ne protège pas l’intégrité. Un AS intermédiaire peut ajouter, retirer ou modifier une valeur. Déduire la provenance exige donc de faire confiance au chemin ou d’utiliser un mécanisme distinct, que la RFC ne fournit pas.

L’agrégation peut réunir les communautés des routes composantes. Les signaux s’accumulent et peuvent entrer en conflit. Une longueur mal formée déclenche treat-as-withdraw, tandis qu’un ASN non attribué ou réservé dans le premier champ ne rend pas à lui seul l’attribut invalide. Validité protocolaire et légitimité de politique sont deux examens différents.

Le coût porte sur la gouvernance : publier le répertoire, contrôler les voisins autorisés, documenter la priorité, surveiller les modifications, tester l’agrégation et conserver un retour arrière. Une automatisation pratique peut aussi amplifier une mauvaise interprétation.

Preuves et limites

La RFC 8092 fixe format, représentation, agrégation, doublons, erreurs et limites d’intégrité. La RFC 8195 décrit les usages ; les RFC 1997 et 7454 apportent le contexte. L’analyse du pouvoir, des bénéficiaires et des coûts est une inférence explicite.

Les sources ne prouvent aucun déploiement nommé, n’authentifient pas l’AS qui a posé une valeur, n’imposent pas son exécution et ne garantissent pas sa conservation. Une valeur bien formée peut rester non autorisée, périmée, altérée ou sans objet.

Sources