Zusammenfassung

  • BOOTP ließ einen plattenlosen Client seine IP-Adresse, einen Server und einen Dateinamen für den Systemstart anfragen, bevor normale IP-Konnektivität bestand; die Datei selbst wurde danach separat, meist per TFTP, übertragen.
  • Die Antwort schuf ein weiteres Problem: Ohne Adresse konnte der Client nicht auf ARP reagieren. RFC 951 beschrieb einen temporären ARP-Cacheeintrag auf der Serverseite oder eine Broadcast-Antwort; spätere Relay-Regeln machten Anfragen über Subnetze hinweg möglich.

Beim Einschalten hatte eine Arbeitsstation ohne Laufwerk noch kein Betriebssystem, das ihr Netzwerk konfigurieren konnte. Ihr PROM konnte eine Anfrage senden, musste aber zuerst erfahren, welche Adresse und welche Datei sie verwenden sollte. Erst danach konnte es die Datei anfordern. Die Abfolge wirkte zirkulär: Wie erhält ein Rechner eine Antwort aus dem Netz, bevor er dort eine nutzbare Netzwerkidentität besitzt?

Bill Croft und John Gilmore beschrieben dieses Problem im September 1985 in RFC 951. BOOTP übertrug keine Dateien. Es übernahm die erste Phase: die Adresse zu bestimmen und eine Startdatei auszuwählen. Das PROM des Clients konnte nach Adresse, Server und Dateiname fragen; anschließend lud eine zweite Phase die Datei in den Speicher, normalerweise mit TFTP. Vorgesehen war auch ein unbeaufsichtigter Start beim Einschalten. Das Dokument beschrieb einen Entwurf, keine Statistik über die tatsächliche Zahl der Nutzer. (RFC 951, §§ 2 und 7.5.)

Die Anfrage brauchte keine IP-Adresse, die der Client noch gar nicht kannte. War auch der Server unbekannt, konnte der Client ein IP/UDP-Paket mit der Quelladresse null an 255.255.255.255 senden – einen Broadcast auf dem lokalen Kabel. Die Anfrage enthielt außerdem Hardwaretyp und Hardwareadresse sowie eine Transaktionskennung. Der Server konnte in seiner eigenen Datenbank die Hardwareadresse einer IP-Adresse zuordnen, diese in das Feld yiaddr der Antwort eintragen und einen vollständigen Pfad zur Startdatei auswählen. Eine allgemeine Anfrage wie unix konnte so zu einer für diesen Client angepassten Datei führen. Der lokale Datensatz auf dem Server gehörte damit zum Startvorgang. (RFC 951, §§ 2–3, 7.1, 7.3 und 9.)

Die erste Antwort hatte ihr eigenes Henne-Ei-Problem. Normalerweise braucht ein Server ARP, um die Link-Layer-Adresse für ein IP-Ziel herauszufinden. Doch der Client kannte seine eigene Adresse noch nicht und konnte auf die ARP-Anfrage des Servers nicht antworten. RFC 951 nannte zwei Wege aus der Lücke. Mit geeigneter Unterstützung im Kernel oder Treiber konnte der Sender aus chaddr und yiaddr einen befristeten ARP-Cacheeintrag anlegen. RFC 951 verwies ausdrücklich darauf, dass UNIX 4.2 BSD dazu in der Lage war. Ohne diese Unterstützung konnte der Server die Antwort auf der Schnittstelle des Clients broadcasten. Welche Lösung möglich war, hing von den lokalen Fähigkeiten des sendenden Systems ab. (RFC 951, § 4.)

Auch die zwei UDP-Ports halfen bei diesem Rückweg. Anfragen gingen an den BOOTP-Serverport 67, Antworten an den Clientport 68. RFC 951 erklärte, dass der Kernel einen Broadcast an den Clientport auf Rechnern herausfiltern konnte, die dort nicht lauschten. So mussten die BOOTP-Server-Daemons anderer Hosts nicht geweckt und eingeplant werden. Ein zufälliger Clientport hätte den Broadcast zudem für einen Prozess auf einem anderen Rechner bestimmt erscheinen lassen können. Das war keine nebensächliche Portnummernordnung: Die Startantwort für einen Rechner wurde dadurch nicht zum Anwendungsereignis im gesamten Segment. (RFC 951, § 3.)

Der Startserver stand nicht immer am selben Kabel. RFC 951 machte den Start über Gateways optional und abhängig von deren Kooperation mit den Servern. Ein Gateway oder ein anderer Agent konnte den Broadcast empfangen, giaddr mit dem Netz des Clients belegen und die Anfrage weitergeben. Die Autoren warnten davor, Anfragen unterschiedslos überall erneut zu senden, weil dabei Schleifen entstehen konnten. RFC 1542 zog im Oktober 1993 eine klarere Grenze: Ein BOOTP-Relay-Agent war kein gewöhnlicher IP-Router, der ein Datagramm transparent weiterleitete. Er konnte die BOOTP-Nachricht als Endziel entgegennehmen und eine neue BOOTP-Nachricht erzeugen. Die Funktion konnte auf einem Router oder einem separaten Host im Client-Subnetz laufen. Das Relay war ein konfigurierter Dienst mit eigenen Verarbeitungsregeln. (RFC 951, § 8; RFC 1542, §§ 4–4.1.)

Deshalb sollte man BOOTP nicht einfach als „altes DHCP“ abtun. RFC 2131 beschrieb DHCP später als Erweiterung des BOOTP-Mechanismus und behielt Nachrichtenformat und Relay-Verhalten bei, damit vorhandene Clients zusammenarbeiten konnten. Eine wichtige Neuerung waren befristete Leases: Eine nicht mehr benötigte Adresse konnte wiederverwendet werden. Im BOOTP-Modell von 1985 stammten Adresse und Startdatei aus Servereinträgen. Auch DHCP unterstützt manuelle Vergabe. Der Unterschied besteht also nicht darin, dass später jede Adresse nur noch vorübergehend war; neu war die dynamische Vergabe im Protokoll. (RFC 2131, §§ 1–2.)

BOOTPs historische Aufgabe war klein, aber notwendig. Es machte einen plattenlosen Rechner weder selbstständig noch authentifizierte es einen Nutzer oder übertrug selbst ein Betriebssystemabbild. Es beschrieb, wie ein Rechner mit Hardwareadresse, aber ohne nutzbare IP-Identität die nächsten Startinformationen anfordern konnte, wie ein Server sie auswählte und wie die Antwort eintraf, bevor ARP normal funktionierte. Die Netzanbindung begann hier mit einem lokalen Broadcast, einem ausdrücklichen Servereintrag und einer Antwort, die besondere Behandlung brauchte.

Quellen und Grenzen

RFC 951 war ein Vorschlag und beschreibt beabsichtigtes Verhalten, keine Verbreitungsmessung. Der Hinweis auf den ARP-Cache in 4.2 BSD belegt nicht, dass jede Implementierung diese Funktion hatte. RFC 1542 dokumentiert spätere Relay-Regeln, aber keine allgemeine Einhaltung. BOOTP wählte Netzparameter und einen Dateinamen aus; der Dateitransfer erfolgte getrennt. DHCP führte dynamische Leases ein und behielt zugleich die manuelle Vergabe bei.