Zusammenfassung

  • RFC 1293 ist ein Standards-Track-RFC vom Januar 1992. Er ergänzt ARP um Inverse Address Resolution Protocol, das zu einer bekannten Hardwareadresse die passende Protokolladresse anfragt; sein Frame-Relay-Beispiel beginnt mit einem DLCI eines bestehenden PVC, dessen Gegenstellenadresse fehlt.
  • InARP sendet nicht per Broadcast, weil die Ziel-Hardwareadresse bekannt ist. Der Empfänger kann eine geeignete Antwort geben oder einen Request ignorieren, wenn er nicht antworten kann oder will. Der Anfrager kann eine lokale ARP-Zuordnung vervollständigen, die später altern oder invalidiert werden kann.

Der RFC trennt eine Verbindungsinformation von einer Nachbarinformation. Ein DLCI definiert eine einzelne virtuelle Verbindung durch ein WAN und entspricht im Frame-Relay-Kontext einer Hardwareadresse. Die Signalisierung kann einen neuen virtuellen Kreis mit diesem DLCI ankündigen. Doch die Protokolladresse der Station am anderen Ende wird nicht mitgeliefert. Ohne zusätzliche Konfiguration oder einen Entdeckungsmechanismus kann die lokale Station die Gegenstelle nicht adressieren.

„Unbrauchbar“ bedeutet in diesem Satz nicht, dass der Kreis nicht existiert oder eine Störung bewiesen ist. Es bedeutet, dass ein bestimmter nächster Schritt nicht möglich ist: die andere Seite mit einer Protokolladresse anzusprechen. Der bekannte untere Kennzeichner ist ein Weg für eine Anfrage, nicht die Antwort auf die Anfrage.

InARP bewahrte die unbekannte Adresse sichtbar

Die anfragende Station setzt ihre Hardware- und Protokolladressen ein, fügt die bekannte Ziel-Hardwareadresse ein und füllt das Feld der Ziel-Protokolladresse mit Null. Danach kapselt sie den Request für das betreffende Netz ein und schickt ihn direkt zum Ziel. Gerade die Null ist entscheidend: Sie markiert, was noch nicht bekannt ist, statt eine Identität aus dem DLCI zu erfinden.

Der direkte Versand unterscheidet InARP vom üblichen ARP-Broadcast. Weil die Hardwareadresse bereits bekannt ist, muss die Station nicht nach einem beliebigen möglichen Empfänger suchen. Das kann nach RFC 1293 effizienter sein als die Nachbildung eines Broadcasts mit mehreren Kopien und flexibler als statische Konfiguration. Es macht den Request aber nicht zu einem Nachweis, dass die entfernte Station InARP unterstützt, erreichbar ist, eine passende Adresse besitzt oder antworten wird.

Eine präzise Beobachtung lautet daher: Diese Station sendete zu diesem Zeitpunkt eine InARP-Frage an diese Hardwareadresse. Erst eine Antwort fügt eine weitere Beobachtung hinzu. Eine gesendete Frage wird nicht dadurch zu einer aufgelösten Nachbarschaft, dass ihr Ziel bestimmt war.

Reverse ARP beantwortete ein anderes Subjekt

InARP erweitert das ARP-Format und verwendet den Operationscode 8 für Request sowie 9 für Reply. Reverse ARP wurde nach Darstellung des RFC erwogen, aber verworfen: Seine Antwort enthält die Protokolladresse der anfragenden Station, nicht die der Station, die den Request empfängt und deren Adresse hier gesucht wird.

Die Ähnlichkeit im Wort „reverse“ ersetzt nicht die Richtung der Information. „Welche Adresse habe ich?“ und „Welche Adresse gehört zu dieser bekannten Hardware-Gegenstelle?“ sind verschiedene Fragen. IP-spezifische Mechanismen wurden ebenfalls nicht gewählt, da mehrere Protokolle aufgelöst werden sollten. InARP ist somit weder ein IP-Eigentumsregister noch eine Routingautorität, sondern ein begrenzter Austausch über eine fehlende Zuordnung.

Der Empfänger behielt die Wahl über Antwort oder Schweigen

Eine empfangende Station darf die Zuordnung aus Protokoll- und Hardwareadresse des Anfragers selbst in ihren ARP-Cache aufnehmen. Sie darf aus den Quelladressen des Requests eine passende Antwort formen. Kann oder will sie nicht antworten, ignoriert sie den Request.

Dieses Schweigen ist kein unvollständiger Erfolg. Ein Log mit einem Request belegt seinen Versand, nicht eine Ursache für die ausbleibende Antwort. Der RFC ordnet das Schweigen keiner konkreten Störung, Policy, Identität oder Sicherheitseigenschaft zu. Eine solche Diagnose benötigt zusätzliche Belege.

Kommt eine Antwort an, darf der Anfrager seinen ARP-Tabelleneintrag vervollständigen und die Adresse verwenden. Das belegt eine lokale Verarbeitung einer Antwort. Es zertifiziert nicht die Zuordnung, autorisiert keinen Verkehr und beweist nicht, dass spätere Pakete zugestellt werden. Informationen aus InARP können nach dem RFC altern oder invalidiert werden.

Mehrere Adressen machten die Antwort kontextabhängig

Ein Host mit mehreren Protokolladressen auf einer Schnittstelle darf nicht willkürlich eine davon zurückgeben. Er muss die Protokolladresse des Anfragers berücksichtigen und eine Adresse wählen, die zu dessen Netz gehört. Im IP-Beispiel soll er nicht antworten, wenn er auf der Schnittstelle keine Adresse im angefragten Subnetz hat. Ein mehrfach adressierter Host kann Requests für jede Adresse der Schnittstelle schicken; die Gegenstelle kann je nach Konfiguration einige oder keine beantworten.

Damit ist eine passende Reply keine isolierte Eigenschaft des entfernten Hosts. Dass er mehrere Adressen besitzt, entscheidet nicht, welche für diese Anfrage geschrieben werden darf. Anfrager, Netzkontext, Konfiguration und tatsächliche Antwort müssen zusammen erhalten bleiben.

Cache-Alter hielt die Zuordnung zeitlich begrenzt

Eine ARP-Zeile, die nach einem InARP-Reply vervollständigt wurde, ist eine lokale, zeitlich gebundene Aufzeichnung. Der RFC nennt ausdrücklich Altern und Invalidieren. Für eine überprüfbare Nutzung müssen DLCI, Request, Antwort oder Schweigen, Zeitpunkt, eingetragene Adresse, Ablauf und Invalidierung getrennt protokolliert werden.

Diese Zeile beweist keinen aktuellen Kreis, keine Dauerhaftigkeit, keine IP-Route und keine Datenzustellung. Sie beweist auch keine Sicherheit: Die Security Considerations des RFC sagen, dass Sicherheitsfragen nicht behandelt werden. Discovery, lokales Caching und der Erfolg einer späteren Datenoperation sind daher drei verschiedene Evidenzarten.

Quelle und Evidenzgrenzen

Dieser Beitrag verwendet RFC 1293 — Inverse Address Resolution Protocol. Die Quelle trägt Status und Datum, DLCI/PVC-Motivation, die fehlende Gegenstellenadresse, die Ablehnung von RARP und nur-IP-Mechanismen, Format und Codes, direkten nicht-broadcastenden Versand, Reply oder Ignorieren, Cache sowie Altern/Invalidieren, Mehradressenwahl und den Hinweis auf nicht behandelte Sicherheit.

Sie trägt nicht die Existenz oder den gegenwärtigen Zustand eines bestimmten Frame-Relay-Kreises, die Konfiguration oder Erreichbarkeit eines Peers, eine korrekte oder autorisierte Antwort, eine persistente Cache-Zeile, IP-Routing, Paketlieferung, Sicherheit oder ein Nutzerergebnis. Ein bekannter DLCI ist nach dieser Lesart eine begrenzte Koordinationsbedingung, kein Urteil über einen nutzbaren Nachbarn.