rfc9686.original   rfc9686.txt 
Dynamic Host Configuration W. Kumari Internet Engineering Task Force (IETF) W. Kumari
Internet-Draft Google, LLC Request for Comments: 9686 Google, LLC
Intended status: Standards Track S. Krishnan Category: Standards Track S. Krishnan
Expires: 17 November 2024 Cisco Systems, Inc. ISSN: 2070-1721 Cisco Systems, Inc.
R. Asati R. Asati
Independent Independent
L. Colitti L. Colitti
J. Linkova J. Linkova
Google, LLC Google, LLC
S. Jiang S. Jiang
Beijing University of Posts and Telecommunications Beijing University of Posts and Telecommunications
16 May 2024 October 2024
Registering Self-generated IPv6 Addresses using DHCPv6 Registering Self-Generated IPv6 Addresses Using DHCPv6
draft-ietf-dhc-addr-notification-13
Abstract Abstract
This document defines a method to inform a DHCPv6 server that a This document defines a method to inform a DHCPv6 server that a
device has one or more self-generated or statically configured device has one or more self-generated or statically configured
addresses. addresses.
About This Document
This note is to be removed before publishing as an RFC.
The latest revision of this draft can be found at
https://wkumari.github.io/draft-wkumari-dhc-addr-notification/draft-
ietf-dhc-addr-notification.html. Status information for this
document may be found at https://datatracker.ietf.org/doc/draft-ietf-
dhc-addr-notification/.
Discussion of this document takes place on the Dynamic Host
Configuration Working Group mailing list (mailto:dhcwg@ietf.org),
which is archived at https://mailarchive.ietf.org/arch/browse/dhcwg/.
Subscribe at https://www.ietf.org/mailman/listinfo/dhcwg/.
Source for this draft and an issue tracker can be found at
https://github.com/wkumari/draft-wkumari-dhc-addr-notification.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on 17 November 2024. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9686.
Copyright Notice Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the Copyright (c) 2024 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Revised BSD License text as to this document. Code Components extracted from this document must
described in Section 4.e of the Trust Legal Provisions and are include Revised BSD License text as described in Section 4.e of the
provided without warranty as described in the Revised BSD License. Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction
2. Conventions and Definitions . . . . . . . . . . . . . . . . . 3 2. Conventions and Definitions
3. Registration Mechanism Overview . . . . . . . . . . . . . . . 4 3. Registration Mechanism Overview
4. DHCPv6 Address Registration Procedure . . . . . . . . . . . . 5 4. DHCPv6 Address Registration Procedure
4.1. DHCPv6 Address Registration Option . . . . . . . . . . . 5 4.1. DHCPv6 Address Registration Option
4.2. DHCPv6 Address Registration Request Message . . . . . . . 6 4.2. DHCPv6 Address Registration Request Message
4.2.1. Server message processing . . . . . . . . . . . . . . 8 4.2.1. Server Message Processing
4.3. DHCPv6 Address Registration Acknowledgement . . . . . . . 9 4.3. DHCPv6 Address Registration Acknowledgement
4.4. Signaling Address Registration Support . . . . . . . . . 10 4.4. Signaling Address Registration Support
4.5. Retransmission . . . . . . . . . . . . . . . . . . . . . 11 4.5. Retransmission
4.6. Registration Expiry and Refresh . . . . . . . . . . . . . 11 4.6. Registration Expiry and Refresh
4.6.1. SLAAC Addresses . . . . . . . . . . . . . . . . . . . 12 4.6.1. SLAAC Addresses
4.6.2. Statically Assigned Addresses . . . . . . . . . . . . 13 4.6.2. Statically Assigned Addresses
4.6.3. Transmitting Refreshes . . . . . . . . . . . . . . . 14 4.6.3. Transmitting Refreshes
5. Client configuration . . . . . . . . . . . . . . . . . . . . 14 5. Client Configuration
6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 6. Security Considerations
7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 15 7. Privacy Considerations
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 8. IANA Considerations
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 9. References
9.1. Normative References . . . . . . . . . . . . . . . . . . 16 9.1. Normative References
9.2. Informative References . . . . . . . . . . . . . . . . . 17 9.2. Informative References
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 18 Acknowledgements
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 18 Contributors
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 Authors' Addresses
1. Introduction 1. Introduction
It is very common operational practice, especially in enterprise It is very common operational practice, especially in enterprise
networks, to use IPv4 DHCP logs for troubleshooting or forensics networks, to use IPv4 DHCP logs for troubleshooting or forensics
purposes. Examples of this include a help desk dealing with a ticket purposes. An example of this includes a help desk dealing with a
such as "The CEO's laptop cannot connect to the printer"; if the MAC ticket such as "The CEO's laptop cannot connect to the printer"; if
address of the printer is known (for example from an inventory the Media Access Control (MAC) address of the printer is known (for
system), the printer's IPv4 address can be retrieved from the DHCP example, from an inventory system), the printer's IPv4 address can be
log or lease table and the printer pinged to determine if it is retrieved from the DHCP log or lease table and the printer can be
reachable. Another common example is a Security Operations team pinged to determine if it is reachable. Another common example is a
discovering suspicious events in outbound firewall logs and then security operations team discovering suspicious events in outbound
consulting DHCP logs to determine which employee's laptop had that firewall logs and then consulting DHCP logs to determine which
IPv4 address at that time so that they can quarantine it and remove employee's laptop had that IPv4 address at that time so that they can
the malware. quarantine it and remove the malware.
This operational practice relies on the DHCP server knowing the IP This operational practice relies on the DHCP server knowing the IP
address assignments. This works quite well for IPv4 addresses, as address assignments. This works quite well for IPv4 addresses, as
most addresses are either assigned by DHCP [RFC2131] or statically most addresses are either assigned by DHCP [RFC2131] or statically
configured by the network operator. For IPv6, however, this practice configured by the network operator. For IPv6, however, this practice
is much harder to implement, as devices often self-configure IPv6 is much harder to implement, as devices often self-configure IPv6
addresses via SLAAC [RFC4862]. addresses via Stateless Address Autoconfiguration (SLAAC) [RFC4862].
This document provides a mechanism for a device to inform the DHCPv6 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 server that the device has a self-configured IPv6 address (or has a
statically configured address), and thus provides parity with IPv4, statically configured address), and thus provides parity with IPv4 by
by making DHCPv6 infrastructure aware of self-assigned IPv6 making DHCPv6 infrastructure aware of self-assigned IPv6 addresses.
addresses.
2. Conventions and Definitions 2. Conventions and Definitions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
3. Registration Mechanism Overview 3. Registration Mechanism Overview
The DHCPv6 protocol is used as the address registration protocol when The DHCPv6 protocol is used as the address registration protocol when
a 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 This document introduces a new Address Registration
(OPTION_ADDR_REG_ENABLE) option which indicates that the server (OPTION_ADDR_REG_ENABLE) option, which indicates that the server
supports the registration mechanism. Before registering any supports the registration mechanism. Before registering any
addresses, the client MUST determine whether the network supports addresses, the client MUST determine whether the network supports
address registration. It can do this by including the Address address registration. It can do this by including the Address
Registration option code in the Option Request option (see Registration option code in the Option Request option (see
Section 21.7 of [RFC8415]) of the Information-Request, Solicit, Section 21.7 of [RFC8415]) of the Information-Request, Solicit,
Request, Renew, or Rebind messages it sends to the server as part of Request, Renew, or Rebind messages it sends to the server as part of
the regular stateless or stateful DHCPv6 configuration process. If the regular stateless or stateful DHCPv6 configuration process. If
the server supports address registration, it includes an Address the server supports address registration, it includes an Address
Registration option in its Advertise or Reply messages. To avoid Registration option in its Advertise or Reply messages. To avoid
undesired multicast traffic, if the DHCPv6 infrastructure does not undesired multicast traffic, if the DHCPv6 infrastructure does not
support (or is not willing to receive) any address registration support (or is not willing to receive) any address registration
information, the client MUST NOT register any addresses using the information, the client MUST NOT register any addresses using the
mechanism in this specification. Otherwise, the client registers mechanism in this specification. Otherwise, the client registers
addresses as described below. addresses as described below.
After successfully assigning a self-generated or statically After successfully assigning a self-generated or statically
configured Valid ([RFC4862]) IPv6 address on one of its interfaces, a configured valid IPv6 address [RFC4862] on one of its interfaces, a
client implementing this specification multicasts an ADDR-REG-INFORM client implementing this specification multicasts an ADDR-REG-INFORM
message (see Section 4.2) in order to inform the DHCPv6 server that message (see Section 4.2) in order to inform the DHCPv6 server that
this self-generated address is in use. Each ADDR-REG-INFORM message this self-generated address is in use. Each ADDR-REG-INFORM message
contains a DHCPv6 IA Address option [RFC8415] to specify the address contains a DHCPv6 Identity Association (IA) Address option [RFC8415]
being registered. to specify the address being registered.
The address registration mechanism overview is shown in Fig.1. The address registration mechanism overview is shown in Figure 1.
+--------+ +------------------+ +---------------+ +--------+ +------------------+ +---------------+
| 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 page 5, line 36 skipping to change at line 176
| 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 |
| | | |
Figure 1: Address Registration Procedure Overview Figure 1: Address Registration Procedure Overview
4. DHCPv6 Address Registration Procedure 4. DHCPv6 Address Registration Procedure
4.1. DHCPv6 Address Registration Option 4.1. DHCPv6 Address Registration Option
The Address Registration option (OPTION_ADDR_REG_ENABLE) indicates The Address Registration option (OPTION_ADDR_REG_ENABLE) indicates
that the server supports the mechanism described in this document. that the server supports the mechanism described in this document.
The format of the Address Registration option is described as The format of the Address Registration option is described as
follows: follows:
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) Figure 2: DHCPv6 Address Registration Option
option-len 0 option-code: OPTION_ADDR_REG_ENABLE (148)
Figure 2: DHCPv6 Address Registration option option-len: 0
If a client has the address registration mechanism enabled, it MUST If a client has the address registration mechanism enabled, it MUST
include this option in all Option Request options that it sends. include this option in all Option Request options that it sends.
A server which is configured to support the address registration A server that is configured to support the address registration
mechanism MUST include this option in Advertise and Reply messages if mechanism MUST include this option in Advertise and Reply messages if
the client message it is replying to contained this option in the the client message it is replying to contained this option in the
Option Request option. Option Request option.
4.2. DHCPv6 Address Registration Request Message 4.2. DHCPv6 Address Registration Request Message
The DHCPv6 client sends an ADDR-REG-INFORM message to inform that an 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 IPv6 address is assigned to the client's interface. The format of
the ADDR-REG-INFORM message is described as follows: the ADDR-REG-INFORM message is described as follows:
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;
Set to ADDR-REG-INFORM (TBA1).
transaction-id The transaction ID for this message exchange. Figure 3: DHCPv6 ADDR-REG-INFORM Message
options Options carried in this message. msg-type: Identifies the DHCPv6 message type; set to ADDR-REG-INFORM
(36).
Figure 3: DHCPv6 ADDR-REG-INFORM message transaction-id: The transaction ID for this message exchange.
options: The options carried in this message.
The client MUST generate a transaction ID as described in [RFC8415] The client MUST generate a transaction ID as described in [RFC8415]
and insert this value in the "transaction-id" field. and insert this value in the "transaction-id" field.
The client MUST include the Client Identifier option [RFC8415] in the The client MUST include the Client Identifier option [RFC8415] in the
ADDR-REG-INFORM message. ADDR-REG-INFORM message.
The ADDR-REG-INFORM message MUST NOT contain the Server Identifier The ADDR-REG-INFORM message MUST NOT contain the Server Identifier
option and MUST contain exactly one IA Address option containing the option and MUST contain exactly one IA Address option containing the
address being registered. The valid-lifetime and preferred-lifetime address being registered. The valid-lifetime and preferred-lifetime
fields in the option MUST match the current Valid Lifetime and fields in the option MUST match the current Valid Lifetime and
Preferred Lifetime of the address being registered. Preferred Lifetime of the address being registered.
The ADDR-REG-INFORM message is dedicated for clients to initiate an The ADDR-REG-INFORM message is dedicated for clients to initiate an
address registration request toward an address registration server. address registration request toward an address registration server.
Consequently, clients MUST NOT put any Option Request Option(s) in Consequently, clients MUST NOT put any Option Request option(s) in
the ADDR-REG-INFORM message. Clients MAY include other options, such the ADDR-REG-INFORM message. Clients MAY include other options, such
as the Client FQDN Option [RFC4704]. as the Client FQDN option [RFC4704].
The client sends the DHCPv6 ADDR-REG-INFORM message to the The client sends the DHCPv6 ADDR-REG-INFORM message to the
All_DHCP_Relay_Agents_and_Servers multicast address (ff02::1:2). The All_DHCP_Relay_Agents_and_Servers multicast address (ff02::1:2). The
client MUST send separate messages for each address being registered. client MUST send separate messages for each address being registered.
Unlike other types of messages, which are sent from the link-local Unlike other types of messages, which are sent from the link-local
address of the client, the ADDR-REG-INFORM message MUST be sent from address of the client, the ADDR-REG-INFORM message MUST be sent from
the address being registered. This is primarily for "fate sharing" the address being registered. This is primarily for "fate sharing"
purposes - for example, if the network implements some form of purposes; for example, if the network implements some form of Layer 2
layer-2 security to prevent a client from spoofing other clients' MAC security to prevent a client from spoofing other clients' MAC
addresses, this prevents an attacker from spoofing ADDR-REG-INFORM addresses, this prevents an attacker from spoofing ADDR-REG-INFORM
messages. messages.
On clients with multiple interfaces, the client MUST only send the On clients with multiple interfaces, the client MUST only send the
packet on the network interface that has the address being packet on the network interface that has the address being
registered, even if it has multiple interfaces with different registered, even if it has multiple interfaces with different
addresses. If the same address is configured on multiple interfaces, addresses. If the same address is configured on multiple interfaces,
then the client MUST send ADDR-REG-INFORM each time the address is then the client MUST send the ADDR-REG-INFORM message each time the
configured on an interface that did not previously have it, and address is configured on an interface that did not previously have it
refresh each registration independently from the others. and refresh each registration independently from the others.
The client MUST only send the ADDR-REG-INFORM message for valid The client MUST only send the ADDR-REG-INFORM message for valid
([RFC4862]) addresses of global scope ([RFC4007]). This includes ULA addresses [RFC4862] of global scope [RFC4007]. This includes Unique
addresses, which are defined in [RFC4193] to have global scope. This Local Addresses (ULAs), which are defined in [RFC4193] to have global
also includes statically assigned addresses of global scope (such scope. This also includes statically assigned addresses of global
addresses are considered to be valid indefinitely). The client MUST scope (such addresses are considered to be valid indefinitely). The
NOT send the ADDR-REG-INFORM message for addresses configured by client MUST NOT send the ADDR-REG-INFORM message for addresses
DHCPv6. configured by DHCPv6.
The client SHOULD NOT send the ADDR-REG-INFORM message unless it has The client SHOULD NOT send the ADDR-REG-INFORM message unless it has
received a Router Advertisement message with either M or O flags set received a Router Advertisement (RA) message with either the M or O
to 1. flags set to 1.
Clients MUST discard any received ADDR-REG-INFORM messages. Clients MUST discard any received ADDR-REG-INFORM messages.
4.2.1. Server message processing 4.2.1. Server Message Processing
Servers MUST discard any ADDR-REG-INFORM messages that meet any of Servers MUST discard any ADDR-REG-INFORM messages that meet any of
the following conditions: the following conditions:
* the message does not include a Client Identifier option; * the message does not include a Client Identifier option;
* the message includes a Server Identifier option; * the message includes a Server Identifier option;
* the message does not include the IA Address option, or the IP * the message does not include the IA Address option, or the IP
address in the IA Address option does not match the source address address in the IA Address option does not match the source address
of the original ADDR-REG-INFORM message sent by the client. The of the original ADDR-REG-INFORM message sent by the client. The
source address of the original message is the source IP address of source address of the original message is the source IP address of
the packet if it is not relayed, or the Peer-Address field of the the packet if it is not relayed or is the peer-address field of
innermost Relay-Forward message if it is relayed. the innermost Relay-forward message if it is relayed; or
* the message includes an Option Request Option. * the message includes an Option Request option.
If the message is not discarded, the address registration server If the message is not discarded, the address registration server
SHOULD verify that the address being registered is "appropriate to SHOULD verify that the address being registered is "appropriate to
the link" as defined by [RFC8415] or within a prefix delegated to the the link" as defined by [RFC8415] or within a prefix delegated to the
client via DHCPv6-PD (see Section 6.3 of [RFC8415]). If the address client via DHCPv6 for Prefix Delegation (DHCPv6-PD) (see Section 6.3
being registered fails this verification, the server MUST drop the of [RFC8415]). If the address being registered fails this
message, and SHOULD log this fact. If the message passes the verification, the server MUST drop the message and SHOULD log this
verification, the server: fact. If the message passes the verification, the server:
* MUST log the address registration information (as is done normally * MUST log the address registration information (as is done normally
for clients to which it has assigned an address), unless for clients to which it has assigned an address), unless it is
configured not to do so. The server SHOULD log the client DUID configured not to do so. The server SHOULD log the client DHCP
and the link-layer address, if available. The server MAY log any Unique Identifier (DUID) and the link-layer address, if available.
other information. The server MAY log any other information.
* SHOULD register a binding between the provided Client Identifier * SHOULD register a binding between the provided Client Identifier
and IPv6 address in its database, if no binding exists. The and IPv6 address in its database, if no binding exists. The
lifetime of the binding is equal to the Valid Lifetime of the lifetime of the binding is equal to the Valid Lifetime of the
address reported by the client. If there is already a binding address reported by the client. If there is already a binding
between the registered address and the same client, the server between the registered address and the same client, the server
MUST update its lifetime. If there is already a binding between MUST update its lifetime. If there is already a binding between
the registered address and another client, the server SHOULD log the registered address and another client, the server SHOULD log
the fact and update the binding. the fact and update the binding.
* SHOULD mark the address as unavailable for use and not include it * SHOULD mark the address as unavailable for use and not include it
in future ADVERTISE messages. in future ADVERTISE messages.
* MUST send back an ADDR-REG-REPLY message to ensure the client does * MUST send back an ADDR-REG-REPLY message to ensure the client does
not retransmit. not retransmit.
If a client is multihomed (connected to multiple administrative If a client is multihomed (i.e., connected to multiple administrative
domains, each operating its own DHCPv6 infrastructure), the domains, each operating its own DHCPv6 infrastructure), the
requirement to verify that the registered address is appropriate for requirement to verify that the registered address is appropriate for
the link or belongs to a delegated prefix ensures that each DHCPv6 the link or belongs to a delegated prefix ensures that each DHCPv6
server only registers bindings for addresses from the given server only registers bindings for addresses from the given
administrative domain. administrative domain.
Although a client "MUST NOT send the ADDR-REG-INFORM message for As mentioned in Section 4.2, although a client "MUST NOT send the
addresses configured by DHCPv6", if a server does receive such a ADDR-REG-INFORM message for addresses configured by DHCPv6", if a
message, it SHOULD log and discard it. server does receive such a message, it SHOULD log and discard it.
DHCPv6 relay agents and switches that relay address registration DHCPv6 relay agents and switches that relay address registration
messages directly from clients MUST include the client's link-layer messages directly from clients MUST include the client's link-layer
address in the relayed message using the Client Link-Layer Address address in the relayed message using the Client Link-Layer Address
option ([RFC6939]) if they would do so for other DHCPv6 client option [RFC6939] if they would do so for other DHCPv6 client messages
messages such as SOLICIT, REQUEST, and REBIND. such as SOLICIT, REQUEST, and REBIND.
4.3. DHCPv6 Address Registration Acknowledgement 4.3. DHCPv6 Address Registration Acknowledgement
The server MUST acknowledge receipt of a valid ADDR-REG-INFORM The server MUST acknowledge receipt of a valid ADDR-REG-INFORM
message by sending back an ADDR-REG-REPLY message. The format of the message by sending back an ADDR-REG-REPLY message. The format of the
ADDR-REG-REPLY message is described as follows: ADDR-REG-REPLY message is described as follows:
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;
Set to ADDR-REG-REPLY (TBA2).
transaction-id The transaction ID for this message exchange. Figure 4: DHCPv6 ADDR-REG-REPLY Message
options Options carried in this message. msg-type: Identifies the DHCPv6 message type; set to ADDR-REG-REPLY
(37).
Figure 4: DHCPv6 ADDR-REG-REPLY message transaction-id: The transaction ID for this message exchange.
options: The options carried in this message.
If the ADDR-REG-INFORM message that the server is replying to was not If the ADDR-REG-INFORM message that the server is replying to was not
relayed, then the IPv6 destination address of the message MUST be the relayed, then the IPv6 destination address of the message MUST be the
address being registered. If the ADDR-REG-INFORM message was address being registered. If the ADDR-REG-INFORM message was
relayed, then the server MUST construct the Relay-reply message as relayed, then the server MUST construct the Relay-reply message as
specified in [RFC8415] section 19.3. specified in Section 19.3 of [RFC8415].
The server MUST copy the transaction-id from the ADDR-REG-INFORM The server MUST copy the transaction-id from the ADDR-REG-INFORM
message to the transaction-id field of the ADDR-REG-REPLY. message to the transaction-id field of the ADDR-REG-REPLY.
The ADDR-REG-REPLY message MUST contain an IA Address option for the The ADDR-REG-REPLY message MUST contain an IA Address option for the
address being registered. The option MUST be identical to the one in address being registered. The option MUST be identical to the one in
the ADDR-REG-INFORM message that the server is replying to. the ADDR-REG-INFORM message that the server is replying to.
Servers MUST ignore any received ADDR-REG-REPLY messages. Servers MUST ignore any received ADDR-REG-REPLY messages.
Clients MUST discard any ADDR-REG-REPLY messages that meet any of the Clients MUST discard any ADDR-REG-REPLY messages that meet any of the
following conditions: following conditions:
* The IPv6 destination address does not match the address being * the IPv6 destination address does not match the address being
registered. registered;
* The IA Address option does not match the address being registered. * the IA Address option does not match the address being registered;
* The address being registered is not assigned to the interface * the address being registered is not assigned to the interface
receiving the message. receiving the message; or
* The transaction-id does not match the transaction-id the client * the transaction-id does not match the transaction-id the client
used in the corresponding ADDR-REG-INFORM message. used in the corresponding ADDR-REG-INFORM message.
The ADDR-REG-REPLY message only indicates that the ADDR-REG-INFORM The ADDR-REG-REPLY message only indicates that the ADDR-REG-INFORM
message has been received and that the client should not retransmit message has been received and that the client should not retransmit
it. The ADDR-REG-REPLY message MUST NOT be considered as any it. The ADDR-REG-REPLY message MUST NOT be considered to be any
indication of the address validity and MUST NOT be required for the indication of the address validity and MUST NOT be required for the
address to be usable. DHCPv6 relays, or other devices that snoop address to be usable. DHCPv6 relays, or other devices that snoop
ADDR-REG-REPLY messages, MUST NOT add or alter any forwarding or ADDR-REG-REPLY messages, MUST NOT add or alter any forwarding or
security state based on the ADDR-REG-REPLY message. security state based on the ADDR-REG-REPLY message.
4.4. Signaling Address Registration Support 4.4. Signaling Address Registration Support
To avoid undesired multicast traffic, the client MUST NOT register To avoid undesired multicast traffic, the client MUST NOT register
addresses using this mechanism unless the DHCPv6 infrastructure addresses using this mechanism unless the DHCPv6 infrastructure
supports address registration. The client can discover this by supports address registration. The client can discover this by
skipping to change at page 11, line 10 skipping to change at line 434
use. Once the client starts the registration process, it MUST NOT use. Once the client starts the registration process, it MUST NOT
stop registering addresses until it disconnects from the link, even stop registering addresses until it disconnects from the link, even
if subsequent Advertise or Reply messages do not contain the if subsequent Advertise or Reply messages do not contain the
OPTION_ADDR_REG_ENABLE option. OPTION_ADDR_REG_ENABLE option.
The client MUST discover whether the DHCPv6 infrastructure supports The client MUST discover whether the DHCPv6 infrastructure supports
address registration every time it connects to a network or when it address registration every time it connects to a network or when it
detects it has moved to a new link, without utilizing any prior detects it has moved to a new link, without utilizing any prior
knowledge about address registration support on that network or link. knowledge about address registration support on that network or link.
This client behavior allows networks to progressively roll out This client behavior allows networks to progressively roll out
support for the address registration option across the DHCPv6 support for the Address Registration option across the DHCPv6
infrastructure without causing clients to frequently stop and restart infrastructure without causing clients to frequently stop and restart
address registration if some of the network's DHCPv6 servers support address registration if some of the network's DHCPv6 servers support
it and some of them do not. it and some do not.
A client with multiple interfaces MUST discover address registration A client with multiple interfaces MUST discover address registration
support for each interface independently. The client MUST NOT send support for each interface independently. The client MUST NOT send
address registration messsages on a given interface unless the client address registration messages on a given interface unless the client
has discovered that the interface is connected to a network which has discovered that the interface is connected to a network that
supports address registration. supports address registration.
4.5. Retransmission 4.5. Retransmission
To reduce the effects of packet loss on registration, the client MUST To reduce the effects of packet loss on registration, the client MUST
retransmit the registration message. Retransmissions SHOULD follow retransmit the registration message. Retransmissions SHOULD follow
the standard retransmission logic specified by section 15 of the standard retransmission logic specified by Section 15 of
[RFC8415] with the following default parameters: [RFC8415] with the following default parameters:
* IRT 1 sec * IRT 1 sec
* MRC 3 * MRC 3
The client SHOULD allow these parameters to be configured by the The client SHOULD allow these parameters to be configured by the
administrator. administrator.
To comply with section 16.1 of [RFC8415], the client MUST leave the To comply with Section 16.1 of [RFC8415], the client MUST leave the
transaction ID unchanged in retransmissions of an ADDR-REG-INFORM transaction ID unchanged in retransmissions of an ADDR-REG-INFORM
message. When the client retransmits the registration message, the message. When the client retransmits the registration message, the
lifetimes in the packet MUST be updated so that they match the lifetimes in the packet MUST be updated so that they match the
current lifetimes of the address. current lifetimes of the address.
If an ADDR-REG-REPLY message is received for the address being If an ADDR-REG-REPLY message is received for the address being
registered, the client MUST stop retransmission. registered, the client MUST stop retransmission.
4.6. Registration Expiry and Refresh 4.6. Registration Expiry and Refresh
The client MUST refresh registrations to ensure that the server is The client MUST refresh registrations to ensure that the server is
always aware of which addresses are still valid. The client SHOULD always aware of which addresses are still valid. The client SHOULD
perform refreshes as described below. perform refreshes as described below.
4.6.1. SLAAC Addresses 4.6.1. SLAAC Addresses
For an address configured using SLAAC, a function For an address configured using SLAAC, a function
AddrRegRefreshInterval(address) is defined as 80% of the address's AddrRegRefreshInterval(address) is defined as 80% of the address's
current Valid Lifetime. When calculating this value, the client current Valid Lifetime. When calculating this value, the client
applies a multiplier of AddrRegDesyncMultiplier to avoid applies a multiplier of AddrRegDesyncMultiplier to avoid
synchronization causing a large number of registration messages from synchronization, causing a large number of registration messages from
different clients at the same time. AddrRegDesyncMultiplier is a different clients at the same time. AddrRegDesyncMultiplier is a
random value uniformly distributed between 0.9 and 1.1 (inclusive) random value uniformly distributed between 0.9 and 1.1 (inclusive)
and is chosen by the client when it starts the registration process, and is chosen by the client when it starts the registration process
to ensure that refreshes for addresses with the same lifetime are to ensure that refreshes for addresses with the same lifetime are
coalesced (see below). coalesced (see below).
Whenever the client registers or refreshes an address, it calculates Whenever the client registers or refreshes an address, it calculates
a NextAddrRegRefreshTime for that address as AddrRegRefreshInterval a NextAddrRegRefreshTime for that address as AddrRegRefreshInterval
seconds in the future but does not schedule any refreshes. seconds in the future but does not schedule any refreshes.
Whenever the network changes the Valid Lifetime of an existing Whenever the network changes the Valid Lifetime of an existing
address by more than 1%, for example, by sending a Prefix Information address by more than 1%, for example, by sending a Prefix Information
option (PIO, [RFC4861]) with a new Valid Lifetime, the client Option (PIO) [RFC4861] with a new Valid Lifetime, the client
calculates a new AddrRegRefreshInterval. The client schedules a calculates a new AddrRegRefreshInterval. The client schedules a
refresh for min(now + AddrRegRefreshInterval, refresh for min(now + AddrRegRefreshInterval,
NextAddrRegRefreshTime). If the refresh would be scheduled in the NextAddrRegRefreshTime). If the refresh would be scheduled in the
past, then the refresh occurs immediately. past, then the refresh occurs immediately.
Justification: this algorithm ensures that refreshes are not sent too Justification: This algorithm ensures that refreshes are not sent too
frequently, while ensuring that the server never believes that the frequently while ensuring that the server never believes that the
address has expired when it has not. Specifically, after every address has expired when it has not. Specifically, after every
registration: registration:
* If the network never changes the lifetime of an address (e.g., if * 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 no further PIOs are received, or if all PIO lifetimes decrease in
step with the passage of time), then no refreshes occur. step with the passage of time), then no refreshes occur.
Refreshes are not necessary, because the address expires at the Refreshes are not necessary, because the address expires at the
time the server expects it to expire. time the server expects it to expire.
* Any time the network changes the lifetime of an address (i.e., * Any time the network changes the lifetime of an address (i.e.,
changes the time at which the address will expire) the client changes the time at which the address will expire), the client
ensures that a refresh is scheduled, so that server will be ensures that a refresh is scheduled, so that server will be
informed of the new expiry. informed of the new expiry.
* Because AddrRegDesyncMultiplier is at most 1.1, the refresh never * Because AddrRegDesyncMultiplier is at most 1.1, the refresh never
occurs later than a point 88% between the time when the address occurs later than a point 88% between the time when the address
was registered and the time when the address will expire. This was registered and the time when the address will expire. This
allows the client to retransmit the registration for up to 12% of allows the client to retransmit the registration for up to 12% of
the original interval before it expires. This may not be possible the original interval before it expires. This may not be possible
if the network sends a Router Advertisement (RA, [RFC4861]) very if the network sends a Router Advertisement (RA) [RFC4861] very
close to the time when the address would have expired. In this close to the time when the address would have expired. In this
case, the client refreshes immediately, which is the best it can case, the client refreshes immediately, which is the best it can
do. do.
* The 1% tolerance ensures that the client will not refresh or * The 1% tolerance ensures that the client will not refresh or
reschedule refreshes if the Valid Lifetime experiences minor reschedule refreshes if the Valid Lifetime experiences minor
changes due to transmission delays or clock skew between the changes due to transmission delays or clock skew between the
client and the router(s) sending the Router Advertisement. client and the router(s) sending the RA.
* AddrRegRefreshCoalesce (Section 4.6.3) allows battery-powered * AddrRegRefreshCoalesce (Section 4.6.3) allows battery-powered
clients to wake up less often. In particular, it allows the clients to wake up less often. In particular, it allows the
client to coalesce refreshes for multiple addresses formed from client to coalesce refreshes for multiple addresses formed from
the same prefix, such as the stable and privacy addresses. Higher the same prefix, such as the stable and privacy addresses. Higher
values will result in fewer wakeups, but may result in more values will result in fewer wakeups but may result in more network
network traffic, because if a refresh is sent early, then the next traffic, because if a refresh is sent early, then the next RA
RA received will cause the client to immediately send a refresh received will cause the client to immediately send a refresh
message. message.
* In typical networks, the lifetimes in periodic Router * In typical networks, the lifetimes in periodic RAs either contain
Advertisements either contain constant values, or values that constant values or values that decrease over time to match another
decrease over time to match another lifetime, such as the lifetime lifetime, such as the lifetime of a prefix delegated to the
of a prefix delegated to the network. In both these cases, this network. In both these cases, this algorithm will refresh on the
algorithm will refresh on the order of once per address lifetime, order of once per address lifetime, which is similar to the number
which is similar to the number of refreshes that are necessary of refreshes that are necessary using stateful DHCPv6.
using stateful DHCPv6.
* Because refreshes occur at least once per address lifetime, the * Because refreshes occur at least once per address lifetime, the
network administrator can control the address refresh frequency by network administrator can control the address refresh frequency by
appropriately setting the Valid Lifetime in the Prefix Information appropriately setting the Valid Lifetime in the PIO.
Option.
4.6.2. Statically Assigned Addresses 4.6.2. Statically Assigned Addresses
A statically assigned address has an infinite valid lifetime which is A statically assigned address has an infinite Valid Lifetime that is
not affected by Router Advertisements. Therefore whenever the client not affected by RAs. Therefore, whenever the client registers or
registers or refreshes a statically assigned address, the next refreshes a statically assigned address, the next refresh is
refresh is scheduled for StaticAddrRegRefreshInterval seconds in the scheduled for StaticAddrRegRefreshInterval seconds in the future.
future. The default value of StaticAddrRegRefreshInterval is 4 The default value of StaticAddrRegRefreshInterval is 4 hours. This
hours. This ensures static addresses are still refreshed ensures static addresses are still refreshed periodically, but
periodically, but refreshes for static addresses do not cause refreshes for static addresses do not cause excessive multicast
excessive multicast traffic. The StaticAddrRegRefreshInterval traffic. The StaticAddrRegRefreshInterval interval SHOULD be
interval SHOULD be configurable. configurable.
4.6.3. Transmitting Refreshes 4.6.3. Transmitting Refreshes
When a refresh is performed, the client MAY refresh all addresses When a refresh is performed, the client MAY refresh all addresses
assigned to the interface that are scheduled to be refreshed within assigned to the interface that are scheduled to be refreshed within
the next AddrRegRefreshCoalesce seconds. The value of the next AddrRegRefreshCoalesce seconds. The value of
AddrRegRefreshCoalesce is implementation-dependent, and a suggested AddrRegRefreshCoalesce is implementation dependent, and a suggested
default is 60 seconds. default is 60 seconds.
Registration refresh packets MUST be retransmitted using the same Registration refresh packets MUST be retransmitted using the same
logic as used for initial registrations (see the 'Retransmission' logic as used for initial registrations (see Section 4.5).
section above).
The client MUST generate a new transaction ID when refreshing the The client MUST generate a new transaction ID when refreshing the
registration. registration.
When a Client-Identifier-to-IPv6-address binding expires, the server When a Client-Identifier-to-IPv6-address binding expires, the server
MUST remove it and consider the address as available for use. MUST remove it and consider the address as available for use.
The client MAY choose to notify the server when an address is no The client MAY choose to notify the server when an address is no
longer being used (e.g., if the client is disconnecting from the longer being used (e.g., if the client is disconnecting from the
network, the address lifetime expired, or the address is being network, the address lifetime expired, or the address is being
removed from the interface). To indicate that the address is not removed from the interface). To indicate that the address is not
being used anymore the client MUST set the preferred-lifetime and being used anymore, the client MUST set the preferred-lifetime and
valid-lifetime fields of the IA Address option in the ADDR-REG-INFORM 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- message to zero. If the server receives a message with a valid-
lifetime of zero, it MUST act as if the address has expired. lifetime of zero, it MUST act as if the address has expired.
5. Client configuration 5. Client Configuration
DHCP clients SHOULD allow the administrator to disable sending ADDR- DHCP clients SHOULD allow the administrator to disable sending ADDR-
REG-INFORM messages. This could be used, for example, to reduce REG-INFORM messages. This could be used, for example, to reduce
network traffic on networks where the servers are known not to network traffic on networks where the servers are known not to
support the message type. Sending the messages SHOULD be enabled by support the message type. Sending the messages SHOULD be enabled by
default. default.
6. Security Considerations 6. Security Considerations
An attacker may attempt to register a large number of addresses in An attacker may attempt to register a large number of addresses in
quick succession in order to overwhelm the address registration quick succession in order to overwhelm the address registration
server and / or fill up log files. Similar attack vectors exist server and/or fill up log files. Similar attack vectors exist today,
today, e.g., an attacker can DoS the server with messages containing e.g., an attacker can DoS the server with messages containing spoofed
spoofed DHCP Unique Identifiers (DUIDs) [RFC8415]. DHCP Unique Identifiers (DUIDs) [RFC8415].
If a network is using FCFS SAVI [RFC6620], then the DHCPv6 server can If a network is using First-Come, First-Served Source Address
trust that the ADDR-REG-INFORM message was sent by the legitimate Validation Improvement (FCFS SAVI) [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 holder of the address. This prevents a client from registering an
address configured on another client. address configured on another client.
One of the use cases for the mechanism described in this document is One of the use cases for the mechanism described in this document is
to identify sources of malicious traffic after the fact. Note, to identify sources of malicious traffic after the fact. Note,
however, that as the device itself is responsible for informing the however, that as the device itself is responsible for informing the
DHCPv6 server that it is using an address, a malicious or compromised DHCPv6 server that it is using an address, a malicious or compromised
device can simply not send the ADDR-REG-INFORM message. This is an device cannot simply send the ADDR-REG-INFORM message. This is an
informational, optional mechanism, and is designed to aid in informational, optional mechanism and is designed to aid in
troubleshooting and forensics. On its own, it is not intended to be troubleshooting and forensics. On its own, it is not intended to be
a strong security access mechanism. In particular, the ADDR-REG- a strong security access mechanism. In particular, the ADDR-REG-
INFORM message MUST NOT be used for authentication and authorization INFORM message MUST NOT be used for authentication and authorization
purposes, because in addition to the reasons above, the packets purposes, because in addition to the reasons above, the packets
containing the message may be dropped. containing the message may be dropped.
7. Privacy Considerations 7. Privacy Considerations
If the network doesn't have MLD snooping enabled, then IPv6 link- If the network doesn't have Multicast Listener Discovery (MLD)
local multicast traffic is effectively transmitted as broadcast. In snooping enabled, then IPv6 link-local multicast traffic is
such networks, an on-link attacker listening to DHCPv6 messages might effectively transmitted as broadcast. In such networks, an on-link
obtain information about IPv6 addresses assigned to the client. As attacker listening to DHCPv6 messages might obtain information about
ADDR-REG-INFORM messages contain unique identifiers such as the IPv6 addresses assigned to the client. As ADDR-REG-INFORM messages
client's DUID, the attacker may be able to track addresses being contain unique identifiers such as the client's DUID, the attacker
registered and map them to the same client, even if the client uses may be able to track addresses being registered and map them to the
randomized MAC addresses. This privacy consideration is not specific same client, even if the client uses randomized MAC addresses. This
to the proposed mechanism. Section 4.3 of [RFC7844] discusses using privacy consideration is not specific to the proposed mechanism.
the DUID for device tracking in DHCPv6 environments and provides Section 4.3 of [RFC7844] discusses using the DUID for device tracking
mitigation recommendations. in DHCPv6 environments and provides mitigation recommendations.
In general, hiding information about the specific IPv6 address from In general, hiding information about the specific IPv6 address from
on-link observers should not be considered a security measure, as on-link observers should not be considered a security measure, as
such information is usually disclosed via Duplicate Address Detection such information is usually disclosed via Duplicate Address Detection
[RFC4862] to all nodes anyway, if MLD snooping is not enabled. [RFC4862] to all nodes anyway, if MLD snooping is not enabled.
If MLD snooping is enabled, an attacker might be able to join the 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 All_DHCP_Relay_Agents_and_Servers multicast address (ff02::1:2) group
to listen for address registration messages. However, the same to listen for address registration messages. However, the same
result can be achieved by joining the All Routers Address (ff02::2) result can be achieved by joining the All Routers Address (ff02::2)
group and listen to Gratuitous Neighbor Advertisement messages group and listen to gratuitous neighbor advertisement messages
[RFC9131]. It should be noted that this particular scenario shares [RFC9131]. It should be noted that this particular scenario shares
the fate with DHCPv6 address assignment: if an attacker can join the the fate with DHCPv6 address assignment: if an attacker can join the
All_DHCP_Relay_Agents_and_Servers multicast group, they would be able All_DHCP_Relay_Agents_and_Servers multicast group, they would be able
to monitor all DHCPv6 messages sent from the client to DHCPv6 servers to monitor all DHCPv6 messages sent from the client to DHCPv6 servers
and relays, and therefore obtain the information about addresses and relays and therefore obtain the information about addresses being
being assigned via DHCPv6. Layer 2 isolation allows mitigating this assigned via DHCPv6. Layer 2 isolation allows mitigating this threat
threat by blocking onlink peer-to-peer communication between nodes. by blocking on-link peer-to-peer communication between nodes.
8. IANA Considerations 8. IANA Considerations
This document introduces the following new entities which require an This document introduces the following entities, which have been
allocation out of the Dynamic Host Configuration Protocol for IPv6 allocated in the "Dynamic Host Configuration Protocol for IPv6
(DHCPv6) registry group defined at http://www.iana.org/assignments/ (DHCPv6)" registry group defined at <http://www.iana.org/assignments/
dhcpv6-parameters/: dhcpv6-parameters>. These include:
* one new DHCPv6 option, described in Section 4.1 which requires an
allocation out of the Option Codes registry:
- Value: TBA0
- Description: OPTION_ADDR_REG_ENABLE
- Client ORO: Yes
- Singleton Option: Yes
- Reference: This document (draft-ietf-dhc-addr-notification) * One new DHCPv6 option, described in Section 4.1, which has been
allocated in the "Option Codes" registry:
* two new DHCPv6 messages which require an allocation out of the Value: 148
Message Types registry: Description: OPTION_ADDR_REG_ENABLE
Client ORO: Yes
Singleton Option: Yes
Reference: RFC 9686
- ADDR-REG-INFORM message (TBA1) described in Section 4.2 * Two new DHCPv6 messages, which have been allocated in the "Message
Types" registry (for more information, see Sections 4.2 and 4.3,
respectively, for each DHCPv6 message):
- ADDR-REG-REPLY (TBA2) described in Section 4.3. Value: 36
Description: ADDR-REG-INFORM
Reference: RFC 9686
- Reference: This document (draft-ietf-dhc-addr-notification) Value: 37
Description: ADDR-REG-REPLY
Reference: RFC 9686
9. References 9. References
9.1. Normative References 9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", [RFC2131] Droms, R., "Dynamic Host Configuration Protocol",
RFC 2131, DOI 10.17487/RFC2131, March 1997, RFC 2131, DOI 10.17487/RFC2131, March 1997,
<https://www.rfc-editor.org/rfc/rfc2131>. <https://www.rfc-editor.org/info/rfc2131>.
[RFC4007] Deering, S., Haberman, B., Jinmei, T., Nordmark, E., and [RFC4007] Deering, S., Haberman, B., Jinmei, T., Nordmark, E., and
B. Zill, "IPv6 Scoped Address Architecture", RFC 4007, B. Zill, "IPv6 Scoped Address Architecture", RFC 4007,
DOI 10.17487/RFC4007, March 2005, DOI 10.17487/RFC4007, March 2005,
<https://www.rfc-editor.org/rfc/rfc4007>. <https://www.rfc-editor.org/info/rfc4007>.
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005,
<https://www.rfc-editor.org/rfc/rfc4193>. <https://www.rfc-editor.org/info/rfc4193>.
[RFC4704] Volz, B., "The Dynamic Host Configuration Protocol for [RFC4704] Volz, B., "The Dynamic Host Configuration Protocol for
IPv6 (DHCPv6) Client Fully Qualified Domain Name (FQDN) IPv6 (DHCPv6) Client Fully Qualified Domain Name (FQDN)
Option", RFC 4704, DOI 10.17487/RFC4704, October 2006, Option", RFC 4704, DOI 10.17487/RFC4704, October 2006,
<https://www.rfc-editor.org/rfc/rfc4704>. <https://www.rfc-editor.org/info/rfc4704>.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862, Address Autoconfiguration", RFC 4862,
DOI 10.17487/RFC4862, September 2007, DOI 10.17487/RFC4862, September 2007,
<https://www.rfc-editor.org/rfc/rfc4862>. <https://www.rfc-editor.org/info/rfc4862>.
[RFC6939] Halwasia, G., Bhandari, S., and W. Dec, "Client Link-Layer [RFC6939] Halwasia, G., Bhandari, S., and W. Dec, "Client Link-Layer
Address Option in DHCPv6", RFC 6939, DOI 10.17487/RFC6939, Address Option in DHCPv6", RFC 6939, DOI 10.17487/RFC6939,
May 2013, <https://www.rfc-editor.org/rfc/rfc6939>. May 2013, <https://www.rfc-editor.org/info/rfc6939>.
[RFC7844] Huitema, C., Mrugalski, T., and S. Krishnan, "Anonymity [RFC7844] Huitema, C., Mrugalski, T., and S. Krishnan, "Anonymity
Profiles for DHCP Clients", RFC 7844, Profiles for DHCP Clients", RFC 7844,
DOI 10.17487/RFC7844, May 2016, DOI 10.17487/RFC7844, May 2016,
<https://www.rfc-editor.org/rfc/rfc7844>. <https://www.rfc-editor.org/info/rfc7844>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., [RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A.,
Richardson, M., Jiang, S., Lemon, T., and T. Winters, Richardson, M., Jiang, S., Lemon, T., and T. Winters,
"Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)",
RFC 8415, DOI 10.17487/RFC8415, November 2018, RFC 8415, DOI 10.17487/RFC8415, November 2018,
<https://www.rfc-editor.org/rfc/rfc8415>. <https://www.rfc-editor.org/info/rfc8415>.
[RFC9131] Linkova, J., "Gratuitous Neighbor Discovery: Creating [RFC9131] Linkova, J., "Gratuitous Neighbor Discovery: Creating
Neighbor Cache Entries on First-Hop Routers", RFC 9131, Neighbor Cache Entries on First-Hop Routers", RFC 9131,
DOI 10.17487/RFC9131, October 2021, DOI 10.17487/RFC9131, October 2021,
<https://www.rfc-editor.org/rfc/rfc9131>. <https://www.rfc-editor.org/info/rfc9131>.
9.2. Informative References 9.2. Informative References
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
DOI 10.17487/RFC4861, September 2007, DOI 10.17487/RFC4861, September 2007,
<https://www.rfc-editor.org/rfc/rfc4861>. <https://www.rfc-editor.org/info/rfc4861>.
[RFC6620] Nordmark, E., Bagnulo, M., and E. Levy-Abegnoli, "FCFS [RFC6620] Nordmark, E., Bagnulo, M., and E. Levy-Abegnoli, "FCFS
SAVI: First-Come, First-Served Source Address Validation SAVI: First-Come, First-Served Source Address Validation
Improvement for Locally Assigned IPv6 Addresses", Improvement for Locally Assigned IPv6 Addresses",
RFC 6620, DOI 10.17487/RFC6620, May 2012, RFC 6620, DOI 10.17487/RFC6620, May 2012,
<https://www.rfc-editor.org/rfc/rfc6620>. <https://www.rfc-editor.org/info/rfc6620>.
Acknowledgments Acknowledgements
Many thanks to Bernie Volz for significant review and feedback, as Many thanks to Bernie Volz for the significant review and feedback,
well as Hermin Anggawijaya, Carlos Jesus Bernardos, Brian Carpenter, as well as Hermin Anggawijaya, Carlos Jesus Bernardos, Brian
Stuart Cheshire, Roman Danyliw, Alan DeKok, James Guichard, James Carpenter, Stuart Cheshire, Roman Danyliw, Alan DeKok, James
Guichard, Erik Kline, Mallory Knodel, Murray Kucherawy, David Guichard, James Guichard, Erik Kline, Mallory Knodel, Murray
Lamparter, Ted Lemon, Eric Levy-Abegnoli, Aditi Patange, Jim Reid, Kucherawy, David Lamparter, Ted Lemon, Eric Levy-Abegnoli, Aditi
Michael Richardson, Patrick Rohr, John Scudder, Mark Smith, Gunter Patange, Jim Reid, Michael Richardson, Patrick Rohr, John Scudder,
Van de Velde, Eric Vyncke, Timothy Winters, Peter Yee for their Mark Smith, Gunter Van de Velde, Eric Vyncke, Timothy Winters, and
feedback, comments and guidance. We apologize if we inadvertently Peter Yee for their feedback, comments, and guidance. We apologize
forgot to acknowledge anyone's contributions. if we inadvertently forgot to acknowledge anyone's contributions.
Contributors Contributors
Gang Chen Gang Chen
China Mobile China Mobile
53A, Xibianmennei Ave. 53A, Xibianmennei Ave.
Xuanwu District Xuanwu District
Beijing Beijing
P.R. China China
Email: phdgang@gmail.com Email: phdgang@gmail.com
Authors' Addresses Authors' Addresses
Warren Kumari Warren Kumari
Google, LLC Google, LLC
Email: warren@kumari.net Email: warren@kumari.net
Suresh Krishnan Suresh Krishnan
Cisco Systems, Inc. Cisco Systems, Inc.
 End of changes. 97 change blocks. 
250 lines changed or deleted 227 lines changed or added

This html diff was produced by rfcdiff 1.48.