IPv6-Only Preferred Option for DHCPv4
RFC 8925
Document | Type |
RFC - Proposed Standard
(October 2020; No errata)
Updates RFC 2563
Was draft-ietf-dhc-v6only (dhc WG)
|
|
---|---|---|---|
Authors | Lorenzo Colitti , Jen Linkova , Michael Richardson , Tomek Mrugalski | ||
Last updated | 2020-10-17 | ||
Replaces | draft-link-dhc-v6only | ||
Stream | IETF | ||
Formats | plain text html xml pdf htmlized bibtex | ||
Reviews | |||
Stream | WG state | Submitted to IESG for Publication | |
Document shepherd | Bernie Volz | ||
Shepherd write-up | Show (last changed 2020-06-01) | ||
IESG | IESG state | RFC 8925 (Proposed Standard) | |
Action Holders |
(None)
|
||
Consensus Boilerplate | Yes | ||
Telechat date | |||
Responsible AD | Éric Vyncke | ||
Send notices to | Bernie Volz <volz@cisco.com> | ||
IANA | IANA review state | IANA OK - Actions Needed | |
IANA action state | RFC-Ed-Ack |
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 aShow full document text