draft-ietf-dmm-pmipv6-dlif-06.txt		rfc8885.txt
	DMM Working Group CJ. Bernardos		Internet Engineering Task Force (IETF) CJ. Bernardos
	Internet-Draft A. de la Oliva		Request for Comments: 8885 A. de la Oliva
	Intended status: Experimental UC3M		Category: Experimental UC3M
	Expires: September 9, 2020 F. Giust		ISSN: 2070-1721 F. Giust
	Athonet		Athonet
	JC. Zuniga		JC. Zúñiga
	SIGFOX		SIGFOX
	A. Mourad		A. Mourad
	InterDigital		InterDigital
	March 8, 2020		October 2020
	Proxy Mobile IPv6 extensions for Distributed Mobility Management		Proxy Mobile IPv6 Extensions for Distributed Mobility Management
	draft-ietf-dmm-pmipv6-dlif-06
	Abstract		Abstract
	Distributed Mobility Management solutions allow for setting up		Distributed Mobility Management solutions allow networks to be set up
	networks so that traffic is distributed in an optimal way and does		in such a way that traffic is distributed optimally and centrally
	not rely on centrally deployed anchors to provide IP mobility		deployed anchors are not relied upon to provide IP mobility support.
	support.
	There are many different approaches to address Distributed Mobility		There are many different approaches to address Distributed Mobility
	Management, as for example extending network-based mobility protocols		Management -- for example, extending network-based mobility protocols
	(like Proxy Mobile IPv6), or client-based mobility protocols (like		(like Proxy Mobile IPv6) or client-based mobility protocols (like
	Mobile IPv6), among others. This document follows the former		Mobile IPv6), among others. This document follows the former
	approach and proposes a solution based on Proxy Mobile IPv6 in which		approach and proposes a solution based on Proxy Mobile IPv6, in which
	mobility sessions are anchored at the last IP hop router (called		mobility sessions are anchored at the last IP hop router (called the
	mobility anchor and access router). The mobility anchor and access		mobility anchor and access router). The mobility anchor and access
	router is an enhanced access router which is also able to operate as		router is an enhanced access router that is also able to operate as a
	a local mobility anchor or mobility access gateway, on a per prefix		local mobility anchor or mobility access gateway on a per-prefix
	basis. The document focuses on the required extensions to		basis. The document focuses on the required extensions to
	effectively support simultaneously anchoring several flows at		effectively support the simultaneous anchoring several flows at
	different distributed gateways.		different distributed gateways.
	Requirements Language
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in BCP
	14 [RFC2119] [RFC8174] when, and only when, they appear in all
	capitals, as shown here.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This document is not an Internet Standards Track specification; it is
	provisions of BCP 78 and BCP 79.		published for examination, experimental implementation, and
			evaluation.
	Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		This document defines an Experimental Protocol for the Internet
	and may be updated, replaced, or obsoleted by other documents at any		community. This document is a product of the Internet Engineering
	time. It is inappropriate to use Internet-Drafts as reference		Task Force (IETF). It represents the consensus of the IETF
	material or to cite them other than as "work in progress."		community. It has received public review and has been approved for
			publication by the Internet Engineering Steering Group (IESG). Not
			all documents approved by the IESG are candidates for any level of
			Internet Standard; see Section 2 of RFC 7841.
	This Internet-Draft will expire on September 9, 2020.		Information about the current status of this document, any errata,
			and how to provide feedback on it may be obtained at
			https://www.rfc-editor.org/info/rfc8885.
	Copyright Notice		Copyright Notice
	Copyright (c) 2020 IETF Trust and the persons identified as the		Copyright (c) 2020 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
	(https://trustee.ietf.org/license-info) in effect on the date of		(https://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 . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4		1.1. Requirements Language
	3. PMIPv6 DMM extensions . . . . . . . . . . . . . . . . . . . . 6		2. Terminology
	3.1. Initial registration . . . . . . . . . . . . . . . . . . 7		3. PMIPv6 DMM Extensions
	3.2. The CMD as PBU/PBA relay . . . . . . . . . . . . . . . . 8		3.1. Initial Registration
	3.3. The CMD as MAAR locator . . . . . . . . . . . . . . . . . 11		3.2. The CMD as PBU/PBA Relay
	3.4. The CMD as MAAR proxy . . . . . . . . . . . . . . . . . . 12		3.3. The CMD as MAAR Locator
	3.5. De-registration . . . . . . . . . . . . . . . . . . . . . 13		3.4. The CMD as PBU/PBA Proxy
	3.6. Retransmissions and Rate Limiting . . . . . . . . . . . . 14		3.5. De-registration
	3.7. The Distributed Logical Interface (DLIF) concept . . . . 14		3.6. Retransmissions and Rate Limiting
	4. Message Format . . . . . . . . . . . . . . . . . . . . . . . 18		3.7. The Distributed Logical Interface (DLIF) Concept
	4.1. Proxy Binding Update . . . . . . . . . . . . . . . . . . 18		4. Message Format
	4.2. Proxy Binding Acknowledgment . . . . . . . . . . . . . . 19		4.1. Proxy Binding Update
	4.3. Anchored Prefix Option . . . . . . . . . . . . . . . . . 19		4.2. Proxy Binding Acknowledgement
	4.4. Local Prefix Option . . . . . . . . . . . . . . . . . . . 21		4.3. Anchored Prefix Option
	4.5. Previous MAAR Option . . . . . . . . . . . . . . . . . . 22		4.4. Local Prefix Option
	4.6. Serving MAAR Option . . . . . . . . . . . . . . . . . . . 23		4.5. Previous MAAR Option
	4.7. DLIF Link-local Address Option . . . . . . . . . . . . . 24		4.6. Serving MAAR Option
	4.8. DLIF Link-layer Address Option . . . . . . . . . . . . . 25		4.7. DLIF Link-Local Address Option
			4.8. DLIF Link-Layer Address Option
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26		5. IANA Considerations
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 26		6. Security Considerations
	7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27		7. References
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . 27		7.1. Normative References
	8.1. Normative References . . . . . . . . . . . . . . . . . . 27		7.2. Informative References
	8.2. Informative References . . . . . . . . . . . . . . . . . 28		Acknowledgements
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28		Authors' Addresses
	1. Introduction		1. Introduction
	The Distributed Mobility Management (DMM) paradigm aims at minimizing		The Distributed Mobility Management (DMM) paradigm aims at minimizing
	the impact of currently standardized mobility management solutions		the impact of currently standardized mobility management solutions,
	which are centralized (at least to a considerable extent) [RFC7333].		which are centralized (at least to a considerable extent) [RFC7333].
	Current IP mobility solutions, standardized with the names of Mobile		The two most relevant examples of current IP mobility solutions are
	IPv6 [RFC6275], or Proxy Mobile IPv6 (PMIPv6) [RFC5213], just to cite		Mobile IPv6 [RFC6275] and Proxy Mobile IPv6 (PMIPv6) [RFC5213].
	the two most relevant examples, offer mobility support at the cost of		These solutions offer mobility support at the cost of handling
	handling operations at a cardinal point, the mobility anchor (i.e.,		operations at a cardinal point (i.e., the mobility anchor) and
	the home agent for Mobile IPv6, and the local mobility anchor for		burdening it with data forwarding and control mechanisms for a large
	Proxy Mobile IPv6), and burdening it with data forwarding and control		number of users. The mobility anchor is the home agent for Mobile
	mechanisms for a great amount of users. As stated in [RFC7333],		IPv6 and the local mobility anchor for PMIPv6. As stated in
	centralized mobility solutions are prone to several problems and		[RFC7333], centralized mobility solutions are prone to several
	limitations: longer (sub-optimal) routing paths, scalability		problems and limitations: longer (sub-optimal) routing paths,
	problems, signaling overhead (and most likely a longer associated		scalability problems, signaling overhead (and most likely a longer
	handover latency), more complex network deployment, higher		associated handover latency), more complex network deployment, higher
	vulnerability due to the existence of a potential single point of		vulnerability due to the existence of a potential single point of
	failure, and lack of granularity of the mobility management service		failure, and lack of granularity of the mobility management service
	(i.e., mobility is offered on a per-node basis, not being possible to		(i.e., mobility is offered on a per-node basis because it is not
	define finer granularity policies, as for example per-application).		possible to define finer granularity policies, for example, on a per-
			application basis).
	The purpose of Distributed Mobility Management is to overcome the		The purpose of DMM is to overcome the limitations of the traditional
	limitations of the traditional centralized mobility management		centralized mobility management [RFC7333] [RFC7429]; the main concept
	[RFC7333] [RFC7429]; the main concept behind DMM solutions is indeed		behind DMM solutions is indeed bringing the mobility anchor closer to
	bringing the mobility anchor closer to the Mobile Node (MN).		the mobile node (MN). Following this idea, the central anchor is
	Following this idea, the central anchor is moved to the edge of the		moved to the edge of the network and is deployed in the default
	network, being deployed in the default gateway of the mobile node.		gateway of the MN. That is, the first elements that provide IP
	That is, the first elements that provide IP connectivity to a set of		connectivity to a set of MNs are also the mobility managers for those
	MNs are also the mobility managers for those MNs. In this document,		MNs. In this document, we call these entities Mobility Anchors and
	we call these entities Mobility Anchors and Access Routers (MAARs).		Access Routers (MAARs).
	This document focuses on network-based DMM, hence the starting point		This document focuses on network-based DMM; hence, the starting point
	is making PMIPv6 work in a distributed manner [RFC7429]. Mobility is		is making PMIPv6 work in a distributed manner [RFC7429]. Mobility is
	handled by the network without the MNs involvement, but, differently		handled by the network without the MN's involvement. But differently
	from PMIPv6, when the MN moves from one access network to another, it		from PMIPv6, when the MN moves from one access network to another,
	may also change anchor router, hence requiring signaling between the		the router anchoring the MN's address may change, hence requiring
	anchors to retrieve the MN's previous location(s). Also, a key-		signaling between the anchors to retrieve the MN's previous
	aspect of network-based DMM, is that a prefix pool belongs		location(s). Also, a key aspect of network-based DMM is that a
	exclusively to each MAAR, in the sense that those prefixes are		prefix pool belongs exclusively to each MAAR in the sense that those
	assigned by the MAAR to the MNs attached to it, and they are routable		prefixes are assigned by the MAAR to the MNs attached to it and are
	at that MAAR. Prefixes are assigned to MNs attached a MAAR at that		routable at that MAAR. Prefixes are assigned to MNs attached to a
	time, but remain with those MNs as mobility occurs, remaining always		MAAR at that time, but remain with those MNs as mobility occurs,
	routable at that MAAR as well as towards the MN itself.		remaining always routable at that MAAR as well as towards the MN
			itself.
	We consider partially distributed schemes, where only the data plane		We consider partially distributed schemes, where only the data plane
	is distributed among access routers similar to MAGs, whereas the		is distributed among access routers similar to mobile access gateways
	control plane is kept centralized towards a cardinal node used as		(MAGs), whereas the control plane is kept centralized towards a
	information store, but relieved from any route management and MN's		cardinal node (used as an information store), which is discharged
	data forwarding task.		from any route management and MN's data forwarding tasks.
			1.1. Requirements Language
			The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
			"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
			"OPTIONAL" in this document are to be interpreted as described in
			BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
			capitals, as shown here.
	2. Terminology		2. Terminology
	The following terms used in this document are defined in the Proxy		The following terms used in this document are defined in the PMIPv6
	Mobile IPv6 specification [RFC5213]:		specification [RFC5213]:
	Local Mobility Anchor (LMA)		BCE: Binding Cache Entry
	Mobile Access Gateway (MAG)		LMA: Local Mobility Anchor
	Mobile Node (MN)		MAG: Mobile Access Gateway
	Binding Cache Entry (BCE)		MN: Mobile Node
	Proxy Care-of Address (P-CoA)		P-CoA: Proxy Care-of Address
	Proxy Binding Update (PBU)		PBA: Proxy Binding Acknowledgement
	Proxy Binding Acknowledgement (PBA)		PBU: Proxy Binding Update
			The following terms used in this document are defined in the Mobile
			IPv6 (MIPv6) specification [RFC6275]:
			CN: Correspondent Node
	The following terms are used in this document:		The following terms are used in this document:
	Home Control-Plane Anchor (Home-CPA or H-CPA): The Home-CPA function		Home Control-Plane Anchor (Home-CPA or H-CPA):
	hosts the mobile node (MN)'s mobility session. There can be more		The Home-CPA function hosts the MN's mobility session. There can
	than one mobility session for a mobile node and those sessions may		be more than one mobility session for an MN, and those sessions
	be anchored on the same or different Home-CPA's. The home-CPA		may be anchored on the same or different Home-CPAs. The Home-CPA
	will interface with the home-DPA for managing the forwarding		will interface with the Home-DPA for managing the forwarding
	state.		state.
	Home Data Plane Anchor (Home-DPA or H-DPA): The Home-DPA is the		Home Data Plane Anchor (Home-DPA or H-DPA):
	topological anchor for the MN's IP address/ prefix(es). The Home-		The Home-DPA is the topological anchor for the MN's IP addresses
	DPA is chosen by the Home-CPA on a session- basis. The Home-DPA		and/or prefixes. The Home-DPA is chosen by the Home-CPA on a
	is in the forwarding path for all the mobile node's IP traffic.		session basis. The Home-DPA is in the forwarding path for all the
			MN's IP traffic.
	Access Control Plane Node (Access-CPN or A-CPN): The Access-CPN is		Access Control Plane Node (Access-CPN or A-CPN):
	responsible for interfacing with the mobile node's Home-CPA and		The Access-CPN is responsible for interfacing with the MN's Home-
	with the Access-DPN. The Access-CPN has a protocol interface to		CPA and the Access-DPN. The Access-CPN has a protocol interface
	the Home-CPA.		to the Home-CPA.
	Access Data Plane Node (Access-DPN or A-DPN): The Access-DPN		Access Data Plane Node (Access-DPN or A-DPN):
	function is hosted on the first-hop router where the mobile node		The Access-DPN function is hosted on the first-hop router where
	is attached. This function is not hosted on a layer-2 bridging		the MN is attached. This function is not hosted on a Layer 2 (L2)
	device such as a eNode(B) or Access Point.		bridging device such as an eNode(B) or Access Point.
	The following terms are defined and used in this document:		The following terms are defined and used in this document:
	MAAR (Mobility Anchor and Access Router). First hop router where the		MAAR (Mobility Anchor and Access Router):
	mobile nodes attach to. It also plays the role of mobility		First-hop router where the MNs attach. It also plays the role of
	manager for the IPv6 prefixes it anchors, running the		mobility manager for the IPv6 prefixes it anchors, running the
	functionalities of PMIP's MAG and LMA. Depending on the prefix,		functionalities of PMIP's MAG and LMA. Depending on the prefix,
	it plays the role of Access-DPN, Home-DPA and Access-CPN.		it plays the role of Access-DPN, Home-DPA, and Access-CPN.
	CMD (Central Mobility Database). The node that stores the BCEs		CMD (Central Mobility Database):
	allocated for the MNs in the mobility domain. It plays the role		The node that stores the BCEs allocated for the MNs in the
	of Home-CPA.		mobility domain. It plays the role of Home-CPA.
	P-MAAR (Previous MAAR). When a MN moves to a new point of attachment		P-MAAR (Previous MAAR):
	a new MAAR might be allocated as its anchor point for future IPv6		When an MN moves to a new point of attachment, a new MAAR might be
	prefixes. The MAAR that served the MN prior to new attachment		allocated as its anchor point for future IPv6 prefixes. The MAAR
	becomes the P-MAAR. It is still the anchor point for the IPv6		that served the MN prior to new attachment becomes the P-MAAR. It
	prefixes it had allocated to the MN in the past and serves as the		is still the anchor point for the IPv6 prefixes it had allocated
	Home-DPA for flows using these prefixes. There might be several		to the MN in the past and serves as the Home-DPA for flows using
	P-MAARs serving a MN when the MN is frequently switching points of		these prefixes. There might be several P-MAARs serving an MN in
	attachment while maintaining long-lasting flows.		cases when the MN is frequently switching points of attachment
			while maintaining long-lasting flows.
	S-MAAR (Serving MAAR). The MAAR which the MN is currently attached		S-MAAR (Serving MAAR):
	to. Depending on the prefix, it plays the role of Access-DPN,		The MAAR to which the MN is currently attached. Depending on the
	Home-DPA and Access-CPN.		prefix, it plays the role of Access-DPN, Home-DPA, and Access-CPN.
	Anchoring MAAR. A MAAR anchoring an IPv6 prefix used by an MN.		Anchoring MAAR:
			A MAAR anchoring an IPv6 prefix used by an MN.
	DLIF (Distributed Logical Interface). It is a logical interface at		DLIF (Distributed Logical Interface):
	the IP stack of the MAAR. For each active prefix used by the MN,		It is a logical interface at the IP stack of the MAAR. For each
	the S-MAAR has a DLIF configured (associated to each MAAR still		active prefix used by the MN, the S-MAAR has a DLIF configured
	anchoring flows). In this way, an S-MAAR exposes itself towards		(associated with each MAAR still anchoring flows). In this way,
	each MN as multiple routers, one as itself and one per P-MAAR.		an S-MAAR exposes itself towards each MN as multiple routers, one
			as itself and one per P-MAAR.
	3. PMIPv6 DMM extensions		3. PMIPv6 DMM Extensions
	The solution consists of de-coupling the entities that participate in		The solution consists of decoupling the entities that participate in
	the data and the control planes: the data plane becomes distributed		the data and the control planes: the data plane becomes distributed
	and managed by the MAARs near the edge of the network, while the		and managed by the MAARs near the edge of the network, while the
	control plane, besides those on the MAARs, relies on a central entity		control plane, besides those on the MAARs, relies on a central entity
	called Central Mobility Database (CMD). In the proposed		called the Central Mobility Database (CMD). In the proposed
	architecture, the hierarchy present in PMIPv6 between LMA and MAG is		architecture, the hierarchy present in PMIPv6 between LMA and MAG is
	preserved, but with the following substantial variations:		preserved but with the following substantial variations:
	o The LMA is relieved from the data forwarding role, only the		* The LMA is discharged from the data forwarding role; only the
	Binding Cache and its management operations are maintained. Hence		Binding Cache and its management operations are maintained.
	the LMA is renamed into CMD, which is therefore a Home-CPA. Also,		Hence, the LMA is renamed as "CMD", which is therefore a Home-CPA.
	the CMD is able to send and parse both PBU and PBA messages.		Also, the CMD is able to send and parse both PBU and PBA messages.
	o The MAG is enriched with the LMA functionalities, hence the name		* The MAG is enriched with the LMA functionalities, hence the name
	Mobility Anchor and Access Router (MAAR). It maintains a local		Mobility Anchor and Access Router (MAAR). It maintains a local
	Binding Cache for the MNs that are attached to it and it is able		Binding Cache for the MNs that are attached to it, and it is able
	to send and parse PBU and PBA messages.		to send and parse PBU and PBA messages.
	o The binding cache will be extended to include information		* The Binding Cache will be extended to include information
	regarding P-MAARs where the mobile node was anchored and still		regarding P-MAARs where the MN was anchored and still retains
	retains active data sessions.		active data sessions.
	o Each MAAR has a unique set of global prefixes (which are		* Each MAAR has a unique set of global prefixes (which are
	configurable), that can be allocated by the MAAR to the MNs, but		configurable) that can be allocated by the MAAR to the MNs but
	must be exclusive to that MAAR, i.e. no other MAAR can allocate		must be exclusive to that MAAR, i.e., no other MAAR can allocate
	the same prefixes.		the same prefixes.
	The MAARs leverage the CMD to access and update information related		The MAARs leverage the CMD to access and update information related
	to the MNs, stored as mobility sessions; hence, a centralized node		to the MNs, which is stored as mobility sessions; hence, a
	maintains a global view of the network status. The CMD is queried		centralized node maintains a global view of the network status. The
	whenever a MN is detected to join/leave the mobility domain. It		CMD is queried whenever an MN is detected joining/leaving the
	might be a fresh attachment, a detachment or a handover, but as MAARs		mobility domain. It might be a fresh attachment, a detachment, or a
	are not aware of past information related to a mobility session, they		handover, but as MAARs are not aware of past information related to a
	contact the CMD to retrieve the data of interest and eventually take		mobility session, they contact the CMD to retrieve the data of
	the appropriate action. The procedure adopted for the query and the		interest and eventually take the appropriate action. The procedure
	message exchange sequence might vary to optimize the update latency		adopted for the query and the message exchange sequence might vary to
	and/or the signaling overhead. Here is presented one method for the		optimize the update latency and/or the signaling overhead. Here, one
	initial registration, and three different approaches for updating the		method for the initial registration and three different approaches
	mobility sessions using PBUs and PBAs. Each approach assigns a		for updating the mobility sessions using PBUs and PBAs are presented.
	different role to the CMD:		Each approach assigns a different role to the CMD:
	o The CMD is a PBU/PBA relay;		* The CMD is a PBU/PBA relay;
	o The CMD is only a MAAR locator;		* The CMD is only a MAAR locator;
	o The CMD is a PBU/PBA proxy.		* The CMD is a PBU/PBA proxy.
	The solution described in this document allows performing per-prefix		The solution described in this document allows per-prefix anchoring
	anchoring decisions, to support e.g., some flows to be anchored at a		decisions -- for example, to support the anchoring of some flows at a
	central Home-DPA (like a traditional LMA) or to enable an application		central Home-DPA (like a traditional LMA) or to enable an application
	to switch to the locally anchored prefix to gain route optimization,		to switch to the locally anchored prefix to gain route optimization,
	as indicated in [RFC8563]. This type of per-prefix treatment would		as indicated in [RFC8563]. This type of per-prefix treatment would
	potentially require additional extensions to the MAARs and signaling		potentially require additional extensions to the MAARs and signaling
	between the MAARs and the MNs to convey the per-flow anchor		between the MAARs and the MNs to convey the per-flow anchor
	preference (central, distributed), which are not covered in this		preference (central, distributed), which are not covered in this
	document.		document.
	Note that a MN may move across different MAARs, which might result in		Note that an MN may move across different MAARs, which might result
	several P-MAARs existing at a given moment of time, each of them		in several P-MAARs existing at a given moment of time, each of them
	anchoring a different prefix used by the MN.		anchoring a different prefix used by the MN.
	3.1. Initial registration		3.1. Initial Registration
	Initial registration is performed when an MN attaches to a network		Initial registration is performed when an MN attaches to a network
	for the first time (rather than attaching to a new network after		for the first time (rather than attaching to a new network after
	moving from a previous one).		moving from a previous one).
	In this description (shown in Figure 1), it is assumed that:		In this description (shown in Figure 1), it is assumed that:
	1. The MN is attaching to MAAR1.		1. The MN is attaching to MAAR1.
	2. The MN is authorized to attach to the network.		2. The MN is authorized to attach to the network.
	Upon MN attachment, the following operations take place:		Upon MN attachment, the following operations take place:
	1. MAAR1 assigns a global IPv6 prefix from its own prefix pool to		1. MAAR1 assigns a global IPv6 prefix from its own prefix pool to
	the MN (Pref1). It also stores this prefix (Pref1) in the		the MN (Pref1). It also stores this prefix (Pref1) in the
	locally allocated temporary Binding Cache Entry (BCE).		locally allocated temporary BCE.
	2. MAAR1 sends a PBU [RFC5213] with Pref1 and the MN's MN-ID to the		2. MAAR1 sends a PBU [RFC5213] with Pref1 and the MN's MN-ID to the
	CMD.		CMD.
	3. Since this is an initial registration, the CMD stores a BCE		3. Since this is an initial registration, the CMD stores a BCE
	containing as primary fields the MN-ID, Pref1 and MAAR1's address		containing the MN-ID, Pref1, and MAAR1's address (as a Proxy-CoA)
	as a Proxy-CoA.		as the primary fields.
	4. The CMD replies with a PBA with the usual options defined in		4. The CMD replies with a PBA with the usual options defined in
	PMIPv6 [RFC5213], meaning that the MN's registration is fresh and		PMIPv6 [RFC5213], meaning that the MN's registration is fresh and
	no past status is available.		no past status is available.
	5. MAAR1 stores the BCE described in (1) and unicasts a Router		5. MAAR1 stores the BCE described in (1) and unicasts a Router
	Advertisement (RA) to the MN with Pref1.		Advertisement (RA) to the MN with Pref1.
	6. The MN uses Pref1 to configure an IPv6 address (IP1) (e.g., with		6. The MN uses Pref1 to configure an IPv6 address (IP1) (e.g., with
	stateless auto-configuration, SLAAC).		stateless address autoconfiguration (SLAAC)).
	Note that:		Note that:
	1. Alternative IPv6 auto-configuration mechanisms can also be used,		1. Alternative IPv6 autoconfiguration mechanisms can also be used,
	though this document describes the SLAAC-based one.		though this document describes the SLAAC-based one.
	2. IP1 is routable at MAAR1, in the sense that it is on the path of		2. IP1 is routable at MAAR1 in the sense that it is on the path of
	packets addressed to the MN.		packets addressed to the MN.
	3. MAAR1 acts as a plain router for packets destined to the MN, as		3. MAAR1 acts as a plain router for packets destined to the MN as no
	no encapsulation nor special handling takes place.		encapsulation or special handling takes place.
	In the diagram shown in Figure 1 (and subsequent diagrams), the flow		In the diagram shown in Figure 1 (and subsequent diagrams), the flow
	of packets is presented using '*'.		of packets is presented using '*'.
	+-----+ +---+ +--+		+-----+ +---+ +--+
	|MAAR1| |CMD| |CN|		|MAAR1| |CMD| |CN|
	+-----+ +---+ +*-+		+-----+ +---+ +*-+
	| | *		| | *
	MN | * +---+		MN | * +---+
	attach. | ***** _|CMD|_		attach. | ***** _|CMD|_
	skipping to change at page 8, line 40 ¶		skipping to change at line 376 ¶
	| BCE | * | | | | |		| BCE | * | | | | |
	| creation |MAAR1+------+MAAR2+-----+MAAR3|		| creation |MAAR1+------+MAAR2+-----+MAAR3|
	|<-- PBA ---| | * | | | | |		|<-- PBA ---| | * | | | | |
	local BCE | +---*-+ +-----+ +-----+		local BCE | +---*-+ +-----+ +-----+
	finalized | *		finalized | *
	| | Pref1 *		| | Pref1 *
	| | +*-+		| | +*-+
	| | |MN|		| | |MN|
	| | +--+		| | +--+
	Operations sequence Packets flow		Operations sequence Packet flow
	Figure 1: First attachment to the network		Figure 1: First Attachment to the Network
	Note that the registration process does not change regardless of the		Note that the registration process does not change regardless of the
	CMD's modes (relay, locator or proxy) described next. The procedure		CMD's modes (relay, locator, or proxy) described in the following
	is depicted in Figure 1.		sections. The procedure is depicted in Figure 1.
	3.2. The CMD as PBU/PBA relay		3.2. The CMD as PBU/PBA Relay
	Upon MN mobility, if the CMD behaves as PBU/PBA relay, the following		Upon MN mobility, if the CMD behaves as a PBU/PBA relay, the
	operations take place:		following operations take place:
	1. When the MN moves from its current point of attachment and		1. When the MN moves from its current point of attachment and
	attaches to MAAR2 (now the S-MAAR), MAAR2 reserves an IPv6 prefix		attaches to MAAR2 (now the S-MAAR), MAAR2 reserves an IPv6 prefix
	(Pref2), it stores a temporary BCE, and it sends a PBU to the CMD		(Pref2), stores a temporary BCE, and sends a PBU to the CMD for
	for registration.		registration.
	2. Upon PBU reception and BC lookup, the CMD retrieves an already		2. Upon PBU reception and BC lookup, the CMD retrieves an already
	existing entry for the MN, binding the MN-ID to its former		existing entry for the MN and binds the MN-ID to its former
	location; thus, the CMD forwards the PBU to the MAAR indicated as		location; thus, the CMD forwards the PBU to the MAAR indicated as
	Proxy CoA (MAAR1), including a new mobility option to communicate		Proxy-CoA (MAAR1) and includes a new mobility option to
	the S-MAAR's global address to MAAR1, defined as Serving MAAR		communicate the S-MAAR's global address to MAAR1 (defined as the
	Option in Section 4.6. The CMD updates the P-CoA field in the		Serving MAAR option in Section 4.6). The CMD updates the P-CoA
	BCE related to the MN with the S-MAAR's address.		field in the BCE related to the MN with the S-MAAR's address.
	3. Upon PBU reception, MAAR1 can install a tunnel on its side		3. Upon PBU reception, MAAR1 can install a tunnel on its side
	towards MAAR2 and the related routes for Pref1. Then MAAR1		towards MAAR2 and the related routes for Pref1. Then MAAR1
	replies to the CMD with a PBA (including the option mentioned		replies to the CMD with a PBA (including the option mentioned
	before) to ensure that the new location has successfully changed,		before) to ensure that the new location has successfully changed.
	containing the prefix anchored at MAAR1 in the Home Network		The PBA contains the prefix anchored at MAAR1 in the Home Network
	Prefix option.		Prefix option.
	4. The CMD, after receiving the PBA, updates the BCE populating an		4. The CMD, after receiving the PBA, updates the BCE and populates
	instance of the P-MAAR list. The P-MAAR list is an additional		an instance of the P-MAAR list. The P-MAAR list is an additional
	field on the BCE that contains an element for each P-MAAR		field on the BCE that contains an element for each P-MAAR
	involved in the MN's mobility session. The list element contains		involved in the MN's mobility session. The list element contains
	the P-MAAR's global address and the prefix it has delegated.		the P-MAAR's global address and the prefix it has delegated.
	Also, the CMD sends a PBA to the new S-MAAR, containing the		Also, the CMD sends a PBA to the new S-MAAR, which contains the
	previous Proxy-CoA and the prefix anchored to it embedded into a		previous Proxy-CoA and the prefix anchored to it embedded into a
	new mobility option called Previous MAAR Option (defined in		new mobility option called the Previous MAAR option (defined in
	Section 4.5), so that, upon PBA arrival, a bi-directional tunnel		Section 4.5). Then, upon PBA arrival, a bidirectional tunnel can
	can be established between the two MAARs and new routes are set		be established between the two MAARs, and new routes are set
	appropriately to recover the IP flow(s) carrying Pref1.		appropriately to recover the IP flow(s) carrying Pref1.
	5. Now packets destined to Pref1 are first received by MAAR1,		5. Now, packets destined for Pref1 are first received by MAAR1,
	encapsulated into the tunnel and forwarded to MAAR2, which		encapsulated into the tunnel, and forwarded to MAAR2, which
	finally delivers them to their destination. In uplink, when the		finally delivers them to their destination. In the uplink, when
	MN transmits packets using Pref1 as source address, they are sent		the MN transmits packets using Pref1 as a source address, they
	to MAAR2, as it is MN's new default gateway, then tunneled to		are sent to MAAR2 (as it is the MN's new default gateway) and
	MAAR1 which routes them towards the next hop to destination.		then tunneled to MAAR1, which routes them towards the next hop to
	Conversely, packets carrying Pref2 are routed by MAAR2 without		the destination. Conversely, packets carrying Pref2 are routed
	any special packet handling both for uplink and downlink.		by MAAR2 without any special packet handling both for the uplink
			and downlink.
	+-----+ +---+ +-----+ +--+ +--+		+-----+ +---+ +-----+ +--+ +--+
	|MAAR1| |CMD| |MAAR2| |CN| |CN|		|MAAR1| |CMD| |MAAR2| |CN| |CN|
	+-----+ +---+ +-----+ +*-+ +*-+		+-----+ +---+ +-----+ +*-+ +*-+
	| | | * *		| | | * *
	| | MN * +---+ *		| | MN * +---+ *
	| | attach. ***** _|CMD|_ *		| | attach. ***** _|CMD|_ *
	| | det. flow1 * / +-+-+ \ *flow2		| | det. flow1 * / +-+-+ \ *flow2
	| |<-- PBU ---| * / | \ *		| |<-- PBU ---| * / | \ *
	| BCE | * / | *******		| BCE | * / | *******
	skipping to change at page 10, line 26 ¶		skipping to change at line 452 ¶
	|<-- PBU*---| | | * | | *| | |		|<-- PBU*---| | | * | | *| | |
	route | | |MAAR1|______|MAAR2+-----+MAAR3|		route | | |MAAR1|______|MAAR2+-----+MAAR3|
	update | | | **(______)** *| | |		update | | | **(______)** *| | |
	|--- PBA*-->| | +-----+ +-*--*+ +-----+		|--- PBA*-->| | +-----+ +-*--*+ +-----+
	| BCE | * *		| BCE | * *
	| update | Pref1 * *Pref2		| update | Pref1 * *Pref2
	| |--- PBA*-->| +*--*+		| |--- PBA*-->| +*--*+
	| | route ---move-->|*MN*|		| | route ---move-->|*MN*|
	| | update +----+		| | update +----+
	Operations sequence Data Packets flow		Operations sequence Data Packet flow
	PBU/PBA Messages with * contain		PBU/PBA messages with * contain
	a new mobility option		a new mobility option
	Figure 2: Scenario after a handover, CMD as relay		Figure 2: Scenario after a Handover, CMD as Relay
	For MN's next movements the process is repeated except the number of		For MN's next movements, the process is repeated, but the number of
	P-MAARs involved increases (accordingly to the number of prefixes		P-MAARs involved increases (according to the number of prefixes that
	that the MN wishes to maintain). Indeed, once the CMD receives the		the MN wishes to maintain). Indeed, once the CMD receives the first
	first PBU from the new S-MAAR, it forwards copies of the PBU to all		PBU from the new S-MAAR, it forwards copies of the PBU to all the
	the P-MAARs indicated in the BCE, namely the one registered as		P-MAARs indicated in the BCE, namely the P-MAAR registered as the
	current P-CoA (i.e., the MAAR prior to handover) plus the ones in the		current P-CoA (i.e., the MAAR prior to handover) plus the ones in the
	P-MAARs list. They reply with a PBA to the CMD, which aggregates		P-MAAR list. Those P-MAARs reply with a PBA to the CMD, which
	them into a single one to notify the S-MAAR, that finally can		aggregates all of the PBAs into one PBA to notify the S-MAAR, which
	establish the tunnels with the P-MAARs.		finally can establish the tunnels with the P-MAARs.
	It should be noted that this design separates the mobility management		It should be noted that this design separates the mobility management
	at the prefix granularity, and it can be tuned in order to erase old		at the prefix granularity, and it can be tuned in order to erase old
	mobility sessions when not required, while the MN is reachable		mobility sessions when not required, while the MN is reachable
	through the latest prefix acquired. Moreover, the latency associated		through the latest prefix acquired. Moreover, the latency associated
	to the mobility update is bound to the PBA sent by the furthest		with the mobility update is bound to the PBA sent by the furthest
	P-MAAR, in terms of RTT, that takes the longest time to reach the		P-MAAR, in terms of RTT, that takes the longest time to reach the
	CMD. The drawback can be mitigated introducing a timeout at the CMD,		CMD. The drawback can be mitigated by introducing a timeout at the
	by which, after its expiration, all the PBAs so far collected are		CMD, by which, after its expiration, all the PBAs so far collected
	transmitted, and the remaining are sent later upon their arrival.		are transmitted, and the remaining are sent later upon their arrival.
	Note that in this case the S-MAAR might receive multiple PBAs from		Note that, in this case, the S-MAAR might receive multiple PBAs from
	the CMD in response to a PBU. The CMD SHOULD follow the		the CMD in response to a PBU. The CMD SHOULD follow the
	retransmissions and rate limiting considerations described in		retransmissions and rate-limiting considerations described in
	Section 3.6, especially when aggregating and relaying PBAs.		Section 3.6, especially when aggregating and relaying PBAs.
	When there are multiple previous MAARs, e.g., k MAARs, a single PBU		When there are multiple P-MAARs, e.g., k MAARs, a single PBU received
	received by the CMD triggers k outgoing packets from a single		by the CMD triggers k outgoing packets from a single incoming packet.
	incoming packet. This may lead to packet bursts originated from the		This may lead to packet bursts originating from the CMD, albeit to
	CMD, albeit to different targets. Pacing mechanisms MUST be		different targets. Pacing mechanisms MUST be introduced to avoid
	introduced to avoid bursts on the outgoing link.		bursts on the outgoing link.
	3.3. The CMD as MAAR locator		3.3. The CMD as MAAR Locator
	The handover latency experienced in the approach shown before can be		The handover latency experienced in the approach shown before can be
	reduced if the P-MAARs are allowed to signal directly their		reduced if the P-MAARs are allowed to directly signal their
	information to the new S-MAAR. This procedure reflects what was		information to the new S-MAAR. This procedure reflects what was
	described in Section 3.2 up to the moment the P-MAAR receives the PBU		described in Section 3.2 up to the moment the P-MAAR receives the PBU
	with the S-MAAR option. At that point a P-MAAR is aware of the new		with the Serving MAAR option. At that point, a P-MAAR is aware of
	MN's location (because of the S-MAAR's address in the S-MAAR option),		the new MN's location (because of the S-MAAR's address in the Serving
	and, besides sending a PBA to the CMD, it also sends a PBA to the		MAAR option), and, besides sending a PBA to the CMD, it also sends a
	S-MAAR including the prefix it is anchoring. This latter PBA does		PBA to the S-MAAR, including the prefix it is anchoring. This latter
	not need to include new options, as the prefix is embedded in the HNP		PBA does not need to include new options, as the prefix is embedded
	option and the P-MAAR's address is taken from the message's source		in the Home Network Prefix (HNP) option and the P-MAAR's address is
	address. The CMD is relieved from forwarding the PBA to the S-MAAR,		taken from the message's source address. The CMD is released from
	as the latter receives a copy directly from the P-MAAR with the		forwarding the PBA to the S-MAAR as the latter receives a copy
	necessary information to build the tunnels and set the appropriate		directly from the P-MAAR with the necessary information to build the
	routes. Figure 3 illustrates the new message sequence, while the		tunnels and set the appropriate routes. Figure 3 illustrates the new
	data forwarding is unaltered.		message sequence. The data forwarding is unaltered.
	+-----+ +---+ +-----+ +--+ +--+		+-----+ +---+ +-----+ +--+ +--+
	|MAAR1| |CMD| |MAAR2| |CN| |CN|		|MAAR1| |CMD| |MAAR2| |CN| |CN|
	+-----+ +---+ +-----+ +*-+ +*-+		+-----+ +---+ +-----+ +*-+ +*-+
	| | | * *		| | | * *
	| | MN * +---+ *		| | MN * +---+ *
	| | attach. ***** _|CMD|_ *		| | attach. ***** _|CMD|_ *
	| | det. flow1 * / +-+-+ \ *flow2		| | det. flow1 * / +-+-+ \ *flow2
	| |<-- PBU ---| * / | \ *		| |<-- PBU ---| * / | \ *
	| BCE | * / | *******		| BCE | * / | *******
	skipping to change at page 12, line 26 ¶		skipping to change at line 527 ¶
	|<-- PBU*---| | | * | | *| | |		|<-- PBU*---| | | * | | *| | |
	route | | |MAAR1|______|MAAR2+-----+MAAR3|		route | | |MAAR1|______|MAAR2+-----+MAAR3|
	update | | | **(______)** *| | |		update | | | **(______)** *| | |
	|--------- PBA -------->| +-----+ +-*--*+ +-----+		|--------- PBA -------->| +-----+ +-*--*+ +-----+
	|--- PBA*-->| route * *		|--- PBA*-->| route * *
	| BCE update Pref1 * *Pref2		| BCE update Pref1 * *Pref2
	| update | +*--*+		| update | +*--*+
	| | | ---move-->|*MN*|		| | | ---move-->|*MN*|
	| | | +----+		| | | +----+
	Operations sequence Data Packets flow		Operations sequence Data Packet flow
	PBU/PBA Messages with * contain		PBU/PBA messages with * contain
	a new mobility option		a new mobility option
	Figure 3: Scenario after a handover, CMD as locator		Figure 3: Scenario after a Handover, CMD as Locator
	3.4. The CMD as MAAR proxy		3.4. The CMD as PBU/PBA Proxy
	A further enhancement of previous solutions can be achieved when the		A further enhancement of previous solutions can be achieved when the
	CMD sends the PBA to the new S-MAAR before notifying the P-MAARs of		CMD sends the PBA to the new S-MAAR before notifying the P-MAARs of
	the location change. Indeed, when the CMD receives the PBU for the		the location change. Indeed, when the CMD receives the PBU for the
	new registration, it is already in possession of all the information		new registration, it is already in possession of all the information
	that the new S-MAAR requires to set up the tunnels and the routes.		that the new S-MAAR requires to set up the tunnels and the routes.
	Thus the PBA is sent to the S-MAAR immediately after a PBU is		Thus, the PBA is sent to the S-MAAR immediately after a PBU is
	received, including also in this case the P-MAAR option. In		received, including the Previous MAAR option in this case. In
	parallel, a PBU is sent by the CMD to the P-MAARs containing the		parallel, a PBU is sent by the CMD to the P-MAARs containing the
	S-MAAR option, to notify them about the new MN's location, so they		Serving MAAR option to notify them about the new MN's location so
	receive the information to establish the tunnels and routes on their		that they receive the information to establish the tunnels and routes
	side. When P-MAARs complete the update, they send a PBA to the CMD		on their side. When P-MAARs complete the update, they send a PBA to
	to indicate that the operation is concluded and the information is		the CMD to indicate that the operation has concluded and the
	updated in all network nodes. This procedure is obtained from the		information is updated in all network nodes. This procedure is
	first one re-arranging the order of the messages, but the parameters		obtained from the first procedure rearranging the order of the
	communicated are the same. This scheme is depicted in Figure 4,		messages, but the parameters communicated are the same. This scheme
	where, again, the data forwarding is kept untouched.		is depicted in Figure 4, where, again, the data forwarding is kept
			untouched.
	+-----+ +---+ +-----+ +--+ +--+		+-----+ +---+ +-----+ +--+ +--+
	|MAAR1| |CMD| |MAAR2| |CN| |CN|		|MAAR1| |CMD| |MAAR2| |CN| |CN|
	+-----+ +---+ +-----+ +*-+ +*-+		+-----+ +---+ +-----+ +*-+ +*-+
	| | | * *		| | | * *
	| | MN * +---+ *		| | MN * +---+ *
	| | attach. ***** _|CMD|_ *		| | attach. ***** _|CMD|_ *
	| | det. flow1 * / +-+-+ \ *flow2		| | det. flow1 * / +-+-+ \ *flow2
	| |<-- PBU ---| * / | \ *		| |<-- PBU ---| * / | \ *
	| BCE | * / | *******		| BCE | * / | *******
	skipping to change at page 13, line 26 ¶		skipping to change at line 574 ¶
	|<-- PBU*---x--- PBA*-->| | * | | *| | |		|<-- PBU*---x--- PBA*-->| | * | | *| | |
	route | route |MAAR1|______|MAAR2+-----+MAAR3|		route | route |MAAR1|______|MAAR2+-----+MAAR3|
	update | update | **(______)** *| | |		update | update | **(______)** *| | |
	|--- PBA*-->| | +-----+ +-*--*+ +-----+		|--- PBA*-->| | +-----+ +-*--*+ +-----+
	| BCE | * *		| BCE | * *
	| update | Pref1 * *Pref2		| update | Pref1 * *Pref2
	| | | +*--*+		| | | +*--*+
	| | | ---move-->|*MN*|		| | | ---move-->|*MN*|
	| | | +----+		| | | +----+
	Operations sequence Data Packets flow		Operations sequence Data Packet flow
	PBU/PBA Messages with * contain		PBU/PBA messages with * contain
	a new mobility option		a new mobility option
	Figure 4: Scenario after a handover, CMD as proxy		Figure 4: Scenario after a Handover, CMD as Proxy
	3.5. De-registration		3.5. De-registration
	The de-registration mechanism devised for PMIPv6 cannot be used as-is		The de-registration mechanism devised for PMIPv6 cannot be used as is
	in this solution. The reason for this is that each MAAR handles an		in this solution because each MAAR handles an independent mobility
	independent mobility session (i.e., a single or a set of prefixes)		session (i.e., a single prefix or a set of prefixes) for a given MN,
	for a given MN, whereas the aggregated session is stored at the CMD.		whereas the aggregated session is stored at the CMD. Indeed, if a
	Indeed, if a previous MAAR initiates a de-registration procedure,		P-MAAR initiates a de-registration procedure because the MN is no
	because the MN is no longer present on the MAAR's access link, it		longer present on the MAAR's access link, it removes the routing
	removes the routing state for that (those) prefix(es), that would be		state for the prefix(es), that would be deleted by the CMD as well,
	deleted by the CMD as well, hence defeating any prefix continuity		hence defeating any prefix continuity attempt. The simplest approach
	attempt. The simplest approach to overcome this limitation is to		to overcome this limitation is to deny a P-MAAR to de-register a
	deny a P-MAAR to de-register a prefix, that is, allowing only a		prefix, that is, allowing only an S-MAAR to de-register the whole MN
	serving MAAR to de-register the whole MN session. This can be		session. This can be achieved by first removing any L2 detachment
	achieved by first removing any layer-2 detachment event, so that de-		event so that de-registration is triggered only when the binding
	registration is triggered only when the binding lifetime expires,		lifetime expires, hence providing a guard interval for the MN to
	hence providing a guard interval for the MN to connect to a new MAAR.		connect to a new MAAR. Then, a change in the MAAR operations is
	Then, a change in the MAAR operations is required, and at this stage		required, and at this stage, two possible solutions can be deployed:
	two possible solutions can be deployed:
	o A previous MAAR stops the BCE timer upon receiving a PBU from the		* A P-MAAR stops the BCE timer upon receiving a PBU from the CMD
	CMD containing a "Serving MAAR" option. In this way only the		containing a "Serving MAAR" option. In this way, only the S-MAAR
	Serving MAAR is allowed to de-register the mobility session,		is allowed to de-register the mobility session, arguing that the
	arguing that the MN definitely left the domain.		MN definitely left the domain.
	o Previous MAARs can, upon BCE expiry, send de-registration messages		* P-MAARs can, upon BCE expiry, send de-registration messages to the
	to the CMD, which, instead of acknowledging the message with a 0		CMD, which, instead of acknowledging the message with a 0
	lifetime, sends back a PBA with a non-zero lifetime, hence re-		lifetime, sends back a PBA with a non-zero lifetime, hence
	newing the session, if the MN is still connected to the domain.		renewing the session if the MN is still connected to the domain.
	3.6. Retransmissions and Rate Limiting		3.6. Retransmissions and Rate Limiting
	When sending PBUs, the node sending them (the CMD or S-MAAR) SHOULD		The node sending PBUs (the CMD or S-MAAR) SHOULD make use of the
	make use of the timeout also to deal with missing PBAs (to retransmit		timeout to also deal with missing PBAs (to retransmit PBUs). The
	PBUs). The INITIAL_BINDACK_TIMEOUT [RFC6275] SHOULD be used for		INITIAL_BINDACK_TIMEOUT [RFC6275] SHOULD be used for configuring the
	configuring the retransmission timer. The retransmissions by the		retransmission timer. The retransmissions by the node MUST use an
	node MUST use an exponential backoff process in which the timeout		exponential backoff process in which the timeout period is doubled
	period is doubled upon each retransmission, until either the node		upon each retransmission until either the node receives a response or
	receives a response or the timeout period reaches the value		the timeout period reaches the value MAX_BINDACK_TIMEOUT [RFC6275].
	MAX_BINDACK_TIMEOUT [RFC6275]. The node MAY continue to send these		The node MAY continue to send these messages at this slower rate
	messages at this slower rate indefinitely. The node MUST NOT send		indefinitely. The node MUST NOT send PBU messages to a particular
	PBU messages to a particular node more than MAX_UPDATE_RATE times		node more than MAX_UPDATE_RATE times within a second [RFC6275].
	within a second [RFC6275].
	3.7. The Distributed Logical Interface (DLIF) concept		3.7. The Distributed Logical Interface (DLIF) Concept
	One of the main challenges of a network-based DMM solution is how to		One of the main challenges of a network-based DMM solution is how to
	allow a mobile node to simultaneously send/receive traffic which is		allow a MN to simultaneously send/receive traffic that is anchored at
	anchored at different MAARs, and how to influence the mobile node's		different MAARs and how to influence the MN's selection process of
	selection process of its source IPv6 address for a new flow, without		its source IPv6 address for a new flow without requiring special
	requiring special support from the mobile node's IP stack. This		support from the MN's IP stack. This document defines the DLIF,
	document defines the Distributed Logical Interface (DLIF), which is a		which is a software construct in the MAAR that can easily hide the
	software construct in the MAAR that allows to easily hide the change		change of associated anchors from the MN.
	of associated anchors from the mobile node.
	+---------------------------------------------------+		+---------------------------------------------------+
	( Operator's )		( Operator's )
	( core )		( core )
	+---------------------------------------------------+		+---------------------------------------------------+
	| |		| |
	+---------------+ tunnel +---------------+		+---------------+ tunnel +---------------+
	| IP stack |===============| IP stack |		| IP stack |===============| IP stack |
	+---------------+ +-------+-------+		+---------------+ +-------+-------+
	| mn1mar1 |--+ (DLIFs) +--|mn1mar1|mn1mar2|--+		| mn1mar1 |--+ (DLIFs) +--|mn1mar1|mn1mar2|--+
	skipping to change at page 15, line 28 ¶		skipping to change at line 654 ¶
	x x		x x
	x x		x x
	prefA::/64 x x prefB::/64		prefA::/64 x x prefB::/64
	(AdvPrefLft=0) x x		(AdvPrefLft=0) x x
	(o)		(o)
	|		|
	+-----+		+-----+
	prefA::MN1 | MN1 | prefB::MN1		prefA::MN1 | MN1 | prefB::MN1
	(deprecated) +-----+		(deprecated) +-----+
	Figure 5: DLIF: exposing multiple routers (one per P-MAAR)		Figure 5: DLIF: Exposing Multiple Routers (One per P-MAAR)
	The basic idea of the DLIF concept is the following: each serving		The basic idea of the DLIF concept is the following: each S-MAAR
	MAAR exposes itself towards a given MN as multiple routers, one per		exposes itself to a given MN as multiple routers, one per P-MAAR
	P-MAAR associated to the MN. Let's consider the example shown in		associated with the MN. Let's consider the example shown in
	Figure 5, MN1 initially attaches to MAAR1, configuring an IPv6		Figure 5: MN1 initially attaches to MAAR1, configuring an IPv6
	address (prefA::MN1) from a prefix locally anchored at MAAR1		address (prefA::MN1) from a prefix locally anchored at MAAR1
	(prefA::/64). At this stage, MAAR1 plays both the role of anchoring		(prefA::/64). At this stage, MAAR1 plays the role of both anchoring
	and serving MAAR, and also behaves as a plain IPv6 access router.		and serving MAAR and also behaves as a plain IPv6 access router.
	MAAR1 creates a distributed logical interface to communicate (point-		MAAR1 creates a DLIF to communicate (through a point-to-point link)
	to-point link) with MN1, exposing itself as a (logical) router with a		with MN1, exposing itself as a (logical) router with specific MAC and
	specific MAC and IPv6 addresses (e.g., prefA::MAAR1/64 and		IPv6 addresses (e.g., prefA::MAAR1/64 and fe80::MAAR1/64) using the
	fe80::MAAR1/64) using the DLIF mn1mar1. As explained below, these		DLIF mn1mar1. As explained below, these addresses represent the
	addresses represent the "logical" identity of MAAR1 towards MN1, and		"logical" identity of MAAR1 for MN1 and will "follow" the MN while
	will "follow" the mobile node while roaming within the domain (note		roaming within the domain (note that the place where all this
	that the place where all this information is maintained and updated		information is maintained and updated is out of scope of this
	is out-of-scope of this draft; potential examples are to keep it on		document; potential examples are to keep it on the home subscriber
	the home subscriber server -- HSS -- or the user's profile).		server -- HSS -- or the user's profile).
	If MN1 moves and attaches to a different MAAR of the domain (MAAR2 in		If MN1 moves and attaches to a different MAAR of the domain (MAAR2 in
	the example of Figure 5), this MAAR will create a new logical		the example of Figure 5), this MAAR will create a new logical
	interface (mn1mar2) to expose itself towards MN1, providing it with a		interface (mn1mar2) to expose itself to MN1, providing it with a
	locally anchored prefix (prefB::/64). In this case, since the MN1		locally anchored prefix (prefB::/64). In this case, since the MN1
	has another active IPv6 address anchored at a MAAR1, MAAR2 also needs		has another active IPv6 address anchored at MAAR1, MAAR2 also needs
	to create an additional logical interface configured to resemble the		to create an additional logical interface configured to resemble the
	one used by MAAR1 to communicate with MN1. In this example, there is		one used by MAAR1 to communicate with MN1. In this example, MAAR1 is
	only one P-MAAR (in addition to MAAR2, which is the serving one):		the only P-MAAR (MAAR2 is the same as S-MAAR), so only the logical
	MAAR1, so only the logical interface mn1mar1 is created, but the same		interface mn1mar1 is created. However, the same process would be
	process would be repeated in case there were more P-MAARs involved.		repeated if more P-MAARs were involved. In order to keep the prefix
	In order to maintain the prefix anchored at MAAR1 reachable, a tunnel		anchored at MAAR1 reachable, a tunnel between MAAR1 and MAAR2 is
	between MAAR1 and MAAR2 is established and the routing is modified		established and the routing is modified accordingly. The PBU/PBA
	accordingly. The PBU/PBA signaling is used to set-up the bi-		signaling is used to set up the bidirectional tunnel between MAAR1
	directional tunnel between MAAR1 and MAAR2, and it might also be used		and MAAR2, and it might also be used to convey the information about
	to convey to MAAR2 the information about the prefix(es) anchored at		the prefix(es) anchored at MAAR1 and the addresses of the associated
	MAAR1 and about the addresses of the associated DLIF (i.e., mn1mar1).		DLIF (i.e., mn1mar1) to MAAR2.
	+------------------------------------------+ +----------------------+		+------------------------------------------+ +----------------------+
	| MAAR1 | | MAAR2 |		| MAAR1 | | MAAR2 |
	|+----------------------------------------+| |+--------------------+|		|+----------------------------------------+| |+--------------------+|
	||+------------------++------------------+|| ||+------------------+||		||+------------------++------------------+|| ||+------------------+||
	|||+-------++-------+||+-------++-------+||| |||+-------++-------+|||		|||+-------++-------+||+-------++-------+||| |||+-------++-------+|||
	||||mn3mar1||mn3mar2||||mn2mar1||mn2mar2|||| ||||mn1mar1||mn1mar2||||		||||mn3mar1||mn3mar2||||mn2mar1||mn2mar2|||| ||||mn1mar1||mn1mar2||||
	|||| LMAC1 || LMAC2 |||| LMAC3 || LMAC4 |||| |||| LMAC5 || LMAC6 ||||		|||| LMAC1 || LMAC2 |||| LMAC3 || LMAC4 |||| |||| LMAC5 || LMAC6 ||||
	|||+-------++-------+||+-------++-------+||| |||+-------++-------+|||		|||+-------++-------+||+-------++-------+||| |||+-------++-------+|||
	||| LIFs of MN3 || LIFs of MN2 ||| ||| LIFs of MN1 |||		||| LIFs of MN3 || LIFs of MN2 ||| ||| LIFs of MN1 |||
	skipping to change at page 16, line 36 ¶		skipping to change at line 711 ¶
	|+----------------------------------------+| |+--------------------+|		|+----------------------------------------+| |+--------------------+|
	+------------------------------------------+ +----------------------+		+------------------------------------------+ +----------------------+
	x x x		x x x
	x x x		x x x
	(o) (o) (o)		(o) (o) (o)
	| | |		| | |
	+--+--+ +--+--+ +--+--+		+--+--+ +--+--+ +--+--+
	| MN3 | | MN2 | | MN1 |		| MN3 | | MN2 | | MN1 |
	+-----+ +-----+ +-----+		+-----+ +-----+ +-----+
	Figure 6: Distributed Logical Interface concept		Figure 6: Distributed Logical Interface Concept
	Figure 6 shows the logical interface concept in more detail. The		Figure 6 shows the logical interface concept in more detail. The
	figure shows two MAARs and three MNs. MAAR1 is currently serving MN2		figure shows two MAARs and three MNs. MAAR1 is currently serving MN2
	and MN3, while MAAR2 is serving MN1. Note that a serving MAAR always		and MN3, while MAAR2 is serving MN1. Note that an S-MAAR always
	plays the role of anchoring MAAR for the attached (served) MNs. Each		plays the role of anchoring MAAR for the attached (served) MNs. Each
	MAAR has one single physical wireless interface as depicted in this		MAAR has one single physical wireless interface as depicted in this
	example.		example.
	As introduced before, each MN always "sees" multiple logical routers		As discussed before, each MN always "sees" multiple logical routers
	-- one per anchoring MAAR -- independently of its currently serving		-- one per anchoring MAAR -- independently of its currently S-MAAR.
	MAAR. From the point of view of the MN, these MAARs are portrayed as		From the point of view of the MN, these MAARs are portrayed as
	different routers, although the MN is physically attached to one		different routers, although the MN is physically attached to a single
	single interface. The way this is achieved is by the serving MAAR		interface. This is achieved by the S-MAAR configuring different
	configuring different logical interfaces. Focusing on MN1, it is		logical interfaces. MN1 is currently attached to MAAR2 (i.e., MAAR2
	currently attached to MAAR2 (i.e., MAAR2 is its serving MAAR) and,		is its S-MAAR) and, therefore, it has configured an IPv6 address from
	therefore, it has configured an IPv6 address from MAAR2's pool (e.g.,		MAAR2's pool (e.g., prefB::/64). MAAR2 has set up a logical
	prefB::/64). MAAR2 has set-up a logical interface (mn1mar2) on top		interface (mn1mar2) on top of its wireless physical interface (phy if
	of its wireless physical interface (phy if MAAR2) which is used to		MAAR2), which is used to serve MN1. This interface has a logical MAC
	serve MN1. This interface has a logical MAC address (LMAC6),		address (LMAC6) that is different from the hardware MAC address
	different from the hardware MAC address (MAC2) of the physical		(MAC2) of the physical interface of MAAR2. Over the mn1mar2
	interface of MAAR2. Over the mn1mar2 interface, MAAR2 advertises its		interface, MAAR2 advertises its locally anchored prefix prefB::/64.
	locally anchored prefix prefB::/64. Before attaching to MAAR2, MN1		Before attaching to MAAR2, MN1 was attached to MAAR1 and configured a
	was attached to MAAR1, configuring also an address locally anchored		locally anchored address at that MAAR, which is still being used by
	at that MAAR, which is still being used by MN1 in active		MN1 in active communications. MN1 keeps "seeing" an interface
	communications. MN1 keeps "seeing" an interface connecting to MAAR1,		connecting to MAAR1 as if it were directly connected to the two
	as if it were directly connected to the two MAARs. This is achieved		MAARs. This is achieved by the S-MAAR (MAAR2) configuring an
	by the serving MAAR (MAAR2) configuring an additional distributed		additional DLIF, mn1mar1, which behaves as the logical interface
	logical interface: mn1mar1, which behaves as the logical interface
	configured by MAAR1 when MN1 was attached to it. This means that		configured by MAAR1 when MN1 was attached to it. This means that
	both the MAC and IPv6 addresses configured on this logical interface		both the MAC and IPv6 addresses configured on this logical interface
	remain the same regardless of the physical MAAR which is serving the		remain the same regardless of the physical MAAR that is serving the
	MN. The information required by a serving MAAR to properly configure		MN. The information required by an S-MAAR to properly configure this
	this logical interfaces can be obtained in different ways: as part of		logical interfaces can be obtained in different ways: as part of the
	the information conveyed in the PBA, from an external database (e.g.,		information conveyed in the PBA, from an external database (e.g., the
	the HSS) or by other means. As shown in the figure, each MAAR may		HSS) or by other means. As shown in the figure, each MAAR may have
	have several logical interfaces associated to each attached MN,		several logical interfaces associated with each attached MN and
	having always at least one (since a serving MAAR is also an anchoring		always has at least one (since an S-MAAR is also an anchoring MAAR
	MAAR for the attached MN).		for the attached MN).
	In order to enforce the use of the prefix locally anchored at the		In order to enforce the use of the prefix locally anchored at the
	serving MAAR, the router advertisements sent over those logical		S-MAAR, the RAs sent over those logical interfaces playing the role
	interfaces playing the role of anchoring MAARs (different from the		of anchoring MAARs (different from the serving one) include a zero
	serving one) include a zero preferred prefix lifetime (and a non-zero		preferred prefix lifetime (and a non-zero valid prefix lifetime, so
	valid prefix lifetime, so the prefix remains valid, while being		the prefix remains valid while being deprecated). The goal is to
	deprecated). The goal is to deprecate the prefixes delegated by		deprecate the prefixes delegated by these MAARs (so that they will no
	these MAARs (so that they will no longer be serving the MN). Note		longer be serving the MN). Note that ongoing communications may keep
	that on-going communications may keep on using those addresses, even		on using those addresses even if they are deprecated, so this only
	if they are deprecated, so this only affects the establishment of new		affects the establishment of new sessions.
	sessions.
	The distributed logical interface concept also enables the following		The DLIF concept also enables the following use case: suppose that
	use case: suppose that access to a local IP network is provided by a		access to a local IP network is provided by a given MAAR (e.g., MAAR1
	given MAAR (e.g., MAAR1 in the example shown in Figure 5) and that		in the example shown in Figure 5) and that the resources available at
	the resources available at that network cannot be reached from		that network cannot be reached from outside the local network (e.g.,
	outside the local network (e.g., cannot be accessed by an MN attached		cannot be accessed by an MN attached to MAAR2). This is similar to
	to MAAR2). This is similar to the local IP access scenario		the local IP access scenario considered by 3GPP, where a local
	considered by 3GPP, where a local gateway node is selected for		gateway node is selected for sessions requiring access to services
	sessions requiring access to services provided locally (instead of		provided locally (instead of going through a central gateway). The
	going through a central gateway). The goal is to allow an MN to be		goal is to allow an MN to be able to roam while still being able to
	able to roam while still being able to have connectivity to this		have connectivity to this local IP network. The solution adopted to
	local IP network. The solution adopted to support this case makes		support this case makes use of more specific routes, as discussed in
	use of RFC 4191 [RFC4191] more specific routes when the MN moves to a		RFC 4191 [RFC4191], when the MN moves to a MAAR different from the
	MAAR different from the one providing access to the local IP network		one providing access to the local IP network (MAAR1 in the example).
	(MAAR1 in the example). These routes are advertised through the		These routes are advertised through the DLIF where the MAAR is
	distributed logical interface representing the MAAR providing access		providing access to the local network (MAAR1 in this example). In
	to the local network (MAAR1 in this example). In this way, if MN1		this way, if MN1 moves from MAAR1 to MAAR2, any active session that
	moves from MAAR1 to MAAR2, any active session that MN1 may have with		MN1 may have with a node on the local network connected to MAAR1 will
	a node on the local network connected to MAAR1 will survive via the		survive via the tunnel between MAAR1 and MAAR2. Also, any potential
	tunnel between MAAR1 and MAAR2. Also, any potential future		future connection attempt to the local network will be supported even
	connection attempt towards the local network will be supported, even		though MN1 is no longer attached to MAAR1, so long as a source
	though MN1 is no longer attached to MAAR1.		address configured from MAAR1 is selected for new connections (see
			[RFC6724], rule 5.5).
	4. Message Format		4. Message Format
	This section defines extensions to the Proxy Mobile IPv6 [RFC5213]		This section defines extensions to the PMIPv6 [RFC5213] protocol
	protocol messages.		messages.
	4.1. Proxy Binding Update		4.1. Proxy Binding Update
	A new flag (D) is included in the Proxy Binding Update to indicate		A new flag (D) is included in the PBU to indicate that the PBU is
	that the Proxy Binding Update is coming from a MAAR or a CMD and not		coming from a MAAR or a CMD and not from a MAG. The rest of the PBU
	from a mobile access gateway. The rest of the Proxy Binding Update
	format remains the same as defined in [RFC5213].		format remains the same as defined in [RFC5213].
	0 1 2 3		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		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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Sequence # |		| Sequence # |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|A|H|L|K|M|R|P|F|T|B|S|D| Rsrvd | Lifetime |		|A|H|L|K|M|R|P|F|T|B|S|D| Rsrvd | Lifetime |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	. .		. .
	. Mobility options .		. Mobility Options .
	. .		. .
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	DMM Flag (D)		DMM Flag (D)
			The D flag is set to indicate to the receiver of the message that
	The D Flag is set to indicate to the receiver of the message that		the PBU is from a MAAR or a CMD. When an LMA that does not
	the Proxy Binding Update is from a MAAR or a CMD. When an LMA		support the extensions described in this document receives a
	that does not support the extensions described in this document		message with the D flag set, the PBU in that case MUST NOT be
	receives a message with the D-Flag set, the PBU in that case MUST		processed by the LMA, and an error MUST be returned.
	NOT be processed by the LMA and an error MUST be returned.
	Mobility Options		Mobility Options
	Variable-length field of such length that the complete Mobility		Variable-length field of such length that the complete Mobility
	Header is an integer multiple of 8 octets long. This field		Header is an integer that is a multiple of 8 octets long. This
	contains zero or more TLV-encoded mobility options. The encoding		field contains zero or more TLV-encoded mobility options. The
	and format of defined options are described in Section 6.2 of		encoding and format of the defined options are described in
	[RFC6275]. The receiving node MUST ignore and skip any options		Section 6.2 of [RFC6275]. The receiving node MUST ignore and skip
	that it does not understand.		any options that it does not understand.
	4.2. Proxy Binding Acknowledgment		4.2. Proxy Binding Acknowledgement
	A new flag (D) is included in the Proxy Binding Acknowledgment to		A new flag (D) is included in the PBA to indicate that the sender
	indicate that the sender supports operating as a MAAR or CMD. The		supports operating as a MAAR or CMD. The rest of the PBA format
	rest of the Proxy Binding Acknowledgment format remains the same as		remains the same as defined in [RFC5213].
	defined in [RFC5213].
	0 1 2 3		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		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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Status |K|R|P|T|B|S|D| |		| Status |K|R|P|T|B|S|D| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Sequence # | Lifetime |		| Sequence # | Lifetime |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	. .		. .
	. Mobility options .		. Mobility Options .
	. .		. .
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	DMM Flag (D)		DMM Flag (D)
	The D flag is set to indicate that the sender of the message		The D flag is set to indicate that the sender of the message
	supports operating as a MAAR or a CMD. When a MAG that does not		supports operating as a MAAR or CMD. When a MAG that does not
	support the extensions described in this document receives a		support the extensions described in this document receives a
	message with the D-Flag set, it MUST ignore the message and an		message with the D flag set, it MUST ignore the message, and an
	error MUST be returned.		error MUST be returned.
	Mobility Options		Mobility Options
	Variable-length field of such length that the complete Mobility		Variable-length field of such length that the complete Mobility
	Header is an integer multiple of 8 octets long. This field		Header is an integer multiple of 8 octets long. This field
	contains zero or more TLV-encoded mobility options. The encoding		contains zero or more TLV-encoded mobility options. The encoding
	and format of defined options are described in Section 6.2 of		and format of the defined options are described in Section 6.2 of
	[RFC6275]. The MAAR MUST ignore and skip any options that it does		[RFC6275]. The MAAR MUST ignore and skip any options that it does
	not understand.		not understand.
	4.3. Anchored Prefix Option		4.3. Anchored Prefix Option
	A new Anchored Prefix option is defined for use with the Proxy		A new Anchored Prefix option is defined for use with the PBU and PBA
	Binding Update and Proxy Binding Acknowledgment messages exchanged		messages exchanged between MAARs and CMDs. Therefore, this option
	between MAARs and CMDs. Therefore, this option can only appear if		can only appear if the D bit is set in a PBU/PBA. This option is
	the D bit is set in a PBU/PBA. This option is used for exchanging		used for exchanging the MN's prefix anchored at the anchoring MAAR.
	the mobile node's prefix anchored at the anchoring MAAR. There can		There can be multiple Anchored Prefix options present in the message.
	be multiple Anchored Prefix options present in the message.
	The Anchored Prefix Option has an alignment requirement of 8n+4. Its		The Anchored Prefix option has an alignment requirement of 8n+4. Its
	format is as follows:		format is as follows:
	0 1 2 3		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		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 | Reserved | Prefix Length |		| Type | Length | Reserved | Prefix Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	+ +		+ +
	| |		| |
	+ Anchored Prefix +		+ Anchored Prefix +
	| |		| |
	+ +		+ +
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Type		Type
			65
	IANA-1.
	Length		Length
	8-bit unsigned integer indicating the length of the option in		8-bit unsigned integer indicating the length of the option in
	octets, excluding the type and length fields. This field MUST be		octets, excluding the type and length fields. This field MUST be
	set to 18.		set to 18.
	Reserved		Reserved
			This field is unused at the time of publication. The value MUST
	This field is unused for now. The value MUST be initialized to 0		be initialized to 0 by the sender and MUST be ignored by the
	by the sender and MUST be ignored by the receiver.		receiver.
	Prefix Length		Prefix Length
	8-bit unsigned integer indicating the prefix length in bits of the		8-bit unsigned integer indicating the prefix length in bits of the
	IPv6 prefix contained in the option.		IPv6 prefix contained in the option.
	Anchored Prefix		Anchored Prefix
			A 16-octet field containing the MN's IPv6 Anchored Prefix. Only
	A sixteen-octet field containing the mobile node's IPv6 Anchored		the first Prefix Length bits are valid for the Anchored Prefix
	Prefix. Only the first Prefix Length bits are valid for the		option. The rest of the bits MUST be ignored.
	Anchored Prefix. The rest of the bits MUST be ignored.
	4.4. Local Prefix Option		4.4. Local Prefix Option
	A new Local Prefix option is defined for use with the Proxy Binding		A new Local Prefix option is defined for use with the PBU and PBA
	Update and Proxy Binding Acknowledgment messages exchanged between		messages exchanged between MAARs or between a MAAR and a CMD.
	MAARs or between a MAAR and a CMD. Therefore, this option can only		Therefore, this option can only appear if the D bit is set in a PBU/
	appear if the D bit is set in a PBU/PBA. This option is used for		PBA. This option is used for exchanging a prefix of a local network
	exchanging a prefix of a local network that is only reachable via the		that is only reachable via the anchoring MAAR. There can be multiple
	anchoring MAAR. There can be multiple Local Prefix options present		Local Prefix options present in the message.
	in the message.
	The Local Prefix Option has an alignment requirement of 8n+4. Its		The Local Prefix option has an alignment requirement of 8n+4. Its
	format is as follows:		format is as follows:
	0 1 2 3		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		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 | Reserved | Prefix Length |		| Type | Length | Reserved | Prefix Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	+ +		+ +
	| |		| |
	+ Local Prefix +		+ Local Prefix +
	| |		| |
	+ +		+ +
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Type		Type
			66
	IANA-2.
	Length		Length
	8-bit unsigned integer indicating the length of the option in		8-bit unsigned integer indicating the length of the option in
	octets, excluding the type and length fields. This field MUST be		octets, excluding the type and length fields. This field MUST be
	set to 18.		set to 18.
	Reserved		Reserved
			This field is unused at the time of publication. The value MUST
	This field is unused for now. The value MUST be initialized to 0		be initialized to 0 by the sender and MUST be ignored by the
	by the sender and MUST be ignored by the receiver.		receiver.
	Prefix Length		Prefix Length
	8-bit unsigned integer indicating the prefix length in bits of the		8-bit unsigned integer indicating the prefix length in bits of the
	IPv6 prefix contained in the option.		IPv6 prefix contained in the option.
	Local Prefix		Local Prefix
	A sixteen-octet field containing the IPv6 Local Prefix. Only the		A 16-octet field containing the IPv6 Local Prefix. Only the first
	first Prefix Length bits are valid for the IPv6 Local Prefix. The		Prefix Length bits are valid for the IPv6 Local Prefix. The rest
	rest of the bits MUST be ignored.		of the bits MUST be ignored.
	4.5. Previous MAAR Option		4.5. Previous MAAR Option
	This new option is defined for use with the Proxy Binding		This new option is defined for use with the PBA messages exchanged by
	Acknowledgement messages exchanged by the CMD to a MAAR. This option		the CMD to a MAAR. This option is used to notify the S-MAAR about
	is used to notify the S-MAAR about the previous MAAR's global address		the P-MAAR's global address and the prefix anchored to it. There can
	and the prefix anchored to it. There can be multiple Previous MAAR		be multiple Previous MAAR options present in the message.
	options present in the message. Its format is as follows:
	The Previous MAAR Option has an alignment requirement of 8n+4. Its		The Previous MAAR option has an alignment requirement of 8n+4. Its
	format is as follows:		format is as follows:
	0 1 2 3		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		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 | Reserved | Prefix Length |		| Type | Length | Reserved | Prefix Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	+ +		+ +
	| |		| |
	+ P-MAAR's address +		+ Previous MAAR +
	| |		| |
	+ +		+ +
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	+ +		+ +
	| |		| |
	+ Home Network Prefix +		+ Home Network Prefix +
	| |		| |
	+ +		+ +
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Type		Type
			67
	IANA-3.
	Length		Length
	8-bit unsigned integer indicating the length of the option in		8-bit unsigned integer indicating the length of the option in
	octets, excluding the type and length fields. This field MUST be		octets, excluding the type and length fields. This field MUST be
	set to 34.		set to 34.
	Reserved		Reserved
	This field is unused for now. The value MUST be initialized to 0		This field is unused at the time of publication. The value MUST
	by the sender and MUST be ignored by the receiver.		be initialized to 0 by the sender and MUST be ignored by the
			receiver.
	Prefix Length		Prefix Length
	8-bit unsigned integer indicating the prefix length in bits of the		8-bit unsigned integer indicating the prefix length in bits of the
	IPv6 prefix contained in the option.		IPv6 prefix contained in the option.
	Previous MAAR's address		Previous MAAR
			A 16-octet field containing the P-MAAR's IPv6 global address.
	A sixteen-octet field containing the P-MAAR's IPv6 global address.
	Home Network Prefix		Home Network Prefix
			A 16-octet field containing the MN's IPv6 Home Network Prefix.
	A sixteen-octet field containing the mobile node's IPv6 Home		Only the first Prefix Length bits are valid for the MN's IPv6 Home
	Network Prefix. Only the first Prefix Length bits are valid for		Network Prefix. The rest of the bits MUST be ignored.
	the mobile node's IPv6 Home Network Prefix. The rest of the bits
	MUST be ignored.
	4.6. Serving MAAR Option		4.6. Serving MAAR Option
	This new option is defined for use with the Proxy Binding Update		This new option is defined for use with the PBU message exchanged
	message exchanged between the CMD and a Previous MAAR. This option		between the CMD and a P-MAAR. This option is used to notify the
	is used to notify the P-MAAR about the current Serving MAAR's global		P-MAAR about the current S-MAAR's global address. Its format is as
	address. Its format is as follows:		follows:
	The Serving MAAR Option has an alignment requirement of 8n+6. Its		The Serving MAAR option has an alignment requirement of 8n+6. Its
	format is as follows:		format is as follows:
	0 1 2 3		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		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 |		| Type | Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	+ +		+ +
	| |		| |
	+ S-MAAR's address +		+ S-MAAR's Address +
	| |		| |
	+ +		+ +
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Type		Type
			68
	IANA-4.
	Length		Length
	8-bit unsigned integer indicating the length of the option in		8-bit unsigned integer indicating the length of the option in
	octets, excluding the type and length fields. This field MUST be		octets, excluding the type and length fields. This field MUST be
	set to 16.		set to 16.
	Serving MAAR's address		Serving MAAR
			A 16-octet field containing the S-MAAR's IPv6 global address.
	A sixteen-octet field containing the S-MAAR's IPv6 global address.
	4.7. DLIF Link-local Address Option		4.7. DLIF Link-Local Address Option
	A new DLIF Link-local Address option is defined for use with the		A new DLIF Link-Local Address option is defined for use with the PBA
	Proxy Binding Acknowledgment message exchanged between MAARs and		message exchanged between MAARs and between a MAAR and a CMD. This
	between a MAAR and a CMD. This option is used for exchanging the		option is used for exchanging the link-local address of the DLIF to
	link-local address of the DLIF to be configured on the serving MAAR		be configured on the S-MAAR so it resembles the DLIF configured on
	so it resembles the DLIF configured on the P-MAAR.		the P-MAAR.
	The DLIF Link-local Address option has an alignment requirement of		The DLIF Link-Local Address option has an alignment requirement of
	8n+6. Its format is as follows:		8n+6. Its format is as follows:
	0 1 2 3		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		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 |		| Type | Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	+ +		+ +
	| |		| |
	+ DLIF Link-local Address +		+ DLIF Link-Local Address +
	| |		| |
	+ +		+ +
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Type		Type
			69
	IANA-5.
	Length		Length
	8-bit unsigned integer indicating the length of the option in		8-bit unsigned integer indicating the length of the option in
	octets, excluding the type and length fields. This field MUST be		octets, excluding the type and length fields. This field MUST be
	set to 16.		set to 16.
	DLIF Link-local Address		DLIF Link-Local Address
	A sixteen-octet field containing the link-local address of the		A 16-octet field containing the link-local address of the logical
	logical interface.		interface.
	4.8. DLIF Link-layer Address Option		4.8. DLIF Link-Layer Address Option
	A new DLIF Link-layer Address option is defined for use with the		A new DLIF Link-Layer Address option is defined for use with the PBA
	Proxy Binding Acknowledgment message exchanged between MAARs and		message exchanged between MAARs and between a MAAR and a CMD. This
	betwwe a MAAR and a CMD. This option is used for exchanging the		option is used for exchanging the link-layer address of the DLIF to
	link-layer address of the DLIF to be configured on the serving MAAR		be configured on the S-MAAR so it resembles the DLIF configured on
	so it resembles the DLIF configured on the P-MAAR.		the P-MAAR.
	The format of the DLIF Link-layer Address option is shown below.		The format of the DLIF Link-Layer Address option is shown below.
	Based on the size of the address, the option MUST be aligned		Based on the size of the address, the option MUST be aligned
	appropriately, as per mobility option alignment requirements		appropriately, as per the mobility option alignment requirements
	specified in [RFC6275].		specified in [RFC6275].
	0 1 2 3		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		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 | Reserved |		| Type | Length | Reserved |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	+ DLIF Link-layer Address +		+ DLIF Link-Layer Address +
	. ... .		. ... .
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Type		Type
			70
	IANA-6.
	Length		Length
	8-bit unsigned integer indicating the length of the option in		8-bit unsigned integer indicating the length of the option in
	octets, excluding the type and length fields.		octets, excluding the type and length fields.
	Reserved		Reserved
			This field is unused at the time of publication. The value MUST
			be initialized to 0 by the sender and MUST be ignored by the
			receiver.
	This field is unused for now. The value MUST be initialized to 0		DLIF Link-Layer Address
	by the sender and MUST be ignored by the receiver.
	DLIF Link-layer Address
	A variable length field containing the link-layer address of the		A variable length field containing the link-layer address of the
	logical interface to be configured on the S-MAAR.		logical interface to be configured on the S-MAAR.
	The content and format of this field (including octet and bit		The content and format of this field (including octet and bit
	ordering) is as specified in Section 4.6 of [RFC4861] for carrying		ordering) is as specified in Section 4.6 of [RFC4861] for carrying
	link-layer addresses. On certain access links, where the link-		link-layer addresses. On certain access links where the link-
	layer address is not used or cannot be determined, this option		layer address is not used or cannot be determined, this option
	cannot be used.		cannot be used.
	5. IANA Considerations		5. IANA Considerations
	This document defines six new mobility options, the Anchored Prefix		This document defines six new mobility options: Anchored Prefix,
	Option, the Local Prefix Option, the Previous MAAR Option, the		Local Prefix, Previous MAAR, Serving MAAR, DLIF Link-Local Address,
	Serving MAAR Option, the DLIF Link-local Address Option and the DLIF		and DLIF Link-Layer Address. IANA has assigned Type values for these
	Link-layer Address Option. The Type value for these options needs to		options from the same numbering space as allocated for the other
	be assigned from the same numbering space as allocated for the other
	mobility options in the "Mobility Options" registry defined in		mobility options in the "Mobility Options" registry defined in
	http://www.iana.org/assignments/mobility-parameters. The required		http://www.iana.org/assignments/mobility-parameters.
	IANA actions are marked as IANA-1 to IANA-6.
	This document reserves a new flag (D) in the "Binding Update Flags"		This document reserves a new flag (D) with a value of 0x0010 in the
	and a new flag (D) in the "Binding Acknowledgment Flags" of the		"Binding Update Flags" registry and a new flag (D) with a value of
	"Mobile IPv6 parameters" registry http://www.iana.org/assignments/		0x02 in the "Binding Acknowledgment Flags" of the "Mobile IPv6
	mobility-parameters.		parameters" registry (http://www.iana.org/assignments/mobility-
			parameters).
	6. Security Considerations		6. Security Considerations
	The protocol extensions defined in this document share the same		The protocol extensions defined in this document share the same
	security concerns of Proxy Mobile IPv6 [RFC5213]. It is recommended		security concerns of PMIPv6 [RFC5213]. It is recommended that the
	that the signaling messages, Proxy Binding Update and Proxy Binding		signaling messages, PBU and PBA, exchanged between the MAARs be
	Acknowledgment, exchanged between the MAARs are protected using IPsec		protected using IPsec, specifically by using the established security
	using the established security association between them. This		association between them. This essentially eliminates the threats
	essentially eliminates the threats related to the impersonation of a		related to the impersonation of a MAAR.
	MAAR.
	When the CMD acts as a PBU/PBA relay, the CMD may act as a relay of a		When the CMD acts as a PBU/PBA relay, the CMD may act as a relay of a
	single PBU to multiple previous MAARs. In situations of many fast		single PBU to multiple P-MAARs. In situations with many fast
	handovers (e.g., with vehicular networks), there may exist multiple		handovers (e.g., with vehicular networks), multiple previous (e.g.,
	previous (e.g., k) MAARs. In this situation, the CMD creates k		k) MAARs may exist. In this situation, the CMD creates k outgoing
	outgoing packets from a single incoming packet. This bears a certain		packets from a single incoming packet. This bears a certain
	amplification risk. The CMD MUST use a pacing approach in the		amplification risk. The CMD MUST use a pacing approach in the
	outgoing queue to cap the output traffic (i.e., the rate of PBUs		outgoing queue to cap the output traffic (i.e., the rate of PBUs
	sent) to limit this amplification risk.		sent) to limit this amplification risk.
	When the CMD acts as MAAR locator, mobility signaling (PBAs) is		When the CMD acts as a MAAR locator, mobility signaling (PBAs) is
	exchanged between P-MAARs and current S-MAAR. Hence, security		exchanged between P-MAARs and the current S-MAAR. Hence, security
	associations are REQUIRED to exist between the involved MAARs (in		associations are REQUIRED to exist between the involved MAARs (in
	addition to the ones needed with the CMD).		addition to the ones needed with the CMD).
	Since deregistration is performed by timeout, measures SHOULD be		Since de-registration is performed by timeout, measures SHOULD be
	implemented to minimize the risks associated to continued resource		implemented to minimize the risks associated with continued resource
	consumption (DoS attacks), e.g., imposing a limit of the number of		consumption (DoS attacks), e.g., imposing a limit on the number of
	P-MAARs associated to a given MN.		P-MAARs associated with a given MN.
	The CMD and the participating MAARs MUST be trusted parties,		The CMD and the participating MAARs MUST be trusted parties
	authorized perform all operations relevant to their role.		authorized perform all operations relevant to their role.
	There are some privacy considerations to consider. While the		There are some privacy considerations to consider. While the
	involved parties trust each other, the signalling involves disclosing		involved parties trust each other, the signaling involves disclosing
	information about the previous locations visited by each MN, as well		information about the previous locations visited by each MN, as well
	as the active prefixes they are using at a given point of time.		as the active prefixes they are using at a given point of time.
	Therefore, mechanisms MUST be in place to ensure that MAARs and CMD		Therefore, mechanisms MUST be in place to ensure that MAARs and CMDs
	do not disclose this information to other parties nor use it for		do not disclose this information to other parties or use it for other
	other ends that providing the distributed mobility support specified		ends than providing the distributed mobility support specified in
	in this document.		this document.
	7. Acknowledgments
	The authors would like to thank Dirk von Hugo, John Kaippallimalil,
	Ines Robles, Joerg Ott, Carlos Pignataro, Vincent Roca, Mirja
	Kuehlewind, Eric Vyncke, Adam Roach, Benjamin Kaduk and Roman Danyliw
	for the comments on this document. The authors would also like to
	thank Marco Liebsch, Dirk von Hugo, Alex Petrescu, Daniel Corujo,
	Akbar Rahman, Danny Moses, Xinpeng Wei and Satoru Matsushima for
	their comments and discussion on the documents
	[I-D.bernardos-dmm-distributed-anchoring] and
	[I-D.bernardos-dmm-pmip] on which the present document is based.
	The authors would also like to thank Lyle Bertz and Danny Moses for
	their in-deep review of this document and their very valuable
	comments and suggestions.
	8. References		7. References
	8.1. Normative References		7.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,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<https://www.rfc-editor.org/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
	[RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and		[RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and
	More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191,		More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191,
	November 2005, <https://www.rfc-editor.org/info/rfc4191>.		November 2005, <https://www.rfc-editor.org/info/rfc4191>.
	skipping to change at page 28, line 23 ¶		skipping to change at line 1219 ¶
	[RFC7333] Chan, H., Ed., Liu, D., Seite, P., Yokota, H., and J.		[RFC7333] Chan, H., Ed., Liu, D., Seite, P., Yokota, H., and J.
	Korhonen, "Requirements for Distributed Mobility		Korhonen, "Requirements for Distributed Mobility
	Management", RFC 7333, DOI 10.17487/RFC7333, August 2014,		Management", RFC 7333, DOI 10.17487/RFC7333, August 2014,
	<https://www.rfc-editor.org/info/rfc7333>.		<https://www.rfc-editor.org/info/rfc7333>.
	[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC		[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
	2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,		2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
	May 2017, <https://www.rfc-editor.org/info/rfc8174>.		May 2017, <https://www.rfc-editor.org/info/rfc8174>.
	8.2. Informative References		7.2. Informative References
	[I-D.bernardos-dmm-distributed-anchoring]		[DISTRIBUTED-ANCHORING]
	Bernardos, C. and J. Zuniga, "PMIPv6-based distributed		Bernardos, C. and J. Zuniga, "PMIPv6-based distributed
	anchoring", draft-bernardos-dmm-distributed-anchoring-09		anchoring", Work in Progress, Internet-Draft, draft-
	(work in progress), May 2017.		bernardos-dmm-distributed-anchoring-09, 29 May 2017,
			<https://tools.ietf.org/html/draft-bernardos-dmm-
			distributed-anchoring-09>.
	[I-D.bernardos-dmm-pmip]		[DMM-PMIP] Bernardos, C., Oliva, A., and F. Giust, "A PMIPv6-based
	Bernardos, C., Oliva, A., and F. Giust, "A PMIPv6-based		solution for Distributed Mobility Management", Work in
	solution for Distributed Mobility Management", draft-		Progress, Internet-Draft, draft-bernardos-dmm-pmip-09, 8
	bernardos-dmm-pmip-09 (work in progress), September 2017.		September 2017,
			<https://tools.ietf.org/html/draft-bernardos-dmm-pmip-09>.
			[RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown,
			"Default Address Selection for Internet Protocol Version 6
			(IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012,
			<https://www.rfc-editor.org/info/rfc6724>.
	[RFC7429] Liu, D., Ed., Zuniga, JC., Ed., Seite, P., Chan, H., and		[RFC7429] Liu, D., Ed., Zuniga, JC., Ed., Seite, P., Chan, H., and
	CJ. Bernardos, "Distributed Mobility Management: Current		CJ. Bernardos, "Distributed Mobility Management: Current
	Practices and Gap Analysis", RFC 7429,		Practices and Gap Analysis", RFC 7429,
	DOI 10.17487/RFC7429, January 2015,		DOI 10.17487/RFC7429, January 2015,
	<https://www.rfc-editor.org/info/rfc7429>.		<https://www.rfc-editor.org/info/rfc7429>.
	[RFC8563] Katz, D., Ward, D., Pallagatti, S., Ed., and G. Mirsky,		[RFC8563] Katz, D., Ward, D., Pallagatti, S., Ed., and G. Mirsky,
	Ed., "Bidirectional Forwarding Detection (BFD) Multipoint		Ed., "Bidirectional Forwarding Detection (BFD) Multipoint
	Active Tails", RFC 8563, DOI 10.17487/RFC8563, April 2019,		Active Tails", RFC 8563, DOI 10.17487/RFC8563, April 2019,
	<https://www.rfc-editor.org/info/rfc8563>.		<https://www.rfc-editor.org/info/rfc8563>.
			Acknowledgements
			The authors would like to thank Dirk von Hugo, John Kaippallimalil,
			Ines Robles, Joerg Ott, Carlos Pignataro, Vincent Roca, Mirja
			Kühlewind, Éric Vyncke, Adam Roach, Benjamin Kaduk, and Roman Danyliw
			for the comments on this document. The authors would also like to
			thank Marco Liebsch, Dirk von Hugo, Alex Petrescu, Daniel Corujo,
			Akbar Rahman, Danny Moses, Xinpeng Wei, and Satoru Matsushima for
			their comments and discussion on the documents
			[DISTRIBUTED-ANCHORING] and [DMM-PMIP], on which the present document
			is based.
			The authors would also like to thank Lyle Bertz and Danny Moses for
			their in-depth review of this document and their very valuable
			comments and suggestions.
	Authors' Addresses		Authors' Addresses
	Carlos J. Bernardos		Carlos J. Bernardos
	Universidad Carlos III de Madrid		Universidad Carlos III de Madrid
	Av. Universidad, 30		Av. Universidad, 30
	Leganes, Madrid 28911		28911 Leganes Madrid
	Spain		Spain
	Phone: +34 91624 6236		Phone: +34 91624 6236
	Email: cjbc@it.uc3m.es		Email: cjbc@it.uc3m.es
	URI: http://www.it.uc3m.es/cjbc/		URI: http://www.it.uc3m.es/cjbc/
	Antonio de la Oliva		Antonio de la Oliva
	Universidad Carlos III de Madrid		Universidad Carlos III de Madrid
	Av. Universidad, 30		Av. Universidad, 30
	Leganes, Madrid 28911		28911 Leganes Madrid
	Spain		Spain
	Phone: +34 91624 8803		Phone: +34 91624 8803
	Email: aoliva@it.uc3m.es		Email: aoliva@it.uc3m.es
	URI: http://www.it.uc3m.es/aoliva/		URI: http://www.it.uc3m.es/aoliva/
	Fabio Giust		Fabio Giust
	Athonet S.r.l.		Athonet S.r.l.
			via Ca' del Luogo 6/8
			36050 Bolzano Vicentino (VI)
			Italy
	Email: fabio.giust.2011@ieee.org		Email: fabio.giust.research@gmail.com
	Juan Carlos Zuniga		Juan Carlos Zúñiga
	SIGFOX		SIGFOX
	425 rue Jean Rostand		425 rue Jean Rostand
	Labege 31670		31670 Labege
	France		France
	Email: j.c.zuniga@ieee.org		Email: j.c.zuniga@ieee.org
	URI: http://www.sigfox.com/		URI: http://www.sigfox.com/
	Alain Mourad		Alain Mourad
	InterDigital Europe		InterDigital Europe
	Email: Alain.Mourad@InterDigital.com		Email: Alain.Mourad@InterDigital.com
	URI: http://www.InterDigital.com/		URI: http://www.InterDigital.com/
End of changes. 195 change blocks.
	605 lines changed or deleted		594 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/