Zusammenfassung

  • RFC 903 löste ein konkretes Kaltstartproblem: Ein plattenloser Host kannte seine Hardwareadresse, brauchte aber eine Protokolladresse, bevor er IP verwenden konnte.
  • RARP stellte die Anfrage auf der Sicherungsschicht. Ein Server antwortete aus einer gepflegten Zuordnung von Hardware- zu Protokolladressen; die Antwort authentifizierte weder das Gerät noch belegte sie einen abgeschlossenen Systemstart.
  • Für „nicht gefunden“ gab es keine eigene Antwort. Blieb eine Antwort aus, musste der Client eine Zeitüberschreitung abwarten, ohne zu wissen, ob die Zuordnung fehlte, ein Paket verloren ging oder kein Server antwortete.
  • RFC 950 und BOOTP zeigen, warum eine Adresse nicht die gesamte Host-Konfiguration ausmachte: Ein Gateway, ein Namensserver, eine Subnetzmaske und eine Bootdatei konnten ebenfalls nötig sein.

Die erste Frage kam vor IP

Man stelle sich eine Workstation ohne lokale Festplatte vor. Ihr Startcode kann die Hardwareadresse der Ethernet-Schnittstelle lesen, hat aber keine Internetadresse gespeichert. Eine IP-Anfrage hilft noch nicht: Dem Rechner fehlt die Absenderadresse, die er dafür bräuchte.

In RFC 903 schlugen Ross Finlayson, Timothy Mann, Jeffrey Mogul und Marvin Theimer im Juni 1984 RARP vor. Das Memo beschreibt, wie ein Host seine Protokolladresse aus einer externen Quelle erfragt, etwa über ein Ethernet als Broadcast-Medium. ARP löste die Gegenrichtung: Es suchte eine Hardwareadresse, wenn die Protokolladresse bereits bekannt war. RARP setzte bei der Hardwareadresse an und fragte nach der zugehörigen Protokolladresse.

Das war kein allgemeiner Identitätsdienst. RARP fragte weder, wem die Workstation gehörte, noch ob eine Person eine Adresse verwenden durfte. Es gab einem noch unkonfigurierten Host eine Möglichkeit, vor der normalen IP-Kommunikation eine einzelne Zuordnung anzufragen.

Ein lokaler Server hielt die Antwort bereit

RFC 903 definierte RARP bewusst als eigenes Protokoll auf der Sicherungsschicht. Es verwendete das Paketformat von ARP wieder, vergab aber eigene Operationscodes für Anfrage und Antwort in umgekehrter Richtung. Wollte ein Host seine eigene Adresse ermitteln, trug er dieselbe Hardwareadresse sowohl im Absender- als auch im Zielfeld ein. Ein Server, der diese Adresse kannte, konnte die zugeordnete Protokolladresse zurücksenden.

Die Antwort hing vom Zustand des Servers ab. Das RFC sagt, dass ein oder mehrere RARP-Server eine Datenbank mit Zuordnungen von Hardware- zu Protokolladressen pflegen. Bei normalem ARP sammeln Hosts dagegen Zuordnungen ihrer Kommunikationspartner in einem Cache; eine Rollenverteilung in Client und Server gibt es dort nicht. RARP brachte damit eine Betriebsabhängigkeit mit: Der Client konnte fragen, aber eine lokale Administration musste die Servertabelle brauchbar halten.

Die Antwort war ein Zuordnungsbeleg, kein Berechtigungsnachweis. Das RFC definiert keine Authentifizierung, die eine Hardwareadresse an eine Person, einen Eigentümer oder ein zugelassenes Gerät bindet. Es belegt auch nicht, dass der Host die Adresse korrekt installierte, ein Gateway erreichte oder ein Betriebssystem geladen hatte. Das wären spätere Schritte.

Schweigen hieß nicht „nicht vorhanden“

RFC 903 definiert Anfragen und Antworten, aber kein eigenes Paket für „nicht gefunden“ oder einen Fehler. Die Autoren erklären, dass mehrere Server antworten dürfen. Statt eine gesonderte Ablehnung einzuführen, soll der Anfragende bei ausbleibender Antwort nach einer angemessenen Zeit den Vorgang abbrechen.

Das hielt den Austausch klein, ließ den Client aber mit einer mehrdeutigen Beobachtung zurück. Eine Zeitüberschreitung konnte bedeuten, dass kein Server die Zuordnung kannte. Ebenso konnten Anfrage oder Antwort verloren gegangen, die Verbindung unterbrochen oder jeder Server nicht verfügbar sein. Das Schweigen unterschied diese Fälle nicht. Ein Startprotokoll, das nur „RARP timeout“ meldete, konnte die Ursache nicht klären.

Bei der Rekonstruktion eines Fehlers ist diese Grenze wichtig. Keine Antwort belegt, was der Client empfangen hat — nichts —, aber nicht, dass die Adresse nicht vergeben war. Das ursprüngliche Memo macht diese Grenze sichtbar, schreibt jedoch kein Diagnosesystem vor, das jede Ursache auseinanderhalten könnte.

Eine Adresse richtete noch nicht den ganzen Host ein

Das größere Startproblem wurde bald deutlich. RFC 950 nennt RARP als eine Möglichkeit, mit der ein frisch gestarteter Host seine Internetadresse entdecken kann, führt danach aber weitere mögliche Angaben auf: die Hardwareadresse eines Gateways, die IP eines Namensservers und die Subnetzmaske. Mehrere Parameter in einer Anfrage zu erhalten sei besser, als mehrere Broadcasts zu senden.

Das im folgenden Jahr spezifizierte BOOTP behielt die Zuordnung von Hardware- zu IP-Adresse bei und konnte zusätzliche Startinformationen transportieren, darunter einen optionalen Dateinamen. Das Protokoll ermöglichte auch den Start über Gateways. RFC 951 vergleicht ausdrücklich seinen IP/UDP-Ansatz mit den RARP-Paketen auf der Sicherungsschicht und dem besonderen Kernel- oder Treiberaufwand, um solche Rohpakete zu verarbeiten. RFC 1542 präzisierte später das BOOTP-Relay-Verhalten; RFC 2131 beschreibt DHCP als Weiterentwicklung von BOOTP mit automatischer Vergabe wiederverwendbarer Adressen und Konfigurationsoptionen.

Daraus folgt nicht, dass jedes Netz RARP an einem bestimmten Tag einstellte. Es zeigt vielmehr, wie sich die Frage erweiterte: Eine vorab zugeordnete Adresse zu finden war nützlich, doch ein Host über geroutete Netze hinweg zu starten erforderte einen umfassenderen Austausch und einen Relay-Pfad.

Ein Eintrag ist nicht das Gerät

Heng Lus Notiz 72 ist eine spätere analytische Perspektive, kein Beleg für das Jahr 1984: Ein Registereintrag beschreibt die Wirklichkeit, erschafft sie aber nicht. RARP war kein globales Register, doch die Unterscheidung passt. Die Servertabelle koordinierte eine lokale Zuordnung; sie machte aus der zurückgegebenen Adresse keinen Nachweis für Geräteeigentum, Nutzeridentität oder erfolgreichen Betrieb.

Der historische Beitrag des Protokolls war enger und praktisch: Ein Host konnte das bereits erreichbare Netz nach der einen Adresse fragen, die er für den Start der IP-Kommunikation brauchte. Seine Grenze war zugleich sein Aufwand: Lokale Zuordnungen mussten gepflegt werden, Schweigen erklärte sich nicht selbst und die Antwort war noch keine vollständige Konfiguration.

Quellen

RFC 903 — A Reverse Address Resolution Protocol; RFC 826 — An Ethernet Address Resolution Protocol; RFC 950 — Internet Standard Subnetting Procedure; RFC 951 — Bootstrap Protocol; RFC 1542 — Clarifications and Extensions for the Bootstrap Protocol; RFC 2131 — Dynamic Host Configuration Protocol. Notiz 72 ist eine spätere redaktionelle Perspektive, keine historische Quelle.