<?xml version='1.0'encoding='utf-8'?>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 [ <!ENTITY nbsp " "> <!ENTITY zwsp "​"> <!ENTITY nbhy "‑"> <!ENTITY wj "⁠"> ]><?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?> <!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.11 (Ruby 3.0.2) --><rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-ietf-dhc-addr-notification-13" number="9686" updates="" obsoletes="" category="std" consensus="true" submissionType="IETF" tocInclude="true" sortRefs="true" symRefs="true"version="3">version="3" xml:lang="en"> <!--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> <title abbrev="Registeringself-generatedSelf-Generated AddressesusingUsing DHCPv6">RegisteringSelf-generatedSelf-Generated IPv6 AddressesusingUsing DHCPv6</title> <seriesInfoname="Internet-Draft" value="draft-ietf-dhc-addr-notification-13"/>name="RFC" value="9686"/> <author initials="W." surname="Kumari" fullname="Warren Kumari"> <organization>Google, LLC</organization> <address> <email>warren@kumari.net</email> </address> </author> <author initials="S." surname="Krishnan" fullname="Suresh Krishnan"> <organization>Cisco Systems, Inc.</organization> <address> <email>suresh.krishnan@gmail.com</email> </address> </author> <author initials="R." surname="Asati" fullname="Rajiv Asati"> <organization>Independent</organization> <address> <email>rajiv.asati@gmail.com</email> </address> </author> <author initials="L." surname="Colitti" fullname="Lorenzo Colitti"> <organization>Google, LLC</organization> <address> <postal> <street>Shibuya 3-21-3</street> <country>Japan</country> </postal> <email>lorenzo@google.com</email> </address> </author> <author initials="J." surname="Linkova" fullname="Jen Linkova"> <organization>Google, LLC</organization> <address> <postal> <street>1 Darling Island Rd</street> <city>Pyrmont</city> <code>2009</code> <country>Australia</country> </postal> <email>furry13@gmail.com</email> </address> </author> <author initials="S." surname="Jiang" fullname="Sheng Jiang"> <organization>Beijing University of Posts and Telecommunications</organization> <address> <postal> <street>No. 10 Xitucheng Road</street> <city>Beijing</city> <region>Haidian District</region> <code>100083</code> <country>China</country> </postal> <email>shengjiang@bupt.edu.cn</email> </address> </author> <date year="2024"month="May" day="16"/> <area>Internet</area> <workgroup>Dynamic Host Configuration</workgroup> <keyword>Internet-Draft</keyword>month="October"/> <area>INT</area> <workgroup>dhc</workgroup> <!-- [rfced] Please insert any keywords (beyond those that appear in the title) for use on https://www.rfc-editor.org/search. --> <keyword>example</keyword> <abstract><?line 99?><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><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-notification.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="mailto:dhcwg@ietf.org"/>), which is archived at <eref target="https://mailarchive.ietf.org/arch/browse/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-notification"/>.</t> </note></front> <middle><?line 104?><section anchor="introduction"> <name>Introduction</name> <t>It is very common operational practice, especially in enterprise networks, to use IPv4 DHCP logs for troubleshooting or forensics purposes.ExamplesAn example of thisincludeincludes a help desk dealing with a ticket such as "The CEO's laptop cannot connect to the printer"; if theMACMedia Access Control (MAC) address of the printer is known (forexampleexample, from an inventory system), the printer's IPv4 address can be retrieved from the DHCP log or lease table and the printer can be pinged to determine if it is reachable. Another common example is aSecurity Operationssecurity operations team discovering suspicious events in outbound firewall logs and then consulting DHCP logs to determine which employee's laptop had that IPv4 address at that time so that they can quarantine it and remove the malware.</t> <t>This operational practice relies on the DHCP server knowing the IP address assignments. This works quite well for IPv4 addresses, as most addresses are either assigned by DHCP <xref target="RFC2131"/> or statically configured by the network operator. For IPv6, however, this practice is much harder to implement, as devices often self-configure IPv6 addresses viaSLAACStateless Address Autoconfiguration (SLAAC) <xref target="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 withIPv4,IPv4 by making DHCPv6 infrastructure aware of self-assigned IPv6 addresses.</t> </section> <section anchor="conventions-and-definitions"> <name>Conventions and Definitions</name><t>The<t> The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as described inBCP 14BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they appear in all capitals, as shownhere.</t> <?line -18?>here. </t> </section> <section anchor="registration-mechanism-overview"> <name>Registration Mechanism Overview</name> <t>The DHCPv6 protocol is used as the address registration protocol when a DHCPv6 server performs the role of an address registration server. This document introduces a new Address Registration (OPTION_ADDR_REG_ENABLE)optionoption, which indicates that the server supports the registration mechanism. Before registering any addresses, the client <bcp14>MUST</bcp14> determine whether the network supports address registration. It can do this by including the Address Registration option code in the Option Request option (seeSection 21.7 of<xreftarget="RFC8415"/>)target="RFC8415" sectionFormat="of" section="21.7"/>) of the Information-Request, Solicit, Request, Renew, or Rebind messages it sends to the server as part of the regular stateless or stateful DHCPv6 configuration process. If the server supports address registration, it includes an Address Registration option in its Advertise or Reply messages. To avoid undesired multicast traffic, if the DHCPv6 infrastructure does not support (or is not willing to receive) any address registration information, the client <bcp14>MUST NOT</bcp14> register any addresses using the mechanism in this specification. Otherwise, the client registers addresses as described below.</t> <t>After successfully assigning a self-generated or statically configuredValid (<xref target="RFC4862"/>)valid IPv6 address <xref target="RFC4862"/> on one of its interfaces, a client implementing this specification multicasts an ADDR-REG-INFORM message (seeSection 4.2)<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 DHCPv6IAIdentity Association (IA) Address option <xref target="RFC8415"/> to specify the address being registered.</t> <t>The address registration mechanism overview is shown inFig.1.</t><xref target="Fig.1"/>.</t> <figure anchor="Fig.1"> <name>Address Registration Procedure Overview</name> <artwork><![CDATA[ +--------+ +------------------+ +---------------+ | CLIENT | | FIRST-HOP ROUTER | | DHCPv6 SERVER | +--------+ +---------+--------+ +-------+-------+ | SLAAC | | |<--------------------> | | | | | | | | src: link-local address | | --------------------------------------------> | | INFORMATION-REQUEST or SOLICIT/... | | - OPTION REQUEST OPTION | | -- OPTION_ADDR_REG_ENABLE | | | | ... | | | | | |<--------------------------------------------- | | REPLY or ADVERTISE MESSAGE | | - OPTION_ADDR_REG_ENABLE | | | | | | src: address being registered | | --------------------------------------------> | | ADDR-REG-INFORM MESSAGE |Register/ | |log addresses | | | | | <-------------------------------------------- | | ADDR-REG-REPLY MESSAGE | | | ]]></artwork><t>Figure 1: Address Registration Procedure Overview</t></figure> </section> <section anchor="dhcpv6-address-registration-procedure"> <name>DHCPv6 Address Registration Procedure</name> <section anchor="dhcpv6-address-registration-option"> <name>DHCPv6 Address Registration Option</name> <t>The Address Registration option (OPTION_ADDR_REG_ENABLE) indicates that the server supports the mechanism described in this document. The format of the Address Registration option is described as follows:</t> <figure anchor="Fig.2"> <name>DHCPv6 Address Registration Option</name> <artwork><![CDATA[ 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | option-code | option-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+option-code OPTION_ADDR_REG_ENABLE (TBA0) option-len 0]]></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>A serverwhichthat is configured to support the address registration mechanism <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 anchor="dhcpv6-address-registration-request-message"> <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. The format of the ADDR-REG-INFORM message is described as follows:</t> <figure anchor="Fig.3"> <name>DHCPv6 ADDR-REG-INFORM Message</name> <artwork><![CDATA[ 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | msg-type | transaction-id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . options . . (variable) . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+msg-type Identifies]]></artwork> </figure> <dl> <dt>msg-type:</dt><dd>Identifies the DHCPv6 message type;Setset to ADDR-REG-INFORM(TBA1). transaction-id The(36).</dd> <dt>transaction-id:</dt><dd>The transaction ID for this messageexchange.exchange.</dd> <dt>options:</dt><dd>The optionsOptionscarried in thismessage. ]]></artwork> <t>Figure 3: DHCPv6 ADDR-REG-INFORM message</t>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 RequestOption(s)option(s) in the ADDR-REG-INFORM message. Clients <bcp14>MAY</bcp14> include other options, such as the Client FQDNOptionoption <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 -purposes; for example, if the network implements some form oflayer-2Layer 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 haveit,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(<xref target="RFC4862"/>)addresses <xref target="RFC4862"/> of global scope(<xref target="RFC4007"/>).<xref target="RFC4007"/>. This includesULA addresses,Unique Local Addresses (ULAs), which 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> <t>Clients <bcp14>MUST</bcp14> discard any received ADDR-REG-INFORM messages.</t> <section anchor="server-message-processing"> <name>Servermessage processing</name>Message Processing</name> <t>Servers <bcp14>MUST</bcp14> discard any ADDR-REG-INFORM messages that meet any of the following conditions:</t> <ul spacing="normal"> <li> <t>the message does not include a Client Identifier option;</t> </li> <li> <t>the message includes a Server Identifier option;</t> </li> <li> <t>the message does not include the IA Address option, or the IP address in the IA Address option does not match the source address of the original ADDR-REG-INFORM message sent by the client. The source address of the original message is the source IP address of the packet if it is notrelayed,relayed or is thePeer-Addresspeer-address field of the innermostRelay-ForwardRelay-forward message if it isrelayed.</t>relayed; or</t> </li> <li> <t>the message includes an Option RequestOption.</t>option.</t> </li> </ul> <t>If the message is not discarded, the address registration server <bcp14>SHOULD</bcp14> verify that the address being registered is "appropriate to the link" as defined by <xref target="RFC8415"/> or within a prefix delegated to the client viaDHCPv6-PDDHCPv6 for Prefix Delegation (DHCPv6-PD) (seeSection 6.3 of<xreftarget="RFC8415"/>).target="RFC8415" sectionFormat="of" section="6.3"/>). If the address being registered fails this verification, the server <bcp14>MUST</bcp14> drop themessage,message and <bcp14>SHOULD</bcp14> log this fact. If the message passes the verification, the server:</t> <ul spacing="normal"> <li> <t><bcp14>MUST</bcp14> log the address registration information (as is done normally for clients to which it has assigned an address), unless it is configured not to do so. The server <bcp14>SHOULD</bcp14> log the clientDUIDDHCP Unique Identifier (DUID) and the link-layer address, if available. The server <bcp14>MAY</bcp14> log any other information.</t> </li> <li> <t><bcp14>SHOULD</bcp14> register a binding between the provided Client Identifier and IPv6 address in its database, if no binding exists. The lifetime of the binding is equal to the Valid Lifetime of the address reported by the client. If there is already a binding between the registered address and the same client, the server <bcp14>MUST</bcp14> update its lifetime. If 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> <t><bcp14>SHOULD</bcp14> mark the address as unavailable for use and not include it in future ADVERTISE messages.</t> </li> <li> <t><bcp14>MUST</bcp14> send back an ADDR-REG-REPLY message to ensure the client does not retransmit.</t> </li> </ul><t>If<!-- [rfced] FYI - We have added "i.e.," to the parenthetical text below for clarity. Please review and let us know if this changes your meaning. Original: If a client is multihomed (connected to multiple administrative domains, each operating its own DHCPv6 infrastructure), the requirement to verify that the registered address is appropriate... Current: If a client is multihomed (i.e., connected to multiple administrative domains, each operating its own DHCPv6 infrastructure), the requirement to verify that the registered address is appropriate... --> <t>If a client is multihomed (i.e., connected to multiple administrative 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><t>Although<!-- [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"/>)<xref target="RFC6939"/> if they would do so for other DHCPv6 client messages such as SOLICIT, REQUEST, and REBIND.</t> </section> </section> <section anchor="dhcpv6-address-registration-acknowledgement"> <name>DHCPv6 Address Registration Acknowledgement</name> <t>The server <bcp14>MUST</bcp14> acknowledge receipt of a valid ADDR-REG-INFORM message by sending back an ADDR-REG-REPLY message. The 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 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . options . . (variable) . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+msg-type Identifies]]></artwork> </figure> <dl> <dt>msg-type:</dt><dd>Identifies the DHCPv6 message type;Setset to ADDR-REG-REPLY(TBA2). transaction-id The(37).</dd> <dt>transaction-id:</dt><dd>The transaction ID for this messageexchange.exchange.</dd> <dt>options:</dt><dd>The optionsOptionscarried in thismessage. ]]></artwork> <t>Figure 4: DHCPv6 ADDR-REG-REPLY message</t>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 <xreftarget="RFC8415"/> section 19.3.</t>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> <ul spacing="normal"> <li><t>The<t>the IPv6 destination address does not match the address beingregistered.</t>registered;</t> </li> <li><t>The<t>the IA Address option does not match the address beingregistered.</t>registered;</t> </li> <li><t>The<t>the address being registered is not assigned to the interface receiving themessage.</t>message; or</t> </li> <li><t>The<t>the transaction-id does not match the transaction-id the client used in the corresponding ADDR-REG-INFORM message.</t> </li> </ul> <t>The ADDR-REG-REPLY message only indicates that the ADDR-REG-INFORM message has been received and that the client should not retransmit it. The ADDR-REG-REPLY message <bcp14>MUST NOT</bcp14> be consideredasto be any indication of the address validity and <bcp14>MUST NOT</bcp14> be required for the address to be usable. DHCPv6 relays, or other 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 anchor="signaling-address-registration-support"> <name>Signaling Address Registration Support</name> <t>To avoid undesired multicast traffic, the client <bcp14>MUST NOT</bcp14> register addresses using this mechanism unless the DHCPv6 infrastructure supports address registration. The client can discover this by including using the OPTION_ADDR_REG_ENABLE option in the Option Request options that it sends. If the client receives and processes an Advertise or Reply message with the OPTION_ADDR_REG_ENABLE option, it concludes that the DHCPv6 infrastructure supports address registration. When the client detects address registration support, it <bcp14>MUST</bcp14> start the registration process (unless configured not to do so) and <bcp14>MUST</bcp14> immediately register any addresses that are already in use. Once the client starts the registration process, it <bcp14>MUST NOT</bcp14> stop registering addresses until it disconnects from the link, even if subsequent Advertise or Reply messages do not contain the OPTION_ADDR_REG_ENABLE option.</t> <t>The client <bcp14>MUST</bcp14> discover whether the DHCPv6 infrastructure supports address registration every time it connects to a network or when it detects it has moved to a new link, without utilizing any prior knowledge about address registration support on that network or link. This client behavior allows networks to progressively roll out support for theaddress registrationAddress Registration option across the DHCPv6 infrastructure without causing clients to frequently stop and restart address registration if some of the network's DHCPv6 servers support it and someof themdo 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 registrationmesssagesmessages on a given interface unless the client has discovered that the interface is connected to a networkwhichthat supports address registration.</t> </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"> <name>Retransmission</name> <t>To reduce the effects of packet loss on registration, the client <bcp14>MUST</bcp14> retransmit the registration message. Retransmissions <bcp14>SHOULD</bcp14> follow the standard retransmission logic specified bysection 15 of<xreftarget="RFC8415"/>target="RFC8415" sectionFormat="of" section="15"/> with the following default parameters:</t> <ul spacing="normal"> <li> <t>IRT 1 sec</t> </li> <li> <t>MRC 3</t> </li> </ul> <t>The client <bcp14>SHOULD</bcp14> allow these parameters to be configured by the administrator.</t> <t>To comply withsection 16.1 of<xreftarget="RFC8415"/>,target="RFC8415" sectionFormat="of" section="16.1"/>, the client <bcp14>MUST</bcp14> leave the transaction ID unchanged in retransmissions of an ADDR-REG-INFORM message. When the client retransmits the registration message, the lifetimes in the packet <bcp14>MUST</bcp14> be updated so that they match the current lifetimes of the address.</t> <t>If an ADDR-REG-REPLY message is received for the address being registered, the client <bcp14>MUST</bcp14> stop retransmission.</t> </section> <section anchor="registration-expiry-and-refresh"> <name>Registration Expiry and Refresh</name> <t>The client <bcp14>MUST</bcp14> refresh registrations to ensure that the 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"> <name>SLAAC Addresses</name> <t>For an address configured using SLAAC, a function AddrRegRefreshInterval(address) is defined as 80% of the address's current Valid Lifetime. When calculating this value, the client applies a multiplier of AddrRegDesyncMultiplier to avoidsynchronizationsynchronization, causing a large number of registration messages from different clients at the same time. AddrRegDesyncMultiplier is a random value uniformly distributed between 0.9 and 1.1 (inclusive) and is chosen by the client when it starts the registrationprocess,process to ensure that refreshes for addresses with the same lifetime are coalesced (see below).</t> <t>Whenever the client registers or refreshes an address, it calculates a NextAddrRegRefreshTime for that address as AddrRegRefreshInterval seconds in the future but does not schedule any refreshes.</t> <t>Whenever the network changes the Valid Lifetime of an existing address by more than 1%, for example, by sending a Prefix Informationoption (PIO,Option (PIO) <xreftarget="RFC4861"/>)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:thisThis algorithm ensures that refreshes are not sent toofrequently,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"> <li> <t>If the network never changes the lifetime of an address (e.g., if no further PIOs are received, or if all PIO lifetimes decrease in step with the passage of time), then no refreshes occur. Refreshes are not necessary, because the address expires at the time the server expects it to expire.</t> </li> <li> <t>Any time the network changes the lifetime of an address (i.e., changes the time at which the address willexpire)expire), the client ensures that a refresh is scheduled, so that server will be informed of the new expiry.</t> </li> <li> <t>Because AddrRegDesyncMultiplier is at most 1.1, the refresh never occurs later than a point 88% between the time when the address was registered and the time when the address will expire. This allows the client to retransmit the registration for up to 12% of the original interval before it expires. This may not be possible if the network sends a Router Advertisement(RA,(RA) <xreftarget="RFC4861"/>)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> <t>The 1% tolerance ensures that the client will not refresh or reschedule refreshes if the Valid Lifetime experiences minor changes due to transmission delays or clock skew between the client and the router(s) sending theRouter Advertisement.</t>RA.</t> </li> <li> <t>AddrRegRefreshCoalesce(Section 4.6.3)(<xref target="transmitting-refreshes"/>) allows battery-powered clients to wake up less often. In particular, it allows the client to coalesce refreshes for multiple addresses formed from the same prefix, such as the stable and privacy addresses. Higher values will result in fewerwakeups,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> <t>In typical networks, the lifetimes in periodicRouter AdvertisementsRAs either contain constantvalues,values or values that decrease over time to match another lifetime, such as the lifetime of a prefix delegated to the network. In both these cases, this algorithm will refresh on the order of once per address lifetime, which is similar to the number of refreshes that are necessary using stateful DHCPv6.</t> </li> <li> <t>Because refreshes occur at least once per address lifetime, the network administrator can control the address refresh frequency by appropriately setting the Valid Lifetime in thePrefix Information Option.</t>PIO.</t> </li> </ul> </section> <section anchor="statically-assigned-addresses"> <name>Statically Assigned Addresses</name> <t>A statically assigned address has an infinitevalid lifetime whichValid Lifetime that is not affected byRouter Advertisements. ThereforeRAs. Therefore, whenever the client registers or refreshes a statically assigned address, the next refresh is scheduled for StaticAddrRegRefreshInterval seconds in the future. The default value of StaticAddrRegRefreshInterval is 4 hours. This ensures static addresses are still refreshed periodically, but refreshes for static addresses do not cause excessive multicast traffic. The StaticAddrRegRefreshInterval interval <bcp14>SHOULD</bcp14> be configurable.</t> </section> <section anchor="transmitting-refreshes"> <name>Transmitting Refreshes</name> <t>When a refresh is performed, the client <bcp14>MAY</bcp14> refresh all addresses assigned to the interface that are scheduled to be refreshed within the next AddrRegRefreshCoalesce seconds. The value of AddrRegRefreshCoalesce isimplementation-dependent,implementation dependent, and a suggested default is 60 seconds.</t> <t>Registration refresh packets <bcp14>MUST</bcp14> be retransmitted using the same logic as used for initial registrations (seethe 'Retransmission' section above).</t><xref target="retransmission"/>).</t> <t>The client <bcp14>MUST</bcp14> generate a new transaction ID when refreshing the registration.</t> <t>When a Client-Identifier-to-IPv6-address binding expires, the server <bcp14>MUST</bcp14> remove it and consider the address as available for use.</t> <t>The client <bcp14>MAY</bcp14> choose to notify the server when an address is no longer being used (e.g., if the client is 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 usedanymoreanymore, 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 anchor="client-configuration"> <name>Clientconfiguration</name>Configuration</name> <t>DHCP clients <bcp14>SHOULD</bcp14> allow the administrator to disable sending ADDR-REG-INFORM messages. This could be used, for example, to reduce network traffic on networks where the servers are known not to support the message type. Sending the messages <bcp14>SHOULD</bcp14> be enabled by default.</t> </section> <section anchor="security-considerations"> <name>Security Considerations</name> <t>An attacker may attempt to register a large number of addresses in quick succession in order to overwhelm the address registration serverand / orand/or fill up log files. Similar attack vectors exist today, e.g., an attacker can DoS the server with messages containing spoofed DHCP Unique Identifiers (DUIDs) <xref target="RFC8415"/>.</t> <t>If a network is usingFCFS SAVIFirst-Come, First-Served Source Address Validation Improvement (FCFS SAVI) <xref target="RFC6620"/>, then the DHCPv6 server can trust that the ADDR-REG-INFORM message was sent by the legitimate holder of the address. This prevents a client from registering an address configured on another client.</t> <t>One of the use cases for the mechanism described in this document is to identify sources of malicious traffic after the fact. Note, however, that as the device itself is responsible for informing the DHCPv6 server that it is using an address, a malicious or compromised devicecancannot simplynotsend the ADDR-REG-INFORM message. This is an informational, optionalmechanism,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 anchor="privacy-considerations"> <name>Privacy Considerations</name> <t>If the network doesn't haveMLDMulticast Listener Discovery (MLD) snooping enabled, then IPv6 link-local multicast traffic is effectively transmitted as broadcast. In such networks, an on-link attacker listening to DHCPv6 messages might obtain information about IPv6 addresses assigned to the client. As ADDR-REG-INFORM messages contain unique identifiers such as the client's DUID, the attacker may be able to track addresses being registered and map them to the same client, even if the client uses randomized MAC addresses. This privacy consideration is not specific to the proposed mechanism.Section 4.3 of<xreftarget="RFC7844"/>target="RFC7844" sectionFormat="of" section="4.3"/> discusses using the DUID for device tracking in DHCPv6 environments and provides mitigation recommendations.</t> <t>In general, hiding information about the specific IPv6 address from on-link observers should not be considered a security measure, as such information is usually disclosed via Duplicate Address Detection <xref target="RFC4862"/> to all nodes anyway, if MLD snooping is not enabled.</t> <t>If MLD snooping is enabled, an attacker might be able to join the All_DHCP_Relay_Agents_and_Servers multicast address (ff02::1:2) group to listen for address registration messages. However, the same result can be achieved by joining the All Routers Address (ff02::2) group and listen toGratuitous Neighbor Advertisementgratuitous neighbor advertisement messages <xref target="RFC9131"/>. It should be noted that this particular scenario 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 andrelays,relays and therefore obtain the information about addresses being assigned via DHCPv6. Layer 2 isolation allows mitigating this threat by blockingonlinkon-link peer-to-peer communication between nodes.</t> </section> <section anchor="iana-considerations"> <name>IANA Considerations</name> <!-- [rfced] FYI - We have updated the IANA Considerations section to match the registry. Please review and let us know if any further changes are needed. --> <t>This document introduces the followingnew entitiesentities, whichrequire an allocation out ofhave been allocated in theDynamic"Dynamic Host Configuration Protocol for IPv6(DHCPv6)(DHCPv6)" registry group defined athttp://www.iana.org/assignments/dhcpv6-parameters/:</t><eref target="http://www.iana.org/assignments/dhcpv6-parameters" brackets="angle"/>. These include:</t> <ul spacing="normal"> <li><t>one<t>One new DHCPv6 option, described inSection 4.1<xref target="dhcpv6-address-registration-option"/>, whichrequires an allocation out ofhas been allocated in theOption Codes"Option Codes" registry: </t><ul spacing="normal"> <li> <t>Value: TBA0</t> </li> <li> <t>Description: OPTION_ADDR_REG_ENABLE</t><dl newline="false" spacing="compact"> <dt>Value:</dt> <dd>148</dd> <dt>Description:</dt> <dd>OPTION_ADDR_REG_ENABLE</dd> <dt>Client ORO:</dt> <dd>Yes</dd> <dt>Singleton Option:</dt> <dd>Yes</dd> <dt>Reference:</dt> <dd>RFC 9686</dd> </dl> </li> <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> <t>two<t>Two new DHCPv6messagesmessages, whichrequire an allocation out ofhave been allocated in theMessage Types registry:"Message Types" registry (for more information, see Sections <xref target="dhcpv6-address-registration-request-message" format="counter"/> and <xref target="dhcpv6-address-registration-acknowledgement" format="counter"/>, respectively, for each DHCPv6 message): </t><ul spacing="normal"> <li> <t>ADDR-REG-INFORM message (TBA1) described in Section 4.2</t> </li> <li> <t>ADDR-REG-REPLY (TBA2) described in Section 4.3.</t> </li> <li> <t>Reference: This document (draft-ietf-dhc-addr-notification)</t> </li> </ul><dl newline="false" spacing="compact"> <dt>Value:</dt><dd>36</dd> <dt>Description:</dt><dd>ADDR-REG-INFORM</dd> <dt>Reference:</dt><dd>RFC 9686</dd> </dl> <dl newline="false" spacing="compact"> <dt>Value:</dt><dd>37</dd> <dt>Description:</dt><dd>ADDR-REG-REPLY</dd> <dt>Reference:</dt><dd>RFC 9686</dd> </dl> </li> </ul> </section> </middle> <back> <references> <name>References</name> <references anchor="sec-normative-references"> <name>Normative References</name><reference anchor="RFC2119"> <front> <title>Key words for use in RFCs to Indicate Requirement Levels</title> <author fullname="S. Bradner" initials="S." surname="Bradner"/> <date month="March" year="1997"/> <abstract> <t>In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t> </abstract> </front> <seriesInfo name="BCP" value="14"/> <seriesInfo name="RFC" value="2119"/> <seriesInfo name="DOI" value="10.17487/RFC2119"/> </reference> <reference anchor="RFC4007"> <front> <title>IPv6 Scoped Address Architecture</title> <author fullname="S. Deering" initials="S." surname="Deering"/> <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, expected behavior, textual representation, and usage of IPv6 addresses of different scopes. According to a decision in the IPv6 working group, this document intentionally avoids the syntax and usage of unicast site-local addresses. [STANDARDS-TRACK]</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 globally unique and is intended for local communications, usually inside of a site. These addresses are not expected to be routable on the global Internet. [STANDARDS-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 includes generating a link-local address, generating global addresses via stateless address autoconfiguration, and the Duplicate Address Detection procedure to verify the uniqueness of the addresses on a link. [STANDARDS-TRACK]</t> </abstract> </front> <seriesInfo name="RFC" value="4862"/> <seriesInfo name="DOI" value="10.17487/RFC4862"/> </reference> <reference anchor="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 configuration parameters, IP addresses, and prefixes. Parameters can be provided statelessly, or in combination with stateful assignment of one or more IPv6 addresses 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 DHCPv6 specification) and incorporates prefix delegation (RFC 3633), stateless DHCPv6 (RFC 3736), an option to specify an upper bound for how long a client should wait before refreshing information (RFC 4242), a mechanism for throttling DHCPv6 clients when DHCPv6 service is not available (RFC 7083), and relay agent handling of unknown messages (RFC 7283). In addition, this document clarifies the interactions 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 framework for passing configuration information to hosts on a TCPIP network. DHCP is based on the Bootstrap Protocol (BOOTP), adding the capability of automatic allocation of reusable network addresses and additional configuration options. [STANDARDS-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</title> <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 protocol 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) Client 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 Protocol for IPv6 (DHCPv6) option that can be used to exchange information about a DHCPv6 client's Fully Qualified Domain Name (FQDN) and about responsibility for updating DNS resource records (RRs) related to the client's address assignments. [STANDARDS-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 can enable device tracking even if the device administrator takes care of randomizing 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 DHCP or DHCPv6 messages, designed to minimize disclosure of identifying information.</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 Entries 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 determine the link-layer addresses of neighboring nodes as well as to discover and maintain reachability information. This document updates RFC 4861 to allow routers to proactively create a Neighbor Cache entry when a new IPv6 address is assigned to a node. It also updates RFC 4861 and recommends that nodes send unsolicited Neighbor Advertisements upon assigning a new IPv6 address. These changes will minimize 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><xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4007.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4193.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4862.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6939.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8415.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2131.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4704.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7844.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9131.xml"/> </references> <references anchor="sec-informative-references"> <name>Informative References</name><reference anchor="RFC6620"> <front> <title>FCFS SAVI: First-Come, First-Served Source Address Validation Improvement for Locally Assigned IPv6 Addresses</title> <author fullname="E. Nordmark" initials="E." surname="Nordmark"/> <author fullname="M. Bagnulo" initials="M." surname="Bagnulo"/> <author fullname="E. Levy-Abegnoli" initials="E." surname="Levy-Abegnoli"/> <date month="May" year="2012"/> <abstract> <t>This memo describes First-Come, First-Served Source Address Validation Improvement (FCFS SAVI), a mechanism that provides source address validation for IPv6 networks using the FCFS principle. The proposed mechanism is intended 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 other'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><xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6620.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4861.xml"/> </references> </references><?line 423?><section numbered="false"anchor="acknowledgments"> <name>Acknowledgments</name>anchor="acknowledgements"> <name>Acknowledgements</name> <t>Many thanks toBernie Volz<contact fullname="Bernie Volz"/> for the significant review and feedback, as well asHermin Anggawijaya, Carlos<contact fullname="Hermin Anggawijaya"/>, <contact fullname="Carlos JesusBernardos, Brian Carpenter, Stuart Cheshire, Roman Danyliw, Alan DeKok, James Guichard, James Guichard, Erik Kline, Mallory Knodel, Murray Kucherawy, David Lamparter, Ted Lemon, Eric Levy-Abegnoli, Aditi Patange, Jim Reid, Michael Richardson, Patrick Rohr, John Scudder, Mark Smith, GunterBernardos"/>, <contact fullname="Brian Carpenter"/>, <contact fullname="Stuart Cheshire"/>, <contact fullname="Roman Danyliw"/>, <contact fullname="Alan DeKok"/>, <contact fullname="James Guichard"/>, <contact fullname="James Guichard"/>, <contact fullname="Erik Kline"/>, <contact 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 deVelde, Eric Vyncke, Timothy Winters, Peter YeeVelde"/>, <contact fullname="Eric Vyncke"/>, <contact fullname="Timothy Winters"/>, and <contact fullname="Peter Yee"/> for their feedback,commentscomments, and guidance. We apologize if we inadvertently forgot to acknowledge anyone's contributions.</t> </section> <section anchor="contributors" numbered="false"toc="include" removeInRFC="false">toc="include"> <name>Contributors</name> <contact initials="G." surname="Chen" fullname="Gang Chen"> <organization>China Mobile</organization> <address> <postal> <street>53A, Xibianmennei Ave.</street> <street>Xuanwu District</street> <city>Beijing</city><country>P.R. China</country><country>China</country> </postal> <email>phdgang@gmail.com</email> </address> </contact> </section> </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>