rfc9915v1.txt		rfc9915.txt
	skipping to change at line 12 ¶		skipping to change at line 12 ¶
	Internet Engineering Task Force (IETF) T. Mrugalski		Internet Engineering Task Force (IETF) T. Mrugalski
	Request for Comments: 9915 ISC		Request for Comments: 9915 ISC
	Obsoletes: 8415 B. Volz		Obsoletes: 8415 B. Volz
	Category: Standards Track Individual Contributor		Category: Standards Track Individual Contributor
	ISSN: 2070-1721 M. Richardson		ISSN: 2070-1721 M. Richardson
	SSW		SSW
	S. Jiang		S. Jiang
	BUPT		BUPT
	T. Winters		T. Winters
	QA Cafe		QA Cafe
	November 2025		December 2025
	Dynamic Host Configuration Protocol for IPv6 (DHCPv6)		Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
	Abstract		Abstract
	This document specifies the Dynamic Host Configuration Protocol for		This document specifies the Dynamic Host Configuration Protocol for
	IPv6 (DHCPv6), an extensible mechanism for configuring nodes with		IPv6 (DHCPv6), an extensible mechanism for configuring nodes with
	network configuration parameters, IP addresses, and prefixes.		network configuration parameters, IP addresses, and prefixes.
	Parameters can be provided statelessly or in combination with		Parameters can be provided statelessly or in combination with
	stateful assignment of one or more IPv6 addresses and/or IPv6		stateful assignment of one or more IPv6 addresses and/or IPv6
	prefixes. DHCPv6 can operate either in place of or in addition to		prefixes. DHCPv6 can operate either in place of or in addition to
	stateless address autoconfiguration (SLAAC).		stateless address autoconfiguration (SLAAC).
	This document obsoletes RFC 8415 to incorporate reported errata and		This document obsoletes RFC 8415. It incorporates verified errata
	to obsolete the assignment of temporary addresses (the IA_TA option)		and obsoletes the assignment of temporary addresses (the IA_TA
	and the server unicast capability (the Server Unicast option and		option) and the server unicast capability (the Server Unicast option
	UseMulticast status code).		and UseMulticast status code).
	Status of This Memo		Status of This Memo
	This is an Internet Standards Track document.		This is an Internet Standards Track document.
	This document is a product of the Internet Engineering Task Force		This document is a product of the Internet Engineering Task Force
	(IETF). It represents the consensus of the IETF community. It has		(IETF). It represents the consensus of the IETF community. It has
	received public review and has been approved for publication by the		received public review and has been approved for publication by the
	Internet Engineering Steering Group (IESG). Further information on		Internet Engineering Steering Group (IESG). Further information on
	Internet Standards is available in Section 2 of RFC 7841.		Internet Standards is available in Section 2 of RFC 7841.
	skipping to change at line 256 ¶		skipping to change at line 256 ¶
	DHCPv6 can provide a device with addresses assigned by a DHCPv6		DHCPv6 can provide a device with addresses assigned by a DHCPv6
	server and other configuration information; this data is carried in		server and other configuration information; this data is carried in
	options. DHCPv6 can be extended through the definition of new		options. DHCPv6 can be extended through the definition of new
	options to carry configuration information not specified in this		options to carry configuration information not specified in this
	document.		document.
	DHCPv6 also supports a mechanism for automated delegation of IPv6		DHCPv6 also supports a mechanism for automated delegation of IPv6
	prefixes. Through this mechanism, a server can delegate prefixes to		prefixes. Through this mechanism, a server can delegate prefixes to
	clients. Use of this mechanism is specified as part of [RFC7084] and		clients. Use of this mechanism is specified as part of [RFC7084] and
	by [TR-187]. Note that these documents use "requesting router" for		by [TR-187]. Note that those documents use "requesting router" and
	what this document uses client and "delegating router" for server.		"delegating router" where this document uses "client" and "server",
			respectively.
	DHCP can also be used just to provide other configuration options		DHCP can also be used just to provide other configuration options
	(i.e., no addresses or prefixes). That implies that the server does		(i.e., no addresses or prefixes). That implies that the server does
	not have to track any state; thus, this mode is called "stateless		not have to track any state; thus, this mode is called "stateless
	DHCPv6". Mechanisms necessary to support stateless DHCPv6 are much		DHCPv6". Mechanisms necessary to support stateless DHCPv6 are much
	simpler than mechanisms needed to support stateful DHCPv6.		simpler than mechanisms needed to support stateful DHCPv6.
	1.1. Relationship to Previous DHCPv6 Standards		1.1. Relationship to Previous DHCPv6 Standards
	[RFC8415] provided a unified, corrected, and cleaned-up definition of		[RFC8415] provided a unified, corrected, and cleaned-up definition of
	DHCPv6 that also covered all applicable errata filed against older		DHCPv6 that also covered all applicable errata filed against older
	RFCs at the time of its writing. It also obsoleted a small number of		RFCs at the time of its writing. It also obsoleted a small number of
	mechanisms: delayed authentication, lifetime and timer hints sent by		mechanisms: delayed authentication, lifetime, and timer hints sent by
	a client.		a client.
	This document obsoletes [RFC8415] by applying all applicable errata		This document obsoletes [RFC8415]. It applies verified errata
	and obsoleting two features that have not been widely implemented:		reports and obsoletes two features that have not been widely
	the assignment of temporary addresses using the IA_TA option and		implemented - the assignment of temporary addresses using the IA_TA
	allowing clients to unicast some messages directly to the server if		option and allowing clients to unicast some messages directly to the
	the server sent the Server Unicast option to a client in an early		server if the server sent the Server Unicast option to a client in an
	exchange. It also clarifies the UDP ports used by clients, servers,		early exchange. It also clarifies the UDP ports used by clients,
	and relay agents (Section 7.2). See Appendix A for a list of		servers, and relay agents (Section 7.2). See Appendix A for a list
	differences from [RFC8415].		of differences from [RFC8415].
	1.2. Topics Out of Scope		1.2. Topics Out of Scope
	This document specifies DHCPv6 behavior. The server policy, such as		This document specifies DHCPv6 behavior. The server policy, such as
	what options to assign to which clients, which subnets or pools of		what options to assign to which clients, which subnets or pools of
	resources to use, which clients' requests should be denied, etc. are		resources to use, which clients' requests should be denied, etc. are
	out of scope for this document.		out of scope for this document.
	Server configuration, operation, and management are also out of		Server configuration, operation, and management are also out of
	scope. An approach to manage DHCPv6 relays and servers is specified		scope. An approach to manage DHCPv6 relays and servers is specified
	skipping to change at line 476 ¶		skipping to change at line 477 ¶
	same link as the client(s).		same link as the client(s).
	DUID		DUID
	A DHCP Unique Identifier for a DHCP participant. Each DHCP client		A DHCP Unique Identifier for a DHCP participant. Each DHCP client
	and server has exactly one DUID. See Section 11 for details of		and server has exactly one DUID. See Section 11 for details of
	the ways in which a DUID may be constructed.		the ways in which a DUID may be constructed.
	encapsulated option		encapsulated option
	A DHCP option that is usually only contained in another option.		A DHCP option that is usually only contained in another option.
	For example, the IA Address option is contained in IA_NA options		For example, the IA Address option is contained in IA_NA options
	(see Section 21.5). See Section 9 of [RFC7227] for a more		(see Section 21.6 and Section 21.4, respectively). See Section 9
	complete definition.		of [RFC7227] for a more complete definition.
	IA		IA
	Identity Association: a collection of leases assigned to a client.		Identity Association: a collection of leases assigned to a client.
	Each IA has an associated IAID (see below). A client may have		Each IA has an associated IAID (see below). A client may have
	more than one IA assigned to it -- for example, one for each of		more than one IA assigned to it -- for example, one for each of
	its interfaces. Each IA holds one type of lease; for example, an		its interfaces. Each IA holds one type of lease; for example, an
	identity association for non-temporary addresses (IA_NA) holds		identity association for non-temporary addresses (IA_NA) holds
	addresses, and an identity association for prefix delegation		addresses, and an identity association for prefix delegation
	(IA_PD) holds delegated prefixes. Throughout this document, "IA"		(IA_PD) holds delegated prefixes. Throughout this document, "IA"
	is used to refer to an identity association without identifying		is used to refer to an identity association without identifying
	the type of a lease in the IA. This document defines three IA		the type of a lease in the IA. This document defines three IA
	types: IA_NA, IA_TA (obsoleted), and IA_PD. Another IA type		types: IA_NA, IA_TA (obsoleted), and IA_PD. Another IA type
	(IA_LL) was defined in [RFC8947] and more may be defined.		(IA_LL) was defined in [RFC8947] and more may be defined.
	IA option(s)		IA option(s)
	In this document, one or more IA_NA, IA_TA (obsoleted), and/or		In this document, one or more IA_NA, IA_TA (obsoleted), and/or
	IA_PD. Another IA type (IA_LL) was defined in [RFC8947] and more		IA_PD options. Another IA type (IA_LL) was defined in [RFC8947]
	may be defined.		and more may be defined.
	IAID		IAID
	Identity Association Identifier: an identifier for an IA, chosen		Identity Association Identifier: an identifier for an IA, chosen
	by the client. Each IA has an IAID, which is chosen to be unique		by the client. Each IA has an IAID, which is chosen to be unique
	among IAIDs for IAs of a specific type that belong to that client.		among IAIDs for IAs of a specific type that belong to that client.
	IA_NA		IA_NA
	Identity Association for Non-temporary Addresses: an IA that		Identity Association for Non-temporary Addresses: an IA that
	carries assigned addresses. See Section 21.4 for details on the		carries assigned addresses. See Section 21.4 for details on the
	IA_NA option.		IA_NA option.
	skipping to change at line 830 ¶		skipping to change at line 831 ¶
	|Subscriber| |Subscriber| |Subscriber| /		|Subscriber| |Subscriber| |Subscriber| /
	| PC | | PC | | PC | /		| PC | | PC | | PC | /
	+----------+ +----------+ +----------+ /		+----------+ +----------+ +----------+ /
	Figure 1: Prefix Delegation Network		Figure 1: Prefix Delegation Network
	In this example, the server (in the ISP core network or integrated in		In this example, the server (in the ISP core network or integrated in
	the aggregation device) is configured with a set of prefixes to be		the aggregation device) is configured with a set of prefixes to be
	used for assignment to customers at the time of each customer's first		used for assignment to customers at the time of each customer's first
	connection to the ISP service. The prefix delegation process begins		connection to the ISP service. The prefix delegation process begins
	when the client (CPE) requests configuration information through		when the client (or Customer Premises Equipment (CPE)) requests
	DHCP. The DHCP messages from the client are received by the server		configuration information through DHCP. The DHCP messages from the
	via the aggregation device. When the server receives the request, it		client are received by the server via the aggregation device. When
	selects an available prefix or prefixes for delegation to the client.		the server receives the request, it selects an available prefix or
	The server then returns the prefix or prefixes to the client.		prefixes for delegation to the client. The server then returns the
			prefix or prefixes to the client.
	The client subnets the delegated prefix and assigns the longer		The client subnets the delegated prefix and assigns the longer
	prefixes to links in the subscriber's network. In a typical scenario		prefixes to links in the subscriber's network. In a typical scenario
	based on the network shown in Figure 1, the client subnets a single		based on the network shown in Figure 1, the client subnets a single
	delegated /48 prefix into /64 prefixes and assigns one /64 prefix to		delegated /48 prefix into /64 prefixes and assigns one /64 prefix to
	each of the links in the subscriber network.		each of the links in the subscriber network.
	The prefix delegation options can be used in conjunction with other		The prefix delegation options can be used in conjunction with other
	DHCP options carrying other configuration information to the client.		DHCP options carrying other configuration information to the client.
	The client may, in turn, provide DHCP service to nodes attached to		The client may, in turn, provide DHCP service to nodes attached to
	skipping to change at line 970 ¶		skipping to change at line 972 ¶
	Clients MUST listen for DHCP messages on UDP port 546. Servers and		Clients MUST listen for DHCP messages on UDP port 546. Servers and
	relay agents MUST listen for DHCP messages on UDP port 547.		relay agents MUST listen for DHCP messages on UDP port 547.
	Therefore, clients MUST send DHCP messages to UDP destination port		Therefore, clients MUST send DHCP messages to UDP destination port
	547. Servers MUST send Relay-reply messages to UDP destination port		547. Servers MUST send Relay-reply messages to UDP destination port
	547 and client messages to UDP destination port 546. Relay agents		547 and client messages to UDP destination port 546. Relay agents
	MUST send Relay-forward and Relay-reply messages to UDP destination		MUST send Relay-forward and Relay-reply messages to UDP destination
	port 547 and client messages to UDP destination port 546.		port 547 and client messages to UDP destination port 546.
	It is RECOMMENDED for clients to send messages from UDP source port		It is RECOMMENDED for clients to send messages from UDP source port
	546, and servers and relay agents from UDP source port 547. However,		546 and for servers and relay agents from UDP source port 547.
	clients, servers, and relay agents MAY send DHCP messages from any		However, clients, servers, and relay agents MAY send DHCP messages
	UDP source port they are allowed to use.		from any UDP source port they are allowed to use.
	Please note that the Relay Source Port Option [RFC8357] changes some		Please note that the Relay Source Port Option [RFC8357] changes some
	of these rules for servers and relays agents.		of these rules for servers and relays agents.
	7.3. DHCP Message Types		7.3. DHCP Message Types
	DHCP defines the following message types. The formats of these		DHCP defines the following message types. The formats of these
	messages are provided in Sections 8 and 9. Additional message types		messages are provided in Sections 8 and 9. Additional message types
	have been defined and may be defined in the future; see		have been defined and may be defined in the future; see
	<https://www.iana.org/assignments/dhcpv6-parameters>. The numeric		<https://www.iana.org/assignments/dhcpv6-parameters>. The numeric
	skipping to change at line 3066 ¶		skipping to change at line 3068 ¶
	performs DHCP server discovery as described in Section 18.		performs DHCP server discovery as described in Section 18.
	18.2.10.4. Reply for Information-request		18.2.10.4. Reply for Information-request
	Refer to Section 21.23 for details on how the Information Refresh		Refer to Section 21.23 for details on how the Information Refresh
	Time option (whether or not present in the Reply) should be handled		Time option (whether or not present in the Reply) should be handled
	by the client.		by the client.
	18.2.10.5. Revoking Previously Provided Options		18.2.10.5. Revoking Previously Provided Options
	When a client received a configuration option in an earlier Reply and		When a client receives a Reply for a Renew, Rebind, or Information-
	then sends a Renew, Rebind, or Information-request and the requested		Request that does not include a requested configuration option that
	option is not present in the Reply, the client SHOULD stop using the		it previously received in a Reply, the client SHOULD stop using the
	previously received configuration information. In other words, the		previously received configuration information. In other words, the
	client should behave as if it never received this configuration		client should behave as if it never received this configuration
	option and return to the relevant default state. If there is no		option and return to the relevant default state. If there is no
	viable way to stop using the received configuration information, the		viable way to stop using the received configuration information, the
	values received/configured from the option MAY persist if there are		values received/configured from the option MAY persist if there are
	no other sources for that data and they have no external impact. For		no other sources for that data and they have no external impact. For
	example, a client that previously received a Client FQDN option (see		example, a client that previously received a Client FQDN option (see
	[RFC4704]) and used it to set up its hostname is allowed to continue		[RFC4704]) and used it to set up its hostname is allowed to continue
	using it if there is no reasonable way for a node to unset its		using it if there is no reasonable way for a node to unset its
	hostname and it has no external impact. As a counterexample, a		hostname and it has no external impact. As a counterexample, a
	skipping to change at line 3177 ¶		skipping to change at line 3179 ¶
	described in Section 18.2.5, with the exception that the		described in Section 18.2.5, with the exception that the
	retransmission parameters should be set as for the Confirm message		retransmission parameters should be set as for the Confirm message
	(see Section 18.2.3). The client includes IA_NAs and IA_PDs, along		(see Section 18.2.3). The client includes IA_NAs and IA_PDs, along
	with the associated leases, in its Rebind message.		with the associated leases, in its Rebind message.
	If the client has only obtained network information using		If the client has only obtained network information using
	Information-request/Reply message exchanges, the client MUST initiate		Information-request/Reply message exchanges, the client MUST initiate
	an Information-request/Reply message exchange as described in		an Information-request/Reply message exchange as described in
	Section 18.2.6.		Section 18.2.6.
	If not associated with a detection of having moved to a new link, a		A client not detected as having moved to a new link SHOULD initiate
	client SHOULD initiate one of the Renew/Reply, Confirm/Reply or		one of the Renew/Reply, Confirm/Reply or Information-request/Reply
	Information-request/Reply exchanges, if the client detects a		exchanges, if the client detects a significant change regarding the
	significant change regarding the prefixes available on the link. A		prefixes available on the link. A change is considered significant
	change is considered significant when one or more on-link prefixes		when one or more on-link prefixes are added, and/or one or more
	are added, and/or one or more existing on-link prefixes are		existing on-link prefixes are deprecated. The reason for this is
	deprecated. The reason for this is that such a significant change		that such a significant change may indicate a configuration change at
	may indicate a configuration change at the server. However, a client		the server. However, a client MUST rate-limit such initiation
	MUST rate-limit such initiation attempts to avoid flooding a server		attempts to avoid flooding a server with requests when there are link
	with requests when there are link issues (for example, only doing one		issues (for example, only doing one of these at most every 30
	of these at most every 30 seconds).		seconds).
	The above selection of an exchange to initiate depends on the		The above selection of an exchange to initiate depends on the
	client's current state:		client's current state:
	* If the client has any valid delegated prefixes obtained from the		* If the client has any valid delegated prefixes obtained from the
	server, it sends Renew (as if the T1 time expired) as described in		server, it sends Renew (as if the T1 time expired) as described in
	Section 18.2.4.		Section 18.2.4.
	* Else, if the client obtained an address(es) from the server, it		* Else, if the client obtained an address(es) from the server, it
	sends Confirm as described in Section 18.2.3.		sends Confirm as described in Section 18.2.3.
	skipping to change at line 3210 ¶		skipping to change at line 3212 ¶
	sends an Information-request as described in Section 18.2.6.		sends an Information-request as described in Section 18.2.6.
	18.2.13. Restarting Server Discovery Process		18.2.13. Restarting Server Discovery Process
	Whenever a client restarts the DHCP server discovery process or		Whenever a client restarts the DHCP server discovery process or
	selects an alternate server as described in Section 18.2.9, the		selects an alternate server as described in Section 18.2.9, the
	client SHOULD stop using any addresses and delegated prefixes for		client SHOULD stop using any addresses and delegated prefixes for
	which it has bindings (see Section 18.2.7) and, if possible, any		which it has bindings (see Section 18.2.7) and, if possible, any
	other configuration information it previously received. The client		other configuration information it previously received. The client
	SHOULD also try to obtain new bindings and other configuration		SHOULD also try to obtain new bindings and other configuration
	information from a "new" server for the same interface. This		information from a new server for the same interface. This
	facilitates the client using a single state machine for all bindings.		facilitates the client using a single state machine for all bindings.
	18.3. Server Behavior		18.3. Server Behavior
	For this discussion, the server is assumed to have been configured in		For this discussion, the server is assumed to have been configured in
	an implementation-specific manner with configurations of interest to		an implementation-specific manner with configurations of interest to
	clients.		clients.
	A server sends an Advertise message in response to each valid Solicit		A server sends an Advertise message in response to each valid Solicit
	message it receives to announce the availability of the server to the		message it receives to announce the availability of the server to the
	skipping to change at line 4274 ¶		skipping to change at line 4276 ¶
	option-len: An unsigned integer giving the length of the option-data		option-len: An unsigned integer giving the length of the option-data
	field in this option in octets. A 2-octet field.		field in this option in octets. A 2-octet field.
	option-data: The data for the option; the format of this data		option-data: The data for the option; the format of this data
	depends on the definition of the option. A variable-length field		depends on the definition of the option. A variable-length field
	(the length, in octets, is specified by option-len).		(the length, in octets, is specified by option-len).
	DHCP options are scoped by using encapsulation. Some options apply		DHCP options are scoped by using encapsulation. Some options apply
	generally to the client, some are specific to an IA, and some are		generally to the client, some are specific to an IA, and some are
	specific to the addresses within an IA. These latter two cases are		specific to the addresses within an IA. These latter two cases are
	discussed in Sections 21.4, 21.5, and 21.6.		discussed in Sections 21.4 and 21.6.
	21.2. Client Identifier Option		21.2. Client Identifier Option
	The Client Identifier option is used to carry a DUID (see Section 11)		The Client Identifier option is used to carry a DUID (see Section 11)
	that identifies the client. The format of the Client Identifier		that identifies the client. The format of the Client Identifier
	option is:		option is:
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	skipping to change at line 4765 ¶		skipping to change at line 4767 ¶
	than the value in the option-len field).		than the value in the option-len field).
	IANA maintains a registry for the protocol, algorithm, and RDM values		IANA maintains a registry for the protocol, algorithm, and RDM values
	at <https://www.iana.org/assignments/auth-namespaces>.		at <https://www.iana.org/assignments/auth-namespaces>.
	21.12. Server Unicast Option		21.12. Server Unicast Option
	The Server Unicast option is obsolete. Please refer to [RFC8415] for		The Server Unicast option is obsolete. Please refer to [RFC8415] for
	historical information on this option.		historical information on this option.
	The client SHOULD NOT request this option in the Option Request		The server SHOULD NOT send this option. When any entity receives the
	option. The server SHOULD NOT send this option, even when requested		Server Unicast option, the option SHOULD be ignored and the message
	by clients. When any entity receives the Server Unicast option, the		processing should continue as usual.
	option SHOULD be ignored and the message processing should continue
	as usual.
	As this option was not very popular, and it typically required
	special configuration by those server implementations that did
	support it, clients still requesting this option in the Option
	Request option are increasingly unlikely to receive it.
	21.13. Status Code Option		21.13. Status Code Option
	This option returns a status indication related to the DHCP message		This option returns a status indication related to the DHCP message
	or option in which it appears. The format of the Status Code option		or option in which it appears. The format of the Status Code option
	is:		is:
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	skipping to change at line 4804 ¶		skipping to change at line 4799 ¶
	Figure 22: Status Code Option Format		Figure 22: Status Code Option Format
	option-code: OPTION_STATUS_CODE (13).		option-code: OPTION_STATUS_CODE (13).
	option-len: 2 + length of status-message field.		option-len: 2 + length of status-message field.
	status-code: The numeric code for the status encoded in this option.		status-code: The numeric code for the status encoded in this option.
	A 2-octet field containing an unsigned integer.		A 2-octet field containing an unsigned integer.
	status-message: A UTF-8 encoded [RFC3629] text string suitable for		status-message: A UTF-8 encoded [RFC3629] text string suitable for
	display to an end user. MUST NOT be null-terminated. A variable-		display to an end user. MUST NOT be NUL-terminated. A variable-
	length field (2 octets less than the value in the option-len		length field (2 octets less than the value in the option-len
	field).		field).
	A Status Code option may appear in the "options" field of a DHCP		A Status Code option may appear in the "options" field of a DHCP
	message and/or in the "options" field of another option. If the		message and/or in the "options" field of another option. If the
	Status Code option does not appear in a message in which the option		Status Code option does not appear in a message in which the option
	could appear, the status of the message is assumed to be Success.		could appear, the status of the message is assumed to be Success.
	The status-code values are:		The status-code values are:
	skipping to change at line 5061 ¶		skipping to change at line 5056 ¶
	The vendor-option-data field MUST be encoded as a sequence of		The vendor-option-data field MUST be encoded as a sequence of
	code/length/value fields of format identical to the DHCP options (see		code/length/value fields of format identical to the DHCP options (see
	Section 21.1). The suboption codes are defined by the vendor		Section 21.1). The suboption codes are defined by the vendor
	identified in the enterprise-number field and are not managed by		identified in the enterprise-number field and are not managed by
	IANA. Each of the suboptions is formatted as follows:		IANA. Each of the suboptions is formatted 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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| sub-opt-code | suboption-len |		| suboption-code | suboption-len |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	. .		. .
	. suboption-data .		. suboption-data .
	. .		. .
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 29: Vendor-Specific Options Format		Figure 29: Vendor-Specific Options Format
	sub-opt-code: The code for the suboption. A 2-octet field.		suboption-code: The code for the suboption. A 2-octet field.
	suboption-len: An unsigned integer giving the length of the		suboption-len: An unsigned integer giving the length of the
	suboption-data field in this suboption in octets. A 2-octet		suboption-data field in this suboption in octets. A 2-octet
	field.		field.
	suboption-data: The data area for the suboption. The length, in		suboption-data: The data area for the suboption. The length, in
	octets, is specified by suboption-len.		octets, is specified by suboption-len.
	Multiple instances of the Vendor-specific Information option may		Multiple instances of the Vendor-specific Information option may
	appear in a DHCP message. Each instance of the option is interpreted		appear in a DHCP message. Each instance of the option is interpreted
	skipping to change at line 5581 ¶		skipping to change at line 5576 ¶
	through various means to minimize these attacks.		through various means to minimize these attacks.
	The threat common to both the client and the server is the "resource-		The threat common to both the client and the server is the "resource-
	exhaustion" DoS attack. Typically, these attacks involve the		exhaustion" DoS attack. Typically, these attacks involve the
	exhaustion of available assigned addresses or delegatable prefixes or		exhaustion of available assigned addresses or delegatable prefixes or
	the exhaustion of CPU or network bandwidth, and they are present any		the exhaustion of CPU or network bandwidth, and they are present any
	time there is a shared resource. Some forms of these exhaustion		time there is a shared resource. Some forms of these exhaustion
	attacks can be partially mitigated by appropriate server policy,		attacks can be partially mitigated by appropriate server policy,
	e.g., limiting the maximum number of leases any one client can get,		e.g., limiting the maximum number of leases any one client can get,
	limiting the number of leases one client can decline, and limiting		limiting the number of leases one client can decline, and limiting
	the number of messages a single client can transmit of a period of		the number of messages a single client can transmit in a period of
	time.		time.
	22.1. Client Security Considerations		22.1. Client Security Considerations
	One attack specific to a DHCP client is the establishment of a		One attack specific to a DHCP client is the establishment of a
	malicious server with the intent of providing incorrect configuration		malicious server with the intent of providing incorrect configuration
	information to the client. The motivation for doing so may be to		information to the client. The motivation for doing so may be to
	mount a "man-in-the-middle" attack that causes the client to		mount a "man-in-the-middle" attack that causes the client to
	communicate with a malicious server instead of a valid server for		communicate with a malicious server instead of a valid server for
	some service (such as DNS or NTP). The malicious server may also		some service (such as DNS or NTP). The malicious server may also
	skipping to change at line 5668 ¶		skipping to change at line 5663 ¶
	transaction IDs that are cryptographically sound and cannot easily be		transaction IDs that are cryptographically sound and cannot easily be
	predicted will also reduce the probability that such an attack will		predicted will also reduce the probability that such an attack will
	be successful.		be successful.
	22.4. Mitigation Considerations		22.4. Mitigation Considerations
	Various network environments also offer levels of security if		Various network environments also offer levels of security if
	deployed as described below.		deployed as described below.
	* In enterprise and factory networks, use of authentication per		* In enterprise and factory networks, use of authentication per
	[IEEE-802.1x] can prevent unknown or untrusted clients from		[IEEE8802.1x] can prevent unknown or untrusted clients from
	connecting to the network. However, this does not necessarily		connecting to the network. However, this does not necessarily
	assure that the connected client will be a good DHCP or network		assure that the connected client will be a good DHCP or network
	actor.		actor.
	* For wired networks where clients typically are connected to a		* For wired networks where clients typically are connected to a
	switch port, snooping DHCP multicast (or unicast) traffic becomes		switch port, snooping DHCP multicast (or unicast) traffic becomes
	difficult, as the switches limit the traffic delivered to a port.		difficult, as the switches limit the traffic delivered to a port.
	The client's DHCP multicast messages (with destination address		The client's DHCP multicast messages (with destination address
	fe02::1:2) are only forwarded to the DHCP server's (or relay's)		fe02::1:2) are only forwarded to the DHCP server's (or relay's)
	switch port -- not all ports. Also, the server's (or relay's)		switch port -- not all ports. Also, the server's (or relay's)
	skipping to change at line 5871 ¶		skipping to change at line 5866 ¶
	IANA, "Option Codes",		IANA, "Option Codes",
	<https://www.iana.org/assignments/dhcpv6-parameters>.		<https://www.iana.org/assignments/dhcpv6-parameters>.
	[IANA-PEN] IANA, "Private Enterprise Numbers",		[IANA-PEN] IANA, "Private Enterprise Numbers",
	<https://www.iana.org/assignments/enterprise-numbers>.		<https://www.iana.org/assignments/enterprise-numbers>.
	[IANA-RESERVED-IID]		[IANA-RESERVED-IID]
	IANA, "Reserved IPv6 Interface Identifiers",		IANA, "Reserved IPv6 Interface Identifiers",
	<https://www.iana.org/assignments/ipv6-interface-ids>.		<https://www.iana.org/assignments/ipv6-interface-ids>.
	[IEEE-802.1x]		[IEEE8802.1x]
	IEEE, "IEEE Standard for Local and metropolitan area		IEEE/ISO/IEC, "IEEE/ISO/IEC International Standard-
	networks--Port-Based Network Access Control", IEEE 802.1X-		Telecommunications and exchange between information
	2010, DOI 10.1109/IEEESTD.2010.5409813, February 2010,		technology systems--Requirements for local and
	<https://ieeexplore.ieee.org/document/5409813>.		metropolitan area networks--Part 1X:Port-based network
			access control", ISO/IEC/IEEE 8802-1X:2021,
			DOI 10.1109/IEEESTD.2021.9650828, 2021,
			<https://ieeexplore.ieee.org/document/9650828>.
	[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/info/rfc2131>.		<https://www.rfc-editor.org/info/rfc2131>.
	[RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet		[RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet
	Networks", RFC 2464, DOI 10.17487/RFC2464, December 1998,		Networks", RFC 2464, DOI 10.17487/RFC2464, December 1998,
	<https://www.rfc-editor.org/info/rfc2464>.		<https://www.rfc-editor.org/info/rfc2464>.
	[RFC3162] Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6",		[RFC3162] Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6",
	skipping to change at line 6125 ¶		skipping to change at line 6123 ¶
	Use of this was rarely practical as typically relay agents		Use of this was rarely practical as typically relay agents
	between the client and server need to glean information from		between the client and server need to glean information from
	the communication and cannot be bypassed.		the communication and cannot be bypassed.
	* UseMulticast status code. The UseMulticast status code has		* UseMulticast status code. The UseMulticast status code has
	been obsoleted. Clients will always multicast messages (as		been obsoleted. Clients will always multicast messages (as
	Server Unicast option has been obsoleted) and servers will no		Server Unicast option has been obsoleted) and servers will no
	longer check for unicast traffic.		longer check for unicast traffic.
	2. The following errata reports for [RFC8415] were incorporated:		2. The following errata reports for [RFC8415] were incorporated:
	[Err6159] [Err6269], [Err6183]. Note that EID 6269 was no longer		[Err6159], [Err6269], and [Err6183]. Note that EID 6269 was no
	applicable after the Server Unicast Option was obsoleted. Note		longer applicable after the Server Unicast Option was obsoleted.
	that EID 6159 was also no longer applicable as temporary		Note that EID 6159 was also no longer applicable as temporary
	addresses have been obsoleted. Indeed, the text that EID 6159		addresses have been obsoleted. Indeed, the text that EID 6159
	corrects has been deleted.		corrects has been deleted.
	3. A reference to [RFC7943] was added to Section 13.1 as it		3. A reference to [RFC7943] was added to Section 13.1 as it
	documents a method that might be used to generate addresses and		documents a method that might be used to generate addresses and
	was inadvertently missed when compiling [RFC8415].		was inadvertently missed when compiling [RFC8415].
	4. Clarified the UDP ports used by clients, servers, and relay		4. Clarified the UDP ports used by clients, servers, and relay
	agents (Section 7.2).		agents (Section 7.2).
	skipping to change at line 6161 ¶		skipping to change at line 6159 ¶
	| | ID | ID | | | | |Time |Msg. | |		| | ID | ID | | | | |Time |Msg. | |
	+=========+========+========+=====+=====+===+====+=====+=====+=====+		+=========+========+========+=====+=====+===+====+=====+=====+=====+
	| Solicit | * | | * | * | * | | * | | |		| Solicit | * | | * | * | * | | * | | |
	+=========+--------+--------+-----+-----+---+----+-----+-----+-----+		+=========+--------+--------+-----+-----+---+----+-----+-----+-----+
	| Advert. | * | * | * | * | | * | | | |		| Advert. | * | * | * | * | | * | | | |
	+=========+--------+--------+-----+-----+---+----+-----+-----+-----+		+=========+--------+--------+-----+-----+---+----+-----+-----+-----+
	| Request | * | * | * | * | * | | * | | |		| Request | * | * | * | * | * | | * | | |
	+=========+--------+--------+-----+-----+---+----+-----+-----+-----+		+=========+--------+--------+-----+-----+---+----+-----+-----+-----+
	| Confirm | * | | * | | | | * | | |		| Confirm | * | | * | | | | * | | |
	+=========+--------+--------+-----+-----+---+----+-----+-----+-----+		+=========+--------+--------+-----+-----+---+----+-----+-----+-----+
	| Renew | * | * | * | * | * | * | * | | |		| Renew | * | * | * | * | * | | * | | |
	+=========+--------+--------+-----+-----+---+----+-----+-----+-----+		+=========+--------+--------+-----+-----+---+----+-----+-----+-----+
	| Rebind | * | | * | * | * | | * | | |		| Rebind | * | | * | * | * | | * | | |
	+=========+--------+--------+-----+-----+---+----+-----+-----+-----+		+=========+--------+--------+-----+-----+---+----+-----+-----+-----+
	| Decline | * | * | * | * | | | * | | |		| Decline | * | * | * | * | | | * | | |
	+=========+--------+--------+-----+-----+---+----+-----+-----+-----+		+=========+--------+--------+-----+-----+---+----+-----+-----+-----+
	| Release | * | * | * | * | | | * | | |		| Release | * | * | * | * | | | * | | |
	+=========+--------+--------+-----+-----+---+----+-----+-----+-----+		+=========+--------+--------+-----+-----+---+----+-----+-----+-----+
	| Reply | * | * | * | * | | | | | * |		| Reply | * | * | * | * | | | | | * |
	+=========+--------+--------+-----+-----+---+----+-----+-----+-----+		+=========+--------+--------+-----+-----+---+----+-----+-----+-----+
	| Reconf | * | * | | | | | | | * |		| Reconf | * | * | | | | | | | * |
	+=========+--------+--------+-----+-----+---+----+-----+-----+-----+		+=========+--------+--------+-----+-----+---+----+-----+-----+-----+
	| Inform. | * | (see | | | * | | * | | |		| Inform. | * | (see | | | * | | * | | |
	| | | note) | | | | | | | |		| | | note) | | | | | | | |
	+=========+--------+--------+-----+-----+---+----+-----+-----+-----+		+=========+--------+--------+-----+-----+---+----+-----+-----+-----+
	| R-forw. | | | | | | | | | * |		| R-forw. | | | | | | | | * | |
	+=========+--------+--------+-----+-----+---+----+-----+-----+-----+		+=========+--------+--------+-----+-----+---+----+-----+-----+-----+
	| R-repl. | | | | | | | | | * |		| R-repl. | | | | | | | | * | |
	+=========+--------+--------+-----+-----+---+----+-----+-----+-----+		+=========+--------+--------+-----+-----+---+----+-----+-----+-----+
	Table 4		Table 4: Appearance of Options in Message Types (Part 1 of 3)
	NOTE: The Server Identifier option (see Section 21.3) is only		NOTE: The Server Identifier option (see Section 21.3) is only
	included in Information-request messages that are sent in response to		included in Information-request messages that are sent in response to
	a Reconfigure (see Section 18.2.6).		a Reconfigure (see Section 18.2.6).
	+=======+======+=====+=====+======+======+======+======+======+=====+		+=======+======+=====+=====+======+======+======+======+======+=====+
	| |Status|Rap. |User |Vendor|Vendor|Inter.|Recon.|Recon.|Info |		| |Status|Rap. |User |Vendor|Vendor|Inter.|Recon.|Recon.|Info |
	| |Code |Comm.|Class|Class |Spec. |ID |Msg. |Accept|Refr.|		| |Code |Comm.|Class|Class |Spec. |ID |Msg. |Accept|Refr.|
	| | | | | | | | | |Time |		| | | | | | | | | |Time |
	+=======+======+=====+=====+======+======+======+======+======+=====+		+=======+======+=====+=====+======+======+======+======+======+=====+
	skipping to change at line 6219 ¶		skipping to change at line 6217 ¶
	+=======+------+-----+-----+------+------+------+------+------+-----+		+=======+------+-----+-----+------+------+------+------+------+-----+
	|Reconf.| | | | | | | * | | |		|Reconf.| | | | | | | * | | |
	+=======+------+-----+-----+------+------+------+------+------+-----+		+=======+------+-----+-----+------+------+------+------+------+-----+
	|Inform.| | | * | * | * | | | * | |		|Inform.| | | * | * | * | | | * | |
	+=======+------+-----+-----+------+------+------+------+------+-----+		+=======+------+-----+-----+------+------+------+------+------+-----+
	|R-forw.| | | | | * | * | | | |		|R-forw.| | | | | * | * | | | |
	+=======+------+-----+-----+------+------+------+------+------+-----+		+=======+------+-----+-----+------+------+------+------+------+-----+
	|R-repl.| | | | | * | * | | | |		|R-repl.| | | | | * | * | | | |
	+=======+------+-----+-----+------+------+------+------+------+-----+		+=======+------+-----+-----+------+------+------+------+------+-----+
	Table 5		Table 5: Appearance of Options in Message Types (Part 2 of 3)
	+=========+============+============+		+=========+============+============+
	| | SOL_MAX_RT | INF_MAX_RT |		| | SOL_MAX_RT | INF_MAX_RT |
	+=========+============+============+		+=========+============+============+
	| Solicit | | |		| Solicit | | |
	+---------+------------+------------+		+---------+------------+------------+
	| Advert. | * | |		| Advert. | * | |
	+---------+------------+------------+		+---------+------------+------------+
	| Request | | |		| Request | | |
	+---------+------------+------------+		+---------+------------+------------+
	skipping to change at line 6251 ¶		skipping to change at line 6249 ¶
	+---------+------------+------------+		+---------+------------+------------+
	| Reconf. | | |		| Reconf. | | |
	+---------+------------+------------+		+---------+------------+------------+
	| Inform. | | |		| Inform. | | |
	+---------+------------+------------+		+---------+------------+------------+
	| R-forw. | | |		| R-forw. | | |
	+---------+------------+------------+		+---------+------------+------------+
	| R-repl. | | |		| R-repl. | | |
	+---------+------------+------------+		+---------+------------+------------+
	Table 6		Table 6: Appearance of Options in
			Message Types (Part 3 of 3)
	Appendix C. Appearance of Options in the "options" Field of DHCP		Appendix C. Appearance of Options in the "options" Field of DHCP
	Options		Options
	The following table indicates with a "*" where options defined in		The following table indicates with a "*" where options defined in
	this document can appear as top-level options or can be encapsulated		this document can appear as top-level options or can be encapsulated
	in other options defined in this document. Other RFCs may define		in other options defined in this document. Other RFCs may define
	additional situations where options defined in this document are		additional situations where options defined in this document are
	encapsulated in other options.		encapsulated in other options.
	skipping to change at line 6325 ¶		skipping to change at line 6324 ¶
	+============+-----+-----+------+-----+----------+--------+--------+		+============+-----+-----+------+-----+----------+--------+--------+
	| Info | * | | | | | | |		| Info | * | | | | | | |
	| Refresh | | | | | | | |		| Refresh | | | | | | | |
	| Time | | | | | | | |		| Time | | | | | | | |
	+============+-----+-----+------+-----+----------+--------+--------+		+============+-----+-----+------+-----+----------+--------+--------+
	| SOL_MAX_RT | * | | | | | | |		| SOL_MAX_RT | * | | | | | | |
	+============+-----+-----+------+-----+----------+--------+--------+		+============+-----+-----+------+-----+----------+--------+--------+
	| INF_MAX_RT | * | | | | | | |		| INF_MAX_RT | * | | | | | | |
	+============+-----+-----+------+-----+----------+--------+--------+		+============+-----+-----+------+-----+----------+--------+--------+
	Table 7		Table 7: Appearance of Options
	Notes: Options asterisked in the "Top-Level" column appear in the		Notes: Options asterisked in the "Top-Level" column appear in the
	"options" field of client messages (see Section 8). Options		"options" field of client messages (see Section 8). Options
	asterisked in the "RELAY-FORW" and "RELAY-REPL" columns appear in the		asterisked in the "RELAY-FORW" and "RELAY-REPL" columns appear in the
	"options" field of the Relay-forward and Relay-reply messages (see		"options" field of the Relay-forward and Relay-reply messages (see
	Section 9).		Section 9).
	Acknowledgments		Acknowledgments
	This document is merely a refinement of earlier work as described in		This document is merely a refinement of earlier work as described in
End of changes. 28 change blocks.
	74 lines changed or deleted		73 lines changed or added
This html diff was produced by rfcdiff 1.48.