Résumé

  • Le RFC 1293, protocole de la filière de normalisation IAB publié en janvier 1992, ajoute à ARP un échange permettant de demander l’adresse de protocole associée à une adresse matérielle déjà connue. Son cas directeur est un DLCI Frame Relay associé à un PVC établi dont l’adresse de protocole distante manque.
  • InARP n’émet pas en diffusion : l’adresse matérielle du destinataire est connue. Le répondant peut fournir une réponse appropriée ou ignorer la demande s’il ne peut ou ne veut pas répondre ; une information apprise peut compléter un cache local puis vieillir ou être invalidée.

Le problème décrit par le RFC 1293 paraît presque paradoxal si l’on réduit une connexion à une seule propriété. Le réseau peut signaler une nouvelle liaison virtuelle. La station peut connaître le DLCI qui identifie cette liaison à travers le WAN. Pourtant, elle ne peut pas adresser le poste de l’autre côté au niveau du protocole, car l’annonce ne contient pas cette adresse. Le circuit n’est pas absent ; l’information indispensable à l’opération suivante l’est.

Cette différence protège contre une conclusion trop rapide. Un DLCI est un fait de liaison précis dans son propre contexte. Il n’est pas l’adresse de protocole du pair, son consentement à parler, la confirmation d’une configuration présente, ni une promesse de trafic ultérieur. InARP apporte une procédure pour demander l’information manquante, non une autorité permettant de la déduire.

L’annonce d’un chemin ne nommait pas l’extrémité

Dans l’exemple Frame Relay, les PVC et, à terme, les SVC sont identifiés par un Data Link Connection Identifier. Le RFC le présente comme l’équivalent Frame Relay d’une adresse matérielle : il définit une connexion virtuelle unique dans le réseau étendu. Mais lors de l’échange de signalisation qui annonce un nouveau circuit et son DLCI, l’adresse de protocole correspondante n’est pas annoncée.

Sans nouvelle configuration ni mécanisme de découverte de cette adresse, la station qui reçoit l’annonce ne peut adresser l’autre côté ; le RFC qualifie alors le circuit d’inutilisable pour cette tâche. Le texte ne conclut ni à une panne de réseau ni à une identité distante invalide. Il isole une lacune : une poignée de couche liaison existe, mais elle ne suffit pas à former l’adresse de couche protocole demandée par le poste local.

Cette séquence impose de distinguer l’annonce, la question et la réponse. Dire qu’un circuit a été signalé ne dit pas qu’une demande InARP a été envoyée. Dire qu’une demande a été envoyée ne dit pas qu’elle a reçu une réponse. Dire qu’une réponse a rempli une entrée locale ne dit pas qu’un paquet de données a été livré. Le RFC 1293 rend cette chaîne visible au lieu de faire du premier identifiant une preuve de son dernier résultat.

L’inversion concernait la question, pas une symétrie générale

Inverse Address Resolution Protocol commence avec une adresse matérielle et demande l’adresse de protocole qui lui correspond. Le RFC étend le format ARP : le code d’opération de requête InARP est 8, celui de réponse 9. Ce choix ne fait pas de toute procédure portant le mot « inverse » une solution équivalente.

Reverse ARP fut envisagé puis écarté. Sa réponse fournit l’adresse de protocole du demandeur, alors que le besoin était l’adresse de la station qui reçoit la demande, à l’autre extrémité du circuit. La différence ne porte pas sur un détail de format : elle porte sur l’objet de l’information retournée. Une procédure qui répond correctement à « qui suis-je ? » ne répond pas nécessairement à « qui est le pair joignable via cet identifiant connu ? ».

Les mécanismes limités à IP furent également écartés parce que l’objectif était la résolution d’adresses de plusieurs protocoles. InARP n’était donc pas un registre universel de propriétaires IP ni une affirmation de routage. Il organisait une demande de correspondance entre une adresse matérielle de destination déjà connue et une adresse de protocole que le demandeur n’avait pas encore.

Une demande directe réduisait la portée, non l’incertitude

InARP opère comme ARP à une différence essentielle : il ne diffuse pas la requête. Comme l’adresse matérielle de destination est connue, le demandeur renseigne ses propres adresses matérielle et de protocole, place l’adresse matérielle cible connue, met à zéro le champ de l’adresse de protocole cible, encapsule le paquet pour le réseau concerné et l’envoie directement à la cible.

Le zéro n’est pas une valeur inventée pour le pair ; il marque exactement ce qui est recherché. La demande contient assez de savoir pour atteindre un destinataire déterminé et assez de non-savoir pour ne pas prétendre connaître son adresse de protocole. L’envoi direct peut être plus efficace qu’une simulation de diffusion par plusieurs copies et plus souple qu’une configuration statique, selon le RFC. Il ne contraint ni support InARP, ni adresse appropriée, ni réponse, ni validité durable.

Une demande dirigée est ainsi une opération plus étroite qu’une diffusion, pas une attestation plus forte. Son destinataire est sélectionné à la couche où le DLCI a un sens. La réponse demeure une action du poste distant sous sa configuration. Confondre destination de la question et garantie de réponse transfère au DLCI un pouvoir que le document ne lui donne pas.

Répondre ou ignorer restait au répondant

Un poste recevant une requête InARP peut enregistrer dans son cache ARP le couple adresse de protocole/adresse matérielle du demandeur. Il peut former une réponse en reprenant comme cibles les adresses source de la demande. Mais si le poste est incapable ou peu disposé à répondre, le RFC prescrit qu’il ignore la requête.

Le silence n’est donc pas une réponse positive incomplète. Une trace qui ne contient qu’une requête signale l’émission de celle-ci, non la raison d’une absence de réponse. Le RFC ne permet pas d’attribuer cette absence à une panne précise, à une règle de sécurité, à une incompatibilité, à une politique ou à un état distant. Toutes ces hypothèses réclament des observations que le protocole de 1992 ne fournit pas.

Lorsqu’une réponse arrive, le demandeur peut compléter son entrée ARP et utiliser l’information d’adresse fournie. C’est une affirmation locale utile mais limitée. Elle décrit la réception d’une réponse et l’inscription possible d’un mappage dans une table, non une identité perpétuelle, une certification indépendante, une autorisation ou un résultat applicatif. Le RFC avertit expressément que l’information apprise via InARP peut vieillir ou être invalidée.

Le choix multi-adresse dépendait du demandeur

Pour un hôte possédant plusieurs adresses de protocole sur une seule interface, la réponse n’est pas simplement « l’une de mes adresses ». Le répondant doit d’abord regarder l’adresse de protocole du demandeur puis choisir une adresse correspondant au réseau de ce demandeur. Dans l’exemple IP, s’il n’a pas d’adresse de l’interface dans le sous-réseau demandé, il ne doit pas répondre.

Le mappage est donc relationnel. Une même station peut posséder plusieurs adresses et n’en avoir aucune qui soit appropriée à la demande reçue. Un hôte multi-adressé peut envoyer une requête InARP pour chacune des adresses de son interface ; le côté distant peut répondre à certaines ou à aucune selon sa configuration. Une liste d’adresses du pair ne décide pas, à elle seule, de l’adresse à écrire dans une entrée locale donnée.

Cette règle interdit un autre raccourci courant : « le pair a une adresse » n’est pas encore « cette adresse convient à ce demandeur sur ce circuit ». La réponse a besoin du contexte de la question. Elle ne transforme pas une propriété générale attribuée à l’hôte distant en vérité utilisable dans chaque relation réseau.

Cache, vieillissement et invalidation préservent le temps

Une entrée remplie par une réponse InARP n’est pas un acte de conservation historique. Le RFC permet au demandeur de l’utiliser, puis note qu’une information apprise peut être vieillie ou invalidée dans certaines circonstances. Le cache est donc une décision locale de retenir une observation de résolution pendant une période, non une proclamation intemporelle sur la topologie ou l’identité distante.

Pour une opération robuste, il faut enregistrer le DLCI annoncé ou configuré, la demande datée, les adresses impliquées, la réponse ou son absence, l’entrée créée, sa durée et son événement d’invalidation. Un trafic de données ultérieur demande encore un enregistrement séparé : destination, route, droits, moment, résultat et échec éventuel. Le RFC spécifie la procédure de découverte et l’usage possible de son produit local ; il ne remplit pas le journal du trafic qui suivrait.

La séparation est particulièrement importante en sécurité. La section Security Considerations du RFC 1293 dit que les questions de sécurité ne sont pas traitées. Une réponse de résolution ne devient donc ni authentification, ni intégrité, ni autorisation, ni garantie contre une attaque par le seul fait qu’elle a permis à une station de compléter son cache.

Source et limites de l’évidence

Cet article utilise RFC 1293 — Inverse Address Resolution Protocol. La source soutient le statut de normalisation et la date de janvier 1992, la motivation DLCI/PVC, l’adresse de protocole distante manquante, le rejet de RARP et des mécanismes seulement IP, le format et les codes InARP, la requête directe non diffusée, le choix de répondre ou d’ignorer, le cache, le vieillissement ou l’invalidation, la sélection multi-adresse et l’absence de traitement des questions de sécurité.

Elle ne prouve pas l’existence actuelle d’un circuit Frame Relay, la configuration ou l’accessibilité d’un pair, une réponse particulière, l’exactitude ou l’autorisation d’un mappage, la persistance d’un cache, une route IP, la livraison d’un paquet, un service commercial ou un résultat pour un utilisateur. Lire un DLCI connu comme un fait de coordination borné plutôt que comme un verdict sur un voisin utilisable est une analyse éditoriale du mécanisme, non une observation de déploiement.