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.