Le RARP : le protocole reverse ARP

Que se passe-t-il lorsque que l’on a un or­di­na­teur qui ne connaît pas sa propre adresse IP, parce qu’il n’a par exemple pas de mémoire ? Voilà un cas où le Reverse Address Re­so­lu­tion Protocol (RARP) peut servir. Le RARP est le pendant de l’ARP, le protocole de ré­so­lu­tion d’adresse.

Le reverse ARP a vieilli : de nouveaux pro­to­coles comme le protocole BOOTP ou le DHCP (Dynamic Host Con­fi­gu­ra­tion Protocol) l’ont remplacé. Pour autant, il est toujours utile de connaître les vieilles tech­niques, d’autant plus que, d’une part, il subsiste des ap­pli­ca­tions qui utilisent le RARP, et d’autre part, les vieilles tech­niques per­met­tent de mieux com­prendre les tech­no­lo­gies qui ont été bâties dessus.

Le RARP est d’abord un protocole qui a été publié en 1984 et qui a été intégré à la pile des pro­to­coles TCP/IP. Le RARP se trouve au niveau de l’accès au réseau (le niveau le plus bas et le plus élé­men­taire de la pile), et sert donc tech­ni­que­ment aux trans­mis­sions entre deux points d’un réseau. Chacun des par­ti­ci­pants à un réseau dispose (ap­proxi­ma­ti­ve­ment) de deux adresses : une adresse logique, l’adresse IP, et une adresse physique, l’adresse MAC. Alors que l’adresse IP est dé­ter­mi­née côté logiciel, l’adresse MAC est associée au matériel. Le fabricant de votre carte réseau vous a donc attribué une adresse « media access control ».

Il peut arriver en pratique qu’on ne connaisse pas sa propre adresse IP, par exemple lorsque l’appareil utilisé n’a pas de mémoire où elle peut être en­re­gis­trée. C’est dans ce cas qu’in­ter­vient le reverse ARP. Il peut, à partir d’une adresse MAC connue, dé­ter­mi­ner l’adresse IP cor­res­pon­dante. Exac­te­ment l’inverse, donc, du protocole ARP, où l’adresse IP est connue et où l’ARP détermine l’adresse du matériel.

Les dif­fé­rents champs con­tien­nent les in­for­ma­tions suivantes :

• Espace pour l’adresse du matériel : ces 2 octets indiquent le type d’adresse ma­té­rielle.
• Espace pour l’adresse du protocole : ces 2 octets indiquent le type de protocole réseau.
• Longueur de l’adresse du matériel : ces 8 bits indiquent la longueur n de l’adresse du matériel.
• Longueur de l’adresse du protocole : ce champ détermine la longueur m de l’adresse réseau.
• Code opération : ce champ, d’une longueur de 2 octets, indique le type d’opération. Une requête RARP a la valeur 3, la réponse cor­res­pon­dante la valeur 4.
• Adresse du matériel source : em­pla­ce­ment de l’adresse MAC de l’émetteur. La longueur de ce champ est n et s’établit à partir de l’in­di­ca­tion de longueur d’adresse ma­té­rielle. Dans un réseau Ethernet typique cette longueur est de 6 octets.
• Adresse du protocole source : ce champ devrait théo­ri­que­ment contenir l’adresse IP de l’émetteur, mais comme dans une requête elle n’est pas connue, le champ reste non défini. Dans la réponse par contre, c’est l’adresse IP du serveur qui y figure. Ce champ est d’une longueur m, en fonction de la longueur de l’adresse du protocole. Le plus souvent, ce champ a toutefois la longueur d’une adresse IPv4, soit 4 octets.
• Adresse du matériel cible : ce champ contient l’adresse MAC de la cible. Étant donné que pour une requête RARP il n’existe pas de cible spé­ci­fique, ce champ contient lui aussi l’adresse de l’émetteur. La réponse contient elle aussi l’adresse du client demandeur. Ce champ est lui aussi d’une longueur n, soit 6 octets dans le cas d’un réseau Ethernet
• Adresse du protocole cible : le dernier champ reste non défini dans le cadre d’une requête, et contient dans la réponse du serveur l’in­for­ma­tion re­cher­chée : l’adresse IP du par­ti­ci­pant au réseau. Ce champ est également d’une longueur m, soit le plus souvent 4 octets.

Il existe toutefois des dif­fé­rences im­por­tantes entre les deux pro­to­coles ARP et RARP : la première est na­tu­rel­le­ment celle des in­for­ma­tions contenues. Alors qu’avec une requête RARP on connaît sa propre adresse MAC et on demande l’adresse IP cor­res­pon­dante, c’est exac­te­ment l’inverse pour l’ARP : on connaît l’adresse IP et il s’agit d’établir l’adresse MAC. Mais les deux pro­to­coles se dif­fé­ren­cient également du point de vue du contenu de leurs champs opé­ra­toires : l’ARP utilise ici les deux valeurs 1 (pour une requête) et 2 (pour une réponse). Avec le RARP, par contre, on a les valeurs 3 et 4. Ainsi, un serveur peut re­con­naître dès le code opé­ra­toire s’il s’agit d’ARP ou de RARP.

Le Reverse Address Re­so­lu­tion Protocol présente certains in­con­vé­nients qui ont conduit à son rem­pla­ce­ment. Pour une bonne mise en œuvre du protocole, le serveur RARP doit par exemple se trouver dans le même réseau physique. L’or­di­na­teur émet la requête RARP au niveau le plus bas des couches réseau. Cela rend par con­sé­quent im­pos­sible la trans­mis­sion du paquet par un routeur. De plus, le RARP ne gère pas le découpage en sous-réseaux du fait de l’im­pos­si­bi­lité de trans­mettre des masques de sous-réseau. Si on est face à un réseau découpé en plusieurs sous-réseaux, il faut qu’un serveur RARP soit dis­po­nible dans chacun des sous-réseaux.

Par ailleurs la requête permet au par­ti­ci­pant au réseau de connaître uni­que­ment son adresse IP. Ainsi que déjà mentionné, il n’y a pas de masque de sous-réseau, et le protocole RARP ne donne pas non plus d’in­for­ma­tions sur la pas­se­relle. Cela empêche par con­sé­quent de con­fi­gu­rer l’or­di­na­teur pour un réseau moderne. Ce sont ces in­con­vé­nients qui ont conduit au dé­ve­lop­pe­ment des pro­to­coles BOOTP et DHCP.