Aller au contenu principal

2. Recommandations pour le snooping IGMP (IGMP Snooping Recommendations)

Les sections suivantes énumèrent les recommandations applicables à un commutateur pratiquant le snooping IGMP. La recommandation est énoncée, puis complétée par la description d'une approche d'implémentation possible. Toutes les discussions d'implémentation ne sont que des exemples et d'autres moyens d'obtenir la même fonctionnalité existent certainement.

2.1. Règles de transfert (Forwarding Rules)​

La fonctionnalité de snooping IGMP se divise en une partie de contrôle (transfert IGMP) et une partie de données (transfert de données).

2.1.1. Règles de transfert IGMP (IGMP Forwarding Rules)​

  1. Un commutateur pratiquant le snooping DEVRAIT (SHOULD) transférer les rapports d'appartenance IGMP uniquement vers les ports auxquels des routeurs multicast sont rattachés.

Autrement dit : un commutateur pratiquant le snooping NE DEVRAIT PAS (SHOULD NOT) transférer les rapports d'appartenance IGMP vers des ports auxquels seuls des hôtes sont rattachés. Un contrôle administratif peut être prévu pour passer outre cette restriction et permettre l'inondation des messages de rapport vers d'autres ports.

Il s'agit de la principale fonctionnalité de snooping IGMP pour le chemin de contrôle.

Pour IGMPv1 et IGMPv2, l'envoi de rapports d'appartenance à d'autres hôtes peut empêcher involontairement un hôte de rejoindre un groupe multicast donné. Lorsqu'un hôte IGMPv1 ou IGMPv2 reçoit un rapport d'appartenance pour une adresse de groupe qu'il a l'intention de rejoindre, il supprime son propre rapport d'appartenance pour ce même groupe. Cette suppression d'adhésion ou de message est une exigence pour les hôtes IGMPv1 et IGMPv2. Cependant, si le commutateur ne reçoit pas de rapport d'appartenance de l'hôte, il ne lui transférera pas de données multicast.

Ce n'est pas un problème dans un réseau composé uniquement d'IGMPv3, car il n'y a pas de suppression des rapports d'appartenance IGMP.

Le contrôle administratif permet aux messages de rapport d'appartenance IGMP d'être traités par des équipements de surveillance du réseau, tels que des analyseurs de paquets ou des réplicateurs de port.

Le commutateur prenant en charge le snooping IGMP DOIT (MUST) tenir à jour une liste des routeurs multicast et des ports auxquels ils sont rattachés. Cette liste peut être construite par n'importe quelle combinaison des moyens suivants :

  • a) Cette liste DEVRAIT (SHOULD) être construite par l'envoi, par le commutateur, de messages de sollicitation de routeur multicast (Multicast Router Solicitation) tels que décrits dans la découverte de routeurs multicast IGMP [MRDISC]. Il peut également espionner les messages d'annonce de routeur multicast (Multicast Router Advertisement) envoyés par et vers d'autres nœuds.

  • b) Le port d'arrivée des requêtes IGMP (envoyées par les routeurs multicast) dont l'adresse source n'est pas 0.0.0.0. L'adresse 0.0.0.0 représente un cas particulier où le commutateur relaie les requêtes IGMP pour accélérer la convergence du réseau, sans être lui-même le Querier. Le commutateur n'utilise pas sa propre adresse IP (même s'il en possède une), car cela ferait apparaître les requêtes comme provenant d'un Querier nouvellement élu. L'adresse 0.0.0.0 est utilisée pour indiquer que les paquets de requête ne proviennent PAS d'un routeur multicast.

  • c) Les ports explicitement configurés par la gestion comme ports de transfert IGMP, en complément ou à la place de l'une des méthodes ci-dessus de détection des ports de routeur.

  1. Les réseaux IGMP peuvent également comprendre des dispositifs mettant en œuvre le « rapport par procuration » (proxy-reporting), dans lequel les rapports reçus des hôtes en aval sont résumés et utilisés pour construire des états d'appartenance internes. Ces dispositifs peuvent utiliser l'adresse source IP entièrement nulle lors du transfert des rapports résumés vers l'amont. Pour cette raison, les rapports d'appartenance IGMP reçus par le commutateur NE DOIVENT PAS (MUST NOT) être rejetés au motif que l'adresse IP source vaut 0.0.0.0.

  2. Le commutateur prenant en charge le snooping IGMP DOIT (MUST) inonder tous les messages IGMP non reconnus vers tous les autres ports et NE DOIT PAS (MUST NOT) tenter d'utiliser des informations au-delà de la fin de l'en-tête de couche réseau.

De plus, les versions antérieures d'IGMP devraient interpréter les champs IGMP tels que définis pour leur version et NE DOIVENT PAS (MUST NOT) modifier ces champs lors du transfert du message. Lors de la génération de nouveaux messages, une version donnée d'IGMP devrait fixer les champs aux valeurs appropriées à sa propre version. Si des champs sont réservés ou non définis pour une version donnée d'IGMP, ils devraient être ignorés lors de l'analyse du message et DOIVENT (MUST) être mis à zéro lorsque de nouveaux messages sont générés par les implémentations de cette version. Une exception peut exister si le commutateur exécute une fonction d'usurpation (spoofing) et connaît les réglages des champs nouveaux ou réservés nécessaires pour usurper correctement une autre version d'IGMP.

La raison de s'intéresser à ces détails est qu'IGMPv3 réutilise l'ancien message de requête IGMP avec le même numéro de type (0x11) mais un en-tête étendu. Il existe donc un risque que des requêtes IGMPv3 soient interprétées comme des requêtes d'une version plus ancienne, par exemple par des commutateurs pratiquant le snooping IGMPv2. Cela a déjà été signalé [IETF56] et est discuté à la section 2.2.

  1. Un commutateur pratiquant le snooping IGMP DEVRAIT (SHOULD) être conscient des changements de topologie de couche liaison provoqués par le fonctionnement du spanning tree. Lorsqu'un port est activé ou désactivé par le spanning tree, une requête générale (General Query) peut être envoyée sur tous les ports actifs non routeurs afin de réduire le temps de convergence du réseau. Les commutateurs non Querier DEVRAIENT (SHOULD) savoir si le Querier est en mode IGMPv3. Si c'est le cas, le commutateur NE DEVRAIT PAS (SHOULD NOT) usurper de requêtes générales, sauf s'il est capable d'envoyer une requête IGMPv3 conforme aux informations les plus récentes envoyées par le véritable Querier. En aucun cas un commutateur ne doit introduire une requête IGMPv2 usurpée dans un réseau IGMPv3, car cela peut provoquer des perturbations réseau excessives.

Si le commutateur n'est pas le Querier, il DEVRAIT (SHOULD) utiliser l'adresse source IP « tout à zéro » dans ces requêtes mandatées (même si certains hôtes peuvent choisir de ne pas traiter les requêtes dont l'adresse source IP est 0.0.0.0). Lorsque de telles requêtes mandatées sont reçues, elles NE DOIVENT PAS (MUST NOT) être prises en compte dans le processus d'élection du Querier.

  1. Un commutateur pratiquant le snooping IGMP NE DOIT PAS (MUST NOT) utiliser les informations contenues dans les paquets IGMP dont les en-têtes IP ou IGMP présentent des erreurs de somme de contrôle ou d'intégrité. Le commutateur NE DEVRAIT PAS (SHOULD NOT) inonder de tels paquets ; s'il le fait néanmoins, il DEVRAIT (SHOULD) en garder une trace (par exemple en incrémentant un compteur). Ces erreurs et leur traitement sont discutés plus en détail dans [IGMPv3], [MLD] et [MLDv2].

  2. Le commutateur NE DOIT PAS (MUST NOT) se fier exclusivement à l'apparition d'annonces de départ de groupe IGMP (Group Leave) pour déterminer quand des entrées doivent être supprimées de la table de transfert. Il DEVRAIT (SHOULD) mettre en œuvre un mécanisme de temporisation d'appartenance, tel que la fonctionnalité côté routeur du protocole IGMP décrite dans les spécifications IGMP et MLD (voir la section des références normatives pour IGMPv1-3 et MLDv1-2), sur tous ses ports non routeurs. Cette valeur de temporisation DEVRAIT (SHOULD) être configurable.

2.1.2. Règles de transfert des données (Data Forwarding Rules)​

  1. Les paquets dont l'adresse IP de destination est en dehors de 224.0.0.X et qui ne sont pas IGMP DEVRAIENT (SHOULD) être transférés selon les tables d'appartenance de ports basées sur les groupes, et DOIVENT (MUST) également être transférés sur les ports de routeur.

Il s'agit de la principale fonctionnalité de snooping IGMP pour le chemin de données. Une approche possible consiste à tenir séparément en logiciel les tables d'appartenance et de routeurs multicast, puis à les « fusionner » dans un cache de transfert.

  1. Les paquets dont l'adresse IP de destination (DIP) est dans la plage 224.0.0.X et qui ne sont pas IGMP DOIVENT (MUST) être transférés sur tous les ports.

Cette recommandation repose sur le fait que de nombreux systèmes hôtes n'envoient pas de message d'adhésion (Join) pour les adresses multicast de cette plage avant d'envoyer ou d'écouter des paquets multicast IP. De plus, comme la plage 224.0.0.X est définie comme locale au lien (non routable), il semble inutile de conserver un état pour chaque adresse de cette plage. Enfin, certains routeurs fonctionnent dans la plage 224.0.0.X sans émettre de message Join IGMP, et ces applications seraient rompues si le commutateur les élaguait faute d'avoir vu un message Join Group provenant du routeur.

  1. Un paquet non enregistré est défini comme un paquet multicast IPv4 dont l'adresse de destination ne correspond à aucun des groupes annoncés dans des rapports d'appartenance IGMP antérieurs.

Si un commutateur reçoit un paquet non enregistré, il DOIT (MUST) transférer ce paquet sur tous les ports auxquels un routeur IGMP est rattaché. Un commutateur peut, par défaut, transférer les paquets non enregistrés sur tous les ports. Les commutateurs qui ne transfèrent pas les paquets non enregistrés vers tous les ports DOIVENT (MUST) proposer une option de configuration permettant de forcer l'inondation des paquets non enregistrés sur des ports spécifiés.

Dans un environnement où des hôtes IGMPv3 cohabitent avec des commutateurs de snooping qui ne prennent pas encore en charge IGMPv3, le fait que le commutateur n'inonde pas les flux non enregistrés peut empêcher les hôtes v3 de recevoir leur trafic. À l'inverse, dans un environnement où le commutateur prend en charge toutes les versions d'IGMP présentes, l'inondation des flux non enregistrés peut submerger les hôtes IGMP de trafic multicast, au point qu'ils ne reçoivent plus les requêtes et n'émettent plus de nouveaux rapports d'appartenance pour leurs propres groupes.

Il est encouragé que les commutateurs de snooping reconnaissent et traitent au moins les rapports d'adhésion IGMPv3, même si ce traitement se limite au comportement prévu pour les adhésions IGMPv2, c'est-à-dire sans tenir compte d'un filtrage supplémentaire « include source » ou « exclude source ». Lorsque les adhésions IGMPv3 ne sont pas reconnues, un commutateur peut élaguer à tort les flux de données non enregistrés de ces groupes (comme indiqué ci-dessus) ; ou bien il peut ne pas ajouter de transfert vers de nouveaux hôtes IGMPv3 si le groupe a déjà été rejoint en IGMPv2 (le flux de données étant considéré comme déjà enregistré).

  1. Tous les paquets multicast non IPv4 DEVRAIENT (SHOULD) continuer à être inondés vers tous les ports restants en état de transfert, conformément aux opérations de pontage IEEE normales.

Cette recommandation résulte du fait que les groupes composés d'hôtes IPv4 et ceux composés d'hôtes IPv6 sont totalement distincts. Par conséquent, les informations tirées de la topologie entre les membres d'un groupe IPv4 ne sont pas applicables pour former la topologie entre les membres d'un groupe IPv6.

  1. Les commutateurs de snooping IGMP peuvent tenir des tables de transfert basées sur les adresses MAC ou sur les adresses IP. Si un commutateur prend en charge les deux types de tables, le comportement par défaut DEVRAIT (SHOULD) être d'utiliser les adresses IP. Le transfert basé sur les adresses IP est préférable car la correspondance entre les adresses multicast IP et les adresses multicast de couche liaison est ambiguë. Dans le cas d'Ethernet, une adresse Ethernet correspond à 32 adresses IP [RFC1112].

  2. Les commutateurs qui s'appuient sur les informations de l'en-tête IP DEVRAIENT (SHOULD) vérifier que la somme de contrôle de l'en-tête IP est correcte. Si la somme de contrôle échoue, les informations du paquet NE DOIVENT PAS (MUST NOT) être intégrées à la table de transfert. En outre, le paquet DEVRAIT (SHOULD) être rejeté.

  3. Lorsque des rapports d'appartenance IGMPv3 « include source » et « exclude source » sont reçus sur des segments partagés, le commutateur doit transférer le sur-ensemble de tous les rapports d'appartenance reçus vers le segment partagé. Le transfert du trafic d'une source S donnée vers un groupe G DOIT (MUST) avoir lieu si au moins un hôte du segment partagé signale une appartenance IGMPv3 de type INCLUDE(G, Slist1) ou EXCLUDE(G, Slist2), où S est un élément de Slist1 et n'est pas un élément de Slist2.

La mise en œuvre pratique des tables de transfert basées sur (G,S1,S2,...) n'entre pas dans le cadre de ce document. Toutefois, une possibilité consiste à tenir deux listes de transfert (G,S) : l'une pour le filtre INCLUDE, où la correspondance d'un (G,S) particulier est nécessaire pour que le transfert ait lieu, et l'autre pour le filtre EXCLUDE, où la correspondance d'un (G,S) particulier entraîne l'absence de transfert.

Un problème particulier se pose dans les réseaux composés de routeurs IGMPv3 ainsi que d'hôtes IGMPv2 et IGMPv3 interconnectés par un commutateur de snooping IGMPv2, comme cela a été récemment signalé [IETF56]. Le routeur continuera de maintenir IGMPv3 même en présence d'hôtes IGMPv2, et le réseau ne convergera donc pas vers IGMPv2. Or il est probable que le commutateur de snooping IGMPv2 ne reconnaisse ni ne traite les rapports d'appartenance IGMPv3. Les groupes correspondant à ces rapports non reconnus seront alors soit inondés (avec tous les problèmes que cela peut créer pour les hôtes d'un réseau à fort trafic multicast), soit élagués par le commutateur.

Il est donc recommandé, dans un tel réseau, de configurer le routeur multicast pour utiliser IGMPv2. Si cela n'est pas possible, et si le commutateur ne peut pas reconnaître et traiter les rapports d'appartenance IGMPv3, il est recommandé de désactiver la fonctionnalité de snooping IGMP du commutateur, car il n'existe pas de solution claire à ce problème.