Zusammenfassung

  • Version 03 von Mark Smiths individuellem Entwurf ergänzt eine Ausweichmöglichkeit für Clients, die DHCPv4 Router Option 3 verlangen: die eigene DHCP-Adresse des Hosts oder 127.0.0.1.
  • Der Entwurf erwartet, dass beide Werte IPv4-Pakete zu nicht lokalen Zielen auf dem Host halten und ICMP Destination Unreachable auslösen. Das ist eine Behauptung des Entwurfs, kein veröffentlichter Interoperabilitätsnachweis.
  • Die im LACNIC-Blog am 2. Oktober beschriebenen Betriebssystemtests bezogen sich auf Version 02 und lagen vor der neuen Option.

Analyse

Ein Standardgateway soll Verbindungen in ein anderes Netz führen. Eine neue Fassung eines DHCPv4-Entwurfs schlägt nun vor, dass dieses Feld bei manchen älteren Clients auf den Client selbst zurückzeigen kann.

Am 16. Oktober veröffentlichte Mark Smith Version 03 von „Nearly IPv6 Only Dual Stack Hosts“. Version 02 war am 15. Juni abgelaufen. Die neue Fassung hält an der Variante fest, Router Option 3 wegzulassen, sofern der Client das akzeptiert. Für Clients, die den Eintrag angeblich benötigen, nennt sie zusätzlich zwei Werte: die per DHCP zugeteilte eigene Host-Adresse oder 127.0.0.1.

Das ist kein gewöhnliches Gateway. RFC 2132 definiert Option 3 als Liste der Router, die ein DHCP-Server an einen Host übermittelt. Der Entwurf geht davon aus, dass die beiden selbstbezogenen Werte bei einer /32-Maske Pakete zu nicht lokalen IPv4-Zielen auf dem Host halten und unmittelbar ICMPv4 Destination Unreachable auslösen. Entscheidend ist, wie der jeweilige Client die Route interpretiert. Der Text veröffentlicht keine Testmatrix dazu, welche Clients welchen Wert annehmen, welche Routen sie einrichten oder ob Anwendungen anschließend IPv6 versuchen.

Die bisherigen Tests schließen diese Lücke nicht. Alejandro Acostas Beitrag im LACNIC-Blog vom 2. Oktober verweist auf Version 02 und nennt Windows 11, Fedora 43, Raspberry Pi OS auf Basis von Debian Trixie, Chromecast und Google Nest. Smartphones seien nicht getestet worden; weitere Tests seien nötig. Diese Beobachtungen stammen aus der Zeit vor Version 03 und bestätigen den neuen Router-Zweig nicht.

Ein Test sollte deshalb nicht bei der erfolgreichen DHCP-Übertragung enden. Betreiber sollten die Host-Adresse und 127.0.0.1 getrennt prüfen und nach Client, Betriebssystemversion sowie DHCP-Server- oder Relay-Konfiguration unterscheiden. Dazu gehören das DHCP ACK, die tatsächlich installierte Routingtabelle, Paketmitschnitte zu IPv4-Zielen außerhalb des Hosts, der Eingang des ICMP-Fehlers in der Anwendung und ein möglicher IPv6-Wiederholungsversuch. Ziele im selben Link sind separat zu prüfen: Eine Sperre gerouteter Verbindungen beweist nicht, dass lokale IPv4-Kommunikation ebenfalls endet.

Der Entwurf ersetzt DHCPv4 Option 108 nicht. RFC 8925 erlaubt einem kompatiblen Host, für eine bestimmte Zeit IPv6-only zu bevorzugen. Smiths Vorschlag richtet sich an Geräte, die diese Option nicht unterstützen oder weiterhin eine DHCPv4-Antwort erwarten. Die Änderung in Version 03 ist somit eine Kompatibilitätsfrage, kein neuer Standard.

Datatracker führt Version 03 als aktiven individuellen Internet-Draft ohne RFC-Stream und mit dem IESG-Status „I-D Exists“. Das Dokument erklärt, dass es weder von der IETF gebilligt wird noch formellen Status in deren Standardisierungsverfahren hat. Als angestrebter Status steht Informational im Text; das Dokument läuft am 19. April 2027 aus. Eine neue Fassung belegt, dass der Vorschlag weiterbearbeitet wird. Sie belegt nicht seine Übernahme durch die IETF oder Betriebssystemanbieter.

Für Netzbetreiber ist der neue Zweig ein begrenzter Testfall, keine fertige flächendeckende Konfiguration. Die beiden Router-Werte sollten in getrennten, rücksetzbaren Clientgruppen geprüft werden, bis Routingverhalten und IPv6-Fallback belegt sind. Ein erfolgreicher DHCP-Vorgang zeigt nur, dass ein Lease übermittelt wurde. Offen bleibt, wie der Host mit einem Gateway umgeht, das auf ihn selbst zeigt.

Quellen