DMMInternet Engineering Task Force (IETF) D. Liu, Ed.Internet-DraftRequest for Comments: 7429 China MobileIntended status:Category: Informational JC. Zuniga, Ed.Expires: May 8, 2015ISSN: 2070-1721 InterDigital P. Seite Orange H. Chan Huawei Technologies CJ. Bernardos UC3MNovember 4, 2014January 2015 Distributed Mobility Management: CurrentpracticesPractices andgap analysis draft-ietf-dmm-best-practices-gap-analysis-09Gap Analysis Abstract This document analyzes deployment practices of existing IP mobility protocols in a distributed mobility management environment. It then identifies existing limitations when compared to the requirements defined for a distributed mobility management solution. Status of This Memo ThisInternet-Draftdocument issubmitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documentsnot an Internet Standards Track specification; it is published for informational purposes. This document is a product of the Internet Engineering Task Force (IETF).Note that other groups may also distribute working documents as Internet-Drafts. The listIt represents the consensus ofcurrent Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents validthe IETF 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 amaximumcandidate for any level of Internet Standard; see Section 2 of RFC 5741. Information about the current status ofsix monthsthis document, any errata, and how to provide feedback on it may beupdated, replaced, or obsoleted by other documentsobtained atany time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on May 8, 2015.http://www.rfc-editor.org/info/rfc7429. Copyright Notice Copyright (c)20142015 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . .23 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Functions ofexisting mobility protocolsExisting Mobility Protocols . . . . . . . . . .34 4. DMMpracticesPractices . . . . . . . . . . . . . . . . . . . . . . . . 5 4.1. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 5 4.2. IPflat wireless networkFlat Wireless Network . . . . . . . . . . . . . . . . 6 4.2.1.Host-basedHost-Based IP DMMpracticesPractices . . . . . . . . . . . . . 7 4.2.2.Network-basedNetwork-Based IP DMMpracticesPractices . . . . . . . . . . .1112 4.3. Flattening 3GPPmobile network approachesMobile Network Approaches . . . . . . . .1315 5. GapanalysisAnalysis . . . . . . . . . . . . . . . . . . . . . . . .1619 5.1. Distributedmobility managementMobility Management - REQ1 . . . . . . . . .1619 5.2. Bypassablenetwork-layer mobility supportNetwork-Layer Mobility Support foreach application sessionEach Application Session - REQ2 . . . . . . . . . . . . . . .1921 5.3. IPv6deploymentDeployment - REQ3 . . . . . . . . . . . . . . . . .2022 5.4. Consideringexisting mobility protocolsExisting Mobility Protocols - REQ4 . . . . .2023 5.5. Coexistence withdeployed networks/hostsDeployed Networks/Hosts andoperabilityOperability acrossdifferent networksDifferent Networks - REQ5 . . . . . .21. . . . . . 23 5.6. Operation andmanagement considerationsManagement Considerations - REQ6 . . . . .2123 5.7. SecurityconsiderationsConsiderations - REQ7 . . . . . . . . . . . . .2224 5.8. Multicast Considerations - REQ8 . . . . . . . . . . . .. . . . . . . . 2225 5.9. Summary . . . . . . . . . . . . . . . . . . . . . . . . .2325 6. Security Considerations . . . . . . . . . . . . . . . . . . .2528 7.ContributorsReferences . . . . . . . . . . . . . . . . . . . . . . . .25 8.. 28 7.1. Normative References . . . . . . . . . . . . . . . . . . 28 7.2. Informative References . . . . . . . .26 8.1. Normative References. . . . . . . . . 28 Contributors . . . . . . . . .26 8.2. Informative References. . . . . . . . . . . . . . . . .2633 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . .3033 1. Introduction Existing network-layer mobility management protocols have primarily employed a mobility anchor to ensure connectivity of a mobile node by forwarding packets destined to, or sent from, the mobile node after the node has moved to a different network. The mobility anchor has been centrally deployed in the sense that the traffic of millions of mobile nodes in an operator network is typically managed by the same anchor. This centralized deployment of mobility anchors to manage IP sessions poses several problems. In order to address these problems, a distributed mobility management (DMM) architecture has been proposed. This document investigates whether it is feasible to deploy current IP mobility protocols in a DMM scenario in a way that can fulfill the requirements as defined in[RFC7333]. It[RFC7333], discusses current deployment practices of existing mobilityprotocolsprotocols, and identifies the limitations (gaps) in these practices from the standpoint of satisfying DMM requirements. The analysis is primarily towards IPv6deployment,deployment but can be seen to also apply to IPv4 whenever there are IPv4 counterparts equivalent to the IPv6 mobility protocols. The rest of this document is organized asfollows.follows: Section 3 analyzes existing IP mobility protocols by examining their functions and how these functions can be configured and used to work in a DMMenvironment.environment, Section 4 presents the current practices of IP wireless networks and 3GPParchitectures. Botharchitectures (both network- and host-based mobility protocols areconsidered.considered), and Section 5 presents the gap analysis with respect to the current practices. 2. Terminology All general mobility-related terms and their acronyms used in this document are to be interpreted as defined in the Mobile IPv6 base specification [RFC6275], in the Proxy Mobile IPv6 specification [RFC5213], and in the Distributed Mobility Management Requirements [RFC7333]. These terms include mobile node (MN), correspondent node (CN), home agent (HA),Local Mobility Anchorlocal mobility anchor (LMA),Mobile Access Gatewaymobile access gateway (MAG), centrallydepoyeddeployed mobility anchors, distributed mobility management, hierarchical mobile network, flatter mobile network, and flattening mobile network. In addition, this document also introduces some definitions of IP mobility functions in Section 3. In this document there are also references to a "distributed mobility management environment." By this term, we refer to a scenario in which the IP mobility, accessnetworknetwork, and routing solutions allow for setting up IP networks so that traffic is distributed in an optimalway,way without relying on centrally deployed mobility anchors to manage IP mobility sessions. 3. Functions ofexisting mobility protocolsExisting Mobility Protocols The host-based Mobile IPv6 (MIPv6) [RFC6275] and its network-based extension, Proxy Mobile IPv6 (PMIPv6) [RFC5213], as well as Hierarchical Mobile IPv6 (HMIPv6)[RFC5380][RFC5380], are logically centralized mobility management approaches addressing primarily hierarchical mobile networks. Although these approaches are centralized, they have important mobility management functions resulting from years of extensive work to develop and to extend these functions. It is therefore useful to take these existing functions and examine them in a DMM scenario in order to understand how to deploy the existing mobility protocols to provide distributed mobility management. The main mobility management functions of MIPv6, PMIPv6, and HMIPv6 are the following: 1. Anchoring Function (AF): allocation to a mobile node of an IP address, i.e., Home Address (HoA), or prefix, i.e., Home Network Prefix(HNP)(HNP), topologically anchored by the advertising node. That is, the anchor node is able to advertise a connected route into the routing infrastructure for the allocated IP prefixes. This function is acontrol planecontrol-plane function. 2. Internetwork LocationInformation (LI)Management (LM) function: managing and keeping track of the internetwork location of an MN. The location information may be a binding of theIPadvertised IP address/prefix, e.g., HoA or HNP, to the IP routing address of theMNMN, or it may be a binding of a node that can forward packets destined to the MN. It is acontrol planecontrol-plane function. In a client-server protocol model, location query and update messages may be exchanged between alocation informationLocation Management client(LIc)(LMc) and alocation informationLocation Management server(LIs).(LMs). 3. Forwarding Management (FM) function: packet interception and forwarding to/from the IP address/prefix assigned to the MN, based on the internetwork location information, either to the destination or to some other network element that knows how to forward the packets to their destination. FM may optionally be split into the control plane (FM-CP) and data plane (FM-DP). In Mobile IPv6, the home agent (HA) typically provides theanchoring function (AF);AF; thelocation information server (LIs)LMs is at theHAHA, whereas thelocation information client (LIc)LMc is at the MN; theForwarding Management (FM)FM function is distributed between the ends of the tunnel at the HA and the MN. In Proxy Mobile IPv6, theLocal Mobility Anchorlocal mobility anchor (LMA) provides theanchoring function (AF);AF; thelocation information server (LIs)LMs is at theLMALMA, whereas thelocation information client (LIc)LMc is at themobile access gateway (MAG);MAG; theForwarding Management (FM)FM function is distributed between the ends of the tunnel at theHALMA and the MAG. InHierarchical Mobile IPv6 (HMIPv6)HMIPv6 [RFC5380], the Mobility Anchor Point (MAP) serves as a location information aggregator between theLIsLMs at the HA and theLIcLMc at the MN. The MAP also provides the FM function to enable tunneling between HA anditselfitself, as well as tunneling between the MN and itself. 4. DMMpracticesPractices This section documents deployment practices of existing mobility protocols to satisfy distributed mobility management requirements. This description considers both IP wireless, e.g., evolved Wi-Fi hotspots, and 3GPP flattening mobilenetwork.networks. While describing the current DMM practices, the section provides references to the generic mobility management functions described in Section 3 as well as some initial hints on the identified gaps with respect to the DMM requirements documented in [RFC7333]. 4.1. Assumptions There are many different approaches that can be considered to implement and deploy a distributed anchoring and mobility solution. The focus of the gap analysis is on certain current mobile network architectures and standardized IP mobility solutions, considering any kind of deployment optionswhichthat do not violate the original protocol specifications. In order to limit the scope of our analysis of DMM practices, we consider the following list of technical assumptions: 1. Both host- and network-based solutions are considered. 2. Solutions should allow selecting and using the most appropriate IP anchor among a set of available candidates. 3. Mobility management should be realized by the preservation of the IP address across the different points of attachment (i.e., provision of IP address continuity). This is in contrast to certaintransport-layer basedtransport-layer-based approaches such as Stream Control Transmission Protocol (SCTP) [RFC4960] or application-layer mobility. Applicationswhichthat can cope with changes in the MN's IP address do not depend on IP mobility management protocols such as DMM. Typically, a connectionmanagermanager, together with the operatingsystemsystem, will configure the source address selection mechanism of the IP stack. This might involve identifying application capabilities and triggering the mobility support accordingly. Further considerations on application management and source address selection are out of the scope of this document, but the reader might consult [RFC6724]. 4.2. IPflat wireless networkFlat Wireless Network This section focuses on common IP wireless network architectures and how they can be flattened from an IP mobility and anchoring point of view using common and standardized protocols. We take Wi-Fi asana useful wirelesstechnology,technology since it is widely known and deployed nowadays. Some representative examples of Wi-Fi deployment architectures are depicted in Figure 1. +-------------+ _----_ +---+ | Access | _( )_ |AAA|. . . . . . | Aggregation |----------( Internet ) +---+ | Gateway | (_ _) +-------------+ '----' | | | | | +-------------+ | | | | | +-----+ +---------------+ | | AR | | | +--+--+ +-----+ +-----+ *----+----* | RG | | WLC | ( LAN ) +-----+ +-----+ *---------* . / \ / \ / \ +-----+ +-----+ +-----+ +-----+ / \ |Wi-Fi| |Wi-Fi| |Wi-Fi| |Wi-Fi| MN1 MN2 | AP1 | | AP2 | | AP3 | | AP4 | +-----+ +-----+ +-----+ +-----+ . . / \ / \ / \ / \ MN3 MN4 MN5 MN6 Figure 1: IP Wi-Finetwork architecturesNetwork Architectures In Figure 1, three typical deployment options are shown[I-D.gundavelli-v6ops-community-wifi-svcs].[COMMUNITY-WIFI]. On theleft handleft-hand side of the figure, mobile nodes MN1 and MN2 directly connect to a Residential Gateway (RG) at the customer premises. The RG hosts the 802.11 Access Point (AP) function to enable wirelesslayer-2Layer 2 access connectivity and also provideslayer-3Layer 3 routing functions. In the middle of the figure, mobile nodes MN3 and MN4 connect to Wi-FiAccess Points (APs)access points AP1 and AP2 that are managed by a Wireless LAN Controller (WLC), which performs radio resource management on the APs, domain-wide mobility policyenforcementenforcement, and centralized forwarding function for the user traffic. The WLC could also implementlayer-3Layer 3 routingfunctions,functions or attach to an access router (AR). Last, on the right-hand side of the figure, access points AP3 and AP4 are directly connected to an access router. This can also be used as a generic connectivity model. IP mobility protocols can be used to provide heterogeneous network mobility support to users, e.g., handover from Wi-Fi to cellular access. Two kinds of protocols can be used: Proxy Mobile IPv6 [RFC5213] or Mobile IPv6 [RFC5555], with the role of mobilityanchor, e.g., Local Mobility Anchoranchor (e.g., local mobility anchor or homeagent,agent) typically being played by the edge router of the mobile network [SDO-3GPP.23.402]. Although this section has made use of the example of Wi-Fi networks, there are other flattening mobile network architectures specified, such asWiMAXWorldwide Interoperability for Microwave Access (WiMAX) [IEEE.802-16.2009], which integrates both host- and network-based IP mobility functions. Existing IP mobility protocols can also be deployed in a flattermanner,manner so that the anchoring and access aggregation functions are distributed. We next describe several practices for the deployment of existing mobility protocols in a distributed mobility management environment. The analysis in this section is limited to protocol solutions based on existing IP mobility protocols, either host- or network-based, such as Mobile IPv6[RFC6275],[RFC6275] [RFC5555], Proxy Mobile IPv6 (PMIPv6)[RFC5213], [RFC5844][RFC5213] [RFC5844], and Network Mobility (NEMO) Basic Supportprotocol (NEMO)Protocol [RFC3963]. Extensions to these base protocol solutions are also considered. The analysis is divided into two parts: host- and network-based practices. 4.2.1.Host-basedHost-Based IP DMMpracticesPractices Mobile IPv6 (MIPv6) [RFC6275] and its extension to support mobile networks, the NEMO Basic Support protocol (hereafter, simply referred to as NEMO)[RFC3963][RFC3963], arewell-knownwell-known, host-based IP mobility protocols. They depend on the function of theHome Agenthome agent (HA), a centralized anchor, to provide mobile nodes (hosts and routers) with mobility support. In these approaches, theHome Agenthome agent typically provides theAnchoring Function (AF), Forwarding Management (FM),AF, FM function, andInternetworkLocationInformationManagement server(LIs)(LMs) functions. The mobile node possesses the LocationInformationManagement client(LIc)(LMc) function and the FM function to enable tunneling between the HA and itself. We next describe some practices that show how MIPv6/NEMO and several other protocol extensions can be deployed in a distributed mobility management environment. One approach to distribute the anchors can be to deploy several HAs (as shown in Figure 2), and assign the topologically closest anchor to each MN[RFC4640], [RFC5026],[RFC4640] [RFC5026] [RFC6611]. In the example shown in Figure 2, the mobile node MN1 is assigned to the home agent HA1 and uses a home address anchored by HA1 to communicate with the correspondent node CN1. Similarly, the mobile node MN2 is assigned to the home agent HA2 and uses a home address anchored by HA2 to communicate with the correspondent node CN2. Note that MIPv6/NEMO specifications do not prevent the simultaneous use of multiple home agents by a single mobile node. In this deployment model, the mobile node can use several anchors at the same time, each of them anchoring IP flows initiated at a different point of attachment. However, there is currently no mechanism specified in IETF standard to enable an efficient dynamic discovery of available anchors and the selection of the most suitable one. <-INTERNET-> <- HOME NETWORK -> <------- ACCESS NETWORK -------> +-----+ +-----+ +--------+ | CN1 |--- ===| AR1 |=======| MN1 | +-----+ \ +-----------+ // +-----+ |(FM,LMc)| ---| HA1 |=== +--------+ |(AF,FM,LMs)| +-----+ (anchored +-----------+ | AR2 | at HA1) +-----+ +-----+ +-----------+ | CN2|-------------- +-----+ \|-------| HA2 |=== +-----++--------+ -------------||(AF,FM,LMs)| \\ +-----+=======+--------+ +-----------+ ===| AR3|-------| MN2|+-----------+ +-----+ |(FM,LMc)||HA2MN2 |+--------+ |(AF,FM,LMs)|+-----+-------|(FM,LMc)| +-----+ / +--------+ | CN3 |-----------------------------/ (anchored+-----------++-----+ at HA2) +-----+ | AR4 |at HA2)+-----+ CN1 CN2 CN3 HA1 HA2 AR1 AR3 MN1 MN2 | | | | | | | | | |<-------------->|<======tunnel====+=============>| | BT mode | | | | | | | | ||<---------------------------------+-------------->|| |<-------------->|<======tunnel====+==============>| BT mode | | | | | | | | | | | |<----------------------------+-------------->| RO mode | | | | | | | | | Figure 2: DistributedoperationOperation of Mobile IPv6 (BT andRO) / NEMORO)/NEMO One goal of the deployment of mobility protocols in a distributed mobility management environment is to avoid the suboptimal routing caused by centralized anchoring. Here, the Route Optimization (RO) support provided by Mobile IPv6 can be used to achieve a flatter IP data forwarding. By default, Mobile IPv6 and NEMO use the so-called Bidirectional Tunnel (BT) mode, in which data traffic is always encapsulated between the MN and its HA before being directed to any other destination. The RO mode allows the MN to update its current location on theCNs,CNs and then use the direct path between them. Using the example shown in Figure 2, MN1isand MN2 are using BT mode withCN1,CN1 and CN2, respectively, while MN2 is in RO mode withCN2.CN3. However, the RO mode has several drawbacks: o The RO mode is only supported by Mobile IPv6. There is no route optimization support standardized for the NEMO protocol because of the security problems posed by extending return routability tests for prefixes, although many different solutions have been proposed [RFC4889]. o The RO mode requires signaling that adds some protocol overhead. o The signaling required to enable RO involves the home agent and is repeated periodically for security reasons [RFC4225].ThereforeTherefore, the HA remains a single point of failure. o The RO mode requires support from the CN. Notwithstanding these considerations, the RO mode does offer the possibility of substantially reducing traffic through theHome Agent,home agent, in cases when it can be supported by the relevant correspondent nodes. Note that a mobile node can also use itscare-of-addressCare-of Address (CoA) directly [RFC5014] when communicating with CNs on the same link or anywhere in the Internet, although no session continuity support would be provided by the IP stack in this case.Hierarchical Mobile IPv6 (HMIPv6) [RFC5380] (asHMIPv6 [RFC5380], as shown in Figure3),3, is another host-based IP mobility extensionwhichthat can be considered as a complement to provide a less centralized mobility deployment. It allows the reduction of the amount of mobility signaling as well as improving the overall handover performance of Mobile IPv6 by introducing a new hierarchy level to handle local mobility. The Mobility Anchor Point (MAP) entity is introduced as a local mobility handling node deployed closer to the mobile node. It providesLILM intermediary function between theLI server (LIs)LMs at the HA and theLI client (LIc)LMc at the MN. It also performs the FM function to tunnel with the HA and also with the MN. <INTERNET> <- HOME NETWORK -> <---------- ACCESS NETWORK ----------> LCoA anchored at AR1 +---+ +--------+ ===|AR1|==| MN1 | +-----+ +-----------+ +----------+ // +---+ |(FM,LMc)| | CN1 |----| HA1 |======| MAP1 |=== +--------+ +-----+ |(AF,FM,LMs)| /|(AF,FM,LM)| +---+ HoA, +-----------+ / +----------+ |AR2| RCoA, HoA anchored / RCoA anchored +---+ LCoA at HA1 / at MAP1 / +---+ / |AR3| +-----+ / +----------+ +---+ | CN2 |---------------- | MAP2 | +-----+ |(AF,FM,LM)| +---+ +----------+ |AR4| +---+ CN1 CN2 HA1 MAP1 AR1 MN1 | | | | | | |<-------------->|<===============>|<====tunnel============>| HoA | | | | | | | |<-------------------------->|<====tunnel============>| RCoA | | | | | | Figure 3: Hierarchical Mobile IPv6 When HMIPv6 is used, the MN has two different temporary addresses: the Regional Care-of Address (RCoA) and the Local Care-of Address (LCoA). The RCoA is anchored at one MAP, which plays the role of local home agent, while the LCoA is anchored at theaccess routeraccess-router level. The mobile node uses the RCoA as the CoA that is signaled to its home agent. Therefore, while roaming within a local domain handled by the same MAP, the mobile node does not need to update its home agent, i.e., the mobile node does not change its RCoA. The use of HMIPv6 enables a form of route optimization, since a mobile node may decide to directly use the RCoA as the source address for a communication with a given correspondent node, particularly if the MN does not expect to move outside the local domain during the lifetime of the communication. This can be seen as a potential DMM mode of operation, though it fails to provide session continuity if and when the MN moves outside the local domain. In the example shown in Figure 3, MN1 is using its global HoA to communicate with CN1, while it is using its RCoA to communicate with CN2. Furthermore, a local domain might have several MAPs deployed, thus enablingtherefore adifferentkindkinds of HMIPv6 deploymentswhichthat are flattening and distributed. The HMIPv6 specification supports a flexible selection of the MAP, includingthoseselections based on the expected mobility pattern of the MN or on the distance between the MN and theMAP, or taking into consideration the expected mobility pattern of the MN.MAP. Another extension that can be used to help with distributing mobility management functions is the Home Agent switch specification [RFC5142], which defines a new mobility headerfor signalingto signal to a mobile node that it should acquire a new home agent. [RFC5142] does not specify the case of changing the mobile node's home address, as that might imply loss of connectivity for ongoing persistent connections. Nevertheless, that specification could be used to force the change of home agent in those situations where there are no active persistent data sessions that cannot cope with a change of home address. There are other host-based approaches standardized that can be used to provide mobility support. Forexample MOBIKEexample, IKEv2 Mobility and Multihoming (MOBIKE) [RFC4555] allows a mobile node encrypting traffic throughIKEv2 [RFC5996]Internet Key Exchange Protocol Version 2 (IKEv2) [RFC7296] to change its point of attachment while maintaining a Virtual Private Network (VPN) session. The MOBIKE protocol allows updating the VPN Security Associations (SAs) in cases where the base connection initially used is lost and needs to be re-established. The use of the MOBIKE protocol avoids having to perform an IKEv2re-negotiation.renegotiation. Similar considerations to those made for Mobile IPv6 can be applied to MOBIKE; though MOBIKE is best suited for situations where the address of at least one endpoint is relatively stable and can be discovered using existing mechanisms such as DNS. Extensions have been defined to the mobility protocol to optimize the handover performance. Mobile IPv6 Fast Handovers (FMIPv6) [RFC5568] is the extension to optimize handover latency. It defines new access router discovery mechanism before handover to reduce the new network discovery latency. It also defines a tunnel between the previous access router and the new access router to reduce the packet loss during handover. The Candidate Access Router Discovery (CARD) [RFC4066] and Context Transfer Protocol (CXTP) [RFC4067] protocols were standardized to improve the handover performance. The DMM deployment practice discussed in this section can also use those extensions to improve the handover performance. 4.2.2.Network-basedNetwork-Based IP DMMpracticesPractices Proxy Mobile IPv6 (PMIPv6) [RFC5213] is the main network-based IP mobility protocol specified for IPv6. Proxy Mobile IPv4 [RFC5844] defines some IPv4 extensions. With network-based IP mobility protocols, theLocal Mobility Anchor (LMA)LMA typically provides theAnchoring Function (AF), Forwarding Management (FM)AF, FM function, andInternetworkLocationInformationManagement server(LIs)(LMs) function. The mobile access gateway (MAG) provides the LocationInformationManagement client(LIc)(LMc) function andForwarding Management (FM)FM function to tunnel with LMA. PMIPv6 is architecturally almost identical to MIPv6, as the mobility signaling and routing between LMA and MAG in PMIPv6 is similar to those between the HA and MN in MIPv6. The required mobility functionality at the MN is provided by the MAG so that the involvement in mobility support by the MN is not required. We next describe some practices that show how network-based mobility protocols and several other protocol extensions can be deployed in a distributed mobility management environment. One way to decentralize Proxy Mobile IPv6 operation can be to deploy severalLocal Mobility AnchorsLMAs and use some selection criteria to assign LMAs to attaching mobile nodes. An example of this type of assignment is shown in Figure 4. As with theclient basedclient-based approach, a mobile node may use several anchors at the same time, each of them anchoring IP flows initiated at a different point of attachment. This assignment can be static or dynamic. The main advantage of this simple approach is that the IP address anchor, i.e., the LMA, could be placed closer to the mobile node.ThereforeTherefore, the resulting paths areclose-to-optimal.close to optimal. On the other hand, as soon as the mobile node moves, the resulting path will start deviating from the optimal one. <INTERNET> <--- HOME NETWORK ---> <------ ACCESS NETWORK -------> +--------+ +---+ =======| MAG1 |------|MN1| +-----+ +-----------+ // |(FM,LMc)| +---+ | CN1 |-------| LMA1 |======= +--------+ +-----+ |(AF,FM,LMs)| +-----------+ +--------+ +-----+ | MAG2 | | CN2 |--- |(FM,LMc)| +-----+ \ +-----------+ +--------+ ---| LMA2 |======= +-----+ |(AF,FM,LMs)| \\ +--------+ +---+ | CN3 | +-----------+ =======| MAG3 |------|MN2| +-----+|(FM,LMs)||(FM,LMc)| +---+ +--------+ CN1 CN2 LMA1 LMA2 MAG1 MAG3 MN1 MN2 | | | | | | | | |<-------------->|<===========tunnel========>|<----------->| | | | | | | | | | | |<-------------->|<=====tunnel=============>|<----------->| | | | | | | | | Figure 4: DistributedoperationOperation of Proxy Mobile IPv6 In a similar way to the host-based IP mobility case, network-based IP mobility has some extensions defined to mitigate the suboptimal routing issues that may arise due to the use of a centralized anchor. The Local Routing extensions [RFC6705] enable optimal routing in Proxy Mobile IPv6 in three cases: i) when two communicating MNs are attached to the same MAG and LMA, ii) when two communicating MNs are attached to different MAGs but to the same LMA, and iii) when two communicating MNs are attached to the same MAG but have different LMAs. In these three cases, data traffic between the two mobile nodes does not traverse the LMA(s), thus providing some form of pathoptimizationoptimization, since the traffic is locally routed at the edge. The main disadvantage of this approach is that it only tackles the MN-to- MN communicationscenario,scenario and only under certain circumstances. An interesting extension that can also be used to facilitate the deployment of network-based mobility protocols in a distributed mobility management environment is the support of an LMA runtime assignment described in [RFC6463]. This extension specifies a runtimeLocal Mobility AnchorLMA assignment functionality and corresponding mobility options for Proxy Mobile IPv6. This runtimeLocal Mobility AnchorLMA assignment takes place during the Proxy Binding Update / Proxy Binding Acknowledgment message exchange between a mobile access gateway anda local mobility anchor.an LMA. While this mechanism is mainly aimed for load-balancing purposes, it can also be used to select an optimal LMA from the routing point of view. A runtime LMA assignment can be used to change the assigned LMA of an MN, for example, in cases when the mobile node does not have any activesession,session or when the running sessions can survive an IP address change. Note that several possible dynamicLocal Mobility AnchorLMA discovery solutions can be used, as described in [RFC6097]. 4.3. Flattening 3GPPmobile network approachesMobile Network Approaches The3rd Generation Partnership Project (3GPP)3GPP is the standards development organization that specifies the 3rd generation mobile network and the Evolved Packet System (EPS) [SDO-3GPP.23.402], which mainly comprises the Evolved Packet Core (EPC) and a new radio access network, usually referred to as LTE (Long Term Evolution). Architecturally, the 3GPPEvolved Packet Core (EPC)EPC network is similar to an IP wireless network running PMIPv6 or MIPv6, as it relies on the Packet Data Network Gateway(PGW)(P-GW) anchoring services to provide mobile nodes with mobility support (see Figure 5). There are client-based and network-based mobility solutions in 3GPP, which for simplicity will be analyzed together. We next describe how 3GPP mobility protocols and several other completed or ongoing extensions can be deployed to meet some of the DMM requirements [RFC7333]. +---------------------------------------------------------+ | PCRF | +-----------+--------------------------+----------------+-+ | | | +----+ +-----------+------------+ +--------+-----------+ +-+-+ | | | +-+ | | Core Network | | | | | | +------+ |S|__ | | +--------+ +---+ | | | | | | |GERAN/|_|G| \ | | | HSS | | | | | | | +-----+ UTRAN| |S| \ | | +---+----+ | | | | E | | | | +------+ |N| +-+-+ | | | | | | | x | | | | +-+ /|MME| | | +---+----+ | | | | t | | | | +---------+ / +---+ | | | 3GPP | | | | | e | | +-----+ E-UTRAN |/ | | | AAA | | | | | r | | | | +---------+\ | | | SERVER | | | | | n | | | | \+---++----+ | | +--------+ | | | | a | | | | 3GPP AN\|SGW+-----\|S-GW+---- S5---------------+ P | | | l | | | |+---++----+ | | |G- | | | | | | +------------------------+ | |WG | | | I | | UE | | | W | | | P | | | +------------------------+ | | +-----+ | | | |+-------------+ +------+| | | | | | n | | | || Untrusted +-+ ePDG +-S2b---------------+ | | | e | | +---+| non-3GPP AN | +------+| | | | | | t | | | |+-------------+ | | | | | | w | | | +------------------------+ | | | | | o | | | | | | | | r | | | +------------------------+ | | | | | k | | +---+ Trusted non-3GPP AN +-S2a--------------+ | | | s | | | +------------------------+ | | | | | | | | | +-+-+ | | | | +--------------------------S2c--------------------| | | | | | | | | | +----+ +--------------------+ +---+ where E-UTRAN - Evolved Universal Terrestrial Radio Access Network GERAN - GSM EDGE Radio Access Network HSS - Home Subscriber Server MME - Mobility Management Entity PCRF - Policy and Charging Rule Function SGSN - Serving GPRS Support Node UTRAN - Universal Terrestrial Radio Access Network Figure 5: EPS(non-roaming) architecture overview(Non-roaming) Architecture Overview The GPRS Tunneling Protocol (GTP) [SDO-3GPP.29.060] [SDO-3GPP.29.281] [SDO-3GPP.29.274] is a network-based mobility protocol specified for 3GPP networks (S2a, S2b,S5S5, and S8 interfaces). In a similar way to PMIPv6, it can handle mobility without requiring the involvement of the mobile nodes. In this case, the mobile node functionality is provided in a proxy manner by the Serving Data Gateway(SGW),(S-GW), Evolved Packet Data Gateway (ePDG), or Trusted Wireless Access Gateway (TWAG [SDO-3GPP.23.402]) . 3GPP specifications also include client-based mobility support, based on adopting the use of Dual-Stack Mobile IPv6 (DSMIPv6) [RFC5555] for the S2c interface [SDO-3GPP.24.303]. In this case, the User Equipment (UE) implements the binding update functionality, while the home agent role is played by thePGW.P-GW. A Local IP Access (LIPA) and Selected IP Traffic Offload (SIPTO) enabled network [SDO-3GPP.23.401] allows offloading some IP services at the local access network above the Radio Access Network (RAN) without the need to travel back to thePGWP-GW (see Figure 6). +---------+ IP traffic to mobile operator's CN | User |....................................(Operator's CN) | Equipm. |.................. +---------+ . Local IP traffic . +-----------+ |Residential| |enterprise | |IP network | +-----------+ Figure 6: LIPAscenarioScenario SIPTO enables an operator to offload certain types of traffic at a network node close to the UE's point of attachment to the accessnetwork,network. This is done by selecting a set of GWs(SGW(S-GW andPGW)P-GW1 in the figure below) that are geographically/topologically close to the UE's point of attachment. SIPTO Traffic | . . +-------+ +------+ |L-PGWP-GW1 | ---- | MME | +-------+ / +------+ | / +------+ +-----++-----+/ +-----++------+/ +-------+ | UE |.....| eNB|....| SGW|...| S-GW |........|PGW |....P-GW2 |... CN Traffic +------+ +-----++-----+ +-----++------+ +-------+ Figure 7: SIPTOarchitectureArchitecture LIPA, on the other hand, enables an IP addressable UE connected via a HomeeNBevolved Network B (HeNB) to access other IP addressable entities in the same residential/enterprise IP network without traversing the mobile operator's network core in the user plane. In order to achieve this, a Local GW(LGW)(L-GW) collocated with the HeNB is used.LIPA is established byTo establish LIPA, the UErequestingrequests a new Public Data Network (PDN) connection to an access point name for which LIPA is permitted,andthe networkselectingselects the Local GW associated with theHeNBHeNB, andenablingthe network enables a directuser planeuser-plane path between the Local GW and the HeNB.+---------------+------++------------+ +------+ +----------+ +-------------+ ===== |Residential | | HeNB | | Backhaul | |Mobile | ( IP ) |Enterprise |..|------|..| |..|Operator |..(Network) |Network | |LGWL-GW | | | |Core network | =======+---------------+------++------------+ +------+ +----------+ +-------------+ / | / +-----+ | UE | +-----+ Figure 8: LIPAarchitectureArchitecture The 3GPP architecture specifications also provide mechanisms to allow discovery and selection of gateways [SDO-3GPP.29.303]. These mechanisms enable decisionstakingthat take into consideration topological location and gateway collocation aspects, by relying upon the DNS as a "location database." Both SIPTO and LIPA have a very limited mobility support, especially in 3GPP specifications up to Rel-12. Briefly, LIPA mobility support is limited to handovers between HeNBs that are managed by the sameLGWL-GW (i.e., mobility within the local domain). There is no guarantee of IP session continuity for SIPTO. 5. GapanalysisAnalysis This section identifies the limitations in the current practices, described in Section 4, with respect to the DMM requirements listed in [RFC7333]. 5.1. Distributedmobility managementMobility Management - REQ1 According to requirement REQ1 stated in [RFC7333], IP mobility, networkaccessaccess, and forwarding solutions provided by DMM must make it possible for traffic to avoid traversing a single mobility anchor far from the optimal route. From the analysis performed in Section 4, a DMM deployment can meet the requirement "REQ1 Distributed mobility management" usually relying on the following functions: o Multiple (distributed) anchoring: ability to anchor different sessions of a single mobile node at different anchors. In order to provide improved routing, some anchors might need to be placed closer to the mobile node or the corresponding node. o Dynamic anchor assignment/re-location: ability to i) assign the initial anchor, and ii) dynamically change the initially assigned anchor and/or assign a new one (this may also require the transfer of mobility context between anchors). This can be achieved either by changing anchor for all ongoing sessions or by assigning new anchors just for new sessions. GAP1-1: Both the main client- and network-based IP mobilityprotocols, namely (DS)MIPv6protocols (namely, MIPv6, DSMIPv6, andPMIPv6PMIPv6) allow deploying multiple anchors (i.e., home agents and localized mobility anchors), thereby providing the multiple anchoring function. However, existing solutions only provide an initial anchor assignment, thus the lack of dynamic anchor change/new anchor assignment is a gap. Neither the HA switch nor the LMA runtime assignment allows changing the anchor during an ongoing session. This actually comprises several gaps: ability to perform anchor assignment at any time (not only at the initial MN's attachment), ability of the current anchor to initiate/trigger the relocation, and ability to transfer registration context between anchors. GAP1-2: Dynamic anchor assignment may lead the MN to manage different mobility sessions served by different mobility anchors. This is not an issue withclient basedclient-based mobilitymanagementmanagement, where the mobility client natively knows the anchor associated with each of its mobility sessions. However, there is one gap, as the MN should be capable of handling IP addresses in a DMM-friendly way, meaning that the MN can perform smart source address selection (i.e., deprecating IP addresses from previous mobilityanchors,anchors so they are not used for new sessions). Besides, managing different mobility sessions served by different mobility anchors may raise issues withnetwork basednetwork-based mobility management. In this case, the mobile client located in the network, e.g., MAG, usually retrieves the MN's anchor from the MN's policyprofileprofile, as described in Section 6.2 of [RFC5213]. Currently, the MN's policy profile implicitly assumes a single serving anchor and thus does not maintain the association between home network prefix and anchor. GAP1-3: The consequence of the distribution of the mobility anchors is that there might be more than one available anchor for a mobile node to use, which leads to an anchor discovery and selection issue. Currently, there is no efficient mechanism specified to allow the dynamic discovery of the presence of nodes that can play the anchor role,discoveringthe discovery of theircapabilitiescapabilities, andselectingthe selection of the most suitable one. There is also no mechanism to allow selecting a node that is currently anchoring a given home address/prefix (capability sometimes required to meet REQ#2). However, there are some mechanisms that could help to discover anchors, such as the Dynamic Home Agent Address Discovery (DHAAD) [RFC6275], the use of the home agent flag (H) in Router Advertisements (which indicates that the router sending the Router Advertisement is also functioning as a Mobile IPv6 home agent on the link) or the MAP option in Router Advertisements defined by HMIPv6. Note that there are 3GPP mechanisms providing that functionality defined in [SDO-3GPP.29.303]. Regarding the ability to transfer registration context between anchors, there are already some solutions that could be reused or adapted to fill that gap, such as Fast Handovers for Mobile IPv6 [RFC5568]--to enable traffic redirection from the old to the newanchor --,anchor, the Context TransferprotocolProtocol [RFC4067]--to enable the required transfer of registration information betweenanchors --,anchors, or the Handover Keying architecture solutions[RFC6697],[RFC6697] to speed up there-authenticationre- authentication process after a change of anchor. Note that some extensions might be needed in the context of DMM, as these protocols were designed in the context of centralized client IPmobility, focusingmobility (focusing on the accessre-attachmentreattachment andauthentication.authentication). GAP1-4: Also note that REQ1 is intended to prevent thedata planedata-plane traffic from taking a suboptimal route. Distributed processing of the traffic may then be needed only in the data plane. Provision of this capability for distributed processing should not conflict with the use of a centralized control plane. Othercontrol planecontrol-plane solutionssuch(such as charging, lawful interception,etc.etc.) should not be constrained by the DMM solution. On the otherhandhand, combining thecontrol planecontrol-plane anddata plane forwarding management (FM)data-plane FM function may limit the choice of solutions to those that distribute both data plane and control plane together. In order to enable distribution of only the data plane without distributing the control plane, it would be necessary to split the forwarding management function into thecontrol planecontrol-plane (FM-CP) anddatadata- plane (FM-DP) components; there is currently a gap here. 5.2. Bypassablenetwork-layer mobility supportNetwork-Layer Mobility Support foreach application sessionEach Application Session - REQ2 The requirement REQ2 for "bypassable network-layer mobility support for each application session" introduced in [RFC7333] requires flexibility in determining whether network-layer mobility support is needed. This requirement enables one to choose whether or not to use network-layer mobility support. The following two functions are also needed: o Dynamically assign/relocate anchor:aA mobility anchor is assigned only to sessionswhichthat use the network-layer mobility support. The MN may thus manage more than one session; some of them may be associated with anchored IP address(es), while the others may be associated with local IP address(es). o Multiple IP address management:thisThis function is related to the preceding item and is about the ability of the mobile node to simultaneously use multiple IP addresses and select the best one (from an anchoring point of view) to use on a per- session/application/service basis. This requires MN to acquire information regarding the properties of the available IP addresses. GAP2-1: The dynamic anchor assignment/relocation needs to ensure that IP address continuity is guaranteed for sessions thatusesuse such mobility support (e.g., in some scenarios, the provision of mobility locally within a limited area might be enough from the point of view of the mobile node or theapplication point of view)application) at the relocated anchor. Implicitly, DMM may release the needed resources when no applications are using the network-layer mobilitysupport,support. DMMmay releaseis then potentially required to know which sessions at theneeded resources.mobile node are active and are using the mobility support. Typically, this is known only by the MN (e.g., by its connection manager) and would require some signaling support, such as socket API extensions, from applications to indicate to the IP stack whether or not mobility support is required. This may imply having the knowledge of which sessions at the mobile node are active and are using the mobility support. This is something typically known only by the MN, e.g., by its connection manager, and would also typically require some signalingsupportsupport, such as socket APIextensionsextensions, from applications to indicate to the IP stack whether mobility support is required or not. Therefore, (part of) this knowledge might need to be transferred to/shared with the network. GAP2-2:MultipleManagement of multiple IPaddress managementaddresses provides the MN with the choice to pick the correctaddress, e.g.,address (e.g., from those provided or not provided with mobilitysupport,support) depending on the application requirements. When usingclient basedclient-based mobility management, themobile nodeMN is itself aware of the anchoring capabilities of its assigned IP addresses. This is not necessarily the case withnetwork basednetwork-based IP mobilitymanagement;management, as current mechanisms do not allow the MN to be aware of the properties of its IP addresses. For example, the MN does not know whether or not the allocated IP addresses are anchored. However, there areproposals,proposals such as[I-D.bhandari-dhc-class-based-prefix], [I-D.korhonen-6man-prefix-properties][CLASS-PREFIX], [PREFIX-PROPERTIES], and[I-D.anipko-mif-mpvd-arch] that[MULTI-ARCH], where the network could indicate suchIP addressproperties during IP address assignment procedures.Although these individual efforts exist and theyThese proposals could be considered as attempts to fix thegap, there is no solution adopted as a work item within any IETF working group.gap. GAP2-3: The handling of mobility management to the granularity of an individual session of a user/device needs proper session identification in addition to user/device identification. 5.3. IPv6deploymentDeployment - REQ3 This requirement states that DMM solutions should primarily target IPv6 as the primary deployment environment. IPv4 support is not considered mandatory and solutions should not be tailored specifically to support IPv4. All analyzed DMM practices support IPv6. Some of them, such as MIPv6/NEMOincluding(including the support of dynamic HAselection,selection), MOBIKE, and SIPTO also have IPv4 support. Some solutions, e.g., PMIPv6, also have some limited IPv4 support. In conclusion, this requirement is met by existing DMM practices. 5.4. Consideringexisting mobility protocolsExisting Mobility Protocols - REQ4 A DMM solution must first consider reusing and extending IETF- standardized protocols before specifying new protocols. As stated in [RFC7333], a DMM solution could reuse existing IETF and standardized protocols before specifying new protocols. Besides, Section 4 of this document discusses various ways to flatten and distribute current mobility solutions. Actually, nothing prevents the distribution of mobility functions within IP mobility protocols. However, as discussed inSectionSections 5.1 andSection5.2, limitations exist. The 3GPPdata planedata-plane anchoring function, i.e., thePGW,P-GW, can also bedistributed,distributed but withlimitations; e.g.,limitations such as no anchoringrelocation,relocation and no context transfer between anchors and the centralized control plane. The 3GPP architecture is also going in the direction of flattening with SIPTO and LIPA, though they do not provide full mobility support. For example, mobility support for SIPTO traffic can be rather limited, and offloaded traffic cannot access operator services. Thus, the operator must be very careful in selecting which traffic to offload. 5.5. Coexistence withdeployed networks/hostsDeployed Networks/Hosts andoperabilityOperability acrossdifferent networksDifferent Networks - REQ5 According to [RFC7333], DMM implementations are required toco-existcoexist with existing network deployments, endhostshosts, and routers. Additionally, DMM solutions are expected to work across different networks, possibly operated as separate administrative domains, when the necessary mobility management signaling, forwarding, and network access are allowed by the trust relationship between them. All current mobility protocols canco-existcoexist with existing network deployments and end hosts. There is no gap between existing mobility protocols and this requirement. 5.6. Operation andmanagement considerationsManagement Considerations - REQ6 This requirement actually comprises several aspects, as summarized below. o A DMM solution needs to consider configuring a device, monitoring the current operational state of a device, responding to events that impact the device, possibly by modifying theconfigurationconfiguration, and storing the data in a format that can be analyzed later. o A DMM solution has to describe in what environment and how it can be scalably deployed and managed. o A DMM solution has to support mechanisms to test if the DMM solution is working properly. o A DMM solution is expected to expose the operational state of DMM to the administrators of the DMM entities. o A DMM solution, which supports flow mobility, is also expected to support means to correlate the flow routing policies and the observed forwarding actions. o A DMM solution is expected to support mechanisms to check the liveness of the forwarding path. o A DMM solution has to provide fault management and monitoring mechanisms to manage situations where update of the mobility session or the data path fails. o A DMM solution is expected to be able to monitor the usage of the DMM protocol. o DMM solutions have to support standardized configuration withNETCONF [RFC6241],Network Configuration Protocol (NETCONF) [RFC6241] using YANG [RFC6020] modules, which are expected to be created for DMM when needed for such configuration. GAP6-1: Existing mobility management protocols have not thoroughly documented how, or whether, they support the above list of operation and management considerations. Each of the above needs to be considered from the beginning in a DMM solution. GAP6-2: Managementinformation baseInformation Base (MIB) objects are currently defined in [RFC4295] for MIPv6 and in [RFC6475] for PMIPv6. Standardized configuration with NETCONF [RFC6241], using YANG [RFC6020]modulesmodules, is lacking. 5.7. SecurityconsiderationsConsiderations - REQ7 As stated in [RFC7333], a DMM solution has to support any security protocols and mechanisms needed to secure the network and to make continuous security improvements. In addition, with security taken into consideration early in the design, a DMM solution cannot introduce new securityrisks,risks or privacy concerns, or amplify existing securityrisks,risks that cannot be mitigated by existing security protocols and mechanisms. Any solutions that are intended to fill in gaps identified in this document need to meet this requirement. At present, it does not appear that using existing solutions to support DMM has introduced any new security issues. For example, Mobile IPv6 defines security features to protect binding updates both to home agents and correspondent nodes. It also defines mechanisms to protect the data packets transmission for Mobile IPv6 users. Proxy Mobile IPv6 and other variations of mobile IP also have similar security considerations. 5.8. Multicast Considerations - REQ8 It is stated in [RFC7333] that DMM solutions are expected to allow the development of multicast solutions to avoid network inefficiency in multicast traffic delivery. Current IP mobility solutions address mainly the mobility problem for unicast traffic. Solutions relying on the use of an anchor point for tunneling multicast traffic down to the access router, or to the mobile node, introduce the so-called "tunnel convergenceproblem."problem". This means that multiple instances of the same multicast traffic can converge to the same node, diminishing the advantage of using multicast protocols. [RFC6224] documents a baseline solution for the previous issue, and [RFC7028] documents a routing optimization solution. The baseline solution suggests deploying a Multicast Listener Discovery (MLD) proxy function at theMAG,MAG and either a multicast router or another MLD proxy function at the LMA. The routing optimization solution describes an architecture where a dedicated multicast tree mobility anchor or a direct routing option can be used to avoid the tunnel convergence problem. Besides the solutions highlighted before, there are no other mechanisms for mobility protocols to address the multicast tunnel convergence problem. 5.9. Summary We next list the main gaps identified from the analysis performed above: GAP1-1: Existing solutions only provide an optimal initial anchor assignment, a gap being the lack of dynamic anchor change/ new anchor assignment. Neither the HA switch nor the LMA runtime assignment allows changing the anchor during an ongoing session. MOBIKE allows change ofGWGW, but its applicability has been scoped to a very narrow use case. GAP1-2: The MN needs to be able to perform source address selection.ProperA proper mechanism to inform the MN islacking to provide thelacking, so there is not a basis for performing thepropercorrect selection. GAP1-3: Currently, there is no efficient mechanism specified by the IETF that allows the dynamic discovery of the presence of nodes that can play the role of anchor, discover theircapabilitiescapabilities, and allow the selection of the most suitable one. However, the following mechanisms could help discovering anchors: Dynamic Home Agent Address Discovery (DHAAD):theThe use of the home agent(H)flag (H) in Router Advertisements (which indicates that the router sending the Router Advertisement is also functioning as a Mobile IPv6 home agent on the link) and the MAP option in Router Advertisements defined by HMIPv6. GAP1-4: While existing network-based DMM practices may allow the deployment of multiple LMAs and dynamically select the best one, this requires to still keep some centralization in the controlplane,plane to access the policy database (as defined inRFC5213).RFC 5213). Although[I-D.ietf-netext-pmip-cp-up-separation][RFC7389] allows a MAG to perform splitting of its control and user planes, there is a lack of solutions/extensions that support a clearcontrolcontrol- anddatadata- plane separation for IETF IP mobility protocols in a DMM context. GAP2-1: The information of which sessions at the mobile node are active and are using the mobility support need to be transferredtoto, or sharedwithwith, the network. Such mechanism has not been defined. GAP2-2: The mobile node needs to simultaneously use multiple IP addresses with different properties. There is a lack of mechanism to expose this information to the mobilenodenode, which can then update accordingly its source address selection mechanism. GAP2-3: The handling of mobility management has not been to the granularity of an individual session of a user/device before. The combination of session identification and user/ device identification may be lacking. GAP6-1: Mobility management protocols have not thoroughly documented how, or whether, they support the following list of operation and management considerations: * A DMM solution needs to consider configuring a device, monitoring the current operational state of a device, and responding to events that impact thedevice,device possibly by modifying the configuration and storing the data in a format that can be analyzed later. * A DMM solution has to describe in whatenvironmentenvironment, andhowhow, it can be scalably deployed and managed. * A DMM solution has to support mechanisms to test if the DMM solution is working properly. * A DMM solution is expected to expose the operational state of DMM to the administrators of the DMM entities. * A DMM solution, which supports flow mobility, is also expected to support means to correlate the flow routing policies and the observed forwarding actions. * A DMM solution is expected to support mechanisms to check the liveness of the forwarding path. * A DMM solution has to provide fault management and monitoring mechanisms to manage situations where update of the mobility session or the data path fails. * A DMM solution is expected to be able to monitor the usage of the DMM protocol. * DMM solutions have to support standardized configuration with NETCONF [RFC6241], using YANG [RFC6020] modules, which are expected to be created for DMM when needed for such configuration. GAP6-2: Managementinformation baseInformation Base (MIB) objects are currently defined in [RFC4295] for MIPv6 and in [RFC6475] for PMIPv6. Standardized configuration with NETCONF [RFC6241], using YANG [RFC6020]modulesmodules, is lacking. 6. Security Considerations The deployment of DMM using existing IP mobility protocols raises similar security threats as those encountered in centralized mobility management systems. Without authentication, a malicious node could forge signaling messages and redirect traffic from its legitimate path. This would amount to adenial of servicedenial-of-service attack against the specific node or nodes for which the traffic is intended. Distributed mobility anchoring, while keeping current security mechanisms, might require more security associations to be managed by the mobility management entities, potentially leading to scalability and performance issues. Moreover, distributed mobility anchoring makes mobility security problems more complex, since traffic redirection requests might come from previously unconsidered origins, thus leading to distributed points of attack. Consequently, the DMM security design needs to account for the distribution of security associations between additional mobility entities and fulfill the security requirement of [RFC7333]. 7.Contributors This document has benefited to valuable contributions from Charles E. Perkins Huawei Technologies EMail: charliep@computer.org who had produced a matrix to compare the different mobility protocols and extensions against a list of desired DMM properties. They were useful inputs in the early work of gap analysis. He had continued to give suggestions as well as extensive review comments to this documents. 8.References8.1.7.1. Normative References [RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support in IPv6", RFC 6275, July2011.2011, <http://www.rfc-editor.org/info/rfc6275>. [RFC7333] Chan, H., Liu, D., Seite, P., Yokota, H., and J. Korhonen, "Requirements for Distributed Mobility Management", RFC 7333, August2014. 8.2.2014, <http://www.rfc-editor.org/info/rfc7333>. 7.2. Informative References[I-D.anipko-mif-mpvd-arch] Anipko, D., "Multiple Provisioning Domain Architecture", draft-anipko-mif-mpvd-arch-05 (work in progress), November 2013. [I-D.bhandari-dhc-class-based-prefix][CLASS-PREFIX] Systems, C., Halwasia, G., Gundavelli, S., Deng, H., Thiebaut, L., Korhonen, J., and I. Farrer, "DHCPv6 class based prefix",draft-bhandari-dhc-class-based-prefix-05 (workWork inprogress),Progress, draft-bhandari-dhc-class- based-prefix-05, July 2013.[I-D.gundavelli-v6ops-community-wifi-svcs][COMMUNITY-WIFI] Gundavelli, S., Grayson, M., Seite, P., and Y. Lee, "Service Provider Wi-Fi Services Over Residential Architectures",draft-gundavelli-v6ops-community-wifi- svcs-06 (workWork inprogress),Progress, draft-gundavelli-v6ops- community-wifi-svcs-06, April 2013.[I-D.ietf-netext-pmip-cp-up-separation] Wakikawa, R., Pazhyannur, R., Gundavelli, S., and C. Perkins, "Separation of Control and User Plane for Proxy Mobile IPv6", draft-ietf-netext-pmip-cp-up-separation-07 (work in progress), August 2014. [I-D.korhonen-6man-prefix-properties] Korhonen, J., Patil, B., Gundavelli, S., Seite, P., and D. Liu, "IPv6 Prefix Properties", draft-korhonen-6man-prefix- properties-02 (work in progress), July 2013.[IEEE.802-16.2009] IEEE, "IEEE Standard for Local and metropolitan area networks Part 16: Air Interface for Broadband Wireless Access Systems", IEEE Standard 802.16, 2009, <http://standards.ieee.org/getieee802/ download/802.16-2009.pdf>. [MULTI-ARCH] Anipko, D., Ed., "Multiple Provisioning Domain Architecture", Work in Progress, draft-ietf-mif-mpvd-arch- 08, January 2015. [PREFIX-PROPERTIES] Korhonen, J., Patil, B., Gundavelli, S., Seite, P., and D. Liu, "IPv6 Prefix Properties", Work in Progress, draft- korhonen-6man-prefix-properties-02, July 2013. [RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, January2005.2005, <http://www.rfc-editor.org/info/rfc3963>. [RFC4066] Liebsch, M., Singh, A., Chaskar, H., Funato, D., and E. Shim, "Candidate Access Router Discovery (CARD)", RFC 4066, July2005.2005, <http://www.rfc-editor.org/info/rfc4066>. [RFC4067] Loughney, J., Nakhjiri, M., Perkins, C., and R. Koodli, "Context Transfer Protocol (CXTP)", RFC 4067, July2005.2005, <http://www.rfc-editor.org/info/rfc4067>. [RFC4225] Nikander, P., Arkko, J., Aura, T., Montenegro, G., and E. Nordmark, "Mobile IP Version 6 Route Optimization Security Design Background", RFC 4225, December2005.2005, <http://www.rfc-editor.org/info/rfc4225>. [RFC4295] Keeni, G., Koide, K., Nagami, K., and S. Gundavelli, "Mobile IPv6 Management Information Base", RFC 4295, April2006.2006, <http://www.rfc-editor.org/info/rfc4295>. [RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol (MOBIKE)", RFC 4555, June2006.2006, <http://www.rfc-editor.org/info/rfc4555>. [RFC4640] Patel, A. and G. Giaretta, "Problem Statement for bootstrapping Mobile IPv6 (MIPv6)", RFC 4640, September2006.2006, <http://www.rfc-editor.org/info/rfc4640>. [RFC4889] Ng, C., Zhao, F., Watari, M., and P. Thubert, "Network Mobility Route Optimization Solution Space Analysis", RFC 4889, July2007.2007, <http://www.rfc-editor.org/info/rfc4889>. [RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 4960, September2007.2007, <http://www.rfc-editor.org/info/rfc4960>. [RFC5014] Nordmark, E., Chakrabarti, S., and J. Laganier, "IPv6 Socket API for Source Address Selection", RFC 5014, September2007.2007, <http://www.rfc-editor.org/info/rfc5014>. [RFC5026] Giaretta, G., Kempf, J., and V. Devarapalli, "Mobile IPv6 Bootstrapping in Split Scenario", RFC 5026, October2007.2007, <http://www.rfc-editor.org/info/rfc5026>. [RFC5142] Haley, B., Devarapalli, V., Deng, H., and J. Kempf, "Mobility Header Home Agent Switch Message", RFC 5142, January2008.2008, <http://www.rfc-editor.org/info/rfc5142>. [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, August2008.2008, <http://www.rfc-editor.org/info/rfc5213>. [RFC5380] Soliman, H., Castelluccia, C., ElMalki, K., and L. Bellier, "Hierarchical Mobile IPv6 (HMIPv6) Mobility Management", RFC 5380, October2008.2008, <http://www.rfc-editor.org/info/rfc5380>. [RFC5555] Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and Routers", RFC 5555, June2009.2009, <http://www.rfc-editor.org/info/rfc5555>. [RFC5568] Koodli, R., "Mobile IPv6 Fast Handovers", RFC 5568, July2009.2009, <http://www.rfc-editor.org/info/rfc5568>. [RFC5844] Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy Mobile IPv6", RFC 5844, May2010. [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 5996, September 2010.2010, <http://www.rfc-editor.org/info/rfc5844>. [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, October2010.2010, <http://www.rfc-editor.org/info/rfc6020>. [RFC6097] Korhonen, J. and V. Devarapalli, "Local Mobility Anchor (LMA) Discovery for Proxy Mobile IPv6", RFC 6097, February2011.2011, <http://www.rfc-editor.org/info/rfc6097>. [RFC6224] Schmidt, T., Waehlisch, M., and S. Krishnan, "Base Deployment for Multicast Listener Support in Proxy Mobile IPv6 (PMIPv6) Domains", RFC 6224, April2011.2011, <http://www.rfc-editor.org/info/rfc6224>. [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. Bierman, "Network Configuration Protocol (NETCONF)", RFC 6241, June2011.2011, <http://www.rfc-editor.org/info/rfc6241>. [RFC6463] Korhonen, J., Gundavelli, S., Yokota, H., and X. Cui, "Runtime Local Mobility Anchor (LMA) Assignment Support for Proxy Mobile IPv6", RFC 6463, February2012.2012, <http://www.rfc-editor.org/info/rfc6463>. [RFC6475] Keeni, G., Koide, K., Gundavelli, S., and R. Wakikawa, "Proxy Mobile IPv6 Management Information Base", RFC 6475, May2012.2012, <http://www.rfc-editor.org/info/rfc6475>. [RFC6611] Chowdhury, K. and A. Yegin, "Mobile IPv6 (MIPv6) Bootstrapping for the Integrated Scenario", RFC 6611, May2012.2012, <http://www.rfc-editor.org/info/rfc6611>. [RFC6697] Zorn, G., Wu, Q., Taylor, T., Nir, Y., Hoeper, K., and S. Decugis, "Handover Keying (HOKEY) Architecture Design", RFC 6697, July2012.2012, <http://www.rfc-editor.org/info/rfc6697>. [RFC6705] Krishnan, S., Koodli, R., Loureiro, P., Wu, Q., and A. Dutta, "Localized Routing for Proxy Mobile IPv6", RFC 6705, September2012.2012, <http://www.rfc-editor.org/info/rfc6705>. [RFC6724] Thaler, D., Draves, R., Matsumoto, A., and T. Chown, "Default Address Selection for Internet Protocol Version 6 (IPv6)", RFC 6724, September2012.2012, <http://www.rfc-editor.org/info/rfc6724>. [RFC7028] Zuniga, JC., Contreras, LM., Bernardos, CJ., Jeon, S., and Y. Kim, "Multicast Mobility Routing Optimizations for Proxy Mobile IPv6", RFC 7028, September2013.2013, <http://www.rfc-editor.org/info/rfc7028>. [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. Kivinen, "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 7296, October 2014, <http://www.rfc-editor.org/info/rfc7296>. [RFC7389] Wakikawa, R., Pazhyannur, R., Gundavelli, S., and C. Perkins, "Separation of Control and User Plane for Proxy Mobile IPv6", RFC 7389, October 2014, <http://www.rfc-editor.org/info/rfc7389>. [SDO-3GPP.23.401] 3GPP, "General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access", 3GPP TS 23.401 10.10.0, March 2013. [SDO-3GPP.23.402] 3GPP, "Architecture enhancements for non-3GPP accesses", 3GPP TS 23.402 10.8.0, September 2012. [SDO-3GPP.24.303] 3GPP, "Mobility management based on Dual-Stack Mobile IPv6; Stage 3", 3GPP TS 24.303 10.0.0, June 2013. [SDO-3GPP.29.060] 3GPP, "General Packet Radio Service (GPRS); GPRS Tunnelling Protocol (GTP) across the Gn and Gp interface", 3GPP TS 29.060 3.19.0, March 2004. [SDO-3GPP.29.274] 3GPP, "3GPP Evolved Packet System (EPS); Evolved General Packet Radio Service (GPRS) Tunnelling Protocol for Control plane (GTPv2-C); Stage 3", 3GPP TS 29.274 10.11.0, June 2013. [SDO-3GPP.29.281] 3GPP, "General Packet Radio System (GPRS) Tunnelling Protocol User Plane (GTPv1-U)", 3GPP TS 29.281 10.3.0, September 2011. [SDO-3GPP.29.303] 3GPP, "Domain Name System Procedures; Stage 3", 3GPP TS 29.303 10.4.0, September 2012. Contributors This document has benefited due to valuable contributions from Charles E. Perkins Huawei Technologies EMail: charliep@computer.org who produced a matrix to compare the different mobility protocols and extensions against a list of desired DMM properties. They were useful inputs in the early work of gap analysis. He continued to give suggestions as well as extensively review comments for this document. Authors' Addresses Dapeng Liu (editor) China MobileUnit2,Unit 2, 28 Xuanwumenxi Ave, Xuanwu District Beijing 100053 ChinaEmail:EMail: liudapeng@chinamobile.com Juan Carlos Zuniga (editor) InterDigital Communications, LLC 1000 Sherbrooke Street West, 10th floor Montreal, Quebec H3A 3G4 CanadaEmail:EMail: JuanCarlos.Zuniga@InterDigital.com URI: http://www.InterDigital.com/ Pierrick Seite Orange 4, rue du Clos Courtel, BP 91226 Cesson-Sevigne 35512 FranceEmail:EMail: pierrick.seite@orange.com H Anthony Chan Huawei Technologies 5340 Legacy Dr. Building 3 Plano, TX 75024USA Email:United States EMail: h.a.chan@ieee.org Carlos J. Bernardos Universidad Carlos III de Madrid Av. Universidad, 30 Leganes, Madrid 28911 Spain Phone: +34 91624 6236Email:EMail: cjbc@it.uc3m.es URI: http://www.it.uc3m.es/cjbc/