rfc9686.original.xml   rfc9686.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version='1.0' encoding='UTF-8'?>
<!-- pre-edited by ST 05/28/24 -->
<!-- reference review by TH 09/09/24 -->
<!-- formatting completed by KF 09/11/24 -->
<!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" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.11 (Ruby 3.0. <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
2) --> -ietf-dhc-addr-notification-13" number="9686" updates="" obsoletes="" category="
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft std" consensus="true" submissionType="IETF" tocInclude="true" sortRefs="true" sy
-ietf-dhc-addr-notification-13" category="std" consensus="true" submissionType=" mRefs="true" version="3" xml:lang="en">
IETF" tocInclude="true" sortRefs="true" symRefs="true" version="3">
<!-- xml2rfc v2v3 conversion 3.21.0 --> <!-- [rfced] Due to its length, may we abbreviate the following
affiliation in the document header? It will be expanded in the
Authors' Addresses section.
Original:
S. Jiang
Beijing University of Posts and Telecommunications
Perhaps:
S. Jiang
BUPT
-->
<front> <front>
<title abbrev="Registering self-generated Addresses using DHCPv6">Registerin <title abbrev="Registering Self-Generated Addresses Using DHCPv6">Registerin
g Self-generated IPv6 Addresses using DHCPv6</title> g Self-Generated IPv6 Addresses Using DHCPv6</title>
<seriesInfo name="Internet-Draft" value="draft-ietf-dhc-addr-notification-13 <seriesInfo name="RFC" value="9686"/>
"/>
<author initials="W." surname="Kumari" fullname="Warren Kumari"> <author initials="W." surname="Kumari" fullname="Warren Kumari">
<organization>Google, LLC</organization> <organization>Google, LLC</organization>
<address> <address>
<email>warren@kumari.net</email> <email>warren@kumari.net</email>
</address> </address>
</author> </author>
<author initials="S." surname="Krishnan" fullname="Suresh Krishnan"> <author initials="S." surname="Krishnan" fullname="Suresh Krishnan">
<organization>Cisco Systems, Inc.</organization> <organization>Cisco Systems, Inc.</organization>
<address> <address>
<email>suresh.krishnan@gmail.com</email> <email>suresh.krishnan@gmail.com</email>
skipping to change at line 68 skipping to change at line 85
<postal> <postal>
<street>No. 10 Xitucheng Road</street> <street>No. 10 Xitucheng Road</street>
<city>Beijing</city> <city>Beijing</city>
<region>Haidian District</region> <region>Haidian District</region>
<code>100083</code> <code>100083</code>
<country>China</country> <country>China</country>
</postal> </postal>
<email>shengjiang@bupt.edu.cn</email> <email>shengjiang@bupt.edu.cn</email>
</address> </address>
</author> </author>
<date year="2024" month="May" day="16"/> <date year="2024" month="October"/>
<area>Internet</area> <area>INT</area>
<workgroup>Dynamic Host Configuration</workgroup> <workgroup>dhc</workgroup>
<keyword>Internet-Draft</keyword>
<abstract>
<?line 99?>
<t>This document defines a method to inform a DHCPv6 server that a device has on <!-- [rfced] Please insert any keywords (beyond those that appear in
e or more self-generated or statically configured addresses.</t> the title) for use on https://www.rfc-editor.org/search. -->
<keyword>example</keyword>
<abstract>
<t>This document defines a method to inform a DHCPv6 server that a
device has one or more self-generated or statically configured
addresses.</t>
</abstract> </abstract>
<note removeInRFC="true">
<name>About This Document</name>
<t>
The latest revision of this draft can be found at <eref target="https://
wkumari.github.io/draft-wkumari-dhc-addr-notification/draft-ietf-dhc-addr-notifi
cation.html"/>.
Status information for this document may be found at <eref target="https
://datatracker.ietf.org/doc/draft-ietf-dhc-addr-notification/"/>.
</t>
<t>
Discussion of this document takes place on the
Dynamic Host Configuration Working Group mailing list (<eref target="mai
lto:dhcwg@ietf.org"/>),
which is archived at <eref target="https://mailarchive.ietf.org/arch/bro
wse/dhcwg/"/>.
Subscribe at <eref target="https://www.ietf.org/mailman/listinfo/dhcwg/"
/>.
</t>
<t>Source for this draft and an issue tracker can be found at
<eref target="https://github.com/wkumari/draft-wkumari-dhc-addr-notifica
tion"/>.</t>
</note>
</front> </front>
<middle> <middle>
<?line 104?>
<section anchor="introduction"> <section anchor="introduction">
<name>Introduction</name> <name>Introduction</name>
<t>It is very common operational practice, especially in enterprise networ <t>It is very common operational practice, especially in enterprise
ks, to use IPv4 DHCP logs for troubleshooting or forensics purposes. Examples of networks, to use IPv4 DHCP logs for troubleshooting or forensics
this include a help desk dealing with a ticket such as "The CEO's laptop cannot purposes. An example of this includes a help desk dealing with a ticket
connect to the printer"; if the MAC address of the printer is known (for exampl such as "The CEO's laptop cannot connect to the printer"; if the Media Acc
e from an inventory system), the printer's IPv4 address can be retrieved from th ess Control (MAC)
e DHCP log or lease table and the printer pinged to determine if it is reachable address of the printer is known (for example, from an inventory system),
. Another common example is a Security Operations team discovering suspicious ev the printer's IPv4 address can be retrieved from the DHCP log or lease
ents in outbound firewall logs and then consulting DHCP logs to determine which table and the printer can be pinged to determine if it is
employee's laptop had that IPv4 address at that time so that they can quarantine reachable. Another common example is a security operations team
it and remove the malware.</t> discovering suspicious events in outbound firewall logs and then
<t>This operational practice relies on the DHCP server knowing the IP addr consulting DHCP logs to determine which employee's laptop had that IPv4
ess assignments. address at that time so that they can quarantine it and remove the
This works quite well for IPv4 addresses, as most addresses are either assigned malware.</t>
by DHCP <xref target="RFC2131"/> or statically configured by the network operato
r. For IPv6, however, this practice is much harder to implement, as devices ofte <t>This operational practice relies on the DHCP server knowing the IP
n self-configure IPv6 addresses via SLAAC <xref target="RFC4862"/>.</t> address assignments. This works quite well for IPv4 addresses, as most
<t>This document provides a mechanism for a device to inform the DHCPv6 se addresses are either assigned by DHCP <xref target="RFC2131"/> or
rver that the device has a self-configured IPv6 address (or has a statically con statically configured by the network operator. For IPv6, however, this
figured address), and thus provides parity with IPv4, by making DHCPv6 infrastru practice is much harder to implement, as devices often self-configure
cture aware of self-assigned IPv6 addresses.</t> IPv6 addresses via Stateless Address Autoconfiguration (SLAAC) <xref targe
t="RFC4862"/>.</t>
<t>This document provides a mechanism for a device to inform the DHCPv6
server that the device has a self-configured IPv6 address (or has a
statically configured address), and thus provides parity with IPv4 by
making DHCPv6 infrastructure aware of self-assigned IPv6 addresses.</t>
</section> </section>
<section anchor="conventions-and-definitions"> <section anchor="conventions-and-definitions">
<name>Conventions and Definitions</name> <name>Conventions and Definitions</name>
<t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14 <t>
>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECO "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>
MMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", ",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be i "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
nterpreted as "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
only when, they be
appear in all capitals, as shown here.</t> interpreted as described in BCP&nbsp;14 <xref target="RFC2119"/> <xref
<?line -18?> target="RFC8174"/> when, and only when, they appear in all capitals, as
shown here.
</t>
</section>
</section>
<section anchor="registration-mechanism-overview"> <section anchor="registration-mechanism-overview">
<name>Registration Mechanism Overview</name> <name>Registration Mechanism Overview</name>
<t>The DHCPv6 protocol is used as the address registration protocol when a <t>The DHCPv6 protocol is used as the address registration protocol when
DHCPv6 server performs the role of an address registration server. a DHCPv6 server performs the role of an address registration server.
This document introduces a new Address Registration (OPTION_ADDR_REG_ENABLE) opt This document introduces a new Address Registration
ion which indicates that the server supports the registration mechanism. (OPTION_ADDR_REG_ENABLE) option, which indicates that the server
Before registering any addresses, the client <bcp14>MUST</bcp14> determine wheth supports the registration mechanism. Before registering any addresses,
er the network supports address registration. It can do this by including the Ad the client <bcp14>MUST</bcp14> determine whether the network supports
dress Registration option code in the Option Request option (see Section 21.7 of address registration. It can do this by including the Address
<xref target="RFC8415"/>) of the Information-Request, Solicit, Request, Renew, Registration option code in the Option Request option (see <xref
or Rebind messages it sends to the server as part of the regular stateless or st target="RFC8415" sectionFormat="of" section="21.7"/>) of the
ateful DHCPv6 configuration process. If the server supports address registration Information-Request, Solicit, Request, Renew, or Rebind messages it
, it includes an Address Registration option in its Advertise or Reply messages. sends to the server as part of the regular stateless or stateful DHCPv6
To avoid undesired multicast traffic, if the DHCPv6 infrastructure does not supp configuration process. If the server supports address registration, it
ort (or is not willing to receive) any address registration information, the cli includes an Address Registration option in its Advertise or Reply
ent <bcp14>MUST NOT</bcp14> register any addresses using the mechanism in this s messages. To avoid undesired multicast traffic, if the DHCPv6
pecification. Otherwise, the client registers addresses as described below.</t> infrastructure does not support (or is not willing to receive) any
<t>After successfully assigning a self-generated or statically configured address registration information, the client <bcp14>MUST NOT</bcp14>
Valid (<xref target="RFC4862"/>) IPv6 address on one of its interfaces, a client register any addresses using the mechanism in this
implementing this specification multicasts an ADDR-REG-INFORM message (see Sec specification. Otherwise, the client registers addresses as described
tion 4.2) in order to inform the DHCPv6 server that this self-generated address below.</t>
is in use. Each ADDR-REG-INFORM message contains a DHCPv6 IA Address option <xre
f target="RFC8415"/> to specify the address being registered.</t> <t>After successfully assigning a self-generated or statically
<t>The address registration mechanism overview is shown in Fig.1.</t> configured valid IPv6 address <xref target="RFC4862"/> on one of its
interfaces, a client implementing this specification multicasts an
ADDR-REG-INFORM message (see <xref
target="dhcpv6-address-registration-request-message"/>) in order to
inform the DHCPv6 server that this self-generated address is in
use. Each ADDR-REG-INFORM message contains a DHCPv6 Identity Association
(IA) Address option <xref target="RFC8415"/> to specify the address
being registered.</t>
<t>The address registration mechanism overview is shown in <xref
target="Fig.1"/>.</t>
<figure anchor="Fig.1">
<name>Address Registration Procedure Overview</name>
<artwork><![CDATA[ <artwork><![CDATA[
+--------+ +------------------+ +---------------+ +--------+ +------------------+ +---------------+
| CLIENT | | FIRST-HOP ROUTER | | DHCPv6 SERVER | | CLIENT | | FIRST-HOP ROUTER | | DHCPv6 SERVER |
+--------+ +---------+--------+ +-------+-------+ +--------+ +---------+--------+ +-------+-------+
| SLAAC | | | SLAAC | |
|<--------------------> | | |<--------------------> | |
| | | | | |
| | | |
| src: link-local address | | src: link-local address |
| --------------------------------------------> | | --------------------------------------------> |
skipping to change at line 152 skipping to change at line 212
| | | |
| src: address being registered | | src: address being registered |
| --------------------------------------------> | | --------------------------------------------> |
| ADDR-REG-INFORM MESSAGE |Register/ | ADDR-REG-INFORM MESSAGE |Register/
| |log addresses | |log addresses
| | | |
| | | |
| <-------------------------------------------- | | <-------------------------------------------- |
| ADDR-REG-REPLY MESSAGE | | ADDR-REG-REPLY MESSAGE |
| | | |
]]></artwork> ]]></artwork>
<t>Figure 1: Address Registration Procedure Overview</t> </figure>
</section> </section>
<section anchor="dhcpv6-address-registration-procedure"> <section anchor="dhcpv6-address-registration-procedure">
<name>DHCPv6 Address Registration Procedure</name> <name>DHCPv6 Address Registration Procedure</name>
<section anchor="dhcpv6-address-registration-option"> <section anchor="dhcpv6-address-registration-option">
<name>DHCPv6 Address Registration Option</name> <name>DHCPv6 Address Registration Option</name>
<t>The Address Registration option (OPTION_ADDR_REG_ENABLE) indicates th <t>The Address Registration option (OPTION_ADDR_REG_ENABLE) indicates
at the server supports the mechanism described in this document. The format of t that the server supports the mechanism described in this document. The
he Address Registration option is described as follows:</t> format of the Address Registration option is described as follows:</t>
<artwork><![CDATA[ <figure anchor="Fig.2">
<name>DHCPv6 Address Registration Option</name>
<artwork><![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-code OPTION_ADDR_REG_ENABLE (TBA0)
option-len 0
]]></artwork> ]]></artwork>
<t>Figure 2: DHCPv6 Address Registration option</t> </figure>
<dl>
<dt>option-code:</dt><dd>OPTION_ADDR_REG_ENABLE (148)</dd>
<dt>option-len:</dt><dd>0</dd>
</dl>
<t>If a client has the address registration mechanism enabled, it <bcp14 >MUST</bcp14> include this option in all Option Request options that it sends.</ t> <t>If a client has the address registration mechanism enabled, it <bcp14 >MUST</bcp14> include this option in all Option Request options that it sends.</ t>
<t>A server which is configured to support the address registration mech anism <bcp14>MUST</bcp14> include this option in Advertise and Reply messages if the client message it is replying to contained this option in the Option Reques t option.</t> <t>A server that is configured to support the address registration mecha nism <bcp14>MUST</bcp14> include this option in Advertise and Reply messages if the client message it is replying to contained this option in the Option Request option.</t>
</section> </section>
<section anchor="dhcpv6-address-registration-request-message"> <section anchor="dhcpv6-address-registration-request-message">
<name>DHCPv6 Address Registration Request Message</name> <name>DHCPv6 Address Registration Request Message</name>
<t>The DHCPv6 client sends an ADDR-REG-INFORM message to inform that an IPv6 address is assigned to the client's interface. <t>The DHCPv6 client sends an ADDR-REG-INFORM message to inform that an IPv6 address is assigned to the client's interface.
The format of the ADDR-REG-INFORM message is described as follows:</t> The format of the ADDR-REG-INFORM message is described as follows:</t>
<artwork><![CDATA[
<figure anchor="Fig.3">
<name>DHCPv6 ADDR-REG-INFORM Message</name>
<artwork><![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) . . (variable) .
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
msg-type Identifies the DHCPv6 message type; ]]></artwork>
Set to ADDR-REG-INFORM (TBA1). </figure>
transaction-id The transaction ID for this message exchange. <dl>
<dt>msg-type:</dt><dd>Identifies the DHCPv6 message type; set to ADDR-REG-INFO
RM (36).</dd>
<dt>transaction-id:</dt><dd>The transaction ID for this message exchange.</dd>
<dt>options:</dt><dd>The options carried in this message.</dd>
</dl>
<t>The client <bcp14>MUST</bcp14> generate a transaction ID as
described in <xref target="RFC8415"/> and insert this value in the
"transaction-id" field.</t>
<t>The client <bcp14>MUST</bcp14> include the Client Identifier option
<xref target="RFC8415"/> in the ADDR-REG-INFORM message.</t>
<t>The ADDR-REG-INFORM message <bcp14>MUST NOT</bcp14> contain the
Server Identifier option and <bcp14>MUST</bcp14> contain exactly one IA
Address option containing the address being registered. The
valid-lifetime and preferred-lifetime fields in the option
<bcp14>MUST</bcp14> match the current Valid Lifetime and Preferred
Lifetime of the address being registered.</t>
<t>The ADDR-REG-INFORM message is dedicated for clients to initiate an
address registration request toward an address registration server.
Consequently, clients <bcp14>MUST NOT</bcp14> put any Option Request
option(s) in the ADDR-REG-INFORM message. Clients <bcp14>MAY</bcp14>
include other options, such as the Client FQDN option <xref
target="RFC4704"/>.</t>
<t>The client sends the DHCPv6 ADDR-REG-INFORM message to the
All_DHCP_Relay_Agents_and_Servers multicast address (ff02::1:2). The
client <bcp14>MUST</bcp14> send separate messages for each address
being registered.</t>
<t>Unlike other types of messages, which are sent from the link-local
address of the client, the ADDR-REG-INFORM message <bcp14>MUST</bcp14>
be sent from the address being registered. This is primarily for "fate
sharing" purposes; for example, if the network implements some form
of Layer 2 security to prevent a client from spoofing other clients'
MAC addresses, this prevents an attacker from spoofing ADDR-REG-INFORM
messages.</t>
<t>On clients with multiple interfaces, the client <bcp14>MUST</bcp14>
only send the packet on the network interface that has the address
being registered, even if it has multiple interfaces with different
addresses. If the same address is configured on multiple interfaces,
then the client <bcp14>MUST</bcp14> send the ADDR-REG-INFORM message
each time the address is configured on an interface that did not
previously have it and refresh each registration independently
from the others.</t>
<t>The client <bcp14>MUST</bcp14> only send the ADDR-REG-INFORM
message for valid addresses <xref target="RFC4862"/> of global scope
<xref target="RFC4007"/>. This includes Unique Local Addresses (ULAs), w
hich are
defined in <xref target="RFC4193"/> to have global scope. This also
includes statically assigned addresses of global scope (such addresses
are considered to be valid indefinitely). The client <bcp14>MUST
NOT</bcp14> send the ADDR-REG-INFORM message for addresses configured
by DHCPv6.</t>
<t>The client <bcp14>SHOULD NOT</bcp14> send the ADDR-REG-INFORM
message unless it has received a Router Advertisement (RA) message with
either the M or O flags set to 1.</t>
options Options carried in this message.
]]></artwork>
<t>Figure 3: DHCPv6 ADDR-REG-INFORM message</t>
<t>The client <bcp14>MUST</bcp14> generate a transaction ID as described
in <xref target="RFC8415"/> and insert this value in the "transaction-id" field
.</t>
<t>The client <bcp14>MUST</bcp14> include the Client Identifier option <
xref target="RFC8415"/> in the ADDR-REG-INFORM message.</t>
<t>The ADDR-REG-INFORM message <bcp14>MUST NOT</bcp14> contain the Serve
r Identifier option and <bcp14>MUST</bcp14> contain exactly one IA Address optio
n containing the address being registered. The valid-lifetime and preferred-life
time fields in the option <bcp14>MUST</bcp14> match the current Valid Lifetime a
nd Preferred Lifetime of the address being registered.</t>
<t>The ADDR-REG-INFORM message is dedicated for clients to initiate an a
ddress registration request toward an address registration server. Consequently
, clients <bcp14>MUST NOT</bcp14> put any Option Request Option(s) in the ADDR-R
EG-INFORM message. Clients <bcp14>MAY</bcp14> include other options, such as the
Client FQDN Option <xref target="RFC4704"/>.</t>
<t>The client sends the DHCPv6 ADDR-REG-INFORM message to the All_DHCP_R
elay_Agents_and_Servers multicast address (ff02::1:2). The client <bcp14>MUST</b
cp14> send separate messages for each address being registered.</t>
<t>Unlike other types of messages, which are sent from the link-local ad
dress of the client, the ADDR-REG-INFORM message <bcp14>MUST</bcp14> be sent fro
m the address being registered. This is primarily for "fate sharing" purposes -
for example, if the network implements some form of layer-2 security to prevent
a client from spoofing other clients' MAC addresses, this prevents an attacker f
rom spoofing ADDR-REG-INFORM messages.</t>
<t>On clients with multiple interfaces, the client <bcp14>MUST</bcp14> o
nly send the packet on the network interface that has the address being register
ed, even if it has multiple interfaces with different addresses. If the same add
ress is configured on multiple interfaces, then the client <bcp14>MUST</bcp14> s
end ADDR-REG-INFORM each time the address is configured on an interface that did
not previously have it, and refresh each registration independently from the ot
hers.</t>
<t>The client <bcp14>MUST</bcp14> only send the ADDR-REG-INFORM message
for valid (<xref target="RFC4862"/>) addresses of global scope (<xref target="RF
C4007"/>). This includes ULA addresses, which are defined in <xref target="RFC41
93"/> to have global scope. This also includes statically assigned addresses of
global scope (such addresses are considered to be valid indefinitely).
The client <bcp14>MUST NOT</bcp14> send the ADDR-REG-INFORM message for addresse
s configured by DHCPv6.</t>
<t>The client <bcp14>SHOULD NOT</bcp14> send the ADDR-REG-INFORM message
unless it has received a Router Advertisement message with either M or O flags
set to 1.</t>
<t>Clients <bcp14>MUST</bcp14> discard any received ADDR-REG-INFORM mess ages.</t> <t>Clients <bcp14>MUST</bcp14> discard any received ADDR-REG-INFORM mess ages.</t>
<section anchor="server-message-processing"> <section anchor="server-message-processing">
<name>Server message processing</name> <name>Server Message Processing</name>
<t>Servers <bcp14>MUST</bcp14> discard any ADDR-REG-INFORM messages th
at meet any of the following conditions:</t> <t>Servers <bcp14>MUST</bcp14> discard any ADDR-REG-INFORM messages
that meet any of the following conditions:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>the message does not include a Client Identifier option;</t> <t>the message does not include a Client Identifier option;</t>
</li> </li>
<li> <li>
<t>the message includes a Server Identifier option;</t> <t>the message includes a Server Identifier option;</t>
</li> </li>
<li> <li>
<t>the message does not include the IA Address option, or the IP a <t>the message does not include the IA Address option, or the IP
ddress in the IA Address option does not match the source address of the origina address in the IA Address option does not match the source
l ADDR-REG-INFORM message sent by the client. The source address of the original address of the original ADDR-REG-INFORM message sent by the
message is the source IP address of the packet if it is not relayed, or the Pee client. The source address of the original message is the source
r-Address field of the innermost Relay-Forward message if it is relayed.</t> IP address of the packet if it is not relayed or is the
peer-address field of the innermost Relay-forward message if it
is relayed; or</t>
</li> </li>
<li> <li>
<t>the message includes an Option Request Option.</t> <t>the message includes an Option Request option.</t>
</li> </li>
</ul> </ul>
<t>If the message is not discarded, the address registration server <b
cp14>SHOULD</bcp14> verify that the address being registered is "appropriate to <t>If the message is not discarded, the address registration server
the link" as defined by <xref target="RFC8415"/> or within a prefix delegated to <bcp14>SHOULD</bcp14> verify that the address being registered is
the client via DHCPv6-PD (see Section 6.3 of <xref target="RFC8415"/>). If the "appropriate to the link" as defined by <xref target="RFC8415"/> or
address being registered fails this verification, the server <bcp14>MUST</bcp14> within a prefix delegated to the client via DHCPv6 for Prefix
drop the message, and <bcp14>SHOULD</bcp14> log this fact. If the message passe Delegation (DHCPv6-PD) (see <xref target="RFC8415"
s the verification, the server:</t> sectionFormat="of" section="6.3"/>). If the address being registered
fails this verification, the server <bcp14>MUST</bcp14> drop the
message and <bcp14>SHOULD</bcp14> log this fact. If the message
passes the verification, the server:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t><bcp14>MUST</bcp14> log the address registration information (a <t><bcp14>MUST</bcp14> log the address registration information
s is done normally for clients to which it has assigned an address), unless conf (as is done normally for clients to which it has assigned an
igured not to do so. The server <bcp14>SHOULD</bcp14> log the client DUID and th address), unless it is configured not to do so. The server
e link-layer address, if available. The server <bcp14>MAY</bcp14> log any other <bcp14>SHOULD</bcp14> log the client DHCP Unique Identifier
information.</t> (DUID) and the link-layer address, if available. The server
<bcp14>MAY</bcp14> log any other information.</t>
</li> </li>
<li> <li>
<t><bcp14>SHOULD</bcp14> register a binding between the provided C <t><bcp14>SHOULD</bcp14> register a binding between the provided
lient Identifier and IPv6 address in its database, if no binding exists. The lif Client Identifier and IPv6 address in its database, if no
etime of the binding is equal to the Valid Lifetime of the address reported by t binding exists. The lifetime of the binding is equal to the
he client. If there is already a binding between the registered address and the Valid Lifetime of the address reported by the client. If there
same client, the server <bcp14>MUST</bcp14> update its lifetime. If there is alr is already a binding between the registered address and the same
eady a binding between the registered address and another client, the server <bc client, the server <bcp14>MUST</bcp14> update its lifetime. If
p14>SHOULD</bcp14> log the fact and update the binding.</t> there is already a binding between the registered address and
another client, the server <bcp14>SHOULD</bcp14> log the fact
and update the binding.</t>
</li> </li>
<li> <li>
<t><bcp14>SHOULD</bcp14> mark the address as unavailable for use a <t><bcp14>SHOULD</bcp14> mark the address as unavailable for use
nd not include it in future ADVERTISE messages.</t> and not include it in future ADVERTISE messages.</t>
</li> </li>
<li> <li>
<t><bcp14>MUST</bcp14> send back an ADDR-REG-REPLY message to ensu <t><bcp14>MUST</bcp14> send back an ADDR-REG-REPLY message to
re the client does not retransmit.</t> ensure the client does not retransmit.</t>
</li> </li>
</ul> </ul>
<t>If a client is multihomed (connected to multiple administrative dom
ains, each operating its own DHCPv6 infrastructure), the requirement to verify t <!-- [rfced] FYI - We have added "i.e.," to the parenthetical text below for
hat the registered address is appropriate for the link or belongs to a delegate clarity. Please review and let us know if this changes your meaning.
d prefix ensures that each DHCPv6 server only registers bindings for addresses f
rom the given administrative domain.</t> Original:
<t>Although a client "<bcp14>MUST NOT</bcp14> send the ADDR-REG-INFORM If a client is multihomed (connected to multiple administrative
message for addresses configured by DHCPv6", if a server does receive such a me domains, each operating its own DHCPv6 infrastructure), the
ssage, it <bcp14>SHOULD</bcp14> log and discard it.</t> requirement to verify that the registered address is appropriate...
<t>DHCPv6 relay agents and switches that relay address registration me
ssages directly from clients <bcp14>MUST</bcp14> include the client's link-layer Current:
address in the relayed message using the Client Link-Layer Address option (<xre If a client is multihomed (i.e., connected to multiple administrative
f target="RFC6939"/>) if they would do so for other DHCPv6 client messages such domains, each operating its own DHCPv6 infrastructure), the requirement to
as SOLICIT, REQUEST, and REBIND.</t> verify that the registered address is appropriate...
-->
<t>If a client is multihomed (i.e., connected to multiple administrati
ve
domains, each operating its own DHCPv6 infrastructure), the
requirement to verify that the registered address is appropriate for
the link or belongs to a delegated prefix ensures that each DHCPv6
server only registers bindings for addresses from the given
administrative domain.</t>
<!-- [rfced] We note that this quotation below appears earlier in this
document, so we have updated to include a pointer to give the reader
additional context. Please review.
Original:
Although a client "MUST NOT send the ADDR-REG-INFORM message for
addresses configured by DHCPv6", if a server does receive such a
message, it SHOULD log and discard it.
Current:
As mentioned in Section 4.2, although a client "MUST NOT send the
ADDR-REG-INFORM message for addresses configured by DHCPv6", if a
server does receive such a message, it SHOULD log and discard it.
-->
<t>As mentioned in <xref
target="dhcpv6-address-registration-request-message"/>, although a
client "<bcp14>MUST NOT</bcp14> send the ADDR-REG-INFORM message for
addresses configured by DHCPv6", if a server does receive such a
message, it <bcp14>SHOULD</bcp14> log and discard it.</t>
<t>DHCPv6 relay agents and switches that relay address registration
messages directly from clients <bcp14>MUST</bcp14> include the
client's link-layer address in the relayed message using the Client
Link-Layer Address option <xref target="RFC6939"/> if they would
do so for other DHCPv6 client messages such as SOLICIT, REQUEST, and
REBIND.</t>
</section> </section>
</section> </section>
<section anchor="dhcpv6-address-registration-acknowledgement"> <section anchor="dhcpv6-address-registration-acknowledgement">
<name>DHCPv6 Address Registration Acknowledgement</name> <name>DHCPv6 Address Registration Acknowledgement</name>
<t>The server <bcp14>MUST</bcp14> acknowledge receipt of a valid ADDR-RE
G-INFORM message by sending back an ADDR-REG-REPLY message. The format of the AD <t>The server <bcp14>MUST</bcp14> acknowledge receipt of a valid
DR-REG-REPLY message is described as follows:</t> ADDR-REG-INFORM message by sending back an ADDR-REG-REPLY message. The
<artwork><![CDATA[ format of the ADDR-REG-REPLY message is described as follows:</t>
<figure anchor="Fig.4">
<name>DHCPv6 ADDR-REG-REPLY Message</name>
<artwork><![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) . . (variable) .
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
msg-type Identifies the DHCPv6 message type; ]]></artwork>
Set to ADDR-REG-REPLY (TBA2). </figure>
transaction-id The transaction ID for this message exchange. <dl>
<dt>msg-type:</dt><dd>Identifies the DHCPv6 message type; set to ADDR-REG-REPL
Y (37).</dd>
<dt>transaction-id:</dt><dd>The transaction ID for this message exchange.</dd>
<dt>options:</dt><dd>The options carried in this message.</dd>
</dl>
<t>If the ADDR-REG-INFORM message that the server is replying to was
not relayed, then the IPv6 destination address of the message
<bcp14>MUST</bcp14> be the address being registered. If the
ADDR-REG-INFORM message was relayed, then the server
<bcp14>MUST</bcp14> construct the Relay-reply message as specified in
<xref target="RFC8415" sectionFormat="of" section="19.3"/>.</t>
<t>The server <bcp14>MUST</bcp14> copy the transaction-id from the
ADDR-REG-INFORM message to the transaction-id field of the
ADDR-REG-REPLY.</t>
<t>The ADDR-REG-REPLY message <bcp14>MUST</bcp14> contain an IA
Address option for the address being registered. The option
<bcp14>MUST</bcp14> be identical to the one in the ADDR-REG-INFORM
message that the server is replying to.</t>
<t>Servers <bcp14>MUST</bcp14> ignore any received ADDR-REG-REPLY
messages.</t>
<t>Clients <bcp14>MUST</bcp14> discard any ADDR-REG-REPLY messages
that meet any of the following conditions:</t>
options Options carried in this message.
]]></artwork>
<t>Figure 4: DHCPv6 ADDR-REG-REPLY message</t>
<t>If the ADDR-REG-INFORM message that the server is replying to was not
relayed, then the IPv6 destination address of the message <bcp14>MUST</bcp14> b
e the address being registered. If the ADDR-REG-INFORM message was relayed, then
the server <bcp14>MUST</bcp14> construct the Relay-reply message as specified i
n <xref target="RFC8415"/> section 19.3.</t>
<t>The server <bcp14>MUST</bcp14> copy the transaction-id from the ADDR-
REG-INFORM message to the transaction-id field of the ADDR-REG-REPLY.</t>
<t>The ADDR-REG-REPLY message <bcp14>MUST</bcp14> contain an IA Address
option for the address being registered. The option <bcp14>MUST</bcp14> be ident
ical to the one in the ADDR-REG-INFORM message that the server is replying to.</
t>
<t>Servers <bcp14>MUST</bcp14> ignore any received ADDR-REG-REPLY messag
es.</t>
<t>Clients <bcp14>MUST</bcp14> discard any ADDR-REG-REPLY messages that
meet any of the following conditions:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>The IPv6 destination address does not match the address being reg istered.</t> <t>the IPv6 destination address does not match the address being reg istered;</t>
</li> </li>
<li> <li>
<t>The IA Address option does not match the address being registered .</t> <t>the IA Address option does not match the address being registered ;</t>
</li> </li>
<li> <li>
<t>The address being registered is not assigned to the interface rec eiving the message.</t> <t>the address being registered is not assigned to the interface rec eiving the message; or</t>
</li> </li>
<li> <li>
<t>The transaction-id does not match the transaction-id the client u sed in the corresponding ADDR-REG-INFORM message.</t> <t>the transaction-id does not match the transaction-id the client u sed in the corresponding ADDR-REG-INFORM message.</t>
</li> </li>
</ul> </ul>
<t>The ADDR-REG-REPLY message only indicates that the ADDR-REG-INFORM me
ssage has been received and that the client should not retransmit it. The ADDR-R <t>The ADDR-REG-REPLY message only indicates that the ADDR-REG-INFORM
EG-REPLY message <bcp14>MUST NOT</bcp14> be considered as any indication of the message has been received and that the client should not retransmit
address validity and <bcp14>MUST NOT</bcp14> be required for the address to be u it. The ADDR-REG-REPLY message <bcp14>MUST NOT</bcp14> be considered
sable. DHCPv6 relays, or other devices that snoop ADDR-REG-REPLY messages, <bcp1 to be any indication of the address validity and <bcp14>MUST NOT</bcp14>
4>MUST NOT</bcp14> add or alter any forwarding or security state based on the AD be required for the address to be usable. DHCPv6 relays, or other
DR-REG-REPLY message.</t> devices that snoop ADDR-REG-REPLY messages, <bcp14>MUST NOT</bcp14>
add or alter any forwarding or security state based on the
ADDR-REG-REPLY message.</t>
</section> </section>
<section anchor="signaling-address-registration-support"> <section anchor="signaling-address-registration-support">
<name>Signaling Address Registration Support</name> <name>Signaling Address Registration Support</name>
<t>To avoid undesired multicast traffic, the client <bcp14>MUST NOT</bcp
14> register addresses using this mechanism unless the DHCPv6 infrastructure sup <t>To avoid undesired multicast traffic, the client <bcp14>MUST
ports address registration. The client can discover this by including using the NOT</bcp14> register addresses using this mechanism unless the DHCPv6
OPTION_ADDR_REG_ENABLE option in the Option Request options that it sends. If th infrastructure supports address registration. The client can discover
e client receives and processes an Advertise or Reply message with the OPTION_AD this by including using the OPTION_ADDR_REG_ENABLE option in the
DR_REG_ENABLE option, it concludes that the DHCPv6 infrastructure supports addre Option Request options that it sends. If the client receives and
ss registration. When the client detects address registration support, it <bcp14 processes an Advertise or Reply message with the
>MUST</bcp14> start the registration process (unless configured not to do so) an OPTION_ADDR_REG_ENABLE option, it concludes that the DHCPv6
d <bcp14>MUST</bcp14> immediately register any addresses that are already in use infrastructure supports address registration. When the client detects
. Once the client starts the registration process, it <bcp14>MUST NOT</bcp14> st address registration support, it <bcp14>MUST</bcp14> start the
op registering addresses until it disconnects from the link, even if subsequent registration process (unless configured not to do so) and
Advertise or Reply messages do not contain the OPTION_ADDR_REG_ENABLE option.</t <bcp14>MUST</bcp14> immediately register any addresses that are
> already in use. Once the client starts the registration process, it
<t>The client <bcp14>MUST</bcp14> discover whether the DHCPv6 infrastruc <bcp14>MUST NOT</bcp14> stop registering addresses until it
ture supports address registration every time it connects to a network or when i disconnects from the link, even if subsequent Advertise or Reply
t detects it has moved to a new link, without utilizing any prior knowledge abou messages do not contain the OPTION_ADDR_REG_ENABLE option.</t>
t address registration support on that network or link. This client behavior all
ows networks to progressively roll out support for the address registration opti <t>The client <bcp14>MUST</bcp14> discover whether the DHCPv6
on across the DHCPv6 infrastructure without causing clients to frequently stop a infrastructure supports address registration every time it connects to
nd restart address registration if some of the network's DHCPv6 servers support a network or when it detects it has moved to a new link, without
it and some of them do not.</t> utilizing any prior knowledge about address registration support on
<t>A client with multiple interfaces <bcp14>MUST</bcp14> discover addres that network or link. This client behavior allows networks to
s registration support for each interface independently. The client <bcp14>MUST progressively roll out support for the Address Registration option
NOT</bcp14> send address registration messsages on a given interface unless the across the DHCPv6 infrastructure without causing clients to frequently
client has discovered that the interface is connected to a network which support stop and restart address registration if some of the network's DHCPv6
s address registration.</t> servers support it and some do not.</t>
<t>A client with multiple interfaces <bcp14>MUST</bcp14> discover
address registration support for each interface independently. The
client <bcp14>MUST NOT</bcp14> send address registration messages on
a given interface unless the client has discovered that the interface
is connected to a network that supports address registration.</t>
</section> </section>
<!-- [rfced] Please review the text below. How may we reformat for clarity and
to expand IRT and MRC as they appear in RFC 8415?
Original:
Retransmissions SHOULD follow the standard retransmission logic specified
by section 15 of [RFC8415] with the following default parameters:
* IRT 1 sec
* MRC 3
Perhaps:
Retransmissions SHOULD follow the standard retransmission logic specified
by Section 15 of [RFC8415] with the following default parameters for the
initial retransmission time (IRT) and maximum retransmission count (MRC):
* IRT is 1 sec
* MRC is 3
-->
<section anchor="retransmission"> <section anchor="retransmission">
<name>Retransmission</name> <name>Retransmission</name>
<t>To reduce the effects of packet loss on registration, the client <bcp 14>MUST</bcp14> retransmit the registration message. Retransmissions <bcp14>SHOU LD</bcp14> follow the standard retransmission logic specified by section 15 of < xref target="RFC8415"/> with the following default parameters:</t> <t>To reduce the effects of packet loss on registration, the client <bcp 14>MUST</bcp14> retransmit the registration message. Retransmissions <bcp14>SHOU LD</bcp14> follow the standard retransmission logic specified by <xref target="R FC8415" sectionFormat="of" section="15"/> with the following default parameters: </t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>IRT 1 sec</t> <t>IRT 1 sec</t>
</li> </li>
<li> <li>
<t>MRC 3</t> <t>MRC 3</t>
</li> </li>
</ul> </ul>
<t>The client <bcp14>SHOULD</bcp14> allow these parameters to be configu red by the administrator.</t> <t>The client <bcp14>SHOULD</bcp14> allow these parameters to be configu red by the administrator.</t>
<t>To comply with section 16.1 of <xref target="RFC8415"/>, the client < bcp14>MUST</bcp14> leave the transaction ID unchanged in retransmissions of an A DDR-REG-INFORM message. When the client retransmits the registration message, th e lifetimes in the packet <bcp14>MUST</bcp14> be updated so that they match the current lifetimes of the address.</t> <t>To comply with <xref target="RFC8415" sectionFormat="of" section="16. 1"/>, the client <bcp14>MUST</bcp14> leave the transaction ID unchanged in retra nsmissions of an ADDR-REG-INFORM message. When the client retransmits the regist ration message, the lifetimes in the packet <bcp14>MUST</bcp14> be updated so th at they match the current lifetimes of the address.</t>
<t>If an ADDR-REG-REPLY message is received for the address being regist ered, the client <bcp14>MUST</bcp14> stop retransmission.</t> <t>If an ADDR-REG-REPLY message is received for the address being regist ered, the client <bcp14>MUST</bcp14> stop retransmission.</t>
</section> </section>
<section anchor="registration-expiry-and-refresh"> <section anchor="registration-expiry-and-refresh">
<name>Registration Expiry and Refresh</name> <name>Registration Expiry and Refresh</name>
<t>The client <bcp14>MUST</bcp14> refresh registrations to ensure that t he server is always aware of which addresses are still valid. The client <bcp14> SHOULD</bcp14> perform refreshes as described below.</t> <t>The client <bcp14>MUST</bcp14> refresh registrations to ensure that t he server is always aware of which addresses are still valid. The client <bcp14> SHOULD</bcp14> perform refreshes as described below.</t>
<section anchor="slaac-addresses"> <section anchor="slaac-addresses">
<name>SLAAC Addresses</name> <name>SLAAC Addresses</name>
<t>For an address configured using SLAAC, a function AddrRegRefreshInt
erval(address) is defined as 80% of the address's current Valid Lifetime. When c <t>For an address configured using SLAAC, a function
alculating this value, the client applies a multiplier of AddrRegDesyncMultiplie AddrRegRefreshInterval(address) is defined as 80% of the address's
r to avoid synchronization causing a large number of registration messages from current Valid Lifetime. When calculating this value, the client
different clients at the same time. AddrRegDesyncMultiplier is a random value un applies a multiplier of AddrRegDesyncMultiplier to avoid
iformly distributed between 0.9 and 1.1 (inclusive) and is chosen by the client synchronization, causing a large number of registration messages
when it starts the registration process, to ensure that refreshes for addresses from different clients at the same time. AddrRegDesyncMultiplier is
with the same lifetime are coalesced (see below).</t> a random value uniformly distributed between 0.9 and 1.1 (inclusive)
<t>Whenever the client registers or refreshes an address, it calculate and is chosen by the client when it starts the registration process
s a NextAddrRegRefreshTime for that address as AddrRegRefreshInterval seconds in to ensure that refreshes for addresses with the same lifetime are
the future but does not schedule any refreshes.</t> coalesced (see below).</t>
<t>Whenever the network changes the Valid Lifetime of an existing addr
ess by more than 1%, for example, by sending a Prefix Information option (PIO, < <t>Whenever the client registers or refreshes an address, it
xref target="RFC4861"/>) with a new Valid Lifetime, the client calculates a new calculates a NextAddrRegRefreshTime for that address as
AddrRegRefreshInterval. The client schedules a refresh for min(now + AddrRegRefr AddrRegRefreshInterval seconds in the future but does not schedule
eshInterval, NextAddrRegRefreshTime). If the refresh would be scheduled in the p any refreshes.</t>
ast, then the refresh occurs immediately.</t>
<t>Justification: this algorithm ensures that refreshes are not sent t <t>Whenever the network changes the Valid Lifetime of an existing
oo frequently, while ensuring that the server never believes that the address ha address by more than 1%, for example, by sending a Prefix
s expired when it has not. Specifically, after every registration:</t> Information Option (PIO) <xref target="RFC4861"/> with a new Valid
Lifetime, the client calculates a new AddrRegRefreshInterval. The
client schedules a refresh for min(now + AddrRegRefreshInterval,
NextAddrRegRefreshTime). If the refresh would be scheduled in the
past, then the refresh occurs immediately.</t>
<t>Justification: This algorithm ensures that refreshes
are not sent too frequently while ensuring that the server never
believes that the address has expired when it has not. Specifically,
after every registration:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>If the network never changes the lifetime of an address (e.g., <t>If the network never changes the lifetime of an address
if no further PIOs are received, or if all PIO lifetimes decrease in step with t (e.g., if no further PIOs are received, or if all PIO lifetimes
he passage of time), then no refreshes occur. Refreshes are not necessary, becau decrease in step with the passage of time), then no refreshes
se the address expires at the time the server expects it to expire.</t> occur. Refreshes are not necessary, because the address expires
at the time the server expects it to expire.</t>
</li> </li>
<li> <li>
<t>Any time the network changes the lifetime of an address (i.e., <t>Any time the network changes the lifetime of an address
changes the time at which the address will expire) the client ensures that a ref (i.e., changes the time at which the address will expire), the
resh is scheduled, so that server will be informed of the new expiry.</t> client ensures that a refresh is scheduled, so that server will
be informed of the new expiry.</t>
</li> </li>
<li> <li>
<t>Because AddrRegDesyncMultiplier is at most 1.1, the refresh nev <t>Because AddrRegDesyncMultiplier is at most 1.1, the refresh
er occurs later than a point 88% between the time when the address was registere never occurs later than a point 88% between the time when the
d and the time when the address will expire. This allows the client to retransmi address was registered and the time when the address will
t the registration for up to 12% of the original interval before it expires. Thi expire. This allows the client to retransmit the registration
s may not be possible if the network sends a Router Advertisement (RA, <xref tar for up to 12% of the original interval before it expires. This
get="RFC4861"/>) very close to the time when the address would have expired. In may not be possible if the network sends a Router Advertisement
this case, the client refreshes immediately, which is the best it can do.</t> (RA) <xref target="RFC4861"/> very close to the time when the
address would have expired. In this case, the client refreshes
immediately, which is the best it can do.</t>
</li> </li>
<li> <li>
<t>The 1% tolerance ensures that the client will not refresh or re <t>The 1% tolerance ensures that the client will not refresh or
schedule refreshes if the Valid Lifetime experiences minor changes due to transm reschedule refreshes if the Valid Lifetime experiences minor
ission delays or clock skew between the client and the router(s) sending the Rou changes due to transmission delays or clock skew between the
ter Advertisement.</t> client and the router(s) sending the RA.</t>
</li> </li>
<li> <li>
<t>AddrRegRefreshCoalesce (Section 4.6.3) allows battery-powered c <t>AddrRegRefreshCoalesce (<xref
lients to wake up less often. In particular, it allows the client to coalesce re target="transmitting-refreshes"/>) allows battery-powered
freshes for multiple addresses formed from the same prefix, such as the stable a clients to wake up less often. In particular, it allows the
nd privacy addresses. Higher values will result in fewer wakeups, but may result client to coalesce refreshes for multiple addresses formed from
in more network traffic, because if a refresh is sent early, then the next RA r the same prefix, such as the stable and privacy
eceived will cause the client to immediately send a refresh message.</t> addresses. Higher values will result in fewer wakeups but may
result in more network traffic, because if a refresh is sent
early, then the next RA received will cause the client to
immediately send a refresh message.</t>
</li> </li>
<li> <li>
<t>In typical networks, the lifetimes in periodic Router Advertise <t>In typical networks, the lifetimes in periodic RAs either conta
ments either contain constant values, or values that decrease over time to match in constant values or values that
another lifetime, such as the lifetime of a prefix delegated to the network. In decrease over time to match another lifetime, such as the
both these cases, this algorithm will refresh on the order of once per address lifetime of a prefix delegated to the network. In both these
lifetime, which is similar to the number of refreshes that are necessary using s cases, this algorithm will refresh on the order of once per
tateful DHCPv6.</t> address lifetime, which is similar to the number of refreshes
that are necessary using stateful DHCPv6.</t>
</li> </li>
<li> <li>
<t>Because refreshes occur at least once per address lifetime, the <t>Because refreshes occur at least once per address lifetime,
network administrator can control the address refresh frequency by appropriatel the network administrator can control the address refresh
y setting the Valid Lifetime in the Prefix Information Option.</t> frequency by appropriately setting the Valid Lifetime in the
PIO.</t>
</li> </li>
</ul> </ul>
</section> </section>
<section anchor="statically-assigned-addresses"> <section anchor="statically-assigned-addresses">
<name>Statically Assigned Addresses</name> <name>Statically Assigned Addresses</name>
<t>A statically assigned address has an infinite valid lifetime which <t>A statically assigned address has an infinite Valid Lifetime
is not affected by Router Advertisements. Therefore whenever the client register that is not affected by RAs. Therefore, whenever
s or refreshes a statically assigned address, the next refresh is scheduled for the client registers or refreshes a statically assigned address, the
StaticAddrRegRefreshInterval seconds in the future. The default value of StaticA next refresh is scheduled for StaticAddrRegRefreshInterval seconds
ddrRegRefreshInterval is 4 hours. This ensures static addresses are still refres in the future. The default value of StaticAddrRegRefreshInterval is
hed periodically, but refreshes for static addresses do not cause excessive mult 4 hours. This ensures static addresses are still refreshed
icast traffic. The StaticAddrRegRefreshInterval interval <bcp14>SHOULD</bcp14> b periodically, but refreshes for static addresses do not cause
e configurable.</t> excessive multicast traffic. The StaticAddrRegRefreshInterval
interval <bcp14>SHOULD</bcp14> be configurable.</t>
</section> </section>
<section anchor="transmitting-refreshes"> <section anchor="transmitting-refreshes">
<name>Transmitting Refreshes</name> <name>Transmitting Refreshes</name>
<t>When a refresh is performed, the client <bcp14>MAY</bcp14> refresh <t>When a refresh is performed, the client <bcp14>MAY</bcp14>
all addresses assigned to the interface that are scheduled to be refreshed withi refresh all addresses assigned to the interface that are scheduled
n the next AddrRegRefreshCoalesce seconds. The value of AddrRegRefreshCoalesce i to be refreshed within the next AddrRegRefreshCoalesce seconds. The
s implementation-dependent, and a suggested default is 60 seconds.</t> value of AddrRegRefreshCoalesce is implementation dependent, and a
<t>Registration refresh packets <bcp14>MUST</bcp14> be retransmitted u suggested default is 60 seconds.</t>
sing the same logic as used for initial registrations (see the 'Retransmission'
section above).</t> <t>Registration refresh packets <bcp14>MUST</bcp14> be retransmitted
<t>The client <bcp14>MUST</bcp14> generate a new transaction ID when r using the same logic as used for initial registrations (see <xref
efreshing the registration.</t> target="retransmission"/>).</t>
<t>When a Client-Identifier-to-IPv6-address binding expires, the serve
r <bcp14>MUST</bcp14> remove it and consider the address as available for use.</ <t>The client <bcp14>MUST</bcp14> generate a new transaction ID when
t> refreshing the registration.</t>
<t>The client <bcp14>MAY</bcp14> choose to notify the server when an a
ddress is no longer being used (e.g., if the client is disconnecting from the ne <t>When a Client-Identifier-to-IPv6-address binding expires, the
twork, the address lifetime expired, or the address is being removed from the in server <bcp14>MUST</bcp14> remove it and consider the address as
terface). To indicate that the address is not being used anymore the client <bcp available for use.</t>
14>MUST</bcp14> set the preferred-lifetime and valid-lifetime fields of the IA A
ddress option in the ADDR-REG-INFORM message to zero. If the server receives a m <t>The client <bcp14>MAY</bcp14> choose to notify the server when an
essage with a valid-lifetime of zero, it <bcp14>MUST</bcp14> act as if the addre address is no longer being used (e.g., if the client is
ss has expired.</t> disconnecting from the network, the address lifetime expired, or the
address is being removed from the interface). To indicate that the
address is not being used anymore, the client <bcp14>MUST</bcp14> set
the preferred-lifetime and valid-lifetime fields of the IA Address
option in the ADDR-REG-INFORM message to zero. If the server
receives a message with a valid-lifetime of zero, it
<bcp14>MUST</bcp14> act as if the address has expired.</t>
</section> </section>
</section> </section>
</section> </section>
<section anchor="client-configuration"> <section anchor="client-configuration">
<name>Client configuration</name> <name>Client Configuration</name>
<t>DHCP clients <bcp14>SHOULD</bcp14> allow the administrator to disable s <t>DHCP clients <bcp14>SHOULD</bcp14> allow the administrator to disable
ending ADDR-REG-INFORM messages. This could be used, for example, to reduce netw sending ADDR-REG-INFORM messages. This could be used, for example, to
ork traffic on networks where the servers are known not to support the message t reduce network traffic on networks where the servers are known not to
ype. Sending the messages <bcp14>SHOULD</bcp14> be enabled by default.</t> support the message type. Sending the messages <bcp14>SHOULD</bcp14> be
enabled by default.</t>
</section> </section>
<section anchor="security-considerations"> <section anchor="security-considerations">
<name>Security Considerations</name> <name>Security Considerations</name>
<t>An attacker may attempt to register a large number of addresses in quic <t>An attacker may attempt to register a large number of addresses in
k succession in order to overwhelm the address registration server and / or fill quick succession in order to overwhelm the address registration server
up log files. Similar attack vectors exist today, e.g., an attacker can DoS the and/or fill up log files. Similar attack vectors exist today, e.g., an
server with messages containing spoofed DHCP Unique Identifiers (DUIDs) <xref t attacker can DoS the server with messages containing spoofed DHCP Unique
arget="RFC8415"/>.</t> Identifiers (DUIDs) <xref target="RFC8415"/>.</t>
<t>If a network is using FCFS SAVI <xref target="RFC6620"/>, then the DHCP
v6 server can trust that the ADDR-REG-INFORM message was sent by the legitimate <t>If a network is using First-Come, First-Served Source Address
holder of the address. This prevents a client from registering an address config Validation Improvement (FCFS SAVI) <xref target="RFC6620"/>, then the
ured on another client.</t> DHCPv6 server can trust that the ADDR-REG-INFORM message was sent by the
<t>One of the use cases for the mechanism described in this document is to legitimate holder of the address. This prevents a client from
identify sources of malicious traffic after the fact. Note, however, that as th registering an address configured on another client.</t>
e device itself is responsible for informing the DHCPv6 server that it is using
an address, a malicious or compromised device can simply not send the ADDR-REG-I <t>One of the use cases for the mechanism described in this document is
NFORM message. This is an informational, optional mechanism, and is designed to to identify sources of malicious traffic after the fact. Note, however,
aid in troubleshooting and forensics. On its own, it is not intended to be a str that as the device itself is responsible for informing the DHCPv6 server
ong security access mechanism. that it is using an address, a malicious or compromised device cannot simp
In particular, the ADDR-REG-INFORM message <bcp14>MUST NOT</bcp14> be used for a ly
uthentication and authorization purposes, because in addition to the reasons abo send the ADDR-REG-INFORM message. This is an informational,
ve, the packets containing the message may be dropped.</t> optional mechanism and is designed to aid in troubleshooting and
forensics. On its own, it is not intended to be a strong security access
mechanism. In particular, the ADDR-REG-INFORM message <bcp14>MUST
NOT</bcp14> be used for authentication and authorization purposes,
because in addition to the reasons above, the packets containing the
message may be dropped.</t>
</section> </section>
<section anchor="privacy-considerations"> <section anchor="privacy-considerations">
<name>Privacy Considerations</name> <name>Privacy Considerations</name>
<t>If the network doesn't have MLD snooping enabled, then IPv6 link-local <t>If the network doesn't have Multicast Listener Discovery (MLD) snooping
multicast traffic is effectively transmitted as broadcast. enabled, then IPv6
In such networks, an on-link attacker listening to DHCPv6 messages might obtain link-local multicast traffic is effectively transmitted as broadcast.
information about IPv6 addresses assigned to the client. In such networks, an on-link attacker listening to DHCPv6 messages might
As ADDR-REG-INFORM messages contain unique identifiers such as the client's DUID obtain information about IPv6 addresses assigned to the client. As
, the attacker may be able to track addresses being registered and map them to t ADDR-REG-INFORM messages contain unique identifiers such as the client's
he same client, even if the client uses randomized MAC addresses. DUID, the attacker may be able to track addresses being registered and
This privacy consideration is not specific to the proposed mechanism. Section 4. map them to the same client, even if the client uses randomized MAC
3 of <xref target="RFC7844"/> discusses using the DUID for device tracking in DH addresses. This privacy consideration is not specific to the proposed
CPv6 environments and provides mitigation recommendations.</t> mechanism. <xref target="RFC7844" sectionFormat="of" section="4.3"/>
<t>In general, hiding information about the specific IPv6 address from on- discusses using the DUID for device tracking in DHCPv6 environments and
link observers should not be considered a security measure, as such information provides mitigation recommendations.</t>
is usually disclosed via Duplicate Address Detection <xref target="RFC4862"/> to
all nodes anyway, if MLD snooping is not enabled.</t> <t>In general, hiding information about the specific IPv6 address from
<t>If MLD snooping is enabled, an attacker might be able to join the All_D on-link observers should not be considered a security measure, as such
HCP_Relay_Agents_and_Servers multicast address (ff02::1:2) group to listen for a information is usually disclosed via Duplicate Address Detection <xref
ddress registration messages. target="RFC4862"/> to all nodes anyway, if MLD snooping is not
However, the same result can be achieved by joining the All Routers Address (ff0 enabled.</t>
2::2) group and listen to Gratuitous Neighbor Advertisement messages <xref targe
t="RFC9131"/>. It should be noted that this particular scenario shares the fate <t>If MLD snooping is enabled, an attacker might be able to join the
with DHCPv6 address assignment: if an attacker can join the All_DHCP_Relay_Agent All_DHCP_Relay_Agents_and_Servers multicast address (ff02::1:2) group to
s_and_Servers multicast group, they would be able to monitor all DHCPv6 messages listen for address registration messages. However, the same result can
sent from the client to DHCPv6 servers and relays, and therefore obtain the inf be achieved by joining the All Routers Address (ff02::2) group and
ormation about addresses being assigned via DHCPv6. listen to gratuitous neighbor advertisement messages <xref
Layer 2 isolation allows mitigating this threat by blocking onlink peer-to-peer target="RFC9131"/>. It should be noted that this particular scenario
communication between nodes.</t> shares the fate with DHCPv6 address assignment: if an attacker can join
the All_DHCP_Relay_Agents_and_Servers multicast group, they would be
able to monitor all DHCPv6 messages sent from the client to DHCPv6
servers and relays and therefore obtain the information about addresses
being assigned via DHCPv6. Layer 2 isolation allows mitigating this
threat by blocking on-link peer-to-peer communication between nodes.</t>
</section> </section>
<section anchor="iana-considerations"> <section anchor="iana-considerations">
<name>IANA Considerations</name> <name>IANA Considerations</name>
<t>This document introduces the following new entities which require an al
location out of the Dynamic Host Configuration Protocol for IPv6 (DHCPv6) regist <!-- [rfced] FYI - We have updated the IANA Considerations section to match
ry group defined at http://www.iana.org/assignments/dhcpv6-parameters/:</t> the registry. Please review and let us know if any further changes are needed.
-->
<t>This document introduces the following entities, which have been
allocated in the "Dynamic Host Configuration Protocol for IPv6
(DHCPv6)" registry group defined at
<eref target="http://www.iana.org/assignments/dhcpv6-parameters" brackets=
"angle"/>. These include:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>one new DHCPv6 option, described in Section 4.1 which requires an a <t>One new DHCPv6 option, described in <xref
llocation out of the Option Codes registry: target="dhcpv6-address-registration-option"/>, which has been
allocated in the "Option Codes" registry:
</t> </t>
<ul spacing="normal"> <dl newline="false" spacing="compact">
<li> <dt>Value:</dt> <dd>148</dd>
<t>Value: TBA0</t> <dt>Description:</dt> <dd>OPTION_ADDR_REG_ENABLE</dd>
</li> <dt>Client ORO:</dt> <dd>Yes</dd>
<li> <dt>Singleton Option:</dt> <dd>Yes</dd>
<t>Description: OPTION_ADDR_REG_ENABLE</t> <dt>Reference:</dt> <dd>RFC 9686</dd>
</li> </dl>
<li>
<t>Client ORO: Yes</t>
</li>
<li>
<t>Singleton Option: Yes</t>
</li>
<li>
<t>Reference: This document (draft-ietf-dhc-addr-notification)</t>
</li>
</ul>
</li> </li>
<li> <li>
<t>two new DHCPv6 messages which require an allocation out of the Mess age Types registry: <t>Two new DHCPv6 messages, which have been allocated in the "Message Types" registry (for more information, see Sections <xref target="dhcpv6-address -registration-request-message" format="counter"/> and <xref target="dhcpv6-addr ess-registration-acknowledgement" format="counter"/>, respectively, for each DHC Pv6 message):
</t> </t>
<ul spacing="normal"> <dl newline="false" spacing="compact">
<li> <dt>Value:</dt><dd>36</dd>
<t>ADDR-REG-INFORM message (TBA1) described in Section 4.2</t> <dt>Description:</dt><dd>ADDR-REG-INFORM</dd>
</li> <dt>Reference:</dt><dd>RFC 9686</dd>
<li> </dl>
<t>ADDR-REG-REPLY (TBA2) described in Section 4.3.</t>
</li> <dl newline="false" spacing="compact">
<li> <dt>Value:</dt><dd>37</dd>
<t>Reference: This document (draft-ietf-dhc-addr-notification)</t> <dt>Description:</dt><dd>ADDR-REG-REPLY</dd>
</li> <dt>Reference:</dt><dd>RFC 9686</dd>
</ul> </dl>
</li> </li>
</ul> </ul>
</section> </section>
</middle> </middle>
<back> <back>
<references> <references>
<name>References</name> <name>References</name>
<references anchor="sec-normative-references"> <references anchor="sec-normative-references">
<name>Normative References</name> <name>Normative References</name>
<reference anchor="RFC2119"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.21
<front> 19.xml"/>
<title>Key words for use in RFCs to Indicate Requirement Levels</tit <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.40
le> 07.xml"/>
<author fullname="S. Bradner" initials="S." surname="Bradner"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.41
<date month="March" year="1997"/> 93.xml"/>
<abstract> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.48
<t>In many standards track documents several words are used to sig 62.xml"/>
nify the requirements in the specification. These words are often capitalized. T <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.69
his document defines these words as they should be interpreted in IETF documents 39.xml"/>
. This document specifies an Internet Best Current Practices for the Internet Co <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.84
mmunity, and requests discussion and suggestions for improvements.</t> 15.xml"/>
</abstract> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.21
</front> 31.xml"/>
<seriesInfo name="BCP" value="14"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.81
<seriesInfo name="RFC" value="2119"/> 74.xml"/>
<seriesInfo name="DOI" value="10.17487/RFC2119"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.47
</reference> 04.xml"/>
<reference anchor="RFC4007"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.78
<front> 44.xml"/>
<title>IPv6 Scoped Address Architecture</title> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.91
<author fullname="S. Deering" initials="S." surname="Deering"/> 31.xml"/>
<author fullname="B. Haberman" initials="B." surname="Haberman"/>
<author fullname="T. Jinmei" initials="T." surname="Jinmei"/>
<author fullname="E. Nordmark" initials="E." surname="Nordmark"/>
<author fullname="B. Zill" initials="B." surname="Zill"/>
<date month="March" year="2005"/>
<abstract>
<t>This document specifies the architectural characteristics, expe
cted behavior, textual representation, and usage of IPv6 addresses of different
scopes. According to a decision in the IPv6 working group, this document intenti
onally avoids the syntax and usage of unicast site-local addresses. [STANDARDS-T
RACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4007"/>
<seriesInfo name="DOI" value="10.17487/RFC4007"/>
</reference>
<reference anchor="RFC4193">
<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. [STAND
ARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4193"/>
<seriesInfo name="DOI" value="10.17487/RFC4193"/>
</reference>
<reference anchor="RFC4862">
<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 i
ncludes generating a link-local address, generating global addresses via statele
ss address autoconfiguration, and the Duplicate Address Detection procedure to v
erify 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="RFC6939">
<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="RFC8415">
<front>
<title>Dynamic Host Configuration Protocol for IPv6 (DHCPv6)</title>
<author fullname="T. Mrugalski" initials="T." surname="Mrugalski"/>
<author fullname="M. Siodelski" initials="M." surname="Siodelski"/>
<author fullname="B. Volz" initials="B." surname="Volz"/>
<author fullname="A. Yourtchenko" initials="A." surname="Yourtchenko
"/>
<author fullname="M. Richardson" initials="M." surname="Richardson"/
>
<author fullname="S. Jiang" initials="S." surname="Jiang"/>
<author fullname="T. Lemon" initials="T." surname="Lemon"/>
<author fullname="T. Winters" initials="T." surname="Winters"/>
<date month="November" year="2018"/>
<abstract>
<t>This document describes the Dynamic Host Configuration Protocol
for IPv6 (DHCPv6): an extensible mechanism for configuring nodes with network c
onfiguration parameters, IP addresses, and prefixes. Parameters can be provided
statelessly, or in combination with stateful assignment of one or more IPv6 addr
esses and/or IPv6 prefixes. DHCPv6 can operate either in place of or in addition
to stateless address autoconfiguration (SLAAC).</t>
<t>This document updates the text from RFC 3315 (the original DHCP
v6 specification) and incorporates prefix delegation (RFC 3633), stateless DHCPv
6 (RFC 3736), an option to specify an upper bound for how long a client should w
ait before refreshing information (RFC 4242), a mechanism for throttling DHCPv6
clients when DHCPv6 service is not available (RFC 7083), and relay agent handlin
g of unknown messages (RFC 7283). In addition, this document clarifies the inter
actions between models of operation (RFC 7550). As such, this document obsoletes
RFC 3315, RFC 3633, RFC 3736, RFC 4242, RFC 7083, RFC 7283, and RFC 7550.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8415"/>
<seriesInfo name="DOI" value="10.17487/RFC8415"/>
</reference>
<reference anchor="RFC2131">
<front>
<title>Dynamic Host Configuration Protocol</title>
<author fullname="R. Droms" initials="R." surname="Droms"/>
<date month="March" year="1997"/>
<abstract>
<t>The Dynamic Host Configuration Protocol (DHCP) provides a frame
work for passing configuration information to hosts on a TCPIP network. DHCP is
based on the Bootstrap Protocol (BOOTP), adding the capability of automatic allo
cation of reusable network addresses and additional configuration options. [STAN
DARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="2131"/>
<seriesInfo name="DOI" value="10.17487/RFC2131"/>
</reference>
<reference anchor="RFC8174">
<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="RFC4704">
<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="RFC7844">
<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 c
an enable device tracking even if the device administrator takes care of randomi
zing other potential identifications like link-layer addresses or IPv6 addresses
. The anonymity profiles are designed for clients that wish to remain anonymous
to the visited network. The profiles provide guidelines on the composition of DH
CP or DHCPv6 messages, designed to minimize disclosure of identifying informatio
n.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7844"/>
<seriesInfo name="DOI" value="10.17487/RFC7844"/>
</reference>
<reference anchor="RFC9131">
<front>
<title>Gratuitous Neighbor Discovery: Creating Neighbor Cache Entrie
s on First-Hop Routers</title>
<author fullname="J. Linkova" initials="J." surname="Linkova"/>
<date month="October" year="2021"/>
<abstract>
<t>Neighbor Discovery (RFC 4861) is used by IPv6 nodes to determin
e the link-layer addresses of neighboring nodes as well as to discover and maint
ain reachability information. This document updates RFC 4861 to allow routers to
proactively create a Neighbor Cache entry when a new IPv6 address is assigned t
o a node. It also updates RFC 4861 and recommends that nodes send unsolicited Ne
ighbor Advertisements upon assigning a new IPv6 address. These changes will mini
mize the delay and packet loss when a node initiates connections to an off-link
destination from a new IPv6 address.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9131"/>
<seriesInfo name="DOI" value="10.17487/RFC9131"/>
</reference>
</references> </references>
<references anchor="sec-informative-references"> <references anchor="sec-informative-references">
<name>Informative References</name> <name>Informative References</name>
<reference anchor="RFC6620">
<front> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.66
<title>FCFS SAVI: First-Come, First-Served Source Address Validation 20.xml"/>
Improvement for Locally Assigned IPv6 Addresses</title> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.48
<author fullname="E. Nordmark" initials="E." surname="Nordmark"/> 61.xml"/>
<author fullname="M. Bagnulo" initials="M." surname="Bagnulo"/>
<author fullname="E. Levy-Abegnoli" initials="E." surname="Levy-Abeg
noli"/>
<date month="May" year="2012"/>
<abstract>
<t>This memo describes First-Come, First-Served Source Address Val
idation Improvement (FCFS SAVI), a mechanism that provides source address valida
tion for IPv6 networks using the FCFS principle. The proposed mechanism is inten
ded to complement ingress filtering techniques to help detect and prevent source
address spoofing. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6620"/>
<seriesInfo name="DOI" value="10.17487/RFC6620"/>
</reference>
<reference anchor="RFC4861">
<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 o
ther's presence, to determine each other's link-layer addresses, to find routers
, 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>
</references> </references>
</references> </references>
<?line 423?>
<section numbered="false" anchor="acknowledgments"> <section numbered="false" anchor="acknowledgements">
<name>Acknowledgments</name> <name>Acknowledgements</name>
<t>Many thanks to Bernie Volz for significant review and feedback, as well <t>Many thanks to <contact fullname="Bernie Volz"/> for the significant
as Hermin Anggawijaya, Carlos Jesus Bernardos, Brian Carpenter, Stuart Cheshire review and feedback, as well as <contact fullname="Hermin
, Roman Danyliw, Alan DeKok, James Guichard, James Guichard, Erik Kline, Mallory Anggawijaya"/>, <contact fullname="Carlos Jesus Bernardos"/>, <contact
Knodel, Murray Kucherawy, David Lamparter, Ted Lemon, Eric Levy-Abegnoli, Aditi fullname="Brian Carpenter"/>, <contact fullname="Stuart Cheshire"/>,
Patange, Jim Reid, Michael Richardson, Patrick Rohr, John Scudder, Mark Smith, <contact fullname="Roman Danyliw"/>, <contact fullname="Alan DeKok"/>,
Gunter Van de Velde, Eric Vyncke, Timothy Winters, Peter Yee for their feedback, <contact fullname="James Guichard"/>, <contact fullname="James
comments and guidance. We apologize if we inadvertently forgot to acknowledge a Guichard"/>, <contact fullname="Erik Kline"/>, <contact
nyone's contributions.</t> fullname="Mallory Knodel"/>, <contact fullname="Murray Kucherawy"/>,
<contact fullname="David Lamparter"/>, <contact fullname="Ted Lemon"/>,
<contact fullname="Eric Levy-Abegnoli"/>, <contact fullname="Aditi
Patange"/>, <contact fullname="Jim Reid"/>, <contact fullname="Michael
Richardson"/>, <contact fullname="Patrick Rohr"/>, <contact
fullname="John Scudder"/>, <contact fullname="Mark Smith"/>, <contact
fullname="Gunter Van de Velde"/>, <contact fullname="Eric Vyncke"/>,
<contact fullname="Timothy Winters"/>, and <contact fullname="Peter Yee"/>
for their feedback, comments, and guidance. We apologize if we
inadvertently forgot to acknowledge anyone's contributions.</t>
</section> </section>
<section anchor="contributors" numbered="false" toc="include" removeInRFC="f
alse"> <section anchor="contributors" numbered="false" toc="include">
<name>Contributors</name> <name>Contributors</name>
<contact initials="G." surname="Chen" fullname="Gang Chen"> <contact initials="G." surname="Chen" fullname="Gang Chen">
<organization>China Mobile</organization> <organization>China Mobile</organization>
<address> <address>
<postal> <postal>
<street>53A, Xibianmennei Ave.</street> <street>53A, Xibianmennei Ave.</street>
<street>Xuanwu District</street> <street>Xuanwu District</street>
<city>Beijing</city> <city>Beijing</city>
<country>P.R. China</country> <country>China</country>
</postal> </postal>
<email>phdgang@gmail.com</email> <email>phdgang@gmail.com</email>
</address> </address>
</contact> </contact>
</section> </section>
</back> </back>
<!-- ##markdown-source:
H4sIAAAAAAAAA+19a3MbN7bgd/4KrKZSsSYkrYfHsTWzc0NLcqxEsnwlObmp
qZQL7AZJxM0Gpx+imUnub9nfsr9szwNAA81uynFStVtbw6lxxGY3cHBw3g/0
aDQaVLrK1InYu1FzXVaq0Plc3KpsNpqrXBWyUqm4eHP/VEzStFBlqUpRl3jP
2atTuLw3kNNpoe5bA5TxAH3PJvDr3BSbE1FW6aCsp0tdltrk1WYFIF2c370c
DFKT5HIJX9NCzqqRVtVslC6SkYQxR7mp9EzDMPDQKIPRyqp7GL0qTkRV1GV1
dHDw/OBoIAslAeiLHCDOVQWwmLxUeVmXdJ8awJKOB2tTvJ8Xpl7BrWcbgEMn
4pUpK3Fq8pme1wXNvDd4rzZwawqT2fFGZwjt4F7ltToZCPExgwjBAO99D7Mi
mr7Gh/D6UuoMrsOy1/OvEANjU8zxB1kkC/hhUVWr8uTxY7wPL+l7NXa3PcYL
j6eFWZfqMY3wGJ+c62pRT+HZ9ft6KQv9mNFrv3VjGJ9jJAdz2ifGPOBYm48Z
6fFDmzleVMtsbzAoK5mn72RmckDMRpWDEgat3v2zNgDGicjNYKVPxD8qkwxF
aYqqULMS/tos8Y8fBwNZVwtT4A6M4P9CMCl9L4tC5eJbgpCu6xxG+34cXgLc
yVz/TOCciK+NmWdqKC4vT+lXxXuyppG+sjiAjW/NJG5roPyF+LbQ5SKXeTPZ
7Ti+CNOdiFNdJkbcboCPlrCOizwZh7OVNNj4vX3uqzleHidm2Zr1Rv6k78Wk
BNibCW/GwRWa7SJP1UrBP3kVzlLg02OJ9/bOcGlg2T8bIOFMV+Esl+Po2m4k
lrBfqjqhv0fidqGn9UaK49HR4eiYLiamziuUD9/IlcWTBTJjAL6a05AdEH4D
G3yp8/fmXjbQfTOOrv0W6A7FmSwyZMuLMgOiFDcpg6grgO/Nplgai8bEpDA/
ypl4DROQPoXMtAzXMauLYhOvIv7t8Lh3E24XCsD5Rst8HtFVcyVe4Aulf8IF
vM1BQBQlAC7MTLwBUVQKXNGdyhTMsqxzy4VlBx5em7E4PBD/pas6oflvjAwx
YSehKwWoBJz4ldQpwCTOQEEUOgnRdHhwcPCstdmnC51HSCpxop9wVV9N61U1
Vmk9TvIBymwYb1pX2yz+NdwMA6mA474eNxeY23AecWWmOlMdK/3L8WQI65zC
vEuV50qLCchV++N/1TJf160VbSHAL+nN+Ga8va7VIp3jopoNHgxyUywB+fek
Nm5enh4dHj63fz45OPjS/Xn4/Nj9+ezpkf3z6fNjd++zJ4d/ORkMdD5rjff0
6dFB8+Qh3DMajYScIm3COgZ3C10KULo1rLkSqZrpHPS2FEsFkjQVlRE8Jlxi
NQ7KvgByEtVCVnAxVfc6UWIhSwFCGxAtlsCqbYsALoNor4DOsmwDaGJFCD9I
ZyqMBwzZUqcpbM/gT6hbC5PWCVLmYHBRCQAUJsbHl8B8wqwUq1KZiRUuBuAY
ClWuVKJpGp0Lhfp5BfJTCRDWqN5BzMKaargAZs4TWhMIl3kpYJFgCZh6moHM
NaCbgKDg0gwFT6mTUqzqYmUQUnH+QS5XcBuyU4X403mS1akCdCxUtgKclO/h
H0niYw2KEn4A6N6rCkR6At9KsXe3UOL0/PrzElTsqjIrkcgcNCLiJldJhUBW
cAvAjkvY+6vQM7pwNTl1SOPp/T2In/e5WefiEa5FMZBiVhjYvBxgBOsEOGcD
6hL1zf4wfBjgIHy4oQEaMVXA0UDu6h42iobBBxzGEDmZkoDISgLOSKKE0Kxg
8YoIKFXwfQl0hWvQtI9gjSULfAyUFKx6AffbXXVgayTCW5XUBcqta7fXpaiU
XIoUFee9NT7rcqUTbepSKFwibocwdTUFZgS4daHWQA68yRbIHNFc1lnlrFP+
NYJ1vdCwVQqAMRulmn1ayJRpP8IXfKeLlV4C8Rv7ZaE2hMl/1rKQeUUoqAiI
Qi0BfkLYUmZgVoCkYV7sImu4PdNIb3mzBZYNccdxFXj94k0DD1jEc5RjFXAW
jUvED5DoCtamACFIJOEaFLAGUOYSTVV/CUxOJZSmHeIxYU+nGwbhX//6HySx
jg9//bWfxeFuBM7yn12fKcbiJQPwdCgWZg1bVwyZm/yq4e8l8stCFilKHJBF
SBu4KgKVZQ/yQQVbSiLHz8teTLOOew3kdDkB7mGoUYz++uu4LQBXhbnXqZWA
QKK5LpeEKS/pGonotqIlE/FyIBVlC7A0gkw8grHtbbsEJHAr025dNjCuJDEH
SRjcySHieinfNz4XglpIkPUgRhEpEikN5QbB5Dc0xhWK4j+ht4LcRDyHU5+h
atBsJgxQeoEThESVgjC7ent7tzfk/4rX1/T3zfl/vr24OT/Dv29fTS4v/R8D
e8ftq+u3l2fNX82Tp9dXV+evz/hhuCqiS4O9q8kPe4yQves3dxfXryeXe8j1
VbSXuFTYLRBjmtWAQlUkywHgLgE7Ar7AMy9O3/zv/3X4xBPz4XMgZv7y7PDL
J/BlDQKDZzM5bA5/Rd4eyNVKyQJHQQmTyJWuZMZsBDoEJDGwDTL2n/+BmPnx
RPxtmqwOn/zdXsAFRxcdzqKLhLPtK1sPMxI7LnVM47EZXW9hOoZ38kP03eE9
uPi3/8hQwo0On/3H3wdEQxwjYHEmrjw/XQOv3Gu1ZjqylApUDW6dyZDrQT3j
RhErOUYpwrH8zbgZW6YJSBhkUH6+MBlRPIjhzqH4mXFLDmhrfJAkyNXaxTTi
JT1iLLybnJ3dvLs5//rd+evJi8vzfRBy9DvrEJ2naGCrspEPFtCyXq3Ai7WA
hiN74TMevFBog9ifWeXJfBNKbXw6AQUBcBNZhUpMkegOBbCftAsdYwGGFqqs
1DA3TTfWunFKphMRdr1o4zMfKlDZdOlG/bNWoFHsHY9KpVCt05ejw/GXuDX/
sAbsj/vOpLlwdqzJR3aEobgFRxNs7qHwV27AwFwPUfXcqCmgGdBWlnIOmAY1
W4KrWzo7yiJcktCs3DSw8jqTrLjAGUKTyn6Z1ZkjqiQM2yDlAVGAEXgx69zJ
LqQOyephGxGF6U4cAvo0jDNJYdgKDVda3QoEj1sc0KoR8t7oVICFo0qNemKJ
1kwCoh6MWDmb6WToLMZuTZAaAAUNTgs5KSLNl9Y6I9MVcFeoRIEzsR+SXEyp
utmqbUpEieIIN6ZaGxokA8gLBifCyYb3sSFxjTS8BlxEE7hxy9BaQaPACfep
yswapO9kVtEOJbhxsLGAStZ8xEof7ap8B/Z8Kh6F5sN+rMtxE3MSNpqsUJh2
JhOyqxzQ3oDhxbfXKpp9ZEIBwTICwTK6eP3y+ubKkUDMRk/GR/tk83or6QH7
BGeNF+1WQL4Mil9wcsBC750fPXGp0TJwM1xMPFVbQrY6FPgadChAxQvdREJ9
qhAPbidVOmaV0EloDZkYqz8QXNazAPRLPR8fwvP/7T+DwRcj+/lC2I+/0ny+
6Pnpi8Ev4vTy4vz1nfjFPf6LeHlxc3s3enX9Rtxcv707v/G//eIwcXt+8x1e
3zn71m9ftH74YsCD0ocN1+Dzi+j5/MKP/W17maPR3x98rO/XT3us9+MfK4vk
RICoeT/KDPCb3/fdj3Wtre/z9whIpuIJ6uwR2lrnIKKA32+vLy9OL+4ej8fj
vrWNBKt64R6zXx9Gycg92rYSdj/2cZ/gsQj4j3/sE2f7hMc6abL3E892c/7m
8gfcqskZ8Nbdxe25uDq/vZ18fd43m/32Ucj//Wv75MeIA/qkYe9jn84BbYHe
h0V6wKX4Hn/iIjFK5HXz/xX8/iaa25rNI4vJrxdXnwxkpKxectzi8KTbPHyD
hmeKdzTuE7hYVunsfgRu3H0nG+usfHcZp70Oz0f6OI0Oj3zwyG8fC4SCjUpn
qO80mEObT2IgNwO7rzwB9DCeDzpwf9hx7ajj2rEf4xB+PxZPxF/EU/GleCae
/5ZrPMoXo9/5Px4mIDRGwYj8roauxNYNGXjJAd39QdAM+mHoE7uP7l5MDvbj
JyPgANUDzwtHJzup1liqBVfMG9iLXWGDhvxUjtHnlDwz8lRcCL/iGKxzxTCu
0+nJWkJ3fia6GY7irddfhs4D2r/W0foI6HZB1DiGlJWMPEPn8llcOGvdxdzh
VuvWWfsdAYtH7/Xcxw/KEHf/Fc8aBXcsQOyS7/BrQucF00t57GDpsglCW8ee
R/48cLfGgw750TNfv+z4/1h0LMv5CEtPxLbOgr3MS0lu5Uhv2x9/nOhooPkd
HwvNTrvXceuOz/jhYR7dy0KjxNh/cJg/aFF/EIrDzW4+F1gDomdalWGQwDMh
3P7XwQ4QbxXlJ9tMhbL9cH/seKeTlpA1gx/ExRknXlEKufnVB5SDc+VH6tzD
a3sxkUWhAzPCjjL2SuS4USLdUmDAoiqMW7nICCZuY2ijCBPM6WOXJI51DjrA
hljuZVb7aOhejI09AcjPXLgjnLmR+kqc8nW/W4UT1M2kdvieldnx+6SfD9FZ
dUBD3bIS254U10dPuLvVB1gPaB+MeW2Hf+xdLsjXG/EhkrjH2Noo0zNFCVSc
alWomSrgjuYy4ax0a7bzEEgg6kHlkj6osUKrstG6y3DEN27E5rJVDw+Eo3Zq
D7Z7UyJj3siS1ZiuNFFQT96hsOqyMmtZpA+lJwTm40p8JAeUD/1MfgtXdUUB
1pby5q+Pyv2HKMUSG4w4+cETIWfmLfsNffFCQJsv//PstZvTRka/PHhiE6sq
1vuBqNmh/wnILHuHd767UZncvJvMEbJ3WBrI1FkG4W6fSJ3NDo5OTg5PjvaZ
pkKuQgDgn5UkpvbmEtVJYJxzBwG8zTP93qECRSPVXbghhtbak1TzAtP5OomO
sJYJrbPhTsOEoJ62x9zFRJrMo1WhsTQRuBLXtjfD5ZYLiVmjPV/BIkYiqBDx
iQKXIPIx6lKUZsmmFMIOW6GK0RHAZKsyYLeAS+8p1+rQTbCWK2NmVEDDpR1M
Wp+HxSuctyKIbdUGckBVyeQ9PBGP0oMkNLqvc88KlAYnuqD6kSD63s5KUBqX
SIIKViRV5tjaCo8E9zxbom23or0DQ6o9sQUueHMHIAxhqmcghQhnPuHuk0ly
qUJjN3Ag0D/oWVu+tUBaWxtrROgk9cKFbM1CpULR2lMQpJgWwp3CMhtA3kLe
o1sxtLUsMyp6pQlauSFfcYoU6ciYqKLsUH7xxvTxBtLufVcypskDAbXOMzMF
3isTA8aPu/Hg4Eu40bGLy8i9vZyEZNlwNJfDkZ63Axw+P+ZsBmEgnMMOKrPS
NCMHmSTvuOyAkgVsVHuDhUo6VdaHnFpVSZilegyVbfbHW4hEjfBReGwmiyt2
WE7HW9RUEzw8dp1TOtUyg80iwtrFjakxG+e92GXoqBKD2GqjKwz3XotZJueY
riKLE/M7p6Hmwzow1p6bZpId4uJP4MNaA8fNaRO6WMI5cNpla+y+IZlBlkqx
8rUCnr1IFBCA1JRrZrDw0obAeF6fgG2KB/vsvb+2Hm1Syb3WWvuRrdkoy942
2iiV3qoks3bDtoHnh2yMr9LURaLa+s4Ueq6xnK2PWEjJ2TIxpjXW4A8MF5hh
weQB6K4+kgW8Lz5EmAs0LFBs2wW/UaDa3ALJznRP6xxcASqKI2Nk9NIUZLD5
2ZuaRhpy3LtZebdxNqYAVvQIw2gJEKHsjRnZkJNlTayIpAyrrHZqK5xhT66A
9MFeQBPB2l1os+yxi8OCDzal8TUAVcigGBUj61x/gPsyNSfzNwrHULUdi5DR
m7M4W/10fIyoDbPD+14B9gI8kzorrV+Fi7T58mEYaWauhTWFyGQVZfGDCQka
A5Rb5Sf1kkCSIMRLfXMAF/8ZnU+aikfr2ZigLEI8kqRnU3SUqN47s/ZZ4C/Y
oCHLy0ZXeK9gf+hkaiCokUqwaNUA8VuWiejBQWh35ewtOrBWcrN9iiadm4IM
QXmPTUVUmRuMh04BZXNQyJF4DtY3ZpzYOZtyD4ElObiPU7CplDVTbPFi2iHs
ELI43MelMKms5FSWbKjmxg+rPsBEJcOZtTw6dw+gHZgNhIWlz5Zb2PL/CoUR
2qZm1QkjJpSCq5KzQsl007O8gGR9Ka5FOBl3oe0fkm29SpEPcbluKX/AtDIP
DfBo1haFIEPQIxaQAIfx9oJ38T7CGZBrnXuqIbKubXA61DdUASVmNRUfNVnc
Rjc3fEXGxRSEdhQp5hxc4Chi916hQvr2GgnL1mVeLnU1jrMD2hrmC/BrwHy0
xfYsvrx5LdMlWFbMyfeoOpdY6jJk+9aWZyNpwV5h7UlnfZWtrkcnXxds5MAU
bfncsW241YFgnln9hNyKApiKmnKuVZeB+LXymHFizRKCNy4AIgO7KZyyO1y2
TEFvqM81OjWd+MCER1YtTD1fNOjd+yONzz2WRw502lxr49lIRCPjdRUSNNKe
s96IBCwSSEMLObfuZipK0GfJwuHL/tydmrH2Xgq7mXhnJorChJaVz0psS1ln
UFlzobGYfT2clYzYuTa6pEdblpf1ZrD9B90edt+xGLsGs4WUAaGXeT/OwPiF
uFiOrX0ZusIW1pc35y8uXp89nPOZJNh/kKl0TjTO7kIo12RzA2/einIy0rox
fdQxZTeQxNxOQdCZLO4WGf/O9cSff+d6uj//zvWEn3auh3kKUz1H/++lep5s
p3oiGeA9rd74c6t4pZU2X8uW9+ijb2S3gngBy4AlY8sHbcd1d0dzH4ByLcsO
EEKxi1EjMkXoF3Zci7BUgFpUuPI4jG/Zat3S+mqHz8fH422hnpgV28etffd2
wwPh/fZjobsdb1w7ARNL9CgbhbUCWzEKZz7tzj6FmSTsFiKOSRqnAf223emT
Bwhn3AotgXOHLR3dUatojeWuiFfPI78xKHW3i3w7gjz9uRI71sdEih4aZFfk
Akdql4E0IWtGaNNbYEXEqC2PkPI6AGvdEXgX1JRkySAxBYC3MmyifGT2NSZe
MsU7yub6KAzjAlP095pgap42j7lM24KMwNgJQiNYPMRHaLVPo3gzBiJyDyMV
XMXuMtlwmAjyqWE7iHV70i3+4xB2XXKAITTLSwrFscnq+jppcWVuzKqP1IfN
tDAFjiAz12oy40Cd7eP2SStq7xEYT0hdzqfHtCTr9xbIjBu5Ow3gWy7qGnxk
S047URP3x2z1xpCOc0VhNvwTKPFWS88DjV1BJJ8avGwLtdhu82pckZ4qvo+o
F2vXxzmd5pt3iIhLm+qnELzrjeprfOL0wINgkTcIZGzDrp5DPglp37fSa9ha
l/Tc7cZqigqB1orQ0497yMSj3RG9/Yav9HKpUgwIBO57q5+KC+ZQq9hIkWvk
uc6TKEpCQHW0HFqoGujJj8eW96j1sCFSUJIZ3kyURIGUMk5/N0nRsp7a4oVd
jW24bHsGgi9H2bnVHSlET9Zh6+MnbD2CXmw4X6r9sQw27uJ72QtuQNUNYbj0
r7ln5cTdo4wNpF9TgyYBxOmfXSPnqtCG+/jZTZZTvGcXgbHcgu0O4MAZbArS
omOqFvJek0hEP9cfgMFpezPH4YEFkaLANMATE/z4bbEdAeHKgZLC7BRHbrWJ
ZHkSBLtnhatkYQLjLDJzS3c0fcalCCaqVPi8jMNbpV+APWUheGZpiYsKdS2G
+ioGWpS0cyt8CUljgURZ7+1aFB8e6400MTMgjm0Erhk7UAJBwbMDVQUGQQBP
KaJAZ0O/nHTYLQJJC944W4IOWiNtB5PVVrCo2YxoHzBtc22Z4XbIuAu2rf0C
C2VLGvn4Tjx16eJ8bM6yyY2HhqFNXES3YihQJ4GXQ0El69j8Jeo7bjRLYyWn
aiaBNLBfWC6xobp0yR9xcXMnDnEs+/3q5lQcd6XKpYOxVME41graPiIjCLSa
YkxYTswSJSTB54F/Oj6MwN/GbKakPV2k5YHXOTvcZMkWLdRyl3xvhVhbFzbb
19nAbkOzVZCd8cFPSybO4+KkQxofnLJd09cMExuiNsjfmyzQQQXCQx7hNi6t
CgxR5ZgiWO/5h5UuNrYmn+phtnWTK5QJEVVGqYwtJxLPhtmUzbkdtjYlKhEB
rw3kNxnjkbSxRGhPQ3Cz93VJU2kE9Zn64xsHAzyiJahMDEiWZTo9gO3NMyAs
jgjDrYAYiwM6HxEge+SymByF5eQygPHs4LPWXoJM7y7htPQHbnlSZ7Lpn6Yy
22jX5GpFp+VIJ9upLGLmQDtT5SZPrpqfKme64/VFYdwJal5zSZHJAugor5dT
Hqo7OUDGT1Pf5RSe21TM//FK+iChQ4+AzlIYh8uH61zj5oEISOnosWlN6Umb
+jsYPyeKOwSB8Ijs99I265OjnCwMKJo4mekNlgfNwBZdNuQTp2686KT1NSW8
VLskQVslmGnDCgCiNAwa4kaqe2ubbXXzw+gBqXriY7Pe7j7t7mv1oYrJ7U4v
XcpMNpaELHuoEiWqyZuKYpudBBwHxyMkC1B0mQvWWLjai3AKlYVr2ZNqljnn
rAM7mk7sMYxjkOyfDePKzCAPIql+WX8Iz8bwCaE3F9dD0gd4xtuP++7QMTQ9
YzAiRomw6Q452UZTJFQcPohSrTxDkEFzPQITVnzRM8iwZ7ua2g83GqexsPbV
TpU2WqOsgoCne8AkIDHK0EeC7fmmLpvjRU9YVMhsbgrAzDLOkwbUVijedM7X
hoYqlQUCGdCTLHxiYc3EMMWDuu5Dt9NtNNppCpUErMfx4ILjyWNx6w6ByHAm
SQdWsAMS8iaF6y7iYl2eNqS7LKY4Xx+txvOxK6GY1QU5R0A3vGqnHykKg2lX
0CjwY6ByU5UUdNwbbAYw6qphfKyboYjWjMTbvt2i3ASYpT0aO9UYoBrMUhSf
BSx7qlDgxrFxxpiXob581SIdfnZeF4oruhljfZN809zbxZx9SNJjBUgK72Rp
VlnNG8KGx6TYOfdDtoqIq+ESPKzCUfTQmzquZxDHopOqkLlV2ng6a55ig8t6
YTG0S39UfIIbqIRhxCVMKJZXkOkLljlSrAz4CuLZs8+ikhJa99rxml+zLANj
yde29NzcIMhXx5IrGiCLzpjpdwOonGRFtZ9Hn21VAGonyKd8RhKMYAnGzreU
G6IywOwKXBKNFSqtanfbk9hdmProZhLJVT5/ErybJpfRvXKSYVQjbHkexJzN
WiVy6yAbxxSBCBs2baR46xQja9odzeTC2YefARiZAuwlKia7UOHjLnBA2MpL
VLBerwWzz7r0FrJYAQOhXwxC3jTCJq0ZC6HPlVIsV1Btm0kAu++BgEOycjaa
JZyCsI79KU7PUcKqYy+IrSP1cWrNC/GoOQnn6fh431HZVFYwyma0Mmsi1rDa
Tr5Hr0PwmU94fCDtD54NpVElFmRtdFKrM2paBlFQPeTLaJiTfUiMDCQu1Il7
acrmBM1Voe9lEsT1xuKVnqOoJnvQ8hT8hK4pFlSpNUoPWE69AhMJTRek+eYG
Mi4crfs4tBO1VGATCiiSX7JA+vN6NgfFLW4mjQ9FMDSyusFNGKbkEIcfPEjE
ICNsVpRgCw5lbbuJSHUmBQe+ixhKVyXuQoWU8JRYeUpoIjVmMcY9DE57ccib
VIOxLqarksu8jRRuTqQpeute7UKIiqaGFSPMhrzuGl0a68PuoeVG281GhzfB
HAZ5eRWEnRqwvEQo9RJPfveTB36Jo0kfDvYK1rpsrePNQrXSUteoS/CE12oX
TKEojeIXJKroxGaTtYKJ1mpk2wqIHazcoOaNaKeqnCxoiSNrCnbYwtdNnzp4
sk3jxcSlCgO/drKrM4NLcKmElzosbK2SJwS/DZSIpNgXx3A6KZWs54L10/o3
OD67IBw2fNllXZBAYgz8FseH7XwX92L/E2hq50Aw7ROxMGBTWI3rtBBD3xmp
cItMPY+z2YvCKxaqW4O4BAGRq/qQcAh7O9PGS9kNufvDhkmCiBxlJ5mO7qxl
QuTorVf2/mLRacMs7QjS5Ad/E9rUAT56M9iedZsN5Yhhgzhbh++poEcx2m32
Pba8oT03Y0eU6/zjkxd9GJuLAoEk6zkofqR2RyXw0NMDP89gEMXE3MI52lf6
cF9j8FU+ktREEChqK+0hoEgF3EqbtcJmFFLApz6PI8Sf+zipnIKw3+/IEQXd
3Whft0KkZMxZ0B1krYi43X0uzBg1JeyjyoywlGLkvXtfqk5W6Xbdtz0H2uYr
XPI9kpcojNrl1a1FAZElC2OtUnqvxiaciQ9JbbwcEl0C64jJY+WUL0ZpvIsY
ULAugwQf3urtGSv24+6ULLAbdRF02ASTu5grJ8n8eJ4DsEHP+NqIbVfait4A
cplvbBSl3QjJT3Y0kyO+W23ntr/cnUG6VcfyUA2QET+rwrSPBm1S3XEiW7an
h3nx+SYBSzX53i7vCCTYk5ptNCc8p5Rrnr3J285HtFQ1Zpw1FWV4M7y3ic7m
GF2QBtHfClpVPjnUsjvR1vFZyDV1NjR4Yg3BB9jbLHh4Yk5YsDgWt4Gz4MOv
jSC3p/ugTraCijHlz5M/tYxmX3sxmAS9x2g/o+ewXFnv1PeztKPAjTDXeMa7
Rn+HTxm11OJP5ESrExacxW3cXZ1cSJaP6cUDqCrRRTFz/Bsxf2vNPgYVnNEE
Nq/kmCLMkkpQoszCYS812mFn5jYSCJT4dHgLTmqglmtAHBHP21yDgRZ06IDQ
xRYicNbCakHXYuE7p139ysvTl7fidvLdBXnQ+CKKHwOvIm5MQCDpfU3iwUIo
DEGEHYNgiYN+WKKkWJjMWtFhdogptukzj1rV42OVuzId1BMd9tFQ27nPRdfO
zPeppY855Iz8emNLDUFac/MiHy0gM/s6A8c2HA8kQ4361l6bSkWH5svKeSv2
4Hld4QGvnPjCMjWOfLAyRSvF8U7H8bDczGgTH0H0XQaAGXpdA1jsoHPJGKBJ
cQ9LTflKG0Td2QLSHFogo3Y5jBWzwKUeT4vLoUtqYHWVs5ukZsy2XtuBd/r3
dmABjOvVGQYdoKht8tTbVmhvF4beZWZlhCRODk/ibkUIdhFpWA3nDRl8OxWX
lvoDVfiFVS7h5A5oCBx02gGq1nSGIvqxdCg/mjf2JR7WwGqdueKAQYkGcGBr
5IqUxp/Af+I4Q1sQtqLLmAbJP684knUFwpWq8ciicQeoEUNT/Whw4sWWQU6N
eOQqcclJaABiYWNhZIr3E5LJ/W5CAxKPVR5RB5QXahkybW7LsuOadgxTzRfg
tE4pMhA2YnJpTevNEN0nio0Hk7K/7duFHWoWkToQkWHswLcBodi0dlKoZpDu
kDE5ioZ9Lh6qrcJXpJalpN7WpT/VPGwpdLVWgQ1U40icT9Q/wxjR+Rv2yHsX
cUpCSnBM4g6nbl5HY5BA04ArgmOog8beL589wVcnoOVYt477pi5UZAf3Qg1c
OTXU+V46ld9rYMalb9Tyr7wAktFz513gK2OAh5l2UQ3l1rQHCbLQ3P+5tfuE
N7esqN2U9IGjNDP1NUVNSW2rPraRFUvgSVAW/OaHmqqBmnlJnNbkyCM+MkIg
dUjXq4xNXGdonlEVWXCYDp1sQaKOgrjcR75Zo6aHrY440m6ZZUzWyu0bPNeG
BgKzS0CLPxln6f6+c3j4NYg4IrNrmDnuTqGPB68arWbp28Yy7RuJZLLgFxKB
9kc4/WsJAD8cfyk9Ni0oHhCkJAsJwPQ1zF3rCvXZawUomJqeYylKuxnP6UU3
9IYESxNTymE1VVe6DBQEuO+A7kIbOoDHZpPoQB4yvyypN16ee2HPCUVlWwbc
J20JrZpfVdJkVd0mLw241VwduCVA41OHmvhuq9qOy/a4eNsG9G2gy8pe9ura
HNgWcl4AN6cGjAfc+HgERGsy+zBH450EcPUf1QIUIhmDU8w4ULl3Tiy8UuyR
439F9KI7n5EgjiKFeDF5PdnShr3vBKGt9KVilKQDBVBh1QlHB20FPO1jhjqR
0/W1b1LsfzMoHtvLLzexb2h6CmY3YWXfMc3GErSvpAENXVUrfD3nej3WMpf8
KtDmJVD4KtDV/dNRU4X22Jaz0aEEsAC7t66GOjJdGxF/GK+v7F+grQo/JZnl
4OZ37f0Zg7q1OhF4GKy9ckbzrThb3130a++07u71zfWJ+MGeK/1n8I3yeaYq
HwcOf7tRVJGT4IzRjj566L2k+4wjsERCHHk++ci9tieiijs6PayNi/6XPNB5
in07cbT1eNia1/fU8dg99ruQgqdlY2Muck7TA0yUNvjXCXvIKv2fezOZlWrv
18HgCstnMN/M9ccvVJFrJb4z2c8c6MW3ceD4FBCndzuQEa9UitOQXqWXlsF/
X9G7bcQkn8/lWv8kN3IoTmUBalV8A6qipMFlkRqQSi8KfA8l/LpSGFwaituq
xiLj0wUG91Bh35gl+scAXqbXQxCv+E19a2DObySmor4Gvx5fQLb9/bzQ78W3
+M6jobjCnQe+/BYlCpgfV3VRgIH3Lb40s5BrUNdn8h7zGHKJGgJBucODCNUS
mQ1GSuDv+81oMlXz3GQaIEGrX7yRFSZbYXK9hC3TMO0Vzq9A2zEcJQ4AtxUY
frgxCxj5G7OAPU/qNMV5rvDEhlsQm4shAE/v5vsOs8iAfgXusp39u00Oygag
0kvwdTfie4rGAQrfoLQAZvJnEegi2Bc2wayVNq91iqnosfgeuGFlMJT7MyUZ
16gHJClXexYYyCcO8oQd4rALII4+Z/uait3Ysvs/Hm8rCbl6AAA=
<!-- [rfced] Please review the following questions regarding the terminology
used in this document.
a. We note some messages in this document use all caps while others do not
(some examples below). Please review the capitalization of messages in this
document and let us know how or if to update for consistency.
Original:
... the Information-Request, Solicit,
Request, Renew, or Rebind messages it sends to the server...
... it includes an Address
Registration option in its Advertise or Reply messages.
Original (all caps):
... if they would do so for other DHCPv6 client messages such as SOLICIT,
REQUEST, and REBIND.
* SHOULD mark the address as unavailable for use and not include it
in future ADVERTISE messages.
b. Fields appear formatted both with and without quotes in this document. How
should these be formatted for consistency?
"transaction-id" field
valid-lifetime field
preferred-lifetime field
--> -->
<!-- [rfced] 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.
Media Access Control (MAC)
Stateless Address Autoconfiguration (SLAAC)
Identity Association (IA)
Unique Local Addresses (ULAs)
DHCPv6 for Prefix Delegation (DHCPv6-PD)
DHCP Unique Identifier (DUID)
Multicast Listener Discovery (MLD)
First-Come, First-Served Source Address Validation Improvement (FCFS SAVI)
-->
<!-- [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.
Note that our script did not flag any words in particular, but this should
still be reviewed as a best practice. -->
</rfc> </rfc>
 End of changes. 88 change blocks. 
906 lines changed or deleted 715 lines changed or added

This html diff was produced by rfcdiff 1.48.