Summary

  • Version 03 of Mark Smith's individual DHCP draft adds a fallback for clients that require Router Option 3: the DHCP address assigned to the host itself or 127.0.0.1.
  • The draft predicts those values will keep other IPv4 packets inside the host and produce ICMP Destination Unreachable. That is a proposal, not a published interoperability result.
  • The operating-system tests discussed by the LACNIC Blog were reported on 2 October against version 02, before the new fallback appeared.

Analysis

A default gateway is supposed to lead somewhere. A new revision of a DHCPv4 draft now suggests that, for some older clients, the field may instead point back to the client itself.

On 16 October, Mark Smith posted version 03 of “Nearly IPv6 Only Dual Stack Hosts.” Version 02 had expired on 15 June. The revised draft keeps its original route for clients that accept no DHCP Router Option 3, but adds a conditional alternative for clients said to require one: provide the host's own DHCP-assigned address, or 127.0.0.1, as the router value.

These are not ordinary gateways. RFC 2132 defines Option 3 as the list of routers a DHCP server supplies to a host. Smith's draft says that under a /32 mask, either self-referential value should keep packets for non-local IPv4 destinations within the host and cause an ICMPv4 Destination Unreachable response. It is a practical claim about client routing behavior. The draft does not publish a test matrix showing which clients accept either value, what routes they install, or whether applications then retry over IPv6.

The older evidence is easy to overextend. Alejandro Acosta's 2 October LACNIC Blog post links to version 02 and reports tests on Windows 11, Fedora 43, Raspberry Pi OS based on Debian Trixie, Chromecast and Google Nest. It says smartphones had not been tested and calls for more testing. Those observations predate version 03; they cannot validate its new Router Option branch.

The right test is not only whether a DHCP server can send the value. Operators need to compare the two proposed values across client and operating-system versions and server or relay configurations. A useful record would include the DHCP ACK, the host's installed route table, packet captures for off-host IPv4 destinations, whether the operating system returns the expected ICMP error, and whether applications fall back to IPv6. Same-link destinations need a separate check because suppressing routed IPv4 does not establish what local applications can still reach.

The draft also sits beside, rather than replaces, DHCPv4 Option 108. RFC 8925 lets a capable host signal that it prefers IPv6-only operation for a period. This proposal is aimed at clients that do not support that option or still require a DHCPv4 answer. Version 03 therefore raises a compatibility question, not a new standard.

Datatracker lists version 03 as an active individual Internet-Draft, with no RFC stream and an IESG state of “I-D Exists.” The document says it is not endorsed by the IETF and has no formal standing in its standards process. Its intended status is Informational; the text expires on 19 April 2027. A revised draft is evidence that a proposal is being maintained, not that the IETF or operating-system vendors have adopted it.

For network teams, this is a testable branch, not a safe default. Keep the host-address and loopback values as separate cases in a limited pilot until route behavior and application fallback have been measured. A successful DHCP exchange establishes only that a lease was delivered. The question is whether the host behaves as the draft expects.

Sources