Résumé

  • RFC 9793 définit l’attribut de chemin BGP optionnel transitif 41. Pour un préfixe d’hôte BFR, il peut annoncer sous-domaine, BFR-ID, encapsulation et prochain saut BIER afin d’alimenter le calcul des BIFT.
  • Le texte suppose qu’un domaine BIER coïncide avec un domaine administratif, lequel peut comprendre plusieurs systèmes autonomes. Sur un routeur de frontière qui prend en charge l’attribut, la politique EBGP l’interdit par défaut.
  • Quand l’attribut n’est pas autorisé, il ne doit pas être exporté ; reçu du pair, il doit être ignoré sans bruit et ne pas être propagé. Sa présence ne prouve donc ni consentement, ni compatibilité des espaces de numérotation, ni état installé, ni résultat multicast.

Une frontière qui comprend le message peut tout de même le refuser

Le cas décisif de RFC 9793 n’est pas celui d’un paquet illisible. C’est celui d’une UPDATE BGP parfaitement analysable qui arrive au bon protocole, avec un attribut connu, et dont l’usage reste interdit. Cette nuance retire au transport une autorité qu’on lui prête trop facilement.

RFC 9793 qualifie l’attribut BIER d’optionnel et transitif. Il peut voyager avec une NLRI d’hôte IPv4 /32 ou IPv6 /128, pour les combinaisons AFI 1 ou 2 et SAFI 1, 2 ou 4 visées par le document. Son type 41 est enregistré dans le registre IANA des paramètres BGP. Un TLV BIER associe un sous-domaine et un BFR-ID à des données d’encapsulation MPLS ou non-MPLS ; un sous-TLV de prochain saut BIER peut préciser le voisin utilisé pour le calcul.

Cette transitivité est utile au sein du périmètre prévu. Un locuteur BGP qui n’est pas BFR peut relayer la route avec l’attribut sans agir sur BIER. Un BFR peut, selon les règles du texte, remplacer son prochain saut et ses informations d’encapsulation pour les sous-domaines et longueurs de chaîne de bits qu’il prend en charge. Les types de TLV inconnus doivent même être conservés et propagés dans l’attribut : l’extensibilité ne doit pas être cassée par un nœud qui ne connaît pas encore une extension.

Mais cette logique interne n’est pas un passeport interdomaines. La section 7 exige qu’un routeur de frontière prenant en charge l’attribut dispose d’une politique attachée à une session ou à un groupe EBGP. Par défaut, l’attribut n’est pas autorisé. Dans ce cas, il ne doit pas être envoyé au pair ; s’il est reçu, il est traité comme un attribut optionnel non transitif inconnu, donc ignoré silencieusement et non retransmis.

Le contraste avec RFC 4271 est volontaire. La règle BGP générale permet de conserver un attribut optionnel transitif inconnu et de le propager avec le bit Partial. Pour l’attribut BIER connu, RFC 9793 commande à la frontière refusante le résultat de traitement de l’autre catégorie. Le type 41 ne change pas de nature sur le fil ; c’est la décision administrative locale qui ferme le passage.

Le calcul est réel, mais ce n’est qu’un étage

L’attribut transporte assez d’information pour avoir des conséquences techniques. Un BFR parcourt, pour chaque sous-domaine, les préfixes BFR dont le TLV BIER correspond. Un BFR-ID non nul peut donner lieu à la création ou à la mise à jour d’une entrée BIFT. Le prochain saut BIER, ou le repli défini lorsqu’il manque, fournit le voisin BFR ; la plage d’étiquettes MPLS ou d’identifiants BIFT fournit l’information d’encapsulation. Ce résultat se combine avec la FIB unicast de l’underlay.

Il faut pourtant conserver les verbes séparés. L’émetteur déclare. Le récepteur analyse. La politique admet ou refuse. Le calcul produit un état candidat. Une plate-forme peut ensuite installer, ou non, cet état. Un tunnel peut être nécessaire alors que son établissement et son choix sont hors du champ de RFC 9793. Enfin, seuls des paquets observés et des récepteurs vérifiés parlent du résultat multicast. Une route reçue ne signe aucun de ces étages suivants.

Le document maintient cette discipline dans ses erreurs. Une longueur TLV incohérente rend l’attribut malformé et impose l’action attribute discard décrite par RFC 7606. Deux TLV BIER portant le même sous-domaine peuvent invalider tout l’attribut. Des longueurs de chaîne de bits répétées ou des plages qui se chevauchent font ignorer les données d’encapsulation concernées. Deux préfixes BFR ne doivent pas partager le même BFR-ID non nul dans un sous-domaine pour le calcul BIFT. Une syntaxe propre ne vaut donc pas autorisation ; une autorisation ne rend pas cohérentes des données contradictoires.

Un domaine administratif peut contenir plusieurs AS

La politique ne doit pas être réduite à l’équation « EBGP égale extérieur ». RFC 9793 suppose l’alignement du domaine BIER et du domaine administratif, mais précise que ce dernier peut regrouper plusieurs systèmes autonomes. RFC 8279 admet aussi qu’EBGP serve d’underlay dans certains scénarios. Une session EBGP peut donc relier deux AS sous une même autorité opérationnelle, ou franchir la limite vers une autorité indépendante.

Le logiciel ne peut pas déduire cette différence du numéro d’AS. D’où une règle en deux temps : fermeture par défaut, exception explicite sur la session ou le groupe que l’opérateur a classé. L’exception ne prouve toutefois pas que la classification est correcte. Elle doit encore être reliée à une conception connue : quels préfixes BFR, quels sous-domaines, quels BFR-ID, quelles longueurs de BitString, quelles plages d’encapsulation, quel propriétaire et quelle voie de retour.

Recevoir le type 41 établit seulement qu’un pair l’a émis. Cela ne révèle pas qui a autorisé l’export, ni si l’autre extrémité a donné le même sens à « sous-domaine 0 ». Le BFR-ID n’est unique que dans son sous-domaine. Une étiquette ou un BIFT-id appartient à un contexte d’encapsulation. Le prochain saut BIER n’authentifie pas l’organisation qui contrôle la session. L’UPDATE transporte les valeurs, pas l’accord qui rend leurs espaces compatibles.

Le faux raccord commence par une collision de sens

RFC 9793 explique pourquoi les préfixes BFR, généralement des loopbacks, n’ont pas besoin de sortir du domaine administratif pour les besoins BIER. S’ils sortent avec l’attribut et que le domaine voisin déploie lui aussi BIER, deux domaines censés rester indépendants peuvent être raccordés par erreur. Le texte prévoit des configurations probablement conflictuelles, des risques de sécurité et des difficultés d’exploitation.

Ce passage n’est pas le compte rendu d’un incident. Il ne démontre aucune perte, attaque, panne ou mauvaise livraison. Il identifie le mécanisme de risque : des numéros localement valides acquièrent une portée qu’aucun opérateur n’a encore reconciliée. La frontière est donc une protection des espaces de sens avant d’être une histoire de trafic.

La frontière du plan de données renforce cette lecture. RFC 8279 dit qu’un paquet encapsulé BIER ne passe pas directement d’un domaine BIER à l’autre. Il doit être décapsulé, remis à l’overlay multicast, puis éventuellement réimposé par un routeur agissant comme BFER du premier domaine et BFIR du second. Cette rupture explicite est différente d’une fusion silencieuse des identifiants du plan de contrôle.

Enfin, l’erratum vérifié de RFC 9793 corrige l’exemple de la section 6 : quand la route de BFER1 n’inclut pas de prochain saut BIER, BFR2 doit utiliser le préfixe BFR de BFER1, et non celui de BFR1. La correction affine l’exemple ; elle ne modifie pas la politique de frontière. La fiche RFC Editor et le dossier Datatracker prouvent le statut du document, pas sa présence dans un réseau.