RFC 826 - Ethernet-Adressauflösungsprotokoll

An Ethernet Address Resolution Protocol

Untertitel: Konvertierung von Netzwerkprotokoll-Adressen in 48-Bit-Ethernet-Adressen für die Übertragung auf Ethernet-Hardware

Autor: David C. Plummer (DCP@MIT-MC)
Veröffentlichungsdatum: November 1982
Status: Standardprotokoll (Standard)

Zusammenfassung (Abstract)

Die Implementierung des Protokolls P auf dem sendenden Host S entscheidet durch den Routing-Mechanismus des Protokolls P, dass es an einen Zielhost T übertragen möchte, der irgendwo auf einem verbundenen 10Mbit-Ethernet-Kabel liegt. Um das Ethernet-Paket (Ethernet Packet) tatsächlich zu übertragen, muss eine 48-Bit-Ethernet-Adresse (Ethernet Address) generiert werden. Die Adressen der Hosts innerhalb des Protokolls P sind nicht immer mit der entsprechenden Ethernet-Adresse kompatibel (unterschiedliche Längen oder Werte). Das hier vorgestellte Protokoll ermöglicht die dynamische Verteilung der Informationen, die zum Aufbau von Tabellen benötigt werden, um eine Adresse A im Adressraum des Protokolls P in eine 48-Bit-Ethernet-Adresse zu übersetzen.

Es wurden Verallgemeinerungen vorgenommen, die es ermöglichen, das Protokoll auf anderer Hardware als 10Mbit-Ethernet zu verwenden. Einige Paketfunknetzwerke (Packet Radio Networks) sind Beispiele für solche Hardware.

Das hier beschriebene Protokoll war das Ergebnis umfangreicher Diskussionen mit mehreren anderen Personen, insbesondere J. Noel Chiappa, Yogen Dalal und James E. Kulp, sowie hilfreichen Kommentaren von David Moon.

[Der Zweck dieses RFC ist es, eine Methode zur Konvertierung von Protokolladressen (z.B. IP-Adressen) in lokale Netzwerkadressen (z.B. Ethernet-Adressen) vorzustellen. Dies ist derzeit ein Thema von allgemeinem Interesse in der ARPA-Internet-Community. Die hier vorgeschlagene Methode wird zu Ihrer Überlegung und Kommentierung vorgelegt. Dies ist keine Spezifikation eines Internet-Standards.]

Hinweise (Notes)

Das Protokoll wurde ursprünglich für das DEC/Intel/Xerox 10Mbit-Ethernet entwickelt. Es wurde verallgemeinert, um die Verwendung für andere Netzwerktypen zu ermöglichen. Ein Großteil der Diskussion wird sich auf das 10Mbit-Ethernet konzentrieren. Verallgemeinerungen werden, wo zutreffend, der Ethernet-spezifischen Diskussion folgen.

Das DOD Internet Protocol wird vereinfacht als Internet bezeichnet.

Die Zahlen hier folgen dem Ethernet-Standard, Höherwertiges Byte zuerst (High Byte First), was das Gegenteil der Byte-Adressierung von Maschinen wie PDP-11s und VAXen ist. Daher muss dem unten beschriebenen Opcode-Feld (ar$op) besondere Aufmerksamkeit geschenkt werden.

Es existiert eine Autorität zur Verwaltung der Hardware-Namensraumwerte (siehe unten). Bevor diese offizielle Autorität existierte, sollten Anfragen eingereicht werden an:

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

Oder Netzwerk-Mail kann an <DCP@MIT-MC> gesendet werden.

Das Problem (The Problem)

Insgesamt ist die Welt ein Dschungel, und das Netzwerk-Spiel trägt viele Tiere bei. Auf nahezu jeder Schicht einer Netzwerkarchitektur gibt es mehrere potenzielle Protokolle, die verwendet werden könnten. Auf hoher Ebene gibt es beispielsweise TELNET und SUPDUP für Remote-Login. Darunter befindet sich ein zuverlässiges Byte-Stream-Protokoll (Reliable Byte Stream Protocol), das das CHAOS-Protokoll, DOD TCP, Xerox BSP oder DECnet sein könnte. Noch näher an der Hardware liegt die logische Transportschicht (Logical Transport Layer), die CHAOS, DOD Internet, Xerox PUP oder DECnet sein könnte. Das 10Mbit-Ethernet ermöglicht es allen diesen Protokollen (und mehr), auf einem einzigen Kabel durch ein Typfeld (Type Field) im Ethernet-Paket-Header zu koexistieren. Das 10Mbit-Ethernet benötigt jedoch 48-Bit-Adressen auf dem physischen Kabel, aber die meisten Protokolladressen sind nicht 48 Bit lang und haben nicht notwendigerweise eine Beziehung zur 48-Bit-Ethernet-Adresse der Hardware. Zum Beispiel sind CHAOS-Adressen 16 Bit, DOD Internet-Adressen sind 32 Bit und Xerox PUP-Adressen sind 8 Bit. Ein Protokoll wird benötigt, um die Entsprechungen zwischen einem <Protokoll, Adresse>-Paar und einer 48-Bit-Ethernet-Adresse dynamisch zu verteilen.

Motivation

Da immer mehr Hersteller Schnittstellen anbieten, die der von DEC, Intel und Xerox veröffentlichten Spezifikation entsprechen, nimmt die Verfügbarkeit von 10Mbit-Ethernet zu. Mit dieser zunehmenden Verfügbarkeit wird immer mehr Software für diese Schnittstellen geschrieben. Es gibt zwei Alternativen: (1) Jeder Implementierer erfindet seine eigene Methode zur Durchführung einer Form der Adressauflösung, oder (2) jeder Implementierer verwendet einen Standard, damit sein Code ohne Modifikation auf andere Systeme verteilt werden kann. Dieser Vorschlag versucht, den Standard zu setzen.

Definitionen (Definitions)

Definieren Sie das Folgende, um auf die Werte zu verweisen, die in das TYPE-Feld des Ethernet-Paket-Headers eingefügt werden:

ether_type$XEROX_PUP
ether_type$DOD_INTERNET
ether_type$CHAOS

und einen neuen Wert:

ether_type$ADDRESS_RESOLUTION

Definieren Sie auch die folgenden Werte (später zu diskutieren):

ares_op$REQUEST (= 1, höherwertiges Byte wird zuerst gesendet)
ares_op$REPLY (= 2)

und:

ares_hrd$Ethernet (= 1)

Paketformat (Packet Format)

Um Zuordnungen von <Protokoll, Adresse>-Paaren zu 48-Bit-Ethernet-Adressen zu kommunizieren, wird ein Paketformat benötigt, das das Adressauflösungsprotokoll (Address Resolution Protocol) verkörpert. Das Format ist wie folgt.

Ethernet-Übertragungsschicht (nicht unbedingt für den Benutzer zugänglich):

Bit: Ethernet-Zieladresse
Bit: Ethernet-Quelladresse
Bit: Protokolltyp = ether_type$ADDRESS_RESOLUTION

Ethernet-Paketdaten:

16 Bit: (ar$hrd) Hardware-Adressraum (z.B. Ethernet, Paketfunknetz)
16 Bit: (ar$pro) Protokoll-Adressraum. Für Ethernet-Hardware stammt dies aus dem Typfeld-Set ether_typ$<protocol>
 8 Bit: (ar$hln) Byte-Länge jeder Hardware-Adresse
 8 Bit: (ar$pln) Byte-Länge jeder Protokolladresse
16 Bit: (ar$op)  Opcode (ares_op$REQUEST | ares_op$REPLY)
n Bytes: (ar$sha) Hardware-Adresse des Absenders dieses Pakets, n aus ar$hln-Feld
m Bytes: (ar$spa) Protokolladresse des Absenders dieses Pakets, m aus ar$pln-Feld
n Bytes: (ar$tha) Hardware-Adresse des Ziels dieses Pakets (falls bekannt)
m Bytes: (ar$tpa) Protokolladresse des Ziels

Paketerzeugung (Packet Generation)

Wenn ein Paket durch die Netzwerkschichten nach unten gesendet wird, bestimmt das Routing (Routing) die Protokolladresse des nächsten Hops für das Paket und auf welcher Hardware es die Station mit der unmittelbaren Ziel-Protokolladresse zu finden erwartet. Im Fall des 10Mbit-Ethernet ist eine Adressauflösung erforderlich, und eine niedrigere Schicht (wahrscheinlich der Hardware-Treiber) muss das Adressauflösungsmodul (Address Resolution Module) (wahrscheinlich im Ethernet-Unterstützungsmodul implementiert) konsultieren, um das <Protokolltyp, Ziel-Protokolladresse>-Paar in eine 48-Bit-Ethernet-Adresse zu konvertieren. Das Adressauflösungsmodul versucht, dieses Paar in einer Tabelle zu finden. Wenn es das Paar findet, gibt es die entsprechende 48-Bit-Ethernet-Adresse an den Aufrufer (Hardware-Treiber) zurück, der dann das Paket überträgt. Wenn es nicht gefunden wird, informiert es wahrscheinlich den Aufrufer, dass es das Paket verwirft (unter der Annahme, dass das Paket von einer höheren Netzwerkschicht erneut übertragen wird), und erzeugt ein Ethernet-Paket mit einem Typfeld von ether_type$ADDRESS_RESOLUTION. Das Adressauflösungsmodul setzt dann das ar$hrd-Feld auf ares_hrd$Ethernet, ar$pro auf den Protokolltyp, der aufgelöst wird, ar$hln auf 6 (die Anzahl der Bytes in einer 48-Bit-Ethernet-Adresse), ar$pln auf die Länge einer Adresse in diesem Protokoll, ar$op auf ares_op$REQUEST, ar$sha auf seine eigene 48-Bit-Ethernet-Adresse, ar$spa auf seine eigene Protokolladresse und ar$tpa auf die Protokolladresse der Maschine, auf die zugegriffen werden soll. Es setzt ar$tha nicht auf einen bestimmten Wert, da dies der Wert ist, den es zu bestimmen versucht. Es kann ar$tha auf die Broadcast-Adresse für die Hardware (alle Einsen im Fall des 10Mbit-Ethernet) setzen, wenn dies für einige Aspekte der Implementierung bequem ist. Es veranlasst dann, dass dieses Paket an alle Stationen auf dem Ethernet-Kabel gesendet wird, das ursprünglich durch den Routing-Mechanismus bestimmt wurde.

Paketempfang (Packet Reception)

Wenn ein Adressauflösungspaket empfangen wird, übergibt das empfangende Ethernet-Modul das Paket an das Adressauflösungsmodul, das einen Algorithmus ähnlich dem folgenden durchläuft. Negative Bedingungen zeigen ein Ende der Verarbeitung und ein Verwerfen des Pakets an.

?Habe ich den Hardware-Typ in ar$hrd?
Ja: (fast sicher)
  [optional Hardware-Länge ar$hln prüfen]
  ?Spreche ich das Protokoll in ar$pro?
  Ja:
    [optional Protokolllänge ar$pln prüfen]
    Merge_flag := false
    Wenn das Paar <Protokolltyp, Absender-Protokolladresse>
        bereits in meiner Übersetzungstabelle vorhanden ist,
        aktualisiere das Absender-Hardware-Adressfeld des Eintrags mit den
        neuen Informationen im Paket und setze Merge_flag auf true.
    ?Bin ich die Ziel-Protokolladresse?
    Ja:
      Wenn Merge_flag false ist, füge das Tripel <Protokolltyp,
          Absender-Protokolladresse, Absender-Hardware-Adresse> zur
          Übersetzungstabelle hinzu.
      ?Ist der Opcode ares_op$REQUEST? (JETZT den Opcode ansehen!!)
      Ja:
        Tausche Hardware- und Protokollfelder aus und setze die lokale
            Hardware- und Protokolladresse in die Absenderfelder.
        Setze das ar$op-Feld auf ares_op$REPLY
        Sende das Paket an die (neue) Ziel-Hardware-Adresse auf
            derselben Hardware, auf der die Anfrage empfangen wurde.

Beachten Sie, dass das Tripel <Protokolltyp, Absender-Protokolladresse, Absender-Hardware-Adresse> in die Tabelle eingefügt wird, bevor der Opcode betrachtet wird. Dies basiert auf der Annahme, dass die Kommunikation bidirektional ist; wenn A einen Grund hat, mit B zu sprechen, wird B wahrscheinlich einen Grund haben, mit A zu sprechen. Beachten Sie auch, dass wenn ein Eintrag für das <Protokolltyp, Absender-Protokolladresse>-Paar bereits existiert, die neue Hardware-Adresse die alte ersetzt. Verwandte Probleme (Related Issues) geben eine gewisse Motivation hierfür.

Verallgemeinerung: Die ar$hrd- und ar$hln-Felder ermöglichen es diesem Protokoll und Paketformat, für Nicht-10Mbit-Ethernets verwendet zu werden. Für das 10Mbit-Ethernet nimmt <ar$hrd, ar$hln> den Wert <1, 6> an. Für andere Hardware-Netzwerke entspricht das ar$pro-Feld möglicherweise nicht mehr dem Ethernet-Typfeld, sollte aber mit dem Protokoll assoziiert sein, dessen Adressauflösung gesucht wird.

Warum wird es so gemacht? (Why is it done this way?)

Periodisches Broadcasting ist definitiv nicht erwünscht. Stellen Sie sich 100 Workstations auf einem einzigen Ethernet vor, die jeweils alle 10 Minuten Adressauflösungsinformationen broadcasten (als ein möglicher Satz von Parametern). Das ist ein Paket alle 6 Sekunden. Das ist fast vernünftig, aber wozu dient es? Die Workstations werden im Allgemeinen nicht miteinander sprechen (und haben daher 100 nutzlose Einträge in einer Tabelle); sie werden hauptsächlich mit einem Mainframe, Dateiserver oder einer Bridge sprechen, aber nur mit einer kleinen Anzahl anderer Workstations (z.B. für interaktive Gespräche). Das in diesem Dokument beschriebene Protokoll verteilt Informationen nach Bedarf und nur einmal (wahrscheinlich) pro Systemstart einer Maschine.

Dieses Format erlaubt nicht mehr als eine Auflösung im selben Paket. Dies dient der Einfachheit. Wenn Dinge gemultiplext würden, wäre das Paketformat erheblich schwieriger zu verdauen, und vieles der Informationen könnte überflüssig sein. Denken Sie an eine Bridge, die vier Protokolle spricht und einer Workstation alle vier Protokolladressen mitteilt, von denen die Workstation wahrscheinlich drei nie verwenden wird.

Dieses Format ermöglicht die Wiederverwendung des Paketpuffers, wenn eine Antwort generiert wird; eine Antwort hat dieselbe Länge wie eine Anfrage, und mehrere der Felder sind dieselben.

Der Wert des Hardware-Felds (ar$hrd) wird aus einer Liste für diesen Zweck entnommen. Derzeit ist der einzige definierte Wert für das 10Mbit-Ethernet (ares_hrd$Ethernet = 1). Es wurde darüber gesprochen, dieses Protokoll auch für Paketfunknetzwerke (Packet Radio Networks) zu verwenden, was einen anderen Wert erfordern würde, ebenso wie andere zukünftige Hardware-Medien, die dieses Protokoll verwenden möchten.

Für das 10Mbit-Ethernet wird der Wert im Protokollfeld (ar$pro) aus dem Set ether_type$ entnommen. Dies ist eine natürliche Wiederverwendung der zugewiesenen Protokolltypen. Die Kombination davon mit dem Opcode (ar$op) würde die Anzahl der Protokolle, die unter diesem Protokoll aufgelöst werden können, effektiv halbieren und würde einen Monitor/Debugger komplexer machen (siehe Netzwerküberwachung und Debugging unten). Es wird gehofft, dass wir niemals 32768 Protokolle sehen werden, aber Murphys Gesetz erlaubt es uns nicht, eine solche Annahme zu treffen.

Die Längenfelder (ar$hln und ar$pln) sind theoretisch redundant, da die Länge einer Protokolladresse durch den Hardware-Typ (in ar$hrd gefunden) und den Protokolltyp (in ar$pro gefunden) bestimmt werden sollte. Sie sind für optionale Konsistenzprüfungen und für Netzwerküberwachung und Debugging enthalten (siehe unten).

Der Opcode wird verwendet, um zu bestimmen, ob dies eine Anfrage ist (die eine Antwort verursachen kann) oder eine Antwort auf eine vorherige Anfrage. 16 Bit hierfür sind übertrieben, aber ein Flag (Feld) wird benötigt.

Die Absender-Hardware-Adresse und die Absender-Protokolladresse sind absolut notwendig. Es sind diese Felder, die in eine Übersetzungstabelle eingefügt werden.

Die Ziel-Protokolladresse ist in der Anforderungsform des Pakets notwendig, damit eine Maschine bestimmen kann, ob die Absenderinformationen in eine Tabelle eingetragen oder eine Antwort gesendet werden soll. Sie ist in der Antwortform nicht unbedingt erforderlich, wenn man annimmt, dass eine Antwort nur durch eine Anfrage ausgelöst wird. Sie ist aus Gründen der Vollständigkeit, der Netzwerküberwachung und zur Vereinfachung des oben beschriebenen vorgeschlagenen Verarbeitungsalgorithmus enthalten (der den Opcode erst NACH dem Einfügen der Absenderinformationen in eine Tabelle betrachtet).

Die Ziel-Hardware-Adresse ist aus Gründen der Vollständigkeit und der Netzwerküberwachung enthalten. Sie hat in der Anforderungsform keine Bedeutung, da dies die Nummer ist, die die Maschine anfordert. Ihre Bedeutung in der Antwortform ist die Adresse der Maschine, die die Anfrage stellt. In einigen Implementierungen (die die Ziel-Hardware-Adresse zurückerhalten müssen) kann dies durch Senden dieses Felds an den Hardware-Treiber als Hardware-Zieladresse des Pakets einige Register-Umgruppierungen oder Stack-Speicher sparen.

Es gibt keine Füllbytes zwischen Adressen. Die Paketdaten sollten als Byte-Stream betrachtet werden, in dem nur 3 Byte-Paare als Wörter definiert sind (ar$hrd, ar$pro und ar$op), die höchstwertiges Byte zuerst gesendet werden (Ethernet/PDP-10-Byte-Stil).

Netzwerküberwachung und Debugging (Network Monitoring and Debugging)

Das obige Adressauflösungsprotokoll ermöglicht es einer Maschine, Wissen über die höherstufige Protokollaktivität (z.B. CHAOS, Internet, PUP, DECnet) auf einem Ethernet-Kabel zu erlangen. Es kann bestimmen, welche Ethernet-Protokoll-Typfelder verwendet werden (nach Wert) und die Protokolladressen innerhalb jedes Protokolltyps. Tatsächlich ist es nicht notwendig, dass der Monitor eines der beteiligten höherstufigen Protokolle spricht. Es kann wie folgt durchgeführt werden:

Wenn ein Monitor ein Adressauflösungspaket empfängt, trägt er immer das <Protokolltyp, Absender-Protokolladresse, Absender-Hardware-Adresse> in eine Tabelle ein. Er kann die Länge der Hardware- und Protokolladresse aus den ar$hln- und ar$pln-Feldern des Pakets bestimmen. Wenn der Opcode REPLY ist, kann der Monitor das Paket verwerfen. Wenn der Opcode REQUEST ist und die Ziel-Protokolladresse mit der Protokolladresse des Monitors übereinstimmt, sendet der Monitor eine REPLY wie gewöhnlich. Der Monitor erhält nur eine Zuordnung auf diese Weise, da die REPLY auf die REQUEST direkt an den anfordernden Host gesendet wird. Der Monitor könnte versuchen, seine eigene REQUEST zu senden, aber dies könnte zwei Monitore in eine REQUEST-Sendeschleife bringen, und Vorsicht muss walten.

Da das Protokoll und der Opcode nicht in einem Feld kombiniert sind, muss der Monitor nicht wissen, welcher Request-Opcode mit welchem Reply-Opcode für dasselbe höherstufige Protokoll übereinstimmt. Die Längenfelder sollten auch genügend Informationen liefern, um ihm zu ermöglichen, Protokolladressen zu „parsen", obwohl er keine Kenntnis davon hat, was die Protokolladressen bedeuten.

Eine funktionierende Implementierung des Adressauflösungsprotokolls kann auch verwendet werden, um eine nicht funktionierende Implementierung zu debuggen. Wahrscheinlich wird ein Hardware-Treiber erfolgreich ein Paket mit einem Ethernet-Typfeld von ether_type$ADDRESS_RESOLUTION broadcasten. Das Format des Pakets ist möglicherweise nicht vollständig korrekt, da anfängliche Implementierungen Fehler haben können und die Tabellenverwaltung etwas knifflig sein kann. Da Anfragen gebroadcastet werden, empfängt ein Monitor das Paket und kann es bei Bedarf zum Debugging anzeigen.

Ein Beispiel (An Example)

Angenommen, es gibt Maschinen X und Y, die sich auf demselben 10Mbit-Ethernet-Kabel befinden. Sie haben Ethernet-Adressen EA(X) und EA(Y) sowie DOD Internet-Adressen IPA(X) und IPA(Y). Sei der Ethernet-Typ von Internet ET(IP). Maschine X wurde gerade gestartet und möchte früher oder später ein Internet-Paket an Maschine Y auf demselben Kabel senden. X weiß, dass es an IPA(Y) senden möchte, und teilt dem Hardware-Treiber (hier ein Ethernet-Treiber) IPA(Y) mit. Der Treiber konsultiert das Adressauflösungsmodul, um <ET(IP), IPA(Y)> in eine 48-Bit-Ethernet-Adresse zu konvertieren, aber da X gerade gestartet wurde, hat es diese Information nicht. Es verwirft das Internet-Paket und erstellt stattdessen ein ADDRESS RESOLUTION-Paket:

(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) = egal
(ar$tpa) = IPA(Y)

und broadcastet dieses Paket an alle auf dem Kabel.

Maschine Y erhält dieses Paket und bestimmt, dass sie den Hardware-Typ (Ethernet) versteht, dass sie das angegebene Protokoll (Internet) spricht und dass das Paket für sie ist ((ar$tpa)=IPA(Y)). Sie trägt (wahrscheinlich unter Ersetzung eines vorhandenen Eintrags) die Information ein, dass <ET(IP), IPA(X)> auf EA(X) abgebildet wird. Sie bemerkt dann, dass es eine Anfrage ist, also tauscht sie Felder aus, setzt EA(Y) in das neue Absender-Ethernet-Adressfeld (ar$sha), setzt den Opcode auf reply und sendet das Paket direkt (nicht broadcast) an EA(X). An diesem Punkt weiß Y, wie man an X sendet, aber X weiß immer noch nicht, wie man an Y sendet.

Maschine X erhält das Antwortpaket von Y, bildet die Zuordnung von <ET(IP), IPA(Y)> zu EA(Y), bemerkt, dass das Paket eine Antwort ist, und verwirft es. Wenn X's Internet-Modul das nächste Mal versucht, ein Paket an Y auf dem Ethernet zu senden, wird die Übersetzung erfolgreich sein und das Paket wird (hoffentlich) ankommen. Wenn Y's Internet-Modul dann mit X kommunizieren möchte, wird dies ebenfalls erfolgreich sein, da Y sich bereits die Informationen aus X's Adressauflösungsanfrage gemerkt hat.

Es kann wünschenswert sein, Tabellen-Aging und/oder Timeouts zu haben. Die Implementierung davon liegt außerhalb des Umfangs dieses Protokolls. Hier ist eine detailliertere Beschreibung (Dank an MOON@SCRC@MIT-MC).

Wenn ein Host sich bewegt, werden alle von diesem Host initiierten Verbindungen funktionieren, vorausgesetzt, seine eigene Adressauflösungstabelle wird gelöscht, wenn er sich bewegt. Allerdings haben von anderen Hosts zu ihm initiierte Verbindungen keinen besonderen Grund zu wissen, dass die alte Adresse verworfen werden sollte. Jedoch sollen 48-Bit-Ethernet-Adressen eindeutig und für alle Zeit fest sein, also sollten sie sich nicht ändern. Ein Host kann sich „bewegen", wenn sein Hostname (und seine Adresse in einem anderen Protokoll) einer anderen physischen Hardware neu zugewiesen wird. Außerdem, wie wir aus Erfahrung wissen, besteht immer die Gefahr, dass falsche Routing-Informationen versehentlich durch Hardware- oder Software-Fehler übertragen werden; dies sollte nicht dauerhaft erlaubt werden. Vielleicht sollte das Scheitern beim Initiieren einer Verbindung das Adressauflösungsmodul informieren, die Informationen zu löschen, mit der Begründung, dass der Host nicht erreichbar ist, möglicherweise weil er ausgefallen ist oder die alte Übersetzung nicht mehr gültig ist. Oder vielleicht sollte der Empfang eines Pakets von einem Host den Timeout im Adressauflösungseintrag zurücksetzen, der zum Übertragen von Paketen an diesen Host verwendet wird; wenn für eine geeignete Zeitdauer keine Pakete von einem Host empfangen werden, wird der Adressauflösungseintrag vergessen. Dies kann zusätzlichen Overhead verursachen, um die Tabelle für jedes eingehende Paket zu scannen. Vielleicht kann die Verwendung eines Hash oder Index dies schneller machen.

Der vorgeschlagene Algorithmus zum Empfang von Adressauflösungspaketen versucht, die Zeit zu verkürzen, die für die Wiederherstellung benötigt wird, wenn ein Host sich tatsächlich bewegt. Erinnern Sie sich daran, dass wenn das <Protokolltyp, Absender-Protokolladresse>-Paar bereits in der Übersetzungstabelle vorhanden ist, die neue Hardware-Adresse den vorhandenen Eintrag ersetzt. Daher erhält auf einem perfekten Ethernet, wo ein Broadcast-REQUEST alle Stationen auf dem Kabel erreicht, jede Station die neue Hardware-Adresse.

Eine Alternative wäre, einen Daemon die Timeouts durchführen zu lassen. Nach einer angemessenen Zeit erwägt der Daemon, einen Eintrag zu entfernen. Er sendet zuerst (mit einer kleinen Anzahl von Neuübertragungen bei Bedarf) ein Adressauflösungspaket mit Opcode REQUEST direkt an die Ethernet-Adresse in der Tabelle. Wenn eine REPLY nicht in kurzer Zeit gesehen wird, wird der Eintrag gelöscht. Die Anfrage wird direkt gesendet, um nicht jede Station auf dem Ethernet zu stören. Einfach Einträge zu vergessen wird wahrscheinlich dazu führen, dass nützliche Informationen vergessen werden, die neu gewonnen werden müssen.

Da Hosts keine Informationen über jemand anderen als sich selbst übertragen, führt ein Neustart eines Hosts dazu, dass seine Adresszuordnungstabelle aktuell ist. Schlechte Informationen können nicht dauerhaft bestehen bleiben, indem sie von Maschine zu Maschine weitergegeben werden; die einzigen schlechten Informationen, die existieren können, befinden sich in einer Maschine, die nicht weiß, dass eine andere Maschine ihre 48-Bit-Ethernet-Adresse geändert hat. Vielleicht reicht das manuelle Zurücksetzen (oder Löschen) der Adresszuordnungstabelle aus.

Wenn man glaubt, dass dieses Problem wichtig ist, ist es wichtig, dass der Daemon einen Timeout durchführt und die Frage erneut stellt, anstatt einfach den Eintrag zu entfernen. Der Daemon könnte auch bessere Arbeit bei Neuübertragungen leisten als dieses Protokoll, da eine Zielmaschine, die physisch verbunden, aber nicht erreichbar ist (z.B. aufgrund eines Software-Fehlers), nicht auf die Anfrage antworten sollte. Dieses Protokoll wird verwendet, um die Ethernet-Adresse des nächsten Hop-Gateways zu bestimmen, und dieses Gateway sollte nicht auf alle Adressauflösungspakete auf dem Ethernet antworten müssen. Dies ist kein wesentliches Problem, da der Daemon das Adressauflösungsprotokoll verwenden könnte, um die Frage zu stellen, anstatt das Adressauflösungsmodul sein eigenes Protokoll verwenden zu lassen.

An Ethernet Address Resolution Protocol​

Zusammenfassung (Abstract)​

Hinweise (Notes)​

Das Problem (The Problem)​

Motivation​

Definitionen (Definitions)​

Paketformat (Packet Format)​

Paketerzeugung (Packet Generation)​

Paketempfang (Packet Reception)​

Warum wird es so gemacht? (Why is it done this way?)​

Netzwerküberwachung und Debugging (Network Monitoring and Debugging)​

Ein Beispiel (An Example)​

Verwandte Fragen (Related Issue)​

Verwandte Ressourcen​