< draft-ietf-nemo-dhcpv6-pd-00.txt		draft-ietf-nemo-dhcpv6-pd-01.txt >
	IPv6 Group R. Droms		IPv6 Group R. Droms
	Internet-Draft P. Thubert		Internet-Draft P. Thubert
	Expires: February 5, 2006 Cisco		Expires: August 31, 2006 Cisco
	August 4, 2005		February 27, 2006
	DHCPv6 Prefix Delegation for NEMO		DHCPv6 Prefix Delegation for NEMO
	draft-ietf-nemo-dhcpv6-pd-00		draft-ietf-nemo-dhcpv6-pd-01
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that any		By submitting this Internet-Draft, each author represents that any
	applicable patent or other IPR claims of which he or she is aware		applicable patent or other IPR claims of which he or she is aware
	have been or will be disclosed, and any of which he or she becomes		have been or will be disclosed, and any of which he or she becomes
	aware will be disclosed, in accordance with Section 6 of BCP 79.		aware will be disclosed, in accordance with Section 6 of BCP 79.
	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
	skipping to change at page 1, line 34 ¶		skipping to change at page 1, line 34 ¶
	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://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 February 5, 2006.		This Internet-Draft will expire on August 31, 2006.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2005).		Copyright (C) The Internet Society (2006).
	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 [1] (DHCPv6PD) can be used for
	this configuration task, whether from the Home Network or locally		this configuration task.
	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 [2].
	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 [4]:
	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 [5]:
	mobile router (MR)		Mobile Router (MR)
	mobile network		Mobile Network
	mobile host (MH)		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:		[6] and DHCPv6 prefix delegation [1] 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 for
			delegation of home prefixes
	The network mobility requirements document [7] defines a solution for		The NEMO Basic protocol [8] extends the mobile IPv6 protocol [4] to
	mobile IPv6 networks based on the mobile IPv6 protocol [4]. In this		enable network mobility. In this extension, a MR uses the mobile
	solution, a MR uses the mobile IPv6 protocol to establish a maintain		IPv6 protocol to establish a maintain a session with its HA, and uses
	a session with its HA, and uses bidirectional tunneling between the		bidirectional tunneling between the MR and HA to provide a path
	MR and HA to provide a path through which hosts attached to links in		through which hosts attached to links in the Mobile Network can
	the mobile network can maintain connectivity with nodes not in the		maintain connectivity with nodes not in the Mobile Network.
	mobile network.
	The requirements in basic network mobility support [7] include the		The requirements for NEMO [7] include the ability of the MR to
	ability of the MR to receive delegated prefixes that can then be		receive delegated prefixes that can then be assigned to links in the
	assigned to links in the mobile network. DHCPv6PD can be used to		Mobile Network. DHCPv6PD can be used to meet this requirement for
	meet this requirement for prefix delegation.		prefix delegation.
	3.1 Delegating Home prefixes		To use DHCPv6PD for Mobile Networks, the HA assumes the role of
			either the DR or a DHCPv6 relay agent and the MR assumes the role of
			the RR. Throughout the remainder of this document, the HA will be
			assumed to be acting as a DHCPv6PD DR or relay agent and the MR will
			be assumed to be acting as a RR.
	To use DHCPv6PD for mobile networks, the HA assumes the role of the		If the HA is acts as relay agent, some other device acts as the DR.
	DR and the MR assumes the role of the RR. Throughout the remainder		For example, the server providing DHCPv6 service in the home network
	of this document, the HA will be assumed to be acting as a DHCPv6PD		might also provide NEMO DHCPv6PD service. Or, a home network with
	DR and the MR will be assumed to be acting as a RR.		several HAs might configure one of those HAs as a DHCPv6PD server
			while the other HAs act as relay agents.
	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 DHCPv6PD server is provisioned with prefixes to be assigned using
	using any of the prefix assignment mechanisms described in the		any of the prefix assignment mechanisms described in the DHCPv6PD
	DHCPv6PD specifications. Other updates to the HA data structures		specifications. Other updates to the HA data structures required as
	required as a side effect of prefix delegation are specified by the		a side effect of prefix delegation are specified by the particular
	particular network mobility protocol. For example, in the case of		network mobility protocol. For example, in the case of Basic Network
	Basic Network Mobility Support [8], the HA would add an entry in its		Mobility Support [8], the HA would add an entry in its binding cache
	binding cache registering the delegated prefix to the MR to which the		registering the delegated prefix to the MR to which the prefix was
	prefix was delegated.		delegated.
	3.1.1 Use of HA-MR tunnel for DHCPv6 messages		3.1. When the MR uses DHCPv6
			The MR initiates a DHCPv6 message exchange for prefix delegation
			whenever it establishes an MRHA tunnel to its HA. If the MR does not
			have any active delegated prefixes (with unexpired leases), the MR
			initiates a DHCPv6 message exchange with a DHCPv6 Solicit message as
			described in section 17 of RFC 3315 and section 12 of RFC 3633. If
			the MR has one or more active delegated prefixes, the MR initiates a
			DHCPv6 message exchange with a DHCPv6 Confirm message as described in
			section 18.1.2 of RFC 3315 and section 12 of RFC 3633.
			3.2. Use of MRHA 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 may be sent between the HA and the MR through the		packets" and may be sent between the HA and the MR through the
	tunnel.		tunnel.
	3.1.2 Exchanging DHCPv6 messages when HA and MR are on the same link		Even though the MRHA tunnel is a point to point connection, the MR
			SHOULD use multicast DHCPv6 messages as described in RFC 3315 over
			that tunnel.
			3.3. Exchanging DHCPv6 messages when MR is at home
	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. It is the responsibility of
	across the home link between the MR and the HA. It is the		the implementation to determine when the MR is on its home link and
	responsibility of the implementation to determine when the MR is on		to avoid use of any existing tunnel.
	its home link and to avoid use of any existing tunnel.
	3.1.3 Location of DHCPv6PD Delegating Router function		3.4. Minimizing DHCPv6PD messages
	Support of DHCPv6PD in a mobile network is optional. If DHCPv6PD is		DHCPv6PD in a Mobile Network can be combined with the Rapid Commit
	used then the DHCPv6PD DR function MUST be implemented in the HA for		option [6] to provide DHCPv6 prefix delegation with a two message
	the MR. The use of a DHCPv6 relay agent is not defined for DHCPv6PD.		exchange between the mobile node and the DHCPv6 PD server.
	3.1.4 Other DHCPv6 functions		3.5. DHCPv6PD and DHAAD
			The MR acting as RR needs a direct link to the DR (or relay)
			function. When the MR is away from Home, that link is the MRHA
			tunnel. If a MR needs to obtain a prefix by means of DHCPv6PD, it
			has to locate a HA that is capable of serving either as a DHCPv6PD
			relay agent or server. Since the use of DHCPv6PD is optional and
			comes as an addition to existing protocols [RFC 3775] and [RFC 3963],
			it can not be expected that all HAs are DHCPv6PD capable.
			This specification extends Dynamic Home Agent Address Discovery and
			the Home Agent Information Option in order to enable the detection by
			a MR of all HAs that are DHCPv6PD capable. A new 'D' bit is
			introduced to let Home Agents advertise that they are willing to
			participate to DHCP. Note that there is no need for the MR acting as
			RR to know whether a HA is actually a DR or simply acting as a relay.
			3.5.1. Modified Dynamic Home Agent Address Discovery Request
			A new flag (D) (Support for DHCPv6PD) is introduced in the DHAAD
			Request message, defined in [RFC3775] and [RFC 3963]. The Mobile
			Router sets this flag to indicate that it wants to discover Home
			Agents participating to DHCPv6 Prefix Delegation.
			A the MR which sets the 'D' flag MUST also set the 'R' flag, to
			declare that it is a Mobile Router and asks for a HA that supports
			Mobile Routers, as defined in [RFC 3963].
			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 | Code | Checksum |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Identifier |R|D| Reserved |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			DHCPv6PD Support Flag (D)
			A one-bit flag that when set indicates that the Mobile Router
			wants to discover Home Agents participating to DHCPv6 Prefix
			Delegation.
			For a description of the other fields in the message, see [RFC3775]
			and [RFC 3963].
			3.5.2. Modified Dynamic Home Agent Address Discovery Reply
			A new flag (D) (Support for DHCPv6PD) is introduced in the DHAAD
			Reply message, defined in [RFC3775] and [RFC 3963]. If a Home Agent
			receives a Dynamic Home Agent Discovery request message with the
			DHCPv6PD Support Flag set, it MUST reply with a list of Home Agents
			participating to DHCPv6PD.
			The DHCPv6PD Support Flag MUST be set if there is at least one Home
			Agent participating to DHCPv6PD. In that case, the reply will list
			only those HAs that participate to DHCPv6PD, whether they act as
			servers (DRs) or relays.
			A HA that supports DHCPv6PD MUST support Mobile Routers as well, so
			if the 'D' bit is set, then the 'R' bit should be set as well. So
			there is no need in an implementation to support the case where some
			HAs would support Mobile Routers while others would be participating
			to DHCPv6 Prefix Delegation but none could do both.
			If none of the Home Agents support DHCPv6PD, the Home Agent MAY reply
			with a list of Home Agents that only support NEMO basic Mobile
			Routers or Mobile IPv6 Mobile Nodes. In this case, the DHCPv6PD
			Support Flag MUST be set to 0.
			The modified message format is as follows.
			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 | Code | Checksum |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Identifier |R|D| Reserved |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| |
			+ +
			+ +
			| |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			DHCPv6PD Support Flag (D)
			A one-bit flag that when set indicates that the Home Agents
			listed in this message participate to DHCPv6 Prefix Delegation.
			For a description of the other fields in the message, see [RFC3775]
			and [RFC 3963].
			3.5.3. Modified Home Agent Information Option
			A new flag (D) (Support for DHCPv6PD) is introduced in the Home Agent
			Information Option defined in [RFC3775] and [RFC 3963].
			If a Home Agent participates to DHCPv6PD, it SHOULD set the flag. If
			the HA sets the 'D' flag, then it MUST also set the 'R' flag,
			Indicating that it supports Mobile Routers, as defined in [RFC 3963].
			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 |R|D| Reserved |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Home Agent Preference | Home Agent Lifetime |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			DHCPv6PD Support Flag (D)
			A one-bit flag that when set indicates that the Home Agents
			participates to DHCPv6 Prefix Delegation.
			For a description of the other fields in the message, see [RFC3775]
			and [RFC 3963].
			3.6. Location of DHCPv6PD Delegating Router function
			Support of DHCPv6PD for a Mobile Network is optional.
			The use of a DHCPv6 relay agent is not defined for DHCPv6PD in the
			DHCPv6PD specification [1]. If the DHCPv6PD DR function is
			implemented in the HA for the MR, no relay agent function is
			required.
			It may be desirable to use a single DR to manage RRs in a network
			with multiple HAs. In this scenario, the HAs will act as DHCP relay
			agents, forwarding messages between the RRs and the DR.
			Use of the DHCPv6 relay agent function with DHCPv6PD requires that
			there be some mechanism through which routing information for the
			delegated prefixes can be added to the appropriate routing
			infrastructure. If the HA is acting as a DHCPv6 relay agent, the HA
			SHOULD add a route to the delegated prefix and advertise that route
			after receiving a binding update for the prefix from the RR [8].
			In particular, if the MR uses NEMO explicit mode, then it must add
			the delegated prefix to prefix list in the Binding Update messages.
			If the binding cache is cleared before the prefix valid lifetime, the
			MR might bind that prefix again using explicit mode, till the
			lifetime expires.
			In implicit mode, the HA must save the delegated prefix with the
			binding cache entry of the Mobile Router. When the BCE is cleared,
			the HA loses the information about the delegated prefix. Because the
			MR will use DHCPv6 when it reestablishes its tunnel to the HA (see
			Section 3.1), the HA will be able to add the delegated prefix back to
			the BCE.
			At the time this draft was written, one way in which a DR can
			explicitly notify a relay agent about delegated prefixes, is to use
			the "DHCP Relay Agent Assignment Notification Option" [9].
			Another alternative, if the RR is part of the same administrative
			domain as the home network to which it is attached through the HA,
			and the RR can be trusted, the RR can use a routing protocol like
			OSPF to advertise any delegated prefixes.
			NEMO explicit mode is recommended to take advantage of the function
			already defined for NEMO.
			3.7. 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		The HA may act as a DHCPv6 relay agent for MHs while it acts as a DR
	for MRs.		for MRs.
	3.2 Delegating Access Prefixes		4. Changes in this draft
	A Mobile Router may also obtain a temporary delegated prefix from its		4.1. Revision -01
	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		Removed section 3.2, "Delegating Access Prefixes".
	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		Modified sections 3 and 3.6 (was section 3.1.3), "Location of
	structure are all aggregated by a larger prefix owned, subdelegated,		DHCPv6PD Delegating Router function," to allow for DHCPv6PD through a
	and advertised to the infrastructure by the Access Router itself.		relay agent and to allow for a single DR on a home network to perform
			PD for RRs through more than one HA.
	It is possible to protect the privacy of both parties between a VMN		Added section 3.1 describing when the MR should use DHCPv6 PD.
	that implements RFC 3041 [9] 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		Added section 3.4 describing use of Rapid Commit to minimize DHCPv6PD
	MR maintain a tunnel and that the connectivity between the two is		messages and
	maintained somehow; this can be achieved by:
	o Performing a routing protocol such as a MANET within the nested		Added section 3.5 recommending that DHCPv6PD and DHAAD be kept
	topology.		independent and describing flags indicating availability of PD
	o performing some L3 bridging technique between AR and MRs.		service from HA.
	o 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		Added section 3.7 describing the use of DHCPv6 for other
	its delegated prefix as CareOf to register to its Home Agent. As a		configuration in parallel with PD.
	result, the MR gets some advantages similar to those obtained with
	HMIP.
	4. Security Considerations		5. 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 [6] and the
	"Security Considerations" of the DHCPv6 Prefix Delegation		"Security Considerations" of the DHCPv6 Prefix Delegation
	specification [1].		specification [1].
	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 [6], to
	guard against attacks mounted through prefix delegation.		guard against attacks mounted through prefix delegation.
	5. IANA Considerations		6. 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. Normative References		7. Normative References
	[1] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host		[1] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host
	Configuration Protocol (DHCP) version 6", RFC 3633,		Configuration Protocol (DHCP) version 6", RFC 3633,
	December 2003.		December 2003.
	[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement		[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
	Levels", BCP 14, RFC 2119, March 1997.		Levels", BCP 14, RFC 2119, March 1997.
	[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 3513, April 2003.		Addressing Architecture", RFC 3513, April 2003.
	[4] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in		[4] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
	IPv6", RFC 3775, June 2004.		IPv6", RFC 3775, June 2004.
	[5] Ernst, T. and H. Lach, "Network Mobility Support Terminology",		[5] Ernst, T. and H. Lach, "Network Mobility Support Terminology",
	draft-ietf-nemo-terminology-03 (work in progress),		draft-ietf-nemo-terminology-04 (work in progress), October 2005.
	February 2005.
	[6] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M.		[6] 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.
	[7] Ernst, T., "Network Mobility Support Goals and Requirements",		[7] Ernst, T., "Network Mobility Support Goals and Requirements",
	draft-ietf-nemo-requirements-04 (work in progress),		draft-ietf-nemo-requirements-05 (work in progress),
	February 2005.		October 2005.
	[8] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert,		[8] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert,
	"Network Mobility (NEMO) Basic Support Protocol", RFC 3963,		"Network Mobility (NEMO) Basic Support Protocol", RFC 3963,
	January 2005.		January 2005.
	[9] Narten, T. and R. Draves, "Privacy Extensions for Stateless		[9] Droms, R., "DHCP Relay Agent Assignment Notification Option",
	Address Autoconfiguration in IPv6", RFC 3041, January 2001.		draft-ietf-dhc-dhcpv6-agentopt-delegate-00 (work in progress),
			January 2006.
	Authors' Addresses		Authors' Addresses
	Ralph Droms		Ralph Droms
	Cisco		Cisco
	1414 Massachusetts Avenue		1414 Massachusetts Avenue
	Boxborough, MA 01719		Boxborough, MA 01719
	USA		USA
	Phone: +1 978.936.1674		Phone: +1 978.936.1674
	skipping to change at page 6, line 32 ¶		skipping to change at page 11, line 5 ¶
	Pascal Thubert		Pascal Thubert
	Cisco		Cisco
	Village d'Entreprises Green Side		Village d'Entreprises Green Side
	400, Avenue Roumanille		400, Avenue Roumanille
	Biot - Sophia Antipolis 06410		Biot - Sophia Antipolis 06410
	FRANCE		FRANCE
	Email: pthubert@cisco.com		Email: pthubert@cisco.com
	Appendix A. Changes Log
	Rev -01: 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.
	Rev -02: The section on optimization of access prefix delegation was
	removed.
	WG work item: Published as draft-ietf-nemo-dhcpv6-pd-02.txt
	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 Rights 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; nor does it represent that it has		might or might not be available; nor does it represent that it has
	made any independent effort to identify any such rights. Information		made any independent effort to identify any such rights. Information
	on the procedures with respect to rights in RFC documents can be		on the procedures with respect to rights in RFC documents can be
	found in BCP 78 and BCP 79.		found in BCP 78 and BCP 79.
	skipping to change at page 7, line 29 ¶		skipping to change at page 11, line 29 ¶
	such proprietary rights by implementers or users of this		such proprietary rights by implementers or users of this
	specification can be obtained from the IETF on-line IPR repository at		specification can be obtained from the IETF on-line IPR repository at
	http://www.ietf.org/ipr.		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 that may cover technology that may be required to implement		rights that may cover technology that may be required to implement
	this standard. Please address the information to the IETF at		this standard. Please address the information to the IETF at
	ietf-ipr@ietf.org.		ietf-ipr@ietf.org.
	The IETF has been notified of intellectual property rights claimed in
	regard to some or all of the specification contained in this
	document. For more information consult the online list of claimed
	rights.
	Disclaimer of Validity		Disclaimer of Validity
	This document and the information contained herein are provided on an		This document and the information contained herein are provided on an
	"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS		"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
	OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET		OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
	ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,		ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
	INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE		INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
	INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED		INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
	WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.		WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
	Copyright Statement		Copyright Statement
	Copyright (C) The Internet Society (2005). This document is subject		Copyright (C) The Internet Society (2006). This document is subject
	to the rights, licenses and restrictions contained in BCP 78, and		to the rights, licenses and restrictions contained in BCP 78, and
	except as set forth therein, the authors retain all their rights.		except as set forth therein, the authors retain all their rights.
	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. 39 change blocks.
	109 lines changed or deleted		258 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/