Zusammenfassung

  • RFC 1048 stellte 99.130.83.99 an den Anfang des BOOTP-Herstellerfelds. Danach begrenzen Tag und Länge jede normale Option, sodass ein Empfänger unbekannte Inhalte überspringen kann, ohne die nächste bekannte Option zu verlieren.
  • Das Cookie belegt nur die gewählte Darstellungsweise. Auch ein syntaktisch einwandfreies Feld kann von einem unbefugten Server stammen und falsche Router-, DNS- oder Bootinformationen enthalten.

Der Client aus RFC 951 steht vor einer ungewöhnlichen Reihenfolge. Er kennt vielleicht seine Hardwareadresse und kann ein kleines Startprogramm ausführen, aber noch nicht die eigene IP-Adresse, den geeigneten Server oder die zu ladende Datei. BOOTP soll zunächst Konfiguration und Dateipfad liefern; ein anderes Protokoll übernimmt anschließend die Übertragung.

Im Paket waren 64 Oktette als vend für herstellerspezifische Angaben vorgesehen. Dort ließen sich Maske, Gateway und weitere Startparameter ablegen. Ohne gemeinsame Struktur konnte derselbe Wert aber je nach Hersteller etwas anderes bedeuten. RFC 951 empfahl bereits eine vier Byte lange magische Zahl am Anfang, um die Art der folgenden Information erkennbar zu machen. Eine allgemeine innere Gliederung fehlte.

RFC 1048 änderte im Februar 1988 nicht die Feldgröße, sondern die Lesbarkeit. Verschiedene Clients konnten nun dieselbe Hülle benutzen, auch wenn sie nicht denselben vollständigen Optionskatalog kannten. Der Standard schuf einen Interoperabilitätsrand, keine Vertrauenswurzel.

Die Kennung benennt die Syntax, nicht den Sprecher

Das Magic Cookie lautet dezimal 99.130.83.99, hexadezimal 63.82.53.63, und wird in Netzwerkbytefolge übertragen. RFC 1048 weist ihm genau die Identifikation des Modus zu, in dem die nachfolgenden Daten auszulegen sind.

Damit kann ein Client den RFC-1048-Parser statt einer privaten Herstellerbelegung wählen. Das öffentliche, konstante Muster ist jedoch weder Schlüssel noch Signatur. Es authentisiert keinen BOOTP-Server, beweist keine unveränderte Weiterleitung und legitimiert keinen angekündigten Router.

Transaction ID, Hardwareadresse und IP-Felder beantworten andere Fragen. Sie helfen, die Antwort einer offenen Anfrage zuzuordnen und an den Client zu bringen. Eine solche Korrelation ist notwendig, aber kein Identitätsnachweis. Ein Paket kann zur richtigen Transaktion passen und vom falschen Absender kommen.

RFC 1542 beschreibt die Folge ausdrücklich: BOOTP besitzt keinen vernünftigen Authentisierungsmechanismus; ein nicht autorisierter Server kann falsche IP-, Router- und DNS-Angaben einspeisen. Gerade ein sauber codierter falscher Wert kann vom Client ohne Reibung übernommen werden.

Die Länge macht Unkenntnis begrenzt

Nach dem Cookie besteht eine gewöhnliche Option aus einem Oktett Tag, einem Oktett Länge und der angegebenen Zahl von Wertoktetten. Die Länge zählt Tag und Längenoktett nicht mit. Mehrbytewerte stehen in Netzwerkbytefolge.

Ein älterer Client kann dadurch mit einer jüngeren Erweiterung leben. Kennt er den Tag, verarbeitet er den Wert. Kennt er ihn nicht, springt er um die deklarierte Länge weiter und sucht die nächste Option. Unbekanntes bleibt unbekannt, zerstört aber nicht automatisch die Rahmung des Rests.

Diese Form der Kompatibilität verlangt nicht von jedem Teilnehmer, die Zukunft vorwegzunehmen. Ein Sender kann einen neuen registrierten Parameter ergänzen, ohne das ganze Paketformat umzuschalten. Ein Empfänger darf Nichtwissen eingestehen, ohne die bereits gemeinsamen Begriffe zu verlieren.

Die Länge garantiert nur eine Grenze. Sie macht eine Adresse nicht aktuell, einen privaten Code nicht universell und den Parser nicht fehlerfrei. RFC 1084 und RFC 1497 änderten später den Katalog, behielten aber Cookie und Tag-Längen-Form. Das belegt die Tragfähigkeit der Erweiterungsstelle, nicht einheitliches Verhalten aller Implementierungen.

Pad und End sind Steuerzeichen des Feldes

Pad mit Tag 0 belegt nur ein Oktett und besitzt keine Länge. Es dient der Ausrichtung oder füllt freien Platz. End mit Tag 255 besteht ebenfalls aus einem Oktett und schließt die Optionen ab; der Rest wird mit Nullen gefüllt.

Beide sind keine normalen Optionen mit leerem Wert. Wer nach Pad ein Längenoktett erwartet, verschiebt alle folgenden Grenzen. Wer hinter End weiterliest, verwandelt Padding in erfundene Konfiguration. Erweiterbarkeit braucht neben der Additionsregel eine eindeutige Stopregel.

Auch die Reihenfolge kann Bedeutung tragen. Sind Subnetzmaske und Gateway vorhanden, verlangt RFC 1048 die Maske zuerst. Der Client benötigt sie, um lokale Ziele und das Gateway sinnvoll einzuordnen. Getrennte Tags machen also nicht jede Permutation gleichwertig.

Die tatsächliche Grammatik umfasst deshalb Cookie, normale Felder, zwei längenlose Ausnahmen, Abhängigkeiten und Abschluss. Das Kürzel TLV allein beschreibt nicht, wie ein sicherer Leser mit den Grenzfällen umgeht.

Ein fester Raum verlangt eine Rangfolge

Vier von 64 Oktetten gehören dem Cookie. Jede normale Option zahlt zwei Oktette Struktur vor ihrem Wert. Eine IPv4-Adresse braucht weitere vier, eine Liste entsprechend mehr. RFC 1048 verbietet das Überschreiten von vend und empfiehlt, nicht notwendige Angaben über andere Dienste zu entdecken.

Damit wird jede Erweiterung zur Auswahl. Maske, Router, Namens-, Zeit- oder Logserver können wichtig sein, passen aber nicht unbegrenzt in die erste Antwort. Der Standard definiert Codierungen; Betreiber und Client legen fest, was in ihrer Umgebung unverzichtbar ist.

Auch allgemeine Tagnummern sind knapp. Breit brauchbare Felder sollen registriert werden, damit öffentliche Definitionen nicht kollidieren. Die Tags 128 bis 254 bleiben standortspezifisch. Sie ermöglichen lokale Anpassung, sind aber nur innerhalb der jeweiligen Vereinbarung verständlich. Eine gemeinsame Rahmung schafft keine gemeinsame Semantik.

Diese Konstruktion macht kleine Ergänzungen günstig und einen Austausch der Hülle teuer. Sobald Firmware, Server und Verfahren die gleichen Codes und Ausnahmefälle erwarten, lässt sich ein neuer Tag leichter einführen als ein neues Format. Erweiterbarkeit innerhalb der Grenze kann die Grenze selbst langfristig verfestigen.

Zentrale Pflege ist keine Dienst-Authentisierung

RFC 1048 stellt die zentrale BOOTP-Tabelle verteilten Entdeckungsverfahren gegenüber. Wenn eine Antwort alle nötigen Angaben liefert, ist das effizient: Der Client kann aus einer lokalen Tabelle weiterarbeiten. Zugleich kann zentral gepflegte Information unvollständig oder veraltet sein.

Wer die BOOTP-Datenbank verwaltet, kontrolliert die dort veröffentlichten Startwerte. Daraus folgt nicht die Identität des eingetragenen Dateiservers oder die Integrität seines Images. Der RFC sagt ausdrücklich, dass die BOOTP-Tabelle für starke Dateiserver-Authentisierung nicht genügt; der jeweilige Dienst muss sie selbst leisten.

Ein erfolgreicher Start enthält mehrere getrennte Nachweise: lesbare Syntax, Transaktionszuordnung, eine Serverquelle, den Inhalt einer administrierten Tabelle und den Erfolg des Folgedienstes. Wer alles „gültiges Cookie“ nennt, verliert die Möglichkeit, Syntaxfehler, falsche Daten, falsche Herkunft und Dienstfehler auseinanderzuhalten.

RFC 1542 empfiehlt sogar für eine Anfrage ohne Optionen Cookie, End und Nullfüllung. So erkennt der Server das gewünschte Antwortformat. Es ist eine nahezu inhaltslose Formatansage und gerade deshalb keine Berechtigung.

DHCP erbte die Form, nicht die Gewähr

RFC 1533 verwendet für DHCP-Optionen das BOOTP-Erweiterungsformat: Tag, Länge und Wert mit Pad und End als Ausnahmen. Cookie, Netzwerkbytefolge und der standortspezifische Bereich bleiben erhalten. RFC 2132 dokumentiert später einen ausgebauten DHCP-Katalog in dieser Linie.

Die Dokumente belegen eine Formatabstammung. Sie erlauben nicht, spätere DHCP-Praxis in jede BOOTP-Installation von 1988 zurückzulesen oder unveränderte Semantik jeder Option zu behaupten. RFC 1533 hält zudem fest, dass Sicherheitsfragen dort nicht erörtert werden. Die Hülle setzte sich fort, ohne Herkunftsgewähr zu erwerben.

Die dauerhafte Leistung von RFC 1048 ist präziser. Vier Oktette wählen eine Leseordnung, Längen halten Unbekanntes begrenzt, Pad und End steuern den Weg, und der kleine Raum zwingt zu verantworteter Auswahl. Identität, Aktualität, Autorisierung und Diensterfolg bleiben Aufgaben anderer Kontrollen.

Quellen und Beweisgrenzen

RFC 951 liefert BOOTP, das 64-Oktett-Feld und die Empfehlung einer magischen Zahl. RFC 1048 definiert Cookie, Grammatik, Reihenfolge, Vergabe und Größenlimit. RFC 1084 sowie RFC 1497 halten spätere BOOTP-Fassungen fest. RFC 1533, RFC 1542 und RFC 2132 zeigen DHCP-Linie und Sicherheitsgrenze.

Diese Quellen belegen Spezifikation und Dokumententwicklung. Sie messen weder historische Verbreitung noch die Konfiguration eines bestimmten Netzes und garantieren nicht, dass jede Implementierung unbekannte Tags sicher übersprang.