Résumé

  • En 1982, RFC 826 ne chercha pas à dresser un registre universel. Il donna à une machine le moyen de demander, sur le réseau local choisi par le routage, quelle adresse matérielle pouvait exécuter le prochain envoi.
  • La requête révélait déjà l’émetteur. Le destinataire pouvait donc apprendre avant de répondre, puis chaque hôte conservait une correspondance provisoire afin de ne pas redemander avant chaque trame.
  • Proxy ARP, DHCP et la détection des conflits montrèrent la limite de cette preuve : une réponse peut être une promesse de transfert, et une adresse attribuée peut rester inutilisable si le lien local la contredit.

Ce qui manquait après la décision de routage

Le routage répond à une question de chemin : quel est le prochain destinataire IP et par quelle interface faut-il sortir ? Ethernet en pose aussitôt une autre : quelle adresse de 48 bits inscrire dans la trame ? Ces deux noms ne sont ni de même taille ni de même nature. L’un ne contient pas nécessairement l’autre.

RFC 826, publié en novembre 1982 par David C. Plummer, se place exactement entre ces deux décisions. Son module de résolution reçoit un type de protocole et une adresse cible, consulte une table locale et rend une adresse matérielle. Si l’entrée manque, il émet une requête sur le morceau d’Ethernet que le routage avait déjà sélectionné.

Le format garde les espaces séparés : type matériel, type de protocole, longueur des deux adresses, opération, adresses de l’émetteur et de la cible dans les deux mondes. IPv4 sur Ethernet devint le cas quotidien, mais la forme prévoyait d’autres protocoles et d’autres supports. ARP ne déclarait pas qu’une adresse IP « contenait » une adresse Ethernet ; il définissait un échange capable d’observer leur correspondance.

La distinction évite une erreur durable. Quand le paquet IP vise un réseau éloigné, la destination Ethernet est normalement le routeur du prochain saut, non le serveur final. Le paquet et la trame nomment alors deux machines différentes parce qu’ils accomplissent deux étapes différentes.

Une question entendue par tous les voisins

En cas d’échec du cache, la requête est diffusée. Elle indique qui parle, quelle adresse de protocole il possède et quelle cible il cherche. Tous les hôtes du domaine de diffusion peuvent l’entendre ; celui qui reconnaît son adresse répond directement à l’émetteur.

Cette asymétrie est sobre. La découverte est publique parce que l’interrogateur ne connaît pas encore le destinataire matériel. La réponse n’a pas besoin de l’être. RFC 826 rejetait aussi l’idée d’une annonce périodique de toutes les correspondances : elle aurait rempli chaque table d’informations inutiles et consommé le câble même lorsque personne ne voulait communiquer.

La première version envisageait que le paquet IP en attente soit abandonné, une couche supérieure devant le retransmettre. RFC 1122, en 1989, recommanda de garder au moins le paquet le plus récent pour une destination non résolue. Cette file améliore l’exécution ; elle ne renforce pas l’identité du répondant.

Le silence ne doit pas provoquer une tempête. RFC 1122 exige un frein aux requêtes répétées et recommande au plus une requête par seconde et par destination. Répéter une question perdue peut être utile ; la répéter sans borne ne transforme pas l’absence de réponse en certitude.

Apprendre avant de lire l’opération

L’algorithme de réception de 1982 procède dans un ordre remarquable. Une machine vérifie d’abord les types matériel et protocolaire. Si sa table connaît déjà l’adresse de protocole de l’émetteur, elle remplace l’adresse matérielle par celle du paquet reçu. Si elle est la cible et ne possède pas encore l’entrée, elle l’ajoute. Elle regarde seulement ensuite si l’opération est une requête exigeant une réponse.

La requête porte donc deux actes. Elle demande : « Qui peut recevoir pour cette adresse ? » Elle affirme en même temps : « Voici comment me répondre. » Le destinataire apprend le chemin de retour avant de former sa réponse. Un observateur du câble peut même établir des correspondances sans parler IP ou les autres protocoles annoncés.

Cette efficacité repose sur une preuve modeste. Une observation récente peut remplacer une ancienne valeur, mais le paquet n’authentifie pas celui qui parle. Le cache est une hypothèse opérationnelle, pas un cadastre. La fraîcheur améliore la récupération après déplacement ou reconfiguration ; elle ouvre aussi la porte aux données erronées et aux annonces malveillantes.

RFC 826 évoquait les délais d’expiration sans les normaliser. RFC 1122 rendit ensuite obligatoire un mécanisme d’élimination des entrées périmées. Expiration temporelle, interrogation unicast, conseil de la couche de liaison ou échec remonté par une couche supérieure : les méthodes diffèrent, mais leur principe commun est qu’une correspondance ne peut commander indéfiniment les trames futures.

Quand la passerelle répondait au nom d’un autre

En octobre 1987, RFC 1027 documenta Proxy ARP, alors largement utilisé pour introduire des sous-réseaux sans modifier de nombreux systèmes d’exploitation. Si A demandait l’adresse matérielle de B alors que B se trouvait derrière une passerelle, celle-ci pouvait répondre avec sa propre adresse matérielle.

A mettait cette réponse en cache et envoyait vers la passerelle une trame contenant toujours un paquet IP destiné à B. La passerelle transférait le paquet grâce à son routage. Du côté de B, le même mécanisme pouvait masquer le chemin de retour. Aux extrémités, le sous-réseau disparaissait.

Le gain était réel : la migration ne dépendait pas d’une mise à jour simultanée de plus d’une demi-douzaine de familles de machines. Mais la sémantique de la réponse changeait de lumière. Elle ne signifiait pas « je suis B ». Elle signifiait « envoie-moi les trames destinées à B, je promets de les acheminer ».

La promesse vaut autant que la table de routage et la configuration du proxy. Plusieurs passerelles peuvent répondre, et la première arrivée peut devenir l’entrée conservée. ARP seul ne prouve ni la proximité physique de B, ni l’autorité de la passerelle, ni la livraison finale.

Le bail que le câble pouvait refuser

Un service d’attribution centralisé ne supprima pas ce contrôle local. RFC 2131, spécification de DHCP publiée en 1997, recommande au serveur de vérifier une adresse avant de la réattribuer et au client de faire un dernier test après DHCPACK.

Le client peut envoyer une requête ARP avec son adresse matérielle, l’adresse proposée comme cible et zéro comme adresse IP d’émetteur. Il demande avant d’affirmer. Ce zéro évite que les voisins installent dans leurs caches une adresse que le client devra peut-être refuser.

Si quelqu’un utilise déjà l’adresse, le client doit envoyer DHCPDECLINE et recommencer. Après succès, une annonce aide à effacer les anciennes correspondances. Le bail reste une décision valide sur le registre du serveur ; il ne garantit pas que le domaine de diffusion présent est exempt d’un doublon, d’un reste de configuration ou d’un imposteur.

De la résolution ponctuelle à la surveillance du conflit

RFC 3927, consacré aux adresses IPv4 locales en 2005, transforma le contrôle en procédure temporisée. L’hôte attend une durée aléatoire, envoie plusieurs sondes dont l’adresse IP source vaut zéro, puis annonce l’adresse retenue. Des compteurs et une limitation de débit empêchent une machine pathologique qui répond à tout de déclencher une boucle de revendications.

Le contrôle continue après l’acquisition. Deux segments séparés peuvent choisir la même adresse, puis être reliés. Un test effectué au démarrage ne protège pas contre cette réunion future. L’hôte doit donc surveiller les annonces contradictoires pendant toute l’utilisation.

RFC 5227, en 2008, généralisa la détection de conflit IPv4. Sa sonde pose une question et glisse une intention : « cette adresse est-elle utilisée ? » et « j’espère l’utiliser ». L’annonce dit plus fermement : « je l’utilise maintenant ».

Lors d’un conflit, une machine ordinaire peut abandonner immédiatement ou défendre une fois son adresse. Une seconde contradiction dans DEFEND_INTERVAL l’oblige à cesser, afin que deux hôtes ne s’enferment pas dans une bataille de diffusions. Certains équipements critiques peuvent être configurés pour ne jamais céder, mais cette exception réclame journalisation et limitation ; elle n’authentifie toujours pas leur droit.

Le contrôle réduit les collisions accidentelles, sans transformer ARP en sécurité. Un adversaire peut simuler un conflit et expulser un hôte. Une sonde sans réponse peut avoir manqué une machine endormie ou isolée. Le lien fournit un indice assez fort pour modifier l’exécution, pas un jugement universel.

Ce que le registre des nombres ARP ne décidait pas

Les champs d’ARP contiennent leurs propres nombres coordonnés. RFC 5494, en 2009, donna à l’IANA des règles d’attribution pour les types matériels et les codes d’opération, avec des valeurs réservées à l’expérimentation.

Cette coordination permet à deux implémentations de lire les mêmes bits de la même façon. Elle ne donne pas à l’IANA le pouvoir de déterminer quelle machine emploie une adresse IPv4 sur un VLAN donné. Administrer le vocabulaire d’un protocole n’est pas gouverner toutes les affirmations formulées avec ce vocabulaire.

ARP laisse ainsi trois niveaux distincts. La spécification commune rend la conversation possible. Le lien local produit une observation. Le cache d’un hôte transforme cette observation en trame et décide quand l’oublier. La confusion commence lorsqu’un indice d’un niveau devient le mandat d’un autre.

Une mémoire locale faite pour oublier

La force historique d’ARP tient à sa faible ambition. Aucun service universel ne devait connaître à l’avance chaque machine. Chaque hôte ne diffusait pas tout ce qu’il savait. Une question limitée et une réponse mémorisée suffisaient pour avancer.

Mais cette économie impose une discipline. La valeur la plus récente peut être fausse. Un proxy peut dissimuler une dépendance. Une entrée statique peut survivre au dispositif qu’elle désignait. Le cache n’est sûr que s’il reste borné par le lien, le temps et la possibilité d’une preuve contraire.

ARP n’a pas fait du câble une autorité. Il en a fait un témoin. L’hôte garde la décision de croire, d’émettre, de sonder encore, de défendre ou d’abandonner—et supporte la conséquence s’il transforme un témoignage local en identité permanente.

Sources et limites de preuve

RFC 826 décrit le format, la diffusion à la demande, l’apprentissage avant l’opcode et la substitution des entrées. RFC 1027 documente la réponse déléguée de Proxy ARP. RFC 1122 impose l’invalidation et la maîtrise du débit.

RFC 2131 sépare le bail DHCP du test local. RFC 3927 fixe les sondes et annonces des adresses locales ; RFC 5227 généralise le conflit et la défense bornée. RFC 5494 coordonne les codes du protocole. Ces textes prouvent des conceptions et des obligations normatives, non leur déploiement universel. Une capture ARP ne prouve à elle seule ni identité authentifiée, ni propriété globale, ni intention.