Résumé

  • Dans l’exemple de la RFC 2390, A envoyait sur le DLCI 50 mais B recevait le même circuit comme DLCI 70 : chaque numéro appartenait à l’interface qui le voyait.
  • L’en-tête extérieur portait donc la bonne coordonnée d’arrivée alors que les adresses matérielles du message InARP étaient invalides ; B reconstruisait ar$sha avec l’adresse Q.922 du cadre reçu.
  • Cette valeur attestait un point d’entrée local. Elle ne prouvait ni l’identité du pair, ni son autorisation, ni la vérité de son adresse de protocole, ni le succès d’un service.

Un circuit ne possédait pas un numéro universel

La RFC 1293 avait déjà posé le problème général d’Inverse ARP : un équipement connaît un circuit virtuel et son identifiant de liaison, mais ignore l’adresse de protocole de l’équipement distant. La RFC 2390, publiée en septembre 1998, ne prétendait pas réinventer ce mécanisme. Elle disait elle-même remplacer le texte antérieur par des ajustements de forme, un schéma de paquet, un exemple détaillé en 7.2 et une section de sécurité.

Ce nouvel exemple rendait visible une difficulté que l’expression « adresse matérielle connue » masquait. Sur Frame Relay, le DLCI était normalement de portée locale. La RFC 2427 le confirmait : chaque circuit était identifié à chaque interface, et la valeur n’avait le plus souvent de sens qu’à cette interface.

Ainsi, le circuit entre A et B apparaissait comme DLCI 50 à A et DLCI 70 à B. A plaçait 50 dans l’en-tête de départ. Le réseau transformait cet en-tête, et B recevait 70. Le circuit n’avait pas changé ; le référentiel, oui. Un identifiant local n’était pas une propriété globale du pair.

Le corps du message ne pouvait pas prédire l’arrivée

Le format hérité d’ARP comporte une adresse matérielle source, une adresse de protocole source, une adresse matérielle cible et une adresse de protocole cible. Sur Ethernet, l’émetteur connaît généralement sa propre adresse matérielle. Sur Frame Relay, il ne connaît pas le DLCI sous lequel la trame sera présentée à l’interface distante.

Dans l’exemple, A émet une requête InARP vers son DLCI 50. Son champ source matériel est inconnu. Le champ cible contient la forme Q.922 de la coordonnée qu’A connaît, 0x0C21. Or B ne peut pas utiliser 50 pour désigner l’arrivée : son interface voit le DLCI 70, codé 0x1061 lorsque les bits C/R, FECN, BECN et DE sont mis à zéro comme l’exige le texte.

La RFC 2390 formule alors le paradoxe sans l’adoucir : quand le message atteint sa destination, toutes les adresses matérielles qu’il contient sont invalides, tandis que l’adresse de l’en-tête de trame est correcte. Le réseau avait rendu obsolète le contenu intérieur en accomplissant correctement son travail extérieur.

Une réparation délibérément transversale

B copie donc l’adresse Q.922 observée dans l’en-tête vers ar$sha. La source inconnue devient 0x1061, c’est-à-dire la coordonnée locale par laquelle B vient réellement de recevoir A. Dans le sens retour, B envoie lui aussi une source matérielle inconnue ; à l’arrivée, A extrait son DLCI local 50 de l’en-tête et insère 0x0C21 dans le champ source.

Les auteurs reconnaissent que l’opération contrarie la pureté des couches. Mais la donnée valide se trouve précisément dans la couche qui a observé l’arrivée. Refuser de la faire remonter préserverait un dessin abstrait au prix d’un paquet inutilisable.

La règle restait étroite. L’interface n’intervenait que sur les paquets entrants, car seul le récepteur connaissait son espace d’adressage local. Elle ne réparait pas tout. L’adresse matérielle cible restait invalide dans la requête comme dans la réponse ; InARP n’en dépendait pas, et une implémentation pouvait la remplir de zéros ou l’ignorer.

Cette asymétrie est essentielle. On reconstruit ce qui peut être déduit d’une observation directe. On ne fabrique pas une signification pour chaque case simplement parce que le format prévoit une case.

La provenance n’est pas l’identité

Après réécriture, le champ source semble propre et complet. Pourtant, son statut épistémique est limité. Il dit : cette trame est arrivée sur cette interface avec cette adresse Q.922 locale. Il ne dit pas : l’émetteur est authentifié sous une identité globale.

La nouvelle section de sécurité de la RFC 2390 le rappelle. La famille ARP ne comporte pas d’authentification, l’usurpation d’hôte est un risque connu et InARP n’ajoute aucun mécanisme de protection. La reconstruction corrige une coordonnée de transport ; elle ne signe ni le paquet ni l’adresse de protocole annoncée par le pair.

Il faut donc conserver plusieurs preuves séparées. L’en-tête reçu établit le point d’arrivée local. La réponse InARP fournit une déclaration d’adresse de protocole. La politique locale décide si cette association entre dans un cache. Le temps et les invalidations déterminent sa durée de vie. Les paquets ultérieurs fournissent des indices de joignabilité. Une application fournit, éventuellement, le résultat final. Aucun de ces actes ne peut parler à la place des autres.

Un registre de nombres ne transforme pas leur portée

Le registre IANA des paramètres ARP conserve aujourd’hui le type matériel 15 pour Frame Relay et les codes 8 et 9 pour la requête et la réponse InARP. Ce travail évite des collisions de syntaxe. Il ne rend pas le DLCI global, ne prouve pas qu’un équipement implémente le protocole et n’atteste aucun échange particulier.

La répartition des responsabilités est nette. La spécification définit la transformation. L’IANA maintient l’unicité des codes. Le réseau expose la coordonnée locale d’arrivée. L’interface effectue la projection dans le champ source. Le pair choisit de répondre et annonce son adresse de protocole. Les systèmes locaux décident ce qu’ils en font.

Confondre ces rôles produirait deux erreurs opposées. Conserver aveuglément l’adresse intérieure reviendrait à prendre la déclaration de l’émetteur pour une réalité locale qu’il ne pouvait connaître. Élever l’adresse reconstruite au rang d’identité reviendrait à transformer une observation valide mais limitée en autorité générale.

Ce que le dessin de 1998 a clarifié

Le schéma A–B–C de la RFC séparait enfin le circuit, la vue d’A, la vue de B et le champ que B devait livrer à son moteur InARP. Les quatre enregistrements étaient reliés, mais aucun n’était le substitut absolu des autres.

Cette discipline dépasse Frame Relay. Un système distribué rencontre souvent des identifiants qui n’existent que dans le domaine de l’observateur : ports, labels, handles, numéros de session ou clés de cache. La bonne réponse n’est ni de les déclarer universels, ni de rejeter toute traversée de couche. Il faut nommer le domaine, noter la provenance, effectuer seulement la conversion justifiée et demander d’autres preuves pour l’identité, l’autorité et le résultat.

La RFC 2390 montrait donc une Internet architecture pragmatique. Le minimum commun restait le format et la règle de reconstruction. La décision future demeurait locale. Et la réalité opérationnelle venait de la trame effectivement reçue, non d’un champ qui avait l’apparence d’un fait mais appartenait déjà au mauvais espace de noms.

Sources