Zusammenfassung

  • DHCP kann file und sname für zusätzliche Optionen verwenden, wenn Option 52 dies ausdrücklich erklärt. Die Felder bleiben am selben Ort, erhalten aber eine andere Interpretation.
  • Mehr Feldraum und die Aufteilung eines langen Werts sind getrennte Mechanismen. RFC 3396 rekonstruiert Teile in der logischen Reihenfolge options, file, sname statt in ihrer physischen Paketfolge.
  • Die gemeinsame Regel macht die Auslegung eindeutig, aktualisiert jedoch keine alten Empfänger. Korrekte Rekonstruktion beweist außerdem weder die Vertrauenswürdigkeit der Konfiguration noch einen erfolgreichen Start.

Der Empfänger konnte die neue Ordnung noch nicht kennen

Im November 2002 enthielt RFC 3396 eine betriebliche Warnung: Viele damals eingesetzte DHCP-Agenten implementierten die Verkettung von Optionen nicht. Ein Sender sollte Werte deshalb nicht ohne Not aufteilen, sofern er nicht wusste, dass sein Gegenüber sie korrekt zusammensetzen konnte.

Das war kein abstraktes Plädoyer gegen Erweiterungen. Die Spezifikation definierte gerade eine solche Erweiterungsregel. Sie trennte aber die gemeinsame Beschreibung vom Zustand laufender Programme. Ein veröffentlichtes Verfahren änderte die Routinen eines entfernten Startprogramms nicht automatisch.

Ein Teilnehmer konnte Fähigkeit annehmen, wenn sein Gegenüber eine Option anbot oder anforderte, deren Definition die Verkettung voraussetzte. Eine ausdrücklich konfigurierte Annahme des Administrators war ebenfalls möglich. Daraus entstand kein neues universelles Fähigkeitsbit. Und die Aussage über damalige Installationen ist keine Statistik über heutige Geräte.

Um den Grund für diese Vorsicht zu verstehen, muss man zwei ältere Entscheidungen auseinanderhalten: Wo durften zusätzliche Optionen liegen, und wie wurden mehrere Vorkommen wieder zu einem Wert? Mehr Platz beantwortete nur die erste Frage.

Das Paket war ursprünglich für den Systemstart geordnet

BOOTP sollte einem Rechner helfen, der noch nicht über seine vollständige Betriebsumgebung verfügte. RFC 951 vom September 1985 reservierte in einem festen Format Plätze für Adresse, Server und Startdatei.

sname bot 64 Oktette für einen optionalen Server-Hostnamen. file enthielt 128 Oktette für den Namen der Startdatei. Beide waren nullterminierte Zeichenketten. Ein weiterer Bereich, vend, stellte 64 Oktette für herstellerspezifische Informationen bereit.

Feste Positionen erleichterten einem kleinen Startprogramm das Auffinden dieser Daten. Die später geliehenen Felder waren also keine bedeutungslosen Lücken. Ihre alte Aufgabe musste berücksichtigt werden, wenn ihr Platz einen neuen Zweck erhielt.

DHCP übernahm das Gerüst und erweiterte die Konfiguration. In RFC 2131 vom März 1997 blieb die Größe der Namensfelder erhalten, während options variabel wurde. Clients mussten ein Optionsfeld von mindestens 312 Oktetten empfangen können; größere Nachrichten konnten über einen anderen Mechanismus ausgehandelt werden.

Diese Kapazität ist nicht mit der Datenlänge eines einzelnen Optionsvorkommens zu verwechseln. Dessen übliches Längenoktett kann höchstens 255 Datenoktette ausdrücken. Das begrenzt nicht für sich allein die ganze DHCP-Nachricht.

Die geliehene Fläche brauchte eine ausdrückliche Erklärung

Option Overload war bereits im Oktober 1993 in RFC 1533 definiert. Der Optionscode 52 trägt einen einoktettigen Wert: 1 erklärt file zum Optionsbereich, 2 erklärt sname dazu und 3 wählt beide.

Die Erklärung betrifft die ausgewählten Felder der jeweiligen Nachricht. Sie erlaubt nicht, beliebige unleserliche Bytes als Optionen zu behandeln, und ändert nicht dauerhaft die Bedeutung späterer Pakete. Ein nicht ausgewähltes Feld gehört nicht zum zusätzlichen Optionsraum.

RFC 2131 verlangt, dass diese Erklärung im gewöhnlichen options-Feld steht. Dieses wird zuerst gelesen. Danach folgen gegebenenfalls file und anschließend sname. Der Empfänger erfährt die neue Auslegung somit an einer Stelle, deren Grammatik er bereits kennt.

Andernfalls entstünde ein Zirkelschluss: Um die Erlaubnis für eine neue Feldinterpretation zu finden, müsste er das betreffende Feld schon nach dieser neuen Interpretation lesen. Der gemeinsame Ausgangspunkt vermeidet das Raten.

Der Sender kann örtlich entscheiden, ob er den Platz braucht. Wie er diese Entscheidung für den Empfänger erkennbar macht, ist dagegen keine private Konvention. Genau diese kleine Einschränkung ermöglicht die größere Freiheit bei der Belegung.

Die Feldgrenze blieb eine harte Grenze

Das gewöhnliche Optionsfeld beginnt mit einem vieroktettigen Magic Cookie. Danach folgen markierte Einträge. Eine übliche variable Option besitzt Code, Länge und die angegebene Zahl von Datenoktetten; Code und Längenoktett zählen nicht zur Datenlänge. Pad und End sind einoktettige Ausnahmen.

In einem umgenutzten file- oder sname-Feld beginnt die Optionsfolge am ersten Oktett. Dort wird kein zweiter Cookie vorgeschaltet. Jedes verwendete Feld muss seine Optionen mit End abschließen und den Rest mit Pad füllen. Ein einzelnes codiertes Optionsvorkommen muss vollständig in einem Feld bleiben.

Das Vorhandensein von Platz im Nachbarfeld erlaubt also kein physisches Überlaufen. Umgekehrt bedeutet End in einem Bereich nicht, dass alle anderen erklärten Bereiche ignoriert werden sollen. Das Ende eines Behälters ist etwas anderes als das Ende aller logisch zusammengehörenden Konfiguration.

Zusammen bieten file und sname 192 rohe Feldoktette, aber keine garantierten 192 zusätzlichen Nutzdatenoktette. Kennungen, Längen, Abschlüsse, Füllung und gegebenenfalls verlagerte Startinformationen verbrauchen Kapazität. Die Umnutzung ist begrenzt; sie ist weder unendliche Erweiterung noch IP-Fragmentierung.

Der alte Name durfte anderswo weiterleben

Die Wiederverwendung musste die ursprüngliche Information nicht löschen. RFC 2132 vom März 1997 definiert Option 66 für einen TFTP-Servernamen, wenn sname als Optionsraum dient, und Option 67 für den Startdateinamen bei umgenutztem file.

Damit kann ein Parameter seine feste Position verlassen und als markierter Wert erscheinen. Ein Werkzeug, das ausschließlich nach einer lesbaren Zeichenkette im alten Feld sucht, kann eine Verlagerung fälschlich als fehlende Konfiguration melden.

Das aktuelle IANA-Verzeichnis für BOOTP/DHCP führt diese Codes und die spätere Domain-Search-Option 119. Es handelt sich um Optionsnummern, nicht um Transportports. Dass 67 zugleich als UDP-Portnummer des DHCP-Servers vorkommt, verbindet die beiden Bedeutungen nicht.

Eine registrierte Option belegt auch nicht, dass eine Installation sie aktiviert hat. Ein übermittelter Dateiname beweist weder Existenz noch Abrufbarkeit oder Ausführungsberechtigung der Datei. Der Parameter hilft, einen späteren Vorgang vorzubereiten; sein Transport führt diesen Vorgang nicht aus.

Eine kurze Zeichenkette konnte trotzdem nicht hineinpassen

Eine lange Option kann mehr als 255 Datenoktette benötigen. Dann reichen zusätzliche Felder allein nicht aus: Das Längenoktett eines einzelnen Vorkommens bleibt zu klein. Ein zweiter Fall betrifft Werte unterhalb dieser Grenze, die nicht mehr in den Rest des aktuellen Feldes passen, wohl aber verteilt in mehrere erlaubte Bereiche.

Ted Lemon und Stuart Cheshire behandelten beide Fälle in RFC 3396. Das Dokument entfernte ausdrücklich den Satz aus RFC 2131, der Optionswiederholungen grundsätzlich beschränkte, und regelte die Aufteilung und Verkettung. Diese spätere Präzisierung darf nicht rückwirkend als überall bereits umgesetztes Verhalten gelten.

Jeder Teil trägt denselben Optionscode und seine eigene Länge. Die Datenlängen ergeben zusammen die Länge des vollständigen Werts. Der Empfänger fügt die Daten ohne ihre Code- und Längenrahmen zusammen. Er darf nicht nur das erste oder letzte Vorkommen verwenden und die Teile nicht als eigenständige Objekte behandeln.

Das Beispiel /diskless/foo umfasst nur dreizehn Oktette. Es kann in sieben und sechs zerlegt werden, wobei die Trennung mitten in diskless liegt. Der Schnitt markiert keine Verzeichnisgrenze und erzeugt keine zwei Dateinamen. Seine Position hat keine semantische Bedeutung.

Das erklärt auch, weshalb Überladung und Verkettung getrennt bleiben. Geliehene Felder können vollständige Optionen enthalten. Mehrere Teile einer langen Option können vollständig im gewöhnlichen options-Feld liegen. Der eine Mechanismus bestimmt zulässige Ablageorte, der andere die Rekonstruktion eines Werts.

Die Reihenfolge des Lesens wurde ausdrücklich vereinbart

Im physischen Format steht sname vor file, und beide stehen vor options. Der logische Gesamtpuffer aus RFC 3396 folgt jedoch options, file, sname. Nicht zur Umnutzung ausgewählte Felder werden ausgelassen.

An den tatsächlichen Feldpositionen ändert sich nichts. Ein Parser, der das Paket von vorne nach hinten durchläuft und passende Vorkommen sofort aneinanderhängt, kann deshalb bei feldübergreifend verteilten Teilen die falsche Reihenfolge herstellen.

Zuerst wird die Erklärung gelesen, dann die Folge der erlaubten Bereiche festgelegt und schließlich der jeweilige Optionsinhalt zusammengesetzt. Der Zufall einer lokalen Schleifenstruktur darf nicht entscheiden, welcher Dateiname oder welche Konfiguration beim Empfänger entsteht.

Trotz des logischen Gesamtpuffers bleibt jedes codierte Vorkommen innerhalb seines Feldes. Die Abstraktion hebt die ursprünglichen Wände nicht auf. Sie beschreibt, wie getrennt gespeicherte Stücke einen gemeinsamen Sinn erhalten.

Ein einfacher Sender brauchte nicht nur einfache Eingaben

Die Kompatibilitätswarnung von 2002 erlaubte es Implementierungen, gewöhnliche Optionen gar nicht aufzuteilen. Ein Programm konnte sich beim Senden auf Optionen beschränken, deren Definition Verkettung verlangte. Das verringerte die Zahl eigener komplizierter Ausgaben.

Sobald es eine solche Option unterstützte, musste es jedoch auch empfangene Teile anderer Optionen zusammenfügen können. Eine bewusste Beschränkung der eigenen Ausgabe verkürzte nicht beliebig die gültige Eingabesprache des Gegenübers.

Das ist ein wichtiger Unterschied zwischen Implementierungspolitik und Protokollbedeutung. Ein Sender kann Kapazitätsgewinn gegen Kompatibilitätsrisiko abwägen. Ein Empfänger darf eine gültige Folge nicht eigenmächtig in mehrere Werte oder eine Überschreibung umdeuten.

Ein Zeiger braucht zuerst das richtige Ganze

Die im selben Monat veröffentlichte RFC 3397 zeigt eine konkrete Abhängigkeit. Die Domain-Search-Option 119 transportiert DNS-Suchlisten, kann mehrere Optionsvorkommen nutzen und spart wiederkehrende Namenssuffixe durch Kompression.

Ihre Zeiger beziehen sich auf die vollständig verketteten Optionsdaten. Sie beginnen weder am DHCP-Paketanfang noch bei jedem einzelnen Teil neu. Die jeweiligen Code- und Längenoktette gehören nicht zum Bezugssystem.

Deshalb muss die logische Rekonstruktion vor der Namensinterpretation erfolgen. Ein Teil kann mitten in einem Label enden; er ist dann noch kein vollständiger Gegenstand, auf den man isoliert alle Abschlussregeln anwenden könnte. Die obere Interpretation hängt davon ab, dass die untere das richtige Ganze hergestellt hat.

Damit wird hier nicht die gesamte Geschichte der DNS-Kompression wiederholt. Der Fall zeigt lediglich, wie eine falsche Zusammensetzung Bedeutung verändern kann, obwohl einzelne Längen zunächst plausibel aussehen.

Korrektes Zusammensetzen schafft außerdem kein Vertrauen. RFC 3397 weist darauf hin, dass eine Suchliste einen kurzen Namen zu einer anderen vollständigen Domain führen kann, selbst wenn deren Daten gültige DNSSEC-Signaturen tragen. Eine formal richtige Konfiguration beweist nicht, dass ihr Sender den Benutzer dorthin lenken darf.

Die geliehenen Bytes wurden durch eine klare gemeinsame Auslegung brauchbar. Ihre Geschichte handelt deshalb nicht nur von Platzgewinn, sondern von der Fähigkeit alter und neuer Teilnehmer, denselben Inhalt aus derselben Nachricht zu gewinnen.