Zusammenfassung

  • RFC 1931 beschrieb mehrere Dynamic-RARP-Server als Verfügbarkeitsreserve, verlangte aber, dass alle Server eines Segments mit derselben logischen Adressautorität kommunizieren.
  • Ein kohärentes Register konnte dennoch falsch sein: Vor einer Vergabe sollte ARP oder ICMP prüfen, ob eine als frei geführte Adresse im laufenden Netz bereits benutzt wurde.
  • Das Dokument erschien im April 1996 als Informational und wird heute als Legacy geführt. Es hielt ein seit 1988 auf bestimmten Sun-Plattformen genutztes Verfahren fest, definierte keinen Internetstandard und belegt keine kausale Abstammung von DHCP.

Warum Schweigen kein brauchbarer Zustand war

Das in RFC 903 definierte RARP half einem startenden Rechner, der seine Hardwareadresse kannte, aber noch keine Protokolladresse besaß. Ein oder mehrere Server hielten die Zuordnungen. Eine negative Antwort gab es bewusst nicht, denn das Nichtwissen eines Servers sagte nichts über einen anderen aus.

Für eine unbeaufsichtigte Installation blieb Schweigen dadurch mehrdeutig. Das Paket konnte verloren, der sachkundige Server ausgefallen, der Rechner unbekannt oder am falschen Segment angeschlossen sein. Vielleicht existierte überhaupt kein Server. Exponentielles Wiederholen begrenzte den Verkehr, lieferte aber keinen Zeitpunkt, an dem weiteres Warten sinnlos wurde.

Auch „automatisch“ bedeutete nicht voraussetzungslos. IP-Netz und Namenssystem mussten administrativ vorbereitet sein. Eine Adresse war erst der Anfang; Registrierung, Boot-Ressourcen, Schlüssel und Anfangspasswort gehörten zu anderen Schritten.

RFC 1931 dokumentierte Dynamic RARP als eng begrenzte Ergänzung. Das Paketformat blieb erhalten, hinzu kamen Anfrage, temporäre Antwort und Fehler. Bei dauerhafter Zuordnung antwortete der Server mit REVARP_REPLY. Andernfalls konnte er eine temporäre Bindung als DRARP_REPLY erzeugen oder per DRARP_ERROR zwischen Richtlinienverbot, erschöpftem Vorrat, vorübergehend nicht verfügbarer Autorität, falschem Segment und unbestimmtem Fehler unterscheiden.

Die aktuelle RFC-Editor-Seite ordnet das Dokument als Informational im Legacy-Stream ein und hält fest, dass es keinen Internetstandard definiert. Bestimmte Sun-Microsystems-Plattformen nutzten DRARP laut Text seit 1988; im April 1996 wurden diese Produkte nicht mehr verkauft, und DHCP hatte den Zweck teilweise übernommen. Das Memo konservierte Betriebserfahrung, nicht einen verspäteten Standardanspruch.

Der Serverpool durfte keine zweite Wahrheit erzeugen

Hörten mehrere DRARP-Server dieselbe Anfrage, mussten ihre Antworten bis auf die Absenderfelder übereinstimmen. Jede andere Abweichung war ein Protokollfehler. Diese kleine Regel machte aus mehreren Rechnern eine Dienstoberfläche mit einer Entscheidung.

Ein Server pro Kabelsegment senkte die Kosten einer Partition; mehrere Server verringerten die Abhängigkeit von einer Maschine oder Strecke. Alle mussten jedoch dieselbe Adressautorität erreichen. Die beschriebene Implementierung verwendete NIS und den zentralen RPC-Dienst IPalloc. Autorisierte Akteure wie Administratoren und DRARP-Server durften das Register verändern. Weder dieses Autoritätsprotokoll noch seine Sicherheitsentscheidungen wurden standardisiert.

Die Autorität verwaltete dauerhafte Bindungen, temporäre Bindungen und den freien Vorrat. Sie musste anlegen, suchen, löschen und bereinigen, gleichzeitige Ansprüche ordnen und Berechtigungen prüfen. Eine Autorität pro Segment war eine logische Konsistenzforderung, kein Beweis für genau einen physischen Rechner. Eine Partitionierung war denkbar, aber technisch und administrativ teuer.

Damit ist Redundanz genau verortet: Sie erhöht die Zahl der Antwortmöglichkeiten. Sie verteilt nicht von selbst das Recht, eine Adresse verbindlich zuzuweisen. Eine replizierte Infrastruktur kann einen gemeinsamen Fehler ausgesprochen zuverlässig ausliefern.

Das Kabel konnte dem Register widersprechen

RFC 1931 vertraute dem zentralen Bestand nicht blind. Eine administrativ freie Adresse konnte tatsächlich in Gebrauch sein. Vor der Vergabe sollte daher das Netz geprüft werden; die Implementierung nutzte ARP und ICMP Echo.

ARP nach RFC 826 verteilt Zuordnungen von Protokoll- zu Hardwareadressen bei Bedarf. Eine Antwort ist ein örtlicher, zeitgebundener Hinweis auf Nutzung. Sie beweist weder Eigentum noch Berechtigung oder künftige Einzigartigkeit. Ausbleibende Antwort kann ebenfalls an Verlust oder Isolation liegen.

Hardwarekennung, Autoritätsdatensatz und Live-Beobachtung müssen deshalb getrennt bleiben. Die Kennung ist ein Wert auf der Verbindungsschicht. Das Register sagt, welche Bindung die Organisation anerkennt. Die Sonde sagt, was zu einem Zeitpunkt auf einem Segment sichtbar war.

Für den Wechsel eines Rechners zwischen Segmenten mussten die Autoritäten identisch sein oder kommunizieren; auch die Hardwarekennung brauchte einen ausreichend weiten Geltungsbereich. Trotzdem authentifizierte sie keinen Eigentümer. Server konnten Ankündigungen anderer Server beobachten und einen scheinbar unkoordinierten Antwortenden melden. Ein Verfahren zur gegenseitigen Entscheidung, wer tatsächlich unzulässig war, definierte das RFC nicht. Erkennung blieb Beweis, nicht Urteil.

Ablaufzeit war Ressourcenpolitik, kein Abschlusszeugnis

Temporäre Bindungen mussten lange genug überleben, damit Installation und nachgelagerte Register auch bei kurzen Störungen konvergieren konnten. Eine Stunde hatte in der ersten Implementierung genügt. Das war ein Erfahrungswert, keine allgemeine Lease-Regel. Ablauf gewann Adressen zurück, bewies aber keinen erfolgreichen Abschluss.

Spätere DHCP-Spezifikationen wählten andere Zustände. RFC 1541 machte mehrere Angebote, die Auswahl des Clients, Serverkennung und endliche Lease sichtbar. RFC 2131 präzisierte den Ablauf und erlaubte dem Client, ein lokal als belegt erkanntes Angebot abzulehnen. Das ist ein Architekturvergleich und keine Behauptung, DRARP habe DHCP verursacht.

Auf einen einzelnen Link beschränkt erlaubte RFC 3927 später die Wahl, Prüfung, Beanspruchung und teilweise Verteidigung einer IPv4-Link-Local-Adresse. Sie ist nicht routbar und keine dauerhafte Identität. RFC 5227 verallgemeinerte Konflikterkennung mit ARP Probes und Announcements. Auch diese Evidenz bleibt lokal und zeitlich begrenzt; Partitionen und bösartige Antwortende verschwinden nicht.

Der kleinste gemeinsame Vertrag

Heng Lus Running-Code Primacy bietet eine passende Lesart. Das Register koordinierte symbolisch, doch der laufende Datenverkehr konnte es widerlegen. Die Sonde ersetzte Verwaltung nicht; sie zwang Verwaltung, sich vor der Ausführung an der Betriebswirklichkeit prüfen zu lassen.

Minimum Initial Specification lenkt den Blick auf den kleinen zwingenden Kern: Antworten müssen kohärent, Fehler unterscheidbar und temporäre Zustände lange genug haltbar sein. NIS, RPC, genaue Dauer und lokale Autorisierung dürfen austauschbar bleiben.

Aus Sicht der Realitätsebenen koordiniert das Register, konfiguriert die Antwort und widerspricht die Sonde. RFC 1931 verwechselte viele Server nicht mit vielen Autoritäten. Noch wichtiger: Es verwechselte eine Autorität nicht mit der ganzen Wirklichkeit.

Quellen

  1. RFC 1931 — Dynamic RARP Extensions for Automatic Network Address Acquisition
  2. RFC Editor — aktueller Datensatz zu RFC 1931
  3. RFC 903 — A Reverse Address Resolution Protocol
  4. RFC 826 — An Ethernet Address Resolution Protocol
  5. RFC 1541 — Dynamic Host Configuration Protocol
  6. RFC 2131 — Dynamic Host Configuration Protocol
  7. RFC 3927 — Dynamic Configuration of IPv4 Link-Local Addresses
  8. RFC 5227 — IPv4 Address Conflict Detection
  9. Heng Lu — Running-Code Primacy
  10. Heng Lu — Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption
  11. Heng Lu — On Reality Layers, Symbolic Power, and Why Clarity Feels So Hostile