{"id":34577,"date":"2026-10-02T15:21:40","date_gmt":"2026-10-02T15:21:40","guid":{"rendered":"https:\/\/blog.lacnic.net\/?p=34577"},"modified":"2026-10-02T15:52:56","modified_gmt":"2026-10-02T15:52:56","slug":"dual-stack-hosts","status":"publish","type":"post","link":"https:\/\/blog.lacnic.net\/en\/dual-stack-hosts\/","title":{"rendered":"Nearly IPv6 Only Dual Stack Hosts"},"content":{"rendered":"\n

By Alejandro Acosta<\/a><\/p>\n\n\n\n

Today, we will discuss the Internet-Draft titled Nearly IPv6 Only Dual Stack Hosts.<\/p>\n\n\n\n

Introduction<\/strong><\/strong><\/h2>\n\n\n\n

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.<\/p>\n\n\n\n

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.<\/p>\n\n\n\n

<\/a>The Issue the Draft Is Trying to Solve<\/strong><\/strong><\/h2>\n\n\n\n

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.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Specifically, the document addresses the following interconnected issues:<\/p>\n\n\n\n

    \n
  1. Unnecessary traffic on the local network (endless broadcasts):<\/strong> 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.<\/li>\n\n\n\n
  2. Incompatibility of legacy hosts with modern solutions:<\/strong> Many readers are already familiar with IPv6-mostly networks, where DHCPv4 Option 108<\/strong> (IPv6-Only Preferred) plays a key role. What\u2019s wrong with this option? It allows a \u201cmodern host\u201d to indicate that it prefers not to receive an IPv4 address when IPv6 is available. Legacy hosts<\/strong>, however, do not understand this DHCPv4<\/strong> option and will continue to send broadcast traffic indefinitely.<\/li>\n\n\n\n
  3. The IPv4 assignment \u201cdilemma\u201d:<\/strong> Network administrators are forced to continue providing IPv4 addressing and maintaining both IPv6 infrastructure and DHCPv4 servers solely to silence legacy hosts.<\/li>\n<\/ol>\n\n\n\n

    Proposed Solution<\/strong><\/strong><\/h2>\n\n\n\n

    In my humble opinion, the proposed solution is quite creative.<\/p>\n\n\n\n

    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 \u201cmathematically does not realize\u201d is that the address is practically unusable.<\/p>\n\n\n\n

    I won’t go into every idea mentioned in the draft, but I will cover the two most interesting ones:<\/p>\n\n\n\n

    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<\/strong> configuration:<\/p>\n\n\n\n

      \n
    1. Configuring a \/32 subnet mask (255.255.255.255)<\/strong>: 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.<\/li>\n\n\n\n
    2. Suppressing default gateway delivery<\/strong>: The DHCPv4 server does not provide the host with any routers (the Router Option, option value 3, is deliberately eliminated).<\/li>\n<\/ol>\n\n\n\n

      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).<\/p>\n\n\n\n

      \"\"<\/figure>\n\n\n\n

      How Does This Isolate a Host in the World of IPv4?<\/strong><\/strong><\/h2>\n\n\n\n
        \n
      1. Effect of the \/32 mask<\/strong>: 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<\/strong>. Consequently, the host treats every off-link IPv4 address as unreachable.<\/li>\n\n\n\n
      2. Searching for a non-existent router<\/strong>: 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<\/strong> via DHCPv4.<\/li>\n<\/ol>\n\n\n\n
        \"\"<\/figure>\n\n\n\n

        So far, the host satisfies its need to obtain an IP address via DHCPv4 while avoiding repetitive broadcast traffic on the network.<\/p>\n\n\n\n

        <\/a>What advantages does this method offer compared to IPv6-Mostly networks?<\/strong><\/strong><\/h2>\n\n\n\n

        The main advantage of this method (providing a 255.255.255.255<\/strong> subnet mask and omitting a default gateway) over Option 108<\/strong> (IPv6-Only Preferred) is its compatibility with legacy hosts and servers<\/strong>.<\/p>\n\n\n\n