draft-ietf-dhc-dhcpv6-stateful-issues-04.txt		draft-ietf-dhc-dhcpv6-stateful-issues-05.txt
	Network Working Group O. Troan		Network Working Group O. Troan
	Internet-Draft B. Volz		Internet-Draft B. Volz
	Updates: 3315,3633 (if approved) Cisco Systems, Inc.		Updates: 3315,3633 (if approved) Cisco Systems, Inc.
	Intended status: Standards Track May 13, 2013		Intended status: Standards Track January 1, 2014
	Expires: November 14, 2013		Expires: July 5, 2014
	Issues with multiple stateful DHCPv6 options		Issues with multiple stateful DHCPv6 options
	draft-ietf-dhc-dhcpv6-stateful-issues-04.txt		draft-ietf-dhc-dhcpv6-stateful-issues-05.txt
	Abstract		Abstract
	Dynamic Host Configuration Protocol for IPv6 (DHCPv6) was not written		Dynamic Host Configuration Protocol for IPv6 (DHCPv6) was not written
	with the expectation that additional stateful DHCPv6 options would be		with the expectation that additional stateful DHCPv6 options would be
	developed. IPv6 Prefix Options for Dynamic Host Configuration		developed. IPv6 Prefix Options for Dynamic Host Configuration
	Protocol (DHCP) version 6 shoe-horned the new options for Prefix		Protocol (DHCP) version 6 shoe-horned the new options for Prefix
	Delegation into DHCPv6. Implementation experience of the CPE model		Delegation into DHCPv6. Implementation experience of the CPE model
	described in [RFC6204] has shown multiple issues with the DHCPv6		described in RFC6204 has shown multiple issues with the DHCPv6
	protocol in supporting multiple stateful options.		protocol in supporting multiple stateful options. This document
			updates RFC3315 and indirectly RFC3633.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on November 14, 2013.		This Internet-Draft will expire on July 5, 2014.
	Copyright Notice		Copyright Notice
	Copyright (c) 2013 IETF Trust and the persons identified as the		Copyright (c) 2014 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3		3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
	4. Handling of multiple IA options types . . . . . . . . . . . . 3		4. Handling of multiple IA options types . . . . . . . . . . . . 3
	4.1. Advertisement message . . . . . . . . . . . . . . . . . . 4		4.1. Advertise Message . . . . . . . . . . . . . . . . . . . . 4
	4.2. Placement of Status codes . . . . . . . . . . . . . . . . 5		4.2. Placement of Status Codes . . . . . . . . . . . . . . . . 5
	4.3. T1/T2 timers . . . . . . . . . . . . . . . . . . . . . . 5		4.3. T1/T2 Timers . . . . . . . . . . . . . . . . . . . . . . 5
	4.4. Renew and Rebind messages . . . . . . . . . . . . . . . . 6		4.4. Renew Message . . . . . . . . . . . . . . . . . . . . . . 6
	4.5. Confirm message . . . . . . . . . . . . . . . . . . . . . 7		4.5. Rebind Message . . . . . . . . . . . . . . . . . . . . . 7
	4.6. Release messages . . . . . . . . . . . . . . . . . . . . 8		4.6. Confirm Message . . . . . . . . . . . . . . . . . . . . . 8
	4.7. Multiple provisioning domains . . . . . . . . . . . . . . 9		4.7. Release Message . . . . . . . . . . . . . . . . . . . . . 9
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9		4.8. Multiple Provisioning Domains . . . . . . . . . . . . . . 9
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 9		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
	7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9		6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9		7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
	8.1. Normative References . . . . . . . . . . . . . . . . . . 9		8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
	8.2. Informative References . . . . . . . . . . . . . . . . . 9		8.1. Normative References . . . . . . . . . . . . . . . . . . 10
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9		8.2. Informative References . . . . . . . . . . . . . . . . . 10
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
	1. Introduction		1. Introduction
	DHCPv6 [RFC3315] was not written with the expectation that additional		DHCPv6 [RFC3315] was not written with the expectation that additional
	stateful DHCPv6 options would be developed. DHCPv6 Prefix Delegation		stateful DHCPv6 options would be developed. DHCPv6 Prefix Delegation
	[RFC3633] shoe-horned the new options for Prefix Delegation into		[RFC3633] shoe-horned the new options for Prefix Delegation into
	DHCPv6. Implementation experience of the CPE model described in		DHCPv6. Implementation experience of the CPE model described in
	[RFC6204] has shown multiple issues with the DHCPv6 protocol in		[RFC6204] has shown multiple issues with the DHCPv6 protocol in
	supporting multiple stateful options.		supporting multiple stateful options.
	skipping to change at page 3, line 45		skipping to change at page 3, line 45
	DHCPv6 was written with the assumption that the only stateful options		DHCPv6 was written with the assumption that the only stateful options
	were for assigning addresses. DHCPv6 PD describes how to extend the		were for assigning addresses. DHCPv6 PD describes how to extend the
	DHCPv6 protocol to handle prefix delegation, but [RFC3633] did not		DHCPv6 protocol to handle prefix delegation, but [RFC3633] did not
	consider how DHCP address assignment and prefix delegation could co-		consider how DHCP address assignment and prefix delegation could co-
	exist.		exist.
	If a client requests multiple IA option types, but the server is		If a client requests multiple IA option types, but the server is
	configured to only offer a subset of them, the client could react in		configured to only offer a subset of them, the client could react in
	several ways. Reset the state machine and continue to send Solicit		several ways. Reset the state machine and continue to send Solicit
	messages, create separate DHCP sessions for each IA option type and		messages, create separate DHCP sessions for each IA option type and
	continue to Solicit for the missing options, or it could continue		continue to Solicit for the unfulfilled IA options, or it could
	with the single session, and include the missing options on		continue with the single session, and include the unfulfilled IA
	subsequent messages to the server.		options on subsequent messages to the server.
	Proposed solution: the client should keep a single session with the		Proposed solution: the client should keep a single session with the
	server and include the missing options on subsequent messages		server and include the missing options on subsequent messages
	(Request, Renew, and Rebind) to the server.		(Request, Renew, and Rebind) to the server.
	4.1. Advertisement message		4.1. Advertise Message
	[RFC3315] specifies that a client must ignore an Advertise message if		[RFC3315] specifies that a client must ignore an Advertise message if
	a server will not assign any addresses to a client. A client		a server will not assign any addresses to a client. A client
	requesting both IA_NA and IA_PD, with a server that only offers one		requesting both IA_NA and IA_PD, with a server that only offers one
	of them, is not supported in the current protocol specification.		of them, is not supported in the current protocol specification.
	Proposed solution: a client SHOULD accept Advertise messages, even		Proposed solution: a client SHOULD accept Advertise messages, even
	when not all IA option types are being offered. A client SHOULD		when not all IA option types are being offered. A client SHOULD
	ignore an Advertise message when no bindings at all are being		ignore an Advertise message when no bindings at all are being
	offered. The client SHOULD include the not offered IA option types		offered. The client SHOULD include the not offered IA option types
	in its Request.		in its Request.
	Replace Section 17.1.3 of [RFC3315]: (existing errata)		Replace Section 17.1.3 of [RFC3315]: (existing errata)
	The client MUST ignore any Advertise message that includes a Status		The client MUST ignore any Advertise message that includes a Status
	Code option containing the value NoAddrsAvail, with the exception		Code option containing the value NoAddrsAvail, with the exception
	that the client MAY display the associated status message(s) to the		that the client MAY display the associated status message(s) to the
	user.		user.
	With:		With:
	The client MUST ignore any Advertise message that contains no		The client MUST ignore any Advertise message that contains no
	bindings (if only IA_NA and/or IA_TA options were requested,		bindings (if only IA_NA and/or IA_TA options were requested,
	this is a message that includes a Status Code option containing the		this is a message that includes a Status Code option containing the
	value NoAddrsAvail), with the exception that the client MAY display		value NoAddrsAvail), with the exception that the client MAY display
	the associated status message(s) to the user.		the associated status message(s) to the user.
	And, replace:		And, replace:
	- The client MAY choose a less-preferred server if that server		- The client MAY choose a less-preferred server if that server
	has a better set of advertised parameters, such as the		has a better set of advertised parameters, such as the
	available addresses advertised in IAs.		available addresses advertised in IAs.
	With:		With:
	- The client MAY choose a less-preferred server if that server		- The client MAY choose a less-preferred server if that server
	has a better set of advertised parameters, such as the		has a better set of advertised parameters, such as the
	available options advertised in IAs.		available options advertised in IAs.
	It is important to note that the receipt of a Advertisement without		It is important to note that the receipt of a Advertisement without
	any bindings does not imply that the client should restart the		any bindings does not imply that the client should restart the
	Solicit retransmissions timers. Doing so would lead to a Solicit/		Solicit retransmissions timers. Doing so would lead to a Solicit/
	Advertisement storm.		Advertisement storm.
	4.2. Placement of Status codes		4.2. Placement of Status Codes
	In Reply messages IA specific status codes (i.e., NoAddrsAvail,		In Reply messages IA specific status codes (i.e., NoAddrsAvail,
	NotOnlink, NoBinding, NoPrefixAvail) are encapsulated in the IA		NotOnlink, NoBinding, NoPrefixAvail) are encapsulated in the IA
	option. In Advertisement messages the Status Code option with the		option. In Advertisement messages the Status Code option with the
	NoAddrsAvail code is in the "global" scope. That makes sense when		NoAddrsAvail code is in the "global" scope. That makes sense when
	the failure case is fatal. With the introduction of multiple IA		the failure case is fatal. With the introduction of multiple IA
	option types, there might be a case where a server is not willing to		option types, there might be a case where a server is not willing to
	offer addresses, but might be willing to offer other stateful option		offer addresses, but might be willing to offer other stateful option
	types.		types.
	While a Status Code option is implicitly bound to a specific type of		While a Status Code option is implicitly bound to a specific type of
	IA, e.g. NoPrefixAvail is only applicable to IA_PD and NoAddrsAvail		IA, e.g. NoPrefixAvail is only applicable to IA_PD and NoAddrsAvail
	is only applicable to IA_NA/IA_TA, it may be problematic to make this		is only applicable to IA_NA/IA_TA, it may be problematic to make this
	assumption for all status codes. Ideally the Status Code option		assumption for all status codes. Ideally the Status Code option
	should be encapsulated in the IA option for all DHCP messages. This		should be encapsulated in the IA option for all DHCP messages. This
	makes Advertisement messages equal to Reply messages.		makes Advertisement messages equal to Reply messages.
	Proposed solution: No change. For backwards compatibility, the		Proposed solution: No change. For backwards compatibility, the
	NoAddrsAvail Status Code option when no addresses are available will		NoAddrsAvail Status Code option when no addresses are available will
	be kept in the global scope for Advertise messages. Other IA option		be kept in the global scope for Advertise messages. Other IA option
	types MUST encapsulate the Status Code option within the IA option.		types MUST encapsulate the Status Code option within the IA option.
	To clarify further: when a client requests both IA_NA and IA_PD, and		To clarify further: when a client requests both IA_NA and IA_PD, and
	the server can offer IA_PD but not IA_NA, the server sends an		the server can offer IA_PD but not IA_NA, the server sends an
	Advertise response containing no IA_NA option, a status code option		Advertise response containing no IA_NA option, a status code option
	of NoAddrsAvail, and one or more IA_PD options containing IAPREFIX		of NoAddrsAvail, and one or more IA_PD options containing IAPREFIX
	options.		options.
	4.3. T1/T2 timers		4.3. T1/T2 Timers
	The T1 and T2 timers determine when the client will contact the		The T1 and T2 timers determine when the client will contact the
	server to extend lifetimes of information received in an IA. How		server to extend lifetimes of information received in an IA. How
	should a client handle the case where multiple IA options have		should a client handle the case where multiple IA options have
	different T1 and T2 timers?		different T1 and T2 timers?
	In a multiple IA option types model, the T1/T2 timers are protocol		In a multiple IA option types model, the T1/T2 timers are protocol
	timers, that should be independent of the IA options themselves. If		timers, that should be independent of the IA options themselves. If
	we were to redo the DHCP protocol from scratch the T1/T2 timers		we were to redo the DHCP protocol from scratch the T1/T2 timers
	should be carried in a separate DHCP option.		should be carried in a separate DHCP option.
	Proposed solution: The server SHOULD set the T1/T2 timers in all IA		Proposed solution: The server SHOULD set the T1/T2 timers in all IA
	options in Reply and Advertise messages to the same value. To deal		options in Reply and Advertise messages to the same value. To deal
	with the case where servers have not yet been updated to do that,		with the case where servers have not yet been updated to do that,
	clients MUST use the shortest (explicit or implicit) T1/T2 timer		clients MUST use the shortest (explicit or implicit) T1/T2 timer
	(larger than 0) in any IA options in the Reply. Longer T1/T2 timers		(larger than 0) in any IA options in the Reply. Longer T1/T2 timers
	are ignored.		are ignored.
	4.4. Renew and Rebind messages		4.4. Renew Message
	The Renew message, as described in [RFC3315], allows a client to only		The Renew message, as described in [RFC3315], allows a client to only
	renew bindings assigned via a Request message. The Rebind message,		renew bindings assigned via a Request message.
	as described in [RFC3315] does not explicitly specify what a server
	should do when an IA option which contains no addresses is present.
	In a multiple IA option type model, the Renew does not support the		In a multiple IA option type model, the Renew does not support the
	ability for the client to renew one IA option type while requesting		ability for the client to renew one IA option type while requesting
	bindings for other IA option types that were not available when the		bindings for other IA option types that were not available when the
	client sent the Request.		client sent the Request.
	Proposed solution: The client should continue with the IA options		Proposed solution: The client should continue with the IA options
	received, while continuing to include the other IA options in		received, while continuing to include the other IA options in
	subsequent messages to the server. The client and server processing		subsequent messages to the server. The client and server processing
	need to be modified. Note that this change makes the server's IA		need to be modified. Note that this change makes the server's IA
	processing of Renew and Rebind similar to the Request processing.		processing of Renew and Rebind similar to the Request processing.
	Replace Section 18.1.3 of [RFC3315]:		Replace Section 18.1.3 of [RFC3315]:
	At time T1 for an IA, the client initiates a Renew/Reply message		At time T1 for an IA, the client initiates a Renew/Reply message
	exchange to extend the lifetimes on any addresses in the IA. The		exchange to extend the lifetimes on any addresses in the IA. The
	client includes an IA option with all addresses currently assigned		client includes an IA option with all addresses currently assigned
	to the IA in its Renew message.		to the IA in its Renew message.
	With:		With:
	At time T1 for an IA, the client initiates a Renew/Reply message		At time T1 for an IA, the client initiates a Renew/Reply message
	exchange to extend the lifetimes on any addresses in the IA. The		exchange to extend the lifetimes on any addresses in the IA. The
	client includes an IA option with all addresses currently assigned		client includes an IA option with all addresses currently assigned
	to the IA in its Renew message. The client also includes an IA		to the IA in its Renew message. The client also includes an IA
	option for each binding it desires but has been unable to obtain.		option for each binding it desires but has been unable to obtain.
	Replace Section 18.2.3 of [RFC3315]:		Replace Section 18.2.3 of [RFC3315]:
	If the server cannot find a client entry for the IA the server		If the server cannot find a client entry for the IA the server
	returns the IA containing no addresses with a Status Code option		returns the IA containing no addresses with a Status Code option
	set to NoBinding in the Reply message.		set to NoBinding in the Reply message.
	With:		With:
	If the server cannot find a client entry for the IA the server		If the server cannot find a client entry for the IA the server
	creates the bindings for that client according to the server's		creates the bindings for that client according to the server's
	policy and configuration information and records the IAs and		policy and configuration information and records the IAs and
	other information requested by the client.		other information requested by the client.
	Note that clients that communicate with servers that do not support		Note that clients that communicate with servers that do not support
	this updated Renew processing will receive the NoBinding status for		this updated Renew processing will receive the NoBinding status for
	the IA which had no bindings. The client MUST continue to process		the IA which had no bindings. The client MUST continue to process
	the other IAs in the Reply. The client MAY attempt a Solicit/		the other IAs in the Reply. The client MAY attempt a Solicit/
	Advertise/Request/Reply sequence periodically to obtain bindings for		Advertise/Request/Reply sequence periodically to obtain bindings for
	these IAs. However, it MUST limit the frequency at which is does		these IAs. However, it MUST limit the frequency at which is does
	this to no more often than the renewal frequency.		this to no more often than the renewal frequency.
			4.5. Rebind Message
			The Rebind message, as described in [RFC3315] does not explicitly
			specify what a server should do when an IA option which contains no
			addresses is present.
	Replace Section 18.1.4 of [RFC3315]:		Replace Section 18.1.4 of [RFC3315]:
	At time T2 for an IA (which will only be reached if the server to		At time T2 for an IA (which will only be reached if the server to
	which the Renew message was sent at time T1 has not responded), the		which the Renew message was sent at time T1 has not responded), the
	client initiates a Rebind/Reply message exchange with any available		client initiates a Rebind/Reply message exchange with any available
	server. The client includes an IA option with all addresses		server. The client includes an IA option with all addresses
	currently assigned to the IA in its Rebind message.		currently assigned to the IA in its Rebind message.
	With:		With:
	At time T2 for an IA (which will only be reached if the server to		At time T2 for an IA (which will only be reached if the server to
	which the Renew message was sent at time T1 has not responded), the		which the Renew message was sent at time T1 has not responded), the
	client initiates a Rebind/Reply message exchange with any available		client initiates a Rebind/Reply message exchange with any available
	server. The client includes an IA option with all addresses		server. The client includes an IA option with all addresses
	currently assigned to the IA in its Rebind message. The client		currently assigned to the IA in its Rebind message. The client
	also includes an IA option for each binding it desires but has been		also includes an IA option for each binding it desires but has been
	unable to obtain.		unable to obtain.
	4.5. Confirm message		Replace Section 18.2.4 of [RFC3315] with the following text to
			clarify how the server should handle all of the possible conditions:
			When the server receives a Rebind message that contains an IA
			option from a client, it locates the client's binding and verifies
			that the information in the IA from the client matches the
			information stored for that client.
			If the server finds the addresses in the IA for the client and the
			server determines that the addresses in the IA are appropriate for
			the link to which the client's interface is attached according to
			the server's explicit configuration information, the server SHOULD
			send back the IA to the client with new lifetimes and T1/T2 times.
			If the server cannot find a client entry for the IA and the server
			determines that the addresses in the IA are not appropriate for the
			link to which the client's interface is attached according to the
			server's explicit configuration information, the server MAY send a
			Reply message to the client containing the client's IA, with the
			lifetimes for the addresses in the IA set to zero. This Reply
			constitutes an explicit notification to the client that the
			addresses in the IA are no longer valid. In this situation, if the
			server does not send a Reply message it silently discards the
			Rebind message.
			If the server cannot find a client entry for the IA and the server
			determines that the addresses in the IA are appropriate for the
			link to which the client's interface is attached according to the
			server's explicit configuration information, and the addresses are
			not in use, the server MAY assign the addresses to the client and
			send a Reply message to the client with new lifetimes and T1/T2
			times for the bindings. If the server cannot assign the addresses
			to the client, the server returns the IA containing no addresses
			with a Status Code option set to NoBinding in the Reply message.
			Note: A server SHOULD NOT provide additional bindings to the client
			as the client could accept a Reply from a different server (this is
			the same issue as in the Discussion under the Rapid Commit option,
			see section 22.14).
			The server constructs a Reply message by setting the "msg-type"
			field to REPLY, and copying the transaction ID from the Rebind
			message into the transaction-id field.
			The server MUST include a Server Identifier option containing the
			server's DUID and the Client Identifier option from the Rebind
			message in the Reply message.
			The server includes other options containing configuration
			information to be returned to the client as described in section
			18.2.
			4.6. Confirm Message
	The Confirm message, as described in [RFC3315], is specific to		The Confirm message, as described in [RFC3315], is specific to
	address assignment. It allows a server without a binding reply to		address assignment. It allows a server without a binding reply to
	the message, under the assumption that the server only needs		the message, under the assumption that the server only needs
	knowledge about the prefix(es) on the link, to inform the client that		knowledge about the prefix(es) on the link, to inform the client that
	the address is likely valid or not. This message is sent when e.g.		the address is likely valid or not. This message is sent when e.g.
	the client has moved and needs to validate its addresses. Not all		the client has moved and needs to validate its addresses. Not all
	bindings can be validated by servers and the Confirm message provides		bindings can be validated by servers and the Confirm message provides
	for this by specifying that a server that is unable to determine the		for this by specifying that a server that is unable to determine the
	on-link status MUST NOT send a Reply.		on-link status MUST NOT send a Reply.
	skipping to change at page 8, line 13		skipping to change at page 9, line 11
	Rebind. It also is lower processing cost as the server does NOT need		Rebind. It also is lower processing cost as the server does NOT need
	to extend lease times or otherwise send back other configuration		to extend lease times or otherwise send back other configuration
	options.		options.
	Proposed solution: Allow and specify the Confirm message for other IA		Proposed solution: Allow and specify the Confirm message for other IA
	option types. The server performs the same test as for addresses on		option types. The server performs the same test as for addresses on
	the delegated prefixes (see [RFC3315], section 18.2.2).		the delegated prefixes (see [RFC3315], section 18.2.2).
	Replace Section 12.1 of [RFC3633]:		Replace Section 12.1 of [RFC3633]:
	If such verification is needed the requesting router MUST initiate		If such verification is needed the requesting router MUST initiate
	a Rebind/Reply message exchange as described in section 18.1.4,		a Rebind/Reply message exchange as described in section 18.1.4,
	"Creation and Transmission of Rebind Messages" of RFC 3315, with		"Creation and Transmission of Rebind Messages" of RFC 3315, with
	the exception that the retransmission parameters should be set as		the exception that the retransmission parameters should be set as
	for the Confirm message, described in section 18.1.2, "Creation		for the Confirm message, described in section 18.1.2, "Creation
	and Transmission of Confirm Messages" of RFC 3315. The requesting		and Transmission of Confirm Messages" of RFC 3315. The requesting
	router includes any IA_PDs, along with prefixes associated with		router includes any IA_PDs, along with prefixes associated with
	those IA_PDs in its Rebind message.		those IA_PDs in its Rebind message.
	...		...
	The Confirm and Decline message types are not used with Prefix		The Confirm and Decline message types are not used with Prefix
	Delegation.		Delegation.
	With:		With:
	If such verification is needed the requesting router MUST initiate		If such verification is needed the requesting router MUST initiate
	a Confirm message exchange as described in section 18.1.2,		a Confirm message exchange as described in section 18.1.2,
	"Creation and Transmission of Confirm Messages" of RFC 3315. The		"Creation and Transmission of Confirm Messages" of RFC 3315. The
	requesting router includes any IA_PDs, along with prefixes		requesting router includes any IA_PDs, along with prefixes
	associated with those IA_PDs in its Confirm message.		associated with those IA_PDs in its Confirm message.
	...		...
	The Decline message type is not used with Prefix Delegation.		The Decline message type is not used with Prefix Delegation.
	4.6. Release messages		4.7. Release Message
	A client can release any individual lease at any time. A client can		A client can release any individual lease at any time. A client can
	get "back" a lease by using a Renew message. It MAY do this at any		get "back" a lease by using a Renew message. It MAY do this at any
	time, though must avoid creating a Renew storm. E.g. wait until T1.		time, though must avoid creating a Renew storm. E.g. wait until T1.
	4.7. Multiple provisioning domains		4.8. Multiple Provisioning Domains
	This document has assumed that all DHCP servers on a network are in a		This document has assumed that all DHCP servers on a network are in a
	single provisioning domain and thus should be "equal" in the service		single provisioning domain and thus should be "equal" in the service
	that they offer. This was also assumed by [RFC3315] and [RFC3633].		that they offer. This was also assumed by [RFC3315] and [RFC3633].
	One could envision a network where the DHCP servers are in multiple		One could envision a network where the DHCP servers are in multiple
	provisioning domains, and it may be desirable to have the DHCP client		provisioning domains, and it may be desirable to have the DHCP client
	obtain different IA types from different provisioning domains. How a		obtain different IA types from different provisioning domains. How a
	client detects the multiple provisioning domains and how it would		client detects the multiple provisioning domains and how it would
	interact with the multiple servers in these different domains is		interact with the multiple servers in these different domains is
	outside the scope of this document and an area for future work.		outside the scope of this document.
	5. IANA Considerations		5. IANA Considerations
	This specification does not require any IANA actions.		This specification does not require any IANA actions.
	6. Security Considerations		6. Security Considerations
	There are no new security considerations pertaining to this document.		There are no new security considerations pertaining to this document.
	7. Acknowledgements		7. Acknowledgements
End of changes. 35 change blocks.
	98 lines changed or deleted		156 lines changed or added
This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/