draft-ietf-dmm-hnprenum-06.txt		draft-ietf-dmm-hnprenum-07.txt
	DMM Working Group Z. Yan		DMM Working Group Z. Yan
	Internet-Draft CNNIC		Internet-Draft CNNIC
	Intended status: Standards Track J. Lee		Intended status: Standards Track J. Lee
	Expires: August 19, 2017 Sangmyung University		Expires: September 14, 2017 Sangmyung University
	X. Lee		X. Lee
	CNNIC		CNNIC
	February 15, 2017		March 13, 2017
	Home Network Prefix Renumbering in PMIPv6		Home Network Prefix Renumbering in PMIPv6
	draft-ietf-dmm-hnprenum-06		draft-ietf-dmm-hnprenum-07
	Abstract		Abstract
	In the basic Proxy Mobile IPv6 (PMIPv6) specification, a Mobile Node		In the basic Proxy Mobile IPv6 (PMIPv6) specification, a Mobile Node
	(MN) is assigned with a Home Network Prefix (HNP) during its initial		(MN) is assigned with a Home Network Prefix (HNP) during its initial
	attachment and the MN configures its Home Address (HoA) with the HNP.		attachment and the MN configures its Home Address (HoA) with the HNP.
	During the movement of the MN, the HNP remains unchanged to keep		During the movement of the MN, the HNP remains unchanged to keep
	ongoing communications associated with the HoA. However, the current		ongoing communications associated with the HoA. However, the current
	PMIPv6 specification does not specify related operations when an HNP		PMIPv6 specification does not specify related operations when an HNP
	renumbering has happened (e.g. due to change of service provider,		renumbering has happened (e.g. due to change of service provider,
	change of site topology, etc.). In this document, a solution to		change of site topology, etc.). In this document, a solution to
	support the HNP renumbering is proposed, as an update of the PMIPv6		support the HNP renumbering is proposed, as an optional extension of
	specification.		the PMIPv6 specification.
	Requirements Language		Requirements Language
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL","SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL","SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in [RFC2119]		document are to be interpreted as described in [RFC2119]
	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
	skipping to change at page 1, line 48 ¶		skipping to change at page 1, line 48 ¶
	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 August 19, 2017.		This Internet-Draft will expire on September 14, 2017.
	Copyright Notice		Copyright Notice
	Copyright (c) 2017 IETF Trust and the persons identified as the		Copyright (c) 2017 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Usage Scenarios . . . . . . . . . . . . . . . . . . . . . . . 2		2. Usage Scenarios . . . . . . . . . . . . . . . . . . . . . . . 2
	3. PMIPv6 Extensions . . . . . . . . . . . . . . . . . . . . . . 3		3. HNP Renumbering Procedure . . . . . . . . . . . . . . . . . . 3
	4. Session Connectivity . . . . . . . . . . . . . . . . . . . . 5		4. Session Connectivity . . . . . . . . . . . . . . . . . . . . 5
	5. Message Format . . . . . . . . . . . . . . . . . . . . . . . 6		5. Message Format . . . . . . . . . . . . . . . . . . . . . . . 5
	6. Other Issues . . . . . . . . . . . . . . . . . . . . . . . . 6		6. Other Issues . . . . . . . . . . . . . . . . . . . . . . . . 6
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 6		7. Security Considerations . . . . . . . . . . . . . . . . . . . 6
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7		9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
	9.1. Normative References . . . . . . . . . . . . . . . . . . 7		9.1. Normative References . . . . . . . . . . . . . . . . . . 7
	9.2. Informative References . . . . . . . . . . . . . . . . . 8		9.2. Informative References . . . . . . . . . . . . . . . . . 8
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
	1. Introduction		1. Introduction
	Network managers currently prefer Provider Independent (PI)		Network managers currently prefer Provider Independent (PI)
	addressing for IPv6 to attempt to minimize the need for future		addressing for IPv6 to attempt to minimize the need for future
	possible renumbering. However, a widespread use of PI addresses may		possible renumbering. However, a widespread use of PI addresses will
	cause Border Gateway Protocol (BGP) scaling problems [RFC7010]. It		cause Border Gateway Protocol (BGP) scaling problems [RFC7010]. It
	is thus desirable to develop tools and practices that make IPv6		is thus desirable to develop tools and practices that make IPv6
	renumbering a simpler process to reduce demand for IPv6 PI space		renumbering a simpler process to reduce demand for IPv6 PI space
	[RFC6879]. In this document, we aim to solve the HNP renumbering		[RFC6879]. In this document, we aim to solve the HNP renumbering
	problem when the HNP in PMIPv6 [RFC5213] is not the type of PI.		problem when the HNP in PMIPv6 [RFC5213] is a PI prefix.
	2. Usage Scenarios		2. Usage Scenarios
	There are a number of reasons why the HNP renumbering support in		There are a number of reasons why the HNP renumbering support in
	PMIPv6 is useful and some scenarios are identified below:		PMIPv6 is useful and some scenarios are identified below:
	o Scenario 1: the HNP set used by a PMIPv6 service provider is		o Scenario 1: the HNP set used by a PMIPv6 service provider is
	assigned by a different Internet Service Provider (ISP), and then		assigned by a different Internet Service Provider (ISP), and then
	the HNP renumbering may happen if the PMIPv6 service provider		the HNP renumbering MAY happen if the PMIPv6 service provider
	switches to a different ISP.		switches to a different ISP.
	o Scenario 2: multiple Local Mobility Anchors (LMAs) may be deployed		o Scenario 2: multiple Local Mobility Anchors (LMAs) MAY be deployed
	by the same PMIPv6 service provider, and then each LMA may serve		by the same PMIPv6 service provider, and then each LMA MAY serve
	for a specific HNP set. In this case, the HNP of an MN may change		for a specific HNP set. In this case, the HNP of an MN MAY change
	if the current serving LMA switches to another LMA but without		if the current serving LMA switches to another LMA but without
	inheriting the assigned HNP set [RFC6463].		inheriting the assigned HNP set [RFC6463].
	o Scenario 3: the PMIPv6 HNP renumbering may be caused by the re-		o Scenario 3: the PMIPv6 HNP renumbering MAY be caused by the re-
	building of the network architecture as the companies split,		building of the network architecture as the companies split,
	merge, grow, relocate, or reorganize. For example, the PMIPv6		merge, grow, relocate, or reorganize. For example, the PMIPv6
	service provider may reorganize its network topology.		service provider MAY reorganize its network topology.
	In the scenario 1, we assume that only the HNP is renumbered while		In the scenario 1, we assume that only the HNP is renumbered while
	the serving LMA remains unchanged and this is the basic scenario		the serving LMA remains unchanged and this is the basic scenario
	considered in this document. In the scenario 2 and scenario 3, more		considered in this document. In the scenario 2 and scenario 3, more
	complex results may be caused, for example, the HNP renumbering may		complex results MAY be caused, for example, the HNP renumbering MAY
	happen due to the switchover of a serving LMA.		happen due to the switchover of a serving LMA.
	In the Mobile IPv6 (MIPv6) protocol, when a home network prefix		In the Mobile IPv6 (MIPv6) protocol, when a home network prefix
	changes, the Home Agent (HA) will actively notify the new prefix to		changes, the Home Agent (HA) will actively notify the new prefix to
	its MN and then the renumbering of the Home Network Address (HoA) can		its MN and then the renumbering of the Home Network Address (HoA) can
	be well supported [RFC6275]. In the basic PMIPv6, the PMIPv6 binding		be well supported [RFC6275]. In the basic PMIPv6, the PMIPv6 binding
	is triggered by a Mobile Access Gateway (MAG), which detects the		is triggered by a Mobile Access Gateway (MAG), which detects the
	attachment of the MN. A scheme is also needed for the LMA to		attachment of the MN. A scheme is also needed for the LMA to
	immediately initiate the PMIPv6 binding state refreshment during the		immediately initiate the PMIPv6 binding state refreshment during the
	HNP renumbering process. Although this issue is also mentioned in		HNP renumbering process. Although this issue is also mentioned in
	Section 6.12 of [RFC5213], the related solution has not been		Section 6.12 of [RFC5213], the related solution has not been
	specified.		specified.
	3. PMIPv6 Extensions		3. HNP Renumbering Procedure
	When the HNP renumbering happens in PMIPv6, the LMA has to notify a		When the HNP renumbering happens in PMIPv6, the LMA MUST notify a new
	new HNP to a MAG and then the MAG has to announce the new HNP to the		HNP to the MAG and then the MAG MUST announce the new HNP to the
	attached MN accordingly. Also, the LMA and the MAG must update the		attached MN accordingly. Also, the LMA and the MAG MUST update the
	routing states for the HNP and the related addresses. To support		routing states for the HNP and the related addresses. To support
	this procedure, [RFC7077] can be adopted which specifies an		this procedure, [RFC7077] can be adopted which specifies an
	asynchronous update from the LMA to the MAG about specific session		asynchronous update from the LMA to the MAG about specific session
	parameters. This document considers the following two cases:		parameters. This document considers the following two cases:
	(1) HNP is renumbered under the same LMA		(1) HNP is renumbered under the same LMA
	In this case, the LMA remains unchanged as in the scenario 1 and		In this case, the LMA remains unchanged as in the scenario 1 and
	scenario 3. The operation steps are shown in Figure 1.		scenario 3. The operation steps are shown in Figure 1.
	+-----+ +-----+ +-----+		+-----+ +-----+ +-----+
	| MN | | MAG | | LMA |		| MN | | MAG | | LMA |
	+-----+ +-----+ +-----+		+-----+ +-----+ +-----+
	| | |		| | |
	| | Allocate new HNP		| | Allocate new HNP
	| | |		| | |
	| |<------------- UPN ---|		| |<------------- UPN ---|
	| | |		| | |
	| | |		| | |
	| | |		| | |
	|<-----RA/DHCP --------| |		|<-----RA/DHCP --------| |
	| | |		| | |
	Address configuration | |		Address configuration | |
	| | |		| | |
	| Update binding&routing states |		| Update binding&routing states |
	| | |		| | |
	| |--- UPA ------------->|		| |--- UPA ------------->|
	| | |		| | |
	| | Update binding&routing states		| | Update binding&routing states
	| | |		| | |
	Figure 1: Signaling call flow of the HNP renumbering		Figure 1: Signaling call flow of the HNP renumbering
	o When a PMIPv6 service provider renumbers the HNP set under the		o When a PMIPv6 service provider renumbers the HNP set under the
	same LMA, the serving LMA will initiate the HNP renumbering		same LMA, the serving LMA SHOULD initiate the HNP renumbering
	operation. The LMA allocates a new HNP for the related MN.		operation. The LMA allocates a new HNP for the related MN.
	o The LMA sends the Update Notification (UPN) message to the MAG to		o The LMA sends the Update Notification (UPN) message to the MAG to
	update the HNP information. If the Dynamic Host Configuration		update the HNP information. If the Dynamic Host Configuration
	Protocol (DHCP) is used to allocate the address, the new HNP		Protocol (DHCP) is used to allocate the address, the new HNP MUST
	should be also notified to the DHCP infrastructure.		be also notified to the DHCP infrastructure.
	o Once the MAG receives this UPN message, it recognizes that the		o Once the MAG receives this UPN message, it recognizes that the
	related MN has the new HNP. Then the MAG should notify the MN		related MN has the new HNP. Then the MAG MUST notify the MN about
	about the new HNP with a Router Advertisement (RA) message or		the new HNP with a Router Advertisement (RA) message or allocate a
	allocate a new address within the new HNP through a DHCP		new address within the new HNP through a DHCP procedure.
	procedure.
	o After the MN obtains the HNP information through the RA message,		o After the MN obtains the HNP information through the RA message,
	it deletes the old HoA and configures a new HoA with the newly		it deletes the old HoA and configures a new HoA with the newly
	allocated HNP.		allocated HNP.
	o When the new HNP is announced or the new address is configured to		o When the new HNP is announced or the new address is configured to
	the MN successfully, the MAG updates the related binding and		the MN successfully, the MAG MUST update the related binding and
	routing states. Then the MAG sends back the Update Notification		routing states. Then the MAG sends back the Update Notification
	Acknowledgement (UPA) message to the LMA for the notification of		Acknowledgement (UPA) message to the LMA for the notification of
	successful update of the HNP, related binding state, and routing		successful update of the HNP, related binding state, and routing
	state. Then the LMA updates the routing and binding information		state. Then the LMA updates the routing and binding information
	corresponding to the MN to replace the old HNP with the new one.		corresponding to the MN to replace the old HNP with the new one.
	(2) HNP renumbering caused by the LMA switchover		(2) HNP renumbering caused by the LMA switchover
	Since the HNP is assigned by the LMA, the HNP renumbering may be		Since the HNP is assigned by the LMA, the HNP renumbering MAY be
	caused by the LMA switchover, as in the scenario 2 and scenario 3.		caused by the LMA switchover, as in the scenario 2 and scenario 3.
	The information of LMA is the basic configuration information of MAG.		The information of LMA is the basic configuration information of MAG.
	When the LMA changes, the related profile should be updated by the		When the LMA changes, the related profile SHOULD be updated by the
	service provider. In this way, the MAG initiates the registration to		service provider. In this way, the MAG initiates the registration to
	the new LMA as specified in [RFC5213]. When the HNP renumbering is		the new LMA as specified in [RFC5213]. When the HNP renumbering is
	caused in this case, the new HNP information is sent by the LMA		caused in this case, the new HNP information is sent by the LMA
	during the new binding procedure. Accordingly, the MAG withdraws the		during the new binding procedure. Accordingly, the MAG withdraws the
	old HNP of the MN and announces the new HNP to the MN as like the		old HNP of the MN and announces the new HNP to the MN as like the
	case of the HNP is renumbered under the same LMA.		case of the HNP is renumbered under the same LMA.
	4. Session Connectivity		4. Session Connectivity
	The HNP renumbering may cause the disconnection of the ongoing		The HNP renumbering may cause the disconnection of the ongoing
	skipping to change at page 5, line 35 ¶		skipping to change at page 5, line 33 ¶
	the session connectivity during the HNP renumbering.		the session connectivity during the HNP renumbering.
	(1) Soft-mode		(1) Soft-mode
	The LMA will temporarily maintain the state of the old HNP during the		The LMA will temporarily maintain the state of the old HNP during the
	HNP renumbering (after the UPA reception) in order to redirect the		HNP renumbering (after the UPA reception) in order to redirect the
	packets to the MN before the MN reconnects the ongoing session and		packets to the MN before the MN reconnects the ongoing session and
	notifies its new HoA to the Correspondent Node (CN). This mode is		notifies its new HoA to the Correspondent Node (CN). This mode is
	aiming to reduce the packet loss during the HNP renumbering but the		aiming to reduce the packet loss during the HNP renumbering but the
	binding state corresponding to the old HNP should be marked for		binding state corresponding to the old HNP should be marked for
	example as transient binding [RFC6058]. This temporary binding		example as transient binding [RFC6058]. And the LMA MUST stop
	should only be used for the downwards packet transmission and the LMA		broadcasting the routing information about the old HNP if the old HNP
	should stop broadcasting the routing information about the old HNP if		is no longer anchored at this LMA.
	the old HNP is no longer anchored at this LMA.
	(2) Hard-mode		(2) Hard-mode
	If the HNP renumbering happens with the switchover of the LMA, the		If the HNP renumbering happens with the switchover of the LMA, the
	hard-mode is recommended to keep the protocol simple. In this mode,		hard-mode is recommended to keep the protocol simple. In this mode,
	the LMA deletes the binding state of the old HNP after it receives		the LMA deletes the binding state of the old HNP after it receives
	the UPA message from the MAG and the LMA silently discards the		the UPA message from the MAG and the LMA silently discards the
	packets destined to the old HNP.		packets destined to the old HNP.
	5. Message Format		5. Message Format
	(1) UPN message		(1) UPN message
	In the UPN message sent from the LMA to the MAG, the notification		In the UPN message sent from the LMA to the MAG, the notification
	reason is set to 2 (UPDATE-SESSION-PARAMETERS). Besides, the HNP		reason is set to 2 (UPDATE-SESSION-PARAMETERS). Besides, the HNP
	Option [RFC5213] containing the new HNP and the Mobile Node		Option [RFC5213] containing the new HNP and the Mobile Node
	Identifier Option [RFC4283] carrying identifier of MN are contained		Identifier Option [RFC4283] carrying identifier of MN are contained
	as Mobility Options of UPN. The order of HNP Option and Mobile Node		as Mobility Options of UPN. The order of HNP Option and Mobile Node
	Identifier Option in the UPN message is not mandated in this draft.		Identifier Option in the UPN message is not mandated here.
	(2) UPA message		(2) UPA message
	The MAG sends this message in order to acknowledge that it has		The MAG sends this message in order to acknowledge that it has
	received an UPN message with the (A) flag set and to indicate the		received an UPN message with the (A) flag set and to indicate the
	status after processing the message. When the MAG did not		status after processing the message. When the MAG did not
	successfully renumber the HNP which is required in the UPN message,		successfully renumber the HNP which is required in the UPN message,
	the Status Code of 128 is set in the UPA message and the following		the Status Code of 128 is set in the UPA message and the following
	operation of LMA is PMIPv6 service provider specific.		operation of LMA is PMIPv6 service provider specific.
	(3) RA Message		(3) RA Message
	When the RA message is used by the MAG to advise the new HNP, two		When the RA message is used by the MAG to advise the new HNP, two
	Prefix Information Options are contained in the RA message [RFC4861].		Prefix Information Options are contained in the RA message [RFC4861]
	In the first Prefix Information Option, the old HNP is carried but		[RFC4862]. In the first Prefix Information Option, the old HNP is
	both the related Valid Lifetime and Preferred Lifetime are set to 0.		carried and the related Preferred Lifetime is set to 0. In the
	In the second Prefix Information Option, the new HNP is carried with		second Prefix Information Option, the new HNP is carried with the
	the Valid Lifetime and Preferred Lifetime set to larger than 0.		Valid Lifetime and Preferred Lifetime set to larger than 0.
	(4) DHCP Message		(4) DHCP Message
	When the DHCP is used in PMIPv6 to configure the addresses for the		When the DHCP is used in PMIPv6 to configure the addresses for the
	MN, new IPv6 address(es) (e.g., HoA) will be generated based on the		MN, new IPv6 address(es) (e.g., HoA) will be generated based on the
	new HNP and the related DHCP procedure is also triggered by the		new HNP and the related DHCP procedure is also triggered by the
	reception of UPN message [RFC3315].		reception of UPN message [RFC3315].
	6. Other Issues		6. Other Issues
	In order to maintain the reachability of the MN, the Domain Name		In order to maintain the reachability of the MN, the Domain Name
	System (DNS) resource record corresponding to this MN may need to be		System (DNS) resource record corresponding to this MN may need to be
	updated when the HNP of MN changes [RFC3007]. However, this is		updated when the HNP of MN changes [RFC3007]. However, this is
	beyond the scope of this document.		beyond the scope of this document.
	7. Security Considerations		7. Security Considerations
	The protection of UPN and UPA messages in this document follows		This document causes no further security problem for the signaling
	[RFC5213] and [RFC7077]. This extension thus causes no further		exchanges. The UPN and UPA messages in this document MUST be
	security problems for protecting of the messages.		protected using end-to-end security association(s) offering integrity
			and data origin authentication as speficied in [RFC5213] and
			[RFC7077].
	When the HNP renumbering is triggered, a new HNP has to be allocated		When the HNP renumbering is triggered, a new HNP SHOULD be allocated
	to the MN. The LMA must follow the procedure of PMIPv6 to make sure		to the MN. The LMA MUST follow the procedure of PMIPv6 to make sure
	that only an authorized HNP can be assigned for the MN. In this way,		that only an authorized HNP can be assigned for the MN. In this way,
	LMA is ready to be the topological anchor point of the new HNP and		LMA is ready to be the topological anchor point of the new HNP and
	the new HNP is for that MN's exclusive use.		the new HNP is for that MN's exclusive use.
			[RFC4862] requires an RA to be authenticated for the Valid Lifetime
			in a Prefix Information Option to be set to less than 2 hours. Thus,
			when the old HNP that is being deprecated is included in an RA from
			the MAG, it will normally be expected that the Valid Lifetime SHOULD
			be set to 2 hours (and the Preferred Lifetime set to 0) for a non-
			authenticated RA. However, if the legality of the signaling messages
			exchanged between MAG and MN can be guaranteed, it MAY be acceptable
			to also set the Valid Lifetime to 0 for a non-authenticated RA.
	8. IANA Considerations		8. IANA Considerations
	This document presents no IANA considerations.		This document presents no IANA considerations.
	9. References		9. References
	9.1. Normative References		9.1. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119,
	skipping to change at page 7, line 43 ¶		skipping to change at page 7, line 46 ¶
	[RFC4283] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K.		[RFC4283] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K.
	Chowdhury, "Mobile Node Identifier Option for Mobile IPv6		Chowdhury, "Mobile Node Identifier Option for Mobile IPv6
	(MIPv6)", RFC 4283, DOI 10.17487/RFC4283, November 2005,		(MIPv6)", RFC 4283, DOI 10.17487/RFC4283, November 2005,
	<http://www.rfc-editor.org/info/rfc4283>.		<http://www.rfc-editor.org/info/rfc4283>.
	[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,		[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
	"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,		"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
	DOI 10.17487/RFC4861, September 2007,		DOI 10.17487/RFC4861, September 2007,
	<http://www.rfc-editor.org/info/rfc4861>.		<http://www.rfc-editor.org/info/rfc4861>.
			[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
			Address Autoconfiguration", RFC 4862,
			DOI 10.17487/RFC4862, September 2007,
			<http://www.rfc-editor.org/info/rfc4862>.
	[RFC5213] Gundavelli, S., Ed., Leung, K., Devarapalli, V.,		[RFC5213] Gundavelli, S., Ed., Leung, K., Devarapalli, V.,
	Chowdhury, K., and B. Patil, "Proxy Mobile IPv6",		Chowdhury, K., and B. Patil, "Proxy Mobile IPv6",
	RFC 5213, DOI 10.17487/RFC5213, August 2008,		RFC 5213, DOI 10.17487/RFC5213, August 2008,
	<http://www.rfc-editor.org/info/rfc5213>.		<http://www.rfc-editor.org/info/rfc5213>.
	[RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility		[RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility
	Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July		Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July
	2011, <http://www.rfc-editor.org/info/rfc6275>.		2011, <http://www.rfc-editor.org/info/rfc6275>.
	[RFC6463] Korhonen, J., Ed., Gundavelli, S., Yokota, H., and X. Cui,		[RFC6463] Korhonen, J., Ed., Gundavelli, S., Yokota, H., and X. Cui,
End of changes. 30 change blocks.
	66 lines changed or deleted		80 lines changed or added
This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/