IPv6-Only Preferred Option for DHCPv4
RFC 8925

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 00
• 01
• 02
• 03
• 04
• 05
• 06
• 07
• 08



Internet Engineering Task Force (IETF)                        L. Colitti
Request for Comments: 8925                                    J. Linkova
Updates: 2563                                                     Google
Category: Standards Track                                  M. Richardson
ISSN: 2070-1721                                                Sandelman
                                                            T. Mrugalski
                                                                     ISC
                                                            October 2020

                 IPv6-Only Preferred Option for DHCPv4

Abstract

   This document specifies a DHCPv4 option to indicate that a host
   supports an IPv6-only mode and is willing to forgo obtaining an IPv4
   address if the network provides IPv6 connectivity.  It also updates
   RFC 2563 to specify DHCPv4 server behavior when the server receives a
   DHCPDISCOVER not containing the Auto-Configure option but containing
   the new option defined in this document.

Status of This Memo

   This is an Internet Standards Track document.

   This document is a product of the Internet Engineering Task Force
   (IETF).  It represents the consensus of the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Further information on
   Internet Standards is available in Section 2 of RFC 7841.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   https://www.rfc-editor.org/info/rfc8925.

Copyright Notice

   Copyright (c) 2020 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 extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction
     1.1.  Requirements Language
     1.2.  Terminology
   2.  Reasons to Signal IPv6-Only Support in DHCPv4 Packets
   3.  IPv6-Only Preferred Option
     3.1.  Option Format
     3.2.  DHCPv4 Client Behavior
     3.3.  DHCPv4 Server Behavior
       3.3.1.  Interaction with RFC 2563
     3.4.  Constants and Configuration Variables
   4.  IPv6-Only Transition Technology Considerations
   5.  IANA Considerations
   6.  Security Considerations
   7.  References
     7.1.  Normative References
     7.2.  Informative References
   Acknowledgements
   Authors' Addresses

1.  Introduction

   One of the biggest challenges of deploying IPv6-only LANs is that
   such networks might contain a rather heterogeneous collection of
   hosts.  While some hosts are capable of operating in IPv6-only mode
   (either because the OS and all applications are IPv6-only capable or
   because the host has some form of 464XLAT [RFC6877] deployed), others
   might still have IPv4 dependencies and need IPv4 addresses to operate
   properly.  To incrementally roll out IPv6-only, network operators
   might need to provide IPv4 on demand, whereby a host receives an IPv4
   address if it needs it, while IPv6-only-capable hosts (such as modern
   mobile devices) are not allocated IPv4 addresses.  Traditionally,
   that goal is achieved by placing IPv6-only-capable devices in a
   dedicated IPv6-only network segment or Wi-Fi Service Set Identifier
   (SSID), while dual-stack devices reside in another network with IPv4
   and DHCPv4 enabled.  However, such an approach has a number of
   drawbacks, including, but not limited to, the following:

   *  Doubling the number of network segments leads to operational
      complexity and impact on performance -- for instance, due to high
      memory utilization caused by an increased number of Access Control
      List (ACL) entries.

   *  Placing a host in the correct network segment is problematic.  For
      example, in the case of 802.11 Wi-Fi, the user might select the
      wrong SSID.  In the case of wired 802.1x authentication, the
      authentication server might not have all the information required
      to make the correct decision and choose between an IPv6-only VLAN
      and a dual-stack VLAN.

   It would be beneficial for IPv6 deployment if operators could
   implement IPv6-mostly (or IPv4-on-demand) segments where IPv6-only
   hosts coexist with legacy dual-stack devices.  The trivial solution
   of disabling the IPv4 stack on IPv6-only-capable hosts is not
   feasible, as those clients must be able to operate on IPv4-only
   networks as well.  While IPv6-only-capable devices might use a