Summary

  • BOOTP ermöglichte 1985 einem plattenlosen Client, eine Adresse und Angaben zur Startdatei anzufordern, bevor er eine gewöhnliche IP-Anfrage an einen Server senden konnte. Ein Relay-Agent konnte den Austausch über das lokale Netz hinaus tragen.
  • giaddr beschrieb den BOOTP-eigenen Relay-Pfad. RFC 1542 stellte später klar, dass das Feld weder einen allgemeinen IP-Router noch die Standardroute des Clients bezeichnet.

Der Rechner brauchte Hilfe, bevor er danach fragen konnte

Eine plattenlose Workstation stand beim Einschalten vor einem praktischen Zirkelschluss: Für IP brauchte sie eine Internetadresse, doch das Netzwerk musste ihr erst mitteilen, welche Adresse sie verwenden sollte. Außerdem musste sie den Server und die Datei für den weiteren Start finden. Lag der Server in einem anderen Netz, konnte ein lokaler Broadcast gewöhnliche Router nicht von selbst überwinden.

RFC 951 vom September 1985 beschrieb BOOTP als erste Phase: Adresse ermitteln und Startdatei auswählen. Der Client sendete einen BOOTREQUEST mit seiner Hardwareadresse und, sofern bekannt, seiner IP-Adresse. ciaddr ist das Feld für eine bereits bekannte Client-IP-Adresse; war es null, konnte der Server anhand der Hardwareadresse seinen Datenbankeintrag suchen. Die angebotene Clientadresse stand anschließend in yiaddr. Weitere Felder bezeichneten Server und Datei. Der Austausch lief über UDP-Port 67 und 68.

Die Antwort lud das Betriebssystem nicht selbst. RFC 951 trennte die Auswahl von Adresse und Datei ausdrücklich von der anschließenden Dateiübertragung, typischerweise per TFTP. RFC 906 hatte netzgestütztes Laden von Startdateien bereits 1984 beschrieben. Eine BOOTP-Antwort, die Server und Datei nannte, bewies also nicht, dass der Client den Server erreichte, die Datei vollständig empfing oder den Start abschloss.

Lokaler Broadcast, dann Weiterleitung zu einem entfernten Dienst

Ein noch nicht konfigurierter Client musste weder per DNS einen entfernten Server suchen noch schon eine entfernte Route kennen. Er konnte die Anfrage im lokalen Netz broadcasten. Befand sich der Server anderswo, konnte ein Gateway oder Forwarding-Agent die BOOTP-Anfrage dorthin und die Antwort zurücktragen. RFC 951 machte diese netzübergreifende Fähigkeit optional. Sie erforderte zusätzliche Software in Gateways und Servern, aber keine besondere Aktion des Clients.

Das Paket enthielt giaddr, 1985 als Gateway-IP-Adresse beschrieben. Beim Weiterleiten konnte das erste Gateway das leere Feld mit seiner eigenen Adresse füllen und hops erhöhen. War giaddr ungleich null, konnte der Server die BOOTP-Antwort an diese Adresse und den Server-Port senden, damit der Relay-Agent sie im Clientnetz zustellte. Das Feld verband so einen startenden Rechner mit einem Boot-Dienst an einem anderen Ort.

Dieser Pfad war nicht die Route, die der Rechner später verwenden würde. Die frühe Formulierung in RFC 951 ließ Verwechslungen zu: Eine Passage sprach davon, Pakete über giaddr weiterzuleiten, um den Server zu erreichen. Die Übertragung der Startdatei und das gewöhnliche IP-Routing des Clients waren jedoch unterschiedliche Aufgaben. Ein Feldname mit „Gateway“ machte daraus nicht dieselbe Adresse.

Die Klarstellung von 1993

RFC 1542 ging auf die Mehrdeutigkeit ein. Die frühere Spezifikation hatte das Verhalten des Weiterleitungsagenten nicht eindeutig festgelegt. Deshalb führte das Dokument den Begriff „Relay-Agent“ ein und grenzte die Aufgabe vom normalen IP-Forwarding ab: Ein BOOTP-Relay empfängt die Nachricht als Ziel und erzeugt eine neue BOOTP-Nachricht. Es reicht nicht bloß ein gewöhnliches IP-Datagramm unverändert durch. Die Funktion konnte in einem verbindenden Router liegen, aber auch auf einem Host direkt im Clientnetz.

RFC 1542 erklärte, dass giaddr BOOTREQUEST-Nachrichten durch Relay-Agents zu Servern in anderen Netzen und BOOTREPLY-Nachrichten auf diesem Weg zurückbringt. Das Feld bezeichnet keinen allgemeinen IP-Router für den Client; der Client darf es nicht so interpretieren. Für einen nichtlokalen TFTP-Server braucht der Host weiterhin eine separate Adresse für den ersten Router, etwa aus einer anderen Konfigurationsoption oder einem Entdeckungsverfahren.

Die Klarstellung verwarf das Design von 1985 nicht. Sie zeigte seine Grenze: Das Relay löste ein Problem des Boot-Dienstes, solange die IP-Konfiguration des Clients noch unvollständig war. Den späteren Datenverkehr konfigurierte es nicht automatisch.

Was zentralisiertes Booten ermöglichte – und offenließ

Mit einem Relay konnten Boot-Server, Zuordnungen zwischen Hardware- und IP-Adressen sowie Startdateien außerhalb des lokalen Kabels liegen. Das konnte separate Boot-Server pro Segment überflüssig machen und dem Betreiber eine zentrale Pflege der Zuordnungen und Dateien ermöglichen. Das ist eine architektonische Folgerung aus den RFCs, keine Messung realer Verbreitung oder Kosten.

Nach einer BOOTP-Antwort waren mehrere Schritte noch offen. Zuerst musste die Anfrage den Relay-Agenten auf dem lokalen Link und von dort das richtige Serverziel erreichen. Dann brauchte der Server einen passenden Client-Eintrag und musste die Startdatei bereitstellen. Schließlich benötigte der Client eine eigene Route zum Datei-Server; erst danach konnte die TFTP-Übertragung gelingen. Jeder Schritt hat einen anderen Nachweis. Eine Antwort in der ersten Phase belegt keinen der späteren Schritte. Die Relay-Adresse identifiziert auch keine Person, belegt keine Berechtigung und legt nicht die Standardroute des Clients fest.

DHCP übernahm später das Verhalten der Relay-Agents und ergänzte unterschiedliche Zuweisungsarten, darunter befristete Leases. Diese Entwicklung sollte BOOTP-Startaustausch, DHCP-Lease-Zyklus, TFTP-Dateiübertragung und gewöhnliches IP-Routing nicht vermischen. Ein Startvorgang kann von allen vier abhängen; jeder Mechanismus hat jedoch einen eigenen Zustand und eigene Nachweise.

Die historische Lehre steckt in einem Feld mit vier Buchstaben. giaddr half einer Steuernachricht, eine Netzgrenze zu überschreiten, während der Host noch lernte, am IP-Verkehr teilzunehmen. Der Name machte es nicht zum Gateway des Hosts. Rückweg einer Steuernachricht, nächster Hop des Clients, Adresse des Dateiservers und erfolgreicher Dienst sind in der Internet-Infrastruktur verbundene, aber nicht austauschbare Tatsachen.

Quellen