Difference between revisions of "MOOC:Compagnon Act31-s7"

From Livre IPv6

Latest revision as of 09:07, 18 October 2024

Activité 31 : Découvrir le voisinage sur le réseau local

Introduction

Nous avons décrit dans l'activité 23 le protocole ICMPv6 (Internet Message Control Protocol) [RFC 4443], dont l'objectif est d'assurer le bon fonctionnement de la couche réseau. Nous avons décrit dans cette activité les fonctions de signalement d'erreur en cours d'acheminement d'un paquet et de test d'accessibilité d'un nœud.

À la différence d'ICMP pour IPv4, qui comporte également ces 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 était du ressort de IGMP (Internet Group Management Protocol), et la résolution d'adresse matérielle, du protocole ARP (Address Resolution Protocol).

Cette 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 nœuds 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 supplémentaires comme la mobilité IP ou la re-numérotation. Il en ressort qu'ICMPv6 est bien plus complet que son prédécesseur ICMP en IPv4. Il est un élément indispensable dans le service de connectivité offert par la couche de réseau.

Ce chapitre du document compagnon va décrire en détail le protocole de découverte de voisin. Après avoir détaillé les messages ICMPv6 dédiés à ce protocole, nous expliquerons leur utilisation dans le mécanisme de résolution de l'adresse matérielle. Nous verrons ensuite comment ce même mécanisme est utilisé de manière détourné pour vérifier l'unicité d'une adresse sur le réseau local. L'annexe complète ce chapitre par la description du protocole de gestion des groupes multicast (MLD), de l'indication de redirection et des champs optionnels transportés dans les messages ICMPv6 utilisés dans la découverte des voisins.

Protocole de 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 nœud et ses voisins. Les voisins sont les nœuds qui partagent une même connectivité physique. Dans la terminologie IPv6, on parle de lien. Avec NDP, un nœud est capable de dialoguer avec les nœuds connectés au même support (hôtes et routeurs). Il ne s'agit pas, pour un nœud, de connaître exactement la liste de tous les autres nœuds 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 1. Nous allons, dans la suite de ce paragraphe, nous intéresser à deux fonctions de NDP :

la détermination de l'adresse physique d'un nœud à partir de son adresse IP ;
la détection d'adresses IP dupliquées.

Ces fonctions sont réalisées à travers deux 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 1 : Messages ICMPv6 pour les interactions entre voisins

Format des messages mis en œuvre

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 nœud 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 1 sert à demander des informations d'un nœud 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 nœud 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 nœud recherché.

Le champ option contient, en général, l'adresse physique de la source.

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

Message Annonce d'un voisin

Le message de la figure 2 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 nœuds, 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 2 : 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 qu'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 3 dans lequel les deux nœuds 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 3 : Lien utilisé comme exemple pour la résolution d'adresse IPv6.

Le nœud 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

Commande ping6

La commande ping6 est l'équivalent de la commande ping d'IPv4 mais, comme son numéro l'indique, en utilisant le protocole IPv6. La commande ping, dans certains OS, comporte une option -6 qui rend cette commande équivalente à la commande ping6.

Avant de pouvoir émettre un paquet IPv6 sur le réseau, l'émetteur a besoin de connaître l'adresse physique du nœud destinataire. Dans notre exemple, le nœud destinataire est le destinataire final, autrement dit le récepteur. Dans d'autre situation, le destinataire est le nœud destinataire 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 1.

Ethernet Src : 8:0:20:a:aa:6d Dst : 33:33:ff:0:0:3 Type : 0x86dd
IPv6
 Version : 6 Classe : 0x00 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 : 0x780d
 Cible : 2001:db8:12:3::3 (ganesha)
 Option :
   Type : 1 (Adresse physique source) Lg : 8 octets (0x01) : 08-00-20-0a-aa-6d 

0000: 33 33 ff 00 00 03 08 00 20 0a aa 6d 86 dd|60 00
0010: 00 00 00 20 3a ff 20 01 0d b8 00 12 00 03 0a 00
0020: 20 ff fe 0a aa 6d ff 02 00 00 00 00 00 00 00 00
0030: 00 01 ff 00 00 03|87|00|78 0d|00 00 00 00|20 01
0040: 0d b8 00 12 00 03 00 00 00 00 00 00 00 03|01|01|
0050: 08 00 20 0a aa 6d

Trace 1: 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 d'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. Le destinataire n'aura ainsi pas besoin lui-même de déclencher le mécanisme de résolution de l'adresse matérielle.

L'adresse de destination est l'adresse de multicast sollicité associée à l'adresse recherchée. En effet l'émetteur ne peut pas utilisé ici l'adresse de ganesha, car la pile réseau ne pourra pas dans ce cas déterminer l'adresse Ethernet de destination. L'objectif de ce mécanisme est justement de récupérer cette information ! L'utilisation du multicast permet d'effectuer cette recherche de l'interface cible parmi celles connectées au même réseau local de manière plus efficace qu'un envoi en diffusion^[1]. Comme décrit dans l'activité 13, une adresse de multicast sollicité est construite à partir du préfixe multicast de portée locale (ff02::/8) et des 3 derniers octets de l'adresse du destinataire (ici 00:0003). L'adresse Ethernet de destination est aussi une adresse multicast, associée à l'adresse de multicast sollicité [RFC 2464].

Le message NS apparait en bleu dans la trace. Le format du message est représenté par la figure 1. Ce message NS contient, dans le champ cible, l'adresse IPv6 du nœud 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 nœud 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 2. La trace 2 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 : 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:0a00:20ff:fe0a:aa6d (uma)
ICMPv6
 Type : 136 (0x88, Annonce de voisin) Code : 0 Checksum : 0x028a
 Bits (0xe) 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

0000: 08 00 20 0a aa 6d 1a 00 20 0c 7a 34 86 dd|60 00
0010: 00 00 00 20 3a ff fe 80 00 00 00 00 00 00 18 00
0020: 20 ff fe 0c 7a 34 20 01 0d b8 00 12 00 03 0a 00
0030: 20 ff fe 0a aa 6d|88|00|02 8a|e0|00 00 00|20 01
0040: 0d b8 00 12 00 03 00 00 00 00 00 00 00 03|02|01|
0050: 1a 00 20 0c 7a 34

Trace 2 : 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 nœud 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 nœud é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 nœud".

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 nœuds 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 nœud 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 3 et 4 un échange NUD. Il s'agit du nœud Ganesha qui lance une vérification de la validité du nœud Uma.

Ethernet Src : 8:0:20:a:aa:6d Dst : 1a:0:20:c:7a:34 Type : 0x86dd
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 (uma)
 Option :
  Type : 1 (Adresse physique source) Lg : 8 octets (0x01) : 1a-00-20-0c-7a-34

0000: 1a 00 20 0c 7a 34 08 00 20 0a aa 6d 86 dd|60 00
0010: 00 00 00 20 3a ff fe 80 00 00 00 00 00 00 18 00
0020: 20 ff fe 0c 7a 34 20 01 0d b8 00 12 00 03 0a 00
0030: 20 ff fe 0a aa 6d|87|00|11 16|00 00 00 00|20 01
0040: 0d b8 00 12 00 03 0a 00 20 ff fe 0a aa 6d|01|01|
0050: 1a 00 20 0c 7a 34

Trace 3 : 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, le nœud émetteur 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.

Ethernet Src : 1a:0:20:c:7a:34 Dst : 8:0:20:a:aa:6d Type : 0x86dd
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: 08 00 20 0a aa 6d 1a 00 20 0c 7a 34 86 dd|60 00
0010: 00 00 00 18 3a ff 20 01 0d b8 00 12 00 03 0a 00
0020: 20 ff fe 0a aa 6d fe 80 00 00 00 00 00 00 18 00
0030: 20 ff fe 0c 7a 34|88|00|85 5f|40|00 00 00|20 01
0040: 0d b8 00 12 00 03 0a 00 20 ff fe 0a aa 6d

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

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

Avant qu'une adresse IP soit mise en service sur une interface, il peut être intéressant d'en vérifier l'unicité. En théorie, un plan d'adressage complètement documenté assure sur le papier cette unicité. Un protocole de configuration automatique centralisé assure ensuite que les équipements utilise bien l'adresse qui leur est assigné. Mais dans la pratique, il est moins évident de garantir cette unicité car des configurations manuelles erronées ou malveillantes peuvent survenir et ainsi perturber le fonctionnement du réseau en cas de conflit.

Pourquoi arrêter l'auto-configuration en cas d'échec de la DAD ?

Lorsque la DAD échoue, cela veut dire que l'unicité de l'adresse n'est plus. Dans le RFC 4429, il est proposé d'anticiper une réponse négative du DAD (i.e. pas d'adresse dupliquée) afin d'utiliser l'adresse de manière anticipée. Dans ce RFC, on trouve, en Annexe A, une étude de la probabilité d'une collision d'adresses. La conclusion est qu'une collision est plus probablement due à une erreur de configuration du réseau qu'à une rencontre probabiliste malheureuse. L'intervention manuelle de l'administrateur est alors, dans ces cas, souhaitable pour pouvoir corriger l'erreur. Un mécanisme de résolution automatique de collision d'adresses n'enlèverait pas l'erreur.

La vérification de l'unicité d'une adresse au moment de sa configuration s'effectue au niveau du réseau local, car c'est sur ce réseau que sont censées se trouver toutes les adresses qui partagent le même préfixe. En IPv4, le mécanisme d'ARP gratuit (gratuitous ARP^[2]) est utilisé par certains système pour vérifier cette unicité. En IPv6, les nœuds doivent exécuter un algorithme de "Détection d'Adresse Dupliquée" (DAD) avant de les utiliser [RFC 4862]. Le principe est le même pour ces deux mécanismes : chercher une résolution en adresse matérielle de l'adresse IP en cours de configuration. 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.

Au moment de sa configuration, une adresse est qualifiée de "provisoire" pendant l'exécution de l'algorithme "Détection d'Adresse Dupliquée" (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 un 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 :

Un message "Annonce de voisin" est reçu : l'adresse provisoire est utilisée comme adresse valide par un autre nœud. L'adresse provisoire n'est pas unique et ne peut être retenue.
Un message "Sollicitation de voisin" est reçu dans le cadre d'une procédure DAD : l'adresse provisoire est également une adresse provisoire pour un autre nœud. L'adresse provisoire ne peut être utilisée par aucun des nœuds.
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 5 montre le contenu du message de sollicitation de voisin utilisé pour la détection d'adresse dupliquée. L'adresse de source est l'adresse IPv6 indéterminée (::) car le nœud n'est pas supposé avoir d'autres adresses valide à sa disposition. Les adresses encore provisoires ne peuvent servir au mieux que pour la réception. L'adresse dont l'unicité est vérifiée est placée dans le champ adresse de la cible du message ICMPv6.

Ethernet Src : 8:0:20:a:aa:6d Dst : 33:33:ff:a:aa:6d Type : 0x86dd
IPv6
 Version : 6 Priorité : 0xf0 Label: 000000
 Longueur : 24 octets (0x0018) Protocole : 58 (0x3a, ICMPv6)
 Nombre de sauts : 255 (0x0ff)
 Source : ::
 Desti. : ff02::1:ff0a:aa6d (multicast sollicité associé à l'adresse cible)
ICMPv6
 Type : 135 (0x87, Sollicitation d'un voisin) Code : 0 Checksum : 0xfe37
 cible : fe80::0a00:20ff:fe0a:aa6d (uma, lien-local)

0000: 6f 00 00 00 00 18 3a ff 00 00 00 00 00 00 00 00
0010: 00 00 00 00 00 00 00 00 ff 02 00 00 00 00 00 00
0020: 00 00 00 01 ff 0a aa 6d|87|00|fe 37|00 00 00 00
0030: fe 80 00 00 00 00 00 00 0a 00 20 ff fe 0a aa 6d

Trace 5: Message de sollicitation de voisin utilisé pour la détection d'adresse dupliquée

La trace 6 affichée par la commande tcpdump ci-dessous illustre le cas d'un conflit d'adresse. Dans ce cas, un message d'annonce de voisin est envoyé par le nœud propriétaire de l'adresse pour signaler que cette adresse est valide sur une autre interface. Ce nœud envoie ce message à destination du multicast "tous les nœuds du lien" pour s'assurer que sa bonne réception par le nœud ayant initié la détection de l'adresse dupliquée.

1 IP6 :: > ff02::1:ff0a:aa6d: ICMP6, neighbor solicitation, who has fe80::0a00:20ff:fe0a:aa6d
2 IP6 fe80::0a00:20ff:fe0a:aa6d > ff02::1: ICMP6, neighbor advertisement, tgt is fe80::0a00:20ff:fe0a:aa6d

Trace 6: Messages échangés lors de la detection d'une adresse dupliquée sur le réseau local

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.

Conclusion

Nous nous sommes concentrés dans cette activité sur les fonctionnalités principales de la découverte du voisinage sur le réseau local. Ce mécanisme permet l'échange, entre deux nœuds du même lien, d'informations nécessaires à l'ouverture de la communication entre ces nœuds. Ces informations, comme l'adresse matérielle, sont régulièrement confirmées pour s'assurer de leur validité, à travers le mécanisme NUD. La procédure de détection d'adresse dupliquée permet d'éviter les conflit d'adresse pouvant survenir au moment de la configuration de l'adresse. Nous allons décrire dans la prochaine activité le mécanisme d'automatisation de cette configuration d'adresse en IPv6. La vérification de l'unicité de l'adresse en sera une étape.

Les message du protocole de découverte de voisins, sur lesquels s'appuient ces mécanismes, font un usage important de la diffusion en multicast restreint au réseau local. Ils utilisent donc les propriétés de diffusion offertes par le support physique du réseau. Nous avons vu notamment que les adresses IPv6 multicast étaient traduites en adresses Ethernet multicast. Le bon fonctionnement de ces mécanismes repose donc sur la fiabilité de la diffusion au niveau 2. Si le lien au niveau 2 est coupé par exemple, certains messages ne seraient alors pas reçus par tous les nœuds concernés, ce qui pourraient entraîner des dysfonctionnements. Nous verrons aussi, dans l'activité 34, que l'utilisation de message en diffusion peut présenter certains risques lorsqu'un équipement malveillant est présent sur le lien.

Références bibliographiques

↑ Spathis, P (2021). Article en ligne. How Multicast Helped IPv6 Kill Broadcast: A friendly introduction to IPv6 node-solicited multicast addresses and ICMPv6 Neighbor Discovery
↑ Documentation Wireshark : Gratuitous ARP

Pour aller plus loin

RFC et leur analyse par S. Bortzmeyer :

RFC 1191 Path MTU Discovery
RFC 2464 Transmission of IPv6 Packets over Ethernet Networks
RFC 3122 Extensions to IPv6 Neighbor Discovery for Inverse Discovery Specification
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 4861 Neighbor Discovery for IP version 6 (IPv6) Analyse
RFC 4862 IPv6 Stateless Address Autoconfiguration Analyse

ANNEXE Activité 31 : Autres fonctions de la découverte des voisins

Gestion de groupes multicast sur le lien local

Pour offrir un service de distribution multicast, deux composants sont nécessaires : un protocole de gestion de groupes multicast et un protocole de routage multicast^[1]. Le protocole de gestion de groupes 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, pour un hôte, à indiquer les groupes auxquels il souhaite souscrire. MLD est donc un protocole de gestion de groupes. Ainsi, un routeur de bordure IPv6 va pouvoir découvrir la présence de récepteurs multicast (qualifiés de listeners) 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 listeners) 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 messages 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'en-tê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 4. Les différents types de messages ICMPv6 pour MLD sont indiqués par le tableau 2. On distingue trois types de messages pour MLD.

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.
Le second type de message (type = 131) vise à obtenir un rapport d'abonnement multicast (Multicast Listener Report). Ce message est émis par le récepteur multicast. L'adresse de destination est l'adresse multicast du groupe en question. Avec MLDv2, le rapport d'abonnement à un groupe multicast a été complété par la possibilité de limiter la réception au trafic émis par certaines sources. Le trafic des sources non indiquées est alors non reçu. Cette restriction sur la source s'effectue par un message spécifique (type = 143).
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).

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

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.

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 reçoive 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, à l'expiration 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 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.

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.

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

Indication de redirection

La technique de redirection est la même que dans IPv4. Un équipement ne connaît que les préfixes des réseaux auxquels il est directement attaché et l'adresse d'un routeur par défaut. Si la route peut être optimisée, le routeur par défaut envoie ce message pour indiquer qu'une route plus courte existe. En effet, avec IPv6, comme le routeur par défaut est appris automatiquement, la route n'est pas forcément la meilleure (cf. figure Routage par défaut non optimal).

Un autre cas d'utilisation particulier à IPv6 concerne des stations situées sur un même lien physique mais ayant des préfixes différents. Ces machines passent dans un premier temps par le routeur par défaut. Ce dernier les avertit qu'une route directe existe.

Figure 5 : Format d'un message ICMPv6 d'indication de redirection.

La figure 5 Format des paquets d'indication de redirection donne le format du message :

Le champ adresse cible contient l'adresse IPv6 de l'équipement vers lequel les paquets doivent être émis.
Le champ adresse destination contient l'adresse IPv6 de l'équipement pour lequel la redirection s'applique.

Dans le cas de la redirection vers un équipement se situant sur le même lien, l'adresse cible et la destination sont identiques.

Les options contiennent l'adresse physique du nouveau routeur et l'en-tête du paquet redirigé.

Ce message peut être utilisé de la même manière qu'en IPv4. Une machine n'a qu'une route par défaut pour atteindre un équipement se trouvant sur un autre préfixe. Elle envoie donc son paquet au routeur qui s'aperçoit que le préfixe de destination est accessible par le même sous réseau que l'émetteur. Il relaie le paquet et informe la source qu'elle peut directement joindre le routeur menant vers le préfixe.

Fonctions autres et expérimentales

Pour être complet, nous pouvons signaler que les messages ICMPv6 servent aussi pour des fonctions expérimentales. Le tableau 3 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 nœud (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 3 : Fonctions expérimentales s'appuyant sur ICMPv6

Options véhiculées par les messages ICMPv6

L'intérêt du protocole de découverte des voisins est d'unifier différents protocoles qui existent dans IPv4. En particulier, la plupart des informations à transporter utilise un format commun sous la forme d'options. Le format commun des options simplifie la mise en œuvre du protocole. Une option se décrit en mot de 64 bits et comporte les champs type, longueur, données.
Les différentes fonctionnalités de découverte des voisins utilisent 5 messages : 2 pour le dialogue entre un équipement et un routeur, 2 pour le dialogue entre voisins et 1 dernier pour la redirection. Chacun de ces messages peut contenir des options. Le tableau 1 présente l'utilisation des options définies dans le RFC 4861 dans les messages de découverte de voisin.

	Sollicitation du	Annonce du	Sollicitation	Annonce	Indication de
	routeur	routeur	d'un voisin	d'un voisin	redirection
Adresse physique de la source	présent	présent	présent
Adresse physique de la cible				présent	présent
Information sur le préfixe		≥ 1
En-tête redirigée					présent
MTU		possible

Tableau 4: Utilisation des options dans les messages de découverte de voisin.

En plus des cinq options générales décrites dans le tableau 4, il existe d'autres options spécifiques pour la mobilité et les réseaux NBMA (Non Broadcast Multiple Access) comme le montre le tableau 5. La liste complète des options pour NDP est gérée par l'IANA et se retrouve sur une page web^[2].

type	description	Message
Basic Neighbor Discovery options [RFC 4861]
1	Source Link-layer Address (SLLAO)	RS/RA/NS
2	Target Link-layer Address	NA/Redirect
3	Prefix Information (PIO)	RA
4	Redirected Header	Redirect
5	MTU	RA
NBMA (unused) [RFC 2491]
6	NBMA Shortcut Limit Option	NS
Mobile IP [RFC 6275]
7	Advertisement Interval Option	RA
8	Home Agent Information Option	RA
9	Source Address List
10	Target Address List
SEND [RFC 3971]
11	CGA option
12	RSA Signature option
13	Timestamp option
14	Nonce option
15	Trust Anchor option
16	Certificate option
Mobility options
17	IP Address/Prefix Option [RFC 5568]
18	New Router Prefix Information Option [RFC 5568]
19	Link-layer Address Option [RFC 5568]
20	Neighbor Advertisement Acknowledgment Option [RFC 5568]
23	MAP Option [RFC 5380]
SLAAC optimization
24	Route Information Option [RFC 4191]
25	Recursive DNS Server Option [RFC 8106]	RA
26	RA Flags Extension Option [RFC 5175]
Fast Mobility options
27	Handover Key Request Option	[RFC 5269]
28	Handover Key Reply Option	[RFC 5269]
29	Handover Assist Information Option	[RFC 5271]
30	Mobile Node Identifier Option	[RFC 5271]
6LoWPAN [RFC 6775]
33	Address Registration (ARO)
34	6LoWPAN Context (6CO)
35	Authoritative Border Router (ABRO)
38	PREF64 [RFC 8781]	RA
157	Duplicate Address Request (DAR)
158	Duplicate Address Confirmation (DAC)
Inverse Neighbor Discovery [RFC 3122]
138	CARD Request option	[RFC 4065]
139	CARD Reply option	[RFC 4065]

Tableau 5: Identification des options de Neighbor Discovery.

Adresse physique de la source/cible

Figure 6 : Format de l'option adresse physique source/cible.

La figure 6 donne le format de ces options. Le type 1 est réservé à l'adresse physique de la source et le type 2 à l'adresse de la cible.

Le champ «longueur» est la taille en mots de 64 bits de l'option. Dans le cas d'une adresse MAC, d'une longueur de 6 octets, il contient donc la valeur 1.

Le RFC 2464 définit le format pour les adresses MAC-48 utilisés dans les réseaux Ethernet et Wi-Fi. Le RFC 4944 définit le format pour les MAC-16 et MAC-64 utilisés dans les réseaux de capteurs reposant sur la norme IEEE 802.15.4.

Information sur le préfixe

Figure 7 : Format de l'option information sur le préfixe.

Cette option contient les informations sur le préfixe pour permettre une configuration automatique des équipements. Cette option sera présentée en détail dans l'activité d'autoconfiguration.

En-tête redirigée

Figure 8 : Format de l'option en-tête redirigée.

Cette option est utilisée par le message d'indication de redirection. Elle permet d'encapsuler les premiers octets du paquet IPv6 qui a provoqué l'émission de ce message comme dans le cas des messages ICMPv6 d'erreur.

Le type vaut 4 et la taille de cette option ne doit pas conduire à un paquet IPv6 dépassant 1280 octets (cf. figure Format de l'option en-tête redirigée). Par contre le paquet doit contenir le maximum d'information possible.

MTU

Figure 9 : Format de l'option MTU.

Cette option permet d'informer les équipements sur la taille maximale des données pouvant être émises sur le lien. La figure "Format de l'option MTU" donne le format de cette option. Il n'est pas nécessaire de diffuser cette information si l'équipement utilise toujours la taille maximale permise. Par exemple, sur les réseaux Ethernet, les équipements utiliseront la valeur 1 500. Par contre pour les réseaux anneau à jeton ou FDDI, il est souvent nécessaire de préciser si les équipements doivent utiliser la valeur maximale permise ou une valeur inférieure pour autoriser l'utilisation de ponts.

Le champ type vaut 5 et le champ longueur 1.

Référence bibliographique

↑ Sébastien LOYE. (2005). Techniques de l'ingénieur. ref TE7527. Le multicast IP : principes et protocoles
↑ IANA. IPv6 Neighbor Discovery Option Formats

Pour aller plus loin

RFC et leur analyse par S. Bortzmeyer

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 6275 Mobility Support in IPv6

Retrieved from "http://livre.g6.asso.fr/index.php?title=MOOC:Compagnon_Act31-s7&oldid=20618"

Association G6

Difference between revisions of "MOOC:Compagnon Act31-s7"

From Livre IPv6

Latest revision as of 09:07, 18 October 2024

Activité 31 : Découvrir le voisinage sur le réseau local

Introduction

Protocole de découverte des voisins

Format des messages mis en œuvre

Message Sollicitation d'un voisin

Message Annonce d'un voisin

Fonctionnement de la résolution d'adresse IP

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

Conclusion

Références bibliographiques

Pour aller plus loin

ANNEXE Activité 31 : Autres fonctions de la découverte des voisins

Gestion de groupes multicast sur le lien local

Format des messages pour MLD

Principe de MLD

Indication de redirection

Fonctions autres et expérimentales

Options véhiculées par les messages ICMPv6

Adresse physique de la source/cible

Information sur le préfixe

En-tête redirigée

MTU

Référence bibliographique

Pour aller plus loin

Views

Personal tools

Navigation

Search

Tools

@@ Line 2: / Line 2: @@
 > [[MOOC:Accueil|MOOC]]>[[MOOC:Contenu|Contenu]]>[[MOOC:Sequence_3|Séquence 3]]
 ----
-__NOTOC__
 -->
-= Activité 31: Contrôler le fonctionnement du réseau par ICMPv6 =
+__NOTOC__
+= Activité 31 : Découvrir le voisinage sur le réseau local =
-Comme pour IPv4, le bon fonctionnement de la couche réseau effectuée par IPv6 est supervisé par le protocole ICMPv6(''Internet Message Control Protocol'')[RFC 4443].  Dans IPv4, ICMP sert à la détection d'erreurs (par exemple : équipement inaccessible, durée de vie expirée,...), au test (par exemple ping), à la configuration automatique des équipements (redirection ICMP, découverte des routeurs). Le protocole de contrôle pour IPv6 a été revu en plus de ces trois fonctions, ICMPv6 intègre les fonctions de gestion des groupes de multicast (MLD : ''Multicast Listener Discovery'') et de résolution d'adresse IP en adresse physique. Pour rappel, en IPv4 la gestion des groupe est du ressort de IGMP et la résolution d'adresse du protocole ARP.
+==Introduction==
-== Fonctions de gestion du niveau IP ==
+Nous avons décrit dans l'activité 23 le protocole ICMPv6 (''Internet Message Control Protocol'') [RFC 4443], dont l'objectif est d'assurer le bon fonctionnement de la couche réseau. Nous avons décrit dans cette activité les fonctions de signalement d'erreur en cours d'acheminement d'un paquet et de test d'accessibilité d'un nœud.
-Même si le protocole IPv6 a été conçu pour être le plus simple possible, le bon fonctionnement d'un réseau IP nécessite un ensemble d'interactions entre les équipements, interactions relevant de la gestion du réseau et non du transport d'informations. Ces interactions permettent notamment :
+À la différence d'ICMP pour IPv4, qui comporte également ces 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 était du ressort de IGMP (''Internet Group Management Protocol''), et la résolution d'adresse matérielle, du protocole ARP (''Address Resolution Protocol'').
-* le signalement d'erreur en cours d'acheminement d'un paquet (équipement inaccessible, durée de vie expirée, etc.)
-* le test d'accessibilité de bout en bout à travers le réseau (ping)
-* La configuration automatique des équipements (redirection, découverte des voisins et routeurs)
-Afin d'assurer les échanges pour réaliser ces fonctions, la famille de protocole ICMP (''Internet Control Management Protocol'') a été spécifiée. ICMPv6 [RFC 4443] réalise ces fonctions sur la base d'IPv6. De plus ICMPv6 intègre les fonctions de gestion des groupes de multicast au niveau du réseau local (assuré par le protocole IGMP en IPv4).
-== Format générique d'un message ICMPv6 ==
+Cette 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 nœuds 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.
-[[File:MOOC_Act31_Fig1.png|400px|center|thumb|Figure 1: Format d'un message ICMPv6.]]
+ICMPv6 comporte aussi des fonctions supplémentaires comme la mobilité IP ou la re-numérotation. Il en ressort qu'ICMPv6 est bien plus complet que son prédécesseur ICMP en IPv4. Il est un élément indispensable dans le service de connectivité offert par la couche de réseau.
-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érique des paquets ICMPv6 est donné par la figure 1.
+Ce chapitre du document compagnon va décrire en détail le protocole de découverte de voisin. Après avoir détaillé les messages ICMPv6 dédiés à ce protocole, nous expliquerons leur utilisation dans le mécanisme de résolution de l'adresse matérielle. Nous verrons ensuite comment ce même mécanisme est utilisé de manière détourné pour vérifier l'unicité d'une adresse sur le réseau local. L'annexe complète ce chapitre par la description du protocole de gestion des groupes multicast (MLD), de l'indication de redirection et des champs optionnels transportés dans les messages ICMPv6 utilisés dans la découverte des voisins.
-* Le champ <tt>type</tt> (voir tableau Valeurs des champs type et code d'ICMPv6) code la nature du message ICMPv6. Les valeurs de ce champs sont classée pour distinguer les messages d'erreurs des autres messages d'information (ping, configuration automatique).
+== Protocole de découverte des voisins ==
-* Le champ <tt>code</tt> précise la cause du message ICMPv6.
+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.
-* Le champ <tt>checksum</tt> permet de vérifier l'intégrité du paquet ICMP (rendu obligatoire pour tout protocole transporté au dessus d'IPv6).
+NDP vise à gérer les interactions entre un nœud et ses voisins. Les voisins sont les nœuds qui partagent une même connectivité physique. Dans la terminologie IPv6, on parle de lien. Avec NDP, un nœud est capable de dialoguer avec les nœuds connectés au même support (hôtes et routeurs). Il ne s'agit pas, pour un nœud, de connaître exactement la liste de tous les autres nœuds connectés sur le lien, mais uniquement de gérer ceux avec qui il dialogue.
-* Le champ <tt>options</tt> est divisé en plusieurs champs selon le <tt>type</tt> et le <tt>code</tt> du message.
-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é.
+Le protocole utilise cinq types de messages ICMPv6, comme le montre le tableau 1. Nous allons, dans la suite de ce paragraphe, nous intéresser à deux fonctions de NDP :
+* la détermination de l'adresse physique d'un nœud à partir de son adresse IP ;
+* la détection d'adresses IP dupliquées.
+Ces fonctions sont réalisées à travers deux 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é.
+<center>
+{|
+|-style="background-color:#f0f0f0"
+!Type !! Code  !! Signification
+|-style="background:silver"
+!colspan=3 | Découverte de voisins
+|-
+|133 || || Sollicitation du routeur
+|-style="background:silver"
+|134 || || Annonce du routeur
+|-
+|135 || || Sollicitation d'un voisin
+|-style="background:silver"
+|136 || || Annonce d'un voisin
+|-
+|137 || || Redirection
+|-style="background:silver"
+! colspan=3| Découverte de voisins inverse (RFC 3122)
+|-
+|141 || || Sollicitation
+|-style="background:silver"
+|142 ||  || Annonce
+|-
+| ||  ||
+|-style="background:silver"
+!colspan=3 | Découverte de voisins sécurisée (SEND, RFC 3971)
+|-
+|148 || || Sollicitation de chemin de certification
+|-style="background:silver"
+|149 || ||Annonce de chemin de certification
+|}
+Tableau 1 : Messages ICMPv6 pour les interactions entre voisins
+</center>
-{{Tableau ICMPv6 MOOC}}
+=== Format des messages mis en œuvre ===
+Avant d'étudier la procédure, nous allons présenter le format des messages impliqués.<br>
+Les messages ICMPv6 pour NDP sont encapsulés dans des paquets IPv6. Il est intéressant de souligner que le champ <tt>nombre de sauts</tt> 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 nœud 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.
-== Test d'accessibilité entre équipements (ping) ==
+==== <div id="NS">Message Sollicitation d'un voisin</div> ====
+Le message de la figure 1 sert à demander des informations d'un nœud 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.
-[[File:MOOC_Act31_Fig2.png|400px|center|thumb|Figure 2: Format du message d'echo.]]
+Le champ <tt>adresse source</tt> du paquet IPv6 contient, soit l'adresse locale au lien, soit une adresse globale, soit l'adresse non spécifiée.
+Le champ <tt>adresse destination</tt> contient, soit l'adresse de multicast sollicité correspondant à l'adresse recherchée, soit l'adresse d'un nœud dans le cas d'une détection d'inaccessibilité des voisins (''Neighbor Unreachability Detection'' NUD).
-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.
+Le champ <tt>adresse de la cible</tt> contient l'adresse IPv6 du nœud recherché.
-== Rapport d'erreur ==
+Le champ <tt>option</tt> contient, en général, l'adresse physique de la source.
+<center>
+[[File:Act31_Fig8.jpeg|400px|center|thumb|Figure 1 : Format du message de Sollicitation d'un voisin.]]
+</center>
-=== <div id="inaccessible">Destination inaccessible</div> ===
+==== <div id="NA">Message Annonce d'un voisin</div> ====
+Le message de la figure 2 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 <tt>R</tt> est mis à 1 si l'émetteur est un routeur ;
+* le bit <tt>S</tt> mis à 1 indique que cette annonce est émise en réponse à une sollicitation ;
+* le bit <tt>O</tt> mis à 1 indique que cette annonce doit effacer les informations précédentes qui se trouvent dans les caches des autres nœuds, en particulier la table contenant les adresses physiques ;
+* le champ <tt>adresse de la cible</tt> reprend l'adresse de la cible de la sollicitation auquel ce message répond (le bit <tt>S</tt> 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 <tt>adresse de la cible</tt> contient alors cette nouvelle adresse "lien-local" ;
+* l'option <tt>adresse physique</tt> de la cible contient l'adresse physique de l'émetteur.
+<center>
+[[File:MOOC_Act31_Fig9.png|400px|center|thumb|Figure 2 : Format du message d'annonce d'un voisin.]]
+</center>
-[[File:MOOC_Act31_Fig3.png|666px]]
+== 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 qu'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 3 dans lequel les deux nœuds 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.
-Ce message est émis par un routeur intermédiaire quand le paquet ne peut pas être transmis parce que soit :
+<center>
+[[Image:31-fig-10.png|400px|center|thumb|Figure 3 : Lien utilisé comme exemple pour la résolution d'adresse IPv6.]]
+</center>
-* le routeur ne trouve pas dans ses tables la route vers la destination (code = 0) ;
+Le nœud Uma essaye de tester la connectivité avec Ganesha via la commande <tt>ping6</tt>.  La commande entrée sur Uma est la suivante :
-* le franchissement d'un équipement de type firewall est interdit ("raison administrative", code = 1) ;
+ uma# '''ping6 ganesha'''
-* 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) ;
+ trying to get source for ganesha
-* toute autre raison comme par exemple la tentative de routage d'une adresse locale au lien (code = 3) ;
+ source should be 2001:db8:12:3:a00:20ff:fe0a:aa6d
-* 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) ;
+ PING ganesha (2001:db8:12:3::3): 56 data bytes
-* le paquet a été rejeté à cause de son adresse source (code = 5) ;
+bytes from 2001:db8:12:3::3: icmp6_seq=0 ttl=255 time=5.121 ms
-* la route vers la destination conduit a un rejet du paquet (code = 6).
-=== Paquet trop grand ===
+{{HorsTexte|Commande ping6|La commande ping6 est l'équivalent de la commande ping d'IPv4 mais, comme son numéro l'indique, en utilisant le protocole IPv6. La commande ping, dans certains OS, comporte une option <tt>-6</tt> qui rend cette commande équivalente à la commande ping6.}}
-[[File:MOOC_Act31_Fig4.png|666px]]
+Avant de pouvoir émettre un paquet IPv6 sur le réseau, l'émetteur a besoin de connaître l'adresse physique du nœud destinataire. Dans notre exemple, le nœud destinataire est le destinataire final, autrement dit le récepteur. Dans d'autre situation, le destinataire est le nœud destinataire 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 1.
+ <font color="green">Ethernet Src : 8:0:20:a:aa:6d Dst : 33:33:ff:0:0:3 Type : 0x86dd</font>
+ IPv6
+  Version : 6 Classe : 0x00 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)
+ <font color="blue">ICMPv6
+  Type : 135 (0x87, Sollicitation de voisin) Code : 0 Checksum : 0x780d
+  Cible : 2001:db8:12:3::3 (ganesha)
+  Option :
+    Type : 1 (Adresse physique source) Lg : 8 octets (0x01) : 08-00-20-0a-aa-6d
+ </font>
+: <font color="green">''33 33 ff 00 00 03 08 00 20 0a aa 6d 86 dd</font>|60 00''
+: ''00 00 00 20 3a ff 20 01 0d b8 00 12 00 03 0a 00''
+: ''20 ff fe 0a aa 6d ff 02 00 00 00 00 00 00 00 00''
+: ''00 01 ff 00 00 03|<font color="blue">87|00|78 0d|00 00 00 00|20 01''</font>
+: <font color="blue">''0d b8 00 12 00 03 00 00 00 00 00 00 00 03|01|01|''</font>
+: <font color="blue">''08 00 20 0a aa 6d''</font>
-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.
+<center>'''Trace 1: Message ICMPv6 Sollicitation de voisin(NS).'''</center>
-=== Délai expiré ===
+Dans l'en-tête IPv6, l'adresse de la source est l'adresse globale de l'interface d'émission d'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. Le destinataire n'aura ainsi pas besoin lui-même de déclencher le mécanisme de résolution de l'adresse matérielle.
-[[File:MOOC_Act31_Fig5.png|666px]]
+L'adresse de destination est l'adresse de multicast sollicité associée à l'adresse recherchée. En effet l'émetteur ne peut pas utilisé ici l'adresse de ganesha, car la pile réseau ne pourra pas dans ce cas déterminer l'adresse Ethernet de destination. L'objectif de ce mécanisme est justement de récupérer cette information ! L'utilisation du multicast permet d'effectuer cette recherche de l'interface cible parmi celles connectées au même réseau local de manière plus efficace qu'un envoi en diffusion<ref>Spathis, P (2021). Article en ligne. [https://spathis.medium.com/how-multicast-helped-ipv6-kill-broadcast-6b4ab8a106c0 How Multicast Helped IPv6 Kill Broadcast: A friendly introduction to IPv6 node-solicited multicast addresses and ICMPv6 Neighbor Discovery]</ref>. Comme décrit dans l'activité 13, une adresse de multicast sollicité est construite à partir du préfixe multicast de portée locale (<tt>ff02::/8</tt>) et des 3 derniers octets de l'adresse du destinataire (ici <tt>00:0003</tt>). L'adresse Ethernet de destination est aussi une adresse multicast, associée à l'adresse de multicast sollicité [RFC 2464].
-Ce message indique que le paquet a été rejeté par le routeur :
+Le message NS apparait en bleu dans la trace. Le format du message est représenté par la figure 1. Ce message NS contient, dans le champ cible, l'adresse IPv6 du nœud 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 <tt>option</tt> contient l'adresse physique de l'émetteur de la requête, à savoir celle d'Uma.
-* soit parce que le champ nombre de sauts a atteint 0 (code = 0) ;
+Le nœud 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 <tt>Cible</tt> une de ses adresses IPv6. Il y répond par un message NA dont le format est rappelé par la figure 2. La trace 2 montre la réponse émise.
-* soit qu'un fragment s'est perdu et le temps alloué au réassemblage a été dépassé (code = 1).
+ <font color="green">Ethernet Src : 1a:0:20:c:7a:34 Dst : 8:0:20:a:aa:6d Type : 0x86dd</font>
+ 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:0a00:20ff:fe0a:aa6d (uma)
+ <font color="blue">ICMPv6
+  Type : 136 (0x88, Annonce de voisin) Code : 0 Checksum : 0x028a
+  Bits (0xe) 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
+ </font>
+: ''<font color="green">08 00 20 0a aa 6d 1a 00 20 0c 7a 34 86 dd</font>|60 00''
+: ''00 00 00 20 3a ff fe 80 00 00 00 00 00 00 18 00''
+: ''20 ff fe 0c 7a 34 20 01 0d b8 00 12 00 03 0a 00''
+: ''20 ff fe 0a aa 6d|<font color="blue">88|00|02 8a|e0|00 00 00|20 01''</font>
+: <font color="blue">''0d b8 00 12 00 03 00 00 00 00 00 00 00 03|02|01|''</font>
+: <font color="blue">''1a 00 20 0c 7a 34''</font>
+<center>'''Trace 2 : Message ICMPv6 Annonce de voisin(NA).'''</center>
-Ce message sert aussi à la commande traceroute pour déterminer le chemin pris par les paquets.
+L'adresse source utilisée par Ganesha est celle de portée locale au lien. Le bit <tt>R</tt> indique que le nœud qui répond a une fonction de routeur. Le bit <tt>S</tt> indique que ce message est une réponse à une demande explicite (le message précédent). Le bit <tt>O</tt> indique que cette réponse doit remplacer toute valeur connue précédemment. Le champ <tt>Cible</tt> rappelle l'adresse IPv6. Le champ <tt>Option</tt> donne l'adresse physique recherchée.
-=== Erreur de paramètre ===
+L'adresse physique ainsi obtenue est ensuite enregistrée dans une table de correspondance du nœud é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 nœud".
-[[File:MOOC_Act31_Fig6.png|666px]]
+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 nœuds 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 nœud 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 3 et 4 un échange NUD. Il s'agit du nœud Ganesha qui lance une vérification de la validité du nœud Uma.
-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 :
+ <font color="green">Ethernet Src : 8:0:20:a:aa:6d Dst : 1a:0:20:c:7a:34 Type : 0x86dd</font>
+ 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)
+ <font color="blue">ICMPv6
+  Type : 135 (0x87, Sollicitation de voisin) Code : 0 Checksum : 0x1116
+  Cible : 2001:db8:12:3:a00:20ff:fe0a:aa6d (uma)
+  Option :
+   Type : 1 (Adresse physique source) Lg : 8 octets (0x01) : 1a-00-20-0c-7a-34
+ </font>
+: ''<font color="green">1a 00 20 0c 7a 34 08 00 20 0a aa 6d 86 dd</font>|60 00''
+: ''00 00 00 20 3a ff fe 80 00 00 00 00 00 00 18 00''
+: ''20 ff fe 0c 7a 34 20 01 0d b8 00 12 00 03 0a 00''
+: ''20 ff fe 0a aa 6d<font color="blue">|87|00|11 16|00 00 00 00|20 01''</font>
+: <font color="blue">''0d b8 00 12 00 03 0a 00 20 ff fe 0a aa 6d|01|01|''</font>
+: <font color="blue">''1a 00 20 0c 7a 34''</font>
+<center>'''Trace 3 : Message ICMPv6 Sollicitation de voisin(NS).'''</center>
+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, le nœud émetteur 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.<br>
+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 <tt>cible</tt> du message d'annonce de voisin.
-* la syntaxe de l'en-tête n'est pas correcte (code = 0) ;
+ <font color="green">Ethernet Src : 1a:0:20:c:7a:34 Dst : 8:0:20:a:aa:6d Type : 0x86dd</font>
-* le numéro en-tête suivant n'est pas reconnu (code = 1) ;
+ IPv6
-* 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).
+  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)
+ <font color="blue">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)
+ </font>
+: ''<font color="green">08 00 20 0a aa 6d 1a 00 20 0c 7a 34 86 dd</font>|60 00''
+: ''00 00 00 18 3a ff 20 01 0d b8 00 12 00 03 0a 00''
+: ''20 ff fe 0a aa 6d fe 80 00 00 00 00 00 00 18 00''
+: ''20 ff fe 0c 7a 34|<font color="blue">88|00|85 5f|40|00 00 00|20 01</font>''
+: <font color="blue">''0d b8 00 12 00 03 0a 00 20 ff fe 0a aa 6d''</font>
+<center>'''Trace 4 : Message ICMPv6 Annonce de voisin(NA).'''</center>
-Le champ pointeur indique l'octet où l'erreur est survenue dans le paquet retourné.
+== Fonctionnement de la détection d'adresse dupliquée ==
-=== Pourquoi filtrer avec précaution ICMPv6 ===
+Avant qu'une adresse IP soit mise en service sur une interface, il peut être intéressant d'en vérifier l'unicité. En théorie, un plan d'adressage complètement documenté assure sur le papier cette unicité. Un protocole de configuration automatique centralisé assure ensuite que les équipements utilise bien l'adresse qui leur est assigné. Mais dans la pratique, il est moins évident de garantir cette unicité car des configurations manuelles erronées ou malveillantes peuvent survenir et ainsi perturber le fonctionnement du réseau en cas de conflit.
-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.
+{{HorsTexte|Pourquoi arrêter l'auto-configuration en cas d'échec de la DAD ?|
+Lorsque la DAD échoue, cela veut dire que l'unicité de l'adresse n'est plus. Dans le RFC 4429, il est proposé d'anticiper une réponse négative du DAD (i.e. pas d'adresse dupliquée) afin d'utiliser l'adresse de manière anticipée.
+Dans ce RFC, on trouve, en Annexe A, une étude de la probabilité d'une collision d'adresses. La conclusion est qu'une collision est plus probablement due à une erreur de configuration du réseau qu'à une rencontre probabiliste malheureuse. L'intervention manuelle de l'administrateur est alors, dans ces cas, souhaitable pour pouvoir corriger l'erreur. Un mécanisme de résolution automatique de collision d'adresses n'enlèverait pas l'erreur.}}
+La vérification de l'unicité d'une adresse au moment de sa configuration s'effectue au niveau du réseau local, car c'est sur ce réseau que sont censées se trouver toutes les adresses qui partagent le même préfixe. En IPv4, le mécanisme d'ARP gratuit (''gratuitous ARP''<ref>Documentation Wireshark : [https://wiki.wireshark.org/Gratuitous_ARP Gratuitous ARP]</ref>) est utilisé par certains système pour vérifier cette unicité. En IPv6, les nœuds doivent exécuter un algorithme de "Détection d'Adresse Dupliquée" (DAD) avant de les utiliser [RFC 4862]. Le principe est le même pour ces deux mécanismes : chercher une résolution en adresse matérielle de l'adresse IP en cours de configuration. 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.
-==Gestion des abonnements sur le lien-local : MLD==
+Au moment de sa configuration, une adresse est qualifiée de "provisoire" pendant l'exécution de l'algorithme "Détection d'Adresse Dupliquée" (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 un 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 <tt>adresse de la cible</tt>, 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 :
-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.
+# Un message "Annonce de voisin" est reçu : l'adresse provisoire est utilisée comme adresse valide par un autre nœud. L'adresse provisoire n'est pas unique et ne peut être retenue.
+# Un message "Sollicitation de voisin" est reçu dans le cadre d'une procédure DAD : l'adresse provisoire est également une adresse provisoire pour un autre nœud. L'adresse provisoire ne peut être utilisée par aucun des nœuds.
+# 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.
-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.
+La trace 5 montre le contenu du message de sollicitation de voisin utilisé pour la détection d'adresse dupliquée. L'adresse de source est l'adresse IPv6 indéterminée (<tt>::</tt>) car le nœud n'est pas supposé avoir d'autres adresses valide à sa disposition. Les adresses encore provisoires ne peuvent servir au mieux que pour la réception. L'adresse dont l'unicité est vérifiée est placée dans le champ <tt>adresse de la cible</tt> du message ICMPv6.
-Comme MLD est un sous-protocole d'ICMPv6, les messages MLD sont des messages ICMPv6 particuliers. Ils sont envoyés avec :
+ Ethernet Src : 8:0:20:a:aa:6d Dst : 33:33:ff:a:aa:6d Type : 0x86dd
+ IPv6
+  Version : 6 Priorité : 0xf0 Label: 000000
+  Longueur : 24 octets (0x0018) Protocole : 58 (0x3a, ICMPv6)
+  Nombre de sauts : 255 (0x0ff)
+  Source : ::
+  Desti. : ff02::1:ff0a:aa6d (multicast sollicité associé à l'adresse cible)
+ <font color="blue">ICMPv6
+  Type : 135 (0x87, Sollicitation d'un voisin) Code : 0 Checksum : 0xfe37
+  cible : fe80::0a00:20ff:fe0a:aa6d (uma, lien-local)
+ </font>
+: 6f 00 00 00 00 18 3a ff 00 00 00 00 00 00 00 00
+: 00 00 00 00 00 00 00 00 ff 02 00 00 00 00 00 00
+: 00 00 00 01 ff 0a aa 6d|<font color="blue">87|00|fe 37|00 00 00 00</font>
+: <font color="blue">fe 80 00 00 00 00 00 00 0a 00 20 ff fe 0a aa 6d</font>
+<center>'''Trace 5: Message de sollicitation de voisin utilisé pour la détection d'adresse dupliquée'''</center>
-* une adresse source IPv6 lien-local ;
+La trace 6 affichée par la commande ''tcpdump'' ci-dessous illustre le cas d'un conflit d'adresse. Dans ce cas, un message d'annonce de voisin est envoyé par le nœud propriétaire de l'adresse pour signaler que cette adresse est valide sur une autre interface. Ce nœud envoie ce message à destination du multicast "tous les nœuds du lien" pour s'assurer que sa bonne réception par le nœud ayant initié la détection de l'adresse dupliquée.
-* 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.
+IP6 :: > ff02::1:ff0a:aa6d: ICMP6, neighbor solicitation, who has fe80::0a00:20ff:fe0a:aa6d
+IP6 fe80::0a00:20ff:fe0a:aa6d > ff02::1: ICMP6, neighbor advertisement, tgt is fe80::0a00:20ff:fe0a:aa6d
+<center>'''Trace 6: Messages échangés lors de la detection d'une adresse dupliquée sur le réseau local'''</center>
-Le format générique d'un message MLD est donné sur la figure Format générique d'un message ICMP pour MLD:
+'''''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.''
-[[File:MOOC_Act31_Fig7.png|666px]]
+== Conclusion ==
+Nous nous sommes concentrés dans cette activité sur les fonctionnalités principales de la découverte du voisinage sur le réseau local. Ce mécanisme permet l'échange, entre deux nœuds du même lien, d'informations nécessaires à l'ouverture de la communication entre ces nœuds. Ces informations, comme l'adresse matérielle, sont régulièrement confirmées pour s'assurer de leur validité, à travers le mécanisme NUD. La procédure de détection d'adresse dupliquée permet d'éviter les conflit d'adresse pouvant survenir au moment de la configuration de l'adresse. Nous allons décrire dans la prochaine activité le mécanisme d'automatisation de cette configuration d'adresse en IPv6. La vérification de l'unicité de l'adresse en sera une étape.
-Trois types de messages sont utilisés. Le premier concerne le recensement des des récepteurs multicast (<tt>type</tt> = 130) selon plusieurs méthodes :
+Les message du protocole de découverte de voisins, sur lesquels s'appuient ces mécanismes, font un usage important de la diffusion en multicast restreint au réseau local. Ils utilisent donc les propriétés de diffusion offertes par le support physique du réseau. Nous avons vu notamment que les adresses IPv6 multicast étaient traduites en adresses Ethernet multicast. Le bon fonctionnement de ces mécanismes repose donc sur la fiabilité de la diffusion au niveau 2. Si le lien au niveau 2 est coupé par exemple, certains messages ne seraient alors pas reçus par tous les nœuds concernés, ce qui pourraient entraîner des dysfonctionnements. Nous verrons aussi, dans l'activité 34, que l'utilisation de message en diffusion peut présenter certains risques lorsqu'un équipement malveillant est présent sur le lien.
-* recensement général émis à l'adresse de diffusion générale sur le lien (<tt>FF02::1</tt>)
-* 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 (<tt>type</tt> = 131), l'adresse de destination est l'adresse multicast du groupe en question
+== Références bibliographiques ==
-Enfin le troisième permet à un récepteur d'annoncer une résiliation d'abonnement multicast (<tt>type</tt> = 132), émis à l'adresse du groupe multicast "tous les routeurs du lien local" (<tt>FF02::2</tt>).
+<references />
-Les champs ont la signification suivante :
+== Pour aller plus loin==
-* <tt>type</tt> : prend la valeur 130, 131 ou 132.
+RFC et leur analyse par S. Bortzmeyer :
-* <tt>code</tt> : mis à zéro par l'émetteur et ignoré par les récepteurs
+* RFC 1191 Path MTU Discovery
-* <tt>checksum</tt> : celui du protocole ICMPv6 standard, couvrant tout le message MLD auquel s'ajoutent les champs du pseudo-en-tête IPv6
+* RFC 2464 Transmission of IPv6 Packets over Ethernet Networks
-* <tt>délai maximal de réponse</tt> :
+* RFC 3122 Extensions to IPv6 Neighbor Discovery for Inverse Discovery Specification
-** utilisé seulement dans les messages de recensement. Il exprime le retard maximal autorisé (en millisecondes) pour l'arrivée des rapports d'abonnement
+* RFC 4429 Optimistic Duplicate Address Detection (DAD) for IPv6
-** 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
+* RFC 4443 Internet Control Message Protocol (ICMPv6)  for the Internet Protocol Version 6 (IPv6) Specification [http://www.bortzmeyer.org/4443.html Analyse]
-* <tt>inutilisé</tt> : mis à zéro par l'émetteur et ignoré par les récepteurs
+* RFC 4861 Neighbor Discovery for IP version 6 (IPv6) [http://www.bortzmeyer.org/4861.html Analyse]
-* <tt>adresse multicast</tt> :
+* RFC 4862 IPv6 Stateless Address Autoconfiguration  [http://www.bortzmeyer.org/4862.html Analyse]
-** 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
-== Fonctionnement du Protocole MLD ==
+= ANNEXE Activité 31 : Autres fonctions de la découverte des voisins =
-===Messages de recensement et rapports d'abonnement périodiques MLD===
+== Gestion de groupes multicast sur le lien local ==
-Le routeur envoie régulièrement des messages de recensement général à l'adresse de diffusion générale sur le lien (<tt>FF02::1</tt>). 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.
+Pour offrir un service de distribution multicast, deux composants sont nécessaires : un protocole de gestion de groupes multicast et un protocole de routage multicast<ref>Sébastien LOYE. (2005). Techniques de l'ingénieur. ref TE7527. Le multicast IP : principes et protocoles </ref>. Le protocole de gestion de groupes 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.
-===Rapports d'abonnements MLD non-sollicités===
+En IPv6, MLD (''Multicast Listener Discovery'') sert, pour un hôte, à indiquer les groupes auxquels il souhaite souscrire. MLD est donc un  protocole de gestion de groupes. Ainsi, un routeur de bordure IPv6 va pouvoir découvrir la présence de récepteurs multicast (qualifiés de ''listeners'') 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 ''listeners'') 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.
-Les changements d'état des hôtes sont notifiés par des messages non-sollicités :
+MLD est une  fonction d'ICMPv6 ; aussi, les messages MLD sont des messages ICMPv6. Les messages pour MLD sont envoyés avec :
+* une adresse source IPv6 lien-local ;
+* le champ <tt>nombre de sauts</tt> fixé à 1 ;
+* l'option <tt>IPv6 Router Alert</tt> activée en ajoutant l'extension d'en-tête ''Hop-by-Hop'' correspondante.
-* Pour souscrire à une adresse multicast spécifique, un hôte envoie un rapport d'abonnement non-sollicité ;
+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.
-* 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 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.
-* 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" (<tt>FF02::2</tt>). 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.
+=== Format des messages pour MLD ===
+Le format générique d'un message MLD est donné par la figure 4. Les différents types de messages ICMPv6 pour MLD sont indiqués par le tableau 2. On distingue trois types de messages pour MLD.<br>
+# Le premier type (<tt>type</tt> = 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 (<tt>FF02::1</tt>), (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.
+# Le second type de message (<tt>type</tt> = 131) vise à obtenir un rapport d'abonnement multicast (''Multicast Listener Report''). Ce message est émis par le récepteur multicast. L'adresse de destination est l'adresse multicast du groupe en question. Avec MLDv2, le rapport d'abonnement à un groupe multicast a été complété par la possibilité de limiter la réception au trafic émis par certaines sources. Le trafic des sources non indiquées est alors non reçu. Cette restriction sur la source s'effectue par un message spécifique (<tt>type</tt> = 143).
+# Enfin, le troisième type de message (<tt>type</tt> = 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" (<tt>FF02::2</tt>).
-== Découverte des voisins ==
+<center>
+[[File:MOOC_Act31_Fig7.png|400px|center|thumb|Figure 4 : Format générique d'un message ICMPv6 pour MLD.]]
+</center>
-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 :
+Les champs des messages pour MLD ont la signification suivante :
-* La détermination de l'adresse physique d'un équipement à partir de son adresse IP
+* <tt>Type</tt> : prend la valeur 130, 131 ou 132 ;
-* La détection d'adresses IP dupliquées
+* <tt>Code</tt> : mis à zéro par l'émetteur et ignoré par les récepteurs ;
+* <tt>Checksum</tt> : celui du protocole ICMPv6 standard, couvrant tout le message MLD auquel s'ajoutent les champs du pseudo-en-tête IPv6 ;
+* <tt>Délai maximal de réponse</tt> :
+** 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 ;
+* <tt>réservé</tt> : champ non utilisé et mis à zéro par l'émetteur et ignoré par les récepteurs ;
+* <tt>Adresse multicast</tt> :
+** 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.
-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).
+<center>
+{|
+|-style="background-color:#f0f0f0"
+!Type !! Code  !! Signification
+|-style="background:silver"
+!colspan=3 |Gestion des groupes multicast
+|-
+|130 || || Requête d'abonnement
+|-style="background:silver"
+|131 || || Rapport d'abonnement
+|-
+|132 || || Fin d'abonnement
+|-style="background:silver"
+|143 || || Rapport d'abonnement MLDv2
+|-
+|}
+Tableau 2 : Messages ICMPv6 pour MLD
+</center>
+=== Principe de MLD ===
-=== Détails des messages mis en oeuvre ===
+Le routeur envoie régulièrement des messages de recensement général à l'adresse de multicast <tt>FF02::1</tt>. Cette adresse équivaut à l'adresse de diffusion sur un lien. Pour éviter que le routeur reçoive 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, à l'expiration 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.
-==== <div id="NS">Message Sollicitation d'un voisin</div> ====
+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 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" (<tt>FF02::2</tt>). 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.
-[[File:MOOC_Act31_Fig8.png|666px]]
+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.
-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.
+À 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.
-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 )
+== Indication de redirection ==
-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.
+La technique de redirection est la même que dans IPv4. Un équipement ne connaît que les préfixes des réseaux auxquels il est directement attaché et l'adresse d'un routeur par défaut. Si la route peut être optimisée, le routeur par défaut envoie ce message pour indiquer qu'une route plus courte existe. En effet, avec IPv6, comme le routeur par défaut est appris automatiquement, la route n'est pas forcément la meilleure (cf. figure Routage par défaut non optimal).
-==== <div id="NA">Message Annonce d'un voisin</div> ====
+Un autre cas d'utilisation particulier à IPv6 concerne des stations situées sur un même lien physique mais ayant des préfixes différents. Ces machines passent dans un premier temps par le routeur par défaut. Ce dernier les avertit qu'une route directe existe.
-[[File:MOOC_Act31_Fig9.png|666px]]
+<center>
+[[File:MOOC_Act31_Fig10.png|400px|center|thumb|Figure 5 : Format d'un message ICMPv6 d'indication de redirection.]]
+</center>
-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.
+La figure 5 Format des paquets d'indication de redirection donne le format du message :
-* Le bit <tt>R</tt> 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 champ adresse cible contient l'adresse IPv6 de l'équipement vers lequel les paquets doivent être émis.
-* Le bit <tt>S</tt> mis à 1 indique que cette annonce est émise en réponse à une sollicitation.
+* Le champ adresse destination contient l'adresse IPv6 de l'équipement pour lequel la redirection s'applique.
-* Le bit <tt>O</tt> 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 <tt>S</tt> est à 1, la valeur du champ adresse de la cible de la sollicitation auquel ce message répond. Si le bit <tt>S</tt> est à 0, ce champ contient l'adresse IPv6 lien-local de l'équipement émetteur.
+Dans le cas de la redirection vers un équipement se situant sur le même lien, l'adresse cible et la destination sont identiques.
-* L'option adresse physique de la cible contient l'adresse physique de l'émetteur.
-=== Fonctionnement de la résolution d'adresse physique ===
+Les options contiennent l'adresse physique du nouveau routeur et l'en-tête du paquet redirigé.
-Nous allons étudier le cas où un noeud cherche à joindre un autre noeud situé sur le même réseau.
+Ce message peut être utilisé de la même manière qu'en IPv4. Une machine n'a qu'une route par défaut pour atteindre un équipement se trouvant sur un autre préfixe. Elle envoie donc son paquet au routeur qui s'aperçoit que le préfixe de destination est accessible par le même sous réseau que l'émetteur. Il relaie le paquet et informe la source qu'elle peut directement joindre le routeur menant vers le préfixe.
- uma# '''ping6 ganesha'''
+== Fonctions autres et expérimentales ==
-  trying to get source for ganesha
+Pour être complet, nous pouvons signaler que les messages ICMPv6 servent aussi pour des fonctions expérimentales.  Le tableau 3 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.
- source should be 2001:db8:12:3:a00:20ff:fe0a:aa6d
- PING ganesha (2001:db8:12:3::3): 56 data bytes
-bytes from 2001:db8:12:3::3: icmp6_seq=0 ttl=255 time=5.121 ms
-==== Sollicitation du voisin ====
+<center>
+{|
+|-style="background-color:#f0f0f0"
+!Type !! Code  !! Signification
+|-style="background:silver"
+!colspan=3 | Renumérotation des routeurs (expérimental, RFC 2894)
+|-
+|138 || || Renumérotation des routeurs :
+|-style="background:silver"
+| || 0 ||&nbsp;&nbsp;&nbsp;&nbsp; Commande
+|-
+| || 1 ||&nbsp;&nbsp;&nbsp;&nbsp; Résultat
+|-style="background:silver"
+| || 255 ||&nbsp;&nbsp;&nbsp;&nbsp; Remise à zéro du numéro de séquence
+|-
+| ||  ||
+|-style="background:silver"
+!colspan=3 | Recherche d'information sur un nœud (expérimental, RFC 4620)
+|-
+|139 || || Demande d'information
+|-style="background:silver"
+|140 || || Réponse
+|-
+|    || ||
+|-style="background:silver"
+!colspan=3 | Mobilité (RFC 6275)
+|-
+|144 || || Découverte d'agent mère (requête)
+|-style="background:silver"
+|145 || ||Découverte d'agent mère (réponse)
+|-
+|146 || ||Sollicitation de préfixe mobile
+|-style="background:silver"
+|147 || || Annonce de préfixe mobile
+|-
+|    || ||
+|-style="background:silver"
+! colspan=3 | Mobilité (expérimental, RFC 4065)
+|-
+|150 || || Protocoles de mobilité expérimentaux, tels que Seamoby
+|}
+Tableau 3 : Fonctions expérimentales s'appuyant sur ICMPv6
+</center>
-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.
+== Options véhiculées par les messages ICMPv6 ==
- Ethernet Src : 8:0:20:a:aa:6d Dst : 33:33:ff:0:0:3 Type : 0x86dd
+L'intérêt du protocole de découverte des voisins est d'unifier différents protocoles qui existent dans IPv4. En particulier, la plupart des informations à transporter utilise un format commun sous la forme d'options. Le format commun des options simplifie la mise en œuvre du protocole. Une option se décrit en mot de 64 bits et comporte les champs type, longueur, données. <br>
- IPv6
+Les différentes fonctionnalités de découverte des voisins utilisent 5 messages : 2 pour le dialogue entre un équipement et un routeur, 2 pour le dialogue entre voisins et 1 dernier pour la redirection. Chacun de ces messages peut contenir des options. Le tableau 1 présente l'utilisation des options définies dans le RFC 4861 dans les messages de découverte de voisin.<br>
-  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
-: ''6<font color="blue">f 0</font>0 00 00 <font color="blue">00 20</font> 3a <font color="blue">ff</font> 20 01 0d b8 00 12 00 03''
-: ''0a 00 20 ff fe 0a aa 6d <font color="blue">ff 02 00 00 00 00 00 00</font>''
-: ''<font color="blue">00 00 00 01 ff 00 00 03</font>|87 <font color="blue">00</font> 4d 7f <font color="blue">00 00 00 00</font>''
-: ''20 01 0d b8 00 12 00 03 00 00 00 00 00 00 00 03|''
-: ''01 <font color="blue">01</font> 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).
+<center >
+{|
+| width = 150 |              || width = 100 |Sollicitation du || width = 100 |Annonce du || width = 100 |Sollicitation  ||width = 100 | Annonce     ||width = 100 |Indication de
+|-
+|               ||  routeur         || routeur    || d'un voisin    || d'un voisin || redirection
+|-style="background:silver"
+| Adresse physique de la source   || présent          || présent    || présent || ||
+|-
+| Adresse physique de la cible    ||                  ||            ||                || présent     ||  présent
+|-style="background:silver"
+|Information sur le préfixe    ||                   || &ge; 1 || || ||
+|-
+| En-tête redirigée     ||                   ||           ||                ||              || présent
+|-style="background:silver"
+| MTU           ||                   ||  possible || || ||
+|}
+'''Tableau 4''': Utilisation des options dans les messages de découverte de voisin.</center>
+En plus des cinq options générales décrites dans le tableau 4, il existe d'autres options spécifiques pour la mobilité et les réseaux NBMA (''Non Broadcast Multiple Access'') comme le montre le tableau 5. La liste complète des options pour NDP est gérée par l'IANA et se retrouve sur une page web<ref>IANA. [http://www.iana.org/assignments/icmpv6-parameters/icmpv6-parameters.xhtml#icmpv6-parameters-5  ''IPv6 Neighbor Discovery Option Formats'']</ref>.
+<center >
+{{NB-options}}
+'''Tableau 5''': Identification des options de ''Neighbor Discovery''.</center>
-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.
+=== <div id="physique">Adresse physique de la source/cible</div> ===
-==== Annonce du voisin ====
+[[Image:31-Afig1.png|400px|right|thumb|Figure 6 : Format de l'option adresse physique source/cible.]]
-La machine <tt>ganesha</tt>, 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.
+La figure 6 donne le format de ces options. Le type 1 est réservé à l'adresse physique de la source et le type 2 à l'adresse de la cible.
- Ethernet Src : 1a:0:20:c:7a:34 Dst : 8:0:20:a:aa:6d Type : 0x86dd
+Le champ «longueur» est la taille en mots de 64 bits de l'option. Dans le cas d'une adresse MAC, d'une longueur de 6 octets, il contient donc la valeur 1.
- 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 <tt>R</tt> indique que l'équipement qui répond a une fonction de routeur. Le bit <tt>S</tt> indique que ce message est une réponse à une demande explicite (le message précédent). Le bit <tt>O</tt> 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.
+Le RFC 2464 définit le format pour les adresses MAC-48 utilisés dans les réseaux Ethernet et Wi-Fi. Le RFC 4944 définit le format pour les MAC-16 et MAC-64 utilisés dans les réseaux de capteurs reposant sur la norme IEEE 802.15.4.
-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.
+=== <div id="information">Information sur le préfixe</div> ===
-=== Fonctionnement de la détection d'adresse dupliquée ===
+[[Image:31-Afig2.png|400px|right|thumb|Figure 7 : Format de l'option information sur le préfixe.]]
-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.
+Cette option contient les informations sur le préfixe pour permettre une configuration automatique des équipements. Cette option sera présentée en détail dans l'activité d'autoconfiguration.
-* 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é.
+=== <div id="redirigee">En-tête redirigée</div> ===
-== Conclusion ==
+[[Image:31-Afig3-2.png|400px|right|thumb|Figure 8 : Format de l'option en-tête redirigée.]]
-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.
+Cette option est utilisée par le message d'indication de redirection. Elle permet d'encapsuler les premiers octets du paquet IPv6 qui a provoqué l'émission de ce message comme dans le cas des messages ICMPv6 d'erreur.
-== Références bibliographiques ==
+Le type vaut 4 et la taille de cette option ne doit pas conduire à un paquet IPv6 dépassant 1280 octets (cf. figure Format de l'option en-tête redirigée). Par contre le paquet doit contenir le maximum d'information possible.
-<references />
+=== <div id="MTU">MTU</div> ===
+[[Image:31-Afig4.png|400px|right|thumb|Figure 9 : Format de l'option MTU.]]
+Cette option permet d'informer les équipements sur la taille maximale des données pouvant être émises sur le lien. La figure "Format de l'option MTU" donne le format de cette option. Il n'est pas nécessaire de diffuser cette information si l'équipement utilise toujours la taille maximale permise. Par exemple, sur les réseaux Ethernet, les équipements utiliseront la valeur 1 500. Par contre pour les réseaux anneau à jeton ou FDDI, il est souvent nécessaire de préciser si les équipements doivent utiliser la valeur maximale permise ou une valeur inférieure pour autoriser l'utilisation de ponts.
+Le champ type vaut 5 et le champ longueur 1.
+== Référence bibliographique ==
+<references />
 == Pour aller plus loin==
+RFC et leur analyse par S. Bortzmeyer
+* 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) [http://www.bortzmeyer.org/3971.html Analyse]
+* RFC 3810  Multicast Listener Discovery Version 2 (MLDv2) for IPv6
+* RFC 4065 Instructions for Seamoby and Experimental Mobility Protocol IANA Allocations
+* RFC 6275 Mobility Support in IPv6

	This page was last modified on 18 October 2024, at 09:07. - Disclaimers - About Livre IPv6