idnits 2.17.1 draft-ietf-dmm-best-practices-gap-analysis-06.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 == Line 69 has weird spacing: '...support for e...' == Line 73 has weird spacing: '...s/hosts and o...' -- The document date (July 4, 2014) is 3577 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-07) exists of draft-ietf-netext-pmip-cp-up-separation-05 -- Obsolete informational reference (is this intentional?): RFC 5996 (Obsoleted by RFC 7296) Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 2 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: January 5, 2015 InterDigital 6 P. Seite 7 Orange 8 H. Chan 9 Huawei Technologies 10 CJ. Bernardos 11 UC3M 12 July 4, 2014 14 Distributed Mobility Management: Current practices and gap analysis 15 draft-ietf-dmm-best-practices-gap-analysis-06 17 Abstract 19 The present document analyzes deployment practices of existing IP 20 mobility protocols in a distributed mobility management environment. 21 It then identifies existing limitations when compared to the 22 requirements 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 January 5, 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. 3GPP network flattening 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 . . . . . . . . . . . . . . . . . 20 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 . . . . . . . . . . . . . 22 77 5.8. Multicast - REQ8 . . . . . . . . . . . . . . . . . . . . 23 78 5.9. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 23 79 6. Security Considerations . . . . . . . . . . . . . . . . . . . 24 80 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 81 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 82 8.1. Normative References . . . . . . . . . . . . . . . . . . 24 83 8.2. Informative References . . . . . . . . . . . . . . . . . 25 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 86 1. Introduction 88 The distributed mobility management (DMM) WG has studied the problems 89 of centralized deployment of mobility management protocols and 90 specified the DMM requirements [I-D.ietf-dmm-requirements]. This 91 document investigates whether it is feasible to deploy current IP 92 mobility protocols in a DMM scenario in a way that can fulfill the 93 requirements. It discusses current deployment practices of existing 94 mobility protocols and identifies the limitations (gaps) in these 95 practices from the standpoint of satisfying DMM requirements, as 96 defined in [I-D.ietf-dmm-requirements]. 98 The rest of this document is organized as follows. Section 3 99 analyzes existing IP mobility protocols by examining their functions 100 and how these functions can be configured and used to work in a DMM 101 environment. Section 4 presents the current practices of IP wireless 102 networks and 3GPP architectures. Both network- and host-based 103 mobility protocols are considered. Section 5 presents the gap 104 analysis with respect to the current practices. 106 2. Terminology 108 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 109 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 110 document are to be interpreted as described in [RFC2119]. 112 All general mobility-related terms and their acronyms used in this 113 document are to be interpreted as defined in the Mobile IPv6 base 114 specification [RFC6275] and in the Proxy mobile IPv6 specification 115 [RFC5213]. These terms include mobile node (MN), correspondent node 116 (CN), home agent (HA), local mobility anchor (LMA), and mobile access 117 gateway (MAG). 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 anchors to manage IP 127 mobility sessions. 129 3. Functions of existing mobility protocols 131 The host-based Mobile IPv6 [RFC6275] and its network-based extension, 132 PMIPv6 [RFC5213], even HMIPv6 [RFC5380] are logically centralized 133 mobility management approaches addressing primarily hierarchical 134 mobile networks. Although these two are centralized approaches, they 135 have important mobility management functions resulting from years of 136 extensive work to develop and to extend these functions. It is 137 therefore useful to take these existing functions and examine them in 138 a DMM scenario in order to understand how to deploy the existing 139 mobility protocols to provide distributed mobility management. 141 The main mobility management functions of MIPv6, PMIPv6, and HMIPv6 142 are the following: 144 1. Anchoring function (AF): allocation to a mobile node of an IP 145 address (a Home Address (HoA)) or prefix (a Home Network Prefix 146 (HNP)) topologically anchored by the advertising node (i.e., the 147 anchor node is able to advertise a connected route into the 148 routing infrastructure for the allocated IP prefixes). It is a 149 control plane function. 151 2. Internetwork Location Information (LI) function: managing and 152 keeping track of the internetwork location of an MN. The 153 location information may be a binding of the IP advertised 154 address/prefix (e.g., HoA or HNP) to the IP routing address of 155 the MN or of a node that can forward packets destined to the MN. 156 It is a control plane function. 158 In a client-server protocol model, location query and update 159 messages may be exchanged between a location information client 160 (LIc) and a location information server (LIs). 162 3. Forwarding Management (FM) function: packet interception and 163 forwarding to/from the IP address/prefix assigned to the MN, 164 based on the internetwork location information, either to the 165 destination or to some other network element that knows how to 166 forward the packets to their destination. 168 FM may optionally be split into the control plane (FM-CP) and 169 data plane (FM-DP). 171 In Mobile IPv6, the home agent (HA) typically provides the anchoring 172 function (AF); the location information server (LIs) is at the HA 173 while the location information client (LIc) is at the MN; the 174 forwarding management (FM) function is both ends of tunneling at the 175 HA and the MN. 177 In Proxy Mobile IPv6, the Local Mobility Anchor (LMA) provides the 178 anchoring function (AF); the location information server (LIs) is at 179 the LMA while the location information client (LIc) is at the mobile 180 access gateway (MAG); the forwarding management (FM) function is both 181 ends of tunneling at the HA and the MAG. 183 In Hierarchical mobile IPv6 (HMIPv6) [RFC5380], the mobility anchor 184 point (MAP) serves as a location information aggregator between the 185 LIs at the HA and the LIc at the MN. The MAP also has FM function to 186 enable tunneling between HA and itself as well as tunneling between 187 MN and itself. 189 4. DMM practices 191 This section documents deployment practices of existing mobility 192 protocols to satisfy distributed mobility management requirement. 193 This description considers both IP wireless (e.g., evolved Wi-Fi 194 hotspots) and 3GPP Architecture flattening approaches(i.e. fewer 195 levels of routing hierarchy introduced into the data path by the 196 mobility management system). 198 While describing the current DMM practices, references to the generic 199 mobility management functions described in Section 3 are provided, as 200 well as some initial hints on the identified gaps with respect to the 201 DMM requirements documented in [I-D.ietf-dmm-requirements]. 203 4.1. Assumptions 205 There are many different approaches that can be considered to 206 implement and deploy a distributed anchoring and mobility solution. 207 The focus of the gap analysis is on certain current mobile network 208 architectures and standardized IP mobility solutions, considering any 209 kind of deployment options which do not violate the original protocol 210 specifications. In order to limit the scope of our analysis of DMM 211 practices, we consider the following list of technical assumptions: 213 1. Both host- and network-based solutions should be considered. 215 2. Solutions should allow selecting and using the most appropriate 216 IP anchor among a set of available candidates. 218 3. Mobility management should be realized by the preservation of the 219 IP address across the different points of attachment (i.e., 220 provision of IP address continuity). This is in contrast to 221 certain transport-layer based approaches such as SCTP or 222 application-layer 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 [RFC- 232 SourceAddrSelection]. 234 4.2. IP flat wireless network 236 This section focuses on common IP wireless network architectures and 237 how they can be flattened from an IP mobility and anchoring point of 238 view using common and standardized protocols. We take Wi-Fi as an 239 useful wireless technology, since it is widely known and deployed 240 nowadays. Some representative examples of Wi-Fi deployment 241 architectures are depicted in Figure 1. 243 +-------------+ _----_ 244 +---+ | Access | _( )_ 245 |AAA|. . . . . . | Aggregation |----------( Internet ) 246 +---+ | Gateway | (_ _) 247 +-------------+ '----' 248 | | | 249 | | +-------------+ 250 | | | 251 | | +-----+ 252 +---------------+ | | AR | 253 | | +--+--+ 254 +-----+ +-----+ *----+----* 255 | RG | | WLC | ( LAN ) 256 +-----+ +-----+ *---------* 257 . / \ / \ 258 / \ +-----+ +-----+ +-----+ +-----+ 259 MN MN |Wi-Fi| |Wi-Fi| |Wi-Fi| |Wi-Fi| 260 | AP | | AP | | AP | | AP | 261 +-----+ +-----+ +-----+ +-----+ 262 . . 263 / \ / \ 264 MN MN MN MN 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 directly connect to a Residential Gateway 271 (RG) which is a network device at the customer premises and provides 272 both wireless layer-2 access connectivity (i.e., it hosts the 802.11 273 Access Point function) and layer-3 routing functions. In the middle 274 of the figure, mobile nodes connect to Wi-Fi Access Points (APs) that 275 are managed by a WLAN Controller (WLC), which performs radio resource 276 management on the APs, domain-wide mobility policy enforcement and 277 centralized forwarding function for the user traffic. The WLC could 278 also implement layer-3 routing functions, or attach to an access 279 router (AR). Last, on the right-hand side of the figure, access 280 points are directly connected to an access router. This can also be 281 used as a generic connectivity model. 283 IP mobility protocols can be used to provide inter-access mobility 284 support to users, e.g. handover from Wi-Fi to cellular access. Two 285 kind of protocols can be used: Proxy Mobile IPv6 [RFC5213] or Mobile 286 IPv6 [RFC5555], with the mobility anchor (e.g., local mobility anchor 287 or home agent) role typically being played by the edge router of the 288 mobile network [SDO-3GPP.23.402]. 290 Although this section has made use of the example of Wi-Fi networks, 291 there are other IP flat wireless network architectures specified, 292 such as WiMAX [IEEE.802-16.2009], which integrates both host and 293 network-based IP mobility functionality. 295 Existing IP mobility protocols can also be deployed in a more 296 flattened manner, so that the anchoring and access aggregation 297 functions are distributed. We next describe several practices for 298 the deployment of existing mobility protocols in a distributed 299 mobility management environment. The analysis in this section is 300 limited to protocol solutions based on existing IP mobility 301 protocols, either host- or network-based, such as Mobile IPv6 302 [RFC6275], [RFC5555], Proxy Mobile IPv6 [RFC5213], [RFC5844] and NEMO 303 [RFC3963]. Extensions to these base protocol solutions are also 304 considered. The analysis is divided into two parts: host- and 305 network-based practices. 307 4.2.1. Host-based IP DMM practices 309 Mobile IPv6 (MIPv6) [RFC6275] and its extension to support mobile 310 networks, the NEMO Basic Support protocol (hereafter, simply referred 311 to as NEMO) [RFC3963] are well-known host-based IP mobility 312 protocols. They depend upon the function of the Home Agent (HA), a 313 centralized anchor, to provide mobile nodes (hosts and routers) with 314 mobility support. In these approaches, the home agent typically 315 provides the anchoring function (AF), forwarding management (FM), and 316 Internetwork Location Information server (LIs) functions. The mobile 317 node possesses the Location Information client (LIc) function and the 318 FM function to enable tunneling between HA and itself. We next 319 describe some practices that show how MIPv6/NEMO and several other 320 protocol extensions can be deployed in a distributed mobility 321 management environment. 323 One approach to distribute the anchors can be to deploy several HAs 324 (as shown in Figure 2), and assign the topologically closest anchor 325 to each MN [RFC4640], [RFC5026], [RFC6611]. In the example shown in 326 Figure 2, MN1 is assigned HA1 (and a home address anchored by HA1), 327 while MN2 is assigned HA2. Note that MIPv6/NEMO specifications do 328 not prevent the simultaneous use of multiple home agents by a single 329 mobile node. In this deployment model, the mobile node can use 330 several anchors at the same time, each of them anchoring IP flows 331 initiated at a different point of attachment. However there is no 332 mechanism specified by IETF to enable an efficient dynamic discovery 333 of available anchors and the selection of the most suitable one. 334 Note that some of these mechanisms [SDO-3GPP.23.402] have been 335 defined outside IETF. 337 <- INTERNET -> <- HOME NETWORK -> <---- ACCESS NETWORK ----> 338 ------- ------- 339 | CN1 | ------- | AR1 |-(o) zzzz (o) 340 ------- | HA1 | ------- | 341 ------- (MN1 anchored at HA1) ------- 342 ------- | MN1 | 343 | AR2 |-(o) ------- 344 ------- 345 ------- 346 | HA2 | ------- 347 ------- | AR3 |-(o) zzzz (o) 348 ------- | 349 ------- (MN2 anchored at HA2) ------- 350 | CN2 | ------- | MN2 | 351 ------- | AR4 |-(o) ------- 352 ------- 354 CN1 CN2 HA1 HA2 AR1 MN1 AR3 MN2 355 | | | | | | | | 356 |<------------>|<=================+=====>| | | BT mode 357 | | | | | | | | 358 | |<----------------------------------------+----->| RO mode 359 | | | | | | | | 361 Figure 2: Distributed operation of Mobile IPv6 (BT and RO) / NEMO 363 Since one of the goals of the deployment of mobility protocols in a 364 distributed mobility management environment is to avoid the 365 suboptimal routing caused by centralized anchoring, the Route 366 Optimization (RO) support provided by Mobile IPv6 can also be used to 367 achieve a flatter IP data forwarding. By default, Mobile IPv6 and 368 NEMO use the so-called Bidirectional Tunnel (BT) mode, in which data 369 traffic is always encapsulated between the MN and its HA before being 370 directed to any other destination. The Route Optimization (RO) mode 371 allows the MN to update its current location on the CNs, and then use 372 the direct path between them. Using the example shown in Figure 2, 373 MN1 is using BT mode with CN1 and MN2 is in RO mode with CN2. 374 However, the RO mode has several drawbacks: 376 o The RO mode is only supported by Mobile IPv6. There is no route 377 optimization support standardized for the NEMO protocol because of 378 the security problems posed by extending return routability tests 379 for prefixes, although many different solutions have been proposed 380 [RFC4889]. 382 o The RO mode requires signaling that adds some protocol overhead. 384 o The signaling required to enable RO involves the home agent and is 385 repeated periodically for security reasons [RFC4225] and, thus, 386 the HA remains a single point of failure. 388 o The RO mode requires support from the correspondent node (CN). 390 Notwithstanding these considerations, the RO mode does offer the 391 possibility of substantially reducing traffic through the Home Agent, 392 in cases when it can be supported by the relevant correspondent 393 nodes. Note that a mobile node can also use its CoA directly 394 [RFC5014] when communicating with CNs on the same link or anywhere in 395 the Internet, although no session continuity support would be 396 provided by the IP stack in this case. 398 Hierarchical Mobile IPv6 (HMIPv6) [RFC5380] (as shown in Figure 3), 399 is another host-based IP mobility extension which can be considered 400 as a complement to provide a less centralized mobility deployment. 401 It allows reducing the amount of mobility signaling as well as 402 improving the overall handover performance of Mobile IPv6 by 403 introducing a new hierarchy level to handle local mobility. The 404 Mobility Anchor Point (MAP) entity is introduced as a local mobility 405 handling node deployed closer to the mobile node. It provides LI 406 intermediary function between the LI server (LIs) at the HA and the 407 LI client (LIc) at the MN. It also performs the FM function using 408 tunneling with the HA and also to tunnel with the MN. 410 <- INTERNET -> <- HOME NETWORK -> <------- ACCESS NETWORK -------> 411 ----- 412 /|AR1|-(o) zz (o) 413 -------- / ----- | 414 | MAP1 |< ------- 415 -------- \ ----- | MN1 | 416 ------- \|AR2| ------- 417 | CN1 | ----- HoA anchored 418 ------- ----- at HA1 419 ------- /|AR3| RCoA anchored 420 | HA1 | -------- / ----- at MAP1 421 ------- | MAP2 |< LCoA anchored 422 -------- \ ----- at AR1 423 \|AR4| 424 ------- ----- 425 | CN2 | ----- 426 ------- /|AR5| 427 -------- / ----- 428 | MAP3 |< 429 -------- \ ----- 430 \|AR6| 431 ----- 433 CN1 CN2 HA1 MAP1 AR1 MN1 434 | | | | ________|__________ | 435 |<------------------>|<==============>|<________+__________>| HoA 436 | | | | | | 437 | |<-------------------------->|<===================>| RCoA 438 | | | | | | 440 Figure 3: Hierarchical Mobile IPv6 442 When HMIPv6 is used, the MN has two different temporary addresses: 443 the Regional Care-of Address (RCoA) and the Local Care-of Address 444 (LCoA). The RCoA is anchored at one MAP, that plays the role of 445 local home agent, while the LCoA is anchored at the access router 446 level. The mobile node uses the RCoA as the CoA signaled to its home 447 agent. Therefore, while roaming within a local domain handled by the 448 same MAP, the mobile node does not need to update its home agent 449 (i.e., the mobile node does not change its RCoA). 451 The use of HMIPv6 enables some form of route optimization, since a 452 mobile node may decide to directly use the RCoA as source address for 453 a communication with a given correspondent node, particularly if the 454 MN does not expect to move outside the local domain during the 455 lifetime of the communication. This can be seen as a potential DMM 456 mode of operation,though it fails to provide session continuity if 457 and when the MN moves outside the local domain. In the example shown 458 in Figure 3, MN1 is using its global HoA to communicate with CN1, 459 while it is using its RCoA to communicate with CN2. 461 Furthermore, a local domain might have several MAPs deployed, 462 enabling therefore a different kind of HMIPv6 deployments (e.g., flat 463 and distributed). The HMIPv6 specification supports a flexible 464 selection of the MAP (e.g., based on the distance between the MN and 465 the MAP, taking into consideration the expected mobility pattern of 466 the MN, etc.). 468 Another extension that can be used to help distributing mobility 469 management functions is the Home Agent switch specification 470 [RFC5142], which defines a new mobility header for signaling a mobile 471 node that it should acquire a new home agent. [RFC5142] does not 472 specify the case of changing the mobile node's home address, as that 473 might imply loss of connectivity for ongoing persistent connections. 474 Nevertheless, that specification could be used to force the change of 475 home agent in those situations where there are no active persistent 476 data sessions that cannot cope with a change of home address. 478 There are other host-based approaches standardized within IETF that 479 can be used to provide mobility support. For example MOBIKE 480 [RFC4555] allows a mobile node encrypting traffic through IKEv2 481 [RFC5996] to change its point of attachment while maintaining a 482 Virtual Private Network (VPN) session. The MOBIKE protocol allows 483 updating the VPN Security Associations (SAs) in cases where the base 484 connection initially used is lost and needs to be re-established. 485 The use of the MOBIKE protocol avoids having to perform an IKEv2 re- 486 negotiation. Similar considerations to those made for Mobile IPv6 487 can be applied to MOBIKE; though MOBIKE is best suited for situations 488 where the address of at least one endpoint is relatively stable and 489 can be discovered using existing mechanisms such as DNS. 491 IETF has defined extensions to the mobility protocol to optimize the 492 handover performance. Mobile IPv6 Fast Handovers (FMIPv6) [RFC5568] 493 is the extension to optimize handover latency. It defines new access 494 router discovery mechanism before handover to reduce the new network 495 discovery latency. It also defines a tunnel between the previous 496 access router and the new access router to reduce the packet loss 497 during handover. IETF seamoby working group also has published 498 Candidate Access Router Discovery (CARD) [RFC4066] and Context 499 Transfer Protocol (CXTP) [RFC4067] to improve the handover 500 performance. The DMM deployment practice discussed in this section 501 can also use those extensions to improve the handover performance. 503 4.2.2. Network-based IP DMM practices 505 Proxy Mobile IPv6 (PMIPv6) [RFC5213] is the main network-based IP 506 mobility protocol specified for IPv6. Proxy Mobile IPv4 [RFC5844] 507 defines some IPv4 extensions. With network-based IP mobility 508 protocols, the local mobility anchor (LMA) typically provides the 509 anchoring function (AF), Forwarding management (FM) function, and 510 Internetwork Location Information server (LIs) function. The mobile 511 access gateway (MAG) provides the Location Information client (LIc) 512 function and Forwarding management (FM) function to tunnel with LMA. 513 PMIPv6 is architecturally almost identical to MIPv6, as the mobility 514 signaling and routing between LMA and MAG in PMIPv6 is similar to 515 those between HA and MN in MIPv6. The required mobility 516 functionality at the MN is provided by the MAG so that the 517 involvement in mobility support by the MN is not required. 519 We next describe some practices that show how network-based mobility 520 protocols and several other protocol extensions can be deployed in a 521 distributed mobility management environment. 523 One way to decentralize Proxy Mobile IPv6 operation can be to deploy 524 several local mobility anchors and use some selection criteria to 525 assign LMAs to attaching mobile nodes (an example of this type of 526 assignment is shown in Figure 4). As with the client based approach, 527 a mobile node may use several anchors at the same time, each of them 528 anchoring IP flows initiated at a different point of attachment. 529 This assignment can be static or dynamic. The main advantage of this 530 simple approach is that the IP address anchor (i.e., the LMA) could 531 be placed closer to the mobile node. Therefore the resulting paths 532 are close-to-optimal. On the other hand, as soon as the mobile node 533 moves, the resulting path will start deviating from the optimal one. 535 <- INTERNET -><- HOME NET -><----------- ACCESS NETWORK ------------> 536 ------- 537 | CN1 | -------- -------- -------- 538 ------- -------- | MAG1 | | MAG2 | | MAG3 | 539 | LMA1 | ---+---- ---+---- ---+---- 540 ------- -------- | | | 541 | CN2 | (o) (o) (o) 542 ------- -------- x x 543 | LMA2 | x x 544 ------- -------- (o) (o) 545 | CN3 | | | 546 ------- ---+--- ---+--- 547 Anchored | MN1 | Anchored | MN2 | 548 at LMA1 -> ------- at LMA2 -> ------- 550 CN1 CN2 LMA1 LMA2 MAG1 MN1 MAG3 MN2 551 | | | | | | | | 552 |<------------>|<================>|<---->| | | 553 | | | | | | | | 554 | |<------------>|<========================>|<----->| 555 | | | | | | | | 557 Figure 4: Distributed operation of Proxy Mobile IPv6 559 Similar to the host-based IP mobility case, network-based IP mobility 560 has some extensions defined to mitigate the suboptimal routing issues 561 that may arise due to the use of a centralized anchor. The Local 562 Routing extensions [RFC6705] enable optimal routing in Proxy Mobile 563 IPv6 in three cases: i) when two communicating MNs are attached to 564 the same MAG and LMA, ii) when two communicating MNs are attached to 565 different MAGs but to the same LMA, and iii) when two communicating 566 MNs are attached to the same MAG but have different LMAs. In these 567 three cases, data traffic between the two mobile nodes does not 568 traverse the LMA(s), thus providing some form of path optimization 569 since the traffic is locally routed at the edge. The main 570 disadvantage of this approach is that it only tackles the MN-to-MN 571 communication scenario, and only under certain circumstances. 573 An interesting extension that can also be used to facilitate the 574 deployment of network-based mobility protocols in a distributed 575 mobility management environment is the LMA runtime assignment 576 [RFC6463]. This extension specifies a runtime local mobility anchor 577 assignment functionality and corresponding mobility options for Proxy 578 Mobile IPv6. This runtime local mobility anchor assignment takes 579 place during the Proxy Binding Update / Proxy Binding Acknowledgment 580 message exchange between a mobile access gateway and a local mobility 581 anchor. While this mechanism is mainly aimed for load-balancing 582 purposes, it can also be used to select an optimal LMA from the 583 routing point of view. A runtime LMA assignment can be used to 584 change the assigned LMA of an MN, for example, in cases when the 585 mobile node does not have any active session, or when the running 586 sessions can survive an IP address change. Note that several 587 possible dynamic local mobility anchor discovery solutions can be 588 used, as described in [RFC6097]. 590 4.3. 3GPP network flattening approaches 592 The 3rd Generation Partnership Project (3GPP) is the standards 593 development organization that specifies the 3rd generation mobile 594 network and the Evolved Packet System (EPS), which mainly comprises 595 the Evolved Packet Core (EPC) and a new radio access network, usually 596 referred to as LTE (Long Term Evolution). 598 Architecturally, the 3GPP Evolved Packet Core (EPC) network is 599 similar to an IP wireless network running PMIPv6 or MIPv6, as it 600 relies on the Packet Data Gateway (PGW) anchoring services to provide 601 mobile nodes with mobility support (see Figure 5). There are client- 602 based and network-based mobility solutions in 3GPP, which for 603 simplicity will be analyzed together. We next describe how 3GPP 604 mobility protocols and several other completed or ongoing extensions 605 can be deployed to meet some of the DMM requirements 606 [I-D.ietf-dmm-requirements]. 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 |....................................(Operator's CN) 667 | Equipm. |.................. 668 +---------+ . Local IP traffic 669 . 670 +-----------+ 671 |Residential| 672 |enterprise | 673 |IP network | 674 +-----------+ 676 Figure 6: LIPA scenario 678 SIPTO enables an operator to offload certain types of traffic at a 679 network node close to the UE's point of attachment to the access 680 network, by selecting a set of GWs (SGW and PGW) that are 681 geographically/topologically close to the UE's point of attachment. 683 SIPTO Traffic 684 | 685 . 686 . 687 +------+ +------+ 688 |L-PGW | ---- | MME | 689 +------+ / +------+ 690 | / 691 +-------+ +------+ +------+/ +------+ 692 | UE |.....|eNB |....| S-GW |........| P-GW |...> CN Traffic 693 +-------+ +------+ +------+ +------+ 695 Figure 7: SIPTO architecture 697 LIPA, on the other hand, enables an IP addressable UE connected via a 698 Home eNB (HeNB) to access other IP addressable entities in the same 699 residential/enterprise IP network without traversing the mobile 700 operator's network core in the user plane. In order to achieve this, 701 a Local GW (L-GW) collocated with the HeNB is used. LIPA is 702 established by the UE requesting a new PDN (Public Data Network) 703 connection to an access point name for which LIPA is permitted, and 704 the network selecting the Local GW associated with the HeNB and 705 enabling a direct user plane path between the Local GW and the HeNB. 707 +---------------+-------+ +----------+ +-------------+ ===== 708 |Residential | |H(e)NB | | Backhaul | |Mobile | ( IP ) 709 |Enterprise |..|-------|..| |..|Operator |..(Network) 710 |Network | |L-GW | | | |Core network | ======= 711 +---------------+-------+ +----------+ +-------------+ 712 / 713 | 714 / 715 +-----+ 716 | UE | 717 +-----+ 719 Figure 8: LIPA architecture 721 The 3GPP architecture specifications also provide mechanisms to allow 722 discovery and selection of gateways [SDO-3GPP.29.303]. These 723 mechanisms enable decisions taking into consideration topological 724 location and gateway collocation aspects, relying upon the DNS as a 725 "location database". 727 Both SIPTO and LIPA have a very limited mobility support, specially 728 in 3GPP specifications up to Rel-12. Briefly, LIPA mobility support 729 is limited to handovers between HeNBs that are managed by the same 730 L-GW (i.e., mobility within the local domain). There is no guarantee 731 of IP session continuity for SIPTO. 733 5. Gap analysis 735 The goal of this section is to identify the limitations in the 736 current practices, described in Section 4, with respect to the DMM 737 requirements listed in [I-D.ietf-dmm-requirements]. 739 5.1. Distributed mobility management - REQ1 741 According to requirement #1 stated in [I-D.ietf-dmm-requirements], IP 742 mobility, network access and forwarding solutions provided by DMM 743 must enable traffic to avoid traversing single mobility anchor far 744 from the optimal route. 746 From the analysis performed in Section 4, a DMM deployment can meet 747 the requirement "REQ#1 Distributed mobility management" usually 748 relying on the following functions: 750 o Multiple (distributed) anchoring: ability to anchor different 751 sessions of a single mobile node at different anchors. In order 752 to provide improved routing, some anchors might need to be placed 753 closer to the mobile node or the corresponding node. 755 o Dynamic anchor assignment/re-location: ability to i) assign the 756 initial anchor, and ii) dynamically change the initially assigned 757 anchor and/or assign a new one (this may also require to transfer 758 mobility context between anchors). This can be achieved either by 759 changing anchor for all ongoing sessions or by assigning new 760 anchors just for new sessions. 762 Both the main client- and network-based IP mobility protocols, namely 763 (DS)MIPv6 and PMIPv6 allow deploying multiple anchors (i.e., home 764 agents and localized mobility anchors), therefore providing the 765 multiple anchoring function. However, existing solutions only 766 provide a initial anchor assignment, thus the lack of dynamic anchor 767 change/new anchor assignment is a gap. Neither the HA switch nor the 768 LMA runtime assignment allow changing the anchor during an ongoing 769 session. This actually comprises several gaps: ability to perform 770 anchor assignment at any time (not only at the initial MN's 771 attachment), ability of the current anchor to initiate/trigger the 772 relocation, and ability to transfer registration context between 773 anchors. 775 Dynamic anchor assignment may lead the MN to manage different 776 mobility sessions served by different mobility anchors. This is not 777 an issue with client based mobility management where the mobility 778 client natively knows each anchor associated to each mobility 779 sessions. However, there is one gap, as the MN should be capable of 780 handling IP addresses in a DMM-friendly way, meaning that the MN can 781 perform smart source address selection (i.e., deprecating IP 782 addresses from previous mobility anchors, so they are not used for 783 new sessions). Besides, managing different mobility sessions served 784 by different mobility anchors may raise issues with network based 785 mobility management. In this case, the mobile client, located in the 786 network (e.g., MAG), usually retrieves the MN's anchor from the MN's 787 policy profile (e.g., Section 6.2 of [RFC5213]). Currently, the MN's 788 policy profile implicitly assumes a single serving anchor and, thus, 789 does not maintain the association between home network prefix and 790 anchor. 792 The consequence of the distribution of the mobility anchors is that 793 there might be more than one available anchor for a mobile node to 794 use, which leads to an anchor discovery and selection issue. 795 Currently, there is no efficient mechanism specified by IETF to allow 796 dynamically discovering the presence of nodes that can play the 797 anchor role, discovering their capabilities and selecting the most 798 suitable one. There is also no mechanism to allow selecting a node 799 that is currently anchoring a given home address/prefix (capability 800 sometimes required to meet REQ#2). There are though some mechanisms 801 that could help discovering anchors, such as the Dynamic Home Agent 802 Address Discovery (DHAAD), the use of the Home Agent (H) flag in 803 Router Advertisements (which indicates that the router sending the 804 Router Advertisement is also functioning as a Mobile IPv6 home agent 805 on the link) or the MAP option in Router Advertisements defined by 806 HMIPv6. Note that there are 3GPP mechanisms providing that 807 functionality defined in [SDO-3GPP.29.303]. 809 Regarding the ability to transfer registration context between 810 anchors, there are already some solutions that could be reused or 811 adapted to fill that gap, such as Fast Handovers for Mobile IPv6 812 [RFC5568] -- to enable traffic redirection from the old to the new 813 anchor --, the Context Transfer protocol [RFC4067] -- to enable the 814 required transfer of registration information between anchors --, or 815 the Handover Keying architecture solutions [RFC6697], to speed up the 816 re-authentication process after a change of anchor. Note that some 817 extensions might be needed in the context of DMM, as these protocols 818 were designed in the context of centralized client IP mobility, 819 focusing on the access re-attachment and authentication. 821 Also note that REQ1 is such that the data plane traffic can avoid 822 suboptimal route. Distributed processing of the traffic is then 823 needed only in the data plane. The needed capability in distributed 824 processing therefore should not contradict with centralized control 825 plane. Other control plane solutions such as charging, lawful 826 interception, etc. should not be limited. Yet combining the control 827 plane and data plane forwarding management (FM) function may limit 828 the choice to distributing both data plane and control plane 829 together. In order to enable distributing only the data plane 830 without distributing the control plane, a gap is to split the 831 forwarding management function into the control plane (FM-CP) and 832 data plane (FM-DP). 834 5.2. Bypassable network-layer mobility support for each application 835 session - REQ2 837 The need for "bypassable network-layer mobility support for each 838 application session" introduced in [I-D.ietf-dmm-requirements] 839 requires flexibility on determining whether network-layer mobility 840 support is needed. The requirement enables one to choose whether or 841 not use network-layer mobility support. It only enables the two 842 following functions: 844 o Dynamically assign/relocate anchor: a mobility anchor is assigned 845 only to sessions which uses the network-layer mobility support. 846 The MN may thus manage more than one session; some of them may be 847 associated with anchored IP address(es), while the others may be 848 associated with local IP address(es). 850 o Multiple IP address management: this function is related to the 851 preceding and is about the ability of the mobile node to 852 simultaneously use multiple IP addresses and select the best one 853 (from an anchoring point of view) to use on a per-session/ 854 application/service basis. This requires MN to acquire 855 information regarding the properties of the available IP 856 addresses. 858 The dynamic anchor assignment/relocation needs to ensure that IP 859 address continuity is guaranteed for sessions that uses such mobility 860 support (e.g., in some scenarios, the provision of mobility locally 861 within a limited area might be enough from the mobile node or the 862 application point of view) at the relocated anchor. Implicitly, when 863 no applications are using the network-layer mobility support, DMM may 864 release the needed resources. This may imply having the knowledge of 865 which sessions at the mobile node are active and are using the 866 mobility support. This is something typically known only by the MN 867 (e.g., by its connection manager). Therefore, (part of) this 868 knowledge might need to be transferred to/shared with the network. 870 Multiple IP address management provides the MN with the choice to 871 pick-up the correct address (provided with mobility support or not) 872 depending on the application requirements. When using client based 873 mobility management, the mobile node is itself aware of the anchoring 874 capabilities of its assigned IP addresses. This is not necessarily 875 the case with network based IP mobility management; current 876 mechanisms do not allow the MN to be aware of the properties of its 877 IP addresses (e.g., the MN does not know whether the allocated IP 878 addresses are anchored). However, there are proposals that the 879 network could indicate such IP address properties during assignment 880 procedures, such as [I-D.bhandari-dhc-class-based-prefix], 881 [I-D.korhonen-6man-prefix-properties] and [I-D.anipko-mif-mpvd-arch]. 882 Although there exist these individual efforts that could be be 883 considered as attempts to fix the gap, there is no solution adopted 884 as a work item within any IETF working group. 886 The handling of mobility management to the granularity of an 887 individual session of a user/device SHOULD need proper session 888 identification in addition to user/device identification. 890 5.3. IPv6 deployment - REQ3 892 This requirement states that DMM solutions should primarily target 893 IPv6 as the primary deployment environment. IPv4 support is not 894 considered mandatory and solutions should not be tailored 895 specifically to support IPv4. 897 All analyzed DMM practices support IPv6. Some of them, such as 898 MIPv6/NEMO (including the support of dynamic HA selection), MOBIKE, 899 SIPTO have also IPv4 support. There are also some solutions that 900 have some limited IPv4 support (e.g., PMIPv6). In conclusion, this 901 requirement is met by existing DMM practices. 903 5.4. Existing mobility protocols - REQ4 905 A DMM solution must first consider reusing and extending IETF- 906 standardized protocols before specifying new protocols. 908 As stated in [I-D.ietf-dmm-requirements], a DMM solution could reuse 909 existing IETF and standardized protocols before specifying new 910 protocols. Besides, Section 4 of this document discusses various 911 ways to flatten and distribute current mobility solutions. Actually, 912 nothing prevent the distribution of mobility functions with in IP 913 mobility protocols. However, as discussed in Section 5.1 and 914 Section 5.2, limitations exist. 916 The 3GPP data plane anchoring function, i.e., the PGW, can be also be 917 distributed, but with limitations; e.g., no anchoring relocation, no 918 context transfer between anchors and centralized control plane. The 919 3GPP architecture is also going into the direction of flattening with 920 SIPTO and LIPA, though they do not provide full mobility support. 921 For example, mobility support for SIPTO traffic can be rather 922 limited, and offloaded traffic cannot access operator services. 923 Thus, the operator must be very careful in selecting which traffic to 924 offload. 926 5.5. Coexistence with deployed networks/hosts and operability across 927 different networks- REQ5 929 According to [I-D.ietf-dmm-requirements], DMM implementations must be 930 able to co-exist with existing network deployments, end hosts and 931 routers, and a DMM solution SHOULD work across different networks, 932 possibly operated as separate administrative domains, when the needed 933 mobility management signaling, forwarding, and network access are 934 allowed by the trust relationship between them. All current mobility 935 protocols can co-exist with existing network deployments and end 936 hosts. There is no gap between existing mobility protocols and this 937 requirement. 939 5.6. Operation and management considerations - REQ6 941 As stated in [I-D.ietf-dmm-requirements], (1) a DMM solution needs to 942 consider configuring a device, monitoring the current operational 943 state of a device, responding to events that impact the device, 944 possibly by modifying the configuration and storing the data in a 945 format that can be analyzed later. (2) a DMM solution MUST describe 946 in what environment and how it can be scalably deployed and managed. 947 (3) a DMM solution MUST support mechanisms to test if the DMM 948 solution is working properly. (4) a DMM solution SHOULD expose the 949 operational state of DMM to the administrators of the DMM entities. 950 (5) a DMM solution, which supports flow mobility, SHOULD support 951 means to correlate the flow routing policies and the observed 952 forwarding actions. (6) a DMM solution SHOULD support mechanisms to 953 check the liveness of forwarding path. (7) a DMM solution MUST 954 provide fault management and monitoring mechanisms to manage 955 situations where update of the mobility session or the data path 956 fails. (8) a DMM solution SHOULD be able to monitor usage of DMM 957 protocol. (9) DMM solutions SHOULD support standardized 958 configuration with NETCONF [RFC6241], using YANG [RFC6020] modules, 959 which SHOULD be created for DMM when needed for such configuration. 961 Existing mobility management protocols have not thoroughly documented 962 the above list of operation and management considerations. Each of 963 the above needs to be considered from the begining in a DMM solution. 965 Management information base (MIB) objects are currently defined in 966 [RFC4295] for MIPv6 and in [RFC6475] for PMIPv6. Standardized 967 configuration with NETCONF [RFC6241], using YANG [RFC6020] modules is 968 needed. 970 5.7. Security considerations - REQ7 972 As stated in [I-D.ietf-dmm-requirements], a DMM solution MUST support 973 any security protocols and mechanisms needed to secure the network 974 and to make continuous security improvements. In addition, with 975 security taken into consideration early in the design, a DMM solution 976 MUST NOT introduce new security risks, or amplify existing security 977 risks, that cannot be mitigated by existing security protocols and 978 mechanisms. 980 Current mobility protocols have all security mechanisms in place. 981 For example, Mobile IPv6 defines security features to protect binding 982 updates both to home agents and correspondent nodes. It also defines 983 mechanisms to protect the data packets transmission for Mobile IPv6 984 users. Proxy Mobile IPv6 and other variations of mobile IP also have 985 similar security considerations. 987 5.8. Multicast - REQ8 989 It is stated in [I-D.ietf-dmm-requirements] that DMM solutions should 990 enable multicast solutions to be developed to avoid network 991 inefficiency in multicast traffic delivery. 993 Current IP mobility solutions address mainly the mobility problem for 994 unicast traffic. Solutions relying on the use of an anchor point for 995 tunneling multicast traffic down to the access router, or to the 996 mobile node, introduce the so-called "tunnel convergence problem". 997 This means that multiple instances of the same multicast traffic can 998 converge to the same node, diminishing the advantage of using 999 multicast protocols. 1001 The MULTIMOB WG in IETF has studied this issue, for the specific case 1002 of PMIPv6, and has produced a baseline solution [RFC6224] as well as 1003 a routing optimization solution [RFC7028] to address the problem. 1004 The baseline solution suggests deploying an MLD proxy function at the 1005 MAG, and either a multicast router or another MLD proxy function at 1006 the LMA. The routing optimization solution describes an architecture 1007 where a dedicated multicast tree mobility anchor (MTMA) or a direct 1008 routing option can be used to avoid the tunnel convergence problem. 1010 Besides the solutions proposed in MULTIMOB for PMIPv6 within the 1011 IETF, there are no other solutions for other mobility protocols to 1012 address the multicast tunnel convergence problem. 1014 5.9. Summary 1016 We next list the main gaps identified from the analysis performed 1017 above: 1019 o Existing solutions only provide an optimal initial anchor 1020 assignment, a gap being the lack of dynamic anchor change/new 1021 anchor assignment. Neither the HA switch nor the LMA runtime 1022 assignment allow changing the anchor during an ongoing session. 1023 MOBIKE allows change of GW but its applicability has been scoped 1024 to very narrow use case. 1026 o The mobile node needs to simultaneously use multiple IP addresses 1027 with different properties, which requires to expose this 1028 information to the mobile node and to update accordingly the 1029 source address selection mechanism of the latter. 1031 o Currently, there is no efficient mechanism specified by the IETF 1032 that allows to dynamically discover the presence of nodes that can 1033 play the role of anchor, discover their capabilities and allow the 1034 selection of the most suitable one. However, the following 1035 mechanisms that could help discovering anchors: 1037 o Dynamic Home Agent Address Discovery (DHAAD): the use of the Home 1038 Agent (H) flag in Router Advertisements (which indicates that the 1039 router sending the Router Advertisement is also functioning as a 1040 Mobile IPv6 home agent on the link) and the MAP option in Router 1041 Advertisements defined by HMIPv6. 1043 o While existing network-based DMM practices may allow to deploy 1044 multiple LMAs and dynamically select the best one, this requires 1045 to still keep some centralization in the control plane, to access 1046 the policy database (as defined in RFC5213). Although 1047 [I-D.ietf-netext-pmip-cp-up-separation] allows a MAG to perform 1048 splitting of its control and user planes, there is a lack of 1049 solutions/extensions that support a clear control and data plane 1050 separation for IETF IP mobility protocols in a DMM context. 1052 6. Security Considerations 1054 Distributed mobility management systems encounter same security 1055 threats as existing centralized IP mobility protocols. Without 1056 authentication, a malicious node could forge signaling messages and 1057 redirect traffic from its legitimate path. This would amount to a 1058 denial of service attack against the specific node or nodes for which 1059 the traffic is intended. Distributed mobility anchoring, while 1060 keeping current security mechanisms, might require more security 1061 associations to be managed by the mobility management entities, 1062 potentially leading to scalability and performance issues. Moreover, 1063 distributed mobility anchoring makes mobility security problems more 1064 complex, since traffic redirection requests might come from 1065 previously unconsidered origins, thus leading to distributed points 1066 of attack. Consequently, the DMM security design must account for 1067 the distribution of security associations between additional mobility 1068 entities. 1070 7. IANA Considerations 1072 None. 1074 8. References 1076 8.1. Normative References 1078 [I-D.ietf-dmm-requirements] 1079 Chan, A., Liu, D., Seite, P., Yokota, H., and J. Korhonen, 1080 "Requirements for Distributed Mobility Management", draft- 1081 ietf-dmm-requirements-17 (work in progress), June 2014. 1083 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1084 Requirement Levels", BCP 14, RFC 2119, March 1997. 1086 [RFC4295] Keeni, G., Koide, K., Nagami, K., and S. Gundavelli, 1087 "Mobile IPv6 Management Information Base", RFC 4295, April 1088 2006. 1090 [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the 1091 Network Configuration Protocol (NETCONF)", RFC 6020, 1092 October 2010. 1094 [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. 1095 Bierman, "Network Configuration Protocol (NETCONF)", RFC 1096 6241, June 2011. 1098 [RFC6475] Keeni, G., Koide, K., Gundavelli, S., and R. Wakikawa, 1099 "Proxy Mobile IPv6 Management Information Base", RFC 6475, 1100 May 2012. 1102 8.2. Informative References 1104 [I-D.anipko-mif-mpvd-arch] 1105 Anipko, D., "Multiple Provisioning Domain Architecture", 1106 draft-anipko-mif-mpvd-arch-05 (work in progress), November 1107 2013. 1109 [I-D.bhandari-dhc-class-based-prefix] 1110 Systems, C., Halwasia, G., Gundavelli, S., Deng, H., 1111 Thiebaut, L., Korhonen, J., and I. Farrer, "DHCPv6 class 1112 based prefix", draft-bhandari-dhc-class-based-prefix-05 1113 (work in progress), July 2013. 1115 [I-D.gundavelli-v6ops-community-wifi-svcs] 1116 Gundavelli, S., Grayson, M., Seite, P., and Y. Lee, 1117 "Service Provider Wi-Fi Services Over Residential 1118 Architectures", draft-gundavelli-v6ops-community-wifi- 1119 svcs-06 (work in progress), April 2013. 1121 [I-D.ietf-netext-pmip-cp-up-separation] 1122 Wakikawa, R., Pazhyannur, R., Gundavelli, S., and C. 1123 Perkins, "Separation of Control and User Plane for Proxy 1124 Mobile IPv6", draft-ietf-netext-pmip-cp-up-separation-05 1125 (work in progress), July 2014. 1127 [I-D.korhonen-6man-prefix-properties] 1128 Korhonen, J., Patil, B., Gundavelli, S., Seite, P., and D. 1129 Liu, "IPv6 Prefix Properties", draft-korhonen-6man-prefix- 1130 properties-02 (work in progress), July 2013. 1132 [IEEE.802-16.2009] 1133 "IEEE Standard for Local and metropolitan area networks 1134 Part 16: Air Interface for Broadband Wireless Access 1135 Systems", IEEE Standard 802.16, 2009, 1136 . 1139 [RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. 1140 Thubert, "Network Mobility (NEMO) Basic Support Protocol", 1141 RFC 3963, January 2005. 1143 [RFC4066] Liebsch, M., Singh, A., Chaskar, H., Funato, D., and E. 1144 Shim, "Candidate Access Router Discovery (CARD)", RFC 1145 4066, July 2005. 1147 [RFC4067] Loughney, J., Nakhjiri, M., Perkins, C., and R. Koodli, 1148 "Context Transfer Protocol (CXTP)", RFC 4067, July 2005. 1150 [RFC4225] Nikander, P., Arkko, J., Aura, T., Montenegro, G., and E. 1151 Nordmark, "Mobile IP Version 6 Route Optimization Security 1152 Design Background", RFC 4225, December 2005. 1154 [RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol 1155 (MOBIKE)", RFC 4555, June 2006. 1157 [RFC4640] Patel, A. and G. Giaretta, "Problem Statement for 1158 bootstrapping Mobile IPv6 (MIPv6)", RFC 4640, September 1159 2006. 1161 [RFC4889] Ng, C., Zhao, F., Watari, M., and P. Thubert, "Network 1162 Mobility Route Optimization Solution Space Analysis", RFC 1163 4889, July 2007. 1165 [RFC5014] Nordmark, E., Chakrabarti, S., and J. Laganier, "IPv6 1166 Socket API for Source Address Selection", RFC 5014, 1167 September 2007. 1169 [RFC5026] Giaretta, G., Kempf, J., and V. Devarapalli, "Mobile IPv6 1170 Bootstrapping in Split Scenario", RFC 5026, October 2007. 1172 [RFC5142] Haley, B., Devarapalli, V., Deng, H., and J. Kempf, 1173 "Mobility Header Home Agent Switch Message", RFC 5142, 1174 January 2008. 1176 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 1177 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 1179 [RFC5380] Soliman, H., Castelluccia, C., ElMalki, K., and L. 1180 Bellier, "Hierarchical Mobile IPv6 (HMIPv6) Mobility 1181 Management", RFC 5380, October 2008. 1183 [RFC5555] Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and 1184 Routers", RFC 5555, June 2009. 1186 [RFC5568] Koodli, R., "Mobile IPv6 Fast Handovers", RFC 5568, July 1187 2009. 1189 [RFC5844] Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy 1190 Mobile IPv6", RFC 5844, May 2010. 1192 [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, 1193 "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 1194 5996, September 2010. 1196 [RFC6097] Korhonen, J. and V. Devarapalli, "Local Mobility Anchor 1197 (LMA) Discovery for Proxy Mobile IPv6", RFC 6097, February 1198 2011. 1200 [RFC6224] Schmidt, T., Waehlisch, M., and S. Krishnan, "Base 1201 Deployment for Multicast Listener Support in Proxy Mobile 1202 IPv6 (PMIPv6) Domains", RFC 6224, April 2011. 1204 [RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support 1205 in IPv6", RFC 6275, July 2011. 1207 [RFC6463] Korhonen, J., Gundavelli, S., Yokota, H., and X. Cui, 1208 "Runtime Local Mobility Anchor (LMA) Assignment Support 1209 for Proxy Mobile IPv6", RFC 6463, February 2012. 1211 [RFC6611] Chowdhury, K. and A. Yegin, "Mobile IPv6 (MIPv6) 1212 Bootstrapping for the Integrated Scenario", RFC 6611, May 1213 2012. 1215 [RFC6697] Zorn, G., Wu, Q., Taylor, T., Nir, Y., Hoeper, K., and S. 1216 Decugis, "Handover Keying (HOKEY) Architecture Design", 1217 RFC 6697, July 2012. 1219 [RFC6705] Krishnan, S., Koodli, R., Loureiro, P., Wu, Q., and A. 1220 Dutta, "Localized Routing for Proxy Mobile IPv6", RFC 1221 6705, September 2012. 1223 [RFC7028] Zuniga, JC., Contreras, LM., Bernardos, CJ., Jeon, S., and 1224 Y. Kim, "Multicast Mobility Routing Optimizations for 1225 Proxy Mobile IPv6", RFC 7028, September 2013. 1227 [SDO-3GPP.23.401] 1228 3GPP, "General Packet Radio Service (GPRS) enhancements 1229 for Evolved Universal Terrestrial Radio Access Network 1230 (E-UTRAN) access", 3GPP TS 23.401 10.10.0, March 2013. 1232 [SDO-3GPP.23.402] 1233 3GPP, "Architecture enhancements for non-3GPP accesses", 1234 3GPP TS 23.402 10.8.0, September 2012. 1236 [SDO-3GPP.24.303] 1237 3GPP, "Mobility management based on Dual-Stack Mobile 1238 IPv6; Stage 3", 3GPP TS 24.303 10.0.0, June 2013. 1240 [SDO-3GPP.29.060] 1241 3GPP, "General Packet Radio Service (GPRS); GPRS 1242 Tunnelling Protocol (GTP) across the Gn and Gp interface", 1243 3GPP TS 29.060 3.19.0, March 2004. 1245 [SDO-3GPP.29.274] 1246 3GPP, "3GPP Evolved Packet System (EPS); Evolved General 1247 Packet Radio Service (GPRS) Tunnelling Protocol for 1248 Control plane (GTPv2-C); Stage 3", 3GPP TS 29.274 10.11.0, 1249 June 2013. 1251 [SDO-3GPP.29.281] 1252 3GPP, "General Packet Radio System (GPRS) Tunnelling 1253 Protocol User Plane (GTPv1-U)", 3GPP TS 29.281 10.3.0, 1254 September 2011. 1256 [SDO-3GPP.29.303] 1257 3GPP, "Domain Name System Procedures; Stage 3", 3GPP TS 1258 29.303 10.4.0, September 2012. 1260 Authors' Addresses 1262 Dapeng Liu (editor) 1263 China Mobile 1264 Unit2, 28 Xuanwumenxi Ave, Xuanwu District 1265 Beijing 100053 1266 China 1268 Email: liudapeng@chinamobile.com 1269 Juan Carlos Zuniga (editor) 1270 InterDigital Communications, LLC 1271 1000 Sherbrooke Street West, 10th floor 1272 Montreal, Quebec H3A 3G4 1273 Canada 1275 Email: JuanCarlos.Zuniga@InterDigital.com 1276 URI: http://www.InterDigital.com/ 1278 Pierrick Seite 1279 Orange 1280 4, rue du Clos Courtel, BP 91226 1281 Cesson-Sevigne 35512 1282 France 1284 Email: pierrick.seite@orange.com 1286 H Anthony Chan 1287 Huawei Technologies 1288 5340 Legacy Dr. Building 3 1289 Plano, TX 75024 1290 USA 1292 Email: h.a.chan@ieee.org 1294 Carlos J. Bernardos 1295 Universidad Carlos III de Madrid 1296 Av. Universidad, 30 1297 Leganes, Madrid 28911 1298 Spain 1300 Phone: +34 91624 6236 1301 Email: cjbc@it.uc3m.es 1302 URI: http://www.it.uc3m.es/cjbc/