Résumé

  • La RFC 1433 ajoutait une adresse d’assistance ARP à une route afin de résoudre un prochain saut appartenant à un autre réseau IP présent sur la même infrastructure de liaison.
  • Cette assistance devait être résolue localement, sans récursion, puis les requêtes restaient soumises à la route, à l’interface et aux filtres limitant boucles et inondations.
  • Une réponse d’adresse ne certifiait pas le trajet : des filtres de liaison non transitifs ou asymétriques pouvaient rendre un prochain saut connu mais inutilisable.

Le voisin que l’on ne savait pas adresser

La RFC 1433 part d’une architecture qui contrarie l’intuition du câble partagé. Plusieurs réseaux IP pouvaient être administrés sur un même réseau de niveau liaison, par exemple un service SMDS. Un routeur doté d’une adresse dans deux de ces réseaux voyait qu’ils empruntaient la même infrastructure. Il pouvait donc annoncer un prochain saut direct et éviter que chaque paquet passe par lui.

Le destinataire de l’annonce ne possédait pourtant qu’une moitié de l’instruction. Sa table de routage indiquait l’adresse IP à viser et l’interface à employer, mais son mécanisme local de résolution appartenait à son propre réseau IP. Il ignorait peut-être l’adresse de requête du réseau étranger, ou même la méthode utilisée pour associer IP et adresse de liaison.

Ainsi, un chemin pouvait être préférable dans le calcul de routage et inexécutable au moment de fabriquer une trame. Le routage choisissait un prochain saut. La résolution devait encore produire l’adresse comprise par le service sous-jacent. La RFC ne confondait pas les deux opérations sous le mot « joignable ».

Directed ARP répondait à cette lacune sans inventer un nouveau paquet. La procédure conservait le format ARP ordinaire et ajoutait à la route l’adresse d’un assistant auquel transmettre la question concernant le prochain saut étranger.

Une dépendance écrite dans la route

Chaque entrée de routage pouvait porter une ARP Helper Address. La valeur nulle signifiait que le nœud savait déjà résoudre localement le prochain saut, ou directement la destination lorsqu’aucun routeur intermédiaire n’était requis. Une valeur non nulle désignait le routeur ayant annoncé que cette adresse étrangère partageait la même liaison.

Cette valeur conservait la provenance opérationnelle. L’annonceur ne se bornait pas à livrer une adresse attractive ; il devenait le point d’assistance nécessaire pour rendre l’annonce utilisable. Une route apprise par un protocole à vecteur de distance associait normalement l’annonceur à ce rôle. Dans le cas d’un Redirect ICMP, l’émetteur du Redirect devenait l’assistant, sauf si le destinataire savait déjà résoudre le nouveau prochain saut.

La séquence était volontairement finie. Le nœud consultait d’abord sa table de résolution. En l’absence de résultat, il utilisait sa procédure locale si aucun assistant n’était indiqué. Sinon, il résolvait localement l’adresse de l’assistant, lui adressait une requête ARP portant sur la cible étrangère et attendait une réponse.

L’assistant ne pouvait pas être découvert par une nouvelle opération Directed ARP. Cette interdiction de récursion est essentielle. Sans elle, chaque dépendance pourrait en appeler une autre, dissimuler une boucle et repousser indéfiniment la responsabilité de l’échec. L’assistant devait être assez proche pour être adressé par les moyens déjà disponibles.

Relayer, représenter, répondre

Un hôte ne relayait pas une requête qui ne le concernait pas. Un routeur pouvait la diriger seulement si la cible figurait comme prochain saut admissible ou destination locale, et si la route correspondante utilisait la même interface physique que celle d’arrivée. Une connaissance obtenue sur une autre interface ne suffisait pas à renvoyer la requête dans le réseau reçu.

Deux branches étaient alors possibles. Si le réseau de la cible utilisait ARP, le routeur transmettait la requête à l’adresse de requête appropriée et la cible pouvait répondre. Si ce réseau employait une autre méthode de résolution, le routeur obtenait lui-même l’association et répondait au nom de la cible par « published ARP ».

Ces réponses n’avaient pas la même source d’autorité. Dans le premier cas, le paquet avait traversé l’assistant et atteint un répondant. Dans le second, l’assistant traduisait sa propre table ou procédure dans le langage ARP. Un observateur devait donc conserver qui avait répondu, par quelle méthode et à quel moment, plutôt que de réduire l’événement à une ligne de cache.

Même une réponse correctement formée ne prouvait ni l’identité institutionnelle de la cible, ni l’autorisation de la route, ni l’acceptation de trafic ultérieur. Elle donnait une association d’adresses dans un contexte déterminé.

Contenir la question avant qu’elle ne tourne en boucle

Relayer une question de découverte peut multiplier cette question. La RFC 1433 exigeait des filtres pour limiter les inondations provoquées par des nœuds fautifs et interrompre les boucles issues d’un routage instable ou d’une mauvaise configuration. Elle suggérait des familles de garde-fous sans figer une politique unique.

Le routeur pouvait limiter, par intervalle, les requêtes possédant le même couple source-cible. Il pouvait refuser de renvoyer une requête vers l’adresse de liaison qui avait déjà porté la trame reçue. Il pouvait aussi exploiter l’indicateur signalant une réception en diffusion et ne jamais relayer ces requêtes.

Le premier contrôle gouvernait la répétition, le second la réflexion immédiate, le troisième l’expansion d’une diffusion. Aucun ne validait le contenu de la réponse. Ils protégeaient la ressource collective consommée par une demande qui n’avait pas encore obtenu de résultat.

Les paramètres N et T évoqués par la RFC restaient administrés. Une requête légitime pouvait être répétée après une perte. Une limite trop basse fabriquait un silence durable ; une limite trop haute entretenait la boucle. L’historique utile inclut donc la règle appliquée, le compteur, la décision et la réponse éventuelle.

L’échec devait retirer le raccourci

Une route dépendante d’un assistant ne pouvait survivre intacte à la disparition de cette dépendance. Lorsqu’un hôte ne parvenait plus à résoudre le prochain saut appris par Redirect, notamment après expiration de l’entrée de l’assistant, la RFC demandait de supprimer l’entrée de routage associée.

Le problème de compatibilité conduisait au même résultat. Un routeur sachant pratiquer Directed ARP pouvait annoncer un prochain saut étranger à un pair qui ne le savait pas. Pour ce pair, la route n’était pas moins élégante ; elle était inexécutable. L’annonceur pouvait devoir offrir un prochain saut conventionnel, éventuellement plus coûteux, ou la relation administrée pouvait interdire l’annonce étrangère.

La validité ne résidait donc pas dans la seule valeur du champ next hop. Elle dépendait des capacités du récepteur, de l’assistant enregistré, de l’interface et de l’état de résolution. Deux pairs pouvaient recevoir la même annonce et disposer de possibilités différentes.

Une même infrastructure ne formait pas une clique

La partie la plus moderne du document traite des prochains sauts tiers. Un routeur qui annonce sa propre information de routage doit normalement la corriger lorsqu’elle devient fausse. Un tiers placé directement sur la liaison peut échapper à cette observation : l’annonceur ne voit pas nécessairement les paquets ni la panne entre les deux autres participants.

L’exemple SMDS donne à ce risque une forme précise. Des filtres pouvaient autoriser R1 avec R2 et R2 avec R3, tout en bloquant R1 avec R3. R2 connaissait réellement R3. Il pouvait néanmoins annoncer à R1 un prochain saut direct que la politique de liaison rendait impossible. La proximité de chacun avec R2 ne créait pas la transitivité entre R1 et R3.

Les filtres pouvaient aussi être asymétriques : R3 envoyait vers R1, mais R1 ne pouvait pas répondre. Voir une trame ou recevoir une association dans un sens ne prouvait donc pas le chemin inverse. La notion de réseau partagé décrivait une infrastructure commune, non un droit universel de communication entre toutes ses extrémités.

Vérifier sans laisser le routage tricher

La RFC proposait de tester le prochain saut par un echo ICMP adressé directement à son adresse de liaison, avant l’installation ou la première utilisation de la route. Un echo envoyé normalement à l’adresse IP aurait pu suivre un autre itinéraire et revenir avec succès sans avoir traversé l’adjacence examinée.

Cette précaution illustre une règle de preuve : le test doit emprunter exactement la dépendance qu’il prétend vérifier. Même alors, un succès n’attestait qu’un échange à un instant. Il ne certifiait pas toutes les classes de trafic, la symétrie, le transfert vers la destination finale ou la stabilité future. La détection des changements ultérieurs restait du ressort du routage dynamique.

Un rapport sérieux distingue donc l’annonce, l’assistant, la résolution locale de cet assistant, la requête dirigée, l’origine de la réponse, l’interface, le filtre, le test direct et le premier échange de données. Chacun peut réussir ou échouer séparément.

Sources et limites

La RFC 1433 définit cette procédure expérimentale. La RFC 826 fournit ARP ; la RFC 1209 décrit le contexte SMDS ; les RFC 1267 et 1247 apportent les cadres contemporains BGP-3 et OSPF ; les RFC 1122 et 792 apportent les contraintes d’hôte et ICMP.

Ces textes n’établissent ni déploiement actuel, ni comportement universel des équipements, ni taux d’attaque, ni recommandation présente. La RFC 1433 déclare elle-même ne pas discuter les questions de sécurité. Son intérêt historique est ailleurs : elle montre qu’une adresse trouvée au-dessous d’une route ne transforme pas une politique de liaison en promesse de transport.

Sources