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

Comme pour IPv4, en IPv6, 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 les erreurs quand un paquet ne peut être traité. 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.

A la différence d'ICMP pour IPv4, qui comporte 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. Pour rappel, en IPv4 la gestion des groupe est 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(ND)). La notion de voisinage est définie par la connectivité au lien. 2 noeuds connectés sur le même lien sont des voisins. Ils partagent exactement le même préfixe réseau. 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 il est devenu 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'information et un autre pour les messages d'erreur. Les groupes sont identifiés par le bit de poids fort de ce champ. Les messages d'erreur ont se bit à zéro et donc le champ type prendra avec le valeur de 0 à 127. Les messages d'information sont identifiés par un 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 sa charge utile.

Figure 1: Format d'un message ICMPv6.

Les messages ICMPv6 de compte rendu d'erreur contiennent dans la partie charge utile (message body) le paquet IPv6 ayant provoqué l'erreur. Pour éviter d'avoir à fragmenter, la longueur du message ICMPv6 est limitée à 1 280 octet. Par conséquent le contenu du paquet IPv6 renvoyé peut être tronqué.

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.

Type	Code	Signification
Message de gestion des erreurs
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
Messages 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

Figure 2: Format du message d'echo.

Ces deux messages sont utiliser par la commande ping. Ils servent à vérifier l'accessibilité d'un noeud. 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 identificateur. 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 le temps 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 le temps de transmission) pour les mesures.

Pour illustrer le test d'accessibilité, nous prenons comme exemple le réseau indiqué par la figure 10. Les messages ICMPv6 suivants ont été obtenus lors d'un ping entre deux noeuds IPv6. Le noeud Uma qui est l'initiateur envoie un message ICMPv6 Demande d'écho. Le trace du message ICMPv6 Demande d'écho apparait 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.

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, Demande 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

Chaque cas d'erreur est défini par un message ICMP. Nous allons voir les cas d'erreur rapporté par ICMPv6.

Destination inaccessible

Un message ICMP Destination Unreachable est généré dès qu'un datagramme ne peut être traité. Le format de ce message est présenté par la figure 3.

Figure 3: Format du message de Destination inaccessible.

Ce message est émis par un routeur quand le paquet ne peut pas être transmis parce que soit :

• le routeur ne trouve pas dans ses tables la route vers la destination (code = 0) ;
• le franchissement d'un pare-feu (Firewall) est interdit ("raison administrative", code = 1) ;
• l'adresse destination ne peut être atteinte avec l'adresse source fournie, par exemple si le message est adressé à un destinataire hors du lien, l'adresse source ne doit pas être une adresse lien-local (code = 2) ;
• toute autre raison comme par exemple la tentative de routage d'une adresse locale au lien (code = 3) ;
• le destinataire peut aussi émettre un message ICMPv6 de ce type quand le port destination contenu dans le paquet n'est pas affecté à une application (code = 4) ;
• le paquet a été rejeté à cause de son adresse source (code = 5) ;
• la route vers la destination conduit a un rejet du paquet (code = 6).

Le champ de données contient tout ou partie du datagramme IP qui a occasioné ce message d'erreur.

Paquet trop grand

Si un routeur ne pas relayer le datagramme IP car celui ci a une taille supérieure à la MTU (Maximum Transmission Unit) du lien de sortie, il émet le message d'erreur Packet Too Big. Les routeurs en IPv6 ne sont plus habilités à effectuer la fragmentation. Le format du message est représenté par la figure 4.

Figure 4: Format du message ICMPv6 Paquet trop grand.

Ce message ICMPv6 est utilisé par le protocole de découverte de la MTU pour trouver la taille optimale des paquets IPv6 afin qu'ils puissent traverser les routeurs. Ce mécanisme, spécifié par le RFC 1981, est décrit dans la séquence 2. Ce message contient la taille du MTU acceptée par le routeur pour que la source puisse efficacement adapter la taille des données. Ce champ manquait cruellement dans les spécifications initiales de IPv4, ce qui compliquait la découverte de la taille maximale des paquets utilisables sur l'ensemble du chemin. Pour IPv4, le RFC 1191 proposait déjà une modification du comportement des routeurs pour y inclure cette information. A noter que le RFC 4443 indique que ce message n'est pas produit dans le cas d'une communication multicast.

Délai expiré

Quand un routeur relaie un datagramme, il décrément la valeur du Hop Limit de 1. Ce champ dans l'en-tête IPv6 limite la durée de vie d'un paquet dans le réseau. La durée de vie est exprimée en nombre de routeurs traversés. Dans ce cas, on parle de sauts. Si un routeur reçoit un datagramme avec un hop limit de 1. La décrémentation amène la valeur de ce champ à zéro. Le routeur supprime le datagramme et en avertit la source à l'aide du message Time Exceeded.

Figure 5: Format du message de délai expiré.

Ce message indique que le paquet a été rejeté par le routeur :

• soit parce que le champ nombre de sauts a atteint 0 (code = 0) ;
• soit qu'un fragment s'est perdu et le temps alloué au réassemblage a été dépassé (code = 1).

Ce message est à la base de la commande traceroute. Cette commande vise à déterminer le chemin pris par les datagrammes ^[2].

Erreur de paramètre

Le message Parameter problem est émis quand un paquet IPv6 ne peut être traité par un noeud du fait d'un problème dans l'en-tête du paquet ou dans ses extensions d'en-tête. Le paquet IPv6 est supprimé mais le noeud envoie à la source le message ICMPv6 dont le format est présenté par la figure 6.

Figure 6: Format du message Erreur de paramètre.

Le champ type prend la valeur 4. Le champ code révèle la cause de l'erreur :

• la syntaxe de l'en-tête n'est pas correcte (code = 0) ;
• le numéro en-tête suivant n'est pas reconnu (code = 1) ;
• une option de l'extension (par exemple proche-en-proche ou destination) n'est pas reconnue et le codage des deux bits de poids fort oblige à rejeter le paquet (code = 2).

Le champ pointeur indique l'octet où l'erreur est survenue dans le paquet retourné. Le message contient tout ou partie du paquet IPv6 qui a occasionné le message lui-même.

Attention au filtrage d'ICMPv6

Contrairement à une pratique couramment répandue en IPv4, il ne faut jamais filtrer l'ensemble des messages ICMPv6 en entrée d'un réseau (en particulier le message Paquet trop grand). Le filtrage peut introduire des effets néfastes sur le fonctionnement du réseau. Supposons que la MTU entre un client et un serveur soit limitée à 1480 octets à cause d'un tunnel IPv6 dans IPv4 et qu'un serveur filtre les messages ICMPv6 (en particulier Paquet trop grand). Le client et le serveur vont échanger des petits paquets pour ouvrir la connexion TCP (SYN, SYN ACK, ACK), puis le client va envoyer une requête HTTP qui est elle même de petite taille. Le serveur va répondre en envoyant une page complète, si le paquet a une longueur de 1500 octet, il va être détecté trop grand par le routeur à l'entrée du tunnel. Ce dernier va rejeter le paquet et envoyer au serveur un message ICMPv6 indiquant que le paquet est trop grand. Si le pare-feu du serveur le filtre, le serveur ne sera jamais la taille de la MTU adaptée au chemin qui mène à ce client. Il ne pourra pas adapter la taille de ses paquets. Tous les paquets de 1500 octets seront inexorablement supprimés. Le client devient alors quasiment injoignable et c'est le service de connectivité de la couche de réseau qui est cassé. Dans cette situation, on se trouve dans une situation où certains paquets passent (ouvertures de connexion, ping, sessions SSH,...) et d'autres sont bloquées. Diagnostiquer ce type d'erreur est particulièrement délicat.

Comme ICMPv6 est essentiel au fonctionnement d'IPv6, le RFC 4890 donne les bonnes pratiques pour filtrer correctement les messages ICMPv6. L'idée est laisser passer les messages ICMPv6 qui sont indispensables au fonctionnement du réseau et de jeter ceux qui introduisent un risque d'insécurité.

Gestion de groupe multicast sur le lien-local

Pour offrir un service de distribution multicast, deux composants sont nécessaires : un protocole de gestion de groupe multicast et un protocole de routage multicast^[3]. Le protocole de gestion de groupe 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 à un hôte à indiquer les groupes auxquels il souhaite souscrire. Ainsi un routeur de bordure IPv6 va pouvoir découvrir la présence de récepteurs multicast 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 récepteurs) 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 message 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'entê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.

1. 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.
2. Le second type de message (type = 131) vise à obtenir un rapport d'abonnement multicast (Multicast Listener Report). L'adresse de destination est l'adresse multicast du groupe en question. Le rapport d'abonnement a été complété avec MLDv2 par la possibilité d'indiquer la source pour un groupe multicast. Ceci s'effectue par un message spécifique (type = 143). Dans les deux cas, ce message est émis par le récepteur.
3. 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

Figure 7: Format générique d'un message ICMPv6 pour MLD.

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 recoive 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 à expération 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 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 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.

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

Découverte des voisins

La découverte des voisins ou NDP (Neighbor Discovery Protocol) est décrit 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. On peut voir en fait 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és à travers 2 messages ICMPv6 : Sollicitation d'un 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ée un routeur. Les datagramme ayant une valeur différent 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 à 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 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 c'est le destinataire final. Il faut comprendre le destinataire au sens de la tranmission. Aussi le destinataire est le noeud destinaire de la transmission. Il peut s'agir du prochain routeur (next hop) sur le chemin vers le destinataire final. 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 ci-dessous.

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

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é 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 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 de la réponse est la suivante :

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

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écouverte de non-joignabilité (Neighbor Unreachability Discovery (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'échoont é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 (il a pu tomber en panne ou être remplacé avec changement d'adresse Ethernet) en utilisant la procédure NUD. 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 ci-dessous les traces d'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

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

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

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.

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ée manuellement ou automatique sur leurs interfaces, les machines doivent exécuter un algorithme de Détection d'Adresse Dupliquée (DAD) avant de les utiliser. 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 est assignée à une interface uniquement pour recevoir les messages de sollicitation et d'annonce d'un voisin. Les autres messages reçus sont ignorés. 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 :

• 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.
• 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.
• Rien n'est reçu au bout d'une seconde (valeur par défaut) : l'adresse provisoire est unique, elle passe de l'état de provisoire à celle de valide et elle est assignée à l'interface.

A noter que cet algorithme n'offre pas une fiabilité absolue, notamment lorsque le lien est coupé.

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 noeud (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

Conclusion

Cette activité a présenté les fonctions assurées par le protocole ICMPv6. Ce protocole est en effet crucial au bon fonctionnement de la couche réseau. 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. A l'échelle de l'Internet, ICMPv6 permet de retourner à l'émetteur d'un paquet des informations en cas de non-livraison du paquet.

Références bibliographiques

1. ↑ IANA. Internet Control Message Protocol version 6 (ICMPv6) Parameters
2. ↑ Wikipédia Principe de l'utilitaire traceroute
3. ↑ Sébastien LOYE. (2005). Techniques de l'ingénieur. ref TE7527. Le multicast IP : principes et protocoles

Pour aller plus loin

• RFC 1191 Path MTU Discovery
• RFC 1981 Path MTU Discovery for IP version 6
• RFC 2710 Multicast Listener Discovery (MLD) for IPv6
• RFC 3122
• RFC 3971 SEcure Neighbor Discovery (SEND)
• RFC 3810 Multicast Listener Discovery Version 2 (MLDv2) for IPv6
• RFC 4443 Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification
• RFC 4861 Neighbor Discovery for IP version 6 (IPv6)3122
• RFC 4890 Recommendations for Filtering ICMPv6 Messages in Firewalls