idnits 2.17.1 draft-ietf-dmm-best-practices-gap-analysis-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 10, 2014) is 3508 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 4960 (Obsoleted by RFC 9260) -- Obsolete informational reference (is this intentional?): RFC 5996 (Obsoleted by RFC 7296) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DMM D. Liu, Ed. 3 Internet-Draft China Mobile 4 Intended status: Informational JC. Zuniga, Ed. 5 Expires: March 14, 2015 InterDigital 6 P. Seite 7 Orange 8 H. Chan 9 Huawei Technologies 10 CJ. Bernardos 11 UC3M 12 September 10, 2014 14 Distributed Mobility Management: Current practices and gap analysis 15 draft-ietf-dmm-best-practices-gap-analysis-07 17 Abstract 19 This document analyzes deployment practices of existing IP mobility 20 protocols in a distributed mobility management environment. It then 21 identifies existing limitations when compared to the requirements 22 defined for a distributed mobility management solution. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on March 14, 2015. 41 Copyright Notice 43 Copyright (c) 2014 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. Functions of existing mobility protocols . . . . . . . . . . 3 61 4. DMM practices . . . . . . . . . . . . . . . . . . . . . . . . 5 62 4.1. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 5 63 4.2. IP flat wireless network . . . . . . . . . . . . . . . . 6 64 4.2.1. Host-based IP DMM practices . . . . . . . . . . . . . 7 65 4.2.2. Network-based IP DMM practices . . . . . . . . . . . 12 66 4.3. Flattening 3GPP mobile network approaches . . . . . . . . 14 67 5. Gap analysis . . . . . . . . . . . . . . . . . . . . . . . . 17 68 5.1. Distributed mobility management - REQ1 . . . . . . . . . 17 69 5.2. Bypassable network-layer mobility support for each 70 application session - REQ2 . . . . . . . . . . . . . . . 19 71 5.3. IPv6 deployment - REQ3 . . . . . . . . . . . . . . . . . 21 72 5.4. Existing mobility protocols - REQ4 . . . . . . . . . . . 21 73 5.5. Coexistence with deployed networks/hosts and operability 74 across different networks- REQ5 . . . . . . . . . . . . . 21 75 5.6. Operation and management considerations - REQ6 . . . . . 22 76 5.7. Security considerations - REQ7 . . . . . . . . . . . . . 23 77 5.8. Multicast - REQ8 . . . . . . . . . . . . . . . . . . . . 23 78 5.9. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 23 79 6. Security Considerations . . . . . . . . . . . . . . . . . . . 24 80 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 81 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 25 82 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 83 9.1. Normative References . . . . . . . . . . . . . . . . . . 25 84 9.2. Informative References . . . . . . . . . . . . . . . . . 25 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 87 1. Introduction 89 The centralized deployment of mobility anchors to manage IP sessions 90 pose several problems. In order to address these problems, a 91 distributed mobility management (DMM) architecture has been proposed. 92 This document investigates whether it is feasible to deploy current 93 IP mobility protocols in a DMM scenario in a way that can fulfill the 94 requirements as defined in [RFC7333]. It discusses current 95 deployment practices of existing mobility protocols and identifies 96 the limitations (gaps) in these practices from the standpoint of 97 satisfying DMM requirements. 99 The rest of this document is organized as follows. Section 3 100 analyzes existing IP mobility protocols by examining their functions 101 and how these functions can be configured and used to work in a DMM 102 environment. Section 4 presents the current practices of IP wireless 103 networks and 3GPP architectures. Both network- and host-based 104 mobility protocols are considered. Section 5 presents the gap 105 analysis with respect to the current practices. 107 2. Terminology 109 All general mobility-related terms and their acronyms used in this 110 document are to be interpreted as defined in the Mobile IPv6 base 111 specification [RFC6275], in the Proxy mobile IPv6 specification 112 [RFC5213], and in the Distributed Management Requirements [RFC7333]. 113 These terms include mobile node (MN), correspondent node (CN), home 114 agent (HA), local mobility anchor (LMA), mobile access gateway (MAG), 115 centrally depoyed mobility anchors, distributed mobility management, 116 hierarchical mobile network, flatter mobile network, and flattening 117 mobile network. 119 In addition, this document also introduces some definitions of IP 120 mobility functions in Section 3. 122 In this document there are also references to a "distributed mobility 123 management environment". By this term, we refer to a scenario in 124 which the IP mobility, access network and routing solutions allow for 125 setting up IP networks so that traffic is distributed in an optimal 126 way, without the reliance on centrally deployed mobility anchors to 127 manage IP mobility sessions. 129 3. Functions of existing mobility protocols 131 The host-based Mobile IPv6 (MIPv6) [RFC6275] and its network-based 132 extension, Proxy Mobile IPv6 (PMIPv6) [RFC5213], even Hierarchical 133 Mobile IPv6 (HMIPv6) [RFC5380] are logically centralized mobility 134 management approaches addressing primarily hierarchical mobile 135 networks. Although these two are centralized approaches, they have 136 important mobility management functions resulting from years of 137 extensive work to develop and to extend these functions. It is 138 therefore useful to take these existing functions and examine them in 139 a DMM scenario in order to understand how to deploy the existing 140 mobility protocols to provide distributed mobility management. 142 The main mobility management functions of MIPv6, PMIPv6, and HMIPv6 143 are the following: 145 1. Anchoring function (AF): allocation to a mobile node of an IP 146 address (a Home Address, HoA) or prefix (a Home Network Prefix, 147 HNP) topologically anchored by the advertising node (i.e., the 148 anchor node is able to advertise a connected route into the 149 routing infrastructure for the allocated IP prefixes). It is a 150 control plane function. 152 2. Internetwork Location Information (LI) function: managing and 153 keeping track of the internetwork location of an MN. The 154 location information may be a binding of the IP advertised 155 address/prefix (e.g., HoA or HNP) to the IP routing address of 156 the MN or of a node that can forward packets destined to the MN. 157 It is a control plane function. 159 In a client-server protocol model, location query and update 160 messages may be exchanged between a location information client 161 (LIc) and a location information server (LIs). 163 3. Forwarding Management (FM) function: packet interception and 164 forwarding to/from the IP address/prefix assigned to the MN, 165 based on the internetwork location information, either to the 166 destination or to some other network element that knows how to 167 forward the packets to their destination. 169 FM may optionally be split into the control plane (FM-CP) and 170 data plane (FM-DP). 172 In Mobile IPv6, the home agent (HA) typically provides the anchoring 173 function (AF); the location information server (LIs) is at the HA 174 while the location information client (LIc) is at the MN; the 175 forwarding management (FM)function is both ends of tunneling at the 176 HA and the MN. 178 In Proxy Mobile IPv6, the Local Mobility Anchor (LMA) provides the 179 anchoring function (AF); the location information server (LIs) is at 180 the LMA while the location information client (LIc) is at the mobile 181 access gateway (MAG); the forwarding management (FM) function is both 182 ends of tunneling at the HA and the MAG. 184 In Hierarchical Mobile IPv6 (HMIPv6) [RFC5380], the mobility anchor 185 point (MAP) serves as a location information aggregator between the 186 LIs at the HA and the LIc at the MN. The MAP also has FM function to 187 enable tunneling between HA and itself as well as tunneling between 188 MN and itself. 190 4. DMM practices 192 This section documents deployment practices of existing mobility 193 protocols to satisfy distributed mobility management requirements. 194 This description considers both IP wireless (e.g., evolved Wi-Fi 195 hotspots) and 3GPP flattening mobile network. 197 While describing the current DMM practices, references to the generic 198 mobility management functions described in Section 3 are provided, as 199 well as some initial hints on the identified gaps with respect to the 200 DMM requirements documented in [RFC7333]. 202 4.1. Assumptions 204 There are many different approaches that can be considered to 205 implement and deploy a distributed anchoring and mobility solution. 206 The focus of the gap analysis is on certain current mobile network 207 architectures and standardized IP mobility solutions, considering any 208 kind of deployment options which do not violate the original protocol 209 specifications. In order to limit the scope of our analysis of DMM 210 practices, we consider the following list of technical assumptions: 212 1. Both host- and network-based solutions are considered. 214 2. Solutions should allow selecting and using the most appropriate 215 IP anchor among a set of available candidates. 217 3. Mobility management should be realized by the preservation of the 218 IP address across the different points of attachment (i.e., 219 provision of IP address continuity). This is in contrast to 220 certain transport-layer based approaches such as Stream Control 221 Transmission Protocol (SCTP) [RFC4960] or application-layer 222 mobility. 224 Applications which can cope with changes in the MN's IP address do 225 not depend on IP mobility management protocols such as DMM. 226 Typically, a connection manager together with the operating system 227 will configure the source address selection mechanism of the IP 228 stack. This might involve identifying application capabilities and 229 triggering the mobility support accordingly. Further considerations 230 on application management and source address selection are out of the 231 scope of this document, but the reader might consult [RFC6724]. 233 4.2. IP flat wireless network 235 This section focuses on common IP wireless network architectures and 236 how they can be flattened from an IP mobility and anchoring point of 237 view using common and standardized protocols. We take Wi-Fi as an 238 useful wireless technology, since it is widely known and deployed 239 nowadays. Some representative examples of Wi-Fi deployment 240 architectures are depicted in Figure 1. 242 +-------------+ _----_ 243 +---+ | Access | _( )_ 244 |AAA|. . . . . . | Aggregation |----------( Internet ) 245 +---+ | Gateway | (_ _) 246 +-------------+ '----' 247 | | | 248 | | +-------------+ 249 | | | 250 | | +-----+ 251 +---------------+ | | AR | 252 | | +--+--+ 253 +-----+ +-----+ *----+----* 254 | RG | | WLC | ( LAN ) 255 +-----+ +-----+ *---------* 256 . / \ / \ 257 / \ +-----+ +-----+ +-----+ +-----+ 258 / \ |Wi-Fi| |Wi-Fi| |Wi-Fi| |Wi-Fi| 259 MN1 MN2 | AP1 | | AP2 | | AP3 | | AP4 | 260 +-----+ +-----+ +-----+ +-----+ 261 . . 262 / \ / \ 263 / \ / \ 264 MN3 MN4 MN5 MN6 266 Figure 1: IP Wi-Fi network architectures 268 In the figure, three typical deployment options are shown 269 [I-D.gundavelli-v6ops-community-wifi-svcs]. On the left hand side of 270 the figure, mobile nodes MN1 and MN2 directly connect to a 271 Residential Gateway (RG) which is a network device at the customer 272 premises and provides both wireless layer-2 access connectivity 273 (i.e., it hosts the 802.11 Access Point function) and layer-3 routing 274 functions. In the middle of the figure, mobile nodes MN3 and MN4 275 connect to Wi-Fi Access Points (APs) AP1 and AP2 that are managed by 276 a WLAN Controller (WLC), which performs radio resource management on 277 the APs, domain-wide mobility policy enforcement and centralized 278 forwarding function for the user traffic. The WLC could also 279 implement layer-3 routing functions, or attach to an access router 280 (AR). Last, on the right-hand side of the figure, access points AP3 281 and AP4 are directly connected to an access router. This can also be 282 used as a generic connectivity model. 284 IP mobility protocols can be used to provide inter-access mobility 285 support to users, e.g., handover from Wi-Fi to cellular access. Two 286 kind of protocols can be used: Proxy Mobile IPv6 [RFC5213] or Mobile 287 IPv6 [RFC5555], with the mobility anchor (e.g., local mobility anchor 288 or home agent) role typically being played by the edge router of the 289 mobile network [SDO-3GPP.23.402]. 291 Although this section has made use of the example of Wi-Fi networks, 292 there are other IP flat wireless network architectures specified, 293 such as WiMAX [IEEE.802-16.2009], which integrates both host and 294 network-based IP mobility functionality. 296 Existing IP mobility protocols can also be deployed in a flatter 297 manner, so that the anchoring and access aggregation functions are 298 distributed. We next describe several practices for the deployment 299 of existing mobility protocols in a distributed mobility management 300 environment. The analysis in this section is limited to protocol 301 solutions based on existing IP mobility protocols, either host- or 302 network-based, such as Mobile IPv6 [RFC6275], [RFC5555], Proxy Mobile 303 IPv6 (PMIPv6) [RFC5213], [RFC5844] and Network Mobility Basic Support 304 protocol (NEMO) [RFC3963]. Extensions to these base protocol 305 solutions are also considered. The analysis is divided into two 306 parts: host- and network-based practices. 308 4.2.1. Host-based IP DMM practices 310 Mobile IPv6 (MIPv6) [RFC6275] and its extension to support mobile 311 networks, the NEMO Basic Support protocol (hereafter, simply referred 312 to as NEMO) [RFC3963] are well-known host-based IP mobility 313 protocols. They depend upon the function of the Home Agent (HA), a 314 centralized anchor, to provide mobile nodes (hosts and routers) with 315 mobility support. In these approaches, the home agent typically 316 provides the anchoring function (AF), forwarding management (FM), and 317 Internetwork Location Information server (LIs) functions. The mobile 318 node possesses the Location Information client (LIc) function and the 319 FM function to enable tunneling between HA and itself. We next 320 describe some practices that show how MIPv6/NEMO and several other 321 protocol extensions can be deployed in a distributed mobility 322 management environment. 324 One approach to distribute the anchors can be to deploy several HAs 325 (as shown in Figure 2), and assign the topologically closest anchor 326 to each MN [RFC4640], [RFC5026], [RFC6611]. In the example shown in 327 Figure 2, MN1 is assigned HA1 (and a home address anchored by HA1), 328 while MN2 is assigned HA2. Note that MIPv6/NEMO specifications do 329 not prevent the simultaneous use of multiple home agents by a single 330 mobile node. In this deployment model, the mobile node can use 331 several anchors at the same time, each of them anchoring IP flows 332 initiated at a different point of attachment. However there is no 333 mechanism specified to enable an efficient dynamic discovery of 334 available anchors and the selection of the most suitable one. Note 335 that some of these mechanisms [SDO-3GPP.23.402] have been defined in 336 other standards organizations. 338 <- INTERNET -> <- HOME NETWORK -> <---- ACCESS NETWORK ----> 339 ------- ------- 340 | CN1 | ------- | AR1 |-(o) zzzz (o) 341 ------- | HA1 | ------- | 342 ------- (MN1 anchored at HA1) ------- 343 ------- | MN1 | 344 | AR2 |-(o) ------- 345 ------- 346 ------- 347 | HA2 | ------- 348 ------- | AR3 |-(o) zzzz (o) 349 ------- | 350 ------- (MN2 anchored at HA2) ------- 351 | CN2 | ------- | MN2 | 352 ------- | AR4 |-(o) ------- 353 ------- 355 CN1 CN2 HA1 HA2 AR1 MN1 AR3 MN2 356 | | | | | | | | 357 |<------------>|<=================+=====>| | | BT mode 358 | | | | | | | | 359 | |<----------------------------------------+----->| RO mode 360 | | | | | | | | 362 Figure 2: Distributed operation of Mobile IPv6 (BT and RO) / NEMO 364 Since one of the goals of the deployment of mobility protocols in a 365 distributed mobility management environment is to avoid the 366 suboptimal routing caused by centralized anchoring, the Route 367 Optimization (RO) support provided by Mobile IPv6 can also be used to 368 achieve a flatter IP data forwarding. By default, Mobile IPv6 and 369 NEMO use the so-called Bidirectional Tunnel (BT) mode, in which data 370 traffic is always encapsulated between the MN and its HA before being 371 directed to any other destination. The Route Optimization (RO) mode 372 allows the MN to update its current location on the CNs, and then use 373 the direct path between them. Using the example shown in Figure 2, 374 MN1 is using BT mode with CN1 and MN2 is in RO mode with CN2. 375 However, the RO mode has several drawbacks: 377 o The RO mode is only supported by Mobile IPv6. There is no route 378 optimization support standardized for the NEMO protocol because of 379 the security problems posed by extending return routability tests 380 for prefixes, although many different solutions have been proposed 381 [RFC4889]. 383 o The RO mode requires signaling that adds some protocol overhead. 385 o The signaling required to enable RO involves the home agent and is 386 repeated periodically for security reasons [RFC4225] and, thus, 387 the HA remains a single point of failure. 389 o The RO mode requires support from the correspondent node (CN). 391 Notwithstanding these considerations, the RO mode does offer the 392 possibility of substantially reducing traffic through the Home Agent, 393 in cases when it can be supported by the relevant correspondent 394 nodes. Note that a mobile node can also use its CoA directly 395 [RFC5014] when communicating with CNs on the same link or anywhere in 396 the Internet, although no session continuity support would be 397 provided by the IP stack in this case. 399 Hierarchical Mobile IPv6 (HMIPv6) [RFC5380] (as shown in Figure 3), 400 is another host-based IP mobility extension which can be considered 401 as a complement to provide a less centralized mobility deployment. 402 It allows reducing the amount of mobility signaling as well as 403 improving the overall handover performance of Mobile IPv6 by 404 introducing a new hierarchy level to handle local mobility. The 405 Mobility Anchor Point (MAP) entity is introduced as a local mobility 406 handling node deployed closer to the mobile node. It provides LI 407 intermediary function between the LI server (LIs) at the HA and the 408 LI client (LIc) at the MN. It also performs the FM function using 409 tunneling with the HA and also to tunnel with the MN. 411 <- INTERNET -> <- HOME NETWORK -> <------- ACCESS NETWORK -------> 412 ----- 413 /|AR1|-(o) zz (o) 414 -------- / ----- | 415 | MAP1 |< ------- 416 -------- \ ----- | MN1 | 417 ------- \|AR2| ------- 418 | CN1 | ----- HoA anchored 419 ------- ----- at HA1 420 ------- /|AR3| RCoA anchored 421 | HA1 | -------- / ----- at MAP1 422 ------- | MAP2 |< LCoA anchored 423 -------- \ ----- at AR1 424 \|AR4| 425 ------- ----- 426 | CN2 | ----- 427 ------- /|AR5| 428 -------- / ----- 429 | MAP3 |< 430 -------- \ ----- 431 \|AR6| 432 ----- 434 CN1 CN2 HA1 MAP1 AR1 MN1 435 | | | | ________|__________ | 436 |<------------------>|<==============>|<________+__________>| HoA 437 | | | | | | 438 | |<-------------------------->|<===================>| RCoA 439 | | | | | | 441 Figure 3: Hierarchical Mobile IPv6 443 When HMIPv6 is used, the MN has two different temporary addresses: 444 the Regional Care-of Address (RCoA) and the Local Care-of Address 445 (LCoA). The RCoA is anchored at one MAP, that plays the role of 446 local home agent, while the LCoA is anchored at the access router 447 level. The mobile node uses the RCoA as the CoA signaled to its home 448 agent. Therefore, while roaming within a local domain handled by the 449 same MAP, the mobile node does not need to update its home agent 450 (i.e., the mobile node does not change its RCoA). 452 The use of HMIPv6 enables some form of route optimization, since a 453 mobile node may decide to directly use the RCoA as source address for 454 a communication with a given correspondent node, particularly if the 455 MN does not expect to move outside the local domain during the 456 lifetime of the communication. This can be seen as a potential DMM 457 mode of operation,though it fails to provide session continuity if 458 and when the MN moves outside the local domain. In the example shown 459 in Figure 3, MN1 is using its global HoA to communicate with CN1, 460 while it is using its RCoA to communicate with CN2. 462 Furthermore, a local domain might have several MAPs deployed, 463 enabling therefore a different kind of HMIPv6 deployments (e.g., 464 flattening and distributed). The HMIPv6 specification supports a 465 flexible selection of the MAP (e.g., based on the distance between 466 the MN and the MAP, taking into consideration the expected mobility 467 pattern of the MN, etc.). 469 Another extension that can be used to help distributing mobility 470 management functions is the Home Agent switch specification 471 [RFC5142], which defines a new mobility header for signaling a mobile 472 node that it should acquire a new home agent. [RFC5142] does not 473 specify the case of changing the mobile node's home address, as that 474 might imply loss of connectivity for ongoing persistent connections. 475 Nevertheless, that specification could be used to force the change of 476 home agent in those situations where there are no active persistent 477 data sessions that cannot cope with a change of home address. 479 There are other host-based approaches standardized that can be used 480 to provide mobility support. For example MOBIKE [RFC4555] allows a 481 mobile node encrypting traffic through IKEv2 [RFC5996] to change its 482 point of attachment while maintaining a Virtual Private Network (VPN) 483 session. The MOBIKE protocol allows updating the VPN Security 484 Associations (SAs) in cases where the base connection initially used 485 is lost and needs to be re-established. The use of the MOBIKE 486 protocol avoids having to perform an IKEv2 re-negotiation. Similar 487 considerations to those made for Mobile IPv6 can be applied to 488 MOBIKE; though MOBIKE is best suited for situations where the address 489 of at least one endpoint is relatively stable and can be discovered 490 using existing mechanisms such as DNS. 492 Extensions have been defined to the mobility protocol to optimize the 493 handover performance. Mobile IPv6 Fast Handovers (FMIPv6) [RFC5568] 494 is the extension to optimize handover latency. It defines new access 495 router discovery mechanism before handover to reduce the new network 496 discovery latency. It also defines a tunnel between the previous 497 access router and the new access router to reduce the packet loss 498 during handover. The Candidate Access Router Discovery (CARD) 499 [RFC4066] and Context Transfer Protocol (CXTP) [RFC4067] protocols 500 were standardized to improve the handover performance. The DMM 501 deployment practice discussed in this section can also use those 502 extensions to improve the handover performance. 504 4.2.2. Network-based IP DMM practices 506 Proxy Mobile IPv6 (PMIPv6) [RFC5213] is the main network-based IP 507 mobility protocol specified for IPv6. Proxy Mobile IPv4 [RFC5844] 508 defines some IPv4 extensions. With network-based IP mobility 509 protocols, the local mobility anchor (LMA) typically provides the 510 anchoring function (AF), Forwarding management (FM) function, and 511 Internetwork Location Information server (LIs) function. The mobile 512 access gateway (MAG) provides the Location Information client (LIc) 513 function and Forwarding management (FM) function to tunnel with LMA. 514 PMIPv6 is architecturally almost identical to MIPv6, as the mobility 515 signaling and routing between LMA and MAG in PMIPv6 is similar to 516 those between HA and MN in MIPv6. The required mobility 517 functionality at the MN is provided by the MAG so that the 518 involvement in mobility support by the MN is not required. 520 We next describe some practices that show how network-based mobility 521 protocols and several other protocol extensions can be deployed in a 522 distributed mobility management environment. 524 One way to decentralize Proxy Mobile IPv6 operation can be to deploy 525 several local mobility anchors and use some selection criteria to 526 assign LMAs to attaching mobile nodes (an example of this type of 527 assignment is shown in Figure 4). As with the client based approach, 528 a mobile node may use several anchors at the same time, each of them 529 anchoring IP flows initiated at a different point of attachment. 530 This assignment can be static or dynamic. The main advantage of this 531 simple approach is that the IP address anchor (i.e., the LMA) could 532 be placed closer to the mobile node. Therefore the resulting paths 533 are close-to-optimal. On the other hand, as soon as the mobile node 534 moves, the resulting path will start deviating from the optimal one. 536 <- INTERNET -><- HOME NET -><----------- ACCESS NETWORK ------------> 537 ------- 538 | CN1 | -------- -------- -------- 539 ------- -------- | MAG1 | | MAG2 | | MAG3 | 540 | LMA1 | ---+---- ---+---- ---+---- 541 ------- -------- | | | 542 | CN2 | (o) (o) (o) 543 ------- -------- x x 544 | LMA2 | x x 545 ------- -------- (o) (o) 546 | CN3 | | | 547 ------- ---+--- ---+--- 548 Anchored | MN1 | Anchored | MN2 | 549 at LMA1 -> ------- at LMA2 -> ------- 551 CN1 CN2 LMA1 LMA2 MAG1 MN1 MAG3 MN2 552 | | | | | | | | 553 |<------------>|<================>|<---->| | | 554 | | | | | | | | 555 | |<------------>|<========================>|<----->| 556 | | | | | | | | 558 Figure 4: Distributed operation of Proxy Mobile IPv6 560 Similar to the host-based IP mobility case, network-based IP mobility 561 has some extensions defined to mitigate the suboptimal routing issues 562 that may arise due to the use of a centralized anchor. The Local 563 Routing extensions [RFC6705] enable optimal routing in Proxy Mobile 564 IPv6 in three cases: i) when two communicating MNs are attached to 565 the same MAG and LMA, ii) when two communicating MNs are attached to 566 different MAGs but to the same LMA, and iii) when two communicating 567 MNs are attached to the same MAG but have different LMAs. In these 568 three cases, data traffic between the two mobile nodes does not 569 traverse the LMA(s), thus providing some form of path optimization 570 since the traffic is locally routed at the edge. The main 571 disadvantage of this approach is that it only tackles the MN-to-MN 572 communication scenario, and only under certain circumstances. 574 An interesting extension that can also be used to facilitate the 575 deployment of network-based mobility protocols in a distributed 576 mobility management environment is the LMA runtime assignment 577 [RFC6463]. This extension specifies a runtime local mobility anchor 578 assignment functionality and corresponding mobility options for Proxy 579 Mobile IPv6. This runtime local mobility anchor assignment takes 580 place during the Proxy Binding Update / Proxy Binding Acknowledgment 581 message exchange between a mobile access gateway and a local mobility 582 anchor. While this mechanism is mainly aimed for load-balancing 583 purposes, it can also be used to select an optimal LMA from the 584 routing point of view. A runtime LMA assignment can be used to 585 change the assigned LMA of an MN, for example, in cases when the 586 mobile node does not have any active session, or when the running 587 sessions can survive an IP address change. Note that several 588 possible dynamic local mobility anchor discovery solutions can be 589 used, as described in [RFC6097]. 591 4.3. Flattening 3GPP mobile network approaches 593 The 3rd Generation Partnership Project (3GPP) is the standards 594 development organization that specifies the 3rd generation mobile 595 network and the Evolved Packet System (EPS), which mainly comprises 596 the Evolved Packet Core (EPC) and a new radio access network, usually 597 referred to as LTE (Long Term Evolution). 599 Architecturally, the 3GPP Evolved Packet Core (EPC) network is 600 similar to an IP wireless network running PMIPv6 or MIPv6, as it 601 relies on the Packet Data Gateway (PGW) anchoring services to provide 602 mobile nodes with mobility support (see Figure 5). There are client- 603 based and network-based mobility solutions in 3GPP, which for 604 simplicity will be analyzed together. We next describe how 3GPP 605 mobility protocols and several other completed or ongoing extensions 606 can be deployed to meet some of the DMM requirements [RFC7333]. 608 +---------------------------------------------------------+ 609 | PCRF | 610 +-----------+--------------------------+----------------+-+ 611 | | | 612 +----+ +-----------+------------+ +--------+-----------+ +-+-+ 613 | | | +-+ | | Core Network | | | 614 | | | +------+ |S|__ | | +--------+ +---+ | | | 615 | | | |GERAN/|_|G| \ | | | HSS | | | | | | 616 | +-----+ UTRAN| |S| \ | | +---+----+ | | | | E | 617 | | | +------+ |N| +-+-+ | | | | | | | x | 618 | | | +-+ /|MME| | | +---+----+ | | | | t | 619 | | | +---------+ / +---+ | | | 3GPP | | | | | e | 620 | +-----+ E-UTRAN |/ | | | AAA | | | | | r | 621 | | | +---------+\ | | | SERVER | | | | | n | 622 | | | \ +---+ | | +--------+ | | | | a | 623 | | | 3GPP AN \|SGW+----- S5---------------+ P | | | l | 624 | | | +---+ | | | G | | | | 625 | | +------------------------+ | | W | | | I | 626 | UE | | | | | | P | 627 | | +------------------------+ | | +-----+ | 628 | | |+-------------+ +------+| | | | | | n | 629 | | || Untrusted +-+ ePDG +-S2b---------------+ | | | e | 630 | +---+| non-3GPP AN | +------+| | | | | | t | 631 | | |+-------------+ | | | | | | w | 632 | | +------------------------+ | | | | | o | 633 | | | | | | | r | 634 | | +------------------------+ | | | | | k | 635 | +---+ Trusted non-3GPP AN +-S2a--------------+ | | | s | 636 | | +------------------------+ | | | | | | 637 | | | +-+-+ | | | 638 | +--------------------------S2c--------------------| | | | 639 | | | | | | 640 +----+ +--------------------+ +---+ 642 Figure 5: EPS (non-roaming) architecture overview 644 The GPRS Tunneling Protocol (GTP) [SDO-3GPP.29.060] [SDO-3GPP.29.281] 645 [SDO-3GPP.29.274] is a network-based mobility protocol specified for 646 3GPP networks (S2a, S2b, S5 and S8 interfaces). Similar to PMIPv6, 647 it can handle mobility without requiring the involvement of the 648 mobile nodes. In this case, the mobile node functionality is 649 provided in a proxy manner by the Serving Data Gateway (SGW), Evolved 650 Packet Data Gateway (ePDG), or Trusted Wireless Access Gateway (TWAG 651 [SDO-3GPP.23.402]) . 653 3GPP specifications also include client-based mobility support, based 654 on adopting the use of Dual-Stack Mobile IPv6 (DSMIPv6) [RFC5555] for 655 the S2c interface [SDO-3GPP.24.303]. In this case, the User 656 Equipment (UE) implements the binding update functionality, while the 657 home agent role is played by the PGW. 659 A Local IP Access (LIPA) and Selected IP Traffic Offload (SIPTO) 660 enabled network [SDO-3GPP.23.401] allows offloading some IP services 661 at the local access network, above the Radio Access Network (RAN) or 662 at the macro, without the need to travel back to the PGW (see 663 Figure 6). 665 +---------+ IP traffic to mobile operator's CN 666 | User |.........................\C2 667 \B7.........(Opera 668 r's CN) 669 | Equipm. |......... 670 .... 671 .\C2 672 \B7 673 +---------+ . Local IP traffic 674 . 675 +-----------+ 676 |Residential| 677 |enterprise | 678 |IP network | 679 +-----------+ 681 Figure 6: LIPA scenario 683 SIPTO enables an operator to offload certain types of traffic at a 684 network node close to the UE's point of attachment to the access 685 network, by selecting a set of GWs (SGW and PGW) that are 686 geographically/topologically close to the UE's point of attachment. 688 SIPTO Traffic 689 | 690 . 691 . 692 +------+ +------+ 693 |L-PGW | ---- | MME | 694 +------+ / +------+ 695 | / 696 +-------+ +------+ +------+/ +------+ 697 | UE |.....|eNB |....| S-GW |........| P-GW 698 ...> CN Traf 699 c 700 +-------+ +------+ +------+ +------+ 702 Figure 7: SIPTO architecture 704 LIPA, on the other hand, enables an IP addressable UE connected via a 705 Home eNB (HeNB) to access other IP addressable entities in the same 706 residential/enterprise IP network without traversing the mobile 707 operator's network core in the user plane. In order to achieve this, 708 a Local GW (L-GW) collocated with the HeNB is used. LIPA is 709 established by the UE requesting a new PDN (Public Data Network) 710 connection to an access point name for which LIPA is permitted, and 711 the network selecting the Local GW associated with the HeNB and 712 enabling a direct user plane path between the Local GW and the HeNB. 714 +---------------+-------+ +----------+ +-------------+ ===== 715 |Residential | |H(e)NB | | Backhaul | |Mobile | ( IP ) 716 |Enterprise |..|-------|..| |..|Operator |..(Network) 717 |Network | |L-GW | | | |Core network | ======= 718 +---------------+-------+ +----------+ +-------------+ 719 / 720 | 721 / 722 +-----+ 723 | UE | 724 +-----+ 726 Figure 8: LIPA architecture 728 The 3GPP architecture specifications also provide mechanisms to allow 729 discovery and selection of gateways [SDO-3GPP.29.303]. These 730 mechanisms enable decisions taking into consideration topological 731 location and gateway collocation aspects, relying upon the DNS as a 732 "location database". 734 Both SIPTO and LIPA have a very limited mobility support, specially 735 in 3GPP specifications up to Rel-12. Briefly, LIPA mobility support 736 is limited to handovers between HeNBs that are managed by the same 737 L-GW (i.e., mobility within the local domain). There is no guarantee 738 of IP session continuity for SIPTO. 740 5. Gap analysis 742 The goal of this section is to identify the limitations in the 743 current practices, described in Section 4, with respect to the DMM 744 requirements listed in [RFC7333]. 746 5.1. Distributed mobility management - REQ1 748 According to requirement #1 stated in [RFC7333], IP mobility, network 749 access and forwarding solutions provided by DMM must enable traffic 750 to avoid traversing single mobility anchor far from the optimal 751 route. 753 From the analysis performed in Section 4, a DMM deployment can meet 754 the requirement "REQ#1 Distributed mobility management" usually 755 relying on the following functions: 757 o Multiple (distributed) anchoring: ability to anchor different 758 sessions of a single mobile node at different anchors. In order 759 to provide improved routing, some anchors might need to be placed 760 closer to the mobile node or the corresponding node. 762 o Dynamic anchor assignment/re-location: ability to i) assign the 763 initial anchor, and ii) dynamically change the initially assigned 764 anchor and/or assign a new one (this may also require to transfer 765 mobility context between anchors). This can be achieved either by 766 changing anchor for all ongoing sessions or by assigning new 767 anchors just for new sessions. 769 Both the main client- and network-based IP mobility protocols, namely 770 (DS)MIPv6 and PMIPv6 allow deploying multiple anchors (i.e., home 771 agents and localized mobility anchors), therefore providing the 772 multiple anchoring function. However, existing solutions only 773 provide a initial anchor assignment, thus the lack of dynamic anchor 774 change/new anchor assignment is a gap. Neither the HA switch nor the 775 LMA runtime assignment allow changing the anchor during an ongoing 776 session. This actually comprises several gaps: ability to perform 777 anchor assignment at any time (not only at the initial MN's 778 attachment), ability of the current anchor to initiate/trigger the 779 relocation, and ability to transfer registration context between 780 anchors. 782 Dynamic anchor assignment may lead the MN to manage different 783 mobility sessions served by different mobility anchors. This is not 784 an issue with client based mobility management where the mobility 785 client natively knows each anchor associated to each mobility 786 sessions. However, there is one gap, as the MN should be capable of 787 handling IP addresses in a DMM-friendly way, meaning that the MN can 788 perform smart source address selection (i.e., deprecating IP 789 addresses from previous mobility anchors, so they are not used for 790 new sessions). Besides, managing different mobility sessions served 791 by different mobility anchors may raise issues with network based 792 mobility management. In this case, the mobile client, located in the 793 network (e.g., MAG), usually retrieves the MN's anchor from the MN's 794 policy profile (e.g., Section 6.2 of [RFC5213]). Currently, the MN's 795 policy profile implicitly assumes a single serving anchor and, thus, 796 does not maintain the association between home network prefix and 797 anchor. 799 The consequence of the distribution of the mobility anchors is that 800 there might be more than one available anchor for a mobile node to 801 use, which leads to an anchor discovery and selection issue. 802 Currently, there is no efficient mechanism specified to allow 803 dynamically discovering the presence of nodes that can play the 804 anchor role, discovering their capabilities and selecting the most 805 suitable one. There is also no mechanism to allow selecting a node 806 that is currently anchoring a given home address/prefix (capability 807 sometimes required to meet REQ#2). There are though some mechanisms 808 that could help discovering anchors, such as the Dynamic Home Agent 809 Address Discovery (DHAAD), the use of the Home Agent (H) flag in 810 Router Advertisements (which indicates that the router sending the 811 Router Advertisement is also functioning as a Mobile IPv6 home agent 812 on the link) or the MAP option in Router Advertisements defined by 813 HMIPv6. Note that there are 3GPP mechanisms providing that 814 functionality defined in [SDO-3GPP.29.303]. 816 Regarding the ability to transfer registration context between 817 anchors, there are already some solutions that could be reused or 818 adapted to fill that gap, such as Fast Handovers for Mobile IPv6 819 [RFC5568] -- to enable traffic redirection from the old to the new 820 anchor --, the Context Transfer protocol [RFC4067] -- to enable the 821 required transfer of registration information between anchors --, or 822 the Handover Keying architecture solutions [RFC6697], to speed up the 823 re-authentication process after a change of anchor. Note that some 824 extensions might be needed in the context of DMM, as these protocols 825 were designed in the context of centralized client IP mobility, 826 focusing on the access re-attachment and authentication. 828 Also note that REQ1 is such that the data plane traffic can avoid 829 suboptimal route. Distributed processing of the traffic is then 830 needed only in the data plane. The needed capability in distributed 831 processing therefore should not contradict with centralized control 832 plane. Other control plane solutions such as charging, lawful 833 interception, etc. should not be limited. Yet combining the control 834 plane and data plane forwarding management (FM) function may limit 835 the choice to distributing both data plane and control plane 836 together. In order to enable distributing only the data plane 837 without distributing the control plane, a gap is to split the 838 forwarding management function into the control plane (FM-CP) and 839 data plane (FM-DP). 841 5.2. Bypassable network-layer mobility support for each application 842 session - REQ2 844 The need for "bypassable network-layer mobility support for each 845 application session" introduced in [RFC7333] requires flexibility on 846 determining whether network-layer mobility support is needed. The 847 requirement enables one to choose whether or not use network-layer 848 mobility support. It only enables the two following functions: 850 o Dynamically assign/relocate anchor: a mobility anchor is assigned 851 only to sessions which uses the network-layer mobility support. 852 The MN may thus manage more than one session; some of them may be 853 associated with anchored IP address(es), while the others may be 854 associated with local IP address(es). 856 o Multiple IP address management: this function is related to the 857 preceding and is about the ability of the mobile node to 858 simultaneously use multiple IP addresses and select the best one 859 (from an anchoring point of view) to use on a per-session/ 860 application/service basis. This requires MN to acquire 861 information regarding the properties of the available IP 862 addresses. 864 The dynamic anchor assignment/relocation needs to ensure that IP 865 address continuity is guaranteed for sessions that uses such mobility 866 support (e.g., in some scenarios, the provision of mobility locally 867 within a limited area might be enough from the mobile node or the 868 application point of view) at the relocated anchor. Implicitly, when 869 no applications are using the network-layer mobility support, DMM may 870 release the needed resources. This may imply having the knowledge of 871 which sessions at the mobile node are active and are using the 872 mobility support. This is something typically known only by the MN 873 (e.g., by its connection manager), and would also typically require 874 some signaling support (e.g., socket API extensions) from 875 applications to indicate the IP stack whether mobility support is 876 required or not in. Therefore, (part of) this knowledge might need 877 to be transferred to/shared with the network. 879 Multiple IP address management provides the MN with the choice to 880 pick-up the correct address (provided with mobility support or not) 881 depending on the application requirements. When using client based 882 mobility management, the mobile node is itself aware of the anchoring 883 capabilities of its assigned IP addresses. This is not necessarily 884 the case with network based IP mobility management; current 885 mechanisms do not allow the MN to be aware of the properties of its 886 IP addresses (e.g., the MN does not know whether the allocated IP 887 addresses are anchored). However, there are proposals that the 888 network could indicate such IP address properties during assignment 889 procedures, such as [I-D.bhandari-dhc-class-based-prefix], 890 [I-D.korhonen-6man-prefix-properties] and [I-D.anipko-mif-mpvd-arch]. 891 Although there exist these individual efforts that could be be 892 considered as attempts to fix the gap, there is no solution adopted 893 as a work item within any IETF working group. 895 The handling of mobility management to the granularity of an 896 individual session of a user/device needs proper session 897 identification in addition to user/device identification. 899 5.3. IPv6 deployment - REQ3 901 This requirement states that DMM solutions should primarily target 902 IPv6 as the primary deployment environment. IPv4 support is not 903 considered mandatory and solutions should not be tailored 904 specifically to support IPv4. 906 All analyzed DMM practices support IPv6. Some of them, such as 907 MIPv6/NEMO (including the support of dynamic HA selection), MOBIKE, 908 SIPTO have also IPv4 support. There are also some solutions that 909 have some limited IPv4 support (e.g., PMIPv6). In conclusion, this 910 requirement is met by existing DMM practices. 912 5.4. Existing mobility protocols - REQ4 914 A DMM solution must first consider reusing and extending IETF- 915 standardized protocols before specifying new protocols. 917 As stated in [RFC7333], a DMM solution could reuse existing IETF and 918 standardized protocols before specifying new protocols. Besides, 919 Section 4 of this document discusses various ways to flatten and 920 distribute current mobility solutions. Actually, nothing prevent the 921 distribution of mobility functions with in IP mobility protocols. 922 However, as discussed in Section 5.1 and Section 5.2, limitations 923 exist. 925 The 3GPP data plane anchoring function, i.e., the PGW, can be also be 926 distributed, but with limitations; e.g., no anchoring relocation, no 927 context transfer between anchors and centralized control plane. The 928 3GPP architecture is also going into the direction of flattening with 929 SIPTO and LIPA, though they do not provide full mobility support. 930 For example, mobility support for SIPTO traffic can be rather 931 limited, and offloaded traffic cannot access operator services. 932 Thus, the operator must be very careful in selecting which traffic to 933 offload. 935 5.5. Coexistence with deployed networks/hosts and operability across 936 different networks- REQ5 938 According to [RFC7333], DMM implementations are required to co-exist 939 with existing network deployments, end hosts and routers. 940 Additionally, DMM solutions are expected to work across different 941 networks, possibly operated as separate administrative domains, when 942 the needed mobility management signaling, forwarding, and network 943 access are allowed by the trust relationship between them. All 944 current mobility protocols can co-exist with existing network 945 deployments and end hosts. There is no gap between existing mobility 946 protocols and this requirement. 948 5.6. Operation and management considerations - REQ6 950 This requirement actually comprises several aspects, as summarized 951 below. 953 o A DMM solution needs to consider configuring a device, monitoring 954 the current operational state of a device, responding to events 955 that impact the device, possibly by modifying the configuration 956 and storing the data in a format that can be analyzed later. 958 o A DMM solution has to describe in what environment and how it can 959 be scalably deployed and managed. 961 o A DMM solution has to support mechanisms to test if the DMM 962 solution is working properly. 964 o A DMM solution is expected to expose the operational state of DMM 965 to the administrators of the DMM entities. 967 o A DMM solution, which supports flow mobility, is also expected to 968 support means to correlate the flow routing policies and the 969 observed forwarding actions. 971 o A DMM solution is expected to support mechanisms to check the 972 liveness of forwarding path. 974 o A DMM solution has to provide fault management and monitoring 975 mechanisms to manage situations where update of the mobility 976 session or the data path fails. 978 o A DMM solution is expected to be able to monitor the usage of the 979 DMM protocol. 981 o DMM solutions have to support standardized configuration with 982 NETCONF [RFC6241], using YANG [RFC6020] modules, which are 983 expected to be created for DMM when needed for such configuration. 985 Existing mobility management protocols have not thoroughly documented 986 the above list of operation and management considerations. Each of 987 the above needs to be considered from the beginning in a DMM 988 solution. 990 Management information base (MIB) objects are currently defined in 991 [RFC4295] for MIPv6 and in [RFC6475] for PMIPv6. Standardized 992 configuration with NETCONF [RFC6241], using YANG [RFC6020] modules is 993 needed. 995 5.7. Security considerations - REQ7 997 As stated in [RFC7333], a DMM solution has to support any security 998 protocols and mechanisms needed to secure the network and to make 999 continuous security improvements. In addition, with security taken 1000 into consideration early in the design, a DMM solution cannot 1001 introduce new security risks, or amplify existing security risks, 1002 that cannot be mitigated by existing security protocols and 1003 mechanisms. 1005 Current mobility protocols have all security mechanisms in place. 1006 For example, Mobile IPv6 defines security features to protect binding 1007 updates both to home agents and correspondent nodes. It also defines 1008 mechanisms to protect the data packets transmission for Mobile IPv6 1009 users. Proxy Mobile IPv6 and other variations of mobile IP also have 1010 similar security considerations. 1012 5.8. Multicast - REQ8 1014 It is stated in [RFC7333] that DMM solutions are expected to enable 1015 multicast solutions to be developed to avoid network inefficiency in 1016 multicast traffic delivery. 1018 Current IP mobility solutions address mainly the mobility problem for 1019 unicast traffic. Solutions relying on the use of an anchor point for 1020 tunneling multicast traffic down to the access router, or to the 1021 mobile node, introduce the so-called "tunnel convergence problem". 1022 This means that multiple insta ces of the same multicast traffic can 1023 converge to the same node, diminishing the advantage of using 1024 multicast protocols. 1026 [RFC6224] documents a baseline solution for the previous issue, and 1027 [RFC7028] a routing optimization solution. The baseline solution 1028 suggests deploying an MLD proxy function at the MAG, and either a 1029 multicast router or another MLD proxy function at the LMA. The 1030 routing optimization solution describes an architecture where a 1031 dedicated multicast tree mobility anchor (MTMA) or a direct routing 1032 option can be used to avoid the tunnel convergence problem. 1034 Besides the solutions highlighted before, there are no other 1035 mechanisms for mobility protocols to address the multicast tunnel 1036 convergence problem. 1038 5.9. Summary 1040 We next list the main gaps identified from the analysis performed 1041 above: 1043 o Existing solutions only provide an optimal initial anchor 1044 assignment, a gap being the lack of dynamic anchor change/new 1045 anchor assignment. Neither the HA switch nor the LMA runtime 1046 assignment allow changing the anchor during an ongoing session. 1047 MOBIKE allows change of GW but its applicability has been scoped 1048 to very narrow use case. 1050 o The mobile node needs to simultaneously use multiple IP addresses 1051 with different properties, which requires to expose this 1052 information to the mobile node and to update accordingly the 1053 source address selection mechanism of the latter. 1055 o Currently, there is no efficient mechanism specified by the IETF 1056 that allows to dynamically discover the presence of nodes that can 1057 play the role of anchor, discover their capabilities and allow the 1058 selection of the most suitable one. However, the following 1059 mechanisms that could help discovering anchors: 1061 o Dynamic Home Agent Address Discovery (DHAAD): the use of the Home 1062 Agent (H) flag in Router Advertisements (which indicates that the 1063 router sending the Router Advertisement is also functioning as a 1064 Mobile IPv6 home agent on the link) and the MAP option in Router 1065 Advertisements defined by HMIPv6. 1067 o While existing network-based DMM practices may allow to deploy 1068 multiple LMAs and dynamically select the best one, this requires 1069 to still keep some centralization in the control plane, to access 1070 the policy database (as defined in RFC5213). Although 1071 [I-D.ietf-netext-pmip-cp-up-separation] allows a MAG to perform 1072 splitting of its control and user planes, there is a lack of 1073 solutions/extensions that support a clear control and data plane 1074 separation for IETF IP mobility protocols in a DMM context. 1076 6. Security Considerations 1078 Distributed mobility management systems encounter same security 1079 threats as existing centralized IP mobility protocols. Without 1080 authentication, a malicious node could forge signaling messages and 1081 redirect traffic from its legitimate path. This would amount to a 1082 denial of service attack against the specific node or nodes for which 1083 the traffic is intended. Distributed mobility anchoring, while 1084 keeping current security mechanisms, might require more security 1085 associations to be managed by the mobility management entities, 1086 potentially leading to scalability and performance issues. Moreover, 1087 distributed mobility anchoring makes mobility security problems more 1088 complex, since traffic redirection requests might come from 1089 previously unconsidered origins, thus leading to distributed points 1090 of attack. Consequently, the DMM security design needs to account 1091 for the distribution of security associations between additional 1092 mobility entities. 1094 7. IANA Considerations 1096 None. 1098 8. Contributors 1100 This document has benefited to valuable contributions from 1102 Charles E. Perkins 1103 Huawei Technologies 1104 EMail: charliep@computer.org 1106 who had produced a matrix to compare the different mobility protocols 1107 and extensions against a list of desired DMM properties. They were 1108 useful inputs in the early work of gap analysis. He had continued to 1109 give suggestions as well as extensive review comments to this 1110 documents. 1112 9. References 1114 9.1. Normative References 1116 [RFC7333] Chan, H., Liu, D., Seite, P., Yokota, H., and J. Korhonen, 1117 "Requirements for Distributed Mobility Management", RFC 1118 7333, August 2014. 1120 9.2. Informative References 1122 [I-D.anipko-mif-mpvd-arch] 1123 Anipko, D., "Multiple Provisioning Domain Architecture", 1124 draft-anipko-mif-mpvd-arch-05 (work in progress), November 1125 2013. 1127 [I-D.bhandari-dhc-class-based-prefix] 1128 Systems, C., Halwasia, G., Gundavelli, S., Deng, H., 1129 Thiebaut, L., Korhonen, J., and I. Farrer, "DHCPv6 class 1130 based prefix", draft-bhandari-dhc-class-based-prefix-05 1131 (work in progress), July 2013. 1133 [I-D.gundavelli-v6ops-community-wifi-svcs] 1134 Gundavelli, S., Grayson, M., Seite, P., and Y. Lee, 1135 "Service Provider Wi-Fi Services Over Residential 1136 Architectures", draft-gundavelli-v6ops-community-wifi- 1137 svcs-06 (work in progress), April 2013. 1139 [I-D.ietf-netext-pmip-cp-up-separation] 1140 Wakikawa, R., Pazhyannur, R., Gundavelli, S., and C. 1141 Perkins, "Separation of Control and User Plane for Proxy 1142 Mobile IPv6", draft-ietf-netext-pmip-cp-up-separation-07 1143 (work in progress), August 2014. 1145 [I-D.korhonen-6man-prefix-properties] 1146 Korhonen, J., Patil, B., Gundavelli, S., Seite, P., and D. 1147 Liu, "IPv6 Prefix Properties", draft-korhonen-6man-prefix- 1148 properties-02 (work in progress), July 2013. 1150 [IEEE.802-16.2009] 1151 "IEEE Standard for Local and metropolitan area networks 1152 Part 16: Air Interface for Broadband Wireless Access 1153 Systems", IEEE Standard 802.16, 2009, 1154 . 1157 [RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. 1158 Thubert, "Network Mobility (NEMO) Basic Support Protocol", 1159 RFC 3963, January 2005. 1161 [RFC4066] Liebsch, M., Singh, A., Chaskar, H., Funato, D., and E. 1162 Shim, "Candidate Access Router Discovery (CARD)", RFC 1163 4066, July 2005. 1165 [RFC4067] Loughney, J., Nakhjiri, M., Perkins, C., and R. Koodli, 1166 "Context Transfer Protocol (CXTP)", RFC 4067, July 2005. 1168 [RFC4225] Nikander, P., Arkko, J., Aura, T., Montenegro, G., and E. 1169 Nordmark, "Mobile IP Version 6 Route Optimization Security 1170 Design Background", RFC 4225, December 2005. 1172 [RFC4295] Keeni, G., Koide, K., Nagami, K., and S. Gundavelli, 1173 "Mobile IPv6 Management Information Base", RFC 4295, April 1174 2006. 1176 [RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol 1177 (MOBIKE)", RFC 4555, June 2006. 1179 [RFC4640] Patel, A. and G. Giaretta, "Problem Statement for 1180 bootstrapping Mobile IPv6 (MIPv6)", RFC 4640, September 1181 2006. 1183 [RFC4889] Ng, C., Zhao, F., Watari, M., and P. Thubert, "Network 1184 Mobility Route Optimization Solution Space Analysis", RFC 1185 4889, July 2007. 1187 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 1188 4960, September 2007. 1190 [RFC5014] Nordmark, E., Chakrabarti, S., and J. Laganier, "IPv6 1191 Socket API for Source Address Selection", RFC 5014, 1192 September 2007. 1194 [RFC5026] Giaretta, G., Kempf, J., and V. Devarapalli, "Mobile IPv6 1195 Bootstrapping in Split Scenario", RFC 5026, October 2007. 1197 [RFC5142] Haley, B., Devarapalli, V., Deng, H., and J. Kempf, 1198 "Mobility Header Home Agent Switch Message", RFC 5142, 1199 January 2008. 1201 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 1202 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 1204 [RFC5380] Soliman, H., Castelluccia, C., ElMalki, K., and L. 1205 Bellier, "Hierarchical Mobile IPv6 (HMIPv6) Mobility 1206 Management", RFC 5380, October 2008. 1208 [RFC5555] Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and 1209 Routers", RFC 5555, June 2009. 1211 [RFC5568] Koodli, R., "Mobile IPv6 Fast Handovers", RFC 5568, July 1212 2009. 1214 [RFC5844] Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy 1215 Mobile IPv6", RFC 5844, May 2010. 1217 [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, 1218 "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 1219 5996, September 2010. 1221 [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the 1222 Network Configuration Protocol (NETCONF)", RFC 6020, 1223 October 2010. 1225 [RFC6097] Korhonen, J. and V. Devarapalli, "Local Mobility Anchor 1226 (LMA) Discovery for Proxy Mobile IPv6", RFC 6097, February 1227 2011. 1229 [RFC6224] Schmidt, T., Waehlisch, M., and S. Krishnan, "Base 1230 Deployment for Multicast Listener Support in Proxy Mobile 1231 IPv6 (PMIPv6) Domains", RFC 6224, April 2011. 1233 [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. 1234 Bierman, "Network Configuration Protocol (NETCONF)", RFC 1235 6241, June 2011. 1237 [RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support 1238 in IPv6", RFC 6275, July 2011. 1240 [RFC6463] Korhonen, J., Gundavelli, S., Yokota, H., and X. Cui, 1241 "Runtime Local Mobility Anchor (LMA) Assignment Support 1242 for Proxy Mobile IPv6", RFC 6463, February 2012. 1244 [RFC6475] Keeni, G., Koide, K., Gundavelli, S., and R. Wakikawa, 1245 "Proxy Mobile IPv6 Management Information Base", RFC 6475, 1246 May 2012. 1248 [RFC6611] Chowdhury, K. and A. Yegin, "Mobile IPv6 (MIPv6) 1249 Bootstrapping for the Integrated Scenario", RFC 6611, May 1250 2012. 1252 [RFC6697] Zorn, G., Wu, Q., Taylor, T., Nir, Y., Hoeper, K., and S. 1253 Decugis, "Handover Keying (HOKEY) Architecture Design", 1254 RFC 6697, July 2012. 1256 [RFC6705] Krishnan, S., Koodli, R., Loureiro, P., Wu, Q., and A. 1257 Dutta, "Localized Routing for Proxy Mobile IPv6", RFC 1258 6705, September 2012. 1260 [RFC6724] Thaler, D., Draves, R., Matsumoto, A., and T. Chown, 1261 "Default Address Selection for Internet Protocol Version 6 1262 (IPv6)", RFC 6724, September 2012. 1264 [RFC7028] Zuniga, JC., Contreras, LM., Bernardos, CJ., Jeon, S., and 1265 Y. Kim, "Multicast Mobility Routing Optimizations for 1266 Proxy Mobile IPv6", RFC 7028, September 2013. 1268 [SDO-3GPP.23.401] 1269 3GPP, "General Packet Radio Service (GPRS) enhancements 1270 for Evolved Universal Terrestrial Radio Access Network 1271 (E-UTRAN) access", 3GPP TS 23.401 10.10.0, March 2013. 1273 [SDO-3GPP.23.402] 1274 3GPP, "Architecture enhancements for non-3GPP accesses", 1275 3GPP TS 23.402 10.8.0, September 2012. 1277 [SDO-3GPP.24.303] 1278 3GPP, "Mobility management based on Dual-Stack Mobile 1279 IPv6; Stage 3", 3GPP TS 24.303 10.0.0, June 2013. 1281 [SDO-3GPP.29.060] 1282 3GPP, "General Packet Radio Service (GPRS); GPRS 1283 Tunnelling Protocol (GTP) across the Gn and Gp interface", 1284 3GPP TS 29.060 3.19.0, March 2004. 1286 [SDO-3GPP.29.274] 1287 3GPP, "3GPP Evolved Packet System (EPS); Evolved General 1288 Packet Radio Service (GPRS) Tunnelling Protocol for 1289 Control plane (GTPv2-C); Stage 3", 3GPP TS 29.274 10.11.0, 1290 June 2013. 1292 [SDO-3GPP.29.281] 1293 3GPP, "General Packet Radio System (GPRS) Tunnelling 1294 Protocol User Plane (GTPv1-U)", 3GPP TS 29.281 10.3.0, 1295 September 2011. 1297 [SDO-3GPP.29.303] 1298 3GPP, "Domain Name System Procedures; Stage 3", 3GPP TS 1299 29.303 10.4.0, September 2012. 1301 Authors' Addresses 1303 Dapeng Liu (editor) 1304 China Mobile 1305 Unit2, 28 Xuanwumenxi Ave, Xuanwu District 1306 Beijing 100053 1307 China 1309 Email: liudapeng@chinamobile.com 1311 Juan Carlos Zuniga (editor) 1312 InterDigital Communications, LLC 1313 1000 Sherbrooke Street West, 10th floor 1314 Montreal, Quebec H3A 3G4 1315 Canada 1317 Email: JuanCarlos.Zuniga@InterDigital.com 1318 URI: http://www.InterDigital.com/ 1320 Pierrick Seite 1321 Orange 1322 4, rue du Clos Courtel, BP 91226 1323 Cesson-Sevigne 35512 1324 France 1326 Email: pierrick.seite@orange.com 1327 H Anthony Chan 1328 Huawei Technologies 1329 5340 Legacy Dr. Building 3 1330 Plano, TX 75024 1331 USA 1333 Email: h.a.chan@ieee.org 1335 Carlos J. Bernardos 1336 Universidad Carlos III de Madrid 1337 Av. Universidad, 30 1338 Leganes, Madrid 28911 1339 Spain 1341 Phone: +34 91624 6236 1342 Email: cjbc@it.uc3m.es 1343 URI: http://www.it.uc3m.es/cjbc/