Revision as of 01:55, 15 March 2016 (view source) Panelli (Talk | contribs) (→‎Gestion des abonnements sur le lien-local : MLD) ← Older edit		Revision as of 01:56, 15 March 2016 (view source) Panelli (Talk | contribs) (→‎Gestion des abonnements sur le lien-local : MLD) Newer edit →
Line 185:		Line 185:
	|-		|-
	|}		|}
−
−	{{Tableau ICMPv6 MOOC}}
	== Fonctionnement du Protocole MLD ==		== Fonctionnement du Protocole MLD ==

---

Revision as of 01:56, 15 March 2016

Activité 31: Protocole ICMPv6: la supervision d'IPv6

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, Le protocole ICMP pour IPv6 a été revu. En plus de 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éfini 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'entête IPv6 comme prochaine entête (champ Next Header). Le format général des messages ICMPv6 est donné par la figure 1. L'entê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. (rendu obligatoire pour tout protocole transporté au dessus d'IPv6).

Les messages ICMPv6 de compte rendu d'erreur contiennent dans la partie données le paquet IPv6 ayant provoqué l'erreur. Pour éviter des problèmes de fragmentation puisqu'il est difficilement envisageable de mettre en œuvre la découverte du MTU, la longueur du message ICMPv6 est limitée à 1 280 octet. Par conséquent le contenu du paquet IPv6 renvoyé peut être tronqué.

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 descrit dans le RFC 4443.

Test d'accessibilité entre équipements (ping)

Ces deux messages servent en particulier à la commande ping permettant de tester l'accessibilité d'une machine. Le principe de fonctionnement est le même que pour IPv4, une requête (type 128) est envoyée vers l'équipement dont on veut tester le fonctionnement, celui-ci répond par le message réponse d'écho (type 129). Le champ identificateur permet de distinguer les réponses dans le cas où plusieurs commandes ping seraient lancées simultanément sur la machine. Le champ numéro de séquence permet d'associer la réponse à une requête pour 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é. Le champ données permet d'augmenter la taille du message pour les mesures.

Rapport d'erreur

Destination inaccessible

Ce message est émis par un routeur intermédiaire 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 équipement de type 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).

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.

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 sert aussi à la commande traceroute pour déterminer le chemin pris par les paquets.

Erreur de paramètre

Ce message est émis par un nœud ayant détecté une erreur de syntaxe dans l'en-tête du paquet IP ou des extensions. 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é.

Pourquoi filtrer avec précaution 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 Paquet trop grand) car cela peut avoir des conséquences néfastes sur le bon fonctionnement du réseau. Supposons que le MTU entre un client et un serveur soit de 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 commande HTTP courte (GET /). Le serveur va répondre en envoyant une page complète, si le paquet est trop grand, le routeur va rejeter le paquet et envoyer au serveur un message indiquant que le paquet et trop grand. Si le pare-feux du serveur le filtre, le serveur ne pourra jamais adapter la taille du paquet. On se trouve dans une situation où certains paquets passent (ouvertures de connexion, ping, sessions SSH,...) et d'autres sont bloquées.

Le RFC 4890 donne les bonnes pratiques pour filtrer correctement les paquets IPv6 en entrée d'un réseau.

Gestion des abonnements sur le lien-local : MLD

Pour offrir un service de distribution multicast, deux composants sont nécessaires : un protocole de gestion de groupe multicast et un protocole de construction d'arbre multicast. Le protocole de gestion de groupe multicast réalise la signalisation entre l'hôte et son routeur d'accès à l'Internet. En IPv6, ce protocole est MLD (Multicast Listener Discovery). Il est utilisé par un routeur de bordure IPv6 pour 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 et les routeurs multicast. Toutefois, pour les adresses multicast sur lesquelles un routeur lui-même écoute, il doit exécuter les deux parties du protocole et répondre à ses propres messages.

Comme MLD est un sous-protocole d'ICMPv6, les messages MLD sont des messages ICMPv6 particuliers. Ils 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.

Le format générique d'un message MLD est donné sur la figure :

Trois types de messages sont utilisés. Le premier concerne le recensement des des récepteurs multicast (type = 130) selon plusieurs méthodes :

• recensement général émis à l'adresse de diffusion générale sur le lien (FF02::1)
• recensement spécifique à une adresse multicast, l'adresse de destination est l'adresse multicast du groupe en question

Le second permet d'obtenir un rapport d'abonnement multicast (type = 131), l'adresse de destination est l'adresse multicast du groupe en question Enfin le troisième permet à un récepteur d'annoncer une résiliation d'abonnement multicast (type = 132), émis à l'adresse du groupe multicast "tous les routeurs du lien local" (FF02::2).

Les champs 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
• inutilisé : 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

Gestion des groupes multicast (MLD, RFC 2710)
130		Requête d'abonnement
131		Rapport d'abonnement
132		Fin d'abonnement
Gestion des groupes multicast (MLDv2, RFC 3810)
143		Rapport d'abonnement MLDv2

Fonctionnement du Protocole MLD

Messages de recensement et rapports d'abonnement périodiques MLD

Le routeur envoie régulièrement des messages de recensement général à l'adresse de diffusion générale sur le lien (FF02::1). Les hôtes arment un temporisateur pour chaque adresse multicast qui les concerne. Si un temporisateur expire sans que l'hôte ait entendu une réponse d'un de ses voisins concernant la même adresse, il envoie un rapport d'abonnement à l'adresse multicast du groupe. Ce système de temporisateurs permet aux hôtes de surveiller les rapports des autres hôtes sur le lien et d'annuler leurs propres rapports concernant les mêmes adresses. Ainsi la quantité du trafic MLD peut être minimisée.

Rapports d'abonnements MLD non-sollicités

Les changements d'état des hôtes sont notifiés par des messages non-sollicités :

• Pour souscrire à une adresse multicast spécifique, un hôte envoie un rapport d'abonnement non-sollicité ;
• Pour cesser d'écouter sur une adresse multicast, l'hôte 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 l'hôte était le dernier concerné par l'adresse multicast sur le lien;
• La résiliation rapide est aussi une possibilité offerte par MLDv1. L'hôte 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.

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

Cette fonction permet à 2 équipements connectés sur le même réseau de se découvrir l'un et l'autre et d'échanger des informations de configuration. La découverte des voisins est principalement mise en oeuvre dans 2 cas d'usage :

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

Cette fonction de découverte des voisins est réalisée en IPv6 à travers 2 messages ICMPv6 : Sollicitation d'un voisin (Neighbor Sollicitation ou NS) et Annonce d'un voisin (Neighbor Advertisment ou NA).

Détails des messages mis en oeuvre

Message Sollicitation d'un voisin

Ce message (cf. figure Format des paquets de sollicitation d'un voisin) permet d'obtenir des informations d'un équipement 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 de diffusion. Dans le cas de la détermination de l'adresse physique, il correspond à la requête ARP du protocole IPv4.

Le champ adresse source du paquet IPv6 contient soit l'adresse locale au lien adresse lien-local, 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 de l'équipement (dans le cas d'une détection d'inaccessibilité des voisins, NUD )

Le champ adresse de la cible contient l'adresse IPv6 de l'équipement cherché. Le champ option contient en général l'adresse physique de la source.

Message Annonce d'un voisin

Ce message (cf. figure Format des paquets d'annonce d'un voisin) 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 pour le protocole IPv4.

• Le bit R est mis à 1 si l'émetteur est un routeur. Ce bit est utilisé pour permettre la détection d'un routeur qui redevient un équipement ordinaire.
• 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 contient, si le bit S est à 1, la valeur du champ adresse de la cible de la sollicitation auquel ce message répond. Si le bit S est à 0, ce champ contient l'adresse IPv6 lien-local de l'équipement émetteur.
• L'option adresse physique de la cible contient l'adresse physique de l'émetteur.

Fonctionnement de la résolution d'adresse physique

Nous allons étudier le cas où un noeud cherche à joindre un autre noeud situé sur le même réseau.

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

Sollicitation du voisin

Avant de pouvoir émettre un paquet IPv6 sur le réseau, l'émetteur a besoin de connaître l'adresse physique de l'équipement destinataire ou du routeur par défaut. Il utilise pour cela le protocole de découverte des voisins et émet une trame de sollicitation d'un voisin.

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. On aurait pu penser que l'émetteur utilisait l'adresse locale au lien comme adresse de la 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 entre adresse IPv6 et adresse physique, puisque ce dernier trouvera dans la suite du datagramme 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 (cf. RFC 2464).

L'en-tête ICMPv6 contient dans le champ cible l'adresse IPv6 de la machine dont l'adresse physique est recherchée. On peut remarquer que les trois derniers octets correspondent au groupe de multicast de l'en-tête IPv6. Le champ option contient l'adresse physique de l'émetteur de la requête.

Annonce du voisin

La machine ganesha, qui écoute sur tous les groupes multicast sollicité associés à ses adresses, reçoit le message de sollicitation de voisin, reconnaît dans la cible une de ses adresses IPv6, et répond.

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 est locale au lien. Le bit R indique que l'équipement 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'information est ensuite enregistrée dans un cache du système de l'équipement émetteur, appelé 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 périodiquement grâce à un protocole de découverte de non-joignabilité des voisins (Neighbor Unreachability Discovery), basé sur ces mêmes messages.

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

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

Pour aller plus loin