Résumé

  • L’ETR récepteur choisit localement un groupe multicast de l’underlay qu’il peut rejoindre ; RFC 9798 ne crée ni allocation mondiale de groupes ni attestation distante de cette capacité.
  • L’ITR racine crée une entrée OIF pour chaque mapping underlay distinct. Pour suivre les ETR, il doit lire l’adresse source du Join/Prune, qui doit être un RLOC d’ETR, et non déduire leur nombre du groupe.
  • L’authentification peut conforter l’origine et l’intégrité d’une demande, mais elle ne prouve ni l’autorité sur le groupe, ni la formation de l’arbre, ni la réception des données.

Deux adresses, deux responsabilités

Le message reçu par l’ITR contient deux éléments faciles à amalgamer. Le Receiver RLOC multicast indique l’adresse sur laquelle un ETR souhaite recevoir le flux encapsulé. L’adresse IP source du PIM Join/Prune identifie l’ETR qui a envoyé la demande lorsque l’ITR doit tenir une liste de ces ETR. RFC 9798 exige alors que cette source soit elle-même une adresse RLOC d’ETR.

Le groupe ne répond donc pas à la question « qui a demandé ? ». La source ne répond pas à « qui a reçu ? ». Et un état de transfert ne répond pas à « quel service a consommé les données ? ». Une exploitation qui range ces trois réponses dans une même colonne “receiver” perd la capacité d’expliquer un écart.

Publié en juin 2025 dans la catégorie Experimental, RFC 9798 met à jour RFC 8059 dans une portée étroite. La syntaxe et la sémantique de l’attribut Transport restent intactes. L’extension ne vaut que lorsque Transport=0, c’est-à-dire multicast. Le champ Receiver RLOC, auparavant formulé pour la réplication unicast en tête, accepte alors une adresse multicast pour un flux encapsulé en multicast. Cette adresse ne doit être utilisée que si l’underlay du cœur LISP prend en charge le transport IP multicast.

Ce « prend en charge » n’est pas accompagné d’un protocole de preuve. RFC 9798 confie à l’ETR une décision locale : choisir un groupe qu’il peut rejoindre, identifier le site LISP amont où l’arbre doit prendre racine, puis construire le Join/Prune selon RFC 8059. Il faut donc conserver la configuration, le test de capacité et la version de politique qui ont motivé ce choix. L’adresse seule ne les remplace pas.

Le mapping décide où la facture apparaît

RFC 6831 sépare l’état des sites, fondé sur les EID, de l’état du cœur, fondé sur les RLOC. Cette architecture permet au cœur multicast d’effectuer une partie de la réplication avant que les ETR ne décapsulent et n’appliquent leur état interne (S-EID,G).

RFC 9798 décrit trois formes de mapping. Plusieurs flux overlay peuvent partager un seul flux underlay ; un seul flux overlay peut être envoyé sur plusieurs groupes underlay pour satisfaire des contraintes différentes ; ou chaque flux peut garder son mapping propre. Il ne s’agit pas de trois écritures équivalentes. Elles déplacent l’état, la réplication et le risque de trafic inutile.

Le many-to-one réduit le nombre d’arbres du cœur. RFC 6831 montre cependant que deux sources overlay agrégées dans le même (S-RLOC,G) peuvent faire parvenir à un site du trafic qu’il n’avait demandé que pour l’autre source ; l’ETR le jette après décapsulation si son état interne ne correspond pas. Le one-to-many sépare des populations contraintes mais oblige la racine à produire plusieurs copies. Le one-to-one améliore l’isolation au prix d’un état plus abondant.

La règle de comptabilité de RFC 9798 est nette : l’ITR alloue une nouvelle entrée dans la liste des interfaces sortantes pour chaque mapping multicast underlay unique. Il peut appliquer une politique locale de limitation du nombre de copies. Le standard ne fixe ni quota universel ni promesse de service. Les preuves utiles sont le mapping exact, l’entrée OIF, le nombre demandé, le nombre admis et le motif de limitation.

Les contraintes de plages expliquent pourquoi un même flux overlay peut se fragmenter. Un PxTR peut relier des interfaces de site à un cœur LISP externe qui n’utilise pas les mêmes plages de groupes. Un équipement peut aussi être limité par ses ressources matérielles. Chaque groupe retenu devrait donc être lié à la frontière concernée, à la plage autorisée, au profil matériel et à leur date d’effet.

L’enveloppe d’attribut ne découvre pas les capacités

RFC 5384 définit l’encodage générique des Join Attributes. Il avertit que les attributs influençant l’arbre ne sont réellement exploitables que dans un domaine coopérant où l’on sait à l’avance que les routeurs comprennent l’encodage et l’attribut. Dans le PIM ordinaire, une option Hello évite d’envoyer cette forme à un voisin incapable de la traiter.

RFC 8059 précise toutefois que les xTR LISP n’échangent pas de PIM Hello. Aucun Hello ne négocie donc ses attributs ; les systèmes assurant la réplication unicast en tête sont supposés les comprendre. Les attributs Transport et Receiver RLOC sont non transitifs. RFC 9798 étend leur usage au multicast sans ajouter de registre mondial de groupes ni de découverte universelle de capacité.

Cette modestie de la spécification est saine à condition de ne pas transformer l’hypothèse en fait d’exploitation. Un attribut décodé prouve la compréhension d’une représentation. Une politique chargée prouve une intention. Une entrée OIF prouve un état de contrôle. Des compteurs datés prouvent une activité. Seule une observation côté réception établit ce qui est arrivé.

Une demande authentifiée reste une demande

RFC 8059 rappelle que l’attribut n’est pas plus authentique que le paquet PIM qui le transporte. RFC 9798 envisage des rafales de joins portant des groupes différents ou se chevauchant, avec interférence et épuisement par réplication. Il indique que les mécanismes de RFC 5796 pourraient valider les demandes et évoque un suivi ou un plafond de groupes par RLOC source.

RFC 5796 traite de la protection IPsec des messages PIM-SM de lien local. Avec des associations de sécurité correctement gérées, on peut documenter l’origine et l’intégrité d’un message. On ne peut pas en déduire que le groupe appartient à l’émetteur, que chaque segment le transporte, que des membres sont présents ou que les données ont été livrées.

Le reçu complet conserve donc les octets du Join/Prune, les attributs décodés, le résultat d’authentification, le RLOC source, la décision locale de l’ETR, la cardinalité du mapping, l’entrée OIF, la limitation, l’état du cœur, la décapsulation et le constat applicatif. Chaque étape porte une heure et un identifiant de corrélation ; aucune ne s’intitule simplement « valide ».

Sources