ICMPv6

Objectifs du chapitre

L’objectif de ce chapitre est de compléter les informations déjà apportées sur ICMPv6 à propos des mécanismes gérant les voisins et l’autoconfiguration des adresses, en balayant les principaux messages utilisés en ICMPv6 et en comparant le fonctionnement de ce dernier avec celui d’ICMPv4.

Nous gardons ici, comme dans beaucoup de chapitres, les désignations anglaises des paramètres et des valeurs puisque ce sont celles-ci que le lecteur retrouvera communément dans les documents de référence (RFC ou autres) auxquels il pourra avoir accès sur Internet. Quand cela nous semblera pertinent, nous indiquerons néanmoins entre parenthèses la signification française des termes employés.

Rappelons que ICMP signifie Internet Control Message Protocol. Son rôle, aussi bien en version 6 qu’en version 4, est donc bien de véhiculer non pas des données utilisateur mais des informations permettant de gérer les communications entre les différents composants d’un réseau (postes, routeurs, imprimantes, switches...).

Le RFC 4443 de mars 2006 décrit le fonctionnement d’ICMPv6. Il est complété par l’URL http://www.iana.org/assignments/icmpv6-parameters qui permet de pointer sur les différents RFC concernés par les types de messages ICMPv6....

Format des messages ICMPv6

Il existe deux grandes catégories de messages ICMP : les messages d’erreur et les messages d’information.

Le format général est le suivant :

Type sur un octet.
Code sur un octet.
Checksum (somme de contrôle) sur deux octets.
Message Body (corps du message) de taille variable selon le message.

La taille totale d’un paquet ICMP ne doit pas excéder la taille minimale du MTU (Maximum Transmission Unit) qui est de 1280 octets en IPv6. Cela assure une bonne transmission du message, sans aucune fragmentation, dans toutes les circonstances, ce qui est primordial pour des messages de contrôle.

Principaux types

Le tableau ci-dessous résume les valeurs des champs Code et Type différenciant les messages. Il faut noter que pour les messages de type erreur, ce champ va de 0 à 127, alors que pour les messages d’information, il va de 128 à 255 (cela correspond en fait à la valeur du bit le plus à gauche qui est de 0 pour les erreurs et de 1 pour les informations).

Les valeurs définies pour le moment (notamment dans le RFC) pour les deux premiers champs (Type et Code) sont les suivantes :

Type	Message	Code
1	Destination Unreachable	0 - no route 1 - communication administratively prohibited
2	Packet Too Big	0
3	Time Exceeded	0 - hop limit exceeded 1 - fragmentation reassembly time exceeded
4	Parameter Problem	0 - erroneous header field 1 - next header unknown 2 - IPv6 option unknown
100	Private experimentation
101	Private experimentation

127	Reserved for expansion of error messages

128	Echo request
129	Echo Reply
130	Multicast Listener Query
131	Multicast Listener Report
132	Multicast Listener Done
133	Router Solicitation
134	Router Advertisement
135	Neighbor Solicitation
136	Neighbor Advertisement
137	Redirect Message
138	Router Renumbering	0 - router renumbering command 1 - router renumbering result 255 - sequence number reset
139	ICMP Node Query
140	ICMP Node Response
141	Inverse ND Solicitation
142	Inverse ND Adv Message
143	Multicast Listener Report v2
144	ICMP Home Agent Address Discovery Request
145	ICMP Home Agent Address Discovery Reply
146	ICMP Mobile Prefix Solicitation
147	ICMP Mobile Prefix Advertisement
148	Certification Path Solicitation
149	Certification Path Advertisement
151	Multicast Router Advertisment
152	Multicast Router Solicitation
153	Multicast Router Termination...

Fonction et format des principaux messages

Les lecteurs familiers d’ICMPv4 ne seront pas dépaysés car ils vont retrouver en ICMPv6 des messages très proches de ceux qu’ils connaissent déjà. Par contre, les valeurs des champs Type et Code seront différentes.

1. Type 1 - Destination Unreachable

Ce message ICMP indique que l’adresse IPv6 de destination n’est pas accessible. Il est envoyé à l’expéditeur pour signaler ce fait. Le champ Code précisera la cause potentielle de cette inaccessibilité.

Le champ Data contient le paquet d’origine ou seulement une partie de celui-ci (pour ne pas dépasser la taille maximale de 1280 octets pour l’ensemble du paquet ICMPv6 comme vu plus haut).

a. Code 0 - No route to destination

Ce code signifie que l’élément auquel l’expéditeur a confié son paquet ou un routeur intermédiaire ne dispose pas d’une route permettant d’acheminer ce dernier.

Ce message sera donc généré uniquement sur les routeurs (ou des postes si ce sont eux qui font le routage) qui n’ont pas de route par défaut.

b. Code 1 - Communication administratively prohibited

Ce cas se produit généralement lorsqu’un élément filtrant tel qu’un firewall interdit la communication et le spécifie avec ce message précis. Néanmoins, dans beaucoup de cas semblables le firewall interdit la connexion sans pour autant envoyer ce message, cela pour éviter la détection de sa présence.

c. Code 2 - Beyond scope of source address

Le libellé un peu ésotérique de ce message (au-delà du champ de l’adresse source) signifie tout simplement que l’adresse source est de type link-local alors que l’adresse destination est de type global. Cela n’est pas cohérent car l’adresse IPv6 source doit être une adresse routable pour que le destinataire puisse avoir une chance de lui faire parvenir sa réponse.

d. Code 3 - Address unreachable

C’est souvent le message envoyé lorsqu’il a été impossible de trouver l’adresse MAC correspondant à l’adresse IPv6 demandée ou à l’adresse du routeur permettant d’atteindre la destination.

e. Code 4 - Port unreachable...

Multicast Listener Discovery (MLD)

Nous allons maintenant nous attarder sur un protocole basé essentiellement sur ICMPv6 : MLD (Multicast Listener Discovery).

Ce protocole, décrit dans le RFC 2710 pour sa version 1 et RFC 3810 pour sa version 2, vise principalement à informer les routeurs présents sur un lien des postes en écoute, pour un groupe de multicast donné, sur ce même lien. Le but visé est que seuls les routeurs ayant des auditeurs avérés pour un groupe diffusent les informations qui leurs sont destinées.

Nous retrouvons ici les principes de fonctionnement et les buts du protocole IGMP (Internet Group Management Protocol) décrit par les RFC 2236 (pour la version 2) et 3376 (pour la version 3). Une des différences notables est que MLD s’appuie sur des messages ICMPv6 (alors qu’IGMP possède ses propres messages encapsulés en IP), ce qui justifie sa présence dans ce chapitre.

Voyons maintenant les grands principes de fonctionnement de MLD.

1. Adhésion à un groupe

Un nœud (appelé listener dans les documentations) souhaitant se joindre à un groupe de multicast donné envoie un message de type Multicast Listener Report à tous les routeurs du lien. L’adresse de destination est le groupe dans le cas de MLD version 1 ou l’adresse ff02::16 (tous les routeurs MLDv2) dans le cas de la version 2.

Ce message possède les caractéristiques visualisables dans la capture suivante (en mode MLDv2) :

Nous avons bien...

Multicast Router Discovery (MRD)

Ce mécanisme, décrit dans le RFC 4286, permet à des postes de découvrir quels sont les routeurs susceptibles de faire du routage multicast. Il existe en IPv4 et en IPv6.

Dans le cadre d’IPv6, le mécanisme MRD se base sur les trois types de messages ICMPv6 déjà évoqués plus haut : 151, 152 et 153.

Les routeurs annoncent leur participation à du routage multicast en envoyant un message de type 151 (Multicast Router Advertisement) à l’adresse spéciale ff02::6A (All-snoopers multicast address) désignant tous les auditeurs potentiels.

Les postes souhaitant connaître les routeurs intervenant dans le routage multicast émettent à destination de l’adresse ff02::2 (tous les routeurs) un message de type 152 (Multicast Router Solicitation) pour que ceux-ci répondent par un message de type Advertisement.

Enfin, les routeurs cessant d’accomplir cette fonction de routage multicast envoient un message de type 153 (Multicast Router Termination) à l’adresse ff02::6A.

Mécanisme de Path MTU Discovery

Nous le mentionnons ici pour mémoire car nous avons déjà abordé le PMTU dans le chapitre Structure des paquets IPv6 traitant de la structure des paquets.

Pour aller plus loin

Voici les principaux RFC documentant l’ICMP et ses extensions dans la version v6 :

RFC 4443 pour ICMPv6.
RFC 4884 pour des extensions ICMP.