rfc9915.original.xml   rfc9915.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE rfc [ <!DOCTYPE rfc [
<!ENTITY nbsp "&#160;"> <!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;"> <!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;"> <!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;"> <!ENTITY wj "&#8288;">
]> ]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<?rfc toc="yes"?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" docName="draft-ie
<?rfc tocdepth="4"?> tf-dhc-rfc8415bis-12" number="9915" ipr="pre5378Trust200902" obsoletes="8415" su
<?rfc symrefs="yes"?> bmissionType="IETF" consensus="true" updates="" xml:lang="en" tocInclude="true"
<?rfc sortrefs="yes" ?> tocDepth="4" symRefs="true" sortRefs="true" version="3">
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<?rfc text-list-symbols="-*+o"?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" docName="draft-ie
tf-dhc-rfc8415bis-12" ipr="pre5378Trust200902" obsoletes="8415" submissionType="
IETF" consensus="true" updates="" xml:lang="en" tocInclude="true" tocDepth="4" s
ymRefs="true" sortRefs="true" version="3">
<!-- xml2rfc v2v3 conversion 3.17.0 -->
<front> <front>
<title abbrev="DHCP for IPv6">Dynamic Host Configuration Protocol for IPv6 <title abbrev="DHCP for IPv6">Dynamic Host Configuration Protocol for IPv6
(DHCPv6)</title> (DHCPv6)</title>
<!-- The status field doesn't seem to work, at least not with the latest xml <seriesInfo name="RFC" value="9915"/>
2rfc 3.25.0.
The RFC7991, section 2.47.3 bullet 1 says it should. But the
https://ietf-tools.github.io/xml2rfc/#name-seriesinfo docs have it empt
y.
Is this attribute being deprecated?
-->
<seriesInfo name="Internet-Draft" value="draft-ietf-dhc-rfc8415bis-12" statu
s="full-standard"/>
<author fullname="Tomek Mrugalski" initials="T." surname="Mrugalski"> <author fullname="Tomek Mrugalski" initials="T." surname="Mrugalski">
<organization abbrev="ISC">Internet Systems Consortium, <organization abbrev="ISC">Internet Systems Consortium,
Inc.</organization> Inc.</organization>
<address> <address>
<postal> <postal>
<street>PO Box 360</street> <street>PO Box 360</street>
<city>Newmarket</city> <city>Newmarket</city>
<region>NH</region> <region>NH</region>
<code>03857</code> <code>03857</code>
<country>United States of America</country> <country>United States of America</country>
skipping to change at line 92 skipping to change at line 81
<postal> <postal>
<street>100 Main Street, Suite #212</street> <street>100 Main Street, Suite #212</street>
<city>Dover</city> <city>Dover</city>
<region>NH</region> <region>NH</region>
<code>03820</code> <code>03820</code>
<country>United States of America</country> <country>United States of America</country>
</postal> </postal>
<email>tim@qacafe.com</email> <email>tim@qacafe.com</email>
</address> </address>
</author> </author>
<date year="2025"/> <date year="2025" month="November"/>
<area>INT</area>
<workgroup>dhc</workgroup>
<keyword>DHCPv6</keyword> <keyword>DHCPv6</keyword>
<keyword>IPv6</keyword> <keyword>IPv6</keyword>
<keyword>DHCP</keyword> <keyword>DHCP</keyword>
<abstract> <abstract>
<t>This document specifies the Dynamic Host Configuration Protocol for <t>This document specifies the Dynamic Host Configuration Protocol for
IPv6 (DHCPv6): an extensible mechanism for configuring nodes with IPv6 (DHCPv6), an extensible mechanism for configuring nodes with
network configuration parameters, IP addresses, and prefixes. Parameters network configuration parameters, IP addresses, and prefixes. Parameters
can be provided statelessly, or in combination with stateful assignment can be provided statelessly or in combination with stateful assignment
of one or more IPv6 addresses and/or IPv6 prefixes. DHCPv6 can operate of one or more IPv6 addresses and/or IPv6 prefixes. DHCPv6 can operate
either in place of or in addition to stateless address autoconfiguration either in place of or in addition to stateless address autoconfiguration
(SLAAC).</t> (SLAAC).</t>
<t>This document obsoletes RFC8415 to incorporate reported errata and to <!--[rfced] In the abstract, should "reported errata" be "verified errata
reports" for accuracy? In the RFC errata system, "Reported" is the status
name for errata that have not yet been reviewed (see https://www.rfc-editor.org/
errata-definitions/).
In addition, we suggest splitting the sentence as follows.
Original:
This document obsoletes RFC8415 to incorporate reported errata and
to obsolete the assignment of temporary addresses (the IA_TA option)
and the server unicast capability (the Server Unicast option and
UseMulticast status code).
Perhaps:
This document obsoletes RFC 8415. It incorporates reported errata and
obsoletes the assignment of temporary addresses (the IA_TA option)
and the server unicast capability (the Server Unicast option and
UseMulticast status code).
Similarly, in Section 1.1, should "all applicable errata" be
"verified errata reports"?
Original:
This document obsoletes [RFC8415] by applying all applicable errata
and obsoleting two features that have not been widely implemented -
the assignment of temporary addresses using the IA_TA option and
allowing clients to unicast some messages directly to the server if
the server sent the Server Unicast option to a client in an early
exchange.
Perhaps:
This document obsoletes [RFC8415]. It applies verified errata reports
and obsoletes two features that have not been widely implemented -
the assignment of temporary addresses using the IA_TA option and
allowing clients to unicast some messages directly to the server if
the server sent the Server Unicast option to a client in an early
exchange.
-->
<t>This document obsoletes RFC 8415 to incorporate reported errata and to
obsolete the assignment of temporary addresses (the IA_TA option) and the obsolete the assignment of temporary addresses (the IA_TA option) and the
server unicast capability (the Server Unicast option and UseMulticast server unicast capability (the Server Unicast option and UseMulticast
status code).</t> status code).</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section anchor="intro-and-overview" numbered="true" toc="default"> <section anchor="intro-and-overview" numbered="true" toc="default">
<name>Introduction</name> <name>Introduction</name>
<t>This document specifies DHCP for IPv6 (DHCPv6), a client/server <t>This document specifies DHCP for IPv6 (DHCPv6), a client/server
protocol that provides managed configuration of devices. The basic protocol that provides managed configuration of devices. The basic
operation of DHCPv6 provides configuration for clients connected to operation of DHCPv6 provides configuration for clients connected to
the same link as the server. Relay agent functionality is also the same link as the server. Relay agent functionality is also
defined for enabling communication between clients and servers that defined for enabling communication between clients and servers that
are not on the same link.</t> are not on the same link.</t>
<t>DHCPv6 can provide a device with addresses assigned by a DHCPv6 <t>DHCPv6 can provide a device with addresses assigned by a DHCPv6
server and other configuration information; this data is carried in server and other configuration information; this data is carried in
options. DHCPv6 can be extended through the definition of new options options. DHCPv6 can be extended through the definition of new options
to carry configuration information not specified in this document.</t> to carry configuration information not specified in this document.</t>
<!--[rfced] Please clarify this sentence. If the suggestion doesn't
correctly capture your intent, please let us know how we can rephrase.
Original:
Note that these documents use "requesting router" for what this
document uses client and "delegating router" for server.
Perhaps:
Note that those documents use "requesting router" and "delegating
router" where this document uses "client" and "server", respectively.
-->
<t>DHCPv6 also supports a mechanism for automated delegation of <t>DHCPv6 also supports a mechanism for automated delegation of
IPv6 prefixes. Through this mechanism, a server IPv6 prefixes. Through this mechanism, a server
can delegate prefixes to clients. Use of this mechanism is can delegate prefixes to clients. Use of this mechanism is
specified as part of <xref target="RFC7084" format="default"/> and by <xre f target="TR-187" format="default"/>. specified as part of <xref target="RFC7084" format="default"/> and by <xre f target="TR-187" format="default"/>.
Note that these documents use "requesting router" for what this Note that these documents use "requesting router" for what this
document uses client and "delegating router" for server.</t> document uses client and "delegating router" for server.</t>
<t>DHCP can also be used just to provide other configuration options <t>DHCP can also be used just to provide other configuration options
(i.e., no addresses or prefixes). That implies that the (i.e., no addresses or prefixes). That implies that the
server does not have to track any state; thus, this mode is called server does not have to track any state; thus, this mode is called
"stateless DHCPv6". Mechanisms necessary to support stateless DHCPv6 are "stateless DHCPv6". Mechanisms necessary to support stateless DHCPv6 are
much simpler than mechanisms needed to support stateful DHCPv6.</t> much simpler than mechanisms needed to support stateful DHCPv6.</t>
<section anchor="previous-dhcp6" numbered="true" toc="default"> <section anchor="previous-dhcp6" numbered="true" toc="default">
<name>Relationship to Previous DHCPv6 Standards</name> <name>Relationship to Previous DHCPv6 Standards</name>
<!--[rfced] Is this a list of 2 or 3 items (i.e., is it lifetime hints
and timer hints?)?
Original:
It also obsoleted a small number of mechanisms: delayed
authentication, lifetime and timer hints sent by a client.
Perhaps:
It also obsoleted a small number of mechanisms: delayed
authentication, lifetime, and timer hints sent by a client.
-->
<t><xref target="RFC8415" format="default"/> provided a unified, correct ed, and cleaned-up <t><xref target="RFC8415" format="default"/> provided a unified, correct ed, and cleaned-up
definition of DHCPv6 that also covered all applicable errata filed definition of DHCPv6 that also covered all applicable errata filed
against older RFCs. It also obsoleted a small number of mechanisms: against older RFCs at the time of its writing. It also obsoleted a small number of mechanisms:
delayed authentication, lifetime and timer hints sent by a client.</t> delayed authentication, lifetime and timer hints sent by a client.</t>
<t>This document obsoletes <xref target="RFC8415" format="default"/> by applying all <t>This document obsoletes <xref target="RFC8415" format="default"/> by applying all
applicable errata and obsoleting two features that have not applicable errata and obsoleting two features that have not
been widely implemented - the assignment of temporary addresses been widely implemented: the assignment of temporary addresses
using the IA_TA option and allowing clients to unicast some messages using the IA_TA option and allowing clients to unicast some messages
directly to the server if the server sent the Server Unicast option directly to the server if the server sent the Server Unicast option
to a client in an early exchange. It also clarifies the UDP ports used to a client in an early exchange. It also clarifies the UDP ports used
by clients, servers, and relay agents (<xref target="udp-ports" format=" default"/>). by clients, servers, and relay agents (<xref target="udp-ports" format=" default"/>).
See <xref target="ChangeSummary" format="default"/> for a list of differ ences See <xref target="ChangeSummary" format="default"/> for a list of differ ences
from <xref target="RFC8415" format="default"/>.</t> from <xref target="RFC8415" format="default"/>.</t>
</section> </section>
<section anchor="out-of-scope" numbered="true" toc="default"> <section anchor="out-of-scope" numbered="true" toc="default">
<name>Topics Out of Scope</name> <name>Topics Out of Scope</name>
<t>This document specifies the DHCPv6 protocol behavior. The server poli cy, such as <t>This document specifies DHCPv6 behavior. The server policy, such as
what options to assign to which clients, which subnets or pools of resou rces to use, what options to assign to which clients, which subnets or pools of resou rces to use,
which clients' requests should be denied etc. are out of scope for this which clients' requests should be denied, etc. are out of scope for this
document.</t> document.</t>
<t>Server configuration, operation and management are also out of scope. <t>Server configuration, operation, and management are also out of scope
An . An
approach to manage DHCPv6 relays and servers is specified in <xref targe t="RFC9243" format="default"/>.</t> approach to manage DHCPv6 relays and servers is specified in <xref targe t="RFC9243" format="default"/>.</t>
<t>Merging DHCPv4 <xref target="RFC2131" format="default"/> and DHCPv6 c onfiguration is out of scope for <t>Merging DHCPv4 <xref target="RFC2131" format="default"/> and DHCPv6 c onfiguration is out of scope for
this document. <xref target="RFC4477" format="default"/> discusses some issues this document. <xref target="RFC4477" format="default"/> discusses some issues
and possible strategies for running DHCPv4 and DHCPv6 services and possible strategies for running DHCPv4 and DHCPv6 services
together. While <xref target="RFC4477" format="default"/> is a bit dated , it provides together. While <xref target="RFC4477" format="default"/> is a bit dated , it provides
a good overview of the issues at hand. a good overview of the issues at hand.
The current consensus of the IETF is that DHCPv4 should be used rather The consensus of the IETF at the time of writing is that DHCPv4 should b e used rather
than DHCPv6 when conveying IPv4 configuration information to nodes. than DHCPv6 when conveying IPv4 configuration information to nodes.
For IPv6-only networks, <xref target="RFC7341" format="default"/> descri bes a For IPv6-only networks, <xref target="RFC7341" format="default"/> descri bes a
transport mechanism to carry DHCPv4 messages using the DHCPv6 protocol transport mechanism to carry DHCPv4 messages using DHCPv6
for the dynamic provisioning of IPv4 address and configuration for the dynamic provisioning of IPv4 address and configuration
information.</t> information.</t>
</section> </section>
</section> </section>
<section anchor="requirements" numbered="true" toc="default"> <section anchor="requirements" numbered="true" toc="default">
<name>Requirements</name> <name>Requirements</name>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", <t>
"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
"NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
are to be interpreted as described in BCP 14 NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
<xref target="RFC2119" format="default"/> <xref target="RFC8174" format="d RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
efault"/> when, "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
and only when, they appear in all capitals, as shown here.</t> be interpreted as
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/>
when, and only when, they appear in all capitals, as shown here.
</t>
<t>This document also makes use of internal conceptual variables to <t>This document also makes use of internal conceptual variables to
describe protocol behavior and external variables that an implementation describe protocol behavior and external variables that an implementation
must allow system administrators to change. The specific variable names, must allow system administrators to change. The specific variable names,
how their values change, and how their settings influence protocol how their values change, and how their settings influence protocol
behavior are provided to demonstrate protocol behavior. An behavior are provided to demonstrate protocol behavior. An
implementation is not required to have them in the exact form described implementation is not required to have them in the exact form described
here, as long as its external behavior is consistent with that described here, as long as its external behavior is consistent with that described
in this document.</t> in this document.</t>
</section> </section>
<section anchor="old-background" numbered="true" toc="default"> <section anchor="old-background" numbered="true" toc="default">
<name>Background</name> <name>Background</name>
<t> <t>
This section, which contained background on IPv6 specifications of In <xref target="RFC8415"/>, the "Background" section contained backgrou
relevance to DHCPv6, has been removed; those interested should refer nd on IPv6 specifications of
to <xref target="RFC8415" />. relevance to DHCPv6. That text has been removed from the current docume
However, this section is retained to keep the major section numbering nt; however, this section has been retained to keep the major section numbering
consistent with <xref target="RFC8415" />. consistent with <xref target="RFC8415"/>. Those interested can refer to
<xref target="RFC8415"/> itself for more information on the topic.
</t> </t>
</section> </section>
<section anchor="terminology" numbered="true" toc="default"> <section anchor="terminology" numbered="true" toc="default">
<name>Terminology</name> <name>Terminology</name>
<t>This section defines terminology specific to IPv6 and DHCP used in <t>This section defines terminology specific to IPv6 and DHCP used in
this document.</t> this document.</t>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>IPv6 Terminology</name> <name>IPv6 Terminology</name>
<t>IPv6 terminology from <xref target="RFC8200" format="default"/>, <xre f target="RFC4291" format="default"/>, and <xref target="RFC4862" format="defau lt"/> relevant <t>IPv6 terminology from <xref target="RFC8200" format="default"/>, <xre f target="RFC4291" format="default"/>, and <xref target="RFC4862" format="defau lt"/> relevant
to this specification is included below.</t> to this specification is included below.</t>
<dl newline="false" spacing="normal" indent="26"> <dl newline="true" spacing="normal">
<dt>address</dt> <dt>address</dt>
<dd>An IP-layer identifier for an interface or a <dd>An IP-layer identifier for an interface or a
set of interfaces.</dd> set of interfaces.</dd>
<dt>GUA</dt> <dt>GUA</dt>
<dd>Global unicast address (see <dd>Global unicast address (see
<xref target="RFC4291" format="default"/>).</dd> <xref target="RFC4291" format="default"/>).</dd>
<dt>host</dt> <dt>host</dt>
<dd>Any node that is not a router.</dd> <dd>Any node that is not a router.</dd>
<dt>IP</dt> <dt>IP</dt>
<dd>Internet Protocol Version 6 (IPv6). The terms <dd>Internet Protocol Version 6 (IPv6). The terms
"IPv4" and "IPv6" are used only in contexts where it is necessary "IPv4" and "IPv6" are used only in contexts where it is necessary
to avoid ambiguity.</dd> to avoid ambiguity.</dd>
<dt>interface</dt> <dt>interface</dt>
<dd>A node's attachment to a link.</dd> <dd>A node's attachment to a link.</dd>
<dt>link</dt> <dt>link</dt>
<dd>A communication facility or medium over which <dd>A communication facility or medium over which
nodes can communicate at the link layer, i.e., the layer nodes can communicate at the link layer, i.e., the layer
immediately below IP. Examples are Ethernet (simple or bridged); immediately below IP. Examples are Ethernet (simple or bridged);
Point-to-Point Protocol (PPP) and PPP over Ethernet (PPPoE) links; Point-to-Point Protocol (PPP) and PPP over Ethernet (PPPoE) links;
and Internet‑layer (or higher) "tunnels", and Internet-layer (or higher) "tunnels",
such as tunnels over IPv4 or IPv6 itself.</dd> such as tunnels over IPv4 or IPv6 itself.</dd>
<dt>link-layer identifier</dt> <dt>link-layer identifier</dt>
<dd>A link-layer identifier for an <dd>A link-layer identifier for an
interface -- for example, IEEE 802 addresses for Ethernet or interface -- for example, IEEE 802 addresses for Ethernet or
Token Ring network interfaces.</dd> Token Ring network interfaces.</dd>
<dt>link-local address</dt> <dt>link-local address</dt>
<dd>An IPv6 address having a <dd>An IPv6 address having a
link-only scope, indicated by having the prefix (fe80::/10), that link-only scope, indicated by having the prefix (fe80::/10), that
can be used to reach neighboring nodes attached to the same link. can be used to reach neighboring nodes attached to the same link.
Every IPv6 interface on which DHCPv6 can reasonably be useful Every IPv6 interface on which DHCPv6 can reasonably be useful
skipping to change at line 250 skipping to change at line 303
to a multicast address is delivered to all interfaces identified to a multicast address is delivered to all interfaces identified
by that address.</dd> by that address.</dd>
<dt>neighbor</dt> <dt>neighbor</dt>
<dd>A node attached to the same link.</dd> <dd>A node attached to the same link.</dd>
<dt>node</dt> <dt>node</dt>
<dd>A device that implements IP.</dd> <dd>A device that implements IP.</dd>
<dt>packet</dt> <dt>packet</dt>
<dd>An IP header plus payload.</dd> <dd>An IP header plus payload.</dd>
<dt>prefix</dt> <dt>prefix</dt>
<dd>The initial bits of an address, or a set <dd>The initial bits of an address, or a set
of IP addresses that share the same initial bits.</dd> of IP addresses that share the same initial bits.</dd>
<dt>prefix length</dt> <dt>prefix length</dt>
<dd>The number of bits in a prefix.</dd> <dd>The number of bits in a prefix.</dd>
<dt>router</dt> <dt>router</dt>
<dd>A node that forwards IP packets not <dd>A node that forwards IP packets not
explicitly addressed to itself.</dd> explicitly addressed to itself.</dd>
<dt>ULA</dt> <dt>ULA</dt>
<dd>Unique local address (see <dd>Unique local address (see
<xref target="RFC4193" format="default"/>).</dd> <xref target="RFC4193" format="default"/>).</dd>
<dt>unicast address</dt> <dt>unicast address</dt>
<dd>An identifier for a single <dd>An identifier for a single
interface. A packet sent to a unicast address is delivered to the interface. A packet sent to a unicast address is delivered to the
interface identified by that address.</dd> interface identified by that address.</dd>
</dl> </dl>
</section> </section>
<section anchor="dhcp-terminology" numbered="true" toc="default"> <section anchor="dhcp-terminology" numbered="true" toc="default">
<name>DHCP Terminology</name> <name>DHCP Terminology</name>
<t>Terminology specific to DHCP can be found below.</t> <t>Terminology specific to DHCP can be found below.</t>
<dl newline="false" spacing="normal" indent="26"> <dl newline="true" spacing="normal">
<dt>appropriate to the link</dt> <dt>appropriate to the link</dt>
<dd>An address is "appropriate <dd>An address is "appropriate
to the link" when the address is consistent with the DHCP server's to the link" when the address is consistent with the DHCP server's
knowledge of the network topology, prefix assignment, and address knowledge of the network topology, prefix assignment, and address
assignment policies.</dd> assignment policies.</dd>
<dt>binding</dt> <dt>binding</dt>
<dd>A binding (or client binding) is a group of <dd>A binding (or client binding) is a group of
server data records containing the information the server has about server data records containing the information the server has about
the addresses or delegated prefixes in an Identity Association the addresses or delegated prefixes in an Identity Association
(IA) or configuration information explicitly assigned to the (IA) or configuration information explicitly assigned to the
client. Configuration information that has been returned to a client. Configuration information that has been returned to a
client through a policy, such as the information returned to all client through a policy, such as the information returned to all
clients on the same link, does not require a binding. A binding clients on the same link, does not require a binding. A binding
containing information about an IA is indexed by the tuple containing information about an IA is indexed by the tuple
&lt;DUID, IA‑type, IAID&gt; (where IA-type is the type of &lt;DUID, IA-type, IAID&gt; (where IA-type is the type of
lease in the IA -- for example, address or delegated prefix). A lease in the IA -- for example, address or delegated prefix). A
binding containing binding containing
configuration information for a client is indexed by configuration information for a client is indexed by
&lt;DUID&gt;. See below for definitions of DUID, IA, and IAID.</dd> &lt;DUID&gt;. See below for definitions of DUID, IA, and IAID.</dd>
<dt>configuration parameter</dt> <dt>configuration parameter</dt>
<dd>An element of the <dd>An element of the
configuration information set on the server and delivered to the configuration information set on the server and delivered to the
client using DHCP. Such parameters may be used to carry client using DHCP. Such parameters may be used to carry
information to be used by a node to configure its network information to be used by a node to configure its network
subsystem and enable communication on a link or internetwork, for subsystem and enable communication on a link or internetwork, for
skipping to change at line 327 skipping to change at line 380
relay agent.</dd> relay agent.</dd>
<dt>DHCP server</dt> <dt>DHCP server</dt>
<dd>This document condenses this term to "server". <dd>This document condenses this term to "server".
A node that responds to requests from clients. It may A node that responds to requests from clients. It may
or may not be on the same link as the client(s).</dd> or may not be on the same link as the client(s).</dd>
<dt>DUID</dt> <dt>DUID</dt>
<dd>A DHCP Unique Identifier for a DHCP <dd>A DHCP Unique Identifier for a DHCP
participant. Each DHCP client and server has exactly one DUID. See participant. Each DHCP client and server has exactly one DUID. See
<xref target="RFC3315-9" format="default"/> for details of the ways in which <xref target="RFC3315-9" format="default"/> for details of the ways in which
a DUID may be constructed.</dd> a DUID may be constructed.</dd>
<!-- [rfced] The following citation may require clarification:
Current:
A DHCP option that is usually only contained in another option. For
example, the IA Address option is contained in IA_NA options (see
Section 21.5). See Section 9 of [RFC7227] for a more complete
definition.
Section 21.5 is about the "IA_TA" option, rather than the "IA_NA"
option. Note: Section 21.6 is about the "IA Address Option".
-->
<dt>encapsulated option</dt> <dt>encapsulated option</dt>
<dd>A DHCP option that is usually <dd>A DHCP option that is usually
only contained in another option. For example, the IA Address only contained in another option. For example, the IA Address
option is contained in IA_NA options (see option is contained in IA_NA options (see
<xref target="RFC3315-22.5" format="default"/>). See Section 9 of <xref target="RFC3315-22.5" format="default"/>). See
<xref target="RFC7227" format="default"/> for a more complete defini <xref target="RFC7227" sectionFormat="of" section="9"/> for a more c
tion.</dd> omplete definition.</dd>
<dt>IA</dt> <dt>IA</dt>
<dd>Identity Association: a collection of leases <dd>Identity Association: a collection of leases
assigned to a client. Each IA has an associated IAID (see below). assigned to a client. Each IA has an associated IAID (see below).
A client may have more than one IA assigned to it -- for example, A client may have more than one IA assigned to it -- for example,
one for each of its interfaces. Each IA holds one type of one for each of its interfaces. Each IA holds one type of
lease; for example, an identity association for non-temporary lease; for example, an identity association for non-temporary
addresses (IA_NA) holds addresses, and an identity addresses (IA_NA) holds addresses, and an identity
association for prefix delegation (IA_PD) holds delegated association for prefix delegation (IA_PD) holds delegated
prefixes. Throughout this document, "IA" is used to refer to prefixes. Throughout this document, "IA" is used to refer to
an identity association without identifying the type an identity association without identifying the type
skipping to change at line 357 skipping to change at line 421
<dt>IA option(s)</dt> <dt>IA option(s)</dt>
<dd>In this document, one or more IA_NA, IA_TA (obsoleted), and/or IA_ PD. <dd>In this document, one or more IA_NA, IA_TA (obsoleted), and/or IA_ PD.
Another IA type (IA_LL) was defined in <xref target="RFC8947" format ="default"/> Another IA type (IA_LL) was defined in <xref target="RFC8947" format ="default"/>
and more may be defined.</dd> and more may be defined.</dd>
<dt>IAID</dt> <dt>IAID</dt>
<dd>Identity Association Identifier: an identifier <dd>Identity Association Identifier: an identifier
for an IA, chosen by the client. Each IA has an IAID, which is for an IA, chosen by the client. Each IA has an IAID, which is
chosen to be unique among IAIDs for IAs of a specific type that chosen to be unique among IAIDs for IAs of a specific type that
belong to that client.</dd> belong to that client.</dd>
<dt>IA_NA</dt> <dt>IA_NA</dt>
<dd>Identity Association for Non‑temporary <dd>Identity Association for Non-temporary
Addresses: an IA that carries assigned addresses. See <xref target=" RFC3315-22.4" format="default"/> for details on the IA_NA option.</dd> Addresses: an IA that carries assigned addresses. See <xref target=" RFC3315-22.4" format="default"/> for details on the IA_NA option.</dd>
<dt>IA_PD</dt> <dt>IA_PD</dt>
<dd>Identity Association for Prefix Delegation: an <dd>Identity Association for Prefix Delegation: an
IA that carries delegated prefixes. IA that carries delegated prefixes.
See <xref target="IA_PD-option" format="default"/> for details on th e See <xref target="IA_PD-option" format="default"/> for details on th e
IA_PD option.</dd> IA_PD option.</dd>
<dt>IA_TA</dt> <dt>IA_TA</dt>
<dd>Identity Association for Temporary Addresses: <dd>Identity Association for Temporary Addresses:
an IA that carries temporary addresses (see <xref target="RFC8981" f ormat="default"/>). This an IA that carries temporary addresses (see <xref target="RFC8981" f ormat="default"/>). This
option is obsoleted by this document. See <xref target="RFC8415" for mat="default"/> option is obsoleted by this document. See <xref target="RFC8415" for mat="default"/>
skipping to change at line 419 skipping to change at line 483
timer expires is referred to as the T1 time.</dd> timer expires is referred to as the T1 time.</dd>
<dt>T2</dt> <dt>T2</dt>
<dd>The time interval after which the client is <dd>The time interval after which the client is
expected to contact any available server to extend (rebind) the expected to contact any available server to extend (rebind) the
lifetimes of the addresses assigned (via IA_NA option(s)) and/or pre fixes lifetimes of the addresses assigned (via IA_NA option(s)) and/or pre fixes
delegated (via IA_PD option(s)) to the client. T2 is expressed as an absolute value delegated (via IA_PD option(s)) to the client. T2 is expressed as an absolute value
in messages (in seconds), is conveyed within IA containers in messages (in seconds), is conveyed within IA containers
(currently the IA_NA and IA_PD options), and is interpreted as a tim e interval (currently the IA_NA and IA_PD options), and is interpreted as a tim e interval
since the message's reception. The value stored in the T2 field in I A options since the message's reception. The value stored in the T2 field in I A options
is referred to as the T2 value. The actual time when the timer expir es is referred to as the T2 value. The actual time when the timer expir es
is referred to as the T2 time.</dd> is referred to as the T2 time.</dd>
<dt>top-level option</dt> <dt>top-level option</dt>
<dd>An option conveyed in a DHCP <dd>An option conveyed in a DHCP
message directly, i.e., not encapsulated in any other option, as message directly, i.e., not encapsulated in any other option, as
described in Section 9 of <xref target="RFC7227" format="default"/>. </dd> described in <xref target="RFC7227" sectionFormat="of" section="9"/> .</dd>
<dt>transaction ID</dt> <dt>transaction ID</dt>
<dd>An opaque value used to match <dd>An opaque value used to match
responses with replies initiated by either a client or a responses with replies initiated by either a client or a
server.</dd> server.</dd>
</dl> </dl>
</section> </section>
</section> </section>
<section anchor="Client-Server-Exchanges" numbered="true" toc="default"> <section anchor="Client-Server-Exchanges" numbered="true" toc="default">
<name>Client/Server Exchanges</name> <name>Client/Server Exchanges</name>
<t>Clients and servers exchange DHCP messages using UDP <t>Clients and servers exchange DHCP messages using UDP
skipping to change at line 464 skipping to change at line 528
reply exchange with a DHCP server. To obtain other configuration reply exchange with a DHCP server. To obtain other configuration
information, the client first sends an Information-request message to information, the client first sends an Information-request message to
the All_DHCP_Relay_Agents_and_Servers multicast address. Servers the All_DHCP_Relay_Agents_and_Servers multicast address. Servers
respond with a Reply message containing the other configuration respond with a Reply message containing the other configuration
information for the client.</t> information for the client.</t>
<t>A client may also request the server to expedite address assignment <t>A client may also request the server to expedite address assignment
and/or prefix delegation by using a two-message and/or prefix delegation by using a two-message
exchange instead of the normal four-message exchange as discussed exchange instead of the normal four-message exchange as discussed
in the next section. Expedited assignment can be requested by the in the next section. Expedited assignment can be requested by the
client, and servers may or may not honor the request (see client, and servers may or may not honor the request (see
Sections <xref target="RFC3315-17.2.1" format="counter"/> Sections <xref target="RFC3315-17.2.1" format="counter"/>
and <xref target="RFC3315-22.14" format="counter"/> and <xref target="RFC3315-22.14" format="counter"/>
for more details and why servers may not honor this request). for more details and why servers may not honor this request).
Clients may request this expedited service in environments where it Clients may request this expedited service in environments where it
is likely that there is only one server available on a link and no is likely that there is only one server available on a link and no
expectation that a second server would become available, or when expectation that a second server would become available, or when
completing the configuration process as quickly as possible is a completing the configuration process as quickly as possible is a
priority.</t> priority.</t>
<t>To request the expedited two-message exchange, the client <t>To request the expedited two-message exchange, the client
sends a Solicit message to the All_DHCP_Relay_Agents_and_Servers multica st address sends a Solicit message to the All_DHCP_Relay_Agents_and_Servers multica st address
requesting the assignment of addresses and/or delegated prefixes and oth er configuration requesting the assignment of addresses and/or delegated prefixes and oth er configuration
skipping to change at line 549 skipping to change at line 613
protocol extension.</t> protocol extension.</t>
<section anchor="OpModes-Stateless" numbered="true" toc="default"> <section anchor="OpModes-Stateless" numbered="true" toc="default">
<name>Stateless DHCP</name> <name>Stateless DHCP</name>
<t>Stateless DHCP can be <t>Stateless DHCP can be
used at any time, typically when a node requires used at any time, typically when a node requires
some missing or expired configuration information that is available some missing or expired configuration information that is available
via DHCP. via DHCP.
</t> </t>
<t>This is the simplest and most basic operation for DHCP and requires <t>This is the simplest and most basic operation for DHCP and requires
a client (and a server) to support only two messages -- a client (and a server) to support only two messages --
Information‑request and Reply. Note that DHCP servers and Information-request and Reply. Note that DHCP servers and
relay agents typically also need to support the Relay-forward and relay agents typically also need to support the Relay-forward and
Relay‑reply messages to accommodate operation when clients and Relay-reply messages to accommodate operation when clients and
servers are not on the same link.</t> servers are not on the same link.</t>
</section> </section>
<section anchor="OpModes-NA" numbered="true" toc="default"> <section anchor="OpModes-NA" numbered="true" toc="default">
<name>DHCP for Non-temporary Address Assignment</name> <name>DHCP for Non-Temporary Address Assignment</name>
<t>This model of operation was the original motivation for DHCP. <t>This model of operation was the original motivation for DHCP.
It is appropriate for situations where It is appropriate for situations where
stateless address autoconfiguration alone is insufficient or stateless address autoconfiguration alone is insufficient or
impractical, e.g., because of network policy, additional requirements impractical, e.g., because of network policy, additional requirements
such as dynamic updates to the DNS, or client-specific requirements.</t> such as dynamic updates to the DNS, or client-specific requirements.</t>
<t>The model of operation for non-temporary address assignment is as <t>The model of operation for non-temporary address assignment is as
follows: follows:
</t> </t>
<ul spacing="normal"> <ul spacing="normal">
<li>The server is provided with prefixes from which it may <li>The server is provided with prefixes from which it may
assign addresses to clients, as well as any related network topology assign addresses to clients, as well as any related network topology
information as to which prefixes are present on which links. information as to which prefixes are present on which links.
</li> </li>
<li>A client requests a non-temporary address to be assigned by the serv er. The <li>A client requests a non-temporary address to be assigned by the serv er. The
server allocates an address or addresses appropriate for the link on server allocates an address or addresses appropriate for the link on
which the client is connected. which the client is connected.
</li> </li>
<li>The server returns the allocated address or addresses to the client. <li>The server returns the allocated address or addresses to the client.
</li> </li>
</ul> </ul>
<t>Each address has associated preferred and valid lifetimes (see <xref target="RFC3315-10.1" format="default" />), which <t>Each address has associated preferred and valid lifetimes (see <xref target="RFC3315-10.1" format="default"/>), which
constitute an agreement about the length of time over which the constitute an agreement about the length of time over which the
client is allowed to use the address. A client can request an client is allowed to use the address. A client can request an
extension of the lifetimes on an address and is required to terminate extension of the lifetimes on an address and is required to terminate
the use of an address if the valid lifetime of the address the use of an address if the valid lifetime of the address
expires.</t> expires.</t>
<t>Typically, clients request other configuration parameters, such as <t>Typically, clients request other configuration parameters, such as
the DNS name server addresses and domain search lists, when requesting the DNS name server addresses and domain search lists, when requesting
addresses.</t> addresses.</t>
<t>Clients can also request more than one address or set of addresses <t>Clients can also request more than one address or set of addresses
(see Sections <xref target="multiple-addrs" format="counter"/> (see Sections <xref target="multiple-addrs" format="counter"/>
and <xref target="RFC3315-10" format="counter"/>).</t> and <xref target="RFC3315-10" format="counter"/>).</t>
</section> </section>
<section anchor="OpModes-PD" numbered="true" toc="default"> <section anchor="OpModes-PD" numbered="true" toc="default">
<name>DHCP for Prefix Delegation</name> <name>DHCP for Prefix Delegation</name>
<t>The prefix delegation mechanism is another stateful mode of operation and <t>The prefix delegation mechanism is another stateful mode of operation and
was originally intended for simple delegation of prefixes from a was originally intended for simple delegation of prefixes from a
DHCP server to DHCP clients (typically routers). DHCP server to DHCP clients (typically routers).
It is appropriate for situations in which the client It is appropriate for situations in which the client
(1) does not have knowledge about the topology of the (1) does not have knowledge about the topology of the
networks to which it is attached and networks to which it is attached and
(2) does not require other information to choose a prefix for delegation . (2) does not require other information to choose a prefix for delegation .
This mechanism is appropriate for use by an ISP to This mechanism is appropriate for use by an ISP to
delegate a prefix to a subscriber, where the delegated prefix would delegate a prefix to a subscriber, where the delegated prefix would
possibly be subnetted and assigned to the links within the possibly be subnetted and assigned to the links within the
subscriber's network. <xref target="RFC7084" format="default"/> and subscriber's network. <xref target="RFC7084" format="default"/> and
<xref target="RFC7368" format="default"/> describe such use in detail.</ t> <xref target="RFC7368" format="default"/> describe such use in detail.</ t>
<t>The design of this prefix delegation mechanism meets the requirements <t>The design of this prefix delegation mechanism meets the requirements
for prefix delegation in <xref target="RFC3769" format="default"/>.</t> for prefix delegation in <xref target="RFC3769" format="default"/>.</t>
<t>DHCP prefix delegation itself does not require that the client forwar d <t>DHCP prefix delegation itself does not require that the client forwar d
IP packets not addressed to itself and thus does not require IP packets not addressed to itself and thus does not require
that the client (or server) be a router as defined in that the client (or server) be a router as defined in
skipping to change at line 633 skipping to change at line 697
prefix(es) for delegation and responds with prefix(es) to the prefix(es) for delegation and responds with prefix(es) to the
client. client.
</li> </li>
<li>The client is then responsible for the <li>The client is then responsible for the
delegated prefix(es). For example, the client might assign delegated prefix(es). For example, the client might assign
a subnet from a delegated prefix to one of its interfaces and begin a subnet from a delegated prefix to one of its interfaces and begin
sending Router Advertisements for the prefix on that link. sending Router Advertisements for the prefix on that link.
</li> </li>
</ul> </ul>
<t>Each prefix has an associated preferred lifetime and <t>Each prefix has an associated preferred lifetime and
valid lifetime (see <xref target="RFC3315-10.2" format="default" />), wh ich constitute an agreement about the length of time valid lifetime (see <xref target="RFC3315-10.2" format="default"/>), whi ch constitute an agreement about the length of time
over which the client is allowed to use the prefix. A client over which the client is allowed to use the prefix. A client
can request an extension of the lifetimes on a delegated prefix and is can request an extension of the lifetimes on a delegated prefix and is
required to terminate the use of a delegated prefix if the valid required to terminate the use of a delegated prefix if the valid
lifetime of the prefix expires.</t> lifetime of the prefix expires.</t>
<t><xref target="FigISPNetwork" format="default"/> illustrates a network <t><xref target="FigISPNetwork" format="default"/> illustrates a network
architecture in which prefix delegation could be used.</t> architecture in which prefix delegation could be used.</t>
<figure anchor="FigISPNetwork"> <figure anchor="FigISPNetwork">
<name>Prefix Delegation Network</name> <name>Prefix Delegation Network</name>
<artwork alt="Network architecture" type="ascii-art"> <artwork alt="Network architecture"><![CDATA[
<![CDATA[ ______________________ \
______________________ \ / \ \
/ \ \ | ISP core network | \
| ISP core network | \ \__________ ___________/ |
\__________ ___________/ | | |
| | +-------+-------+ |
+-------+-------+ | | Aggregation | | ISP
| Aggregation | | ISP | device | | network
| device | | network +-------+-------+ |
+-------+-------+ | | /
| / |Network link to /
|Network link to / |subscriber premises /
|subscriber premises / |
| +------+--------+ \
+-------+-------+ \ | CPE | \
| CPE | \ | (DHCP client) | \
| (DHCP client) | \ +----+---+------+ |
+----+---+------+ | | | | Subscriber
| | | Subscriber ---+-------------+-----+ +-----+------ | network
---+-------------+-----+ +-----+------ | network | | | |
| | | | +----+-----+ +-----+----+ +----+-----+ |
+----+-----+ +-----+----+ +----+-----+ | |Subscriber| |Subscriber| |Subscriber| /
|Subscriber| |Subscriber| |Subscriber| / | PC | | PC | | PC | /
| PC | | PC | | PC | / +----------+ +----------+ +----------+ /]]></artwork>
+----------+ +----------+ +----------+ /]]></artwork>
</figure> </figure>
----------+ +----------+ +----------+ /]]&gt;&lt;/artwork&gt;
<t>In this example, the server (in the ISP core network or integrated <t>In this example, the server (in the ISP core network or integrated
in the aggregation device) is configured with a set of in the aggregation device) is configured with a set of
prefixes to be used for assignment to customers at the time of each prefixes to be used for assignment to customers at the time of each
customer's first connection to the ISP service. The prefix delegation customer's first connection to the ISP service. The prefix delegation
process begins when the client (CPE) requests configuration process begins when the client (CPE) requests configuration
information through DHCP. The DHCP messages from the client information through DHCP. The DHCP messages from the client
are received by the server via the aggregation device. When are received by the server via the aggregation device. When
the server receives the request, it selects an available the server receives the request, it selects an available
prefix or prefixes for delegation to the client. The prefix or prefixes for delegation to the client. The
server then returns the prefix or prefixes to the server then returns the prefix or prefixes to the
skipping to change at line 695 skipping to change at line 759
<t>The prefix delegation options can be used in conjunction with other <t>The prefix delegation options can be used in conjunction with other
DHCP options carrying other configuration information to the DHCP options carrying other configuration information to the
client. The client may, in turn, provide DHCP client. The client may, in turn, provide DHCP
service to nodes attached to the internal network. For example, the service to nodes attached to the internal network. For example, the
client may obtain the addresses of DNS and NTP servers from client may obtain the addresses of DNS and NTP servers from
the ISP server and then pass that configuration the ISP server and then pass that configuration
information on to the subscriber hosts through a DHCP server in the information on to the subscriber hosts through a DHCP server in the
client.</t> client.</t>
<t>If the client uses a delegated prefix to configure addresses on <t>If the client uses a delegated prefix to configure addresses on
interfaces on itself or other nodes behind it, the preferred and interfaces on itself or other nodes behind it, the preferred and
valid lifetimes of those addresses MUST be no longer than the valid lifetimes of those addresses <bcp14>MUST</bcp14> be no longer than the
remaining preferred and valid lifetimes, respectively, for the remaining preferred and valid lifetimes, respectively, for the
delegated prefix at any time. In particular, if the delegated delegated prefix at any time. In particular, if the delegated
prefix or a prefix derived from it is advertised for stateless prefix or a prefix derived from it is advertised for stateless
address autoconfiguration <xref target="RFC4862" format="default"/>, the advertised address autoconfiguration <xref target="RFC4862" format="default"/>, the advertised
preferred and valid lifetimes MUST NOT exceed the corresponding preferred and valid lifetimes <bcp14>MUST NOT</bcp14> exceed the correspo nding
remaining lifetimes of the delegated prefix.</t> remaining lifetimes of the delegated prefix.</t>
<t> <t>
A client that has delegated any of the address space received through A client that has delegated any of the address space received through
DHCP Prefix Delegation MUST NOT issue a DHCP Release on the relevant DHCP Prefix Delegation <bcp14>MUST NOT</bcp14> issue a DHCP Release on the relevant
delegated prefix while any of the address space is outstanding. delegated prefix while any of the address space is outstanding.
That includes addresses leased out by DHCPv6 (IA_NA), prefixes delegate d That includes addresses leased out by DHCPv6 (IA_NA), prefixes delegate d
via DHCPv6-PD (IA_PD), and addresses autoconfigured by IPv6 Router via DHCPv6-PD (IA_PD), and addresses autoconfigured by IPv6 Router
Advertisements. Advertisements.
Requirement WPD-9 in <xref target="RFC9096" format="default" /> makes t Requirement WPD-9 in <xref target="RFC9096" format="default"/> makes th
his is
the Best Current Practice. the best current practice.
</t> </t>
<t> <t>
<xref target="RFC9096" format="default" /> section 3.3 further <xref target="RFC9096" section="3.3" sectionFormat="comma"/>
provides more guidance on coordination of lifetimes between WAN provides further guidance on coordination of lifetimes between WAN
(DHCPv6-PD client) and LAN (DHCPv6-PD server) sides. (DHCPv6-PD client) and LAN (DHCPv6-PD server) sides.
</t> </t>
<t>Several problems related to Prefix Delegation and Relay Agents and a s et of <t>Several problems related to Prefix Delegation and Relay Agents and a s et of
requirements to address them are defined in <xref target="RFC8987" format ="default"/>.</t> requirements to address them are defined in <xref target="RFC8987" format ="default"/>.</t>
</section> </section>
<section anchor="OpModes-CPE" numbered="true" toc="default"> <section anchor="OpModes-CPE" numbered="true" toc="default">
<name>DHCP for Customer Edge Routers</name> <name>DHCP for Customer Edge Routers</name>
<t>The DHCP requirements and network architecture for Customer Edge <t>The DHCP requirements and network architecture for Customer Edge
Routers are described in <xref target="RFC7084" format="default"/>, Routers are described in <xref target="RFC7084" format="default"/>,
with improvements for renumbering described in with improvements for renumbering described in
skipping to change at line 743 skipping to change at line 807
<t>DHCP allows a client to receive multiple addresses. <t>DHCP allows a client to receive multiple addresses.
During typical operation, a client sends one instance During typical operation, a client sends one instance
of an IA_NA option and the server assigns at most one address from of an IA_NA option and the server assigns at most one address from
each prefix assigned to the link to which the client is attached. each prefix assigned to the link to which the client is attached.
In In
particular, the server can be configured to serve addresses out particular, the server can be configured to serve addresses out
of multiple prefixes for a given link. This is useful in cases of multiple prefixes for a given link. This is useful in cases
such as when a network renumbering event is in progress. In a typical such as when a network renumbering event is in progress. In a typical
deployment, the server will grant one address for each IA_NA deployment, the server will grant one address for each IA_NA
option (see <xref target="RFC3315-22.4" format="default"/>).</t> option (see <xref target="RFC3315-22.4" format="default"/>).</t>
<t>To meet the recommendations of <xref target="RFC7934" format="default " />, <t>To meet the recommendations of <xref target="RFC7934" format="default "/>,
a client can explicitly request multiple addresses by sending a client can explicitly request multiple addresses by sending
multiple IA_NA options. A client can send multiple multiple IA_NA options. A client can send multiple
IA_NA options in its initial transmissions. IA_NA options in its initial transmissions.
Alternatively, it can send an extra Request message Alternatively, it can send an extra Request message
with additional new IA_NA options (or include them with additional new IA_NA options (or include them
in a Renew message).</t> in a Renew message).</t>
<t>The same principle also applies to prefix delegation. In <t>The same principle also applies to prefix delegation. In
principle, DHCP allows a client to request new prefixes principle, DHCP allows a client to request new prefixes
to be delegated by sending additional IA_PD options to be delegated by sending additional IA_PD options
(see <xref target="IA_PD-option" format="default"/>). However, a (see <xref target="IA_PD-option" format="default"/>). However, a
skipping to change at line 765 skipping to change at line 829
prefix. In most deployments, it is recommended that the client prefix. In most deployments, it is recommended that the client
request a larger prefix in its initial transmissions rather than request a larger prefix in its initial transmissions rather than
request additional prefixes later on.</t> request additional prefixes later on.</t>
<t>The exact behavior of the server (whether to grant additional <t>The exact behavior of the server (whether to grant additional
addresses and prefixes or not) is up to the server policy and is addresses and prefixes or not) is up to the server policy and is
out of scope for this document.</t> out of scope for this document.</t>
<t>For more information on how the server distinguishes between <t>For more information on how the server distinguishes between
IA option instances, see <xref target="RFC3315-10" format="default"/>.</ t> IA option instances, see <xref target="RFC3315-10" format="default"/>.</ t>
</section> </section>
<section anchor="use-case-addr-registration" numbered="true" toc="default" > <section anchor="use-case-addr-registration" numbered="true" toc="default" >
<name>Registering Self-generated Addresses</name> <name>Registering Self-Generated Addresses</name>
<t><xref target="RFC9686" format="default"/> introduces a method for <t><xref target="RFC9686" format="default"/> introduces a method for
devices to register their self-generated or statically configured addres ses devices to register their self-generated or statically configured addres ses
in the DHCPv6 servers. The general idea is that devices would notify the in the DHCPv6 servers. The general idea is that devices would notify the
server about addresses that they are using, so that the server can log server about addresses that they are using, so that the server can log
or record these addresses as required by local policy.</t> or record these addresses as required by local policy.</t>
<t>The major specificity of this mechanism is that the address <t>The major specificity of this mechanism is that the address
selection is not done by the DHCP server, but by the device itself. The most selection is not done by the DHCP server, but by the device itself. The majority
of the lifecycle remains the same in principle: a lease is created by th e server, of the lifecycle remains the same in principle: a lease is created by th e server,
and the device performs periodic actions to get the lease renewed, and e ventually the device performs periodic actions to get the lease renewed, and, even tually,
the lease can expire. However, this mechanism uses different message typ es the lease can expire. However, this mechanism uses different message typ es
(ADDR-REG-INFORM and ADDR-REG-REPLY) and has different source address re quirements, (ADDR-REG-INFORM and ADDR-REG-REPLY) and has different source address re quirements,
as defined in <xref target="RFC9686" format="default"/>.</t> as defined in <xref target="RFC9686" format="default"/>.</t>
</section> </section>
</section> </section>
<section anchor="dhcp-constants" numbered="true" toc="default"> <section anchor="dhcp-constants" numbered="true" toc="default">
<name>DHCP Constants</name> <name>DHCP Constants</name>
<t>This section describes various program and networking constants used <t>This section describes various program and networking constants used
by DHCP.</t> by DHCP.</t>
<section anchor="mutlicastAddr" numbered="true" toc="default"> <section anchor="mutlicastAddr" numbered="true" toc="default">
skipping to change at line 807 skipping to change at line 871
the relay agent wants to send messages to all servers or the relay agent wants to send messages to all servers or
because it does not know the unicast addresses of the servers. because it does not know the unicast addresses of the servers.
Note that in order for a relay agent to use this address, it must Note that in order for a relay agent to use this address, it must
have an address of sufficient scope to be reachable by the have an address of sufficient scope to be reachable by the
servers. All servers within the site are members of this multicast servers. All servers within the site are members of this multicast
group on the interfaces that are within the site.</dd> group on the interfaces that are within the site.</dd>
</dl> </dl>
</section> </section>
<section anchor="udp-ports" numbered="true" toc="default"> <section anchor="udp-ports" numbered="true" toc="default">
<name>UDP Ports</name> <name>UDP Ports</name>
<t>Clients MUST listen for DHCP messages on UDP port 546. <t>Clients <bcp14>MUST</bcp14> listen for DHCP messages on UDP port 546.
Servers and relay agents MUST listen for DHCP messages on Servers and relay agents <bcp14>MUST</bcp14> listen for DHCP messages on
UDP port 547.</t> UDP port 547.</t>
<t>Therefore, clients MUST send DHCP messages to UDP <t>Therefore, clients <bcp14>MUST</bcp14> send DHCP messages to UDP
destination port 547. Servers MUST send destination port 547. Servers <bcp14>MUST</bcp14> send
Relay-reply messages to UDP destination port 547 Relay-reply messages to UDP destination port 547
and client messages to UDP destination port 546. and client messages to UDP destination port 546.
Relay agents MUST send Relay-forward and Relay-reply Relay agents <bcp14>MUST</bcp14> send Relay-forward and Relay-reply
messages to UDP destination port 547 and client messages messages to UDP destination port 547 and client messages
to UDP destination port 546.</t> to UDP destination port 546.</t>
<t>It is RECOMMENDED for clients to send messages from UDP
<!--[rfced] It may be useful to further clarify the reach of this BCP 14
keyword (i.e., are both clauses RECOMMENDED?).
Original:
It is RECOMMENDED for clients to send messages from UDP source port
546, and servers and relay agents from UDP source port 547.
Perhaps:
It is RECOMMENDED for clients to send messages from UDP source port
546 and for servers and relay agents from UDP source port 547.
-->
<t>It is <bcp14>RECOMMENDED</bcp14> for clients to send messages from UD
P
source port 546, and servers and relay agents from UDP source port 546, and servers and relay agents from UDP
source port 547. However, clients, servers, and relay agents source port 547. However, clients, servers, and relay agents
MAY send DHCP messages from any UDP source port they <bcp14>MAY</bcp14> send DHCP messages from any UDP source port they
are allowed to use.</t> are allowed to use.</t>
<t>Please note that the Relay Source Port Option <t>Please note that the Relay Source Port Option
<xref target="RFC8357" format="default"/> <xref target="RFC8357" format="default"/>
changes some of these rules for servers and relays agents. changes some of these rules for servers and relays agents.
</t> </t>
</section> </section>
<section anchor="RFC3315-5.3" numbered="true" toc="default"> <section anchor="RFC3315-5.3" numbered="true" toc="default">
<name>DHCP Message Types</name> <name>DHCP Message Types</name>
<t>DHCP defines the following message types. The formats of these <t>DHCP defines the following message types. The formats of these
messages are provided in messages are provided in
Sections <xref target="RFC3315-6" format="counter"/> and Sections <xref target="RFC3315-6" format="counter"/> and
<xref target="RFC3315-7" format="counter"/>. <xref target="RFC3315-7" format="counter"/>.
Additional message types Additional message types
have been defined and may be defined in the future; see have been defined and may be defined in the future; see
<https://www.iana.org/assignments/dhcpv6-parameters&gt;. <eref brackets="angle" target="https://www.iana.org/assignments/dhcpv6-p arameters"/&gt;.
The numeric encoding for each message type is shown in parentheses.</t> The numeric encoding for each message type is shown in parentheses.</t>
<dl newline="false" spacing="normal" indent="26"> <dl newline="true" spacing="normal">
<dt>SOLICIT (1)</dt> <dt>SOLICIT (1)</dt>
<dd>A client sends a Solicit message to <dd>A client sends a Solicit message to
locate servers.</dd> locate servers.</dd>
<dt>ADVERTISE (2)</dt> <dt>ADVERTISE (2)</dt>
<dd>A server sends an Advertise message to <dd>A server sends an Advertise message to
indicate that it is available for DHCP service, in response to a indicate that it is available for DHCP service, in response to a
Solicit message received from a client.</dd> Solicit message received from a client.</dd>
<dt>REQUEST (3)</dt> <dt>REQUEST (3)</dt>
<dd>A client sends a Request message to <dd>A client sends a Request message to
request configuration parameters, including addresses and/or request configuration parameters, including addresses and/or
skipping to change at line 891 skipping to change at line 968
leases.</dd> leases.</dd>
<dt>DECLINE (9)</dt> <dt>DECLINE (9)</dt>
<dd>A client sends a Decline message to a <dd>A client sends a Decline message to a
server to indicate that the client has determined that one or more server to indicate that the client has determined that one or more
addresses assigned by the server are already in use on the link to addresses assigned by the server are already in use on the link to
which the client is connected.</dd> which the client is connected.</dd>
<dt>RECONFIGURE (10)</dt> <dt>RECONFIGURE (10)</dt>
<dd>A server sends a Reconfigure <dd>A server sends a Reconfigure
message to a client to inform the client that the server has new message to a client to inform the client that the server has new
or updated configuration parameters and that the client is to or updated configuration parameters and that the client is to
initiate a Renew⁠/Reply, Rebind/Reply, or initiate a Renew/Reply, Rebind/Reply, or
Information‑request/Reply transaction with the server in Information-request/Reply transaction with the server in
order to receive the updated information.</dd> order to receive the updated information.</dd>
<dt>INFORMATION-REQUEST (11)</dt> <dt>INFORMATION-REQUEST (11)</dt>
<dd>A client sends an <dd>A client sends an
Information-request message to a server to request configuration Information-request message to a server to request configuration
parameters without the assignment of any leases to the parameters without the assignment of any leases to the
client.</dd> client.</dd>
<dt>RELAY-FORW (12)</dt> <dt>RELAY-FORW (12)</dt>
<dd>A relay agent sends a Relay-forward <dd>A relay agent sends a Relay-forward
message to relay messages to servers, either directly or through message to relay messages to servers, either directly or through
another relay agent. The received message -- either a client another relay agent. The received message -- either a client
skipping to change at line 938 skipping to change at line 1015
operations requested in messages from clients and servers and to operations requested in messages from clients and servers and to
provide additional information about the specific cause of the failure provide additional information about the specific cause of the failure
of a message. The specific status codes are defined in <xref target="RFC 3315-22.13" format="default"/>.</t> of a message. The specific status codes are defined in <xref target="RFC 3315-22.13" format="default"/>.</t>
<t>If the Status Code option (see <xref target="RFC3315-22.13" format="d efault"/>) does <t>If the Status Code option (see <xref target="RFC3315-22.13" format="d efault"/>) does
not appear in a message in which the not appear in a message in which the
option could appear, the status of the message is assumed to be option could appear, the status of the message is assumed to be
Success.</t> Success.</t>
</section> </section>
<section anchor="RFC3315-5.5" numbered="true" toc="default"> <section anchor="RFC3315-5.5" numbered="true" toc="default">
<name>Transmission and Retransmission Parameters</name> <name>Transmission and Retransmission Parameters</name>
<t>The table of values (<xref target="Trans-Parameters-Table" />) is use d to describe the <t>The table of values (<xref target="Trans-Parameters-Table"/>) is used to describe the
message transmission behavior of clients and servers. Some of message transmission behavior of clients and servers. Some of
the values are adjusted by a randomization factor and backoffs the values are adjusted by a randomization factor and backoffs
(see <xref target="RFC3315-14" format="default"/>). Transmissions may al so (see <xref target="RFC3315-14" format="default"/>). Transmissions may al so
be influenced by rate limiting (see <xref target="rate-limit" format="de fault"/>).</t> be influenced by rate limiting (see <xref target="rate-limit" format="de fault"/>).</t>
<table anchor="Trans-Parameters-Table" align="center"> <table anchor="Trans-Parameters-Table" align="center">
<name>Transmission and Retransmission Parameters</name> <name>Transmission and Retransmission Parameters</name>
<thead> <thead>
<tr> <tr>
<th align="left">Parameter</th> <th align="left">Parameter</th>
<th align="left">Default</th> <th align="left">Default</th>
skipping to change at line 1122 skipping to change at line 1199
<t>All values in the message header and in options are in network byte <t>All values in the message header and in options are in network byte
order.</t> order.</t>
<t>Options are stored serially in the "options" field, with no padding <t>Options are stored serially in the "options" field, with no padding
between the options. Options are byte-aligned but are not aligned in any between the options. Options are byte-aligned but are not aligned in any
other way (such as on 2-byte or 4-byte boundaries).</t> other way (such as on 2-byte or 4-byte boundaries).</t>
<t>The following diagram illustrates the format of DHCP messages sent <t>The following diagram illustrates the format of DHCP messages sent
between clients and servers:</t> between clients and servers:</t>
<figure anchor="FigClientServerMsg"> <figure anchor="FigClientServerMsg">
<name>Client/Server Message Format</name> <name>Client/Server Message Format</name>
<artwork align="left" name="" type="" alt=""><![CDATA[ <artwork align="left" name="" type="" alt=""><![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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| msg-type | transaction-id | | msg-type | transaction-id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
. options . . options .
. (variable number and length) . . (variable number and length) .
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
]]></artwork>
</figure> </figure>
<dl newline="false" spacing="normal" indent="24"> <dl>
<dt> msg-type</dt> <dt>msg-type:</dt>
<dd>Identifies the DHCP message type; the <dd>Identifies the DHCP message type; the
available message types are listed in <xref target="RFC3315-5.3" forma available message types are listed in <xref target="RFC3315-5.3" forma
t="default"/>. A 1‑octet field.</dd> t="default"/>. A 1-octet field.</dd>
<dt> transaction-id</dt> <dt>transaction-id:</dt>
<dd>The transaction ID for this message <dd>The transaction ID for this message
exchange. A 3‑octet field.</dd> exchange. A 3-octet field.</dd>
<dt> options</dt> <dt>options:</dt>
<dd>Options carried in this message; options <dd>Options carried in this message; options
are described in <xref target="RFC3315-22" format="default"/>. A varia ble-length are described in <xref target="RFC3315-22" format="default"/>. A varia ble-length
field (4 octets less than the size of the message).</dd> field (4 octets less than the size of the message).</dd>
</dl> </dl>
</section> </section>
<section anchor="RFC3315-7" numbered="true" toc="default"> <section anchor="RFC3315-7" numbered="true" toc="default">
<name>Relay Agent/Server Message Formats</name> <name>Relay Agent/Server Message Formats</name>
<t>Relay agents exchange messages with other relay agents and servers <t>Relay agents exchange messages with other relay agents and servers
to relay messages between to relay messages between
clients and servers that are not connected to the same link.</t> clients and servers that are not connected to the same link.</t>
<t>All values in the message header and in options are in network byte <t>All values in the message header and in options are in network byte
order.</t> order.</t>
<t>Options are stored serially in the "options" field, with no padding <t>Options are stored serially in the "options" field, with no padding
between the options. Options are byte-aligned but are not aligned in any between the options. Options are byte-aligned but are not aligned in any
other way (such as on 2-byte or 4-byte boundaries).</t> other way (such as on 2-byte or 4-byte boundaries).</t>
<t>There are two relay agent messages (Relay-forward and Relay-reply), <t>There are two relay agent messages (Relay-forward and Relay-reply),
which share the following format:</t> which share the following format:</t>
<figure anchor="FigRelayServerMsg"> <figure anchor="FigRelayServerMsg">
<name>Relay Agent/Server Message Format</name> <name>Relay Agent/Server Message Format</name>
<artwork align="left" name="" type="" alt=""><![CDATA[ <artwork align="left" name="" type="" alt=""><![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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| msg-type | hop-count | | | msg-type | hop-count | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | | |
| link-address | | link-address |
| | | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | | |
| peer-address | | peer-address |
| | | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
. . . .
. options (variable number and length) .... . . options (variable number and length) .... .
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
]]></artwork>
</figure> </figure>
<t>The following sections describe the use of the relay agent message <t>The following sections describe the use of the relay agent message
header.</t> header.</t>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Relay-forward Message</name> <name>Relay-forward Message</name>
<t>The following table defines the use of message fields in a <t>The following list defines the use of message fields in a
Relay‑forward message.</t> Relay-forward message.</t>
<dl newline="false" spacing="normal" indent="24"> <dl>
<dt> msg-type</dt> <dt> msg-type:</dt>
<dd>RELAY-FORW (12). A 1‑octet field.</dd> <dd>RELAY-FORW (12). A 1-octet field.</dd>
<dt> hop-count</dt> <dt> hop-count:</dt>
<dd>Number of relay agents that <dd>Number of relay agents that
have already relayed this message. A 1‑octet field.</dd> have already relayed this message. A 1-octet field.</dd>
<dt> link-address</dt> <dt> link-address:</dt>
<dd>An address that may be used by the <dd>An address that may be used by the
server to identify the link on which the client is located. This server to identify the link on which the client is located. This
is typically a globally scoped unicast address is typically a globally scoped unicast address
(i.e., GUA or ULA), but see the discussion (i.e., GUA or ULA), but see the discussion
in <xref target="relaying-from-client" format="default"/>. A 16-octe t field.</dd> in <xref target="relaying-from-client" format="default"/>. A 16-octe t field.</dd>
<dt> peer-address</dt> <dt> peer-address:</dt>
<dd>The address of the client or relay <dd>The address of the client or relay
agent from which the message to be relayed was received. A agent from which the message to be relayed was received. A
16-octet field.</dd> 16-octet field.</dd>
<dt> options</dt> <dt> options:</dt>
<dd>MUST include a Relay Message option <dd><bcp14>MUST</bcp14> include a Relay Message option
(see <xref target="RFC3315-22.10" format="default"/>); MAY include o (see <xref target="RFC3315-22.10" format="default"/>); <bcp14>MAY</b
ther cp14> include other
options, such as the Interface-Id option (see options, such as the Interface-Id option (see
<xref target="RFC3315-22.18" format="default"/>), added by the relay agent. A <xref target="RFC3315-22.18" format="default"/>), added by the relay agent. A
variable-length field variable-length field
(34 octets less than the size of the message).</dd> (34 octets less than the size of the message).</dd>
</dl> </dl>
<t>See <xref target="addr-assign-ia-na" format="default"/> for an explan ation of <t>See <xref target="addr-assign-ia-na" format="default"/> for an explan ation of
how the link-address field is used.</t> how the link-address field is used.</t>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Relay-reply Message</name> <name>Relay-reply Message</name>
<t>The following table defines the use of message fields in a <t>The following list defines the use of message fields in a
Relay‑reply message.</t> Relay-reply message.</t>
<dl newline="false" spacing="normal" indent="24"> <dl>
<dt> msg-type</dt> <dt> msg-type:</dt>
<dd>RELAY-REPL (13). <dd>RELAY-REPL (13).
A 1‑octet field.</dd> A 1-octet field.</dd>
<dt> hop-count</dt> <dt> hop-count:</dt>
<dd>Copied from the Relay-forward <dd>Copied from the Relay-forward
message. A 1‑octet field.</dd> message. A 1-octet field.</dd>
<dt> link-address</dt> <dt> link-address:</dt>
<dd>Copied from the Relay-forward <dd>Copied from the Relay-forward
message. A 16‑octet field.</dd> message. A 16-octet field.</dd>
<dt> peer-address</dt> <dt> peer-address:</dt>
<dd>Copied from the Relay-forward <dd>Copied from the Relay-forward
message. A 16‑octet field.</dd> message. A 16-octet field.</dd>
<dt> options</dt> <dt> options:</dt>
<dd>MUST include a Relay Message option <dd><bcp14>MUST</bcp14> include a Relay Message option
(see <xref target="RFC3315-22.10" format="default"/>); MAY include o (see <xref target="RFC3315-22.10" format="default"/>); <bcp14>MAY</b
ther cp14> include other
options, such as the Interface-Id option (see options, such as the Interface-Id option (see
<xref target="RFC3315-22.18" format="default"/>). A variable-length field <xref target="RFC3315-22.18" format="default"/>). A variable-length field
(34 octets less than the size of the message).</dd> (34 octets less than the size of the message).</dd>
</dl> </dl>
</section> </section>
</section> </section>
<section anchor="RFC3315-8" numbered="true" toc="default"> <section anchor="RFC3315-8" numbered="true" toc="default">
<name>Representation and Use of Domain Names</name> <name>Representation and Use of Domain Names</name>
<t>So that domain names may be encoded uniformly, a domain name or a <t>So that domain names may be encoded uniformly, a domain name or a
list of domain names is encoded using the technique described in list of domain names is encoded using the technique described in <xref
Section 3.1 of <xref target="RFC1035" format="default"/>. target="RFC1035" sectionFormat="of" section="3.1"/>. The message
The message compression scheme in Section 4.1.4 of <xref compression scheme in <xref target="RFC1035" sectionFormat="of"
target="RFC1035" format="default"/> MUST NOT be used. section="4.1.4"/> <bcp14>MUST NOT</bcp14> be used.
</t> </t>
</section> </section>
<section anchor="RFC3315-9" numbered="true" toc="default"> <section anchor="RFC3315-9" numbered="true" toc="default">
<name>DHCP Unique Identifier (DUID)</name> <name>DHCP Unique Identifier (DUID)</name>
<t>Each DHCP client and server has a DUID. DHCP servers use DUIDs to <t>Each DHCP client and server has a DUID. DHCP servers use DUIDs to
identify clients for the selection of configuration parameters and in identify clients for the selection of configuration parameters and in
the association of IAs with clients. DHCP clients use DUIDs to identify the association of IAs with clients. DHCP clients use DUIDs to identify
a server in messages where a server needs to be identified. See a server in messages where a server needs to be identified. See
Sections <xref target="RFC3315-22.2" format="counter"/> and Sections <xref target="RFC3315-22.2" format="counter"/> and
<xref target="RFC3315-22.3" format="counter"/> <xref target="RFC3315-22.3" format="counter"/>
for details regarding the representation of a DUID in a DHCP message.</t> for details regarding the representation of a DUID in a DHCP message.</t>
<t>Clients and servers MUST treat DUIDs as opaque values and MUST only <t>Clients and servers <bcp14>MUST</bcp14> treat DUIDs as opaque values an
compare DUIDs for equality. Clients and servers SHOULD NOT in any other d <bcp14>MUST</bcp14> only
way interpret DUIDs. Clients and servers MUST NOT restrict DUIDs to the compare DUIDs for equality. Clients and servers <bcp14>SHOULD NOT</bcp14>
in any other
way interpret DUIDs. Clients and servers <bcp14>MUST NOT</bcp14> restrict
DUIDs to the
types defined in this document, as additional DUID types may be defined types defined in this document, as additional DUID types may be defined
in the future. It should be noted that an attempt to parse a DUID to in the future. It should be noted that an attempt to parse a DUID to
obtain a client's link-layer address is unreliable, as there is no obtain a client's link-layer address is unreliable, as there is no
guarantee that the client is still using the same link‑layer guarantee that the client is still using the same link-layer
address as when it generated its DUID. Also, such an attempt will be address as when it generated its DUID. Also, such an attempt will be
more and more unreliable as more clients adopt privacy measures more and more unreliable as more clients adopt privacy measures
such as those defined in <xref target="RFC7844" format="default"/>. such as those defined in <xref target="RFC7844" format="default"/>.
If this capability is required, it is recommended to rely on the If this capability is required, it is recommended to rely on the
Client Link‑Layer Address option instead Client Link-Layer Address option instead
<xref target="RFC6939" format="default"/>.</t> <xref target="RFC6939" format="default"/>.</t>
<t>The DUID is carried in an option because it may be variable in length <t>The DUID is carried in an option because it may be variable in length
and because it is not required in all DHCP messages. The DUID is and because it is not required in all DHCP messages. The DUID is
designed to be unique across all DHCP clients and servers, and stable designed to be unique across all DHCP clients and servers, and stable
for any specific client or server. That is, the DUID used by a for any specific client or server. That is, the DUID used by a
client or server SHOULD NOT change over time if at all possible; for client or server <bcp14>SHOULD NOT</bcp14> change over time if at all poss ible; for
example, a device's DUID should not change as a result of a change in example, a device's DUID should not change as a result of a change in
the device's network hardware or changes to virtual interfaces (e.g., the device's network hardware or changes to virtual interfaces (e.g.,
logical PPP (over Ethernet) interfaces that may come and go in logical PPP (over Ethernet) interfaces that may come and go in
Customer Premises Equipment routers). The client Customer Premises Equipment routers). The client
may change its DUID as specified in <xref target="RFC7844" format="default "/>.</t> may change its DUID as specified in <xref target="RFC7844" format="default "/>.</t>
<t>The motivation for having more than one type of DUID is that the DUID <t>The motivation for having more than one type of DUID is that the DUID
must be globally unique and must also be easy to generate. The sort of must be globally unique and must also be easy to generate. The sort of
globally unique identifier that is easy to generate for any given device globally unique identifier that is easy to generate for any given device
can differ quite widely. Also, some devices may not contain any can differ quite widely. Also, some devices may not contain any
persistent storage. Retaining a generated DUID in such a device is not persistent storage. Retaining a generated DUID in such a device is not
skipping to change at line 1337 skipping to change at line 1412
UUID stored in a device's firmware settings.</t> UUID stored in a device's firmware settings.</t>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>DUID Based on Link-Layer Address Plus Time (DUID-LLT)</name> <name>DUID Based on Link-Layer Address Plus Time (DUID-LLT)</name>
<t>This type of DUID consists of a 2-octet type field containing the <t>This type of DUID consists of a 2-octet type field containing the
value 1, a 2-octet hardware type code, and 4 octets containing value 1, a 2-octet hardware type code, and 4 octets containing
a time value, followed by the link-layer address of any one network a time value, followed by the link-layer address of any one network
interface that is connected to the DHCP device at the time that the interface that is connected to the DHCP device at the time that the
DUID is generated. The time value is the time that the DUID is DUID is generated. The time value is the time that the DUID is
generated, represented in seconds since midnight (UTC), January 1, generated, represented in seconds since midnight (UTC), January 1,
2000, modulo 2^32. The hardware type MUST be a valid hardware type 2000, modulo 2^32. The hardware type <bcp14>MUST</bcp14> be a valid hard ware type
assigned by IANA; see <xref target="IANA-HARDWARE-TYPES" format="default "/>. Both the assigned by IANA; see <xref target="IANA-HARDWARE-TYPES" format="default "/>. Both the
time and the hardware type are stored in network byte order. For time and the hardware type are stored in network byte order. For
Ethernet hardware types, the link-layer address is stored in canonical Ethernet hardware types, the link-layer address is stored in canonical
form, as described in <xref target="RFC2464" format="default"/>.</t> form, as described in <xref target="RFC2464" format="default"/>.</t>
<t>The following diagram illustrates the format of a DUID-LLT:</t> <t>The following diagram illustrates the format of a DUID-LLT:</t>
<figure anchor="FigDUIDLLT"> <figure anchor="FigDUIDLLT">
<name>DUID-LLT Format</name> <name>DUID-LLT Format</name>
<artwork align="left" name="" type="" alt=""><![CDATA[ <artwork align="left" name="" type="" alt=""><![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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DUID-Type (1) | hardware type (16 bits) | | DUID-Type (1) | hardware type (16 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| time (32 bits) | | time (32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . . .
. link-layer address (variable length) . . link-layer address (variable length) .
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
]]></artwork>
</figure> </figure>
<t>The choice of network interface can be completely arbitrary, as <t>The choice of network interface can be completely arbitrary, as
long as that interface provides a globally unique link-layer address long as that interface provides a globally unique link-layer address
for the link type; the same DUID-LLT SHOULD be used in configuring for the link type; the same DUID-LLT <bcp14>SHOULD</bcp14> be used in co nfiguring
all network interfaces connected to the device, regardless of which all network interfaces connected to the device, regardless of which
interface's link-layer address was used to generate the DUID-LLT.</t> interface's link-layer address was used to generate the DUID-LLT.</t>
<t>Clients and servers using this type of DUID MUST store the DUID-LLT <t>Clients and servers using this type of DUID <bcp14>MUST</bcp14> store
in stable storage and MUST continue to use this DUID-LLT even if the the DUID-LLT
in stable storage and <bcp14>MUST</bcp14> continue to use this DUID-LLT
even if the
network interface used to generate the DUID-LLT is removed. Clients network interface used to generate the DUID-LLT is removed. Clients
and servers that do not have any stable storage MUST NOT use this type and servers that do not have any stable storage <bcp14>MUST NOT</bcp14> use this type
of DUID.</t> of DUID.</t>
<t>Clients and servers that use this DUID SHOULD attempt to configure <t>Clients and servers that use this DUID <bcp14>SHOULD</bcp14> attempt
the time prior to generating the DUID, if that is possible, and MUST to configure
the time prior to generating the DUID, if that is possible, and <bcp14>M
UST</bcp14>
use some sort of time source (for example, a real-time clock) in use some sort of time source (for example, a real-time clock) in
generating the DUID, even if that time source could not be configured generating the DUID, even if that time source could not be configured
prior to generating the DUID. The use of a time source makes it prior to generating the DUID. The use of a time source makes it
unlikely that two identical DUID-LLTs will be generated if the network unlikely that two identical DUID-LLTs will be generated if the network
interface is removed from the client and another client then uses the interface is removed from the client and another client then uses the
same network interface to generate a DUID-LLT. A collision between two same network interface to generate a DUID-LLT. A collision between two
DUID-LLTs is very unlikely even if the clocks have not been configured DUID-LLTs is very unlikely even if the clocks have not been configured
prior to generating the DUID.</t> prior to generating the DUID.</t>
<t>This method of DUID generation is recommended for all <t>This method of DUID generation is recommended for all
general-purpose computing devices such as desktop computers and laptop general-purpose computing devices such as desktop computers and laptop
computers, and also for devices such as printers, routers, and so on, computers, and also for devices such as printers, routers, and so on,
that contain some form of writable non-volatile storage.</t> that contain some form of writable non-volatile storage.</t>
<t>It is possible that this algorithm for <t>It is possible that this algorithm for
generating a DUID could result in a client identifier collision. A generating a DUID could result in a client identifier collision. A
DHCP client that generates a DUID-LLT using this mechanism MUST DHCP client that generates a DUID-LLT using this mechanism <bcp14>MUST</ bcp14>
provide an administrative interface that replaces the existing DUID provide an administrative interface that replaces the existing DUID
with a newly generated DUID-LLT.</t> with a newly generated DUID-LLT.</t>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>DUID Assigned by Vendor Based on Enterprise Number (DUID-EN)</name > <name>DUID Assigned by Vendor Based on Enterprise Number (DUID-EN)</name >
<t>The vendor assigns this form of DUID to the device. This DUID <t>The vendor assigns this form of DUID to the device. This DUID
consists of the 4‑octet vendor's registered Private Enterprise consists of the 4-octet vendor's registered Private Enterprise
Number as maintained by IANA <xref target="IANA-PEN" format="default"/> followed by a Number as maintained by IANA <xref target="IANA-PEN" format="default"/> followed by a
unique identifier assigned by the vendor. The following diagram unique identifier assigned by the vendor. The following diagram
summarizes the structure of a DUID-EN:</t> summarizes the structure of a DUID-EN:</t>
<figure anchor="FigDUIDEN"> <figure anchor="FigDUIDEN">
<name>DUID-EN Format</name> <name>DUID-EN Format</name>
<artwork align="left" name="" type="" alt=""><![CDATA[ <artwork align="left" name="" type="" alt=""><![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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DUID-Type (2) | enterprise-number | | DUID-Type (2) | enterprise-number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| enterprise-number (contd) | | | enterprise-number (contd) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
. identifier . . identifier .
. (variable length) . . (variable length) .
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
]]></artwork>
</figure> </figure>
<t>The source of the identifier is left up to the vendor defining it, <t>The source of the identifier is left up to the vendor defining it,
but each identifier part of each DUID-EN MUST be unique to the device but each identifier part of each DUID-EN <bcp14>MUST</bcp14> be unique t
that is using it, and MUST be assigned to the device no later than at o the device
that is using it, and <bcp14>MUST</bcp14> be assigned to the device no l
ater than at
the first usage and stored in some form of non-volatile storage. This the first usage and stored in some form of non-volatile storage. This
typically means being assigned during the manufacturing process typically means being assigned during the manufacturing process
in the case of physical devices or, in the case of virtual machines, in the case of physical devices or, in the case of virtual machines,
when the image is created or booted for the first time. The when the image is created or booted for the first time. The
generated DUID SHOULD be recorded in non-erasable storage. The generated DUID <bcp14>SHOULD</bcp14> be recorded in non-erasable storage . The
enterprise-number is the vendor's registered Private enterprise-number is the vendor's registered Private
Enterprise Number as maintained by IANA <xref target="IANA-PEN" format=" default"/>. The Enterprise Number as maintained by IANA <xref target="IANA-PEN" format=" default"/>. The
enterprise-number is stored as an unsigned 32‑bit number.</t> enterprise-number is stored as an unsigned 32-bit number.</t>
<t>An example DUID of this type might look like this:</t> <t>An example DUID of this type might look like this:</t>
<figure anchor="FigDUIDENExample"> <figure anchor="FigDUIDENExample">
<name>DUID-EN Example</name> <name>DUID-EN Example</name>
<artwork align="left" name="" type="" alt=""><![CDATA[ <artwork align="left" name="" type="" alt=""><![CDATA[
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
| 0 | 2 | 0 | 0 |126|217| 12|192| | 0 | 2 | 0 | 0 |126|217| 12|192|
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
|132|211| 3 | 0 | 9 | 18| |132|211| 3 | 0 | 9 | 18|
+---+---+---+---+---+---+ +---+---+---+---+---+---+]]></artwork>
]]></artwork>
</figure> </figure>
<t>This example includes the 2-octet type of 2 and the Enterprise <t>This example includes the 2-octet type of 2 and the Enterprise
Number (32473) (from <xref target="RFC5612"/>), followed by 8 octets of identifier data Number (32473) (from <xref target="RFC5612"/>), followed by 8 octets of identifier data
(0x0CC084D303000912).</t> (0x0CC084D303000912).</t>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>DUID Based on Link-Layer Address (DUID-LL)</name> <name>DUID Based on Link-Layer Address (DUID-LL)</name>
<t>This type of DUID consists of 2 octets containing a DUID type <t>This type of DUID consists of 2 octets containing a DUID type
of 3 and a 2-octet network hardware type code, followed by of 3 and a 2-octet network hardware type code, followed by
the link‑layer address of any one network interface that is the link-layer address of any one network interface that is
permanently connected to the client or server device. For example, a permanently connected to the client or server device. For example, a
node that has a network interface implemented in a chip that is node that has a network interface implemented in a chip that is
unlikely to be removed and used elsewhere could use a DUID-LL. unlikely to be removed and used elsewhere could use a DUID-LL.
The hardware type MUST be a valid hardware type assigned by IANA; The hardware type <bcp14>MUST</bcp14> be a valid hardware type assigned by IANA;
see <xref target="IANA-HARDWARE-TYPES" format="default"/>. see <xref target="IANA-HARDWARE-TYPES" format="default"/>.
The hardware type is stored in network byte The hardware type is stored in network byte
order. The link-layer address is stored in canonical form, as order. The link-layer address is stored in canonical form, as
described in <xref target="RFC2464" format="default"/>. The following di agram described in <xref target="RFC2464" format="default"/>. The following di agram
illustrates the format of a DUID-LL:</t> illustrates the format of a DUID-LL:</t>
<figure anchor="FigDUIDLL"> <figure anchor="FigDUIDLL">
<name>DUID-LL Format</name> <name>DUID-LL Format</name>
<artwork align="left" name="" type="" alt=""><![CDATA[ <artwork align="left" name="" type="" alt=""><![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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DUID-Type (3) | hardware type (16 bits) | | DUID-Type (3) | hardware type (16 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . . .
. link-layer address (variable length) . . link-layer address (variable length) .
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
]]></artwork>
</figure> </figure>
<t>The choice of network interface can be completely arbitrary, as <t>The choice of network interface can be completely arbitrary, as
long as that interface provides a unique link-layer address and is long as that interface provides a unique link-layer address and is
permanently attached to the device on which the DUID-LL is being permanently attached to the device on which the DUID-LL is being
generated. The same DUID-LL SHOULD be used in configuring all network generated. The same DUID-LL <bcp14>SHOULD</bcp14> be used in configuring all network
interfaces connected to the device, regardless of which interface's interfaces connected to the device, regardless of which interface's
link-layer address was used to generate the DUID.</t> link-layer address was used to generate the DUID.</t>
<t>A DUID-LL is recommended for devices that have a permanently <t>A DUID-LL is recommended for devices that have a permanently
connected network interface with a link-layer address and do not connected network interface with a link-layer address and do not
have nonvolatile, writable stable storage. A DUID-LL SHOULD NOT be have nonvolatile, writable stable storage. A DUID-LL <bcp14>SHOULD NOT</ bcp14> be
used by DHCP clients or servers that cannot tell whether or not a used by DHCP clients or servers that cannot tell whether or not a
network interface is permanently attached to the device on which the network interface is permanently attached to the device on which the
DHCP client is running.</t> DHCP client is running.</t>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>DUID Based on Universally Unique Identifier (DUID-UUID)</name> <name>DUID Based on Universally Unique Identifier (DUID-UUID)</name>
<t>This type of DUID consists of 16 octets containing a 128-bit <t>This type of DUID consists of 16 octets containing a 128-bit
UUID. <xref target="RFC6355" format="default"/> details when to use this type and UUID. <xref target="RFC6355" format="default"/> details when to use this type and
how to pick an appropriate source of the UUID. how to pick an appropriate source of the UUID.
</t> </t>
<figure anchor="FigDUIDUUID"> <figure anchor="FigDUIDUUID">
<name>DUID-UUID Format</name> <name>DUID-UUID Format</name>
<artwork align="left" name="" type="" alt=""><![CDATA[ <artwork align="left" name="" type="" alt=""><![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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DUID-Type (4) | UUID (128 bits) | | DUID-Type (4) | UUID (128 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | | |
| | | |
| -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-]]></artwork>
]]></artwork>
</figure> </figure>
</section> </section>
</section> </section>
<section anchor="RFC3315-10" numbered="true" toc="default"> <section anchor="RFC3315-10" numbered="true" toc="default">
<name>Identity Association</name> <name>Identity Association</name>
<t>An Identity Association (IA) is a construct through which a server <t>An Identity Association (IA) is a construct through which a server
and a client can identify, group, and manage a set of related IPv6 and a client can identify, group, and manage a set of related IPv6
addresses or delegated prefixes. Each IA consists of an IAID and addresses or delegated prefixes. Each IA consists of an IAID and
associated configuration information.</t> associated configuration information.</t>
<t>The IAID uniquely identifies the IA and MUST be chosen to be unique <t>The IAID uniquely identifies the IA and <bcp14>MUST</bcp14> be chosen t o be unique
among the IAIDs for that IA type on the client (e.g., an IA_NA with among the IAIDs for that IA type on the client (e.g., an IA_NA with
an IAID of 0 and an IA_PD with an IAID of 0 are each considered unique). an IAID of 0 and an IA_PD with an IAID of 0 are each considered unique).
The IAID is chosen by the client. For any given use of an IA by the The IAID is chosen by the client. For any given use of an IA by the
client, the IAID for that IA MUST be consistent across restarts of the client, the IAID for that IA <bcp14>MUST</bcp14> be consistent across rest arts of the
DHCP client. The client may maintain consistency by either storing the DHCP client. The client may maintain consistency by either storing the
IAID in non-volatile storage or using an algorithm that will IAID in non-volatile storage or using an algorithm that will
consistently produce the same IAID as long as the configuration of the consistently produce the same IAID as long as the configuration of the
client has not changed. There may be no way for a client to maintain client has not changed. There may be no way for a client to maintain
consistency of the IAIDs if it does not have non-volatile storage and consistency of the IAIDs if it does not have non-volatile storage and
the client's hardware configuration changes. If the client uses only one the client's hardware configuration changes. If the client uses only one
IAID, it can use a well-known value, e.g., zero.</t> IAID, it can use a well-known value, e.g., zero.</t>
<t>If the client wishes to obtain a distinctly new address or prefix and <t>If the client wishes to obtain a distinctly new address or prefix and
deprecate the existing one, the client sends a Release message deprecate the existing one, the client sends a Release message
to the server for the IAs using the original IAID. The client then to the server for the IAs using the original IAID. The client then
creates a new IAID, to be used in future messages to obtain leases for creates a new IAID, to be used in future messages to obtain leases for
the new IA.</t> the new IA.</t>
<section anchor="RFC3315-10.1" numbered="true" toc="default"> <section anchor="RFC3315-10.1" numbered="true" toc="default">
<name>Identity Associations for Address Assignment</name> <name>Identity Associations for Address Assignment</name>
<t>A client must associate at least one distinct IA with each of its <t>A client must associate at least one distinct IA with each of its
network interfaces for which it is to request the assignment of IPv6 network interfaces for which it is to request the assignment of IPv6
addresses from a DHCP server. The client uses the IAs assigned to an addresses from a DHCP server. The client uses the IAs assigned to an
interface to obtain configuration information from a server for that interface to obtain configuration information from a server for that
interface. Each such IA must be associated with exactly one interface.</ t> interface. Each such IA must be associated with exactly one interface.</ t>
<t>The configuration information in an IA_NA option consists of one or <t>The configuration information in an IA_NA option consists of one or
more IPv6 addresses along with the T1 and T2 values for the IA. See <xre more IPv6 addresses along with the T1 and T2 values for the IA. See
f target="RFC3315-22.4" format="default"/> for details regarding the representat <xref target="RFC3315-22.4" format="default"/> for details regarding
ion of an IA_NA in a the representation of an IA_NA in a DHCP message.</t>
DHCP message.</t>
<t>Each address in an IA has a preferred lifetime and a valid <t>Each address in an IA has a preferred lifetime and a valid
lifetime, as defined in <xref target="RFC4862" format="default"/>. The l ifetimes lifetime, as defined in <xref target="RFC4862" format="default"/>. The l ifetimes
are transmitted from the DHCP server to the client in the IA Address are transmitted from the DHCP server to the client in the IA Address
option (see <xref target="RFC3315-22.6" format="default"/>). option (see <xref target="RFC3315-22.6" format="default"/>).
The lifetimes apply to the use of addresses; see The lifetimes apply to the use of addresses; see
Section 5.5.4 of <xref target="RFC4862" format="default"/>.</t> <xref target="RFC4862" sectionFormat="of" section="5.5.4"/>.</t>
</section> </section>
<section anchor="RFC3315-10.2" numbered="true" toc="default"> <section anchor="RFC3315-10.2" numbered="true" toc="default">
<name>Identity Associations for Prefix Delegation</name> <name>Identity Associations for Prefix Delegation</name>
<t>An IA_PD is different from an IA for address assignment in that it <t>An IA_PD is different from an IA for address assignment in that it
does not need to be associated with exactly one interface. One IA_PD does not need to be associated with exactly one interface. One IA_PD
can be associated with the client, with a set of interfaces, can be associated with the client, with a set of interfaces,
or with exactly one interface. A client configured to request or with exactly one interface. A client configured to request
delegated prefixes must create at delegated prefixes must create at
least one distinct IA_PD. It may associate a distinct IA_PD with each least one distinct IA_PD. It may associate a distinct IA_PD with each
of its downstream network interfaces and use that IA_PD to obtain a of its downstream network interfaces and use that IA_PD to obtain a
prefix for that interface from the server.</t> prefix for that interface from the server.</t>
<t>The configuration information in an IA_PD option consists of one or m ore <t>The configuration information in an IA_PD option consists of one or m ore
prefixes along with the T1 and T2 values for the IA_PD. See <xref target ="IA_PD-option" format="default"/> for details regarding the representation of a n IA_PD in a prefixes along with the T1 and T2 values for the IA_PD. See <xref target ="IA_PD-option" format="default"/> for details regarding the representation of a n IA_PD in a
DHCP message.</t> DHCP message.</t>
<t>Each delegated prefix in an IA has a preferred lifetime and a valid <t>Each delegated prefix in an IA has a preferred lifetime and a valid
lifetime, as defined in <xref target="RFC4862" format="default"/>. The l ifetimes lifetime, as defined in <xref target="RFC4862" format="default"/>. The l ifetimes
are transmitted from the DHCP server to the client in the IA Prefix opti on are transmitted from the DHCP server to the client in the IA Prefix opti on
(see <xref target="IAPREFIX-option" format="default"/>). (see <xref target="IAPREFIX-option" format="default"/>).
The lifetimes apply to the use of delegated prefixes; see The lifetimes apply to the use of delegated prefixes; see
Section 5.5.4 of <xref target="RFC4862" format="default"/>.</t> <xref target="RFC4862" sectionFormat="of" section="5.5.4"/>.</t>
</section> </section>
</section> </section>
<section anchor="RFC3315-11" numbered="true" toc="default"> <section anchor="RFC3315-11" numbered="true" toc="default">
<name>Assignment to an IA</name> <name>Assignment to an IA</name>
<section anchor="addr-assign-ia-na" numbered="true" toc="default"> <section anchor="addr-assign-ia-na" numbered="true" toc="default">
<name>Selecting Addresses for Assignment to an IA_NA</name> <name>Selecting Addresses for Assignment to an IA_NA</name>
<t>A server selects addresses to be assigned to an IA_NA according to <t>A server selects addresses to be assigned to an IA_NA according to
the address assignment policies determined by the server administrator the address assignment policies determined by the server administrator
and the specific information the server determines about the client and the specific information the server determines about the client
from some combination of the following sources:</t> from some combination of the following sources:</t>
skipping to change at line 1586 skipping to change at line 1657
<ul spacing="normal"> <ul spacing="normal">
<li>If the server receives the message directly <li>If the server receives the message directly
from the client and the source address in the IP datagram in from the client and the source address in the IP datagram in
which the message was received is a link-local address, then which the message was received is a link-local address, then
the client is on the same link to which the interface over the client is on the same link to which the interface over
which the message was received is attached.</li> which the message was received is attached.</li>
<li>If the server receives the message from a <li>If the server receives the message from a
forwarding relay agent, then the client is on the same link as forwarding relay agent, then the client is on the same link as
the one to which the interface, identified by the link-address the one to which the interface, identified by the link-address
field in the message from the relay agent, is attached. field in the message from the relay agent, is attached.
According to <xref target="RFC6221" format="default"/>, the serv er MUST According to <xref target="RFC6221" format="default"/>, the serv er <bcp14>MUST</bcp14>
ignore any link-address field whose value is zero. The ignore any link-address field whose value is zero. The
link-address in this case may come from any of the link-address in this case may come from any of the
Relay-forward messages encapsulated in the received Relay-forward messages encapsulated in the received
Relay-forward, and in general the most encapsulated Relay-forward, and in general the most encapsulated
(closest Relay-forward to the client) has the most (closest Relay-forward to the client) has the most
useful value.</li> useful value.</li>
</ul> </ul>
</li> </li>
<li>The DUID supplied by the client.</li> <li>The DUID supplied by the client.</li>
<li>Other information in options supplied by the <li>Other information in options supplied by the
client, e.g., IA Address options (see <xref target="RFC3315-22.6" fo rmat="default"/>) client, e.g., IA Address options (see <xref target="RFC3315-22.6" fo rmat="default"/>)
that include the client's requests for specific addresses.</li> that include the client's requests for specific addresses.</li>
<li>Other information in options supplied by the relay <li>Other information in options supplied by the relay
agent.</li> agent.</li>
</ul> </ul>
<t>By default, DHCP server implementations SHOULD NOT generate <t>By default, DHCP server implementations <bcp14>SHOULD NOT</bcp14> gen
predictable addresses (see Section 4.7 of <xref target="RFC7721" format= erate
"default"/>). Server predictable addresses (see <xref target="RFC7721" sectionFormat="of" sec
tion="4.7"/>). Server
implementers are encouraged to review <xref target="RFC8981" format="def ault"/>, implementers are encouraged to review <xref target="RFC8981" format="def ault"/>,
<xref target="RFC7824" format="default"/>, <xref target="RFC7707" format ="default"/>, and <xref target="RFC7824" format="default"/>, <xref target="RFC7707" format ="default"/>, and
<xref target="RFC7943" format="default"/> as to <xref target="RFC7943" format="default"/> as to
possible considerations for how to generate addresses.</t> possible considerations for how to generate addresses.</t>
<t>A server MUST NOT assign an address that is otherwise reserved for <t>A server <bcp14>MUST NOT</bcp14> assign an address that is otherwise
some other purpose. For example, a server MUST NOT assign addresses reserved for
some other purpose. For example, a server <bcp14>MUST NOT</bcp14> assign
addresses
that use a reserved IPv6 Interface Identifier <xref target="RFC5453" for mat="default"/> that use a reserved IPv6 Interface Identifier <xref target="RFC5453" for mat="default"/>
<xref target="RFC7136" format="default"/> <xref target="IANA-RESERVED- IID" format="default"/>.</t> <xref target="RFC7136" format="default"/> <xref target="IANA-RESERVED- IID" format="default"/>.</t>
<t>See <xref target="RFC7969" format="default"/> for a more detailed <t>See <xref target="RFC7969" format="default"/> for a more detailed
discussion on how servers determine a client's location on the network.< /t> discussion on how servers determine a client's location on the network.< /t>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Assignment of Prefixes for IA_PD</name> <name>Assignment of Prefixes for IA_PD</name>
<t>The mechanism through which the server selects <t>The mechanism through which the server selects
prefix(es) for delegation is not specified in this document. Examples prefix(es) for delegation is not specified in this document. Examples
of ways in which the server might select prefix(es) for a client of ways in which the server might select prefix(es) for a client
skipping to change at line 1632 skipping to change at line 1703
external authority such as a RADIUS server using the external authority such as a RADIUS server using the
Framed-IPv6-Prefix option as described in <xref target="RFC3162" format= "default"/>.</t> Framed-IPv6-Prefix option as described in <xref target="RFC3162" format= "default"/>.</t>
</section> </section>
</section> </section>
<section anchor="RFC3315-13" numbered="true" toc="default"> <section anchor="RFC3315-13" numbered="true" toc="default">
<name>Transmission of Messages by a Client</name> <name>Transmission of Messages by a Client</name>
<t>Unless otherwise specified in this document or in a document that <t>Unless otherwise specified in this document or in a document that
describes how IPv6 is carried over a specific type of link (for link describes how IPv6 is carried over a specific type of link (for link
types that do not support multicast), a client sends DHCP messages to types that do not support multicast), a client sends DHCP messages to
the All_DHCP_Relay_Agents_and_Servers multicast address.</t> the All_DHCP_Relay_Agents_and_Servers multicast address.</t>
<t>DHCP servers SHOULD NOT check to see whether the Layer 2 address <t>DHCP servers <bcp14>SHOULD NOT</bcp14> check to see whether the Layer 2 address
used was multicast or not, as long as the Layer 3 address was used was multicast or not, as long as the Layer 3 address was
correct.</t> correct.</t>
<t>A client uses multicast to reach all servers or an individual server. <t>A client uses multicast to reach all servers or an individual server.
An individual server is indicated by specifying that server's DUID in a An individual server is indicated by specifying that server's DUID in a
Server Identifier option (see <xref target="RFC3315-22.3" format="default" />) in Server Identifier option (see <xref target="RFC3315-22.3" format="default" />) in
the client's message. (All servers will receive this message, but only the client's message. (All servers will receive this message, but only
the indicated server will respond.) All servers are indicated when the indicated server will respond.) All servers are indicated when
this option is not supplied.</t> this option is not supplied.</t>
<section anchor="rate-limit" numbered="true" toc="default"> <section anchor="rate-limit" numbered="true" toc="default">
<name>Rate Limiting</name> <name>Rate Limiting</name>
<t> <t>
A DHCPv6 client MUST limit the rate of DHCP messages it A DHCPv6 client <bcp14>MUST</bcp14> limit the rate of DHCP messages it
transmits or retransmits. transmits or retransmits.
This will minimise the impact of prolonged message bursts or loops, This will minimize the impact of prolonged message bursts or loops,
for example when a client rejects a server's response, repeats the for example when a client rejects a server's response, repeats the
request and gets the same server response which again gets rejected request and gets the same server response, which, again, gets rejected
by the client. by the client.
</t> </t>
<t> This loop can repeat infinitely if <t> This loop can repeat infinitely if
there is not a quit/stop mechanism. Therefore, a client must not there is not a quit/stop mechanism. Therefore, a client must not
initiate transmissions too frequently. initiate transmissions too frequently.
</t> </t>
<t>A recommended method for implementing the rate-limiting function is <t>A recommended method for implementing the rate-limiting function is
a token bucket (see Appendix A of <xref target="RFC3290" format="default "/>), limiting the average rate of transmission to a certain a token bucket (see <xref section="A" target="RFC3290" format="default"/ >), limiting the average rate of transmission to a certain
number in a certain time interval. This method of bounding burstiness al so number in a certain time interval. This method of bounding burstiness al so
guarantees that the long-term transmission rate will not be exceeded.</t > guarantees that the long-term transmission rate will not be exceeded.</t >
<t>A transmission rate limit SHOULD be configurable. A possible <t>A transmission rate limit <bcp14>SHOULD</bcp14> be configurable. A po ssible
default could be 20 messages in 20 seconds.</t> default could be 20 messages in 20 seconds.</t>
<t>For a device that has multiple interfaces, the limit MUST be <t>For a device that has multiple interfaces, the limit <bcp14>MUST</bcp 14> be
enforced on a per-interface basis.</t> enforced on a per-interface basis.</t>
<t>Rate limiting of forwarded DHCP messages and server-side messages <t>Rate limiting of forwarded DHCP messages and server-side messages
is out of scope for this specification.</t> is out of scope for this specification.</t>
</section> </section>
<section anchor="t1-t2-0" numbered="true" toc="default"> <section anchor="t1-t2-0" numbered="true" toc="default">
<name>Client Behavior when T1 and/or T2 Are 0</name> <name>Client Behavior when T1 and/or T2 Are 0</name>
<t>In certain cases, T1 and/or T2 values may be set to 0. Currently, <t>In certain cases, T1 and/or T2 values may be set to 0. Currently,
there are two such cases: there are two such cases:
</t> </t>
<ol spacing="normal" type="1"><li>a client received an IA_NA option (see <xref target="RFC3315-22.4" format="default"/>) with a zero value</li> <ol spacing="normal" type="1"><li>a client received an IA_NA option (see <xref target="RFC3315-22.4" format="default"/>) with a zero value</li>
<li>a client received an IA_PD option (see <xref target="IA_PD-option" format="default"/>) with a zero value</li> <li>a client received an IA_PD option (see <xref target="IA_PD-option" format="default"/>) with a zero value</li>
</ol> </ol>
<t> <t>
This is an indication that the renew and rebind times are left to This is an indication that the renew and rebind times are left to
the discretion of the client. However, they are not completely the discretion of the client. However, they are not completely
discretionary.</t> discretionary.</t>
<t>When T1 and/or T2 values are set to 0, the client MUST choose a <t>When T1 and/or T2 values are set to 0, the client <bcp14>MUST</bcp14>
time to avoid message storms. In particular, it MUST NOT transmit choose a
immediately. If the client received multiple IA options, it SHOULD time to avoid message storms. In particular, it <bcp14>MUST NOT</bcp14>
transmit
immediately. If the client received multiple IA options, it <bcp14>SHOUL
D</bcp14>
pick renew and/or rebind transmission times so all IA options are pick renew and/or rebind transmission times so all IA options are
handled in one exchange, if possible. The client MUST choose renew handled in one exchange, if possible. The client <bcp14>MUST</bcp14> cho ose renew
and rebind times to not violate rate-limiting restrictions as defined and rebind times to not violate rate-limiting restrictions as defined
in <xref target="rate-limit" format="default"/>.</t> in <xref target="rate-limit" format="default"/>.</t>
</section> </section>
</section> </section>
<section anchor="RFC3315-14" numbered="true" toc="default"> <section anchor="RFC3315-14" numbered="true" toc="default">
<name>Reliability of Client-Initiated Message Exchanges</name> <name>Reliability of Client-Initiated Message Exchanges</name>
<t>DHCP clients are responsible for reliable delivery of messages in the <t>DHCP clients are responsible for reliable delivery of messages in the
client-initiated message exchanges described in <xref target="configuratio n-exchange" format="default"/>. If a DHCP client fails to client-initiated message exchanges described in <xref target="configuratio n-exchange" format="default"/>. If a DHCP client fails to
receive an expected response from a server, the client must retransmit receive an expected response from a server, the client must retransmit
its message according to the retransmission strategy described below.</t> its message according to the retransmission strategy described below.</t>
<t>Note that the procedure described in this section is slightly <t>Note that the procedure described in this section is slightly
modified when used with the Solicit message. The modified procedure is modified when used with the Solicit message. The modified procedure is
described in <xref target="solicit-create-transmit" format="default"/>.</t > described in <xref target="solicit-create-transmit" format="default"/>.</t >
<t>The client begins the message exchange by transmitting a message to <t>The client begins the message exchange by transmitting a message to
the server. The message exchange terminates when either the server. The message exchange terminates when either
(1) the client successfully receives the appropriate response or (1) the client successfully receives the appropriate response or
responses from a server or servers or (2) the message exchange is responses from a server or servers or (2) the message exchange is
considered to have failed according to the retransmission mechanism considered to have failed according to the retransmission mechanism
described below.</t> described below.</t>
<t>The client MUST update an "elapsed-time" value within an Elapsed <t>The client <bcp14>MUST</bcp14> update an "elapsed-time" value within an Elapsed
Time option (see <xref target="RFC3315-22.9" format="default"/>) in the Time option (see <xref target="RFC3315-22.9" format="default"/>) in the
retransmitted message. In some cases, the client may also need to modify retransmitted message. In some cases, the client may also need to modify
values in IA Address options (see <xref target="RFC3315-22.6" format="defa ult"/>) or values in IA Address options (see <xref target="RFC3315-22.6" format="defa ult"/>) or
IA Prefix options (see <xref target="IAPREFIX-option" format="default"/>) if a valid lifetime for IA Prefix options (see <xref target="IAPREFIX-option" format="default"/>) if a valid lifetime for
any of the client's leases expires before retransmission. Thus, whenever any of the client's leases expires before retransmission. Thus, whenever
this document refers to a "retransmission" of a client's message, it this document refers to a "retransmission" of a client's message, it
refers to both modifying the original message and sending this new message refers to both modifying the original message and sending this new message
instance to the server.</t> instance to the server.</t>
<t>The client retransmission behavior is controlled and described by the <t>The client retransmission behavior is controlled and described by the
following variables: </t> following variables: </t>
<dl newline="false" spacing="normal" indent="11"> <dl indent="7">
<dt> RT</dt> <dt>RT:</dt> <dd>Retransmission timeout</dd>
<dd>Retransmission timeout</dd> <dt>IRT:</dt> <dd>Initial retransmission time</dd>
<dt> IRT</dt> <dt>MRC:</dt> <dd>Maximum retransmission count</dd>
<dd>Initial retransmission time</dd> <dt>MRT:</dt> <dd>Maximum retransmission time</dd>
<dt> MRC</dt> <dt>MRD:</dt> <dd>Maximum retransmission duration</dd>
<dd>Maximum retransmission count</dd> <dt>RAND:</dt> <dd>Randomization factor</dd>
<dt> MRT</dt>
<dd>Maximum retransmission time</dd>
<dt> MRD</dt>
<dd>Maximum retransmission duration</dd>
<dt> RAND</dt>
<dd>Randomization factor</dd>
</dl> </dl>
<t>Specific values for each of these parameters relevant to the <t>Specific values for each of these parameters relevant to the
various messages are given in the subsections of various messages are given in the subsections of
<xref target="Client-Behavior" format="default"/>, using values defined in <xref target="Client-Behavior" format="default"/>, using values defined in
<xref target="Trans-Parameters-Table" format="default"/> in <xref target=" RFC3315-5.5" format="default"/>. <xref target="Trans-Parameters-Table" format="default"/> in <xref target=" RFC3315-5.5" format="default"/>.
The algorithm for RAND is common across all message transmissions.</t> The algorithm for RAND is common across all message transmissions.</t>
<t>With each message transmission or retransmission, the client sets RT <t>With each message transmission or retransmission, the client sets RT
according to the rules given below. If RT expires before the message according to the rules given below. If RT expires before the message
exchange terminates, the client recomputes RT and retransmits the exchange terminates, the client recomputes RT and retransmits the
message.</t> message.</t>
<t>Each of the computations of a new RT includes a randomization factor <t>Each of the computations of a new RT includes a randomization factor
(RAND), which is a random number chosen with a uniform distribution (RAND), which is a random number chosen with a uniform distribution
between -0.1 and +0.1. The randomization factor is included to minimize between -0.1 and +0.1. The randomization factor is included to minimize
synchronization of messages transmitted by DHCP clients.</t> synchronization of messages transmitted by DHCP clients.</t>
<t>The algorithm for choosing a random number does not need to be <t>The algorithm for choosing a random number does not need to be
cryptographically sound. The algorithm SHOULD produce a different cryptographically sound. The algorithm <bcp14>SHOULD</bcp14> produce a dif ferent
sequence of random numbers from each invocation of the DHCP client.</t> sequence of random numbers from each invocation of the DHCP client.</t>
<t>RT for the first message transmission is based on IRT:</t> <t>RT for the first message transmission is based on IRT:</t>
<artwork name="" type="" align="left" alt=""><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
RT = IRT + RAND*IRT RT = IRT + RAND*IRT]]></artwork>
]]></artwork>
<t>RT for each subsequent message transmission is based on the previous <t>RT for each subsequent message transmission is based on the previous
value of RT:</t> value of RT:</t>
<artwork name="" type="" align="left" alt=""><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
RT = 2*RTprev + RAND*RTprev RT = 2*RTprev + RAND*RTprev]]></artwork>
]]></artwork>
<t>MRT specifies an upper bound on the value of RT (disregarding the <t>MRT specifies an upper bound on the value of RT (disregarding the
randomization added by the use of RAND). If MRT has a value of 0, there randomization added by the use of RAND). If MRT has a value of 0, there
is no upper limit on the value of RT. Otherwise:</t> is no upper limit on the value of RT. Otherwise:</t>
<artwork name="" type="" align="left" alt=""><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
if (RT > MRT) if (RT > MRT)
RT = MRT + RAND*MRT RT = MRT + RAND*MRT]]></artwork>
]]></artwork>
<t>MRC specifies an upper bound on the number of times a client may <t>MRC specifies an upper bound on the number of times a client may
retransmit a message. Unless MRC is zero, the message exchange fails retransmit a message. Unless MRC is zero, the message exchange fails
once the client has transmitted the message MRC times.</t> once the client has transmitted the message MRC times.</t>
<t>MRD specifies an upper bound on the length of time a client may <t>MRD specifies an upper bound on the length of time a client may
retransmit a message. Unless MRD is zero, the message exchange fails retransmit a message. Unless MRD is zero, the message exchange fails
once MRD seconds have elapsed since the client first transmitted the once MRD seconds have elapsed since the client first transmitted the
message.</t> message.</t>
<t>If both MRC and MRD are non-zero, the message exchange fails whenever <t>If both MRC and MRD are non-zero, the message exchange fails whenever
either of the conditions specified in the previous two paragraphs either of the conditions specified in the previous two paragraphs
is met.</t> is met.</t>
<t>If both MRC and MRD are zero, the client continues to transmit the <t>If both MRC and MRD are zero, the client continues to transmit the
message until it receives a response.</t> message until it receives a response.</t>
<t>A client is not expected to listen for a response during the entire <t>A client is not expected to listen for a response during the entire
RT period and may turn off listening capabilities after waiting at least RT period and may turn off listening capabilities after waiting at least
the shorter of RT and MAX_WAIT_TIME due to power consumption saving or the shorter of RT and MAX_WAIT_TIME due to power consumption saving or
other reasons. Of course, a client MUST listen for a Reconfigure if it other reasons. Of course, a client <bcp14>MUST</bcp14> listen for a Reconf igure if it
has negotiated for its use with the server.</t> has negotiated for its use with the server.</t>
</section> </section>
<section anchor="RFC3315-15" numbered="true" toc="default"> <section anchor="RFC3315-15" numbered="true" toc="default">
<name>Message Validation</name> <name>Message Validation</name>
<t>This section describes which options are valid in which kinds of <t>This section describes which options are valid in which kinds of
message types and explains what to do when a client or server receives message types and explains what to do when a client or server receives
a message that contains known options that are invalid for that message. a message that contains known options that are invalid for that message.
For example, an IA option is not allowed to appear in an For example, an IA option is not allowed to appear in an
Information-request message.</t> Information-request message.</t>
<t>Clients and servers MAY choose to either (1) extract <t>Clients and servers <bcp14>MAY</bcp14> choose to either (1) extract
information from such a message if the information is of use to the information from such a message if the information is of use to the
recipient or (2) ignore such a message completely and just recipient or (2) ignore such a message completely and just
discard it.</t> discard it.</t>
<t>If a server receives a message that it considers invalid, it <t>If a server receives a message that it considers invalid, it
MAY send a Reply message (or Advertise message, as appropriate) with a <bcp14>MAY</bcp14> send a Reply message (or Advertise message, as appropri ate) with a
Server Identifier option (see <xref target="RFC3315-22.3" format="default" />), a Client Server Identifier option (see <xref target="RFC3315-22.3" format="default" />), a Client
Identifier option (see <xref target="RFC3315-22.2" format="default"/>) (if one was Identifier option (see <xref target="RFC3315-22.2" format="default"/>) (if one was
included in the message), and a Status Code option (see <xref target="RFC3 315-22.13" format="default"/>) with status UnspecFail.</t> included in the message), and a Status Code option (see <xref target="RFC3 315-22.13" format="default"/>) with status UnspecFail.</t>
<t>Clients, relay agents, and servers MUST NOT discard messages that <t>Clients, relay agents, and servers <bcp14>MUST NOT</bcp14> discard mess ages that
contain unknown options (or instances of vendor options with unknown contain unknown options (or instances of vendor options with unknown
enterprise-number values). These options should be ignored as if they were not enterprise-number values). These options should be ignored as if they were not
present. This is critical to provide for future extensions of DHCP.</t> present. This is critical to provide for future extensions of DHCP.</t>
<t>A client or server MUST discard any received DHCP messages <t>A client or server <bcp14>MUST</bcp14> discard any received DHCP messag es
with an unknown message type.</t> with an unknown message type.</t>
<t> <t>
Clients SHOULD NOT accept multicast messages. Clients <bcp14>SHOULD NOT</bcp14> accept multicast messages.
</t> </t>
<t> <t>
Servers SHOULD NOT accept unicast traffic from clients. Servers <bcp14>SHOULD NOT</bcp14> accept unicast traffic from clients.
The Server Unicast option (see <xref target="RFC3315-22.12" format="defaul t"/>) The Server Unicast option (see <xref target="RFC3315-22.12" format="defaul t"/>)
and UseMulticast status code (see <xref target="RFC3315-22.13" format="def ault"/>) and UseMulticast status code (see <xref target="RFC3315-22.13" format="def ault"/>)
have been obsoleted and hence clients should no longer send messages have been obsoleted; hence, clients should no longer send messages
to a server's unicast address nor receive the UseMulticast status code. to a server's unicast address nor receive the UseMulticast status code.
However, a server that previously supported the Server Unicast option However, a server that previously supported the Server Unicast option
and is upgraded to not support it, MAY continue to receive and is upgraded to not support it <bcp14>MAY</bcp14> continue to receive
unicast messages if it previously sent the client the Server Unicast unicast messages if it previously sent the client the Server Unicast
option. But this causes no harm and the client will eventually switch option. However, this causes no harm and the client will eventually switch
back to sending multicast messages (such as after the lease's rebinding ti me back to sending multicast messages (such as after the lease's rebinding ti me
is reached or the client is rebooted). is reached or the client is rebooted).
</t> </t>
<t> <t>
Relay agents SHOULD NOT accept unicast messages from clients. Relay agents <bcp14>SHOULD NOT</bcp14> accept unicast messages from client s.
</t> </t>
<t> <t>
Note: The multicast/unicast rules mentioned above apply to the DHCP messag es Note: The multicast/unicast rules mentioned above apply to the DHCP messag es
within this document. Messages defined in other and future documents may within this document. Messages defined in other and future documents may
have different rules. have different rules.
</t> </t>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Use of Transaction IDs</name> <name>Use of Transaction IDs</name>
<t>The "transaction-id" field holds a value used by clients and <t>The "transaction-id" field holds a value used by clients and
servers to synchronize server responses to client messages. A client servers to synchronize server responses to client messages. A client
SHOULD generate a random number that cannot easily be guessed or <bcp14>SHOULD</bcp14> generate a random number that cannot easily be gue ssed or
predicted to use as the transaction ID for each new message it sends. predicted to use as the transaction ID for each new message it sends.
Note that if a client generates easily predictable transaction Note that if a client generates easily predictable transaction
identifiers, it may become more vulnerable to certain kinds of attacks identifiers, it may become more vulnerable to certain kinds of attacks
from off-path intruders. A client MUST leave the transaction ID from off-path intruders. A client <bcp14>MUST</bcp14> leave the transact ion ID
unchanged in retransmissions of a message.</t> unchanged in retransmissions of a message.</t>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Solicit Message</name> <name>Solicit Message</name>
<t>Clients MUST discard any received Solicit messages.</t> <t>Clients <bcp14>MUST</bcp14> discard any received Solicit messages.</t
<t>Servers MUST discard any Solicit messages that do not include a >
<t>Servers <bcp14>MUST</bcp14> discard any Solicit messages that do not
include a
Client Identifier option or that do include a Server Identifier Client Identifier option or that do include a Server Identifier
option.</t> option.</t>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Advertise Message</name> <name>Advertise Message</name>
<t>Clients MUST discard any received Advertise message that meets any <t>Clients <bcp14>MUST</bcp14> discard any received Advertise message th at meets any
of the following conditions:</t> of the following conditions:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>the message does not include a Server Identifier <li>the message does not include a Server Identifier
option (see <xref target="RFC3315-22.3" format="default"/>).</li> option (see <xref target="RFC3315-22.3" format="default"/>).</li>
<li>the message does not include a Client Identifier <li>the message does not include a Client Identifier
option (see <xref target="RFC3315-22.2" format="default"/>).</li> option (see <xref target="RFC3315-22.2" format="default"/>).</li>
<li>the contents of the Client Identifier option do <li>the contents of the Client Identifier option do
not match the client's DUID.</li> not match the client's DUID.</li>
<li>the "transaction-id" field value does not match <li>the "transaction-id" field value does not match
the value the client used in its Solicit message.</li> the value the client used in its Solicit message.</li>
</ul> </ul>
<t>Servers and relay agents MUST discard any received Advertise <t>Servers and relay agents <bcp14>MUST</bcp14> discard any received Adv ertise
messages.</t> messages.</t>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Request Message</name> <name>Request Message</name>
<t>Clients MUST discard any received Request messages.</t> <t>Clients <bcp14>MUST</bcp14> discard any received Request messages.</t
<t>Servers MUST discard any received Request message that meets any of >
<t>Servers <bcp14>MUST</bcp14> discard any received Request message that
meets any of
the following conditions:</t> the following conditions:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>the message does not include a Server Identifier <li>the message does not include a Server Identifier
option (see <xref target="RFC3315-22.3" format="default"/>).</li> option (see <xref target="RFC3315-22.3" format="default"/>).</li>
<li>the contents of the Server Identifier option do <li>the contents of the Server Identifier option do
not match the server's DUID.</li> not match the server's DUID.</li>
<li>the message does not include a Client Identifier <li>the message does not include a Client Identifier
option (see <xref target="RFC3315-22.2" format="default"/>).</li> option (see <xref target="RFC3315-22.2" format="default"/>).</li>
</ul> </ul>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Confirm Message</name> <name>Confirm Message</name>
<t>Clients MUST discard any received Confirm messages.</t> <t>Clients <bcp14>MUST</bcp14> discard any received Confirm messages.</t
<t>Servers MUST discard any received Confirm messages that do not >
<t>Servers <bcp14>MUST</bcp14> discard any received Confirm messages tha
t do not
include a Client Identifier option (see <xref target="RFC3315-22.2" form at="default"/>) include a Client Identifier option (see <xref target="RFC3315-22.2" form at="default"/>)
or that do include a Server Identifier option (see or that do include a Server Identifier option (see
<xref target="RFC3315-22.3" format="default"/>).</t> <xref target="RFC3315-22.3" format="default"/>).</t>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Renew Message</name> <name>Renew Message</name>
<t>Clients MUST discard any received Renew messages.</t> <t>Clients <bcp14>MUST</bcp14> discard any received Renew messages.</t>
<t>Servers MUST discard any received Renew message that meets any of <t>Servers <bcp14>MUST</bcp14> discard any received Renew message that m
eets any of
the following conditions:</t> the following conditions:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>the message does not include a Server Identifier <li>the message does not include a Server Identifier
option (see <xref target="RFC3315-22.3" format="default"/>).</li> option (see <xref target="RFC3315-22.3" format="default"/>).</li>
<li>the contents of the Server Identifier option do <li>the contents of the Server Identifier option do
not match the server's identifier.</li> not match the server's identifier.</li>
<li>the message does not include a Client Identifier <li>the message does not include a Client Identifier
option (see <xref target="RFC3315-22.2" format="default"/>).</li> option (see <xref target="RFC3315-22.2" format="default"/>).</li>
</ul> </ul>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Rebind Message</name> <name>Rebind Message</name>
<t>Clients MUST discard any received Rebind messages.</t> <t>Clients <bcp14>MUST</bcp14> discard any received Rebind messages.</t>
<t>Servers MUST discard any received Rebind messages that do not <t>Servers <bcp14>MUST</bcp14> discard any received Rebind messages that
do not
include a Client Identifier option (see <xref target="RFC3315-22.2" form at="default"/>) include a Client Identifier option (see <xref target="RFC3315-22.2" form at="default"/>)
or that do include a Server Identifier option (see or that do include a Server Identifier option (see
<xref target="RFC3315-22.3" format="default"/>).</t> <xref target="RFC3315-22.3" format="default"/>).</t>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Decline Message</name> <name>Decline Message</name>
<t>Clients MUST discard any received Decline messages.</t> <t>Clients <bcp14>MUST</bcp14> discard any received Decline messages.</t
<t>Servers MUST discard any received Decline message that meets any of >
<t>Servers <bcp14>MUST</bcp14> discard any received Decline message that
meets any of
the following conditions:</t> the following conditions:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>the message does not include a Server Identifier <li>the message does not include a Server Identifier
option (see <xref target="RFC3315-22.3" format="default"/>).</li> option (see <xref target="RFC3315-22.3" format="default"/>).</li>
<li>the contents of the Server Identifier option do <li>the contents of the Server Identifier option do
not match the server's identifier.</li> not match the server's identifier.</li>
<li>the message does not include a Client Identifier <li>the message does not include a Client Identifier
option (see <xref target="RFC3315-22.2" format="default"/>).</li> option (see <xref target="RFC3315-22.2" format="default"/>).</li>
</ul> </ul>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Release Message</name> <name>Release Message</name>
<t>Clients MUST discard any received Release messages.</t> <t>Clients <bcp14>MUST</bcp14> discard any received Release messages.</t
<t>Servers MUST discard any received Release message that meets any of >
<t>Servers <bcp14>MUST</bcp14> discard any received Release message that
meets any of
the following conditions:</t> the following conditions:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>the message does not include a Server Identifier <li>the message does not include a Server Identifier
option (see <xref target="RFC3315-22.3" format="default"/>).</li> option (see <xref target="RFC3315-22.3" format="default"/>).</li>
<li>the contents of the Server Identifier option do <li>the contents of the Server Identifier option do
not match the server's identifier.</li> not match the server's identifier.</li>
<li>the message does not include a Client Identifier <li>the message does not include a Client Identifier
option (see <xref target="RFC3315-22.2" format="default"/>).</li> option (see <xref target="RFC3315-22.2" format="default"/>).</li>
</ul> </ul>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Reply Message</name> <name>Reply Message</name>
<t>Clients MUST discard any received Reply message that meets any of <t>Clients <bcp14>MUST</bcp14> discard any received Reply message that m eets any of
the following conditions:</t> the following conditions:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>the message does not include a Server Identifier <li>the message does not include a Server Identifier
option (see <xref target="RFC3315-22.3" format="default"/>).</li> option (see <xref target="RFC3315-22.3" format="default"/>).</li>
<li>the "transaction-id" field in the message does not <li>the "transaction-id" field in the message does not
match the value used in the original message.</li> match the value used in the original message.</li>
</ul> </ul>
<t>If the client included a Client Identifier option (see <xref target=" RFC3315-22.2" format="default"/>) in the original message, <t>If the client included a Client Identifier option (see <xref target=" RFC3315-22.2" format="default"/>) in the original message,
the Reply message MUST include a the Reply message <bcp14>MUST</bcp14> include a
Client Identifier option, and the contents of the Client Identifier Client Identifier option, and the contents of the Client Identifier
option MUST match the DUID of the client. If the client did not option <bcp14>MUST</bcp14> match the DUID of the client. If the client did not
include a Client Identifier option in the original message, the Reply include a Client Identifier option in the original message, the Reply
message MUST NOT include a Client Identifier option. message <bcp14>MUST NOT</bcp14> include a Client Identifier option.
</t> </t>
<t>Servers and relay agents MUST discard any received Reply <t>Servers and relay agents <bcp14>MUST</bcp14> discard any received Rep ly
messages.</t> messages.</t>
</section> </section>
<section anchor="RFC3315-15.11" numbered="true" toc="default"> <section anchor="RFC3315-15.11" numbered="true" toc="default">
<name>Reconfigure Message</name> <name>Reconfigure Message</name>
<t>Servers and relay agents MUST discard any received Reconfigure <t>Servers and relay agents <bcp14>MUST</bcp14> discard any received Rec onfigure
messages.</t> messages.</t>
<t>Clients MUST discard any Reconfigure message that meets any of the <t>Clients <bcp14>MUST</bcp14> discard any Reconfigure message that meet s any of the
following conditions:</t> following conditions:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>the message was not unicast to the client.</li> <li>the message was not unicast to the client.</li>
<li>the message does not include a Server Identifier <li>the message does not include a Server Identifier
option (see <xref target="RFC3315-22.3" format="default"/>).</li> option (see <xref target="RFC3315-22.3" format="default"/>).</li>
<li>the message does not include a Client Identifier <li>the message does not include a Client Identifier
option (see <xref target="RFC3315-22.2" format="default"/>) that con tains the option (see <xref target="RFC3315-22.2" format="default"/>) that con tains the
client's DUID.</li> client's DUID.</li>
<li>the message does not include a Reconfigure Message <li>the message does not include a Reconfigure Message
option (see <xref target="RFC3315-22.19" format="default"/>).</li> option (see <xref target="RFC3315-22.19" format="default"/>).</li>
<li>the Reconfigure Message option msg-type is not a <li>the Reconfigure Message option msg-type is not a
valid value.</li> valid value.</li>
<li>the message does not include authentication (such <li>the message does not include authentication (such
as RKAP; see <xref target="reconfigure-protocol" format="default"/>) or fails as RKAP; see <xref target="reconfigure-protocol" format="default"/>) or fails
authentication validation.</li> authentication validation.</li>
</ul> </ul>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Information-request Message</name> <name>Information-request Message</name>
<t>Clients MUST discard any received Information-request messages.</t> <t>Clients <bcp14>MUST</bcp14> discard any received Information-request
<t>Servers MUST discard any received Information-request message that messages.</t>
<t>Servers <bcp14>MUST</bcp14> discard any received Information-request
message that
meets any of the following conditions:</t> meets any of the following conditions:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>the message includes a Server Identifier option <li>the message includes a Server Identifier option
(see <xref target="RFC3315-22.3" format="default"/>), and the DUID i n the option (see <xref target="RFC3315-22.3" format="default"/>), and the DUID i n the option
does not match the server's DUID.</li> does not match the server's DUID.</li>
<li>the message includes an IA option.</li> <li>the message includes an IA option.</li>
</ul> </ul>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Relay-forward Message</name> <name>Relay-forward Message</name>
<t>Clients MUST discard any received Relay-forward messages.</t> <t>Clients <bcp14>MUST</bcp14> discard any received Relay-forward messag es.</t>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Relay-reply Message</name> <name>Relay-reply Message</name>
<t>Clients and servers MUST discard any received Relay-reply <t>Clients and servers <bcp14>MUST</bcp14> discard any received Relay-re ply
messages.</t> messages.</t>
</section> </section>
</section> </section>
<section anchor="RFC3315-16" numbered="true" toc="default"> <section anchor="RFC3315-16" numbered="true" toc="default">
<name>Client Source Address and Interface Selection</name> <name>Client Source Address and Interface Selection</name>
<t>The client's behavior regarding interface selection is different, <t>The client's behavior regarding interface selection is different,
depending on the purpose of the configuration.</t> depending on the purpose of the configuration.</t>
<section anchor="if-addr-sel-addr-assignment" numbered="true" toc="default "> <section anchor="if-addr-sel-addr-assignment" numbered="true" toc="default ">
<name>Source Address and Interface Selection for Address Assignment</nam e> <name>Source Address and Interface Selection for Address Assignment</nam e>
<t>When a client sends a DHCP message to the <t>When a client sends a DHCP message to the
All_DHCP_Relay_Agents_and_Servers multicast address, it SHOULD send All_DHCP_Relay_Agents_and_Servers multicast address, it <bcp14>SHOULD</b cp14> send
the message through the interface for which configuration information the message through the interface for which configuration information
(including the addresses) is being requested. However, the client MAY (including the addresses) is being requested. However, the client <bcp14 >MAY</bcp14>
send the message through another interface if the interface for which send the message through another interface if the interface for which
configuration is being requested is a logical interface without direct configuration is being requested is a logical interface without direct
link attachment or the client is certain that two interfaces are link attachment or the client is certain that two interfaces are
attached to the same link.</t> attached to the same link.</t>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Source Address and Interface Selection for Prefix Delegation</name > <name>Source Address and Interface Selection for Prefix Delegation</name >
<t>Delegated prefixes are not associated with a particular interface <t>Delegated prefixes are not associated with a particular interface
in the same way as addresses are for address assignment as mentioned in the same way as addresses are for address assignment as mentioned
in <xref target="if-addr-sel-addr-assignment" format="default"/> above.< /t> in <xref target="if-addr-sel-addr-assignment" format="default"/> above.< /t>
<t>When a client sends a DHCP message <t>When a client sends a DHCP message
for the purpose of prefix delegation, it SHOULD be sent on the for the purpose of prefix delegation, it <bcp14>SHOULD</bcp14> be sent o n the
interface associated with the upstream router (typically, connected interface associated with the upstream router (typically, connected
to an ISP network); see <xref target="RFC7084" format="default"/>. The to an ISP network); see <xref target="RFC7084" format="default"/>. The
upstream interface is typically determined by configuration. This rule upstream interface is typically determined by configuration. This rule
applies even in the case where a separate IA_PD is used for each applies even in the case where a separate IA_PD is used for each
downstream interface.</t> downstream interface.</t>
</section> </section>
</section> </section>
<section anchor="configuration-exchange" numbered="true" toc="default"> <section anchor="configuration-exchange" numbered="true" toc="default">
<name>DHCP Configuration Exchanges</name> <name>DHCP Configuration Exchanges</name>
<t>A client initiates a message exchange with a server or servers to <t>A client initiates a message exchange with a server or servers to
acquire or update configuration information of interest. A client has acquire or update configuration information of interest. A client has
many reasons to initiate the configuration exchange. Some of the many reasons to initiate the configuration exchange. Some of the
more common ones are: more common ones are:
</t> </t>
<ol spacing="normal" type="1"><li>as part of the operating system configur ation/bootstrap process,</li> <ol spacing="normal" type="1"><li>as part of the operating system configur ation/bootstrap process,</li>
<li>when requested to do so by the application layer <li>when requested to do so by the application layer
(through an operating-system-specific API),</li> (through an operating-system-specific API),</li>
<li>when a Router Advertisement indicates that DHCPv6 is available for <li>when a Router Advertisement indicates that DHCPv6 is available for
address configuration (see Section 4.2 of address configuration (see <xref target="RFC4861" sectionFormat="of" sec
<xref target="RFC4861" format="default"/>),</li> tion="4.2"/>),</li>
<li>as required to extend the lifetime of address(es) and/or <li>as required to extend the lifetime of address(es) and/or
delegated prefix(es), using Renew and Rebind messages, or</li> delegated prefix(es), using Renew and Rebind messages, or</li>
<li>upon the receipt of a Reconfigure message, when requested to do so <li>upon the receipt of a Reconfigure message, when requested to do so
by a server.</li> by a server.</li>
</ol> </ol>
<t>The client is responsible for creating IAs and requesting that a <t>The client is responsible for creating IAs and requesting that a
server assign addresses and/or delegated prefixes to the IAs. The server assign addresses and/or delegated prefixes to the IAs. The
client first creates the IAs and assigns IAIDs to them. The client then client first creates the IAs and assigns IAIDs to them. The client then
transmits a Solicit message containing the IA options describing the transmits a Solicit message containing the IA options describing the
IAs. The client MUST NOT be using any of the addresses or delegated IAs. The client <bcp14>MUST NOT</bcp14> be using any of the addresses or d elegated
prefixes for which it tries to obtain the bindings by sending the prefixes for which it tries to obtain the bindings by sending the
Solicit message. In particular, if the client had some valid bindings Solicit message. In particular, if the client had some valid bindings
and has chosen to start the server discovery process to obtain the and has chosen to start the server discovery process to obtain the
same bindings from a different server, the client MUST stop using the same bindings from a different server, the client <bcp14>MUST</bcp14> stop using the
addresses and delegated prefixes for the bindings that it had obtained addresses and delegated prefixes for the bindings that it had obtained
from the previous server (see <xref target="RFC3315-18.1.6" format="defaul t"/> for from the previous server (see <xref target="RFC3315-18.1.6" format="defaul t"/> for
more details on what "stop using" means in this context) and that it is more details on what "stop using" means in this context) and that it is
now trying to obtain from a new server.</t> now trying to obtain from a new server.</t>
<t>A DHCP client that does not need to have a DHCP server assign <t>A DHCP client that does not need to have a DHCP server assign
IP addresses or delegated prefixes to it can obtain configuration IP addresses or delegated prefixes to it can obtain configuration
information such as a list of available DNS servers <xref target="RFC3646" format="default"/> or NTP servers <xref target="RFC5908" format="default"/> thr ough a information such as a list of available DNS servers <xref target="RFC3646" format="default"/> or NTP servers <xref target="RFC5908" format="default"/> thr ough a
single message and reply exchange with a DHCP server. single message and reply exchange with a DHCP server.
To obtain To obtain
configuration information, the client first sends an Information-request configuration information, the client first sends an Information-request
skipping to change at line 2097 skipping to change at line 2158
<t>If the server responds with an Advertise message, the client initiates <t>If the server responds with an Advertise message, the client initiates
a configuration exchange as described in a configuration exchange as described in
<xref target="request-create-transmit" format="default"/>.</t> <xref target="request-create-transmit" format="default"/>.</t>
<t>A server may initiate a message exchange with a client by sending a <t>A server may initiate a message exchange with a client by sending a
Reconfigure message to cause the client to send a Renew, Rebind, or Reconfigure message to cause the client to send a Renew, Rebind, or
Information-request message to refresh its configuration information as Information-request message to refresh its configuration information as
soon as the Reconfigure message is received by the client.</t> soon as the Reconfigure message is received by the client.</t>
<t><xref target="FigMsgFlow" format="default"/> shows a timeline diagram o f the <t><xref target="FigMsgFlow" format="default"/> shows a timeline diagram o f the
messages exchanged between a client and two servers for the messages exchanged between a client and two servers for the
typical lifecycle of one or more leases. This starts with the typical lifecycle of one or more leases. This starts with the
four-message Solicit/Advertise/Request⁠/Reply four-message Solicit/Advertise/Request/Reply
exchange to obtain the lease(s), followed by a two‑message exchange to obtain the lease(s), followed by a two-message
Renew/Reply exchange to extend the lifetime on the lease(s), and then Renew/Reply exchange to extend the lifetime on the lease(s), and then
ends with a two-message Release/Reply exchange to end the ends with a two-message Release/Reply exchange to end the
client's use of the lease(s).</t> client's use of the lease(s).</t>
<figure anchor="FigMsgFlow"> <figure anchor="FigMsgFlow">
<name>Timeline Diagram of the Messages Exchanged between a Client and Two Servers for the Typical Lifecycle of One or More Leases</name> <name>Timeline Diagram of the Messages Exchanged Between a Client and Two Servers for the Typical Lifecycle of One or More Leases</name>
<artwork align="left" name="" type="" alt=""><![CDATA[ <artwork align="left" name="" type="" alt=""><![CDATA[
Server Server Server Server
(not selected) Client (selected) (not selected) Client (selected)
v v v v v v
| | | | | |
| Begins initialization | | Begins initialization |
| | | | | |
start of | _____________/|\_____________ | start of | _____________/|\_____________ |
4-message |/ Solicit | Solicit \| 4-message |/ Solicit | Solicit \|
skipping to change at line 2160 skipping to change at line 2221
| Graceful shutdown | | Graceful shutdown |
| | | | | |
2-message | _____________/|\_____________ | 2-message | _____________/|\_____________ |
exchange |/ Release | Release \| exchange |/ Release | Release \|
| | | | | |
| | Discards lease(s) | | Discards lease(s)
| | | | | |
| | _____________/| | | _____________/|
| |/ Reply | | |/ Reply |
| | | | | |
v v v v v v]]></artwork>
]]></artwork>
</figure> </figure>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>A Single Exchange for Multiple IA Options</name> <name>A Single Exchange for Multiple IA Options</name>
<t>This document assumes that a client SHOULD use a single transaction <t>This document assumes that a client <bcp14>SHOULD</bcp14> use a singl e transaction
for all of the IA options required on an interface; this simplifies for all of the IA options required on an interface; this simplifies
the client implementation and reduces the potential number of the client implementation and reduces the potential number of
transactions required. To facilitate transactions required. To facilitate
a client's use of a single transaction for all IA options, servers a client's use of a single transaction for all IA options, servers
MUST return the same T1/T2 values for all IA options in a Reply <bcp14>MUST</bcp14> return the same T1/T2 values for all IA options in a R
(see Sections <xref target="RFC3315-18.2.1" format="counter"/>, eply
(see Sections <xref target="RFC3315-18.2.1" format="counter"/>,
<xref target="RFC3315-18.2.3" format="counter"/>, <xref target="RFC3315-18.2.3" format="counter"/>,
and <xref target="RFC3315-18.2.4" format="counter"/>) so that the and <xref target="RFC3315-18.2.4" format="counter"/>) so that the
client will client will
generate a single transaction when renewing or rebinding its leases. generate a single transaction when renewing or rebinding its leases.
However, because some servers may not yet conform to this requirement, However, because some servers may not yet conform to this requirement,
a client MUST be prepared to select appropriate T1/T2 times as a client <bcp14>MUST</bcp14> be prepared to select appropriate T1/T2 times as
described in <xref target="RFC3315-18.1.3" format="default"/>.</t> described in <xref target="RFC3315-18.1.3" format="default"/>.</t>
</section> </section>
<section anchor="Client-Behavior" numbered="true" toc="default"> <section anchor="Client-Behavior" numbered="true" toc="default">
<name>Client Behavior</name> <name>Client Behavior</name>
<t>A client uses the Solicit message to discover DHCP servers <t>A client uses the Solicit message to discover DHCP servers
configured to assign leases or return other configuration parameters configured to assign leases or return other configuration parameters
on the link to which the client is attached.</t> on the link to which the client is attached.</t>
<t>A client uses Request, Renew, Rebind, Release, and Decline messages <t>A client uses Request, Renew, Rebind, Release, and Decline messages
during the normal lifecycle of addresses and delegated prefixes. When during the normal lifecycle of addresses and delegated prefixes. When
a client detects that it may have moved to a new link, it uses a client detects that it may have moved to a new link, it uses
Confirm if it only has addresses and Rebind if it has delegated Confirm if it only has addresses and Rebind if it has delegated
prefixes (and addresses). It uses Information-request messages when it prefixes (and addresses). It uses Information-request messages when it
needs configuration information but no addresses and no prefixes.</t> needs configuration information but no addresses and no prefixes.</t>
<t>When a client requests multiple IA option types or multiple <t>When a client requests multiple IA option types or multiple
instances of the same IA types in a Solicit, Request, Renew, or instances of the same IA types in a Solicit, Request, Renew, or
Rebind, it is possible Rebind, it is possible
that the available server(s) may only be configured to offer a subset that the available server(s) may only be configured to offer a subset
of them. When possible, the client SHOULD use the best configuration of them. When possible, the client <bcp14>SHOULD</bcp14> use the best co nfiguration
available and continue to request the additional IAs in subsequent available and continue to request the additional IAs in subsequent
messages. This allows the client to maintain messages. This allows the client to maintain
a single session and state machine. In practice, especially in the a single session and state machine. In practice, especially in the
case of handling IA_NA and IA_PD requests <xref target="RFC7084" format= "default"/>, case of handling IA_NA and IA_PD requests <xref target="RFC7084" format= "default"/>,
this situation should be rare or a result of a temporary operational this situation should be rare or a result of a temporary operational
error. Thus, it is more likely that the client will get all error. Thus, it is more likely that the client will get all
configuration if it continues, in each subsequent configuration configuration if it continues, in each subsequent configuration
exchange, to request all the configuration information it is exchange, to request all the configuration information it is
programmed to try to obtain, including any stateful configuration programmed to try to obtain, including any stateful configuration
options for which no results were returned in previous message options for which no results were returned in previous message
exchanges.</t> exchanges.</t>
<t>Upon receipt of a Reconfigure message from the server, a client <t>Upon receipt of a Reconfigure message from the server, a client
responds with a Renew, Rebind, or Information-request message as responds with a Renew, Rebind, or Information-request message as
indicated by the Reconfigure Message option (see <xref target="RFC3315-2 2.19" format="default"/>). indicated by the Reconfigure Message option (see <xref target="RFC3315-2 2.19" format="default"/>).
The client SHOULD be suspicious of the Reconfigure message (they The client <bcp14>SHOULD</bcp14> be suspicious of the Reconfigure messag
may be faked), and it MUST NOT abandon any resources it might have e (they
may be faked), and it <bcp14>MUST NOT</bcp14> abandon any resources it m
ight have
already obtained. already obtained.
The client SHOULD treat the Reconfigure message as if the T1 timer The client <bcp14>SHOULD</bcp14> treat the Reconfigure message as if the T1 timer
had expired. The client will expect the server to send IAs had expired. The client will expect the server to send IAs
and/or other configuration information to the client in a Reply and/or other configuration information to the client in a Reply
message.</t> message.</t>
<section anchor="solicit-create-transmit" numbered="true" toc="default"> <section anchor="solicit-create-transmit" numbered="true" toc="default">
<name>Creation and Transmission of Solicit Messages</name> <name>Creation and Transmission of Solicit Messages</name>
<t>The client sets the "msg-type" field to SOLICIT. The client <t>The client sets the "msg-type" field to SOLICIT. The client
generates a transaction ID and inserts this value in the generates a transaction ID and inserts this value in the
"transaction-id" field.</t> "transaction-id" field.</t>
<t>The client MUST include a Client Identifier option (see <t>The client <bcp14>MUST</bcp14> include a Client Identifier option ( see
<xref target="RFC3315-22.2" format="default"/>) to identify <xref target="RFC3315-22.2" format="default"/>) to identify
itself to the server. The client includes IA options for any IAs to itself to the server. The client includes IA options for any IAs to
which it wants the server to assign leases.</t> which it wants the server to assign leases.</t>
<t>The client MUST include an Elapsed Time option (see <t>The client <bcp14>MUST</bcp14> include an Elapsed Time option (see
<xref target="RFC3315-22.9" format="default"/>) to indicate how long t he client has <xref target="RFC3315-22.9" format="default"/>) to indicate how long t he client has
been trying to complete the current DHCP message exchange.</t> been trying to complete the current DHCP message exchange.</t>
<t>The client uses IA_NA options (see <xref target="RFC3315-22.4" form at="default"/>) <t>The client uses IA_NA options (see <xref target="RFC3315-22.4" form at="default"/>)
to request the assignment of non-temporary addresses and IA_PD options (see to request the assignment of non-temporary addresses and IA_PD options (see
<xref target="IA_PD-option" format="default"/>) to request prefix dele gation. <xref target="IA_PD-option" format="default"/>) to request prefix dele gation.
IA_NA or IA_PD options, or a combination, can IA_NA or IA_PD options, or a combination, can
be included in DHCP messages. In addition, multiple instances of any be included in DHCP messages. In addition, multiple instances of any
IA option type can be included.</t> IA option type can be included.</t>
<t>The client MAY include addresses in IA Address options (see <t>The client <bcp14>MAY</bcp14> include addresses in IA Address optio ns (see
<xref target="RFC3315-22.6" format="default"/>) encapsulated <xref target="RFC3315-22.6" format="default"/>) encapsulated
within IA_NA option as hints to the server about the within IA_NA option as hints to the server about the
addresses for which the client has a preference.</t> addresses for which the client has a preference.</t>
<t>The client MAY include values in IA Prefix options (see <t>The client <bcp14>MAY</bcp14> include values in IA Prefix options ( see
<xref target="IAPREFIX-option" format="default"/>) <xref target="IAPREFIX-option" format="default"/>)
encapsulated within IA_PD options as hints for the delegated prefix encapsulated within IA_PD options as hints for the delegated prefix
and/or prefix length for which the client has a preference. See and/or prefix length for which the client has a preference. See
<xref target="RFC3315-18.1.3" format="default"/> for more on prefix-le ngth hints.</t> <xref target="RFC3315-18.1.3" format="default"/> for more on prefix-le ngth hints.</t>
<t>The client MUST include an Option Request option (ORO) (see <xref t arget="RFC3315-22.7" format="default"/>) to request the SOL_MAX_RT option (see <t>The client <bcp14>MUST</bcp14> include an Option Request option (OR O) (see <xref target="RFC3315-22.7" format="default"/>) to request the SOL_MAX_R T option (see
<xref target="SOL_MAX_RT_option" format="default"/>) and any other opt ions the <xref target="SOL_MAX_RT_option" format="default"/>) and any other opt ions the
client is interested in receiving. The client MAY additionally client is interested in receiving. The client <bcp14>MAY</bcp14> addit ionally
include instances of those options that are identified in the Option include instances of those options that are identified in the Option
Request option, with data values as hints to the server about Request option, with data values as hints to the server about
parameter values the client would like to have returned.</t> parameter values the client would like to have returned.</t>
<t>The client includes a Reconfigure Accept option (see <xref target=" RFC3315-22.20" format="default"/>) if the client is willing to accept <t>The client includes a Reconfigure Accept option (see <xref target=" RFC3315-22.20" format="default"/>) if the client is willing to accept
Reconfigure messages from the server.</t> Reconfigure messages from the server.</t>
<t>The client MUST NOT include any other options in the Solicit <t>The client <bcp14>MUST NOT</bcp14> include any other options in the Solicit
message, except as specifically allowed in the definition of message, except as specifically allowed in the definition of
individual options.</t> individual options.</t>
<t>The first Solicit message from the client on the interface SHOULD <t>The first Solicit message from the client on the interface <bcp14>S HOULD</bcp14>
be delayed by a random amount of time between 0 and SOL_MAX_DELAY. be delayed by a random amount of time between 0 and SOL_MAX_DELAY.
This random delay helps desynchronize clients that start a DHCP This random delay helps desynchronize clients that start a DHCP
session at the same time, such as after recovery from a power session at the same time, such as after recovery from a power
failure or after a router outage after seeing that DHCP is failure or after a router outage after seeing that DHCP is
available in Router Advertisement messages (see Section 4.2 of available in Router Advertisement messages (see
<xref target="RFC4861" format="default"/>).</t> <xref target="RFC4861" sectionFormat="of" section="4.2"/>).</t>
<t>The client transmits the message according to <xref target="RFC3315 -14" format="default"/>, using the following parameters: </t> <t>The client transmits the message according to <xref target="RFC3315 -14" format="default"/>, using the following parameters: </t>
<dl newline="false" spacing="normal" indent="11"> <ul spacing="normal">
<dt> IRT</dt> <li>IRT: SOL_TIMEOUT</li>
<dd>SOL_TIMEOUT</dd> <li>MRT: SOL_MAX_RT</li>
<dt> MRT</dt> <li>MRC: 0</li>
<dd>SOL_MAX_RT</dd> <li>MRD: 0</li>
<dt> MRC</dt> </ul>
<dd>0</dd>
<dt> MRD</dt>
<dd>0</dd>
</dl>
<t>A client that wishes to use the Rapid Commit two-message exchange <t>A client that wishes to use the Rapid Commit two-message exchange
includes a Rapid Commit option (see <xref target="RFC3315-22.14" for mat="default"/>) includes a Rapid Commit option (see <xref target="RFC3315-22.14" for mat="default"/>)
in its Solicit message. in its Solicit message.
The client may receive a number of different replies from The client may receive a number of different replies from
different servers. The client will make note of any valid Advertise different servers. The client will make note of any valid Advertise
messages that it receives. The client will discard any Reply messages that it receives. The client will discard any Reply
messages that do not contain the Rapid Commit option. messages that do not contain the Rapid Commit option.
</t> </t>
<t>Upon receipt of a valid Reply with the Rapid Commit option, <t>Upon receipt of a valid Reply with the Rapid Commit option,
the client processes the message as described in the client processes the message as described in
skipping to change at line 2303 skipping to change at line 2359
messages received in response to the Request message</li> messages received in response to the Request message</li>
<li>processes any Reply messages received in <li>processes any Reply messages received in
response to the Request message and discards the Reply message response to the Request message and discards the Reply message
that includes the Rapid Commit option</li> that includes the Rapid Commit option</li>
</ul> </ul>
<t>If the client is waiting for an Advertise message, the mechanism <t>If the client is waiting for an Advertise message, the mechanism
described in <xref target="RFC3315-14" format="default"/> is modified as follows for described in <xref target="RFC3315-14" format="default"/> is modified as follows for
use in the transmission of Solicit messages. The message exchange is use in the transmission of Solicit messages. The message exchange is
not terminated by the receipt of an Advertise before the first RT has not terminated by the receipt of an Advertise before the first RT has
elapsed. Rather, the client collects valid Advertise messages until elapsed. Rather, the client collects valid Advertise messages until
the first RT has elapsed. Also, the first RT MUST be selected to be the first RT has elapsed. Also, the first RT <bcp14>MUST</bcp14> be se lected to be
strictly greater than IRT by choosing RAND to be strictly greater strictly greater than IRT by choosing RAND to be strictly greater
than 0.</t> than 0.</t>
<t>A client MUST collect valid Advertise messages for the first <t>A client <bcp14>MUST</bcp14> collect valid Advertise messages for t
RT seconds, unless it receives a valid Advertise message with a prefer he first
ence RT seconds, unless it receives a valid Advertise message with a prefer
ence
value of 255. The preference value is carried in the Preference value of 255. The preference value is carried in the Preference
option (see <xref target="RFC3315-22.8" format="default"/>). Any valid Advertise that option (see <xref target="RFC3315-22.8" format="default"/>). Any valid Advertise that
does not include a Preference option is considered to have a does not include a Preference option is considered to have a
preference value of 0. If the client receives a valid Advertise messag e preference value of 0. If the client receives a valid Advertise messag e
that includes a Preference option with a preference value of 255, that includes a Preference option with a preference value of 255,
the client immediately begins a client-initiated message exchange the client immediately begins a client-initiated message exchange
(as described in <xref target="request-create-transmit" format="defaul t"/>) by (as described in <xref target="request-create-transmit" format="defaul t"/>) by
sending a Request message to the server from which the Advertise sending a Request message to the server from which the Advertise
message was received. If the client receives a valid Advertise message message was received. If the client receives a valid Advertise message
that does not include a Preference option with a preference value of that does not include a Preference option with a preference value of
255, the client continues to wait until the first RT elapses. If the 255, the client continues to wait until the first RT elapses. If the
first RT elapses and the client has received a valid Advertise message , first RT elapses and the client has received a valid Advertise message ,
the client SHOULD continue with a client-initiated message exchange the client <bcp14>SHOULD</bcp14> continue with a client-initiated mess age exchange
by sending a Request message.</t> by sending a Request message.</t>
<t>If the client does not receive any valid Advertise messages before the <t>If the client does not receive any valid Advertise messages before the
first RT has elapsed, it then applies the retransmission mechanism first RT has elapsed, it then applies the retransmission mechanism
described in <xref target="RFC3315-14" format="default"/>. The client described in <xref target="RFC3315-14" format="default"/>. The client
terminates the retransmission process as soon as it receives any terminates the retransmission process as soon as it receives any
valid Advertise message, and the client acts on the received Advertise valid Advertise message, and the client acts on the received Advertise
message without waiting for any additional Advertise messages.</t> message without waiting for any additional Advertise messages.</t>
<t>A DHCP client SHOULD choose MRC and MRD values of 0. If the DHCP <t>A DHCP client <bcp14>SHOULD</bcp14> choose MRC and MRD values of 0. If the DHCP
client is configured with either MRC or MRD set to a value other client is configured with either MRC or MRD set to a value other
than 0, it MUST stop trying to configure the interface if the than 0, it <bcp14>MUST</bcp14> stop trying to configure the interface if the
message exchange fails. After the DHCP client stops trying to message exchange fails. After the DHCP client stops trying to
configure the interface, it SHOULD restart the reconfiguration configure the interface, it <bcp14>SHOULD</bcp14> restart the reconfig uration
process after some external event, such as user input, system process after some external event, such as user input, system
restart, or when the client is attached to a new link.</t> restart, or when the client is attached to a new link.</t>
</section> </section>
<section anchor="request-create-transmit" numbered="true" toc="default"> <section anchor="request-create-transmit" numbered="true" toc="default">
<name>Creation and Transmission of Request Messages</name> <name>Creation and Transmission of Request Messages</name>
<t>The client uses a Request message to populate IAs with leases and <t>The client uses a Request message to populate IAs with leases and
obtain other configuration information. The client includes one or obtain other configuration information. The client includes one or
more IA options in the Request message. The server then returns more IA options in the Request message. The server then returns
leases and other information about the IAs to the client in IA leases and other information about the IAs to the client in IA
options in a Reply message.</t> options in a Reply message.</t>
<t>The client sets the "msg-type" field to REQUEST. <t>The client sets the "msg-type" field to REQUEST.
The client generates a transaction ID and inserts this value in The client generates a transaction ID and inserts this value in
the "transaction-id" field.</t> the "transaction-id" field.</t>
<t>The client MUST include the identifier of the destination server in a <t>The client <bcp14>MUST</bcp14> include the identifier of the destin ation server in a
Server Identifier option (see <xref target="RFC3315-22.3" format="defa ult"/>).</t> Server Identifier option (see <xref target="RFC3315-22.3" format="defa ult"/>).</t>
<t>The client MUST include a Client Identifier option (see <t>The client <bcp14>MUST</bcp14> include a Client Identifier option ( see
<xref target="RFC3315-22.2" format="default"/>) to identify <xref target="RFC3315-22.2" format="default"/>) to identify
itself to the server. The client adds any other appropriate options, itself to the server. The client adds any other appropriate options,
including one or more IA options.</t> including one or more IA options.</t>
<t>The client MUST include an Elapsed Time option (see <t>The client <bcp14>MUST</bcp14> include an Elapsed Time option (see
<xref target="RFC3315-22.9" format="default"/>) to indicate how long t he client has <xref target="RFC3315-22.9" format="default"/>) to indicate how long t he client has
been trying to complete the current DHCP message exchange.</t> been trying to complete the current DHCP message exchange.</t>
<t>The client MUST include an Option Request option (see <xref target= "RFC3315-22.7" format="default"/>) to request the SOL_MAX_RT option (see <t>The client <bcp14>MUST</bcp14> include an Option Request option (se e <xref target="RFC3315-22.7" format="default"/>) to request the SOL_MAX_RT opti on (see
<xref target="SOL_MAX_RT_option" format="default"/>) and any other opt ions the <xref target="SOL_MAX_RT_option" format="default"/>) and any other opt ions the
client is interested in receiving. The client MAY additionally client is interested in receiving. The client <bcp14>MAY</bcp14> addit ionally
include instances of those options that are identified in the Option include instances of those options that are identified in the Option
Request option, with data values as hints to the server about Request option, with data values as hints to the server about
parameter values the client would like to have returned.</t> parameter values the client would like to have returned.</t>
<t>The client includes a Reconfigure Accept option (see <xref target=" RFC3315-22.20" format="default"/>) if the client is willing to <t>The client includes a Reconfigure Accept option (see <xref target=" RFC3315-22.20" format="default"/>) if the client is willing to
accept Reconfigure messages from the server.</t> accept Reconfigure messages from the server.</t>
<t>The client transmits the message according to <xref target="RFC3315 -14" format="default"/>, using the following parameters: </t> <t>The client transmits the message according to <xref target="RFC3315 -14" format="default"/>, using the following parameters: </t>
<dl newline="false" spacing="normal" indent="11"> <ul spacing="normal">
<dt> IRT</dt> <li>IRT: REQ_TIMEOUT</li>
<dd>REQ_TIMEOUT</dd> <li>MRT: REQ_MAX_RT</li>
<dt> MRT</dt> <li>MRC: REQ_MAX_RC</li>
<dd>REQ_MAX_RT</dd> <li>MRD: 0</li>
<dt> MRC</dt> </ul>
<dd>REQ_MAX_RC</dd>
<dt> MRD</dt>
<dd>0</dd>
</dl>
<t>If the message exchange fails, the client takes an action based <t>If the message exchange fails, the client takes an action based
on the client's local policy. Examples of actions the client might on the client's local policy. Examples of actions the client might
take include the following:</t> take include the following:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>Select another server from a list of servers <li>Select another server from a list of servers
known to the client -- for example, servers that responded with known to the client -- for example, servers that responded with
an Advertise message.</li> an Advertise message.</li>
<li>Initiate the server discovery process described <li>Initiate the server discovery process described
in <xref target="configuration-exchange" format="default"/>.</li> in <xref target="configuration-exchange" format="default"/>.</li>
<li>Terminate the configuration process and report <li>Terminate the configuration process and report
skipping to change at line 2396 skipping to change at line 2448
</section> </section>
<section anchor="RFC3315-18.1.2" numbered="true" toc="default"> <section anchor="RFC3315-18.1.2" numbered="true" toc="default">
<name>Creation and Transmission of Confirm Messages</name> <name>Creation and Transmission of Confirm Messages</name>
<t>The client uses a Confirm message when it has only addresses <t>The client uses a Confirm message when it has only addresses
(no delegated prefixes) assigned by a DHCP server to determine if it (no delegated prefixes) assigned by a DHCP server to determine if it
is still connected to the same link when the client detects a is still connected to the same link when the client detects a
change in network information as described in <xref target="RFC3315-18 .2.12" format="default"/>.</t> change in network information as described in <xref target="RFC3315-18 .2.12" format="default"/>.</t>
<t>The client sets the "msg-type" field to CONFIRM. The client <t>The client sets the "msg-type" field to CONFIRM. The client
generates a transaction ID and inserts this value in the generates a transaction ID and inserts this value in the
"transaction-id" field.</t> "transaction-id" field.</t>
<t>The client MUST include a Client Identifier option (see <t>The client <bcp14>MUST</bcp14> include a Client Identifier option ( see
<xref target="RFC3315-22.2" format="default"/>) to identify itself to the server.</t> <xref target="RFC3315-22.2" format="default"/>) to identify itself to the server.</t>
<t>The client MUST include an Elapsed Time option (see <t>The client <bcp14>MUST</bcp14> include an Elapsed Time option (see
<xref target="RFC3315-22.9" format="default"/>) to indicate how long t he client has <xref target="RFC3315-22.9" format="default"/>) to indicate how long t he client has
been trying to complete the current DHCP message exchange.</t> been trying to complete the current DHCP message exchange.</t>
<t>The client includes IA options for all of the <t>The client includes IA options for all of the
IAs assigned to the interface for which the Confirm message is being IAs assigned to the interface for which the Confirm message is being
sent. The IA options include all of the addresses the client sent. The IA options include all of the addresses the client
currently has associated with those IAs. The client SHOULD set the currently has associated with those IAs. The client <bcp14>SHOULD</bcp 14> set the
T1 and T2 fields in any IA_NA options (see T1 and T2 fields in any IA_NA options (see
<xref target="RFC3315-22.4" format="default"/>) and the preferred‑life time and <xref target="RFC3315-22.4" format="default"/>) and the preferred-life time and
valid-lifetime fields in the IA Address options (see valid-lifetime fields in the IA Address options (see
<xref target="RFC3315-22.6" format="default"/>) to 0, as the server <xref target="RFC3315-22.6" format="default"/>) to 0, as the server
will ignore these fields.</t> will ignore these fields.</t>
<t>The first Confirm message from the client on the interface MUST <t>The first Confirm message from the client on the interface <bcp14>M UST</bcp14>
be delayed by a random amount of time between 0 and CNF_MAX_DELAY. be delayed by a random amount of time between 0 and CNF_MAX_DELAY.
The client transmits the message according to <xref target="RFC3315-14 " format="default"/>, using the following parameters: </t> The client transmits the message according to <xref target="RFC3315-14 " format="default"/>, using the following parameters: </t>
<dl newline="false" spacing="normal" indent="11"> <ul spacing="normal">
<dt> IRT</dt> <li>IRT: CNF_TIMEOUT</li>
<dd>CNF_TIMEOUT</dd> <li>MRT: CNF_MAX_RT</li>
<dt> MRT</dt> <li>MRC: 0</li>
<dd>CNF_MAX_RT</dd> <li>MRD: CNF_MAX_RD</li>
<dt> MRC</dt> </ul>
<dd>0</dd>
<dt> MRD</dt>
<dd>CNF_MAX_RD</dd>
</dl>
<t>If the client receives no responses before the message <t>If the client receives no responses before the message
transmission process terminates, as described in <xref target="RFC3315 -14" format="default"/>, the client SHOULD continue to use any transmission process terminates, as described in <xref target="RFC3315 -14" format="default"/>, the client <bcp14>SHOULD</bcp14> continue to use any
leases, using the last known lifetimes for those leases, leases, using the last known lifetimes for those leases,
and SHOULD continue to use any other previously obtained and <bcp14>SHOULD</bcp14> continue to use any other previously obtaine d
configuration parameters.</t> configuration parameters.</t>
</section> </section>
<section anchor="RFC3315-18.1.3" numbered="true" toc="default"> <section anchor="RFC3315-18.1.3" numbered="true" toc="default">
<name>Creation and Transmission of Renew Messages</name> <name>Creation and Transmission of Renew Messages</name>
<t>To extend the preferred and valid lifetimes for the leases <t>To extend the preferred and valid lifetimes for the leases
assigned to the IAs and obtain new addresses or delegated prefixes assigned to the IAs and obtain new addresses or delegated prefixes
for IAs, the client sends a Renew message to the server from which for IAs, the client sends a Renew message to the server from which
the leases were obtained; the Renew message includes IA options for the leases were obtained; the Renew message includes IA options for
the IAs whose lease lifetimes are to be extended. The client the IAs whose lease lifetimes are to be extended. The client
includes IA Address options (see <xref target="RFC3315-22.6" format="d efault"/>) includes IA Address options (see <xref target="RFC3315-22.6" format="d efault"/>)
within IA_NA (see <xref target="RFC3315-22.4" format="default"/>) opti ons for the addresses within IA_NA (see <xref target="RFC3315-22.4" format="default"/>) opti ons for the addresses
assigned to the IAs. The client includes IA Prefix options assigned to the IAs. The client includes IA Prefix options
(see <xref target="IAPREFIX-option" format="default"/>) within IA_PD o ptions (see <xref target="IAPREFIX-option" format="default"/>) within IA_PD o ptions
(see <xref target="IA_PD-option" format="default"/>) for the delegated prefixes (see <xref target="IA_PD-option" format="default"/>) for the delegated prefixes
assigned to the IAs.</t> assigned to the IAs.</t>
<t>The server controls the time at which the client should contact the <t>The server controls the time at which the client should contact the
server to extend the lifetimes on assigned leases through the T1 and server to extend the lifetimes on assigned leases through the T1 and
T2 values assigned to an IA. However, as the client SHOULD T2 values assigned to an IA. However, as the client <bcp14>SHOULD</bcp
renew⁠/rebind all IAs from the server at the same time, the client 14>
MUST select T1 and T2 times from all IA options that will renew/rebind all IAs from the server at the same time, the client
<bcp14>MUST</bcp14> select T1 and T2 times from all IA options that wi
ll
guarantee that the client initiates transmissions of Renew/Rebind guarantee that the client initiates transmissions of Renew/Rebind
messages not later than at the T1/T2 times associated with any of messages not later than at the T1/T2 times associated with any of
the client's bindings (earliest T1/T2).</t> the client's bindings (earliest T1/T2).</t>
<t>At time T1, the client initiates a Renew/Reply message exchange <t>At time T1, the client initiates a Renew/Reply message exchange
to extend the lifetimes on any leases in the IA.</t> to extend the lifetimes on any leases in the IA.</t>
<t>A client MUST also initiate a Renew/Reply message exchange before <t>A client <bcp14>MUST</bcp14> also initiate a Renew/Reply message ex change before
time T1 if the client's link-local address used in previous time T1 if the client's link-local address used in previous
interactions with the server is no longer valid and it is willing interactions with the server is no longer valid and it is willing
to receive Reconfigure messages. This updates the server's information to receive Reconfigure messages. This updates the server's information
so it is able to continue to communicate with the client (either so it is able to continue to communicate with the client (either
directly or via Relay-reply's).</t> directly or via Relay-reply messages).</t>
<t>If T1 or T2 had been set to 0 by the server (for an IA_NA or <t>If T1 or T2 had been set to 0 by the server (for an IA_NA or
IA_PD) in a previous IA_PD) in a previous
Reply, the client may, at its discretion, send a Renew or Rebind Reply, the client may, at its discretion, send a Renew or Rebind
message, respectively. The client MUST follow the rules defined message, respectively. The client <bcp14>MUST</bcp14> follow the rules defined
in <xref target="t1-t2-0" format="default"/>.</t> in <xref target="t1-t2-0" format="default"/>.</t>
<t>The client sets the "msg-type" field to RENEW. The client <t>The client sets the "msg-type" field to RENEW. The client
generates a transaction ID and inserts this value in the generates a transaction ID and inserts this value in the
"transaction-id" field.</t> "transaction-id" field.</t>
<t>The client MUST include a Server Identifier option <t>The client <bcp14>MUST</bcp14> include a Server Identifier option
(see <xref target="RFC3315-22.3" format="default"/>) in the Renew (see <xref target="RFC3315-22.3" format="default"/>) in the Renew
message, identifying the server with which the client most recently message, identifying the server with which the client most recently
communicated.</t> communicated.</t>
<t>The client MUST include a Client Identifier option <t>The client <bcp14>MUST</bcp14> include a Client Identifier option
(see <xref target="RFC3315-22.2" format="default"/>) to identify (see <xref target="RFC3315-22.2" format="default"/>) to identify
itself to the server. The client adds any appropriate options, itself to the server. The client adds any appropriate options,
including one or more IA options.</t> including one or more IA options.</t>
<t>The client MUST include an Elapsed Time option (see <t>The client <bcp14>MUST</bcp14> include an Elapsed Time option (see
<xref target="RFC3315-22.9" format="default"/>) to indicate how long t he client has <xref target="RFC3315-22.9" format="default"/>) to indicate how long t he client has
been trying to complete the current DHCP message exchange.</t> been trying to complete the current DHCP message exchange.</t>
<t>For IAs to which leases have been assigned, the client includes a <t>For IAs to which leases have been assigned, the client includes a
corresponding IA option containing an IA Address option for each corresponding IA option containing an IA Address option for each
address assigned to the IA and an IA Prefix option for each prefix address assigned to the IA and an IA Prefix option for each prefix
assigned to the IA. The client MUST NOT include addresses and assigned to the IA. The client <bcp14>MUST NOT</bcp14> include address es and
prefixes in any IA option that the client did not obtain from the prefixes in any IA option that the client did not obtain from the
server or that are no longer valid (that have a valid lifetime of server or that are no longer valid (that have a valid lifetime of
0).</t> 0).</t>
<t>The client MAY include an IA option for each binding it desires <t>The client <bcp14>MAY</bcp14> include an IA option for each binding it desires
but has been unable to obtain. In this case, if the client includes but has been unable to obtain. In this case, if the client includes
the IA_PD option to request prefix delegation, the client MAY the IA_PD option to request prefix delegation, the client <bcp14>MAY</ bcp14>
include the IA Prefix option encapsulated within the IA_PD option, include the IA Prefix option encapsulated within the IA_PD option,
with the "IPv6‑prefix" field set to 0 and the "prefix-length" with the "IPv6-prefix" field set to 0 and the "prefix-length"
field set to the desired length of the prefix to be delegated. The field set to the desired length of the prefix to be delegated. The
server MAY use this value as a hint for the prefix length. The client server <bcp14>MAY</bcp14> use this value as a hint for the prefix leng
SHOULD NOT include an IA Prefix option with the th. The client
"IPv6‑prefix" field set to 0 unless it is supplying a hint for <bcp14>SHOULD NOT</bcp14> include an IA Prefix option with the
"IPv6-prefix" field set to 0 unless it is supplying a hint for
the prefix length.</t> the prefix length.</t>
<t>The client includes an Option Request option <t>The client includes an Option Request option
(see <xref target="RFC3315-22.7" format="default"/>) to request the SO L_MAX_RT (see <xref target="RFC3315-22.7" format="default"/>) to request the SO L_MAX_RT
option (see <xref target="SOL_MAX_RT_option" format="default"/>) and a ny other option (see <xref target="SOL_MAX_RT_option" format="default"/>) and a ny other
options the client is interested in receiving. The client MAY options the client is interested in receiving. The client <bcp14>MAY</ bcp14>
include options with data values as hints to the server about include options with data values as hints to the server about
parameter values the client would like to have returned.</t> parameter values the client would like to have returned.</t>
<t>The client transmits the message according to <xref target="RFC3315 -14" format="default"/>, using the following parameters: </t> <t>The client transmits the message according to <xref target="RFC3315 -14" format="default"/>, using the following parameters: </t>
<dl newline="false" spacing="normal" indent="11"> <ul spacing="normal">
<dt> IRT</dt> <li>IRT: REN_TIMEOUT</li>
<dd>REN_TIMEOUT</dd> <li>MRT: REN_MAX_RT</li>
<dt> MRT</dt> <li>MRC: 0</li>
<dd>REN_MAX_RT</dd> <li>MRD: Remaining time until earliest T2</li>
<dt> MRC</dt> </ul>
<dd>0</dd>
<dt> MRD</dt>
<dd>Remaining time until earliest T2</dd>
</dl>
<t>The message exchange is terminated when the earliest time T2 is <t>The message exchange is terminated when the earliest time T2 is
reached. While the client is responding to a Reconfigure, the client reached. While the client is responding to a Reconfigure, the client
ignores and discards any additional Reconfigure messages it may ignores and discards any additional Reconfigure messages it may
receive.</t> receive.</t>
<t>The message exchange is terminated when the earliest <t>The message exchange is terminated when the earliest
time T2 is reached, at which point the client begins the Rebind time T2 is reached, at which point the client begins the Rebind
message exchange (see <xref target="RFC3315-18.1.4" format="default"/> ).</t> message exchange (see <xref target="RFC3315-18.1.4" format="default"/> ).</t>
</section> </section>
<section anchor="RFC3315-18.1.4" numbered="true" toc="default"> <section anchor="RFC3315-18.1.4" numbered="true" toc="default">
<name>Creation and Transmission of Rebind Messages</name> <name>Creation and Transmission of Rebind Messages</name>
skipping to change at line 2537 skipping to change at line 2581
<xref target="RFC3315-18.1.2" format="default"/>.</t> <xref target="RFC3315-18.1.2" format="default"/>.</t>
<t>The client constructs the Rebind message as described in <xref targ et="RFC3315-18.1.3" format="default"/>, with the following differences:</t> <t>The client constructs the Rebind message as described in <xref targ et="RFC3315-18.1.3" format="default"/>, with the following differences:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>The client sets the "msg-type" field to <li>The client sets the "msg-type" field to
REBIND.</li> REBIND.</li>
<li>The client does not include the Server <li>The client does not include the Server
Identifier option (see <xref target="RFC3315-22.3" format="default "/>) in Identifier option (see <xref target="RFC3315-22.3" format="default "/>) in
the Rebind message.</li> the Rebind message.</li>
</ul> </ul>
<t>The client transmits the message according to <xref target="RFC3315 -14" format="default"/>, using the following parameters: </t> <t>The client transmits the message according to <xref target="RFC3315 -14" format="default"/>, using the following parameters: </t>
<dl newline="false" spacing="normal" indent="11"> <ul spacing="normal">
<dt> IRT</dt> <li>IRT: REB_TIMEOUT</li>
<dd>REB_TIMEOUT</dd> <li>MRT: REB_MAX_RT</li>
<dt> MRT</dt> <li>MRC: 0</li>
<dd>REB_MAX_RT</dd> <li>MRD: Remaining time until valid lifetimes of all
<dt> MRC</dt> leases in all IAs have expired</li>
<dd>0</dd> </ul>
<dt> MRD</dt>
<dd>Remaining time until valid lifetimes of all
leases in all IAs have expired</dd>
</dl>
<t>If all leases for an IA have expired, the client may choose to <t>If all leases for an IA have expired, the client may choose to
include this IA in subsequent Rebind messages to indicate that the include this IA in subsequent Rebind messages to indicate that the
client is interested in assignment of the leases to this IA.</t> client is interested in assignment of the leases to this IA.</t>
<t>The message exchange is terminated when the valid lifetimes of <t>The message exchange is terminated when the valid lifetimes of
all leases across all IAs have expired, at which time the client all leases across all IAs have expired, at which time the client
uses the Solicit message to locate a new DHCP server and sends a uses the Solicit message to locate a new DHCP server and sends a
Request for the expired IAs to the new server. If the terminated Request for the expired IAs to the new server. If the terminated
Rebind exchange was initiated as a result of receiving a Reconfigure Rebind exchange was initiated as a result of receiving a Reconfigure
message, the client terminates the reconfigure process and resumes message, the client terminates the reconfigure process and resumes
as if the Reconfigure message had not been received.</t> as if the Reconfigure message had not been received.</t>
</section> </section>
<section anchor="RFC3315-18.1.5" numbered="true" toc="default"> <section anchor="RFC3315-18.1.5" numbered="true" toc="default">
<name>Creation and Transmission of Information-request Messages</name> <name>Creation and Transmission of Information-request Messages</name>
<t>The client uses an Information-request message to obtain <t>The client uses an Information-request message to obtain
configuration information without requesting addresses and/or delegate d configuration information without requesting addresses and/or delegate d
prefixes to be assigned.</t> prefixes to be assigned.</t>
<t>The client sets the "msg-type" field to INFORMATION-REQUEST. The <t>The client sets the "msg-type" field to INFORMATION-REQUEST. The
client generates a transaction ID and inserts this value in the client generates a transaction ID and inserts this value in the
"transaction-id" field.</t> "transaction-id" field.</t>
<t>The client SHOULD include a Client Identifier option <t>The client <bcp14>SHOULD</bcp14> include a Client Identifier option
(see <xref target="RFC3315-22.2" format="default"/>) to identify (see <xref target="RFC3315-22.2" format="default"/>) to identify
itself to the server (however, see itself to the server (however, see
Section 4.3.1 of <xref target="RFC7844" format="default"/> for <xref target="RFC7844" format="default" section="4.3.1"/> for
reasons why a client may not want to include this option). If the reasons why a client may not want to include this option). If the
client does not include a Client client does not include a Client
Identifier option, the server will not be able to return any Identifier option, the server will not be able to return any
client‑specific options to the client, or the server may client-specific options to the client, or the server may
choose not to respond to the message at all.</t> choose not to respond to the message at all.</t>
<t>The client MUST include an Elapsed Time option (see <t>The client <bcp14>MUST</bcp14> include an Elapsed Time option (see
<xref target="RFC3315-22.9" format="default"/>) to indicate how long t he client has <xref target="RFC3315-22.9" format="default"/>) to indicate how long t he client has
been trying to complete the current DHCP message exchange.</t> been trying to complete the current DHCP message exchange.</t>
<t>The client MUST include an Option Request option (see <xref target= "RFC3315-22.7" format="default"/>) to request the INF_MAX_RT option (see <t>The client <bcp14>MUST</bcp14> include an Option Request option (se e <xref target="RFC3315-22.7" format="default"/>) to request the INF_MAX_RT opti on (see
<xref target="INF_MAX_RT_option" format="default"/>), the Information <xref target="INF_MAX_RT_option" format="default"/>), the Information
Refresh Time option (see <xref target="RFC4242-Option" format="default "/>), and any other options the Refresh Time option (see <xref target="RFC4242-Option" format="default "/>), and any other options the
client is interested in receiving. The client MAY include options client is interested in receiving. The client <bcp14>MAY</bcp14> inclu de options
with data values as hints to the server about parameter values the with data values as hints to the server about parameter values the
client would like to have returned.</t> client would like to have returned.</t>
<t>When responding to a Reconfigure, the client MUST include a Server <t>When responding to a Reconfigure, the client <bcp14>MUST</bcp14> in clude a Server
Identifier option (see <xref target="RFC3315-22.3" format="default"/>) with the Identifier option (see <xref target="RFC3315-22.3" format="default"/>) with the
identifier from the Reconfigure message to which the client is respond ing.</t> identifier from the Reconfigure message to which the client is respond ing.</t>
<t>The first Information-request message from the client on the <t>The first Information-request message from the client on the
interface MUST be delayed by a random amount of time between 0 and interface <bcp14>MUST</bcp14> be delayed by a random amount of time be tween 0 and
INF_MAX_DELAY. The client transmits the message according to <xref tar get="RFC3315-14" format="default"/>, using the following parameters: </t> INF_MAX_DELAY. The client transmits the message according to <xref tar get="RFC3315-14" format="default"/>, using the following parameters: </t>
<dl newline="false" spacing="normal" indent="11"> <ul spacing="normal">
<dt> IRT</dt> <li>IRT: INF_TIMEOUT</li>
<dd>INF_TIMEOUT</dd> <li>MRT: INF_MAX_RT</li>
<dt> MRT</dt> <li>MRC: 0</li>
<dd>INF_MAX_RT</dd> <li>MRD: 0</li>
<dt> MRC</dt> </ul>
<dd>0</dd>
<dt> MRD</dt>
<dd>0</dd>
</dl>
</section> </section>
<section anchor="RFC3315-18.1.6" numbered="true" toc="default"> <section anchor="RFC3315-18.1.6" numbered="true" toc="default">
<name>Creation and Transmission of Release Messages</name> <name>Creation and Transmission of Release Messages</name>
<t>To release one or more leases, a client sends a Release message <t>To release one or more leases, a client sends a Release message
to the server.</t> to the server.</t>
<t>The client sets the "msg-type" field to RELEASE. The client <t>The client sets the "msg-type" field to RELEASE. The client
generates a transaction ID and places this value in the generates a transaction ID and places this value in the
"transaction‑id" field.</t> "transaction-id" field.</t>
<t>The client MUST include a Server Identifier option <t>The client <bcp14>MUST</bcp14> include a Server Identifier option
(see <xref target="RFC3315-22.3" format="default"/>) in the Renew (see <xref target="RFC3315-22.3" format="default"/>) in the Renew
message, identifying the server which allocated the lease(s).</t> message, identifying the server that allocated the lease(s).</t>
<t>The client MUST include a Client Identifier option <t>The client <bcp14>MUST</bcp14> include a Client Identifier option
(see <xref target="RFC3315-22.2" format="default"/>) to identify (see <xref target="RFC3315-22.2" format="default"/>) to identify
itself to the server.</t> itself to the server.</t>
<t>The client MUST include an Elapsed Time option (see <t>The client <bcp14>MUST</bcp14> include an Elapsed Time option (see
<xref target="RFC3315-22.9" format="default"/>) to indicate how long t he client has <xref target="RFC3315-22.9" format="default"/>) to indicate how long t he client has
been trying to complete the current DHCP message exchange.</t> been trying to complete the current DHCP message exchange.</t>
<t>The client includes options containing the IAs <t>The client includes options containing the IAs
for the leases it is releasing in the "options" field. The leases to for the leases it is releasing in the "options" field. The leases to
be released MUST be included in the IAs. Any leases for the IAs the be released <bcp14>MUST</bcp14> be included in the IAs. Any leases for
client wishes to continue to use MUST NOT be added to the IAs.</t> the IAs the
<t>The client MUST stop using all of the leases being released client wishes to continue to use <bcp14>MUST NOT</bcp14> be added to t
he IAs.</t>
<t>The client <bcp14>MUST</bcp14> stop using all of the leases being r
eleased
before the client begins the Release message exchange process. For before the client begins the Release message exchange process. For
an address, this means the address MUST have been removed from the an address, this means the address <bcp14>MUST</bcp14> have been remov
interface. For a delegated prefix, this means the prefix MUST have ed from the
interface. For a delegated prefix, this means the prefix <bcp14>MUST</
bcp14> have
been advertised with a Preferred Lifetime and a Valid Lifetime of 0 been advertised with a Preferred Lifetime and a Valid Lifetime of 0
in a Router Advertisement message as described in part (e) of in a Router Advertisement message as described in part (e) of
Section 5.5.3 of <xref target="RFC4862" format="default"/>; also see <xref target="RFC4862" section="5.5.3"/>; also see
requirement L-13 in Section 4.3 of <xref target="RFC7084" format="defa requirement L-13 in <xref target="RFC7084" section="4.3"/>.</t>
ult"/>.</t> <t>The client <bcp14>MUST NOT</bcp14> use any of the addresses it is r
<t>The client MUST NOT use any of the addresses it is releasing as eleasing as
the source address in the Release message or in any subsequently the source address in the Release message or in any subsequently
transmitted message.</t> transmitted message.</t>
<t>Because Release messages may be lost, the client should <t>Because Release messages may be lost, the client should
retransmit the Release if no Reply is received. However, there are retransmit the Release if no Reply is received. However, there are
scenarios where the client may not wish to wait for the normal scenarios where the client may not wish to wait for the normal
retransmission timeout before giving up (e.g., on power down). retransmission timeout before giving up (e.g., on power down).
Implementations SHOULD retransmit one or more times but MAY choose Implementations <bcp14>SHOULD</bcp14> retransmit one or more times but <bcp14>MAY</bcp14> choose
to terminate the retransmission procedure early.</t> to terminate the retransmission procedure early.</t>
<t>The client transmits the message according to <xref target="RFC3315 -14" format="default"/>, using the following parameters: </t> <t>The client transmits the message according to <xref target="RFC3315 -14" format="default"/>, using the following parameters: </t>
<dl newline="false" spacing="normal" indent="11"> <ul spacing="normal">
<dt> IRT</dt> <li>IRT: REL_TIMEOUT</li>
<dd>REL_TIMEOUT</dd> <li>MRT: 0</li>
<dt> MRT</dt> <li>MRC: REL_MAX_RC</li>
<dd>0</dd> <li>MRD: 0</li>
<dt> MRC</dt> </ul>
<dd>REL_MAX_RC</dd>
<dt> MRD</dt>
<dd>0</dd>
</dl>
<t>If leases are released but the Reply from a DHCP server is lost, <t>If leases are released but the Reply from a DHCP server is lost,
the client will retransmit the Release message, and the server may the client will retransmit the Release message, and the server may
respond with a Reply indicating a status of NoBinding. Therefore, respond with a Reply indicating a status of NoBinding. Therefore,
the client does not treat a Reply message with a status of NoBinding the client does not treat a Reply message with a status of NoBinding
in a Release message exchange as if it indicates an error.</t> in a Release message exchange as if it indicates an error.</t>
<t>Note that if the client fails to release the lease, each lease <t>Note that if the client fails to release the lease, each lease
assigned to the IA will be reclaimed by the server when the valid assigned to the IA will be reclaimed by the server when the valid
lifetime of that lease expires.</t> lifetime of that lease expires.</t>
</section> </section>
<section anchor="RFC3315-18.1.7" numbered="true" toc="default"> <section anchor="RFC3315-18.1.7" numbered="true" toc="default">
<name>Creation and Transmission of Decline Messages</name> <name>Creation and Transmission of Decline Messages</name>
<t>If a client detects that one or more addresses assigned to it by <t>If a client detects that one or more addresses assigned to it by
a server are already in use by another node, the client sends a a server are already in use by another node, the client sends a
Decline message to the server to inform it that the address is Decline message to the server to inform it that the address is
suspect.</t> suspect.</t>
<t>The Decline message is not used in prefix delegation; thus, the <t>The Decline message is not used in prefix delegation; thus, the
client MUST NOT include IA_PD options client <bcp14>MUST NOT</bcp14> include IA_PD options
(see <xref target="IA_PD-option" format="default"/>) in the Decline me ssage.</t> (see <xref target="IA_PD-option" format="default"/>) in the Decline me ssage.</t>
<t>The client sets the "msg-type" field to DECLINE. The client <t>The client sets the "msg-type" field to DECLINE. The client
generates a transaction ID and places this value in the generates a transaction ID and places this value in the
"transaction‑id" field.</t> "transaction-id" field.</t>
<t>The client MUST include a Server Identifier option <t>The client <bcp14>MUST</bcp14> include a Server Identifier option
(see <xref target="RFC3315-22.3" format="default"/>) in the Decline (see <xref target="RFC3315-22.3" format="default"/>) in the Decline
message, identifying the server which allocated the lease(s).</t> message, identifying the server that allocated the lease(s).</t>
<t>The client MUST include a Client Identifier option <t>The client <bcp14>MUST</bcp14> include a Client Identifier option
(see <xref target="RFC3315-22.2" format="default"/>) to identify (see <xref target="RFC3315-22.2" format="default"/>) to identify
itself to the server.</t> itself to the server.</t>
<t>The client MUST include an Elapsed Time option (see <t>The client <bcp14>MUST</bcp14> include an Elapsed Time option (see
<xref target="RFC3315-22.9" format="default"/>) to indicate how long t he client has <xref target="RFC3315-22.9" format="default"/>) to indicate how long t he client has
been trying to complete the current DHCP message exchange.</t> been trying to complete the current DHCP message exchange.</t>
<t>The client includes options containing the IAs <t>The client includes options containing the IAs
for the addresses it is declining in the "options" field. The for the addresses it is declining in the "options" field. The
addresses to be declined MUST be included in the IAs. Any addresses addresses to be declined <bcp14>MUST</bcp14> be included in the IAs. A ny addresses
for the IAs the client wishes to continue to use should not be for the IAs the client wishes to continue to use should not be
added to the IAs.</t> added to the IAs.</t>
<t>The client MUST NOT use any of the addresses it is declining as <t>The client <bcp14>MUST NOT</bcp14> use any of the addresses it is d eclining as
the source address in the Decline message or in any subsequently the source address in the Decline message or in any subsequently
transmitted message.</t> transmitted message.</t>
<t>The client transmits the message according to <xref target="RFC3315 -14" format="default"/>, using the following parameters: </t> <t>The client transmits the message according to <xref target="RFC3315 -14" format="default"/>, using the following parameters: </t>
<dl newline="false" spacing="normal" indent="11"> <ul spacing="normal">
<dt> IRT</dt> <li>IRT: DEC_TIMEOUT</li>
<dd>DEC_TIMEOUT</dd> <li>MRT: 0</li>
<dt> MRT</dt> <li>MRC: DEC_MAX_RC</li>
<dd>0</dd> <li>MRD: 0</li>
<dt> MRC</dt> </ul>
<dd>DEC_MAX_RC</dd>
<dt> MRD</dt>
<dd>0</dd>
</dl>
<t>If addresses are declined but the Reply from a DHCP server is <t>If addresses are declined but the Reply from a DHCP server is
lost, the client will retransmit the Decline message, and the server lost, the client will retransmit the Decline message, and the server
may respond with a Reply indicating a status of NoBinding. may respond with a Reply indicating a status of NoBinding.
Therefore, the client does not treat a Reply message with a status Therefore, the client does not treat a Reply message with a status
of NoBinding in a Decline message exchange as if it indicates an of NoBinding in a Decline message exchange as if it indicates an
error.</t> error.</t>
<t>The client SHOULD NOT send a Release message for other bindings <t>The client <bcp14>SHOULD NOT</bcp14> send a Release message for oth er bindings
it may have received just because it sent a Decline message. The it may have received just because it sent a Decline message. The
client SHOULD retain the non-conflicting bindings. The client SHOULD client <bcp14>SHOULD</bcp14> retain the non-conflicting bindings. The client <bcp14>SHOULD</bcp14>
treat the failure to acquire a binding (due to the conflict) as treat the failure to acquire a binding (due to the conflict) as
equivalent to not having received the binding, insofar as how it equivalent to not having received the binding, insofar as how it
behaves when sending Renew and Rebind messages.</t> behaves when sending Renew and Rebind messages.</t>
</section> </section>
<section anchor="RFC3315-17.1.3" numbered="true" toc="default"> <section anchor="RFC3315-17.1.3" numbered="true" toc="default">
<name>Receipt of Advertise Messages</name> <name>Receipt of Advertise Messages</name>
<t>Upon receipt of one or more valid Advertise messages, the client <t>Upon receipt of one or more valid Advertise messages, the client
selects one or more Advertise messages based upon the following selects one or more Advertise messages based upon the following
criteria.</t> criteria.</t>
<ul spacing="normal"> <ul spacing="normal">
<li>Those Advertise messages with the highest server <li>Those Advertise messages with the highest server
preference value SHOULD be preferred over all other Advertise preference value <bcp14>SHOULD</bcp14> be preferred over all other
messages. The client MAY choose a less preferred server if Advertise
messages. The client <bcp14>MAY</bcp14> choose a less preferred se
rver if
that server has a better set of advertised parameters, such as that server has a better set of advertised parameters, such as
the available set of IAs, as well as the set of other the available set of IAs, as well as the set of other
configuration options advertised.</li> configuration options advertised.</li>
<li>Within a group of Advertise messages with the <li>Within a group of Advertise messages with the
same server preference value, a client MAY select those servers same server preference value, a client <bcp14>MAY</bcp14> select t hose servers
whose Advertise messages advertise information of interest to whose Advertise messages advertise information of interest to
the client.</li> the client.</li>
</ul> </ul>
<t>Once a client has selected Advertise message(s), the client will <t>Once a client has selected Advertise message(s), the client will
typically store information about each server, such as the server typically store information about each server, such as the server
preference value, addresses advertised, when the advertisement was preference value, addresses advertised, when the advertisement was
received, and so on.</t> received, and so on.</t>
<t>In practice, this means that the client will maintain independent <t>In practice, this means that the client will maintain independent
per-IA state machines for each selected server.</t> per-IA state machines for each selected server.</t>
<t>If the client needs to select an alternate server in the case <t>If the client needs to select an alternate server in the case
that a chosen server does not respond, the client chooses the next that a chosen server does not respond, the client chooses the next
server according to the criteria given above.</t> server according to the criteria given above.</t>
<t>The client MUST process any SOL_MAX_RT option <t>The client <bcp14>MUST</bcp14> process any SOL_MAX_RT option
(see <xref target="SOL_MAX_RT_option" format="default"/>) (see <xref target="SOL_MAX_RT_option" format="default"/>)
and INF_MAX_RT option (see <xref target="INF_MAX_RT_option" format="de fault"/>) present in an and INF_MAX_RT option (see <xref target="INF_MAX_RT_option" format="de fault"/>) present in an
Advertise message, even if the message contains a Status Code option Advertise message, even if the message contains a Status Code option
(see <xref target="RFC3315-22.13" format="default"/>) indicating a fai lure, and the (see <xref target="RFC3315-22.13" format="default"/>) indicating a fai lure, and the
Advertise message will be discarded by Advertise message will be discarded by
the client. A client SHOULD only update its SOL_MAX_RT and INF_MAX_RT the client. A client <bcp14>SHOULD</bcp14> only update its SOL_MAX_RT and INF_MAX_RT
values if all received Advertise messages that contained the values if all received Advertise messages that contained the
corresponding option specified the same value; otherwise, it should corresponding option specified the same value; otherwise, it should
use the default value (see <xref target="RFC3315-5.5" format="default" />).</t> use the default value (see <xref target="RFC3315-5.5" format="default" />).</t>
<t>The client MUST ignore any Advertise message that contains <t>The client <bcp14>MUST</bcp14> ignore any Advertise message that co ntains
no addresses (IA Address options (see <xref target="RFC3315-22.6" form at="default"/>) no addresses (IA Address options (see <xref target="RFC3315-22.6" form at="default"/>)
encapsulated in IA_NA options (see <xref target="RFC3315-22.4" format= "default"/>)) and encapsulated in IA_NA options (see <xref target="RFC3315-22.4" format= "default"/>)) and
no delegated prefixes (IA Prefix options no delegated prefixes (IA Prefix options
(see <xref target="IAPREFIX-option" format="default"/>) encapsulated i n IA_PD (see <xref target="IAPREFIX-option" format="default"/>) encapsulated i n IA_PD
options (see <xref target="IA_PD-option" format="default"/>)), with th e exception options (see <xref target="IA_PD-option" format="default"/>)), with th e exception
that the client:</t> that the client:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>MUST process an included SOL_MAX_RT option <li><bcp14>MUST</bcp14> process an included SOL_MAX_RT option
and</li> and</li>
<li>MUST process an included INF_MAX_RT option.</li> <li><bcp14>MUST</bcp14> process an included INF_MAX_RT option.</li>
</ul> </ul>
<t>A client can record in an activity log or display to the user <t>A client can record in an activity log or display to the user
any associated status message(s).</t> any associated status message(s).</t>
<t>The client ignoring an Advertise message MUST NOT restart the <t>The client ignoring an Advertise message <bcp14>MUST NOT</bcp14> re start the
Solicit retransmission timer.</t> Solicit retransmission timer.</t>
</section> </section>
<section anchor="RFC3315-18.1.8" numbered="true" toc="default"> <section anchor="RFC3315-18.1.8" numbered="true" toc="default">
<name>Receipt of Reply Messages</name> <name>Receipt of Reply Messages</name>
<t>Upon the receipt of a valid Reply message in response to a <t>Upon the receipt of a valid Reply message in response to a
Solicit with a Rapid Commit option (see <xref target="RFC3315-22.14" f ormat="default"/>), Solicit with a Rapid Commit option (see <xref target="RFC3315-22.14" f ormat="default"/>),
Request, Confirm, Renew, Rebind, or Information-request message, Request, Confirm, Renew, Rebind, or Information-request message,
the client extracts the top-level Status Code option the client extracts the top-level Status Code option
(see <xref target="RFC3315-22.13" format="default"/>) if present.</t> (see <xref target="RFC3315-22.13" format="default"/>) if present.</t>
<t>The client MUST process any SOL_MAX_RT option <t>The client <bcp14>MUST</bcp14> process any SOL_MAX_RT option
(see <xref target="SOL_MAX_RT_option" format="default"/>) and INF_MAX_ RT option (see <xref target="SOL_MAX_RT_option" format="default"/>) and INF_MAX_ RT option
(see <xref target="INF_MAX_RT_option" format="default"/>) present in a (see <xref target="INF_MAX_RT_option" format="default"/>) present in a
Reply message, even if the message contains a Status Code option Reply message, even if the message contains a Status Code option
indicating a failure.</t> indicating a failure.</t>
<t>If the client receives a Reply message with a status code of <t>If the client receives a Reply message with a status code of
UnspecFail, the server is indicating that it was unable to process UnspecFail, the server is indicating that it was unable to process
the client's message due to an unspecified failure condition. If the the client's message due to an unspecified failure condition. If the
client retransmits the original message to the same server to retry client retransmits the original message to the same server to retry
the desired operation, the client MUST limit the rate at which it the desired operation, the client <bcp14>MUST</bcp14> limit the rate a t which it
retransmits the message and limit the duration of the time during retransmits the message and limit the duration of the time during
which it retransmits the message (see <xref target="rate-limit" format ="default"/>).</t> which it retransmits the message (see <xref target="rate-limit" format ="default"/>).</t>
<t>Otherwise (no status code or another status code), the client <t>Otherwise (no status code or another status code), the client
processes the Reply as described below based on the original message processes the Reply as described below based on the original message
for which the Reply was received.</t> for which the Reply was received.</t>
<t>The client MAY choose to report any status code or message from <t>The client <bcp14>MAY</bcp14> choose to report any status code or m essage from
the Status Code option in the Reply message.</t> the Status Code option in the Reply message.</t>
<t>The topic of revoking previously assigned options is discussed <t>The topic of revoking previously assigned options is discussed
in <xref target="revoking-config" format="default" />.</t> in <xref target="revoking-config" format="default"/>.</t>
<t>When a client receives a requested option that has an updated <t>When a client receives a requested option that has an updated
value from what was previously received, the client SHOULD make value from what was previously received, the client <bcp14>SHOULD</bcp 14> make
use of that updated value as soon as possible for its configuration use of that updated value as soon as possible for its configuration
information.</t> information.</t>
<section anchor="reply-solicit-request-renew-rebind" numbered="true" t oc="default"> <section anchor="reply-solicit-request-renew-rebind" numbered="true" t oc="default">
<name>Reply for Solicit (with Rapid Commit), Request, Renew, or Rebi nd</name> <name>Reply for Solicit (with Rapid Commit), Request, Renew, or Rebi nd</name>
<t>If the client receives a NotOnLink status from the server in <t>If the client receives a NotOnLink status from the server in
response to a Solicit (with a Rapid Commit option; response to a Solicit (with a Rapid Commit option;
see <xref target="RFC3315-22.14" format="default"/>) or a Request, see <xref target="RFC3315-22.14" format="default"/>) or a Request,
the client can either reissue the message without specifying any the client can either reissue the message without specifying any
addresses or restart the DHCP server discovery process (see <xref ta addresses or restart the DHCP server discovery process (see <xref ta
rget="configuration-exchange" format="default"/> rget="configuration-exchange"/>
or <xref target="RFC8415bis-18.2.13" format="default"/>).</t> or <xref target="RFC8415bis-18.2.13"/>).</t>
<t>If the Reply was received in response to a Solicit (with a <t>If the Reply was received in response to a Solicit (with a
Rapid Commit option), Request, Renew, or Rebind message, the Rapid Commit option), Request, Renew, or Rebind message, the
client updates the information it has recorded about IAs from the client updates the information it has recorded about IAs from the
IA options contained in the Reply message:</t> IA options contained in the Reply message:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>Calculate T1 and T2 times (based on T1 and T2 <li>Calculate T1 and T2 times (based on T1 and T2
values sent in the message and the message reception time), if values sent in the message and the message reception time), if
appropriate for the IA type.</li> appropriate for the IA type.</li>
<li>Add any new leases in the IA option to the IA <li>Add any new leases in the IA option to the IA
as recorded by the client.</li> as recorded by the client.</li>
skipping to change at line 2829 skipping to change at line 2857
<li>Leave unchanged any information about leases <li>Leave unchanged any information about leases
the client has recorded in the IA but that were not included the client has recorded in the IA but that were not included
in the IA from the server.</li> in the IA from the server.</li>
</ul> </ul>
<t>If the client can operate with the addresses and/or prefixes <t>If the client can operate with the addresses and/or prefixes
obtained from the server:</t> obtained from the server:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>The client uses the addresses, delegated <li>The client uses the addresses, delegated
prefixes, and other information from any IAs that do not prefixes, and other information from any IAs that do not
contain a Status Code option with the NoAddrsAvail or contain a Status Code option with the NoAddrsAvail or
NoPrefixAvail status code. The client MAY include the IAs for NoPrefixAvail status code. The client <bcp14>MAY</bcp14> include the IAs for
which it received the NoAddrsAvail or NoPrefixAvail status which it received the NoAddrsAvail or NoPrefixAvail status
code, with no addresses or prefixes, in subsequent Renew and code, with no addresses or prefixes, in subsequent Renew and
Rebind messages sent to the server, to retry obtaining the Rebind messages sent to the server, to retry obtaining the
addresses or prefixes for these IAs.</li> addresses or prefixes for these IAs.</li>
<li>The client MUST perform duplicate address <li>The client <bcp14>MUST</bcp14> perform duplicate address
detection as per Section 5.4 of <xref target="RFC4862" format="d detection as per <xref target="RFC4862" section="5.4"/>,
efault"/>,
which does list some exceptions, on each of the which does list some exceptions, on each of the
received addresses in any IAs on which it has not performed received addresses in any IAs on which it has not performed
duplicate address detection during processing of any of the duplicate address detection during processing of any of the
previous Reply messages from the server. The client performs previous Reply messages from the server. The client performs
the duplicate address detection before using the received the duplicate address detection before using the received
addresses for any traffic. If any of the addresses are found addresses for any traffic. If any of the addresses are found
to be in use on the link, the client sends a Decline message to be in use on the link, the client sends a Decline message
to the server for those addresses as described in <xref target=" RFC3315-18.1.7" format="default"/>.</li> to the server for those addresses as described in <xref target=" RFC3315-18.1.7" format="default"/>.</li>
<li>For each assigned address that does not have any <li>For each assigned address that does not have any
associated reachability information (see the definition of associated reachability information (see the definition of
"on‑link" in Section 2.1 of "on-link" in
<xref target="RFC4861" format="default"/>), in order to avoid th <xref target="RFC4861" section="2.1"/>), in order to avoid the
e
problems described in <xref target="RFC4943" format="default"/>, the client problems described in <xref target="RFC4943" format="default"/>, the client
MUST NOT assume that any addresses are reachable on-link as a <bcp14>MUST NOT</bcp14> assume that any addresses are reachable on-link as a
result of receiving an IA Address option (see result of receiving an IA Address option (see
<xref target="RFC3315-22.6" format="default"/>). Addresses obtai ned from <xref target="RFC3315-22.6" format="default"/>). Addresses obtai ned from
an IA Address option MUST NOT be used to form an implicit prefix an IA Address option <bcp14>MUST NOT</bcp14> be used to form an implicit prefix
with a length other than 128.</li> with a length other than 128.</li>
<li> <li>
<t>For each delegated prefix, the client assigns a <t>For each delegated prefix, the client assigns a
subnet to each of the links to which the associated interfaces a re subnet to each of the links to which the associated interfaces a re
attached. attached.
</t> </t>
<t> <t>
When a client subnets a delegated prefix, it must assign When a client subnets a delegated prefix, it must assign
additional bits to the prefix to generate unique, longer prefixe s. additional bits to the prefix to generate unique, longer prefixe s.
For example, if the client in <xref target="FigISPNetwork" forma t="default"/> were delegated For example, if the client in <xref target="FigISPNetwork" forma t="default"/> were delegated
2001:db8:0::/48, it might generate 2001:db8:0:1::/64 and 2001:db8:0::/48, it might generate 2001:db8:0:1::/64 and
2001:db8:0:2::/64 for assignment to the two links in the subscri ber 2001:db8:0:2::/64 for assignment to the two links in the subscri ber
network. If the client were delegated 2001:db8:0::/48 network. If the client were delegated 2001:db8:0::/48
and 2001:db8:5::/48, it might assign 2001:db8:0:1::/64 and and 2001:db8:5::/48, it might assign 2001:db8:0:1::/64 and
2001:db8:5:1::/64 to one of the links, and 2001:db8:0:2::/64 and 2001:db8:5:1::/64 to one of the links, and 2001:db8:0:2::/64 and
2001:db8:5:2::/64 for assignment to the other link. 2001:db8:5:2::/64 for assignment to the other link.
</t> </t>
<t> <t>
If the client uses a delegated prefix to configure addresses on If the client uses a delegated prefix to configure addresses on
interfaces on itself or other nodes behind it, the preferred and interfaces on itself or other nodes behind it, the preferred and
valid lifetimes of those addresses MUST be no longer than the valid lifetimes of those addresses <bcp14>MUST</bcp14> be no lon ger than the
remaining preferred and valid lifetimes, respectively, for the remaining preferred and valid lifetimes, respectively, for the
delegated prefix at any time. In particular, if the delegated delegated prefix at any time. In particular, if the delegated
prefix or a prefix derived from it is advertised for stateless prefix or a prefix derived from it is advertised for stateless
address autoconfiguration <xref target="RFC4862" format="default "/>, the address autoconfiguration <xref target="RFC4862" format="default "/>, the
advertised preferred and valid lifetimes MUST NOT exceed the advertised preferred and valid lifetimes <bcp14>MUST NOT</bcp14> exceed the
corresponding remaining lifetimes of the delegated prefix.</t> corresponding remaining lifetimes of the delegated prefix.</t>
</li> </li>
</ul> </ul>
<t>Management of the specific configuration information is <t>Management of the specific configuration information is
detailed in the definition of each option in <xref target="RFC3315-2 2" format="default"/>.</t> detailed in the definition of each option in <xref target="RFC3315-2 2" format="default"/>.</t>
<t>If the Reply message contains any IAs but the client finds no <t>If the Reply message contains any IAs but the client finds no
usable addresses and/or delegated prefixes in any of these IAs, usable addresses and/or delegated prefixes in any of these IAs,
the client may either try another server (perhaps restarting the the client may either try another server (perhaps restarting the
DHCP server discovery process) or use the Information-request DHCP server discovery process) or use the Information-request
message to obtain other configuration information only.</t> message to obtain other configuration information only.</t>
skipping to change at line 2901 skipping to change at line 2929
<ul spacing="normal"> <ul spacing="normal">
<li>Sends a Request message to the server that <li>Sends a Request message to the server that
responded if any of the IAs in the Reply message contain the responded if any of the IAs in the Reply message contain the
NoBinding status code. The client places IA options in this NoBinding status code. The client places IA options in this
message for all IAs. The client continues to use other bindings message for all IAs. The client continues to use other bindings
for which the server did not return an error.</li> for which the server did not return an error.</li>
<li>Sends a Renew/Rebind if any of the IAs are not <li>Sends a Renew/Rebind if any of the IAs are not
in the Reply message, but as this likely indicates that the serv er in the Reply message, but as this likely indicates that the serv er
that responded does not support that IA type, sending immediatel y that responded does not support that IA type, sending immediatel y
is unlikely to produce a different result. Therefore, the client is unlikely to produce a different result. Therefore, the client
MUST rate-limit its transmissions (see <xref target="rate-limit" <bcp14>MUST</bcp14> rate-limit its transmissions (see <xref targ
format="default"/>) et="rate-limit" format="default"/>)
and MAY just wait for the normal retransmission time (as if the and <bcp14>MAY</bcp14> just wait for the normal retransmission t
ime (as if the
Reply message had not been received). The client continues to us e Reply message had not been received). The client continues to us e
other bindings for which the server did return information.</li> other bindings for which the server did return information.</li>
<li>Otherwise accepts the information in the <li>Otherwise accepts the information in the
IA.</li> IA.</li>
</ul> </ul>
</section> </section>
<section anchor="reply-release-decline" numbered="true" toc="default"> <section anchor="reply-release-decline" numbered="true" toc="default">
<name>Reply for Release and Decline</name> <name>Reply for Release and Decline</name>
<t>When the client receives a valid Reply message in response to a <t>When the client receives a valid Reply message in response to a
Release message, the client considers the Release event completed, Release message, the client considers the Release event completed,
skipping to change at line 2939 skipping to change at line 2967
</section> </section>
<section anchor="reply-inforequest" numbered="true" toc="default"> <section anchor="reply-inforequest" numbered="true" toc="default">
<name>Reply for Information-request</name> <name>Reply for Information-request</name>
<t>Refer to <xref target="RFC4242-Option" format="default"/> for det ails on how the <t>Refer to <xref target="RFC4242-Option" format="default"/> for det ails on how the
Information Refresh Time option (whether or not present in the Information Refresh Time option (whether or not present in the
Reply) should be handled by the client.</t> Reply) should be handled by the client.</t>
</section> </section>
<section anchor="revoking-config" numbered="true" toc="default"> <section anchor="revoking-config" numbered="true" toc="default">
<name>Revoking Previously Provided Options</name> <name>Revoking Previously Provided Options</name>
<!--[rfced] Does the following rephrase correctly capture your intent?
Original:
When a client received a configuration option in an earlier Reply and
then sends a Renew, Rebind, or Information-request and the requested
option is not present in the Reply, the client SHOULD stop using the
previously received configuration information.
Perhaps:
If a client received a configuration option in an earlier Reply, when
it later sends a Renew, Rebind, or Information-request, the requested
option needs to be present in the next Reply; otherwise, the client SHOULD
stop using the previously received configuration information.
-->
<t>When a client received a configuration option in an earlier <t>When a client received a configuration option in an earlier
Reply and then sends a Renew, Rebind, or Information-request and Reply and then sends a Renew, Rebind, or Information-request and
the requested option is not present in the Reply, the client the requested option is not present in the Reply, the client
SHOULD stop using the previously received configuration <bcp14>SHOULD</bcp14> stop using the previously received configuration
information. In other words, the client should behave as if information. In other words, the client should behave as if
it never received this configuration option and return to the it never received this configuration option and return to the
relevant default state. If there is no viable way to stop using relevant default state. If there is no viable way to stop using
the received configuration information, the values the received configuration information, the values
received/configured from the option MAY persist if there are received/configured from the option <bcp14>MAY</bcp14> persist if ther e are
no other sources for that data and they have no external impact. no other sources for that data and they have no external impact.
For example, a client that previously received a Client FQDN For example, a client that previously received a Client FQDN
option (see <xref target="RFC4704" format="default"/>) and used option (see <xref target="RFC4704" format="default"/>) and used
it to set up its hostname is allowed to continue it to set up its hostname is allowed to continue
using it if there is no reasonable way for a node to unset its using it if there is no reasonable way for a node to unset its
hostname and it has no external impact. As a counter-example, hostname and it has no external impact. As a counterexample,
a client that previously received an NTP server address from a client that previously received an NTP server address from
the DHCP server and does not receive it anymore MUST stop the DHCP server and does not receive it anymore <bcp14>MUST</bcp14> st op
using the configured NTP server address. The client using the configured NTP server address. The client
SHOULD be open to other sources of the same configuration <bcp14>SHOULD</bcp14> be open to other sources of the same configurati
information. This behavior does not apply to any IA options, on
as their processing is described in <xref target="reply-solicit-reques information. This behavior does not apply to any IA options;
t-renew-rebind" /></t> their processing is described in <xref target="reply-solicit-request-r
enew-rebind"/>.</t>
</section> </section>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Receipt of Reconfigure Messages</name> <name>Receipt of Reconfigure Messages</name>
<t>A client receives Reconfigure messages sent to UDP port 546 <t>A client receives Reconfigure messages sent to UDP port 546
on interfaces for which it has acquired configuration information on interfaces for which it has acquired configuration information
through DHCP. These messages may be sent at any time. Since the through DHCP. These messages may be sent at any time. Since the
results of a reconfiguration event may affect application-layer results of a reconfiguration event may affect application-layer
programs, the client SHOULD log these events and MAY notify these programs, the client <bcp14>SHOULD</bcp14> log these events and <bcp14 >MAY</bcp14> notify these
programs of the change through an implementation-specific programs of the change through an implementation-specific
interface.</t> interface.</t>
<t>The message MUST be dropped if it doesn't pass the validation, <t>The message <bcp14>MUST</bcp14> be dropped if it doesn't pass the v
as explained in (see <xref target="RFC3315-15.11" format="default"/>), alidation,
in particular in case the authentication is missing or fails.</t> as explained in <xref target="RFC3315-15.11" format="default"/>,
particularly in cases where the authentication is missing or fails.</t
>
<t>Upon receipt of a valid Reconfigure message, the client responds <t>Upon receipt of a valid Reconfigure message, the client responds
with a Renew message, a Rebind message, or an with a Renew message, a Rebind message, or an
Information-request message as indicated by the Reconfigure Message Information-request message as indicated by the Reconfigure Message
option (see <xref target="RFC3315-22.19" format="default"/>). The option (see <xref target="RFC3315-22.19" format="default"/>). The
client ignores the "transaction‑id" field in the received Reconfigure client ignores the "transaction-id" field in the received Reconfigure
message. While the transaction is in progress, the client discards message. While the transaction is in progress, the client discards
any Reconfigure messages it receives.</t> any Reconfigure messages it receives.</t>
<t>The Reconfigure message acts as a trigger that signals the <t>The Reconfigure message acts as a trigger that signals the
client to complete a successful message exchange. Once the client to complete a successful message exchange. Once the
client has received a Reconfigure, the client proceeds with the client has received a Reconfigure, the client proceeds with the
message exchange (retransmitting the Renew, Rebind, or message exchange (retransmitting the Renew, Rebind, or
Information-request message if necessary); the client MUST ignore Information-request message if necessary); the client <bcp14>MUST</bcp 14> ignore
any additional Reconfigure messages until the exchange is any additional Reconfigure messages until the exchange is
complete.</t> complete.</t>
<t>Duplicate messages will be <t>Duplicate messages will be
ignored because the client will begin the exchange after the ignored because the client will begin the exchange after the
receipt of the first Reconfigure. Retransmitted messages will receipt of the first Reconfigure. Retransmitted messages will
either (1) trigger the exchange (if the first Reconfigure was either (1) trigger the exchange (if the first Reconfigure was
not received by the client) or (2) be ignored. The server MAY not received by the client) or (2) be ignored. The server <bcp14>MAY</
bcp14>
discontinue retransmission of Reconfigure messages to the client discontinue retransmission of Reconfigure messages to the client
once the server receives the Renew, Rebind, or once the server receives the Renew, Rebind, or
Information‑request message from the client.</t> Information-request message from the client.</t>
<t>It might be possible for a duplicate or retransmitted <t>It might be possible for a duplicate or retransmitted
Reconfigure to be sufficiently delayed (and delivered out of Reconfigure to be sufficiently delayed (and delivered out of
order) that it arrives at the client after the exchange (initiated by order) that it arrives at the client after the exchange (initiated by
the original Reconfigure) has been completed. In this case, the the original Reconfigure) has been completed. In this case, the
client would initiate a redundant exchange. The likelihood of client would initiate a redundant exchange. The likelihood of
delayed and out‑of‑order delivery is small enough to be delayed and out-of-order delivery is small enough to be
ignored. The consequence of the redundant exchange is ignored. The consequence of the redundant exchange is
inefficiency rather than incorrect operation.</t> inefficiency rather than incorrect operation.</t>
</section> </section>
<section anchor="RFC3315-18.2.12" numbered="true" toc="default"> <section anchor="RFC3315-18.2.12" numbered="true" toc="default">
<name>Refreshing Configuration Information</name> <name>Refreshing Configuration Information</name>
<t>Whenever a client may have moved to a new link, the <t>Whenever a client may have moved to a new link, the
prefixes⁠/addresses assigned to the interfaces on that link may no prefixes/addresses assigned to the interfaces on that link may no
longer be appropriate for the link to which the client is attached. longer be appropriate for the link to which the client is attached.
Examples of times when a client may have moved to a new link Examples of times when a client may have moved to a new link
include the following:</t> include the following:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>The client reboots (and has stable storage and <li>The client reboots (and has stable storage and
persistent DHCP state).</li> persistent DHCP state).</li>
<li>The client is reconnected to a link on which <li>The client is reconnected to a link on which
it has obtained leases.</li> it has obtained leases.</li>
<li>The client returns from sleep mode.</li> <li>The client returns from sleep mode.</li>
<li>The client changes access points (e.g., if <li>The client changes access points (e.g., if
using Wi-Fi technology).</li> using Wi-Fi technology).</li>
<li>The client's network interface indicates a disconnection event, <li>The client's network interface indicates a disconnection event
followed by a connection event.</li> followed by a connection event.</li>
</ul> </ul>
<t>Specific algorithms for detecting network attachment changes are ou t of scope <t>Specific algorithms for detecting network attachment changes are ou t of scope
for this document. Two possible mechanisms for detecting situations wh ere refreshing for this document. Two possible mechanisms for detecting situations wh ere refreshing
configuration information may be needed are defined in <xref target="R configuration information may be needed are defined in <xref target="R
FC6059" FC6059" format="default"/> and <xref target="RFC4957" format="default"/>.</t>
format="default"/> and <xref target="RFC4957" format="default" />.</t>
<t>When the client detects that it may have moved to a new link and it <t>When the client detects that it may have moved to a new link and it
has obtained addresses and no delegated prefixes from a server, the has obtained addresses and no delegated prefixes from a server, the
client SHOULD initiate a Confirm/Reply message exchange. The client client <bcp14>SHOULD</bcp14> initiate a Confirm/Reply message exchange
MUST include any IAs assigned to the interface that may have moved to . The client
a <bcp14>MUST</bcp14> include any IAs assigned to the interface that may
have moved to a
new link, along with the addresses associated with those IAs, in its new link, along with the addresses associated with those IAs, in its
Confirm message. Any responding servers will indicate whether those Confirm message. Any responding servers will indicate whether those
addresses are appropriate for the link to which the client is addresses are appropriate for the link to which the client is
attached with the status in the Reply message it returns to the attached with the status in the Reply message it returns to the
client.</t> client.</t>
<t>If the client has any valid delegated prefixes obtained from the <t>If the client has any valid delegated prefixes obtained from the
DHCP server, the client MUST DHCP server, the client <bcp14>MUST</bcp14>
initiate a Rebind/Reply message exchange as described in <xref target= "RFC3315-18.1.4" format="default"/>, with the exception that the initiate a Rebind/Reply message exchange as described in <xref target= "RFC3315-18.1.4" format="default"/>, with the exception that the
retransmission parameters should be set as for the Confirm message retransmission parameters should be set as for the Confirm message
(see <xref target="RFC3315-18.1.2" format="default"/>). The client inc ludes IA_NAs and IA_PDs, (see <xref target="RFC3315-18.1.2" format="default"/>). The client inc ludes IA_NAs and IA_PDs,
along with the associated leases, in its Rebind message.</t> along with the associated leases, in its Rebind message.</t>
<t>If the client has only obtained network information using Informati on-request/Reply <t>If the client has only obtained network information using Informati on-request/Reply
message exchanges, the client MUST initiate an Information-request/Rep ly message exchange as message exchanges, the client <bcp14>MUST</bcp14> initiate an Informat ion-request/Reply message exchange as
described in <xref target="RFC3315-18.1.5" format="default"/>.</t> described in <xref target="RFC3315-18.1.5" format="default"/>.</t>
<!--[rfced] The phrasing of "not associated with a detection of having
moved" is a bit tough to get through. Also, it may be easier on
the reader if this sentence did not have two "if" clauses. If
our suggested rephrasing does not capture your intent, please
rephrase.
Original:
If not associated with a detection of having moved to a new link, a
client SHOULD initiate one of the Renew/Reply, Confirm/Reply or
Information-request/Reply exchanges, if the client detects a
significant change regarding the prefixes available on the link.
Perhaps:
A client not detected as having moved to a new link SHOULD initiate
one of the Renew/Reply, Confirm/Reply or Information-request/Reply
exchanges, if the client detects a significant change regarding the
prefixes available on the link.
-->
<t> <t>
If not associated with a detection of having moved to a new link, a If not associated with a detection of having moved to a new link, a
client SHOULD initiate one of the Renew/Reply, Confirm/Reply or client <bcp14>SHOULD</bcp14> initiate one of the Renew/Reply, Confir m/Reply or
Information-request/Reply exchanges, if the client detects a Information-request/Reply exchanges, if the client detects a
significant change regarding the prefixes available on the link. significant change regarding the prefixes available on the link.
A change is considered significant when one or more on-link A change is considered significant when one or more on-link
prefixes are added, and/or one or more existing on-link prefixes prefixes are added, and/or one or more existing on-link prefixes
are deprecated. are deprecated.
The reason for this is that such a significant change may indicate The reason for this is that such a significant change may indicate
a configuration change at the server. a configuration change at the server.
However, a client MUST rate‑limit such initiation attempts to avoid However, a client <bcp14>MUST</bcp14> rate-limit such initiation att empts to avoid
flooding a server with requests when there are link issues (for flooding a server with requests when there are link issues (for
example, only doing one of these at most every 30 seconds). example, only doing one of these at most every 30 seconds).
</t> </t>
<t> <t>
The above selection of an exchange to initiate depends on the client 's current state: The above selection of an exchange to initiate depends on the client 's current state:
</t> </t>
<ul> <ul>
<li>If the client has any valid delegated prefixes obtained <li>If the client has any valid delegated prefixes obtained
from the server, it sends Renew (as if the T1 time expired) as from the server, it sends Renew (as if the T1 time expired) as
described in <xref target="RFC3315-18.1.3" />.</li> described in <xref target="RFC3315-18.1.3"/>.</li>
<li>Else, if the client obtained address(es) from the server, <li>Else, if the client obtained an address(es) from the server,
it sends Confirm as described in <xref target="RFC3315-18.1.2" />.</ it sends Confirm as described in <xref target="RFC3315-18.1.2"/>.</l
li> i>
<li>Else, if only network information was obtained from the <li>Else, if only network information was obtained from the
server, it sends Information-request as described in <xref target="R FC3315-18.1.5" /></li> server, it sends an Information-request as described in <xref target ="RFC3315-18.1.5"/>.</li>
</ul> </ul>
</section> </section>
<section anchor="RFC8415bis-18.2.13" numbered="true" toc="default"> <section anchor="RFC8415bis-18.2.13" numbered="true" toc="default">
<name>Restarting Server Discovery Process</name> <name>Restarting Server Discovery Process</name>
<!--[rfced] Please review our updates to the following text for
readability. Note that this updated text includes a repeat of a
BCP 14 keyword.
Original:
Whenever a client restarts the DHCP server discovery process or
selects an alternate server as described in Section 18.2.9, the
client SHOULD stop using any addresses and delegated prefixes for
which it has bindings (see Section 18.2.7) and if possible, any
previously received other configuration information, and try to
obtain new bindings and other configuration information from a "new"
server for the same interface.
Current:
Whenever a client restarts the DHCP server discovery process or
selects an alternate server as described in Section 18.2.9, the
client SHOULD stop using any addresses and delegated prefixes for
which it has bindings (see Section 18.2.7) and, if possible, any
other configuration information it previously received. The client
SHOULD also try to obtain new bindings and other configuration
information from a "new" server for the same interface.
-->
<t>Whenever a client restarts the DHCP server discovery process or <t>Whenever a client restarts the DHCP server discovery process or
selects an alternate server as described in <xref target="RFC3315-17.1.3 selects an alternate server as described in <xref target="RFC3315-17.1.3
" />, "/>,
the client SHOULD stop using any addresses and delegated prefixes for the client <bcp14>SHOULD</bcp14> stop using any addresses and delegated
which it has bindings (see <xref target="RFC3315-18.1.6" />) prefixes for
and if possible, any previously received other configuration which it has bindings (see <xref target="RFC3315-18.1.6"/>)
information, and try to obtain new bindings and other configuration and, if possible, any other configuration
information it previously received. The client <bcp14>SHOULD</bcp14> al
so try to obtain new bindings and other configuration
information from a "new" server for the same interface. This facilitates the client using a information from a "new" server for the same interface. This facilitates the client using a
single state machine for all bindings.</t> single state machine for all bindings.</t>
</section> </section>
</section> </section>
<section anchor="RFC3315-18.2" numbered="true" toc="default"> <section anchor="RFC3315-18.2" numbered="true" toc="default">
<name>Server Behavior</name> <name>Server Behavior</name>
<t>For this discussion, the server is assumed to have been configured <t>For this discussion, the server is assumed to have been configured
in an implementation-specific manner with configurations of interest to in an implementation-specific manner with configurations of interest to
clients.</t> clients.</t>
<t>A server sends an Advertise message in response to each valid Solicit <t>A server sends an Advertise message in response to each valid Solicit
message it receives to announce the availability of the server to the message it receives to announce the availability of the server to the
client.</t> client.</t>
<t>In most cases, the server will send a Reply in response to <t>In most cases, the server will send a Reply in response to
Request, Confirm, Renew, Rebind, Decline, Release, and Information-reque st Request, Confirm, Renew, Rebind, Decline, Release, and Information-reque st
messages sent by a client. The server will also send a Reply in messages sent by a client. The server will also send a Reply in
response to a Solicit with a Rapid Commit option response to a Solicit with a Rapid Commit option
(see <xref target="RFC3315-22.14" format="default"/>) when the server is (see <xref target="RFC3315-22.14" format="default"/>) when the server is
configured to respond with committed lease assignments.</t> configured to respond with committed lease assignments.</t>
<t>These Advertise and Reply messages MUST always contain the <t>These Advertise and Reply messages <bcp14>MUST</bcp14> always contain the
Server Identifier option (see <xref target="RFC3315-22.3" format="defaul t"/>) containing Server Identifier option (see <xref target="RFC3315-22.3" format="defaul t"/>) containing
the server's DUID and the Client Identifier option the server's DUID and the Client Identifier option
(see <xref target="RFC3315-22.2" format="default"/>) from the (see <xref target="RFC3315-22.2" format="default"/>) from the
client message if one was present.</t> client message if one was present.</t>
<t>In most response messages, the server includes options containing <t>In most response messages, the server includes options containing
configuration information for the client. The server must be aware of configuration information for the client. The server must be aware of
the recommendations on message sizes and the use of fragmentation the recommendations on message sizes and the use of fragmentation
as discussed in Section 5 of <xref target="RFC8200" format="default"/>. If the as discussed in <xref target="RFC8200" section="5"/>. If the
client included an Option Request option (see <xref target="RFC3315-22.7 " format="default"/>) in its message, the server includes options client included an Option Request option (see <xref target="RFC3315-22.7 " format="default"/>) in its message, the server includes options
in the response message containing configuration parameters for all of in the response message containing configuration parameters for all of
the options identified in the Option Request option that the server has the options identified in the Option Request option that the server has
been configured to return to the client. The server MAY return been configured to return to the client. The server <bcp14>MAY</bcp14> r eturn
additional options to the client if it has been configured to do additional options to the client if it has been configured to do
so.</t> so.</t>
<t>Any message sent from a client may arrive at the server <t>Any message sent from a client may arrive at the server
encapsulated in one or more Relay-forward messages. The server MUST encapsulated in one or more Relay-forward messages. The server <bcp14>MU ST</bcp14>
use the received message to construct the proper Relay-reply use the received message to construct the proper Relay-reply
message to allow the response to the received message to be message to allow the response to the received message to be
relayed through the same relay agents (in reverse order) as relayed through the same relay agents (in reverse order) as
the original client message; see <xref target="RFC3315-20.3" format="def ault"/> the original client message; see <xref target="RFC3315-20.3" format="def ault"/>
for more details. for more details.
The server may also need to record this information with each The server may also need to record this information with each
client in case it is needed to send a Reconfigure message at a later client in case it is needed to send a Reconfigure message at a later
time, unless the server has been configured with addresses that can be time, unless the server has been configured with addresses that can be
used to send Reconfigure messages directly to the client (see used to send Reconfigure messages directly to the client (see
<xref target="reconfigure-transmission" format="default"/>). Note that s ervers <xref target="reconfigure-transmission" format="default"/>). Note that s ervers
that support leasequery <xref target="RFC5007" format="default"/> also n eed that support leasequery <xref target="RFC5007" format="default"/> also n eed
to record this information.</t> to record this information.</t>
<t>By sending Reconfigure messages, the server MAY initiate a <t>By sending Reconfigure messages, the server <bcp14>MAY</bcp14> initia te a
configuration exchange to cause DHCP clients to obtain new addresses, configuration exchange to cause DHCP clients to obtain new addresses,
prefixes, and other configuration information. For example, an prefixes, and other configuration information. For example, an
administrator may use a server-initiated configuration exchange when administrator may use a server-initiated configuration exchange when
links in the DHCP domain are to be renumbered or when other links in the DHCP domain are to be renumbered or when other
configuration options are updated, perhaps because servers configuration options are updated, perhaps because servers
are moved, added, or removed.</t> are moved, added, or removed.</t>
<t>When a client receives a Reconfigure message from the server, the <t>When a client receives a Reconfigure message from the server, the
client initiates sending a Renew, Rebind, or Information-request message client initiates sending a Renew, Rebind, or Information-request message
as indicated by msg-type in the Reconfigure Message option (see as indicated by msg-type in the Reconfigure Message option (see
<xref target="RFC3315-22.19" format="default"/>). The server sends IAs a nd/or <xref target="RFC3315-22.19" format="default"/>). The server sends IAs a nd/or
other configuration information to the client in a Reply message. The other configuration information to the client in a Reply message. The
server MAY include options containing the IAs and new values for other server <bcp14>MAY</bcp14> include options containing the IAs and new val ues for other
configuration parameters in the Reply message, even if those IAs and configuration parameters in the Reply message, even if those IAs and
parameters were not requested in the client's message.</t> parameters were not requested in the client's message.</t>
<section anchor="RFC3315-17.2.1" numbered="true" toc="default"> <section anchor="RFC3315-17.2.1" numbered="true" toc="default">
<name>Receipt of Solicit Messages</name> <name>Receipt of Solicit Messages</name>
<t>The server determines the information about the client and its <t>The server determines the information about the client and its
location as described in <xref target="RFC3315-11" format="default"/> and location as described in <xref target="RFC3315-11" format="default"/> and
checks its administrative policy about responding to the client. If checks its administrative policy about responding to the client. If
the server is not permitted to respond to the client, the server the server is not permitted to respond to the client, the server
discards the Solicit message. For example, if the administrative discards the Solicit message. For example, if the administrative
policy for the server is that it may only respond to a client that policy for the server is that it may only respond to a client that
is willing to accept a Reconfigure message, if the client does not is willing to accept a Reconfigure message, if the client does not
include a Reconfigure Accept option (see <xref target="RFC3315-22.20" format="default"/>) in the Solicit message, the server include a Reconfigure Accept option (see <xref target="RFC3315-22.20" format="default"/>) in the Solicit message, the server
discards the Solicit message.</t> discards the Solicit message.</t>
<t>If (1) the server is permitted to respond to the client, <t>If (1) the server is permitted to respond to the client,
(2) the client has not included a Rapid Commit option (see (2) the client has not included a Rapid Commit option (see
<xref target="RFC3315-22.14" format="default"/>) in the Solicit messag e, or <xref target="RFC3315-22.14" format="default"/>) in the Solicit messag e, or
(3) the server has not been configured to respond with (3) the server has not been configured to respond with
committed assignments of leases and other resources, the server committed assignments of leases and other resources, the server
sends an Advertise message to the client as described in sends an Advertise message to the client as described in
<xref target="RFC3315-17.2.2" format="default"/>.</t> <xref target="RFC3315-17.2.2" format="default"/>.</t>
<t>If the client has included a Rapid Commit option in the Solicit <t>If the client has included a Rapid Commit option in the Solicit
message and the server has been configured to respond with committed message and the server has been configured to respond with committed
assignments of leases and other resources, the server responds to the assignments of leases and other resources, the server responds to the
Solicit with a Reply message. The server produces the Reply message Solicit with a Reply message. The server produces the Reply message
as though it had received a Request message as described in <xref targ et="RFC3315-18.2.1" format="default"/>. The server transmits the Reply as though it had received a Request message as described in <xref targ et="RFC3315-18.2.1" format="default"/>. The server transmits the Reply
message as described in <xref target="RFC3315-18.2.8" format="default" />. message as described in <xref target="RFC3315-18.2.8" format="default" />.
The server MUST commit the assignment The server <bcp14>MUST</bcp14> commit the assignment
of any addresses and delegated prefixes or other configuration of any addresses and delegated prefixes or other configuration
information before sending a Reply message to a client. In this case, information before sending a Reply message to a client. In this case,
the server includes a Rapid Commit option in the Reply message to the server includes a Rapid Commit option in the Reply message to
indicate that the Reply is in response to a Solicit message.</t> indicate that the Reply is in response to a Solicit message.</t>
<t>DISCUSSION:</t> <t>DISCUSSION:</t>
<ul empty="true" spacing="normal"> <ul spacing="normal">
<li>When using the Solicit/Reply message exchange, the server <li>When using the Solicit/Reply message exchange, the server
commits the assignment of any leases before sending the Reply commits the assignment of any leases before sending the Reply
message. The client can assume that it has been assigned the message. The client can assume that it has been assigned the
leases in the Reply message and does not need to send a leases in the Reply message and does not need to send a
Request message for those leases.</li> Request message for those leases.</li>
<li>Typically, servers that are configured to use the <li>Typically, servers that are configured to use the
Solicit/Reply message exchange will be deployed so that only one Solicit/Reply message exchange will be deployed so that only one
server will respond to a Solicit message. If more than one server will respond to a Solicit message. If more than one
server responds, the client will only use the leases from one of server responds, the client will only use the leases from one of
the servers, while the leases from the other servers will be the servers, while the leases from the other servers will be
skipping to change at line 3195 skipping to change at line 3282
</ul> </ul>
</section> </section>
<section anchor="RFC3315-18.2.1" numbered="true" toc="default"> <section anchor="RFC3315-18.2.1" numbered="true" toc="default">
<name>Receipt of Request Messages</name> <name>Receipt of Request Messages</name>
<t>When the server receives a valid Request message, the server <t>When the server receives a valid Request message, the server
creates the bindings for that client according to the server's creates the bindings for that client according to the server's
policy and configuration information and records the IAs and other policy and configuration information and records the IAs and other
information requested by the client.</t> information requested by the client.</t>
<t>The server constructs a Reply message by setting the "msg-type" <t>The server constructs a Reply message by setting the "msg-type"
field to REPLY and copying the transaction ID from the Request field to REPLY and copying the transaction ID from the Request
message into the "transaction‑id" field.</t> message into the "transaction-id" field.</t>
<t>The server MUST include in the Reply message a <t>The server <bcp14>MUST</bcp14> include in the Reply message a
Server Identifier option Server Identifier option
(see <xref target="RFC3315-22.3" format="default"/>) containing the (see <xref target="RFC3315-22.3" format="default"/>) containing the
server's DUID and the Client Identifier option server's DUID and the Client Identifier option
(see <xref target="RFC3315-22.2" format="default"/>) from the Request (see <xref target="RFC3315-22.2" format="default"/>) from the Request
message.</t> message.</t>
<t>The server examines all IAs in the message from the client.</t> <t>The server examines all IAs in the message from the client.</t>
<t>For each IA_NA option (see <xref target="RFC3315-22.4" format="defa ult"/>) in the Request <t>For each IA_NA option (see <xref target="RFC3315-22.4" format="defa ult"/>) in the Request
message, the server checks if the prefixes of included addresses are a ppropriate for message, the server checks if the prefixes of included addresses are a ppropriate for
the link to which the client is connected. If any of the prefixes of the link to which the client is connected. If any of the prefixes of
the included addresses are not appropriate for the link to which the included addresses are not appropriate for the link to which
the client is connected, the server MUST return the IA to the client the client is connected, the server <bcp14>MUST</bcp14> return the IA to the client
with a Status Code option (see <xref target="RFC3315-22.13" format="de fault"/>) with a Status Code option (see <xref target="RFC3315-22.13" format="de fault"/>)
with the value NotOnLink. If the server with the value NotOnLink. If the server
does not send the NotOnLink status code but it cannot assign any IP does not send the NotOnLink status code but it cannot assign any IP
addresses to an IA, the server MUST return the IA option in the Reply addresses to an IA, the server <bcp14>MUST</bcp14> return the IA optio n in the Reply
message with no addresses in the IA and a Status Code option message with no addresses in the IA and a Status Code option
containing status code NoAddrsAvail in the IA.</t> containing status code NoAddrsAvail in the IA.</t>
<t>For any IA_PD option (see <xref target="IA_PD-option" format="defau lt"/>) in the <t>For any IA_PD option (see <xref target="IA_PD-option" format="defau lt"/>) in the
Request message to which the server cannot assign any delegated Request message to which the server cannot assign any delegated
prefixes, the server MUST return the IA_PD prefixes, the server <bcp14>MUST</bcp14> return the IA_PD
option in the Reply message with no prefixes in the IA_PD and with a option in the Reply message with no prefixes in the IA_PD and with a
Status Code option containing status code NoPrefixAvail in the IA_PD.< /t> Status Code option containing status code NoPrefixAvail in the IA_PD.< /t>
<t>The server MAY assign different addresses and/or delegated prefixes <t>The server <bcp14>MAY</bcp14> assign different addresses and/or del egated prefixes
to an IA than those included within the IA of the client's Request to an IA than those included within the IA of the client's Request
message.</t> message.</t>
<t>For all IAs to which the server can assign addresses or delegated <t>For all IAs to which the server can assign addresses or delegated
prefixes, the server includes the IAs with addresses (for IA_NAs), prefixes, the server includes the IAs with addresses (for IA_NAs),
prefixes (for IA_PDs), and other configuration parameters prefixes (for IA_PDs), and other configuration parameters
and records the IA as a new client binding. The server MUST NOT and records the IA as a new client binding. The server <bcp14>MUST NOT </bcp14>
include any addresses or delegated prefixes in the IA that the include any addresses or delegated prefixes in the IA that the
server does not assign to the client.</t> server does not assign to the client.</t>
<t>The T1/T2 times set in each applicable IA option for a Reply MUST <t>The T1/T2 times set in each applicable IA option for a Reply <bcp14
be the same values across all IAs. The server MUST determine the >MUST</bcp14>
be the same values across all IAs. The server <bcp14>MUST</bcp14> dete
rmine the
T1/T2 times across all of the applicable client's bindings in the T1/T2 times across all of the applicable client's bindings in the
Reply. This facilitates the client being able to renew all of the Reply. This facilitates the client being able to renew all of the
bindings at the same time.</t> bindings at the same time.</t>
<t>The server SHOULD include a Reconfigure Accept option <t>The server <bcp14>SHOULD</bcp14> include a Reconfigure Accept optio n
(see <xref target="RFC3315-22.20" format="default"/>) if the server (see <xref target="RFC3315-22.20" format="default"/>) if the server
policy enables the reconfigure mechanism and the client supports it. policy enables the reconfigure mechanism and the client supports it.
Currently, sending this option in a Reply is technically redundant, Currently, sending this option in a Reply is technically redundant,
as the use of the reconfiguration mechanism requires authentication; as the use of the reconfiguration mechanism requires authentication;
at present, the only defined mechanism is RKAP (see <xref target="reco nfigure-protocol" format="default"/>), and the presence of the at present, the only defined mechanism is RKAP (see <xref target="reco nfigure-protocol" format="default"/>), and the presence of the
reconfigure key signals support for the acceptance of Reconfigure reconfigure key signals support for the acceptance of Reconfigure
messages. However, there may be better security mechanisms defined messages. However, there may be better security mechanisms defined
in the future that would cause RKAP to not be used anymore.</t> in the future that would cause RKAP to not be used anymore.</t>
<t>The server includes other options containing configuration <t>The server includes other options containing configuration
information to be returned to the client as described in <xref target= "RFC3315-18.2" format="default"/>.</t> information to be returned to the client as described in <xref target= "RFC3315-18.2" format="default"/>.</t>
<t>If the server finds that the client has included an IA in the <t>If the server finds that the client has included an IA in the
Request message for which the server already has a binding that Request message for which the server already has a binding that
associates the IA with the client, the server sends a Reply associates the IA with the client, the server sends a Reply
message with existing bindings, possibly with updated lifetimes. The message with existing bindings, possibly with updated lifetimes. The
server may update the bindings according to its local policies, but server may update the bindings according to its local policies, but
the server SHOULD generate the response again and not simply the server <bcp14>SHOULD</bcp14> generate the response again and not s imply
retransmit previously sent information, even if the retransmit previously sent information, even if the
"transaction‑id" field value matches a previous transmission. "transaction-id" field value matches a previous transmission.
The server MUST NOT cache its responses.</t> The server <bcp14>MUST NOT</bcp14> cache its responses.</t>
<t>DISCUSSION:</t> <t>DISCUSSION:</t>
<ul empty="true" spacing="normal"> <ul spacing="normal">
<li>Cached replies are bad because <li>Cached replies are bad because
lifetimes need to be updated (either decrease the timers by lifetimes need to be updated (either decrease the timers by
the amount of time elapsed since the original transmission the amount of time elapsed since the original transmission
or keep the lifetime values and update the lease or keep the lifetime values and update the lease
information in the server's database). Also, if the message uses any information in the server's database). Also, if the message uses any
security protection (such as the Replay Detection Method (RDM), security protection (such as the Replay Detection Method (RDM),
as described in <xref target="replay" format="default"/>), its value m ust be updated. as described in <xref target="replay" format="default"/>), its value m ust be updated.
Additionally, any digests must be updated. Given all of the above, Additionally, any digests must be updated. Given all of the above,
caching replies is far more complex than simply sending the caching replies is far more complex than simply sending the
same buffer as before, and it is easy to miss some of those same buffer as before, and it is easy to miss some of those
skipping to change at line 3279 skipping to change at line 3366
<name>Receipt of Confirm Messages</name> <name>Receipt of Confirm Messages</name>
<t>When the server receives a Confirm message, the server determines <t>When the server receives a Confirm message, the server determines
whether the addresses in the Confirm message are appropriate for the whether the addresses in the Confirm message are appropriate for the
link to which the client is attached. If all of the addresses in the link to which the client is attached. If all of the addresses in the
Confirm message pass this test, the server returns a status of Confirm message pass this test, the server returns a status of
Success. If any of the addresses do not pass this test, the server Success. If any of the addresses do not pass this test, the server
returns a status of NotOnLink. If the server is unable to perform returns a status of NotOnLink. If the server is unable to perform
this test (for example, the server does not have information about this test (for example, the server does not have information about
prefixes on the link to which the client is connected) or there prefixes on the link to which the client is connected) or there
were no addresses in any of the IAs sent by the client, the server were no addresses in any of the IAs sent by the client, the server
MUST NOT send a Reply to the client.</t> <bcp14>MUST NOT</bcp14> send a Reply to the client.</t>
<t>The server ignores the T1 and T2 fields in the IA options and the <t>The server ignores the T1 and T2 fields in the IA options and the
preferred-lifetime and valid-lifetime fields in the IA Address preferred-lifetime and valid-lifetime fields in the IA Address
options (see <xref target="RFC3315-22.6" format="default"/>).</t> options (see <xref target="RFC3315-22.6" format="default"/>).</t>
<t>The server constructs a Reply message by setting the "msg-type" <t>The server constructs a Reply message by setting the "msg-type"
field to REPLY and copying the transaction ID from the Confirm field to REPLY and copying the transaction ID from the Confirm
message into the "transaction‑id" field.</t> message into the "transaction-id" field.</t>
<t>The server MUST include in the Reply message a <t>The server <bcp14>MUST</bcp14> include in the Reply message a
Server Identifier option Server Identifier option
(see <xref target="RFC3315-22.3" format="default"/>) containing the (see <xref target="RFC3315-22.3" format="default"/>) containing the
server's DUID and the Client Identifier option server's DUID and the Client Identifier option
(see <xref target="RFC3315-22.2" format="default"/>) from the Confirm (see <xref target="RFC3315-22.2" format="default"/>) from the Confirm
message. The server includes a Status Code message. The server includes a Status Code
option (see <xref target="RFC3315-22.13" format="default"/>) indicatin g the option (see <xref target="RFC3315-22.13" format="default"/>) indicatin g the
status of the Confirm message.</t> status of the Confirm message.</t>
</section> </section>
<section anchor="RFC3315-18.2.3" numbered="true" toc="default"> <section anchor="RFC3315-18.2.3" numbered="true" toc="default">
<name>Receipt of Renew Messages</name> <name>Receipt of Renew Messages</name>
<t>For each IA in the Renew message from a client, the server <t>For each IA in the Renew message from a client, the server
locates the client's binding and verifies that the information in locates the client's binding and verifies that the information in
the IA from the client matches the information stored for that the IA from the client matches the information stored for that
client.</t> client.</t>
<t>If the server finds the client entry for the IA, the server sends <t>If the server finds the client entry for the IA, the server sends
the IA back to the client with new lifetimes and, if applicable, the IA back to the client with new lifetimes and, if applicable,
T1⁠/T2 times. If the server is unable to extend the lifetimes of an T1/T2 times. If the server is unable to extend the lifetimes of an
address or delegated prefix in the IA, the server MAY choose not to address or delegated prefix in the IA, the server <bcp14>MAY</bcp14> c
hoose not to
include the IA Address option (see <xref target="RFC3315-22.6" format= "default"/>) for include the IA Address option (see <xref target="RFC3315-22.6" format= "default"/>) for
that address or IA Prefix option (see <xref target="IAPREFIX-option" f ormat="default"/>) that address or IA Prefix option (see <xref target="IAPREFIX-option" f ormat="default"/>)
for that delegated prefix. If the server chooses to include the IA Add ress or for that delegated prefix. If the server chooses to include the IA Add ress or
IA Prefix option for such an address or delegated prefix, the server IA Prefix option for such an address or delegated prefix, the server
SHOULD set T1 and T2 values to the valid lifetime for the IA option un less <bcp14>SHOULD</bcp14> set T1 and T2 values to the valid lifetime for t he IA option unless
the server also includes other addresses or delegated prefixes that the server also includes other addresses or delegated prefixes that
the server is able to extend for the IA. Setting T1 and T2 the server is able to extend for the IA. Setting T1 and T2
to values equal to the valid lifetime informs the client that the leas es to values equal to the valid lifetime informs the client that the leas es
associated with said IA will not be extended, so there is no associated with said IA will not be extended, so there is no
point in trying. Also, it avoids generating unnecessary point in trying. Also, it avoids generating unnecessary
traffic as the remaining lifetime approaches 0.</t> traffic as the remaining lifetime approaches 0.</t>
<t>The server may choose to change the list of addresses or <t>The server may choose to change the list of addresses or
delegated prefixes and the lifetimes in IAs that are returned to the delegated prefixes and the lifetimes in IAs that are returned to the
client.</t> client.</t>
<t>If the server finds that any of the addresses in the IA are not <t>If the server finds that any of the addresses in the IA are not
appropriate for the link to which the client is attached, the server appropriate for the link to which the client is attached, the server
returns the address to the client with lifetimes of 0.</t> returns the address to the client with lifetimes of 0.</t>
<t>If the server finds that any of the delegated prefixes in the IA <t>If the server finds that any of the delegated prefixes in the IA
are not appropriate for the link to which the client is attached, are not appropriate for the link to which the client is attached,
the server returns the delegated prefix to the client with lifetimes the server returns the delegated prefix to the client with lifetimes
of 0.</t> of 0.</t>
<t>For each IA for which the server cannot find a client entry, the <t>For each IA for which the server cannot find a client entry, the
server has the following choices, depending on the server's policy server has the following choices, depending on the server's policy
and configuration information:</t> and configuration information:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>If the server is configured to create new <li>If the server is configured to create new
bindings as a result of processing Renew messages, the server bindings as a result of processing Renew messages, the server
SHOULD create a binding and return the IA with assigned <bcp14>SHOULD</bcp14> create a binding and return the IA with assi gned
addresses or delegated prefixes with lifetimes and, if addresses or delegated prefixes with lifetimes and, if
applicable, T1/T2 times and other information requested by the applicable, T1/T2 times and other information requested by the
client. If the client included the IA Prefix option within the client. If the client included the IA Prefix option within the
IA_PD option (see <xref target="IA_PD-option" format="default"/>) IA_PD option (see <xref target="IA_PD-option" format="default"/>)
with a zero value in the "IPv6-prefix" field and a with a zero value in the "IPv6-prefix" field and a
non-zero value in the "prefix-length" field, the server MAY use non-zero value in the "prefix-length" field, the server <bcp14>MAY </bcp14> use
the "prefix-length" value as a hint for the length of the the "prefix-length" value as a hint for the length of the
prefixes to be assigned (see <xref target="RFC8168" format="defaul t"/> prefixes to be assigned (see <xref target="RFC8168" format="defaul t"/>
for further details on prefix-length hints).</li> for further details on prefix-length hints).</li>
<li>If the server is configured to create new <li>If the server is configured to create new
bindings as a result of processing Renew messages but the bindings as a result of processing Renew messages but the
server will not assign any leases to an IA, the server returns server will not assign any leases to an IA, the server returns
the IA option containing a Status Code option the IA option containing a Status Code option
(see <xref target="RFC3315-22.13" format="default"/>) with the (see <xref target="RFC3315-22.13" format="default"/>) with the
NoAddrsAvail or NoPrefixAvail status code and a status message NoAddrsAvail or NoPrefixAvail status code and a status message
for a user.</li> for a user.</li>
<li>If the server does not support creation of new <li>If the server does not support creation of new
bindings for the client sending a Renew message or if this bindings for the client sending a Renew message or if this
behavior is disabled according to the server's policy or behavior is disabled according to the server's policy or
configuration information, the server returns the IA option configuration information, the server returns the IA option
containing a Status Code option with the NoBinding status code containing a Status Code option with the NoBinding status code
and a status message for a user.</li> and a status message for a user.</li>
</ul> </ul>
<t>The server constructs a Reply message by setting the "msg-type" <t>The server constructs a Reply message by setting the "msg-type"
field to REPLY and copying the transaction ID from the Renew message field to REPLY and copying the transaction ID from the Renew message
into the "transaction-id" field.</t> into the "transaction-id" field.</t>
<t>The server MUST include in the Reply message a <t>The server <bcp14>MUST</bcp14> include in the Reply message a
Server Identifier option Server Identifier option
(see <xref target="RFC3315-22.3" format="default"/>) containing the (see <xref target="RFC3315-22.3" format="default"/>) containing the
server's DUID and the Client Identifier option server's DUID and the Client Identifier option
(see <xref target="RFC3315-22.2" format="default"/>) from the Renew (see <xref target="RFC3315-22.2" format="default"/>) from the Renew
message.</t> message.</t>
<t>The server includes other options containing configuration <t>The server includes other options containing configuration
information to be returned to the client as described in <xref target= "RFC3315-18.2" format="default"/>.</t> information to be returned to the client as described in <xref target= "RFC3315-18.2" format="default"/>.</t>
<t>The server MAY include options containing the IAs and values for <t>The server <bcp14>MAY</bcp14> include options containing the IAs an d values for
other configuration parameters, even if those parameters were not other configuration parameters, even if those parameters were not
requested in the Renew message.</t> requested in the Renew message.</t>
<t>The T1/T2 values set in each applicable IA option for a Reply MUST <t>The T1/T2 values set in each applicable IA option for a Reply <bcp1
be the same across all IAs. The server MUST determine the 4>MUST</bcp14>
be the same across all IAs. The server <bcp14>MUST</bcp14> determine t
he
T1/T2 values across all of the applicable client's bindings in the T1/T2 values across all of the applicable client's bindings in the
Reply. This facilitates the client being able to renew all of the Reply. This facilitates the client being able to renew all of the
bindings at the same time.</t> bindings at the same time.</t>
</section> </section>
<section anchor="RFC3315-18.2.4" numbered="true" toc="default"> <section anchor="RFC3315-18.2.4" numbered="true" toc="default">
<name>Receipt of Rebind Messages</name> <name>Receipt of Rebind Messages</name>
<t>When the server receives a Rebind message that contains an IA <t>When the server receives a Rebind message that contains an IA
option from a client, it locates the client's binding and verifies option from a client, it locates the client's binding and verifies
that the information in the IA from the client matches the that the information in the IA from the client matches the
information stored for that client.</t> information stored for that client.</t>
<t>If the server finds the client entry for the IA and the server <t>If the server finds the client entry for the IA and the server
determines that the addresses or delegated prefixes in the IA are determines that the addresses or delegated prefixes in the IA are
appropriate for the link to which the client's interface is attached appropriate for the link to which the client's interface is attached
according to the server's explicit configuration information, the according to the server's explicit configuration information, the
server SHOULD send the IA back to the client with new lifetimes and, server <bcp14>SHOULD</bcp14> send the IA back to the client with new l ifetimes and,
if applicable, T1/T2 values. If the server is unable to extend the if applicable, T1/T2 values. If the server is unable to extend the
lifetimes of an address in the IA, the server MAY choose not to lifetimes of an address in the IA, the server <bcp14>MAY</bcp14> choos e not to
include the IA Address option (see <xref target="RFC3315-22.6" format= "default"/>) include the IA Address option (see <xref target="RFC3315-22.6" format= "default"/>)
for this address. If the server is for this address. If the server is
unable to extend the lifetimes of a delegated prefix in the IA, the unable to extend the lifetimes of a delegated prefix in the IA, the
server MAY choose not to include the IA Prefix option server <bcp14>MAY</bcp14> choose not to include the IA Prefix option
(see <xref target="IAPREFIX-option" format="default"/>) for this prefi x.</t> (see <xref target="IAPREFIX-option" format="default"/>) for this prefi x.</t>
<t>If the server finds that the client entry for the IA and any of <t>If the server finds that the client entry for the IA and any of
the addresses or delegated prefixes are no longer appropriate for the addresses or delegated prefixes are no longer appropriate for
the link to which the client's interface is attached according to the link to which the client's interface is attached according to
the server's explicit configuration information, the server returns the server's explicit configuration information, the server returns
those addresses or delegated prefixes to the client with lifetimes those addresses or delegated prefixes to the client with lifetimes
of 0.</t> of 0.</t>
<t>If the server cannot find a client entry for the IA, the server <t>If the server cannot find a client entry for the IA, the server
checks if the IA contains addresses (for IA_NAs) or checks if the IA contains addresses (for IA_NAs) or
delegated prefixes (for IA_PDs). The server checks if the addresses delegated prefixes (for IA_PDs). The server checks if the addresses
and delegated prefixes are appropriate for the link to which the and delegated prefixes are appropriate for the link to which the
client's interface is attached according to the server's explicit client's interface is attached according to the server's explicit
configuration information. For any address that is not appropriate configuration information. For any address that is not appropriate
for the link to which the client's interface is attached, the server for the link to which the client's interface is attached, the server
MAY include the IA Address option with lifetimes of 0. For any <bcp14>MAY</bcp14> include the IA Address option with lifetimes of 0. For any
delegated prefix that is not appropriate for the link to which the delegated prefix that is not appropriate for the link to which the
client's interface is attached, the server MAY include the IA Prefix client's interface is attached, the server <bcp14>MAY</bcp14> include the IA Prefix
option with lifetimes of 0. The Reply with lifetimes of 0 option with lifetimes of 0. The Reply with lifetimes of 0
constitutes an explicit notification to the client that the specific constitutes an explicit notification to the client that the specific
addresses and delegated prefixes are no longer valid and MUST NOT be addresses and delegated prefixes are no longer valid and <bcp14>MUST N OT</bcp14> be
used by the client. If the server chooses to not include any IAs used by the client. If the server chooses to not include any IAs
containing IA Address or IA Prefix options with lifetimes of 0 and containing IA Address or IA Prefix options with lifetimes of 0 and
the server does not include any other IAs with leases and/or status the server does not include any other IAs with leases and/or status
codes, the server does not send a Reply message. In this situation, codes, the server does not send a Reply message. In this situation,
the server discards the Rebind message.</t> the server discards the Rebind message.</t>
<t>Otherwise, for each IA for which the server cannot find a client <t>Otherwise, for each IA for which the server cannot find a client
entry, the server has the following choices, depending on the entry, the server has the following choices, depending on the
server's policy and configuration information:</t> server's policy and configuration information:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>If the server is configured to create new <li>If the server is configured to create new
bindings as a result of processing Rebind messages (also see the bindings as a result of processing Rebind messages (also see the
note below about the Rapid Commit option note below about the Rapid Commit option
(<xref target="RFC3315-22.14" format="default"/>)), the server SHO ULD (<xref target="RFC3315-22.14" format="default"/>)), the server <bc p14>SHOULD</bcp14>
create a binding and return the IA with allocated leases with create a binding and return the IA with allocated leases with
lifetimes and, if applicable, T1/T2 values and other information lifetimes and, if applicable, T1/T2 values and other information
requested by the client. The server MUST NOT return any requested by the client. The server <bcp14>MUST NOT</bcp14> return any
addresses or delegated prefixes in the IA that the server does addresses or delegated prefixes in the IA that the server does
not assign to the client.</li> not assign to the client.</li>
<li>If the server is configured to create new <li>If the server is configured to create new
bindings as a result of processing Rebind messages but the bindings as a result of processing Rebind messages but the
server will not assign any leases to an IA, the server returns server will not assign any leases to an IA, the server returns
the IA option containing a Status Code option the IA option containing a Status Code option
(see <xref target="RFC3315-22.13" format="default"/>) with the (see <xref target="RFC3315-22.13" format="default"/>) with the
NoAddrsAvail or NoPrefixAvail status code and a status message NoAddrsAvail or NoPrefixAvail status code and a status message
for a user.</li> for a user.</li>
<li>If the server does not support creation of new <li>If the server does not support creation of new
bindings for the client sending a Rebind message or if this bindings for the client sending a Rebind message or if this
behavior is disabled according to the server's policy or behavior is disabled according to the server's policy or
configuration information, the server returns the IA option configuration information, the server returns the IA option
containing a Status Code option with the NoBinding status code containing a Status Code option with the NoBinding status code
and a status message for a user.</li> and a status message for a user.</li>
</ul> </ul>
<t>When the server creates new bindings for the IA, it is possible <t>When the server creates new bindings for the IA, it is possible
that other servers also create bindings as a result of receiving the that other servers also create bindings as a result of receiving the
same Rebind message; see the "DISCUSSION" text in same Rebind message; see the "DISCUSSION" text in
<xref target="RFC3315-22.14" format="default"/>. Therefore, the server SHOULD only <xref target="RFC3315-22.14" format="default"/>. Therefore, the server <bcp14>SHOULD</bcp14> only
create new bindings during processing of a Rebind message if the create new bindings during processing of a Rebind message if the
server is configured to respond with a Reply message to a Solicit server is configured to respond with a Reply message to a Solicit
message containing the Rapid Commit option.</t> message containing the Rapid Commit option.</t>
<t>The server constructs a Reply message by setting the "msg-type" <t>The server constructs a Reply message by setting the "msg-type"
field to REPLY and copying the transaction ID from the Rebind field to REPLY and copying the transaction ID from the Rebind
message into the "transaction-id" field.</t> message into the "transaction-id" field.</t>
<t>The server MUST include in the Reply message a <t>The server <bcp14>MUST</bcp14> include in the Reply message a
Server Identifier option Server Identifier option
(see <xref target="RFC3315-22.3" format="default"/>) containing the (see <xref target="RFC3315-22.3" format="default"/>) containing the
server's DUID and the Client Identifier option server's DUID and the Client Identifier option
(see <xref target="RFC3315-22.2" format="default"/>) from the Rebind (see <xref target="RFC3315-22.2" format="default"/>) from the Rebind
message.</t> message.</t>
<t>The server includes other options containing configuration <t>The server includes other options containing configuration
information to be returned to the client as described in <xref target= "RFC3315-18.2" format="default"/>.</t> information to be returned to the client as described in <xref target= "RFC3315-18.2" format="default"/>.</t>
<t>The server MAY include options containing the IAs and values for <t>The server <bcp14>MAY</bcp14> include options containing the IAs an d values for
other configuration parameters, even if those IAs and parameters other configuration parameters, even if those IAs and parameters
were not requested in the Rebind message.</t> were not requested in the Rebind message.</t>
<t>The T1 or T2 values set in each applicable IA option for a Reply <t>The T1 or T2 values set in each applicable IA option for a Reply
MUST be the same values across all IAs. The server MUST determine <bcp14>MUST</bcp14> be the same values across all IAs. The server <bc p14>MUST</bcp14> determine
the T1 or T2 values across all of the applicable client's bindings the T1 or T2 values across all of the applicable client's bindings
in the Reply. This facilitates the client being able to renew all of in the Reply. This facilitates the client being able to renew all of
the bindings at the same time.</t> the bindings at the same time.</t>
</section> </section>
<section anchor="RFC3315-18.2.5" numbered="true" toc="default"> <section anchor="RFC3315-18.2.5" numbered="true" toc="default">
<name>Receipt of Information-request Messages</name> <name>Receipt of Information-request Messages</name>
<t>When the server receives an Information-request message, the <t>When the server receives an Information-request message, the
client is requesting configuration information that does not include client is requesting configuration information that does not include
the assignment of any leases. The server determines all the assignment of any leases. The server determines all
configuration parameters appropriate to the client, based on the configuration parameters appropriate to the client, based on the
server configuration policies known to the server.</t> server configuration policies known to the server.</t>
<t>The server constructs a Reply message by setting the "msg-type" <t>The server constructs a Reply message by setting the "msg-type"
field to REPLY and copying the transaction ID from the field to REPLY and copying the transaction ID from the
Information-request message into the "transaction‑id" field.</t> Information-request message into the "transaction-id" field.</t>
<t>The server MUST include a Server Identifier option <t>The server <bcp14>MUST</bcp14> include a Server Identifier option
(see <xref target="RFC3315-22.3" format="default"/>) containing the (see <xref target="RFC3315-22.3" format="default"/>) containing the
server's DUID in the Reply message. If the client included a Client server's DUID in the Reply message. If the client included a Client
Identifier option (see <xref target="RFC3315-22.2" format="default"/>) in the Identifier option (see <xref target="RFC3315-22.2" format="default"/>) in the
Information-request message, the server Information-request message, the server
copies that option to the Reply message.</t> copies that option to the Reply message.</t>
<t>The server includes options containing configuration information <t>The server includes options containing configuration information
to be returned to the client as described in <xref target="RFC3315-18. 2" format="default"/>. The server MAY include additional to be returned to the client as described in <xref target="RFC3315-18. 2" format="default"/>. The server <bcp14>MAY</bcp14> include additional
options that were not requested by the client in the options that were not requested by the client in the
Information-request message.</t> Information-request message.</t>
<t>If the Information-request message received from the client did <t>If the Information-request message received from the client did
not include a Client Identifier option, the server SHOULD respond not include a Client Identifier option, the server <bcp14>SHOULD</bcp1 4> respond
with a Reply message containing any configuration parameters that with a Reply message containing any configuration parameters that
are not determined by the client's identity. If the server chooses are not determined by the client's identity. If the server chooses
not to respond, the client may continue to retransmit the not to respond, the client may continue to retransmit the
Information‑request message indefinitely.</t> Information-request message indefinitely.</t>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Receipt of Release Messages</name> <name>Receipt of Release Messages</name>
<t>The server constructs a Reply message by setting the "msg-type" <t>The server constructs a Reply message by setting the "msg-type"
field to REPLY and copying the transaction ID from the Release field to REPLY and copying the transaction ID from the Release
message into the "transaction‑id" field.</t> message into the "transaction-id" field.</t>
<t>Upon the receipt of a valid Release message, the server examines <t>Upon the receipt of a valid Release message, the server examines
the IAs and the leases in the IAs for validity. If the IAs in the the IAs and the leases in the IAs for validity. If the IAs in the
message are in a binding for the client and the leases in the IAs message are in a binding for the client and the leases in the IAs
have been assigned by the server to those IAs, the server deletes have been assigned by the server to those IAs, the server deletes
the leases from the IAs and makes the leases available for the leases from the IAs and makes the leases available for
assignment to other clients. The server ignores leases not assigned assignment to other clients. The server ignores leases not assigned
to the IAs, although it may choose to log an error.</t> to the IAs, although it may choose to log an error.</t>
<t>After all the leases have been processed, the server generates a <t>After all the leases have been processed, the server generates a
Reply message and includes a Status Code option Reply message and includes a Status Code option
(see <xref target="RFC3315-22.13" format="default"/>) with the value S uccess, (see <xref target="RFC3315-22.13" format="default"/>) with the value S uccess,
skipping to change at line 3535 skipping to change at line 3622
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Receipt of Decline Messages</name> <name>Receipt of Decline Messages</name>
<t>Upon the receipt of a valid Decline message, the server examines <t>Upon the receipt of a valid Decline message, the server examines
the IAs and the addresses in the IAs for validity. If the IAs in the the IAs and the addresses in the IAs for validity. If the IAs in the
message are in a binding for the client and the addresses in the message are in a binding for the client and the addresses in the
IAs have been assigned by the server to those IAs, the server IAs have been assigned by the server to those IAs, the server
deletes the addresses from the IAs. The server ignores addresses not deletes the addresses from the IAs. The server ignores addresses not
assigned to the IAs (though it may choose to log an error if it finds assigned to the IAs (though it may choose to log an error if it finds
such addresses).</t> such addresses).</t>
<t>The client has found any addresses in the Decline messages to be <t>The client has found any addresses in the Decline messages to be
already in use on its link. Therefore, the server SHOULD mark the already in use on its link. Therefore, the server <bcp14>SHOULD</bcp14 > mark the
addresses declined by the client so that those addresses are not addresses declined by the client so that those addresses are not
assigned to other clients and MAY choose to make a notification assigned to other clients and <bcp14>MAY</bcp14> choose to make a noti fication
that addresses were declined. Local policy on the server determines that addresses were declined. Local policy on the server determines
when the addresses identified in a Decline message may be made when the addresses identified in a Decline message may be made
available for assignment.</t> available for assignment.</t>
<t>After all the addresses have been processed, the server generates <t>After all the addresses have been processed, the server generates
a Reply message by setting the "msg-type" field to REPLY and a Reply message by setting the "msg-type" field to REPLY and
copying the transaction ID from the Decline message into the copying the transaction ID from the Decline message into the
"transaction‑id" field. The server includes a Status Code option "transaction-id" field. The server includes a Status Code option
(see <xref target="RFC3315-22.13" format="default"/>) with (see <xref target="RFC3315-22.13" format="default"/>) with
the value Success, a Server Identifier option the value Success, a Server Identifier option
(see <xref target="RFC3315-22.3" format="default"/>) with the server's (see <xref target="RFC3315-22.3" format="default"/>) with the server's
DUID, and a Client Identifier option DUID, and a Client Identifier option
(see <xref target="RFC3315-22.2" format="default"/>) with the client's DUID. For (see <xref target="RFC3315-22.2" format="default"/>) with the client's DUID. For
each IA in the Decline message for which the server has no binding each IA in the Decline message for which the server has no binding
information, the server adds an IA option using the IAID from the information, the server adds an IA option using the IAID from the
Decline message and includes a Status Code option with the value Decline message and includes a Status Code option with the value
NoBinding in the IA option. No other options are included in the IA NoBinding in the IA option. No other options are included in the IA
option.</t> option.</t>
</section> </section>
<section anchor="RFC3315-17.2.2" numbered="true" toc="default"> <section anchor="RFC3315-17.2.2" numbered="true" toc="default">
<name>Creation of Advertise Messages</name> <name>Creation of Advertise Messages</name>
<t>The server sets the "msg-type" field to ADVERTISE and copies the <t>The server sets the "msg-type" field to ADVERTISE and copies the
contents of the "transaction‑id" field from the Solicit message contents of the "transaction-id" field from the Solicit message
received from the client to the Advertise message. The server received from the client to the Advertise message. The server
includes its server identifier in a Server Identifier option includes its server identifier in a Server Identifier option
(see <xref target="RFC3315-22.3" format="default"/>) and (see <xref target="RFC3315-22.3" format="default"/>) and
copies the Client Identifier option copies the Client Identifier option
(see <xref target="RFC3315-22.2" format="default"/>) from the Solicit message into (see <xref target="RFC3315-22.2" format="default"/>) from the Solicit message into
the Advertise message.</t> the Advertise message.</t>
<t>The server MAY add a Preference option <t>The server <bcp14>MAY</bcp14> add a Preference option
(see <xref target="RFC3315-22.8" format="default"/>) to carry the pref erence (see <xref target="RFC3315-22.8" format="default"/>) to carry the pref erence
value for the Advertise message. The server implementation SHOULD value for the Advertise message. The server implementation <bcp14>SHOU LD</bcp14>
allow the setting of a server preference value by the administrator. allow the setting of a server preference value by the administrator.
The server preference value MUST default to 0 unless otherwise The server preference value <bcp14>MUST</bcp14> default to 0 unless ot herwise
configured by the server administrator.</t> configured by the server administrator.</t>
<t>The server includes a Reconfigure Accept option <t>The server includes a Reconfigure Accept option
(see <xref target="RFC3315-22.20" format="default"/>) if the server (see <xref target="RFC3315-22.20" format="default"/>) if the server
wants to indicate that it supports the Reconfigure mechanism. This wants to indicate that it supports the Reconfigure mechanism. This
information may be used by the client during the server information may be used by the client during the server
selection process.</t> selection process.</t>
<t>The server includes the options the server will return to the clien t <t>The server includes the options the server will return to the clien t
in a subsequent Reply message. The information in these options may in a subsequent Reply message. The information in these options may
be used by the client in the selection of a server if the client be used by the client in the selection of a server if the client
receives more than one Advertise message. The server MUST include receives more than one Advertise message. The server <bcp14>MUST</bcp1 4> include
options in the Advertise message containing configuration parameters options in the Advertise message containing configuration parameters
for all of the options identified in the Option Request option for all of the options identified in the Option Request option
(see <xref target="RFC3315-22.7" format="default"/>) in the Solicit me ssage (see <xref target="RFC3315-22.7" format="default"/>) in the Solicit me ssage
that the server has been configured to return to the client. If the that the server has been configured to return to the client. If the
Option Request option includes a container option, the server MUST inc lude all Option Request option includes a container option, the server <bcp14>M UST</bcp14> include all
the options that are eligible to be encapsulated in the container. The Option the options that are eligible to be encapsulated in the container. The Option
Request option MAY be used to signal support for a feature even when t hat option is Request option <bcp14>MAY</bcp14> be used to signal support for a feat ure even when that option is
encapsulated, as in the case of the Prefix Exclude option <xref target ="RFC6603" format="default"/>. encapsulated, as in the case of the Prefix Exclude option <xref target ="RFC6603" format="default"/>.
In this case, special processing is required by the server. In this case, special processing is required by the server.
The server MAY return additional options to the client if it has been The server <bcp14>MAY</bcp14> return additional options to the client if it has been
configured to do so.</t> configured to do so.</t>
<t>The server MUST include IA options in the Advertise message <t>The server <bcp14>MUST</bcp14> include IA options in the Advertise message
containing any addresses and/or delegated prefixes that would be containing any addresses and/or delegated prefixes that would be
assigned to IAs contained in the Solicit message from the client. If assigned to IAs contained in the Solicit message from the client. If
the client has included addresses in the IA Address options the client has included addresses in the IA Address options
(see <xref target="RFC3315-22.6" format="default"/>) in the Solicit me ssage, (see <xref target="RFC3315-22.6" format="default"/>) in the Solicit me ssage,
the server MAY use those addresses as hints about the addresses that the server <bcp14>MAY</bcp14> use those addresses as hints about the a ddresses that
the client would like to receive. If the client has included IA the client would like to receive. If the client has included IA
Prefix options (see <xref target="IAPREFIX-option" format="default"/>) , Prefix options (see <xref target="IAPREFIX-option" format="default"/>) ,
the server MAY use the prefix contained the server <bcp14>MAY</bcp14> use the prefix contained
in the "IPv6‑prefix" field and/or the prefix length contained in the in the "IPv6-prefix" field and/or the prefix length contained in the
"prefix‑length" field as hints about the prefixes the client "prefix-length" field as hints about the prefixes the client
would like to receive. If the server is not going to assign an would like to receive. If the server is not going to assign an
address or delegated prefix received as a hint in the Solicit address or delegated prefix received as a hint in the Solicit
message, the server MUST NOT include this address or delegated message, the server <bcp14>MUST NOT</bcp14> include this address or de legated
prefix in the Advertise message.</t> prefix in the Advertise message.</t>
<t>If the server will not assign any addresses to an IA_NA <t>If the server will not assign any addresses to an IA_NA
in subsequent Request messages from the client, the server MUST in subsequent Request messages from the client, the server <bcp14>MUST </bcp14>
include the IA option in the Advertise message with no addresses in th at IA include the IA option in the Advertise message with no addresses in th at IA
and a Status Code option (see <xref target="RFC3315-22.13" format="def ault"/>) and a Status Code option (see <xref target="RFC3315-22.13" format="def ault"/>)
encapsulated in the IA option containing status code NoAddrsAvail.</t> encapsulated in the IA option containing status code NoAddrsAvail.</t>
<t>If the server will not assign any prefixes to an IA_PD in <t>If the server will not assign any prefixes to an IA_PD in
subsequent Request messages from the client, the server MUST subsequent Request messages from the client, the server <bcp14>MUST</b cp14>
include the IA_PD option (see <xref target="IA_PD-option" format="defa ult"/>) include the IA_PD option (see <xref target="IA_PD-option" format="defa ult"/>)
in the Advertise message with no prefixes in the IA_PD in the Advertise message with no prefixes in the IA_PD
option and a Status Code option encapsulated in the IA_PD containing option and a Status Code option encapsulated in the IA_PD containing
status code NoPrefixAvail.</t> status code NoPrefixAvail.</t>
<t>Transmission of Advertise messages is described in the next <t>Transmission of Advertise messages is described in the next
section.</t> section.</t>
</section> </section>
<section anchor="RFC3315-18.2.8" numbered="true" toc="default"> <section anchor="RFC3315-18.2.8" numbered="true" toc="default">
<name>Transmission of Advertise and Reply Messages</name> <name>Transmission of Advertise and Reply Messages</name>
<t>If the original message was received directly by the server, the <t>If the original message was received directly by the server, the
server unicasts the Advertise or Reply message directly to the client server unicasts the Advertise or Reply message directly to the client
using the address in the source address field from the IP datagram in which using the address in the source address field from the IP datagram in which
the original message was received. The Advertise or Reply message MUST the original message was received. The Advertise or Reply message <bcp 14>MUST</bcp14>
be unicast through the interface on which the original message was be unicast through the interface on which the original message was
received.</t> received.</t>
<t>If the original message was received in a Relay-forward message, <t>If the original message was received in a Relay-forward message,
the server constructs a Relay-reply message with the Reply message the server constructs a Relay-reply message with the Reply message
in the payload of a Relay Message option (see <xref target="RFC3315-22 .10" format="default"/>). If the Relay‑forward messages in the payload of a Relay Message option (see <xref target="RFC3315-22 .10" format="default"/>). If the Relay-forward messages
included an Interface-Id option (see <xref target="RFC3315-22.18" form at="default"/>), included an Interface-Id option (see <xref target="RFC3315-22.18" form at="default"/>),
the server copies that option to the server copies that option to
the Relay-reply message. The server unicasts the Relay-reply message the Relay-reply message. The server unicasts the Relay-reply message
directly to the relay agent using the address in the source address directly to the relay agent using the address in the source address
field from the IP datagram in which the Relay-forward message was field from the IP datagram in which the Relay-forward message was
received. See <xref target="RFC3315-20.3" format="default"/> for more details on the received. See <xref target="RFC3315-20.3" format="default"/> for more details on the
construction of Relay-reply messages.</t> construction of Relay-reply messages.</t>
</section> </section>
<section anchor="reconfigure-transmission" numbered="true" toc="default" > <section anchor="reconfigure-transmission" numbered="true" toc="default" >
<name>Creation and Transmission of Reconfigure Messages</name> <name>Creation and Transmission of Reconfigure Messages</name>
<t>The server sets the "msg-type" field to RECONFIGURE and <t>The server sets the "msg-type" field to RECONFIGURE and
sets the "transaction‑id" field to 0. The server includes a sets the "transaction-id" field to 0. The server includes a
Server Identifier option (see <xref target="RFC3315-22.3" format="defa ult"/>) Server Identifier option (see <xref target="RFC3315-22.3" format="defa ult"/>)
containing its DUID and a Client Identifier option containing its DUID and a Client Identifier option
(see <xref target="RFC3315-22.2" format="default"/>) (see <xref target="RFC3315-22.2" format="default"/>)
containing the client's DUID in the Reconfigure message.</t> containing the client's DUID in the Reconfigure message.</t>
<t>Because of the risk of denial-of-service (DoS) attacks against <t>Because of the risk of denial-of-service (DoS) attacks against
DHCP clients, the use of a security mechanism is mandated in DHCP clients, the use of a security mechanism is mandated in
Reconfigure messages. The server MUST use DHCP authentication in the Reconfigure messages. The server <bcp14>MUST</bcp14> use DHCP authenti cation in the
Reconfigure message (see <xref target="reconfigure-protocol" format="d efault"/>).</t> Reconfigure message (see <xref target="reconfigure-protocol" format="d efault"/>).</t>
<t>The server MUST include a Reconfigure Message option (see <t>The server <bcp14>MUST</bcp14> include a Reconfigure Message option (see
<xref target="RFC3315-22.19" format="default"/>) to select whether the client <xref target="RFC3315-22.19" format="default"/>) to select whether the client
responds with a Renew message, a Rebind message, or an responds with a Renew message, a Rebind message, or an
Information-request message.</t> Information-request message.</t>
<t>The server MUST NOT include any other options in the Reconfigure <t>The server <bcp14>MUST NOT</bcp14> include any other options in the Reconfigure
message, except as specifically allowed in the definition of message, except as specifically allowed in the definition of
individual options.</t> individual options.</t>
<t>A server sends each Reconfigure message to a single DHCP client, <t>A server sends each Reconfigure message to a single DHCP client,
using an IPv6 unicast address of sufficient scope belonging to the using an IPv6 unicast address of sufficient scope belonging to the
DHCP client. If the server does not have an address to which it can DHCP client. If the server does not have an address to which it can
send the Reconfigure message directly to the client, the server send the Reconfigure message directly to the client, the server
uses a Relay-reply message (as described in <xref target="RFC3315-20.3 " format="default"/>) to send the Reconfigure message to a uses a Relay-reply message (as described in <xref target="RFC3315-20.3 " format="default"/>) to send the Reconfigure message to a
relay agent that will relay the message to the client. The server relay agent that will relay the message to the client. The server
may obtain the address of the client (and the appropriate relay may obtain the address of the client (and the appropriate relay
agent, if required) through the information the server has about agent, if required) through the information the server has about
skipping to change at line 3687 skipping to change at line 3774
exchange with the server. The server interprets the receipt of a exchange with the server. The server interprets the receipt of a
Renew, Rebind, or Information-request message (whichever was Renew, Rebind, or Information-request message (whichever was
specified in the original Reconfigure message) from the client as specified in the original Reconfigure message) from the client as
satisfying the Reconfigure message request.</t> satisfying the Reconfigure message request.</t>
<t>When transmitting the Reconfigure message, the server sets <t>When transmitting the Reconfigure message, the server sets
the retransmission time (RT) to REC_TIMEOUT. If the server does the retransmission time (RT) to REC_TIMEOUT. If the server does
not receive a Renew, Rebind, or Information-request message from not receive a Renew, Rebind, or Information-request message from
the client before the RT elapses, the server retransmits the the client before the RT elapses, the server retransmits the
Reconfigure message, doubles the RT value, and waits again. Reconfigure message, doubles the RT value, and waits again.
The server continues this process until REC_MAX_RC unsuccessful The server continues this process until REC_MAX_RC unsuccessful
attempts have been made, at which point the server SHOULD abort attempts have been made, at which point the server <bcp14>SHOULD</bcp1 4> abort
the reconfigure process for that client.</t> the reconfigure process for that client.</t>
<t>Default and initial values for REC_TIMEOUT and REC_MAX_RC are <t>Default and initial values for REC_TIMEOUT and REC_MAX_RC are
documented in <xref target="RFC3315-5.5" format="default"/>.</t> documented in <xref target="RFC3315-5.5" format="default"/>.</t>
</section> </section>
</section> </section>
</section> </section>
<section anchor="RFC3315-20" numbered="true" toc="default"> <section anchor="RFC3315-20" numbered="true" toc="default">
<name>Relay Agent Behavior</name> <name>Relay Agent Behavior</name>
<t>The relay agent SHOULD be configured to use a list of destination <t>The relay agent <bcp14>SHOULD</bcp14> be configured to use a list of de stination
addresses that includes unicast addresses. The list of destination address es addresses that includes unicast addresses. The list of destination address es
MAY include the All_DHCP_Servers multicast address or other addresses sele cted by the network <bcp14>MAY</bcp14> include the All_DHCP_Servers multicast address or other addresses selected by the network
administrator. If the relay agent has not been explicitly configured, it administrator. If the relay agent has not been explicitly configured, it
MUST use the All_DHCP_Servers multicast address as the default.</t> <bcp14>MUST</bcp14> use the All_DHCP_Servers multicast address as the defa ult.</t>
<t>If the relay agent relays messages to the All_DHCP_Servers multicast <t>If the relay agent relays messages to the All_DHCP_Servers multicast
address or other multicast addresses, it sets the Hop Limit field address or other multicast addresses, it sets the Hop Limit field
to 8.</t> to 8.</t>
<t>If the relay agent receives a message other than Relay-forward and <t>If the relay agent receives a message other than Relay-forward and
Relay-reply and the relay agent does not recognize its message type, it Relay-reply and the relay agent does not recognize its message type, it
MUST forward the message as described in <xref target="relaying-from-clien t" format="default"/>.</t> <bcp14>MUST</bcp14> forward the message as described in <xref target="rela ying-from-client" format="default"/>.</t>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Relaying a Client Message or a Relay-forward Message</name> <name>Relaying a Client Message or a Relay-forward Message</name>
<t>A relay agent relays both messages from clients and Relay-forward <t>A relay agent relays both messages from clients and Relay-forward
messages from other relay agents. When a relay agent receives messages from other relay agents. When a relay agent receives
a Relay-forward message, a recognized message type for which it is a Relay-forward message, a recognized message type for which it is
not the intended target, or an unrecognized message type, not the intended target, or an unrecognized message type,
it constructs a new Relay-forward message. The it constructs a new Relay-forward message. The
relay agent copies the source address from the header of the IP relay agent copies the source address from the header of the IP
datagram in which the message was received into the peer-address field datagram in which the message was received into the peer-address field
of the Relay-forward message. The relay agent copies the received DHCP of the Relay-forward message. The relay agent copies the received DHCP
skipping to change at line 3732 skipping to change at line 3819
Agent (LDRA) that allows relay agent information to be inserted by an Agent (LDRA) that allows relay agent information to be inserted by an
access node that performs a link-layer bridging (i.e., non-routing) access node that performs a link-layer bridging (i.e., non-routing)
function.</t> function.</t>
<section anchor="relaying-from-client" numbered="true" toc="default"> <section anchor="relaying-from-client" numbered="true" toc="default">
<name>Relaying a Message from a Client</name> <name>Relaying a Message from a Client</name>
<t>If the relay agent received the message to be relayed from a <t>If the relay agent received the message to be relayed from a
client, the relay agent places a globally scoped unicast address client, the relay agent places a globally scoped unicast address
(i.e., GUA or ULA) from a prefix assigned to the link on which the (i.e., GUA or ULA) from a prefix assigned to the link on which the
client should be assigned leases into the link-address field. If client should be assigned leases into the link-address field. If
such an address is not available, the relay agent may set the such an address is not available, the relay agent may set the
link‑address field to a link-local address from the interface link-address field to a link-local address from the interface
on which the original message was received. This is not recommended, on which the original message was received. This is not recommended,
as it may require that additional information be provided in the as it may require that additional information be provided in the
server configuration. See Section 3.2 of server configuration. See
<xref target="RFC7969" format="default"/> for a detailed discussion.</ <xref target="RFC7969" sectionFormat="of" section="3.2"/> for a detail
t> ed discussion.</t>
<t>This address will be used by the server to determine the link <t>This address will be used by the server to determine the link
from which the client should be assigned leases and other from which the client should be assigned leases and other
configuration information.</t> configuration information.</t>
<t>The hop-count value in the Relay-forward message is set to <t>The hop-count value in the Relay-forward message is set to
0.</t> 0.</t>
<t>The relay SHOULD insert a Client Link-Layer Address option as descr ibed <t>The relay <bcp14>SHOULD</bcp14> insert a Client Link-Layer Address option as described
in <xref target="RFC6939" format="default"/>.</t> in <xref target="RFC6939" format="default"/>.</t>
<t>If the relay agent cannot use the address in the link-address <t>If the relay agent cannot use the address in the link-address
field to identify the interface through which the response to the field to identify the interface through which the response to the
client will be relayed, the relay agent MUST include an Interface-Id client will be relayed, the relay agent <bcp14>MUST</bcp14> include an Interface-Id
option (see <xref target="RFC3315-22.18" format="default"/>) in the option (see <xref target="RFC3315-22.18" format="default"/>) in the
Relay-forward message. The server will include the Interface-Id Relay-forward message. The server will include the Interface-Id
option in its Relay-reply message. The relay agent sets the option in its Relay-reply message. The relay agent sets the
link-address field as described earlier in this subsection, link-address field as described earlier in this subsection,
regardless of whether the relay agent includes an Interface-Id regardless of whether the relay agent includes an Interface-Id
option in the Relay-forward message.</t> option in the Relay-forward message.</t>
</section> </section>
<section anchor="relaying-from-relay-agent" numbered="true" toc="default "> <section anchor="relaying-from-relay-agent" numbered="true" toc="default ">
<name>Relaying a Message from a Relay Agent</name> <name>Relaying a Message from a Relay Agent</name>
<t>If the message received by the relay agent is a Relay-forward <t>If the message received by the relay agent is a Relay-forward
message and the hop-count value in the message is greater than or message and the hop-count value in the message is greater than or
equal to HOP_COUNT_LIMIT, the relay agent discards the received equal to HOP_COUNT_LIMIT, the relay agent discards the received
message.</t> message.</t>
<t>The relay agent copies the source address from the IP datagram in <t>The relay agent copies the source address from the IP datagram in
which the message was received into the which the message was received into the
peer‑address field in the Relay-forward message and sets the peer-address field in the Relay-forward message and sets the
hop‑count field to the value of the hop-count field in the hop-count field to the value of the hop-count field in the
received message incremented by 1.</t> received message incremented by 1.</t>
<t>If the source address from the IP datagram header of the received <t>If the source address from the IP datagram header of the received
message is a globally scoped unicast address (i.e., GUA or ULA), message is a globally scoped unicast address (i.e., GUA or ULA),
the relay agent sets the link-address field to 0; otherwise, the the relay agent sets the link-address field to 0; otherwise, the
relay agent sets the link-address field to a globally scoped unicast relay agent sets the link-address field to a globally scoped unicast
address (i.e., GUA or ULA) assigned to the interface on which the address (i.e., GUA or ULA) assigned to the interface on which the
message was received or includes an Interface-Id option (see message was received or includes an Interface-Id option (see
<xref target="RFC3315-22.18" format="default"/>) to identify the inter face on which <xref target="RFC3315-22.18" format="default"/>) to identify the inter face on which
the message was received.</t> the message was received.</t>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Relay Agent Behavior with Prefix Delegation</name> <name>Relay Agent Behavior with Prefix Delegation</name>
<t>A relay agent forwards messages containing prefix delegation <t>A relay agent forwards messages containing prefix delegation
options in the same way as it would relay addresses (i.e., per options in the same way as it would relay addresses (i.e., per
Sections <xref target="relaying-from-client" format="counter"/> Sections <xref target="relaying-from-client" format="counter"/>
and <xref target="relaying-from-relay-agent" format="counter"/>).</t> and <xref target="relaying-from-relay-agent" format="counter"/>).</t>
<t>If a server communicates with a client through a relay agent <t>If a server communicates with a client through a relay agent
about delegated prefixes, the server may need a protocol or about delegated prefixes, the server may need a protocol or
other out‑of‑band communication to configure routing other out-of-band communication to configure routing
information for delegated prefixes on any router through which the information for delegated prefixes on any router through which the
client may forward traffic.</t> client may forward traffic.</t>
</section> </section>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Relaying a Relay-reply Message</name> <name>Relaying a Relay-reply Message</name>
<t>The relay agent processes any options included in the Relay-reply <t>The relay agent processes any options included in the Relay-reply
message in addition to the Relay Message option message in addition to the Relay Message option
(see <xref target="RFC3315-22.10" format="default"/>).</t> (see <xref target="RFC3315-22.10" format="default"/>).</t>
<t>The relay agent extracts the message from the Relay Message option <t>The relay agent extracts the message from the Relay Message option
and relays it to the address contained in the peer-address field of and relays it to the address contained in the peer-address field of
the Relay-reply message. Relay agents MUST NOT modify the message.</t> the Relay-reply message. Relay agents <bcp14>MUST NOT</bcp14> modify the message.</t>
<t>If the Relay-reply message includes an Interface-Id option <t>If the Relay-reply message includes an Interface-Id option
(see <xref target="RFC3315-22.18" format="default"/>), the (see <xref target="RFC3315-22.18" format="default"/>), the
relay agent relays the message from the server to the client on the relay agent relays the message from the server to the client on the
link identified by the Interface-Id option. Otherwise, if the link identified by the Interface-Id option. Otherwise, if the
link-address field is not set to 0, the relay agent relays the link-address field is not set to 0, the relay agent relays the
message on the link identified by the link-address field.</t> message on the link identified by the link-address field.</t>
<t>If the relay agent receives a Relay-reply message, it MUST process <t>If the relay agent receives a Relay-reply message, it <bcp14>MUST</bc p14> process
the message as defined above, regardless of the type of message the message as defined above, regardless of the type of message
encapsulated in the Relay Message option.</t> encapsulated in the Relay Message option.</t>
</section> </section>
<section anchor="RFC3315-20.3" numbered="true" toc="default"> <section anchor="RFC3315-20.3" numbered="true" toc="default">
<name>Construction of Relay-reply Messages</name> <name>Construction of Relay-reply Messages</name>
<t>A server uses a Relay-reply message to (1) return a response to a <t>A server uses a Relay-reply message to (1) return a response to a
client if the original message from the client was relayed to the client if the original message from the client was relayed to the
server in a Relay-forward message or (2) send a Reconfigure message server in a Relay-forward message or (2) send a Reconfigure message
to a client if the server does not have an address it can use to to a client if the server does not have an address it can use to
send the message directly to the client.</t> send the message directly to the client.</t>
<t>A response to the client MUST be relayed through the same relay <t>A response to the client <bcp14>MUST</bcp14> be relayed through the s ame relay
agents as the original client message. The server causes this to agents as the original client message. The server causes this to
happen by creating a Relay-reply message that includes a Relay Message happen by creating a Relay-reply message that includes a Relay Message
option (see <xref target="RFC3315-22.10" format="default"/>) option (see <xref target="RFC3315-22.10" format="default"/>)
containing the message for the next relay agent in the return containing the message for the next relay agent in the return
path to the client. The contained Relay-reply message contains another path to the client. The contained Relay-reply message contains another
Relay Message option to be sent to the next relay agent, and so on. Relay Message option to be sent to the next relay agent, and so on.
The server must record the contents of the peer-address fields in the The server must record the contents of the peer-address fields in the
received message so it can construct the appropriate Relay-reply received message so it can construct the appropriate Relay-reply
message carrying the response from the server.</t> message carrying the response from the server.</t>
<t>For example, if client C sent a message that was relayed by relay <t>For example, if client C sent a message that was relayed by relay
skipping to change at line 3837 skipping to change at line 3924
<artwork align="left" name="" type="" alt=""><![CDATA[ <artwork align="left" name="" type="" alt=""><![CDATA[
msg-type: RELAY-REPL msg-type: RELAY-REPL
hop-count: 1 hop-count: 1
link-address: 0 link-address: 0
peer-address: A peer-address: A
Relay Message option containing the following: Relay Message option containing the following:
msg-type: RELAY-REPL msg-type: RELAY-REPL
hop-count: 0 hop-count: 0
link-address: address from link to which C is attached link-address: address from link to which C is attached
peer-address: C peer-address: C
Relay Message option: <response from server> Relay Message option: <response from server>]]></artwork>
]]></artwork>
</figure> </figure>
<t>When sending a Reconfigure message to a client through a relay <t>When sending a Reconfigure message to a client through a relay
agent, the server creates a Relay-reply message that includes a Relay agent, the server creates a Relay-reply message that includes a Relay
Message option containing the Reconfigure message for the next relay Message option containing the Reconfigure message for the next relay
agent in the return path to the client. The server sets the agent in the return path to the client. The server sets the
peer‑address field in the Relay-reply message header to the peer-address field in the Relay-reply message header to the
address of the client and sets the link-address field as required by address of the client and sets the link-address field as required by
the relay agent to relay the Reconfigure message to the client. The the relay agent to relay the Reconfigure message to the client. The
server obtains the addresses of the client and the relay agent through server obtains the addresses of the client and the relay agent through
prior interaction with the client or through some external prior interaction with the client or through some external
mechanism.</t> mechanism.</t>
</section> </section>
<section anchor="relay-srv-interaction" numbered="true" toc="default"> <section anchor="relay-srv-interaction" numbered="true" toc="default">
<name>Interaction between Relay Agents and Servers</name> <name>Interaction Between Relay Agents and Servers</name>
<t>Each time a message is relayed by a relay agent towards a server, a <t>Each time a message is relayed by a relay agent towards a server, a
new encapsulation level is added around the message. Each relay is new encapsulation level is added around the message. Each relay is
allowed to insert additional options on the encapsulation level it allowed to insert additional options on the encapsulation level it
added but MUST NOT change anything in the message being encapsulated. If added but <bcp14>MUST NOT</bcp14> change anything in the message being e ncapsulated. If
there are multiple relays between a client and a server, multiple there are multiple relays between a client and a server, multiple
encapsulations are used. Although it makes message processing slightly encapsulations are used. Although it makes message processing slightly
more complex, it provides the major advantage of having a clear more complex, it provides the major advantage of having a clear
indication as to which relay inserted which option. The response indication as to which relay inserted which option. The response
message is expected to travel through the same relays, but in message is expected to travel through the same relays, but in
reverse order. Each time a response message is relayed back towards a reverse order. Each time a response message is relayed back towards a
client, one encapsulation level is removed.</t> client, one encapsulation level is removed.</t>
<t>In certain cases, relays can add one or more options. These options <t>In certain cases, relays can add one or more options. These options
can be added for several reasons:</t> can be added for several reasons:</t>
<ul spacing="normal"> <ul spacing="normal">
skipping to change at line 3902 skipping to change at line 3988
and/or prefixes that were assigned via a specific relay. A second is and/or prefixes that were assigned via a specific relay. A second is
for the reconfigure mechanism. The server may choose to not send the for the reconfigure mechanism. The server may choose to not send the
Reconfigure message directly to the client but rather to send it via Reconfigure message directly to the client but rather to send it via
relays. This particular behavior is considered an implementation relays. This particular behavior is considered an implementation
detail and is out of scope for this document.</t> detail and is out of scope for this document.</t>
</section> </section>
</section> </section>
<section anchor="RFC3315-21" numbered="true" toc="default"> <section anchor="RFC3315-21" numbered="true" toc="default">
<name>Authentication of DHCP Messages</name> <name>Authentication of DHCP Messages</name>
<t>This document introduces two security mechanisms for the <t>This document introduces two security mechanisms for the
authentication of DHCP messages: (1) authentication (and authentication of DHCP messages: (1) authentication (and
encryption) of messages sent between servers and relay agents using encryption) of messages sent between servers and relay agents using
IPsec and (2) protection against misconfiguration of a client IPsec and (2) protection against misconfiguration of a client
caused by a Reconfigure message sent by a malicious DHCP server.</t> caused by a Reconfigure message sent by a malicious DHCP server.</t>
<section anchor="RFC3315-21.1" numbered="true" toc="default"> <section anchor="RFC3315-21.1" numbered="true" toc="default">
<name>Security of Messages Sent between Servers and Relay Agents</name> <name>Security of Messages Sent Between Servers and Relay Agents</name>
<t>Relay agents and servers that exchange messages can use <t>Relay agents and servers that exchange messages can use
IPsec as detailed in <xref target="RFC8213" format="default"/>. IPsec as detailed in <xref target="RFC8213" format="default"/>.
</t> </t>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Summary of DHCP Authentication</name> <name>Summary of DHCP Authentication</name>
<t>Authentication of DHCP messages is accomplished through the use of <t>Authentication of DHCP messages is accomplished through the use of
the Authentication option (see <xref target="RFC3315-22.11" format="defa ult"/>). the Authentication option (see <xref target="RFC3315-22.11" format="defa ult"/>).
The authentication information carried in the Authentication option The authentication information carried in the Authentication option
can be used to reliably identify the source of a DHCP message and to can be used to reliably identify the source of a DHCP message and to
confirm that the contents of the DHCP message have not been tampered confirm that the contents of the DHCP message have not been tampered
with.</t> with.</t>
<t>The Authentication option provides a framework for multiple <t>The Authentication option provides a framework for multiple
authentication protocols. One such protocol, RKAP, is defined in <xref t arget="reconfigure-protocol" format="default"/>. Other protocols defined in the future authentication protocols. One such protocol, RKAP, is defined in <xref t arget="reconfigure-protocol" format="default"/>. Other protocols defined in the future
will be specified in separate documents.</t> will be specified in separate documents.</t>
<t>Any DHCP message MUST NOT include more than one Authentication <t>Any DHCP message <bcp14>MUST NOT</bcp14> include more than one Authen tication
option.</t> option.</t>
<t>The protocol field in the Authentication option identifies the <t>The protocol field in the Authentication option identifies the
specific protocol used to generate the authentication information specific protocol used to generate the authentication information
carried in the option. The algorithm field identifies a specific carried in the option. The algorithm field identifies a specific
algorithm within the authentication protocol; for example, the algorithm within the authentication protocol; for example, the
algorithm field specifies the hash algorithm used to generate the algorithm field specifies the hash algorithm used to generate the
Message Authentication Code (MAC) in the Authentication option. The Message Authentication Code (MAC) in the Authentication option. The
RDM field specifies the type of replay detection used in the RDM field specifies the type of replay detection used in the
replay detection field.</t> replay detection field.</t>
</section> </section>
<section anchor="replay" numbered="true" toc="default"> <section anchor="replay" numbered="true" toc="default">
<name>Replay Detection</name> <name>Replay Detection</name>
<t>The RDM field of the Authentication option <t>The RDM field of the Authentication option
(see <xref target="RFC3315-22.11" format="default"/>) determines the typ e of (see <xref target="RFC3315-22.11" format="default"/>) determines the typ e of
replay detection used in the replay detection field.</t> replay detection used in the replay detection field.</t>
<t>If the RDM field contains 0x00, the replay detection field MUST be <t>If the RDM field contains 0x00, the replay detection field <bcp14>MUS T</bcp14> be
set to the value of a strictly monotonically increasing 64-bit unsigned set to the value of a strictly monotonically increasing 64-bit unsigned
integer (modulo 2^64). Using this technique can reduce the danger integer (modulo 2^64). Using this technique can reduce the danger
of replay attacks. This method MUST be supported by all Authentication of replay attacks. This method <bcp14>MUST</bcp14> be supported by all A uthentication
option protocols. One choice might be to use the 64-bit NTP timestamp option protocols. One choice might be to use the 64-bit NTP timestamp
format <xref target="RFC5905" format="default"/>).</t> format <xref target="RFC5905" format="default"/>).</t>
<t>A client that receives a message with the RDM field set to 0x00 MUST <t>A client that receives a message with the RDM field set to 0x00 <bcp1 4>MUST</bcp14>
compare its replay detection field with the previous value sent by compare its replay detection field with the previous value sent by
that same server (based on the Server Identifier option; see that same server (based on the Server Identifier option; see
<xref target="RFC3315-22.3" format="default"/>) and only accept the mess age if the <xref target="RFC3315-22.3" format="default"/>) and only accept the mess age if the
received value is greater and record this as the new value. If this received value is greater and record this as the new value. If this
is the first time a client processes an Authentication option sent by is the first time a client processes an Authentication option sent by
a server, the client MUST record the replay detection value and skip a server, the client <bcp14>MUST</bcp14> record the replay detection val ue and skip
the replay detection check.</t> the replay detection check.</t>
<t>Servers that support the reconfigure mechanism MUST ensure that <t>Servers that support the reconfigure mechanism <bcp14>MUST</bcp14> en sure that
the replay detection value is retained between restarts. Failing to the replay detection value is retained between restarts. Failing to
do so may cause clients to refuse Reconfigure messages sent by the do so may cause clients to refuse Reconfigure messages sent by the
server, effectively rendering the reconfigure mechanism useless.</t> server, effectively rendering the reconfigure mechanism useless.</t>
</section> </section>
<section anchor="reconfigure-protocol" numbered="true" toc="default"> <section anchor="reconfigure-protocol" numbered="true" toc="default">
<name>Reconfiguration Key Authentication Protocol (RKAP)</name> <name>Reconfiguration Key Authentication Protocol (RKAP)</name>
<t>RKAP provides protection against misconfiguration of a client <t>RKAP provides protection against misconfiguration of a client
caused by a Reconfigure message sent by a malicious DHCP server. In caused by a Reconfigure message sent by a malicious DHCP server. In
this protocol, a DHCP server sends a reconfigure key to the client in this protocol, a DHCP server sends a reconfigure key to the client in
the initial exchange of DHCP messages. The client records the the initial exchange of DHCP messages. The client records the
skipping to change at line 3982 skipping to change at line 4068
the authentication information is defined in the following the authentication information is defined in the following
section.</t> section.</t>
<t>RKAP is used (initiated by the server) only <t>RKAP is used (initiated by the server) only
if the client and server have negotiated to use Reconfigure if the client and server have negotiated to use Reconfigure
messages.</t> messages.</t>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Use of the Authentication Option in RKAP</name> <name>Use of the Authentication Option in RKAP</name>
<t>The following fields are set in an Authentication option <t>The following fields are set in an Authentication option
(see <xref target="RFC3315-22.11" format="default"/>) for RKAP: (see <xref target="RFC3315-22.11" format="default"/>) for RKAP:
</t> </t>
<dl newline="false" spacing="normal" indent="14"> <ul spacing="normal">
<dt> protocol</dt> <li>protocol: 3</li>
<dd>3</dd> <li>algorithm: 1</li>
<dt> algorithm</dt> <li>RDM: 0</li>
<dd>1</dd> </ul>
<dt> RDM</dt>
<dd>0</dd>
</dl>
<t>The format of the authentication information for RKAP is:</t> <t>The format of the authentication information for RKAP is:</t>
<figure anchor="FigRKAPAuthInfo"> <figure anchor="FigRKAPAuthInfo">
<name>RKAP Authentication Information</name> <name>RKAP Authentication Information</name>
<artwork align="left" name="" type="" alt=""><![CDATA[ <artwork align="left" name="" type="" alt=""><![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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Value (128 bits) | | Type | Value (128 bits) |
+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+ |
. . . .
. . . .
. +-+-+-+-+-+-+-+-+ . +-+-+-+-+-+-+-+-+
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
]]></artwork>
</figure> </figure>
<dl newline="false" spacing="normal" indent="20"> <dl>
<dt> Type</dt> <dt>Type:</dt><dd><t>Type of data in the Value field carried in this
<dd> option:</t>
<t>Type of data in the Value field carried in <dl>
this option: <dt>1</dt><dd>Reconfigure key value (used in the Reply message).
</t> </dd>
<dl newline="false" spacing="normal" indent="8"> <dt>2</dt><dd>HMAC-MD5 digest of the message (used in the Reconf
<dt> 1</dt> igure
<dd>Reconfigure key value (used in the Reply message).</dd>
message).</dd>
<dt> 2</dt>
<dd>HMAC-MD5 digest of the message (used in
the Reconfigure message).</dd>
</dl> </dl>
<t> <t>A 1-octet field.</t>
A 1‑octet field.</t> </dd>
</dd> <dt>Value:</dt><dd> Data as defined by the Type field. A 16-octet
<dt> Value</dt> field.</dd>
<dd>Data as defined by the Type field. A
16-octet field.</dd>
</dl> </dl>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Server Considerations for RKAP</name> <name>Server Considerations for RKAP</name>
<t>The server selects a reconfigure key for a client during the <t>The server selects a reconfigure key for a client during the
Request⁠/Reply, Solicit/Reply, or Information-request/Reply Request/Reply, Solicit/Reply, or Information-request/Reply
message exchange. The server records the reconfigure key and message exchange. The server records the reconfigure key and
transmits that key to the client in an Authentication option transmits that key to the client in an Authentication option
(see <xref target="RFC3315-22.11" format="default"/>) in the Reply mes sage.</t> (see <xref target="RFC3315-22.11" format="default"/>) in the Reply mes sage.</t>
<t>The reconfigure key is 128 bits long and MUST be a <t>The reconfigure key is 128 bits long and <bcp14>MUST</bcp14> be a
cryptographically strong random or pseudorandom number that cannot cryptographically strong random or pseudorandom number that cannot
easily be predicted.</t> easily be predicted.</t>
<t>To provide authentication for a Reconfigure message, the server <t>To provide authentication for a Reconfigure message, the server
selects a replay detection value according to the RDM selected by selects a replay detection value according to the RDM selected by
the server and computes an HMAC-MD5 of the Reconfigure message the server and computes an HMAC-MD5 of the Reconfigure message
using the reconfigure key for the client. The server computes the using the reconfigure key for the client. The server computes the
HMAC-MD5 over the entire DHCP Reconfigure message, including the HMAC-MD5 over the entire DHCP Reconfigure message, including the
Authentication option; the HMAC-MD5 field in the Authentication Authentication option; the HMAC-MD5 field in the Authentication
option is set to 0 for the HMAC-MD5 computation. The server option is set to 0 for the HMAC-MD5 computation. The server
includes the HMAC-MD5 in the authentication information field in an includes the HMAC-MD5 in the authentication information field in an
skipping to change at line 4057 skipping to change at line 4131
the client.</t> the client.</t>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Client Considerations for RKAP</name> <name>Client Considerations for RKAP</name>
<t>The client will receive a reconfigure key from the server in an <t>The client will receive a reconfigure key from the server in an
Authentication option (see <xref target="RFC3315-22.11" format="defaul t"/>) in the Authentication option (see <xref target="RFC3315-22.11" format="defaul t"/>) in the
initial Reply message from the server. The client records the initial Reply message from the server. The client records the
reconfigure key for use in authenticating subsequent Reconfigure reconfigure key for use in authenticating subsequent Reconfigure
messages.</t> messages.</t>
<t>To authenticate a Reconfigure message, the client computes an <t>To authenticate a Reconfigure message, the client computes an
HMAC‑MD5 over the Reconfigure message, with zeroes substituted HMAC-MD5 over the Reconfigure message, with zeroes substituted
for the HMAC-MD5 field, using the reconfigure key received for the HMAC-MD5 field, using the reconfigure key received
from the server. If this computed HMAC-MD5 matches the from the server. If this computed HMAC-MD5 matches the
value in the Authentication option, the client accepts the value in the Authentication option, the client accepts the
Reconfigure message.</t> Reconfigure message.</t>
</section> </section>
</section> </section>
</section> </section>
<section anchor="RFC3315-22" numbered="true" toc="default"> <section anchor="RFC3315-22" numbered="true" toc="default">
<name>DHCP Options</name> <name>DHCP Options</name>
<t>Options are used to carry additional information and parameters in <t>Options are used to carry additional information and parameters in
skipping to change at line 4080 skipping to change at line 4154
represented in network byte order.</t> represented in network byte order.</t>
<t>This document specifies the DHCP options defined as part of this base <t>This document specifies the DHCP options defined as part of this base
DHCP specification. Other options have been or may be defined in the futur e in DHCP specification. Other options have been or may be defined in the futur e in
separate documents. See <xref target="RFC7227" format="default"/> for guid elines regarding separate documents. See <xref target="RFC7227" format="default"/> for guid elines regarding
the definition of new options. the definition of new options.
See <xref target="iana" format="default"/> for additional information abou t the See <xref target="iana" format="default"/> for additional information abou t the
DHCPv6 "Option Codes" registry maintained by IANA.</t> DHCPv6 "Option Codes" registry maintained by IANA.</t>
<t>Unless otherwise noted, each option may appear only in the options <t>Unless otherwise noted, each option may appear only in the options
area of a DHCP message and may appear only once. If an option does area of a DHCP message and may appear only once. If an option does
appear multiple times, each instance is considered separate and the data appear multiple times, each instance is considered separate and the data
areas of the options MUST NOT be concatenated or otherwise combined.</t> areas of the options <bcp14>MUST NOT</bcp14> be concatenated or otherwise combined.</t>
<t>Options that are allowed to appear only once are called "singleton <t>Options that are allowed to appear only once are called "singleton
options". The only non-singleton options defined in this document are options". The only non-singleton options defined in this document are
the IA_NA (see <xref target="RFC3315-22.4" format="default"/>), the IA_NA (see <xref target="RFC3315-22.4" format="default"/>),
Vendor Class (see <xref target="RFC3315-22.16" format="default"/>), Vendor Class (see <xref target="RFC3315-22.16" format="default"/>),
Vendor-specific Information (see <xref target="RFC3315-22.17" format="defa ult"/>), Vendor-specific Information (see <xref target="RFC3315-22.17" format="defa ult"/>),
and IA_PD (see <xref target="IA_PD-option" format="default"/>) options. Al so, IA Address (see <xref target="RFC3315-22.6" format="default"/>) and IA Prefi x (see <xref target="IAPREFIX-option" format="default"/>) may appear in their re spective IA and IA_PD (see <xref target="IA_PD-option" format="default"/>) options. Al so, IA Address (see <xref target="RFC3315-22.6" format="default"/>) and IA Prefi x (see <xref target="IAPREFIX-option" format="default"/>) may appear in their re spective IA
options more than once.</t> options more than once.</t>
<section anchor="RFC3315-22.1" numbered="true" toc="default"> <section anchor="RFC3315-22.1" numbered="true" toc="default">
<name>Format of DHCP Options</name> <name>Format of DHCP Options</name>
<t>The format of DHCP options is:</t> <t>The format of DHCP options is:</t>
<figure anchor="FigOptions"> <figure anchor="FigOptions">
<name>Option Format</name> <name>Option Format</name>
<artwork align="left" name="" type="" alt=""><![CDATA[ <artwork align="left" name="" type="" alt=""><![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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option-code | option-len | | option-code | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option-data | | option-data |
| (option-len octets) | | (option-len octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
]]></artwork>
</figure> </figure>
<dl newline="false" spacing="normal" indent="24"> <dl>
<dt> option-code</dt> <dt>option-code:</dt><dd> An unsigned integer identifying the specific
<dd>An unsigned integer identifying the option
specific option type carried in this option. type carried in this option. A 2-octet field.</dd>
A 2‑octet field.</dd> <dt>option-len:</dt><dd> An unsigned integer giving the length of the
<dt> option-len</dt> option-data field in this option in octets. A 2-octet field.</dd>
<dd>An unsigned integer giving the length <dt>option-data:</dt><dd> The data for the option; the format of this
of the option-data field in this option in octets. A 2-octet data
field.</dd> depends on the definition of the option. A variable-length field
<dt> option-data</dt> (the length, in octets, is specified by option-len).</dd>
<dd>The data for the option; the format
of this data depends on the definition of the option. A
variable-length field (the length, in octets, is specified by
option-len).</dd>
</dl> </dl>
<t>DHCP options are scoped by using encapsulation. Some options <t>DHCP options are scoped by using encapsulation. Some options
apply generally to the client, some are specific to an IA, and some apply generally to the client, some are specific to an IA, and some
are specific to the addresses within an IA. These latter two cases are are specific to the addresses within an IA. These latter two cases are
discussed in Sections <xref target="RFC3315-22.4" format="counter"/>, <x ref target="RFC3315-22.5" format="counter"/>, discussed in Sections <xref target="RFC3315-22.4" format="counter"/>, <x ref target="RFC3315-22.5" format="counter"/>,
and <xref target="RFC3315-22.6" format="counter"/>.</t> and <xref target="RFC3315-22.6" format="counter"/>.</t>
</section> </section>
<section anchor="RFC3315-22.2" numbered="true" toc="default"> <section anchor="RFC3315-22.2" numbered="true" toc="default">
<name>Client Identifier Option</name> <name>Client Identifier Option</name>
<t>The Client Identifier option is used to carry a DUID (see <xref targe t="RFC3315-9" format="default"/>) that identifies the client. <t>The Client Identifier option is used to carry a DUID (see <xref targe t="RFC3315-9" format="default"/>) that identifies the client.
The format of the Client Identifier option is:</t> The format of the Client Identifier option is:</t>
<figure anchor="FigOption1"> <figure anchor="FigOption1">
<name>Client Identifier Option Format</name> <name>Client Identifier Option Format</name>
<artwork align="left" name="" type="" alt=""><![CDATA[ <artwork align="left" name="" type="" alt=""><![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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_CLIENTID | option-len | | OPTION_CLIENTID | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . . .
. DUID . . DUID .
. (variable length) . . (variable length) .
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
]]></artwork>
</figure> </figure>
<dl newline="false" spacing="normal" indent="24"> <dl>
<dt> option-code</dt> <dt>option-code:</dt><dd> OPTION_CLIENTID (1).</dd>
<dd>OPTION_CLIENTID (1).</dd> <dt>option-len:</dt><dd> Length of DUID in octets.</dd>
<dt> option-len</dt> <dt>DUID:</dt><dd> The DUID for the client.</dd>
<dd>Length of DUID in octets.</dd>
<dt> DUID</dt>
<dd>The DUID for the client.</dd>
</dl> </dl>
</section> </section>
<section anchor="RFC3315-22.3" numbered="true" toc="default"> <section anchor="RFC3315-22.3" numbered="true" toc="default">
<name>Server Identifier Option</name> <name>Server Identifier Option</name>
<t>The Server Identifier option is used to carry a DUID (see <xref targe t="RFC3315-9" format="default"/>) that identifies the server. The format of the <t>The Server Identifier option is used to carry a DUID (see <xref targe t="RFC3315-9" format="default"/>) that identifies the server. The format of the
Server Identifier option is:</t> Server Identifier option is:</t>
<figure anchor="FigOption2"> <figure anchor="FigOption2">
<name>Server Identifier Option Format</name> <name>Server Identifier Option Format</name>
<artwork align="left" name="" type="" alt=""><![CDATA[ <artwork align="left" name="" type="" alt=""><![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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_SERVERID | option-len | | OPTION_SERVERID | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . . .
. DUID . . DUID .
. (variable length) . . (variable length) .
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
]]></artwork>
</figure> </figure>
<dl newline="false" spacing="normal" indent="24"> <dl>
<dt> option-code</dt> <dt>option-code:</dt><dd> OPTION_SERVERID (2).</dd>
<dd>OPTION_SERVERID (2).</dd> <dt>option-len:</dt><dd> Length of DUID in octets.</dd>
<dt> option-len</dt> <dt>DUID:</dt><dd> The DUID for the server.</dd>
<dd>Length of DUID in octets.</dd>
<dt> DUID</dt>
<dd>The DUID for the server.</dd>
</dl> </dl>
</section> </section>
<section anchor="RFC3315-22.4" numbered="true" toc="default"> <section anchor="RFC3315-22.4" numbered="true" toc="default">
<name>Identity Association for Non-temporary Addresses Option</name> <name>Identity Association for Non-Temporary Addresses Option</name>
<t>The Identity Association for Non-temporary Addresses (IA_NA) <t>The Identity Association for Non-temporary Addresses (IA_NA)
option is used to carry an IA_NA, the parameters associated with the option is used to carry an IA_NA, the parameters associated with the
IA_NA, and the non-temporary addresses associated with the IA_NA.</t> IA_NA, and the non-temporary addresses associated with the IA_NA.</t>
<t>A client that needs a short-term / special purpose address can use <t>A client that needs a short-term / special-purpose address can use
a new IA_NA binding to request an address and release it when a new IA_NA binding to request an address and release it when
finished with it. </t> finished with it. </t>
<t>Note: Addresses appearing in an IA_NA option are not temporary addres ses <t>Note: Addresses appearing in an IA_NA option are not temporary addres ses
(see <xref target="RFC3315-22.5" format="default"/>).</t> (see <xref target="RFC3315-22.5" format="default"/>).</t>
<t>The format of the IA_NA option is:</t> <t>The format of the IA_NA option is:</t>
<figure anchor="FigOption3"> <figure anchor="FigOption3">
<name>Identity Association for Non-temporary Addresses Option Format</ name> <name>Identity Association for Non-Temporary Addresses Option Format</ name>
<artwork align="left" name="" type="" alt=""><![CDATA[ <artwork align="left" name="" type="" alt=""><![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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_IA_NA | option-len | | OPTION_IA_NA | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IAID (4 octets) | | IAID (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| T1 | | T1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| T2 | | T2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
. IA_NA-options . . IA_NA-options .
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
]]></artwork>
</figure> </figure>
<dl newline="false" spacing="normal" indent="24"> <dl>
<dt> option-code</dt> <dt>option-code:</dt><dd> OPTION_IA_NA (3).</dd>
<dd>OPTION_IA_NA (3).</dd> <dt>option-len:</dt><dd> 12 + length of IA_NA-options field.</dd>
<dt> option-len</dt> <dt>IAID:</dt><dd> The unique identifier for this IA_NA; the
<dd>12 + length of IA_NA-options
field.</dd>
<dt> IAID</dt>
<dd>The unique identifier for this IA_NA; the
IAID must be unique among the identifiers for all of this client's IAID must be unique among the identifiers for all of this client's
IA_NAs. The number space for IA_NA IAIDs is separate from the IA_NAs. The number space for IA_NA IAIDs is separate from the
number space for other IA option types (i.e., IA_PD). number space for other IA option types (i.e., IA_PD).
A 4‑octet field containing an unsigned integer.</dd> A 4-octet field containing an unsigned integer.</dd>
<dt> T1</dt> <dt>T1:</dt><dd> The time interval after which the client should conta
<dd>The time interval after which the client should contact the ct the
server from which the addresses in the IA_NA were obtained to server from which the addresses in the IA_NA were obtained to
extend the lifetimes of the addresses assigned to the IA_NA; T1 is extend the lifetimes of the addresses assigned to the IA_NA; T1 is
a time duration relative to the current time expressed in units of a time duration relative to the current time expressed in units of
seconds. A 4‑octet field containing an unsigned integer.</dd> seconds. A 4-octet field containing an unsigned integer.</dd>
<dt> T2</dt> <dt>T2:</dt><dd> The time interval after which the client should conta
<dd>The time interval after which the client should contact any ct any
available server to extend the lifetimes of the addresses assigned available server to extend the lifetimes of the addresses assigned
to the IA_NA; T2 is a time duration relative to the current time to the IA_NA; T2 is a time duration relative to the current time
expressed in units of seconds. A 4‑octet field containing expressed in units of seconds. A 4-octet field containing
an unsigned integer.</dd> an unsigned integer.</dd>
<dt> IA_NA-options</dt> <dt>IA_NA-options:</dt><dd> Options associated with this
<dd>Options associated with this
IA_NA. A variable-length field (12 octets less than the IA_NA. A variable-length field (12 octets less than the
value in the option-len field).</dd> value in the option-len field).</dd>
</dl> </dl>
<t>The IA_NA-options field encapsulates those options that are <t>The IA_NA-options field encapsulates those options that are
specific to this IA_NA. For example, all of the IA Address options specific to this IA_NA. For example, all of the IA Address options
(see <xref target="RFC3315-22.6" format="default"/>) (see <xref target="RFC3315-22.6" format="default"/>)
carrying the addresses associated with this IA_NA are in the carrying the addresses associated with this IA_NA are in the
IA_NA-options field.</t> IA_NA-options field.</t>
<t>Each IA_NA carries one "set" of non-temporary addresses; <t>Each IA_NA carries one "set" of non-temporary addresses;
it is up to the server policy to determine how many addresses are it is up to the server policy to determine how many addresses are
skipping to change at line 4262 skipping to change at line 4313
each must have a unique IAID).</t> each must have a unique IAID).</t>
<t>The status of any operations involving this IA_NA is indicated in a <t>The status of any operations involving this IA_NA is indicated in a
Status Code option (see <xref target="RFC3315-22.13" format="default"/>) Status Code option (see <xref target="RFC3315-22.13" format="default"/>)
in the IA_NA-options field.</t> in the IA_NA-options field.</t>
<t>Note that an IA_NA has no explicit "lifetime" or "lease length" of <t>Note that an IA_NA has no explicit "lifetime" or "lease length" of
its own. When the valid lifetimes of all of the addresses in an IA_NA its own. When the valid lifetimes of all of the addresses in an IA_NA
have expired, the IA_NA can be considered as having expired. T1 and T2 have expired, the IA_NA can be considered as having expired. T1 and T2
are included to give servers explicit control over when a client are included to give servers explicit control over when a client
recontacts the server about a specific IA_NA.</t> recontacts the server about a specific IA_NA.</t>
<t>In a message sent by a client to a server, the T1 and T2 fields <t>In a message sent by a client to a server, the T1 and T2 fields
SHOULD be set to 0. The server MUST ignore any values in these fields <bcp14>SHOULD</bcp14> be set to 0. The server <bcp14>MUST</bcp14> ignore any values in these fields
in messages received from a client.</t> in messages received from a client.</t>
<t>In a message sent by a server to a client, the client MUST use the <t>In a message sent by a server to a client, the client <bcp14>MUST</bc p14> use the
values in the T1 and T2 fields for the T1 and T2 times, unless values in the T1 and T2 fields for the T1 and T2 times, unless
values in those fields are 0. The values in the T1 and T2 fields values in those fields are 0. The values in the T1 and T2 fields
are the number of seconds until T1 and T2 and are calculated since are the number of seconds until T1 and T2 and are calculated since
reception of the message.</t> reception of the message.</t>
<t>As per <xref target="RFC3315-5.6" format="default"/>, the value 0xfff fffff is <t>As per <xref target="RFC3315-5.6" format="default"/>, the value 0xfff fffff is
taken to mean "infinity" and should be used carefully.</t> taken to mean "infinity" and should be used carefully.</t>
<t>The server selects the T1 and T2 values to allow the client to <t>The server selects the T1 and T2 values to allow the client to
extend the lifetimes of any addresses in the IA_NA before the extend the lifetimes of any addresses in the IA_NA before the
lifetimes expire, even if the server is unavailable for some short lifetimes expire, even if the server is unavailable for some short
period of time. Recommended values for T1 and T2 are 0.5 and 0.8 times period of time. Recommended values for T1 and T2 are 0.5 and 0.8 times
the shortest preferred lifetime of the addresses in the IA that the the shortest preferred lifetime of the addresses in the IA that the
server is willing to extend, respectively. If the "shortest" preferred server is willing to extend, respectively. If the "shortest" preferred
lifetime is 0xffffffff ("infinity"), the recommended T1 and T2 values lifetime is 0xffffffff ("infinity"), the recommended T1 and T2 values
are also 0xffffffff. If the time at which the addresses in an IA_NA are also 0xffffffff. If the time at which the addresses in an IA_NA
are to be renewed is to be left to the discretion of the client, the are to be renewed is to be left to the discretion of the client, the
server sets the T1 and T2 values to 0. The client MUST follow the server sets the T1 and T2 values to 0. The client <bcp14>MUST</bcp14> fo llow the
rules defined in <xref target="t1-t2-0" format="default"/>.</t> rules defined in <xref target="t1-t2-0" format="default"/>.</t>
<t>If a client receives an IA_NA with T1 greater than T2 and both T1 <t>If a client receives an IA_NA with T1 greater than T2 and both T1
and T2 are greater than 0, the client discards the IA_NA option and and T2 are greater than 0, the client discards the IA_NA option and
processes the remainder of the message as though the server had not processes the remainder of the message as though the server had not
included the invalid IA_NA option.</t> included the invalid IA_NA option.</t>
</section> </section>
<section anchor="RFC3315-22.5" numbered="true" toc="default"> <section anchor="RFC3315-22.5" numbered="true" toc="default">
<name>Identity Association for Temporary Addresses Option</name> <name>Identity Association for Temporary Addresses Option</name>
<t>The Identity Association for Temporary Addresses (IA_TA) option <t>The Identity Association for Temporary Addresses (IA_TA) option
is obsoleted. Please refer to <xref target="RFC8415" format="default"/> for historical is obsoleted. Please refer to <xref target="RFC8415" format="default"/> for historical
information on this option.</t> information on this option.</t>
<t>The client SHOULD NOT send this option. The server SHOULD NOT send th <t>The client <bcp14>SHOULD NOT</bcp14> send this option. The server <bc
is p14>SHOULD NOT</bcp14> send this
option. When the server receives IA_TA option, the option SHOULD be option. When the server receives an IA_TA option, the option <bcp14>SHOU
LD</bcp14> be
ignored and the message processing should continue as usual.</t> ignored and the message processing should continue as usual.</t>
<t>As this option was never popular among server or client <t>As this option was never popular among server or client
implementations before being deprecated, any implementations that implementations before being deprecated, any implementations that
still attempt to send it are unlikely to have the option processed.</t> still attempt to send it are unlikely to have the option processed.</t>
</section> </section>
<section anchor="RFC3315-22.6" numbered="true" toc="default"> <section anchor="RFC3315-22.6" numbered="true" toc="default">
<name>IA Address Option</name> <name>IA Address Option</name>
<t>The IA Address option is used to specify an address. <t>The IA Address option is used to specify an address.
In this document it is only specified to be encapsulated within an In this document, it is only specified to be encapsulated within an
IA_NA. DHCPv6 Leasequery <xref target="RFC5007" format="default"/> make s IA_NA. DHCPv6 Leasequery <xref target="RFC5007" format="default"/> make s
use of the IA Address Option without encapsulating it in IA_NA. The IAad dr‑options use of the IA Address option without encapsulating it in IA_NA. The IAad dr-options
field encapsulates those options that are specific to this address.</t> field encapsulates those options that are specific to this address.</t>
<t>The format of the IA Address option is:</t> <t>The format of the IA Address option is:</t>
<figure anchor="FigOption5"> <figure anchor="FigOption5">
<name>IA Address Option Format</name> <name>IA Address Option Format</name>
<artwork align="left" name="" type="" alt=""><![CDATA[ <artwork align="left" name="" type="" alt=""><![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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_IAADDR | option-len | | OPTION_IAADDR | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| IPv6-address | | IPv6-address |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| preferred-lifetime | | preferred-lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| valid-lifetime | | valid-lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . . .
. IAaddr-options . . IAaddr-options .
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
]]></artwork>
</figure> </figure>
<dl newline="false" spacing="normal" indent="24"> <dl>
<dt> option-code</dt> <dt>option-code:</dt><dd> OPTION_IAADDR (5).</dd>
<dd>OPTION_IAADDR (5).</dd> <dt>option-len:</dt><dd> 24 + length of IAaddr-options
<dt> option-len</dt>
<dd>24 + length of IAaddr-options
field.</dd> field.</dd>
<dt> IPv6-address</dt> <dt>IPv6-address:</dt><dd> An IPv6 address. A client <bcp14>MUST NOT</
<dd>An IPv6 address. A client MUST NOT bcp14>
form an implicit prefix with a length other than 128 for this form an implicit prefix with a length other than 128 for this
address. A 16-octet field.</dd> address. A 16-octet field.</dd>
<dt> preferred-lifetime</dt> <dt>preferred-lifetime:</dt><dd> The preferred lifetime for the
<dd>The preferred lifetime for the
address in the option, expressed in units of seconds. A address in the option, expressed in units of seconds. A
4‑octet field containing an unsigned integer.</dd> 4-octet field containing an unsigned integer.</dd>
<dt> valid-lifetime</dt> <dt>valid-lifetime:</dt><dd> The valid lifetime for the
<dd>The valid lifetime for the
address in the option, expressed in units of seconds. A address in the option, expressed in units of seconds. A
4‑octet field containing an unsigned integer.</dd> 4-octet field containing an unsigned integer.</dd>
<dt> IAaddr-options</dt> <dt>IAaddr-options:</dt><dd> Options associated with this
<dd>Options associated with this
address. A variable-length field (24 octets less than the address. A variable-length field (24 octets less than the
value in the option-len field).</dd> value in the option-len field).</dd>
</dl> </dl>
<t>In a message sent by a client to a server, the <t>In a message sent by a client to a server, the
preferred-lifetime and valid-lifetime fields SHOULD be set to 0. preferred-lifetime and valid-lifetime fields <bcp14>SHOULD</bcp14> be se
The server MUST ignore any received values.</t> t to 0.
<t>The client SHOULD NOT send the IA Address option with an unspecified The server <bcp14>MUST</bcp14> ignore any received values.</t>
<t>The client <bcp14>SHOULD NOT</bcp14> send the IA Address option with
an unspecified
address (::).</t> address (::).</t>
<t>In a message sent by a server to a client, the client MUST use the <t>In a message sent by a server to a client, the client <bcp14>MUST</bc p14> use the
values in the preferred-lifetime and valid-lifetime fields for the values in the preferred-lifetime and valid-lifetime fields for the
preferred and valid lifetimes. The values in these fields are the preferred and valid lifetimes. The values in these fields are the
number of seconds remaining in each lifetime.</t> number of seconds remaining in each lifetime.</t>
<t>The client MUST discard any addresses for which the preferred <t>The client <bcp14>MUST</bcp14> discard any addresses for which the pr eferred
lifetime is greater than the valid lifetime.</t> lifetime is greater than the valid lifetime.</t>
<t>As per <xref target="RFC3315-5.6" format="default"/>, if the valid li fetime of an <t>As per <xref target="RFC3315-5.6" format="default"/>, if the valid li fetime of an
address is 0xffffffff, it is taken to mean "infinity" and should be address is 0xffffffff, it is taken to mean "infinity" and should be
used carefully.</t> used carefully.</t>
<t>More than one IA Address option can appear in an IA_NA option.</t> <t>More than one IA Address option can appear in an IA_NA option.</t>
<t>The status of any operations involving this IA Address is indicated <t>The status of any operations involving this IA Address is indicated
in a Status Code option in the IAaddr-options field, as specified in in a Status Code option in the IAaddr-options field, as specified in
<xref target="RFC3315-22.13" format="default"/>.</t> <xref target="RFC3315-22.13" format="default"/>.</t>
</section> </section>
<section anchor="RFC3315-22.7" numbered="true" toc="default"> <section anchor="RFC3315-22.7" numbered="true" toc="default">
<name>Option Request Option</name> <name>Option Request Option</name>
<t>The Option Request option is used to identify a list of options in <t>The Option Request option is used to identify a list of options in
a message between a client and a server. The format of the Option a message between a client and a server. The format of the Option
Request option is:</t> Request option is:</t>
<figure anchor="FigOption6"> <figure anchor="FigOption6">
<name>Option Request Option Format</name> <name>Option Request Option Format</name>
<artwork align="left" name="" type="" alt=""><![CDATA[ <artwork align="left" name="" type="" alt=""><![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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_ORO | option-len | | OPTION_ORO | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| requested-option-code-1 | requested-option-code-2 | | requested-option-code-1 | requested-option-code-2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
]]></artwork>
</figure> </figure>
<dl newline="false" spacing="normal" indent="29"> <dl>
<dt> option-code</dt> <dt>option-code:</dt><dd> OPTION_ORO (6).</dd>
<dd>OPTION_ORO (6).</dd> <dt>option-len:</dt><dd> 2 * number of requested options.</dd>
<dt> option-len</dt> <dt>requested-option-code-n:</dt><dd> The option code for
<dd>2 * number of requested options.</dd>
<dt> requested-option-code-n</dt>
<dd>The option code for
an option requested by the client. Each option code is a an option requested by the client. Each option code is a
2‑octet field containing an unsigned integer.</dd> 2-octet field containing an unsigned integer.</dd>
</dl> </dl>
<t>A client MUST include an Option Request option in a Solicit, <t>A client <bcp14>MUST</bcp14> include an Option Request option in a So licit,
Request, Renew, Rebind, or Information-request message to Request, Renew, Rebind, or Information-request message to
inform the server about options the client wants the server to send to inform the server about options the client wants the server to send to
the client.</t> the client.</t>
<t>The Option Request option MUST NOT include the <t>The Option Request option <bcp14>MUST NOT</bcp14> include the
following option codes:</t> following option codes:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>Client Identifier (see <xref target="RFC3315-22.2" format="default "/>)</li> <li>Client Identifier (see <xref target="RFC3315-22.2" format="default "/>)</li>
<li>Server Identifier (see <xref target="RFC3315-22.3" format="default "/>)</li> <li>Server Identifier (see <xref target="RFC3315-22.3" format="default "/>)</li>
<li>IA_NA (see <xref target="RFC3315-22.4" format="default"/>)</li> <li>IA_NA (see <xref target="RFC3315-22.4" format="default"/>)</li>
<li>IA_TA (option obsoleted, see <xref target="RFC3315-22.5" format="d efault"/>)</li> <li>IA_TA (option obsoleted, see <xref target="RFC3315-22.5" format="d efault"/>)</li>
<li>IA_PD (see <xref target="IA_PD-option" format="default"/>)</li> <li>IA_PD (see <xref target="IA_PD-option" format="default"/>)</li>
<li>IA Address (see <xref target="RFC3315-22.6" format="default"/>)</l i> <li>IA Address (see <xref target="RFC3315-22.6" format="default"/>)</l i>
<li>IA Prefix (see <xref target="IAPREFIX-option" format="default"/>)< /li> <li>IA Prefix (see <xref target="IAPREFIX-option" format="default"/>)< /li>
<li>Option Request (this section)</li> <li>Option Request (this section)</li>
skipping to change at line 4431 skipping to change at line 4471
<li>Authentication (see <xref target="RFC3315-22.11" format="default"/ >)</li> <li>Authentication (see <xref target="RFC3315-22.11" format="default"/ >)</li>
<li>Server Unicast (option obsoleted, see <xref target="RFC3315-22.12" format="default"/>)</li> <li>Server Unicast (option obsoleted, see <xref target="RFC3315-22.12" format="default"/>)</li>
<li>Status Code (see <xref target="RFC3315-22.13" format="default"/>)< /li> <li>Status Code (see <xref target="RFC3315-22.13" format="default"/>)< /li>
<li>Rapid Commit (see <xref target="RFC3315-22.14" format="default"/>) </li> <li>Rapid Commit (see <xref target="RFC3315-22.14" format="default"/>) </li>
<li>User Class (see <xref target="RFC3315-22.15" format="default"/>)</ li> <li>User Class (see <xref target="RFC3315-22.15" format="default"/>)</ li>
<li>Vendor Class (see <xref target="RFC3315-22.16" format="default"/>) </li> <li>Vendor Class (see <xref target="RFC3315-22.16" format="default"/>) </li>
<li>Interface-Id (see <xref target="RFC3315-22.18" format="default"/>) </li> <li>Interface-Id (see <xref target="RFC3315-22.18" format="default"/>) </li>
<li>Reconfigure Message (see <xref target="RFC3315-22.19" format="defa ult"/>)</li> <li>Reconfigure Message (see <xref target="RFC3315-22.19" format="defa ult"/>)</li>
<li>Reconfigure Accept (see <xref target="RFC3315-22.20" format="defau lt"/>)</li> <li>Reconfigure Accept (see <xref target="RFC3315-22.20" format="defau lt"/>)</li>
</ul> </ul>
<t>Other top-level option codes MUST appear in the Option Request <t>Other top-level option codes <bcp14>MUST</bcp14> appear in the Option Request
option or they will not be sent by the server. Only top-level option cod es option or they will not be sent by the server. Only top-level option cod es
MAY appear in the Option Request option. Option codes encapsulated in a <bcp14>MAY</bcp14> appear in the Option Request option. Option codes enc
container option SHOULD NOT appear in an Option Request option; see apsulated in a
container option <bcp14>SHOULD NOT</bcp14> appear in an Option Request o
ption; see
<xref target="RFC7598" format="default"/> for an example of container op tions. However, <xref target="RFC7598" format="default"/> for an example of container op tions. However,
options MAY be defined that specify exceptions to this restriction on options <bcp14>MAY</bcp14> be defined that specify exceptions to this re striction on
including encapsulated option codes in an Option Request option. For including encapsulated option codes in an Option Request option. For
example, the Option Request option MAY be used to signal support for a example, the Option Request option <bcp14>MAY</bcp14> be used to signal support for a
feature even when that option is encapsulated, as in the case of the feature even when that option is encapsulated, as in the case of the
Prefix Exclude option <xref target="RFC6603" format="default"/>. See <xr ef target="IANA-OPTION-DETAILS" format="default"/>. Prefix Exclude option <xref target="RFC6603" format="default"/>. See <xr ef target="IANA-OPTION-DETAILS" format="default"/>.
</t> </t>
<t> <t>
See <xref target="IANA-OPTION-DETAILS" format="default"/> See <xref target="IANA-OPTION-DETAILS" format="default"/>
for the authoritative list of which option codes are required, permitted or forbidden. for the authoritative list of which option codes are required, permitted , or forbidden.
</t> </t>
</section> </section>
<section anchor="RFC3315-22.8" numbered="true" toc="default"> <section anchor="RFC3315-22.8" numbered="true" toc="default">
<name>Preference Option</name> <name>Preference Option</name>
<t>The Preference option is sent by a server to a client to control <t>The Preference option is sent by a server to a client to control
the selection of a server by the client.</t> the selection of a server by the client.</t>
<t>The format of the Preference option is:</t> <t>The format of the Preference option is:</t>
<figure anchor="FigOption7"> <figure anchor="FigOption7">
<name>Preference Option Format</name> <name>Preference Option Format</name>
<artwork align="left" name="" type="" alt=""><![CDATA[ <artwork align="left" name="" type="" alt=""><![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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_PREFERENCE | option-len | | OPTION_PREFERENCE | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| pref-value | | pref-value |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+]]></artwork>
]]></artwork>
</figure> </figure>
<dl newline="false" spacing="normal" indent="24"> <dl>
<dt> option-code</dt> <dt>option-code:</dt><dd> OPTION_PREFERENCE (7).</dd>
<dd>OPTION_PREFERENCE (7).</dd> <dt>option-len:</dt><dd> 1.</dd>
<dt> option-len</dt> <dt>pref-value:</dt><dd> The preference value for the server in
<dd>1.</dd> this message. A 1-octet unsigned integer.</dd>
<dt> pref-value</dt>
<dd>The preference value for the server in
this message. A 1‑octet unsigned integer.</dd>
</dl> </dl>
<t>A server MAY include a Preference option in an Advertise message to <t>A server <bcp14>MAY</bcp14> include a Preference option in an Adverti se message to
control the selection of a server by the client. See <xref target="RFC33 15-17.1.3" format="default"/> for information regarding the use of the control the selection of a server by the client. See <xref target="RFC33 15-17.1.3" format="default"/> for information regarding the use of the
Preference option by the client and the interpretation of the Preference option by the client and the interpretation of the
Preference option data value.</t> Preference option data value.</t>
</section> </section>
<section anchor="RFC3315-22.9" numbered="true" toc="default"> <section anchor="RFC3315-22.9" numbered="true" toc="default">
<name>Elapsed Time Option</name> <name>Elapsed Time Option</name>
<figure anchor="FigOption8"> <figure anchor="FigOption8">
<name>Elapsed Time Option Format</name> <name>Elapsed Time Option Format</name>
<artwork align="left" name="" type="" alt=""><![CDATA[ <artwork align="left" name="" type="" alt=""><![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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_ELAPSED_TIME | option-len | | OPTION_ELAPSED_TIME | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| elapsed-time | | elapsed-time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
]]></artwork>
</figure> </figure>
<dl newline="false" spacing="normal" indent="24"> <dl>
<dt> option-code</dt> <dt>option-code:</dt><dd> OPTION_ELAPSED_TIME (8).</dd>
<dd>OPTION_ELAPSED_TIME (8).</dd> <dt>option-len:</dt><dd> 2.</dd>
<dt> option-len</dt> <dt>elapsed-time:</dt><dd> The amount of time since the client
<dd>2.</dd>
<dt> elapsed-time</dt>
<dd>The amount of time since the client
began its current DHCP transaction. This time is expressed in began its current DHCP transaction. This time is expressed in
hundredths of a second (10^‑2 seconds). A 2-octet field hundredths of a second (10^-2 seconds). A 2-octet field
containing an unsigned integer.</dd> containing an unsigned integer.</dd>
</dl> </dl>
<t>A client MUST include an Elapsed Time option in messages to <t>A client <bcp14>MUST</bcp14> include an Elapsed Time option in messag es to
indicate how long the client has been trying to complete a DHCP indicate how long the client has been trying to complete a DHCP
message exchange. The elapsed time is measured from the time at which message exchange. The elapsed time is measured from the time at which
the client sent the first message in the message exchange, and the the client sent the first message in the message exchange, and the
elapsed-time field is set to 0 in the first message in the message elapsed-time field is set to 0 in the first message in the message
exchange. Servers and relay agents use the data value in this option exchange. Servers and relay agents use the data value in this option
as input to policy that controls how a server responds to a client as input to policy that controls how a server responds to a client
message. For example, the Elapsed Time option allows a secondary DHCP message. For example, the Elapsed Time option allows a secondary DHCP
server to respond to a request when a primary server has not answered server to respond to a request when a primary server has not answered
in a reasonable time. The elapsed-time value is a 16-bit in a reasonable time. The elapsed-time value is a 16-bit
(2-octet) unsigned integer. The client uses the value 0xffff to (2-octet) unsigned integer. The client uses the value 0xffff to
skipping to change at line 4525 skipping to change at line 4557
that can be represented in the Elapsed Time option.</t> that can be represented in the Elapsed Time option.</t>
</section> </section>
<section anchor="RFC3315-22.10" numbered="true" toc="default"> <section anchor="RFC3315-22.10" numbered="true" toc="default">
<name>Relay Message Option</name> <name>Relay Message Option</name>
<t>The Relay Message option carries a DHCP message in a Relay-forward <t>The Relay Message option carries a DHCP message in a Relay-forward
or Relay-reply message.</t> or Relay-reply message.</t>
<t>The format of the Relay Message option is:</t> <t>The format of the Relay Message option is:</t>
<figure anchor="FigOption9"> <figure anchor="FigOption9">
<name>Relay Message Option Format</name> <name>Relay Message Option Format</name>
<artwork align="left" name="" type="" alt=""><![CDATA[ <artwork align="left" name="" type="" alt=""><![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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_RELAY_MSG | option-len | | OPTION_RELAY_MSG | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
. DHCP-relay-message . . DHCP-relay-message .
. . . .
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
]]></artwork>
</figure> </figure>
<dl newline="false" spacing="normal" indent="24"> <dl>
<dt> option-code</dt> <dt>option-code:</dt><dd> OPTION_RELAY_MSG (9).</dd>
<dd>OPTION_RELAY_MSG (9).</dd> <dt>option-len:</dt><dd> Length of DHCP-relay-message field.</dd>
<dt> option-len</dt> <dt>DHCP-relay-message:</dt><dd> In a Relay-forward message,
<dd>Length of DHCP-relay-message field.</dd>
<dt> DHCP-relay-message</dt>
<dd>In a Relay-forward message,
the received message, relayed verbatim to the next relay agent or the received message, relayed verbatim to the next relay agent or
server; in a Relay-reply message, the message to be copied and server; in a Relay-reply message, the message to be copied and
relayed to the relay agent or client whose address is in the relayed to the relay agent or client whose address is in the
peer-address field of the Relay-reply message. The peer-address field of the Relay-reply message. The
length, in octets, is specified by option-len.</dd> length, in octets, is specified by option-len.</dd>
</dl> </dl>
</section> </section>
<section anchor="RFC3315-22.11" numbered="true" toc="default"> <section anchor="RFC3315-22.11" numbered="true" toc="default">
<name>Authentication Option</name> <name>Authentication Option</name>
<t>The Authentication option carries authentication information to <t>The Authentication option carries authentication information to
authenticate the identity and contents of DHCP messages. The use of authenticate the identity and contents of DHCP messages. The use of
the Authentication option is described in <xref target="RFC3315-21" form at="default"/>. the Authentication option is described in <xref target="RFC3315-21" form at="default"/>.
The format of the Authentication option is:</t> The format of the Authentication option is:</t>
<figure anchor="FigOption11"> <figure anchor="FigOption11">
<name>Authentication Option Format</name> <name>Authentication Option Format</name>
<artwork align="left" name="" type="" alt=""><![CDATA[ <artwork align="left" name="" type="" alt=""><![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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_AUTH | option-len | | OPTION_AUTH | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| protocol | algorithm | RDM | | | protocol | algorithm | RDM | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | | |
| replay detection (64 bits) +-+-+-+-+-+-+-+-+ | replay detection (64 bits) +-+-+-+-+-+-+-+-+
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
. authentication information . . authentication information .
. (variable length) . . (variable length) .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
]]></artwork>
</figure> </figure>
<dl newline="false" spacing="normal" indent="32"> <dl>
<dt> option-code</dt> <dt>option-code:</dt><dd> OPTION_AUTH (11).</dd>
<dd>OPTION_AUTH (11).</dd> <dt>option-len:</dt><dd> 11 + length of authentication
<dt> option-len</dt>
<dd>11 + length of authentication
information field.</dd> information field.</dd>
<dt> protocol</dt> <dt>protocol:</dt><dd> The authentication protocol used in this
<dd>The authentication protocol used in this Authentication option. A 1-octet unsigned integer.</dd>
Authentication option. A 1‑octet unsigned integer.</dd> <dt>algorithm:</dt><dd> The algorithm used in the
<dt> algorithm</dt> authentication protocol. A 1-octet unsigned integer.</dd>
<dd>The algorithm used in the <dt>RDM:</dt><dd> The replay detection method used in this
authentication protocol. A 1‑octet unsigned integer.</dd> Authentication option. A 1-octet unsigned integer.</dd>
<dt> RDM</dt> <dt>replay detection:</dt><dd> The replay detection information
<dd>The replay detection method used in this
Authentication option. A 1‑octet unsigned integer.</dd>
<dt> replay detection</dt>
<dd>The replay detection information
for the RDM. A 64-bit (8-octet) field.</dd> for the RDM. A 64-bit (8-octet) field.</dd>
<dt> authentication information</dt> <dt>authentication information:</dt><dd> The authentication
<dd>The authentication
information, as specified by the protocol and algorithm used in information, as specified by the protocol and algorithm used in
this Authentication option. A variable-length field (11 octets this Authentication option. A variable-length field (11 octets
less than the value in the option-len field).</dd> less than the value in the option-len field).</dd>
</dl> </dl>
<t>IANA maintains a registry for the protocol, algorithm, and RDM <t>IANA maintains a registry for the protocol, algorithm, and RDM
values at <https://www.iana.org/assignments/auth-namespaces&gt;.</t > values at <eref brackets="angle" target="https://www.iana.org/assignme nts/auth-namespaces"/>.</t>
</section> </section>
<section anchor="RFC3315-22.12" numbered="true" toc="default"> <section anchor="RFC3315-22.12" numbered="true" toc="default">
<name>Server Unicast Option</name> <name>Server Unicast Option</name>
<t>The Server Unicast option is obsolete. Please refer to <t>The Server Unicast option is obsolete. Please refer to
<xref target="RFC8415" format="default"/> for historical information on this option.</t> <xref target="RFC8415" format="default"/> for historical information on this option.</t>
<t>The client SHOULD NOT request this option in the Option Request opti on. The server SHOULD NOT send <t>The client <bcp14>SHOULD NOT</bcp14> request this option in the Opti on Request option. The server <bcp14>SHOULD NOT</bcp14> send
this option, even when requested by clients. When any entity receives the Server Unicast this option, even when requested by clients. When any entity receives the Server Unicast
option, the option SHOULD be ignored and the message processing should continue as option, the option <bcp14>SHOULD</bcp14> be ignored and the message pro cessing should continue as
usual.</t> usual.</t>
<t>As this option was not very popular and it typically required specia l <t>As this option was not very popular, and it typically required speci al
configuration by those server implementations that did support it, configuration by those server implementations that did support it,
clients still requesting this option in the Option Request option are i ncreasingly unlikely clients still requesting this option in the Option Request option are i ncreasingly unlikely
to receive it.</t> to receive it.</t>
</section> </section>
<section anchor="RFC3315-22.13" numbered="true" toc="default"> <section anchor="RFC3315-22.13" numbered="true" toc="default">
<name>Status Code Option</name> <name>Status Code Option</name>
<t>This option returns a status indication related to the DHCP message <t>This option returns a status indication related to the DHCP message
or option in which it appears. The format of the Status Code or option in which it appears. The format of the Status Code
option is:</t> option is:</t>
<figure anchor="FigOption13"> <figure anchor="FigOption13">
<name>Status Code Option Format</name> <name>Status Code Option Format</name>
<artwork align="left" name="" type="" alt=""><![CDATA[ <artwork align="left" name="" type="" alt=""><![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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_STATUS_CODE | option-len | | OPTION_STATUS_CODE | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| status-code | | | status-code | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
. . . .
. status-message . . status-message .
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
]]></artwork>
</figure> </figure>
<dl newline="false" spacing="normal" indent="24"> <dl>
<dt> option-code</dt> <dt>option-code:</dt><dd> OPTION_STATUS_CODE (13).</dd>
<dd>OPTION_STATUS_CODE (13).</dd> <dt>option-len:</dt><dd> 2 + length of status-message field.</dd>
<dt> option-len</dt> <dt>status-code:</dt><dd> The numeric code for the status
<dd>2 + length of status-message field.</dd>
<dt> status-code</dt>
<dd>The numeric code for the status
encoded in this option. A 2-octet field containing encoded in this option. A 2-octet field containing
an unsigned integer.</dd> an unsigned integer.</dd>
<dt> status-message</dt> <!--[rfced] Please review: Should "null-terminated" should be
<dd>A UTF-8 encoded "NUL-terminated" if it is referring to the NUL character (which
is mentioned in RFC 3629)?
Original:
status-message A UTF-8 encoded [RFC3629] text string
suitable for display to an end user.
MUST NOT be null-terminated. A variable-
length field (2 octets less than the value in
the option-len field).
-->
<dt>status-message:</dt><dd> A UTF-8 encoded
<xref target="RFC3629" format="default"/> text string <xref target="RFC3629" format="default"/> text string
suitable for display to an end user. MUST NOT be suitable for display to an end user. <bcp14>MUST NOT</bcp14> be
null-terminated. A variable-length field (2 octets null-terminated. A variable-length field (2 octets
less than the value in the option-len field).</dd> less than the value in the option-len field).</dd>
</dl> </dl>
<t>A Status Code option may appear in the "options" field of a DHCP <t>A Status Code option may appear in the "options" field of a DHCP
message and/or in the "options" field of another option. If the Status message and/or in the "options" field of another option. If the Status
Code option does not appear in a message in which the option could Code option does not appear in a message in which the option could
appear, the status of the message is assumed to be Success.</t> appear, the status of the message is assumed to be Success.</t>
<t>The status-code values are:</t> <t>The status-code values are:</t>
<table anchor="Status-Code-Table" align="center"> <table anchor="Status-Code-Table" align="center">
<name>Status Code Definitions</name> <name>Status Code Definitions</name>
<thead> <thead>
<tr> <tr>
<th align="left">Name</th> <th align="left">Name</th>
<th align="right">Code</th> <th align="right">Code</th>
<th align="left">Description</th> <th align="left">Description</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
skipping to change at line 4715 skipping to change at line 4741
</tr> </tr>
<tr> <tr>
<td align="left">NoPrefixAvail</td> <td align="left">NoPrefixAvail</td>
<td align="right">6</td> <td align="right">6</td>
<td align="left">The server has no prefixes available to assign to the <td align="left">The server has no prefixes available to assign to the
IA_PD(s).</td> IA_PD(s).</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
<t>See the "Status Codes" registry at <t>See the "Status Codes" registry at
<https://www.iana.org/assignments/dhcpv6-parameters&gt; <eref brackets="angle" target="https://www.iana.org/assignments/dhcpv6-p arameters"/&gt;
for the current list of status codes.</t> for the current list of status codes.</t>
</section> </section>
<section anchor="RFC3315-22.14" numbered="true" toc="default"> <section anchor="RFC3315-22.14" numbered="true" toc="default">
<name>Rapid Commit Option</name> <name>Rapid Commit Option</name>
<t>The Rapid Commit option is used to signal the use of the <t>The Rapid Commit option is used to signal the use of the
two-message exchange for address assignment. The format of the Rapid two-message exchange for address assignment. The format of the Rapid
Commit option is:</t> Commit option is:</t>
<figure anchor="FigOption14"> <figure anchor="FigOption14">
<name>Rapid Commit Option Format</name> <name>Rapid Commit Option Format</name>
<artwork align="left" name="" type="" alt=""><![CDATA[ <artwork align="left" name="" type="" alt=""><![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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_RAPID_COMMIT | option-len | | OPTION_RAPID_COMMIT | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
]]></artwork>
</figure> </figure>
<dl newline="false" spacing="normal" indent="24"> <dl>
<dt> option-code</dt> <dt>option-code:</dt><dd> OPTION_RAPID_COMMIT (14).</dd>
<dd>OPTION_RAPID_COMMIT (14).</dd> <dt>option-len:</dt><dd> 0.</dd>
<dt> option-len</dt>
<dd>0.</dd>
</dl> </dl>
<t>A client MAY include this option in a Solicit message if the client <t>A client <bcp14>MAY</bcp14> include this option in a Solicit message if the client
is prepared to perform the Solicit/Reply message exchange described in is prepared to perform the Solicit/Reply message exchange described in
<xref target="solicit-create-transmit" format="default"/>.</t> <xref target="solicit-create-transmit" format="default"/>.</t>
<t>A server MUST include this option in a Reply message sent in <t>A server <bcp14>MUST</bcp14> include this option in a Reply message s ent in
response to a Solicit message when completing the Solicit/Reply response to a Solicit message when completing the Solicit/Reply
message exchange.</t> message exchange.</t>
<t>DISCUSSION:</t> <t>DISCUSSION:</t>
<ul empty="true" spacing="normal"> <ul spacing="normal">
<li>Each server that responds with a Reply to a Solicit that <li>Each server that responds with a Reply to a Solicit that
includes a Rapid Commit option will commit the leases includes a Rapid Commit option will commit the leases
in the Reply message to the client but will not receive any in the Reply message to the client but will not receive any
confirmation that the client has received the Reply message. confirmation that the client has received the Reply message.
Therefore, if more than one server responds to a Solicit that Therefore, if more than one server responds to a Solicit that
includes a Rapid Commit option, all but one server will commit includes a Rapid Commit option, all but one server will commit
leases that are not actually used by the client; this could leases that are not actually used by the client; this could
result in incorrect address information in DNS if the DHCP servers result in incorrect address information in DNS if the DHCP servers
update DNS <xref target="RFC4704" format="default"/>, and responses to update DNS <xref target="RFC4704" format="default"/>, and responses to
leasequery requests <xref target="RFC5007" format="default"/> may in clude leasequery requests <xref target="RFC5007" format="default"/> may in clude
skipping to change at line 4772 skipping to change at line 4795
</ul> </ul>
</section> </section>
<section anchor="RFC3315-22.15" numbered="true" toc="default"> <section anchor="RFC3315-22.15" numbered="true" toc="default">
<name>User Class Option</name> <name>User Class Option</name>
<t>The User Class option is used by a client to identify the type or <t>The User Class option is used by a client to identify the type or
category of users or applications it represents.</t> category of users or applications it represents.</t>
<t>The format of the User Class option is:</t> <t>The format of the User Class option is:</t>
<figure anchor="FigOption15"> <figure anchor="FigOption15">
<name>User Class Option Format</name> <name>User Class Option Format</name>
<artwork align="left" name="" type="" alt=""><![CDATA[ <artwork align="left" name="" type="" alt=""><![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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_USER_CLASS | option-len | | OPTION_USER_CLASS | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . . .
. user-class-data . . user-class-data .
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
]]></artwork>
</figure> </figure>
<dl newline="false" spacing="normal" indent="24"> <dl>
<dt> option-code</dt> <dt>option-code:</dt><dd> OPTION_USER_CLASS (15).</dd>
<dd>OPTION_USER_CLASS (15).</dd> <dt>option-len:</dt><dd> Length of user-class-data field.</dd>
<dt> option-len</dt> <dt>user-class-data:</dt><dd> The user classes carried by the
<dd>Length of user-class-data field.</dd> client. The length, in octets, is specified by option-len.</dd>
<dt> user-class-data</dt>
<dd>The user classes carried by the
client. The length, in octets, is specified by option‑len.</dd>
</dl> </dl>
<t>The information contained in the data area of this option is <t>The information contained in the data area of this option is
contained in one or more opaque fields that represent the user class contained in one or more opaque fields that represent the user class
or classes of which the client is a member. A server selects or classes of which the client is a member. A server selects
configuration information for the client based on the classes configuration information for the client based on the classes
identified in this option. For example, the User Class option can be identified in this option. For example, the User Class option can be
used to configure all clients of people in the accounting department used to configure all clients of people in the accounting department
with a different printer than clients of people in the marketing with a different printer than clients of people in the marketing
department. The user class information carried in this option MUST be department. The user class information carried in this option <bcp14>MUS T</bcp14> be
configurable on the client.</t> configurable on the client.</t>
<t>The data area of the User Class option MUST contain one or more <t>The data area of the User Class option <bcp14>MUST</bcp14> contain on e or more
instances of user-class-data information. Each instance of instances of user-class-data information. Each instance of
user‑class-data is formatted as follows:</t> user-class-data is formatted as follows:</t>
<figure anchor="FigOption15Data"> <figure anchor="FigOption15Data">
<name>Format of user-class-data Field</name> <name>Format of user-class-data Field</name>
<artwork align="left" name="" type="" alt=""><![CDATA[ <artwork align="left" name="" type="" alt=""><![CDATA[
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+
| user-class-len | opaque-data | | user-class-len | opaque-data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+]]></artwork>
]]></artwork>
</figure> </figure>
<t>The user-class-len field is 2 octets long and specifies the <t>The user-class-len field is 2 octets long and specifies the
length of the opaque user-class-data in network byte order.</t> length of the opaque user-class-data in network byte order.</t>
<t>A server interprets the classes identified in this option according <t>A server interprets the classes identified in this option according
to its configuration to select the appropriate configuration to its configuration to select the appropriate configuration
information for the client. A server may use only those user classes information for the client. A server may use only those user classes
that it is configured to interpret in selecting configuration that it is configured to interpret in selecting configuration
information for a client and ignore any other user classes. In information for a client and ignore any other user classes. In
response to a message containing a User Class option, a server may response to a message containing a User Class option, a server may
include a User Class option containing those classes that were include a User Class option containing those classes that were
skipping to change at line 4834 skipping to change at line 4852
<section anchor="RFC3315-22.16" numbered="true" toc="default"> <section anchor="RFC3315-22.16" numbered="true" toc="default">
<name>Vendor Class Option</name> <name>Vendor Class Option</name>
<t>This option is used by a client to identify the vendor that <t>This option is used by a client to identify the vendor that
manufactured the hardware on which the client is running. The manufactured the hardware on which the client is running. The
information contained in the data area of this option is contained in information contained in the data area of this option is contained in
one or more opaque fields that identify details of the hardware one or more opaque fields that identify details of the hardware
configuration. The format of the Vendor Class option is:</t> configuration. The format of the Vendor Class option is:</t>
<figure anchor="FigOption16"> <figure anchor="FigOption16">
<name>Vendor Class Option Format</name> <name>Vendor Class Option Format</name>
<artwork align="left" name="" type="" alt=""><![CDATA[ <artwork align="left" name="" type="" alt=""><![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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_VENDOR_CLASS | option-len | | OPTION_VENDOR_CLASS | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| enterprise-number | | enterprise-number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . . .
. vendor-class-data . . vendor-class-data .
. . . . . . . . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
]]></artwork>
</figure> </figure>
<dl newline="false" spacing="normal" indent="24"> <dl>
<dt> option-code</dt> <dt>option-code:</dt><dd> OPTION_VENDOR_CLASS (16).</dd>
<dd>OPTION_VENDOR_CLASS (16).</dd> <dt>option-len:</dt><dd> 4 + length of vendor-class-data
<dt> option-len</dt>
<dd>4 + length of vendor-class-data
field.</dd> field.</dd>
<dt> enterprise-number</dt> <dt>enterprise-number:</dt><dd> The vendor's registered
<dd>The vendor's registered
Enterprise Number as maintained by IANA <xref target="IANA-PEN" form at="default"/>. Enterprise Number as maintained by IANA <xref target="IANA-PEN" form at="default"/>.
A 4‑octet field containing an unsigned integer.</dd> A 4-octet field containing an unsigned integer.</dd>
<dt> vendor-class-data</dt> <dt>vendor-class-data:</dt><dd> The hardware configuration of
<dd>The hardware configuration of the node on which the client is running. A variable-length
the node on which the client is running. A variable‑length
field (4 octets less than the value in the option-len field).</dd> field (4 octets less than the value in the option-len field).</dd>
</dl> </dl>
<t>The vendor-class-data field is composed of a series of separate <t>The vendor-class-data field is composed of a series of separate
items, each of which describes some characteristic of the client's items, each of which describes some characteristic of the client's
hardware configuration. Examples of vendor-class-data instances hardware configuration. Examples of vendor-class-data instances
might include the version of the operating system the client is might include the version of the operating system the client is
running or the amount of memory installed on the client.</t> running or the amount of memory installed on the client.</t>
<t>Each instance of vendor-class-data is formatted as follows:</t> <t>Each instance of vendor-class-data is formatted as follows:</t>
<figure anchor="FigOption16Data"> <figure anchor="FigOption16Data">
<name>Format of vendor-class-data Field</name> <name>Format of vendor-class-data Field</name>
<artwork align="left" name="" type="" alt=""><![CDATA[ <artwork align="left" name="" type="" alt=""><![CDATA[
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+
| vendor-class-len | opaque-data | | vendor-class-len | opaque-data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+]]></artwork>
]]></artwork>
</figure> </figure>
<t>The vendor-class-len field is 2 octets long and specifies the <t>The vendor-class-len field is 2 octets long and specifies the
length of the opaque vendor-class-data in network byte order.</t> length of the opaque vendor-class-data in network byte order.</t>
<t>Servers and clients MUST NOT include more than one instance of <t>Servers and clients <bcp14>MUST NOT</bcp14> include more than one ins tance of
OPTION_VENDOR_CLASS with the same Enterprise Number. Each instance of OPTION_VENDOR_CLASS with the same Enterprise Number. Each instance of
OPTION_VENDOR_CLASS can carry multiple vendor-class-data instances.</t> OPTION_VENDOR_CLASS can carry multiple vendor-class-data instances.</t>
</section> </section>
<section anchor="RFC3315-22.17" numbered="true" toc="default"> <section anchor="RFC3315-22.17" numbered="true" toc="default">
<name>Vendor-specific Information Option</name> <name>Vendor-Specific Information Option</name>
<t>This option is used by clients and servers to exchange <t>This option is used by clients and servers to exchange
vendor-specific information.</t> vendor-specific information.</t>
<t>The format of the Vendor-specific Information option is:</t> <t>The format of the Vendor-specific Information option is:</t>
<figure anchor="FigOption17"> <figure anchor="FigOption17">
<name>Vendor-specific Information Option Format</name> <name>Vendor-Specific Information Option Format</name>
<artwork align="left" name="" type="" alt=""><![CDATA[ <artwork align="left" name="" type="" alt=""><![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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_VENDOR_OPTS | option-len | | OPTION_VENDOR_OPTS | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| enterprise-number | | enterprise-number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . . .
. vendor-option-data . . vendor-option-data .
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
]]></artwork>
</figure> </figure>
<dl newline="false" spacing="normal" indent="24"> <dl>
<dt> option-code</dt> <dt>option-code:</dt><dd> OPTION_VENDOR_OPTS (17).</dd>
<dd>OPTION_VENDOR_OPTS (17).</dd> <dt>option-len:</dt><dd> 4 + length of vendor-option-data
<dt> option-len</dt>
<dd>4 + length of vendor-option-data
field.</dd> field.</dd>
<dt> enterprise-number</dt> <dt>enterprise-number:</dt><dd> The vendor's registered
<dd>The vendor's registered
Enterprise Number as maintained by IANA <xref target="IANA-PEN" form at="default"/>. Enterprise Number as maintained by IANA <xref target="IANA-PEN" form at="default"/>.
A 4‑octet field containing an unsigned integer.</dd> A 4-octet field containing an unsigned integer.</dd>
<dt> vendor-option-data</dt> <dt>vendor-option-data:</dt><dd> Vendor options, interpreted by
<dd>Vendor options, interpreted by
vendor-specific code on the clients and servers. A vendor-specific code on the clients and servers. A
variable-length field (4 octets less than the value in the variable-length field (4 octets less than the value in the
option-len field).</dd> option-len field).</dd>
</dl> </dl>
<t>The definition of the information carried in this option is vendor <t>The definition of the information carried in this option is vendor
specific. The vendor is indicated in the enterprise-number field. Use specific. The vendor is indicated in the enterprise-number field. Use
of vendor-specific information allows enhanced operation, utilizing of vendor-specific information allows enhanced operation, utilizing
additional features in a vendor's DHCP implementation. A DHCP client additional features in a vendor's DHCP implementation. A DHCP client
that does not receive requested vendor-specific information will still that does not receive requested vendor-specific information will still
configure the node's IPv6 stack to be functional.</t> configure the node's IPv6 stack to be functional.</t>
<t>The vendor-option-data field MUST be encoded as a sequence of <t>The vendor-option-data field <bcp14>MUST</bcp14> be encoded as a sequ ence of
code/length/value fields of format identical to the DHCP options code/length/value fields of format identical to the DHCP options
(see <xref target="RFC3315-22.1" format="default"/>). The suboption code s are defined (see <xref target="RFC3315-22.1" format="default"/>). The suboption code s are defined
by the vendor identified in the enterprise-number field and are not by the vendor identified in the enterprise-number field and are not
managed by IANA. Each of the suboptions is formatted as follows:</t> managed by IANA. Each of the suboptions is formatted as follows:</t>
<figure anchor="FigOption17Data"> <figure anchor="FigOption17Data">
<name>Vendor-specific Options Format</name> <name>Vendor-Specific Options Format</name>
<artwork align="left" name="" type="" alt=""><![CDATA[ <artwork align="left" name="" type="" alt=""><![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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sub-opt-code | suboption-len | | sub-opt-code | suboption-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . . .
. suboption-data . . suboption-data .
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
]]></artwork>
</figure> </figure>
<dl newline="false" spacing="normal" indent="24"> <dl>
<dt> sub-opt-code</dt> <dt>sub-opt-code:</dt><dd> The code for the suboption. A
<dd>The code for the suboption. A
2-octet field.</dd> 2-octet field.</dd>
<dt> suboption-len</dt> <dt>suboption-len:</dt><dd> An unsigned integer giving the length
<dd>An unsigned integer giving the length
of the suboption-data field in this suboption in octets. A of the suboption-data field in this suboption in octets. A
2-octet field.</dd> 2-octet field.</dd>
<dt> suboption-data</dt>
<dd>The data area for the suboption. <!--[rfced] Please note that we have updated "sub-option-len" to
The length, in octets, is specified by sub‑option‑len. "suboption-len" in the following to match both Figure 29 and the
updates to other instances made in Section 21.17. Please let us
know any objections.
Original:
The data area for the suboption. The length, in octets, is specified
by sub-option-len.
Current:
The data area for the suboption. The length, in octets, is specified
by suboption-len.
-->
<dt>suboption-data:</dt><dd> The data area for the suboption.
The length, in octets, is specified by suboption-len.
</dd> </dd>
</dl> </dl>
<t>Multiple instances of the Vendor-specific Information option may <t>Multiple instances of the Vendor-specific Information option may
appear in a DHCP message. Each instance of the option is interpreted appear in a DHCP message. Each instance of the option is interpreted
according to the option codes defined by the vendor identified by the according to the option codes defined by the vendor identified by the
Enterprise Number in that option. Servers and clients MUST NOT send Enterprise Number in that option. Servers and clients <bcp14>MUST NOT</b cp14> send
more than one instance of the Vendor-specific Information option with more than one instance of the Vendor-specific Information option with
the same Enterprise Number. Each instance of the Vendor-specific the same Enterprise Number. Each instance of the Vendor-specific
Information option MAY contain multiple suboptions.</t> Information option <bcp14>MAY</bcp14> contain multiple suboptions.</t>
<t>A client that is interested in receiving a Vendor-specific <t>A client that is interested in receiving a Vendor-specific
Information option:</t> Information option:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>MUST specify the Vendor-specific Information <li><bcp14>MUST</bcp14> specify the Vendor-specific Information
option in an Option Request option.</li> option in an Option Request option.</li>
<li>MAY specify an associated Vendor Class option <li><bcp14>MAY</bcp14> specify an associated Vendor Class option
(see <xref target="RFC3315-22.16" format="default"/>).</li> (see <xref target="RFC3315-22.16" format="default"/>).</li>
<li>MAY specify the Vendor-specific Information option <li><bcp14>MAY</bcp14> specify the Vendor-specific Information option
with appropriate data.</li> with appropriate data.</li>
</ul> </ul>
<t>Servers only return the Vendor-specific Information options if <t>Servers only return the Vendor-specific Information options if
specified in Option Request options from clients and:</t> specified in Option Request options from clients and:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>MAY use the Enterprise Numbers in the associated <li><bcp14>MAY</bcp14> use the Enterprise Numbers in the associated
Vendor Class options to restrict the set of Enterprise Numbers in Vendor Class options to restrict the set of Enterprise Numbers in
the Vendor‑specific Information options returned.</li> the Vendor-specific Information options returned.</li>
<li>MAY return all configured Vendor-specific <li><bcp14>MAY</bcp14> return all configured Vendor-specific
Information options.</li> Information options.</li>
<li>MAY use other information in the message or in its <li><bcp14>MAY</bcp14> use other information in the message or in its
configuration to determine which set of Enterprise Numbers in the configuration to determine which set of Enterprise Numbers in the
Vendor-specific Information options to return.</li> Vendor-specific Information options to return.</li>
</ul> </ul>
</section> </section>
<section anchor="RFC3315-22.18" numbered="true" toc="default"> <section anchor="RFC3315-22.18" numbered="true" toc="default">
<name>Interface-Id Option</name> <name>Interface-Id Option</name>
<t>The relay agent MAY send the Interface-Id option to identify the <t>The relay agent <bcp14>MAY</bcp14> send the Interface-Id option to id entify the
interface on which the client message was received. If a relay agent interface on which the client message was received. If a relay agent
receives a Relay-reply message with an Interface-Id option, the relay receives a Relay-reply message with an Interface-Id option, the relay
agent relays the message to the client through the interface agent relays the message to the client through the interface
identified by the option.</t> identified by the option.</t>
<t>The format of the Interface-Id option is:</t> <t>The format of the Interface-Id option is:</t>
<figure anchor="FigOption18"> <figure anchor="FigOption18">
<name>Interface-Id Option Format</name> <name>Interface-Id Option Format</name>
<artwork align="left" name="" type="" alt=""><![CDATA[ <artwork align="left" name="" type="" alt=""><![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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_INTERFACE_ID | option-len | | OPTION_INTERFACE_ID | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . . .
. interface-id . . interface-id .
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
]]></artwork>
</figure> </figure>
<dl newline="false" spacing="normal" indent="24"> <dl>
<dt> option-code</dt> <dt>option-code:</dt><dd> OPTION_INTERFACE_ID (18).</dd>
<dd>OPTION_INTERFACE_ID (18).</dd> <dt>option-len:</dt><dd> Length of interface-id field.</dd>
<dt> option-len</dt> <dt>interface-id:</dt><dd> An opaque value of arbitrary length
<dd>Length of interface-id field.</dd>
<dt> interface-id</dt>
<dd>An opaque value of arbitrary length
generated by the relay agent to identify one of the relay agent's generated by the relay agent to identify one of the relay agent's
interfaces. The length, in octets, is specified by option-len.</dd> interfaces. The length, in octets, is specified by option-len.</dd>
</dl> </dl>
<t>The server MUST copy the Interface-Id option from the Relay-forward <t>The server <bcp14>MUST</bcp14> copy the Interface-Id option from the Relay-forward
message into the Relay-reply message the server sends to the relay message into the Relay-reply message the server sends to the relay
agent in response to the Relay-forward message. This option MUST NOT agent in response to the Relay-forward message. This option <bcp14>MUST NOT</bcp14>
appear in any message except a Relay-forward or Relay-reply appear in any message except a Relay-forward or Relay-reply
message.</t> message.</t>
<t>Servers MAY use the interface-id field for parameter assignment <t>Servers <bcp14>MAY</bcp14> use the interface-id field for parameter a
policies. The interface-id value SHOULD be considered an opaque value, ssignment
policies. The interface-id value <bcp14>SHOULD</bcp14> be considered an
opaque value,
with policies based on exact match only; that is, the interface-id with policies based on exact match only; that is, the interface-id
field SHOULD NOT be internally parsed by the server. The field <bcp14>SHOULD NOT</bcp14> be internally parsed by the server. The
interface-id value for an interface SHOULD be stable and remain interface-id value for an interface <bcp14>SHOULD</bcp14> be stable and
remain
unchanged -- for example, after the relay agent is restarted; if the unchanged -- for example, after the relay agent is restarted; if the
interface-id value changes, a server will not be able to use it interface-id value changes, a server will not be able to use it
reliably in parameter assignment policies.</t> reliably in parameter assignment policies.</t>
</section> </section>
<section anchor="RFC3315-22.19" numbered="true" toc="default"> <section anchor="RFC3315-22.19" numbered="true" toc="default">
<name>Reconfigure Message Option</name> <name>Reconfigure Message Option</name>
<t>A server includes a Reconfigure Message option in a Reconfigure <t>A server includes a Reconfigure Message option in a Reconfigure
message to indicate to the client whether the client responds with a message to indicate to the client whether the client responds with a
Renew message, a Rebind message, or an Information-request message. Renew message, a Rebind message, or an Information-request message.
The format of the Reconfigure Message option is:</t> The format of the Reconfigure Message option is:</t>
<figure anchor="FigOption19"> <figure anchor="FigOption19">
<name>Reconfigure Message Option Format</name> <name>Reconfigure Message Option Format</name>
<artwork align="left" name="" type="" alt=""><![CDATA[ <artwork align="left" name="" type="" alt=""><![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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_RECONF_MSG | option-len | | OPTION_RECONF_MSG | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| msg-type | | msg-type |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+]]></artwork>
]]></artwork>
</figure> </figure>
<dl newline="false" spacing="normal" indent="24"> <dl>
<dt> option-code</dt> <dt>option-code:</dt><dd> OPTION_RECONF_MSG (19).</dd>
<dd>OPTION_RECONF_MSG (19).</dd> <dt>option-len:</dt><dd> 1.</dd>
<dt> option-len</dt> <dt>msg-type:</dt><dd> 5 for Renew message,
<dd>1.</dd> 6 for Rebind message, 11 for Information-request message.
<dt> msg-type</dt> A 1-octet unsigned integer.</dd>
<dd>5 for Renew message,
6 for Rebind message, 11 for Information-request message.
A 1‑octet unsigned integer.</dd>
</dl> </dl>
<t>The Reconfigure Message option can only appear in a Reconfigure <t>The Reconfigure Message option can only appear in a Reconfigure
message.</t> message.</t>
</section> </section>
<section anchor="RFC3315-22.20" numbered="true" toc="default"> <section anchor="RFC3315-22.20" numbered="true" toc="default">
<name>Reconfigure Accept Option</name> <name>Reconfigure Accept Option</name>
<t>A client uses the Reconfigure Accept option to announce to the <t>A client uses the Reconfigure Accept option to announce to the
server whether the client is willing to accept Reconfigure messages, server whether the client is willing to accept Reconfigure messages,
and a server uses this option to tell the client whether or not to and a server uses this option to tell the client whether or not to
accept Reconfigure messages. In the absence of this option, the accept Reconfigure messages. In the absence of this option, the
default behavior is that the client is unwilling to accept default behavior is that the client is unwilling to accept
Reconfigure messages. The format of the Reconfigure Accept Reconfigure messages. The format of the Reconfigure Accept
option is:</t> option is:</t>
<figure anchor="FigOption20"> <figure anchor="FigOption20">
<name>Reconfigure Accept Option Format</name> <name>Reconfigure Accept Option Format</name>
<artwork align="left" name="" type="" alt=""><![CDATA[ <artwork align="left" name="" type="" alt=""><![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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_RECONF_ACCEPT | option-len | | OPTION_RECONF_ACCEPT | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
]]></artwork>
</figure> </figure>
<dl newline="false" spacing="normal" indent="24"> <dl>
<dt> option-code</dt> <dt>option-code:</dt><dd> OPTION_RECONF_ACCEPT (20).</dd>
<dd>OPTION_RECONF_ACCEPT (20).</dd> <dt>option-len:</dt><dd> 0.</dd>
<dt> option-len</dt>
<dd>0.</dd>
</dl> </dl>
</section> </section>
<section anchor="IA_PD-option" numbered="true" toc="default"> <section anchor="IA_PD-option" numbered="true" toc="default">
<name>Identity Association for Prefix Delegation Option</name> <name>Identity Association for Prefix Delegation Option</name>
<t>The IA_PD option is used to carry a prefix delegation identity <t>The IA_PD option is used to carry a prefix delegation identity
association, the parameters associated with the IA_PD, and the association, the parameters associated with the IA_PD, and the
prefixes associated with it. The format of the IA_PD option is:</t> prefixes associated with it. The format of the IA_PD option is:</t>
<figure anchor="FigOption25"> <figure anchor="FigOption25">
<name>Identity Association for Prefix Delegation Option Format</name> <name>Identity Association for Prefix Delegation Option Format</name>
<artwork align="left" name="" type="" alt=""><![CDATA[ <artwork align="left" name="" type="" alt=""><![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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_IA_PD | option-len | | OPTION_IA_PD | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IAID (4 octets) | | IAID (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| T1 | | T1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| T2 | | T2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . . .
. IA_PD-options . . IA_PD-options .
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
]]></artwork>
</figure> </figure>
<dl newline="false" spacing="normal" indent="24"> <dl>
<dt> option-code</dt> <dt>option-code:</dt><dd> OPTION_IA_PD (25).</dd>
<dd>OPTION_IA_PD (25).</dd> <dt>option-len:</dt><dd> 12 + length of IA_PD-options
<dt> option-len</dt>
<dd>12 + length of IA_PD-options
field.</dd> field.</dd>
<dt> IAID</dt> <dt>IAID:</dt><dd> The unique identifier for this IA_PD; the
<dd>The unique identifier for this IA_PD; the
IAID must be unique among the identifiers for all of this IAID must be unique among the identifiers for all of this
client's IA_PDs. The number space for IA_PD IAIDs is separate from client's IA_PDs. The number space for IA_PD IAIDs is separate from
the number space for other IA option types (i.e., IA_NA). the number space for other IA option types (i.e., IA_NA).
A 4‑octet field containing an unsigned integer.</dd> A 4-octet field containing an unsigned integer.</dd>
<dt> T1</dt> <dt>T1:</dt><dd> The time interval after which the client should
<dd>The time interval after which the client should
contact the server from which the prefixes in the IA_PD contact the server from which the prefixes in the IA_PD
were obtained to extend the lifetimes of the prefixes delegated to were obtained to extend the lifetimes of the prefixes delegated to
the IA_PD; T1 is a time duration relative to the message reception the IA_PD; T1 is a time duration relative to the message reception
time expressed in units of seconds. A 4‑octet field containing time expressed in units of seconds. A 4-octet field containing
an unsigned integer.</dd> an unsigned integer.</dd>
<dt> T2</dt> <dt>T2:</dt><dd> The time interval after which the client should
<dd>The time interval after which the client should
contact any available server to extend the lifetimes of contact any available server to extend the lifetimes of
the prefixes assigned to the IA_PD; T2 is a time duration relative the prefixes assigned to the IA_PD; T2 is a time duration relative
to the message reception time expressed in units of seconds. to the message reception time expressed in units of seconds.
A 4‑octet field containing an unsigned integer.</dd> A 4-octet field containing an unsigned integer.</dd>
<dt> IA_PD-options</dt> <dt>IA_PD-options:</dt><dd> Options associated with this
<dd>Options associated with this
IA_PD. A variable-length field (12 octets less than the IA_PD. A variable-length field (12 octets less than the
value in the option-len field).</dd> value in the option-len field).</dd>
</dl> </dl>
<t>The IA_PD-options field encapsulates those options that are <t>The IA_PD-options field encapsulates those options that are
specific to this IA_PD. For example, all of the IA Prefix options specific to this IA_PD. For example, all of the IA Prefix options
(see <xref target="IAPREFIX-option" format="default"/>) (see <xref target="IAPREFIX-option" format="default"/>)
carrying the prefixes associated with this IA_PD are in the carrying the prefixes associated with this IA_PD are in the
IA_PD-options field.</t> IA_PD-options field.</t>
<t>An IA_PD option may only appear in the options area of a DHCP <t>An IA_PD option may only appear in the options area of a DHCP
message. A DHCP message may contain multiple IA_PD options (though message. A DHCP message may contain multiple IA_PD options (though
skipping to change at line 5163 skipping to change at line 5163
<t>The status of any operations involving this IA_PD is indicated in a <t>The status of any operations involving this IA_PD is indicated in a
Status Code option (see <xref target="RFC3315-22.13" format="default"/>) Status Code option (see <xref target="RFC3315-22.13" format="default"/>)
in the IA_PD-options field.</t> in the IA_PD-options field.</t>
<t>Note that an IA_PD has no explicit "lifetime" or "lease length" of <t>Note that an IA_PD has no explicit "lifetime" or "lease length" of
its own. When the valid lifetimes of all of the prefixes in an IA_PD its own. When the valid lifetimes of all of the prefixes in an IA_PD
have expired, the IA_PD can be considered as having expired. T1 and T2 have expired, the IA_PD can be considered as having expired. T1 and T2
fields are included to give the server explicit control over when a fields are included to give the server explicit control over when a
client should contact the server about a client should contact the server about a
specific IA_PD.</t> specific IA_PD.</t>
<t>In a message sent by a client to a server, <t>In a message sent by a client to a server,
the T1 and T2 fields SHOULD be set to 0. The server MUST the T1 and T2 fields <bcp14>SHOULD</bcp14> be set to 0. The server <bcp1 4>MUST</bcp14>
ignore any values in these fields in messages received from a ignore any values in these fields in messages received from a
client.</t> client.</t>
<t>In a message sent by a server to a client, <t>In a message sent by a server to a client,
the client MUST use the values in the T1 and T2 fields for the client <bcp14>MUST</bcp14> use the values in the T1 and T2 fields fo r
the T1 and T2 timers, unless values in those fields are 0. the T1 and T2 timers, unless values in those fields are 0.
The values in the T1 and T2 fields are the number of seconds until T1 The values in the T1 and T2 fields are the number of seconds until T1
and T2.</t> and T2.</t>
<t>The server selects the T1 and T2 times to allow the <t>The server selects the T1 and T2 times to allow the
client to extend the lifetimes of any prefixes in the IA_PD client to extend the lifetimes of any prefixes in the IA_PD
before the lifetimes expire, even if the server is before the lifetimes expire, even if the server is
unavailable for some short period of time. Recommended values for T1 unavailable for some short period of time. Recommended values for T1
and T2 are 0.5 and 0.8 times the shortest preferred lifetime of the and T2 are 0.5 and 0.8 times the shortest preferred lifetime of the
prefixes in the IA_PD that the server is willing to extend, prefixes in the IA_PD that the server is willing to extend,
respectively. If the time at which the prefixes in an IA_PD are to be respectively. If the time at which the prefixes in an IA_PD are to be
renewed is to be left to the discretion of the client, the renewed is to be left to the discretion of the client, the
server sets T1 and T2 to 0. The client MUST server sets T1 and T2 to 0. The client <bcp14>MUST</bcp14>
follow the rules defined in <xref target="t1-t2-0" format="default"/>.</ t> follow the rules defined in <xref target="t1-t2-0" format="default"/>.</ t>
<t>If a client receives an IA_PD with T1 greater than T2 <t>If a client receives an IA_PD with T1 greater than T2
and both T1 and T2 are greater than 0, the client discards and both T1 and T2 are greater than 0, the client discards
the IA_PD option and processes the remainder of the message as though the IA_PD option and processes the remainder of the message as though
the server had not included the IA_PD option.</t> the server had not included the IA_PD option.</t>
</section> </section>
<section anchor="IAPREFIX-option" numbered="true" toc="default"> <section anchor="IAPREFIX-option" numbered="true" toc="default">
<name>IA Prefix Option</name> <name>IA Prefix Option</name>
<t>The IA Prefix option is used to specify a prefix <t>The IA Prefix option is used to specify a prefix
associated with an IA_PD. The IA Prefix option must be encapsulated associated with an IA_PD. The IA Prefix option must be encapsulated
in the IA_PD‑options field of an IA_PD option in the IA_PD-options field of an IA_PD option
(see <xref target="IA_PD-option" format="default"/>).</t> (see <xref target="IA_PD-option" format="default"/>).</t>
<figure anchor="FigOption26"> <figure anchor="FigOption26">
<name>IA Prefix Option Format</name> <name>IA Prefix Option Format</name>
<artwork align="left" name="" type="" alt=""><![CDATA[ <artwork align="left" name="" type="" alt=""><![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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_IAPREFIX | option-len | | OPTION_IAPREFIX | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| preferred-lifetime | | preferred-lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| valid-lifetime | | valid-lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| prefix-length | | | prefix-length | |
+-+-+-+-+-+-+-+-+ IPv6-prefix | +-+-+-+-+-+-+-+-+ IPv6-prefix |
| (16 octets) | | (16 octets) |
| | | |
| | | |
| | | |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | . | | .
+-+-+-+-+-+-+-+-+ . +-+-+-+-+-+-+-+-+ .
. IAprefix-options . . IAprefix-options .
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
]]></artwork>
</figure> </figure>
<dl newline="false" spacing="normal" indent="24"> <dl>
<dt> option-code</dt> <dt>option-code:</dt><dd> OPTION_IAPREFIX (26).</dd>
<dd>OPTION_IAPREFIX (26).</dd> <dt>option-len:</dt><dd> 25 + length of IAprefix-options
<dt> option-len</dt>
<dd>25 + length of IAprefix-options
field.</dd> field.</dd>
<dt> preferred-lifetime</dt> <dt>preferred-lifetime:</dt><dd> The preferred
<dd>The preferred
lifetime for the prefix in the option, expressed in units of lifetime for the prefix in the option, expressed in units of
seconds. A value of 0xffffffff represents "infinity" seconds. A value of 0xffffffff represents "infinity"
(see <xref target="RFC3315-5.6" format="default"/>). A 4‑octet field (see <xref target="RFC3315-5.6" format="default"/>). A 4-octet field
containing an unsigned integer.</dd> containing an unsigned integer.</dd>
<dt> valid-lifetime</dt> <dt>valid-lifetime:</dt><dd> The valid lifetime for the
<dd>The valid lifetime for the
prefix in the option, expressed in units of seconds. A value of prefix in the option, expressed in units of seconds. A value of
0xffffffff represents "infinity". A 4‑octet field 0xffffffff represents "infinity". A 4-octet field
containing an unsigned integer.</dd> containing an unsigned integer.</dd>
<dt> prefix-length</dt> <dt>prefix-length:</dt><dd> Length for this prefix in bits.
<dd>Length for this prefix in bits. A 1-octet unsigned integer.</dd>
A 1‑octet unsigned integer.</dd> <dt>IPv6-prefix:</dt><dd> An IPv6 prefix. A 16-octet field.</dd>
<dt> IPv6-prefix</dt> <dt>IAprefix-options:</dt><dd> Options associated with this
<dd>An IPv6 prefix. A 16-octet field.</dd>
<dt> IAprefix-options</dt>
<dd>Options associated with this
prefix. A variable-length field (25 octets less than the prefix. A variable-length field (25 octets less than the
value in the option-len field).</dd> value in the option-len field).</dd>
</dl> </dl>
<t>In a message sent by a client to a server, <t>In a message sent by a client to a server,
the preferred-lifetime and valid-lifetime fields SHOULD be set to 0. the preferred-lifetime and valid-lifetime fields <bcp14>SHOULD</bcp14> b
The server MUST ignore any received values in these e set to 0.
The server <bcp14>MUST</bcp14> ignore any received values in these
lifetime fields.</t> lifetime fields.</t>
<t>The client SHOULD NOT send an IA Prefix option with 0 in the <t>The client <bcp14>SHOULD NOT</bcp14> send an IA Prefix option with 0
"prefix‑length" field (and an unspecified value (::) in the in the
"IPv6‑prefix" field). A client MAY send a non-zero value in the "prefix-length" field (and an unspecified value (::) in the
"IPv6-prefix" field). A client <bcp14>MAY</bcp14> send a non-zero value
in the
"prefix-length" field and the unspecified value (::) in the "prefix-length" field and the unspecified value (::) in the
"IPv6‑prefix" field to indicate a preference for the size of the "IPv6-prefix" field to indicate a preference for the size of the
prefix to be delegated. See <xref target="RFC8168" format="default"/> fo r prefix to be delegated. See <xref target="RFC8168" format="default"/> fo r
further details on prefix-length hints.</t> further details on prefix-length hints.</t>
<t>The client MUST discard any prefixes for which the preferred <t>The client <bcp14>MUST</bcp14> discard any prefixes for which the pre ferred
lifetime is greater than the valid lifetime.</t> lifetime is greater than the valid lifetime.</t>
<t>The values in the preferred-lifetime and valid-lifetime fields <t>The values in the preferred-lifetime and valid-lifetime fields
are the number of seconds remaining in each lifetime. See are the number of seconds remaining in each lifetime. See
<xref target="reply-solicit-request-renew-rebind" format="default"/> for more details <xref target="reply-solicit-request-renew-rebind" format="default"/> for more details
on how these values are used for delegated prefixes.</t> on how these values are used for delegated prefixes.</t>
<t>As per <xref target="RFC3315-5.6" format="default"/>, the value of 0x ffffffff <t>As per <xref target="RFC3315-5.6" format="default"/>, the value of 0x ffffffff
for the preferred lifetime or the valid lifetime is taken to mean for the preferred lifetime or the valid lifetime is taken to mean
"infinity" and should be used carefully.</t> "infinity" and should be used carefully.</t>
<t>An IA Prefix option may appear only in an IA_PD option. More <t>An IA Prefix option may appear only in an IA_PD option. More
than one IA Prefix option can appear in a single IA_PD option.</t> than one IA Prefix option can appear in a single IA_PD option.</t>
<t>The status of any operations involving this IA Prefix option is <t>The status of any operations involving this IA Prefix option is
indicated in a Status Code option (see <xref target="RFC3315-22.13" form at="default"/>) indicated in a Status Code option (see <xref target="RFC3315-22.13" form at="default"/>)
in the IAprefix‑options field.</t> in the IAprefix-options field.</t>
</section> </section>
<section anchor="RFC4242-Option" numbered="true" toc="default"> <section anchor="RFC4242-Option" numbered="true" toc="default">
<name>Information Refresh Time Option</name> <name>Information Refresh Time Option</name>
<t>This option is requested by clients and returned by servers to <t>This option is requested by clients and returned by servers to
specify an upper bound for how long a client should wait before specify an upper bound for how long a client should wait before
refreshing information retrieved refreshing information retrieved
from a DHCP server. It is only used in Reply messages in response to from a DHCP server. It is only used in Reply messages in response to
Information-request messages. In other messages, there will usually Information-request messages. In other messages, there will usually
be other information that indicates when the client should contact the be other information that indicates when the client should contact the
server, e.g., T1/T2 times and lifetimes. This option is useful when server, e.g., T1/T2 times and lifetimes. This option is useful when
the configuration parameters change or during a renumbering event, as the configuration parameters change or during a renumbering event, as
clients running in the stateless mode will be able to update their clients running in the stateless mode will be able to update their
configuration.</t> configuration.</t>
<t>The format of the Information Refresh Time option is:</t> <t>The format of the Information Refresh Time option is:</t>
<figure anchor="FigOption32"> <figure anchor="FigOption32">
<name>Information Refresh Time Option Format</name> <name>Information Refresh Time Option Format</name>
<artwork align="left" name="" type="" alt=""><![CDATA[ <artwork align="left" name="" type="" alt=""><![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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|OPTION_INFORMATION_REFRESH_TIME| option-len | |OPTION_INFORMATION_REFRESH_TIME| option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| information-refresh-time | | information-refresh-time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
]]></artwork>
</figure> </figure>
<dl newline="false" spacing="normal" indent="30"> <dl>
<dt> option-code</dt> <dt>option-code:</dt><dd> OPTION_INFORMATION_REFRESH_TIME (32).</dd>
<dd>OPTION_INFORMATION_REFRESH_TIME (32).</dd> <dt>option-len:</dt><dd> 4.</dd>
<dt> option-len</dt> <dt>information-refresh-time:</dt><dd> Time duration relative to
<dd>4.</dd> the current time, expressed in units of seconds. A 4-octet
<dt> information-refresh-time</dt>
<dd>Time duration relative to
the current time, expressed in units of seconds. A 4‑octet
field containing an unsigned integer.</dd> field containing an unsigned integer.</dd>
</dl> </dl>
<t>A DHCP client MUST request this option in the Option Request option <t>A DHCP client <bcp14>MUST</bcp14> request this option in the Option R equest option
(see <xref target="RFC3315-22.7" format="default"/>) when sending Inform ation-request (see <xref target="RFC3315-22.7" format="default"/>) when sending Inform ation-request
messages. A client MUST NOT request this option in the Option Request messages. A client <bcp14>MUST NOT</bcp14> request this option in the Op tion Request
option in any other messages.</t> option in any other messages.</t>
<t>A server sending a Reply to an Information-request message SHOULD <t>A server sending a Reply to an Information-request message <bcp14>SHO ULD</bcp14>
include this option if it is requested in the Option Request option include this option if it is requested in the Option Request option
of the Information-request. The option value MUST NOT be smaller of the Information-request. The option value <bcp14>MUST NOT</bcp14> be
than IRT_MINIMUM. This option MUST only appear in the top-level smaller
than IRT_MINIMUM. This option <bcp14>MUST</bcp14> only appear in the top
-level
options area of Reply messages.</t> options area of Reply messages.</t>
<t>If the Reply to an Information-request message does not contain this <t>If the Reply to an Information-request message does not contain this
option, the client MUST behave as if the option with the value option, the client <bcp14>MUST</bcp14> behave as if the option with the value
IRT_DEFAULT was provided.</t> IRT_DEFAULT was provided.</t>
<t>A client MUST use the refresh time IRT_MINIMUM if it receives the <t>A client <bcp14>MUST</bcp14> use the refresh time IRT_MINIMUM if it r eceives the
option with a value less than IRT_MINIMUM.</t> option with a value less than IRT_MINIMUM.</t>
<t>As per <xref target="RFC3315-5.6" format="default"/>, the value 0xfff fffff is taken to <t>As per <xref target="RFC3315-5.6" format="default"/>, the value 0xfff fffff is taken to
mean "infinity" and implies that the client should not refresh its mean "infinity" and implies that the client should not refresh its
configuration data without some other trigger (such as detecting configuration data without some other trigger (such as detecting
movement to a new link).</t> movement to a new link).</t>
<t>If a client contacts the server to obtain new data or refresh some <t>If a client contacts the server to obtain new data or refresh some
existing data before the refresh time expires, then it SHOULD also existing data before the refresh time expires, then it <bcp14>SHOULD</bc p14> also
refresh all data covered by this option.</t> refresh all data covered by this option.</t>
<t>When the client detects that the refresh time has expired, it SHOULD <t>When the client detects that the refresh time has expired, it <bcp14> SHOULD</bcp14>
try to update its configuration data by sending an try to update its configuration data by sending an
Information‑request as specified in Information-request as specified in
<xref target="RFC3315-18.1.5" format="default"/>, except that the <xref target="RFC3315-18.1.5" format="default"/>, except that the
client MUST delay sending the first Information-request by a random client <bcp14>MUST</bcp14> delay sending the first Information-request b y a random
amount of time between 0 and INF_MAX_DELAY.</t> amount of time between 0 and INF_MAX_DELAY.</t>
<t>A client MAY have a maximum value for the refresh time, where that <t>A client <bcp14>MAY</bcp14> have a maximum value for the refresh time , where that
value is used whenever the client receives this option with a value value is used whenever the client receives this option with a value
higher than the maximum. This also means that the maximum value is higher than the maximum. This also means that the maximum value is
used when the received value is "infinity". A maximum value might used when the received value is "infinity". A maximum value might
make the client less vulnerable to attacks based on forged DHCP make the client less vulnerable to attacks based on forged DHCP
messages. Without a maximum value, a client may be made to use wrong messages. Without a maximum value, a client may be made to use wrong
information for a possibly infinite period of time. There may, information for a possibly infinite period of time. There may,
however, be reasons for having a very long refresh time, so it may be however, be reasons for having a very long refresh time, so it may be
useful for this maximum value to be configurable.</t> useful for this maximum value to be configurable.</t>
</section> </section>
<section anchor="SOL_MAX_RT_option" numbered="true" toc="default"> <section anchor="SOL_MAX_RT_option" numbered="true" toc="default">
skipping to change at line 5355 skipping to change at line 5343
<t>A DHCP server sends the SOL_MAX_RT option to a client to override <t>A DHCP server sends the SOL_MAX_RT option to a client to override
the default value of SOL_MAX_RT. The value of SOL_MAX_RT in the option the default value of SOL_MAX_RT. The value of SOL_MAX_RT in the option
replaces the default value defined in <xref target="RFC3315-5.5" format= "default"/>. One use for the SOL_MAX_RT option is to replaces the default value defined in <xref target="RFC3315-5.5" format= "default"/>. One use for the SOL_MAX_RT option is to
set a higher value for SOL_MAX_RT; this reduces the Solicit traffic set a higher value for SOL_MAX_RT; this reduces the Solicit traffic
from a client that has not received a response to its Solicit from a client that has not received a response to its Solicit
messages.</t> messages.</t>
<t>The format of the SOL_MAX_RT option is:</t> <t>The format of the SOL_MAX_RT option is:</t>
<figure anchor="FigOption82"> <figure anchor="FigOption82">
<name>SOL_MAX_RT Option Format</name> <name>SOL_MAX_RT Option Format</name>
<artwork align="left" name="" type="" alt=""><![CDATA[ <artwork align="left" name="" type="" alt=""><![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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_SOL_MAX_RT | option-len | | OPTION_SOL_MAX_RT | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SOL_MAX_RT value | | SOL_MAX_RT value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
]]></artwork>
</figure> </figure>
<dl newline="false" spacing="normal" indent="24"> <dl>
<dt> option-code</dt> <dt>option-code:</dt><dd> OPTION_SOL_MAX_RT (82).</dd>
<dd>OPTION_SOL_MAX_RT (82).</dd> <dt>option-len:</dt><dd> 4.</dd>
<dt> option-len</dt> <dt>SOL_MAX_RT value:</dt><dd> Overriding value for SOL_MAX_RT
<dd>4.</dd> in seconds; <bcp14>MUST</bcp14> be in this range: 60 &lt;= "value" &l
<dt> SOL_MAX_RT value</dt> t;= 86400
<dd>Overriding value for SOL_MAX_RT (1 day). A 4-octet field containing an unsigned integer.</dd>
in seconds; MUST be in this range: 60 &lt;= "value" &lt;= 86400
(1 day). A 4‑octet field containing an unsigned integer.</dd>
</dl> </dl>
<t>A DHCP client MUST include the SOL_MAX_RT option code in any Option <t>A DHCP client <bcp14>MUST</bcp14> include the SOL_MAX_RT option code in any Option
Request option (see <xref target="RFC3315-22.7" format="default"/>) it s ends in a Request option (see <xref target="RFC3315-22.7" format="default"/>) it s ends in a
Solicit message.</t> Solicit message.</t>
<t>The DHCP server MAY include the SOL_MAX_RT option in any response <t>The DHCP server <bcp14>MAY</bcp14> include the SOL_MAX_RT option in a ny response
it sends to a client that has included the SOL_MAX_RT option code in it sends to a client that has included the SOL_MAX_RT option code in
an Option Request option. The SOL_MAX_RT option is sent as a top-level an Option Request option. The SOL_MAX_RT option is sent as a top-level
option in the message to the client.</t> option in the message to the client.</t>
<t>A DHCP client MUST ignore any SOL_MAX_RT option values that are <t>A DHCP client <bcp14>MUST</bcp14> ignore any SOL_MAX_RT option values that are
less than 60 or more than 86400.</t> less than 60 or more than 86400.</t>
<t>If a DHCP client receives a message containing a SOL_MAX_RT option <t>If a DHCP client receives a message containing a SOL_MAX_RT option
that has a valid value for SOL_MAX_RT, the client MUST set its that has a valid value for SOL_MAX_RT, the client <bcp14>MUST</bcp14> se t its
internal SOL_MAX_RT parameter to the value contained in the SOL_MAX_RT internal SOL_MAX_RT parameter to the value contained in the SOL_MAX_RT
option. This value of SOL_MAX_RT is then used by the retransmission option. This value of SOL_MAX_RT is then used by the retransmission
mechanism defined in Sections <xref target="RFC3315-14" format="counter" /> and <xref target="solicit-create-transmit" format="counter"/>.</t> mechanism defined in Sections <xref target="RFC3315-14" format="counter" /> and <xref target="solicit-create-transmit" format="counter"/>.</t>
<t>The purpose of this mechanism is to give network administrators <t>The purpose of this mechanism is to give network administrators
a way to avoid excessive DHCP traffic if all DHCP servers a way to avoid excessive DHCP traffic if all DHCP servers
become unavailable. Therefore, this value is expected become unavailable. Therefore, this value is expected
to be retained for as long as practically possible.</t> to be retained for as long as practically possible.</t>
<t>An updated SOL_MAX_RT value applies only to the network interface on <t>An updated SOL_MAX_RT value applies only to the network interface on
which the client received the SOL_MAX_RT option.</t> which the client received the SOL_MAX_RT option.</t>
</section> </section>
<section anchor="INF_MAX_RT_option" numbered="true" toc="default"> <section anchor="INF_MAX_RT_option" numbered="true" toc="default">
<name>INF_MAX_RT Option</name> <name>INF_MAX_RT Option</name>
<t>A DHCP server sends the INF_MAX_RT option to a client to override <t>A DHCP server sends the INF_MAX_RT option to a client to override
the default value of INF_MAX_RT. The value of INF_MAX_RT in the option the default value of INF_MAX_RT. The value of INF_MAX_RT in the option
replaces the default value defined in <xref target="RFC3315-5.5" format= "default"/>. One use for the INF_MAX_RT option is to replaces the default value defined in <xref target="RFC3315-5.5" format= "default"/>. One use for the INF_MAX_RT option is to
set a higher value for INF_MAX_RT; this reduces the set a higher value for INF_MAX_RT; this reduces the
Information-request traffic from a client that has not received a Information-request traffic from a client that has not received a
response to its Information-request messages.</t> response to its Information-request messages.</t>
<t>The format of the INF_MAX_RT option is:</t> <t>The format of the INF_MAX_RT option is:</t>
<figure anchor="FigOption83"> <figure anchor="FigOption83">
<name>INF_MAX_RT Option Format</name> <name>INF_MAX_RT Option Format</name>
<artwork align="left" name="" type="" alt=""><![CDATA[ <artwork align="left" name="" type="" alt=""><![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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_INF_MAX_RT | option-len | | OPTION_INF_MAX_RT | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| INF_MAX_RT value | | INF_MAX_RT value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
]]></artwork>
</figure> </figure>
<dl newline="false" spacing="normal" indent="24"> <dl>
<dt> option-code</dt> <dt>option-code:</dt><dd> OPTION_INF_MAX_RT (83).</dd>
<dd>OPTION_INF_MAX_RT (83).</dd> <dt>option-len:</dt><dd> 4.</dd>
<dt> option-len</dt> <dt>INF_MAX_RT value:</dt><dd> Overriding value for INF_MAX_RT
<dd>4.</dd> in seconds; <bcp14>MUST</bcp14> be in this range: 60 &lt;= "value" &l
<dt> INF_MAX_RT value</dt> t;= 86400
<dd>Overriding value for INF_MAX_RT (1 day). A 4-octet field containing an unsigned integer.</dd>
in seconds; MUST be in this range: 60 &lt;= "value" &lt;= 86400
(1 day). A 4‑octet field containing an unsigned integer.</dd>
</dl> </dl>
<t>A DHCP client MUST include the INF_MAX_RT option code in any Option <t>A DHCP client <bcp14>MUST</bcp14> include the INF_MAX_RT option code in any Option
Request option (see <xref target="RFC3315-22.7" format="default"/>) it s ends in Request option (see <xref target="RFC3315-22.7" format="default"/>) it s ends in
an Information-request message.</t> an Information-request message.</t>
<t>The DHCP server MAY include the INF_MAX_RT option in any response <t>The DHCP server <bcp14>MAY</bcp14> include the INF_MAX_RT option in a ny response
it sends to a client that has included the INF_MAX_RT option code in it sends to a client that has included the INF_MAX_RT option code in
an Option Request option. The INF_MAX_RT option is a top-level an Option Request option. The INF_MAX_RT option is a top-level
option in the message to the client.</t> option in the message to the client.</t>
<t>A DHCP client MUST ignore any INF_MAX_RT option values that are <t>A DHCP client <bcp14>MUST</bcp14> ignore any INF_MAX_RT option values that are
less than 60 or more than 86400.</t> less than 60 or more than 86400.</t>
<t>If a DHCP client receives a message containing an INF_MAX_RT option <t>If a DHCP client receives a message containing an INF_MAX_RT option
that has a valid value for INF_MAX_RT, the client MUST set its that has a valid value for INF_MAX_RT, the client <bcp14>MUST</bcp14> se t its
internal INF_MAX_RT parameter to the value contained in the INF_MAX_RT internal INF_MAX_RT parameter to the value contained in the INF_MAX_RT
option. This value of INF_MAX_RT is then used by the retransmission option. This value of INF_MAX_RT is then used by the retransmission
mechanism defined in Sections <xref target="RFC3315-14" format="counter" /> and <xref target="RFC3315-18.1.5" format="counter"/>.</t> mechanism defined in Sections <xref target="RFC3315-14" format="counter" /> and <xref target="RFC3315-18.1.5" format="counter"/>.</t>
<t>An updated INF_MAX_RT value applies only to the network interface on <t>An updated INF_MAX_RT value applies only to the network interface on
which the client received the INF_MAX_RT option.</t> which the client received the INF_MAX_RT option.</t>
</section> </section>
</section> </section>
<section anchor="impl-status" title="Implementation status">
<t>NOTE TO RFC EDITOR: Please remove this section before publication.
It is intended for the IESG evaluation.</t>
<t>This section records the status of known implementations of the
protocol defined by this specification at the time of posting of
this Internet-Draft, and is based on a proposal described in
RFC 7942. The description of implementations in this section is
intended to assist the IETF in its decision processes in
progressing drafts to RFCs. Please note that the listing of any
individual implementation here does not imply endorsement by the
IETF. Furthermore, no effort has been spent to verify the
information presented here that was supplied by IETF contributors.
This is not intended as, and must not be construed to be, a
catalog of available implementations or their features. Readers
are advised to note that other implementations may exist.</t>
<t>According to RFC 7942, "this will allow reviewers and working
groups to assign due consideration to documents that have the
benefit of running code, which may serve as evidence of valuable
experimentation and feedback that have made the implemented
protocols more mature. It is up to the individual working groups
to use this information as they see fit".</t>
<t>The DHCPv6 protocol was originally published as RFC 3315 in July 2003.
Many extensions were defined and RFC
8415 was published in November 2018. The protocol was implemented by many
vendors that claim DHCPv6 compliance.
It is sometimes difficult to determine whether full compliance with 8415 i
s claimed.</t>
<t>The DHCPv6 protocol enjoys multiple interoperable implementations from
all sectors of industry.
There are many open source and proprietary implementations, both general s
oftware and hardware-specific.
The following implementations (listed alphabetically) are known to support
DHCPv6:</t>
<ul>
<li>Android (Google): In March 2023 (IETF'115) Google revealed it is wor
king on the PD client
implementation for Android. Open source. Maturity: prototype. Details ar
e scarce, but it seems
the implementation will focus on PD functionality. Source: https://datat
racker.ietf.org/meeting/116/materials/slides-116-v6ops-using-dhcp-pd-to-allocate
-64-per-host-in-broadcast-networks-00,
slide 17.</li>
<li>Cisco Prime Network Registrar: Cisco's software suite that supports
many protocols, including RFC8415
compliant server functionality. Proprietary. Maturity: widely used. One
of the authors of this I-D was
heavily involved in CPNR development. Source:
https://www.cisco.com/c/en/us/products/collateral/cloud-systems-manageme
nt/prime-network-registrar/datasheet-c78-729989.html.</li>
<li>dhcpcd: Client implementation. Works on many Linux and BSD distribut
ions, but seems to be the
default client for various BSD flavors. Open source (BSD). Maturity: wid
ely used, in particular on BSD systems.
Source: https://github.com/NetworkConfiguration/dhcpcd .</li>
<li>dhcpd (ISC): Client, relay and server implementation, present in mos
t Linux and BSD
distributions. Open source (Mozilla Public License v2). The project is n
o longer developed, but
the software is still in wide use. Source: https://www.isc.org/dhcp/ .</
li>
<li>dibbler: Client, relay and server implementation. Limited compatibil
ity with RFC8415. Open
source (GNU GPLv2). The project is no longer developed, but the software
is still in wide use. The biggest
known deployment is 16 million devices. One of the authors of this I-D w
as the leading developer.
Source: https://klub.com.pl/dhcpv6/ .</li>
<li>dnsmasq: Probably the most popular implementation in terms of number
of devices. Very popular
among CPE and various home appliances. Client and server implementation
with some relay capabilities. Open
source (GPL v2 or v3). Source: https://dnsmasq.org/ .</li>
<li>EdgeMax (Ubiquiti): Proprietary implementation running on EdgeMax ha
rdware, home and small enterprise
gateways and switches. Focused on DHCPv6-PD. Source: https://help.ui.com
/hc/en-us/articles/115002531728-EdgeRouter-Beginners-Guide-to-EdgeRouter.</li>
<li>EOS (Arista): Proprietary implementation for network switches, route
rs and other networking
hardware. RFC8415 support explicitly stated. Server, client, relay imple
mentation. Source:
https://www.arista.com/en/um-eos/eos-ipv6 .</li>
<li>FreeRADIUS: RADIUS implementation that also provides DHCPv6 server f
unctionality. Open
source.</li>
<li>Huawei: Server, client and relay functionalities are available on mo
st routers and switches.
Proprietary. Source: https://support.huawei.com/hedex/hdx.do?docid=EDOC1
100247463&amp;id=EN-US_TASK_0176372622, see
"Configuring Server/Relay/client/PD client" on the left panel. </li>
<li>iOS (Apple): Client implementation running on Apple portable devices
(iPhones, iPads, etc.). Proprietary.
The implementation is widely used.</li>
<li>IOS (Cisco): Server, relay, and client implementation that runs on C
isco routers, switches and
other networking hardware. Proprietary. Widely used. Source:
https://community.cisco.com/t5/networking-knowledge-base/part-1-implemen
ting-dhcpv6-stateful-dhcpv6/ta-p/3145631
.</li>
<li>Kea (ISC): Server implementation. Open source (Mozilla Public Licens
e v2). It is a modern
replacement for now retired isc-dhcp. More than 500 users subscribed to
the mailing list. One of the authors of
this I-D is the lead developer.
Source: https://kea.readthedocs.io/en/kea-2.4.0/arm/dhcp6-srv.html#suppo
rted-dhcpv6-standards .</li>
<li>JunOS (Juniper): Server, relay, and client implementation that runs
on Juniper routers,
switches, and other networking hardware. Proprietary. Widely used. Sourc
e:
https://www.juniper.net/documentation/us/en/software/junos/dhcp/topics/t
opic-map/dhcpv6-server.html .</li>
<li>macOS (Apple): Client implementation for Macs (laptops and desktops)
. Proprietary. Widely used.</li>
<li>odhcp6c (OpenWRT): Minimalistic client implementation intended for e
mbedded environment. Open source
(GPL-2). Source: https://github.com/openwrt/odhcp6c .</li>
<li>RouterOS (Mikrotik): Server, relay, and client implementation runnin
g on Mikrotik networking
hardware (routers, switches, many other appliances). Proprietary. Source
s:
https://wiki.mikrotik.com/wiki/Manual:IPv6/DHCP_Client, https://wiki.mik
rotik.com/wiki/Manual:IPv6/DHCP_Server, https://wiki.mikrotik.com/wiki/Manual:Ro
uterOS6_news .</li>
<li>ServPoET (Finepoint): Server implementation. Proprietary. One of the
authors of this I-D was the lead
developer. Source: https://finepoint.com/servpoet/ .</li>
<li>udhcpc6 (busybox): Minimum footprint implementation, intended for em
bedded devices. It used to
be a separate project (udhcpc6), but it is now part of the BusyBox proje
ct. Open source (GPL-v2). Client
implementation. Source: https://udhcp.busybox.net/README.udhcpc .</li>
<li>Unifi (Ubiquiti): Server, relay, and client implementation running o
n UniFi hardware (routers, switches,
firewalls). Proprietary. Source: https://help.ui.com/hc/en-us/articles/1
15005868927-UniFi-Gateway-Static-IPv6-and-DHCPv6-Prefix-Delegation.</li>
<li>Windows (Microsoft): Microsoft Windows provides client implementatio
n, which is probably still
the most popular OS on desktops and laptops. The server version of Windo
ws provides DHCPv6 server implementation. Proprietary.</li>
</ul>
<t>The DHCPv6 support is also mandated by some third party specs. For exampl
e, all cable modems conformant to
DOCSIS3.0 or later must support DHCPv6 client functionality.</t>
<t>There are many large scale deployments that use DHCPv6. One of them is Co
mcast's Xfinity. Authors are
aware of many other large scale country wide deployments, but due to signed
Non-Disclosure Agreements cannot
list them.</t>
<t>University of New Hampshire's InterOperability Laboratory runs USGv6 Test
ing Program. Testing DHCPv6
compliance is one aspect of the program.</t>
<t>While the original IPv6 Ready Logo testing involved the original DHCPv6 s
pecifications (primarily RFC3315,
RFC3633), the large number of tested and certified implementations supports
the breadth and depth of DHCPv6
implementations available and deployed in the marketplace over the years tha
t confirm the protocol specifications are
up to Internet Standard. See https://www.ipv6ready.org/db/index.php/public/s
earch/?l=&amp;c=&amp;ds=&amp;de=&amp;pc=&amp;ap=2&amp;oem=&amp;etc=D&amp;fw=&amp
;vn=&amp;do=1&amp;o=6.- </t>
</section>
<section anchor="security" numbered="true" toc="default"> <section anchor="security" numbered="true" toc="default">
<name>Security Considerations</name> <name>Security Considerations</name>
<t>This section discusses security considerations that are not related <t>This section discusses security considerations that are not related
to privacy. See <xref target="privacy" format="default"/> for a discussion to privacy. See <xref target="privacy" format="default"/> for a discussion
dedicated to privacy.</t> dedicated to privacy.</t>
<t>The threat to DHCP is inherently an insider threat (assuming a <t>The threat to DHCP is inherently an insider threat (assuming a
properly configured network where DHCP ports are blocked on the properly configured network where DHCP ports are blocked on the
perimeter gateways of the enterprise). Regardless of the gateway perimeter gateways of the enterprise). Regardless of the gateway
configuration, however, the potential attacks by insiders and configuration, however, the potential attacks by insiders and
outsiders are the same.</t> outsiders are the same.</t>
<t>DHCP lacks end-to-end encryption between clients and servers; thus, <t>DHCP lacks end-to-end encryption between clients and servers; thus,
hijacking, tampering, and eavesdropping attacks are all possible hijacking, tampering, and eavesdropping attacks are all possible
as a result. Some network environments (discussed below) can be as a result. Some network environments (discussed below) can be
secured through various means to minimize these attacks.</t> secured through various means to minimize these attacks.</t>
<t>The threat common to both the client and the server is the <t>The threat common to both the client and the server is the
"resource-exhaustion" DoS attack. These attacks typically involve the "resource-exhaustion" DoS attack. Typically, these attacks involve the
exhaustion of available assigned addresses or delegatable prefixes, or exhaustion of available assigned addresses or delegatable prefixes or
the exhaustion of CPU or network bandwidth, and are present any time the exhaustion of CPU or network bandwidth, and they are present any time
there is a shared resource. Some forms of these exhaustion attacks there is a shared resource. Some forms of these exhaustion attacks
can be partially mitigated by appropriate server policy, e.g., limiting can be partially mitigated by appropriate server policy, e.g., limiting
the maximum number of leases any one client can get, limiting the number the maximum number of leases any one client can get, limiting the number
of leases one client can decline, and limiting number of messages a of leases one client can decline, and limiting the number of messages a
single client can transmit of a period of time.</t> single client can transmit of a period of time.</t>
<section anchor="security-client" numbered="true" toc="default"> <section anchor="security-client" numbered="true" toc="default">
<name>Client Security Considerations</name> <name>Client Security Considerations</name>
<t>One attack specific to a DHCP client is the establishment of a <t>One attack specific to a DHCP client is the establishment of a
malicious server with the intent of providing incorrect configuration malicious server with the intent of providing incorrect configuration
information to the client. The motivation for doing so may be to mount information to the client. The motivation for doing so may be to mount
a "man in the middle" attack that causes the client to communicate with a "man-in-the-middle" attack that causes the client to communicate with
a malicious server instead of a valid server for some service (such as a malicious server instead of a valid server for some service (such as
DNS or NTP). The malicious server may also mount a DoS attack DNS or NTP). The malicious server may also mount a DoS attack
through misconfiguration of the client; this attack would cause all through misconfiguration of the client; this attack would cause all
network communication from the client to fail.</t> network communication from the client to fail.</t>
<t>A malicious DHCP server might cause a client to set its SOL_MAX_RT <t>A malicious DHCP server might cause a client to set its SOL_MAX_RT
and INF_MAX_RT parameters to an unreasonably high value with the and INF_MAX_RT parameters to an unreasonably high value with the
SOL_MAX_RT (see <xref target="SOL_MAX_RT_option" format="default"/>) and I NF_MAX_RT SOL_MAX_RT (see <xref target="SOL_MAX_RT_option" format="default"/>) and I NF_MAX_RT
(see <xref target="INF_MAX_RT_option" format="default"/>) options; this ma y cause (see <xref target="INF_MAX_RT_option" format="default"/>) options; this ma y cause
an undue delay in a client completing its DHCP protocol transaction an undue delay in a client completing its DHCP protocol transaction
in the case where no other valid response is received. Assuming that in the case where no other valid response is received. Assuming that
the client also receives a response from a valid DHCP server, the client also receives a response from a valid DHCP server,
large values for SOL_MAX_RT and INF_MAX_RT will not have any effect.</t> large values for SOL_MAX_RT and INF_MAX_RT will not have any effect.</t>
<t>Another threat to DHCP clients originates from mistakenly or <t>Another threat to DHCP clients originates from mistakenly or
accidentally configured DHCP servers that answer DHCP client requests accidentally configured DHCP servers that answer DHCP client requests
with unintentionally incorrect configuration parameters.</t> with unintentionally incorrect configuration parameters.</t>
<t>If a client implementation supports the reconfigure mechanism, also see <t>If a client implementation supports the reconfigure mechanism, see
<xref target="security-rkap"/> below.</t> <xref target="security-rkap"/>.</t>
</section> </section>
<section anchor="security-server" numbered="true" toc="default"> <section anchor="security-server" numbered="true" toc="default">
<name>Server Security Considerations</name> <name>Server Security Considerations</name>
<t>The threat specific to a DHCP server is an invalid client masquerading <t>The threat specific to a DHCP server is an invalid client masquerading
as a valid client. The motivation for this may be for theft of service, as a valid client. The motivation for this may be for theft of service
or to circumvent auditing for any number of nefarious purposes.</t> or to circumvent auditing for any number of nefarious purposes.</t>
<t>The messages exchanged between relay agents and servers may be used to <t>The messages exchanged between relay agents and servers may be used to
mount a man-in-the-middle or DoS attack. Communication mount a man-in-the-middle or DoS attack. Communication
between a server and a relay agent, and communication between relay between a server and a relay agent, and communication between relay
agents, can be authenticated and encrypted through the use of IPsec, as agents, can be authenticated and encrypted through the use of IPsec, as
described in <xref target="RFC8213" format="default"/>.</t> described in <xref target="RFC8213" format="default"/>.</t>
<t>However, the use of manually configured pre-shared keys for IPsec <t>However, the use of manually configured pre-shared keys for IPsec
between relay agents and servers does not defend against replayed DHCP between relay agents and servers does not defend against replayed DHCP
messages. Replayed messages can represent a DoS attack through messages. Replayed messages can represent a DoS attack through
exhaustion of processing resources but not through misconfiguration or exhaustion of processing resources but not through misconfiguration or
exhaustion of other resources such as assignable addresses and exhaustion of other resources such as assignable addresses and
delegatable prefixes.</t> delegatable prefixes.</t>
<t>If a server implementation supports the reconfigure mechanism, also see <t>If a server implementation supports the reconfigure mechanism, see
<xref target="security-rkap"/> below.</t> <xref target="security-rkap"/>.</t>
</section> </section>
<section anchor="security-rkap" numbered="true" toc="default"> <section anchor="security-rkap" numbered="true" toc="default">
<name>Reconfigure Security Considerations</name> <name>Reconfigure Security Considerations</name>
<t>RKAP, described in <xref target="reconfigure-protocol" format="default" />, <t>RKAP, described in <xref target="reconfigure-protocol" format="default" />,
provides protection against the provides protection against the
use of a Reconfigure message by a malicious DHCP server to mount a DoS use of a Reconfigure message by a malicious DHCP server to mount a DoS
or man-in-the-middle attack on a client. This protocol can be or man-in-the-middle attack on a client. This protocol can be
compromised by an attacker that can intercept the initial message in compromised by an attacker that can intercept the initial message in
which the DHCP server sends the key as plain text to the client.</t> which the DHCP server sends the key as plain text to the client.</t>
<t>Because of the opportunity for attack through the Reconfigure message, <t>Because of the opportunity for attack through the Reconfigure message,
a DHCP client MUST discard any Reconfigure message that does not include a DHCP client <bcp14>MUST</bcp14> discard any Reconfigure message that doe s not include
authentication or that does not pass the validation process for the authentication or that does not pass the validation process for the
authentication protocol.</t> authentication protocol.</t>
<t>A DHCP client may also be subject to attack through the receipt of a <t>A DHCP client may also be subject to attack through the receipt of a
Reconfigure message from a malicious server that causes the client to Reconfigure message from a malicious server that causes the client to
obtain incorrect configuration information from that server. Note that obtain incorrect configuration information from that server. Note that
although a client sends its response (Renew, Rebind, or although a client sends its response (Renew, Rebind, or
Information-request message) through a relay agent and, therefore, that Information-request message) through a relay agent and, therefore, that
response will only be received by servers to which DHCP messages are response will only be received by servers to which DHCP messages are
relayed, a malicious server could send a Reconfigure message to a client, relayed, a malicious server could send a Reconfigure message to a client,
skipping to change at line 5735 skipping to change at line 5583
of the mechanisms described in <xref target="RFC7610" format="default"/> of the mechanisms described in <xref target="RFC7610" format="default"/>
and <xref target="RFC7513" format="default"/>.</t> and <xref target="RFC7513" format="default"/>.</t>
</section> </section>
</section> </section>
<section anchor="privacy" numbered="true" toc="default"> <section anchor="privacy" numbered="true" toc="default">
<name>Privacy Considerations</name> <name>Privacy Considerations</name>
<t>For an extended discussion about privacy considerations for the <t>For an extended discussion about privacy considerations for the
client, see <xref target="RFC7824" format="default"/>:</t> client, see <xref target="RFC7824" format="default"/>:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>In particular, its Section 3 discusses various identifiers that <li>In particular, <xref target="RFC7824" section="3"
could be misused to track the client.</li> sectionFormat="of"/> discusses various identifiers that could be
<li>Its Section 4 discusses existing mechanisms that may have an misused to track the client.</li>
<li><xref target="RFC7824" section="4"
sectionFormat="of"/> discusses existing mechanisms that may have an
impact on a client's privacy.</li> impact on a client's privacy.</li>
<li>Finally, its Section 5 discusses potential attack vectors.</li> <li>Finally, <xref target="RFC7824" section="5"
sectionFormat="of"/> discusses potential attack vectors.</li>
</ul> </ul>
<t>For recommendations regarding how to address or mitigate those <t>For recommendations regarding how to address or mitigate those
issues, see <xref target="RFC7844" format="default"/>.</t> issues, see <xref target="RFC7844" format="default"/>.</t>
<t>This specification does not define any allocation strategies for server <t>This specification does not define any allocation strategies for
s. servers. Implementers are expected to develop their own algorithm for
Implementers are expected to develop their own algorithm for the server the server to choose a resource out of the available pool. Several
to choose a resource out of the available pool. Several possible possible allocation strategies are mentioned in <xref target="RFC7824"
allocation strategies are mentioned in Section 4.3 of <xref target="RFC782 section="4.3"/>. Please keep in mind that the list in <xref
4" format="default"/>. Please keep in mind that the list in target="RFC7824" format="default"/> is not exhaustive; there are
<xref target="RFC7824" format="default"/> is not exhaustive; there are cer certainly other possible strategies. Readers are also encouraged to read
tainly other <xref target="RFC7707" format="default"/> -- in particular,
possible strategies. Readers are also encouraged to read <xref target="RFC <xref target="RFC7707" section="4.1.2" sectionFormat="of "/>, which
7707" format="default"/> -- in particular, its Section 4.1.2, which
discusses the problems with certain allocation strategies.</t> discusses the problems with certain allocation strategies.</t>
</section> </section>
<section anchor="iana" numbered="true" toc="default"> <section anchor="iana" numbered="true" toc="default">
<name>IANA Considerations</name> <name>IANA Considerations</name>
<t>This document does not define any new DHCP name spaces or <t>This document does not define any new DHCP name spaces or
definitions.</t> definitions.</t>
<t>The publication of this document does not change the <t>The publication of this document does not change the
assignment rules for new values for message types, option codes, assignment rules for new values for message types, option codes,
DUID types, or status codes.</t> DUID types, or status codes.</t>
<t>The list of assigned values used in DHCPv6 is available at <t>The list of assigned values used in DHCPv6 is available at
&lt;https://www.iana.org/assignments/dhcpv6-parameters&gt;.</t> <eref brackets="angle" target="https://www.iana.org/assignments/dhcpv6-par
<t>IANA is requested ameters"/>.</t>
to update all references to <xref target="RFC8415" format="default"/> to t <t>IANA has updated all references to <xref target="RFC8415" format="defau
his lt"/> to this
document at document at
<https://www.iana.org/assignments/dhcpv6-parameters&gt;.</t> <eref brackets="angle" target="https://www.iana.org/assignments/dhcpv6-par ameters"/&gt;.</t>
<t> <t>
IANA is requested to add a new column "Status" to all IANA has added a new column "Status" to all
registries on the DHCPv6 parameters page at registries on the DHCPv6 parameters page at
&lt;https://www.iana.org/assignments/dhcpv6-parameters&gt; <eref brackets="angle" target="https://www.iana.org/assignments/dhcpv6-p
and leave each entry blank except as indicated below: arameters"/>
and has left each entry blank except as indicated below:
</t> </t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
In the Option Code registry, set the "Status" column value In the "Option Codes" registry, the "Status" column value has been set
to "Obsolete" for the IA_TA (option code 4) and UNICAST to "Obsolete" for the IA_TA (option code 4) and UNICAST
(option code 12) rows. (option code 12) rows.
</li> </li>
<li> <li>
In the Status Codes registry, set the "Status" column value In the "Status Codes" registry, the "Status" column value has been set
to "Obsolete" for the UseMulticast (status code 5) row. to "Obsolete" for the UseMulticast (status code 5) row.
</li> </li>
</ul> </ul>
<t>IANA is requested to update other references to <xref target="RFC8415" format="default"/> <t>IANA has updated other references to <xref target="RFC8415" format="def ault"/>
with references to this document at: with references to this document at:
</t> </t>
<ul spacing="normal"> <ul spacing="normal">
<li>https://www.iana.org/assignments/auth-namespaces (four entries)</li> <li><eref brackets="angle" target="https://www.iana.org/assignments/auth
<li>https://www.iana.org/assignments/bootp-dhcp-parameters (two entries) -namespaces"/> (four entries)</li>
</li> <li><eref brackets="angle" target="https://www.iana.org/assignments/boot
<li>https://www.iana.org/assignments/ipv6-multicast-addresses (two entri p-dhcp-parameters"/> (two entries)</li>
es)</li> <li><eref brackets="angle" target="https://www.iana.org/assignments/ipv6
<li>https://www.iana.org/assignments/service-names-port-numbers (two ent -multicast-addresses"/> (two entries)</li>
ries; UDP ports 546 and 547)</li> <li><eref brackets="angle" target="https://www.iana.org/assignments/serv
ice-names-port-numbers"/> (two entries; UDP ports 546 and 547)</li>
</ul> </ul>
</section> </section>
</middle> </middle>
<back> <back>
<references> <references>
<name>References</name> <name>References</name>
<references> <references>
<name>Normative References</name> <name>Normative References</name>
<reference anchor="RFC0768" target="https://www.rfc-editor.org/info/rfc7 <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.0
68" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.0768.xml"> 768.xml"/>
<front> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1
<title>User Datagram Protocol</title> 035.xml"/>
<author fullname="J. Postel" initials="J." surname="Postel"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
<date month="August" year="1980"/> 119.xml"/>
</front> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
<seriesInfo name="STD" value="6"/> 291.xml"/>
<seriesInfo name="RFC" value="768"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
<seriesInfo name="DOI" value="10.17487/RFC0768"/> 861.xml"/>
</reference> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
<reference anchor="RFC1035" target="https://www.rfc-editor.org/info/rfc1 862.xml"/>
035" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1035.xml"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
<front> 221.xml"/>
<title>Domain names - implementation and specification</title> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
<author fullname="P. Mockapetris" initials="P." surname="Mockapetris 355.xml"/>
"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
<date month="November" year="1987"/> 227.xml"/>
<abstract> <xi:include href="https://bib.ietf.org/public/rfc/bibxml9/reference.BCP.
<t>This RFC is the revised specification of the protocol and forma 0145.xml"/>
t used in the implementation of the Domain Name System. It obsoletes RFC-883. <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.81
This memo documents the details of the domain name client - server communication 74.xml"/>
.</t> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
</abstract> 200.xml"/>
</front> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
<seriesInfo name="STD" value="13"/> 213.xml"/>
<seriesInfo name="RFC" value="1035"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
<seriesInfo name="DOI" value="10.17487/RFC1035"/> 934.xml"/>
</reference>
<reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2
119" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</tit
le>
<author fullname="S. Bradner" initials="S." surname="Bradner"/>
<date month="March" year="1997"/>
<abstract>
<t>In many standards track documents several words are used to sig
nify the requirements in the specification. These words are often capitalized.
This document defines these words as they should be interpreted in IETF documen
ts. This document specifies an Internet Best Current Practices for the Internet
Community, and requests discussion and suggestions for improvements.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="2119"/>
<seriesInfo name="DOI" value="10.17487/RFC2119"/>
</reference>
<reference anchor="RFC4291" target="https://www.rfc-editor.org/info/rfc4
291" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4291.xml">
<front>
<title>IP Version 6 Addressing Architecture</title>
<author fullname="R. Hinden" initials="R." surname="Hinden"/>
<author fullname="S. Deering" initials="S." surname="Deering"/>
<date month="February" year="2006"/>
<abstract>
<t>This specification defines the addressing architecture of the I
P Version 6 (IPv6) protocol. The document includes the IPv6 addressing model, te
xt representations of IPv6 addresses, definition of IPv6 unicast addresses, anyc
ast addresses, and multicast addresses, and an IPv6 node's required addresses.</
t>
<t>This document obsoletes RFC 3513, "IP Version 6 Addressing Arch
itecture". [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4291"/>
<seriesInfo name="DOI" value="10.17487/RFC4291"/>
</reference>
<reference anchor="RFC4861" target="https://www.rfc-editor.org/info/rfc4
861" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4861.xml">
<front>
<title>Neighbor Discovery for IP version 6 (IPv6)</title>
<author fullname="T. Narten" initials="T." surname="Narten"/>
<author fullname="E. Nordmark" initials="E." surname="Nordmark"/>
<author fullname="W. Simpson" initials="W." surname="Simpson"/>
<author fullname="H. Soliman" initials="H." surname="Soliman"/>
<date month="September" year="2007"/>
<abstract>
<t>This document specifies the Neighbor Discovery protocol for IP
Version 6. IPv6 nodes on the same link use Neighbor Discovery to discover each
other's presence, to determine each other's link-layer addresses, to find router
s, and to maintain reachability information about the paths to active neighbors.
[STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4861"/>
<seriesInfo name="DOI" value="10.17487/RFC4861"/>
</reference>
<reference anchor="RFC4862" target="https://www.rfc-editor.org/info/rfc4
862" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4862.xml">
<front>
<title>IPv6 Stateless Address Autoconfiguration</title>
<author fullname="S. Thomson" initials="S." surname="Thomson"/>
<author fullname="T. Narten" initials="T." surname="Narten"/>
<author fullname="T. Jinmei" initials="T." surname="Jinmei"/>
<date month="September" year="2007"/>
<abstract>
<t>This document specifies the steps a host takes in deciding how
to autoconfigure its interfaces in IP version 6. The autoconfiguration process
includes generating a link-local address, generating global addresses via statel
ess address autoconfiguration, and the Duplicate Address Detection procedure to
verify the uniqueness of the addresses on a link. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4862"/>
<seriesInfo name="DOI" value="10.17487/RFC4862"/>
</reference>
<reference anchor="RFC6221" target="https://www.rfc-editor.org/info/rfc6
221" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6221.xml">
<front>
<title>Lightweight DHCPv6 Relay Agent</title>
<author fullname="D. Miles" initials="D." role="editor" surname="Mil
es"/>
<author fullname="S. Ooghe" initials="S." surname="Ooghe"/>
<author fullname="W. Dec" initials="W." surname="Dec"/>
<author fullname="S. Krishnan" initials="S." surname="Krishnan"/>
<author fullname="A. Kavanagh" initials="A." surname="Kavanagh"/>
<date month="May" year="2011"/>
<abstract>
<t>This document proposes a Lightweight DHCPv6 Relay Agent (LDRA)
that is used to insert relay agent options in DHCPv6 message exchanges identifyi
ng client-facing interfaces. The LDRA can be implemented in existing access nod
es (such as Digital Subscriber Link Access Multiplexers (DSLAMs) and Ethernet sw
itches) that do not support IPv6 control or routing functions. [STANDARDS-TRACK]
</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6221"/>
<seriesInfo name="DOI" value="10.17487/RFC6221"/>
</reference>
<reference anchor="RFC6355" target="https://www.rfc-editor.org/info/rfc6
355" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6355.xml">
<front>
<title>Definition of the UUID-Based DHCPv6 Unique Identifier (DUID-U
UID)</title>
<author fullname="T. Narten" initials="T." surname="Narten"/>
<author fullname="J. Johnson" initials="J." surname="Johnson"/>
<date month="August" year="2011"/>
<abstract>
<t>This document defines a new DHCPv6 Unique Identifier (DUID) typ
e called DUID-UUID. DUID-UUIDs are derived from the already-standardized Univer
sally Unique IDentifier (UUID) format. DUID-UUID makes it possible for devices
to use UUIDs to identify themselves to DHC servers and vice versa. UUIDs are gl
obally unique and readily available on many systems, making them convenient iden
tifiers to leverage within DHCP. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6355"/>
<seriesInfo name="DOI" value="10.17487/RFC6355"/>
</reference>
<reference anchor="RFC7227" target="https://www.rfc-editor.org/info/rfc7
227" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7227.xml">
<front>
<title>Guidelines for Creating New DHCPv6 Options</title>
<author fullname="D. Hankins" initials="D." surname="Hankins"/>
<author fullname="T. Mrugalski" initials="T." surname="Mrugalski"/>
<author fullname="M. Siodelski" initials="M." surname="Siodelski"/>
<author fullname="S. Jiang" initials="S." surname="Jiang"/>
<author fullname="S. Krishnan" initials="S." surname="Krishnan"/>
<date month="May" year="2014"/>
<abstract>
<t>This document provides guidance to prospective DHCPv6 option de
velopers to help them create option formats that are easily adoptable by existin
g DHCPv6 software. It also provides guidelines for expert reviewers to evaluate
new registrations. This document updates RFC 3315.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="187"/>
<seriesInfo name="RFC" value="7227"/>
<seriesInfo name="DOI" value="10.17487/RFC7227"/>
</reference>
<?rfc include="reference.BCP.145.xml" ?>
<reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8
174" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml">
<front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</ti
tle>
<author fullname="B. Leiba" initials="B." surname="Leiba"/>
<date month="May" year="2017"/>
<abstract>
<t>RFC 2119 specifies common key words that may be used in protoco
l specifications. This document aims to reduce the ambiguity by clarifying that
only UPPERCASE usage of the key words have the defined special meanings.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="8174"/>
<seriesInfo name="DOI" value="10.17487/RFC8174"/>
</reference>
<reference anchor="RFC8200" target="https://www.rfc-editor.org/info/rfc8
200" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8200.xml">
<front>
<title>Internet Protocol, Version 6 (IPv6) Specification</title>
<author fullname="S. Deering" initials="S." surname="Deering"/>
<author fullname="R. Hinden" initials="R." surname="Hinden"/>
<date month="July" year="2017"/>
<abstract>
<t>This document specifies version 6 of the Internet Protocol (IPv
6). It obsoletes RFC 2460.</t>
</abstract>
</front>
<seriesInfo name="STD" value="86"/>
<seriesInfo name="RFC" value="8200"/>
<seriesInfo name="DOI" value="10.17487/RFC8200"/>
</reference>
<reference anchor="RFC8213" target="https://www.rfc-editor.org/info/rfc8
213" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8213.xml">
<front>
<title>Security of Messages Exchanged between Servers and Relay Agen
ts</title>
<author fullname="B. Volz" initials="B." surname="Volz"/>
<author fullname="Y. Pal" initials="Y." surname="Pal"/>
<date month="August" year="2017"/>
<abstract>
<t>The Dynamic Host Configuration Protocol for IPv4 (DHCPv4) has n
o guidance for how to secure messages exchanged between servers and relay agents
. The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) states that IPsec s
hould be used to secure messages exchanged between servers and relay agents but
does not require encryption. With recent concerns about pervasive monitoring an
d other attacks, it is appropriate to require securing relay-to-relay and relay-
to-server communication for DHCPv6 and relay-to-server communication for DHCPv4.
</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8213"/>
<seriesInfo name="DOI" value="10.17487/RFC8213"/>
</reference>
<?rfc include="reference.RFC.7934.xml" ?>
</references> </references>
<references> <references>
<name>Informative References</name> <name>Informative References</name>
<?rfc include="reference.RFC.8415.xml" ?> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
<reference anchor="IANA-PEN" target="https://www.iana.org/assignments/en 415.xml"/>
terprise-numbers"> <reference anchor="IANA-PEN" target="https://www.iana.org/assignments/ent
erprise-numbers">
<front> <front>
<title>Private Enterprise Numbers</title> <title>Private Enterprise Numbers</title>
<author> <author>
<organization>IANA</organization> <organization>IANA</organization>
</author> </author>
<date/> <date/>
</front> </front>
</reference> </reference>
<?rfc include="reference.RFC.5612.xml" ?> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
<reference anchor="IANA-RESERVED-IID" target="https://www.iana.org/assig 612.xml"/>
nments/ipv6-interface-ids"> <reference anchor="IANA-RESERVED-IID" target="https://www.iana.org/assign
ments/ipv6-interface-ids">
<front> <front>
<title>Reserved IPv6 Interface Identifiers</title> <title>Reserved IPv6 Interface Identifiers</title>
<author> <author>
<organization>IANA</organization> <organization>IANA</organization>
</author> </author>
<date/> <date/>
</front> </front>
</reference> </reference>
<reference anchor="IANA-HARDWARE-TYPES" target="https://www.iana.org/ass ignments/arp-parameters"> <reference anchor="IANA-HARDWARE-TYPES" target="https://www.iana.org/ass ignments/arp-parameters">
<front> <front>
skipping to change at line 6006 skipping to change at line 5706
</reference> </reference>
<reference anchor="IANA-OPTION-DETAILS" target="https://www.iana.org/ass ignments/dhcpv6-parameters"> <reference anchor="IANA-OPTION-DETAILS" target="https://www.iana.org/ass ignments/dhcpv6-parameters">
<front> <front>
<title>Option Codes</title> <title>Option Codes</title>
<author> <author>
<organization>IANA</organization> <organization>IANA</organization>
</author> </author>
<date/> <date/>
</front> </front>
</reference> </reference>
<?rfc include="reference.RFC.2131.xml" ?> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
<reference anchor="RFC2464" target="https://www.rfc-editor.org/info/rfc2 131.xml"/>
464" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2464.xml"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.24
<front> 64.xml"/>
<title>Transmission of IPv6 Packets over Ethernet Networks</title> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
<author fullname="M. Crawford" initials="M." surname="Crawford"/> 162.xml"/>
<date month="December" year="1998"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
<abstract> 290.xml"/>
<t>This document specifies the frame format for transmission of IP <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
v6 packets and the method of forming IPv6 link-local addresses and statelessly a 629.xml"/>
utoconfigured addresses on Ethernet networks. It also specifies the content of <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
the Source/Target Link-layer Address option used in Router Solicitation, Router 646.xml"/>
Advertisement, Neighbor Solicitation, Neighbor Advertisement and Redirect messag <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
es when those messages are transmitted on an Ethernet. [STANDARDS-TRACK]</t> 769.xml"/>
</abstract> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.59
</front> 08.xml"/>
<seriesInfo name="RFC" value="2464"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
<seriesInfo name="DOI" value="10.17487/RFC2464"/> 193.xml"/>
</reference> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
<reference anchor="RFC3162" target="https://www.rfc-editor.org/info/rfc3 477.xml"/>
162" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3162.xml"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
<front> 704.xml"/>
<title>RADIUS and IPv6</title> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
<author fullname="B. Aboba" initials="B." surname="Aboba"/> 943.xml"/>
<author fullname="G. Zorn" initials="G." surname="Zorn"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
<author fullname="D. Mitton" initials="D." surname="Mitton"/> 957.xml"/>
<date month="August" year="2001"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.49
<abstract> 94.xml"/>
<t>This document specifies the operation of RADIUS (Remote Authent <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
ication Dial In User Service) when run over IPv6 as well as the RADIUS attribute 007.xml"/>
s used to support IPv6 network access. [STANDARDS-TRACK]</t> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
</abstract> 453.xml"/>
</front> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
<seriesInfo name="RFC" value="3162"/> 905.xml"/>
<seriesInfo name="DOI" value="10.17487/RFC3162"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
</reference> 059.xml"/>
<reference anchor="RFC3290" target="https://www.rfc-editor.org/info/rfc3 <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.64
290" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3290.xml"> 22.xml"/>
<front> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
<title>An Informal Management Model for Diffserv Routers</title> 603.xml"/>
<author fullname="Y. Bernet" initials="Y." surname="Bernet"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
<author fullname="S. Blake" initials="S." surname="Blake"/> 879.xml"/>
<author fullname="D. Grossman" initials="D." surname="Grossman"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
<author fullname="A. Smith" initials="A." surname="Smith"/> 939.xml"/>
<date month="May" year="2002"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
<abstract> 084.xml"/>
<t>This document proposes an informal management model of Differen <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
tiated Services (Diffserv) routers for use in their management and configuration 136.xml"/>
. This model defines functional datapath elements (e.g., classifiers, meters, a <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
ctions, marking, absolute dropping, counting, multiplexing), algorithmic dropper 341.xml"/>
s, queues and schedulers. It describes possible configuration parameters for th <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
ese elements and how they might be interconnected to realize the range of traffi 368.xml"/>
c conditioning and per-hop behavior (PHB) functionalities described in the Diffs <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
erv Architecture. This memo provides information for the Internet community.</t 513.xml"/>
> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
</abstract> 598.xml"/>
</front> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
<seriesInfo name="RFC" value="3290"/> 610.xml"/>
<seriesInfo name="DOI" value="10.17487/RFC3290"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
</reference> 707.xml"/>
<reference anchor="RFC3629" target="https://www.rfc-editor.org/info/rfc3 <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
629" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3629.xml"> 721.xml"/>
<front> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
<title>UTF-8, a transformation format of ISO 10646</title> 824.xml"/>
<author fullname="F. Yergeau" initials="F." surname="Yergeau"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
<date month="November" year="2003"/> 844.xml"/>
<abstract> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
<t>ISO/IEC 10646-1 defines a large character set called the Univer 943.xml"/>
sal Character Set (UCS) which encompasses most of the world's writing systems. <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
The originally proposed encodings of the UCS, however, were not compatible with 969.xml"/>
many current applications and protocols, and this has led to the development of <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
UTF-8, the object of this memo. UTF-8 has the characteristic of preserving the 168.xml"/>
full US-ASCII range, providing compatibility with file systems, parsers and othe <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
r software that rely on US-ASCII values but are transparent to other values. Th 357.xml"/>
is memo obsoletes and replaces RFC 2279.</t> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.89
</abstract> 47.xml"/>
</front> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.89
<seriesInfo name="STD" value="63"/> 81.xml"/>
<seriesInfo name="RFC" value="3629"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
<seriesInfo name="DOI" value="10.17487/RFC3629"/> 987.xml"/>
</reference> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.90
<reference anchor="RFC3646" target="https://www.rfc-editor.org/info/rfc3 96.xml"/>
646" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3646.xml"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.92
<front> 43.xml"/>
<title>DNS Configuration options for Dynamic Host Configuration Prot <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.96
ocol for IPv6 (DHCPv6)</title> 86.xml"/>
<author fullname="R. Droms" initials="R." role="editor" surname="Dro <reference anchor="TR-187" target="https://www.broadband-forum.org/pdfs/t
ms"/> r-187-2-0-0.pdf">
<date month="December" year="2003"/>
<abstract>
<t>This document describes Dynamic Host Configuration Protocol for
IPv6 (DHCPv6) options for passing a list of available DNS recursive name server
s and a domain search list to a client.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="3646"/>
<seriesInfo name="DOI" value="10.17487/RFC3646"/>
</reference>
<?rfc include="reference.RFC.3769.xml" ?>
<reference anchor="RFC5908" target="https://www.rfc-editor.org/info/rfc5
908" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5908.xml">
<front>
<title>Network Time Protocol (NTP) Server Option for DHCPv6</title>
<author fullname="R. Gayraud" initials="R." surname="Gayraud"/>
<author fullname="B. Lourdelet" initials="B." surname="Lourdelet"/>
<date month="June" year="2010"/>
<abstract>
<t>The NTP Server Option for Dynamic Host Configuration Protocol f
or IPv6 (DHCPv6) provides NTPv4 (Network Time Protocol version 4) server locatio
n information to DHCPv6 hosts. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5908"/>
<seriesInfo name="DOI" value="10.17487/RFC5908"/>
</reference>
<reference anchor="RFC4193" target="https://www.rfc-editor.org/info/rfc4
193" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4193.xml">
<front>
<title>Unique Local IPv6 Unicast Addresses</title>
<author fullname="R. Hinden" initials="R." surname="Hinden"/>
<author fullname="B. Haberman" initials="B." surname="Haberman"/>
<date month="October" year="2005"/>
<abstract>
<t>This document defines an IPv6 unicast address format that is gl
obally unique and is intended for local communications, usually inside of a site
. These addresses are not expected to be routable on the global Internet. [STAN
DARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4193"/>
<seriesInfo name="DOI" value="10.17487/RFC4193"/>
</reference>
<reference anchor="RFC4477" target="https://www.rfc-editor.org/info/rfc4
477" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4477.xml">
<front>
<title>Dynamic Host Configuration Protocol (DHCP): IPv4 and IPv6 Dua
l-Stack Issues</title>
<author fullname="T. Chown" initials="T." surname="Chown"/>
<author fullname="S. Venaas" initials="S." surname="Venaas"/>
<author fullname="C. Strauf" initials="C." surname="Strauf"/>
<date month="May" year="2006"/>
<abstract>
<t>A node may have support for communications using IPv4 and/or IP
v6 protocols. Such a node may wish to obtain IPv4 and/or IPv6 configuration set
tings via the Dynamic Host Configuration Protocol (DHCP). The original version
of DHCP (RFC 2131) designed for IPv4 has now been complemented by a new DHCPv6 (
RFC 3315) for IPv6. This document describes issues identified with dual IP vers
ion DHCP interactions, the most important aspect of which is how to handle poten
tial problems in clients processing configuration information received from both
DHCPv4 and DHCPv6 servers. The document makes a recommendation on the general
strategy on how best to handle such issues and identifies future work to be unde
rtaken. This memo provides information for the Internet community.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4477"/>
<seriesInfo name="DOI" value="10.17487/RFC4477"/>
</reference>
<reference anchor="RFC4704" target="https://www.rfc-editor.org/info/rfc4
704" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4704.xml">
<front>
<title>The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Cli
ent Fully Qualified Domain Name (FQDN) Option</title>
<author fullname="B. Volz" initials="B." surname="Volz"/>
<date month="October" year="2006"/>
<abstract>
<t>This document specifies a new Dynamic Host Configuration Protoc
ol for IPv6 (DHCPv6) option that can be used to exchange information about a DHC
Pv6 client's Fully Qualified Domain Name (FQDN) and about responsibility for upd
ating DNS resource records (RRs) related to the client's address assignments. [S
TANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4704"/>
<seriesInfo name="DOI" value="10.17487/RFC4704"/>
</reference>
<reference anchor="RFC4943" target="https://www.rfc-editor.org/info/rfc4
943" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4943.xml">
<front>
<title>IPv6 Neighbor Discovery On-Link Assumption Considered Harmful
</title>
<author fullname="S. Roy" initials="S." surname="Roy"/>
<author fullname="A. Durand" initials="A." surname="Durand"/>
<author fullname="J. Paugh" initials="J." surname="Paugh"/>
<date month="September" year="2007"/>
<abstract>
<t>This document describes the historical and background informati
on behind the removal of the "on-link assumption" from the conceptual host sendi
ng algorithm defined in Neighbor Discovery for IP Version 6 (IPv6). According t
o the algorithm as originally described, when a host's default router list is em
pty, the host assumes that all destinations are on-link. This is particularly p
roblematic with IPv6-capable nodes that do not have off-link IPv6 connectivity (
e.g., no default router). This document describes how making this assumption ca
uses problems and how these problems outweigh the benefits of this part of the c
onceptual sending algorithm. This memo provides information for the Internet co
mmunity.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4943"/>
<seriesInfo name="DOI" value="10.17487/RFC4943"/>
</reference>
<?rfc include="reference.RFC.4957.xml" ?>
<reference anchor="RFC4994" target="https://www.rfc-editor.org/info/rfc4
994" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4994.xml">
<front>
<title>DHCPv6 Relay Agent Echo Request Option</title>
<author fullname="S. Zeng" initials="S." surname="Zeng"/>
<author fullname="B. Volz" initials="B." surname="Volz"/>
<author fullname="K. Kinnear" initials="K." surname="Kinnear"/>
<author fullname="J. Brzozowski" initials="J." surname="Brzozowski"/
>
<date month="September" year="2007"/>
<abstract>
<t>This memo defines a Relay Agent Echo Request option for the Dyn
amic Host Configuration Protocol for IPv6 (DHCPv6). The option allows a DHCPv6
relay agent to request a list of relay agent options that the server echoes back
to the relay agent. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4994"/>
<seriesInfo name="DOI" value="10.17487/RFC4994"/>
</reference>
<reference anchor="RFC5007" target="https://www.rfc-editor.org/info/rfc5
007" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5007.xml">
<front>
<title>DHCPv6 Leasequery</title>
<author fullname="J. Brzozowski" initials="J." surname="Brzozowski"/
>
<author fullname="K. Kinnear" initials="K." surname="Kinnear"/>
<author fullname="B. Volz" initials="B." surname="Volz"/>
<author fullname="S. Zeng" initials="S." surname="Zeng"/>
<date month="September" year="2007"/>
<abstract>
<t>This document specifies a leasequery exchange for the Dynamic H
ost Configuration Protocol for IPv6 (DHCPv6) that can be used to obtain lease in
formation about DHCPv6 clients from a DHCPv6 server. This document specifies th
e scope of data that can be retrieved as well as both DHCPv6 leasequery requesto
r and server behavior. This document extends DHCPv6. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5007"/>
<seriesInfo name="DOI" value="10.17487/RFC5007"/>
</reference>
<reference anchor="RFC5453" target="https://www.rfc-editor.org/info/rfc5
453" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5453.xml">
<front>
<title>Reserved IPv6 Interface Identifiers</title>
<author fullname="S. Krishnan" initials="S." surname="Krishnan"/>
<date month="February" year="2009"/>
<abstract>
<t>Interface identifiers in IPv6 unicast addresses are used to ide
ntify interfaces on a link. They are required to be unique within a subnet. Se
veral RFCs have specified interface identifiers or identifier ranges that have a
special meaning attached to them. An IPv6 node autoconfiguring an interface id
entifier in these ranges will encounter unexpected consequences. Since there is
no centralized repository for such reserved identifiers, this document aims to
create one. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5453"/>
<seriesInfo name="DOI" value="10.17487/RFC5453"/>
</reference>
<reference anchor="RFC5905" target="https://www.rfc-editor.org/info/rfc5
905" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5905.xml">
<front>
<title>Network Time Protocol Version 4: Protocol and Algorithms Spec
ification</title>
<author fullname="D. Mills" initials="D." surname="Mills"/>
<author fullname="J. Martin" initials="J." role="editor" surname="Ma
rtin"/>
<author fullname="J. Burbank" initials="J." surname="Burbank"/>
<author fullname="W. Kasch" initials="W." surname="Kasch"/>
<date month="June" year="2010"/>
<abstract>
<t>The Network Time Protocol (NTP) is widely used to synchronize c
omputer clocks in the Internet. This document describes NTP version 4 (NTPv4),
which is backwards compatible with NTP version 3 (NTPv3), described in RFC 1305,
as well as previous versions of the protocol. NTPv4 includes a modified protoc
ol header to accommodate the Internet Protocol version 6 address family. NTPv4
includes fundamental improvements in the mitigation and discipline algorithms th
at extend the potential accuracy to the tens of microseconds with modern worksta
tions and fast LANs. It includes a dynamic server discovery scheme, so that in
many cases, specific server configuration is not required. It corrects certain
errors in the NTPv3 design and implementation and includes an optional extension
mechanism. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5905"/>
<seriesInfo name="DOI" value="10.17487/RFC5905"/>
</reference>
<?rfc include="reference.RFC.6059.xml" ?>
<reference anchor="RFC6422" target="https://www.rfc-editor.org/info/rfc6
422" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6422.xml">
<front>
<title>Relay-Supplied DHCP Options</title>
<author fullname="T. Lemon" initials="T." surname="Lemon"/>
<author fullname="Q. Wu" initials="Q." surname="Wu"/>
<date month="December" year="2011"/>
<abstract>
<t>DHCPv6 relay agents cannot communicate with DHCPv6 clients dire
ctly. However, in some cases, the relay agent possesses some information that wo
uld be useful to the DHCPv6 client. This document describes a mechanism whereby
the DHCPv6 relay agent can provide such information to the DHCPv6 server, which
can, in turn, pass this information on to the DHCP client.</t>
<t>This document updates RFC 3315 (DHCPv6) by making explicit the
implicit requirement that relay agents not modify the content of encapsulation p
ayloads as they are relayed back toward clients. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6422"/>
<seriesInfo name="DOI" value="10.17487/RFC6422"/>
</reference>
<reference anchor="RFC6603" target="https://www.rfc-editor.org/info/rfc6
603" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6603.xml">
<front>
<title>Prefix Exclude Option for DHCPv6-based Prefix Delegation</tit
le>
<author fullname="J. Korhonen" initials="J." role="editor" surname="
Korhonen"/>
<author fullname="T. Savolainen" initials="T." surname="Savolainen"/
>
<author fullname="S. Krishnan" initials="S." surname="Krishnan"/>
<author fullname="O. Troan" initials="O." surname="Troan"/>
<date month="May" year="2012"/>
<abstract>
<t>This specification defines an optional mechanism to allow exclu
sion of one specific prefix from a delegated prefix set when using DHCPv6-based
prefix delegation. The new mechanism updates RFC 3633. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6603"/>
<seriesInfo name="DOI" value="10.17487/RFC6603"/>
</reference>
<reference anchor="RFC6879" target="https://www.rfc-editor.org/info/rfc6
879" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6879.xml">
<front>
<title>IPv6 Enterprise Network Renumbering Scenarios, Considerations
, and Methods</title>
<author fullname="S. Jiang" initials="S." surname="Jiang"/>
<author fullname="B. Liu" initials="B." surname="Liu"/>
<author fullname="B. Carpenter" initials="B." surname="Carpenter"/>
<date month="February" year="2013"/>
<abstract>
<t>This document analyzes events that cause renumbering and descri
bes the current renumbering methods. These are described in three categories: t
hose applicable during network design, those applicable during preparation for r
enumbering, and those applicable during the renumbering operation.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6879"/>
<seriesInfo name="DOI" value="10.17487/RFC6879"/>
</reference>
<reference anchor="RFC6939" target="https://www.rfc-editor.org/info/rfc6
939" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6939.xml">
<front>
<title>Client Link-Layer Address Option in DHCPv6</title>
<author fullname="G. Halwasia" initials="G." surname="Halwasia"/>
<author fullname="S. Bhandari" initials="S." surname="Bhandari"/>
<author fullname="W. Dec" initials="W." surname="Dec"/>
<date month="May" year="2013"/>
<abstract>
<t>This document specifies the format and mechanism that is to be
used for encoding the client link-layer address in DHCPv6 Relay-Forward messages
by defining a new DHCPv6 Client Link-Layer Address option.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6939"/>
<seriesInfo name="DOI" value="10.17487/RFC6939"/>
</reference>
<reference anchor="RFC7084" target="https://www.rfc-editor.org/info/rfc7
084" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7084.xml">
<front>
<title>Basic Requirements for IPv6 Customer Edge Routers</title>
<author fullname="H. Singh" initials="H." surname="Singh"/>
<author fullname="W. Beebee" initials="W." surname="Beebee"/>
<author fullname="C. Donley" initials="C." surname="Donley"/>
<author fullname="B. Stark" initials="B." surname="Stark"/>
<date month="November" year="2013"/>
<abstract>
<t>This document specifies requirements for an IPv6 Customer Edge
(CE) router. Specifically, the current version of this document focuses on the
basic provisioning of an IPv6 CE router and the provisioning of IPv6 hosts attac
hed to it. The document also covers IP transition technologies. Two transition
technologies in RFC 5969's IPv6 Rapid Deployment on IPv4 Infrastructures (6rd)
and RFC 6333's Dual-Stack Lite (DS-Lite) are covered in the document. The docum
ent obsoletes RFC 6204.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7084"/>
<seriesInfo name="DOI" value="10.17487/RFC7084"/>
</reference>
<reference anchor="RFC7136" target="https://www.rfc-editor.org/info/rfc7
136" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7136.xml">
<front>
<title>Significance of IPv6 Interface Identifiers</title>
<author fullname="B. Carpenter" initials="B." surname="Carpenter"/>
<author fullname="S. Jiang" initials="S." surname="Jiang"/>
<date month="February" year="2014"/>
<abstract>
<t>The IPv6 addressing architecture includes a unicast interface i
dentifier that is used in the creation of many IPv6 addresses. Interface identi
fiers are formed by a variety of methods. This document clarifies that the bits
in an interface identifier have no meaning and that the entire identifier shoul
d be treated as an opaque value. In particular, RFC 4291 defines a method by wh
ich the Universal and Group bits of an IEEE link-layer address are mapped into a
n IPv6 unicast interface identifier. This document clarifies that those two bit
s are significant only in the process of deriving interface identifiers from an
IEEE link-layer address, and it updates RFC 4291 accordingly.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7136"/>
<seriesInfo name="DOI" value="10.17487/RFC7136"/>
</reference>
<reference anchor="RFC7341" target="https://www.rfc-editor.org/info/rfc7
341" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7341.xml">
<front>
<title>DHCPv4-over-DHCPv6 (DHCP 4o6) Transport</title>
<author fullname="Q. Sun" initials="Q." surname="Sun"/>
<author fullname="Y. Cui" initials="Y." surname="Cui"/>
<author fullname="M. Siodelski" initials="M." surname="Siodelski"/>
<author fullname="S. Krishnan" initials="S." surname="Krishnan"/>
<author fullname="I. Farrer" initials="I." surname="Farrer"/>
<date month="August" year="2014"/>
<abstract>
<t>IPv4 connectivity is still needed as networks migrate towards I
Pv6. Users require IPv4 configuration even if the uplink to their service provi
der supports IPv6 only. This document describes a mechanism for obtaining IPv4
configuration information dynamically in IPv6 networks by carrying DHCPv4 messag
es over DHCPv6 transport. Two new DHCPv6 messages and two new DHCPv6 options ar
e defined for this purpose.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7341"/>
<seriesInfo name="DOI" value="10.17487/RFC7341"/>
</reference>
<reference anchor="RFC7368" target="https://www.rfc-editor.org/info/rfc7
368" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7368.xml">
<front>
<title>IPv6 Home Networking Architecture Principles</title>
<author fullname="T. Chown" initials="T." role="editor" surname="Cho
wn"/>
<author fullname="J. Arkko" initials="J." surname="Arkko"/>
<author fullname="A. Brandt" initials="A." surname="Brandt"/>
<author fullname="O. Troan" initials="O." surname="Troan"/>
<author fullname="J. Weil" initials="J." surname="Weil"/>
<date month="October" year="2014"/>
<abstract>
<t>This text describes evolving networking technology within resid
ential home networks with increasing numbers of devices and a trend towards incr
eased internal routing. The goal of this document is to define a general archit
ecture for IPv6-based home networking, describing the associated principles, con
siderations, and requirements. The text briefly highlights specific implication
s of the introduction of IPv6 for home networking, discusses the elements of the
architecture, and suggests how standard IPv6 mechanisms and addressing can be e
mployed in home networking. The architecture describes the need for specific pr
otocol extensions for certain additional functionality. It is assumed that the
IPv6 home network is not actively managed and runs as an IPv6-only or dual-stack
network. There are no recommendations in this text for the IPv4 part of the ne
twork.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7368"/>
<seriesInfo name="DOI" value="10.17487/RFC7368"/>
</reference>
<reference anchor="RFC7513" target="https://www.rfc-editor.org/info/rfc7
513" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7513.xml">
<front>
<title>Source Address Validation Improvement (SAVI) Solution for DHC
P</title>
<author fullname="J. Bi" initials="J." surname="Bi"/>
<author fullname="J. Wu" initials="J." surname="Wu"/>
<author fullname="G. Yao" initials="G." surname="Yao"/>
<author fullname="F. Baker" initials="F." surname="Baker"/>
<date month="May" year="2015"/>
<abstract>
<t>This document specifies the procedure for creating a binding be
tween a DHCPv4/DHCPv6-assigned IP address and a binding anchor on a Source Addre
ss Validation Improvement (SAVI) device. The bindings set up by this procedure
are used to filter packets with forged source IP addresses. This mechanism comp
lements BCP 38 (RFC 2827) ingress filtering, providing finer-grained source IP a
ddress validation.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7513"/>
<seriesInfo name="DOI" value="10.17487/RFC7513"/>
</reference>
<reference anchor="RFC7598" target="https://www.rfc-editor.org/info/rfc7
598" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7598.xml">
<front>
<title>DHCPv6 Options for Configuration of Softwire Address and Port
-Mapped Clients</title>
<author fullname="T. Mrugalski" initials="T." surname="Mrugalski"/>
<author fullname="O. Troan" initials="O." surname="Troan"/>
<author fullname="I. Farrer" initials="I." surname="Farrer"/>
<author fullname="S. Perreault" initials="S." surname="Perreault"/>
<author fullname="W. Dec" initials="W." surname="Dec"/>
<author fullname="C. Bao" initials="C." surname="Bao"/>
<author fullname="L. Yeh" initials="L." surname="Yeh"/>
<author fullname="X. Deng" initials="X." surname="Deng"/>
<date month="July" year="2015"/>
<abstract>
<t>This document specifies DHCPv6 options, termed Softwire46 optio
ns, for the provisioning of Softwire46 Customer Edge (CE) devices. Softwire46 i
s a collective term used to refer to architectures based on the notion of IPv4 A
ddress plus Port (A+P) for providing IPv4 connectivity across an IPv6 network.</
t>
</abstract>
</front>
<seriesInfo name="RFC" value="7598"/>
<seriesInfo name="DOI" value="10.17487/RFC7598"/>
</reference>
<reference anchor="RFC7610" target="https://www.rfc-editor.org/info/rfc7
610" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7610.xml">
<front>
<title>DHCPv6-Shield: Protecting against Rogue DHCPv6 Servers</title
>
<author fullname="F. Gont" initials="F." surname="Gont"/>
<author fullname="W. Liu" initials="W." surname="Liu"/>
<author fullname="G. Van de Velde" initials="G." surname="Van de Vel
de"/>
<date month="August" year="2015"/>
<abstract>
<t>This document specifies a mechanism for protecting hosts connec
ted to a switched network against rogue DHCPv6 servers. It is based on DHCPv6 p
acket filtering at the layer 2 device at which the packets are received. A simi
lar mechanism has been widely deployed in IPv4 networks ('DHCP snooping'); hence
, it is desirable that similar functionality be provided for IPv6 networks. Thi
s document specifies a Best Current Practice for the implementation of DHCPv6-Sh
ield.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="199"/>
<seriesInfo name="RFC" value="7610"/>
<seriesInfo name="DOI" value="10.17487/RFC7610"/>
</reference>
<reference anchor="RFC7707" target="https://www.rfc-editor.org/info/rfc7
707" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7707.xml">
<front>
<title>Network Reconnaissance in IPv6 Networks</title>
<author fullname="F. Gont" initials="F." surname="Gont"/>
<author fullname="T. Chown" initials="T." surname="Chown"/>
<date month="March" year="2016"/>
<abstract>
<t>IPv6 offers a much larger address space than that of its IPv4 c
ounterpart. An IPv6 subnet of size /64 can (in theory) accommodate approximatel
y 1.844 * 10^19 hosts, thus resulting in a much lower host density (#hosts/#addr
esses) than is typical in IPv4 networks, where a site typically has 65,000 or fe
wer unique addresses. As a result, it is widely assumed that it would take a tr
emendous effort to perform address-scanning attacks against IPv6 networks; there
fore, IPv6 address-scanning attacks have been considered unfeasible. This docum
ent formally obsoletes RFC 5157, which first discussed this assumption, by provi
ding further analysis on how traditional address-scanning techniques apply to IP
v6 networks and exploring some additional techniques that can be employed for IP
v6 network reconnaissance.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7707"/>
<seriesInfo name="DOI" value="10.17487/RFC7707"/>
</reference>
<reference anchor="RFC7721" target="https://www.rfc-editor.org/info/rfc7
721" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7721.xml">
<front>
<title>Security and Privacy Considerations for IPv6 Address Generati
on Mechanisms</title>
<author fullname="A. Cooper" initials="A." surname="Cooper"/>
<author fullname="F. Gont" initials="F." surname="Gont"/>
<author fullname="D. Thaler" initials="D." surname="Thaler"/>
<date month="March" year="2016"/>
<abstract>
<t>This document discusses privacy and security considerations for
several IPv6 address generation mechanisms, both standardized and non-standardi
zed. It evaluates how different mechanisms mitigate different threats and the t
rade-offs that implementors, developers, and users face in choosing different ad
dresses or address generation mechanisms.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7721"/>
<seriesInfo name="DOI" value="10.17487/RFC7721"/>
</reference>
<reference anchor="RFC7824" target="https://www.rfc-editor.org/info/rfc7
824" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7824.xml">
<front>
<title>Privacy Considerations for DHCPv6</title>
<author fullname="S. Krishnan" initials="S." surname="Krishnan"/>
<author fullname="T. Mrugalski" initials="T." surname="Mrugalski"/>
<author fullname="S. Jiang" initials="S." surname="Jiang"/>
<date month="May" year="2016"/>
<abstract>
<t>DHCPv6 is a protocol that is used to provide addressing and con
figuration information to IPv6 hosts. This document describes the privacy issue
s associated with the use of DHCPv6 by Internet users. It is intended to be an
analysis of the present situation and does not propose any solutions.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7824"/>
<seriesInfo name="DOI" value="10.17487/RFC7824"/>
</reference>
<reference anchor="RFC7844" target="https://www.rfc-editor.org/info/rfc7
844" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7844.xml">
<front>
<title>Anonymity Profiles for DHCP Clients</title>
<author fullname="C. Huitema" initials="C." surname="Huitema"/>
<author fullname="T. Mrugalski" initials="T." surname="Mrugalski"/>
<author fullname="S. Krishnan" initials="S." surname="Krishnan"/>
<date month="May" year="2016"/>
<abstract>
<t>Some DHCP options carry unique identifiers. These identifiers
can enable device tracking even if the device administrator takes care of random
izing other potential identifications like link-layer addresses or IPv6 addresse
s. The anonymity profiles are designed for clients that wish to remain anonymou
s to the visited network. The profiles provide guidelines on the composition of
DHCP or DHCPv6 messages, designed to minimize disclosure of identifying informa
tion.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7844"/>
<seriesInfo name="DOI" value="10.17487/RFC7844"/>
</reference>
<reference anchor="RFC7943" target="https://www.rfc-editor.org/info/rfc7
943" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7943.xml">
<front>
<title>A Method for Generating Semantically Opaque Interface Identif
iers (IIDs) with the Dynamic Host Configuration Protocol for IPv6 (DHCPv6)</titl
e>
<author fullname="F. Gont" initials="F." surname="Gont"/>
<author fullname="W. Liu" initials="W." surname="Liu"/>
<date month="September" year="2016"/>
<abstract>
<t>This document describes a method for selecting IPv6 Interface I
dentifiers that can be employed by Dynamic Host Configuration Protocol for IPv6
(DHCPv6) servers when leasing non-temporary IPv6 addresses to DHCPv6 clients. T
his method is a DHCPv6 server-side algorithm that does not require any updates t
o the existing DHCPv6 specifications. The aforementioned method results in stab
le addresses within each subnet, even in the presence of multiple DHCPv6 servers
or DHCPv6 server reinstallments. It is a DHCPv6 variant of the method specifie
d in RFC 7217 for IPv6 Stateless Address Autoconfiguration.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7943"/>
<seriesInfo name="DOI" value="10.17487/RFC7943"/>
</reference>
<reference anchor="RFC7969" target="https://www.rfc-editor.org/info/rfc7
969" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7969.xml">
<front>
<title>Customizing DHCP Configuration on the Basis of Network Topolo
gy</title>
<author fullname="T. Lemon" initials="T." surname="Lemon"/>
<author fullname="T. Mrugalski" initials="T." surname="Mrugalski"/>
<date month="October" year="2016"/>
<abstract>
<t>DHCP servers have evolved over the years to provide significant
functionality beyond that described in the DHCP base specifications. One aspec
t of this functionality is support for context-specific configuration informatio
n. This memo describes some such features and explains their operation.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7969"/>
<seriesInfo name="DOI" value="10.17487/RFC7969"/>
</reference>
<reference anchor="RFC8168" target="https://www.rfc-editor.org/info/rfc8
168" xml:base="https://www.rfc-editor.org/refs/bibxml/reference.RFC.8168.xml">
<front>
<title>DHCPv6 Prefix-Length Hint Issues</title>
<author initials="T." surname="Li" fullname="T. Li">
<organization/>
</author>
<author initials="C." surname="Liu" fullname="C. Liu">
<organization/>
</author>
<author initials="Y." surname="Cui" fullname="Y. Cui">
<organization/>
</author>
<date year="2017" month="May"/>
<abstract>
<t>DHCPv6 Prefix Delegation allows a client to include a prefix-le
ngth hint value in the IA_PD option to indicate a preference for the size of the
prefix to be delegated, but it is unclear about how the client and server shoul
d act in different situations involving the prefix-length hint. This document p
rovides a summary of the existing problems with the prefix-length hint and guida
nce on what the client and server could do in different situations.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8168"/>
<seriesInfo name="DOI" value="10.17487/RFC8168"/>
</reference>
<?rfc include="reference.RFC.8357.xml" ?>
<?rfc include="reference.RFC.8947.xml" ?>
<reference anchor="RFC8981" target="https://www.rfc-editor.org/info/rfc8
981" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8981.xml">
<front>
<title>Temporary Address Extensions for Stateless Address Autoconfig
uration in IPv6</title>
<author fullname="F. Gont" initials="F." surname="Gont"/>
<author fullname="S. Krishnan" initials="S." surname="Krishnan"/>
<author fullname="T. Narten" initials="T." surname="Narten"/>
<author fullname="R. Draves" initials="R." surname="Draves"/>
<date month="February" year="2021"/>
<abstract>
<t>This document describes an extension to IPv6 Stateless Address
Autoconfiguration that causes hosts to generate temporary addresses with randomi
zed interface identifiers for each prefix advertised with autoconfiguration enab
led. Changing addresses over time limits the window of time during which eavesd
roppers and other information collectors may trivially perform address-based net
work-activity correlation when the same address is employed for multiple transac
tions by the same host. Additionally, it reduces the window of exposure of a ho
st as being accessible via an address that becomes revealed as a result of activ
e communication. This document obsoletes RFC 4941.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8981"/>
<seriesInfo name="DOI" value="10.17487/RFC8981"/>
</reference>
<?rfc include="reference.RFC.8987.xml" ?>
<?rfc include="reference.RFC.9096.xml" ?>
<?rfc include="reference.RFC.9243.xml" ?>
<?rfc include="reference.RFC.9686.xml" ?>
<reference anchor="TR-187" target="https://www.broadband-forum.org/techn
ical/download/TR-187_Issue-2.pdf">
<front> <front>
<title>TR-187 - IPv6 for PPP Broadband Access</title> <title>IPv6 for PPP Broadband Access</title>
<author> <author>
<organization>Broadband Forum</organization> <organization>Broadband Forum</organization>
</author> </author>
<date year="2013" month="February"/> <date year="2013" month="February"/>
</front> </front>
<refcontent>TR-187, Issue: 2</refcontent>
</reference> </reference>
<reference anchor="IEEE-802.1x" target="https://ieeexplore.ieee.org/serv <!-- [rfced] This IEEE Std was superseded by a new version in 2020
let/opac?punumber=5409757"> https://ieeexplore.ieee.org/document/9018454.
We will update to point to the newer version unless we hear an objection.
Original:
[IEEE-802.1x]
IEEE, "IEEE Standard for Local and metropolitan area
networks-Port-Based Network Access Control", IEEE 802.1X-
2010, DOI 10.1109/IEEESTD.2010.5409813,
<https://ieeexplore.ieee.org/servlet/
opac?punumber=5409757>.
-->
<reference anchor="IEEE-802.1x" target="https://ieeexplore.ieee.org/docu
ment/5409813">
<front> <front>
<title>IEEE Standard for Local and metropolitan area networks--Port- Based Network Access Control</title> <title>IEEE Standard for Local and metropolitan area networks--Port- Based Network Access Control</title>
<author> <author>
<organization>IEEE</organization> <organization>IEEE</organization>
</author> </author>
<!-- <date year="2010" month="February" /> --> <date year="2010" month="February" />
<date/>
</front> </front>
<seriesInfo name="IEEE" value="802.1X-2010"/> <seriesInfo name="IEEE" value="802.1X-2010"/>
<seriesInfo name="DOI" value="10.1109/IEEESTD.2010.5409813"/> <seriesInfo name="DOI" value="10.1109/IEEESTD.2010.5409813"/>
</reference> </reference>
<!-- Note to PE: Updated XML for 2020 version of
<reference anchor="IEEE-802.1x" target="https://ieeexplore.ieee.org/docu
ment/9018454">
<front>
<title>IEEE Standard for Local and metropolitan area networks-Port-B
ased Network Access Control</title>
<author>
<organization>IEEE</organization>
</author>
<date year="2020" month="February" />
<date/>
</front>
<seriesInfo name="IEEE" value="802.1X-2020"/>
<seriesInfo name="DOI" value="10.1109/IEEESTD.2020.9018454"/>
</reference>
-->
<reference anchor="Err6159" quote-title="false" target="https://www.rfc-editor.o
rg/errata/eid1912">
<front>
<title>Erratum ID 6159</title>
<author>
<organization>RFC Errata</organization>
</author>
</front>
<refcontent>RFC 8415</refcontent>
</reference>
<reference anchor="Err6269" quote-title="false" target="https://www.rfc-editor.o
rg/errata/eid1912">
<front>
<title>Erratum ID 6269</title>
<author>
<organization>RFC Errata</organization>
</author>
</front>
<refcontent>RFC 8415</refcontent>
</reference>
<reference anchor="Err6183" quote-title="false" target="https://www.rfc-editor.o
rg/errata/eid1912">
<front>
<title>Erratum ID 6183</title>
<author>
<organization>RFC Errata</organization>
</author>
</front>
<refcontent>RFC 8415</refcontent>
</reference>
</references> </references>
</references> </references>
<section anchor="ChangeSummary" numbered="true" toc="default"> <section anchor="ChangeSummary" numbered="true" toc="default">
<name>Summary of Changes</name> <name>Summary of Changes from RFC 8415</name>
<t>This appendix provides a summary of the changes made from <t>This appendix provides a summary of the differences between this docume
RFC8415: nt and
<xref target="RFC8415"/>:</t>
</t> <ol spacing="normal" type="1">
<ol spacing="normal" type="1"><li> <li>
<t>The following mechanisms were obsoleted. These were not widely <t>The following mechanisms were obsoleted. These were not widely
deployed while adding complexity to client and server implementations. deployed while adding complexity to client and server
Legacy implementations MAY support them, but implementations conformant implementations. Legacy implementations <bcp14>MAY</bcp14> support
to this document MUST NOT rely on them. Obsoleting these features does them, but implementations conformant to this document <bcp14>MUST
not cause any interoperatability issues when mixing updated and non-updated NOT</bcp14> rely on them. Obsoleting these features does not cause
clients, relay agents, and servers as these mechanisms were "optional". any interoperability issues when mixing updated and non-updated
clients, relay agents, and servers as these mechanisms were
</t> "optional".</t>
<dl newline="false" spacing="normal"> <ul spacing="normal">
<dt>IA_TA option.</dt> <li>IA_TA option. The Identity Association for Temporary
<dd> Addresses option has been obsoleted. A client that needs a
The Identity Association for Temporary Addresses option has short-term / special purpose address can use a new IA_NA binding
been obsoleted. A client that needs a short-term / special to request an address and release it when finished with it.</li>
purpose address can use a new IA_NA binding to request an <li>UNICAST option. The Server Unicast option has been obsoleted. Us
address and release it when finished with it.</dd> e of this was
<dt>UNICAST option.</dt> rarely practical as typically relay agents between the client and
<dd> server need to glean information from the communication and cannot
The Server Unicast option has been obsoleted. Use of this be bypassed.</li>
was rarely practical as typically relay agents between the <li>UseMulticast status code. The UseMulticast status code has
client and server need to glean information from the been obsoleted. Clients will always multicast messages (as Server
communication and cannot be bypassed.</dd> Unicast option has been obsoleted) and servers will no longer
<dt>UseMulticast status code.</dt> check for unicast traffic.</li>
<dd> </ul>
The UseMulticast status code has been obsoleted. Clients
will always multicast messages (as Server Unicast option
has been obsoleted) and servers will no longer check for
unicast traffic.</dd>
</dl>
</li> </li>
<li>The following errata for RFC 8415 were incorporated: <li>The following errata reports for <xref target="RFC8415"/> were
erratum IDs 6159, 6269 and 6183. incorporated: <xref target="Err6159"/> <xref target="Err6269"/>, <xref t
Note that erratum ID 6269 was no longer arget="Err6183"/>. Note that EID
applicable after the Server Unicast Option was obsoleted. 6269 was no longer applicable after the Server Unicast Option was
Note that erratum 6159 is also no longer applicable now that temporary obsoleted. Note that EID 6159 was also no longer applicable as
addresses have been obsoleted. Indeed, the section (6.5) that erratum temporary addresses have been obsoleted. Indeed, the text that EID 6159
6159 corrects has been deleted. corrects has been deleted.</li>
</li> <li>A reference to <xref target="RFC7943"/> was added to <xref
<li>A reference to RFC 7943 was added to <xref target="addr-assign-ia-na target="addr-assign-ia-na" format="default"/> as it documents a method
" format="default"/> as that might be used to generate addresses and was inadvertently missed
it documents a method that might be used to generate addresses and was when compiling <xref target="RFC8415"/>.</li>
inadvertently missed when compiling RFC 8415.
</li>
<li>Clarified the UDP ports used by clients, servers, and <li>Clarified the UDP ports used by clients, servers, and
relay agents (<xref target="udp-ports" format="default"/>).</li> relay agents (<xref target="udp-ports" format="default"/>).</li>
<li>Several additional RFCs have been referenced and editorial <li>Several additional RFCs have been referenced and editorial
and reviews comments incorporated.</li> and reviews comments incorporated.</li>
</ol> </ol>
</section> </section>
<section anchor="RFC3315-A" numbered="true" toc="default"> <section anchor="RFC3315-A" numbered="true" toc="default">
<name>Appearance of Options in Message Types</name> <name>Appearance of Options in Message Types</name>
<t>The following tables indicate with a "*" the options that are allowed <t>The following tables indicate with a "*" the options that are allowed
in each DHCP message type.</t> in each DHCP message type.</t>
<t>These tables are informational. If they conflict with text earlier <t>These tables are informational. If they conflict with text earlier
in this document, that text should be considered authoritative.</t> in this document, that text should be considered authoritative.</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
Client Server Elap. Relay <table>
ID ID IA_NA IA_PD ORO Pref Time Msg. Auth. <thead>
Solicit * * * * * <tr>
Advert. * * * * * <th/>
Request * * * * * * <th>Client ID</th>
Confirm * * * <th>Server ID</th>
Renew * * * * * * <th>IA_NA</th>
Rebind * * * * * <th>IA_PD</th>
Decline * * * * * <th>ORO</th>
Release * * * * * <th>Pref</th>
Reply * * * * * <th>Elap. Time</th>
Reconf. * * * <th>Relay Msg.</th>
Inform. * (see note) * * <th>Auth.</th>
R-forw. * </tr>
R-repl. * </thead>
]]></artwork> <tbody>
<tr>
<th>Solicit</th>
<td align="center">*</td>
<td/>
<td align="center">*</td>
<td align="center">*</td>
<td align="center">*</td>
<td/>
<td align="center">*</td>
<td/>
<td/>
</tr>
<tr>
<th>Advert.</th>
<td align="center">*</td>
<td align="center">*</td>
<td align="center">*</td>
<td align="center">*</td>
<td></td>
<td align="center">*</td>
<td></td>
<td></td>
<td></td>
</tr>
<tr>
<th>Request</th>
<td align="center">*</td>
<td align="center">*</td>
<td align="center">*</td>
<td align="center">*</td>
<td align="center">*</td>
<td></td>
<td align="center">*</td>
<td></td>
<td></td>
</tr>
<tr>
<th>Confirm</th>
<td align="center">*</td>
<td></td>
<td align="center">*</td>
<td></td>
<td></td>
<td></td>
<td align="center">*</td>
<td></td>
<td></td>
</tr>
<tr>
<th>Renew</th>
<td align="center">*</td>
<td align="center">*</td>
<td align="center">*</td>
<td align="center">*</td>
<td align="center">*</td>
<td align="center">*</td>
<td align="center">*</td>
<td></td>
<td></td>
</tr>
<tr>
<th>Rebind</th>
<td align="center">*</td>
<td></td>
<td align="center">*</td>
<td align="center">*</td>
<td align="center">*</td>
<td></td>
<td align="center">*</td>
<td></td>
<td></td>
</tr>
<tr>
<th>Decline</th>
<td align="center">*</td>
<td align="center">*</td>
<td align="center">*</td>
<td align="center">*</td>
<td></td>
<td></td>
<td align="center">*</td>
<td></td>
<td></td>
</tr>
<tr>
<th>Release</th>
<td align="center">*</td>
<td align="center">*</td>
<td align="center">*</td>
<td align="center">*</td>
<td></td>
<td></td>
<td align="center">*</td>
<td></td>
<td></td>
</tr>
<tr>
<th>Reply</th>
<td align="center">*</td>
<td align="center">*</td>
<td align="center">*</td>
<td align="center">*</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td align="center">*</td>
</tr>
<tr>
<th>Reconf</th>
<td align="center">*</td>
<td align="center">*</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td align="center">*</td>
</tr>
<tr>
<th>Inform.</th>
<td align="center">*</td>
<td>(see note)</td>
<td></td>
<td></td>
<td align="center">*</td>
<td></td>
<td align="center">*</td>
<td></td>
<td></td>
</tr>
<tr>
<th>R-forw.</th>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td align="center">*</td>
</tr>
<tr>
<th>R-repl.</th>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td align="center">*</td>
</tr>
</tbody>
</table>
<t>NOTE: The Server Identifier option <t>NOTE: The Server Identifier option
(see <xref target="RFC3315-22.3" format="default"/>) is (see <xref target="RFC3315-22.3" format="default"/>) is
only included in Information-request messages that are sent in only included in Information-request messages that are sent in
response to a Reconfigure (see <xref target="RFC3315-18.1.5" format="defau lt"/>).</t> response to a Reconfigure (see <xref target="RFC3315-18.1.5" format="defau lt"/>).</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
Info <table>
Status Rap. User Vendor Vendor Inter. Recon. Recon. Refresh <thead>
Code Comm. Class Class Spec. ID Msg. Accept Time <tr>
Solicit * * * * * <th/>
Advert. * * * * * <th>Status Code</th>
Request * * * * <th>Rap. Comm.</th>
Confirm * * * <th>User Class</th>
Renew * * * * <th>Vendor Class</th>
Rebind * * * * <th>Vendor Spec.</th>
Decline * * * <th>Inter. ID</th>
Release * * * <th>Recon. Msg.</th>
Reply * * * * * * * <th>Recon. Accept</th>
Reconf. * <th>Info Refr. Time</th>
Inform. * * * * </tr>
R-forw. * * </thead>
R-repl. * * <tbody>
]]></artwork> <tr>
<artwork name="" type="" align="left" alt=""><![CDATA[ <th>Solicit</th>
SOL_MAX_RT INF_MAX_RT <td></td>
Solicit <td align="center">*</td>
Advert. * <td align="center">*</td>
Request <td align="center">*</td>
Confirm <td align="center">*</td>
Renew <td></td>
Rebind <td></td>
Decline <td align="center">*</td>
Release <td></td>
Reply * * </tr>
Reconf. <tr>
Inform. <th>Advert.</th>
R-forw. <td align="center">*</td>
R-repl. <td></td>
]]></artwork> <td align="center">*</td>
<td align="center">*</td>
<td align="center">*</td>
<td></td>
<td></td>
<td align="center">*</td>
<td></td>
</tr>
<tr>
<th>Request</th>
<td></td>
<td></td>
<td align="center">*</td>
<td align="center">*</td>
<td align="center">*</td>
<td></td>
<td></td>
<td align="center">*</td>
<td></td>
</tr>
<tr>
<th>Confirm</th>
<td></td>
<td></td>
<td align="center">*</td>
<td align="center">*</td>
<td align="center">*</td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr>
<th>Renew</th>
<td></td>
<td></td>
<td align="center">*</td>
<td align="center">*</td>
<td align="center">*</td>
<td></td>
<td></td>
<td align="center">*</td>
<td></td>
</tr>
<tr>
<th>Rebind</th>
<td></td>
<td></td>
<td align="center">*</td>
<td align="center">*</td>
<td align="center">*</td>
<td></td>
<td></td>
<td align="center">*</td>
<td></td>
</tr>
<tr>
<th>Decline</th>
<td></td>
<td></td>
<td align="center">*</td>
<td align="center">*</td>
<td align="center">*</td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr>
<th>Release</th>
<td></td>
<td></td>
<td align="center">*</td>
<td align="center">*</td>
<td align="center">*</td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr>
<th>Reply</th>
<td align="center">*</td>
<td align="center">*</td>
<td align="center">*</td>
<td align="center">*</td>
<td align="center">*</td>
<td></td>
<td></td>
<td align="center">*</td>
<td align="center">*</td>
</tr>
<tr>
<th>Reconf.</th>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td align="center">*</td>
<td></td>
<td></td>
</tr>
<tr>
<th>Inform.</th>
<td></td>
<td></td>
<td align="center">*</td>
<td align="center">*</td>
<td align="center">*</td>
<td></td>
<td></td>
<td align="center">*</td>
<td></td>
</tr>
<tr>
<th>R-forw.</th>
<td></td>
<td></td>
<td></td>
<td></td>
<td align="center">*</td>
<td align="center">*</td>
<td></td>
<td></td>
<td></td>
</tr>
<tr>
<th>R-repl.</th>
<td></td>
<td></td>
<td></td>
<td></td>
<td align="center">*</td>
<td align="center">*</td>
<td></td>
<td></td>
<td></td>
</tr>
</tbody>
</table>
<table>
<thead>
<tr>
<th/>
<th>SOL_MAX_RT</th>
<th>INF_MAX_RT</th>
</tr>
</thead>
<tbody>
<tr>
<td>Solicit</td>
<td></td>
<td></td>
</tr>
<tr>
<td>Advert.</td>
<td align="center">*</td>
<td></td>
</tr>
<tr>
<td>Request</td>
<td></td>
<td></td>
</tr>
<tr>
<td>Confirm</td>
<td></td>
<td></td>
</tr>
<tr>
<td>Renew</td>
<td></td>
<td></td>
</tr>
<tr>
<td>Rebind</td>
<td></td>
<td></td>
</tr>
<tr>
<td>Decline</td>
<td></td>
<td></td>
</tr>
<tr>
<td>Release</td>
<td></td>
<td></td>
</tr>
<tr>
<td>Reply</td>
<td align="center">*</td>
<td align="center">*</td>
</tr>
<tr>
<td>Reconf.</td>
<td></td>
<td></td>
</tr>
<tr>
<td>Inform.</td>
<td></td>
<td></td>
</tr>
<tr>
<td>R-forw.</td>
<td></td>
<td></td>
</tr>
<tr>
<td>R-repl.</td>
<td></td>
<td></td>
</tr>
</tbody>
</table>
</section> </section>
<section anchor="RFC3315-B" numbered="true" toc="default"> <section anchor="RFC3315-B" numbered="true" toc="default">
<name>Appearance of Options in the "options" Field of DHCP Options</name> <name>Appearance of Options in the "options" Field of DHCP Options</name>
<t>The following table indicates with a "*" where options defined in <t>The following table indicates with a "*" where options defined in
this document can appear as top-level options or can be encapsulated this document can appear as top-level options or can be encapsulated
in other options defined in this document. Other RFCs may define in other options defined in this document. Other RFCs may define
additional situations where options defined in this document are additional situations where options defined in this document are
encapsulated in other options.</t> encapsulated in other options.</t>
<t>This table is informational. If it conflicts with text earlier in <t>This table is informational. If it conflicts with text earlier in
this document, that text should be considered authoritative.</t> this document, that text should be considered authoritative.</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
Top- RELAY- RELAY- <table>
Level IA_NA IAADDR IA_PD IAPREFIX FORW REPL <thead>
Client ID * <tr>
Server ID * <th/>
IA_NA * <th>Top-Level</th>
IAADDR * <th>IA_NA</th>
IA_PD * <th>IAADDR</th>
IAPREFIX * <th>IA_PD</th>
ORO * <th>IAPREFIX</th>
Preference * <th>RELAY-FORW</th>
Elapsed Time * <th>RELAY-REPL</th>
Relay Message * * </tr>
Authentic. * </thead>
Status Code * * * <tbody>
Rapid Comm. * <tr>
User Class * <th>Client ID</th>
Vendor Class * <td align="center">*</td>
Vendor Info. * * * <td></td>
Interf. ID * * <td></td>
Reconf. MSG. * <td></td>
Reconf. Accept * <td></td>
Info Refresh Time * <td></td>
SOL_MAX_RT * <td></td>
INF_MAX_RT * </tr>
]]></artwork> <tr>
<th>Server ID</th>
<td align="center">*</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr>
<th>IA_NA</th>
<td align="center">*</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr>
<th>IAADDR</th>
<td></td>
<td align="center">*</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr>
<th>IA_PD</th>
<td align="center">*</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr>
<th>IAPREFIX</th>
<td></td>
<td></td>
<td></td>
<td align="center">*</td>
<td></td>
<td></td>
<td></td>
</tr>
<tr>
<th>ORO</th>
<td align="center">*</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr>
<th>Preference</th>
<td align="center">*</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr>
<th>Elapsed Time</th>
<td align="center">*</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr>
<th>Relay Message</th>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td align="center">*</td>
<td align="center">*</td>
</tr>
<tr>
<th>Authentic.</th>
<td align="center">*</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr>
<th>Status Code</th>
<td align="center">*</td>
<td align="center">*</td>
<td></td>
<td align="center">*</td>
<td></td>
<td></td>
<td></td>
</tr>
<tr>
<th>Rapid Comm.</th>
<td align="center">*</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr>
<th>User Class</th>
<td align="center">*</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr>
<th>Vendor Class</th>
<td align="center">*</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr>
<th>Vendor Info.</th>
<td align="center">*</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td align="center">*</td>
<td align="center">*</td>
</tr>
<tr>
<th>Interf. ID</th>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td align="center">*</td>
<td align="center">*</td>
</tr>
<tr>
<th>Reconf. MSG.</th>
<td align="center">*</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr>
<th>Reconf. Accept</th>
<td align="center">*</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr>
<th>Info Refresh Time</th>
<td align="center">*</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr>
<th>SOL_MAX_RT</th>
<td align="center">*</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr>
<th>INF_MAX_RT</th>
<td align="center">*</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
</tbody>
</table>
<t>Notes: Options asterisked in the "Top-Level" column appear in the <t>Notes: Options asterisked in the "Top-Level" column appear in the
"options" field of client messages (see <xref target="RFC3315-6" format="d efault"/>). Options "options" field of client messages (see <xref target="RFC3315-6" format="d efault"/>). Options
asterisked in the "RELAY-FORW" and "RELAY-REPL" columns appear in the asterisked in the "RELAY-FORW" and "RELAY-REPL" columns appear in the
"options" field of the Relay-forward and Relay-reply messages "options" field of the Relay-forward and Relay-reply messages
(see <xref target="RFC3315-7" format="default"/>).</t> (see <xref target="RFC3315-7" format="default"/>).</t>
</section> </section>
<section numbered="false" toc="default"> <section numbered="false" toc="default">
<name>Acknowledgments</name> <name>Acknowledgments</name>
<t>This document is merely a refinement of earlier work as described <t>This document is merely a refinement of earlier work as described
in RFC 8415. in <xref target="RFC8415"/>.</t>
</t>
<t>A number of additional people have contributed to identifying issues <t>A number of additional people have contributed to identifying issues
with RFC 8415, including Fernando Gont, Felix Hamme, Rene Engel, Esko Dijk with <xref target="RFC8415"/> including <contact fullname="Fernando
, Gont"/>, <contact fullname="Felix Hamme"/>, <contact fullname="Rene
Jen Linkova, Tomoyuki Sahara, and Ted Lemon. Engel"/>, <contact fullname="Esko Dijk"/>, <contact fullname="Jen
</t> Linkova"/>, <contact fullname="Tomoyuki Sahara"/>, and <contact
fullname="Ted Lemon"/>.</t>
<t>We thank the thorough and thoughtful reviewers during the IETF <t>We thank the thorough and thoughtful reviewers during the IETF
process, especially Mohamed Boucadair, Tim Chown, Roman Danyliw, process, especially <contact fullname="Mohamed Boucadair"/>, <contact
Tatuya Jinmei, Jim Read, Ketan Talaulikar, Eric Vyncke, Dave Worley. We fullname="Tim Chown"/>, <contact fullname="Roman Danyliw"/>, <contact
also thank the DHC working group members for their reviews of this updated fullname="Tatuya Jinmei"/>, <contact fullname="Jim Read"/>, <contact
document. fullname="Ketan Talaulikar"/>, <contact fullname="Éric Vyncke"/>, and
</t> <contact fullname="Dave Worley"/>. We also thank the DHC WG
<t>And, special thanks to Suresh Krishnan for shepherding this document members for their reviews of this updated document.</t>
through the IETF process. <t>And special thanks to <contact fullname="Suresh Krishnan"/> for
</t> shepherding this document through the IETF process.</t>
</section> </section>
</back> </back>
<!--[rfced] We had the following questions/comments about abbreviation
use throughout the document:
a) FYI - We have added expansions for abbreviations upon first use per
Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each
expansion in the document carefully to ensure correctness.
b) Should CPE be expanded as Customer Premises Equipment here?
Original:
The prefix delegation process begins
when the client (CPE) requests configuration information through DHCP.
Perhaps:
The prefix delegation process begins
when the client (or Customer Premises Equipment (CPE)) requests
configuration information through DHCP.
-->
<!-- [rfced] Some tables and figures in this document do not have
titles. Please review and provide titles for these, if desired.
-->
<!-- [rfced] Please review whether any of the notes in this document
should be in the <aside> element. It is defined as "a container
for content that is semantically less important or tangential to
the content that surrounds it"
(https://authors.ietf.org/en/rfcxml-vocabulary#aside).
-->
<!-- [rfced] Please review the "Inclusive Language" portion of the
online Style Guide
<https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
and let us know if any changes are needed. Updates of this
nature typically result in more precise language, which is
helpful for readers.
For example, please consider whether the following should be updated:
man-in-the-middle
-->
</rfc> </rfc>
 End of changes. 604 change blocks. 
2711 lines changed or deleted 2447 lines changed or added

This html diff was produced by rfcdiff 1.48.