IPv6-Only-Preferred Option for DHCP
draft-ietf-dhc-v6only-00

Document Type Active Internet-Draft (dhc WG)
Last updated 2020-05-11 (latest revision 2020-03-09)
Replaces draft-link-dhc-v6only
Stream IETF
Intended RFC status Proposed Standard
Formats plain text xml pdf htmlized (tools) htmlized bibtex
Stream WG state In WG Last Call
Document shepherd Bernie Volz
IESG IESG state I-D Exists
Consensus Boilerplate Yes
Telechat date
Responsible AD (None)
Send notices to Bernie Volz <volz@cisco.com>
Dynamic Host Configuration                                    L. Colitti
Internet-Draft                                                J. Linkova
Updates: 2563 (if approved)                                       Google
Intended status: Standards Track                           M. Richardson
Expires: September 10, 2020                                    Sandelman
                                                            T. Mrugalski
                                                                     ISC
                                                           March 9, 2020

                  IPv6-Only-Preferred Option for DHCP
                        draft-ietf-dhc-v6only-00

Abstract

   This document specifies a DHCP option to indicate that a host
   supports an IPv6-only mode and willing to forgo obtaining an IPv4
   address if the network provides IPv6 connectivity.

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 September 10, 2020.

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

Colitti, et al.        Expires September 10, 2020               [Page 1]
Internet-Draft     IPv6-Only-Preferred Option for DHCP        March 2020

   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   3
     1.2.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Reasons to Signal IPv6-Only Support in DHCPv4 Packets . . . .   4
   3.  IPv6-Only Preferred Option  . . . . . . . . . . . . . . . . .   5
     3.1.  Option format . . . . . . . . . . . . . . . . . . . . . .   5
     3.2.  DHCPv4 Client Behaviour . . . . . . . . . . . . . . . . .   5
     3.3.  DHCPv4 Server Behaviour . . . . . . . . . . . . . . . . .   7
       3.3.1.  Interoperability with RFC2563 . . . . . . . . . . . .   8
     3.4.  Constants and Configuration Variables . . . . . . . . . .   9
   4.  IPv6-Only Transition Technologies Considerations  . . . . . .   9
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  10
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  10
   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  10
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  10
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .  11
     8.2.  Informative References  . . . . . . . . . . . . . . . . .  11
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  12

1.  Introduction

   One of the biggest challenges of deploying IPv6-only LANs is that
   such networks might contain 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 rollout 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 into a
   dedicated IPv6-only network segment or WiFi SSID, while dual-stack
   devices reside in another network with IPv4 and DHCP enabled.
   However such approach has a number of drawbacks, including but not
   limited to:

   o  Doubling the number of network segments leads to operational
      complexity and performance impact, for instance due to high memory
      utilization caused by an increased number of ACL entries.
Show full document text