Résumé

  • Le RFC 1868 visait le moment où un terminal distant revenait par un deuxième serveur de communications tandis qu’un pair du LAN conservait encore l’adresse matérielle du premier serveur apprise par Proxy ARP.
  • UNARP reprenait la valeur d’opération d’une réponse ARP non sollicitée, mais mettait la longueur de l’adresse matérielle à zéro. Un récepteur compatible devait supprimer l’entrée correspondant à l’adresse IP annoncée ; un récepteur ignorant l’extension devait rejeter le format abrégé.
  • Émission, réception par un pair, acceptation syntaxique, suppression locale, nouvelle résolution et transfert réussi constituaient des événements distincts. Le protocole ne renvoyait aucun reçu pour les étapes situées après l’envoi.

Un cache correct était devenu faux avec le temps

Un utilisateur distant se connecte à un groupe de modems par le serveur CS1. Pour Host A, placé sur le même réseau local apparent, l’adresse IP de cet utilisateur semble directement accessible. Lorsque Host A émet une requête ARP, CS1 répond à la place du terminal et fournit sa propre adresse matérielle. Host A l’inscrit dans son cache et lui remet ensuite les trames destinées à l’utilisateur.

Cette dissimulation était précisément l’utilité du Proxy ARP décrit par le RFC 1027. Des machines qui ne connaissaient ni le sous-réseau caché ni une route nouvelle pouvaient continuer à communiquer. L’intermédiaire absorbait la complexité. En contrepartie, une relation de chemin était résumée dans une croyance locale très courte : pour cette adresse IP, envoyer à cette adresse matérielle.

L’utilisateur se déconnecte ensuite de CS1 et rappelle aussitôt par CS2. Son adresse IP ne change pas. La valeur conservée par Host A non plus. Elle reste bien formée, mais le monde qu’elle décrivait a pris fin. Jusqu’à son expiration, les trames continuent donc vers un serveur qui ne détient plus le chemin.

ARP distribuait des correspondances, pas un état commun

Le RFC 826 avait défini ARP pour associer une adresse de protocole à une adresse matérielle sur le réseau local. Une requête pose une question ; une réponse expose notamment la correspondance de l’émetteur, que le destinataire peut intégrer à sa propre table.

Cette table n’est pas un registre central. Chaque hôte conserve l’état dont il a besoin et le renouvelle selon ses propres mécanismes. Deux machines peuvent donc posséder au même instant des versions d’âges différents sans que le protocole organise une validation collective.

Le RFC 1122 exigea plus tard un moyen d’invalider les entrées ARP périmées. Il cita l’expiration, l’interrogation unicast, les indications de la couche liaison et les indications d’une couche supérieure après un problème de livraison. Ces mécanismes pouvaient se combiner, mais leurs témoignages n’étaient pas interchangeables. Une échéance locale ne prouve pas un déplacement ; une sonde sans réponse ne révèle pas la nouvelle attache ; un échec de livraison ne prouve pas quel serveur possède désormais le terminal.

Seize octets pour retirer une affirmation

Publié avec le statut Experimental en novembre 1995, le RFC 1868 proposa une intervention étroite. Le serveur qui perdait le terminal envoyait une réponse ARP non sollicitée avec l’opcode 2. Le type de protocole désignait IPv4, la longueur d’adresse de protocole valait quatre et la longueur d’adresse matérielle valait zéro. L’adresse de protocole source était celle du terminal parti ; la cible était 255.255.255.255. Sans champs matériels source et cible, le message ne comptait que seize octets avant l’en-tête de liaison.

Un pair prenant en charge UNARP devait supprimer de son cache l’entrée indexée par l’adresse IP source. Le serveur n’avait même pas à se souvenir s’il avait effectivement envoyé la réponse Proxy ARP initiale. Il pouvait émettre l’avis à chaque déconnexion. Un hôte quittant proprement un LAN pouvait également parler pour lui-même.

Le choix privilégiait une asymétrie pratique. Effacer une entrée encore utile imposait surtout une résolution ultérieure. Conserver une entrée devenue fausse envoyait du trafic vers le mauvais intermédiaire. Le coût d’un doute temporaire paraissait inférieur au coût d’une continuité fictive.

Mais retirer l’ancienne affirmation n’en créait aucune nouvelle. Après l’effacement, Host A devait encore poser une nouvelle question ARP, recevoir une réponse, apprendre l’adresse de CS2 puis tenter un transfert. Un cache vide n’était ni un chemin ni une livraison.

La compatibilité conservait le droit de ne pas comprendre

La longueur matérielle nulle avait aussi une fonction de transition. Le RFC prévoyait un LAN mêlant des hôtes compatibles et des hôtes ignorants d’UNARP. Une pile classique devait considérer la réponse raccourcie comme invalide plutôt que d’enregistrer une adresse matérielle composée de zéros.

Ce refus prudent rendait le silence impossible à interpréter depuis CS1. Un pair pouvait avoir reçu le paquet et supprimé son entrée. Il pouvait l’avoir reçu puis rejeté, avoir désactivé l’extension, avoir perdu la trame, ou ne rien avoir à supprimer. Aucune liste d’acquittements ne distinguait ces cas.

Le document recommandait en outre un commutateur de configuration permettant de désactiver UNARP si une implémentation existante réagissait mal au format. La publication normalisait donc une possibilité tout en préservant une décision locale. L’espoir exprimé d’une prise en charge étendue restait un espoir documentaire, non un recensement du code en service.

Une variante ultérieure réduisit le risque sans créer de consensus

Le RFC 2176 introduisit en 1997 un UNARP propre à IPv4 sur MAPOS. Il employait un code d’opération dédié et conservait de véritables champs matériels. À sa mise en service, un nœud envoyait trois annonces espacées de trente secondes. Le récepteur ne supprimait une association IP que si l’adresse matérielle reçue différait de celle déjà placée en cache.

La répétition diminuait le risque qu’une seule perte maintienne l’ancien état. La comparaison protégeait une association déjà conforme à l’émetteur. Ni l’une ni l’autre ne constituait un accusé de réception. Le même RFC exigeait séparément le vieillissement du cache et son nettoyage immédiat à la perte du lien : la correction reposait sur plusieurs signaux, pas sur une proclamation souveraine.

Le RFC 3790 classa ensuite le RFC 1868 parmi les extensions dépendantes d’IPv4 servant à supprimer des entrées ARP. Cette classification établit une place dans l’histoire normative. Elle ne mesure ni adoption ni efficacité.

Une annonce positive avait la même limite de témoin

Le RFC 5227 décrivit plus tard les deux voix contenues dans une requête ARP. Les champs de l’émetteur affirment une correspondance ; les champs de la cible interrogent le réseau. Une sonde demande si une adresse est utilisée tout en signalant une intention. Une annonce affirme que l’émetteur utilise désormais cette adresse.

UNARP parlait dans l’autre sens : ne faites plus confiance à la correspondance précédente. Une assertion positive et un ordre d’oubli restent toutefois des entrées offertes à des machines locales. Chacune vérifie le format, compare avec son état et choisit l’action. Aucun paquet isolé ne prouve que tous les pairs convergent, qu’aucun conflit ne subsiste, que les trames suivantes atteignent leur destination ou qu’une application obtient son résultat.

L’enseignement historique tient dans le nom donné au reçu. « Avis de départ émis », « trame observée ici », « entrée supprimée sur cet hôte », « nouvelle correspondance apprise » et « premier paquet transféré » sont des propositions vérifiables. « Le réseau a oublié » dépasse le témoin tant que les lieux décisifs n’ont pas été observés.

Sources et limites

Les RFC 826, 1027 et 1122 établissent les bases d’ARP, du Proxy ARP et de l’invalidation. Le RFC 1868 définit le message expérimental ; les RFC 2176, 3790 et 5227 apportent une variante ultérieure, une classification et le vocabulaire des sondes et annonces. Ces sources prouvent des formats, des règles prescrites et des attentes écrites. Elles ne prouvent pas un déploiement actuel, un comportement universel des produits, un incident nommé, une exploitation malveillante, une conformité particulière ni la livraison réussie sur un réseau réel.