ARP en IPv6 ? 
Dans le dernier article sur IPv6, nous avions constaté ensemble que la résolution d’adresse ARP n’était pas utilisée en IPv6 (relire l’article ici). Pourtant, la problématique reste présente autant en IPv4 qu’en IPv6: alors, comment une adresse IPv6 destination est elle associée à l’adresse destination de la couche 2 ?
ICMPv6 ND: l’équivalent de ARP
Le procotole ICMP vous connaissez ? Mais, si: souvenez vous, on a fait une vidéo sur l’outil PING qui expliquait que « ping » exploitait le protocole ICMP (retrouvez cette vidéo ici)! ICMP, c’est un peu comme une signalisation associée au protocole IP: il sert à indiquer qu’il y a des erreurs ou pour échanger des informations entre couches IP…
Le protocole ICMP a été porté en environnement IPV6. Effectivement, lors de l’article sur les différentes adresses IP, nous avons même utilisé l’outil ping alors que l’adresse destination était une adresse IPv6: aucun problème, cela marchait !
Mais, dans le monde IPv6, le protocole ICMP (appelé ICMPv6) a été enrichi et étendu. Par exemple, il a été complété avec le protocole Neighbor Discovery (ND ou ICMPv6 ND) qui est l’équivalent du ARP en IPv4 (le fonctionnement de ARP a été présenté dans un précédent article, à relire ici) ….
Le protocole Neighbor Discovery (que l’on pourrait traduire par découverte des voisins) va plus loin que le protocole ARP et ses requêtes / réponses… Mais, commençons par identifier les différents types de messages définis par le protocole ICMPv6-ND.
Messages ICMPv6 Neighbor Discovery
Les deux messages qui sont les équivalents des messages « ARP Request » et « ARP Reply » sont les messages Neighbor Solicitation (NS) et Neighbor Advertisement (NA).
Dans le RFC Neighbor Discovery, on retrouve également les messages Redirect qui sont utilisés pour demander à un système d’utiliser une autre route, plus optimisée. Enfin, Neighbor Discovery définit également des messages qui n’ont pas d’équivalents dans le monde IPv4: ce sont les messages Router Solicitation (RS) et Router Advertisement (RA).
C’est également grâce à ce protocole qu’un système va pouvoir vérifier que l’adresse IP (la partie d’identifiant de l’interface) qu’il s’est octroyé est bien unique (en utilisant un nouveau protocole appelé DAD pour Duplicate Address Detection).
Mécanisme de Résolution d’adresses en environnement IPv6
Donc, on vient de le voir, la résolution d’adresses utilise des messages ICMPv6 (NS et NA) qui sont des équivalents des messages IPv4 « ARP Request » et « ARP Reply ». Nous reviendrons dans le détail mais là, à priori, les choses ont l’air simple.
Sauf que… ICMPv6 s’appuie sur IPv6. Ça veut donc dire que le message de recherche (l’équivalent de ARP Request) doit être envoyé dans un paquet IPv6… Mais… à quelle adresse de destination ? Souvenons nous qu’en environnement IPv4, la requête ARP est envoyée à l’adresse de diffusion Ethernet…
Solicited Node Multicast
Dans le monde IPv6, lorsqu’une adresse IPv6 est affectée à une interface, alors cette interface est automatiquement abonnée à un groupe multicast: un groupe appelé « Solicited Node« .
L’adresse du groupe Solicited Node est directement dérivée de l’adresse unicast. Cette adresse multicast est construite en associant une partie fixe (FF02:0:0:0:0:1:FF00::/104) et une partie qui correspond exactement aux 24 derniers bits de l’adresse unicast.
Dans l’exemple illustré ci-dessous, le PC dispose de 2 adresses IPv6 unicast: une adresse globale (donc routable) et une adresse (link-local) qui ne lui permet d’effectuer des échanges sur le seul LAN auquel il est raccordé.
A partir de la règle indiquée précédemment, on voit que le PC est alors automatiquement abonné à deux groupes multicast (groupe « Solicited-Node« ).
Le PC étant abonné à ces deux groupe, il va donc traiter les paquets IPv6 envoyés à destination de ce groupe multicast.
Envoi des messages Neighbor Solicitation
Puisque tous les systèmes IPv6 sont abonnés aux groupes « Solicited-Node » en fonction de leur adresse IPv6 unicast, il devient alors pertinent d’envoyer le message qui demande l’association [adresse MAC/ Adresse unicast IPv6] non pas à tous les systèmes du réseau (comme c’est le cas en IPv4) mais à l’adresse de groupe « Solicited-Node » (sachant qu’elle est dérivée de l’adresse unicast recherchée !).
Ainsi, dans l’exemple ci-dessous, le PC1 souhaite envoyer un paquet IPv6 vers PC2 pour lequel il ne connait pas l’adresse MAC. Il va utiliser le message ICMPv6 Neighbor Solicitation comme ceci :
La capture de ce message permet de mieux voir ce qui est effectivement envoyé sur le réseau:
Vous relèverez au passage que l’adresse MAC destination de cette trame est une adresse multicast. Ceci permet d’optimiser le trafic également sur l’infrastructure Ethernet. En effet, chaque groupe multicast IPv6 (et IPv4) se voit attribué un groupe multicast au niveau Ethernet. Dans cet exemple, c’est le groupe 33:33:ff:00:02:00
Réponse: le message Neighbor Advertisement
Après réception de la demande, le PC2 va donc émettre une réponse. Dans ce sens tout est plus simple puisque le PC2 dispose de toutes les informations lui permettant de répondre au PC1.
Après la réception de ce message, les PC1 et PC2 ont toutes les informations requises pour échanger des paquets IPv6. Et, comme en IPv4, ces informations sont stockées dans un cache: le cache Neighbor (Neighbor Cache).
Cache Neighbor
Pour voir le contenu du cache Neighbor, sous Windows, il faut utiliser la commande:
netsh interface ipv6 show neighbor
Voilà un exemple de retour de la commande:
Dans l’IOS Cisco, l’accès à cette table se fait à l’aide de la commande: show ipv6 neighbors comme le montre l’exemple ci-dessous:
C’est tout… Pour le moment ! Dans cet article, on a illustré que le protocole IPv6 ne peut pas se résumer à un protocole où les champs adresses sont plus grands. Le protocole a été repensé, optimisé, amélioré. Je viens de présenter un exemple dans cet article. Je le referai à d’autres occasions. Mais avant: avez-vous des questions ou des commentaires à me transmettre ? Utilisez la zone ci-dessous, c’est fait pour ça !
Laisser un commentaire