Protocole de résolution d'adresse inverse

Statut du présent mémoire

Le présent document spécifie un protocole de l’Internet en cours de normalisation pour la communauté de l’Internet, et appelle à des discussions et suggestions pour son amélioration. Prière de se référer à l’édition en cours des "Normes officielles des protocoles de l’Internet" (STD 1) pour connaître l’état de la normalisation et le statut de ce protocole. La distribution du présent mémoire n’est soumise à aucune restriction.

Notice de Copyright

Copyright (C) The Internet Society (1998). Tous droits réservés.

Résumé

Le présent mémoire décrit des additions à ARP qui permettront à une station de demander une adresse de protocole correspondant à une adresse matérielle donnée. Précisément, cela s'applique aux stations en relais de trame qui peuvent avoir un identifiant de connexion de liaison de données (DLCI, Data Link Connection Identifier), l'équivalent en relais de trame d'une adresse matérielle, associé à un circuit virtuel permanent (PVC, Permanent Virtual Circuit) établi, mais ne connaissent pas l'adresse de protocole de la station de l'autre côté de cette connexion. Il s'appliquera aussi aux autres réseaux qui connaissent des circonstances similaires.

Le présent mémoire remplace la RFC 1293. Les changements par rapport à la RFC 1293 sont des modifications mineures pour formaliser le langage, l'ajout d'un diagramme de paquet et d'un exemple au paragraphe 7.2, et une nouvelle section sur la sécurité.

1.   Conventions

Dans le présent document, les mots clés "DOIT", "NE DOIT PAS", "EXIGE", "DEVRA", "NE DEVRA PAS", "DEVRAIT", "NE DEVRAIT PAS", "RECOMMANDE", "PEUT", et "FACULTATIF" sont à interpréter comme décrit dans [5].

1.   Introduction

Le présent document s'appuie fortement sur le relais de trame comme exemple de la façon dont le protocole de résolution d'adresse inverse (InARP) peut être utile. Il n'est cependant pas entendu que InARP soit exclusivement utilisé avec le relais de trame. InARP peut être utilisé dans tout réseau qui fournit les adresses des matériels de destination sans indiquer les adresses de protocole correspondantes.

3.   Motifs

La motivation du développement de l'ARP inverse est le résultat du désir de rendre la résolution d'adresse dynamique au sein du relais de trame à la fois possible et efficace. Les circuits virtuels permanents (PVC) et éventuellement les circuits virtuels commutés (SVC) sont identifiés par un identifiant de connexion de liaison de données (DLCI, Data Link Connection Identifier). Ces DLCI définissent une seule connexion virtuelle à travers un réseau dispersé (WAN, wide area network) et peuvent être vus comme l'équivalent en relais de trame d'une adresse de matériel. Périodiquement, au moyen de l'échange de messages de signalisation, un réseau peut annoncer un nouveau circuit virtuel avec son DLCI correspondant. Malheureusement, l'adressage du protocole n'est pas inclus dans l'annonce. La station qui reçoit une telle indication sera au courant de la nouvelle connexion, mais ne sera pas capable de s'adresser à l'autre côté. Sans une nouvelle configuration ou un mécanisme pour découvrir l'adresse de protocole de l'autre côté, ce nouveau circuit virtuel est inutilisable.

D'autres méthodes de résolution ont été considérées pour résoudre ces problèmes, mais ont été rejetées. L'ARP inversé [4], par exemple, semblait un bon candidat, mais la réponse à une demande est l'adresse de protocole de la station demanderesse, et non celle de la station qui reçoit la demande. Les mécanismes spécifiques de IP étaient limitatifs dans la mesure où ils ne permettent pas la résolution de protocoles autres que IP. Pour cette raison, le protocole ARP a été élargi.

Le protocole de résolution d'adresse inverse (InARP, Inverse Address Resolution Protocol) permettra à une station de relais de trame de découvrir l'adresse de protocole d'une station associée au circuit virtuel. C'est plus efficace que d'envoyer des messages ARP sur chaque circuit virtuel pour chaque adresse que le système veut résoudre et c'est plus souple que de s'appuyer sur une configuration statique.

4.   Format de paquet

L'ARP inverse est une extension de l'ARP existant. Donc, il a le même format que l'ARP standard.

ar$hrd   16 bits   Type de matériel

ar$pro   16 bits   Type de protocole

ar$hln   8 bits   Longueur en octets de chaque adresse de matériel (n)

ar$pln   8 bits   Longueur en octets de chaque adresse de protocole (m)

ar$op   16 bits   Code de fonctionnement

ar$sha   n octets   Adresse du matériel source

ar$spa   m octets   Adresse du protocole source

ar$tha   n octets   Adresse du matériel cible

ar$tpa   m octets   Adresse du protocole cible

Les valeurs possibles pour les types de matériel et de protocole sont les mêmes que pour ARP et se trouvent dans la RFC actuelle des numéros alloués [2].

La longueur des adresses de matériel et de protocole dépend de l'environnement dans lequel fonctionne InARP. Par exemple, si IP fonctionne sur du relais de trame, la longueur de l'adresse de matériel sera 2, 3, ou 4, et la longueur de l'adresse de protocole est 4.

Le code de fonctionnement indique le type de message, demande ou réponse.

Demande InARP = 8

Réponse InARP = 9

Ces valeurs ont été choisies de façon à ne pas entrer en conflit avec les autres extensions ARP.

5.   Fonctionnement du protocole

L'InARP de base fonctionne essentiellement le la même façon que ARP à l'exception que InARP ne diffuse pas les demandes. Cela parce que l'adresse de matériel de la station de destination est déjà connue.

Lorsqu'une interface qui prend en charge InARP devient active, elle devrait initier le protocole InARP et formater les demandes InARP pour chaque PVC actif pour lequel InARP est actif. Pour ce faire, une station demandeuse formate simplement une demande en insérant son matériel de source, ses adresses de protocole de source et les adresses de matériel cible connues. Elle remplit alors de zéros le champ Adresse de protocole cible. Finalement, elle va encapsuler le paquet pour le réseau spécifié et l'envoyer directement à la station cible.

À réception d'une demande InARP, une station peut mettre la transposition d'adresse de protocole /adresse de matériel du demandeur dans son antémémoire ARP comme elle le ferait d'une demande ARP. Cependant, à la différence des autres demandes ARP, la station receveuse peut supposer que toute demande InARP reçue lui est destinée. Pour chaque demande InARP, la station receveuse devrait formater une réponse appropriée en utilisant les adresses de source provenant de la demande comme adresses de cible de la réponse. Si la station n'est pas capable ou ne veut pas répondre, elle ignore la demande.

Lorsque la station demandeuse reçoit la réponse InARP, elle peut compléter l'entrée de tableau ARP et utiliser les informations d'adresse fournies. Note : comme avec ARP, les informations acquises via InARP peuvent être anciennes ou invalides dans certaines circonstances.

5.1   Fonctionnement avec des hôtes à rattachement multiple

Dans le contexte de cet exposé, un hôte à rattachement multiple va se référer à un hôte qui a plusieurs adresses de protocole allouées à une seule interface. Si une telle station reçoit une demande InARP, elle doit choisir une adresse avec laquelle elle va répondre. Pour faire un tel choix, la station receveuse doit d'abord regarder l'adresse de protocole de la station demandeuse, puis répondre avec l'adresse de protocole qui correspond au réseau de la demandeuse. Par exemple, si la station demandeuse vérifie une adresse IP, la station à rattachement multiple qui répond devrait le faire avec une adresse IP qui correspond au même sous-réseau que la station demandeuse. Si la station n'a pas d'adresse qui soit appropriée pour la demande, elle ne devrait pas répondre. Dans l'exemple IP, si la station receveuse n'a pas une adresse IP allouée à cette interface qui fasse partie du sous-réseau demandé, la station receveuse ne devrait pas répondre.

Un hôte à rattachement multiple devrait envoyer une demande InARP pour chacune des adresses définies pour l'interface donnée. On devrait noter, cependant, que le côté qui reçoit peut répondre à certaines des demandes ou à aucune selon sa configuration.

5.2   Fonctionnement du protocole au sein du relais de trame

Un cas où l'ARP inverse peut être utilise est celui d'une interface de relais de trame qui prend en charge la signalisation des DLCI via une interface de gestion de liaison de données. Une station équipée pour InARP connectée à une telle interface va formater une demande InARP et l'adresser au nouveau circuit virtuel. Si l'autre côté prend en charge InARP, il peut retourner une réponse indiquant l'adresse de protocole demandée.

Dans un environnement de relais de trame , les paquets InARP sont encapsulés en utilisant le format NLPID/SNAP défini en [3] qui indique le protocole ARP. Précisément, l'encapsulation du paquet sera comme suit :

Le format pour une demande InARP elle-même est défini par ce qui suit :

ar$hrd - 0x000F la valeur allouée au relais de trame

ar$pro – type de protocole pour lequel vous faites la recherche (c'est-à-dire, IP = 0x0800)

ar$hln - 2, 3, ou 4 octets de longueur d'adresse

ar$pln – longueur en octets de l'adresse de protocole pour laquelle est faite la recherche (pour IP = 4)

ar$op - 8 ; demande InARP

ar$sha – adresse Q.922 [6] de la station demandeuse

ar$spa – adresse de protocole de la station demandeuse

ar$tha – adresse Q.922 du circuit virtuel nouvellement annoncé

ar$tpa – 0 ; c'est ce qui est demandé

La réponse InARP sera remplie de façon similaire.

ar$hrd - 0x000F la valeur allouée au relais de trame

ar$pro – type de protocole pour lequel la recherche est faite (c'est-à-dire, IP = 0x0800)

ar$hln - 2, 3, ou 4 octets de longueur d'adresse

ar$pln – longueur en octets de l'adresse de protocole pour laquelle la recherche est faite (pour IP = 4)

ar$op - 9 ; réponse InARP

ar$sha – adresse Q.922 de la station qui répond

ar$spa – adresse de protocole demandée

ar$tha – adresse Q.922 de la station demandeuse

ar$tpa – adresse de protocole de la station demandeuse

Noter que les adresses Q.922 spécifiées ont les bits C/R, FECN, BECN et DE mis à zéro.

Les procédures pour utiliser InARP sur un réseau en relais de trame sont les suivantes :

Comme au sein de la plupart des réseaux en relais de trame, les DLCI n'ont de signification que locale, une station d'extrémité n'aura pas elle-même de DLCI spécifique d'alloué. Donc, une telle station n'a pas d'adresse à mettre dans la demande ou réponse InARP. Heureusement, le réseau en relais de trame fournit bien une méthode pour obtenir les DLCI corrects. La solution proposée pour les réseaux en relais de trame à adresse locale ci-dessous fonctionne également bien lorsque les DLCI ont une signification mondiale.

Le DLCI porté dans l'en-tête de relais de trame est modifié lorsqu'il traverse le réseau. Lorsque le paquet arrive à sa destination, le DLCI a été réglé à la valeur qui, du point de vue de la station receveuse, correspond à la station qui envoie. Par exemple, à la figure 1 ci-dessous, si la station A devait envoyer un message à la station B, elle placerait le DLCI 50 dans l'en-tête de relais de trame. Lorsque la station B a reçu ce message, cependant, le DLCI sera modifié par le réseau et apparaîtra à B comme DLCI 70.

Figure 1

Les lignes entre les stations représentent les connexions de liaison de données (DLC, Data Link Connection). Les nombres indiquent le DLCI local associé à chaque connexion.

Tableau des DLCI en adresse Q.922 pour la Figure 1

Pour une description d'autorité de la corrélation entre DLCI et adresses Q.922 [6], le lecteur devrait consulter cette spécification. Un résumé de la corrélation est inclus ici pour la compréhension du lecteur. La traduction de DLCI en adresse Q.922 se fonde sur une longueur d'adresse de deux octets utilisant le format de codage Q.922. Le format est :

Pour InARP, les bits FECN, BECN, C/R et DE sont supposés à zéro.

Lorsque un message InARP atteint sa destination, toutes les adresses de matériel seront invalides. L'adresse trouvée dans l'en-tête de trame sera néanmoins correcte. Bien qu'il viole la pureté de la mise en couches, le relais de trame peut utiliser l'adresse de l'en-tête comme adresse de matériel de l'envoyeur. Il faut aussi noter que l'adresse de matériel cible, aussi bien dans la demande que la réponse InARP, sera aussi invalide. Cela ne devrait pas causer de problème car InARP ne s'appuie pas sur ces champs et en fait, une mise en œuvre peut entièrement remplir de zéros ou ignorer le champ d'adresse de matériel cible.

En utilisant la figure 1 comme exemple, la station A peut utiliser l'ARP inverse pour découvrir l'adresse de protocole de la station associée à son DLCI 50. La demande d'ARP inverse serait comme suit :

Demande InARP de A (DLCI 50)

ar$op 8 (InARP request)

ar$sha unknown

ar$spa pA

ar$tha 0x0C21 (DLCI 50)

ar$tpa unknown

Lorsque la Station B reçoit ce paquet, elle va modifier l'adresse de matériel de source avec l'adresse Q.922 de l'en-tête de relais de trame. De cette façon, la demande InARP de A va devenir :

ar$op 8 (InARP request)

ar$sha 0x1061 (DLCI 70)

ar$spa pA

ar$tha 0x0C21 (DLCI 50)

ar$tpa unknown.

La Station B va formater une réponse ARP inverse et l'envoyer à la station A :

ar$op 9 (InARP response)

ar$sha unknown

ar$spa pB

ar$tha 0x1061 (DLCI 70)

ar$tpa pA

L'adresse de matériel de source est inconnue et lorsque la réponse est reçue, la station A va extraire l'adresse de l'en-tête de relais de trame e t la placer dans le champ d'adresse de matériel de source. Donc, la réponse va devenir :

ar$op 9 (InARP response)

ar$sha 0x0C21 (DLCI 50)

ar$spa pB

ar$tha 0x1061 (DLCI 70)

ar$tpa pA

Cela signifie que l'interface de relais de trame doit seulement intervenir dans le traitement des paquets entrants.

Voir aussi [3] pour une description de procédures similaires pour l'utilisation de ARP [1] et RARP [4] avec le relais de trame.

6.   Considérations pour la sécurité

Le présent document spécifie une amélioration fonctionnelle de la famille des protocoles ARP, et il est soumis aux mêmes contraintes de sécurité que celles qui affectent ARP et les protocole de résolution d'adresse similaires. Comme l'authentification ne fait pas partie de ARP, il y a des problèmes de sécurité connus qui se rapportent à son utilisation (par exemple de se faire passer pour un hôte). Aucun mécanisme de sécurité supplémentaire n'a été ajouté à la famille des protocoles ARP f^r le présent document.

7.   Références

[1]   D. Plummer, "Protocole de résolution d’adresses Ethernet", STD 37, RFC-826, novembre 1982.

[2]   J. Reynolds et J. Postel, "Numéros alloués", STD 2, RFC 1700, octobre 1994. (Historique) Voir aussi : http://www.iana.org/numbers.html

[3]   T. Bradley, C. Brown et A. Malis, "Interconnection multi protocoles sur relais de trame", RFC 1490, juillet 1993.

[4]   R. Finlayson, T. Mann, J. Mogul et M. Theimer, "Protocole de résolution inverse d'adresse", STD 38, RFC 903, Stanford University, juin 1984.

[5]   S. Bradner, "Mots clés à utiliser dans les RFC pour indiquer les niveaux d'exigence", BCP 14, RFC 2119, mars 1997.

[6]   Technologies de l'information – Échanges de télécommunications et d'informations entre systèmes - Protocole d'identification dans la couche réseau, ISO/CEI TR 9577 : 1992.

8.   Adresse des auteurs

9.   Déclaration complète de droits de reproduction

Copyright (C) The Internet Society (1998). Tous droits réservés.

Ce document et les traductions de celui-ci peuvent être copiés et diffusés, et les travaux dérivés qui commentent ou expliquent autrement ou aident à sa mise en œuvre peuvent être préparés, copiés, publiés et distribués, partiellement ou en totalité, sans restriction d'aucune sorte, à condition que l'avis de copyright ci-dessus et ce paragraphe soit inclus sur toutes ces copies et œuvres dérivées. Toutefois, ce document lui-même ne peut être modifié en aucune façon, par exemple en supprimant le droit d'auteur ou les références à l'Internet Society ou d'autres organisations Internet, sauf si c'est nécessaire à l'élaboration des normes Internet, auquel cas les procédures pour les copyrights définis dans les processus de normes pour Internet doivent être suivies, ou si nécessaire pour le traduire dans des langues autres que l'anglais.

Les permissions limitées accordées ci-dessus sont perpétuelles et ne seront pas révoquées par la Société Internet ou ses successeurs ou ayants droit.

Ce document et les renseignements qu'il contient sont fournis "TELS QUELS" et L'INTERNET SOCIETY ET L'INTERNET ENGINEERING TASK FORCE DÉCLINE TOUTE GARANTIE, EXPRESSE OU IMPLICITE, Y COMPRIS MAIS SANS S'Y LIMITER, TOUTE GARANTIE QUE L'UTILISATION DE L'INFORMATION ICI PRÉSENTE N'ENFREINDRA AUCUN DROIT OU AUCUNE GARANTIE IMPLICITE DE COMMERCIALISATION OU D'ADAPTATION A UN OBJET PARTICULIER.