Nearly IPv6 Only Dual Stack Hosts
draft-smith-v6ops-nearly-ipv6-only-dualstack-hosts-00

Internet Engineering Task Force                                 M. Smith
Internet-Draft                                          10 December 2025
Intended status: Informational                                          
Expires: 13 June 2026

                   Nearly IPv6 Only Dual Stack Hosts
         draft-smith-v6ops-nearly-ipv6-only-dualstack-hosts-00

Abstract

   Once all of a dual stack IPv4 and IPv6 host's applications support
   IPv6, IPv4 connectivity becomes unnecessary.  However, ceasing to
   provide a dual stack host with an IPv4 address via a DHCPv4 server
   can cause the host to continue to make periodic and unsatisfied
   DHCPv4 requests, imposing unnecessary broadcast traffic on an
   attached link.  In this situation, it would be useful to continue to
   provide a host with an IPv4 address via DHCPv4, yet prevent it from
   using the IPv4 address for any connectivity outside of the host
   itself.  This memo describes a DHCPv4 method to achieve this.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 13 June 2026.

Copyright Notice

   Copyright (c) 2025 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components

Smith                     Expires 13 June 2026                  [Page 1]
Internet-Draft      Nearly IPv6 Only Dual Stack Hosts      December 2025

   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Supressing On-Link IPv4 Connectivity  . . . . . . . . . . . .   3
   3.  Suppressed On-Link Connectivity Address Pool  . . . . . . . .   4
   4.  Supressing Off-Link IPv4 Connectivity . . . . . . . . . . . .   4
   5.  Other DHCPv4 Options  . . . . . . . . . . . . . . . . . . . .   5
   6.  Lease Times . . . . . . . . . . . . . . . . . . . . . . . . .   5
   7.  ISC Kea Configuration . . . . . . . . . . . . . . . . . . . .   5
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   6
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .   6
     9.2.  Informative References  . . . . . . . . . . . . . . . . .   6
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .   6
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   6

1.  Introduction

   Once all of a dual stack IPv4 and IPv6 host's applications support
   IPv6, IPv4 connectivity becomes unnecessary.  However, ceasing to
   provide a dual stack host with an IPv4 address via a DHCPv4 server
   can cause the host to continue to make periodic and unsatisfied
   DHCPv4 [RFC2131] requests, imposing unnecessary broadcast traffic on
   an attached link.

   One method to satisfy the IPv4 addressing requirement is for a host
   use the DHCPv4 IPv6-Only Preferred option, option value 108
   [RFC8925].  Providing this option in the Parameter Request Lists
   indicates to the DHCPv4 server that the host doesn't require an IPv4
   address.  If supported and enabled, the DHCPv4 server can inform the
   host via option 108 how long the host should supress IPv4.

   The drawback of the DHCPv4 IPv6-Only Preferred option is that it
   requires hosts and their DHCPv4 servers to support the option.  It
   would be useful to be able to prevent a non-DHCPv4 IPv6-Only
   Preferred option supporting dual stack legacy host from using IPv4 to
   reach external destinations (both on-link and off-link), while still
   satisifying its DHCPv4 requests for an IPv4 address.  This memo
   describes a method of how to achieve this using traditional [RFC2131]
   mechanisms.

Smith                     Expires 13 June 2026                  [Page 2]
Internet-Draft      Nearly IPv6 Only Dual Stack Hosts      December 2025

   Note that this method could be used on a per-host basis, via DHCPv4
   client specific options, or for all hosts attached to a link.  It can
   be used when the DHCPv4 server is on the same link as the DHCPv4
   client hosts, or via a DHCPv4 relay.

2.  Supressing On-Link IPv4 Connectivity

   Unlike IPv6 [RFC5942], IPv4 uses an address's subnet mask or prefix
   length to determine if a destination should be directly reachable on
   a link, or if a router should be used to attempt to reach the
   destination.

   For example, a subnet mask of 255.255.255.0 (/24) for the address
   203.0.113.32 assigned to an interface tells a host that the range of
   address from 203.0.113.1 through 203.0.113.31, and from 203.0.113.33
   to 203.0.113.254 (.0 and .255 not being valid host addresses) should
   be reachable directly via the link attached to the interface.  The
   host would then trigger an ARP Request/ARP Reply [RFC826] transaction
   to resolve the destination IPv4 address into a link-layer address,
   should address resolution be necessary.

   If a host was instead provided with a 255.255.255.255 subnet mask for
   an address configured on a interface, the host would conclude that
   there are no directly reachable remote addresses on the attached
   link.  The host would attempt to use a router to reach any and all
   destinations because it considers all destinations to be off-link,
   should the host have any routers available.

   If the host does not have any routers available, then the only IPv4
   addresses that the host can reach will be addresses within
   127.0.0.0/8 [RFC1122], and only IPv4 addresses assigned to its
   interfaces with a 255.255.255.255 subnet mask.  Connectivity to any
   other IPv4 address will immediately fail, and an ICMPv4 [RFC792]
   Destinaton Unreachable, Host Unreachble Message will be generated by
   the host and passed up to the application.  This should cause the
   application to attempt to use IPv6 to reach an equivalent
   destination, should IPv6 not have been previously attempted before
   IPv4 [RFC6724].

   When using a DHCPv4 server to provide the host with an address, the
   Subnet Mask option, option value 1, is used to provide thoe host with
   a 255.255.255.255 (/32) subnet mask.

   Note that although the hosts on the link with 255.255.255.255 subnet
   masks will not attempt to communicate with any other IPv4 addresses
   on the link, the DHCPv4 server will still normally need to provide
   each host with a unique IPv4 address within the link.  In other
   words, the DHCPv4 server would need to be configured with a pool of

Smith                     Expires 13 June 2026                  [Page 3]
Internet-Draft      Nearly IPv6 Only Dual Stack Hosts      December 2025

   IPv4 addresses for these hosts with 255.255.255.255 subnet masks.
   This is because hosts may perform IPv4 Address Conflict Detection
   (ACD) [RFC5227] for addresses acquired via DHCPv4.  Should an address
   conflict be detected, the host would decline to accept the IPv4
   address via DHCPDECLINE message to the DHCPv4 server [RFC2131].

3.  Suppressed On-Link Connectivity Address Pool

   As mentioned previously, unless it is possible to use the same IPv4
   address for all hosts with the 255.255.255.255 subnet mask, the
   DHCPv4 server will need to use a pool of IPv4 addresses for these
   hosts, so that they can perform IPv4 Address Conflict Detection
   successfully.

   As the hosts do not attempt to reach any off-link destinations, the
   IPv4 address pool does not need to be routable over the network or
   the Internet.  If the DHCPv4 server is attached to the same link as
   the DHCPv4 clients, it would be possible to use the same address pool
   on different links within the network.

   The IPv4 link-local prefix of 169.254.0.0/16 [RFC3927] could be a
   good candidate prefix to use for this 255.255.255.255 subnet mask
   address pool, although it would imply that link-local IPv4
   connectivity is available and can be used (the 255.255.255.255 subnet
   mask however would show otherwise).

   A pool of addresses from within the [RFC1918] IPv4 private addresses
   allocations are an alternative.  It might be useful to designate a
   specific subnet or subnets for this purpose that are significantly
   different from any other [RFC1918] addressing being used in the
   network.

   If the 255.255.255.255 subnet mask clients reach the DHCPv4 server
   via a link attached DHCPv4 Relay, then the DHCPv4 pool of addresses
   will need to be unique across the network, as the DHCPv4 Relay's IPv4
   address is used via the 'giaddr' field [RFC2131] by the DHCPv4 server
   to select the pool of addresses to use for the relayed DHCPv4
   requests.

4.  Supressing Off-Link IPv4 Connectivity

   This is simply and easily achieved by not providing the host with any
   routers, by not providing the DHCPv4 client the Router Option, option
   value 3.

Smith                     Expires 13 June 2026                  [Page 4]
Internet-Draft      Nearly IPv6 Only Dual Stack Hosts      December 2025

   Note that any routers attached to the link do not need an IPv4
   address if all hosts are being provided with the 255.255.255.255
   subnet mask, unless the router is acting as a DHCPv4 Relay, as
   discussed previously.

5.  Other DHCPv4 Options

   Since a host with a 255.255.255.255 subnet mask's IPv4 connectivity
   is very limited, there is no point in providing any DHCPv4 options to
   the host other than the Subnet Mask Option and the Router Option.

   Other host configuration parameters, such as DNS resolver (IPv6)
   addresses, are supplied via IPv6 host configuration mechanisms.

6.  Lease Times

   Since the hosts with 255.255.255.255 subnet masks aren't using IPv4
   to reach external destinations, and the DHCPv4 pool can be large
   since it is from a private IPv4 address space, IPv4 address lease
   times can be significantly bigger than typical e.g. 24 hours or even
   a number of weeks.  Larger lease times will reduce the DHCPv4 traffic
   on the network and DHCPv4 server load.

7.  ISC Kea Configuration

   Kea DHCPv4 server automatically derives the value of the Subnet Mask
   option, option value 1 from the 'subnet' prefix option (e.g., the
   "/24" in 198.51.100.0/24).  To cause Kea to supply a 255.255.255.255
   subnet mask, it is necessary to use the 'libdhcp_flex_option.so' hook
   library to modify the subnet mask supplied to clients.  All other Kea
   configuration is conventional, with the exception of removing the
   configuration to supply clients with the Router Option, option value
   3.

   "hooks-libraries": [

   {

   "library": "/usr/lib64/kea/hooks/libdhcp_flex_option.so",

   "parameters": {

   "options": [

   {

   "code": 1,

Smith                     Expires 13 June 2026                  [Page 5]
Internet-Draft      Nearly IPv6 Only Dual Stack Hosts      December 2025

   "supersede": "255.255.255.255"

   }

   ]

   }

   }

   ],

8.  Security Considerations

   Limiting a host's IPv4 connectivity to only within itself reduces the
   attack surface of the host.

9.  References

9.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

9.2.  Informative References

   [exampleRefMin]
              Surname [REPLACE], Initials [REPLACE]., "Title [REPLACE]",
              2006.

   [exampleRefOrg]
              Organization [REPLACE], "Title [REPLACE]", 1984,
              <http://www.example.com/>.

Acknowledgements

   Your name could be here if you provide some comments and feedback!

Author's Address

Smith                     Expires 13 June 2026                  [Page 6]
Internet-Draft      Nearly IPv6 Only Dual Stack Hosts      December 2025

   Mark Smith
   PO BOX 521
   Heidelberg Victoria 3084
   Australia
   Email: markzzzsmith@gmail.com

Smith                     Expires 13 June 2026                  [Page 7]