draft-ietf-dhc-dhcpv6-stateful-issues-03.txt		draft-ietf-dhc-dhcpv6-stateful-issues-04.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 November 5, 2012		Intended status: Standards Track May 13, 2013
	Expires: May 9, 2013		Expires: November 14, 2013
	Issues with multiple stateful DHCPv6 options		Issues with multiple stateful DHCPv6 options
	draft-ietf-dhc-dhcpv6-stateful-issues-03.txt		draft-ietf-dhc-dhcpv6-stateful-issues-04.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 has shown multiple issues with the DHCPv6 protocol in		described in [RFC6204] has shown multiple issues with the DHCPv6
	supporting multiple stateful options.		protocol in supporting multiple stateful options.
	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 May 9, 2013.		This Internet-Draft will expire on November 14, 2013.
	Copyright Notice		Copyright Notice
	Copyright (c) 2012 IETF Trust and the persons identified as the		Copyright (c) 2013 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3		3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
	4. Handling of multiple IA options types . . . . . . . . . . . . 4		4. Handling of multiple IA options types . . . . . . . . . . . . 3
	4.1. Advertisement message . . . . . . . . . . . . . . . . . . 4		4.1. Advertisement message . . . . . . . . . . . . . . . . . . 4
	4.2. Placement of Status codes . . . . . . . . . . . . . . . . 5		4.2. Placement of Status codes . . . . . . . . . . . . . . . . 5
	4.3. T1/T2 timers . . . . . . . . . . . . . . . . . . . . . . . 6		4.3. T1/T2 timers . . . . . . . . . . . . . . . . . . . . . . 5
	4.4. Renew and Rebind messages . . . . . . . . . . . . . . . . 6		4.4. Renew and Rebind messages . . . . . . . . . . . . . . . . 6
	4.5. Confirm message . . . . . . . . . . . . . . . . . . . . . 8		4.5. Confirm message . . . . . . . . . . . . . . . . . . . . . 7
	4.6. Release messages . . . . . . . . . . . . . . . . . . . . . 9		4.6. Release messages . . . . . . . . . . . . . . . . . . . . 8
	4.7. Multiple provisioning domains . . . . . . . . . . . . . . 9		4.7. Multiple provisioning domains . . . . . . . . . . . . . . 9
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 9		6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
	7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9		7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9		8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
	8.1. Normative References . . . . . . . . . . . . . . . . . . . 9		8.1. Normative References . . . . . . . . . . . . . . . . . . 9
	8.2. Informative References . . . . . . . . . . . . . . . . . . 10		8.2. Informative References . . . . . . . . . . . . . . . . . 9
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
	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 4, line 43		skipping to change at page 4, line 20
	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 (NoAddrsAvail, NotOnlink,		In Reply messages IA specific status codes (i.e., NoAddrsAvail,
	NoBinding) are encapsulated in the IA option. In Advertisement		NotOnlink, NoBinding, NoPrefixAvail) are encapsulated in the IA
	messages the Status Code option with the NoAddrsAvail code is in the		option. In Advertisement messages the Status Code option with the
	"global" scope. That makes sense when the failure case is fatal.		NoAddrsAvail code is in the "global" scope. That makes sense when
	With the introduction of multiple IA option types, there might be a		the failure case is fatal. With the introduction of multiple IA
	case where a server is not willing to offer addresses, but might be		option types, there might be a case where a server is not willing to
	willing to offer other stateful option types.		offer addresses, but might be willing to offer other stateful option
			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
	skipping to change at page 6, line 46		skipping to change at page 6, line 25
	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.
	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		4.5. 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 lets a server without a binding to 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.
	Note: Confirm has a specific meaning and does not overload Renew/		Note: Confirm has a specific meaning and does not overload Renew/
	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
	skipping to change at page 9, line 9		skipping to change at page 8, line 43
	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.6. Release messages
	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.7. 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
	skipping to change at page 10, line 12		skipping to change at page 10, line 4
	Host Configuration Protocol (DHCP) version 6", RFC 3633,		Host Configuration Protocol (DHCP) version 6", RFC 3633,
	December 2003.		December 2003.
	8.2. Informative References		8.2. Informative References
	[RFC6204] Singh, H., Beebee, W., Donley, C., Stark, B., and O.		[RFC6204] Singh, H., Beebee, W., Donley, C., Stark, B., and O.
	Troan, "Basic Requirements for IPv6 Customer Edge		Troan, "Basic Requirements for IPv6 Customer Edge
	Routers", RFC 6204, April 2011.		Routers", RFC 6204, April 2011.
	Authors' Addresses		Authors' Addresses
	Ole Troan		Ole Troan
	Cisco Systems, Inc.		Cisco Systems, Inc.
	Philip Pedersens vei 20		Philip Pedersens vei 20
	N-1324 Lysaker,		N-1324 Lysaker
	Norway		Norway
	Email: ot@cisco.com		Email: ot@cisco.com
	Bernie Volz		Bernie Volz
	Cisco Systems, Inc.		Cisco Systems, Inc.
	1414 Massachusetts Ave		1414 Massachusetts Ave
	Boxborough, MA 01719,		Boxborough, MA 01719
	USA		USA
	Email: volz@cisco.com		Email: volz@cisco.com
End of changes. 23 change blocks.
	81 lines changed or deleted		81 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/