Today, we will discuss the Internet-Draft titled Nearly IPv6 Only Dual Stack Hosts.
Introduction
This document proposes a method for managing dual-stack hosts that no longer require IPv4 connectivity but continue to generate network traffic by automatically requesting IPv4 addresses as DHCPv4 clients.
The strategy consists of assigning each host a subnet mask of 255.255.255.255 via DHCPv4, which effectively isolates the host and prevents it from communicating with external destinations over IPv4. By not configuring a gateway or router, the approach directs traffic to IPv6 and avoids the need for newer, more complex mechanisms. This technique reduces noise on the local network and allows private address ranges to be reused without affecting global routing. The author also suggests implementing longer address lease times to minimize server load. Ultimately, this approach offers a practical solution for transitioning to IPv6-only networks using traditional infrastructure mechanisms.
(Free access, no subscription required)
The Issue the Draft Is Trying to Solve
The draft addresses how to silence noisy DHCPv4 requests from legacy devices while effectively revoking their IPv4 access (forcing them to use IPv6), using the traditional DHCPv4 mechanisms that these hosts already understand, without requiring software updates.
Specifically, the document addresses the following interconnected issues:
Unnecessary traffic on the local network (endless broadcasts): When a dual-stack network wants to advance toward an IPv6-only environment, the logical step would be to stop assigning IPv4 addresses to hosts. However, if IPv4 assignment is simply disabled, a host will continue making periodic, unsatisfied DHCPv4 requests. This DHCPv4 traffic is usually broadcast traffic.
Incompatibility of legacy hosts with modern solutions: Many readers are already familiar with IPv6-mostly networks, where DHCPv4 Option 108 (IPv6-Only Preferred) plays a key role. What’s wrong with this option? It allows a “modern host” to indicate that it prefers not to receive an IPv4 address when IPv6 is available. Legacy hosts, however, do not understand this DHCPv4 option and will continue to send broadcast traffic indefinitely.
The IPv4 assignment “dilemma”: Network administrators are forced to continue providing IPv4 addressing and maintaining both IPv6 infrastructure and DHCPv4 servers solely to silence legacy hosts.
Proposed Solution
In my humble opinion, the proposed solution is quite creative.
The Issue the Draft Is Trying to Solve
The draft addresses how to silence noisy DHCPv4 requests from legacy devices while effectively revoking their IPv4 access (forcing them to use IPv6), using the traditional DHCPv4 mechanisms that these hosts already understand, without requiring software updates.
Specifically, the document addresses the following interconnected issues:
Unnecessary traffic on the local network (endless broadcasts): When a dual-stack network wants to advance toward an IPv6-only environment, the logical step would be to stop assigning IPv4 addresses to hosts. However, if IPv4 assignment is simply disabled, a host will continue making periodic, unsatisfied DHCPv4 requests. This DHCPv4 traffic is usually broadcast traffic.
Incompatibility of legacy hosts with modern solutions: Many readers are already familiar with IPv6-mostly networks, where DHCPv4 Option 108 (IPv6-Only Preferred) plays a key role. What’s wrong with this option? It allows a “modern host” to indicate that it prefers not to receive an IPv4 address when IPv6 is available. Legacy hosts, however, do not understand this DHCPv4 option and will continue to send broadcast traffic indefinitely.
The IPv4 assignment “dilemma”: Network administrators are forced to continue providing IPv4 addressing and maintaining both IPv6 infrastructure and DHCPv4 servers solely to silence legacy hosts.
Proposed Solution
In my humble opinion, the proposed solution is quite creative.
The goal is to satisfy the host’s DHCPv4 request without providing usable IPv4 connectivity. The client requests an IPv4 address from the DHCP server, and the server provides one. What the client “mathematically does not realize” is that the address is practically unusable.
I won’t go into every idea mentioned in the draft, but I will cover the two most interesting ones:
The solution proposed in the Internet-Draft to ensure that dual-stack hosts operate almost exclusively over IPv6 involves a subtle yet highly effective method based on the traditional DHCPv4 configuration:
Configuring a /32 subnet mask (255.255.255.255): Using DHCPv4 Option 1 (Subnet Mask), the client is assigned a single-host subnet mask. When it receives this mask, the host concludes that there are no other IPv4 addresses on the attached link; in other words, all outbound IPv4 traffic is automatically considered to be off-link.
Suppressing default gateway delivery: The DHCPv4 server does not provide the host with any routers (the Router Option, option value 3, is deliberately eliminated).
Thus, the legacy host satisfies its need to obtain an IPv4 address (silencing annoying, repeated broadcast requests) but remains isolated from the IPv4 network and is forced to communicate exclusively over IPv6 (in addition to ARP broadcast traffic).
How Does This Isolate a Host in the World of IPv4?
Effect of the /32 mask: When the host interface is configured with a 255.255.255.255 mask, the operating system concludes that there are no other IPv4 addresses on its attached link. Consequently, the host treats every off-link IPv4 address as unreachable.
Searching for a non-existent router: By assuming that all IPv4 destinations are on external networks, the host will attempt to send any IPv4 packet via its default gateway or router. However, the method described in the draft involves not providing a router via DHCPv4.
So far, the host satisfies its need to obtain an IP address via DHCPv4 while avoiding repetitive broadcast traffic on the network.
What advantages does this method offer compared to IPv6-Mostly networks?
The main advantage of this method (providing a 255.255.255.255 subnet mask and omitting a default gateway) over Option 108 (IPv6-Only Preferred) is its compatibility with legacy hosts and servers.
It does not require support for newer protocols: Option 108 is a relatively new DHCPv4 mechanism that requires explicit support from both the host operating system (client) and the DHCPv4 server. The /32 mask (255.255.255.255) method uses standard DHCPv4 mechanisms, making it compatible with legacy systems that do not support Option 108.
It avoids unnecessary broadcast traffic: If a legacy host that does not support Option 108 is no longer assigned an IPv4 address, it continues sending periodic, unsatisfied DHCPv4 requests and floods the local link with unnecessary broadcast traffic. This method satisfies the client’s DHCPv4 request by assigning it an IP address while restricting its connectivity.
IPv4 addressing efficiency and flexibility: As the hosts configured with a 255.255.255.255 subnet mask do not attempt to reach any off-link IPv4 destinations, the assigned addresses do not need to be routable over the internal network or the Internet. This allows using non-routable address ranges such as a link-local prefix (169.254.0.0/16) or RFC 1918 private addresses and even using the same IP address pool on different physical links within the network, provided the DHCPv4 server is attached to the same link.
IPv6-Mostly and Nearly-IPv6-Only Dual-Stack Hosts Are Not Mutually Exclusive
It should be noted that these two approaches are not mutually exclusive and can coexist: a network can be deployed using Option 108 so that modern hosts do not consume IPv4 addresses from DHCPv4 pools, while simultaneously applying the 255.255.255.255 subnet mask method (without a default gateway) to silence IPv4 connectivity for legacy hosts.
Why Did the Draft Expire?
The document we are looking at expired on 15 June 2026.
Without going into detail about the IETF process, Internet-Drafts are temporary working documents that remain valid for no more than six months. During that period, the authors must submit an updated version to keep the work active.
Because that date has passed and no newer revision replaced it, the draft expired automatically. Although I-Ds are valid for a maximum of six months, they can be updated or replaced by other documents at any time. To reactivate the work, the authors or other contributors would need to publish a new revision.
Which Operating Systems Were Tested?
The author has successfully tested this method on the following operating systems and devices:
Windows 11.
Various Linux distributions (or systems based on the Linux kernel) using different DHCPv4 clients:
Fedora 43
Raspberry Pi OS (based on Debian Trixie)
Chromecast devices
Google Nest devices
It is also explicitly noted that no tests were conducted on smartphones.
Conclusions
This technique forces the use of IPv6 by simulating a functional IPv4 connection, eliminating unnecessary broadcast traffic from legacy devices without requiring software updates. The method is compatible with systems such as Windows 11 and Linux.
It is very important to conduct extensive testing across multiple operating systems and network configurations (dual stack, single stack v4, single stack v6). These tests should try to determine which scenario performs better, for example, receiving a subnet mask of 255.255.255.255 from DHCP or receiving an IP address without a default gateway. More testing is needed before decisions can be made.
I plan to test this solution soon, along with Option 108, on an IPv6-mostly network.
Greater compatibility is needed across different operating systems and versions. Your collaboration is essential to delivering a seamless experience. If you would like to contribute to this process, please contact us at imasd@lacnic.net.
Find more information and useful resources on how to deploy IPv6 here.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of LACNIC.
