Difference between revisions of "MOOC:Annexe Compagnon Act31"
From Livre IPv6
(→Introduction) |
(→Indication de redirection) |
||
| (26 intermediate revisions by 4 users not shown) | |||
| Line 5: | Line 5: | ||
__NOTOC__ | __NOTOC__ | ||
| − | = | + | = ANNEXE 1 Activité 31 : Le protocole de découverte des voisins = |
==Introduction== | ==Introduction== | ||
| − | Le contenu de cette annexe | + | Le contenu de cette annexe complète l'activité 31 en : |
| − | + | * introduisant MLD, le protocole de gestion des inscriptions aux groupes de ''multicast'' et les messages ICMPv6 associés ; | |
| − | * introduisant MLD le protocole de gestion des inscriptions aux groupes de ''multicast'' et les messages ICMPv6 associés ; | + | * introduisant des fonctions expérimentales ; |
| − | * | + | * décrivant les informations véhiculées par les messages ICMPv6 sous forme d'options. |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | * | + | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
==Gestion de groupes multicast sur le lien local == | ==Gestion de groupes multicast sur le lien local == | ||
| Line 86: | Line 23: | ||
MLD est une fonction d'ICMPv6 ; aussi, les messages MLD sont des messages ICMPv6. Les messages pour MLD sont envoyés avec : | MLD est une fonction d'ICMPv6 ; aussi, les messages MLD sont des messages ICMPv6. Les messages pour MLD sont envoyés avec : | ||
| − | * une adresse source IPv6 lien-local | + | * une adresse source IPv6 lien-local ; |
| − | * le champ <tt>nombre de sauts</tt> fixé à 1 | + | * le champ <tt>nombre de sauts</tt> fixé à 1 ; |
| − | * l'option <tt>IPv6 Router Alert</tt> activée en ajoutant l'extension d'en-tête ''Hop-by-Hop'' | + | * l'option <tt>IPv6 Router Alert</tt> activée en ajoutant l'extension d'en-tête ''Hop-by-Hop'' correspondante. |
Cette dernière option est nécessaire afin de contraindre les routeurs à examiner les messages MLD envoyés à des adresses multicast par lesquelles les routeurs ne sont pas intéressés. | Cette dernière option est nécessaire afin de contraindre les routeurs à examiner les messages MLD envoyés à des adresses multicast par lesquelles les routeurs ne sont pas intéressés. | ||
| Line 100: | Line 37: | ||
Les champs des messages pour MLD ont la signification suivante : | Les champs des messages pour MLD ont la signification suivante : | ||
| − | * <tt>Type</tt> : prend la valeur 130, 131 ou 132 | + | * <tt>Type</tt> : prend la valeur 130, 131 ou 132 ; |
| − | * <tt>Code</tt> : mis à zéro par l'émetteur et ignoré par les récepteurs | + | * <tt>Code</tt> : mis à zéro par l'émetteur et ignoré par les récepteurs ; |
| − | * <tt>Checksum</tt> : celui du protocole ICMPv6 standard, couvrant tout le message MLD auquel s'ajoutent les champs du pseudo-en-tête IPv6 | + | * <tt>Checksum</tt> : celui du protocole ICMPv6 standard, couvrant tout le message MLD auquel s'ajoutent les champs du pseudo-en-tête IPv6 ; |
* <tt>Délai maximal de réponse</tt> : | * <tt>Délai maximal de réponse</tt> : | ||
| − | ** utilisé seulement dans les messages de recensement, il exprime le retard maximal autorisé (en millisecondes) pour l'arrivée des rapports d'abonnement | + | ** utilisé seulement dans les messages de recensement, il exprime le retard maximal autorisé (en millisecondes) pour l'arrivée des rapports d'abonnement, |
| − | ** dans les messages de rapport ou de résiliation d'abonnement, ce champ est mis à zéro par l'émetteur et ignoré par les récepteurs | + | ** dans les messages de rapport ou de résiliation d'abonnement, ce champ est mis à zéro par l'émetteur et ignoré par les récepteurs ; |
| − | * <tt>réservé</tt> : champ non utilisé et mis à zéro par l'émetteur et ignoré par les récepteurs | + | * <tt>réservé</tt> : champ non utilisé et mis à zéro par l'émetteur et ignoré par les récepteurs ; |
* <tt>Adresse multicast</tt> : | * <tt>Adresse multicast</tt> : | ||
| − | ** pour un message de recensement général, ce champ est mis à zéro | + | ** pour un message de recensement général, ce champ est mis à zéro, |
| − | ** pour un message de recensement spécifique, il contient l'adresse multicast en question | + | ** pour un message de recensement spécifique, il contient l'adresse multicast en question, |
** pour les messages de rapport et de résiliation d'abonnement, le champ contient l'adresse multicast sur laquelle l'hôte souhaite écouter ou cesser d'écouter. | ** pour les messages de rapport et de résiliation d'abonnement, le champ contient l'adresse multicast sur laquelle l'hôte souhaite écouter ou cesser d'écouter. | ||
<center> | <center> | ||
| Line 135: | Line 72: | ||
=== Principe de MLD === | === Principe de MLD === | ||
| − | Le routeur envoie régulièrement des messages de recensement général à l'adresse de multicast <tt>FF02::1</tt>. Cette adresse équivaut à l'adresse de diffusion sur un lien. Pour éviter que le routeur | + | Le routeur envoie régulièrement des messages de recensement général à l'adresse de multicast <tt>FF02::1</tt>. Cette adresse équivaut à l'adresse de diffusion sur un lien. Pour éviter que le routeur reçoive plusieurs réponses pour un même groupe, les récepteurs ne répondent pas immédiatement. Pour cela, les récepteurs arment un temporisateur pour chaque adresse multicast qui les concerne. Si le récepteur entend une réponse équivalente à la sienne, Il désarme le temporisateur. Sinon, à l'expiration du temporisateur, le récepteur envoie un rapport d'abonnement à l'adresse multicast du groupe. Avec ce système de temporisateurs, les récepteurs peuvent surveiller les rapports des autres récepteurs sur le lien et ainsi minimiser le trafic MLD. |
Les changements d'état des récepteurs sont notifiés par des messages non sollicités. Un message non sollicité est un message émis à l'initiative d'un récepteur d'un groupe multicast ; contrairement au recensement, où c'est le routeur local qui prend l'initiative de l'échange. Les récepteurs peuvent envoyer des messages non sollicités pour les cas suivants : | Les changements d'état des récepteurs sont notifiés par des messages non sollicités. Un message non sollicité est un message émis à l'initiative d'un récepteur d'un groupe multicast ; contrairement au recensement, où c'est le routeur local qui prend l'initiative de l'échange. Les récepteurs peuvent envoyer des messages non sollicités pour les cas suivants : | ||
| − | * | + | * pour souscrire à une adresse multicast spécifique ; |
| − | * | + | * pour une résiliation rapide : le récepteur envoie un message de résiliation d'abonnement à l'adresse multicast de "tous les routeurs du lien local" (<tt>FF02::2</tt>). Le routeur répond avec un message de recensement spécifique à l'adresse en question. S'il n'y a plus de récepteur pour répondre à ce recensement, le routeur efface l'adresse multicast de sa table de routage. |
| − | Pour cesser d'écouter sur une adresse multicast, le récepteur peut simplement ne plus répondre aux messages de recensement du routeur. S'il est le seul récepteur de cette adresse multicast sur le lien, après un certain temps l'état du routeur concernant cette adresse expire. Le routeur arrêtera de faire suivre les paquets multicast envoyés à l'adresse en question, s'il s'avère que le récepteur était le dernier concerné par l'adresse multicast sur le lien | + | Pour cesser d'écouter sur une adresse multicast, le récepteur peut simplement ne plus répondre aux messages de recensement du routeur. S'il est le seul récepteur de cette adresse multicast sur le lien, après un certain temps, l'état du routeur concernant cette adresse expire. Le routeur arrêtera de faire suivre les paquets multicast envoyés à l'adresse en question, s'il s'avère que le récepteur était le dernier concerné par l'adresse multicast sur le lien. |
| − | + | À noter qu'il est possible d'avoir plusieurs routeurs multicast sur le même lien local. Dans ce cas, un mécanisme d'élection est utilisé pour choisir le routeur recenseur. Celui-ci sera le seul responsable pour l'envoi des messages de recensement. | |
| − | == | + | == Indication de redirection == |
| − | La | + | La technique de redirection est la même que dans IPv4. Un équipement ne connaît que les préfixes des réseaux auxquels il est directement attaché et l'adresse d'un routeur par défaut. Si la route peut être optimisée, le routeur par défaut envoie ce message pour indiquer qu'une route plus courte existe. En effet, avec IPv6, comme le routeur par défaut est appris automatiquement, la route n'est pas forcément la meilleure (cf. figure Routage par défaut non optimal). |
| − | + | ||
| − | + | Un autre cas d'utilisation particulier à IPv6 concerne des stations situées sur un même lien physique mais ayant des préfixes différents. Ces machines passent dans un premier temps par le routeur par défaut. Ce dernier les avertit qu'une route directe existe. | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | [[File:MOOC_Act31_Fig10.png|400px|center|thumb|Figure 7 : Format d'un message ICMPv6 d'indication de redirection.]] | |
| − | + | ||
| − | + | ||
| − | La | + | La figure Format des paquets d'indication de redirection donne le format du message : |
| − | + | * Le champ adresse cible contient l'adresse IPv6 de l'équipement vers lequel les paquets doivent être émis. | |
| − | + | * Le champ adresse destination contient l'adresse IPv6 de l'équipement pour lequel la redirection s'applique. | |
| + | |||
| + | Dans le cas de la redirection vers un équipement se situant sur le même lien, l'adresse cible et la destination sont identiques. | ||
| − | + | Les options contiennent l'adresse physique du nouveau routeur et l'en-tête du paquet redirigé. | |
| − | + | Ce message peut être utilisé de la même manière qu'en IPv4. Une machine n'a qu'une route par défaut pour atteindre un équipement se trouvant sur un autre préfixe. Elle envoie donc son paquet au routeur qui s'aperçoit que le préfixe de destination est accessible par le même sous réseau que l'émetteur. Il relaie le paquet et informe la source qu'elle peut directement joindre le routeur menant vers le préfixe. | |
== Fonctions autres et expérimentales == | == Fonctions autres et expérimentales == | ||
| Line 364: | Line 121: | ||
| || || | | || || | ||
|-style="background:silver" | |-style="background:silver" | ||
| − | !colspan=3 | Recherche d'information sur un | + | !colspan=3 | Recherche d'information sur un nœud (expérimental, RFC 4620) |
|- | |- | ||
|139 || || Demande d'information | |139 || || Demande d'information | ||
| Line 391: | Line 148: | ||
</center> | </center> | ||
| − | == | + | == Options véhiculées par les messages ICMPv6 == |
| − | + | L'intérêt du protocole de découverte des voisins est d'unifier différents protocoles qui existent dans IPv4. En particulier, la plupart des informations à transporter utilise un format commun sous la forme d'options. Le format commun des options simplifie la mise en œuvre du protocole. Une option se décrit en mot de 64 bits et comporte les champs type, longueur, données. <br> | |
| − | + | Les différentes fonctionnalités de découverte des voisins utilisent 5 messages : 2 pour le dialogue entre un équipement et un routeur, 2 pour le dialogue entre voisins et 1 dernier pour la redirection. Chacun de ces messages peut contenir des options. Le tableau 1 présente l'utilisation des options définies dans le RFC 4861 dans les messages de découverte de voisin.<br> | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | L'intérêt du protocole de découverte des voisins est d'unifier différents protocoles qui existent dans IPv4. En particulier, la plupart des informations à transporter utilise un format commun sous la forme d'options. Le format commun des options simplifie la mise en | + | |
| − | Les différentes fonctionnalités de découverte des voisins utilisent 5 messages : 2 pour le dialogue entre un équipement et un routeur, 2 pour le dialogue entre voisins et | + | |
<center > | <center > | ||
| Line 448: | Line 175: | ||
'''Tableau 2''': Identification des options de ''Neighbor Discovery''.</center> | '''Tableau 2''': Identification des options de ''Neighbor Discovery''.</center> | ||
| − | == <div id="physique">Adresse physique de la source/cible</div> == | + | === <div id="physique">Adresse physique de la source/cible</div> === |
[[Image:31-Afig1.png|400px|right|thumb|Figure : Format de l'option adresse physique source/cible.]] | [[Image:31-Afig1.png|400px|right|thumb|Figure : Format de l'option adresse physique source/cible.]] | ||
| − | La figure Format de l'option adresse physique source/cible donne le format de ces options. Le type 1 est réservé à l'adresse physique de la source et le type 2 à l'adresse de la cible. | + | La figure "Format de l'option adresse physique source/cible" donne le format de ces options. Le type 1 est réservé à l'adresse physique de la source et le type 2 à l'adresse de la cible. |
Le champ «longueur» est la taille en mots de 64 bits de l'option. Dans le cas d'une adresse MAC, d'une longueur de 6 octets, il contient donc la valeur 1. | Le champ «longueur» est la taille en mots de 64 bits de l'option. Dans le cas d'une adresse MAC, d'une longueur de 6 octets, il contient donc la valeur 1. | ||
| Line 458: | Line 185: | ||
Le RFC 2464 définit le format pour les adresses MAC-48 utilisés dans les réseaux Ethernet et Wi-Fi. Le RFC 4944 définit le format pour les MAC-16 et MAC-64 utilisés dans les réseaux de capteurs reposant sur la norme IEEE 802.15.4. | Le RFC 2464 définit le format pour les adresses MAC-48 utilisés dans les réseaux Ethernet et Wi-Fi. Le RFC 4944 définit le format pour les MAC-16 et MAC-64 utilisés dans les réseaux de capteurs reposant sur la norme IEEE 802.15.4. | ||
| − | == <div id="information">Information sur le préfixe</div> == | + | === <div id="information">Information sur le préfixe</div> === |
[[Image:31-Afig2.png|400px|right|thumb|Figure : Format de l'option information sur le préfixe.]] | [[Image:31-Afig2.png|400px|right|thumb|Figure : Format de l'option information sur le préfixe.]] | ||
| − | Cette option contient les informations sur le préfixe pour permettre une configuration automatique des équipements. Cette option sera présentée en détail dans l'activité d' | + | Cette option contient les informations sur le préfixe pour permettre une configuration automatique des équipements. Cette option sera présentée en détail dans l'activité d'autoconfiguration. |
| − | == <div id="redirigee">En-tête redirigée</div> == | + | === <div id="redirigee">En-tête redirigée</div> === |
[[Image:31-Afig3.png|400px|right|thumb|Figure : Format de l'option en-tête redirigée.]] | [[Image:31-Afig3.png|400px|right|thumb|Figure : Format de l'option en-tête redirigée.]] | ||
| Line 472: | Line 199: | ||
Le type vaut 4 et la taille de cette option ne doit pas conduire à un paquet IPv6 dépassant 1280 octets (cf. figure Format de l'option en-tête redirigée). Par contre le paquet doit contenir le maximum d'information possible. | Le type vaut 4 et la taille de cette option ne doit pas conduire à un paquet IPv6 dépassant 1280 octets (cf. figure Format de l'option en-tête redirigée). Par contre le paquet doit contenir le maximum d'information possible. | ||
| − | == <div id="MTU">MTU</div> == | + | === <div id="MTU">MTU</div> === |
[[Image:31-Afig4.png|400px|right|thumb|Figure : Format de l'option MTU.]] | [[Image:31-Afig4.png|400px|right|thumb|Figure : Format de l'option MTU.]] | ||
| − | Cette option permet d'informer les équipements sur la taille maximale des données pouvant être émises sur le lien. La figure Format de l'option MTU donne le format de cette option. Il n'est pas nécessaire de diffuser cette information si l'équipement utilise toujours la taille maximale permise. Par exemple, sur les réseaux Ethernet, les équipements utiliseront la valeur 1 500. Par contre pour les réseaux anneau à jeton ou FDDI, il est souvent nécessaire de préciser si les équipements doivent utiliser la valeur maximale permise ou une valeur inférieure pour autoriser l'utilisation de ponts. | + | Cette option permet d'informer les équipements sur la taille maximale des données pouvant être émises sur le lien. La figure "Format de l'option MTU" donne le format de cette option. Il n'est pas nécessaire de diffuser cette information si l'équipement utilise toujours la taille maximale permise. Par exemple, sur les réseaux Ethernet, les équipements utiliseront la valeur 1 500. Par contre pour les réseaux anneau à jeton ou FDDI, il est souvent nécessaire de préciser si les équipements doivent utiliser la valeur maximale permise ou une valeur inférieure pour autoriser l'utilisation de ponts. |
Le champ type vaut 5 et le champ longueur 1. | Le champ type vaut 5 et le champ longueur 1. | ||
| Line 482: | Line 209: | ||
== Référence bibliographique == | == Référence bibliographique == | ||
<references /> | <references /> | ||
| + | |||
| + | == Pour aller plus loin== | ||
| + | |||
| + | RFC et leur analyse par S. Bortzmeyer | ||
| + | * RFC 2710 Multicast Listener Discovery (MLD) for IPv6 | ||
| + | * RFC 2894 Router Renumbering for IPv6 | ||
| + | * RFC 3122 Extensions to IPv6 Neighbor Discovery for Inverse Discovery Specification | ||
| + | * RFC 3971 SEcure Neighbor Discovery (SEND) [http://www.bortzmeyer.org/3971.html Analyse] | ||
| + | * RFC 3810 Multicast Listener Discovery Version 2 (MLDv2) for IPv6 | ||
| + | * RFC 4065 Instructions for Seamoby and Experimental Mobility Protocol IANA Allocations | ||
| + | * RFC 6275 Mobility Support in IPv6 | ||
Latest revision as of 17:16, 24 February 2022
ANNEXE 1 Activité 31 : Le protocole de découverte des voisins
Introduction
Le contenu de cette annexe complète l'activité 31 en :
- introduisant MLD, le protocole de gestion des inscriptions aux groupes de multicast et les messages ICMPv6 associés ;
- introduisant des fonctions expérimentales ;
- décrivant les informations véhiculées par les messages ICMPv6 sous forme d'options.
Gestion de groupes multicast sur le lien local
Pour offrir un service de distribution multicast, deux composants sont nécessaires : un protocole de gestion de groupes multicast et un protocole de routage multicast[1]. Le protocole de gestion de groupes multicast réalise la signalisation entre l'hôte et son routeur local. Le protocole de routage multicast vise à échanger les informations entre les routeurs afin qu'un arbre de distribution multicast soit construit.
En IPv6, MLD (Multicast Listener Discovery) sert, pour un hôte, à indiquer les groupes auxquels il souhaite souscrire. MLD est donc un protocole de gestion de groupes. Ainsi, un routeur de bordure IPv6 va pouvoir découvrir la présence de récepteurs multicast (qualifiés de listeners) sur ses liens directement attachés, ainsi que les adresses multicast concernées. MLD est un protocole asymétrique qui spécifie un comportement différent pour les hôtes (les listeners) et les routeurs. Toutefois, pour les adresses multicast sur lesquelles un routeur lui-même est récepteur, il doit exécuter les deux parties du protocole. Ceci implique notamment de répondre à ses propres messages de demande. En effet, les routeurs doivent constituer une liste des adresses multicast pour lesquelles il a un ou plusieurs récepteurs sur leur lien local. Aussi, un des récepteurs sur un lien envoie un message de rapport d'abonnement aux groupes auxquels il souhaite recevoir les messages. L'objectif est, par des communications multicast sur le lien, que le routeur local arrive à faire la liste complète des groupes multicast pour lesquels il doit relayer le trafic localement.
MLD est une fonction d'ICMPv6 ; aussi, les messages MLD sont des messages ICMPv6. Les messages pour MLD sont envoyés avec :
- une adresse source IPv6 lien-local ;
- le champ nombre de sauts fixé à 1 ;
- l'option IPv6 Router Alert activée en ajoutant l'extension d'en-tête Hop-by-Hop correspondante.
Cette dernière option est nécessaire afin de contraindre les routeurs à examiner les messages MLD envoyés à des adresses multicast par lesquelles les routeurs ne sont pas intéressés. La version d'origine du protocole MLD [RFC 2710] (que nous appellerons également MLDv1) présente les mêmes fonctionnalités que le protocole IGMPv2 en IPv4. MLDv2 a été proposé par le RFC 3810 dans lequel, en plus du groupe, le récepteur peut indiquer la source. MLDV2 est une adaptation de IGMPv3 d'IPv4 à IPv6.
Format des messages pour MLD
Le format générique d'un message MLD est donné par la figure 7. Les différents types de messages ICMPv6 pour MLD sont indiqués par le tableau 2. On distingue trois types de messages pour MLD.
- Le premier type (type = 130) concerne le recensement des récepteurs multicast selon plusieurs méthodes : (i) recensement général émis à l'adresse de diffusion générale sur le lien (FF02::1), (ii) recensement spécifique pour une adresse multicast ; l'adresse de destination est l'adresse multicast du groupe en question. Le message de requête d'abonnement (Multicast Listener Query) est émis par le routeur.
- Le second type de message (type = 131) vise à obtenir un rapport d'abonnement multicast (Multicast Listener Report). Ce message est émis par le récepteur multicast. L'adresse de destination est l'adresse multicast du groupe en question. Avec MLDv2, le rapport d'abonnement à un groupe multicast a été complété par la possibilité de limiter la réception au trafic émis par certaines sources. Le trafic des sources non indiquées est alors non reçu. Cette restriction sur la source s'effectue par un message spécifique (type = 143).
- Enfin, le troisième type de message (type = 132) va servir à un récepteur pour annoncer une résiliation d'abonnement (Multicast Listener Done) à un groupe. Ce message est émis à l'adresse du groupe multicast "tous les routeurs du lien local" (FF02::2).
Les champs des messages pour MLD ont la signification suivante :
- Type : prend la valeur 130, 131 ou 132 ;
- Code : mis à zéro par l'émetteur et ignoré par les récepteurs ;
- Checksum : celui du protocole ICMPv6 standard, couvrant tout le message MLD auquel s'ajoutent les champs du pseudo-en-tête IPv6 ;
- Délai maximal de réponse :
- utilisé seulement dans les messages de recensement, il exprime le retard maximal autorisé (en millisecondes) pour l'arrivée des rapports d'abonnement,
- dans les messages de rapport ou de résiliation d'abonnement, ce champ est mis à zéro par l'émetteur et ignoré par les récepteurs ;
- réservé : champ non utilisé et mis à zéro par l'émetteur et ignoré par les récepteurs ;
- Adresse multicast :
- pour un message de recensement général, ce champ est mis à zéro,
- pour un message de recensement spécifique, il contient l'adresse multicast en question,
- pour les messages de rapport et de résiliation d'abonnement, le champ contient l'adresse multicast sur laquelle l'hôte souhaite écouter ou cesser d'écouter.
| Type | Code | Signification |
|---|---|---|
| Gestion des groupes multicast | ||
| 130 | Requête d'abonnement | |
| 131 | Rapport d'abonnement | |
| 132 | Fin d'abonnement | |
| 143 | Rapport d'abonnement MLDv2 | |
Tableau 2 : Messages ICMPv6 pour MLD
Principe de MLD
Le routeur envoie régulièrement des messages de recensement général à l'adresse de multicast FF02::1. Cette adresse équivaut à l'adresse de diffusion sur un lien. Pour éviter que le routeur reçoive plusieurs réponses pour un même groupe, les récepteurs ne répondent pas immédiatement. Pour cela, les récepteurs arment un temporisateur pour chaque adresse multicast qui les concerne. Si le récepteur entend une réponse équivalente à la sienne, Il désarme le temporisateur. Sinon, à l'expiration du temporisateur, le récepteur envoie un rapport d'abonnement à l'adresse multicast du groupe. Avec ce système de temporisateurs, les récepteurs peuvent surveiller les rapports des autres récepteurs sur le lien et ainsi minimiser le trafic MLD.
Les changements d'état des récepteurs sont notifiés par des messages non sollicités. Un message non sollicité est un message émis à l'initiative d'un récepteur d'un groupe multicast ; contrairement au recensement, où c'est le routeur local qui prend l'initiative de l'échange. Les récepteurs peuvent envoyer des messages non sollicités pour les cas suivants :
- pour souscrire à une adresse multicast spécifique ;
- pour une résiliation rapide : le récepteur envoie un message de résiliation d'abonnement à l'adresse multicast de "tous les routeurs du lien local" (FF02::2). Le routeur répond avec un message de recensement spécifique à l'adresse en question. S'il n'y a plus de récepteur pour répondre à ce recensement, le routeur efface l'adresse multicast de sa table de routage.
Pour cesser d'écouter sur une adresse multicast, le récepteur peut simplement ne plus répondre aux messages de recensement du routeur. S'il est le seul récepteur de cette adresse multicast sur le lien, après un certain temps, l'état du routeur concernant cette adresse expire. Le routeur arrêtera de faire suivre les paquets multicast envoyés à l'adresse en question, s'il s'avère que le récepteur était le dernier concerné par l'adresse multicast sur le lien.
À noter qu'il est possible d'avoir plusieurs routeurs multicast sur le même lien local. Dans ce cas, un mécanisme d'élection est utilisé pour choisir le routeur recenseur. Celui-ci sera le seul responsable pour l'envoi des messages de recensement.
Indication de redirection
La technique de redirection est la même que dans IPv4. Un équipement ne connaît que les préfixes des réseaux auxquels il est directement attaché et l'adresse d'un routeur par défaut. Si la route peut être optimisée, le routeur par défaut envoie ce message pour indiquer qu'une route plus courte existe. En effet, avec IPv6, comme le routeur par défaut est appris automatiquement, la route n'est pas forcément la meilleure (cf. figure Routage par défaut non optimal).
Un autre cas d'utilisation particulier à IPv6 concerne des stations situées sur un même lien physique mais ayant des préfixes différents. Ces machines passent dans un premier temps par le routeur par défaut. Ce dernier les avertit qu'une route directe existe.
La figure Format des paquets d'indication de redirection donne le format du message :
- Le champ adresse cible contient l'adresse IPv6 de l'équipement vers lequel les paquets doivent être émis.
- Le champ adresse destination contient l'adresse IPv6 de l'équipement pour lequel la redirection s'applique.
Dans le cas de la redirection vers un équipement se situant sur le même lien, l'adresse cible et la destination sont identiques.
Les options contiennent l'adresse physique du nouveau routeur et l'en-tête du paquet redirigé.
Ce message peut être utilisé de la même manière qu'en IPv4. Une machine n'a qu'une route par défaut pour atteindre un équipement se trouvant sur un autre préfixe. Elle envoie donc son paquet au routeur qui s'aperçoit que le préfixe de destination est accessible par le même sous réseau que l'émetteur. Il relaie le paquet et informe la source qu'elle peut directement joindre le routeur menant vers le préfixe.
Fonctions autres et expérimentales
Pour être complet, nous pouvons signaler que les messages ICMPv6 servent aussi pour des fonctions expérimentales. Le tableau 4 indique les types de messages associés à ces fonctions. Nous ne détaillerons pas ici ces fonctions, limitées à des usages très spécifiques. Le lecteur curieux est invité à consulter les RFC associés.
| Type | Code | Signification |
|---|---|---|
| Renumérotation des routeurs (expérimental, RFC 2894) | ||
| 138 | Renumérotation des routeurs : | |
| 0 | Commande | |
| 1 | Résultat | |
| 255 | Remise à zéro du numéro de séquence | |
| Recherche d'information sur un nœud (expérimental, RFC 4620) | ||
| 139 | Demande d'information | |
| 140 | Réponse | |
| Mobilité (RFC 6275) | ||
| 144 | Découverte d'agent mère (requête) | |
| 145 | Découverte d'agent mère (réponse) | |
| 146 | Sollicitation de préfixe mobile | |
| 147 | Annonce de préfixe mobile | |
| Mobilité (expérimental, RFC 4065) | ||
| 150 | Protocoles de mobilité expérimentaux, tels que Seamoby | |
Tableau 4 : Fonctions expérimentales s'appuyant sur ICMPv6
Options véhiculées par les messages ICMPv6
L'intérêt du protocole de découverte des voisins est d'unifier différents protocoles qui existent dans IPv4. En particulier, la plupart des informations à transporter utilise un format commun sous la forme d'options. Le format commun des options simplifie la mise en œuvre du protocole. Une option se décrit en mot de 64 bits et comporte les champs type, longueur, données.
Les différentes fonctionnalités de découverte des voisins utilisent 5 messages : 2 pour le dialogue entre un équipement et un routeur, 2 pour le dialogue entre voisins et 1 dernier pour la redirection. Chacun de ces messages peut contenir des options. Le tableau 1 présente l'utilisation des options définies dans le RFC 4861 dans les messages de découverte de voisin.
| Sollicitation du | Annonce du | Sollicitation | Annonce | Indication de | |
| routeur | routeur | d'un voisin | d'un voisin | redirection | |
| Adresse physique de la source | présent | présent | présent | ||
| Adresse physique de la cible | présent | présent | |||
| Information sur le préfixe | ≥ 1 | ||||
| En-tête redirigée | présent | ||||
| MTU | possible |
En plus des cinq options générales décrites dans le tableau 1, il existe d'autres options spécifiques pour la mobilité et les réseaux NBMA (Non Broadcast Multiple Access) comme le montre le tableau 2. La liste complète des options pour NDP est gérée par l'IANA et se retrouve sur une page web[2].
| type | description | Message |
|---|---|---|
| Basic Neighbor Discovery options [RFC 4861] | ||
| 1 | Source Link-layer Address (SLLAO) | RS/RA/NS |
| 2 | Target Link-layer Address | NA/Redirect |
| 3 | Prefix Information (PIO) | RA |
| 4 | Redirected Header | Redirect |
| 5 | MTU | RA |
| NBMA (unused) [RFC 2491] | ||
| 6 | NBMA Shortcut Limit Option | NS |
| Mobile IP [RFC 6275] | ||
| 7 | Advertisement Interval Option | RA |
| 8 | Home Agent Information Option | RA |
| 9 | Source Address List | |
| 10 | Target Address List | |
| SEND [RFC 3971] | ||
| 11 | CGA option | |
| 12 | RSA Signature option | |
| 13 | Timestamp option | |
| 14 | Nonce option | |
| 15 | Trust Anchor option | |
| 16 | Certificate option | |
| Mobility options | ||
| 17 | IP Address/Prefix Option [RFC 5568] | |
| 18 | New Router Prefix Information Option [RFC 5568] | |
| 19 | Link-layer Address Option [RFC 5568] | |
| 20 | Neighbor Advertisement Acknowledgment Option [RFC 5568] | |
| 23 | MAP Option [RFC 5380] | |
| SLAAC optimization | ||
| 24 | Route Information Option [RFC 4191] | |
| 25 | Recursive DNS Server Option [RFC 8106] | RA |
| 26 | RA Flags Extension Option [RFC 5175] | |
| Fast Mobility options | ||
| 27 | Handover Key Request Option | [RFC 5269] |
| 28 | Handover Key Reply Option | [RFC 5269] |
| 29 | Handover Assist Information Option | [RFC 5271] |
| 30 | Mobile Node Identifier Option | [RFC 5271] |
| 6LoWPAN [RFC 6775] | ||
| 33 | Address Registration (ARO) | |
| 34 | 6LoWPAN Context (6CO) | |
| 35 | Authoritative Border Router (ABRO) | |
| 38 | PREF64 [RFC 8781] | RA |
| 157 | Duplicate Address Request (DAR) | |
| 158 | Duplicate Address Confirmation (DAC) | |
| Inverse Neighbor Discovery [RFC 3122] | ||
| 138 | CARD Request option | [RFC 4065] |
| 139 | CARD Reply option | [RFC 4065] |
Adresse physique de la source/cible
La figure "Format de l'option adresse physique source/cible" donne le format de ces options. Le type 1 est réservé à l'adresse physique de la source et le type 2 à l'adresse de la cible.
Le champ «longueur» est la taille en mots de 64 bits de l'option. Dans le cas d'une adresse MAC, d'une longueur de 6 octets, il contient donc la valeur 1.
Le RFC 2464 définit le format pour les adresses MAC-48 utilisés dans les réseaux Ethernet et Wi-Fi. Le RFC 4944 définit le format pour les MAC-16 et MAC-64 utilisés dans les réseaux de capteurs reposant sur la norme IEEE 802.15.4.
Information sur le préfixe
Cette option contient les informations sur le préfixe pour permettre une configuration automatique des équipements. Cette option sera présentée en détail dans l'activité d'autoconfiguration.
En-tête redirigée
Cette option est utilisée par le message d'indication de redirection. Elle permet d'encapsuler les premiers octets du paquet IPv6 qui a provoqué l'émission de ce message comme dans le cas des messages ICMPv6 d'erreur.
Le type vaut 4 et la taille de cette option ne doit pas conduire à un paquet IPv6 dépassant 1280 octets (cf. figure Format de l'option en-tête redirigée). Par contre le paquet doit contenir le maximum d'information possible.
MTU
Cette option permet d'informer les équipements sur la taille maximale des données pouvant être émises sur le lien. La figure "Format de l'option MTU" donne le format de cette option. Il n'est pas nécessaire de diffuser cette information si l'équipement utilise toujours la taille maximale permise. Par exemple, sur les réseaux Ethernet, les équipements utiliseront la valeur 1 500. Par contre pour les réseaux anneau à jeton ou FDDI, il est souvent nécessaire de préciser si les équipements doivent utiliser la valeur maximale permise ou une valeur inférieure pour autoriser l'utilisation de ponts.
Le champ type vaut 5 et le champ longueur 1.
Référence bibliographique
- ↑ Sébastien LOYE. (2005). Techniques de l'ingénieur. ref TE7527. Le multicast IP : principes et protocoles
- ↑ IANA. IPv6 Neighbor Discovery Option Formats
Pour aller plus loin
RFC et leur analyse par S. Bortzmeyer
- RFC 2710 Multicast Listener Discovery (MLD) for IPv6
- RFC 2894 Router Renumbering for IPv6
- RFC 3122 Extensions to IPv6 Neighbor Discovery for Inverse Discovery Specification
- RFC 3971 SEcure Neighbor Discovery (SEND) Analyse
- RFC 3810 Multicast Listener Discovery Version 2 (MLDv2) for IPv6
- RFC 4065 Instructions for Seamoby and Experimental Mobility Protocol IANA Allocations
- RFC 6275 Mobility Support in IPv6
