Zusammenfassung

  • RFC 3396 definierte wiederholte Instanzen eines DHCPv4-Codes als aufeinanderfolgende Teile eines logischen Werts, sei es wegen der 255-Oktett-Grenze oder wegen knappen Platzes in überladenen Feldern.
  • Die Rekonstruktion folgte der logischen Folge options, file, sname, nicht der physischen Feldfolge. Trennstellen trugen keine Semantik, und korrektes Senden bewies keine erfolgreiche Zusammensetzung beim installierten Empfänger.

In einem alten Paketformat können zwei Ordnungen gleichzeitig gelten. Die Felder liegen physisch an bestimmten Stellen. Ihre als Optionen genutzten Inhalte müssen aber in einer anderen Folge verstanden werden. RFC 3396 machte diesen Unterschied zur Pflicht für jeden DHCPv4-Parser.

Das Standards-Track-Dokument erschien im November 2002. Eine variable DHCP-Option bestand aus einem Oktett Code, einem Oktett Länge und höchstens 255 Oktetten Wert. Größere Objekte passten nicht in eine einzige Instanz.

RFC 2131 hatte bereits die Verkettung wiederholter Optionen erwähnt, aber ihre Reihenfolge nicht vollständig bestimmt. Zudem stand dort allgemein, eine Option dürfe nur einmal erscheinen, sofern kein Optionsdokument anderes sage. RFC 3396 strich diesen Satz. Gleicher Code bedeutete nun Teile, die vor der Verarbeitung zusammengehören.

Auch ein kürzerer Wert konnte geteilt werden, wenn im aktuellen Ausgabefeld nicht genug Raum blieb und ein anderes Optionsfeld noch Platz bot. Der Encoder musste dann das Verfahren anwenden oder die Option weglassen. Eine einzelne codierte Instanz durfte keine Feldgrenze überqueren.

Die drei Orte stammten aus BOOTP. Neben dem normalen Optionsbereich konnten bei Option Overload auch file und sname Optionen tragen. RFC 3396 bildete daraus einen logischen Gesamtpuffer: normale options, danach file, danach sname.

Ausdrücklich war dies nicht die physische Reihenfolge im Paket. Der Gesamtpuffer war eine Sicht zum Codieren und Decodieren, keine Änderung des Drahtformats. Ein Parser, der gleiche Codes nur nach Speicheradressen anhängte, konnte gültige Teile vertauschen.

Jeder Teil wurde wie eine normale variable Option codiert, trug denselben Code und höchstens 255 Wertoktette. Seine Längen addierten sich zum Gesamtwert. Die Teile mussten im logischen Puffer nacheinander stehen, unabhängig vom optischen Eindruck der Feldpositionen.

Geteilt werden durfte an jeder Oktettgrenze. Daraus folgte das Verbot, einer Grenze Bedeutung zu geben. Sie markierte weder Namen, Route, Unteroption noch Datensatz. Sie war lediglich eine Naht zwischen Behältern.

Der Decoder musste mehrere gleiche Codes in Gesamtpufferfolge verbinden und erst das Ergebnis als Option auswerten. Eine fragmentweise Interpretation erfand Objekte, die der Sender nicht mitgeteilt hatte. Auch die Speicherausrichtung musste der Empfänger selbst sicher handhaben; der Sender schuldete seiner CPU keine bequeme Trennstelle.

Das Beispiel teilte den Bootfile-Namen /diskless/foo in zwei Instanzen von Code 67. Weder /diskle noch ss/foo war ein eigener Name. Gerade die Kürze zeigte: Nicht extreme Größe, sondern logische Identität begründete die Regel.

Historisch entscheidend war der Hinweis, dass viele bereits eingesetzte DHCP-Agenten keine Verkettung implementierten. Ein normgerechter Sender konnte auf einen Empfänger treffen, der nur einen Teil las, Teile einzeln behandelte oder den Wert verwarf. Sendekonformität war kein Empfangsnachweis.

Der RFC unterschied deshalb verkettungspflichtige und andere Optionen. Pflicht entstand nur, wenn die definierende Spezifikation RFC 3396 ausdrücklich nannte. Sender sollten nur bei Notwendigkeit, bekannt fähigem Gegenüber oder administrativer Vorgabe teilen.

Wer mindestens eine Pflichtoption angefordert oder geliefert hatte, durfte als fähig gelten. Diese Annahme war begrenzt und garantierte nicht alle Größen und Parserpfade. Eine Implementierung durfte gewöhnliche Optionen nie teilen; unterstützte sie eine Pflichtoption, musste sie beim Empfang Wiederholungen beider Kategorien verbinden.

Auch die Authentifizierungsoption aus RFC 3118 konnte geteilt sein. Vor MAC-Erzeugung oder -Prüfung musste ihr Feld auf null gesetzt werden, selbst wenn es mehrere Instanzen überquerte. Wer Behälter statt logisches Objekt verarbeitete, konnte die falsche Darstellung absichern.

RFC 3397, RFC 3361, RFC 3442 und RFC 3925 nutzten die Grundlage für Domänensuche, SIP-Proxys, klassenlose Routen und Herstellerstrukturen. Deren Grammatik blieb eigenständig. RFC 3396 stellte davor den einen Wert wieder her.

Eine Aufzeichnung aller Fragmente beweist daher nur Übertragung am Messpunkt. Sie beweist nicht Overload-Erkennung, richtige Reihenfolge, Erhalt aller Duplikate, sichere Ausrichtung, Authentifizierung oder Anwendung. Jede Stufe benötigt einen eigenen Beleg.

Die heutige Errata-Suche meldet keinen Treffer für RFC 3396. Das beschreibt die Publikation, nicht Produkte. Der RFC selbst entstand, weil frühere Worte und laufender Code nicht von allein zusammenpassten.

Lu Hengs minimale Anfangsspezifikation erklärt die enge gemeinsame Regel: Codeidentität, Reihenfolge, Kontinuität und bedeutungslose Trennung. Der Vorrang laufenden Codes verlangt zusätzlich Tests mit unbequemen Grenzen, allen drei Feldern und nachweisbarer Anwendung.

RFC 3396 stellte Identität über Ort. Die Teile durften ungleich und verstreut sein. Die wichtigste Leistung des Empfängers war nicht, einen Teil besonders schnell zu verstehen, sondern ihn noch nicht zu verstehen, bevor das Ganze wieder existierte.

Quellen