1 – Définition du protocole ARP

Le protocole Arp, signifiant Address Resolution Protocol, fonctionne en couche Internet du modèle TCP/IP correspondant à la couche 3 du modèle Osi. L’objectif de Arp est de permettre la résolution d’une adresse physique par l’intermédiaire de l’adresse IP correspondante d’un host distant. Le protocole Arp apporte un mécanisme de « translation » pour résoudre ce besoin.

Vous trouverez tous les détails de l’entête Arp et du protocole dans la RFC 826 « An Ethernet Address Resolution Protocol ». Un complément est sortie en juillet 2008 avec la RFC 5227 « IPv4 Address Conflict Detection ».

2 – Structure de l’entête ARP

Voici l’entête du protocole ARP dans le cadre spécifique d’Ip sur Ethernet.

3 – Définition des différents champs

3.1 – Hardware type

Ce champs est placé en premier afin d’indiquer quel est le format de l’entête Arp. Voici les différentes valeurs possibles.

• 01 – Ethernet (10Mb) [JBP]
• 02 – Experimental Ethernet (3Mb) [JBP]
• 03 – Amateur Radio AX.25 [PXK]
• 04 – Proteon ProNET Token Ring [Doria]
• 05 – Chaos [GXP]
• 06 – IEEE 802 Networks [JBP]
• 07 – ARCNET [JBP]
• 08 – Hyperchannel [JBP]
• 09 – Lanstar [TU]
• 10 – Autonet Short Address [MXB1]
• 11 – LocalTalk [JKR1]
• 12 – LocalNet (IBM PCNet or SYTEK LocalNET) [JXM]
• 13 – Ultra link [RXD2]
• 14 – SMDS [GXC1]
• 15 – Frame Relay [AGM] 
• 16 – Asynchronous Transmission Mode (ATM) [JXB2]
• 17 – HDLC [JBP]
• 18 – Fibre Channel [Yakov Rekhter]
• 19 – Asynchronous Transmission Mode (ATM) [RFC2225]
• 20 – Serial Line [JBP] 
• 21 – Asynchronous Transmission Mode (ATM) [MXB1]
• 22 – MIL-STD-188-220 [Jensen]
• 23 – Metricom [Stone]
• 24 – IEEE 1394.1995 [Hattig]
• 25 – MAPOS [Maruyama]
• 26 – Twinaxial [Pitts]
• 27 – EUI-64 [Fujisawa]
• 28 – HIPARP [JMP]
• 29 – IP and ARP over ISO 7816-3 [Guthery]
• 30 – ARPSec [Etienne] 
• 31 – IPsec tunnel [RFC3456]
• 32 – InfiniBand (TM) [Kashyap]
• 33 – TIA-102 Project 25 Common Air Interface (CAI) [Anderson]

On remarquera tout particulièrement que le numéro 1 qui le plus fréquents. En effet ces architectures sont principalement utilisées dans les réseaux d’entreprises, Wifi, et Metro.

3.2 – Protocol type

Ce champs indique quel est le type de protocole couche 3 qui utilise Arp. Voici la valeur propre à Ip.

• 0x0800 – IP

3.3 – Hardware Address Length

Ce champ correspond à la longueur de l’adresse physique. La longueur doit être prise en octets. Voici des exemples de valeurs courantes.

• 01 – Token Ring
• 06 – Ethernet

3.4 – Protocol Address Length

Ce champ correspond à la longueur de l’adresse réseau. La longueur doit être prise en octets. Voici des exemples de valeurs courantes.

• 04 – IP v4
• 16 – IP v6

3.5 – Operation

Ce champ permet de connaître la fonction du message et donc son objectif. Voici les différentes valeurs possibles.

• 01 – Request [ RFC 826]
• 02 – Reply [ RFC 826]

3.6 – Sender Hardware Address

Ce champ indique l’adresse physique de l’émetteur. Dans le cadre spécifique d’Ethernet, cela représente l’adresse Mac source.

3.7 – Sender Internet Address

Ce champ indique l’adresse réseau de l’émetteur. Dans le cadre spécifique de TCP/IP, cela représente l’adresse Ip de source.

 3.8 – Target Hardware Address

Ce champ indique l’adresse physique du destinataire. Dans le cadre spécifique d’Ethernet, cela représente l’adresse Mac destination. Si c’est une demande Arp, alors, ne connaissant justement pas cette adresse, le champs sera mis à 0.

3.9 – Target Internet Address

Ce champ indique l’adresse réseau du destinataire. Dans le cadre spécifique de TCP/IP, cela représente l’adresse Ip de destination.

4 – Fonctionnement ARP

Pour envisager une discussion entre deux Host se situant dans le même LAN, les deux hosts doivent avoir connaissance des adresses physiques des machines avec lesquelles elles discutent. De ce mécanisme découle une table de conversion contenant à la fois les adresses Ip et Mac. L’alimentation de cette table peut s’effectuer de deux manières, automatique via Arp ou manuelle via l’administrateur. Considérons que ces deux hosts n’ont jamais discuté ensemble. Voici la réponse suite à la commande « arp -a » correspondante à ces deux hosts montrant le contenu du cache local.

La machine source ne connaissant pas l’adresse physique de la machine destinatrice, celle-ci va émettre une trame Broadcast de niveau 2 s’adressant à toutes les hôtes du réseau, comportant sa propre adresse physique et la question demandée. Puis, l’hôte de destination va se reconnaître et répondre en Unicast.

4.1 – Arp Request

La question de type Arp Request se présente sous cette forme : « Je suis l’hôte « 00 08 54 0b 21 77», Est-ce que l’hôte possédant l’adresse Ip 192.168.0.1 peut me retourner son adresse physique ? ». Voici la traduction de cette requête saisie grâce à Ethereal.

4.2 – Arp Reply

L’hôte destinataire qui va se reconnaître va pouvoir d’un coté alimenter sa table de conversion et répondre à l’hôte source en envoyant une trame comportant son adresse physique. Voici la traduction de cette réponse saisie grâce à Ethereal.

4.3 – Le cache ARP

4.3.1 – Le cache des hôtes

Par la forme de la question et de la réponse, on s’aperçoit que la table Arp des deux hôtes ont été alimenté. Voici la table Arp de la machine 192.168.0.3.

Voici la table Arp de la machine 192.168.0.1.

4.3.2 – Le cache dans la Rfc

Les mises en caches sont systématiques et obligatoires. Le fonctionnement du cache est bien caché dans le Rfc 826, mais l’on retrouve trois références.

La première concerne l’envoi. Elle se trouve dans le chapitre « An Example: » dont voici un extrait :

An Example:
 -----------
 
 ...
 
 Machine X gets the reply packet from Y, forms the map from
 <ET(IP), IPA(Y)> to EA(Y), notices the packet is a reply and
 throws it away.  The next time X's Internet module tries to send
 a packet to Y on the Ethernet, the translation will succeed, and
 the packet will (hopefully) arrive.  If Y's Internet module then
 wants to talk to X, this will also succeed since Y has remembered
 the information from X's request for Address Resolution.

Cette exemple spécifie que l’émetteur, après réception de la réponse, met en cache la correspondance @mac @ip afin de la réutiliser la prochaine fois sans émettre de nouvelle requête.

La seconde concerne la réception. Elle se trouve dans le chapitre « Packet Reception: » dont voici un extrait :

Packet Reception:
 -----------------
 
 When an address resolution packet is received, the receiving
 Ethernet module gives the packet to the Address Resolution module
 which goes through an algorithm similar to the following.
 Negative conditionals indicate an end of processing and a
 discarding of the packet.
 
 ?Do I have the hardware type in ar$hrd?
 Yes: (almost definitely)
   [optionally check the hardware length ar$hln]
   ?Do I speak the protocol in ar$pro?
   Yes:
     [optionally check the protocol length ar$pln]
     Merge_flag := false
     If the pair <protocol type, sender protocol address> is
         already in my translation table, update the sender
 hardware address field of the entry with the new
 information in the packet and set Merge_flag to true.

Cette explication du fonctionnement basé sur le conditionnel aboutit, si le récepteur possède déjà l’entrée dans son cache, à mettre l’entrée obligatoirement à jour. Et ça, quelle soit ou pas identique au cache actuel. Cette dernière réflexion est très importante pour comprendre la faiblesse de ce process qui vise à privilégier l’économie et la rapidité à l’encontre de la sécurité.

 La troisième référence concerne aussi la réception. Elle se trouve dans le chapitre « An Example: » dont voici un extrait :

An Example:
 -----------
 
 Let there exist machines X and Y that are on the same 10Mbit
 Ethernet cable.  They have Ethernet address EA(X) and EA(Y) and
 DOD Internet addresses IPA(X) and IPA(Y) .  Let the Ethernet type
 of Internet be ET(IP).  Machine X has just been started, and
 sooner or later wants to send an Internet packet to machine Y on
 the same cable.  X knows that it wants to send to IPA(Y) and
 tells the hardware driver (here an Ethernet driver) IPA(Y).  The
 driver consults the Address Resolution module to convert <ET(IP),
 IPA(Y)> into a 48.bit Ethernet address, but because X was just
 started, it does not have this information.  It throws the
 Internet packet away and instead creates an ADDRESS RESOLUTION
 packet with
 (ar$hrd) = ares_hrd$Ethernet
 (ar$pro) = ET(IP)
 (ar$hln) = length(EA(X))
 (ar$pln) = length(IPA(X))
 (ar$op)  = ares_op$REQUEST
 (ar$sha) = EA(X)
 (ar$spa) = IPA(X)
 (ar$tha) = don't care
 (ar$tpa) = IPA(Y)
 and broadcasts this packet to everybody on the cable.
 
 Machine Y gets this packet, and determines that it understands
 the hardware type (Ethernet), that it speaks the indicated
 protocol (Internet) and that the packet is for it
 ((ar$tpa)=IPA(Y)).  It enters (probably replacing any existing
 entry) the information that <ET(IP), IPA(X)> maps to EA(X).

Cette exemple confirme bien la mise en cache systématique quelque soit l’état du cache actuel. Traduction mot à mot de la dernière phrase : « Elle écrit (remplaçant probablement toute entrée existante) l’information qui < ET(ip), des cartes d’cIpa(x) > à EA(x). »

5 – Les vidéos

• 5.1 - Présentation basique de ARP

  Vidéo présentant les bases du fonctionnemet de ARP. Pour cela, vous y découvrirez les commandes correspondantes aux différentes requêtes ARP.

  

• 5.2 - Address Resolution Protocol par Mr Cisco

  Vidéo en anglais de Mr Cisco présentant le protocole de routage ARP (Address Resolution Protocol).

  

• 5.3 - Arp Header

  Video en anglais présentant en détail l'ensemble des champs de l'entête ARP.

  

• 5.4 - Le mécanisme ARP

  L'ARP (Address Resolution Protocol) est à la base de nombreux mécanisme de réseaux. Cette vidéo clarifie quelques points sur ce protocole trop souvent incompris.

  

• 5.5 - Exercice sur ARP

  Video présentant, sous forme d'excercice, des cas concrets du protocole ARP.

  

6 – Suivi du document

Création et suivi de la documentation par _JE et _SebF

Modification de la documentation par Eric Lalitte

• Remplacement du mot Broadcast par Unicast dans le schéma du chapitre 4.2

Modification de la documentation par PascalLX

• Correction du paragraphe 3.4 en spécifiant que ipv6 = 16 et non pas 06

Modification de la documentation par _SebF

• Ajout dans le chapitre 1 de la rérerence à la RFC 5227 « IPv4 Address Conflict Detection »

7 – Discussion autour de l’entête ARP

Vous pouvez poser toutes vos questions, faire part de vos remarques et partager vos expériences à propos de l’entête ARP. Pour cela, n’hésitez pas à laisser un commentaire ci-dessous :