Résumé

  • En SSM, un canal est désigné par le couple formé de l'adresse source et du groupe, noté (S,G).
  • Deux émetteurs privés peuvent choisir le même groupe sans collision puisque leurs adresses sources privées sont différentes.
  • RFC 5135 exige qu'un NAT remplace l'adresse source privée par une adresse extérieure lorsque le trafic multicast sort.
  • Si les deux émetteurs reçoivent la même identité source publique, leurs couples privés distincts deviennent un même couple public.
  • Le récepteur peut alors observer un trafic entremêlé sans que l'acheminement ou l'état du proxy paraisse défaillant.
  • L'agrégation IGMPv3 est indispensable pour éviter une séquence amont incohérente lors de changements d'abonnement concurrents.
  • Cette agrégation protège la logique des adhésions ; elle ne recrée pas une identité source effacée par la traduction.
  • L'Endpoint-Independent Mapping rend la traduction prévisible entre destinations, mais ne garantit pas une source publique unique par émetteur privé.
  • RFC 5135 laisse la solution générale à l'étude et propose provisoirement que l'application permette de changer de groupe SSM.
  • Un changement de groupe n'est effectif que si la signalisation, les filtres, les caches et tous les récepteurs adoptent la nouvelle valeur.
  • Les identifiants RTP peuvent fournir une deuxième couche d'identité, à condition d'être produits, transmis, vérifiés et reliés au bon participant.
  • La preuve finale doit partir de la source privée, traverser le mapping et la publicité publique, puis atteindre la sélection réellement rendue au récepteur.

Le faux confort d'un état amont cohérent

Le proxy IGMP possède une mission difficile mais limitée. Plusieurs hôtes privés peuvent rejoindre et quitter un groupe sans coordonner le moment exact de leurs messages. Le proxy observe leurs états, les agrège, puis parle en amont comme un seul rapporteur. Ce travail empêche que les transitions indépendantes de plusieurs hôtes soient simplement intercalées dans une séquence qui n'aurait plus de sens pour le routeur extérieur.

RFC 5135 insiste sur ce point pour IGMPv3. Une arrivée et un départ presque simultanés peuvent, s'ils sont transmis naïvement, provoquer une période de trou noir. L'exigence de proxy protège donc une réalité opérationnelle : l'état collectif doit être calculé avant d'être annoncé. Une table qui montre le bon agrégat est une preuve utile et nécessaire.

Mais cette table ne décrit pas l'identité portée par chaque paquet de données après traduction. Elle indique les abonnements et les filtres de source que le proxy représente. Elle ne conserve pas, à l'usage du récepteur extérieur, la biographie privée de l'adresse source. Si le NAT remplace deux adresses internes par une même adresse externe, le fait que la demande amont soit correcte ne rend pas ces adresses de nouveau visibles.

C'est là que les audits rapides se trompent. Ils vérifient la version IGMP, la présence du groupe, l'état INCLUDE ou EXCLUDE, le compteur du mapping et le débit de sortie. Toutes ces observations peuvent être vraies. Aucune ne répond encore à la question : le récepteur extérieur peut-il distinguer l'émetteur privé qu'il voulait de l'autre émetteur qui a choisi le même groupe ?

Deux couples privés, un seul couple public

La sélection SSM repose sur un couple. Appelons les deux sources privées A et B, et le groupe G. À l'intérieur, (A,G) et (B,G) sont des canaux distincts. L'égalité de G ne pose pas de problème : la différence entre A et B suffit. Cette propriété permet à des applications de choisir le même groupe tout en conservant une sélection par source.

À la sortie, le NAT doit réécrire l'adresse source privée. Si A et B utilisent la même adresse extérieure N et si la destination multicast reste G, les paquets sont présentés sous (N,G). La distinction sur laquelle reposait SSM a été comprimée. Le récepteur n'a plus, au niveau IP, le fait qui séparait les deux canaux.

L'Appendice A de RFC 5135 ne masque pas ce résultat. Il explique que le trafic n'est plus identifiable de manière unique et que les flux peuvent s'entremêler. La formulation est importante : il ne s'agit pas d'affirmer que toute application affichera nécessairement un mélange. Une couche supérieure peut posséder une autre identité. Il s'agit d'établir que le couple public ne suffit plus à prouver la provenance privée.

Le NAT peut ainsi réussir exactement ce qu'il mesure. Il a traduit, mappé et transmis. Le routeur a peut-être acheminé. Le récepteur a reçu des paquets. Pourtant, l'identité utile à la consommation a pu être perdue. La disponibilité du chemin et l'intégrité de la sélection sont deux résultats différents.

Ce que la conformité encadre — et ce qu'elle ne promet pas

Publié en février 2008 comme BCP 135, RFC 5135 traite des NAT et NAPT IPv4 qui assurent un proxy IGMP pour l'ASM et le SSM. PIM-SM et IPv6 restent hors périmètre. Cette délimitation interdit d'utiliser le nom du document comme une garantie universelle pour tous les chemins multicast.

Dans le sens extérieur-vers-intérieur, le NAT ne doit modifier ni l'adresse multicast de destination ni le port de destination. Il doit transférer l'UDP multicast vers les récepteurs privés concernés et devrait aussi savoir transférer les autres protocoles. Dans le sens intérieur-vers-extérieur, il réécrit la source ; un NAPT peut aussi réécrire le port source et crée un mapping lorsque des réponses sont attendues.

L'Endpoint-Independent Mapping impose que le choix du mapping ne dépende pas de la destination unicast ou multicast. Le paired address pooling recommande, lorsqu'il existe plusieurs adresses publiques, qu'un même endpoint interne conserve la même adresse externe. Ces règles réduisent les surprises de traduction. Elles ne disent pas qu'un endpoint privé différent recevra nécessairement une identité publique différente.

Le transfert de l'UDP multicast sortant est requis, avec une option permettant de le désactiver. Cette option vise notamment les doublons qu'une architecture multihomée pourrait émettre par plusieurs chemins. Un doublon de chemin et un alias de source sont deux diagnostics. Dans le premier cas, un flux est reproduit. Dans le second, deux flux distincts perdent leur distinction.

Les limites de portée possèdent encore une autre fonction. Par défaut, le trafic administrativement limité de 239.0.0.0/8 ne doit pas être exporté, et le bloc de contrôle local 224.0.0.0/24 ne doit pas franchir l'interface extérieure. Un TTL égal à un peut également arrêter le paquet au premier routeur. Ces contrôles répondent à « jusqu'où ? », jamais automatiquement à « de qui ? ».

Le changement de groupe est une procédure, pas une preuve instantanée

Face à la collision SSM, le document propose une mesure provisoire : permettre à l'utilisateur de changer l'adresse de groupe. Si A emploie G1 et B emploie G2, la source publique N peut être commune sans rendre (N,G1) et (N,G2) identiques. La manœuvre est rationnelle, mais RFC 5135 laisse la résolution générale à des travaux ultérieurs.

Le mot « permettre » contient toute la limite. Une interface de configuration prouve qu'une option existe. Elle ne prouve pas qu'un opérateur a détecté la collision, choisi une valeur conforme à la portée attendue, publié une nouvelle description de session et amené chaque récepteur à abandonner l'ancien groupe. Les caches, listes d'autorisation, filtres, enregistreurs et systèmes de supervision doivent également suivre.

Il faut donc tracer une génération de configuration. Quel émetteur utilisait quel groupe, pendant quel intervalle ? Quelle description publique a été diffusée ? Quel récepteur l'a lue ? Quel abonnement effectif a-t-il créé ? Quand l'ancien canal a-t-il été drainé ? Sans ces reçus, le changement de groupe peut rester un acte symbolique dans une console.

L'identité applicative ne doit pas être présumée

RTP offre des identifiants tels que SSRC et CNAME qui peuvent aider une application à reconnaître des participants partageant une topologie traduite. RFC 5135 recommande une génération correcte du CNAME, notamment parce que les mêmes espaces privés RFC 1918 sont réutilisés dans d'innombrables réseaux. Cette couche peut préserver une distinction que l'adresse IP publique ne porte plus.

Elle ne le fait que si toute la chaîne fonctionne. L'émetteur produit l'identifiant ; les paquets et la signalisation le transportent ; le récepteur le vérifie ; la logique de collision l'interprète ; l'application relie enfin le résultat au participant attendu. Une collision SSRC est par ailleurs un problème applicatif différent de la fusion du couple SSM. Confondre les deux ferait perdre le lieu réel de la défaillance.

Pour l'ASM avec RTP, RFC 5135 aborde aussi la durée du mapping. Une recréation peut changer l'adresse de transport traduite et déclencher une détection de collision RTP. Le texte recommande une durée de 60 minutes et une destruction au départ du groupe, avec une réduction possible sous pression de ressources sans descendre sous le minimum de RFC 4787. Une entrée persistante prouve la continuité d'un état de traduction, non celle de l'expérience rendue.

Une chaîne de reçus sans raccourci

La première observation doit être faite avant le NAT : identité opérationnelle de l'émetteur, adresse privée, groupe choisi, génération de configuration et couple (S,G) réellement émis. Après coup, une capture publique ne permet pas de reconstituer sûrement cette pluralité.

À la frontière, il faut conserver le mapping, l'adresse extérieure, le port traduit le cas échéant, la décision de pooling et l'expiration. L'état IGMP doit rester un jeu de preuves séparé : version, membres en aval, filtres de source et agrégat annoncé en amont. Relier ces données est nécessaire ; les fusionner en un unique voyant « multicast OK » les rend inutiles.

À l'extérieur, l'organisation doit comparer le couple annoncé dans la description de session, le couple demandé par le récepteur et les paquets effectivement reçus. Elle doit détecter qu'un même couple public reçoit des contributions de plusieurs sources privées. Si l'application revendique une identité supplémentaire, la liaison entre cet identifiant et la sortie rendue doit être auditable.

Enfin, le récepteur doit fournir le reçu que le réseau ne peut fabriquer : source logique sélectionnée, paquets acceptés ou rejetés, présence d'un mélange, respect des contraintes temporelles, rendu ou action finale. C'est seulement là que l'acheminement devient une livraison conforme à l'intention.

Sources

  1. RFC 5135, HTML
  2. RFC 5135, texte brut
  3. Fiche RFC Editor de RFC 5135
  4. Fiche IETF Datatracker
  5. Historique du document
  6. Recherche d'errata RFC 5135
  7. RFC 4787
  8. RFC 4605
  9. RFC 3376
  10. RFC 4607
  11. RFC 5760
  12. RFC 3550
  13. RFC 2365
  14. RFC 5771
  15. RFC 1918
  16. RFC 8085
  17. Registre IANA des adresses multicast
  18. Registre IANA, XML
  19. Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption
  20. On Reality Layers, Symbolic Power, and Why Clarity Feels So Hostile
  21. Running-Code Primary