Le routeur se souvenait d’un auditeur. Le flux, lui, n’est jamais arrivé : RFC 9777

Résumé

• RFC 9777 apprend l’intérêt multicast sur un lien directement connecté ; il n’authentifie ni l’auditeur ni le chemin de bout en bout.
• L’intention de plusieurs sockets est agrégée dans un état d’interface, puis résumée en état INCLUDE/EXCLUDE du routeur, soumis à des temporisateurs.
• Une décision solide sépare huit preuves : socket, émission du rapport, querier, état du routeur, compatibilité, routage amont, réplication et livraison utile.

Un état multicast peut être exact et insuffisant. C’est la difficulté centrale de RFC 9777, publié en mars 2025 comme STD 101. Le texte indique ce qu’un routeur a appris des nœuds voisins sur un lien IPv6. Il ne prétend pas raconter ce qui se passe ensuite dans l’ensemble du réseau.

La mémoire locale fabrique une projection

Le point de départ est une demande de l’application à la couche IP : socket, interface, adresse multicast, mode de filtrage et liste de sources. INCLUDE retient seulement les sources désignées ; EXCLUDE accepte toutes les sources sauf celles qui figurent dans la liste.

Mais MLDv2 ne transmet pas une copie fidèle de chaque socket. Le système compose un état par interface. Plusieurs sockets en INCLUDE produisent l’union de leurs sources. Dès qu’un socket est en EXCLUDE, la formule change pour respecter toutes les demandes. Le premier rapport est donc déjà une projection.

Le routeur compresse encore cette information. Il lui suffit normalement de savoir qu’au moins un nœud du lien souhaite (S,G). En INCLUDE, il conserve une liste de sources assorties de temporisateurs. En EXCLUDE, il entretient une liste demandée et une liste exclue. La première prépare le retour éventuel vers INCLUDE mais ne commande pas directement le transfert. Aucun de ces enregistrements ne dit quel processus est toujours vivant.

Même l’arrivée du paquet sur l’hôte ne ferme pas la preuve. RFC 9777 précise que sa remise à une socket dépend encore de l’état de cette socket et, éventuellement, du port de transport. L’implémentation n’est pas obligée d’assurer un filtrage par source distinct pour chaque socket. Trame reçue, paquet accepté et donnée consommée sont trois observations différentes.

Les secondes portent une incertitude

Les Current-State Reports rafraîchissent l’état ; les State-Change Reports annoncent une modification et sont répétés selon la Robustness Variable. Avec les valeurs par défaut—robustesse 2, intervalle de requête 125 secondes et réponse 10 secondes—le Multicast Address Listening Interval atteint 270 secondes. Le routeur peut donc conserver un état parfaitement conforme alors que l’application qui l’a déclenché n’existe plus.

Le départ rapide n’est pas instantané. Lorsqu’un hôte demande l’arrêt d’une source, le querier vérifie s’il reste un autre auditeur. Avec un intervalle d’une seconde et deux requêtes, le Last Listener Query Time vaut deux secondes par défaut. Pendant cette fenêtre, le composant MLD continue de suggérer le transfert. Le silence devient absence seulement après une enquête temporisée.

Le sens d’une expiration dépend du mode. En INCLUDE, la source est retirée. En EXCLUDE, une source peut passer de la liste demandée à la liste exclue. À l’expiration du Filter Timer, le routeur retourne vers INCLUDE à partir de la liste demandée. Un tableau qui affiche seulement « timer actif » ou « expiré » efface la transition réellement décisive.

Le coût caché de la compatibilité

Une requête générale MLDv1 place l’hôte en compatibilité v1 sur l’interface. Le temporisateur associé vaut 260 secondes avec les valeurs par défaut. Le changement de mode annule les réponses et retransmissions en attente ; l’hôte cesse alors d’annoncer la précision par source.

Un rapport MLDv1 provoque un effet analogue, groupe par groupe, sur le routeur. Les enregistrements BLOCK sont ignorés et les listes de sources d’un passage vers EXCLUDE disparaissent. Au retour à MLDv2, il faut réapprendre l’état précis ; une source qui devrait être bloquée peut rester ouverte jusqu’à l’expiration de l’intervalle d’écoute.

RFC 4604 ajoute une discipline particulière pour le SSM : une demande ancienne et non spécifique à la source ne devrait pas établir l’état de transfert. Les équipements doivent aussi s’accorder sur la plage SSM. La compatibilité protège la coexistence, mais elle peut dégrader la sémantique que l’exploitation croyait observer.

Au-delà du dernier routeur local

MLDv2 fournit ses informations au protocole de routage multicast et ne les remplace pas. Pour le SSM, RFC 4607 exige que la demande (S,G) progresse saut par saut vers la source sur un chemin sans boucle. RFC 7761 décrit ensuite les arbres partagés et source, les changements de chemin, les réplications, doublons temporaires et élagages. Un rapport local peut précéder la fin de cette construction.

Sur le LAN, un commutateur d’écoute prend encore sa propre décision. RFC 4541 montre que les ports de routeur multicast, les changements de topologie et la distinction entre contrôle et données influencent la distribution. La table du routeur ne certifie pas celle du commutateur.

Enfin, MLDv2 n’est pas authentifié. Les contrôles d’adresse link-local, de Hop Limit égal à 1 et de Router Alert bloquent les messages venus de l’extérieur du lien, pas un émetteur malveillant présent sur ce lien. Une répétition peut prolonger l’état ; un rapport v1 forgé peut déclencher une compatibilité moins précise.

Huit preuves pour une seule promesse de service

La preuve de l’intention socket identifie processus, autorisation, interface, mode et sources. La preuve d’émission capture le bon rapport. La preuve du querier et des temporisateurs fixe version, QRV, QQI, MALI et LLQT. La preuve de l’état routeur conserve mode, listes et durée restante.

La preuve de compatibilité explique toute rétrogradation. La preuve amont suit Join/Prune et le choix RPF. La preuve de réplication vérifie chaque branche. La preuve de livraison mesure ce que la socket et l’application ont effectivement reçu et utilisé.

Ces reçus n’ont de valeur qu’avec un observateur et une heure. L’objectif n’est pas de multiplier les tableaux, mais d’empêcher une vérité locale de parler au nom d’un résultat qu’elle n’a jamais observé.

Sources

1. RFC 9777 — MLDv2 pour IPv6
2. RFC 3810 — spécification MLDv2 remplacée
3. RFC 2710 — MLDv1
4. RFC 4604 — IGMPv3 et MLDv2 pour le SSM
5. RFC 4607 — Source-Specific Multicast
6. RFC 7761 — PIM-SM
7. RFC 4541 — commutateurs avec écoute IGMP/MLD