Difference between revisions of "MOOC:Compagnon Act31-s7"
From Livre IPv6
(→Fonctionnement de la résolution d'adresse IP) |
|||
| Line 2: | Line 2: | ||
> [[MOOC:Accueil|MOOC]]>[[MOOC:Contenu|Contenu]]>[[MOOC:Sequence_3|Séquence 3]] | > [[MOOC:Accueil|MOOC]]>[[MOOC:Contenu|Contenu]]>[[MOOC:Sequence_3|Séquence 3]] | ||
---- | ---- | ||
| + | __NOTOC__ | ||
--> | --> | ||
| − | + | = Activité 31 : Le protocole de découverte des voisins = | |
| − | = Activité 31 : | + | |
| − | + | ||
==Introduction== | ==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 distingué 3 fonctions propres à ICMPv6 : | ||
* le signalement d'erreur en cours d'acheminement d'un paquet ; | * le signalement d'erreur en cours d'acheminement d'un paquet ; | ||
* le test d'accessibilité d'un nœud ; | * le test d'accessibilité d'un nœud ; | ||
| Line 15: | Line 16: | ||
La résolution d'adresse en IPv6 s'effectue par la procédure de découverte des voisins (''Neighbor Discovery Protocol''(NDP)). La notion de voisinage est définie par la connectivité au lien. Deux 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. | La résolution d'adresse en IPv6 s'effectue par la procédure de découverte des voisins (''Neighbor Discovery Protocol''(NDP)). La notion de voisinage est définie par la connectivité au lien. Deux 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 pour la mobilité IP. Il en ressort qu'ICMPv6 est bien plus complet que son prédécesseur. | ICMPv6 comporte aussi des fonctions pour la mobilité IP. Il en ressort qu'ICMPv6 est bien plus complet que son prédécesseur. | ||
| − | Non seulement ICMPv6 rapporte les erreurs, mais pour les mécanismes d' | + | Non seulement ICMPv6 rapporte les erreurs, mais pour les mécanismes d'auto-configuration ou de découverte du voisinage, il est un élément indispensable dans le service de connectivité offert par la couche de '''réseau'''. |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | {{TODO|Annoncer le plan}} | |
== Découverte des voisins == | == Découverte des voisins == | ||
| Line 264: | Line 133: | ||
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.<br> | 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.<br> | ||
| − | L'adresse de destination est l'adresse de multicast sollicitée associée à l'adresse recherchée, et l'adresse Ethernet de destination est l'adresse associée à cette adresse multicast [RFC 2464]. L'adresse IPv6 | + | L'adresse de destination est l'adresse de multicast sollicitée associée à l'adresse recherchée, et l'adresse Ethernet de destination est l'adresse associée à cette adresse multicast [RFC 2464]. L'adresse IPv6 multicast sollicitée offre une alternative efficace par rapport à 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>. |
| + | |||
| + | {{TODO|Compléter selon l'explication du multicast sollicité donnée dans [[MOOC:Compagnon_Act13-s7|Act13]]}} | ||
Le message NS apparait en bleu dans la trace. Le format du message est représenté par la figure 8. Ce message NS contient, dans le champ cible, l'adresse IPv6 du 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. | Le message NS apparait en bleu dans la trace. Le format du message est représenté par la figure 8. Ce message NS contient, dans le champ cible, l'adresse IPv6 du 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. | ||
| Line 351: | Line 222: | ||
== Conclusion == | == Conclusion == | ||
| + | |||
| + | {{TODO|Restreindre la conclusion à la découverte de voisins}} | ||
| + | |||
Cette activité a présenté les fonctions assurées par le protocole ICMPv6. Ce protocole est en effet indispensable au bon fonctionnement de la couche réseau. Par ce protocole, les défauts qui peuvent affecter la connectivité IPv6 peuvent être connus et, donc, corrigés.<br> | Cette activité a présenté les fonctions assurées par le protocole ICMPv6. Ce protocole est en effet indispensable au bon fonctionnement de la couche réseau. Par ce protocole, les défauts qui peuvent affecter la connectivité IPv6 peuvent être connus et, donc, corrigés.<br> | ||
A l'échelle de l'Internet, le bon acheminement d'un paquet IPv6 est contrôlé et les défauts sont notifiés à l'émetteur par des messages ICMPv6. Ainsi, en cas de non livraison d'un paquet, les informations fournies par ICMPv6 vont servir à découvrir le problème et à adapter la communication si besoin est. | A l'échelle de l'Internet, le bon acheminement d'un paquet IPv6 est contrôlé et les défauts sont notifiés à l'émetteur par des messages ICMPv6. Ainsi, en cas de non livraison d'un paquet, les informations fournies par ICMPv6 vont servir à découvrir le problème et à adapter la communication si besoin est. | ||
| Line 359: | Line 233: | ||
== Pour aller plus loin== | == Pour aller plus loin== | ||
| + | {{TODO|Restreindre cette liste car elle va plus loin que NDP}} | ||
| + | |||
RFC et leur analyse par S. Bortzmeyer : | RFC et leur analyse par S. Bortzmeyer : | ||
* RFC 1191 Path MTU Discovery | * RFC 1191 Path MTU Discovery | ||
Revision as of 14:29, 18 January 2022
Contents
Activité 31 : Le protocole de découverte des voisins
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 distingué 3 fonctions propres à ICMPv6 :
- le signalement d'erreur en cours d'acheminement d'un paquet ;
- le test d'accessibilité d'un nœud ;
- la configuration automatique des équipements.
Terminologie
Un équipement connecté au réseau est dénommé nœud. Si ce nœud est un équipement terminal, on parle d'hôte. Le sous-réseau qui correspond à un réseau local sous-jacent se qualifie, en IPv6, de lien. Tous les nœuds attachés au même lien sont des voisins.
À la différence d'ICMP pour IPv4, qui comporte également ces trois fonctions, ICMPv6 intègre les fonctions de gestion des groupes de multicast (Multicast Listener Discovery (MLD)) et de résolution d'adresse IP en adresse physique. En IPv4, ces fonctions étaient assurées par des protocoles annexes (la gestion des groupes était du ressort de IGMP (Internet Group Management Protocol), et la résolution d'adresse, du protocole ARP (Address Resolution Protocol). La résolution d'adresse en IPv6 s'effectue par la procédure de découverte des voisins (Neighbor Discovery Protocol(NDP)). La notion de voisinage est définie par la connectivité au lien. Deux 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 pour la mobilité IP. Il en ressort qu'ICMPv6 est bien plus complet que son prédécesseur. Non seulement ICMPv6 rapporte les erreurs, mais pour les mécanismes d'auto-configuration ou de découverte du voisinage, il est un élément indispensable dans le service de connectivité offert par la couche de réseau.
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 3. 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 3 : 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 8 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.
Message Annonce d'un voisin
Le message de la figure 9 est émis en réponse à une sollicitation, mais il peut aussi être émis spontanément pour propager une information de changement d'adresse physique, ou de statut routeur. Dans le cas de la détermination d'adresse physique, il correspond à la réponse ARP du protocole IPv4. L'adresse de la cible, dans ce cas-là, correspond à l'adresse de la source de ce message.
Les champs de ce message ont la signification suivante :
- le bit R est mis à 1 si l'émetteur est un routeur ;
- le bit S mis à 1 indique que cette annonce est émise en réponse à une sollicitation ;
- le bit O mis à 1 indique que cette annonce doit effacer les informations précédentes qui se trouvent dans les caches des autres 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.
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 10 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.
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 3.
Ethernet Src : 8:0:20:a:aa:6d Dst : 33:33:ff:0:0:3 Type : 0x86dd IPv6 Version : 6 Classe : 0xf0 Label : 000000 Longueur : 32 octets (0x0020) Protocole : 58 (0x3a, ICMPv6) Nombre de sauts : 255 (0xff) Source : 2001:db8:12:3:a00:20ff:fe0a:aa6d (uma) Desti. : ff02::1:ff00:3 (multicast sollicité associé à 2001:db8:12:3::3) ICMPv6 Type : 135 (0x87, Sollicitation de voisin) Code : 0 Checksum : 0x4d7f Cible : 2001:db8:12:3::3 (ganesha) Option : Type : 1 (Adresse physique source) Lg : 8 octets (0x01) : 08-00-20-0a-aa-6d 0000: 6f 00 00 00 00 20 3a ff 20 01 0d b8 00 12 00 03 0010: 0a 00 20 ff fe 0a aa 6d ff 02 00 00 00 00 00 00 0020: 00 00 00 01 ff 00 00 03|87|00|4d 7f|00 00 00 00| 0030: 20 01 0d b8 00 12 00 03 00 00 00 00 00 00 00 03| 0040: 01|01|08 00 20 0a aa 6d
Dans l'en-tête IPv6, l'adresse de la source est l'adresse globale de l'interface d'émission 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.
L'adresse de destination est l'adresse de multicast sollicitée associée à l'adresse recherchée, et l'adresse Ethernet de destination est l'adresse associée à cette adresse multicast [RFC 2464]. L'adresse IPv6 multicast sollicitée offre une alternative efficace par rapport à un envoi en diffusion [1].
Le message NS apparait en bleu dans la trace. Le format du message est représenté par la figure 8. Ce message NS contient, dans le champ cible, l'adresse IPv6 du 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 9. La trace 4 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 : 0xf0 Label : 000000 Longueur : 32 octets (0x20) Protocole : 58 (0x3a, ICMPv6) Nombre de sauts : 255 (0xff) Source : fe80::1800:20ff:fe0c:7a34 (ganesha, lien-local) Desti. : 2001:db8:12:3:0a00:20ff:fe0a:aa6d (uma) ICMPv6 Type : 136 (0x88, Annonce de voisin) Code : 0 Checksum : 0xd7fb Bits (0x7) R = 1, S = 1, O = 1 Cible : 2001:db8:12:3::3 (ganesha) Option : Type : 2 (Adresse physique cible) Lg : 8 octets (0x01) : 1a-00-20-0c-7a-34
L'adresse source utilisée par Ganesha est celle de portée locale au lien. Le bit R indique que le 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 5 et 6 un échange NUD. Il s'agit du nœud Ganesha qui lance une vérification de la validité du nœud Uma.
IPv6 Version : 6 Classe : 0x00 Label : 000000 Longueur : 32 octets (0x20) Protocole : 58 (0x3a, ICMPv6) Nombre de sauts : 255 (0xff) Source : fe80::1800:20ff:fe0c:7a34 (ganesha, lien-local) Desti. : 2001:db8:12:3:a00:20ff:fe0a:aa6d (uma) ICMPv6 Type : 135 (0x87, Sollicitation de voisin) Code : 0 Checksum : 0x1116 Cible : 2001:db8:12:3:a00:20ff:fe0a:aa6d (uma) Option : Type : 1 (Adresse physique source) Lg : 8 octets (0x01) : 1a-00-20-0c-7a-34 0000: 6000 0000 0020 3aff fe80 0000 0000 0000 0010: 1800 20ff fe0c 7a34 2001 0db8 0012 0003 0020: 0a00 20ff fe0a aa6d|8700 1116 0000 0000 0030: 2001 0db8 0012 0003 0a00 20ff fe0a aa6d 0040: 0101 1a00 200c 7a34
On remarque que le message de sollicitation est envoyé par une communication unicast avec l'adresse IPv6 qui est enregistrée dans les tables de correspondance. Si une réponse n'arrive pas, 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.
IPv6 Version : 6 Classe : 0x00 Label : 000000 Longueur : 24 octets (0x18) Protocole : 58 (0x3a, ICMPv6) Nombre de sauts : 255 (0xff) Source : 2001:db8:12:3:a00:20ff:fe0a:aa6d (uma) Desti. : fe80::1800:20ff:fe0c:7a34 (ganesha, lien-local) ICMPv6 Type : 136 (0x88, Annonce de voisin) Code : 0 Checksum : 0x855f Bits (0x4) R = 0, S = 1, O = 0 Cible : 2001:db8:12:3:a00:20ff:fe0a:aa6d (uma) 0000: 6000 0000 0018 3aff 2001 0db8 0012 0003 0010: 0a00 20ff fe0a aa6d fe80 0000 0000 0000 0020: 1800 20ff fe0c 7a34|8800 855f 4000 0000 0030: 2001 0db8 0012 0003 0a00 20ff fe0a aa6d
Fonctionnement de la détection d'adresse dupliquée
Pour vérifier l'unicité des adresses lien-local ou unicast qui viennent d'être configurées manuellement ou automatiquement sur leurs interfaces, les nœuds doivent exécuter un algorithme de "Détection d'Adresse Dupliquée" (DAD) avant de les utiliser [RFC 4862]. L'algorithme utilise les messages ICMPv6 "Sollicitation d'un voisin" et "Annonce d'un voisin". Si une adresse déjà en service est découverte, elle ne pourra être attribuée à l'interface. L'auto-configuration s'arrête et une intervention humaine devient obligatoire.
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.
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 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 d'un 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 d'un 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 affichée par la commande tcpdump ci-dessous illustre le premier cas. Un hôte active son interface réseau, et après avoir constitué une adresse unicast par auto-configuration, effectue une DAD (nous verrons le détail de la construction de l'adresse dans la prochaine activité). Comme l'adresse provisoire n'est pas unique, un message NA est reçu pour signaler que cette adresse est une adresse valide d'un autre nœud sur le lien.
1 IP6 :: > ff02::1:ff02:202: ICMP6, neighbor solicitation, who has 2001:db8:b:2:fd:c8ff:fe02:202 2 IP6 2001:db8:b:2:fd:c8ff:fe02:202 > ff02::1: ICMP6, neighbor advertisement, tgt is 2001:db8:b:2:fd:c8ff:fe02:202
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.
À noter que la procédure DAD n'offre pas une fiabilité absolue ; notamment lorsque le lien est coupé.
Conclusion
Cette activité a présenté les fonctions assurées par le protocole ICMPv6. Ce protocole est en effet indispensable au bon fonctionnement de la couche réseau. Par ce protocole, les défauts qui peuvent affecter la connectivité IPv6 peuvent être connus et, donc, corrigés.
A l'échelle de l'Internet, le bon acheminement d'un paquet IPv6 est contrôlé et les défauts sont notifiés à l'émetteur par des messages ICMPv6. Ainsi, en cas de non livraison d'un paquet, les informations fournies par ICMPv6 vont servir à découvrir le problème et à adapter la communication si besoin est.
A l'échelle du lien, c'est à travers le protocole ICMPv6 que les nœuds se découvrent entre eux, vérifient l'unicité de leurs adresses et gèrent les abonnements aux groupes multicast.
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
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 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 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 4620 IPv6 Node Information Queries
- RFC 4861 Neighbor Discovery for IP version 6 (IPv6) Analyse
- RFC 4862 IPv6 Stateless Address Autoconfiguration Analyse
- RFC 4890 Recommendations for Filtering ICMPv6 Messages in Firewalls
- RFC 6275 Mobility Support in IPv6
- RFC 8201 Path MTU Discovery for IP version 6 Analyse
- RFC 8883 ICMPv6 Errors for Discarding packets Due to Processing Limits Analyse
