draft-ietf-dhc-stateless-dhcpv6-renumbering-00.txt		draft-ietf-dhc-stateless-dhcpv6-renumbering-01.txt
	Dynamic Host Congiguration T. Chown		Dynamic Host Congiguration T. Chown
	Internet-Draft University of Southampton		Internet-Draft University of Southampton
	Expires: September 6, 2004 S. Venaas		Expires: August 30, 2004 S. Venaas
	UNINETT		UNINETT
	A. Vijayabhaskar		A. Vijayabhaskar
	Hewlett-Packard STSD-I		Hewlett-Packard STSD-I
	March 8, 2004		March 2004
	Renumbering Requirements for Stateless DHCPv6		Renumbering Requirements for Stateless DHCPv6
	draft-ietf-dhc-stateless-dhcpv6-renumbering-00		draft-ietf-dhc-stateless-dhcpv6-renumbering-01
	Status of this Memo		Status of this Memo
	This document is an Internet-Draft and is in full conformance with		By submitting this Internet-Draft, I certify that any applicable
	all provisions of Section 10 of RFC2026.		patent or other IPR claims of which I am aware have been disclosed,
			and any of which I become aware will be disclosed, in accordance with
			RFC 3668.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that other		Task Force (IETF), its areas, and its working groups. Note that
	groups may also distribute working documents as Internet-Drafts.		other groups may also distribute working documents as
			Internet-Drafts.
	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."
	The list of current Internet-Drafts can be accessed at http://		The list of current Internet-Drafts can be accessed at
	www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on September 6, 2004.		This Internet-Draft will expire on August 30, 2004.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2004). All Rights Reserved.		Copyright (C) The Internet Society (2004). All Rights Reserved.
	Abstract		Abstract
	IPv6 hosts using Stateless Address Autoconfiguration are able to		IPv6 hosts using Stateless Address Autoconfiguration are able to
	automatically configure their IPv6 address and default router		automatically configure their IPv6 address and default router
	settings. However, further settings are not available. If such		settings. However, further settings are not available. If such
	hosts wish to automatically configure their DNS, NTP or other		hosts wish to automatically configure their DNS, NTP or other
	specific settings the stateless variant of the Dynamic Host		specific settings the stateless variant of the Dynamic Host
	Configuration Protocol for IPv6 (DHCPv6) could be used. This		Configuration Protocol for IPv6 (DHCPv6) could be used. This
	combination of Stateless Address Autoconfiguration and stateless		combination of Stateless Address Autoconfiguration and stateless
	DHCPv6 could be used quite commonly in IPv6 networks. However,		DHCPv6 could be used quite commonly in IPv6 networks. However, hosts
	hosts using such a combination currently have no means by which to be		using such a combination currently have no means by which to be
	informed of changes in stateless DHCPv6 option settings, e.g. the		informed of changes in stateless DHCPv6 option settings, e.g. the
	addition of a new NTP server address, changes in DNS search paths, or		addition of a new NTP server address, changes in DNS search paths, or
	full site renumbering. This document is presented as a problem		full site renumbering. This document is presented as a problem
	statement from which a solution should be proposed in a subsequent		statement from which a solution should be proposed in a subsequent
	document.		document.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3		2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3
	3. Renumbering Scenarios . . . . . . . . . . . . . . . . . . . . 4		3. Renumbering Scenarios . . . . . . . . . . . . . . . . . . . . 4
	3.1 Site renumbering . . . . . . . . . . . . . . . . . . . . . . . 4		3.1 Site renumbering . . . . . . . . . . . . . . . . . . . . . 4
	3.2 Changes to a DHCPv6-assigned setting . . . . . . . . . . . . . 4		3.2 Changes to a DHCPv6-assigned setting . . . . . . . . . . . 4
	4. Renumbering Requirements . . . . . . . . . . . . . . . . . . . 4		4. Renumbering Requirements . . . . . . . . . . . . . . . . . . . 4
	5. Solution Space . . . . . . . . . . . . . . . . . . . . . . . . 5		5. Considerations in choosing a solution . . . . . . . . . . . . 5
	6. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 5		6. Solution Space . . . . . . . . . . . . . . . . . . . . . . . . 5
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 5		7. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
	Normative References . . . . . . . . . . . . . . . . . . . . . 6		8. Security Considerations . . . . . . . . . . . . . . . . . . . 6
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 6		9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6
	Intellectual Property and Copyright Statements . . . . . . . . 7		10. Normative References . . . . . . . . . . . . . . . . . . . . 6
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 7
			Intellectual Property and Copyright Statements . . . . . . . . 8
	1. Introduction		1. Introduction
	IPv6 hosts using Stateless Address Autoconfiguration [1] are able to		IPv6 hosts using Stateless Address Autoconfiguration [1] are able to
	automatically configure their IPv6 address and default router		automatically configure their IPv6 address and default router
	settings. While Stateless Address Autoconfiguration for IPv6 allows		settings. While Stateless Address Autoconfiguration for IPv6 allows
	automatic configuration of these settings, it does not provide a		automatic configuration of these settings, it does not provide a
	mechanism for additional, non IP-address settings to be automatically		mechanism for additional, non IP-address settings to be automatically
	configured.		configured.
	skipping to change at page 3, line 33		skipping to change at page 3, line 33
	stateless variant [3] of DHCPv6 could be used. The stateless variant		stateless variant [3] of DHCPv6 could be used. The stateless variant
	of DHCPv6 is more lightweight. It does not do address assignment,		of DHCPv6 is more lightweight. It does not do address assignment,
	instead it only provides additional configuration parameters like DNS		instead it only provides additional configuration parameters like DNS
	resolver addresses. It does not maintain state about the information		resolver addresses. It does not maintain state about the information
	assigned to clients; the additional parameters do not have an		assigned to clients; the additional parameters do not have an
	explicit life-time associated with them in the same way that IP		explicit life-time associated with them in the same way that IP
	addresses do, and hence the DHCPv6 server does not need to maintain		addresses do, and hence the DHCPv6 server does not need to maintain
	the state of the clients.		the state of the clients.
	This combination of Stateless Address Autoconfiguration and stateless		This combination of Stateless Address Autoconfiguration and stateless
	DHCPv6 could be used quite commonly in IPv6 networks. In the		DHCPv6 could be used quite commonly in IPv6 networks. In the absence
	absence of an alternative method for DNS, NTP and other options to be		of an alternative method for DNS, NTP and other options to be
	automatically configured, it may become the most common combination		automatically configured, it may become the most common combination
	for statelessly configuring hosts.		for statelessly configuring hosts.
	2. Problem Statement		2. Problem Statement
	A problem however lies in the ability, or lack of ability, of clients		A problem however lies in the ability, or lack of ability, of clients
	using this combination to be informed of (or to deduce) changes in		using this combination to be informed of (or to deduce) changes in
	DHCPv6 assigned settings.		DHCPv6 assigned settings.
	While a DHCPv6 server unicasts Reconfigure message to individual		While a DHCPv6 server unicasts Reconfigure message to individual
	skipping to change at page 4, line 38		skipping to change at page 4, line 38
	address space. There is currently no provider independent (PI)		address space. There is currently no provider independent (PI)
	address space in IPv6. A site wishing to change ISP must thus		address space in IPv6. A site wishing to change ISP must thus
	renumber its network. Any such site renumbering will require hosts		renumber its network. Any such site renumbering will require hosts
	to reconfigure both their own address and default router settings as		to reconfigure both their own address and default router settings as
	well as their stateless DHCPv6-assigned settings.		well as their stateless DHCPv6-assigned settings.
	3.2 Changes to a DHCPv6-assigned setting		3.2 Changes to a DHCPv6-assigned setting
	An administrator may need to change one or more stateless		An administrator may need to change one or more stateless
	DHCPv6-assigned settings, e.g. an NTP server, DNS server, or the DNS		DHCPv6-assigned settings, e.g. an NTP server, DNS server, or the DNS
	search path. This may be required if a new, additional DNS server		search path. This may be required if a new, additional DNS server is
	is brought online, is moved to a new network (prefix), or an existing		brought online, is moved to a new network (prefix), or an existing
	server is decommissioned or known to be unavailable.		server is decommissioned or known to be unavailable.
	4. Renumbering Requirements		4. Renumbering Requirements
	Ideally, any of the above scenarios should be handled automatically		Ideally, any of the above scenarios should be handled automatically
	by the hosts on the network. For this to be realised, a method is		by the hosts on the network. For this to be realised, a method is
	required for the hosts to be informed that they should request new		required for the hosts to be informed that they should request new
	stateless DHCPv6-assigned setting information.		stateless DHCPv6-assigned setting information.
	The solution to the problem may depend on whether the renumbering or		The solution to the problem may depend on whether the renumbering or
	configuration change is a planned or unplanned one, from the		configuration change is a planned or unplanned one, from the
	perspective of the network administrator. There is already work		perspective of the network administrator. There is already work
	underway in understanding the planned renumbering [4] scenario for		underway in understanding the planned renumbering [4] scenario for
	IPv6 networks. However, there is currently no mechanism in		IPv6 networks. However, there is currently no mechanism in stateless
	stateless DHCPv6 to even handle planned renumbering events.		DHCPv6 to even handle planned renumbering events.
	The unplanned renumbering event, which may be more common in smaller,		The unplanned renumbering event, which may be more common in smaller,
	unmanaged networks, is more difficult to cater for. Ideally, any		unmanaged networks, is more difficult to cater for. Ideally, any
	solution for the problem should consider planned and unplanned		solution for the problem should consider planned and unplanned
	events.		events.
	The solution should also be secure, such that additional security		The solution should also be secure, such that additional security
	concerns are not added to the stateless DHCPv6 networking		concerns are not added to the stateless DHCPv6 networking
	environment.		environment.
	5. Solution Space		5. Considerations in choosing a solution
			There are a number of considerations that could be listed for a
			desirable solution:
			o It should support planned renumbering; it is desirable to support
			unplanned renumbering.
			o Security is important; e.g., avoiding denialof service attacks
			mounted through Reconfigure messages sent from an attacker.
			o It must be possible to update options even if the network is not
			renumbered.
			o It is desirable to maintain the "stateless" property; i.e., no
			per-client state should need to be kept in the server.
			6. Solution Space
	Solutions should be designed and presented in a separate document.		Solutions should be designed and presented in a separate document.
	An initial, brief set of candidate solutions might include:		An initial, brief set of candidate solutions might include:
	o Adding a Reconfigure message mechanism that would work in the		o Adding a Reconfigure message mechanism that would work in the
	stateless DHCPv6 environment. This could enable planned or		stateless DHCPv6 environment. This could enable planned or
	unplanned events, but may require a multicast mechanism to be		unplanned events, but may require a multicast mechanism to be
	realised.		realised.
	o Conveying a valid lifetime timer to clients for stateless		o Conveying a valid lifetime timer to clients for stateless
	DHCPv6-assigned settings. This could primarily enable planned		DHCPv6-assigned settings. This could primarily enable planned
	events, but with a small time-out it could to some extent handle		events, but with a small time-out it could to some extent handle
	unplanned events at the expense of the additional request traffic.		unplanned events at the expense of the additional request traffic.
	o Using some form of Router Advertisement as a hint to request new		o Using some form of Router Advertisement as a hint to request new
	stateless DHCPv6-assigned settings. Using only an observed new		stateless DHCPv6-assigned settings. Using only an observed new
	Router Advertisement prefix as a hint to re-request settings would		Router Advertisement prefix as a hint to re-request settings would
	not handle changes that are purely to NTP, DNS or other options.		not handle changes that are purely to NTP, DNS or other options.
			Other possible means of detection of network (re)attachment could
			also be used as cues (e.g. see IPv6 DNA Goals [5]).
	6. Summary		o Changing semantics of the DHCPv6 'O' flag such that toggling its
			value may trigger an Information-request message.
			7. Summary
	This document presents a problem statement for how IPv6 hosts that		This document presents a problem statement for how IPv6 hosts that
	use the combination of Stateless Address Autoconfiguration and		use the combination of Stateless Address Autoconfiguration and
	stateless DHCPv6 may be informed of renumbering events or other		stateless DHCPv6 may be informed of renumbering events or other
	changes to the settings that they originally learnt through stateless		changes to the settings that they originally learnt through stateless
	DHCPv6. A short list of candidate solutions is presented, which the		DHCPv6. A short list of candidate solutions is presented, which the
	authors hope may be expanded upon in subsequent documents.		authors hope may be expanded upon in subsequent documents.
	7. Security Considerations		8. Security Considerations
	There are no security considerations in this problem statemement per		There are no security considerations in this problem statemement per
	se. However, whatever mechanism is designed or chosen to address this		se. However, whatever mechanism is designed or chosen to address
	problem should avoid the introduction of new security concerns for		this problem should avoid the introduction of new security concerns
	(stateless) DHCPv6.		for (stateless) DHCPv6.
	Normative References		9. Acknowledgements
			The authors would like to thank Ralph Droms and Bermie Volz for their
			comments on this draft.
			10 Normative References
	[1] Thomson, S. and T. Narten, "IPv6 Stateless Address		[1] Thomson, S. and T. Narten, "IPv6 Stateless Address
	Autoconfiguration", RFC 2462, December 1998.		Autoconfiguration", RFC 2462, December 1998.
	[2] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and M.		[2] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and M.
	Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)",		Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)",
	RFC 3315, July 2003.		RFC 3315, July 2003.
	[3] Droms, R., "A Guide to Implementing Stateless DHCPv6 Service",		[3] Droms, R., "Stateless Dynamic Host Configuration Protocol (DHCP)
	draft-ietf-dhc-dhcpv6-stateless-01 (work in progress), October		Service for IPv6", RFC 3736, April 2004.
	2003.
	[4] Baker, F., "Procedures for Renumbering an IPv6 Network without a		[4] Baker, F., Lear, E. and R. Droms, "Procedures for Renumbering an
	Flag Day", draft-baker-ipv6-renumber-procedure-01 (work in		IPv6 Network without a Flag Day",
	progress), October 2003.		draft-baker-ipv6-renumber-procedure-01 (work in progress),
			October 2003.
			[5] Choi, J., "Detecting Network Attachment in IPv6 Goals",
			draft-ietf-dna-goals-00 (work in progress), June 2004.
	Authors' Addresses		Authors' Addresses
	Tim Chown		Tim Chown
	University of Southampton		University of Southampton
	School of Electronics and Computer Science		School of Electronics and Computer Science
	Southampton, Hampshire SO17 1BJ		Southampton, Hampshire SO17 1BJ
	United Kingdom		United Kingdom
	EMail: tjc@ecs.soton.ac.uk		EMail: tjc@ecs.soton.ac.uk
	skipping to change at page 7, line 8		skipping to change at page 8, line 8
	Hewlett-Packard STSD-I		Hewlett-Packard STSD-I
	29, Cunningham Road		29, Cunningham Road
	Bangalore 560052		Bangalore 560052
	India		India
	EMail: vijayak@india.hp.com		EMail: vijayak@india.hp.com
	Intellectual Property Statement		Intellectual Property Statement
	The IETF takes no position regarding the validity or scope of any		The IETF takes no position regarding the validity or scope of any
	intellectual property or other rights that might be claimed to		Intellectual Property Rights or other rights that might be claimed to
	pertain to the implementation or use of the technology described in		pertain to the implementation or use of the technology described in
	this document or the extent to which any license under such rights		this document or the extent to which any license under such rights
	might or might not be available; neither does it represent that it		might or might not be available; nor does it represent that it has
	has made any effort to identify any such rights. Information on the		made any independent effort to identify any such rights. Information
	IETF's procedures with respect to rights in standards-track and		on the procedures with respect to rights in RFC documents can be
	standards-related documentation can be found in BCP-11. Copies of		found in BCP 78 and BCP 79.
	claims of rights made available for publication and any assurances of
	licenses to be made available, or the result of an attempt made to		Copies of IPR disclosures made to the IETF Secretariat and any
	obtain a general license or permission for the use of such		assurances of licenses to be made available, or the result of an
	proprietary rights by implementors or users of this specification can		attempt made to obtain a general license or permission for the use of
	be obtained from the IETF Secretariat.		such proprietary rights by implementers or users of this
			specification can be obtained from the IETF on-line IPR repository at
			http://www.ietf.org/ipr.
	The IETF invites any interested party to bring to its attention any		The IETF invites any interested party to bring to its attention any
	copyrights, patents or patent applications, or other proprietary		copyrights, patents or patent applications, or other proprietary
	rights which may cover technology that may be required to practice		rights that may cover technology that may be required to implement
	this standard. Please address the information to the IETF Executive		this standard. Please address the information to the IETF at
	Director.		ietf-ipr@ietf.org.
	Full Copyright Statement
	Copyright (C) The Internet Society (2004). All Rights Reserved.		Disclaimer of Validity
	This document and translations of it may be copied and furnished to		This document and the information contained herein are provided on an
	others, and derivative works that comment on or otherwise explain it		"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
	or assist in its implementation may be prepared, copied, published		OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
	and distributed, in whole or in part, without restriction of any		ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
	kind, provided that the above copyright notice and this paragraph are		INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
	included on all such copies and derivative works. However, this		INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
	document itself may not be modified in any way, such as by removing		WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
	the copyright notice or references to the Internet Society or other
	Internet organizations, except as needed for the purpose of
	developing Internet standards in which case the procedures for
	copyrights defined in the Internet Standards process must be
	followed, or as required to translate it into languages other than
	English.
	The limited permissions granted above are perpetual and will not be		Copyright Statement
	revoked by the Internet Society or its successors or assignees.
	This document and the information contained herein is provided on an		Copyright (C) The Internet Society (2004). This document is subject
	"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING		to the rights, licenses and restrictions contained in BCP 78, and
	TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING		except as set forth therein, the authors retain all their rights.
	BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
	HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
	MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
	Acknowledgment		Acknowledgment
	Funding for the RFC Editor function is currently provided by the		Funding for the RFC Editor function is currently provided by the
	Internet Society.		Internet Society.
End of changes.
This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/