Protocole de résolution d’adresse Ethernet
Conversion des adresses de protocole réseau en adresses Ethernet à 48 bits pour la transmission sur matériel Ethernet

Résumé

La mise en œuvre du protocole P sur un hôte envoyeur S décide, grâce au mécanisme de routage du protocole P, qu’il veut transmettre à un hôte cible T localisé quelque part sur une partie connectée d’un câble Ethernet à 10 Mbit. Pour transmettre effectivement le paquet Ethernet, une adresse Ethernet de 48 bits doit être générée. Les adresses des hôtes au sein du protocole P ne sont pas toujours compatibles avec l’adresse Ethernet correspondante (étant de longueurs ou de valeurs différentes). On présente ici un protocole qui permet une distribution dynamique des informations nécessaires pour construire les tableaux de traduction d’une adresse A dans l’espace d’adresse du protocole P en une adresse Ethernet à 48 bits.

Des généralisations ont été faites pour permettre d’utiliser le protocole pour un matériel différent de l’Ethernet à 10 Mbit. Certains réseaux radio par paquets sont des exemples d’un tel matériel.

Le protocole proposé ici est le résultat de nombreuses discussions avec plusieurs autres personnes, principalement J. Noël Chiappa, Yogen Dalal et James E. Kulp, et des commentaires utiles de David Moon.

[L’objet de cette RFC est de présenter une méthode de conversion des adresses de protocole (par exemple, les adresses IP) en adresses de réseau local (par exemple, des adresses Ethernet). C’est en ce moment un sujet général de préoccupation dans la communauté ARPA Internet. La méthode proposée ici est présentée pour être prise en considération et recueillir des commentaires. Ce n’est pas la spécification d’une norme de l’Internet.]

Notes :

Ce protocole a été conçu à l’origine pour l’Ethernet à 10 Mbit DEC/Intel/Xerox. Il a été généralisé pour lui permettre d’être utilisé pour d’autres types de réseaux. Une grande partie de l’exposé sera tournée vers l’Ethernet à 10 Mbit. Les généralisations, lorsqu’elles sont applicables, suivront l’exposé spécifique de l’Ethernet.

Le protocole Internet du DOD sera désigné sous le nom de Internet.

Les nombres indiqués ici sont dans la norme Ethernet, qui est l’octet de plus fort poids en premier. C’est à l’opposé de l’adressage d’octet de machines telles que PDP-11 et VAX. Il faudra donc faire très attention avec le champ opcode (ar$op) décrit ci-dessous.

Une autorité acceptée d’un commun accord est nécessaire pour gérer les valeurs d’espace de nom de matériel (voir ci-dessous).Jusqu’à ce qu’existe une autorité officielle, les demandes devraient être soumises à

David C. Plummer
Symbolics, Inc.
243 Vassar Street
Cambridge, Massachusetts 02139

Autrement, des messages réseau peuvent être envoyés à DCP@MIT-MC.

Le problème :

Le monde est une jungle, et le jeu du réseautage contribue pour de nombreuses espèces. À presque chaque couche d’une architecture de réseau, plusieurs protocoles peuvent être utilisés. Par exemple, à haut niveau, il y a TELNET et SUPDUP pour la connexion à distance. Un peu en dessous, il y a un protocole de flux d’octets fiable, qui peut être le protocole CHAOS, ou DOD TCP, Xerox BSP ou DECnet. Même plus près du matériel se trouve la couche de transport logique, qui pourrait être CHAOS, DOD Internet, Xerox PUP, ou DECnet. L’Ethernet à 10 Mbit permet à tous ces protocoles (et à bien d’autres) de coexister sur un seul câble au moyen d’un champ de type dans l’en-tête du paquet Ethernet. Cependant, l’Ethernet à 10 Mbit exige des adresses de 48 bits sur le câble physique, alors que la plupart des adresses de protocole ne sont pas longues de 48 bits, et n’ont pas nécessairement de relation avec l’adresse Ethernet de 48 bits du matériel. Par exemple, les adresses CHAOS sont de 16 bits, les adresses Internet du DOD sont de 32 bits, et les adresses PUP de Xerox sont de 8 bits. Un protocole est nécessaire pour distribuer de façon dynamique les correspondances entre une paire <protocole, adresse> et une adresse Ethernet à 48 bits.

Motifs :

L’utilisation de l’Ethernet à 10 Mbit se développe car de plus en plus de fabricants fournissent des interfaces conformes à la spécification publiée par DEC, Intel et Xerox. Avec cette disponibilité croissante, de plus en plus de logiciels sont écrits pour ces interfaces. Il y a un choix à faire : (1) Chaque développeur invente sa propre méthode de résolution d’adresse, ou (2) chaque développeur utilise une norme telle que son code puisse être distribué aux autres systèmes sans qu’il soit besoin de le modifier. La présente proposition essaye d’établir cette norme.

Définitions :

Définir ce qui suit pour se référer aux valeurs mises dans l’en-tête TYPE de l’en-tête du paquet Ethernet :

ether_type$XEROX_PUP,
ether_type$DOD_INTERNET,
ether_type$CHAOS,
et en ajouter un nouveau :
ether_type$ADDRESS_RESOLUTION.
Définir aussi les valeurs suivantes (qui sont exposées plus loin) :
ares_op$REQUEST (= 1, octet de plus fort poids transmis en premier) et
ares_op$REPLY (= 2), et
ares_hrd$Ethernet (= 1).

Format de paquet :

Pour communiquer les transpositions des paires <protocole, adresse> en adresses Ethernet à 48 bits, un format de paquet qui incorpore le protocole de résolution d’adresse est nécessaire. Le format du paquet figure ci-dessous.

Couche de transmission Ethernet (pas nécessairement accessible à l’utilisateur) :

48 bits : adresse de destination Ethernet
48 bits : adresse Ethernet de l’envoyeur
16 bits : type de protocole = ether_type$ADDRESS_RESOLUTION

Paquet de données Ethernet :

16 bits : (ar$hrd) espace d’adresse matériel (par exemple, Ethernet, réseau radio par paquet.)
16 bits : (ar$pro) espace d’adresse de protocole. Pour le matériel Ethernet, c’est d’après l’ensemble des champs type ether_typ$<protocol>.
8 bits : (ar$hln) longueur en octets de chaque adresse de matériel
8 bits : (ar$pln) longueur en octets de chaque adresse de protocole
16 bits : (ar$op) opcode (ares_op$REQUEST | ares_op$REPLY)
n octets : (ar$sha) adresse de matériel de l’envoyeur de ce paquet, n d’après le champ ar$hln.
m octets : (ar$spa) adresse de protocole de l’envoyeur de ce paquet, m d’après le champ ar$pln.
n octets : (ar$tha) adresse de matériel de la cible de ce paquet (si elle est connue).
m octets : (ar$tpa) adresse de protocole de la cible.

Génération de paquet :

Comme un paquet est envoyé en descendant les couches réseau, l’acheminement détermine l’adresse de protocole du prochain bond pour le paquet et sur quel matériel on s’attend à trouver la station avec l’adresse de protocole cible immédiate. Dans le cas de l’Ethernet à 10 Mbit, la résolution d’adresse est nécessaire et une couche inférieure (probablement le pilote du matériel) doit consulter le module de résolution d’adresse (peut-être mis en œuvre dans le module de prise en charge Ethernet) pour convertir la paire <type de protocole, adresse de protocole cible> en adresse Ethernet à 48 bits. Le module de résolution d’adresse essaye de trouver cette paire dans un tableau. Si il trouve la paire, il redonne l’adresse Ethernet à 48 bits correspondante à l’appelant (le pilote matériel) qui transmet alors le paquet. S’il ne la trouve pas, il informe probablement l’appelant qu’il élimine le paquet (en supposant que le paquet sera retransmis par une couche réseau supérieure), et génère un paquet Ethernet avec un champ type de ether_type$ADDRESS_RESOLUTION. Le module de résolution d’adresse règle alors les champs de la façon suivante :

ar$hrd à ares_hrd$Ethernet,
ar$pro au type de protocole qu’on veut résoudre,
ar$hln à 6 (le nombre d’octets d’une adresse Ethernet à 48 bits),
ar$pln à la longueur d’une adresse dans ce protocole,
ar$op à ares_op$REQUEST,
ar$sha avec sa propre adresse Ethernet à 48 bits,
ar$spa à sa propre adresse de protocole, et
ar$tpa à l’adresse de protocole de la machine qui essaye de donner l’accès.

Il ne règle pas ar$tha à quelque chose de particulier parce que c’est cette valeur qu’il essaye de déterminer. Il pourrait régler ar$tha à l’adresse de diffusion du matériel (tout à un dans le cas de l’Ethernet à 10 Mbit) si c’est pratique pour un aspect quelconque de la mise en œuvre. Il provoque alors la diffusion de ce paquet à toutes les stations du câble Ethernet déterminées à l’origine par le mécanisme d’acheminement.

Réception du paquet :

Lors de la réception d’un paquet de résolution d’adresse, le module Ethernet récepteur donne le paquet au module de résolution d’adresse qui passe par un algorithme similaire à celui présenté ci-dessous. Des réponses négatives indiquent la fin du traitement et l’élimination du paquet.

- Le type de matériel est-il en ar$hrd ?
Oui : (presque certainement)
- [vérifier facultativement la longueur de matériel ar$hln]
- Est-ce que je parle le protocole en ar$pro ?
Oui :
- [vérifier facultativement la longueur de protocole ar$pln] Merge_flag : = faux
- Si la paire <type de protocole, adresse de protocole de l’envoyeur> est déjà dans le tableau de traduction, mettre à jour le champ d’adresse matériel de l’envoyeur de l’entrée avec les nouvelles informations contenues dans le paquet et régler Merge_flag à vrai.
- Suis-je l’adresse de protocole cible ?
Oui :
- Si Merge_flag est faux, ajouter le triplet <type de protocole, adresse de protocole de l’envoyeur, adresse de matériel de l’envoyeur> au tableau de traduction.
- Le opcode est-il ares_op$REQUEST? (Regarder MAINTENANT le opcode !!)
Oui :
Échanger les champs matériel et protocole, en mettant les adresses de matériel local et de protocole dans les champs d’envoyeur.
Envoyer le champ ar$op à ares_op$REPLY
Envoyer le paquet à la (nouvelle) adresse de matériel cible sur le même matériel que sur lequel la demande a été reçue.

Remarquer que le triplet <type de protocole, adresse de protocole de l’envoyeur, adresse de matériel de l’envoyeur> est incorporé dans le tableau avant l’examen de l’opcode. Ceci dans l’hypothèse où la communication est bidirectionnelle ; si A a quelques raisons de parler à B, B aura probablement quelques raisons de parler à A. Remarquer aussi que si une entrée existe déjà pour la paire <type de protocole, adresse de protocole de l’envoyeur>, la nouvelle adresse de matériel supplante alors l’ancienne. Le paragraphe Problèmes connexes en donne quelques explications.

Généralisation : Les champs ar$hrd et ar$hln permettent d’utiliser ce protocole et ce format de paquet pour autre chose que des Ethernets 10 Mbit. Pour l’Ethernet à 10 Mbit <ar$hrd, ar$hln> prend la valeur <1, 6>. Pour les autres réseaux matériels, le champ ar$pro peut ne plus correspondre au champ type Ethernet, mais il devrait être associé au protocole dont on recherche la résolution d’adresse.

Pourquoi est-ce fait de cette façon ?

La diffusion périodique n’est vraiment pas souhaitable. Imaginez 100 stations de travail sur un seul Ethernet, diffusant chacune des informations de résolution d’adresse une fois toutes les 10 minutes (exemple possible d’ensemble de paramètres). Cela fait un paquet toutes les 6 secondes. C’est assez raisonnable, mais de quelle utilité ? Les stations ne vont généralement pas se mettre à communiquer les unes avec les autres (et donc on a cent entrées inutiles dans un tableau) ; elle dialoguent principalement avec un système central, un serveur de fichiers ou un pont, mais seulement à un faible nombre d’autres stations de travail (pour des conversations interactives, par exemple). Le protocole décrit ici distribue les informations au fur et à mesure qu’elles sont nécessaires, et seulement une fois (probablement) par amorçage de machine.

Ce format ne permet pas d’effectuer plus d’une résolution dans le même paquet. Ceci est pour simplifier. Si on est en multiplex, le format de paquet serait considérablement plus dur à digérer, et beaucoup des informations pourraient être gratuites. Imaginez un pont qui parle quatre protocoles qui donne à une station de travail les quatre adresses de protocole, dont trois ne seront probablement jamais utilisées par la station.

Le présent format permet à la mémoire tampon de paquet d’être réutilisée si une réponse est générée ; une réponse a la même longueur qu’une demande, et plusieurs des champs sont les mêmes.

La valeur du champ de matériel (ar$hrd) est tirés d’une liste destinée à cet effet. Actuellement, la seule valeur définie est pour l’Ethernet à 10 Mbit (ares_hrd$Ethernet = 1). Il y a eu également des discussions sur l’utilisation de ce protocole pour les réseaux radio par paquet, et cela exigera une autre valeur comme pour les autres futurs supports matériels qui souhaitent utiliser ce protocole.

Pour le 10 Mbit Ethernet, la valeur dans le champ protocole (ar$pro) est tirée de l’ensemble ether_type$. C’est une réutilisation naturelle des types de protocole alloués. Combiner cela avec le opcode (ar$op) diviserait effectivement par deux le nombre de protocoles qui peuvent être résolus sous ce protocole et rendrait un système de surveillance / correction d’erreur plus complexe (voir le paragraphe Surveillance du réseau et correction des erreurs ci-dessous). On espère qu’on ne verra jamais 32 768 protocoles, mais Murphy a établi des lois qui ne nous permettent pas de dépasser cette hypothèse.

En théorie, les champs de longueur (ar$hln et ar$pln) sont redondants, car la longueur d’une adresse de protocole devrait être déterminée par le type de matériel (qu’on trouve dans ar$hrd) et le type de protocole (dans ar$pro). C’est inclus pour une vérification de cohérence facultative et pour la surveillance du réseau et la correction d’erreurs (voir ci-dessous).

Le opcode sert à déterminer si il s’agit d’une demande (qui peut causer une réponse) ou une réponse à une demande précédente. 16 bits pour cela est bien plus que nécessaire, mais il faut un fanion (donc un champ).

L’adresse de matériel de l’envoyeur et l’adresse de protocole de l’envoyeur sont absolument nécessaires. Ce sont ces champs qui sont mis dans un tableau de traduction.

L’adresse de protocole cible est nécessaire dans la forme de demande du paquet afin que la machine puisse déterminer s’il faut entrer ou non les informations de l’envoyeur dans un tableau ou envoyer une réponse. Elle n’est pas nécessairement dans la forme d’une réponse si on suppose qu’une réponse n’est provoquée que par une demande. Elle est incluse par souci d’être complet, pour la surveillance du réseau, et pour simplifier le traitement suggéré d’algorithme décrit plus haut (qui ne regarde pas le opcode tant que les informations de l’envoyeur ne sont pas rentrées dans un tableau).

L’adresse de matériel cible est incluse par souci d’exhaustivité et pour la surveillance du réseau. Elle n’a pas de signification sous la forme de demande, car c’est le numéro que demande la machine. Sa signification dans la forme de réponse est l’adresse de la machine qui fait la demande. Dans certaines mises en œuvre (qui ne vont pas regarder dans l’en-tête éthernet de 14 octets, par exemple) cela peut économiser un peu d’espace se registre ou de pile en envoyant de champ au pilote du matériel comme adresse de destination matérielle du paquet.

Il n’y a pas d’octets de bourrage entre les adresses. Les données du paquet ne devraient jamais être considérées comme un flux d’octets dans lequel seulement trois paires d’octets sont définies comme des mots (ar$hrd, ar$pro et ar$op)qui sont envoyés avec l’octet de plus fort poids en premier (dans le style de Ethernet/PDP-10 octets).

Surveillance du réseau et correction d’erreurs :

Le protocole de résolution d’adresse ci-dessus permet à une machine d’acquérir la connaissance de l’activité de protocole de niveau supérieur (par exemple, CHAOS, Internet, PUP, DECnet) sur un câble Ethernet. Il peut déterminer quels champs de type de protocole Ethernet sont utilisés (par leur valeur) ainsi que les adresses de protocole au sein de chaque type de protocole. En fait, il n’est pas nécessaire que le surveillant parle un des protocoles de niveau supérieur impliqués. Il se passe quelque chose comme ce qui suit.

Lorsqu’un surveillant reçoit un paquet de résolution d’adresse, il entre toujours le triplet <type de protocole, adresse de protocole de l’envoyeur, adresse de matériel de l’envoyeur> dans un tableau. Il peut déterminer la longueur de l’adresse du protocole et du matériel à partir des champs ar$hln et ar$pln du paquet. Si le opcode est une RÉPONSE, le surveillant peut alors éliminer le paquet. Si le opcode est une DEMANDE et si l’adresse de protocole cible correspond à l’adresse de protocole du surveillant, celui-ci envoie une RÉPONSE comme il le ferait normalement. Le surveillant va seulement obtenir une transposition de cette façon, car la RÉPONSE à la DEMANDE sera envoyée directement à l’hôte demandeur. Le surveillant pourrait essayer d’envoyer sa propre DEMANDE, mais cela pourrait attraper deux surveillants dans une boucle d’envoi de DEMANDE, et il faut y faire attention.

Comme le protocole et l’opcode ne sont pas combinés dans un seul champ, le surveillant n’a pas besoin de savoir quel opcode de demande est associé avec un opcode de réponse pour le même protocole de niveau supérieur. Les champs longueur devraient aussi donner des informations suffisantes pour lui permettre d’analyser des adresses de protocole, bien qu’il n’ait aucune connaissance de ce que signifient les adresses de protocole.

Une mise en œuvre active de protocole de résolution d’adresses peut aussi être utilisée pour corriger les erreurs d’une mise en œuvre non active. Un pilote de matériel pourra vraisemblablement réussir à diffuser un paquet avec un champ de type Ethernet de ether_type$ADDRESS_RESOLUTION. Le format du paquet peut n’être pas totalement correct, parce que les mises en œuvre initiales peuvent comporter des erreurs, et la gestion des tableaux pourrait être un peu délicate. Comme les demandes sont en diffusion, un surveillant va recevoir le paquet et peut l’afficher pour corriger les erreurs si il le désire.

Exemple :

Soit deux machines X et Y qui sont sur le même câble 10 Mbit Ethernet. Elles ont les adresses Ethernet EA(X) et EA(Y) et les adresse Internet DOD IPA(X) et IPA(Y). Soit le type Ethernet d’Internet ET(IP). La machine X vient juste de démarrer, et tôt ou tard va vouloir envoyer un paquet Internet à la machine Y sur le même câble. X sait qu’il veut envoyer à IPA(Y) et dit IPA(Y) au pilote du matériel (ici un pilote Ethernet). Le pilote consulte le module de résolution d’adresse pour convertir <ET(IP), IPA(Y)> en une adresse Ethernet à 48 bits, mais comme X vient juste de démarrer, il n’a pas cette information. Il élimine le paquet Internet et crée à la place un paquet RÉSOLUTION D’ADRESSE avec

(ar$hrd) = ares_hrd$Ethernet
(ar$pro) = ET(IP)
(ar$hln) = length(EA(X))
(ar$pln) = length(IPA(X))
(ar$op) = ares_op$REQUEST
(ar$sha) = EA(X)
(ar$spa) = IPA(X)
(ar$tha) = sans importance
(ar$tpa) = IPA(Y)
et diffuse ce paquet à tout le monde sur le câble.

La machine Y reçoit ce paquet, et détermine qu’elle comprend le type de matériel (Ethernet), qu’elle parle le protocole indiqué (Internet) et que le paquet est pour elle ((ar$tpa)=IPA(Y)). Elle entre les informations (probablement en remplaçant une entrée existante) selon lesquelles <ET(IP), IPA(X)> se transpose en EA(X). Elle remarque ensuite que c’est une demande, aussi elle échange les champs, mettant EA(Y) dans le nouveau champ d’adresse Ethernet d’envoyeur (ar$sha), règle le opcode à réponse, et envoie le paquet directement (pas de diffusion) à EA(X). À ce point, Y sait comment envoyer à X, mais X ne sait toujours pas comment envoyer à Y.

La machine X obtient le paquet de réponse provenant de Y, forme la transposition de <ET(IP), IPA(Y)> en EA(Y), remarque que le paquet est une réponse et l’élimine. La prochaine fois que le module Internet de X essayera d’envoyer un paquet à Y sur l’Ethernet, la traduction réussira, et le paquet arrivera (on l’espère). Si le module Internet de Y veut alors parler à X, cela réussira aussi car Y va se souvenir des informations provenant de la demande de X pour la résolution d’adresse.

Problèmes connexes :

Il peut être souhaitable d’avoir une obsolescence du tableau et/ou des temporisations. La mise en œuvre de ces éléments sort du domaine d’application du présent protocole. Ci-après figure une description plus détaillée (grâce à MOON@SCRC@MIT-MC).

Si un hôte se déplace, toutes les connexions initialisées par cet hôte vont fonctionner, en supposant que son propre tableau de résolution d’adresses est vidé quand il se déplace. Cependant, les connexions initialisées avec lui par d’autres hôtes n’auront pas de raison particulière de savoir qu’il faut éliminer la vieille adresse. Cependant, les adresses Ethernet à 48 bits sont supposées être uniques et fixées une fois pour toutes, aussi ne devraient elles pas changer. Un hôte pourrait "bouger" si un nom d’hôte (et l’adresse dans certains autres protocoles) était réalloué à un matériel physique différent. Aussi, comme nous le savons par expérience, il y a toujours le danger que des informations d’acheminement incorrectes soient accidentellement transmises à cause d’une erreur de matériel ou de logiciel ; il ne devrait pas être permis que cela persiste pour toujours. Peut-être que l’échec d’initialisation d’une connexion devrait informer le module de résolution d’adresse de supprimer les informations au motif que l’hôte n’est pas joignable, soit qu’il soit en panne, soit que la vieille traduction n’est plus valide. Ou peut-être que la réception d’un paquet de la part d’un hôte devrait faire repartir une temporisation dans l’entrée de résolution d’adresse utilisée pour transmettre des paquets à cet hôte ; si aucun paquet n’est reçu d’un hôte pendant une durée convenable, l’entrée de résolution d’adresse est oubliée. Cela peut cause une redondance supplémentaire d’examiner le tableau pour chaque paquet entrant. Peut-être qu’un hachage ou un indice irait plus vite.

L’algorithme suggéré pour la réception des paquets de résolution d’adresse essaye de diminuer le temps nécessaire pour la récupération si un hôte bouge effectivement. Il faut se rappeler que si la paire <type de protocole, adresse de protocole de l’envoyeur> est déjà dans le tableau de traduction, l’adresse de matériel de l’envoyeur supplante alors l’entrée existante. Donc, sur un Ethernet parfait où une DEMANDE diffusée atteint toutes les stations sur le câble, chaque station obtiendra la nouvelle adresse de matériel.

Une autre solution de remplacement est d’avoir un démon qui effectue les temporisations. Après un intervalle de temps convenable, le démon considère l’éviction d’une entrée. Il envoie d’abord (avec un petit nombre de retransmissions si nécessaire) un paquet de résolution d’adresse avec l’opcode DEMANDE directement à l’adresse Ethernet figurant dans le tableau. Si une RÉPONSE n’est pas vue dans un bref délai, l’entrée est supprimée. La demande est envoyée directement de façon à ne pas ennuyer toutes les stations sur l’Ethernet. Oublier des entrées causera vraisemblablement l’oubli d’informations utiles, qui devront être retrouvées.

Comme les hôtes ne transmettent pas des informations sur d’autres qu’eux mêmes, le réamorçage d’un hôte causera la mise à jour de son tableau de transposition d’adresses. De mauvaises informations ne peuvent pas persister éternellement en étant passées de machine en machine ; la seule mauvaise information qui peut exister est dans une machine qui ne sait pas qu’une autre machine a changé son adresse Ethernet à 48 bits. Peut-être qu’un réglage manuel (ou une remise à zéro) du tableau de transposition d’adresse suffirait.

Ce problème mérite vraiment d’autres réflexions si on pense que c’est important. Il est causé par tous les protocoles du style résolution d’adresse.