|
Entête Arp
par _JE
1 - Définition du protocole
2 - Structure de l'entête
3 - Définition des différents champs
3.1 -
Hardware type
3.2 - Protocol type
3.3 -
Hardware Address Length
3.4 -
Protocol Address Length
3.5 - Operation
3.6 - Sender Hardware Address
3.7 -
Sender Internet Address
3.8 -
Target Hardware Address
3.9 -
Target Internet Address
4 - Fonctionnement
4.1 - Arp Request
4.2 - Arp Reply
4.3 - Le cache
4.3.1 - Le cache des hôtes
4.3.2 - Le cache dans la Rfc
5 - Discussion autour de la
documentation
6 - Suivi du document
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 du protocole Arp 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".
Voici l'entête du protocole ARP dans le cadre spécifique d'Ip sur Ethernet.
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.
Ce champs indique quel est le type de
protocole couche 3 qui utilise Arp. Voici la valeur propre à Ip.
- 0x0800 - IP
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
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
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]
Ce champ indique l'adresse physique de l'émetteur.
Dans le cadre spécifique d'Ethernet, cela représente l'adresse Mac source.
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.
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.
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.
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.
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.
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.
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.
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)."
Vous pouvez poser toutes vos questions,
vos remarques et vos expériences à propos de l'entête ARP. Pour cela,
rendez-vous sur le
Forum "TCP-IP".
Le 02 mars 2009, par _SebF, Ajout dans
le chapitre 1 de la rérerence à la RFC 5227 "IPv4 Address Conflict Detection"
Le 21 Octobre 2008, par PascalLX,
correction du paragraphe 3.4 en spécifiant que ipv6 = 16 et non pas 06
Le 24 août 2004, par Eric Lalitte, remplacement
du mot Broadcast par Unicast dans le schéma du chapitre 4.2
Le 17 août 2004, par _SebF, relecture et
création des schémas.
Le 17 août 2004, par _JE, création du document.
|