RFC 826 - Protocole de résolution d'adresse Ethernet
An Ethernet Address Resolution Protocol
Sous-titre : Conversion des adresses de protocole réseau en adresses Ethernet 48 bits pour la transmission sur matériel Ethernet
Auteur : David C. Plummer (DCP@MIT-MC)
Date de publication : Novembre 1982
Statut : Protocole standard (Standard)
Résumé (Abstract)
L'implémentation du protocole P sur l'hôte émetteur S décide, par le mécanisme de routage du protocole P, qu'il souhaite transmettre à un hôte cible T situé quelque part sur un câble Ethernet 10Mbit connecté. Pour transmettre réellement le paquet Ethernet (Ethernet Packet), une adresse Ethernet 48 bits (Ethernet Address) 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 (longueurs ou valeurs différentes). Le protocole présenté ici permet la distribution dynamique des informations nécessaires à la construction de tables pour traduire une adresse A dans l'espace d'adresses du protocole P en une adresse Ethernet 48 bits.
Des généralisations ont été effectuées pour permettre l'utilisation de ce protocole sur du matériel autre que l'Ethernet 10Mbit. Certains réseaux de paquets radio (Packet Radio Networks) sont des exemples de ce type de matériel.
Le protocole décrit ici est le résultat de nombreuses discussions avec plusieurs autres personnes, notamment J. Noel Chiappa, Yogen Dalal et James E. Kulp, ainsi que des commentaires utiles de David Moon.
[Le but de ce 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, les adresses Ethernet). Il s'agit d'une question de préoccupation générale dans la communauté ARPA Internet à l'heure actuelle. La méthode proposée ici est présentée pour votre considération et vos commentaires. Il ne s'agit pas d'une spécification d'une norme Internet.]
Notes
Le protocole a été conçu à l'origine pour l'Ethernet DEC/Intel/Xerox 10Mbit. Il a été généralisé pour permettre son utilisation sur d'autres types de réseaux. Une grande partie de la discussion sera orientée vers l'Ethernet 10Mbit. Les généralisations, le cas échéant, suivront la discussion spécifique à l'Ethernet.
Le protocole Internet DOD (DOD Internet Protocol) sera simplifié et appelé Internet.
Les nombres ici sont dans la norme Ethernet, octet de poids fort en premier (High Byte First), ce qui est l'opposé de l'adressage des octets de machines telles que les PDP-11 et les VAX. Par conséquent, une attention particulière doit être accordée au champ opcode (ar$op) décrit ci-dessous.
Il existe une autorité de gestion des valeurs de l'espace de noms matériel (voir ci-dessous). Avant l'existence de cette autorité officielle, les demandes devaient être soumises à :
David C. Plummer
Symbolics, Inc.
243 Vassar Street
Cambridge, Massachusetts 02139
Ou, un courrier réseau peut être envoyé à <DCP@MIT-MC>.
Le problème (The Problem)
En général, le monde est une jungle, et le jeu des réseaux contribue avec de nombreux animaux. À presque chaque couche d'une architecture réseau, il existe plusieurs protocoles potentiellement utilisables. Par exemple, au niveau supérieur, il existe TELNET et SUPDUP pour la connexion à distance. En dessous se trouve un protocole de flux d'octets fiable (Reliable Byte Stream Protocol), qui pourrait être le protocole CHAOS, DOD TCP, Xerox BSP ou DECnet. Encore plus proche du matériel se trouve la couche de transport logique (Logical Transport Layer), qui pourrait être CHAOS, DOD Internet, Xerox PUP ou DECnet. L'Ethernet 10Mbit permet à tous ces protocoles (et plus encore) de coexister sur un seul câble au moyen d'un champ de type (Type Field) dans l'en-tête de paquet Ethernet. Cependant, l'Ethernet 10Mbit nécessite des adresses 48 bits sur le câble physique, mais la plupart des adresses de protocole ne font pas 48 bits de long et n'ont pas nécessairement de relation avec l'adresse Ethernet 48 bits du matériel. Par exemple, les adresses CHAOS sont de 16 bits, les adresses DOD Internet sont de 32 bits et les adresses Xerox PUP sont de 8 bits. Un protocole est nécessaire pour distribuer dynamiquement les correspondances entre une paire <protocole, adresse> et une adresse Ethernet 48 bits.
Motivation
À mesure que de plus en plus de fabricants fournissent des interfaces conformes aux spécifications publiées par DEC, Intel et Xerox, la disponibilité de l'Ethernet 10Mbit augmente. Avec cette disponibilité croissante, de plus en plus de logiciels sont écrits pour ces interfaces. Il y a deux alternatives : (1) chaque implémenteur invente sa propre méthode pour effectuer une certaine forme de résolution d'adresse, ou (2) chaque implémenteur utilise une norme afin que son code puisse être distribué à d'autres systèmes sans modification. Cette proposition tente d'établir la norme.
Définitions (Definitions)
Définissez ce qui suit pour faire référence aux valeurs placées dans le champ TYPE de l'en-tête de paquet Ethernet :
ether_type$XEROX_PUPether_type$DOD_INTERNETether_type$CHAOS
et une nouvelle valeur :
ether_type$ADDRESS_RESOLUTION
Définissez également les valeurs suivantes (à discuter plus tard) :
ares_op$REQUEST(= 1, octet de poids fort envoyé en premier)ares_op$REPLY(= 2)
et :
ares_hrd$Ethernet(= 1)
Format de paquet (Packet Format)
Pour communiquer les mappages des paires <protocole, adresse> vers des adresses Ethernet 48 bits, un format de paquet incarnant le protocole de résolution d'adresse (Address Resolution Protocol) est nécessaire. Le format est le suivant.
Couche de transmission Ethernet (pas nécessairement accessible à l'utilisateur) :
48 bits : Adresse Ethernet de destination
48 bits : Adresse Ethernet source
16 bits : Type de protocole = ether_type$ADDRESS_RESOLUTION
Données de paquet Ethernet :
16 bits : (ar$hrd) Espace d'adressage matériel (par exemple, Ethernet, réseau de paquets radio)
16 bits : (ar$pro) Espace d'adressage de protocole. Pour le matériel Ethernet, cela provient de l'ensemble de champs de type ether_typ$<protocol>
8 bits : (ar$hln) Longueur en octets de chaque adresse matérielle
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 matérielle de l'émetteur de ce paquet, n provient du champ ar$hln
m octets : (ar$spa) Adresse de protocole de l'émetteur de ce paquet, m provient du champ ar$pln
n octets : (ar$tha) Adresse matérielle de la cible de ce paquet (si connue)
m octets : (ar$tpa) Adresse de protocole de la cible
Génération de paquet (Packet Generation)
Lorsqu'un paquet est envoyé vers le bas à travers les couches réseau, le routage (Routing) détermine l'adresse de protocole du prochain saut pour le paquet et sur quel matériel il s'attend à trouver la station avec l'adresse de protocole cible immédiate. Dans le cas de l'Ethernet 10Mbit, la résolution d'adresse est nécessaire et une couche inférieure (probablement le pilote matériel) doit consulter le module de résolution d'adresse (Address Resolution Module) (probablement implémenté dans le module de support Ethernet) pour convertir la paire <type de protocole, adresse de protocole cible> en une adresse Ethernet 48 bits. Le module de résolution d'adresse tente de trouver cette paire dans une table. S'il trouve la paire, il renvoie l'adresse Ethernet 48 bits correspondante à l'appelant (pilote matériel) qui transmet ensuite le paquet. S'il ne la trouve pas, il informe probablement l'appelant qu'il jette 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 de type ether_type$ADDRESS_RESOLUTION. Le module de résolution d'adresse définit alors le champ ar$hrd sur ares_hrd$Ethernet, ar$pro sur le type de protocole en cours de résolution, ar$hln sur 6 (le nombre d'octets dans une adresse Ethernet 48 bits), ar$pln sur la longueur d'une adresse dans ce protocole, ar$op sur ares_op$REQUEST, ar$sha sur sa propre adresse Ethernet 48 bits, ar$spa sur sa propre adresse de protocole, et ar$tpa sur l'adresse de protocole de la machine qu'il tente d'accéder. Il ne définit pas ar$tha sur une valeur particulière, car c'est cette valeur qu'il tente de déterminer. Il peut définir ar$tha sur l'adresse de diffusion pour le matériel (tous des uns dans le cas de l'Ethernet 10Mbit) si cela est pratique pour certains aspects de l'implémentation. Il fait alors diffuser ce paquet à toutes les stations sur le câble Ethernet initialement déterminé par le mécanisme de routage.
Réception de paquet (Packet Reception)
Lorsqu'un paquet de résolution d'adresse est reçu, le module Ethernet récepteur transmet le paquet au module de résolution d'adresse qui exécute un algorithme similaire à ce qui suit. Les conditions négatives indiquent une fin de traitement et un rejet du paquet.
?Ai-je le type de matériel dans ar$hrd ?
Oui : (presque certainement)
[vérifier facultativement la longueur matérielle ar$hln]
?Est-ce que j'utilise le protocole dans ar$pro ?
Oui :
[vérifier facultativement la longueur du protocole ar$pln]
Merge_flag := false
Si la paire <type de protocole, adresse de protocole de l'émetteur> est
déjà dans ma table de traduction, mettre à jour le champ d'adresse matérielle
de l'émetteur de l'entrée avec les nouvelles informations dans le paquet
et définir Merge_flag sur true.
?Suis-je l'adresse de protocole cible ?
Oui :
Si Merge_flag est false, ajouter le triplet <type de protocole,
adresse de protocole de l'émetteur, adresse matérielle de l'émetteur> à
la table de traduction.
?L'opcode est-il ares_op$REQUEST ? (Maintenant regarder l'opcode !!)
Oui :
Échanger les champs matériel et protocole, en plaçant les adresses
matérielle et de protocole locales dans les champs émetteur.
Définir le champ ar$op sur ares_op$REPLY
Envoyer le paquet à la (nouvelle) adresse matérielle cible sur
le même matériel sur lequel la requête a été reçue.
Notez que le triplet <type de protocole, adresse de protocole de l'émetteur, adresse matérielle de l'émetteur> est fusionné dans la table avant que l'opcode ne soit examiné. Cela repose sur l'hypothèse que la communication est bidirectionnelle ; si A a une raison de parler à B, alors B aura probablement une raison de parler à A. Notez également que si une entrée existe déjà pour la paire <type de protocole, adresse de protocole de l'émetteur>, la nouvelle adresse matérielle remplace l'ancienne. Les questions connexes (Related Issues) donnent une certaine motivation pour cela.
Généralisation : Les champs ar$hrd et ar$hln permettent à ce protocole et à ce format de paquet d'être utilisés pour des Ethernets non 10Mbit. Pour l'Ethernet 10Mbit, <ar$hrd, ar$hln> prend la valeur <1, 6>. Pour d'autres réseaux matériels, le champ ar$pro peut ne plus correspondre au champ de type Ethernet, mais il devrait être associé au protocole dont la résolution d'adresse est recherchée.
Pourquoi est-ce fait de cette manière ? (Why is it done this way?)
La diffusion périodique n'est absolument pas souhaitable. Imaginez 100 postes de travail sur un seul Ethernet, chacun diffusant des informations de résolution d'adresse toutes les 10 minutes (comme un ensemble possible de paramètres). C'est un paquet toutes les 6 secondes. C'est presque raisonnable, mais à quoi cela sert-il ? Les postes de travail ne vont généralement pas se parler entre eux (et ont donc 100 entrées inutiles dans une table) ; ils parleront principalement à un ordinateur central, un serveur de fichiers ou un pont, mais seulement à un petit nombre d'autres postes de travail (par exemple, pour des conversations interactives). Le protocole décrit dans ce document distribue les informations au fur et à mesure des besoins, et seulement une fois (probablement) par démarrage d'une machine.
Ce format ne permet pas d'effectuer plusieurs résolutions dans le même paquet. C'est pour la simplicité. Si les choses étaient multiplexées, le format de paquet serait considérablement plus difficile à digérer, et une grande partie des informations pourrait être gratuite. Pensez à un pont qui parle quatre protocoles en disant à un poste de travail les quatre adresses de protocole, dont trois que le poste de travail n'utilisera probablement jamais.
Ce format permet de réutiliser le tampon de paquet si une réponse est générée ; une réponse a la même longueur qu'une requête, et plusieurs des champs sont identiques.
La valeur du champ matériel (ar$hrd) est tirée d'une liste à cet effet. Actuellement, la seule valeur définie est pour l'Ethernet 10Mbit (ares_hrd$Ethernet = 1). Il a été question d'utiliser ce protocole pour les réseaux de paquets radio (Packet Radio Networks) également, ce qui nécessiterait une autre valeur, tout comme d'autres supports matériels futurs qui souhaiteraient utiliser ce protocole.
Pour l'Ethernet 10Mbit, la valeur dans le champ de protocole (ar$pro) est tirée de l'ensemble ether_type$. Il s'agit d'une réutilisation naturelle des types de protocole attribués. La combinaison de cela avec l'opcode (ar$op) réduirait effectivement de moitié le nombre de protocoles qui peuvent être résolus sous ce protocole et rendrait un moniteur/débogueur plus complexe (voir Surveillance et débogage du réseau ci-dessous). On espère que nous ne verrons jamais 32768 protocoles, mais la loi de Murphy ne nous permet pas de faire une telle hypothèse.
Les champs de longueur (ar$hln et ar$pln) sont, en théorie, redondants, car la longueur d'une adresse de protocole devrait être déterminée par le type de matériel (trouvé dans ar$hrd) et le type de protocole (trouvé dans ar$pro). Ils sont inclus pour une vérification de cohérence facultative et pour la surveillance et le débogage du réseau (voir ci-dessous).
L'opcode est utilisé pour déterminer s'il s'agit d'une requête (qui peut provoquer une réponse) ou d'une réponse à une requête précédente. 16 bits pour cela sont excessifs, mais un indicateur (champ) est nécessaire.
L'adresse matérielle de l'émetteur et l'adresse de protocole de l'émetteur sont absolument nécessaires. Ce sont ces champs qui sont placés dans une table de traduction.
L'adresse de protocole cible est nécessaire dans la forme de requête du paquet afin qu'une machine puisse déterminer s'il faut entrer les informations de l'émetteur dans une table ou envoyer une réponse. Elle n'est pas nécessairement nécessaire dans la forme de réponse si l'on suppose qu'une réponse n'est provoquée que par une requête. Elle est incluse pour la complétude, la surveillance du réseau et pour simplifier l'algorithme de traitement suggéré décrit ci-dessus (qui ne regarde pas l'opcode jusqu'à APRÈS avoir placé les informations de l'émetteur dans une table).
L'adresse matérielle cible est incluse pour la complétude et la surveillance du réseau. Elle n'a pas de sens dans la forme de requête, car c'est ce numéro que la machine demande. Sa signification dans la forme de réponse est l'adresse de la machine qui fait la requête. Dans certaines implémentations (qui ont besoin de récupérer l'adresse matérielle cible), cela peut économiser un certain réarrangement de registre ou d'espace de pile en envoyant ce champ au pilote matériel comme adresse de destination matérielle du paquet.
Il n'y a pas d'octets de remplissage entre les adresses. Les données du paquet doivent être considérées comme un flux d'octets dans lequel seulement 3 paires d'octets sont définies comme des mots (ar$hrd, ar$pro et ar$op) qui sont envoyés octet le plus significatif en premier (style d'octet Ethernet/PDP-10).
Surveillance et débogage du réseau (Network Monitoring and Debugging)
Le protocole de résolution d'adresse ci-dessus permet à une machine d'acquérir des connaissances sur 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 valeur) et les adresses de protocole dans chaque type de protocole. En fait, il n'est pas nécessaire que le moniteur parle l'un des protocoles de niveau supérieur impliqués. Cela peut être fait comme suit :
Lorsqu'un moniteur reçoit un paquet de résolution d'adresse, il entre toujours le <type de protocole, adresse de protocole de l'émetteur, adresse matérielle de l'émetteur> dans une table. Il peut déterminer la longueur de l'adresse matérielle et de l'adresse de protocole à partir des champs ar$hln et ar$pln du paquet. Si l'opcode est REPLY, le moniteur peut jeter le paquet. Si l'opcode est REQUEST et que l'adresse de protocole cible correspond à l'adresse de protocole du moniteur, le moniteur envoie une REPLY comme il le ferait normalement. Le moniteur n'obtiendra qu'un seul mappage de cette manière, car la REPLY à la REQUEST sera envoyée directement à l'hôte demandeur. Le moniteur pourrait essayer d'envoyer sa propre REQUEST, mais cela pourrait mettre deux moniteurs dans une boucle d'envoi de REQUEST, et des précautions doivent être prises.
Parce que le protocole et l'opcode ne sont pas combinés en un seul champ, le moniteur n'a pas besoin de savoir quel opcode de requête est associé à quel opcode de réponse pour le même protocole de niveau supérieur. Les champs de longueur devraient également fournir suffisamment d'informations pour lui permettre d'« analyser » les adresses de protocole, bien qu'il n'ait aucune connaissance de ce que signifient les adresses de protocole.
Une implémentation fonctionnelle du protocole de résolution d'adresse peut également être utilisée pour déboguer une implémentation non fonctionnelle. Probablement, un pilote matériel diffusera avec succès un paquet avec un champ de type Ethernet de ether_type$ADDRESS_RESOLUTION. Le format du paquet peut ne pas être totalement correct, car les implémentations initiales peuvent avoir des bogues, et la gestion des tables peut être un peu délicate. Étant donné que les requêtes sont diffusées, un moniteur recevra le paquet et pourra l'afficher pour le débogage si nécessaire.
Un exemple (An Example)
Supposons qu'il existe des machines X et Y qui se trouvent sur le même câble Ethernet 10Mbit. Elles ont des adresses Ethernet EA(X) et EA(Y), et des adresses DOD Internet IPA(X) et IPA(Y). Soit le type Ethernet d'Internet ET(IP). La machine X vient de démarrer et, tôt ou tard, souhaite envoyer un paquet Internet à la machine Y sur le même câble. X sait qu'il veut envoyer à IPA(Y) et indique au pilote matériel (ici un pilote Ethernet) IPA(Y). 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 de démarrer, il n'a pas cette information. Il jette le paquet Internet et crée à la place un paquet ADDRESS RESOLUTION :
(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) = peu importe
(ar$tpa) = IPA(Y)
et diffuse ce paquet à tout le monde sur le câble.
La machine Y obtient 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 (probablement en remplaçant toute entrée existante) l'information que <ET(IP), IPA(X)> correspond à EA(X). Elle remarque ensuite que c'est une requête, alors elle échange les champs, met EA(Y) dans le nouveau champ d'adresse Ethernet de l'émetteur (ar$sha), définit l'opcode sur reply, et envoie le paquet directement (pas en diffusion) à EA(X). À ce stade, Y sait comment envoyer à X, mais X ne sait toujours pas comment envoyer à Y.
La machine X obtient le paquet de réponse de Y, forme le mappage de <ET(IP), IPA(Y)> à EA(Y), remarque que le paquet est une réponse et le jette. La prochaine fois que le module Internet de X tente d'envoyer un paquet à Y sur l'Ethernet, la traduction réussira et le paquet arrivera (espérons-le). Si le module Internet de Y veut alors parler à X, cela réussira également puisque Y a déjà mémorisé les informations de la requête de résolution d'adresse de X.
Question connexe (Related Issue)
Il peut être souhaitable d'avoir un vieillissement et/ou des délais d'expiration de table. L'implémentation de ceux-ci est hors du cadre de ce protocole. Voici une description plus détaillée (merci à MOON@SCRC@MIT-MC).
Si un hôte se déplace, toutes les connexions initiées par cet hôte fonctionneront, en supposant que sa propre table de résolution d'adresse soit effacée lorsqu'il se déplace. Cependant, les connexions initiées vers lui par d'autres hôtes n'auront aucune raison particulière de savoir qu'il faut rejeter l'ancienne adresse. Cependant, les adresses Ethernet 48 bits sont censées être uniques et fixées pour toujours, donc elles ne devraient pas changer. Un hôte peut « se déplacer » si son nom d'hôte (et son adresse dans un autre protocole) est réaffecté à un matériel physique différent. De plus, comme nous le savons par expérience, il existe toujours le danger que des informations de routage incorrectes soient accidentellement transmises par erreur matérielle ou logicielle ; cela ne devrait pas être autorisé à persister indéfiniment. Peut-être que l'échec de l'établissement 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, peut-être parce qu'il est en panne ou que l'ancienne traduction n'est plus valide. Ou peut-être que la réception d'un paquet d'un hôte devrait réinitialiser le délai d'expiration 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 appropriée, l'entrée de résolution d'adresse est oubliée. Cela peut causer une surcharge supplémentaire pour scanner la table pour chaque paquet entrant. Peut-être que l'utilisation d'un hachage ou d'un index peut rendre cela plus rapide.
L'algorithme suggéré pour la réception de paquets de résolution d'adresse tente de réduire le temps nécessaire à la récupération si un hôte se déplace effectivement. Rappelez-vous que si la paire <type de protocole, adresse de protocole de l'émetteur> est déjà dans la table de traduction, la nouvelle adresse matérielle remplace l'entrée existante. Par conséquent, sur un Ethernet parfait où une REQUEST de diffusion atteint toutes les stations sur le câble, chaque station obtiendra la nouvelle adresse matérielle.
Une alternative serait d'avoir un démon effectuer les délais d'expiration. Après un temps approprié, le démon envisage de supprimer 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 REQUEST directement à l'adresse Ethernet dans la table. Si une REPLY n'est pas vue dans un court laps de temps, l'entrée est supprimée. La requête est envoyée directement afin de ne pas déranger chaque station sur l'Ethernet. Oublier simplement les entrées entraînera probablement l'oubli d'informations utiles, qui doivent être regagnées.
Étant donné que les hôtes ne transmettent pas d'informations sur quelqu'un d'autre qu'eux-mêmes, le redémarrage d'un hôte fera en sorte que sa table de mappage d'adresses soit à jour. Les mauvaises informations ne peuvent pas persister indéfiniment en étant transmises 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 que la réinitialisation manuelle (ou l'effacement) de la table de mappage d'adresses suffira.
Si l'on pense que ce problème est important, il est important que le démon expire et pose à nouveau la question au lieu de simplement supprimer l'entrée. Le démon pourrait également faire un meilleur travail de retransmissions que ce protocole, car une machine cible qui est physiquement connectée mais inaccessible (par exemple, en raison d'une défaillance logicielle) ne devrait pas avoir à répondre à la requête. Ce protocole sera utilisé pour déterminer l'adresse Ethernet de la passerelle du prochain saut, et cette passerelle ne devrait pas avoir à répondre à tous les paquets de résolution d'adresse sur l'Ethernet. Ce n'est pas un problème significatif, car le démon pourrait utiliser le protocole de résolution d'adresse pour poser la question, plutôt que de faire utiliser son propre protocole par le module de résolution d'adresse.
Ressources connexes
- RFC officiel:
https://www.rfc-editor.org/rfc/rfc826.txt - Page officielle:
https://datatracker.ietf.org/doc/html/rfc826