Summary

  • A DHCPv4 /32 mask plus an omitted router option can satisfy a legacy client while removing its ordinary off-link IPv4 route.
  • That quiets one source of repeated discovery; it does not release the client’s unique lease or block packets arriving from its link.

Quieting a request is not the same as releasing an address

An old dual-stack device can ask for IPv4 long after an operator has decided that its applications should use IPv6. Simply refusing to answer may leave the client making further unsatisfied DHCPv4 requests. LACNIC’s 2 October technical blog points to a narrower workaround in an individual Internet-Draft: answer the request using familiar DHCPv4 fields, but configure the resulting interface so it has no ordinary route to another IPv4 destination.

The recipe is deliberately simple. DHCPv4 option 1 supplies a 255.255.255.255 subnet mask, or /32. The server omits option 3, which would tell the host about a router. With the /32 mask, every other IPv4 destination is off-link. With no router supplied, the host has nowhere to send that off-link traffic. The client has received the IPv4 configuration it asked for, so the repeated discovery problem may stop; its ordinary off-link IPv4 path does not follow.

That is a useful compatibility boundary, not proof that the computer has become an IPv6-only device. DHCPv4 remains active. The configured interface still has an IPv4 address. A machine may have other interfaces, manually configured routes, tunnels or applications that behave differently. An application may try IPv6 after an IPv4 failure, but the draft describes expected host behavior, not a guarantee for every software stack or service.

The lease is still in the server’s book

The draft makes an accounting point that can disappear behind the word “nearly”: a DHCPv4 server still needs to give each host a unique IPv4 address on a link. The method cannot normally hand the same address to every quiet client on one shared segment. Address Conflict Detection may probe an address before use; if two clients receive the same one, they can detect the conflict. The draft warns that repeatedly returning a conflicting address can produce a loop of DHCPDECLINE messages.

So the method exchanges one kind of activity for another. It may reduce recurring unanswered requests, but a successful lease still occupies a pool entry until the address is released or its dynamic lease expires. RFC 2131 defines dynamic allocation as a time-limited assignment that can be reused when no longer needed. A lease record is not a traffic measurement, and a quiet client is not proof that an address has returned to the available pool.

The economic result depends on which pool serves the cohort. If the server allocates from scarce public IPv4 space, a live lease has an opportunity cost even when the host cannot route ordinary traffic through that address. The draft also discusses link-local or RFC1918 addresses for this purpose. A dedicated private pool can protect public capacity, but it still requires unique leases, conflict handling, server state and a plan for overlaps with the operator’s existing private space.

The draft allows carefully bounded reuse of a pool on separate physical links when the DHCP server is directly attached to each link. That is not a universal reuse rule. With a DHCP relay, the server uses the relay’s address to select a pool, so the draft says the allocation pool must be unique across the relayed network. A diagram that counts only the address ranges and ignores the relay boundary can turn an apparent saving into an address-selection error.

Longer leases trade churn for occupancy

The draft suggests that leases for these hosts could last a day or several weeks, because the host is not expected to use the assigned address for external IPv4 and a local or private pool can be large. A longer lease can reduce renewals and server work. It also makes the reservation persist longer. In a constrained public pool, fewer DHCP messages do not automatically mean more available addresses; the operator must count both request rate and address-days. This is an operational inference from the lease model, not a result measured by the blog.

Option 108 offers a different bargain for a different cohort. RFC 8925 standardizes the IPv6-Only Preferred option for capable clients on an explicitly configured IPv6-mostly network. If both sides support the behavior, a client can forgo an IPv4 address. That can preserve pool capacity. The legacy /32 method is presented for clients that do not understand option 108; the draft says the two approaches can coexist. Neither mechanism by itself proves that the client’s applications, DNS64/NAT64 path or required services work.

No gateway is not a firewall

Withholding a router option removes the ordinary route a host would use to reach off-link IPv4 destinations. It does not make the interface invisible to neighboring systems. The draft’s security section explicitly says another host on the link may still send IPv4 packets to the /32 host. It recommends a host firewall that permits only DHCPv4 traffic between client and server or relay on that interface.

This matters because “the host cannot initiate a normal routed IPv4 connection” and “the host cannot receive IPv4 traffic” are different statements. The former follows from the proposed routing configuration. The latter does not. An operator should not use route failure as a substitute for an inbound policy, especially where local services remain enabled or where the same device can be reached through another path.

What the public evidence does and does not show

The LACNIC Blog says its author, Alejandro Acosta, tried the technique on Windows 11, Fedora 43, Raspberry Pi OS based on Debian Trixie, Chromecast and Google Nest devices. It also says smartphones were not tested and asks for broader compatibility work. That is useful reported experimentation, not an independently replicated study, a representative device survey or evidence of production deployment. The post itself says authors’ views do not necessarily reflect LACNIC’s views.

The referenced draft is version 02 of an individual Internet-Draft. The IETF Datatracker records it as expired on 15 June 2026 and says it has no formal standing in the IETF standards process. Expiry does not demonstrate that the mechanism failed a technical review; nor does the existence of a draft make the method an endorsed standard. The public material reviewed here does not provide a measured reduction in DHCP broadcasts, a before-and-after pool-occupancy series, application-fallback results or an inbound-security audit.

An operator testing the method should publish those missing distinctions rather than a single “IPv6-only” success label. Count repeated unanswered requests for the target client cohort. Report active leases and address-days by public, private and link-local pool, alongside releases, expirations and DHCPDECLINE events. Record relay and link boundaries. Sample whether required applications actually complete over IPv6, and show the firewall policy for inbound IPv4. Each measure answers a different question: quieter links, released scarce addresses, working applications and controlled exposure are not interchangeable outcomes.

Sources: