Zusammenfassung

  • RFC 3011 erlaubte einem DHCP-Anforderer, ein Zuteilungssubnetz zu nennen, das nicht dem Netz entsprach, über das die Nachricht den Server erreichte.
  • Die identische Rückgabe von Option 118 war nur ein enger Verarbeitungsbeleg; sie bewies weder Identität und Poolberechtigung noch Route, Konfliktfreiheit oder tatsächlich erbrachten Dienst.

DHCP nutzte Topologie als praktische Abkürzung. Nach RFC 2131 konnte ein Server das Zuteilungsnetz aus giaddr ableiten. War das Feld null, wies die lokale Empfangsschnittstelle den Weg. Die Stelle, an der eine Nachricht sichtbar wurde, bestimmte in der Regel den Adresspool.

Ein Remote-Access-System passte nicht in diese Gleichung. Es erreichte den DHCP-Server über ein internes Netz, verwaltete aber Adressen für Teilnehmer auf externen Netzen. Zwischen intern und extern musste nicht einmal IP-Konnektivität bestehen. Die Anfrage konnte nur intern entstehen, obwohl die Adresse extern zugeteilt werden musste.

RFC 3011 veröffentlichte im November 2000 dafür die IPv4 Subnet Selection Option. Ihr Wert ist eine vier Oktette lange Subnetzadresse: Eine Adresse des Zielnetzes wird mit der Maske verknüpft, sodass die Hostbits null werden. Im heutigen IANA-Register für BOOTP/DHCP steht sie weiterhin als Option 118 mit Länge vier.

Für einen entsprechend konfigurierten Server war dieser Wert keine bloße Empfehlung. Er ging der normalen Auswahl über giaddr oder Empfangsschnittstelle vor. Die angebotene Adresse musste aus dem bezeichneten Subnetz oder aus einem anderen Subnetz desselben Netzsegments stammen. Außerhalb dieser Grenze durfte der Server nichts anbieten.

Damit wurden Beobachtung und Anweisung sichtbar getrennt. Der interne Eingangsweg blieb eine wahre Messung. Die Option behauptete eine andere Zuteilungsfläche. Erst die lokale Serverrichtlinie entschied, ob diese Behauptung die Poolwahl steuern durfte.

Der Rückweg war ein drittes Problem. Bei einer Erneuerung konnte ein Server versuchen, das DHCPACK an die zugeteilte Adresse zu senden, obwohl dieses externe Netz aus der internen Steuerungsumgebung nicht erreichbar war. Deshalb musste jede Nachricht mit Option 118 in giaddr eine IPv4-Adresse angeben, unter der der Anforderer DHCP-Pakete akzeptierte. Das Netz der Ressource und das Ziel der Antwort blieben verschieden.

RFC 3011 baute außerdem einen Kompatibilitätsbeleg ein. Ein aktiv unterstützender Server musste die Option identisch zurückgeben, unabhängig davon, ob sie in der Parameter Request List stand. Ein Client, der den Mechanismus nutzte, musste DHCPOFFER oder DHCPACK ohne diese Option verwerfen.

So wurde ein gefährlicher Scheinerfolg verhindert. Ein älterer Server konnte den unbekannten Code ignorieren und aus dem internen Pool anbieten. Ein neuer Server mit deaktivierter Funktion konnte dasselbe tun. Beide Antworten konnten formal gültig sein, ohne den gewünschten Auswahlvertrag auszuführen. Das fehlende Echo machte diese Nichtübereinstimmung erkennbar.

Das Echo war dennoch kein Vollbeweis. Es bestätigte eine bestimmte Verarbeitung, nicht den Betreiber oder die Berechtigung des Access-Systems. Es installierte keine Route, prüfte keinen Adresskonflikt und belegte keine Übergabe an den Teilnehmer. Die identischen Bytes waren ein Protokollbeleg, kein Eigentums- oder Ergebnisnachweis.

Die Sicherheitsfolge war erheblich. DHCP stellte damals selbst keine Authentisierung bereit. Wer entfernte Subnetze benennen konnte, war bei einem Pool-Erschöpfungsangriff nicht mehr auf das lokale Netz beschränkt. Ein kleiner Steuerwert vergrößerte die erreichbare Knappheit.

Deshalb sollte die Funktion standardmäßig ausgeschaltet sein. Ein Betreiber musste sie bewusst aktivieren und nach Client-ID, Herkunftsnetz oder erlaubten Zielsubnetzen beschränken können. Die Spezifikation machte den Wunsch interoperabel; sie erklärte nicht jeden Absender zum berechtigten Entscheider.

RFC 2132 lieferte die Code-Längen-Wert-Grammatik. RFC 3011 gab Code 118 eine gemeinsame Semantik. Lesbarkeit und Befugnis blieben zwei Schichten. Ein korrekt aufgebautes Feld verpflichtet den Server erst dann, wenn lokale Regeln es zulassen.

Spätere Standards verlagerten eine verwandte Aussage zum vom Betreiber kontrollierten Relay. RFC 3046 definierte Relay Agent Information mit lokalen Circuit- und Remote-IDs. RFC 3527 ergänzte Link Selection, wenn das Zuteilungssegment von der Adresse abwich, über die der Server das Relay erreichen sollte.

Trafen Client-Option 118 und Relay-Link-Selection zusammen, hatte die Relay-Angabe Vorrang. Nicht die Form des Vier-Oktett-Werts entschied, sondern die Vertrauensposition des Sprechers. Ein administriertes Relay konnte anders gebunden werden als ein beliebiger Client.

Auch dort war eine wiederkehrende Suboption nicht automatisch ein Verstehensbeleg, weil ein Relay-Agent-Container kopiert werden konnte. RFC 3527 verlangte administrativ gesicherte Kompatibilität. RFC 3118 beschrieb DHCP-Authentisierung, doch die Veröffentlichung eines Verfahrens beweist nicht seine Nutzung.

RFC 7969 ordnete später die topologieabhängige DHCP-Anpassung. Subnet Selection, Link Selection und Virtual Subnet Selection behandeln unterschiedliche Schnitte. Eingang, physischer Link, logisches Netz, VPN, Pool und Antwortziel waren nicht länger in einem Ortsbegriff darstellbar.

Eine belastbare Spur hält daher Empfangsschnittstelle, beobachtete Quelle, giaddr, Client-ID, Option 118, angewandte Richtlinie, Pool, Angebot, Echo und Antwortziel getrennt fest. Lease, Route, Nachbarschaft, Teilnehmerzustand und Anwendungsergebnis folgen als eigene Belege.

Aus Lu Hengs Perspektive der Running-Code-Primacy war RFC 3011 eine kleine Anfangsspezifikation. Sie änderte bei lokaler Zustimmung genau einen Auswahlwert, ohne ein globales Zuteilungsregime zu schaffen. Der öffentliche Code ermöglichte Koordination; die laufende Konfiguration zeigte, wer tatsächlich handeln durfte.

Die Nachricht kam aus dem internen Netz. Die Adresse gehörte in das externe. Die Antwort brauchte weiterhin einen erreichbaren Weg. RFC 3011 bewahrte alle drei Tatsachen, statt sie in einer scheinbar selbstverständlichen Topologie zusammenzufalten.

Sources