Entête ARP

Entête ARP

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.

entete-arp entete arp partie 1entete-arp entete arp partie 2

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.

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.

entete-arp fonctionnement cmd line
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.

entete-arp arp request

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.

entete-arp arp reply

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.

entete-arp cache hotes

Voici la table Arp de la machine 192.168.0.1.

entete-arp table arp

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 – 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 »

6 – 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 :

Commentaire et discussion

10 commentaires sur la page : “Entête ARP”

  1. Je reviens encore avec une autre question sur le protocole ARP. Je sais que le rôle de ARP est d’obtenir l’adresse physique d’un host distant a partir de son adresse IP, cette notion est bien acquise pour moi. Je sais également que ce processus permettra a chaque host de construire et maintenir un cache ARP.
    Ma question est pourquoi faire une requête ARP? Est-ce dans l’objectif de fournir des informations pour la construction de l’entête de la trame qui va encapsuler le datagram IP lors des échanges entre les deux host ? ou y’a t’il un autre objectif?
    Excusez moi si ma question parait idiote, mais je veux bien maitriser et comprendre tous ces mécanismes.

    1. Lu Edi,

      N’hésite à abuser du site, c’est juste du pure partage 🙂 Et si tu as des questions, vas y sans soucis 🙂

      Ta question en synthèse est : « A quoi ça sert de connaitre l’adresse MAC de son destinataire* ? »

      Et bien je vais te répondre par une question pédagogique. Si tu ne connais pas l’adresse MAC de ton destinataire, tu envoi ta trame à destination de FFFFFFFFFFFF alors. Et que ce passera t il ?

      Je te fais la réponse 🙂 Alors ta trame sera diffuser sur tous les ports physique de ton Switch en Broadcast et Tous les Hosts du réseau recevront ta trame. Pire qu’un HUB 🙂
      Donc, il est intéressant de connaitre l’adresse MAC du destinataire pour :
      – Optimiser les performances LAN
      – Segmenter les trafics en terme de confidentialité
      – D’économiser du traitement de la carte réseau et ou CPU des Hôtes du LAN
      – Choisir son routeur

      * Destinataire, attention, l’adresse MAC connu est forcement un HOST du LAN et donc celle du routeur si on dois changer de LAN.

      @+

      _SebF

  2. Merci infiniment pour ce cours, c’est très enrichissant.
    cependant, j’ai une question:
    l’entête d’un paquet ARP contient des champs sender internet address et target internet address, qui ont une longueur de 4 octets comme le montre cette belle illustration. Comment transporter une adresse IPv6 qui a 16 octets?
    Je me suis pose cette question mais je n’ai pas trouve de réponse.

    1. Lu Edi,

      Pour éviter de répondre à ta question, je pourrais te préciser que les fonctions d’ARP dans le monde IPv6 sont géré, non pas par ARP, mais par NDP ( Neighbor Discovery Protocol).

      Mais pour répondre précisément à ta question, la taille d’un datagramme ARP est de 28 octets. En fait c’est plus exactement le cas d’ARP en mode IPv4.
      Si tu change le champs « Protocol Address Length », alors la taille attendue est différente. Et c’est à ce moment que le problème n’en n’ai plus un 🙂 Les adresses IPv6 rentre, vue que la taille est changée.

      @+

      _SebF

      1. Merci pour l’explication. Je suis en train d’enrichir mes connaissances en parcourant tous les chapitres des cours disponibles sur votre site de façon graduelle. Je ne suis pas encore arrivé au chapitre concernant l’entête IPv6, d’ou ma question un peu prématurée.
        Merci pour le travail que vous faites. Cela me permet d’approfondir mes connaissances sur des notions qui demeuraient encore floues dans mon esprit.
        Encore merci.

  3. Quand est ce que se font l’ajout et la suppression dans le cache arp ?
    Quels sont les cas qui causent une modification dans le cache arp ?

    1. Lu Mohamed,

      La rétention en cache des correspondance @MAC/@IP n’est pas imposée. Cela reste libre dans son implémentation et donc spécifique à chaque environnement. Ainsi, un Windows, un Linux, un Cisco et autres, vont gérer cela à leur convenance.

      En parallèle, il existe une RFC qui définit, sans rien imposer ni arrêter, des conseils et recommandation sur la gestion du cache ARP. Pour cela, regarde la RFC 1122 – Requirements for Internet Hosts — Communication Layers.

      @+

      _SebF

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *