Revision as of 16:09, 3 March 2017

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.

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

• 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

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 grans, 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),

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é.

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

Référence bibliographique

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