ARP est le Protocole de
Résolution d'Adresse (Address Resolution
Protocol). Il est décrit dans le RFC 826. ARP est utilisé par une machine d'un réseau
local pour retrouver l'adresse matérielle (la localisation) d'une
autre machine sur le même réseau. Les machines sur Internet sont
généralement connues par leur nom auquel correspond une adresse IP.
C'est ainsi qu'une machine sur le réseau foo.com est capable de communiquer avec une autre
machine qui est sur le réseau bar.net.
Une adresse IP, cependant, ne peut pas vous indiquer la
localisation physique de la machine. C'est ici que le protocole
ARP entre en jeu.
Prenons un exemple très simple. Supposons que j'aie un réseau
composé de plusieurs machines, dont la machine foo d'adresse IP 10.0.0.1 et la machine bar qui a l'adresse IP 10.0.0.2. Maintenant, foo veut envoyer un ping vers bar pour voir s'il est actif, mais foo n'a aucune indication sur la localisation de
bar. Donc, si foo décide d'envoyer un ping vers bar, il a besoin d'envoyer une requête
ARP. Cette requête
ARP est une façon pour
foo de crier sur le réseau
« Bar (10.0.0.2) ! Où
es-tu ? ». Par conséquent, toutes les machines
sur le réseau entendront foo crier,
mais seul bar (10.0.0.2) répondra. Bar enverra une réponse ARP directement à foo ; ce qui revient à dire : « Foo (10.0.0.1) ! je suis ici, à
l'adresse 00:60:94:E:08:12 ». Après cette simple
transaction utilisée pour localiser son ami sur le réseau,
foo est capable de communiquer avec
bar jusqu'à ce qu'il (le cache
ARP de foo) oublie où bar est situé (typiquement au bout
de 15 minutes sur Unix).
Maintenant, voyons comment cela fonctionne. Vous pouvez consulter votre cache (table) ARP (neighbor) comme ceci :
[root@espa041 /home/src/iputils]# ip neigh show 9.3.76.42 dev eth0 lladdr 00:60:08:3f:e9:f9 nud reachable 9.3.76.1 dev eth0 lladdr 00:06:29:21:73:c8 nud reachable
Comme vous pouvez le voir, ma machine espa041 (9.3.76.41)
sait où trouver espa042 (9.3.76.42) et espagate (9.3.76.1).
Maintenant, ajoutons une autre machine dans le cache
ARP.
[root@espa041 /home/paulsch/.gnome-desktop]# ping -c 1 espa043 PING espa043.austin.ibm.com (9.3.76.43) from 9.3.76.41 : 56(84) bytes of data. 64 bytes from 9.3.76.43: icmp_seq=0 ttl=255 time=0.9 ms 1 packets transmitted, 1 packets received, 0% packet loss round-trip min/avg/max = 0.9/0.9/0.9 ms [root@espa041 /home/src/iputils]# ip neigh show 9.3.76.43 dev eth0 lladdr 00:06:29:21:80:20 nud reachable 9.3.76.42 dev eth0 lladdr 00:60:08:3f:e9:f9 nud reachable 9.3.76.1 dev eth0 lladdr 00:06:29:21:73:c8 nud reachable
Par conséquent, lorsque espa041 a
essayé de contacter espa043, l'adresse
matérielle de espa043 (sa
localisation) a alors été ajoutée dans le cache ARP. Donc, tant que la durée de vie de l'entrée
correspondant à espa043 dans le cache
ARP n'est pas dépassée,
espa041 sait localiser espa043 et n'a plus besoin d'envoyer de requête
ARP.
Maintenant, effaçons espa043 de
notre cache ARP.
[root@espa041 /home/src/iputils]# ip neigh delete 9.3.76.43 dev eth0 [root@espa041 /home/src/iputils]# ip neigh show 9.3.76.43 dev eth0 nud failed 9.3.76.42 dev eth0 lladdr 00:60:08:3f:e9:f9 nud reachable 9.3.76.1 dev eth0 lladdr 00:06:29:21:73:c8 nud stale
Maintenant, espa041 a à nouveau
oublié la localisation d'espa043 et
aura besoin d'envoyer une autre requête ARP la prochaine fois qu'il voudra communiquer
avec lui. Vous pouvez aussi voir ci-dessus que l'état
d'espagate (9.3.76.1) est passé en stale. Cela signifie que la localisation connue
est encore valide, mais qu'elle devra être confirmée à la première
transaction avec cette machine.