Résumé

  • L’option Hello de RFC 5384 annonce la capacité de recevoir l’encodage de source de type 1 ; elle n’atteste pas la compréhension de tous les types d’attributs transportés dans cette enveloppe.
  • En cas de valeurs concurrentes du même type venues de plusieurs adjacences aval, la règle générique retient l’adjacence à l’adresse numériquement la plus petite, sauf procédure spécifique. C’est un ordre de convergence, pas une validation d’intention, d’autorisation ou de résultat.

Une décision certaine, mais pas juste au sens institutionnel

Le cas est simple à reproduire. Deux routeurs aval rejoignent le même arbre, défini par la source et le groupe. Ils joignent au message un attribut du même type, mais avec des valeurs différentes. Le routeur amont doit fabriquer un état unique et annoncer quelque chose à son propre voisin amont. Il lui faut donc une règle commune.

RFC 5384 classe les fournisseurs plutôt que les arguments. L’attribut de l’adjacence PIM portant la plus petite adresse IP gagne. En IPv6, l’adresse lien-local sert à la comparaison. Si deux voisins ont la même adresse, l’indice d’interface les départage. Une future spécification d’attribut peut imposer une autre procédure ; sans elle, l’arithmétique des adresses suffit.

Cette solution possède une qualité importante : elle est reproductible. Deux implémentations qui voient les mêmes messages peuvent retenir le même ensemble. Mais aucune ligne de cette procédure ne dit que le gagnant connaît mieux le service, qu’il représente le propriétaire de l’application ou qu’il a obtenu le dernier accord de changement.

Le piège de gouvernance apparaît lorsque la stabilité est présentée comme un consensus. Le tableau d’exploitation n’affiche qu’une valeur active, les paquets de contrôle cessent d’osciller et l’organisation conclut que la politique est alignée. En réalité, le protocole a seulement masqué le désaccord derrière une convention déterministe.

La capacité à ouvrir l’enveloppe n’est pas la capacité à comprendre la lettre

RFC 5384 introduit l’Encoded-Source Address de type 1. Dans le contexte de l’adresse de groupe, cette source identifie l’arbre et peut contenir une suite d’attributs TLV. Le type 1 exige au moins un attribut ; l’absence d’attributs se représente par le type 0 ordinaire.

Avant d’envoyer le type 1 sur une interface, le routeur vérifie que tous les voisins y ont placé l’option Join Attribute dans leurs Hello. Même un voisin qui n’est pas le prochain saut amont doit savoir analyser le message pour les mécanismes de suppression ou de remplacement des Join.

La portée de cette annonce est volontairement limitée. Un routeur qui émet l’option ne comprend pas nécessairement tous les types d’attributs possibles. RFC 5384 ne crée pas une option Hello par type, car l’incapacité fine d’un voisin n’offre pas de réaction immédiate simple. Le reçu prouve donc le support de l’enveloppe, non un dictionnaire sémantique partagé.

Les textes ultérieurs montrent ce qui manque. RFC 6420 ajoute pour MT-ID une option de capacité propre, des contrôles de validité et des règles de conflit. RFC 6807 fait de même pour Population Count. RFC 7887 compacte les valeurs communes aux niveaux message, groupe et source sans en modifier le sens. La couche générique n’a jamais prétendu remplacer ces contrats particuliers.

Un dossier de mise en service devrait donc distinguer : analyse du type 1, support du type précis, version logicielle, interface concernée et politique locale. Écrire « Join Attributes pris en charge » dans une matrice produit efface la séparation centrale.

Un attribut inconnu peut continuer sa route

Le bit F commande le traitement par un routeur qui ne comprend pas le type. Avec F=1, l’attribut est transitif et doit être retransmis. Avec F=0, il est non transitif et doit être supprimé. Les autres attributs restent traités. S’il ne reste rien, le routeur relaie un Join de type 0.

La présence en amont ne vaut donc pas validation par chaque intermédiaire. Un routeur peut conserver des octets dont il ne sait pas expliquer la politique. Il a exécuté une règle de transport. Il n’a ni approuvé ni vérifié le contenu.

La situation devient plus instructive lorsque deux adjacences fournissent des ensembles transitifs contradictoires du même type à un routeur ignorant. Si les ensembles ne sont pas identiques octet par octet, avec le même nombre d’instances, la règle générique de conflit s’applique quand même. Le routeur choisit sans comprendre ce qu’il choisit.

La trace doit employer des verbes exacts : reçu, enveloppe analysée, type compris, inconnu retransmis, inconnu supprimé, ensemble sélectionné. Les mots « validé » et « approuvé » demandent une preuve supplémentaire.

La provenance reste attachée à l’adjacence

Lorsque le traitement d’un attribut modifie la construction de l’arbre ou l’ensemble retransmis, RFC 5384 exige de conserver l’association entre cet attribut et l’adjacence qui l’a fourni. C’est ce lien qui permet de retirer le bon état après un Prune ou l’expiration d’un voisin.

Le routeur peut mémoriser les valeurs perdantes. Si l’adjacence gagnante disparaît, la candidate suivante dans l’ordre peut devenir active immédiatement. La convergence est plus rapide ; l’intention n’est pas mieux connue.

Cette bascule crée un événement de politique même si le trafic continue. La nouvelle valeur n’est peut-être pas nouvelle : elle attendait depuis longtemps derrière une adresse plus petite. Un système qui ne conserve que la valeur active ne saura pas distinguer une modification explicite d’un changement provoqué par la perte du voisin dominant.

Il faut archiver l’ensemble des candidats, leur adresse, l’interface d’entrée, la procédure choisie, le gagnant, les valeurs écartées et la cause de la transition. La continuité de service ne doit pas rendre la continuité d’autorité invisible.

Le nouveau Join remplace tout l’ensemble

La mise à jour n’est pas un patch incrémental. Si un nouveau Join ne contient pas exactement le même ensemble d’attributs que le précédent, le nouvel ensemble devient l’état complet. Toute valeur absente est retirée. Un ensemble vide repasse au type 0. Un Prune retire aussi les attributs reçus de cette adjacence.

Cette sémantique rend les journaux de différences insuffisants. Un voisin qui envoyait A et B, puis seulement B, a retiré A sans message séparé « supprimer A ». Un collecteur qui ajoute les TLV vus sans reconstruire les états complets inventera un attribut fantôme.

Avec RFC 7887, une valeur peut être portée au niveau de tout le message, d’un groupe ou d’une source. La compression ne change pas le sens, mais elle agrandit le rayon d’une erreur. La preuve de changement doit donc conserver l’avant et l’après complets à chaque portée.

Authentifier l’émetteur ne règle pas le désaccord

RFC 5384 renvoie la sécurité de l’attribut à celle du paquet PIM et aux exigences propres à chaque type. RFC 5796 apporte une authentification des messages PIM lien-local. Elle peut établir l’origine et l’intégrité des octets, ce qui est indispensable pour l’attribution.

Elle ne répond pas à la question institutionnelle. Deux voisins authentifiés peuvent porter des demandes incompatibles. La cryptographie indique qui a parlé ; elle ne sait pas quel service a droit de décider, quel changement est approuvé ni pourquoi la petite adresse devrait dominer la grande.

L’autorisation doit être décrite hors du tiebreaker : principaux autorisés, plages de groupes et de sources, types et valeurs permis, ordre de priorité, approbation et possibilité de surcharge locale. RFC 6420 rappelle utilement qu’une configuration locale de topologie peut prévaloir. Cette configuration et son ticket font alors partie de la preuve.

Construire l’arbre n’est pas livrer le service

Même un attribut correctement compris, sélectionné et authentifié reste une preuve de plan de contrôle. Il peut influencer le voisin amont ou une topologie RPF. Il ne prouve pas l’installation de l’état multicast, le chemin réellement parcouru, l’absence de duplication, l’autorisation des récepteurs ni le résultat applicatif.

La chaîne d’observation doit rester découpée : intention configurée ; capacités annoncées ; Join reçu ; interprétation ; arbitrage du conflit ; nouveau Join amont ; état installé ; compteurs et traces du plan de données ; réception et effet applicatif. Chaque étape peut réussir tandis que la suivante échoue.

L’article BTW sur RFC 9798 conserve son domaine : Receiver RLOC, choix du groupe sous-jacent, réplication ITR et preuve de livraison. Celui sur RFC 9739 conserve PIM Light sans Hello, DR, Assert et retrait après panne. Ici, le sujet est exclusivement l’autorité limitée de l’arbitrage générique de RFC 5384.

Un essai qui conserve aussi le perdant

Dans un laboratoire, créer deux adjacences aval et un routeur amont. Vérifier l’annonce de type 1 sur chaque voisin de l’interface, puis utiliser un type d’attribut dont la spécification est connue. Capturer les octets, l’arbre source/groupe, l’adresse du voisin, l’interface et l’heure.

Envoyer deux valeurs incompatibles. Établir si une règle spécifique s’applique ; sinon confirmer la sélection de la plus petite adresse. Modifier seulement l’ordre des adresses et observer le changement de gagnant. Tester ensuite l’expiration de l’adjacence gagnante, l’activation du candidat mémorisé, le remplacement d’un ensemble A+B par B seul et la différence entre attribut inconnu transitif et non transitif.

Comparer enfin le contrôle aux traces de paquets et à des récepteurs canaris. Le compte rendu doit pouvoir dire « X a été sélectionné par la règle Y » sans convertir cette phrase en « X était autorisé » ni en « le service a été livré ».

Sources