rfc8925xml2.original.xml   rfc8925.xml 
<?xml version="1.0" encoding="US-ASCII"?> <?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [ <!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902"
.2119.xml"> updates="2563" obsoletes="" category="std"
<!ENTITY RFC2131 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC docName="draft-ietf-dhc-v6only-08" number="8925" submissionType="IETF"
.2131.xml"> consensus="true" xml:lang="en" tocInclude="true" tocDepth="4" symRefs="tru
<!ENTITY RFC2132 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC e" sortRefs="true" version="3">
.2132.xml">
<!ENTITY RFC2563 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.2563.xml">
<!ENTITY RFC3927 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.3927.xml">
<!ENTITY RFC4039 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.4039.xml">
<!ENTITY RFC4861 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.4861.xml">
<!ENTITY RFC4957 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.4957.xml">
<!ENTITY RFC6052 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.6052.xml">
<!ENTITY RFC6146 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.6146.xml">
<!ENTITY RFC6147 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.6147.xml">
<!ENTITY RFC6877 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.6877.xml">
<!ENTITY RFC8174 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.8174.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds
might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc ipr="trust200902"
updates="2563"
obsoletes=""
category="std"
docName="draft-ietf-dhc-v6only-08">
<!-- category values: std, bcp, info, exp, and historic -->
<!-- ***** FRONT MATTER ***** --> <!-- xml2rfc v2v3 conversion 2.47.0 -->
<front> <front>
<!-- The abbreviated title is used in the page header - it is only necessary <title>IPv6-Only Preferred Option for DHCPv4</title>
if the <seriesInfo name="RFC" value="8925"/>
full title is longer than 39 characters -->
<title>IPv6-Only-Preferred Option for DHCPv4</title>
<!-- add 'role="editor"' below for the editors if appropriate -->
<author fullname="Lorenzo Colitti" initials="L." surname="Colitti"> <author fullname="Lorenzo Colitti" initials="L." surname="Colitti">
<organization>Google</organization> <organization>Google</organization>
<address> <address>
<postal> <postal>
<street>Shibuya 3-21-3</street> <street>Shibuya 3-21-3</street>
<city>Shibuya</city> <region>Shibuya, Tokyo</region>
<region>Tokyo</region>
<code>150-0002</code> <code>150-0002</code>
<country>JP</country> <country>Japan</country>
</postal> </postal>
<phone></phone>
<email>lorenzo@google.com</email> <email>lorenzo@google.com</email>
</address> </address>
</author> </author>
<author fullname="Jen Linkova" initials="J." surname="Linkova"> <author fullname="Jen Linkova" initials="J." surname="Linkova">
<organization>Google</organization> <organization>Google</organization>
<address> <address>
<postal> <postal>
<street>1 Darling Island Rd</street> <street>1 Darling Island Rd</street>
<city>Pyrmont</city> <city>Pyrmont</city>
<region>NSW</region> <region>NSW</region>
<code>2009</code> <code>2009</code>
<country>AU</country> <country>Australia</country>
</postal> </postal>
<phone></phone>
<email>furry@google.com</email> <email>furry@google.com</email>
</address> </address>
</author> </author>
<author fullname="Michael C. Richardson" initials="M." surname="Richardson">
<author fullname="Michael C. Richardson" initials="M."
surname="Richardson">
<organization abbrev="Sandelman">Sandelman Software Works</organization> <organization abbrev="Sandelman">Sandelman Software Works</organization>
<address> <address>
<email>mcr+ietf@sandelman.ca</email> <email>mcr+ietf@sandelman.ca</email>
<uri>https://www.sandelman.ca/</uri>
<uri>http://www.sandelman.ca/</uri>
</address> </address>
</author> </author>
<author fullname="Tomek Mrugalski" initials="T." surname="Mrugalski"> <author fullname="Tomek Mrugalski" initials="T." surname="Mrugalski">
<organization abbrev="ISC">Internet Systems Consortium, Inc.</organization > <organization abbrev="ISC">Internet Systems Consortium, Inc.</organization >
<address> <address>
<postal> <postal>
<street>950 Charter Street</street> <street>PO Box 360</street>
<city>Redwood City</city> <city>Newmarket</city>
<region>CA</region> <region>NH</region>
<code>94063</code> <code>03857</code>
<country>USA</country> <country>United States of America</country>
</postal> </postal>
<email>tomasz.mrugalski@gmail.com</email> <email>tomasz.mrugalski@gmail.com</email>
</address> </address>
</author> </author>
<date month="October" year="2020"/>
<date/>
<!-- If the month and year are both specified and are the current ones, xml2
rfc will fill
in the current day for you. If only the current year is specified, xml2
rfc will fill
in the current day and month for you. If the year is not the current one
, it is
necessary to specify at least a month (xml2rfc assumes day="1" if not sp
ecified for the
purpose of calculating the expiry date). With drafts it is normally suf
ficient to
specify just the year. -->
<!-- Meta-data Declarations -->
<area>Internet</area>
<workgroup>Dynamic Host Configuration</workgroup>
<!-- WG name at the upperleft corner of the doc,
IETF is fine for individual submissions.
If this element is not present, the default is "Network Working Group",
which is used by the RFC Editor as a nod to the history of the IETF. --
>
<keyword>template</keyword>
<!-- Keywords will be incorporated into HTML output
files in a meta tag but they have no effect on text or nroff
output. If you submit your draft to the RFC Editor, the
keywords will be used for the search engine. -->
<abstract> <abstract>
<t> <t>
This document specifies a DHCPv4 option to indicate t This document specifies a DHCPv4 option to indicate that a host suppor
hat a host supports an IPv6-only mode and is willing to forgo obtaining an IPv4 ts an IPv6-only mode and is willing to forgo obtaining an IPv4 address if the ne
address if the network provides IPv6 connectivity. twork provides IPv6 connectivity.
It also updates RFC2563 to specify the DHCPv4 server It also updates RFC 2563 to specify DHCPv4 server behavior when the se
behavior when the server receives a DHCPDISCOVER not containing the Auto-Configu rver receives a DHCPDISCOVER not containing the Auto-Configure option but contai
re option but containing the new option defined in this document. ning the new option defined in this document.
</t> </t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section title="Introduction"> <section numbered="true" toc="default">
<name>Introduction</name>
<t> <t>
One of the biggest challenges of deploying IPv6-only LANs is One of the biggest challenges of deploying IPv6-only LANs is that
that such networks might contain rather heterogeneous collection of hosts. 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 While some hosts are capable of operating in IPv6-only mode (either
host has some form of 464XLAT <xref target="RFC6877"/> deployed), others might s because the OS and all applications are IPv6-only capable or because
till have IPv4 dependencies and need IPv4 addresses to operate properly. the host has some form of 464XLAT <xref target="RFC6877"
To incrementally rollout IPv6-only, network operators might n format="default"/> deployed), others might still have IPv4 dependencie
eed to provide IPv4 on demand whereby a host receives an IPv4 address if it need s and need IPv4 addresses to operate properly.
s it, while IPv6-only capable hosts (such as modern mobile devices) are not allo To incrementally roll out IPv6-only, network operators might need to p
cated IPv4 addresses. rovide IPv4 on demand, whereby a host receives an IPv4 address if it needs it, w
Traditionally that goal is achieved by placing IPv6-only capable devices into a hile IPv6-only-capable hosts (such as modern mobile devices) are not allocated I
dedicated IPv6-only network segment or WiFi SSID, while dual-stack devices resid Pv4 addresses.
e in another network with IPv4 and DHCPv4 enabled. Traditionally, that goal is achieved by placing IPv6-only-capable devices in
However such an approach has a number of drawbacks, including but not limited to 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
<list style="symbols"> enabled. However, such an approach has a number of drawbacks, including, but not
<t> limited to, the following:
Doubling the number of network segments leads </t>
to operational complexity and performance impact, for instance due to high memo <ul spacing="normal">
ry utilization caused by an increased number of ACL entries. <li>
</t> Doubling the number of network segments leads to operational
<t> complexity and impact on performance -- for instance, due to high
Placing a host into the correct network segme memory utilization caused by an increased number of Access Control
nt is problematic. List (ACL) entries.
For example, in the case of 802.11 Wi-Fi the </li>
user might select the wrong SSID. <li>
In the case of wired 802.1x authentication th Placing a host in the correct network segment is problematic.
e authentication server might not have all the information required to make the For example, in the case of 802.11 Wi-Fi, the user might select the wr
correct decision and choose between an IPv6-only and a dual-stack VLAN. ong SSID.
</t> In the case of wired 802.1x authentication, the authentication
</list> server might not have all the information required to make the
</t> correct decision and choose between an IPv6-only VLAN and a dual-stack
<t> VLAN.
It would be beneficial for IPv6 deployment if operators could </li>
implement IPv6-mostly (or IPv4-on-demand) segments where IPv6-only hosts co-exi </ul>
st with legacy dual-stack devices. <t>
The trivial solution of disabling IPv4 stack on IPv6-only cap It would be beneficial for IPv6 deployment if operators could implemen
able hosts is not feasible as those clients must be able to operate on IPv4-only t IPv6-mostly (or IPv4-on-demand) segments where IPv6-only hosts coexist with le
networks as well. gacy dual-stack devices.
While IPv6-only capable devices might use a heuristic approac The trivial solution of disabling the IPv4 stack on IPv6-only-capable
h to learning if the network provides IPv6-only functionality and stop using IPv hosts is not feasible, as those clients must be able to operate on IPv4-only net
4 if it does, such an approach might be practically undesirable. works as well.
One important reason is that when a host connects to a networ While IPv6-only-capable devices might use a heuristic approach to
k, it does not know if the network is IPv4-only, dual-stack or IPv6-only. learning if the network provides IPv6-only functionality and stop
To ensure that the connectivity over whatever protocol is pre using IPv4 if it does, such an approach might be undesirable in practi
sent becomes available as soon as possible the host usually starts configuring b ce.
oth IPv4 and IPv6 immediately. One important reason is that when a host connects to a network, it doe
If hosts were to delay requesting IPv4 until IPv6 reachabilit s not know whether the network is IPv4-only, dual-stack, or IPv6-only.
y is confirmed, that would penalize IPv4-only and dual-stack networks, which doe To ensure that connectivity over whatever protocol is present becomes
s not seem practical. available as soon as possible, the host usually starts configuring both IPv4 and
Requesting IPv4 and then releasing it later, after IPv6 reach IPv6 immediately.
ability is confirmed, might cause user-visible errors as it would be disruptive If hosts were to delay requesting IPv4 until IPv6 reachability is conf
for applications which have started using the assigned IPv4 address already. irmed, that would penalize IPv4-only and dual-stack networks, which does not see
Instead it would be useful to have a mechanism which m practical.
would allow a host to indicate that its request for an IPv4 address is optional Requesting IPv4 and then releasing it later, after IPv6 reachability
and a network to signal that IPv6-only functionality (such as NAT64, <xref targe is confirmed, might cause errors that are visible to users, as it woul
t="RFC6146"/>) is available. d be
The proposed solution is to introduce a new DHCPv4 option whi disruptive for applications that have already started using the assign
ch a client uses to indicate that it does not need an IPv4 address if the networ ed IPv4 address.
k provides IPv6-only connectivity (as NAT64 and DNS64). Instead, it would be useful to have a mechanism that would allow a hos
If the particular network segment provides IPv4-on-demand such clients would not t to indicate that its request for an IPv4 address is optional and a network to
be supplied with IPv4 addresses, while on IPv4-only or dual-stack segments wit signal that IPv6-only functionality (such as NAT64 <xref target="RFC6146" format
hout NAT64 services IPv4 addresses will be provided. ="default"/>) is available.
</t> This document provides such a solution via a new DHCPv4 option that
<t> a client uses to indicate that it does not need an IPv4 address if
<xref target="RFC2563"/> introduces the Auto-Configure DHCPv the network provides IPv6-only connectivity (as NAT64 and DNS64).
4 option and describes DHCPv4 servers behavior if no address is chosen for a hos If the particular network segment provides IPv4 on demand, such clients would
t. This document updates <xref target="RFC2563"/> to modify the server behavior not be supplied with IPv4 addresses, while IPv4 addresses would be provided on I
if the DHCPOFFER contains the IPv6-only Preferred option. Pv4-only or dual-stack segments without NAT64 services.
</t> </t>
<t>
<section title="Requirements Language"> <xref target="RFC2563" format="default"/> introduced the Auto-Configur
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL e DHCPv4 option and describes DHCPv4 server behavior if no address is chosen for
NOT", a host. This document updates <xref target="RFC2563" format="default"/> to modi
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED" fy server behavior if the DHCPOFFER contains the IPv6-Only Preferred option.
, "MAY", and </t>
"OPTIONAL" in this document are to be interpreted as des <section numbered="true" toc="default">
cribed in <name>Requirements Language</name>
BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> <t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
when, and only when, they appear in all capitals, as show "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>",
n here.</t> "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>",
"<bcp14>SHOULD NOT</bcp14>",
"<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document
are to be interpreted as described in BCP&nbsp;14
<xref target="RFC2119"/> <xref target="RFC8174"/> when, and only
when, they appear in all capitals, as shown here.</t>
</section> </section>
<section title="Terminology"> <section numbered="true" toc="default">
<t> <name>Terminology</name>
Dual-stack network or device: a network or device w <dl newline="false" spacing="normal">
hich has both versions of the Internet Protocol (IPv4 and IPv6) enabled and oper <dt>Dual-stack network or device:</dt>
ational. <dd>A network or device that has both versions of the Internet Protocol
</t> (IPv4 and IPv6) enabled and operational.</dd>
<t> <dt>IPv6-only-capable host:</dt><dd>A host that does not require an IPv4
IPv6-only capable host: a host which does not require an IP address and can operate on IPv6-only networks.
v4 address and can operate on IPv6-only networks. More precisely, IPv6-only capability is specific to a given
More precisely, IPv6-only capability is specific to interface of the host: if some applications on a host require IPv4
a given interface of the host: if some application on a host require IPv4 and 4 and the 464XLAT CLAT (customer-side translator) <xref target="RFC687
64XLAT CLAT <xref target="RFC6877"/> is only enabled on one interface, the host 7"
is IPv6-only capable if connected to a NAT64 network via that interface. This format="default"/> is only enabled on one interface, the host is
document implies that IPv6-only capable hosts reach IPv4-only destinations via a IPv6-only capable if connected to a NAT64 network via that
NAT64 service provided by the network. <xref target="v6onlydef" /> discusses hy interface. This document implies that IPv6-only-capable hosts
pothetical scenarios of other transition technologies being used. reach IPv4-only destinations via a NAT64 service provided by the
</t> network. <xref target="v6onlydef" format="default"/> discusses
<t> hypothetical scenarios for other transition technologies being used.
IPv4-requiring host: a host which is not IPv6-only capable </dd>
and can not operate in an IPv6-only network providing NAT64 service. <dt>IPv4-requiring host:</dt><dd>A host that is not IPv6-only capable an
</t> d cannot operate in an IPv6-only network providing NAT64 service.</dd>
<t> <dt>IPv4 on demand:</dt><dd>A deployment scenario where end hosts are
IPv4-on-demand: a deployment scenario where end hosts are e expected to operate in IPv6-only mode by default and IPv4 addresses
xpected to operate in IPv6-only mode by default and IPv4 addresses can be assign can be assigned to some hosts if those hosts explicitly opt in to receiv
ed to some hosts if those hosts explicitly opt-in to receiving IPv4 addresses. e IPv4 addresses.
</t> </dd>
<t> <dt>IPv6-mostly network:</dt><dd>A network that provides NAT64
IPv6-mostly network: a network which provides NAT64 (possib (possibly with DNS64) service as well as IPv4 connectivity and allows
ly with DNS64) service as well as IPv4 connectivity and allows coexistence of IP the coexistence of IPv6-only, dual-stack, and IPv4-only hosts on the sam
v6-only, dual-stack and IPv4-only hosts on the same segment. e segment.
Such deployment scenario allows operators to incrementally Such a deployment scenario allows operators to incrementally turn of
turn off IPv4 on end hosts, while still providing IPv4 to devices which require f IPv4 on end hosts, while still providing IPv4 to devices that require IPv4 to
IPv4 to operate. operate.
But, IPv6-only capable devices need not be assigned IPv4 ad But IPv6-only-capable devices need not be assigned IPv4 addresses.</
dresses. dd>
</t> <dt>IPv6-only mode:</dt><dd>A mode of operation where a host acts as an
<t> IPv6-only-capable host and does not have IPv4 addresses assigned (except that IP
IPv6-only mode: a mode of operation when a host act v4 link-local addresses <xref target="RFC3927" format="default"/> may have been
s as an IPv6-only capable host and does not have IPv4 addresses assigned (except configured).</dd>
that IPv4 link-local addresses <xref target="RFC3927"/> may have been configure <dt>IPv6-only network:</dt><dd>A network that does not provide routing f
d). unctionality for IPv4 packets.
</t> Such networks may or may not allow intra-LAN IPv4 connectivity.
<t> An IPv6-only network usually provides access to IPv4-only resources
IPv6-only network: a network which does not provide routing via NAT64 <xref target="RFC6146" format="default"/>.</dd>
functionality for IPv4 packets. <dt>NAT64:</dt><dd>Network Address and Protocol Translation from IPv6 Cl
Such networks may or may not allow intra-LAN IPv4 connectiv ients to IPv4 Servers <xref target="RFC6146" format="default"/>.</dd>
ity. <dt>Router Advertisement (RA):</dt><dd>A message used by IPv6 routers to
IPv6-only network usually provides access to IPv4-only reso advertise their presence, together
urces via NAT64 <xref target="RFC6146"/>. with various link and Internet parameters <xref target="RFC4861" for
</t> mat="default"/>.</dd>
<t> <dt>DNS64:</dt><dd>A mechanism for synthesizing AAAA records from A reco
NAT64: Network Address and Protocol Translation from IPv6 C rds <xref target="RFC6147" format="default"/>.</dd>
lients to IPv4 Servers <xref target="RFC6146"/>. <dt>Network attachment event:</dt><dd>A link up event, as described by
</t> <xref target="RFC4957" format="default"/>, that results in a host detect
<t> ing an available network.</dd>
RA: Router Advertisement, a message used by IPv6 routers <dt>Disabling the IPv4 stack on the host interface:</dt><dd>
to advertise their presence together <t>Host behavior when the host</t>
with various link and Internet parameters <xref target="RFC <ul>
4861"/>. <li>does not send any IPv4 packets from that interface,</li>
</t> <li>drops all IPv4 packets received on that interface, and</li>
<t> <li>does not forward any IPv4 packets to that interface.</li>
DNS64: a mechanism for synthesizing AAAA records from A rec </ul>
ords <xref target="RFC6147"/>. </dd>
</t> </dl>
<t>
Network attachment event: A Link Up event, as described by
<xref target="RFC4957" /> which results in a host detecting an available network
.
</t>
<t>
Disabling IPv4 stack on the host interface: the ho
st behavior when the host:
<list style="symbols">
<t>
does not send any IPv4 packets fro
m that interface,
</t>
<t>
drops all IPv4 packets received on
that interface and
</t>
<t>
does not forward any IPv4 packets
to that interface.
</t>
</list>
</t>
</section> </section>
</section> </section>
<section numbered="true" toc="default">
<section title="Reasons to Signal IPv6-Only Support in DHCPv4 Packets"> <name>Reasons to Signal IPv6-Only Support in DHCPv4 Packets</name>
<t> <t>
For networks which contain a mix of both IPv6-only ca For networks that contain a mix of both IPv6-only-capable hosts and
pable hosts and IPv4-requiring hosts, and which utilize DHCPv4 for configuring t IPv4-requiring hosts and that utilize DHCPv4 for configuring the IPv4
he IPv4 network stack on hosts, it seems natural to leverage the same protocol t network stack on hosts, it seems natural to leverage the same protocol to signal
o signal that IPv4 is discretional on a given segment. that IPv4 is discretional on a given segment.
An ability to remotely disable IPv4 on a host can be An ability to remotely disable IPv4 on a host can be seen as a new den
seen as a new denial-of-service attack vector. ial-of-service attack vector.
The proposed approach limits the attack surface to DH The approach provided in this document limits the attack surface to DH
CPv4-related attacks without introducing new vulnerable elements. CPv4-related
</t> attacks without introducing new vulnerable elements.
<t> </t>
Another benefit of using DHCPv4 for signaling is that IPv4 wi <t>
ll be disabled only if both the client and the server indicate IPv6-only capabil Another benefit of using DHCPv4 for signaling is that IPv4 will be dis
ity. abled only if both the client and the server indicate IPv6-only capability.
It allows IPv6-only capable hosts to turn off IPv4 only upon It allows IPv6-only-capable hosts to turn off IPv4 only upon receiving
receiving an explicit signal from the network and operate in dual-stack or IPv4- an explicit signal from the network and operate in dual-stack or IPv4-only mode
only mode otherwise. otherwise.
In addition, the proposed mechanism does not introduce any ad In addition, the mechanism defined in this document does not introduce
ditional delays to the process of configuring IP stack on hosts. any
If the network does not support IPv6-only/IPv4-on-demand mode additional delays to the process of configuring an IP stack on
, an IPv6-only capable host would configure an IPv4 address as quickly as on any hosts.
other host. If the network does not support IPv6-only/IPv4-on-demand mode, an
</t> IPv6-only-capable host would configure an IPv4 address as quickly as
<t> any other host.
Being a client/server protocol, DHCPv4 allows IPv4 to </t>
be selectively disabled on a per-host basis on a given network segment. <t>
Coexistence of IPv6-only, dual-stack and even IPv4-on Being a client/server protocol, DHCPv4 allows IPv4 to be selectively d
ly hosts on the same LAN would not only allow network administrators to preserve isabled on a per-host basis on a given network segment.
scarce IPv4 addresses but would also drastically simplify incremental deploymen The coexistence of IPv6-only, dual-stack, and even IPv4-only hosts on
t of IPv6-only networks, positively impacting IPv6 adoption. the same LAN would not only allow network administrators to preserve scarce IPv4
</t> addresses but would also drastically simplify incremental deployment of IPv6-on
ly networks, positively impacting IPv6 adoption.
</t>
</section> </section>
<section numbered="true" toc="default">
<section title="IPv6-Only Preferred Option"> <name>IPv6-Only Preferred Option</name>
<section anchor="Format" numbered="true" toc="default">
<section anchor="Format" title="Option format"> <name>Option Format</name>
<figure anchor="fig_Option">
<figure align="center" anchor="fig_Option" <name>IPv6-Only Preferred Option Format</name>
title="IPv6-Only Preferred Option Format"> <artwork align="center" name="" type="" alt=""><![CDATA[
<artwork align="center"><![CDATA[
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Length | Value | | Code | Length | Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value (contd) | | Value (cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
</figure>
]]></artwork> <t>Fields:</t>
</figure> <dl newline="false" spacing="normal">
<dt>Code:</dt>
<t>Fields:</t>
<texttable style="none">
<ttcol></ttcol>
<ttcol></ttcol>
<c>Code: </c> <c> 8-bit identifier of the IPv6-On
ly Preferred option code as assigned by IANA: TBD.
The client includes the Code in the Paramet
er Request List in DHCPDISCOVER and DHCPREQUEST messages as described in <xref t
arget="v4client"/>.</c>
<c>Length:</c> <c> 8-bit unsigned integer. The <dd>8-bit identifier of the IPv6-Only Preferred option code as
length of the option excluding the Code and Length Fields. The server MUST set assigned by IANA: 108.
the length field to 4. The client MUST ignore the IPv6-Only Preferred option if The client includes the Code in the Parameter Request List in DHCPDI
the length field value is not 4.</c> SCOVER and DHCPREQUEST messages as described in <xref target="v4client" format="
<c>Value:</c> <c> 32-bit unsigned integer. default"/>.</dd>
The number of seconds the client should dis <dt>Length:</dt>
able DHCPv4 for (V6ONLY_WAIT configuration variable). <dd>8-bit unsigned integer. The length of the option, excluding t
If the server pool is explicitly configured he Code and Length Fields. The server <bcp14>MUST</bcp14> set the length field
with a V6ONLY_WAIT timer the server MUST set the field to that configured value to 4. The client <bcp14>MUST</bcp14> ignore the IPv6-Only Preferred option if th
. Otherwise the server MUST set it to zero. e length field value is not 4.</dd>
The client MUST process that field as descr <dt>Value:</dt>
ibed in <xref target="v4client"/>. <dd><t>32-bit unsigned integer.
The client never sets this field as The number of seconds for which the client should disable DHCPv4 (V6
it never sends the full option but includes the option code in the Parameter Re ONLY_WAIT configuration variable).
quest List as described in <xref target="v4client"/>. If the server pool is explicitly configured with a V6ONLY_WAIT timer
</c> , the server <bcp14>MUST</bcp14> set the field to that configured value. Otherwi
<c></c><c></c> se, the server <bcp14>MUST</bcp14> set it to zero.
</texttable> The client <bcp14>MUST</bcp14> process that field as described in <x
ref target="v4client" format="default"/>.</t>
<t>The client never sets this field, as it never sends the full opti
on but includes the option code in the Parameter Request List as described in <x
ref target="v4client" format="default"/>.</t></dd>
</dl>
</section>
<section anchor="v4client" numbered="true" toc="default">
<name>DHCPv4 Client Behavior</name>
<t>
A DHCPv4 client <bcp14>SHOULD</bcp14> allow a device
administrator to configure IPv6-only capability either for a specific
interface (to indicate that the device is IPv6-only capable if
connected to a NAT64 network via that interface) or for all interfaces.
</section> If only a specific interface is configured as IPv6-only capable, the
<section anchor="v4client" title="DHCPv4 Client Behavior"> DHCPv4 client <bcp14>MUST NOT</bcp14> consider the host an
<t> IPv6-only-capable host for the purpose of sending/receiving DHCPv4 packe
A DHCPv4 client SHOULD allow a device administrator to con ts over any other interfaces.
figure IPv6-only preferred mode either for a specific interface (to indicate tha </t>
t the device is IPv6-only capable if connected to a NAT64 network via that inter <t>
face) or for all interfaces. The DHCPv4 client on an IPv4-requiring host <bcp14>MUST
If only a specific interface is configured as IPv6-only ca NOT</bcp14> include the IPv6-Only Preferred option code in the Param
pable the DHCPv4 client MUST NOT consider the host to be an IPv6-only capable fo eter Request List of any DHCPv4 packets and <bcp14>MUST</bcp14> ignore that opti
r the purpose of sending/receiving DHCPv4 packets over any other interfaces. on in packets received from DHCPv4 servers.
</t> </t>
<t> <t>
The DHCPv4 client on an IPv4-requiring host MUST NOT inclu DHCPv4 clients running on IPv6-only-capable hosts <bcp14>SHOULD</bc
de the IPv6-only Preferred option in the Parameter Request List of any DHCPv4 pa p14> include the IPv6-Only Preferred option code in the Parameter Request List i
ckets and MUST ignore that option in packets received from DHCPv4 servers. n DHCPDISCOVER and DHCPREQUEST messages for interfaces so enabled and follow the
</t> processing as described below on a per-enabled-interface basis.
<t> </t>
DHCPv4 clients running on IPv6-only capable hosts SHOULD i <t>
nclude the IPv6-only Preferred option code in the Parameter Request List in DHCP If the client did not include the IPv6-Only Preferred option code
DISCOVER and DHCPREQUEST messages for interfaces so enabled and follow the proce in the Parameter Request List in the DHCPDISCOVER or
ssing as described below on a per enabled interface basis. DHCPREQUEST message, it <bcp14>MUST</bcp14> ignore the IPv6-Only
</t> Preferred option in any messages received from the server.
<t> </t>
If the client did not include the IPv6-only Preferred opti <t>
on code in the Parameter Request List option in the DHCPDISCOVER or DHCPREQUEST If the client includes the IPv6-Only Preferred option code in the P
message it MUST ignore the IPv6-only Preferred option in any messages received arameter Request List and the DHCPOFFER message from the server contains a valid
from the server. IPv6-Only Preferred option, the client <bcp14>SHOULD NOT</bcp14> request the IP
</t> v4 address provided in the DHCPOFFER.
<t> If the IPv6-Only Preferred option returned by the server contains
If the client includes the IPv6-only Preferred opt a value greater than or equal to MIN_V6ONLY_WAIT, the client <bcp14
ion in the Parameter Request List and the DHCPOFFER message from the server cont >SHOULD</bcp14> set the V6ONLY_WAIT timer to that value.
ains a valid IPv6-only Preferred option, the client SHOULD NOT request the IPv4 Otherwise, the client <bcp14>SHOULD</bcp14> set the V6ONLY_WAIT tim
address provided in the DHCPOFFER. er to MIN_V6ONLY_WAIT.
If the IPv6-only Preferred option returned by the server c The client <bcp14>SHOULD</bcp14> stop the DHCPv4 configuration proc
ontains a value greater or equal to MIN_V6ONLY_WAIT, the client SHOULD set the V ess for V6ONLY_WAIT seconds or until a network attachment event, whichever happe
6ONLY_WAIT timer to that value. ns first.
Otherwise, the client SHOULD set the V6ONLY_WAIT timer to The host <bcp14>MAY</bcp14> disable the IPv4 stack completely on th
MIN_V6ONLY_WAIT. e affected interface for V6ONLY_WAIT seconds or until the network attachment eve
The client SHOULD stop the DHCPv4 configuration process fo nt, whichever happens first.
r V6ONLY_WAIT seconds or until a network attachment event, whichever happens fir </t>
st. <t>
The host MAY disable the IPv4 stack completely on The IPv6-Only Preferred option <bcp14>SHOULD</bcp14> be included in
the affected interface for V6ONLY_WAIT seconds or until the network attachment e the Parameter Request List in DHCPREQUEST messages (after receiving a DHCPOFFER
vent, whichever happens first. without this option, for an INIT-REBOOT, or when renewing or rebinding a leased
</t> address).
<t> If the DHCPv4 server responds with a DHCPACK that includes the
The IPv6-only Preferred option SHOULD be included IPv6-Only Preferred option, the client's behavior depends on the cl
in the Parameter Request List option in DHCPREQUEST messages (after receiving a ient's state.
DHCPOFFER without this option, for a INIT-REBOOT, or when renewing or rebinding If the client is in the INIT-REBOOT state, it
a leased address). <bcp14>SHOULD</bcp14> stop the DHCPv4 configuration process or
If the DHCPv4 server responds with a DHCPACK that disable the IPv4 stack completely for V6ONLY_WAIT seconds or
includes the IPv6-only Preferred option, the client behaviour depends on the cl until the network attachment event, whichever happens first.
ient's state. It also <bcp14>MAY</bcp14> send a DHCPRELEASE message.
If the client is in the INIT-REBOOT state it SHOUL If the client is in any other state, it <bcp14>SHOULD</bcp14> conti
D stop the DHCPv4 configuration process or disable IPv4 stack completely for V6O nue to use the assigned IPv4 address until further DHCPv4 reconfiguration events
NLY_WAIT seconds or until the network event, whichever happens first. .
It also MAY send a DHCPRELEASE message. </t>
If the client is in any other state it SHOULD cont <t>
inue to use the assigned IPv4 address until further DHCPv4 reconfiguration event If the client includes the IPv6-Only Preferred option code in the
s. Parameter Request List and the server responds with a DHCPOFFER mes
</t> sage without a valid IPv6-Only Preferred option, the client <bcp14>MUST</bcp14>
<t> proceed as normal with a DHCPREQUEST.
If the client includes the IPv6-only Preferred option in </t>
the Parameter Request List and the server responds with DHCPOFFER message withou <t>
t a valid IPv6-only Preferred option, the client MUST proceed as normal with a D If the client waits for multiple DHCPOFFER responses and selects on
HCPREQUEST. e of them, it <bcp14>MUST</bcp14> follow the processing for the IPv6-Only Prefer
</t> red option based on the selected response.
<t> A client <bcp14>MAY</bcp14> use the presence of the IPv6-Only Prefe
If the client waits for multiple DHCPOFFER responses and s rred option as a selection criterion.
elects one of them, it MUST follow the processing for the IPv6-only Preferred op </t>
tion based on the selected response. <t>
A client MAY use the presence of the IPv6-only Preferred o When an IPv6-only-capable client receives the IPv6-Only Preferred
ption as a selection criteria. option from the server, the client <bcp14>MAY</bcp14> configure an
</t> IPv4 link-local address <xref target="RFC3927" format="default"/>.
<t> In that case, IPv6-only-capable devices might still be able to comm
When an IPv6-only capable client receives the IPv6-Only Pr unicate over IPv4 to other devices on the link.
eferred option from the server, the client MAY configurean IPv4 link-local addre The Auto-Configure option <xref target="RFC2563"
ss <xref target="RFC3927"/>. format="default"/> can be used to control the autoconfiguration
In that case IPv6-only capable devices might still be able of IPv4 link-local addresses.
to communicate over IPv4 to other devices on the link. <xref target="autoconf" format="default"/> discusses the
The Auto-Configure Option <xref target="RFC2563"/> can be interaction between the IPv6-Only Preferred option and the Auto-Con
used to control IPv4 link-local addresses autoconfiguration. figure option.
<xref target="autoconf"/> discusses the interaction betwee </t>
n the IPv6-only Preferred and the Auto-Configure options. </section>
</t> <section anchor="v4srv" numbered="true" toc="default">
</section> <name>DHCPv4 Server Behavior</name>
<section anchor="v4srv" title="DHCPv4 Server Behavior"> <t>
<t> The DHCPv4 server <bcp14>SHOULD</bcp14> be able to configure all or
The DHCPv4 server SHOULD be able to configure all or indiv individual pools to include the IPv6-Only Preferred option in DHCPv4 responses
idual pools to include the IPv6-only preferred option in DHCPv4 responses if the if the client included the option code in the Parameter Request List.
client included the option code in the Parameter Request List option. The DHCPv4 server <bcp14>MAY</bcp14> have a configuration option to
The DHCPv4 server MAY have a configuration option to speci specify the V6ONLY_WAIT timer for all or individual IPv6-mostly pools.
fy the V6ONLY_WAIT timer for all or individual IPv6-mostly pools. </t>
</t> <t>
<t> The server <bcp14>MUST NOT</bcp14> include the IPv6-Only
The server MUST NOT include the IPv6-only Preferred optio Preferred option in the DHCPOFFER or DHCPACK message if the
n in the DHCPOFFER or DHCPACK message if the YIADDR field in the message does no selected pool is not configured as IPv6-mostly.
t belong to a pool configured as IPv6-mostly. The server <bcp14>MUST NOT</bcp14> include the IPv6-Only Preferred
The server MUST NOT include the IPv6-only Preferred optio option in the DHCPOFFER or DHCPACK message if the option was not present in the
n in the DHCPOFFER or DHCPACK message if the option was not present in the Param Parameter Request List sent by the client.
eter Request List sent by the client. </t>
</t> <t>
<t> If the IPv6-Only Preferred option is present in the Parameter Reque
If the IPv6-only Preferred option is present in the Parame st List received from the client and the corresponding DHCPv4 pool is explicitly
ter Request List received from the client and the corresponding DHCPv4 pool is e configured as belonging to an IPv6-mostly network segment, the server <bcp14>MU
xplicitly configured as belonging to an IPv6-mostly network segment, the server ST</bcp14> include the IPv6-Only Preferred option when responding with the DHCPO
MUST include the IPv6-only Preferred option when responding with the DHCPOFFER o FFER or DHCPACK message.
r DHCPACK message. If the server responds with the IPv6-Only Preferred option and the
If the server responds with the IPv6-only Preferred option V6ONLY_WAIT timer is configured for the pool, the server <bcp14>MUST</bcp14> cop
and the V6ONLY_WAIT timer is configured for the pool, the server MUST copy the y the configured value to the IPv6-Only Preferred option value field.
configured value to the IPv6-only Preferred option value field. Otherwise, it <bcp14>MUST</bcp14> set the field to zero.
Otherwise it MUST set the field to zero.
The server SHOULD NOT assign an address from the pool. The server <bcp14>SHOULD NOT</bcp14> assign an address from the poo
Instead it SHOULD return 0.0.0.0 as the offered address. l.
Alternatively, if offering 0.0.0.0 is not feasible Instead, it <bcp14>SHOULD</bcp14> return 0.0.0.0 as the offered add
, for example due to some limitations of the server or the network infrastructur ress.
e, the server MAY include an available IPv4 address from the pool into the DHCPO Alternatively, if offering 0.0.0.0 is not feasible -- for
FFER as per recommendations in <xref target="RFC2131"/>. example, due to some limitations of the server or the network
In this case, the offered address MUST be infrastructure -- the server <bcp14>MAY</bcp14> include in the
a valid address that is not committed to any other client. DHCPOFFER an available IPv4 address from the pool, as per recommend
Because the client is not expected ever to ations in <xref target="RFC2131" format="default"/>.
request this address, the server SHOULD NOT reserve the address and SHOULD NOT In this case, the offered address <bcp14>MUST</bcp14> be a valid ad
verify its uniqueness. dress that is not committed to any other client.
If the client then issues a DHCPREQUEST fo Because the client is not ever expected to request this address, th
r the address, the server MUST process it per <xref target="RFC2131"/>, includin e server <bcp14>SHOULD NOT</bcp14> reserve the address and <bcp14>SHOULD NOT</bc
g replying with a DHCPACK for the address if in the meantime it has not been com p14> verify its uniqueness.
mitted to another client. If the client then issues a DHCPREQUEST for the address, the
</t> server <bcp14>MUST</bcp14> process it per <xref target="RFC2131"
<t> format="default"/>, including replying with a DHCPACK for the
If a client includes both a Rapid-Commit option <xref targ address if it has not been committed to another
et="RFC4039"/> and IPv6-Only Preferred option in the DHCPDISCOVER message the se client in the meantime.
rver SHOULD NOT honor the Rapid-Commit option if the response would contain the </t>
IPv6-only Preferred option to the client. <t>
It SHOULD instead respond with a DHCPOFFER as indicated ab If a client includes both a Rapid Commit option <xref
ove. target="RFC4039" format="default"/> and an IPv6-Only Preferred
</t> option in the DHCPDISCOVER message, the server <bcp14>SHOULD
<t> NOT</bcp14> honor the Rapid Commit option if the response to the cl
If the server receives a DHCPREQUEST containing th ient would contain the IPv6-Only Preferred option.
e IPv6-only Preferred option for the address from a pool configured as IPv6-mos It <bcp14>SHOULD</bcp14> instead respond with a DHCPOFFER as indica
tly, the server MUST process it per <xref target="RFC2131"/>. ted above.
</t> </t>
<section anchor="autoconf" title="Interaction with RFC2563"> <t>
<t> If the server receives a DHCPREQUEST containing the IPv6-Only Prefe
<xref target="RFC2563"/> defines an Auto-Configure DHCPv4 option to disable IPv4 rred option for the address from a pool configured as IPv6-mostly, the server <b
link-local address configuration for IPv4 clients. Clients can support both, ne cp14>MUST</bcp14> process it per <xref target="RFC2131" format="default"/>.
ither or just one of IPv6-Only Preferred and Auto-Configure options. </t>
If a client sends both IPv6-Only Preferred and Auto-Configure options the networ <section anchor="autoconf" numbered="true" toc="default">
k administrator can prevent the host from configuring an IPv4 link-local address <name>Interaction with RFC 2563</name>
on an IPv6-mostly network. <t>
To achieve this the server needs to send DHCPOFFER which contains a 'yiaddr' of <xref target="RFC2563" format="default"/> defines an Auto-Configure DHCPv4
0x00000000, and the Auto-Configure flag saying "DoNotAutoConfigure". option to disable IPv4 link-local address configuration for IPv4
clients. Clients can support both the IPv6-Only Preferred option and the
Auto-Configure option, just one of the options, or neither option.
If a client sends both the IPv6-Only Preferred option and the Auto-Configure opt
ion, the network administrator can prevent the host from configuring an IPv4 lin
k-local address on an IPv6-mostly network.
To achieve this, the server needs to send a DHCPOFFER that contains a 'yiaddr'
of 0.0.0.0, and the Auto-Configure flag set to "DoNotAutoConfigure".
</t> </t>
<t> <t>
However special care should be taken in a situation when a server supports both However, special care should be taken in a situation where a server supports
options and receives just IPv6-Only Preferred option from a client. both options and receives just an IPv6-Only Preferred option from a client.
Section 2.3 of <xref target="RFC2563"/> states that if no address is chosen for <xref target="RFC2563" sectionFormat="of" section="2.3"/>
the host (which would be the case for IPv6-only capable clients on IPv6-mostly n states that if no address is chosen for the host (which would be the case for
etwork) then: IPv6-only-capable clients on an IPv6-mostly network), then
"If the DHCPDISCOVER does not contain the Auto-Configure option, it is not answe red." "If the DHCPDISCOVER does not contain the Auto-Configure option, it is not answe red."
Such behavior would be undesirable for clients supporting the IPv6-Only Preferre Such behavior would be undesirable for clients supporting the IPv6-Only
d option without supporting the Auto-Configure option as they would not receive Preferred option without supporting the Auto-Configure option, as they would
any response from the server and would keep asking, instead of disabling DHCPv4 not receive any response from the server and would keep requesting a response in
for V6ONLY_WAIT seconds. stead of disabling DHCPv4 for V6ONLY_WAIT seconds.
Therefore the following update is made to Section 2.3 of <xref target="RFC2563"/ Therefore, the following update is made to <xref target="RFC2563" sectionFormat=
>" "of" section="2.3"/>.
</t> </t>
<t> <t>
OLD TEXT: OLD TEXT:
</t> </t>
<t> <blockquote><t>However, if no address is chosen for the host, a few additio
</t> nal steps <bcp14>MUST</bcp14> be taken.</t>
<t> <t>
However, if no address is chosen for the host, a few additional steps MUST be ta
ken.
</t>
<t>
If the DHCPDISCOVER does not contain the Auto-Configure option, it is not answer ed. If the DHCPDISCOVER does not contain the Auto-Configure option, it is not answer ed.
</t> </t>
<t> </blockquote>
</t> <t>
<t>
NEW TEXT: NEW TEXT:
</t> </t>
<t>
</t> <blockquote><t>However, if no address is chosen for the host, a few additio
<t> nal steps <bcp14>MUST</bcp14> be taken.
However, if no address is chosen for the host, a few additional steps MUST be ta
ken.
</t> </t>
<t> <t>
If the DHCPDISCOVER does not contain the Auto-Configure option and the IPv6-Only Preferred option is not present, it is not answered. If the DHCPDISCOVER does not contain the Auto-Configure option and the IPv6-Only Preferred option is not present, it is not answered.
If the DHCPDISCOVER does not contain the Auto-Configure option but contains the IPv6-Only Preferred option, the processing rules for the IPv6-Only Preferred opt ion apply. If the DHCPDISCOVER does not contain the Auto-Configure option but contains the IPv6-Only Preferred option, the processing rules for the IPv6-Only Preferred opt ion apply.
</t> </t>
<t> </blockquote>
</t> </section>
</section>
</section> <section anchor="vars" numbered="true" toc="default">
</section> <name>Constants and Configuration Variables</name>
<section anchor="vars" title="Constants and Configuration Variables"> <dl newline="false" spacing="normal">
<texttable style="none"> <dt>V6ONLY_WAIT:</dt>
<ttcol></ttcol> <dd>The time for which the client <bcp14>SHOULD</bcp14> stop the D
<ttcol></ttcol> HCPv4 configuration process. The value <bcp14>MUST NOT</bcp14> be less than MIN_
<c>V6ONLY_WAIT</c> <c>The time for which the client V6ONLY_WAIT seconds. Default: 1800 seconds</dd>
SHOULD stop the DHCPv4 configuration process. The value MUST NOT be less than M <dt>MIN_V6ONLY_WAIT:</dt>
IN_V6ONLY_WAIT seconds. Default: 1800 seconds</c> <dd>The lower boundary for V6ONLY_WAIT. Value: 300 seconds</dd>
<c>MIN_V6ONLY_WAIT</c> <c>The lower boundary for V6 </dl>
ONLY_WAIT. Value: 300 seconds</c> </section>
<c></c><c></c>
</texttable>
</section>
</section> </section>
<section anchor="v6onlydef" title="IPv6-Only Transition Technologies Considerati <section anchor="v6onlydef" numbered="true" toc="default">
ons"> <name>IPv6-Only Transition Technology Considerations</name>
<t> <t>
Until IPv6 adoption in the Internet reaches 100%, communication between an IPv6- Until IPv6 adoption in the Internet reaches 100%, communication between an
only host and IPv4-only destination requires some form of transition mechanism d IPv6-only host and an IPv4-only destination requires some form of a transition m
eployed in the network. echanism deployed in the network.
At the time of writing, the only such mechanism that is widely supported by end At the time of writing, the only such mechanism that is widely supported by end
hosts is NAT64 <xref target="RFC6146"/> (either with or without 464XLAT). hosts is NAT64 <xref target="RFC6146" format="default"/> (either with or without
Therefore the IPv6-only Preferred option is only sent by hosts capable of operat 464XLAT).
ing on NAT64 networks. Therefore, the IPv6-Only Preferred option is only sent by hosts capable of opera
In a typical deployment scenario, a network administrator would not configure th ting on NAT64 networks.
e DHCPv4 server to return the IPv6-only Preferred option unless the network prov In a typical deployment scenario, a network administrator would not configure th
ides NAT64 service. e DHCPv4 server to return the IPv6-Only Preferred option unless the network prov
</t> ides NAT64 service.
<t>
Hypothetically, it is possible for multiple transition technologies to coexist.
In such scenario some form of negotiation would be required between a client and
a server to ensure that the transition technology supported by the client is th
e one the network provides.
However it seems unlikely that any new transition technology woul
d arise and be widely adopted in any foreseeable future.
Therefore adding support for non-existing technologies seems to b
e suboptimal and the proposed mechanism implies that NAT64 is used to facilitate
connectivity between IPv6 and IPv4.
In the unlikely event that a new transition mechanism becomes wid
ely deployed, the applicability of the IPv6-Only-Preferred option to that mechan
ism will depend on the nature of the new mechanism.
If the new mechanism is designed in such a way that it's fully tr
ansparent for hosts that support NAT64 and the IPv6-Only-Preferred option, then
the option can continue to be used with the new mechanism.
If the new mechanism is not compatible with NAT64, and implementa
tion on the host side is required to support it, then a new DHCPv4 option needs
to be defined.
</t>
<t>
It should be also noted that declaring a host (technically, a host interface) IP
v6-only capable is a policy decision. For example,
<list style="symbols">
<t>
An operating system vendor may make such decision and configure their DHCPv4 cli
ents to send the IPv6-Only Preferred option by default if the OS has 464XLAT CLA
T <xref target="RFC6877"/> enabled.
</t>
<t>
An enterprise network administrator may provision the corporate hosts as IPv6-on
ly capable if all applications users are supposed to run have been tested in an
IPv6-only environment (or if 464XLAT CLAT is enabled on the devices).
</t>
<t>
IoT devices may be shipped in IPv6-only capable mode if they are designed to con
nect to IPv6-enabled cloud destination only.
</t> </t>
</list> <t>
Hypothetically, it is possible for multiple transition technologies to
coexist. In such a scenario, some form of negotiation would be required between
a client and a server to ensure that the transition technology supported by the
client is the one the network provides.
However, it seems unlikely that any new transition technology wo
uld arise and be widely adopted in the foreseeable future.
Therefore, adding support for non-existing technologies seems
to be suboptimal, so this document implies that NAT64 is used to
facilitate
connectivity between IPv6 and IPv4.
In the unlikely event that a new transition mechanism becomes wi
dely deployed, the applicability of the IPv6-Only Preferred option to that mecha
nism will depend on the nature of the new mechanism.
If the new mechanism is designed in such a way that it's fully t
ransparent for hosts that support NAT64 and the IPv6-Only Preferred option, then
the option can continue to be used with the new mechanism.
If the new mechanism is not compatible with NAT64 and implementa
tion on the host side is required to support it, then a new DHCPv4 option needs
to be defined.
</t> </t>
<t>
</section> It should also be noted that declaring a host (technically, a host interface) IP
v6-only capable is a policy decision. For example,
<section anchor="IANA" title="IANA Considerations">
<t>The IANA is requested to assign a new DHCPv4 Option code for the IPv6-Only Pr
eferred option
from the BOOTP Vendor Extensions and DHCPv4 Options registry, located at
https://www.iana.org/assignments/bootp-dhcp-parameters/bootp-dhcp-paramete
rs.xhtml#options .
If possible, please assign option code 108.
</t> </t>
<ul spacing="normal">
<texttable anchor="option_table"> <li>
<ttcol align="left">Tag</ttcol> An OS vendor may make such a decision and configure their DHCPv4
<ttcol align="left">Name</ttcol> clients to send the IPv6-Only Preferred option by default if the OS has
<ttcol align="left">Data Length</ttcol> a 464XLAT CLAT <xref target="RFC6877" format="default"/> enabled.
<ttcol align="left">Meaning</ttcol> </li>
<ttcol align="left">Reference</ttcol> <li>
<c>TBD (proposed value: 108)</c> An enterprise network administrator may provision the corporate hosts as
<c>IPv6-only Preferred option</c> IPv6-only capable if all applications that users are supposed to run have been
<c>4</c> tested in an IPv6-only environment (or if a 464XLAT CLAT is enabled on the devic
<c>Number of seconds to disable DHCPv4 for</c> es).
<c>draft-ietf-dhc-v6only</c> </li>
</texttable> <li>
Internet of Things (IoT) devices may be shipped in IPv6-only-capable mode if the
y are designed to
connect to an IPv6-enabled cloud destination only.
</li>
</ul>
</section> </section>
<section anchor="IANA" numbered="true" toc="default">
<name>IANA Considerations</name>
<section anchor="Security" title="Security Considerations"> <t>The IANA has assigned a new DHCPv4 option code for the IPv6-Only Prefer
<t> red option
An attacker might send a spoofed DHCPOFFER containing from the "BOOTP Vendor Extensions and DHCP Options" registry, located at
IPv6-only Preferred option with the value field set to a large number, such as <eref target="https://www.iana.org/assignments/bootp-dhcp-parameters/" bra
0xffffffff, effectively disabling DHCPv4 on clients supporting the option. ckets="angle"/>.
If the network is IPv4-only such clients would lose c </t>
onnectivity, while on a dual-stack network without NAT64 service only connectivi
ty to IPv4-only destinations would be affected.
The recovery would require triggering a network attac
hment event.
However it should be noted that if the network does n
ot provide protection from a rogue DHCPv4 server the similar attack vector can b
e executed by offering an invalid address and setting the Lease Time option valu
e field to 0xffffffff.
The latter attack would affect all hosts, not just ho
sts that support the IPv6-only Preferred option.
Therefore the security measures against rogue DHCPv4
servers would be sufficient to prevent the attacks specific to IPv6-only Preferr
ed option.
Additionally such attacks can only be executed if the
victim prefers the rogue DHCPOFFER over the legitimate ones.
Therefore for the attack to be successful the attacke
r needs to know the selection criteria used by the client and to be able to make
its rogue offer more preferable.
</t> <dl newline="false" spacing="compact">
<t> <dt>Tag:</dt>
It should be noted that disabling IPv4 on a host upon receivi <dd>108</dd>
ng the IPv6-only Preferred option from the DHCPv4 server protects the host from <dt>Name:</dt>
IPv4-related attacks and therefore could be considered a security feature as it <dd>IPv6-Only Preferred</dd>
reduces the attack surface. <dt>Data Length:</dt>
</t> <dd>4</dd>
<dt>Meaning:</dt>
<dd>Number of seconds that DHCPv4 should be disabled</dd>
<dt>Reference:</dt>
<dd>RFC 8925</dd>
</dl>
</section> </section>
<section anchor="Acknowledgements" title="Acknowledgements"> <section anchor="Security" numbered="true" toc="default">
<t> <name>Security Considerations</name>
<t>
An attacker might send a spoofed DHCPOFFER containing an IPv6-Only Pre
ferred option with the value field set to a large number, such as 0xffffffff, ef
fectively disabling DHCPv4 on clients supporting the option.
If the network is IPv4-only, such clients would lose connectivity, whi
le on a dual-stack network without NAT64 service, only connectivity to IPv4-only
destinations would be affected.
Recovery from such an attack would require triggering a network attach
ment event.
Thanks to the following people (in alphabetical order) for th However, it should be noted that if the network does not provide
eir review and feedback: Mohamed Boucadair, Martin Duke, Russ Housley, Sheng Jia protection from a rogue DHCPv4 server, the similar attack vector can
ng, Benjamin Kaduk, Murray Kucherawy, Ted Lemon, Roy Marples, Bjorn Mork, Alvaro be executed by offering an invalid address and setting the Lease Time
Retana, Peng Shuping, Pascal Thubert, Bernie Volz, Eric Vyncke, Robert Wilton. option <xref target="RFC2132"/> value field to 0xffffffff.
Authors would like to thank Bob Hinden and Brian Carp The latter attack would affect all hosts -- not just hosts that suppor
enter for the initial idea of signaling IPv6-only capability to hosts. t the IPv6-Only Preferred option.
Special thanks to Erik Kline, Mark Townsley and Macie Therefore, the security measures against rogue DHCPv4 servers would
j Zenczykowski for the discussion which led to the idea of signalling IPv6-only be sufficient to prevent attacks specific to the IPv6-Only Preferred o
capability over DHCPv4. ption.
</t> Additionally, such attacks can only be executed if the victim
prefers the rogue DHCPOFFER over legitimate offers.
Therefore, for the attack to be successful, the attacker needs to
know the selection criteria used by the client and be able to make
its rogue offer preferable to other offers.
</t>
<t>
It should be noted that disabling IPv4 on a host upon receiving the IP
v6-Only Preferred option from the DHCPv4 server protects the host from IPv4-rela
ted attacks and therefore could be considered a security feature, as it reduces
the attack surface.
</t>
</section> </section>
</middle> </middle>
<!-- *****BACK MATTER ***** -->
<back> <back>
<references title="Normative References"> <references>
&RFC2119; <name>References</name>
&RFC2131; <references>
&RFC2563; <name>Normative References</name>
&RFC3927; <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.
&RFC4039; xml"/>
&RFC8174; <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2131.
</references> xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2563.
<references title="Informative References"> xml"/>
<!-- &RFC6052; --> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3927.
&RFC4861; xml"/>
&RFC4957; <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4039.
&RFC6146; xml"/>
&RFC6147; <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.
&RFC6877; xml"/>
</references>
<references>
<name>Informative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2132.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4861.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4957.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6146.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6147.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6877.
xml"/>
</references>
</references> </references>
<section anchor="Acknowledgements" numbered="false" toc="default">
<name>Acknowledgements</name>
<t>
Thanks to the following people (in alphabetical order) for their review
and feedback: <contact fullname="Mohamed Boucadair"/>, <contact
fullname="Martin Duke"/>, <contact fullname="Russ Housley"/>, <contact
fullname="Sheng Jiang"/>, <contact fullname="Benjamin Kaduk"/>, <contact
fullname="Murray Kucherawy"/>, <contact fullname="Ted Lemon"/>, <contact
fullname="Roy Marples"/>, <contact fullname="Bjorn Mork"/>, <contact
fullname="Alvaro Retana"/>, <contact fullname="Peng Shuping"/>, <contact
fullname="Pascal Thubert"/>, <contact fullname="Bernie Volz"/>, <contact
fullname="Éric Vyncke"/>, and <contact fullname="Robert Wilton"/>.
The authors would like to thank <contact fullname="Bob Hinden"/> and <cont
act fullname="Brian Carpenter"/> for the initial idea of signaling IPv6-only cap
ability to hosts.
Special thanks to <contact fullname="Erik Kline"/>, <contact fullname="Mar
k Townsley"/>, and <contact fullname="Maciej Zenczykowski"/> for the discussion
that led to the idea of signaling IPv6-only capability over DHCPv4.
</t>
</section>
</back> </back>
</rfc> </rfc>
 End of changes. 48 change blocks. 
725 lines changed or deleted 615 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/