Résumé

  • La RFC 3956 encodait une longueur de préfixe, un préfixe unicast et un petit identifiant dans l’adresse de groupe IPv6 afin que les routeurs calculent le même RP PIM-SM.
  • L’adresse pouvait venir de n’importe quel utilisateur : un calcul valide ne prouvait donc ni l’existence du RP, ni sa joignabilité, ni son autorité, ni l’arrivée des données chez un récepteur.

Une adresse qui distribuait la configuration

Le récepteur multicast commence souvent par une adresse de groupe apprise dans une application, un annuaire, une configuration ou une page web. La RFC 3956 fit de certaines adresses IPv6 une deuxième chose : un support de la correspondance entre groupe et Rendezvous Point de PIM Sparse Mode.

L’objectif répondait à une difficulté inter-domaine. IPv6 n’avait pas reçu le mécanisme MSDP employé pour découvrir les sources ASM d’IPv4, tandis que le multicast spécifique à la source ne couvrait pas immédiatement tous les usages. Si le RP pouvait être calculé depuis la destination, les domaines n’avaient plus à échanger une correspondance distincte pour ce choix.

Cette suppression de configuration ne supprimait pas l’état. Elle déplaçait une décision vers les bits fournis par l’utilisateur.

Le RP complet ne tenait pas dans le groupe

Une adresse IPv6 de 128 bits ne peut pas en contenir une seconde de 128 bits tout en préservant l’identité du groupe. La RFC 3956 prolongea donc le format à préfixe unicast de la RFC 3306. Un drapeau sélectionnait le sous-espace embedded-RP ; une longueur plen, une portion de préfixe réseau et un RIID de quatre bits permettaient de reconstruire l’adresse du RP sous certaines contraintes.

Le RIID zéro était réservé. Plusieurs RIID non nuls pouvaient désigner plusieurs RP sous un même préfixe, mais chaque adresse de groupe complète donnait un seul candidat. L’unicité des identifiants de groupe restait hors du périmètre. Deux routeurs pouvaient donc être d’accord sur le RP tout en recevant une adresse attribuée sans coordination globale.

Dans le sous-espace réservé, cette correspondance avait la priorité du plus long préfixe sur les autres méthodes group-to-RP. La règle empêchait deux mécanismes locaux de se contredire. Elle garantissait une décision identique, non un service vivant.

L’utilisateur orientait indirectement les routeurs

Après avoir appris l’adresse, un récepteur envoyait un rapport MLD. Son routeur désigné lançait alors un Join PIM-SM vers le RP calculé. Côté source, le routeur désigné pouvait encapsuler les premiers paquets dans des messages Register vers le même candidat. L’adresse remise à l’application influençait ainsi une destination du plan de contrôle.

La RFC qualifie explicitement cette information de non fiable : tout utilisateur Internet peut fournir une adresse de groupe. Une implémentation devait appliquer au RP dérivé au moins les mêmes contrôles qu’à un RP appris autrement. Le texte cite notamment l’exclusion des résultats link-local fe80::/10, du bloc ::/16 et du multicast ff00::/8.

Réussir ce filtre prouvait qu’une adresse pouvait être utilisée comme candidat. Cela n’authentifiait ni le créateur du groupe, ni l’opérateur du préfixe, ni une source. Cela n’accordait pas le droit d’émettre ou de recevoir. La syntaxe dirigeait le routage ; elle n’était pas une autorisation.

Le document refusait même de promettre l’existence

PIM-SM souhaite qu’une adresse de RP apprise ou configurée soit joignable dans le domaine. La RFC 3956 reconnaît que cette propriété ne peut pas être prouvée en général et qu’avec un RP étranger encodé, son existence même n’est pas garantie.

Une route vers l’adresse dérivée atteste seulement d’une décision de transfert. Elle ne prouve pas qu’un processus PIM répond, accepte les Register, possède l’état de source attendu ou dispose des ressources nécessaires. Un Join installé témoigne d’un état de contrôle, pas de l’arrivée d’un flux. Une entrée en cache témoigne d’un calcul antérieur, pas de la santé actuelle du RP.

Rendre le RP visible le rend aussi plus identifiable comme point unique de défaillance. Cette visibilité facilite le diagnostic mais aussi le ciblage ; elle n’est pas une sonde de disponibilité. Masquer un groupe des annonces MSDP relevait déjà de l’obscurité, non d’un contrôle d’accès. Le schéma intégré exigeait toujours du filtrage et une politique de frontière.

Les autres protocoles gardaient leur propre verdict

La RFC 4601 décrivit ensuite en détail les arbres partagés, Join et Register de PIM-SM. La RFC 3810 définissait les rapports MLDv2. Le premier consignait des décisions de routage ; le second une demande locale de réception. Aucun ne constituait à lui seul un reçu de livraison.

La RFC 4607 décrivit SSM, qui nomme source et groupe et évite le RP. La RFC 3956 le considérait comme une alternative importante, mais non comme un remplacement universel immédiat. Nommer davantage l’intention ne prouve toujours pas l’état réel du chemin.

La RFC 7371 actualisa plus tard l’architecture des adresses multicast IPv6. La notice RFC Editor et la page des errata documentent RFC 3956 ; elles ne démontrent aucun déploiement particulier.

L’innovation consistait à rendre le choix reproductible. Cette reproductibilité réduisait les divergences de configuration, mais ne changeait pas un candidat en fait opérationnel. L’adresse disait où essayer. La route, les échanges PIM, l’état de source, les compteurs et l’observation du récepteur devaient dire ce qui s’était réellement passé.

Sources