RFC 3376 - Internet Group Management Protocol, Version 3

Publié: October 2002
Met à jour: RFC2236
Remplacé par: RFC9776
Errata: Pas d'errata

Status of this Memo

Ce document spécifie un protocole de suivi des normes Internet pour la communauté Internet, et demande des discussions et des suggestions d'amélioration. Veuillez vous référer à l'édition actuelle des "Normes de protocole officielles d'Internet" (STD 1) pour l'état de normalisation et le statut de ce protocole. La distribution de ce mémo est illimitée.

Copyright Notice

Abstract

Ce document spécifie la version 3 du protocole de gestion de groupe Internet, IGMPv3. IGMP est le protocole utilisé par les systèmes IPv4 pour signaler leurs appartenances aux groupes de multidiffusion IP aux routeurs de multidiffusion voisins. La version 3 d'IGMP ajoute la prise en charge du "filtrage de source", c'est-à-dire la capacité pour un système de signaler son intérêt à recevoir des paquets uniquement à partir d'adresses source spécifiques, ou de tous sauf des adresses source spécifiques, envoyés à une adresse de multidiffusion particulière. Ces informations peuvent être utilisées par les protocoles de routage multicast pour éviter de délivrer des paquets multicast provenant de sources spécifiques vers des réseaux où il n'y a pas de récepteurs intéressés.

Ce document rend obsolète la RFC 2236.

1. Introduction

Le protocole de gestion de groupe Internet (IGMP) est utilisé par les systèmes IPv4 (hôtes et routeurs) pour signaler leur appartenance à des groupes de multidiffusion IP à tout routeur de multidiffusion voisin. Notez qu'un routeur de multidiffusion IP peut lui-même être membre d'un ou plusieurs groupes de multidiffusion, auquel cas il exécute à la fois la "partie routeur de multidiffusion" du protocole (pour collecter les informations d'appartenance nécessaires à son protocole de routage de multidiffusion) et la "partie membre du groupe" du protocole (pour s'informer lui-même et les autres routeurs de multidiffusion voisins de ses appartenances).

IGMP est également utilisé pour d'autres fonctions de gestion de multidiffusion IP, en utilisant des types de messages autres que ceux utilisés pour le signalement de l'appartenance au groupe. Ce document ne spécifie que les fonctions et les messages de signalement de l'appartenance au groupe.

Ce document spécifie la version 3 d'IGMP. La version 1, spécifiée dans [RFC-1112], a été la première version largement déployée et la première version à devenir une norme Internet. La version 2, spécifiée dans [RFC-2236], a ajouté la prise en charge d'une "faible latence de départ", c'est-à-dire une réduction du temps nécessaire à un routeur de multidiffusion pour apprendre qu'il n'y a plus de membres d'un groupe particulier présents sur un réseau connecté. La version 3 ajoute la prise en charge du "filtrage de source", c'est-à-dire la capacité pour un système de signaler son intérêt à recevoir des paquets uniquement à partir d'adresses source spécifiques, comme requis pour prendre en charge la multidiffusion spécifique à la source [SSM], ou à partir de tous sauf des adresses source spécifiques, envoyés à une adresse de multidiffusion particulière. La version 3 est conçue pour être interopérable avec les versions 1 et 2.

La découverte d'auditeur de multidiffusion (MLD) est utilisée de manière similaire par les systèmes IPv6. MLD version 1 [MLD] implémente les fonctionnalités d'IGMP version 2 ; MLD version 2 [MLDv2] implémente les fonctionnalités d'IGMP version 3.

Les mots-clés en majuscules "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" et "OPTIONAL" dans ce document doivent être interprétés comme décrit dans [RFC-2119]. En raison de l'absence d'italique, l'accentuation est indiquée ici en mettant un mot ou une phrase entre crochets de caractères "*".

2. The Service Interface for Requesting IP Multicast Reception (L'interface de service pour demander la réception de multidiffusion IP)

Au sein d'un système IP, il existe (au moins conceptuellement) une interface de service utilisée par les protocoles de couche supérieure ou les programmes d'application pour demander à la couche IP d'activer et de désactiver la réception de paquets envoyés à des adresses de multidiffusion IP spécifiques. Afin de tirer pleinement parti des capacités d'IGMPv3, l'interface de service IP d'un système doit prendre en charge l'opération suivante :

IPMulticastListen ( socket, interface, multicast-address,
                    filter-mode, source-list )

où :

"socket" est un paramètre spécifique à l'implémentation utilisé pour distinguer les différentes entités demandeuses (par exemple, programmes ou processus) au sein du système ; le paramètre socket des appels système BSD Unix est un exemple spécifique.
"interface" est un identifiant local de l'interface réseau sur laquelle la réception de l'adresse de multidiffusion spécifiée doit être activée ou désactivée. Les interfaces peuvent être physiques (par exemple, une interface Ethernet) ou virtuelles (par exemple, le point de terminaison d'un circuit virtuel Frame Relay ou le point de terminaison d'un "tunnel" IP-in-IP). Une implémentation peut permettre de passer une valeur spéciale "non spécifiée" comme paramètre d'interface, auquel cas la demande s'appliquerait à l'interface "primaire" ou "par défaut" du système (peut-être établie par la configuration du système). Si la réception de la même adresse de multidiffusion est souhaitée sur plus d'une interface, IPMulticastListen est invoqué séparément pour chaque interface souhaitée.
"multicast-address" est l'adresse de multidiffusion IP, ou groupe, à laquelle la demande se rapporte. Si la réception de plus d'une adresse de multidiffusion sur une interface donnée est souhaitée, IPMulticastListen est invoqué séparément pour chaque adresse de multidiffusion souhaitée.
"filter-mode" peut être soit INCLUDE, soit EXCLUDE. En mode INCLUDE, la réception des paquets envoyés à l'adresse de multidiffusion spécifiée est demandée uniquement à partir des adresses source IP répertoriées dans le paramètre source-list. En mode EXCLUDE, la réception des paquets envoyés à l'adresse de multidiffusion donnée est demandée à partir de toutes les adresses source IP sauf celles répertoriées dans le paramètre source-list.
"source-list" est une liste non ordonnée de zéro ou plusieurs adresses unicast IP à partir desquelles la réception de multidiffusion est souhaitée ou non, selon le mode de filtrage. Une implémentation PEUT imposer une limite à la taille des listes de sources, mais cette limite NE DOIT PAS être inférieure à 64 adresses par liste. Lorsqu'une opération entraîne le dépassement de la limite de taille de la liste de sources, l'interface de service DOIT renvoyer une erreur.

Pour une combinaison donnée de socket, d'interface et d'adresse de multidiffusion, un seul mode de filtrage et une seule liste de sources peuvent être en vigueur à un moment donné. Cependant, soit le mode de filtrage, soit la liste de sources, ou les deux, peuvent être modifiés par des demandes IPMulticastListen ultérieures qui spécifient le même socket, la même interface et la même adresse de multidiffusion. Chaque demande ultérieure remplace complètement toute demande antérieure pour le socket, l'interface et l'adresse de multidiffusion donnés.

Les versions précédentes d'IGMP ne prenaient pas en charge les filtres de source et avaient une interface de service plus simple consistant en des opérations Join et Leave pour activer et désactiver la réception d'une adresse de multidiffusion donnée (de toutes les sources) sur une interface donnée. Les opérations équivalentes dans la nouvelle interface de service suivent :

The Join operation is equivalent to

L'opération Join est équivalente à

IPMulticastListen ( socket, interface, multicast-address,
                    EXCLUDE, {} )

et l'opération Leave est équivalente à :

IPMulticastListen ( socket, interface, multicast-address,
                    INCLUDE, {} )

où {} est une liste de sources vide.

Un exemple d'API fournissant les capacités décrites dans cette interface de service se trouve dans [FILTER-API].

3. Multicast Reception State Maintained by Systems (État de réception multidiffusion maintenu par les systèmes)

3.1. Socket State (État du socket)

Pour chaque socket sur lequel IPMulticastListen a été invoqué, le système enregistre l'état de réception multidiffusion souhaité pour ce socket. Cet état consiste conceptuellement en un ensemble d'enregistrements de la forme :

(interface, multicast-address, filter-mode, source-list)

L'état du socket évolue en réponse à chaque invocation d'IPMulticastListen sur le socket, comme suit :

Si le mode de filtrage demandé est INCLUDE et que la liste de sources demandée est vide, alors l'entrée correspondant à l'interface et à l'adresse de multidiffusion demandées est supprimée si elle est présente. Si aucune entrée de ce type n'est présente, la demande est ignorée.
Si le mode de filtrage demandé est EXCLUDE ou que la liste de sources demandée n'est pas vide, alors l'entrée correspondant à l'interface et à l'adresse de multidiffusion demandées, si elle est présente, est modifiée pour contenir le mode de filtrage et la liste de sources demandés. Si aucune entrée de ce type n'est présente, une nouvelle entrée est créée, en utilisant les paramètres spécifiés dans la demande.

3.2. Interface State (État de l'interface)

En plus de l'état de réception multidiffusion par socket, un système doit également maintenir ou calculer l'état de réception multidiffusion pour chacune de ses interfaces. Cet état consiste conceptuellement en un ensemble d'enregistrements de la forme :

(multicast-address, filter-mode, source-list)

Il existe au plus un enregistrement par adresse de multidiffusion pour une interface donnée. Cet état par interface est dérivé de l'état par socket, mais peut différer de l'état par socket lorsque différents sockets ont des modes de filtrage et/ou des listes de sources différents pour la même adresse de multidiffusion et la même interface. Par exemple, supposons qu'une application ou un processus invoque l'opération suivante sur le socket s1 :

IPMulticastListen ( s1, i, m, INCLUDE, {a, b, c} )

demandant la réception sur l'interface i des paquets envoyés à l'adresse de multidiffusion m, uniquement s'ils proviennent de la source a, b ou c. Supposons qu'une autre application ou un autre processus invoque l'opération suivante sur le socket s2 :

IPMulticastListen ( s2, i, m, INCLUDE, {b, c, d} )

demandant la réception sur la même interface i des paquets envoyés à la même adresse de multidiffusion m, uniquement s'ils proviennent des sources b, c ou d. Afin de satisfaire les exigences de réception des deux sockets, il est nécessaire que l'interface i reçoive les paquets envoyés à m depuis l'une quelconque des sources a, b, c ou d. Ainsi, dans cet exemple, l'état de réception de l'interface i pour l'adresse de multidiffusion m a le mode de filtrage INCLUDE et la liste de sources {a, b, c, d}.

Une fois qu'un paquet multidiffusion a été accepté depuis une interface par la couche IP, sa livraison ultérieure à l'application ou au processus écoutant sur un socket particulier dépend de l'état de réception multidiffusion de ce socket [et éventuellement aussi d'autres conditions, telles que le port de la couche transport auquel le socket est lié]. Ainsi, dans l'exemple ci-dessus, si un paquet arrive sur l'interface i, destiné à l'adresse de multidiffusion m, avec l'adresse source a, il sera livré sur le socket s1 mais pas sur le socket s2. Notez que les requêtes et rapports IGMP ne sont pas soumis au filtrage de source et doivent toujours être traités par les hôtes et les routeurs.

Le filtrage des paquets basé sur l'état de réception multidiffusion d'un socket est une nouvelle fonctionnalité de cette interface de service. L'interface de service précédente [RFC1112] ne décrivait aucun filtrage basé sur l'état de jonction multidiffusion ; au contraire, une jonction sur un socket amenait simplement l'hôte à rejoindre un groupe sur l'interface donnée, et les paquets destinés à ce groupe pouvaient être livrés à tous les sockets, qu'ils aient rejoint ou non.

Les règles générales pour dériver l'état par interface à partir de l'état par socket sont les suivantes : Pour chaque paire distincte (interface, adresse de multidiffusion) qui apparaît dans un état de socket, un enregistrement par interface est créé pour cette adresse de multidiffusion sur cette interface. En considérant tous les enregistrements de socket contenant la même paire (interface, adresse de multidiffusion),

si un tel enregistrement a un mode de filtrage EXCLUDE, alors le mode de filtrage de l'enregistrement d'interface est EXCLUDE, et la liste de sources de l'enregistrement d'interface est l'intersection des listes de sources de tous les enregistrements de socket en mode EXCLUDE, moins les adresses sources qui apparaissent dans tout enregistrement de socket en mode INCLUDE. Par exemple, si les enregistrements de socket pour l'adresse de multidiffusion m sur l'interface i sont :

from socket s1:  ( i, m, EXCLUDE, {a, b, c, d} )
from socket s2:  ( i, m, EXCLUDE, {b, c, d, e} )
from socket s3:  ( i, m, INCLUDE, {d, e, f} )

alors l'enregistrement d'interface correspondant sur l'interface i est :

( m, EXCLUDE, {b, c} )

Si un quatrième socket est ajouté, tel que :

from socket s4:  ( i, m, EXCLUDE, {} )

( m, EXCLUDE, {} )

si tous ces enregistrements ont un mode de filtrage INCLUDE, alors le mode de filtrage de l'enregistrement d'interface est INCLUDE, et la liste de sources de l'enregistrement d'interface est l'union des listes de sources de tous les enregistrements de socket. Par exemple, si les enregistrements de socket pour l'adresse de multidiffusion m sur l'interface i sont :

from socket s1:  ( i, m, INCLUDE, {a, b, c} )
from socket s2:  ( i, m, INCLUDE, {b, c, d} )
from socket s3:  ( i, m, INCLUDE, {e, f} )

alors l'enregistrement d'interface correspondant sur l'interface i est :

( m, INCLUDE, {a, b, c, d, e, f} )

Une implémentation NE DOIT PAS utiliser un enregistrement d'interface EXCLUDE pour représenter un groupe lorsque tous les sockets de ce groupe sont à l'état INCLUDE. Si les limites des ressources système sont atteintes lors du calcul d'une liste de sources d'état d'interface, une erreur DOIT être renvoyée à l'application qui a demandé l'opération.

Les règles ci-dessus pour dériver l'état de l'interface sont (ré)évaluées chaque fois qu'une invocation IPMulticastListen modifie l'état du socket en ajoutant, supprimant ou modifiant un enregistrement d'état par socket. Notez qu'un changement d'état du socket n'entraîne pas nécessairement un changement d'état de l'interface.

4. Formats de messages

Les messages IGMP sont encapsulés dans des datagrammes IPv4, avec un numéro de protocole IP de 2. Chaque message IGMP décrit dans ce document est envoyé avec un IP Time-to-Live de 1, une IP Precedence de Internetwork Control (par exemple, Type of Service 0xc0), et porte une option IP Router Alert [RFC-2113] dans son en-tête IP. Les types de messages IGMP sont enregistrés par l'IANA [IANA-REG] comme décrit par [RFC-3228].

Il existe deux types de messages IGMP concernés par le protocole IGMPv3 décrit dans ce document:

Type Number (hex)	Message Name
0x11	Membership Query
0x22	Version 3 Membership Report

Une implémentation d'IGMPv3 DOIT également prendre en charge les trois types de messages suivants, pour l'interopération avec les versions précédentes d'IGMP (voir section 7):

Type Number (hex)	Message Name	Reference
0x12	Version 1 Membership Report	[RFC-1112]
0x16	Version 2 Membership Report	[RFC-2236]
0x17	Version 2 Leave Group	[RFC-2236]

Les types de messages non reconnus DOIVENT être ignorés silencieusement. D'autres types de messages peuvent être utilisés par des versions plus récentes ou des extensions d'IGMP, par des protocoles de routage multicast, ou pour d'autres usages.

Dans ce document, sauf qualification contraire, les mots capitalisés "Query" et "Report" se réfèrent respectivement aux IGMP Membership Queries et aux IGMP Version 3 Membership Reports.

4.1. Message Membership Query

Les Membership Queries sont envoyés par les routeurs multicast IP pour interroger l'état de réception multicast des interfaces voisines. Les Queries ont le format suivant:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Type = 0x11  | Max Resp Code |           Checksum            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Group Address                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Resv  |S| QRV |     QQIC      |     Number of Sources (N)     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Source Address [1]                      |
   +-                                                             -+
   |                       Source Address [2]                      |
   +-                              .                              -+
   .                               .                               .
   .                               .                               .
   +-                                                             -+
   |                       Source Address [N]                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

4.1.1. Max Resp Code

Le champ Max Resp Code spécifie le temps maximum autorisé avant l'envoi d'un rapport de réponse. Le temps réellement autorisé, appelé Max Resp Time, est représenté en unités de 1/10 de seconde et est dérivé du Max Resp Code comme suit:

Si Max Resp Code < 128, Max Resp Time = Max Resp Code

Si Max Resp Code >= 128, Max Resp Code représente une valeur à virgule flottante comme suit:

    0 1 2 3 4 5 6 7
   +-+-+-+-+-+-+-+-+
   |1| exp | mant  |
   +-+-+-+-+-+-+-+-+

Max Resp Time = (mant | 0x10) << (exp + 3)

Les petites valeurs de Max Resp Time permettent aux routeurs IGMPv3 d'ajuster la "latence de départ" (le temps entre le moment où le dernier hôte quitte un groupe et le moment où le protocole de routage est notifié qu'il n'y a plus de membres). Les valeurs plus grandes, en particulier dans la plage exponentielle, permettent d'ajuster le caractère en rafale du trafic IGMP sur un réseau.

4.1.2. Checksum

Le Checksum est le complément à un sur 16 bits de la somme en complément à un de l'ensemble du message IGMP (la charge utile IP complète). Pour calculer le checksum, le champ Checksum est mis à zéro. Lors de la réception de paquets, le checksum DOIT être vérifié avant de traiter un paquet. [RFC-1071]

4.1.3. Group Address

Le champ Group Address est mis à zéro lors de l'envoi d'une General Query, et mis à l'adresse multicast IP interrogée lors de l'envoi d'une Group-Specific Query ou Group-and-Source-Specific Query (voir section 4.1.9, ci-dessous).

4.1.4. Resv (Reserved)

Le champ Resv est mis à zéro à la transmission, et ignoré à la réception.

4.1.5. S Flag (Suppress Router-Side Processing)

Lorsqu'il est mis à un, le S Flag indique à tous les routeurs multicast receveurs qu'ils doivent supprimer les mises à jour de minuterie normales qu'ils effectuent lors de l'écoute d'une Query. Il ne supprime cependant pas l'élection du querier ou le traitement normal "côté hôte" d'une Query qu'un routeur peut être tenu d'effectuer en conséquence d'être lui-même un membre de groupe.

4.1.6. QRV (Querier's Robustness Variable)

S'il n'est pas nul, le champ QRV contient la valeur [Robustness Variable] utilisée par le querier, c'est-à-dire l'émetteur de la Query. Si la [Robustness Variable] du querier dépasse 7, la valeur maximale du champ QRV, le QRV est mis à zéro. Les routeurs adoptent la valeur QRV de la Query la plus récemment reçue comme leur propre valeur [Robustness Variable], sauf si ce QRV le plus récemment reçu était zéro, auquel cas les récepteurs utilisent la valeur [Robustness Variable] par défaut spécifiée dans la section 8.1 ou une valeur configurée statiquement.

4.1.7. QQIC (Querier's Query Interval Code)

Le champ Querier's Query Interval Code spécifie le [Query Interval] utilisé par le querier. L'intervalle réel, appelé Querier's Query Interval (QQI), est représenté en unités de secondes et est dérivé du Querier's Query Interval Code comme suit:

Si QQIC < 128, QQI = QQIC

Si QQIC >= 128, QQIC représente une valeur à virgule flottante comme suit:

    0 1 2 3 4 5 6 7
   +-+-+-+-+-+-+-+-+
   |1| exp | mant  |
   +-+-+-+-+-+-+-+-+

QQI = (mant | 0x10) << (exp + 3)

Les routeurs multicast qui ne sont pas le querier actuel adoptent la valeur QQI de la Query la plus récemment reçue comme leur propre valeur [Query Interval], sauf si ce QQI le plus récemment reçu était zéro, auquel cas les routeurs receveurs utilisent la valeur [Query Interval] par défaut spécifiée dans la section 8.2.

4.1.8. Number of Sources (N)

Le champ Number of Sources (N) spécifie combien d'adresses source sont présentes dans la Query. Ce nombre est zéro dans une General Query ou une Group-Specific Query, et non nul dans une Group-and-Source-Specific Query. Ce nombre est limité par la MTU du réseau sur lequel la Query est transmise. Par exemple, sur un Ethernet avec une MTU de 1500 octets, l'en-tête IP incluant l'option Router Alert consomme 24 octets, et les champs IGMP jusqu'au champ Number of Sources (N) inclus consomment 12 octets, laissant 1464 octets pour les adresses source, ce qui limite le nombre d'adresses source à 366 (1464/4).

4.1.9. Source Address [i]

Les champs Source Address [i] sont un vecteur de n adresses unicast IP, où n est la valeur dans le champ Number of Sources (N).

4.1.10. Additional Data

Si le champ Packet Length dans l'en-tête IP d'une Query reçue indique qu'il y a des octets de données supplémentaires présents, au-delà des champs décrits ici, les implémentations IGMPv3 DOIVENT inclure ces octets dans le calcul pour vérifier le Checksum IGMP reçu, mais DOIVENT autrement ignorer ces octets supplémentaires. Lors de l'envoi d'une Query, une implémentation IGMPv3 NE DOIT PAS inclure d'octets supplémentaires au-delà des champs décrits ici.

4.1.11. Variantes de Query

Il existe trois variantes du message Query:

Une "General Query" est envoyée par un routeur multicast pour connaître l'état complet de réception multicast des interfaces voisines (c'est-à-dire les interfaces attachées au réseau sur lequel la Query est transmise). Dans une General Query, le champ Group Address et le champ Number of Sources (N) sont tous deux zéro.
Une "Group-Specific Query" est envoyée par un routeur multicast pour connaître l'état de réception, par rapport à une seule adresse multicast, des interfaces voisines. Dans une Group-Specific Query, le champ Group Address contient l'adresse multicast d'intérêt, et le champ Number of Sources (N) contient zéro.
Une "Group-and-Source-Specific Query" est envoyée par un routeur multicast pour savoir si une interface voisine désire la réception de paquets envoyés à une adresse multicast spécifiée, provenant de l'une des sources d'une liste spécifiée. Dans une Group-and-Source-Specific Query, le champ Group Address contient l'adresse multicast d'intérêt, et les champs Source Address [i] contiennent la ou les adresses source d'intérêt.

4.1.12. Adresses de destination IP pour les Queries

Dans IGMPv3, les General Queries sont envoyées avec une adresse de destination IP de 224.0.0.1, l'adresse multicast all-systems. Les Group-Specific et Group-and-Source-Specific Queries sont envoyées avec une adresse de destination IP égale à l'adresse multicast d'intérêt. Cependant, un système DOIT accepter et traiter toute Query dont le champ IP Destination Address contient n'importe laquelle des adresses (unicast ou multicast) attribuées à l'interface sur laquelle la Query arrive.

4.2. Message Version 3 Membership Report

Les Version 3 Membership Reports sont envoyés par les systèmes IP pour signaler (aux routeurs voisins) l'état actuel de réception multicast, ou les changements dans l'état de réception multicast, de leurs interfaces. Les Reports ont le format suivant:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Type = 0x22  |    Reserved   |           Checksum            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Reserved            |  Number of Group Records (M)  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   .                                                               .
   .                        Group Record [1]                       .
   .                                                               .
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   .                                                               .
   .                        Group Record [2]                       .
   .                                                               .
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                               .                               |
   .                               .                               .
   |                               .                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   .                                                               .
   .                        Group Record [M]                       .
   .                                                               .
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

où chaque Group Record a le format interne suivant:

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Record Type  |  Aux Data Len |     Number of Sources (N)     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Multicast Address                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Source Address [1]                      |
   +-                                                             -+
   |                       Source Address [2]                      |
   +-                                                             -+
   .                               .                               .
   .                               .                               .
   .                               .                               .
   +-                                                             -+
   |                       Source Address [N]                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   .                                                               .
   .                         Auxiliary Data                        .
   .                                                               .
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

4.2.1. Reserved

Les champs Reserved sont mis à zéro à la transmission, et ignorés à la réception.

4.2.2. Checksum

4.2.3. Number of Group Records (M)

Le champ Number of Group Records (M) spécifie combien de Group Records sont présents dans ce Report.

4.2.4. Group Record

Chaque Group Record est un bloc de champs contenant des informations relatives à l'appartenance de l'émetteur à un seul groupe multicast sur l'interface à partir de laquelle le Report est envoyé.

4.2.5. Record Type

Voir section 4.2.12, ci-dessous.

4.2.6. Aux Data Len

Le champ Aux Data Len contient la longueur du champ Auxiliary Data dans ce Group Record, en unités de mots de 32 bits. Il peut contenir zéro, pour indiquer l'absence de données auxiliaires.

4.2.7. Number of Sources (N)

Le champ Number of Sources (N) spécifie combien d'adresses source sont présentes dans ce Group Record.

4.2.8. Multicast Address

Le champ Multicast Address contient l'adresse multicast IP à laquelle ce Group Record se rapporte.

4.2.9. Source Address [i]

Les champs Source Address [i] sont un vecteur de n adresses unicast IP, où n est la valeur dans le champ Number of Sources (N) de cet enregistrement.

4.2.10. Auxiliary Data

Le champ Auxiliary Data, s'il est présent, contient des informations supplémentaires relatives à ce Group Record. Le protocole spécifié dans ce document, IGMPv3, ne définit aucune donnée auxiliaire. Par conséquent, les implémentations d'IGMPv3 NE DOIVENT PAS inclure de données auxiliaires (c'est-à-dire DOIVENT mettre le champ Aux Data Len à zéro) dans tout Group Record transmis, et DOIVENT ignorer toute donnée auxiliaire présente dans tout Group Record reçu. La sémantique et l'encodage interne du champ Auxiliary Data doivent être définis par toute version future ou extension d'IGMP qui utilise ce champ.

4.2.11. Additional Data

Si le champ Packet Length dans l'en-tête IP d'un Report reçu indique qu'il y a des octets de données supplémentaires présents, au-delà du dernier Group Record, les implémentations IGMPv3 DOIVENT inclure ces octets dans le calcul pour vérifier le Checksum IGMP reçu, mais DOIVENT autrement ignorer ces octets supplémentaires. Lors de l'envoi d'un Report, une implémentation IGMPv3 NE DOIT PAS inclure d'octets supplémentaires au-delà du dernier Group Record.

4.2.12. Types de Group Record

Il existe plusieurs types différents de Group Records qui peuvent être inclus dans un message Report:

Un "Current-State Record" est envoyé par un système en réponse à une Query reçue sur une interface. Il signale l'état de réception actuel de cette interface, par rapport à une seule adresse multicast. Le Record Type d'un Current-State Record peut être l'une des deux valeurs suivantes:

Value	Name and Meaning
1	MODE_IS_INCLUDE - indique que l'interface a un mode de filtre INCLUDE pour l'adresse multicast spécifiée. Les champs Source Address [i] dans ce Group Record contiennent la liste source de l'interface pour l'adresse multicast spécifiée, si elle n'est pas vide.
2	MODE_IS_EXCLUDE - indique que l'interface a un mode de filtre EXCLUDE pour l'adresse multicast spécifiée. Les champs Source Address [i] dans ce Group Record contiennent la liste source de l'interface pour l'adresse multicast spécifiée, si elle n'est pas vide.

Un "Filter-Mode-Change Record" est envoyé par un système chaque fois qu'une invocation locale d'IPMulticastListen provoque un changement du mode de filtre (c'est-à-dire un changement de INCLUDE à EXCLUDE, ou de EXCLUDE à INCLUDE), de l'entrée d'état au niveau de l'interface pour une adresse multicast particulière. Le Record est inclus dans un Report envoyé depuis l'interface sur laquelle le changement s'est produit. Le Record Type d'un Filter-Mode-Change Record peut être l'une des deux valeurs suivantes:

Value	Name and Meaning
3	CHANGE_TO_INCLUDE_MODE - indique que l'interface est passée en mode de filtre INCLUDE pour l'adresse multicast spécifiée. Les champs Source Address [i] dans ce Group Record contiennent la nouvelle liste source de l'interface pour l'adresse multicast spécifiée, si elle n'est pas vide.
4	CHANGE_TO_EXCLUDE_MODE - indique que l'interface est passée en mode de filtre EXCLUDE pour l'adresse multicast spécifiée. Les champs Source Address [i] dans ce Group Record contiennent la nouvelle liste source de l'interface pour l'adresse multicast spécifiée, si elle n'est pas vide.

Un "Source-List-Change Record" est envoyé par un système chaque fois qu'une invocation locale d'IPMulticastListen provoque un changement de liste source qui n'est pas coïncident avec un changement de mode de filtre, de l'entrée d'état au niveau de l'interface pour une adresse multicast particulière. Le Record est inclus dans un Report envoyé depuis l'interface sur laquelle le changement s'est produit. Le Record Type d'un Source-List-Change Record peut être l'une des deux valeurs suivantes:

Value	Name and Meaning
5	ALLOW_NEW_SOURCES - indique que les champs Source Address [i] dans ce Group Record contiennent une liste des sources supplémentaires que le système souhaite entendre, pour les paquets envoyés à l'adresse multicast spécifiée. Si le changement concernait une liste source INCLUDE, ce sont les adresses qui ont été ajoutées à la liste; si le changement concernait une liste source EXCLUDE, ce sont les adresses qui ont été supprimées de la liste.
6	BLOCK_OLD_SOURCES - indique que les champs Source Address [i] dans ce Group Record contiennent une liste des sources que le système ne souhaite plus entendre, pour les paquets envoyés à l'adresse multicast spécifiée. Si le changement concernait une liste source INCLUDE, ce sont les adresses qui ont été supprimées de la liste; si le changement concernait une liste source EXCLUDE, ce sont les adresses qui ont été ajoutées à la liste.

Value

Name and Meaning

ALLOW_NEW_SOURCES - indique que les champs Source Address [i] dans ce Group Record contiennent une liste des sources supplémentaires que le système souhaite entendre, pour les paquets envoyés à l'adresse multicast spécifiée. Si le changement concernait une liste source INCLUDE, ce sont les adresses qui ont été ajoutées à la liste; si le changement concernait une liste source EXCLUDE, ce sont les adresses qui ont été supprimées de la liste.

BLOCK_OLD_SOURCES - indique que les champs Source Address [i] dans ce Group Record contiennent une liste des sources que le système ne souhaite plus entendre, pour les paquets envoyés à l'adresse multicast spécifiée. Si le changement concernait une liste source INCLUDE, ce sont les adresses qui ont été supprimées de la liste; si le changement concernait une liste source EXCLUDE, ce sont les adresses qui ont été ajoutées à la liste.

Si un changement de liste source entraîne à la fois l'autorisation de nouvelles sources et le blocage d'anciennes sources, deux Group Records sont envoyés pour la même adresse multicast, l'un de type ALLOW_NEW_SOURCES et l'un de type BLOCK_OLD_SOURCES.

Nous utilisons le terme "State-Change Record" pour désigner soit un Filter-Mode-Change Record, soit un Source-List-Change Record.

Les valeurs de Record Type non reconnues DOIVENT être ignorées silencieusement.

4.2.13. Adresses source IP pour les Reports

Un rapport IGMP est envoyé avec une adresse source IP valide pour le sous-réseau de destination. L'adresse source 0.0.0.0 peut être utilisée par un système qui n'a pas encore acquis d'adresse IP. Notez que l'adresse source 0.0.0.0 peut être utilisée simultanément par plusieurs systèmes sur un LAN. Les routeurs DOIVENT accepter un rapport avec une adresse source de 0.0.0.0.

4.2.14. Adresses de destination IP pour les Reports

Les Version 3 Reports sont envoyés avec une adresse de destination IP de 224.0.0.22, à laquelle tous les routeurs multicast compatibles IGMPv3 écoutent. Un système fonctionnant en mode de compatibilité version 1 ou version 2 envoie des Reports version 1 ou version 2 au groupe multicast spécifié dans le champ Group Address du Report. De plus, un système DOIT accepter et traiter tout Report version 1 ou version 2 dont le champ IP Destination Address contient n'importe laquelle des adresses (unicast ou multicast) attribuées à l'interface sur laquelle le Report arrive.

4.2.15. Notation pour les Group Records

Dans le reste de ce document, nous utilisons la notation suivante pour décrire le contenu d'un Group Record se rapportant à une adresse multicast particulière:

   IS_IN ( x )  -  Type MODE_IS_INCLUDE, source addresses x
   IS_EX ( x )  -  Type MODE_IS_EXCLUDE, source addresses x
   TO_IN ( x )  -  Type CHANGE_TO_INCLUDE_MODE, source addresses x
   TO_EX ( x )  -  Type CHANGE_TO_EXCLUDE_MODE, source addresses x
   ALLOW ( x )  -  Type ALLOW_NEW_SOURCES, source addresses x
   BLOCK ( x )  -  Type BLOCK_OLD_SOURCES, source addresses x

où x est soit:

une lettre majuscule (par exemple, "A") pour représenter l'ensemble des adresses source, ou
une expression d'ensemble (par exemple, "A+B"), où "A+B" signifie l'union des ensembles A et B, "A*B" signifie l'intersection des ensembles A et B, et "A-B" signifie la suppression de tous les éléments de l'ensemble B de l'ensemble A.

4.2.16. Taille du Membership Report

Si l'ensemble des Group Records requis dans un Report ne rentre pas dans la limite de taille d'un seul message Report (tel que déterminé par la MTU du réseau sur lequel il sera envoyé), les Group Records sont envoyés dans autant de messages Report que nécessaire pour signaler l'ensemble complet.

Si un seul Group Record contient tant d'adresses source qu'il ne rentre pas dans la limite de taille d'un seul message Report, si son Type n'est pas MODE_IS_EXCLUDE ou CHANGE_TO_EXCLUDE_MODE, il est divisé en plusieurs Group Records, chacun contenant un sous-ensemble différent des adresses source et chacun envoyé dans un message Report séparé. Si son Type est MODE_IS_EXCLUDE ou CHANGE_TO_EXCLUDE_MODE, un seul Group Record est envoyé, contenant autant d'adresses source que possible, et les adresses source restantes ne sont pas signalées; bien que le choix des sources à signaler soit arbitraire, il est préférable de signaler le même ensemble de sources dans chaque rapport ultérieur, plutôt que de signaler des sources différentes à chaque fois.

5. Description du protocole pour les membres de groupe

IGMP est un protocole asymétrique, spécifiant des comportements différents pour les membres de groupe (hôtes ou routeurs qui souhaitent recevoir des paquets multicast) et les routeurs multicast (qui écoutent les messages IGMP et coordonnent le transfert multicast). Cette section décrit la partie d'IGMPv3 qui s'applique aux membres de groupe. (Notez qu'un routeur peut également être un membre de groupe.)

Un système exécute le protocole décrit dans cette section sur chaque interface sur laquelle la réception multicast est prise en charge. Le protocole sur chaque interface implique le traitement immédiat de deux types d'événements:

Un changement de l'état de réception multicast sur l'interface, causé par une invocation locale de la définition IPMulticastListen.
Réception d'un message Membership Query.

5.1. Action lors d'un changement d'état d'interface

Une invocation d'IPMulticastListen peut entraîner un changement de l'état de réception multicast d'une interface, selon les règles de la section 3.2. Chaque tel changement affecte l'état par interface pour une seule adresse de groupe multicast.

Un changement d'état d'interface amène le système à transmettre immédiatement un State Change Report depuis cette interface. Le type et le contenu du State Change Report sont déterminés comme suit:

Si le changement d'état n'est pas significatif, tel que le mode de filtre pour un groupe passant de INCLUDE à INCLUDE ou de EXCLUDE à EXCLUDE, avec l'ensemble des adresses source restant inchangé, aucun rapport n'est généré.
Si le changement d'état est significatif, un State Change Report est généré. Le Report contient un seul Group Record pour le groupe dont l'état a changé. Le type et le contenu du Group Record sont déterminés en comparant l'Old State (l'état avant le changement) avec le New State (l'état après le changement), comme indiqué dans le tableau suivant:

Old State New State State Change Record Sent
INCLUDE (A) INCLUDE (B) ALLOW (B-A), BLOCK (A-B)
EXCLUDE (A) EXCLUDE (B) ALLOW (A-B), BLOCK (B-A)
INCLUDE (A) EXCLUDE (B) TO_EX (B)
EXCLUDE (A) INCLUDE (B) TO_IN (B)

La notation "ALLOW (B-A)" signifie que le State Change Record porte une liste source contenant toutes les adresses source qui sont dans l'ensemble B mais pas dans l'ensemble A. La notation "BLOCK (A-B)" signifie que le State Change Record porte une liste source contenant toutes les adresses source qui sont dans l'ensemble A mais pas dans l'ensemble B.

Si la liste source calculée pour un enregistrement ALLOW ou BLOCK est vide, cet enregistrement est omis du State Change Report.

Old State	New State	State Change Record Sent
INCLUDE (A)	INCLUDE (B)	ALLOW (B-A), BLOCK (A-B)
EXCLUDE (A)	EXCLUDE (B)	ALLOW (A-B), BLOCK (B-A)
INCLUDE (A)	EXCLUDE (B)	TO_EX (B)
EXCLUDE (A)	INCLUDE (B)	TO_IN (B)

Pour garantir que le State Change Report est reçu par tous les routeurs multicast du réseau, le système retransmet le Report [Robustness Variable] - 1 fois, à des intervalles aléatoires choisis dans la plage (0, [Unsolicited Report Interval]). La [Robustness Variable] est un paramètre ajustable, par défaut à 2. L'[Unsolicited Report Interval] est également un paramètre ajustable, par défaut à 10 secondes.

Si un State Change Report est programmé pour transmission, et qu'une Query est reçue qui provoquerait la génération d'un Current State Report (voir section 5.2), le State Change Report en attente est abandonné et le Current State Report est envoyé à la place. Le Current State Report doit contenir toutes les informations qui auraient été dans le State Change Report.

5.2. Action lors de la réception d'une Query

Lorsqu'un système reçoit une Query, il vérifie d'abord si la Query est valide. Pour être valide, la Query doit:

avoir au moins 12 octets de long,
avoir un checksum IP correct,
avoir une adresse IP de destination égale à l'adresse multicast all-systems (224.0.0.1) ou à l'adresse de groupe spécifique interrogée.

Si la Query n'est pas valide, elle est ignorée. Si la Query est valide, le système effectue les actions suivantes:

Il met à jour son minuteur pour le Querier, si nécessaire (voir section 6).
Il détermine s'il doit répondre à la Query.

Les sous-sections suivantes décrivent les règles pour répondre à différents types de Queries.

5.2.1. Action lors de la réception d'une General Query

Lors de la réception d'une General Query, le système vérifie chaque interface pour voir s'il existe un état de réception multicast pour un groupe. Pour chaque groupe pour lequel il existe un état, le système programme l'envoi d'un Current State Report.

Le Report contient un Group Record pour le groupe. Le type du Group Record est MODE_IS_INCLUDE si le mode de filtre pour le groupe est INCLUDE, et MODE_IS_EXCLUDE si le mode de filtre est EXCLUDE. La liste source dans le Group Record contient l'ensemble des adresses source pour le groupe.

Le Report est programmé pour être envoyé à un moment aléatoire choisi dans la plage (0, [Max Resp Time]), où [Max Resp Time] est la valeur spécifiée dans le champ Max Resp Code de la Query.

5.2.2. Action lors de la réception d'une Group-Specific Query

Lors de la réception d'une Group-Specific Query, le système vérifie s'il a un état de réception multicast pour l'adresse de groupe spécifiée dans la Query. Si ce n'est pas le cas, il ignore la Query.

S'il existe un état pour le groupe, le système programme l'envoi d'un Current State Report. Le Report contient un Group Record pour le groupe, construit comme décrit dans la section 5.2.1.

Le Report est programmé pour être envoyé à un moment aléatoire choisi dans la plage (0, [Max Resp Time]).

5.2.3. Action lors de la réception d'une Group-and-Source-Specific Query

Lors de la réception d'une Group-and-Source-Specific Query, le système vérifie s'il a un état de réception multicast pour l'adresse de groupe spécifiée dans la Query. Si ce n'est pas le cas, il ignore la Query.

S'il existe un état pour le groupe, le système détermine s'il est intéressé par l'une des adresses source spécifiées dans la Query. Le système est intéressé par une adresse source si:

Le mode de filtre pour le groupe est EXCLUDE, OU
Le mode de filtre pour le groupe est INCLUDE et l'adresse source est dans la liste source.

Si le système est intéressé par au moins une des adresses source, il programme l'envoi d'un Current State Report. Le Report contient un Group Record pour le groupe, construit comme décrit dans la section 5.2.1.

Le Report est programmé pour être envoyé à un moment aléatoire choisi dans la plage (0, [Max Resp Time]).

5.2.4. Action lors de la réception d'une Query avec le flag "S" activé

Si le flag "S" (Suppress Router-Side Processing) est activé dans une Query reçue, le système ne met pas à jour son minuteur pour le Querier. Cependant, il répond toujours à la Query comme décrit dans les sections 5.2.1 à 5.2.3.

6. Protocole pour les routeurs multicast

Le but d'IGMP est de permettre à chaque routeur multicast d'apprendre, pour chacun de ses réseaux directement attachés, quelles adresses multicast ont des auditeurs sur ce réseau. IGMPv3 permet également à un routeur multicast d'apprendre quelles sources intéressent les auditeurs.

6.1. Conditions pour l'élection du Querier

IGMPv3 s'accorde avec IGMPv2 sur le fait qu'il ne devrait y avoir qu'un seul Querier par réseau. Cependant, les Queriers IGMPv3 et IGMPv2 peuvent coexister sur le même réseau. Le protocole d'élection est le même que dans IGMPv2:

Initialement, chaque routeur multicast démarre en tant que Querier sur chacun de ses réseaux attachés.
Si un routeur multicast entend un message Query d'un routeur avec une adresse IP inférieure, il doit devenir un Non-Querier sur ce réseau.
Si un routeur multicast n'a pas entendu de message Query d'un routeur avec une adresse IP inférieure pendant [Other Querier Present Interval], il reprend le rôle de Querier.

6.2. Action du Querier lors de la réception d'une Query

Lorsqu'un Querier reçoit un message Query, il vérifie l'adresse IP source de la Query.

Si l'adresse IP source est inférieure à sa propre adresse IP, le routeur devient un Non-Querier.
Si l'adresse IP source est supérieure à sa propre adresse IP, le routeur continue d'être le Querier.
Si l'adresse IP source est égale à sa propre adresse IP, la Query est ignorée (c'est une réflexion ou une boucle).

6.3. Envoi de Queries

Le Querier envoie périodiquement des General Queries pour solliciter des informations d'appartenance. Il envoie également des Group-Specific ou Group-and-Source-Specific Queries lorsqu'il reçoit certains types de State Change Reports.

6.3.1. General Queries

Le Querier envoie périodiquement des General Queries à l'adresse multicast all-systems (224.0.0.1). L'[Query Interval] par défaut est de 125 secondes.

Les General Queries sont utilisées pour rafraîchir les informations d'appartenance pour tous les groupes et sources.

6.3.2. Group-Specific Queries

Lorsque le Querier reçoit un State Change Report indiquant qu'un système a quitté un groupe (par exemple, un changement de mode de filtre de EXCLUDE à INCLUDE, ou un changement de liste source bloquant une source), il envoie une Group-Specific Query à l'adresse du groupe.

Cette Query est utilisée pour déterminer s'il reste des systèmes intéressés par le groupe.

6.3.3. Group-and-Source-Specific Queries

Lorsque le Querier reçoit un State Change Report indiquant qu'un système n'est plus intéressé par des sources spécifiques pour un groupe (par exemple, bloquer des sources spécifiques), il envoie une Group-and-Source-Specific Query.

Cette Query est utilisée pour déterminer s'il reste des systèmes intéressés par ces sources spécifiques.

6.4. Réception de Reports

Les routeurs multicast enregistrent l'état de réception pour chaque groupe et source en fonction des Reports qu'ils reçoivent. L'état est maintenu par interface.

6.4.1. Réception de Current State Records

Lorsqu'un routeur reçoit un Current State Record, il met à jour ses minuteurs de groupe/source.

Si l'enregistrement est MODE_IS_INCLUDE, le routeur rafraîchit les minuteurs pour les sources listées.
Si l'enregistrement est MODE_IS_EXCLUDE, le routeur rafraîchit le minuteur de groupe et les minuteurs pour les sources exclues (le cas échéant).

6.4.2. Réception de Filter-Mode-Change Records

Lorsqu'un routeur reçoit un Filter-Mode-Change Record, il met à jour le mode de filtre et les minuteurs.

CHANGE_TO_INCLUDE_MODE: Le routeur passe en mode INCLUDE s'il ne l'était pas déjà, et met à jour les minuteurs source.
CHANGE_TO_EXCLUDE_MODE: Le routeur passe en mode EXCLUDE et met à jour le minuteur de groupe.

6.4.3. Réception de Source-List-Change Records

Lorsqu'un routeur reçoit un Source-List-Change Record, il met à jour les minuteurs source.

ALLOW_NEW_SOURCES: Le routeur ajoute les nouvelles sources à sa liste et démarre leurs minuteurs.
BLOCK_OLD_SOURCES: Le routeur peut interroger pour voir si d'autres systèmes ont encore besoin de ces sources avant de les supprimer.

6.5. Commutation du mode de filtre du routeur

Le mode de filtre du routeur pour un groupe passe entre INCLUDE et EXCLUDE en fonction de l'état du minuteur de groupe et des minuteurs source.

Si le minuteur de groupe est en cours d'exécution, le mode de filtre est EXCLUDE.
Si le minuteur de groupe expire, le mode de filtre passe à INCLUDE.

6.6. Action lors de la réception d'un message Group Leave (IGMPv2)

Si un routeur reçoit un message IGMPv2 Leave Group, il agit comme s'il avait reçu un State Change Report indiquant un changement vers le mode INCLUDE (quitter effectivement le groupe) pour le groupe spécifié dans le message Leave. Cela permet aux routeurs IGMPv3 d'interopérer avec les hôtes IGMPv2.

7. Interopération avec IGMPv1 et IGMPv2

Les hôtes et routeurs IGMPv3 interopèrent avec les hôtes et routeurs qui n'ont pas encore été mis à niveau vers IGMPv3. Cette compatibilité est maintenue par les messages Membership Query périodiques qui sont diffusés par le Querier, et par les messages Membership Report Version 1 et Version 2 qui sont diffusés par les hôtes plus anciens.

7.1. Fonctionnement de l'hôte IGMPv3

Le comportement d'un hôte IGMPv3 dépend de si le Querier sur le réseau parle IGMPv3, IGMPv2 ou IGMPv1.

7.1.1. Distinctions de version de Query

La version IGMP d'un message Membership Query est déterminée comme suit:

7.1.2. Comportement en présence de Queriers plus anciens

Un hôte IGMPv3 peut être placé sur un réseau où le Querier n'a pas encore été mis à niveau vers IGMPv3. L'hôte doit tenir compte de cette possibilité.

IGMPv1 Querier Present: Si un hôte IGMPv3 reçoit une Query IGMPv1, il doit répondre avec des Reports IGMPv1. Le filtrage de source n'est pas pris en charge.
IGMPv2 Querier Present: Si un hôte IGMPv3 reçoit une Query IGMPv2, il doit répondre avec des Reports IGMPv2. Le filtrage de source n'est pas pris en charge.
IGMPv3 Querier Present: Si un hôte IGMPv3 reçoit une Query IGMPv3, il répond avec des Reports IGMPv3. Le filtrage de source est pris en charge.

L'hôte maintient une variable de mode de compatibilité pour chaque interface, qui est mise à jour chaque fois qu'une Query est reçue. Si une Query plus ancienne est reçue, l'hôte passe au mode de compatibilité correspondant et définit un minuteur. Lorsque le minuteur expire, l'hôte revient en mode IGMPv3.

7.2. Fonctionnement du routeur IGMPv3

Le comportement d'un routeur IGMPv3 dépend de la présence d'hôtes ou de routeurs plus anciens sur le réseau.

7.2.1. Présence d'hôtes plus anciens

Un routeur IGMPv3 peut recevoir des Reports IGMPv1 ou IGMPv2 d'hôtes plus anciens.

IGMPv1 Report Received: Le routeur agit comme s'il avait reçu un rapport IGMPv3 IS_EX({}) pour le groupe. Il doit également ignorer tous les messages Leave Group pour ce groupe (puisque IGMPv1 n'a pas de messages Leave).
IGMPv2 Report Received: Le routeur agit comme s'il avait reçu un rapport IGMPv3 IS_EX({}) pour le groupe.

Lorsque des hôtes plus anciens sont présents, le routeur peut avoir besoin de supprimer le traitement spécifique à IGMPv3 (comme les requêtes spécifiques à la source) pour les groupes affectés afin d'assurer la compatibilité.

7.2.2. Présence de routeurs plus anciens

Si un routeur IGMPv3 se trouve sur un réseau avec des routeurs plus anciens, le processus d'élection du Querier (Section 6.1) détermine quel routeur devient le Querier.

Si un routeur IGMPv1 est présent et devient le Querier, tous les routeurs (y compris les routeurs IGMPv3) doivent agir comme des routeurs IGMPv1.
Si un routeur IGMPv2 est présent et devient le Querier, tous les routeurs doivent agir comme des routeurs IGMPv2.
Si un routeur IGMPv3 devient le Querier, il envoie des Queries IGMPv3. Les routeurs plus anciens verront celles-ci comme des queries IGMPv1/v2 invalides (ou les géreront s'ils sont partiellement compatibles), mais généralement, les routeurs IGMPv3 devraient être configurés pour fonctionner en mode IGMPv1 ou IGMPv2 s'ils doivent coexister avec des routeurs plus anciens qui ne peuvent pas gérer les paquets IGMPv3.

7.3. Mélange d'hôtes Version 1, 2 et 3

Il est possible d'avoir un mélange d'hôtes IGMPv1, IGMPv2 et IGMPv3 sur le même réseau.

Si le Querier est IGMPv3, il envoie des Queries IGMPv3.
Les hôtes IGMPv3 répondent avec des Reports IGMPv3.
Les hôtes IGMPv2 répondent avec des Reports IGMPv2.
Les hôtes IGMPv1 répondent avec des Reports IGMPv1.

Le routeur IGMPv3 doit gérer tous ces types de rapports. Pour les groupes avec des membres IGMPv1 ou IGMPv2, le routeur doit traiter effectivement le groupe comme étant en mode EXCLUDE avec une liste source vide (c'est-à-dire "envoyez-moi tout pour ce groupe"), car les hôtes plus anciens ne peuvent pas spécifier de filtres de source.

8. Liste des minuteurs, compteurs et de leurs valeurs par défaut

La plupart de ces minuteurs et compteurs sont configurables. Si des paramètres non par défaut sont utilisés, ils DOIVENT être cohérents parmi tous les routeurs sur un seul lien. Notez que les parenthèses indiquent la valeur du champ correspondant dans le message Query.

8.1. Robustness Variable

La Robustness Variable permet d'ajuster la perte de paquets attendue sur un réseau. Si un réseau est censé être sujet à des pertes, la Robustness Variable peut être augmentée. IGMP est robuste à [Robustness Variable] - 1 pertes de paquets.

Par défaut: 2

8.2. Query Interval

Le Query Interval est l'intervalle entre les General Queries envoyées par le Querier.

Par défaut: 125 secondes

8.3. Query Response Interval

Le Max Resp Time inséré dans les General Queries périodiques.

Par défaut: 100 (10 secondes)

8.4. Group Membership Interval

Le Group Membership Interval est la durée qui doit s'écouler avant qu'un routeur multicast décide qu'il n'y a plus de membres d'un groupe ou d'une source particulière sur un réseau.

8.5. Other Querier Present Interval

L'Other Querier Present Interval est la durée qui doit s'écouler avant qu'un routeur multicast décide qu'il n'y a plus d'autre routeur multicast qui devrait être le Querier.

8.6. Startup Query Interval

Le Startup Query Interval est l'intervalle entre les General Queries envoyées par un Querier au démarrage.

Par défaut: 1/4 du [Query Interval]

8.7. Startup Query Count

Le Startup Query Count est le nombre de Queries envoyées au démarrage, séparées par le [Startup Query Interval].

Par défaut: [Robustness Variable]

8.8. Last Member Query Interval

Le Last Member Query Interval est le Max Resp Time inséré dans les Group-Specific Queries envoyées en réponse aux messages Leave Group.

Par défaut: 10 (1 seconde)

8.9. Last Member Query Count

Le Last Member Query Count est le nombre de Group-Specific Queries envoyées avant que le routeur suppose qu'il n'y a plus de membres locaux.

Par défaut: [Robustness Variable]

8.10. Unsolicited Report Interval

L'Unsolicited Report Interval est le temps entre les répétitions du rapport initial d'un hôte d'appartenance à un groupe.

Par défaut: 10 secondes

8.11. Older Version Querier Present Timeout

L'Older Version Querier Present Timeout est le délai d'attente pour la transition d'un hôte vers le mode IGMPv3 une fois qu'une query d'une version plus ancienne a été entendue.

9. Considérations de sécurité

Nous considérons les ramifications d'un message falsifié de chaque type.

9.1. Message Query

Un message Query falsifié provenant d'une machine avec une adresse IP inférieure à celle du Querier actuel provoquera une élection de Querier. Cela peut amener le Querier actuel à arrêter d'envoyer des Queries et à attendre que le nouveau Querier démarre. Étant donné que le nouveau Querier n'est pas valide, le minuteur Query sur les routeurs peut finalement expirer, les amenant à supprimer leurs informations d'appartenance.

Une attaque DoS est possible en envoyant des Queries falsifiées avec un petit Max Resp Code. Cela provoquerait l'envoi simultané de Reports par tous les hôtes sur le LAN, submergeant potentiellement le réseau ou le routeur.

9.2. Messages Current State Report

Un message Report falsifié peut amener le routeur à croire qu'il y a des membres d'un groupe sur un réseau alors qu'il n'y en a pas. Cela peut entraîner le transfert inutile de trafic multicast vers le réseau, consommant de la bande passante.

9.3. Messages State Change Report

Un message State Change Report falsifié peut amener le routeur à croire qu'un système a rejoint ou quitté un groupe. Les rapports "Join" falsifiés (ALLOW ou TO_IN) causent du trafic inutile. Les rapports "Leave" falsifiés (BLOCK ou TO_EX) peuvent amener le routeur à envoyer une Group-Specific Query, et si aucun hôte valide ne répond à temps, le routeur peut arrêter de transférer le trafic pour le groupe, causant un déni de service aux membres légitimes.

9.4. IPsec

L'en-tête d'authentification IPsec (AH) [RFC2402] peut être utilisé pour protéger les messages IGMP. Lorsque AH est utilisé, l'authentification est appliquée à l'ensemble du paquet IP, y compris le message IGMP. Cela peut empêcher la falsification de messages IGMP. Cependant, la gestion des clés pour le multicast est complexe et constitue un domaine de recherche en cours.

10. Considérations IANA

10.1. Types de messages IGMP

L'IANA a attribué le type de message IGMP 0x22 pour "Version 3 Membership Report".

10.2. Types d'enregistrements de groupe

L'IANA a créé un nouveau registre pour les "IGMPv3 Report Types" (types d'enregistrements de groupe). Les valeurs 0x01 à 0x06 sont définies dans ce document. Les valeurs 0x00 et 0x07 à 0xFF sont disponibles pour attribution.

10.3. Max Resp Code

Le champ Max Resp Code dans le message Membership Query est un champ de 8 bits. Les valeurs sont définies dans la section 4.1.1. Aucun registre n'est requis.

11. Remerciements

Nous tenons à remercier les nombreuses personnes qui ont contribué à la conception et à la documentation d'IGMPv3. En particulier, nous reconnaissons les contributions de:

Steve Deering, qui a inventé IP Multicast et conçu les versions antérieures d'IGMP.
Van Jacobson, qui a contribué à la conception des mécanismes de minuterie.
Isidor Kouvelas, qui était co-auteur des versions préliminaires.
Les membres du groupe de travail IDMR pour leur examen et leurs commentaires.

12. Références

12.1. Références normatives

[RFC1112] Deering, S., "Host Extensions for IP Multicasting", STD 5, RFC 1112, août 1989.

12.2. Références informatives

Annexe A. Justification de la conception

A.1. Le mode de filtre "Exclude"

Le mode de filtre "Exclude" a été introduit pour prendre en charge le "Source-Specific Multicast" (SSM) tout en maintenant la compatibilité avec le modèle "Any-Source Multicast" (ASM) existant.

Dans ASM, un hôte rejoint un groupe G et reçoit du trafic de toutes les sources envoyant à G. Cela équivaut à EXCLUDE({}, G). Dans SSM, un hôte rejoint un canal spécifique (S, G) et reçoit du trafic uniquement de la source S envoyé au groupe G. Cela équivaut à INCLUDE({S}, G).

Le mode EXCLUDE permet à un hôte de bloquer des sources spécifiques d'un groupe ASM, ce qui est utile pour filtrer le trafic indésirable.

A.2. Le mode de filtre "Include"

Le mode de filtre "Include" est le mode principal pour SSM. Il permet à un hôte de spécifier explicitement l'ensemble des sources qu'il souhaite recevoir. Cela simplifie le protocole de routage multicast, car le routeur n'a besoin de construire qu'un arbre spécifique à la source.

A.3. State Change Reports

Les State Change Reports sont envoyés pour garantir la fiabilité. En répétant les rapports, la probabilité qu'ils soient perdus est réduite. Cela est important car IGMP fonctionne sur un transport non fiable (IP).

Annexe B. Résumé des changements par rapport à IGMPv2

Ce qui suit est un résumé des changements d'IGMPv2 [RFC2236] à IGMPv3:

Filtrage des sources: La capacité pour les hôtes de spécifier quelles sources ils veulent recevoir (mode INCLUDE) ou quelles sources ils veulent bloquer (mode EXCLUDE).
Types d'enregistrements de groupe: Les Reports IGMPv3 contiennent des Group Records, qui peuvent être de différents types (Current State, Filter Mode Change, Source List Change) pour transmettre différents types d'informations.
Format du Membership Report: Le format du Report a été complètement repensé pour prendre en charge plusieurs Group Records dans un seul message et pour transporter des adresses source.
Format de la Query: Le format de la Query a été étendu pour prendre en charge les Group-and-Source-Specific Queries et pour transporter la Robustness Variable et le Query Interval (QQIC).
Max Resp Code: Le champ Max Resp Code a été redéfini pour prendre en charge des valeurs plus grandes en utilisant une représentation en virgule flottante.
Élection du Querier: Le mécanisme d'élection du Querier reste le même, mais les règles de gestion des versions plus anciennes ont été clarifiées.
S Flag: Le flag "Suppress Router-Side Processing" dans les Queries permet aux routeurs de supprimer les mises à jour de minuterie lors de la réception de Queries, ce qui est utile pour certains diagnostics ou configurations spéciales.

Status of this Memo​

Copyright Notice​

Abstract​

Contents​

1. Introduction​

2. The Service Interface for Requesting IP Multicast Reception (L'interface de service pour demander la réception de multidiffusion IP)​

3. Multicast Reception State Maintained by Systems (État de réception multidiffusion maintenu par les systèmes)​

3.1. Socket State (État du socket)​

3.2. Interface State (État de l'interface)​

4. Formats de messages​

4.1. Message Membership Query​

4.1.1. Max Resp Code​

4.1.2. Checksum​

4.1.3. Group Address​

4.1.4. Resv (Reserved)​

4.1.5. S Flag (Suppress Router-Side Processing)​

4.1.6. QRV (Querier's Robustness Variable)​

4.1.7. QQIC (Querier's Query Interval Code)​

4.1.8. Number of Sources (N)​

4.1.9. Source Address [i]​

4.1.10. Additional Data​

4.1.11. Variantes de Query​

4.1.12. Adresses de destination IP pour les Queries​

4.2. Message Version 3 Membership Report​

4.2.1. Reserved​

4.2.2. Checksum​

4.2.3. Number of Group Records (M)​

4.2.4. Group Record​

4.2.5. Record Type​

4.2.6. Aux Data Len​

4.2.7. Number of Sources (N)​

4.2.8. Multicast Address​

4.2.9. Source Address [i]​

4.2.10. Auxiliary Data​

4.2.11. Additional Data​

4.2.12. Types de Group Record​

4.2.13. Adresses source IP pour les Reports​

4.2.14. Adresses de destination IP pour les Reports​

4.2.15. Notation pour les Group Records​

4.2.16. Taille du Membership Report​

5. Description du protocole pour les membres de groupe​

5.1. Action lors d'un changement d'état d'interface​

5.2. Action lors de la réception d'une Query​

5.2.1. Action lors de la réception d'une General Query​

5.2.2. Action lors de la réception d'une Group-Specific Query​

5.2.3. Action lors de la réception d'une Group-and-Source-Specific Query​

5.2.4. Action lors de la réception d'une Query avec le flag "S" activé​

6. Protocole pour les routeurs multicast​

6.1. Conditions pour l'élection du Querier​

6.2. Action du Querier lors de la réception d'une Query​

6.3. Envoi de Queries​

6.3.1. General Queries​

6.3.2. Group-Specific Queries​

6.3.3. Group-and-Source-Specific Queries​

6.4. Réception de Reports​

6.4.1. Réception de Current State Records​

6.4.2. Réception de Filter-Mode-Change Records​

6.4.3. Réception de Source-List-Change Records​

6.5. Commutation du mode de filtre du routeur​

6.6. Action lors de la réception d'un message Group Leave (IGMPv2)​

7. Interopération avec IGMPv1 et IGMPv2​

7.1. Fonctionnement de l'hôte IGMPv3​

7.1.1. Distinctions de version de Query​

7.1.2. Comportement en présence de Queriers plus anciens​

7.2. Fonctionnement du routeur IGMPv3​

7.2.1. Présence d'hôtes plus anciens​

7.2.2. Présence de routeurs plus anciens​

7.3. Mélange d'hôtes Version 1, 2 et 3​

8. Liste des minuteurs, compteurs et de leurs valeurs par défaut​

8.1. Robustness Variable​

8.2. Query Interval​

8.3. Query Response Interval​

8.4. Group Membership Interval​

8.5. Other Querier Present Interval​

8.6. Startup Query Interval​

8.7. Startup Query Count​

8.8. Last Member Query Interval​

8.9. Last Member Query Count​

8.10. Unsolicited Report Interval​

8.11. Older Version Querier Present Timeout​