< draft-droms-nemo-dhcpv6-pd-00.txt		draft-droms-nemo-dhcpv6-pd-01.txt >
	Network Working Group R. Droms		IPv6 Group R. Droms
	Internet-Draft Cisco		Internet-Draft P. Thubert
	Expires: December 22, 2003 June 23, 2003		Expires: August 6, 2004 Cisco
			February 6, 2004
	DHCPv6 Prefix Delegation for NEMO		DHCPv6 Prefix Delegation for NEMO
	draft-droms-nemo-dhcpv6-pd-00.txt		draft-droms-nemo-dhcpv6-pd-01.txt
	Status of this Memo		Status of this Memo
	This document is an Internet-Draft and is in full conformance with		This document is an Internet-Draft and is in full conformance with
	all provisions of Section 10 of RFC2026.		all provisions of Section 10 of RFC2026.
	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		Task Force (IETF), its areas, and its working groups. Note that other
	other groups may also distribute working documents as Internet-		groups may also distribute working documents as Internet-Drafts.
	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		The list of current Internet-Drafts can be accessed at http://
	http://www.ietf.org/ietf/1id-abstracts.txt.		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 December 22, 2003.		This Internet-Draft will expire on August 6, 2004.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2003). All Rights Reserved.		Copyright (C) The Internet Society (2004). All Rights Reserved.
	Abstract		Abstract
	One aspect of network mobility support is the assignment of a prefix		One aspect of network mobility support is the assignment of a prefix
	or prefixes to a mobile router (MR) for use on the links in the		or prefixes to a mobile router (MR) for use on the links in the
	mobile network. DHCPv6 prefix delegation can be used for this		mobile network. DHCPv6 prefix delegation can be used for this
	configuration task.		configuration task.
	1. Introduction		1. Introduction
	One aspect of network mobility support is the assignment of a prefix		One aspect of network mobility support is the assignment of a prefix
	or prefixes to a mobile router for use on the links in the mobile		or prefixes to a mobile router for use on the links in the mobile
	network. DHCPv6 prefix delegation [1] (DHCPv6PD) can be used for		network. DHCPv6 prefix delegation [4] (DHCPv6PD) can be used for
	this configuration task.		this configuration task, whether from the Home Network or locally
			from an Access Network.
	2. Terminology		2. Terminology
	The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,		The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
	SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this document are to be		SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this document are to be
	interpreted as described in RFC2119 [2].		interpreted as described in RFC2119 [1].
	The following terms used in this document are defined in the IPv6		The following terms used in this document are defined in the IPv6
	Addressing Architecture document [3]:		Addressing Architecture document [3]:
	link-local unicast address		link-local unicast address
	link-local scope multicast address		link-local scope multicast address
	The following terms used in this document are defined in the mobile		The following terms used in this document are defined in the mobile
	IPv6 specification [4]:		IPv6 specification [5]:
	home agent (HA)		home agent (HA)
	home link		home link
	The following terms used in this document are defined in the mobile		The following terms used in this document are defined in the mobile
	network terminology document [5]:		network terminology document [8]:
	mobile router (MR)		mobile router (MR)
	mobile network		mobile network
			mobile host (MH)
	The following terms used in this document are defined in the DHCPv6		The following terms used in this document are defined in the DHCPv6
	[6] and DHCPv6 prefix delegation [1] specifications:		[2] and DHCPv6 prefix delegation [4] specifications:
	delegating router (DR)		delegating router (DR)
	requesting router (RR)		requesting router (RR)
	DHCPv6 relay agent		DHCPv6 relay agent
	3. Application of DHCPv6 prefix delegation to mobile networks		3. Application of DHCPv6 prefix delegation to mobile networks
	The network mobility requirements document [7] defines a solution for		The network mobility requirements document [7] defines a solution for
	mobile IPv6 networks based on the mobile IPv6 protocol [4]. In this		mobile IPv6 networks based on the mobile IPv6 protocol [5]. In this
	solution, a MR uses the mobile IPv6 protocol to establish a maintain		solution, a MR uses the mobile IPv6 protocol to establish a maintain
	a session with its HA, and uses bidirectional tunneling between the		a session with its HA, and uses bidirectional tunneling between the
	MR and HA to provide a path through which hosts attached to links in		MR and HA to provide a path through which hosts attached to links in
	the mobile network can maintain connectivity with nodes not in the		the mobile network can maintain connectivity with nodes not in the
	mobile network.		mobile network.
	The requirements for basic network mobility support [8] include the		The requirements in basic network mobility support [7] include the
	ability of the MR to receive delegated prefixes that can then be		ability of the MR to receive delegated prefixes that can then be
	assigned to links in the mobile network. DHCPv6PD can be used to		assigned to links in the mobile network. DHCPv6PD can be used to
	meet this requirement for prefix delegation.		meet this requirement for prefix delegation.
			3.1 Delegating Home prefixes
	To use DHCPv6PD for mobile networks, the HA assumes the role of the		To use DHCPv6PD for mobile networks, the HA assumes the role of the
	DR and the MR assumes the role of the RR. Throughout the remainder		DR and the MR assumes the role of the RR. Throughout the remainder of
	of this document, the HA will be assumed to be acting as a DHCPv6PD		this document, the HA will be assumed to be acting as a DHCPv6PD DR
	DR and the MR will be assumed to be acting as a RR.		and the MR will be assumed to be acting as a RR.
	The HA and MR exchange DHCPv6PD protocol messages through the tunnel		The HA and MR exchange DHCPv6PD protocol messages through the tunnel
	connecting them. The tunnel acts as the link labeled "DSL to		connecting them. The tunnel acts as the link labeled "DSL to
	subscriber premises" in figure 1 of the DHCPv6PD specification.		subscriber premises" in figure 1 of the DHCPv6PD specification.
	The HA (acting as the DR) is provisioned with prefixes to be assigned		The HA (acting as the DR) is provisioned with prefixes to be assigned
	using any of the prefix assignment mechanisms described in the		using any of the prefix assignment mechanisms described in the
	DHCPv6PD specifications. Other updates to the HA data structures		DHCPv6PD specifications. Other updates to the HA data structures
	required as a side effect of prefix delegation are specified by the		required as a side effect of prefix delegation are specified by the
	particular network mobility protocol. For example, in the case of		particular network mobility protocol. For example, in the case of
	"Basic Network Mobility Support" [8], the HA would add an entry in		Basic Network Mobility Support [6], the HA would add an entry in its
	its binding cache registering the delegated prefix to the MR to which		binding cache registering the delegated prefix to the MR to which the
	the prefix was delegated.		prefix was delegated.
	3.1 Use of HA-MR tunnel for DHCPv6 messages		3.1.1 Use of HA-MR tunnel for DHCPv6 messages
	The DHCPv6 specification requires the use of link-local unicast and		The DHCPv6 specification requires the use of link-local unicast and
	link-local scope multicast addresses in DHCPv6 messages (except in		link-local scope multicast addresses in DHCPv6 messages (except in
	certain cases as defined in section 22.12 of the DHCPv6		certain cases as defined in section 22.12 of the DHCPv6
	specification). Section 10.4.2 of the mobile IPv6 specification		specification). Section 10.4.2 of the mobile IPv6 specification
	describes forwarding of intercepted packets, and the third paragraph		describes forwarding of intercepted packets, and the third paragraph
	of that section begins:		of that section begins:
	However, packets addressed to the mobile node's link-local address		However, packets addressed to the mobile node's link-local address
	MUST NOT be tunneled to the mobile node.		MUST NOT be tunneled to the mobile node.
	The DHCPv6 messages exchanged between the HA and the MR originate		The DHCPv6 messages exchanged between the HA and the MR originate
	only with the HA and the MR, and therefore are not "intercepted		only with the HA and the MR, and therefore are not "intercepted
	packets" and are may be forwarded between the HA and the MR through		packets" and may be sent between the HA and the MR through the
	the tunnel.		tunnel.
	3.2 Exchanging DHCPv6 messages when HA and MR are on the same link		3.1.2 Exchanging DHCPv6 messages when HA and MR are on the same link
	When the MR is on its home link, the HA uses the home link to		When the MR is on its home link, the HA uses the home link to
	exchange DHCPv6PD messages with the MR, even if there is a tunnel		exchange DHCPv6PD messages with the MR, even if there is a tunnel
	across the home link between the MR and the HA. It is the		across the home link between the MR and the HA. It is the
	responsibility of the implementation to determine when the MR is on		responsibility of the implementation to determine when the MR is on
	its home link and to avoid use of any existing tunnel.		its home link and to avoid use of any existing tunnel.
	3.3 Location of DHCPv6PD Delegating Router function		3.1.3 Location of DHCPv6PD Delegating Router function
	The DHCPv6PD DR function MUST be implemented in the HA for the MR.		The DHCPv6PD DR function MUST be implemented in the HA for the MR.
	The use of a DHCPv6 relay agent is not defined for DHCPv6PD.		The use of a DHCPv6 relay agent is not defined for DHCPv6PD.
	3.4 Use of DHCPv6 for other configuration information		3.1.4 Other DHCPv6 functions
	The DHCPv6 messages exchanged between the MR and the HA may also be		The DHCPv6 messages exchanged between the MR and the HA may also be
	used for other DHCPv6 functions in addition to DHCPv6PD. For		used for other DHCPv6 functions in addition to DHCPv6PD. For
	example, the HA may assign global addresses to the MR and may pass		example, the HA may assign global addresses to the MR and may pass
	other configuration information such as a list of available DNS		other configuration information such as a list of available DNS
	recursive resolvers to the MR using the same DHCPv6 messages as used		recursive resolvers to the MR using the same DHCPv6 messages as used
	for DHCPV6PD.		for DHCPV6PD.
			The HA may act as a DHCPv6 relay agent for MHs while it acts as a DR
			for MRs.
			3.2 Delegating Access Prefixes
			A Mobile Router may also obtain a temporary delegated prefix from its
			Access Router (acting as a DHCPv6PD DR) while the MR is roaming
			within the AR space.
			This is used for instance if the MR opens a network for anonymous
			visitors to roam in. In that model, the delegated network is
			advertised in the clear, as opposed to the MR's own Mobile Network
			Prefixes, which can stay private, over secured media.
			As a result, the CareOf Addresses of the visitors in a nested
			structure are all aggregated by a larger prefix owned, subdelegated,
			and advertised to the infrastructure by the Access Router itself.
			It is possible to protect the privacy of both parties between a VMN
			that implements RFC 3041 [13] and a visited MR that advertises only
			the delegated prefixes in the clear.
			In the case of a nested structure, it is expected that the AR and the
			MR maintain a tunnel and that the connectivity between the two is
			maintained somehow; this can be achieved by:
			Performing a routing protocol such as a MANET within the nested
			topology.
			performing some L3 bridging technique between AR and MRs.
			placing a Nemo Home Agent at the AR so that the MR registers the
			mobility of the delegated prefix while it is roaming inside or
			outside the nested structure below the AR.
			It may be beneficial for the Mobile Router to use its address within
			its delegated prefix as CareOf to register to its Home Agent. As a
			result, the MR gets some advantages similar to those obtained with
			HMIP.
			In particular, if the Access Router is a Home Agent for the
			aggregation of delegated prefixes, and if that Home Agent supports
			the Reverse Routing Header (see [9]), then there are only 2 tunnels,
			the MRAR encapsulating the MRHA tunnel whatever the nested depth of
			the MR.
			3.2.1 New Tree Information Option Format
			This draft modifies the Tree Information option, as described in [9],
			adding a new bit to indicate that the TLMR supports DHCP-PD.
			The new bit are set by the TLMR are propagated transparently by the
			MRs. Mobile Routers SHOULD add that option to the Router
			Advertisement messages sent over the ingress interfaces.
			The Tree Information option has the following format:
			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
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Type | Length = 6 | TreePreference| TreeDepth |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			|G|H|D|Reserved | Bandwidth | DelayTime |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| MRPreference | BootTimeRandom |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| PathCRC |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| |
			+ +
			| |
			+ Tree TLMR Identifier +
			| |
			+ +
			| |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| |
			+ +
			| |
			+ Tree Group +
			| |
			+ +
			| |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			Type
			8-bit unsigned integer set to 10 by the TLMR.
			Length
			8-bit unsigned integer set to 6 by the TLMR. The length of the
			option (including the type and length fields) in units of 8
			octets.
			TreePreference
			8-bit unsigned integer set by the TLMR to its configured
			preference. Range from 0 = lowest to 255 = highest.
			TreeDepth
			8-bit unsigned integer set to 0 by the TLMR and incremented by 1
			by each MR down the tree.
			Grounded (G)
			1-bit flag. Set by the TLMR to indicate that it is either attached
			to a fixed network or at home.
			Home Agent (H)
			1-bit flag. Set by the TLMR to indicate that it is also
			functioning as a Home Agent, for re-homing purposes.
			Home (D)
			1-bit flag. Set by the TLMR to indicate that it is also
			functioning as a DHCPv6PD-DR.
			Reserved
			6-bit unsigned integer, set to 0 by the TLMR.
			Bandwidth
			8-bit unsigned integer set by the TLMR and decremented by MRs with
			lower egress bandwidth. This is a power of 2 so that the available
			egress bandwidth in bps is between 2^Bandwidth and
			2^(Bandwidth+1). 0 means 'unspecified' and can not be modified
			down the tree.
			DelayTime
			16-bit unsigned integer set by the TLMR. Tree time constant in
			milliseconds.
			MRPreference
			8-bit signed integer. Set by each MR to its configured preference.
			Range from 0 = lowest to 255 = highest.
			BootTimeRandom
			24-bit unsigned integer set by each MR to a random value that the
			MR generates at boot time.
			PathCRC
			32-bit unsigned integer CRC, updated by each MR. This is the
			result of a CRC-32c computation on a bit string obtained by
			appending the received value and the MR CareOf Address. TLMRs use
			a 'previous value' of zeroes to initially set the pathCRC.
			Tree TLMR Identifier
			IPv6 global address, set by the TLMR. Identifier of the tree.
			Tree Group
			IPv6 global address, set by the TLMR. Identifier of the tree
			group. A MR may use the Tree Group in its tree selection
			algorithm.
			The AR MUST include this option in its Router Advertisements, placing
			itself as TLMR.
			A MR receiving this option from its Attachment Router MUST update the
			TreeDepth, MRPreference, BootTimeRandom and PathCRC fields, and MUST
			propagate it on its ingress interface(s), as described in [9].
			The alignment requirement of the Tree Information option is 8n.
	4. Security Considerations		4. Security Considerations
	This document describes the use of DHCPv6 for prefix delegation in		This document describes the use of DHCPv6 for prefix delegation in
	mobile networks. It does not introduce any additional security		mobile networks. It does not introduce any additional security
	considerations beyond those described in the "Security		considerations beyond those described in the "Security
	Considerations" section of the DHCPv6 base specification [6] and the		Considerations" section of the DHCPv6 base specification [2] and the
	"Security Considerations" of the DHCPv6 Prefix Delegation		"Security Considerations" of the DHCPv6 Prefix Delegation
	specification [1].		specification [4].
	Following the DHCPv6 Prefix Delegation specification, HAs and MRs		Following the DHCPv6 Prefix Delegation specification, HAs and MRs
	SHOULD use DHCPv6 authentication as described in section		SHOULD use DHCPv6 authentication as described in section
	"Authentication of DHCP messages" of the DHCPv6 specification [6], to		"Authentication of DHCP messages" of the DHCPv6 specification [2], to
	guard against attacks mounted through prefix delegation.		guard against attacks mounted through prefix delegation.
	5. IANA Considerations		5. IANA Considerations
	This document describes the use of DHCPv6 for prefix delegation in		This document describes the use of DHCPv6 for prefix delegation in
	mobile networks. It does not introduce any additional IANA		mobile networks. It does not introduce any additional IANA
	considerations.		considerations.
			6. Terms of Use
			Cisco has a pending patent which relates to the subject matter of
			this Internet Draft. If a standard relating to this subject matter is
			adopted by IETF and any claims of any issued Cisco patents are
			necessary for practicing this standard, any party will be able to
			obtain a license from Cisco to use any such patent claims under
			openly specified, reasonable, non-discriminatory terms to implement
			and fully comply with the standard.
	Normative References		Normative References
	[1] Troan, O. and R. Droms, "IPv6 Prefix Options for DHCPv6", draft-		[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
	ietf-dhc-dhcpv6-opt-prefix-delegation-04 (work in progress),		Levels", BCP 14, RFC 2119, March 1997.
	June 2003.
	[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement		[2] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and M.
	Levels", BCP 14, RFC 2119, March 1997.		Carney, "Dynamic Host Configuration Protocol for IPv6
			(DHCPv6)", RFC 3315, July 2003.
	[3] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6)		[3] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6)
	Addressing Architecture", RFC 2460, December 1998.		Addressing Architecture", RFC 3513, April 2003.
	[4] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in		[4] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host
	IPv6", draft-ietf-mobileip-ipv6-23 (work in progress), May 2003.		Configuration Protocol (DHCP) version 6", RFC 3633, December
			2003.
	[5] Ernst, T., "Network Mobility Support Terminology", draft-ietf-		[5] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in
	nemo-terminology-00 (work in progress), May 2003.		IPv6", draft-ietf-mobileip-ipv6-24 (work in progress), July
			2003.
	[6] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and M.		[6] Devarapalli, V., "Nemo Basic Support Protocol",
	Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)",		draft-ietf-nemo-basic-support-02 (work in progress), December
	draft-ietf-dhc-dhcpv6-28 (work in progress), November 2002.		2003.
	[7] Ernst, T., "Network Mobility Support Goals and Requirements",		[7] Ernst, T., "Network Mobility Support Goals and Requirements",
	draft-ietf-nemo-requirements-01 (work in progress), May 2003.		draft-ietf-nemo-requirements-01 (work in progress), May 2003.
	[8] Wakikawa, R., Mitsuya, K., Uehara, K. and T. Ernst, "Basic		[8] Ernst, T. and H. Lach, "Network Mobility Support Terminology",
	Network Mobility Support", draft-wakikawa-nemo-basic-00 (work in		draft-ietf-nemo-terminology-00 (work in progress), May 2003.
	progress), February 2003.
	Author's Address		[9] Thubert, P. and M. Molteni, "IPv6 Reverse Routing Header and
			its application to Mobile Networks",
			draft-thubert-nemo-reverse-routing-header-02 (work in
			progress), June 2003.
			[10] Soliman, H., Castelluccia, C., Malki, K. and L. Bellier,
			"Hierarchical Mobile IPv6 mobility management (HMIPv6)",
			draft-ietf-mobileip-hmipv6-08 (work in progress), July 2003.
			[11] Johnson, D., "The Dynamic Source Routing Protocol for Mobile Ad
			Hoc Networks (DSR)", draft-ietf-manet-dsr-09 (work in
			progress), April 2003.
			[12] Perkins, C., Royer, E. and S. Das, "Ad Hoc On Demand Distance
			Vector (AODV) Routing", draft-ietf-manet-aodv-13 (work in
			progress), February 2003.
			[13] Narten, T. and R. Draves, "Privacy Extensions for Stateless
			Address Autoconfiguration in IPv6", RFC 3041, January 2001.
			Authors' Addresses
	Ralph Droms		Ralph Droms
	Cisco		Cisco
	1414 Massachusetts Avenue		1414 Massachusetts Avenue
	Boxborough, MA 01719		Boxborough, MA 01719
	Japan		USA
	Phone: +1 978.936.1674		Phone: +1 978.936.1674
	EMail: rdroms@cisco.com		EMail: rdroms@cisco.com
			Pascal Thubert
			Cisco
			Village d'Entreprises Green Side
			400, Avenue Roumanille
			Biot - Sophia Antipolis 06410
			FRANCE
			EMail: pthubert@cisco.com
			Appendix A. Changes since version 00
			The section on access prefix delegation was added. That section
			provides a mechanism that is very close to HMIP but purely based on
			standard DHCP-PD. It is limited to Nemo applications, but it provides
			additional features, including the privacy of the mobile access
			router.
			Intellectual Property Statement
			The IETF takes no position regarding the validity or scope of any
			intellectual property or other rights that might be claimed to
			pertain to the implementation or use of the technology described in
			this document or the extent to which any license under such rights
			might or might not be available; neither does it represent that it
			has made any effort to identify any such rights. Information on the
			IETF's procedures with respect to rights in standards-track and
			standards-related documentation can be found in BCP-11. Copies of
			claims of rights made available for publication and any assurances of
			licenses to be made available, or the result of an attempt made to
			obtain a general license or permission for the use of such
			proprietary rights by implementors or users of this specification can
			be obtained from the IETF Secretariat.
			The IETF invites any interested party to bring to its attention any
			copyrights, patents or patent applications, or other proprietary
			rights which may cover technology that may be required to practice
			this standard. Please address the information to the IETF Executive
			Director.
	Full Copyright Statement		Full Copyright Statement
	Copyright (C) The Internet Society (2003). All Rights Reserved.		Copyright (C) The Internet Society (2004). All Rights Reserved.
	This document and translations of it may be copied and furnished to		This document and translations of it may be copied and furnished to
	others, and derivative works that comment on or otherwise explain it		others, and derivative works that comment on or otherwise explain it
	or assist in its implementation may be prepared, copied, published		or assist in its implementation may be prepared, copied, published
	and distributed, in whole or in part, without restriction of any		and distributed, in whole or in part, without restriction of any
	kind, provided that the above copyright notice and this paragraph are		kind, provided that the above copyright notice and this paragraph are
	included on all such copies and derivative works. However, this		included on all such copies and derivative works. However, this
	document itself may not be modified in any way, such as by removing		document itself may not be modified in any way, such as by removing
	the copyright notice or references to the Internet Society or other		the copyright notice or references to the Internet Society or other
	Internet organizations, except as needed for the purpose of		Internet organizations, except as needed for the purpose of
	developing Internet standards in which case the procedures for		developing Internet standards in which case the procedures for
	copyrights defined in the Internet Standards process must be		copyrights defined in the Internet Standards process must be
	followed, or as required to translate it into languages other than		followed, or as required to translate it into languages other than
	English.		English.
	The limited permissions granted above are perpetual and will not be		The limited permissions granted above are perpetual and will not be
	revoked by the Internet Society or its successors or assigns.		revoked by the Internet Society or its successors or assignees.
	This document and the information contained herein is provided on an		This document and the information contained herein is provided on an
	"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING		"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
	TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING		TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
	BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION		BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
	HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF		HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
	MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.		MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
	Acknowledgement		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. 44 change blocks.
	61 lines changed or deleted		309 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/