Ce protocole, qui ressemble beaucoup à l'ICMP du monde IPv4, a été enrichi de nouveaux messages, c'est lui qui sert à véhiculer les informations de configuration, dans le cas qui nous intéresse. En effet, nous n'allons maintenant plus tarder à voir que ce sont des messages ICMP qui contiennent les questions et les réponses que nous avons obtenues avec l'outil rdisc6, exactement de la même manière que lors du démarrage de la pile IPv6 sur une interface réseau.

Contrairement à IPv4, IPv6 n'utilise pas le broadcast au profit du multicast, plus restrictif. Certaines adresses multicast sont définies pour répondre à des requêtes bien précises, et les équipements du réseau qui sont sensés disposer des réponses à ces requêtes écoutent sur ces adresses multicast.

Comme nous les avons déjà rencontrées dans la page précédente:

• ff02::2 est une adresse multicast destinée à recevoir des requêtes du type « router discovery (Sollicitation d'un routeur) ». Tous les routeurs accessibles dans le voisinage le seront par cette adresse multicast. C'est ce que fait notre commande rdisc6 ;

• ff02::1 est une autre adresse multicast, qui sert dans l'autre sens. Toutes les stations d'un réseau doivent être capables d'écouter sur cette adresse ce que les routeurs ont à leur dire.

Pour savoir quelles sont sur un nœud, les interfaces à l'écoute des adresses muticast en IPv6, la commande netstat (du paquet net-tools):

netstat -n -6 --groups

Interface       RefCnt Group
--------------- ------ ---------------------
lo              1      ff02::1
lo              1      ff01::1
enp1s0          2      ff02::1:ff37:3649
enp1s0          1      ff02::1
enp1s0          1      ff01::1

ip link ls enp1s0

2: enp1s0: BROADCAST,MULTICAST,UP,LOWER_UP> ...
    link/ether 52:54:00:37:36:49

« Neighbor Discovery Protocol (découverte des voisins) ». Ce protocole permet aux nœuds d'un réseau de découvrir leur voisinage. Pour ce qui nous intéresse principalement ici, c'est grâce à lui qu'une station qui démarre découvre les routeurs qui lui sont accessibles et que ceux-ci lui communiquent les paramètres nécessaires à sa configuration IPv6. Car vous l'avez deviné, ce sont les routeurs qui transmettent ces informations que nous avons mises en évidence grâce à rdisc6.

NDP utilise des messages ICMPv6 et les adresses multicast ff02::1 et ff02::2.

Nous allons lancer notre wireshark favori à l'écoute d'ICMPv6 sur enp1s0 et refaire un rdisc6 enp1s0 sur notre station expérimentale pour voir…

No.  Source                     Destination             Protocol Info
 1   fe80::5054:ff:fe37:3649    ff02::2                 ICMPv6   Router Solicitation
 2   fe80::6aa3:78ff:fe86:ec02  fe80::5054:ff:fe37:3649 ICMPv6   Router Advertisement from 68:a3:78:86:ec:02

1. Notre station (fe80::5054:ff:fe37:3649) envoie un « Router solicitation (sollicitation de routeurs) » sur l'adresse multicast ff02::2 ;
2. un routeur dont l'adresse lien-local est fe80::6aa3:78ff:fe86:ec02 lui répond.

En IPv4, lorsqu'un nœud ne connaît pas l'adresse MAC correspondant à l'IPv4 du destinataire, il utilise le protocole ARP qui lui-même utilise un broadcast.

En IPv6, ARP n'est plus, broadcast non plus. À la place il y a NDP qui va utiliser une adresse multicast spécifique: la «Solicited-Node Multicast». Cette adresse est de la forme ff02::1:ff00:0/104 complétée par les 24 derniers bits de l'adresse IPv6 dont on cherche l'adresse MAC associée.

Si nous démarrons notre wireshark en filtrant à la capture uniquement le protocole ICMP6, nous allons récupérer dans le lot par exemple ceci:

No.   Source                       Destination               Protocol Info
 8    fe80::6aa3:7813:3786:ec02    ff02::1:ff37:3649         ICMPv6   Neighbor Solicitation for fe80::5054:ff:fe37:3649 from 68:a3:78:86:ec:02
 9    fe80::5054:ff:fe37:3649      fe80::6aa3:7813:3786:ec02 ICMPv6   Neighbor Advertisementfe80::5054:ff:fe37:3649 (sol, ovr) is at 52:54:00:37:36:49

37:3649 sont bien les 24 derniers bits que l'on trouve:

1. dans l'adresse multicast ff02::1:ff37:3649,
2. fe80::6aa3:7813:3786:ec02 pose la question et nous savons que c'est la Freebox,
3. dans l'adresse de la réponse fe80::5054:ff:fe37:3649, c'est la machine expérimentale.

Voilà pour un tour d'horizon rapide du protocole NDP

Donc, pour une raison quelconque, la Freebox a eu besoin de rattacher l'adresse lien-local de la machine expérimentale à son adresse MAC. En effet, la Freebox n'est pas en mesure de savoir si cette machine est auto-configurée ou non, autrement-dit, elle ne peut pas déduire à coup sûr l'adresse MAC de l'adresse lien-local.

En regardant la partie spécifique à ICMPv6 dans les deux trames:

Internet Control Message Protocol v6
    Type: Neighbor Solicitation (135)
    Code: 0
    Checksum: 0xecdb 
    Reserved: 00000000
    Target Address: fe80::5054:ff:fe37:3649
    ICMPv6 Option (Source link-layer address : 68:a3:78:86:ec:02)
        Type: Source link-layer address (1)
        Length: 1 (8 bytes)
        Link-layer address: FreeboxS_86:ec:02 (68:a3:78:86:ec:02)

La réponse:

Internet Control Message Protocol v6
    Type: Neighbor Advertisement (136)
    Code: 0
    Checksum: 0x7f63
    Flags: 0x60000000, Solicited, Override
        0... .... .... .... .... .... .... .... = Router: Not set
        .1.. .... .... .... .... .... .... .... = Solicited: Set
        ..1. .... .... .... .... .... .... .... = Override: Set
        ...0 0000 0000 0000 0000 0000 0000 0000 = Reserved: 0
    Target Address: fe80::5054:ff:fe37:3649
    ICMPv6 Option (Target link-layer address : 52:54:00:37:36:49)
        Type: Target link-layer address (2)
        Length: 1 (8 bytes)
        Link-layer address: RealtekU_37:36:49 (52:54:00:37:36:49)

1. qu'elle n'est pas un routeur,
2. qu'elle répond à une question,
3. que la réponse remplace éventuellement une donnée périmée.

Voilà pour un tout d'horizon rapide du protocole NDP