Zusammenfassung

  • DHCPv4-Option 121 führte in RFC 3442 Routen mit expliziter Präfixlänge ein und korrigierte damit die klassenbasierte Annahme der älteren statischen Routenoption.
  • Ein unterstützender Client musste diese Routen installieren und bei gemeinsamem Empfang Router-Option und Option 33 vorziehen; der RFC warnte, dass ein falscher nächster Hop den Verkehr fehlleiten kann.

Eine Adress-Lease klingt nach Zuweisung: Das Netz teilt einem Host mit, welche Adresse er wie lange verwenden darf. Der Host muss aber auch wissen, wohin Pakete außerhalb des lokalen Links gehen sollen. RFC 3442 nahm diese zweite Entscheidung in den DHCP-Konfigurationsaustausch auf. Seine klassenlose Option für statische Routen konnte ein Zielpräfix und die Adresse des dafür zu verwendenden Routers übertragen.

Der Auslöser war ein Missverhältnis. DHCP-Option 33 aus RFC 2132 beschrieb statische Routen ohne eigene Maske für jedes Ziel. Dahinter stand die Annahme, dass sich die Netzgrenze aus der Adressklasse ableiten ließ. Klassenloses Routing hatte diese Annahme überholt: 10.0.0.0/8 und 10.0.0.0/24 sind unterschiedliche Ziele, auch wenn die ersten Oktette gleich aussehen. Der Client braucht die Präfixlänge, um zu wissen, welche Bits die Route bestimmen.

Option 121 kodierte diesen Umfang kompakt. Der Ziel-Deskriptor begann mit der Präfixlänge und enthielt nur die signifikanten Adressoktette; danach folgte eine vier Oktette lange Routeradresse. Vor der Installation rekonstruierte der Client das Ziel und setzte die Bits außerhalb der Maske auf null. RFC 3442 machte DHCP weder zu einem Routingprotokoll noch verteilte es eine Internet-Routingtabelle. Es erlaubte einem Administrator, einen ohnehin zur Hostkonfiguration verwendeten Server auch für ausgewählte statische Routen auf Clients zu nutzen.

Damit wanderte eine wichtige Entscheidung zwischen administrativen Ebenen. Die Routingtabelle blieb auf dem Host, und der Client verarbeitete die Konfiguration weiter nach eigenen Regeln. Eine Route konnte nun aber aus der DHCP-Serverkonfiguration stammen, statt lokal auf jedem Gerät eingetragen zu werden. Ein Client mit Option-121-Unterstützung musste die Routen installieren, abgesehen von einer Ausnahme für lokale Subnetze. Traf Option 121 gemeinsam mit der älteren Router-Option oder Option 33 ein, musste der Client diese älteren Werte ignorieren.

Auch die Reihenfolge der Anforderung war relevant: In der Parameter Request List musste 121 vor Router und Option 33 stehen.

Kompatibilität war Teil des Designs. Clients ohne Option-121-Unterstützung mussten sie ignorieren. Deshalb empfahl RFC 3442 Administratoren, auch die Router-Option zu senden und Angaben zum Standardrouter für ältere Clients zu wiederholen. Das war eine Übergangsstrategie, kein Beleg dafür, wie viele Geräte die neue Option unterstützten oder wie schnell sie sich verbreitete. Ein Standard kann eine Vorrangregel festlegen, aber nicht erzwingen, dass jeder Client sie implementiert.

Die Grenze hatte auch eine Sicherheitsfolge. RFC 3442 warnte ausdrücklich, dass eine falsche Routeradresse einen Denial-of-Service-Angriff auslösen oder den Verkehr über einen Lauscher führen kann. Das Risiko war nicht auf Option 121 beschränkt: Auch Router und die ältere Routenoption konnten auf den falschen nächsten Hop verweisen. Die Option bewies weder die Berechtigung noch die Korrektheit oder Sicherheit der vorgeschlagenen Route. DHCP-Nachrichtenauthentifizierung, sofern eingesetzt, war ein separates Verfahren und bestätigte nicht automatisch, dass die Routenentscheidung sinnvoll war.

Auch die Paketgröße prägte die Übertragung. Eine lange Routenliste konnte die herkömmliche DHCP-Nachrichtengröße überschreiten. RFC 3442 behandelte deshalb die Aushandlung größerer Nachrichten und verlangte Unterstützung für die Verkettung langer Optionen. Für gemeinsam genutzte Links mit mehreren IP-Subnetzen beschrieb der RFC außerdem den Sonderfall eines nächsten Hops 0.0.0.0, der ein direkt erreichbares lokales Subnetz bezeichnete. Clients ohne die erforderliche Stack-Funktion mussten diesen Eintrag ignorieren.

Der historische Schritt von RFC 3442 war begrenzt, aber aufschlussreich: Als Routing klassenlos wurde, musste auch die Adresskonfiguration den Umfang einer Route ausdrücken können. Die Lease wurde damit zu einem möglichen Träger lokaler Weiterleitungspolitik. Der Client blieb der Installationsort, aber DHCP-Administratoren wurden zu Akteuren der Routenauswahl — und der nächste Hop hatte Folgen über die Adressvergabe hinaus.

Quellen