rfc9686v2.txt		rfc9686.txt
	skipping to change at line 13 ¶		skipping to change at line 13 ¶
	Request for Comments: 9686 Google, LLC		Request for Comments: 9686 Google, LLC
	Category: Standards Track S. Krishnan		Category: Standards Track S. Krishnan
	ISSN: 2070-1721 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
	BUPT		BUPT
	November 2024		December 2024
	Registering Self-Generated IPv6 Addresses Using DHCPv6		Registering Self-Generated IPv6 Addresses Using DHCPv6
	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.
	Status of This Memo		Status of This Memo
	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. 6 change blocks.
	19 lines changed or deleted		17 lines changed or added
This html diff was produced by rfcdiff 1.48.