Résumé

  • La RFC 903 répondait à un problème précis de démarrage à froid : une station sans disque connaissait son adresse matérielle, mais devait obtenir une adresse de protocole avant d’utiliser IP.
  • RARP plaçait cette recherche au niveau de la liaison. Un serveur répondait à partir d’une table d’associations entre adresses matérielles et adresses de protocole ; la réponse n’authentifiait ni la machine ni la fin du démarrage.
  • Le protocole ne prévoyait pas de réponse explicite « introuvable ». Sans réponse, le client devait expirer son délai sans savoir si l’association manquait, si le paquet avait été perdu ou si aucun serveur n’avait répondu.
  • La RFC 950 et BOOTP montrent pourquoi une adresse ne suffisait pas à configurer un hôte : il pouvait aussi lui falloir une passerelle, un serveur de noms, un masque de sous-réseau et un fichier de démarrage.

La première question précédait IP

Imaginons une station de travail sans disque local. Son code de démarrage peut lire l’adresse matérielle de l’interface Ethernet, mais il ne possède aucune adresse Internet enregistrée. Une requête IP ne peut pas résoudre le problème : la machine ne sait pas encore quelle adresse source utiliser.

Dans la RFC 903, publiée en juin 1984, Ross Finlayson, Timothy Mann, Jeffrey Mogul et Marvin Theimer proposent RARP. Le mémo décrit un hôte qui demande son adresse de protocole à une source externe sur un support de diffusion tel qu’Ethernet. ARP traitait le sens opposé : retrouver une adresse matérielle quand l’adresse de protocole était déjà connue. RARP partait de l’adresse matérielle pour demander l’adresse de protocole correspondante.

Ce n’était pas un service général d’identité. RARP ne demandait pas qui possédait la station ni si une personne avait le droit d’utiliser une adresse. Il donnait à un hôte non configuré un moyen de demander une association précise avant toute communication IP normale.

Un serveur local détenait la réponse

La RFC 903 séparait délibérément RARP au niveau de la liaison. Le protocole reprenait le format de paquet d’ARP, mais attribuait des codes d’opération distincts à la requête et à la réponse inverses. Pour demander sa propre adresse, l’hôte plaçait la même adresse matérielle dans les champs de l’émetteur et de la cible. Un serveur qui reconnaissait cette adresse pouvait répondre avec l’adresse de protocole de la cible.

La réponse dépendait de l’état du serveur. La RFC précise qu’un ou plusieurs serveurs RARP entretiennent une base d’associations entre adresses matérielles et adresses de protocole. C’est différent d’ARP : les hôtes accumulent dans un cache les correspondances de leurs pairs, sans distinction client-serveur. RARP introduisait donc une dépendance d’exploitation : le client pouvait poser la question, mais un opérateur local devait maintenir une table exploitable.

La réponse attestait une association, pas un justificatif. La RFC ne définit aucune authentification reliant l’adresse matérielle à une personne, à un propriétaire ou à un appareil autorisé. Elle ne prouve pas non plus que l’hôte a installé l’adresse correctement, joint une passerelle ou chargé un système d’exploitation. Ce sont des étapes ultérieures.

Le silence ne signifiait pas « introuvable »

La RFC 903 définit des requêtes et des réponses inverses, mais aucun paquet « introuvable » ou d’erreur. Les auteurs expliquent que plusieurs serveurs peuvent être libres de répondre. Au lieu de définir un refus distinct, le texte demande au client d’expirer son délai si aucune réponse n’arrive dans un intervalle raisonnable.

Ce choix gardait l’échange petit, mais laissait le client face à une observation ambiguë. Le délai expiré pouvait signifier qu’aucun serveur ne possédait l’association ; la requête ou la réponse avait aussi pu être perdue, le lien être en panne ou aucun serveur être disponible. Le silence ne permettait pas de distinguer ces conditions. Un journal de démarrage indiquant seulement « délai RARP dépassé » ne pouvait pas trancher.

Cette distinction compte lorsqu’on reconstitue une panne. L’absence de réponse prouve ce que le client a reçu — rien — mais pas qu’aucune adresse n’était attribuée. Le mémo original trace clairement cette limite, sans pour autant définir un système de diagnostic capable d’isoler chaque cause.

Une adresse ne configurait pas toute la station

La difficulté plus large du démarrage apparaît vite. La RFC 950 cite RARP comme une manière pour un hôte fraîchement démarré de découvrir son adresse Internet, puis énumère d’autres renseignements possibles : l’adresse matérielle d’une passerelle, l’adresse IP d’un serveur de noms et le masque de sous-réseau. Elle estime préférable d’obtenir plusieurs paramètres dans une seule requête plutôt que d’émettre plusieurs diffusions.

BOOTP, spécifié l’année suivante, conservait la recherche matérielle-vers-IP tout en transportant davantage d’informations de démarrage, dont un nom de fichier facultatif. Sa conception permettait aussi le démarrage à travers des passerelles. La RFC 951 oppose explicitement cette approche IP/UDP aux paquets RARP de niveau liaison et aux modifications particulières du noyau ou du pilote nécessaires pour les traiter. La RFC 1542 a ensuite précisé le relais BOOTP ; la RFC 2131 décrit DHCP comme une évolution de BOOTP ajoutant l’allocation automatique d’adresses réutilisables et des options de configuration.

Cette évolution ne prouve pas que tous les réseaux ont abandonné RARP à une date unique. Elle montre que la question avait changé : découvrir une adresse préattribuée était utile, mais démarrer un hôte au-delà d’un réseau routé exigeait un échange plus large et un chemin de relais.

Un enregistrement n’est pas la machine

La Note 72 de Heng Lu fournit un cadre analytique ultérieur, pas une preuve sur 1984 : un registre décrit une réalité sans la créer. RARP n’était pas un registre mondial, mais la distinction reste utile. La table d’un serveur coordonnait une association locale ; elle ne transformait pas l’adresse renvoyée en preuve de propriété matérielle, d’identité de l’utilisateur ou de bon fonctionnement.

L’apport historique du protocole était plus étroit et concret. Il permettait à un hôte de demander au lien déjà accessible la seule adresse nécessaire pour commencer à communiquer par IP. Sa limite faisait aussi son coût : il fallait maintenir les associations locales, le silence ne s’expliquait pas lui-même, et la réponse ne constituait pas une configuration complète.

Sources

RFC 903 — A Reverse Address Resolution Protocol ; RFC 826 — An Ethernet Address Resolution Protocol ; RFC 950 — Internet Standard Subnetting Procedure ; RFC 951 — Bootstrap Protocol ; RFC 1542 — Clarifications and Extensions for the Bootstrap Protocol ; RFC 2131 — Dynamic Host Configuration Protocol. La Note 72 est un cadre éditorial ultérieur, pas une source historique.