draft-ietf-dhc-dhcpv6-stateful-issues-08.txt		draft-ietf-dhc-dhcpv6-stateful-issues-09.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 M. Siodelski		Intended status: Standards Track M. Siodelski
	Expires: April 25, 2015 ISC		Expires: May 30, 2015 ISC
	October 22, 2014		November 26, 2014
	Issues and Recommendations with Multiple Stateful DHCPv6 Options		Issues and Recommendations with Multiple Stateful DHCPv6 Options
	draft-ietf-dhc-dhcpv6-stateful-issues-08.txt		draft-ietf-dhc-dhcpv6-stateful-issues-09.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 has since shoe-horned a new option for
	Delegation into DHCPv6. Implementation experience of the CPE model		Prefix Delegation into DHCPv6. Implementation experience of the CPE
	described in RFC 7084 has shown multiple issues with the DHCPv6		model described in RFC 7084 has shown multiple issues with the DHCPv6
	protocol in supporting multiple stateful options. This document		protocol in supporting multiple stateful options. This document
	updates RFC 3315 and RFC 3633 to address the identified issues.		updates RFC 3315 and RFC 3633 to address the identified issues.
	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 April 25, 2015.		This Internet-Draft will expire on May 30, 2015.
	Copyright Notice		Copyright Notice
	Copyright (c) 2014 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
	skipping to change at page 2, line 43		skipping to change at page 2, line 43
	7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19		7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . 19		8. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
	8.1. Normative References . . . . . . . . . . . . . . . . . . 19		8.1. Normative References . . . . . . . . . . . . . . . . . . 19
	8.2. Informative References . . . . . . . . . . . . . . . . . 20		8.2. Informative References . . . . . . . . . . . . . . . . . 20
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
	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] has since shoe-horned a new option for Prefix Delegation
	DHCPv6. Implementation experience of the CPE model described in		into DHCPv6. Implementation experience of the CPE model described in
	[RFC7084] has shown issues with the DHCPv6 protocol in supporting		[RFC7084] has shown issues with the DHCPv6 protocol in supporting
	multiple stateful option types, in particular IA_NA (non-temporary		multiple stateful option types, in particular IA_NA (non-temporary
	addresses) and IA_PD (delegated prefixes).		addresses) and IA_PD (delegated prefixes).
	This document describes a number of problems encountered with		This document describes a number of problems encountered with
	coexistence of the IA_NA and IA_PD option types and changes to the		coexistence of the IA_NA and IA_PD option types and changes to the
	DHCPv6 protocol specifications to address these problems.		DHCPv6 protocol specifications to address these problems.
	The intention of this work is to clarify and, where needed, modify		The intention of this work is to clarify and, where needed, modify
	the DHCP protocol specification to support IA_NA and IA_PD option		the DHCP protocol specification to support IA_NA and IA_PD option
	skipping to change at page 13, line 29		skipping to change at page 13, line 29
	When the client receives a Reply message in response to a Renew or		When the client receives a Reply message in response to a Renew or
	Rebind message, for each IA in the original Renew or Rebind		Rebind message, for each IA in the original Renew or Rebind
	message, the client:		message, the client:
	- Sends a Request message if the server responded with the		- Sends a Request message if the server responded with the
	NoBinding status code. The client places only these IA options		NoBinding status code. The client places only these IA options
	in the Request message for which the server returned NoBinding		in the Request message for which the server returned NoBinding
	status code in the Reply message. The client continues to use		status code in the Reply message. The client continues to use
	other bindings for which the server did not return an error.		other bindings for which the server did not return an error.
	- Follows the retransmission procedure for Renew/Rebind messages		- Sends a Renew/Rebind if the IA is not in the Reply message.
	as described in section 14 if the IA is not in the Reply		However, in this case, the client MUST limit the rate at which
	message.		it sends subsequent Renew/Rebind messages and limit the duration
			of the time during which it sends the messages.
	- Otherwise accepts the information in the IA.		- Otherwise accepts the information in the IA.
	When the client receives a valid Reply message in response to a		When the client receives a valid Reply message in response to a
	Release message, the client considers the Release event completed,		Release message, the client considers the Release event completed,
	regardless of the Status Code option(s) returned by the server.		regardless of the Status Code option(s) returned by the server.
	When the client receives a valid Reply message in response to a		When the client receives a valid Reply message in response to a
	Decline message, the client considers the Decline event completed,		Decline message, the client considers the Decline event completed,
	regardless of the Status Code option(s) returned by the server.		regardless of the Status Code option(s) returned by the server.
	skipping to change at page 17, line 40		skipping to change at page 17, line 40
	Replace Section 12.2:		Replace Section 12.2:
	The delegating router behaves as follows when it cannot find a		The delegating router behaves as follows when it cannot find a
	binding for the requesting router's IA_PD:		binding for the requesting router's IA_PD:
	With:		With:
	For the Renew or Rebind, if the IA_PD contains no prefixes, i.e.		For the Renew or Rebind, if the IA_PD contains no prefixes, i.e.
	contains no IA Prefix option or the IPv6 prefix field in the IA		contains no IA Prefix option or the IPv6 prefix field in the IA
	Prefix option is set to 0, the delegating router MAY assign		Prefix option is set to 0, the delegating router SHOULD assign
	prefixes to the IA_PD according to the delegating router's		prefixes to the IA_PD according to the delegating router's
	explicit configuration information. In this case, when the server		explicit configuration information. In this case, when the server
	assigns new prefixes to the IA_PD, the server MAY use the value in		assigns new prefixes to the IA_PD, the server MAY use the value in
	the prefix-length field of the IA Prefix option as a hint for the		the prefix-length field of the IA Prefix option as a hint for the
	length of the prefixes being assigned.		length of the prefixes being assigned.
	The delegating router behaves as follows when it cannot find a		The delegating router behaves as follows when it cannot find a
	binding for the requesting router's IA_PD containing prefixes:		binding for the requesting router's IA_PD containing prefixes:
	4.5. Confirm Message		4.5. Confirm Message
	skipping to change at page 20, line 22		skipping to change at page 20, line 22
	[RFC7083] Droms, R., "Modification to Default Values of SOL_MAX_RT		[RFC7083] Droms, R., "Modification to Default Values of SOL_MAX_RT
	and INF_MAX_RT", RFC 7083, November 2013.		and INF_MAX_RT", RFC 7083, November 2013.
	8.2. Informative References		8.2. Informative References
	[I-D.dhcwg-dhc-rfc3315bis]		[I-D.dhcwg-dhc-rfc3315bis]
	Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A.,		Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A.,
	Richardson, M., Jiang, S., and T. Lemon, "Dynamic Host		Richardson, M., Jiang, S., and T. Lemon, "Dynamic Host
	Configuration Protocol for IPv6 (DHCPv6) bis", draft-		Configuration Protocol for IPv6 (DHCPv6) bis", draft-
	dhcwg-dhc-rfc3315bis-02 (work in progress), July 2014.		dhcwg-dhc-rfc3315bis-03 (work in progress), October 2014.
	[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy		[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy
	Extensions for Stateless Address Autoconfiguration in		Extensions for Stateless Address Autoconfiguration in
	IPv6", RFC 4941, September 2007.		IPv6", RFC 4941, September 2007.
	[RFC6059] Krishnan, S. and G. Daley, "Simple Procedures for		[RFC6059] Krishnan, S. and G. Daley, "Simple Procedures for
	Detecting Network Attachment in IPv6", RFC 6059, November		Detecting Network Attachment in IPv6", RFC 6059, November
	2010.		2010.
	[RFC7084] Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic		[RFC7084] Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic
End of changes. 8 change blocks.
	14 lines changed or deleted		15 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/