IGMP : ce qui se cache derrière l’Internet group management protocol
L'équipe éditoriale IONOS
Depuis le franc succès rencontré par les services de streaming, tels que Netflix ou Spotify, le multicast IP s’est imposé comme une méthode de transmission indispensable sur Internet et dans les réseaux domestiques. En effet, ce processus technique permet à une personne expédiant des données d’envoyer des flux de données de façon ciblée à des groupes entiers de destinataires, et d’exploiter ainsi ces capacités de transport et de routage de façon optimale. Sans cette méthode de transmission, des paquets de données séparés devraient être envoyés à tous les appareils destinataires, ce qui nécessiterait une énorme bande passante et entraînerait rapidement une surcharge. Il serait ainsi pratiquement impossible de maintenir de façon durable la disponibilité des services offerts.
L’Internet group management protocol (IGMP) est un protocole qui joue un rôle essentiel dans l’organisation des groupes de destinataires multicast précités au sein de réseaux IPv4.
Qu’est-ce que l'Internet group management protocol ?
L'Internet group management protocol est un protocole de communication appartenant à la suite TCP/IP, développé à l’Université de Stanford et spécifié pour la première fois en 1989 dans les requêtes RFC 1112. Cette première version du protocole IGMPv1 fut suivie par les versions révisées Igmpv2 (RFC 2236) et Igmpv3 (RFC 3376 ; RFC 4604). Chacune des versions est rétrocompatible, ce qui permet à un appareil Igmpv3 de supporter automatiquement les versions 1 et 2. L’Internet group management protocol est destiné exclusivement aux réseaux IPv4 – dans les réseaux IPv6, les fonctions d’IGMP sont assurées par le protocole similaire Multicast Listener Discovery (MLD).
La tâche principale d’IGMP est d’administrer les groupes dynamiques pour les transmissions IP multicast. Cette administration est effectuée à la fois par l’appareil émetteur lui-même et le routeur intégré qui, d’une part, reçoivent des machines destinataires (ou des éventuels routeurs subordonnés) des requêtes d’adhésion à un groupe multicast donné et, d’autre part, relayent les messages IGMP aux routeurs subordonnés correspondants lorsqu’ils reçoivent des paquets de données multicast adaptés. Dans ce cas, la station émettrice ne reçoit aucune information sur les stations de destination atteintes par le paquet de données envoyé, ainsi que sur leur nombre, étant donné qu’elle n'envoie qu'un seul paquet de données aux routeurs qui lui sont subordonnés.
IGMP (Internet group management protocol) est un protocole de communication qui appartient à la suite des protocoles Internet (TCP/IP). Il fut spécifié pour la première fois en 1989 dans la RFC 1112 et est actif sur la couche réseau du modèle OSI. IGMP est responsable de l’organisation des groupes multicast permettant l’envoi de flux de données IP à plusieurs destinataires. Ainsi, l’Internet group management protocol est implémenté automatiquement sur tous les hôtes supportant le multicast IP.
Comment fonctionne IGMP ?
Nous avons déjà précisé que l’émetteur du paquet n'était pas responsable de l'administration des groupes via IGMP. Mais l’hôte émetteur doit, comme toutes les autres stations impliquées dans le réseau (y compris la station du destinataire), être compatible avec les connexions multicast. La réception des requêtes client pour l’adhésion à un groupe multicast donné, ainsi que la notification des clients dans le cas de flux de données multicast entrants est assurée par les différents routeurs du réseau situés entre l’émetteur et le destinataire.
Pour y parvenir, l’Internet group management protocol dispose, d’une part, de fonctionnalités permettant à une station de notifier au routeur qui lui est affecté que l’adhésion à un groupe multicast doit être effectuée. D’autre part, le protocole permet au routeur de retenir les interfaces sortantes des appareils destinataires devant recevoir certains flux de données IP multicast afin de pouvoir envoyer des messages (rapports) de façon ciblée, dès réception des données correspondantes. Dans ce cadre, les groupes multicast se distinguent par des adresses spécifiques dans la plage 224.0.0.x. Dans la plupart des cas, le premier point de contact d’un appareil est le routeur Internet local, qui reçoit la requête d’adhésion et la retransmet au prochain nœud du réseau : en règle générale, le routeur du fournisseur d’accès Internet. Cette chaîne de communication prend fin avec le routeur de l’expéditeur du flux de données qui duplique le paquet IP si nécessaire lorsqu’il doit répondre à plusieurs interfaces sortantes.
Si un deuxième ou un autre appareil destinataire doit être ajouté à un réseau privé du même groupe multicast, le routeur Internet peut accepter immédiatement la requête d’adhésion et relayer directement les flux de données déjà reçus. La transmission des données prend uniquement fin lorsque le dernier appareil a quitté le groupe.
En quoi les différentes versions d’IGMP se distinguent-elles ?
Les trois versions de l’Internet group management protocol publiées ont de nombreux points communs. Par exemple, Igmpv2 et Igmpv3 ont enrichi avant tout la version précédente de nouvelles fonctionnalités, tandis que les caractéristiques de base, telles que l’adresse du groupe pour les requêtes générales (0.0.0.0), ont été reprises sans modification. Mais quelles améliorations ont été apportées exactement ?
IGMPv1 : la base de l’Internet group management protocol
En tant que première version publiée du protocole de communication, IGMPv1 se distingue par certaines caractéristiques de base que l’on retrouve en grande partie dans les versions plus récentes. Par exemple, la version IGMPv1 définissait déjà 0.0.0.0 comme adresse de groupe et 224.0.0.1 comme adresse cible pour les requêtes IGMP générales. L’intervalle standard pour ces requêtes générées automatiquement par le routeur est ici de 60 secondes. IGMPv1 permet à tous les hôtes supportant le protocole de souscrire à des groupes multicast adaptés : les requêtes d’adhésion sont envoyées aux adresses IP multicast correspondantes sous la forme de rapports. Contrairement aux protocoles de suivi, IGMPv1 ne dispose toutefois d’aucune fonction permettant aux hôtes de quitter les groupes de façon autonome ; seul un dépassement de délai d’inactivité fait en sorte que l’hôte concerné soit retiré des groupes auxquels il a souscrit.
Tous les messages IGMP sont transportés dans des paquets IP simples avec le numéro de protocole IP 2 (hexadécimale : 0x02). L’entête IGMP de la première version du protocole se compose ainsi :
L’entête IGMP a donc une longueur totale de 64 bits. Les 8 premiers bits indiquent toujours la version du protocole IGMPv1, ainsi que le type de message. Ce champ (Type) peut être défini de deux façons : « 1 » (pour les requêtes d’adhésion) et « 2 » (pour les messages sur les flux de données multicast). Il est suivi par les bits 8 à 15 qui n’ont aucune fonction et se composent uniquement de zéros. La fin du premier bloc de 32 bits constitue une somme de contrôle. S’il s’agit d’un paquet de messages IGMP, ce bloc est suivi de l’adresse du groupe de 32 bits. En revanche, dans le cas de requêtes d’adhésion, il est suivi d’une section composée uniquement de zéros (adresse de groupe 0.0.0.0).
La version originale de cette suite de protocole n’indique pas quel routeur doit être utilisé pour les requêtes multicast (ceci est réglé par le protocole Multicast Routing Protocol).
Igmpv2 : introduction du message Leave et d’un type de message spécifique au groupe
La spécification Igmpv2, première refonte de ce standard, date de 1997 et intervient donc près de 8 ans après la première publication du protocole. Les adresses de groupe (0.0.0.0) et de destination (224.0.0.1) pour les requêtes automatiques, restent inchangées, mais la durée de l’intervalle standard a été augmentée à 125 secondes. La principale nouveauté apportée de la version Igmpv2 est toutefois l’accélération du processus de déconnexion : le dépassement de délai d’inactivité prévu dans la première version du protocole est remplacé par un processus de déconnexion initié par l’hôte à l’aide d’un message « Leave ». L’adresse 224.0.0.2 est définie comme adresse de destination pour ce type de messages.
Autre nouveauté de la deuxième version de ce protocole de communication : la possibilité de déterminer le statut de la réception pour une certaine adresse multicast à l’aide de messages spécifiques aux groupes.
Les messages Igmpv2 sont également envoyés dans des paquets IP simples avec le numéro de protocole IP 2. De petites modifications ont toutefois été apportées à l’entête IGMP :
L’entête commence comme celui de la première version, mais sans l'indication du numéro de version. Les codes de type possibles sont « 0x11 » (pour les requêtes), « 0x16 » (pour les messages) et « 0x17 » (pour les messages Leave). Dans le cadre de la rétrocompatibilité, on trouve également le code « 0x12 » pour les messages IGMPv1. Les bits 8 à 15 se voient attribuer une fonction concrète dans Igmpv2, du moins pour les requêtes d’adhésion, et définissent le délai de réponse maximal autorisé. Ils sont suivis par la somme de contrôle (16 bits) et l’adresse de groupe (32 bits), qui prend à nouveau la forme caractéristique du protocole 0.0.0.0 pour les requêtes générales.
Igmpv2 instaure la règle suivante : le routeur ayant l’adresse IP la plus basse dans le sous-réseau est utilisé pour les requêtes multicast.
Igmpv3 : sécurité améliorée grâce à la sélection ciblée de sources multicast
Igmpv3, la troisième version de l’Internet group management protocol, est disponible depuis octobre 2002. Dans cette version révisée, 0.0.0.0 et 224.0.0.1 sont, une fois encore, définis comme adresse de groupe et de destination pour les requêtes générales. En ce qui concerne l’intervalle standard, cette version s’aligne sur la version précédente du protocole, avec 125 secondes. La grande nouveauté de cette refonte réside dans la possibilité de sélectionner la source du flux multicast de façon ciblée. Ce multicast spécifique à la source (« source-specific multicast ») diminue très fortement les besoins du réseau et apporte une sécurité supplémentaire dans la transmission, puisque les sources arbitraires et/ou inconnues ne sont tout simplement pas utilisées.
Dans la version Igmpv3, l’entête IGMP est également intégré dans les paquets IP (numéro de protocole 2), mais de façon nettement plus complexe que dans les versions précédentes, notamment parce qu'il est possible d’indiquer l’adresse source. On observe par ailleurs des différences très nettes entre les requêtes et les notifications. L’entête pour les requêtes de groupe Igmpv3 se compose comme suit :
Les deux premières séquences de 32 bits sont identiques à celles de l’entête IGMPv2 – type, délai de réponse maximal, somme de contrôle et adresse de groupe. La version Igmpv3 offre également la possibilité d'un échange avec d’anciennes versions du protocole : les hôtes disposent pour cela des codes « 0x12 » pour la version 1 et « 0x16 » pour la version 2. L’adresse de groupe est suivie par la séquence d’entête spécifique à la requête Igmpv3, dont les 32 premiers bits se composent comme suit :
- Res. : champ de 4 bits réservé, n’ayant aucune fonction et ne contenant que des zéros.
- S (Suppress Router-Side Processing) : champ S qui définit les routeurs sur la valeur « 1 », et signale qu’ils ne doivent pas tenir compte des mises à jour normales lors de la réception d’une requête. Si la valeur est « 0 », le champ est inactif.
- QRV (Querier’s Robustness Variable) : 3 bits pouvant contenir la valeur « variable de robustesse » utilisée par les hôtes requérants.
- QQIC (Querier’s Query Interval Code) : champ de 8 bits permettant de spécifier l’intervalle pour les requêtes IGMPV3.
- Nombre d’adresses source : nombre d’adresses source listées ci-après.
Ces indications très spécifiques sont suivies de l’adresse source ou d’une liste d’adresses source individuelles (de 32 bits chacune), dans la mesure où plusieurs sources doivent être définies.
Le chapitre 4.2 de la requête RFC 3376 indique dans quelle mesure l’entête du deuxième type de message (messages Igmpv3) diffère de l'entête des requêtes Igmpv3 présenté ici.
Contrairement aux versions antérieures, Igmpv3 permet à un hôte d’intégrer une transaction unique d’un groupe et d’en quitter un autre – pour ce faire, Igmpv2 a besoin de deux messages séparés supplémentaires.
Dans quel cas l’Internet group management protocol est-il utilisé ?
Le rôle d’IGMP est clairement défini : ce protocole de communication est toujours utilisé lorsque des transmissions multicast sont nécessaires dans des réseaux IPv4 comme Internet. Les scénarios d’utilisation classiques sont par conséquent les applications en temps réel, qui se déroulent à travers des connexions multipoints, par exemple des outils de conférence Web ou des services de streaming en direct. Dans ce cadre, tous les clients n'ont pas besoin de recevoir le flux de données nécessaire, ce qui entraînerait rapidement une congestion du serveur de départ, et des nœuds de réseau en question.
De nombreux commutateurs et routeurs Internet offrent la possibilité de filtrer le trafic de données multicast dans les réseaux afin d’optimiser la performance du réseau. Pour cela, les machines ont recours à l’IGMP Snooping : une possibilité offerte par l’Internet group management protocol.
