Activité 31 : Contrôler le fonctionnement du réseau par ICMPv6

Introduction

Le bon fonctionnement de la couche réseau est supervisé par le protocole ICMPv6 (Internet Message Control Protocol) [RFC 4443]. Tout comme ICMP pour IPv4, ICMPv6 s'appuie sur IPv6 pour réaliser ses fonctions. La famille des protocoles ICMP donne les informations sur l'état de marche du réseau. Elle rapporte également les erreurs quand un paquet ne peut être traité correctement. On distingue 3 fonctions propres à ICMP :

• le signalement d'erreur en cours d'acheminement d'un paquet,
• le test d'accessibilité d'un noeud,
• la configuration automatique des équipements.

À la différence d'ICMP pour IPv4, qui comporte également ces trois fonctions, ICMPv6 intègre les fonctions de gestion des groupes de multicast (Multicast Listener Discovery (MLD)) et de résolution d'adresse IP en adresse physique. En IPv4 ces fonctions étaient assurées par des protocoles annexes (la gestion des groupes etait du ressort de IGMP (Internet Group Management Protocol), et la résolution d'adresse, du protocole ARP (Address Resolution Protocol). La résolution d'adresse en IPv6 s'effectue par la procédure de découverte des voisins (Neighbor Discovery Protocol(NDP)). La notion de voisinage est définie par la connectivité au lien. Deux noeuds connectés sur le même lien sont des voisins. Ils partagent le même préfixe réseau. Un lien est, par exemple, un domaine de diffusion Ethernet bordé par au moins un routeur. ICMPv6 comporte aussi des fonctions pour la mobilité IP. Il en ressort qu'ICMPv6 est bien plus complet que son prédécesseur. Non seulement ICMPv6 rapporte les erreurs, mais pour les mécanismes d'autoconfiguration ou de découverte du voisinage il est un élément indispensable dans le service de connectivité offert par la couche de réseau.

Format général d'un message ICMPv6

Les messages ICMPv6 sont encapsulés directement dans un paquet IPv6. Le protocole se voit attribuer le numéro 58 pour être représenté dans l'en-tête IPv6 comme prochain en-tête (champ Next Header). Le format général des messages ICMPv6 est donné par la figure 1. L'en-tête des messages ICMPv6 comporte 3 champs :

1. Le champ Type : il indique la nature du message ICMPv6 et, donc, le format spécifique du message. Les messages ICMPv6 forment 2 groupes : un groupe pour les messages d'informations et un autre pour les messages d'erreurs. Les groupes sont identifiés par le bit de poids fort de ce champ. Les messages d'erreurs ont ce bit à zéro et, donc, le champ Type prendra, pour ces messages, une valeur comprise entre 0 et 127. Les messages d'informations sont identifiés par un champ Type dont la valeur est comprise entre 128 et 255.
2. Le champ Code s'interprète dans le contexte du type de message. Il est utilisé pour ajouter une granularité plus fine au type.
3. Le champ Checksum sert à vérifier l'intégrité du message ICMP. Il porte aussi bien sur l'en-tête du message que sur sa charge utile.

Figure 1 : Format d'un message ICMPv6.

La charge utile du message ICMPv6 (message body) est relative au contexte fonctionnel.

• Dans le cas des messages de compte rendu d'erreur elle contient, le paquet IPv6 ayant provoqué l'erreur. Pour éviter d'avoir à fragmenter, la longueur du message ICMPv6 est limitée à 1 280 octets. Par conséquent, le contenu du paquet IPv6 renvoyé peut être tronqué.
• Pour les message de dévouverte du voisinage la charge utile est composée de différentes options selon qu'il s'agit d'une sollicitation de voisin ou d'une annonce de voisin.
• Les messages de test d'accessibilité embarque des données de taille et de contenu quelconque.

Les messages sont spécifiés dans différents RFC. Cependant, la liste complète des types de messages et les différents paramètres associés sont regroupés par l'IANA (Internet Assigned Number Authority)^[1]. Le tableau 1 présente les valeurs et les codes définis dans le RFC 4443. Ce qu'il faut noter, c'est que les valeurs de type inférieures à 128 sont pour les messages d'erreurs et qu'à partir de 128, ce sont des messages d'informations.

Type	Code	Signification
Message de compte rendu d'erreur
1		Destination inaccessible :
	0	Aucune route vers la destination.
	1	La communication avec la destination est administrativement interdite.
	2	Hors portée de l'adresse source.
	3	L'adresse est inaccessible.
	4	Le numéro de port est inaccessible.
	5	L'adresse source est filtrée par un firewall.
	6	L'adresse destination est rejetée.
2		Paquet trop grand.
3		Délai expiré :
	0	Limite du nombre de sauts atteinte.
	1	Temps de réassemblage dépassé.
4		Erreur de paramètre :
	0	Champ d'en-tête erroné.
	1	Champ d'en-tête suivant non reconnu.
	2	Option non reconnue.
Message d'information
128		Demande d'écho
129		Réponse d'écho

Tableau 1 : Messages ICMPv6 décrit dans le RFC 4443.

Test d'accessibilité d'un noeud

Les test d'accessibilté très couramment utilisé, notamment à l'aide du célébre outil nommé ping, est fondé sur l'échange de deux messages ICMPv6, la demande d'écho (echo request) de type 128 et la réponse d'écho (echo reply) de type 129.

Figure 2 : Format du message d'écho.

Le principe de fonctionnement est le même que pour IPv4. Une requête (type 128) est envoyée vers le noeud dont on veut tester la connectivité. Ce dernier répond par le message réponse d'écho (type 129). Le format de ces 2 messages est présenté par la figure 2. Les réponses sont identifiées par le champ identifiant. Ainsi, la réponse est rapprochée de la requête. Ceci est particulièrement utile quand plusieurs commandes ping sont exécutées simultanément sur la machine. Le champ numéro de séquence complète le mécanisme de rapprochement de la réponse à la requête et va servir à mesurer la durée d'aller et retour dans le cas où les demandes sont émises en continu et que le délai de propagation est élevé. La réponse doit toujours contenir les mêmes valeurs que la requête pour ces 2 champs. Le champ données permet d'augmenter la taille du message (et donc la durée de transmission) pour les mesures.

Pour illustrer le test d'accessibilité, observons l'échange suivant : Le noeud nommé "Uma" teste la connectivité du noeud "Ganesha" via la commande ping6. La commande entrée sur Uma est la suivante :

uma# ping6 ganesha
trying to get source for ganesha
source should be 2001:db8:12:3:a00:20ff:fe0a:aa6d
PING ganesha (2001:db8:12:3::3): 56 data bytes
64 bytes from 2001:db8:12:3::3: icmp6_seq=0 ttl=255 time=5.121 ms

Les traces des messages ICMPv6 suivants obtenus

• Le noeud "Uma", qui est l'initiateur, envoie un message ICMPv6 Demande d'écho. La trace 1 montre un paquet IPv6 contenant un message ICMPv6 Demande d'écho (en bleu dans la trace).

Version : 6	Classe : 0x00	Label : 000000 Longueur : 64 octets (0x0040)
Protocole : 58 (0x3a, ICMPv6)
Nombre de sauts : 64 (0x40)
Source : 2001:db8:12:3:a00:20ff:fe0a:aa6d (Uma) 
Desti. : 2001:db8:12:3::3 (Ganesha) 
ICMPv6  
Type : 128 (0x80, Demande d'écho)	Code : 0 Checksum : 0xcfe8
Identificateur : 0x0e02	Numéro de séquence : 0x0001 
Données : b6e0 f056 ...

0000:  6000 0000 0040 3a40 2001 0db8 0012 0003
0010:  0a00 20ff fe0a aa6d 2001 0db8 0012 0003
0020:  0000 0000 0000 0003|80|00|cfe8|0e02|0001|
0030:  b6e0 f056 d947 0700 0809 0a0b 0c0d 0e0f
0040:  1011 1213 1415 1617 1819 1a1b 1c1d 1e1f
0050:  2021

Trace 1 : Message ICMPv6 Demande d'écho.

• Le destinataire du message "Demande d'écho", qui est Ganesha sur la figure 10, acquitte ce message en retournant un message ICMPv6 Réponse d'écho (voir la trace 2).

Version : 6	Classe : 0x00	Label : 000000 Longueur : 64 octets (0x0040)
Protocole : 58 (0x3a, ICMPv6)
Nombre de sauts : 64 (0x40)
Source : 2001:db8:12:3::3 (Ganesha)
Desti. : 2001:db8:12:3:a00:20ff:fe0a:aa6d (Uma)  
ICMPv6  
Type : 129 (0x81, Réponse d'écho)	Code : 0 Checksum : 0xcee8
Identificateur : 0x0e02	Numéro de séquence : 0x0001 
Données : b6e0 f056 ...

0000:  6000 0000 0040 3a40 2001 0db8 0012 0003
0010:  0000 0000 0000 0003 2001 0db8 0012 0003
0020:  0a00 20ff fe0a aa6d|81|00|cee8|0e02|0001|
0030:  b6e0 f056 d947 0700 0809 0a0b 0c0d 0e0f
0040:  1011 1213 1415 1617 1819 1a1b 1c1d 1e1f
0050:  2021

Trace 2 : Message ICMPv6 Réponse d'écho.

Rapport d'erreur

ICMPv6 permet de signaler à l'émetteur d'un paquet, un problème dans son acheminement ou dans sa réception, par des messages de rapport d'erreur. Lorsqu'une machine émet un paquet, si une erreur est détectée par le destinataire ou par tout routeur intermédiaire le long du chemin vers le destinataire alors l'élément qui détecte l'erreur renvoie à l'émetteur un rapport sous la forme d'un message ICMPv6. Le type du message et son code définissent précisément l'erreur détectée. L'extrait, jusqu'à concurence de 1280 octet du paquet en défaut, est incluse pour permettre l'analyse de l'erreur. L'exemple ci dessous illustre un message ICMP Paquet trop grand, généré par un routeur intermédiaire dès qu'un datagramme ne peut être retransmis en raison de la limitation de la MTU sur son interface de sortie.

Figure 4 : Format du message ICMPv6 Paquet trop grand.

Différentes erreurs peuvent être signalées par ICMPv6, les cas les plus courants :

• destination innacessible (type 1), la raison est précisé par le champ code,
• paquet trop grand (type 2),
• délai expiré (type 3),
• erreur de paramètre (type 4),

Nota : une description de ces messages ICMPv6 est disponible dans le document annexe à cette activité MOOC:Annexe_Compagnon_Act31

Découverte des voisins

La découverte des voisins ou NDP (Neighbor Discovery Protocol) est décrite par le RFC 4861. Ce RFC, paru en 2007, est la troisième et dernière version du protocole. On parle de protocole car les messages utilisés par NDP sont encapsulés dans les paquets IPv6, de la même manière qu'ICMPv6. En fait, on peut voir NDP comme un sous-protocole d'ICMPv6. NDP vise à gérer les interactions entre un noeud et ses voisins. Les voisins sont les noeuds qui partagent une même connectivité physique. Dans la terminologie IPv6, on parle de lien. Avec NDP, un noeud est capable de dialoguer avec les équipements connectés au même support (hôtes et routeurs). Il ne s'agit pas, pour un noeud, de connaître exactement la liste de tous les autres noeuds connectés sur le lien, mais uniquement de gérer ceux avec qui il dialogue.

Le protocole utilise cinq types de messages ICMPv6, comme le montre le tableau 3. Nous allons, dans la suite de ce paragraphe, nous intéresser à 2 fonctions de NDP :

• la détermination de l'adresse physique d'un équipement à partir de son adresse IP,
• la détection d'adresses IP dupliquées.

Ces fonctions sont réalisées à travers 2 messages ICMPv6 : Sollicitation de voisin (Neighbor Sollicitation ou NS) et Annonce d'un voisin (Neighbor Advertisment ou NA). La fonction de découverte du routeur et d'auto-configuration sera présentée dans une autre activité.

Type	Code	Signification
Découverte de voisins
133		Sollicitation du routeur
134		Annonce du routeur
135		Sollicitation d'un voisin
136		Annonce d'un voisin
137		Redirection
Découverte de voisins inverse (RFC 3122)
141		Sollicitation
142		Annonce
Découverte de voisins sécurisée (SEND, RFC 3971)
148		Sollicitation de chemin de certification
149		Annonce de chemin de certification

Tableau 3 : Messages ICMPv6 pour les interactions entre voisins

Format des messages mis en oeuvre

Avant d'étudier la procédure, nous allons présenter le format des messages impliqués.
Les messages ICMPv6 pour NDP sont encapsulés dans des paquets IPv6. Il est intéressant de souligner que le champ nombre de sauts de l'en-tête IPv6 contient la valeur 255. Cette valeur peut sembler trop grande pour des datagrammes qui ne doivent pas être routés hors du lien physique. En fait, si un noeud reçoit un datagramme avec une valeur plus petite, cela signifie que l'information provient d'un autre réseau et qu'elle a déjà traversé un routeur. Les datagrammes ayant une valeur différente de 255 doivent être ignorés par le récepteur.

Message Sollicitation d'un voisin

Le message de la figure 8 sert à demander des informations d'un noeud voisin, c'est-à-dire situé sur le même lien physique (ou connecté via des ponts). Le message peut lui être explicitement envoyé, ou émis sur une adresse multicast. Dans le cas de la détermination de l'adresse physique, il a la même fonction qu'une requête ARP du protocole IPv4.

Le champ adresse source du paquet IPv6 contient, soit l'adresse locale au lien, soit une adresse globale, soit l'adresse non spécifiée. Le champ adresse destination contient, soit l'adresse de multicast sollicité correspondant à l'adresse recherchée, soit l'adresse d'un noeud dans le cas d'une détection d'inaccessibilité des voisins (Neighbor Unreachability Detection NUD)

Le champ adresse de la cible contient l'adresse IPv6 du noeud recherché. Le champ option contient, en général, l'adresse physique de la source.

Figure 8 : Format du message de Sollicitation d'un voisin.

Message Annonce d'un voisin

Le message de la figure 9 est émis en réponse à une sollicitation, mais il peut aussi être émis spontanément pour propager une information de changement d'adresse physique, ou de statut routeur. Dans le cas de la détermination d'adresse physique, il correspond à la réponse ARP du protocole IPv4. L'adresse de la cible, dans ce cas-là, correspond à l'adresse de la source de ce message.

Les champs de ce message ont la signification suivante:

• Le bit R est mis à 1 si l'émetteur est un routeur.
• Le bit S mis à 1 indique que cette annonce est émise en réponse à une sollicitation.
• Le bit O mis à 1 indique que cette annonce doit effacer les informations précédentes qui se trouvent dans les caches des autres équipements, en particulier la table contenant les adresses physiques.
• Le champ adresse de la cible reprend l'adresse de la cible de la sollicitation auquel ce message répond (le bit S vaut 1 dans ce cas). Si le message d'annonce de voisin est envoyé sans sollicitation, il s'agit, pour l'émetteur, d'indiquer une nouvelle adresse "lien-local". Le champ adresse de la cible contient alors cette nouvelle adresse "lien-local".
• L'option adresse physique de la cible contient l'adresse physique de l'émetteur.

Figure 9 : Format du message d'annonce d'un voisin.

Fonctionnement de la résolution d'adresse IP

La résolution d'adresse est la procédure par laquelle l'adresse IP d'un voisin est mise en correspondance avec son adresse physique. C'est la même fonction que ARP en IPv4. Les messages utilisés seront NS et NA dont nous venons de voir le format. Pour illustrer le fonctionnement de la résolution d'adresse par NDP, nous prenons l'exemple indiqué par la figure 10 dans lequel les 2 noeuds sont sur le même lien. Sur la figure, les adresses physiques, dites MAC, et IPv6 sont indiquées. Pour chaque niveau d'adresse, les adresses multicast, en plus des adresses unicast, sont indiquées.

Figure 10 : Lien utilisé comme exemple pour la résolution d'adresse IPv6.

Le noeud Uma essaye de tester la connectivité avec Ganesha via la commande ping6. La commande entrée sur Uma est la suivante :

uma# ping6 ganesha
trying to get source for ganesha
source should be 2001:db8:12:3:a00:20ff:fe0a:aa6d
PING ganesha (2001:db8:12:3::3): 56 data bytes
64 bytes from 2001:db8:12:3::3: icmp6_seq=0 ttl=255 time=5.121 ms

Avant de pouvoir émettre un paquet IPv6 sur le réseau, l'émetteur a besoin de connaître l'adresse physique du noeud destinataire. Dans notre exemple, le noeud destinataire est le destinataire final autrement dit le récepteur. Dans d'autre situation, le destinataire est le noeud destinaire de la transmission comme le routeur du lien (next hop). L'émetteur utilise le protocole de découverte des voisins pour découvrir l'adresse physique. Par conséquent, il commence la résolution par l'émission d'un message de sollicitation d'un voisin (NS), comme le montre la trace 3.

Ethernet Src : 8:0:20:a:aa:6d Dst : 33:33:ff:0:0:3 Type : 0x86dd
IPv6
 Version : 6 Classe : 0xf0 Label : 000000
 Longueur : 32 octets (0x0020) Protocole : 58 (0x3a, ICMPv6)
 Nombre de sauts : 255 (0xff)
 Source : 2001:db8:12:3:a00:20ff:fe0a:aa6d (uma)
 Desti. : ff02::1:ff00:3 (multicast sollicité associé à 2001:db8:12:3::3)
ICMPv6
 Type : 135 (0x87, Sollicitation de voisin) Code : 0 Checksum : 0x4d7f
 Cible : 2001:db8:12:3::3 (ganesha)
 Option :
 Type : 1 (Adresse physique source) Lg : 8 octets (0x01) : 08-00-20-0a-aa-6d 

0000: 6f 00 00 00 00 20 3a ff 20 01 0d b8 00 12 00 03
0010: 0a 00 20 ff fe 0a aa 6d ff 02 00 00 00 00 00 00
0020: 00 00 00 01 ff 00 00 03|87|00|4d 7f|00 00 00 00|
0030: 20 01 0d b8 00 12 00 03 00 00 00 00 00 00 00 03|
0040: 01|01|08 00 20 0a aa 6d

Trace 3: Message ICMPv6 Sollicitation de voisin(NS).

Dans l'en-tête IPv6, l'adresse de la source est l'adresse globale de l'interface d'émission de Uma. On aurait pu penser que l'émetteur utiliserait l'adresse locale au lien comme adresse de source. L'utilisation de l'adresse source globale, comme on le verra par la suite, permet au destinataire de remplir directement sa table de correspondance avec l'adresse physique associée à l'adresse IPv6 de l'émetteur puisque le destinataire trouvera dans l'option du message NS l'adresse physique de l'émetteur.
L'adresse de destination est l'adresse de multicast sollicitée associée à l'adresse recherchée, et l'adresse Ethernet de destination est l'adresse associée à cette adresse multicast [RFC 2464].

Le message NS apparait en bleu dans la trace. Le format du message est représenté par la figure 8. Ce message NS contient, dans le champ cible, l'adresse IPv6 du noeud pour laquelle l'adresse physique est recherchée. Dans notre cas, il s'agit de l'adresse de Ganesha. On peut remarquer que les trois derniers octets correspondent au groupe de multicast de l'adresse de destination dans l'en-tête IPv6. Le champ option contient l'adresse physique de l'émetteur de la requête, à savoir celle d'Uma.

Le noeud Ganesha, qui écoute les groupes multicast dont le ou les groupes multicast sollicités associés à ses adresses, reçoit le message NS. Il reconnaît dans le champ Cible une de ses adresses IPv6. Il y répond par un message NA dont le format est rappelé par la figure 9. La trace 4 montre la réponse émise.

Ethernet Src : 1a:0:20:c:7a:34 Dst : 8:0:20:a:aa:6d Type : 0x86dd
IPv6
 Version : 6 Classe : 0xf0 Label : 000000
 Longueur : 32 octets (0x20) Protocole : 58 (0x3a, ICMPv6)
 Nombre de sauts : 255 (0xff)
 Source : fe80::1800:20ff:fe0c:7a34 (ganesha, lien-local)
 Desti. : 2001:db8:12:3:0a00:20ff:fe0a:aa6d (uma)
ICMPv6
 Type : 136 (0x88, Annonce de voisin) Code : 0 Checksum : 0xd7fb
 Bits (0x7) R = 1, S = 1, O = 1
 Cible : 2001:db8:12:3::3 (ganesha)
 Option :
 Type : 2 (Adresse physique cible) Lg : 8 octets (0x01) : 1a-00-20-0c-7a-34

Trace 4: Message ICMPv6 Annonce de voisin(NA).

L'adresse source utilisée par Ganesha est celle de portée locale au lien. Le bit R indique que le noeud qui répond a une fonction de routeur. Le bit S indique que ce message est une réponse à une demande explicite (le message précédent). Le bit O indique que cette réponse doit remplacer toute valeur connue précédemment. Le champ Cible rappelle l'adresse IPv6. Le champ Option donne l'adresse physique recherchée.

L'adresse physique ainsi obtenue est ensuite enregistrée dans une table de correspondance du noeud émetteur, appelée cache des voisins. De cette manière, l'émetteur n'a pas besoin de redemander l'adresse physique d'un même destinataire à chaque paquet. Ce cache est maintenu à jour par une procédure de détection d'injoignabilité (Neighbor Unreachability Detection (NUD)), reposant sur les mêmes messages.

Un fois la résolution d'adresse terminée, les messages ICMPv6 pour le test d'accessibilité peuvent être échangés. Ces messages "Demande d'écho" et "Réponse d'écho" ont été présentés précédemment dans le paragraphe "Test d'accessibilité d'un noeud".

Tant que la commande ping6 n'est pas arrêtée, les échanges de messages d'écho s'effectuent alors à intervalle de temps régulier. Au bout d'un certain temps, et périodiquement, les noeuds vérifieront que leur voisin est toujours correct en utilisant la procédure NUD. Le voisin a pu tomber en panne ou être remplacé avec changement d'adresse Ethernet. Aussi, de temps en temps, chaque noeud va émettre un message NS. Une réponse NA (avec le bit S) confirmera que le voisin (ici le correspondant) est toujours valide. Nous montrons par les traces 5 et 6 un échange NUD. Il s'agit du noeud Ganesha qui lance une vérification de la validité du noeud Uma.

IPv6
 Version : 6 Classe : 0x00 Label : 000000
 Longueur : 32 octets (0x20) Protocole : 58 (0x3a, ICMPv6)
 Nombre de sauts : 255 (0xff)
 Source : fe80::1800:20ff:fe0c:7a34        (ganesha, lien-local)
 Desti. : 2001:db8:12:3:a00:20ff:fe0a:aa6d (uma)
ICMPv6
 Type : 135 (0x87, Sollicitation de voisin) Code : 0 Checksum : 0x1116
 Cible : 2001:db8:12:3:a00:20ff:fe0a:aa6d (ganesha)
 Option :
 Type : 1 (Adresse physique source) Lg : 8 octets (0x01) : 1a-00-20-0c-7a-34

 0000:  6000 0000 0020 3aff fe80 0000 0000 0000
 0010:  1800 20ff fe0c 7a34 2001 0db8 0012 0003
 0020:  0a00 20ff fe0a aa6d|8700 1116 0000 0000
 0030:  2001 0db8 0012 0003 0a00 20ff fe0a aa6d
 0040:  0101 1a00 200c 7a34

Trace 5: Message ICMPv6 Sollicitation de voisin(NS).

On remarque que le message de sollicitation est envoyé par une communication unicast avec l'adresse IPv6 qui est enregistrée dans les tables de correspondance. Si une réponse n'arrive pas, la machine émettrice effacera l'entrée de son cache "Résolution de voisin". Tout trafic ultérieur reprendra l'enquête de résolution au début, avec utilisation de l’adresse multicast sollicitée.
La réception du message "Annonce voisin" (NA) par Ganesha apporte la confirmation que son voisin est toujours accessible. Ce dernier, qui est Uma, indique son adresse dans le champ cible du message d'Annonce de voisin.

IPv6
 Version : 6 Classe : 0x00 Label : 000000
 Longueur : 24 octets (0x18) Protocole : 58 (0x3a, ICMPv6)
 Nombre de sauts : 255 (0xff)
 Source : 2001:db8:12:3:a00:20ff:fe0a:aa6d (uma)
 Desti. : fe80::1800:20ff:fe0c:7a34        (ganesha, lien-local)
ICMPv6
 Type : 136 (0x88, Annonce de voisin) Code : 0 Checksum : 0x855f
 Bits (0x4) R = 0, S = 1, O = 0
 Cible : 2001:db8:12:3:a00:20ff:fe0a:aa6d (uma)

 0000:  6000 0000 0018 3aff 2001 0db8 0012 0003
 0010:  0a00 20ff fe0a aa6d fe80 0000 0000 0000
 0020:  1800 20ff fe0c 7a34|8800 855f 4000 0000
 0030:  2001 0db8 0012 0003 0a00 20ff fe0a aa6d

Trace 6: Message ICMPv6 Annonce de voisin(NA).

Fonctionnement de la détection d'adresse dupliquée

Pour vérifier l'unicité des adresses lien-local ou unicast qui viennent d'être configurées manuellement ou automatiquement sur leurs interfaces, les machines doivent exécuter un algorithme de Détection d'Adresse Dupliquée (DAD) avant de les utiliser [RFC 4862]. L'algorithme utilise les messages ICMPv6 "sollicitation d'un voisin" et "annonce d'un voisin". Si une adresse déjà en service est découverte, elle ne pourra être attribuée à l'interface. L'auto-configuration s'arrête et une intervention humaine devient obligatoire.

Une adresse est qualifiée de "provisoire" pendant l'exécution de l'algorithme DAD et ce jusqu'à la confirmation de son unicité. Une adresse provisoire ne peut servir pour les communications. Elle ne peut être utilisée dans une en-tête de paquet IPv6. On ne peut que la trouver dans le champ cible des messages de sollicitation et d'annonce d'un voisin. L'algorithme DAD consiste à envoyer un message "sollicitation d'un voisin" avec, dans le champ adresse de la cible, l'adresse provisoire. Afin de distinguer l'algorithme DAD de celui de découverte des voisins, le paquet IPv6 contenant un message de sollicitation d'un voisin a comme adresse de source l'adresse indéterminée. Trois cas se présentent :

1. Un message "annonce d'un voisin" est reçu : l'adresse provisoire est utilisée comme adresse valide par une autre machine. L'adresse provisoire n'est pas unique et ne peut être retenue.
2. Un message "sollicitation d'un voisin" est reçu dans le cadre d'une procédure DAD : l'adresse provisoire est également une adresse provisoire pour une autre machine. L'adresse provisoire ne peut être utilisée par aucune des machines.
3. Rien n'est reçu au bout d'une seconde (valeur par défaut) : l'adresse provisoire est unique. Elle passe de l'état provisoire à celui de valide et elle est assignée à l'interface.

La trace affichée par la commande tcpdump ci-dessous illustre le premier cas. Un hôte active son interface réseau, et après avoir constitué une adresse unicast par auto-configuration, effectue une DAD (nous verrons le détail de la construction de l'adresse dans la prochaine activité). Comme l'adresse provisoire n'est pas unique, un message de NA est reçu pour signaler que cette adresse est une adresse valide d'un autre noeud sur le lien.

1 IP6 :: > ff02::1:ff02:202: ICMP6, neighbor solicitation, who has 2001:db8:b:2:fd:c8ff:fe02:202
2 IP6 2001:db8:b:2:fd:c8ff:fe02:202 > ff02::1: ICMP6, neighbor advertisement, tgt is 2001:db8:b:2:fd:c8ff:fe02:202

Nota : Le format de la trace consiste ici en un numéro de ligne, le protocole, l'adresse de la source, l'adresse de destination et le message ICMPv6.

A noter que la procédure DAD n'offre pas une fiabilité absolue ; notamment lorsque le lien est coupé.

Conclusion

Cette activité a présenté les fonctions assurées par le protocole ICMPv6. Ce protocole est en effet indispensable au bon fonctionnement de la couche réseau. Par ce protocole, les défauts qui peuvent affecter la connectivité IPv6 peuvent être connus et, donc, corrigés.
A l'échelle de l'Internet, le bon acheminement d'un paquet IPv6 est contrôlé et les défauts sont notifiés à l'émetteur par des messages ICMPv6. Ainsi, en cas de non-livraison d'un paquet, les informations fournies par ICMPv6 vont servir à découvrir le problème et à adapter la communication si besoin est. A l'échelle du lien, c'est à travers le protocole ICMPv6 que les noeuds se découvrent entre eux, vérifient l'unicité de leurs adresses et gèrent les abonnements aux groupes multicast.

Références bibliographiques

1. ↑ IANA. Internet Control Message Protocol version 6 (ICMPv6) Parameters

Pour aller plus loin

RFC et leur analyse par S. Bortzmeyer :

• RFC 1191 Path MTU Discovery
• RFC 1981 Path MTU Discovery for IP version 6 Analyse
• RFC 2464 Transmission of IPv6 Packets over Ethernet Networks
• 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 4429 Optimistic Duplicate Address Detection (DAD) for IPv6
• RFC 4443 Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification Analyse
• RFC 4620 IPv6 Node Information Queries
• RFC 4861 Neighbor Discovery for IP version 6 (IPv6) Analyse
• RFC 4862 IPv6 Stateless Address Autoconfiguration Analyse
• RFC 4890 Recommendations for Filtering ICMPv6 Messages in Firewalls
• RFC 6275 Mobility Support in IPv6