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 | |||
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. | ||||
18 lines changed or deleted | 16 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. |