Zusammenfassung

  • RFC 3925 ermöglichte es DHCPv4, Daten mehrerer Hersteller mit klaren Grenzen in derselben Nachricht zu transportieren.
  • Es registrierte die äußeren Optioncodes, überließ die inneren Unteroptioncodes und ihre Bedeutung aber den Herstellern. Eine PEN kennzeichnet einen Namensraum, sie authentisiert keine Aussage.

Der übliche Weg für herstellerspezifische Informationen in DHCPv4 war lange eng umrissen. Option 60 aus RFC 2132 erlaubte dem Client eine Herstellerklassen-Zeichenfolge; Option 43 transportierte ein undurchsichtiges, vom Hersteller definiertes Objekt. Der Server interpretierte Option 43 im Kontext des durch Option 60 bezeichneten Herstellers. Das funktionierte, solange die Begriffe eines Herstellers genügten. Mehrdeutig wurde es, wenn ein Gerät oder ein Branchenprofil unabhängig definierte Informationen mehrerer Hersteller benötigte. RFC 3925 beschreibt ein Problem der Rahmung, keinen Ausfall der DHCP-Adressvergabe.

Die Antwort war ein neues Optionspaar. Option 124, Vendor-Identifying Vendor Class, und Option 125, Vendor-Identifying Vendor-Specific Information, stellen jeder Herstellerinformation eine IANA Private Enterprise Number voran. Option 125 kann mehrere Einträge enthalten: Unternehmensnummer, Länge und herstellerspezifische Bytes. Die Länge grenzt die Daten ab, die Nummer wählt den Herstellerkontext. RFC 3925 lässt die alten Optionen 60 und 43 ausdrücklich unverändert; eine Implementierung kann also beide Formen antreffen.

Darin liegt die Trennung von Registrierung und Bedeutung. IANA vergibt den äußeren DHCP-Optioncode. Das Enterprise-Numbers-Register vergibt die Nummer, die den Namensraum eines Herstellers bezeichnet. Keines der Register definiert den Sinn der Nutzlast. Die inneren Unteroptionen verwenden zwar Code/Länge/Wert-Felder, doch RFC 3925 sagt ausdrücklich, dass die Hersteller ihre Unteroptionscodes festlegen und IANA sie nicht verwaltet. Der Standard schuf einen Rahmen, in dem mehrere Dialekte getrennt bleiben können, kein gemeinsames Wörterbuch zu ihrer Übersetzung.

Auch die Paketlänge setzt Grenzen. Da die aggregierten Daten die maximale Länge einer einzelnen Option überschreiten können, erklärt RFC 3925 die Optionen 124 und 125 gemäß RFC 3396 für verkettungspflichtig. Der Empfänger fügt wiederholte Fragmente zuerst zu einer logischen Option zusammen und interpretiert erst dann die Einträge. Er sollte nicht jedes Fragment als neuen Herstellereintrag behandeln. Die Spezifikation empfiehlt, dass jede Unternehmensnummer über alle Instanzen hinweg nur einmal vorkommt; bei Wiederholung ist das Verhalten undefiniert.

Der Rahmen erlaubt Mehrfachangaben, macht aber nicht jede fehlerhafte oder wiederholte Kombination sinnvoll.

RFC 3925 übernahm das Muster der Herstellerklassen- und herstellerspezifischen Optionen für DHCPv6 aus RFC 3315. Das ist eine dokumentierte Wiederverwendung des Entwurfs, kein Beleg für gleiche Nutzlastbedeutungen oder Verbreitung in beiden Protokollfamilien. Die Erweiterung authentisiert auch keinen Hersteller: RFC 3925 selbst bietet keine Sicherheit; RFC 3118 beschreibt einen getrennten DHCP-Authentisierungsmechanismus, der bei Bedarf genutzt werden kann. Eine Nummer in einer Option ist ein Namensraum-Auswahlmerkmal, keine Signatur.

Darum ist RFC 3925 historisch interessant: Es machte die Grenzen für Koexistenz explizit und ließ die lokale Bedeutung zugleich lokal. Das äußere Register hilft, einen Container zu parsen und seinen Namensraum zu benennen. Es sagt dem Client aber nicht, was ein herstellerspezifisches Byte bewirkt, ob ein Gerät tatsächlich zu diesem Hersteller gehört oder ob eine Implementierung die Option unterstützt. Dafür braucht es andere Belege. Die RFCs und IANA-Register zeigen Entwurf und Codepunkt-Zuweisungen; sie messen weder Verbreitung noch Interoperabilität oder Betriebsergebnisse.

Quellen