MOOC:Compagnon Act31-s7 - Revision history

Bstevant: /* Fonctionnement de la résolution d'adresse IP */

2024-10-18T08:07:17Z

‎Fonctionnement de la résolution d'adresse IP

Bstevant: /* Fonctionnement de la résolution d'adresse IP */

2023-02-10T15:10:10Z

‎Fonctionnement de la résolution d'adresse IP

Bstevant: /* Fonctionnement de la résolution d'adresse IP */

2023-02-10T14:26:28Z

‎Fonctionnement de la résolution d'adresse IP

Bstevant: /* Fonctionnement de la résolution d'adresse IP */

2023-02-10T09:40:48Z

‎Fonctionnement de la résolution d'adresse IP

Bstevant: /* Fonctionnement de la résolution d'adresse IP */

2023-02-10T07:51:10Z

‎Fonctionnement de la résolution d'adresse IP

Bstevant: /* Fonctionnement de la résolution d'adresse IP */

2023-02-08T08:26:26Z

‎Fonctionnement de la résolution d'adresse IP

Bstevant: /* En-tête redirigée */

2022-04-19T22:28:05Z

‎En-tête redirigée

Vlerouvillois: /* Conclusion */

2022-04-19T15:24:38Z

‎Conclusion

Vlerouvillois: /* Introduction */

2022-03-06T08:31:58Z

‎Introduction

Bstevant: /* Pour aller plus loin */

2022-02-25T14:42:13Z

‎Pour aller plus loin

@@ Line 136: / Line 136: @@
 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].
-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 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.
-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 9. La trace 2 montre la réponse émise.
+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.
   <font color="green">Ethernet Src : 1a:0:20:c:7a:34 Dst : 8:0:20:a:aa:6d Type : 0x86dd</font>

@@ Line 123: / Line 123: @@
      Type : 1 (Adresse physique source) Lg : 8 octets (0x01) : 08-00-20-0a-aa-6d
   </font>
-: <font color="green">''08 00 20 0a aa 6d 33 33 ff 00 00 03 86 dd</font>|60 00''
+: <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''
@@ Line 149: / Line 149: @@
   <font color="blue">ICMPv6
    Type : 136 (0x88, Annonce de voisin) Code : 0 Checksum : 0x028a
-   Bits (0x7) R = 1, S = 1, O = 1
+   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">''1a 00 20 0c 7a 34 08 00 20 0a aa 6d 86 dd</font>|60 00''
+: ''<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''
@@ Line 170: / Line 170: @@
 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
+  <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
@@ Line 181: / Line 181: @@
    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
+   Type : 1 (Adresse physique source) Lg : 8 octets (0x01) : 1a-00-20-0c-7a-34
   </font>
-:  ''6000 0000 0020 3aff fe80 0000 0000 0000''
+: ''<font color="green">1a 00 20 0c 7a 34 08 00 20 0a aa 6d 86 dd</font>|60 00''
-:  ''1800 20ff fe0c 7a34 2001 0db8 0012 0003''
+: ''00 00 00 20 3a ff fe 80 00 00 00 00 00 00 18 00''
-:  ''0a00 20ff fe0a aa6d|<font color="blue">8700 1116 0000 0000''</font>
+: ''20 ff fe 0c 7a 34 20 01 0d b8 00 12 00 03 0a 00''
-:  <font color="blue">''2001 0db8 0012 0003 0a00 20ff fe0a aa6d''</font>
+: ''20 ff fe 0a aa 6d<font color="blue">|87|00|11 16|00 00 00 00|20 01''</font>
-:  <font color="blue">''0101 1a00 200c 7a34''</font>
+: <font color="blue">''0d b8 00 12 00 03 0a 00 20 ff fe 0a aa 6d|01|01|''</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.
-  Ethernet Src : 1a:0:20:c:7a:34 Dst : 8:0:20:a:aa:6d Type : 0x86dd
+ <font color="green">Ethernet Src : 1a:0:20:c:7a:34 Dst : 8:0:20:a:aa:6d Type : 0x86dd</font>
-  IPv6
+ IPv6
-    Version : 6 Classe : 0x00 Label : 000000
+  Version : 6 Classe : 0x00 Label : 000000
-    Longueur : 24 octets (0x18) Protocole : 58 (0x3a, ICMPv6)
+  Longueur : 24 octets (0x18) Protocole : 58 (0x3a, ICMPv6)
-    Nombre de sauts : 255 (0xff)
+  Nombre de sauts : 255 (0xff)
-    Source : 2001:db8:12:3:a00:20ff:fe0a:aa6d (uma)
+  Source : 2001:db8:12:3:a00:20ff:fe0a:aa6d (uma)
-    Desti. : fe80::1800:20ff:fe0c:7a34        (ganesha, lien-local)
+  Desti. : fe80::1800:20ff:fe0c:7a34        (ganesha, lien-local)
   <font color="blue">ICMPv6
-    Type : 136 (0x88, Annonce de voisin) Code : 0 Checksum : 0x855f
+  Type : 136 (0x88, Annonce de voisin) Code : 0 Checksum : 0x855f
-    Bits (0x4) R = 0, S = 1, O = 0
+  Bits (0x4) R = 0, S = 1, O = 0
-    Cible : 2001:db8:12:3:a00:20ff:fe0a:aa6d (uma)
+  Cible : 2001:db8:12:3:a00:20ff:fe0a:aa6d (uma)
   </font>
-:  ''6000 0000 0018 3aff 2001 0db8 0012 0003''
+: ''<font color="green">08 00 20 0a aa 6d 1a 00 20 0c 7a 34 86 dd</font>|60 00''
-:  ''0a00 20ff fe0a aa6d fe80 0000 0000 0000''
+: ''00 00 00 18 3a ff 20 01 0d b8 00 12 00 03 0a 00''
-:  ''1800 20ff fe0c 7a34|<font color="blue">8800 855f 4000 0000''</font>
+: ''20 ff fe 0a aa 6d fe 80 00 00 00 00 00 00 18 00''
-:  <font color="blue">''2001 0db8 0012 0003 0a00 20ff fe0a aa6d</font>''
+: ''20 ff fe 0c 7a 34|<font color="blue">88|00|85 5f|40|00 00 00|20 01</font>''
 <center>'''Trace 4 : Message ICMPv6 Annonce de voisin(NA).'''</center>

@@ Line 140: / Line 140: @@
 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 9. 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
+  <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
@@ Line 148: / Line 148: @@
    Desti. : 2001:db8:12:3:0a00:20ff:fe0a:aa6d (uma)
   <font color="blue">ICMPv6
-   Type : 136 (0x88, Annonce de voisin) Code : 0 Checksum : 0xd7fb
+   Type : 136 (0x88, Annonce de voisin) Code : 0 Checksum : 0x028a
    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
+   Type : 2 (Adresse physique cible) Lg : 8 octets (0x01) : 1a-00-20-0c-7a-34
   </font>
 <center>'''Trace 2 : Message ICMPv6 Annonce de voisin(NA).'''</center>

@@ Line 112: / Line 112: @@
   <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 : 0xf0 Label : 000000
+   Version : 6 Classe : 0x00 Label : 000000
    Longueur : 32 octets (0x0020) Protocole : 58 (0x3a, ICMPv6)
    Nombre de sauts : 255 (0xff)
@@ Line 142: / Line 142: @@
   Ethernet Src : 1a:0:20:c:7a:34 Dst : 8:0:20:a:aa:6d Type : 0x86dd
   IPv6
-   Version : 6 Classe : 0xf0 Label : 000000
+   Version : 6 Classe : 0x00 Label : 000000
    Longueur : 32 octets (0x20) Protocole : 58 (0x3a, ICMPv6)
    Nombre de sauts : 255 (0xff)

@@ Line 110: / Line 110: @@
 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
+  <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 : 0xf0 Label : 000000
@@ Line 118: / Line 118: @@
    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 : 0x4d7f
+   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
+    Type : 1 (Adresse physique source) Lg : 8 octets (0x01) : 08-00-20-0a-aa-6d
   </font>
-: ''6f 00 00 00 00 20 3a ff 20 01 0d b8 00 12 00 03''
+: <font color="green">''08 00 20 0a aa 6d 33 33 ff 00 00 03 86 dd</font>|60 00''
-: ''0a 00 20 ff fe 0a aa 6d ff 02 00 00 00 00 00 00''
+: ''00 00 00 20 3a ff 20 01 0d b8 00 12 00 03 0a 00''
-: ''00 00 00 01 ff 00 00 03|<font color="blue">87|00|4d 7f|00 00 00 00|''</font>
+: ''20 ff fe 0a aa 6d ff 02 00 00 00 00 00 00 00 00''
-: <font color="blue">''20 01 0d b8 00 12 00 03 00 00 00 00 00 00 00 03|''</font>
+: ''00 01 ff 00 00 03|<font color="blue">87|00|78 0d|00 00 00 00|20 01''</font>
-: <font color="blue">''01|01|08 00 20 0a aa 6d''</font>
+: <font color="blue">''0d b8 00 12 00 03 00 00 00 00 00 00 00 03|01|01|''</font>
 <center>'''Trace 1: Message ICMPv6 Sollicitation de voisin(NS).'''</center>

@@ Line 447: / Line 447: @@
 === <div id="redirigee">En-tête redirigée</div> ===
-[[Image:31-Afig3.png|400px|right|thumb|Figure 8 : Format de l'option en-tête redirigée.]]
+[[Image:31-Afig3-2.png|400px|right|thumb|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.

@@ Line 244: / Line 244: @@
 == Conclusion ==
-Nous nous sommes concentré dans cette activités 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 ses 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.
+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.

@@ Line 16: / Line 16: @@
 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é à 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.
+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 ==

@@ Line 261: / Line 261: @@
 * RFC 4861 Neighbor Discovery for IP version 6 (IPv6) [http://www.bortzmeyer.org/4861.html Analyse]
 * RFC 4862 IPv6 Stateless Address Autoconfiguration  [http://www.bortzmeyer.org/4862.html Analyse]
 = ANNEXE Activité 31 : Autres fonctions de la découverte des voisins =