rfc9686v2.txt   rfc9686.txt 
skipping to change at line 116 skipping to change at line 116
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 and
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
skipping to change at line 417 skipping to change at line 417
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
including using the OPTION_ADDR_REG_ENABLE option in the Option including the OPTION_ADDR_REG_ENABLE option in the Option Request
Request options that it sends. If the client receives and processes options that it sends. If the client receives and processes an
an Advertise or Reply message with the OPTION_ADDR_REG_ENABLE option, Advertise or Reply message with the OPTION_ADDR_REG_ENABLE option, it
it concludes that the DHCPv6 infrastructure supports address concludes that the DHCPv6 infrastructure supports address
registration. When the client detects address registration support, registration. When the client detects address registration support,
it MUST start the registration process (unless configured not to do it MUST start the registration process (unless configured not to do
so) and MUST immediately register any addresses that are already in so) and MUST immediately register any addresses that are already in
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
skipping to change at line 481 skipping to change at line 481
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 with other clients, which could cause a large number
different clients at the same time. AddrRegDesyncMultiplier is a of registration messages to reach the server at the same time.
random value uniformly distributed between 0.9 and 1.1 (inclusive) AddrRegDesyncMultiplier is a random value uniformly distributed
and is chosen by the client when it starts the registration process between 0.9 and 1.1 (inclusive) and is chosen by the client when it
to ensure that refreshes for addresses with the same lifetime are starts the registration process, to ensure that refreshes for
coalesced (see below). addresses with the same lifetime are 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,
skipping to change at line 592 skipping to change at line 592
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. Sending the messages SHOULD be enabled by
network traffic on networks where the servers are known not to
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 today, server and/or fill up log files. Similar attack vectors exist today,
e.g., an attacker can DoS the server with messages containing spoofed e.g., an attacker can DoS the server with messages containing spoofed
DHCP Unique Identifiers (DUIDs) [RFC8415]. DHCP Unique Identifiers (DUIDs) [RFC8415].
If a network is using First-Come, First-Served Source Address If a network is using First-Come, First-Served Source Address
Validation Improvement (FCFS SAVI) [RFC6620], then the DHCPv6 server Validation Improvement (FCFS SAVI) [RFC6620], then the DHCPv6 server
can trust that the ADDR-REG-INFORM message was sent by the legitimate 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 cannot simply send the ADDR-REG-INFORM message. This is an device can simply choose to not send the ADDR-REG-INFORM message.
informational, optional mechanism and is designed to aid in This is an informational, optional mechanism and is designed to aid
troubleshooting and forensics. On its own, it is not intended to be in troubleshooting and forensics. On its own, it is not intended to
a strong security access mechanism. In particular, the ADDR-REG- be 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 Multicast Listener Discovery (MLD) If the network doesn't have Multicast Listener Discovery (MLD)
snooping enabled, then IPv6 link-local multicast traffic is snooping enabled, then IPv6 link-local multicast traffic is
effectively transmitted as broadcast. In such networks, an on-link effectively transmitted as broadcast. In such networks, an on-link
attacker listening to DHCPv6 messages might obtain information about attacker listening to DHCPv6 messages might obtain information about
 End of changes. 5 change blocks. 
19 lines changed or deleted 17 lines changed or added

This html diff was produced by rfcdiff 1.48.