RFC 9686
Registering Self-Generated IPv6 Addresses Using DHCPv6
RFC 9686: Registering Self-Generated IPv6 Addresses Using DHCPv6 🎀
Okay bestie, this is RFC 9686, and it's giving main character energy 💅 It's an IETF Standards Track document from December 2024, with ISSN 2070-1721. It's been reviewed publicly and approved by the IESG, so it's official. ✨
- Authors: W. Kumari (Google, LLC), S. Krishnan (Cisco Systems, Inc.), R. Asati (Independent), L. Colitti (Google, LLC), J. Linkova (Google, LLC), and S. Jiang (BUPT)
- Category: Standards Track
- Date: December 2024
- Obsoletes and updates: the header doesn't list anything this one obsoletes or updates 🦋
Abstract 💖
So the big idea is that this doc gives you a way to tell a DHCPv6 server that a device has one or more addresses it made itself (self-generated) or that were set up by hand (statically configured). 🫶
Status of This Memo 🌸
This is an Internet Standards Track document, so it's an official standard, not just a suggestion 👑 It's a product of the IETF and it represents the consensus of the IETF community. It went through public review and got approved for publication by the Internet Engineering Steering Group (IESG). If you want more on Internet Standards, check out Section 2 of RFC 7841.
For the current status, any errata, and how to send feedback, go to https://www.rfc-editor.org/info/rfc9686 🧚
Copyright Notice 🌈
Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. ⭐
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents, which you can find at https://trustee.ietf.org/license-info (as they stood on the publication date). Read them carefully, because they explain your rights and restrictions with respect to this document 🙈 Any Code Components pulled out of this document must include Revised BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as described in the Revised BSD License.
Table of Contents 🍓
1. Introduction
2. Conventions and Definitions
3. Registration Mechanism Overview
4. DHCPv6 Address Registration Procedure
4.1. DHCPv6 Address Registration Option
4.2. DHCPv6 Address Registration Request Message
4.2.1. Server Message Processing
4.3. DHCPv6 Address Registration Acknowledgement
4.4. Signaling Address Registration Support
4.5. Retransmission
4.6. Registration Expiry and Refresh
4.6.1. SLAAC Addresses
4.6.2. Statically Assigned Addresses
4.6.3. Transmitting Refreshes
5. Client Configuration
6. Security Considerations
7. Privacy Considerations
8. IANA Considerations
9. References
9.1. Normative References
9.2. Informative References
Acknowledgements
Contributors
Authors' Addresses1. Introduction ✨
Okay so this is the part where we set the scene. Using IPv4 DHCP logs for troubleshooting and forensics is super common in ops, especially in enterprise networks 💼 Picture a help desk ticket that says "The CEO's laptop cannot connect to the printer" 😭 If you know the printer's Media Access Control (MAC) address (maybe from an inventory system), you can look up its IPv4 address in the DHCP log or lease table and then ping it to see if it's reachable. Another example: a security ops team spots something sketchy in outbound firewall logs, then checks DHCP logs to figure out which employee's laptop had that IP at that exact time so they can quarantine it and remove the malware 🔥
This whole workflow depends on the DHCP server knowing the IP address assignments. It works really well for IPv4, because most addresses are either assigned by DHCP [RFC2131] or statically configured by the network operator. IPv6 is way harder, though, because devices often configure their own IPv6 addresses through Stateless Address Autoconfiguration (SLAAC) [RFC4862] 🥺
This document gives a device a way to tell the DHCPv6 server that it has a self-configured IPv6 address (or a statically configured one). That gets IPv6 to parity with IPv4 by making DHCPv6 infrastructure aware of self-assigned IPv6 addresses 💜
2. Conventions and Definitions 📖
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 🎀 So those capital words are the official BCP 14 key words, and lowercase versions are just regular words.
3. Registration Mechanism Overview 🦋
DHCPv6 is the address registration protocol here, and a DHCPv6 server plays the role of an address registration server 🧚 This doc adds a new Address Registration (OPTION_ADDR_REG_ENABLE) option, which tells the client that the server supports the registration mechanism.
Before registering any addresses, the client MUST determine whether the network supports address registration. To check, it puts the Address Registration option code in the Option Request option (see Section 21.7 of [RFC8415]) of its Information-Request, Solicit, Request, Renew, or Rebind messages, which it sends to the server as part of the normal stateless or stateful DHCPv6 configuration. If the server supports address registration, it includes an Address Registration option in its Advertise or Reply messages 🌸
Now, to avoid unwanted multicast traffic, if the DHCPv6 infrastructure doesn't support address registration information (or isn't willing to receive it), the client MUST NOT register any addresses using this mechanism 🙈 Otherwise, the client registers addresses the way described below.
After a client implementing this spec successfully assigns a self-generated or statically configured valid IPv6 address [RFC4862] on one of its interfaces, it multicasts an ADDR-REG-INFORM message (see Section 4.2) to tell the DHCPv6 server that this self-generated address is in use 📣 Each ADDR-REG-INFORM message includes a DHCPv6 Identity Association (IA) Address option [RFC8415] to specify the address being registered.
Here's the overview, shown in Figure 1 🍓
+--------+ +------------------+ +---------------+
| 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 |
| |
Figure 1: Address Registration Procedure Overview4. DHCPv6 Address Registration Procedure 💅
4.1. DHCPv6 Address Registration Option 🌈
The Address Registration option (OPTION_ADDR_REG_ENABLE) says the server supports the mechanism in this document. Its format looks like this 👑
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: DHCPv6 Address Registration OptionThe fields work like this:
option-code:OPTION_ADDR_REG_ENABLE(148)option-len: 0
If a client has the address registration mechanism enabled, it MUST include this option in all Option Request options that it sends. 💖
A server that's configured to support the address registration mechanism MUST include this option in Advertise and Reply messages if the client message it's replying to had this option in its Option Request option. ✨
Part 1 is done, and parts 2 through 4 are still coming, so stay tuned 🫶
4.2. DHCPv6 Address Registration Request Message 💌
okay so this is where the client actually sends the ADDR-REG-INFORM message 📨 to say "hey, this IPv6 address is now assigned to my interface!" 💖 Here's the packet layout:
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) .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 3: DHCPv6 ADDR-REG-INFORM Message
Here's what each field does:
msg-type: tells you the DHCPv6 message type. It's set toADDR-REG-INFORM(36) 🎀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] and insert this value in the transaction-id field. 🆔 The client MUST include the Client Identifier option [RFC8415] in the ADDR-REG-INFORM message. 🪪
The ADDR-REG-INFORM message MUST NOT contain the Server Identifier option, and it MUST contain exactly one IA Address option holding the address being registered. The valid-lifetime and preferred-lifetime fields in that option MUST match the current Valid Lifetime and Preferred Lifetime of the address being registered. ⏳
ngl this message is basically only for clients starting a registration request toward an address registration server, so clients MUST NOT put any Option Request option(s) in it 🙅♀️ They MAY include other options, though, like the Client FQDN option [RFC4704]. 🍓
The client sends ADDR-REG-INFORM to the All_DHCP_Relay_Agents_and_Servers multicast address (ff02::1:2) 📡 and it MUST send separate messages for each address being registered. no sharing allowed 💅
Here's the main character moment: unlike other message types, which come from the client's link-local address, the ADDR-REG-INFORM message MUST be sent from the address being registered 🦋 The reason is "fate sharing." For example, if the network uses some Layer 2 security to stop a client from spoofing other clients' MAC addresses, this also stops an attacker from spoofing ADDR-REG-INFORM messages. 🔐
On clients with multiple interfaces, the client MUST only send the packet on the network interface that has the address being registered, even if it has several interfaces with different addresses 🌈 If the same address is configured on multiple interfaces, the client MUST send the ADDR-REG-INFORM message each time the address is configured on an interface that didn't have it before, and each registration gets refreshed independently from the others 🔄
The client MUST only send ADDR-REG-INFORM for valid addresses [RFC4862] with global scope [RFC4007]. That includes Unique Local Addresses (ULAs), which [RFC4193] defines as having global scope 🌍 It also includes statically assigned addresses with global scope, since those are considered valid indefinitely ♾️ The client MUST NOT send the ADDR-REG-INFORM message for addresses configured by DHCPv6. 🚫
The client SHOULD NOT 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. 📻
Clients MUST discard any received ADDR-REG-INFORM messages. 🗑️
4.2.1. Server Message Processing 🖥️
Servers MUST discard any ADDR-REG-INFORM messages that meet any of the following conditions 🙅♀️
- the message does not include a Client Identifier option;
- the message includes a Server Identifier option;
- 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 not relayed, or the peer-address field of the innermost Relay-forward message if it is relayed; or
- the message includes an Option Request option.
If the message isn't discarded, the address registration server SHOULD verify that the address being registered is "appropriate to the link" as defined by [RFC8415], or that it sits within a prefix delegated to the client via DHCPv6 for Prefix Delegation (DHCPv6-PD) (see Section 6.3 of [RFC8415]) 🔍 If the address fails this check, the server MUST drop the message and SHOULD log this fact 📝 If the message passes the check, the server:
- MUST log the address registration information (as it normally does for clients it has assigned an address to), unless it's configured not to 📒 The server SHOULD log the client DHCP Unique Identifier (DUID) and the link-layer address, if available. The server MAY log any other information too.
- SHOULD register a binding between the provided Client Identifier and IPv6 address in its database, if no binding exists 🔗 The lifetime of the binding equals the Valid Lifetime of the address the client reported. If there's already a binding between the registered address and the same client, the server MUST update its lifetime. If there's already a binding between the registered address and another client, the server SHOULD log the fact and update the binding. 👀
- SHOULD mark the address as unavailable for use and not include it in future Advertise messages 🚧
- MUST send back an ADDR-REG-REPLY message so the client doesn't retransmit 📬
If a client is multihomed (meaning it's connected to multiple administrative domains, each running its own DHCPv6 infrastructure), the requirement to verify that the registered address is appropriate for the link or belongs to a delegated prefix makes sure each DHCPv6 server only registers bindings for addresses from its own administrative domain 🏠
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 one anyway, it SHOULD log it and discard it 🫣
DHCPv6 relay agents and switches that relay address registration messages straight from clients MUST include the client's link-layer address in the relayed message, using the Client Link-Layer Address option [RFC6939], if they'd do the same for other DHCPv6 client messages like Solicit, Request, and Rebind 🧷
4.3. DHCPv6 Address Registration Acknowledgement 💕
The server MUST acknowledge receipt of a valid ADDR-REG-INFORM message by sending back an ADDR-REG-REPLY message ✅ Here's the layout:
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) .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 4: DHCPv6 ADDR-REG-REPLY Message
msg-type: identifies the DHCPv6 message type, set toADDR-REG-REPLY(37) 🎀transaction-id: the transaction ID for this message exchange 🧚options: the options carried in this message ✨
If the ADDR-REG-INFORM message the server is replying to was not relayed, the IPv6 destination address of the message MUST be the address being registered 🎯 If it was relayed, the server MUST construct the Relay-reply message as specified in Section 19.3 of [RFC8415] 🔁
The server MUST copy the transaction-id from the ADDR-REG-INFORM message into the transaction-id field of the ADDR-REG-REPLY 👯♀️
The ADDR-REG-REPLY message MUST contain an IA Address option for the address being registered, and that option MUST be identical to the one in the ADDR-REG-INFORM message the server is replying to 🪞
Servers MUST ignore any received ADDR-REG-REPLY messages. 🙈
Clients MUST discard any ADDR-REG-REPLY messages that meet any of the following conditions 🗑️
- the IPv6 destination address 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 receiving the message; or
- the
transaction-iddoes not match thetransaction-idthe client used in the corresponding ADDR-REG-INFORM message.
The ADDR-REG-REPLY message only tells the client that its ADDR-REG-INFORM was received and that it shouldn't retransmit it. It MUST NOT be considered any indication of address validity, and it MUST NOT be required for the address to be usable. 🚨
DHCPv6 relays, and other devices that snoop ADDR-REG-REPLY messages, MUST NOT add or alter any forwarding or security state based on that ADDR-REG-REPLY message 🛑
4.4. Signaling Address Registration Support 📣
To avoid undesired multicast traffic, the client MUST NOT register addresses using this mechanism unless the DHCPv6 infrastructure supports address registration 📵 The client can find this out by including the OPTION_ADDR_REG_ENABLE option in the Option Request options it sends 🔎 If the client receives and processes an Advertise or Reply message containing the OPTION_ADDR_REG_ENABLE option, it concludes the DHCPv6 infrastructure supports address registration 🎉 When the client detects address registration support, it MUST start the registration process (unless it's configured not to) and MUST immediately register any addresses that are already in use 🚀 Once the client starts the registration process, it MUST NOT stop registering addresses until it disconnects from the link, even if later Advertise or Reply messages don't contain the OPTION_ADDR_REG_ENABLE option 🔒
The client MUST discover whether the DHCPv6 infrastructure supports address registration every time it connects to a network or detects it has moved to a new link, without relying on any prior knowledge about address registration support on that network or link 🧠 This behavior lets networks roll out support for the Address Registration option across the DHCPv6 infrastructure bit by bit, without clients constantly stopping and restarting registration when some of the network's DHCPv6 servers support it and some don't 🌱
A client with multiple interfaces MUST discover address registration support for each interface independently 🔌 The client MUST NOT send address registration messages on a given interface unless it has discovered that the interface is connected to a network that supports address registration. 🚦
4.5. Retransmission 🔁
Okay so, packets get lost sometimes 😭 To reduce the effects of packet loss on registration, the client MUST retransmit the registration message. Retransmissions SHOULD follow the standard retransmission logic specified by Section 15 of [RFC8415], with these default parameters for the initial retransmission time (IRT) and maximum retransmission count (MRC):
- IRT 1 sec
- MRC 3
The client SHOULD allow the administrator to configure these parameters ✨
To comply with Section 16.1 of [RFC8415], the client MUST 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 MUST be updated so that they match the current lifetimes of the address 💖
If an ADDR-REG-REPLY message is received for the address being registered, the client MUST stop retransmission. Bye bye retries 👋
4.6. Registration Expiry and Refresh 💅
The client MUST refresh registrations so the server is always aware of which addresses are still valid. The client SHOULD perform refreshes as described below. Keeping the server in the loop is so important, bestie 🫶
4.6.1. SLAAC Addresses 🌸
For an address configured using SLAAC, there's a function AddrRegRefreshInterval(address), defined as 80% of the address's current Valid Lifetime. When calculating this value, the client applies a multiplier of AddrRegDesyncMultiplier so it doesn't sync up with other clients. Otherwise a huge pile of registration messages could hit the server at the exact same moment 😱 AddrRegDesyncMultiplier is a random value uniformly distributed between 0.9 and 1.1 (inclusive). The client picks it when it starts the registration process, which makes sure refreshes for addresses with the same lifetime get coalesced (see below) ✨
Whenever the client registers or refreshes an address, it calculates a NextAddrRegRefreshTime for that address as AddrRegRefreshInterval seconds in the future, but it does not schedule any refreshes yet 🦋
Whenever the network changes the Valid Lifetime of an existing address by more than 1%, for example by sending a Prefix Information Option (PIO) [RFC4861] with a new Valid Lifetime, the client calculates a new AddrRegRefreshInterval. The client schedules a refresh for min(now + AddrRegRefreshInterval, NextAddrRegRefreshTime). If that refresh would be scheduled in the past, the refresh happens immediately ⏰
Justification: this algorithm makes sure refreshes aren't sent too often, while the server never believes an address has expired when it actually hasn't. The tea, bestie 🍓 Specifically, after every registration:
- If the network never changes the lifetime of an address (for example, if no more PIOs arrive, or if all PIO lifetimes decrease in step with the passage of time), then no refreshes occur. Refreshes aren't needed, because the address expires at the time the server expects it to expire 😌
- Any time the network changes the lifetime of an address (that is, it changes the time at which the address will expire), the client makes sure a refresh is scheduled, so the server gets told about the new expiry 📣
- Because
AddrRegDesyncMultiplieris at most 1.1, the refresh never occurs later than a point 88% of the way between when the address was registered and when it will expire. That leaves the client up to 12% of the original interval to retransmit the registration before the address expires. This might not be possible if the network sends a Router Advertisement (RA) [RFC4861] very close to when the address would have expired. In that case, the client refreshes immediately, which is the best it can do 🏃♀️ - The 1% tolerance means the client won't refresh or reschedule refreshes just because the Valid Lifetime shifted a little from transmission delays or clock skew between the client and the router(s) sending the RA 🙈
AddrRegRefreshCoalesce(Section 4.6.3) lets battery-powered clients wake up less often. In particular, it lets the client coalesce refreshes for multiple addresses formed from the same prefix, such as the stable and privacy addresses. Higher values mean fewer wakeups, but they may result in more network traffic, because if a refresh is sent early, the next RA received will make the client immediately send a refresh message 🔋- In typical networks, the lifetimes in periodic RAs either hold constant values or decrease over time to match another lifetime, such as the lifetime of a prefix delegated to the network. In both cases, this algorithm refreshes on the order of once per address lifetime, which is similar to the number of refreshes needed with stateful DHCPv6 💜
- Because refreshes occur at least once per address lifetime, the network administrator can control the address refresh frequency by setting the Valid Lifetime in the PIO appropriately 👑
4.6.2. Statically Assigned Addresses 🧚
A statically assigned address has an infinite Valid Lifetime that isn't affected by RAs. So 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 means static addresses still get refreshed periodically, but refreshes for static addresses don't cause excessive multicast traffic 💅 The StaticAddrRegRefreshInterval interval SHOULD be configurable.
4.6.3. Transmitting Refreshes 🚀
When a refresh is performed, the client MAY refresh all addresses assigned to the interface that are scheduled to be refreshed within the next AddrRegRefreshCoalesce seconds. The value of AddrRegRefreshCoalesce is implementation dependent, and a suggested default is 60 seconds.
Registration refresh packets MUST be retransmitted using the same logic as initial registrations (see Section 4.5).
The client MUST generate a new transaction ID when refreshing the registration. Fresh ID, fresh start ✨
When a Client-Identifier-to-IPv6-address binding expires, the server MUST remove it and consider the address available for use 🗑️
The client MAY choose to notify the server when an address is no longer being used (for example, 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 isn't being used anymore, the client MUST 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 MUST act as if the address has expired. Zero means gone, periodt 💀
5. Client Configuration 🎀
DHCP clients SHOULD allow the administrator to disable sending ADDR-REG-INFORM messages. Sending the messages SHOULD be enabled by default. So it's on unless someone turns it off 🌈
6. Security Considerations 🔥
An attacker may attempt to register a large number of addresses in quick succession in order to overwhelm the address registration server and/or fill up log files. Similar attack vectors exist today. For example, an attacker can DoS the server with messages containing spoofed DHCP Unique Identifiers (DUIDs) [RFC8415]. Scary stuff 😭
If a network is using First-Come, First-Served Source Address 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 address configured on another client. Nobody gets to steal your address, bestie 🔒
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 because the device itself is responsible for informing the DHCPv6 server that it is using an address, a malicious or compromised device can simply choose not to send the ADDR-REG-INFORM message. This is an informational, optional mechanism, 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 MUST NOT be used for authentication and authorization purposes, because, in addition to the reasons above, the packets containing the message may be dropped. Please don't use this as a bouncer 🚫
7. Privacy Considerations 🙈
If the network doesn't have Multicast 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 learn information about IPv6 addresses assigned to the client. ADDR-REG-INFORM messages contain unique identifiers such as the client's DUID, so 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 isn't specific to the proposed mechanism. Section 4.3 of [RFC7844] discusses using the DUID for device tracking in DHCPv6 environments and provides mitigation recommendations 👀
In general, hiding information about the specific IPv6 address from on-link observers shouldn't be treated as a security measure, because that information is usually disclosed to all nodes anyway via Duplicate Address Detection [RFC4862], if MLD snooping isn't enabled. Hiding it is not the move, babe 🫠
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 listening to gratuitous neighbor advertisement messages [RFC9131]. It should be noted that this particular scenario shares its fate with DHCPv6 address assignment. If an attacker can join the All_DHCP_Relay_Agents_and_Servers multicast group, they would be able to monitor all DHCPv6 messages sent from the client to DHCPv6 servers and relays, and therefore obtain the information about addresses being assigned via DHCPv6. Layer 2 isolation helps mitigate this threat by blocking on-link peer-to-peer communication between nodes 🧱
8. IANA Considerations 🦋
This document introduces the following entities, which have been allocated in the "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" registry group defined at http://www.iana.org/assignments/dhcpv6-parameters. These include:
- One new DHCPv6 option, described in Section 4.1, which has been allocated in the "Option Codes" registry:
Value: 148
Description: OPTION_ADDR_REG_ENABLE
Client ORO: Yes
Singleton Option: Yes
Reference: RFC 9686- 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):
Value: 36
Description: ADDR-REG-INFORM
Reference: RFC 9686
Value: 37
Description: ADDR-REG-REPLY
Reference: RFC 96869. References 📚
9.1. Normative References
okay the normative ones are the must-reads, bestie 📚✨ these are the docs the spec leans on hardcore, so here they are exactly as the RFC lists them:
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol",
RFC 2131, DOI 10.17487/RFC2131, March 1997,
<https://www.rfc-editor.org/info/rfc2131>.
[RFC4007] Deering, S., Haberman, B., Jinmei, T., Nordmark, E., and
B. Zill, "IPv6 Scoped Address Architecture", RFC 4007,
DOI 10.17487/RFC4007, March 2005,
<https://www.rfc-editor.org/info/rfc4007>.
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005,
<https://www.rfc-editor.org/info/rfc4193>.
[RFC4704] Volz, B., "The Dynamic Host Configuration Protocol for
IPv6 (DHCPv6) Client Fully Qualified Domain Name (FQDN)
Option", RFC 4704, DOI 10.17487/RFC4704, October 2006,
<https://www.rfc-editor.org/info/rfc4704>.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862,
DOI 10.17487/RFC4862, September 2007,
<https://www.rfc-editor.org/info/rfc4862>.
[RFC6939] Halwasia, G., Bhandari, S., and W. Dec, "Client Link-Layer
Address Option in DHCPv6", RFC 6939, DOI 10.17487/RFC6939,
May 2013, <https://www.rfc-editor.org/info/rfc6939>.
[RFC7844] Huitema, C., Mrugalski, T., and S. Krishnan, "Anonymity
Profiles for DHCP Clients", RFC 7844,
DOI 10.17487/RFC7844, May 2016,
<https://www.rfc-editor.org/info/rfc7844>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A.,
Richardson, M., Jiang, S., Lemon, T., and T. Winters,
"Dynamic Host Configuration Protocol for IPv6 (DHCPv6)",
RFC 8415, DOI 10.17487/RFC8415, November 2018,
<https://www.rfc-editor.org/info/rfc8415>.
[RFC9131] Linkova, J., "Gratuitous Neighbor Discovery: Creating
Neighbor Cache Entries on First-Hop Routers", RFC 9131,
DOI 10.17487/RFC9131, October 2021,
<https://www.rfc-editor.org/info/rfc9131>.9.2. Informative References
these ones are the extra reading 🤓 good context, not required to build the thing:
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
DOI 10.17487/RFC4861, September 2007,
<https://www.rfc-editor.org/info/rfc4861>.
[RFC6620] Nordmark, E., Bagnulo, M., and E. Levy-Abegnoli, "FCFS
SAVI: First-Come, First-Served Source Address Validation
Improvement for Locally Assigned IPv6 Addresses",
RFC 6620, DOI 10.17487/RFC6620, May 2012,
<https://www.rfc-editor.org/info/rfc6620>.Acknowledgements ✨
okay the people who helped make this happen deserve ALL the flowers 🌸🫶 huge thank-you to Bernie Volz for the big review and feedback, plus Hermin Anggawijaya, Carlos Jesus Bernardos, 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, Gunter Van de Velde, Eric Vyncke, Timothy Winters, and Peter Yee for their feedback, comments, and guidance 💜 the authors also say sorry in advance in case they accidentally forgot somebody, which is a very real risk when this many smart people are involved 🙈
Contributors
the contributor's details, exactly as listed 🎀
Gang Chen
China Mobile
53A, Xibianmennei Ave.
Xuanwu District
Beijing
China
Email: phdgang@gmail.comAuthors' Addresses
and last but definitely not least, the authors 👑 their contact details are below, copied exactly:
Warren Kumari
Google, LLC
Email: warren@kumari.net
Suresh Krishnan
Cisco Systems, Inc.
Email: suresh.krishnan@gmail.com
Rajiv Asati
Independent
Email: rajiv.asati@gmail.com
Lorenzo Colitti
Google, LLC
Shibuya 3-21-3,
Japan
Email: lorenzo@google.com
Jen Linkova
Google, LLC
1 Darling Island Rd
Pyrmont 2009
Australia
Email: furry13@gmail.com
Sheng Jiang
Beijing University of Posts and Telecommunications
No. 10 Xitucheng Road
Beijing
Haidian District, 100083
China
Email: shengjiang@bupt.edu.cn📦 where this page comes from
- ietf: rfc9686 2024-12
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms