Zusammenfassung

  • Option 60 liefert einen auslegungsbedürftigen Klassenhinweis, 61 einen Schlüssel für die Adressbindungsdatenbank, 55 eine Parameteranforderung und 43 undurchsichtige herstellerspezifische Angaben.
  • Ein Mitschnitt belegt beobachtete Bytes an einem Punkt des Austauschs, nicht Hersteller-Echtheit, dauerhafte physische Identität, installierte Konfiguration oder funktionierenden Dienst.

Es ist verführerisch, die erste DHCP-Anfrage eines Rechners als Inventareintrag zu lesen. Eine Zeichenfolge sieht wie ein Herstellerschild aus, eine andere wie eine Seriennummer, dahinter folgt eine sortierte Liste von Anforderungen. Doch der Server prüft mit diesen Angaben nicht ein und dieselbe Tatsache. Der 1997 veröffentlichte RFC 2132 von Steve Alexander und Ralph Droms machte aus einer kompakten Optionssyntax mehrere getrennte Entscheidungskanäle.

Das äußere Format baut auf BOOTP auf: Üblicherweise folgt auf einen Optionscode ein Längenbyte und dann die angegebene Anzahl Datenbytes; Pad und End sind Sonderfälle. Im BOOTP-Herstellerfeld wählt ein vier Oktette langer Magic Cookie die Auslegung des folgenden Bereichs. Der ältere RFC 1048 lieferte dafür die Grundlage. Eine solche Grenze hilft dem Parser, unbekannte Felder zu überspringen. Sie beglaubigt weder Sender noch Inhalt.

Option 60 enthält eine vom Client optional gesendete Herstellerklassen-Zeichenfolge. Der Server interpretiert sie als Hinweis auf Typ oder Konfiguration. Kann er die klassenspezifische Angabe nicht deuten, muss er sie ignorieren, darf sie aber melden. Antwortet er mit herstellerspezifischen Angaben, sollte er Option 43 verwenden. Der Hinweis kann also eine Konfigurationsregel auswählen. Er ist weder ein unabhängiger Herkunftsnachweis der Hardware noch ein Befehl an den Server.

Option 43 enthält undurchsichtige Daten, deren Bedeutung im Bereich des jeweiligen Herstellers liegt. Für mehrere Elemente empfiehlt der RFC eine innere Folge aus Code, Länge und Wert. Innere Codes können dort anders definiert sein als die globalen DHCP-Optionsnummern. Auch End hat eine kleinere Reichweite: Es beendet die gekapselten Erweiterungen und nicht das gesamte äußere Optionsfeld. Fehlt ein inneres End, begrenzt die Länge des umschließenden Feldes die Interpretation. Ein Empfangsprotokoll, das diese Grenzen einebnet, kann eine private Aussage fälschlich zur globalen machen.

Die gesendete Antwort beweist noch nicht ihre Anwendung auf dem Client.

Option 61 hat eine andere Aufgabe. DHCP-Server indizieren damit ihre Datenbank von Adressbindungen; sie sollen den Client-Identifier als undurchsichtig behandeln. Er kann aus Hardwaretyp und Adresse bestehen, muss es aber nicht. Auf dem angeschlossenen Subnetz muss er unter den verwendeten Client-Identifiern eindeutig sein; Hersteller und Administratoren tragen die Verantwortung für die Auswahl. Ein eindeutiger Datenbankschlüssel ist kein Authentisierungsverfahren. Derselbe Wert im Mitschnitt identifiziert nicht zwangsläufig denselben physischen Rechner oder Menschen über die Zeit.

Option 55 benennt Codes für gewünschte Konfigurationsparameter. Die Reihenfolge darf eine Präferenz ausdrücken. Der Server muss nicht in dieser Reihenfolge antworten, soll aber versuchen, angeforderte Optionen entsprechend einzufügen. Dass alle Wünsche zurückkommen, ist damit nicht zugesagt. Option 57 gibt zusätzlich die höchste DHCP-Nachrichtengröße an, die der Client annimmt; 576 Oktette sind das zulässige Minimum. Wunsch und Größenlimit beschreiben die Verhandlung, nicht die tatsächlich laufende Einstellung.

Der RFC 2131 trennt Ermittlung, Angebot, Anforderung, Bestätigung und anschließende Prüfung durch den Client. Wer ein Betriebsergebnis nachweisen will, braucht die zugehörige Folge, Serverrichtlinie und Bindung, den übernommenen Zustand am Client und einen Test des Dienstes. Die RFCs liefern weder Messungen einer benannten Installation noch eine Herstellerprüfung. RFC 2132 sagt in seinem Sicherheitsabschnitt ausdrücklich, Sicherheitsfragen würden nicht behandelt; aus diesem Schweigen entsteht keine Sicherheitsgarantie.

Die historische Leistung war eine erweiterbare gemeinsame Sprache für unterschiedliche Konfigurationsentscheidungen. Der Klassenhinweis, der Bindungsschlüssel, die Nachfrage und die private Antwort bleiben trotz gemeinsamer Verpackung getrennt. Heng Lus Gedanke der Vorrangstellung laufender Implementierungen dient hier als redaktioneller Blickwinkel: Eine Spezifikation und ein beobachteter Betrieb sind unterschiedliche Belege, nicht zusätzliche DHCP-Normen.

Quellen: RFC 2132, RFC 2131, RFC 1048 und Heng Lus Running-Code Primacy.