Résumé

  • RFC 3678 a conservé les appels d’adhésion multicast existants pour préserver leur compatibilité source et binaire, puis ajouté des options et fonctions de filtrage au lieu de modifier l’ancienne interface.
  • Un appel incrémental change une source dans le filtre courant. L’appel en état complet remplace ensemble le mode et la liste ; le texte le juge nécessaire pour changer de mode sans quitter le groupe, et utile aux longues listes grâce à une mise à jour atomique.

Le vieil appel ne pouvait pas être élargi

La première contrainte n’était pas un routeur : c’était le programme qui utilisait déjà la socket. Avant le filtrage par source, un récepteur multicast pouvait rejoindre un groupe et, si besoin, désigner une interface locale. Il indiquait ainsi une adhésion, sans préciser quels émetteurs accepter. Modifier l’appel établi pour y ajouter cette information aurait mis en péril sa compatibilité binaire : RFC 3678 dit explicitement que ces interfaces ne pouvaient pas changer sans casser les programmes existants.

Le mémo a donc choisi l’extension additive. Les nouveaux appels devaient préserver la compatibilité du code source — le vieux code se compile et fonctionne toujours — et la compatibilité binaire — un exécutable existant continue de tourner sur un système qui prend en charge l’extension. Il demandait aussi de limiter les changements et de permettre à l’application de détecter l’absence de ces API, afin qu’elle réagisse proprement. C’est un document d’information sur la conception d’API, pas la preuve que tous les systèmes d’exploitation ont implémenté les mêmes appels. RFC 3678

Une source à la fois

L’interface incrémentale modifie le filtre par étapes. Pour une adhésion multicast à toute source, le récepteur accepte d’abord les sources en général ; une opération de blocage ou de déblocage change le traitement d’un émetteur. En multicast à source spécifique, il ajoute ou retire une adresse de la liste souhaitée. L’état qui précède l’appel compte : le RFC distingue les combinaisons d’options et d’adhésions invalides du cas où la source est déjà bloquée ou n’a pas été rejointe.

Cette grammaire est économique lorsqu’une application ne doit effectuer qu’un petit changement. Elle peut dire « bloquer cette source » ou « rejoindre cette source » sans renvoyer toute la liste. Mais la signification dépend de l’état courant du filtre et de l’adhésion. Il s’agit d’un delta, pas d’une déclaration complète de l’état souhaité après l’appel. Le texte prévoit des options IPv4 comme IP_ADD_SOURCE_MEMBERSHIP et des options indépendantes du protocole comme MCAST_JOIN_SOURCE_GROUP. RFC 3678

Ou remplacer tout l’état

L’API en état complet a un autre rôle. L’application fournit le mode du filtre — MCAST_INCLUDE ou MCAST_EXCLUDE — et la liste entière à inclure ou exclure. L’appel remplace le filtre précédent au lieu d’appliquer une modification d’adhésion.

RFC 3678 précise deux cas où cette différence importe. Pour passer d’INCLUDE à EXCLUDE sans quitter le groupe, une application doit utiliser l’API en état complet. Elle est également conseillée pour les grandes listes, car l’ensemble peut changer atomiquement en un seul appel. Une suite de deltas pourrait aboutir au même résultat, mais elle décrit plusieurs modifications intermédiaires plutôt qu’un remplacement unique.

La lecture de l’état a son propre contrat : l’application peut estimer la taille du tampon, recevoir le nombre total de sources et répéter l’appel si le tampon était trop petit. Si l’implémentation impose une limite maximale, une liste qui la dépasse peut échouer avec ENOBUFS. « Tout remplacer » reste donc un outil de gestion d’état, pas une promesse de capacité illimitée. RFC 3678

Un groupe, deux familles d’adresses

Le mémo a gardé des structures et options propres à IPv4 pour réduire les changements requis dans les anciens programmes IPv4. Il a aussi défini des formes indépendantes du protocole. Elles transportent le groupe et la source dans des structures compatibles avec plusieurs familles d’adresses, tandis que l’index d’interface identifie séparément l’attachement local. RFC 3493 avait apporté une grande partie du vocabulaire socket d’IPv6, mais pas des opérations multicast d’adhésion et de départ indépendantes du protocole ; RFC 3678 comble cette lacune. RFC 3493

Cette séparation se perd facilement dans une signature de fonction : l’adresse du groupe nomme la destination multicast, celle de la source nomme un émetteur, et l’index d’interface limite l’opération à un attachement local. L’erratum technique vérifié 2524 a ensuite corrigé la description de l’argument de getsourcefilter, en section 5.2.2 : « adresse IP locale » devait devenir « index d’interface », comme dans la fonction de définition décrite juste avant. Un autre erratum vérifié corrige un renvoi erroné vers une section d’erreurs inexistante. Aucun ne change le modèle du filtre ; tous deux précisent la signification des arguments. Errata RFC 3678

Filtrer ici ne filtre pas partout

Le système d’exploitation peut filtrer localement même si les routeurs ne prennent pas en charge IGMPv3 ou MLDv2. L’application peut donc bénéficier d’un filtrage sur l’hôte sans démontrer que les paquets indésirables ont cessé de traverser le lien local. Les protocoles transmettent des informations de filtre vers un routeur : ce mécanisme réseau est distinct de l’appel socket et possède son propre état et son propre chemin. RFC 3376, RFC 3810 et RFC 4604 décrivent des éléments de ce comportement côté réseau. RFC 3376 RFC 3810 RFC 4604

Le filtrage n’authentifie pas non plus un émetteur. RFC 3678 avertit qu’il ne suffit pas contre un paquet dont l’adresse source est usurpée pour correspondre à une source autorisée ; les contrôles de chemin inverse peuvent aider dans certains routages, sans garantie. Le succès de l’appel socket témoigne d’une opération d’API, pas de l’état du routeur, d’une baisse de bande passante, de l’authenticité du trafic, de la réception des paquets ni du succès de l’application. RFC 3678

Le document est Informational et précise qu’il ne constitue pas une norme Internet ; il renvoie aussi à la spécification officielle des sockets. Son apport historique est plus précis : protéger les anciens appels d’adhésion, rendre peu coûteux un changement sur une seule source et garder la possibilité de remplacer tout le filtre d’un coup lorsque l’état ou l’échelle l’exigent. Les Notes 64 et 65 de Lu Heng, rédigées bien plus tard, servent ici de lentilles sur la compatibilité et l’adoption locale ; elles ne sont ni les auteurs, ni les approbateurs, ni la cause du mémo de 2004. Statut de RFC 3678 Note 64 Note 65

Sources