Résumé

  • RFC 9764 agrandit la charge de transport BFD jusqu’à une valeur configurée, impose des octets de bourrage nuls et, sous IPv4, active le bit Don't Fragment. L’état Up atteste donc le passage récent de ces paquets à cette taille.
  • La preuve reste directionnelle et liée au chemin de forwarding effectivement pris. Il faut configurer les deux extrémités pour parler des deux sens, et une session agrégée peut ignorer des membres LAG ou ECMP défaillants.
  • pdu-size est une commande partagée. Son augmentation peut faire tomber une session déjà Up, entraîner les clients qui en dépendent et confondre limite MTU, incompatibilité du pair, filtrage ou répartition de charge.

Le dossier de changement semblait presque trivial : passer une valeur de 1 400 à 1 512, vérifier que BFD reste Up, puis considérer le réseau prêt. Une seule ligne YANG, une seule fenêtre, un seul voyant. Pourtant, cette ligne pouvait modifier l’état utilisé par plusieurs protocoles et déclencher un retrait de route avant même que l’équipe ait identifié la cause d’un échec.

C’est là que RFC 9764 devient plus intéressant qu’une simple technique de bourrage. Le texte répond à une faiblesse concrète : les paquets BFD habituels sont petits. Ils peuvent traverser une route qui abandonne les datagrammes plus grands dont dépend une application. Une session Up établit alors la joignabilité de son trafic de contrôle, mais pas la capacité de transporter la taille utile.

Le RFC ajoute une variable, bfd.PaddedPduSize. La charge du protocole de transport qui enveloppe le PDU BFD est portée à cette taille. Les octets ajoutés doivent être nuls ; le récepteur ne devrait pas les valider. Sous IPv4, le paquet doit porter Don't Fragment. Ainsi, la fragmentation ne peut pas transformer artificiellement un gros test en plusieurs petits passages.

Cette mécanique est précise. L’interprétation doit l’être aussi.

Un seuil entretenu, pas une mesure du maximum

RFC 5880 fournit la machine d’état BFD. RFC 9764 ne redéfinit ni son en-tête ni sa logique fondamentale. Il change la longueur de l’enveloppe, puis laisse la non-réception produire le comportement BFD normal. Si les paquets rembourrés continuent d’arriver, la session peut rester Up ; s’ils cessent d’arriver assez longtemps, elle descend.

Une valeur de 1 512 octets ne dit pas que le Path MTU vaut exactement 1 512. Elle dit que les paquets BFD observés à cette taille ont franchi le traitement rencontré. Le chemin pourrait accepter davantage. Le mécanisme ne cherche pas ce maximum. Une hausse ultérieure du Path MTU ne produit aucun nouvel état : la session continue simplement.

Cette portée distingue le sujet de la découverte classique. RFC 1191 définit le Path MTU pour une route donnée et fait réviser au poste émetteur son estimation à partir d’un message borné. RFC 8899 organise la découverte au niveau de la paquetisation pour les transports par datagrammes. RFC 9764 ne remplace pas ces boucles. Il maintient une condition minimale choisie pour un client de BFD.

La taille doit donc venir du besoin, pas du prestige du plus grand chiffre. Une interface locale à 9 000 octets ne signifie pas que l’application exige 9 000, ni que le chemin les transporte. Un seuil inutilement élevé peut réduire la disponibilité sans produire une information exploitable. Un seuil trop bas peut conserver Up tout en laissant insatisfaite l’application qui a motivé le contrôle.

Deux sens exigent deux actes

Le caractère bidirectionnel de BFD décrit l’échange du protocole, mais la condition de taille demeure configurée par émetteur. Pour établir qu’un seuil est utilisable dans les deux sens, RFC 9764 demande de configurer PaddedPduSize des deux côtés.

Cette exigence n’est pas cérémonielle. A vers B et B vers A peuvent suivre des tunnels, files, politiques ou routes différentes. Une valeur configurée uniquement à A peut démontrer que B reçoit les gros paquets d’A, sans rien établir sur l’autre sens. Des MTU asymétriques peuvent même être intentionnels ; chaque côté doit alors porter la valeur adaptée à son propre besoin.

RFC 5881 décrit BFD sur un seul saut. Dans une liaison directe, la configuration du MTU d’interface fournit souvent déjà une part de l’assurance. RFC 5883 traite le cas multihop, où la capacité locale de la première liaison ne décrit plus la route complète. C’est précisément là qu’un gros paquet BFD devient utile, et là aussi que le mot « chemin » peut recouvrir plusieurs réalités.

Une preuve exploitable conserve donc deux lignes temporelles : dernière réception réussie et taille opérationnelle d’A vers B ; mêmes éléments de B vers A. Une synthèse unique est permise pour l’exploitation, mais pas au prix de la disparition des faits directionnels.

Plusieurs clients, une valeur effective

Une session BFD peut servir plusieurs protocoles clients. Si l’un demande 1 400 octets et l’autre 1 600, RFC 9764 recommande de retenir la plus grande valeur pour les mêmes extrémités. Autrement, la session pourrait rester Up sans satisfaire le client le plus exigeant.

Cette règle crée un arbitrage silencieux. Le client qui demande la plus grande taille fixe le seuil effectif pour tous. L’arrivée d’un nouveau client peut modifier l’état partagé et provoquer des actions chez des clients plus anciens qui n’avaient pas besoin de cette taille.

Supposons que le pair distant sache traiter le PDU BFD ordinaire mais rejette l’enveloppe agrandie. Après activation, les paquets ne sont plus reçus, la session descend et un protocole de routage réagit. Le réseau a produit un fait exact — le nouveau trafic BFD n’a pas soutenu la session — mais il n’a pas encore distingué une étroitesse physique d’une limite d’implémentation.

Le changement doit donc nommer le demandeur, les autres clients, l’ancienne et la nouvelle valeur, la capacité déclarée des deux pairs, les conséquences associées à Down et le retour arrière. Sans ces éléments, pdu-size devient une commande transversale déguisée en métrique.

L’incompatibilité ressemble à une perte

RFC 9764 ne modifie pas le PDU BFD lui-même. Il exploite le fait que la charge UDP peut être plus longue que le PDU contenu. Pourtant, certaines implémentations peuvent refuser un gros paquet ou appliquer incorrectement leur validation. Dans les deux cas, la machine d’état ne voit qu’une absence.

Un filtre intermédiaire peut produire la même absence. Un attaquant présent sur le chemin peut supprimer sélectivement ces paquets et forcer Down. L’ajout de zéros empêche par ailleurs de divulguer de la mémoire locale non initialisée, mais il ne prouve pas la cause d’une disparition.

Il faut séparer trois phrases. « Les paquets BFD rembourrés ne soutiennent plus la session » est l’observation. « Le Path MTU est inférieur au seuil » est une hypothèse. « Retirer tous les services est la bonne réponse » est une décision. Les fusionner supprime l’étape où l’on vérifie le pair, les filtres, les deux directions et le trafic applicatif.

ECMP peut laisser le défaut hors du faisceau

Les agrégats LAG et les routes ECMP répartissent des flux entre plusieurs membres tout en présentant une seule abstraction. Un flux BFD peut rester fixé sur un membre sain. Une application, hachée autrement, peut emprunter un membre dont le MTU est plus faible. La session est Up ; le service échoue.

RFC 7130 apporte un mécanisme BFD pour les membres d’un LAG. RFC 9764 souligne toutefois l’absence de mécanisme BFD multihop général normalisé qui exercerait tous les liens ECMP. Certaines implémentations utilisent leur connaissance interne pour élargir la couverture. Ce comportement reste propre au produit et ne peut pas être déduit de la seule conformité au RFC.

Le résultat ne doit donc pas être rejeté, mais qualifié. Il décrit le traitement réellement suivi par les paquets de contrôle. Il n’est pas une projection sur toutes les valeurs de hachage. Des MTU incohérents entre membres peuvent rendre la capacité dépendante du flux.

Le rapport BTW consacré à RFC 9978 protège une frontière voisine : compter des paquets BFD manqués avertit d’une instabilité sans prouver la perte client. Le présent rapport protège la frontière de taille : faire passer un gros paquet de contrôle ne prouve pas le sort de tous les gros paquets de données.

Le modèle de données ne garantit pas l’exécution

Le module ietf-bfd-large augmente les modèles de RFC 9314. Il expose la fonction padding et la feuille pdu-size pour plusieurs familles de sessions. Son architecture de gestion suit RFC 8342.

Voir la feuille dans un datastore prouve qu’une configuration existe à cet endroit. Il faut encore vérifier l’état opérationnel, la version déployée, l’extrémité distante, les clients et les paquets. La feuille est modifiable ; changer sa valeur pendant qu’une session est Up peut la faire tomber et toucher plusieurs consommateurs.

La même prudence vaut pour S-BFD. RFC 7880 en donne la base et RFC 9764 autorise l’application de la technique. Cette compatibilité n’efface ni la direction, ni la taille, ni le mode, ni le périmètre de forwarding.

Répéter le test ne transforme pas l’avenir en certitude

RFC 9869 utilise des jetons de requête et de réponse pour la découverte de MTU avec UDP Options. Son sujet distinct est la portée d’une sonde déterminée. BFD apporte ici la répétition : la condition de taille est exercée périodiquement. Cela réduit l’âge de l’observation, mais ne force pas le prochain paquet applicatif à utiliser le même membre, la même encapsulation ou la même file.

Le bon libellé reste daté : « session actuellement Up avec des paquets BFD de telle taille et telle configuration ». Une formule comme « MTU du service garanti » emprunte une autorité que le test ne possède pas.

Sources et limite probatoire

Le corpus figé comprend RFC 9764, les bases BFD RFC 5880, RFC 5881, RFC 5883, RFC 7130 et RFC 7880, puis les modèles RFC 9314 et RFC 8342. Le contexte de taille vient de RFC 1191, RFC 8899 et RFC 9869, avec RFC 9978 pour la portée de la stabilité BFD.

La lecture de gouvernance s’appuie sur les notes de Heng Lu consacrées à la spécification initiale minimale, à la primauté du code en fonctionnement et aux couches de réalité. La discipline commune est simple : conserver un fait technique petit et vérifiable, puis laisser la décision future à l’opérateur qui en assume l’effet.