idnits 2.17.1 draft-ietf-dmm-pmipv6-dlif-05.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 (November 2, 2019) is 1631 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DMM Working Group CJ. Bernardos 3 Internet-Draft A. de la Oliva 4 Intended status: Experimental UC3M 5 Expires: May 5, 2020 F. Giust 6 Athonet 7 JC. Zuniga 8 SIGFOX 9 A. Mourad 10 InterDigital 11 November 2, 2019 13 Proxy Mobile IPv6 extensions for Distributed Mobility Management 14 draft-ietf-dmm-pmipv6-dlif-05 16 Abstract 18 Distributed Mobility Management solutions allow for setting up 19 networks so that traffic is distributed in an optimal way and does 20 not rely on centrally deployed anchors to provide IP mobility 21 support. 23 There are many different approaches to address Distributed Mobility 24 Management, as for example extending network-based mobility protocols 25 (like Proxy Mobile IPv6), or client-based mobility protocols (like 26 Mobile IPv6), among others. This document follows the former 27 approach and proposes a solution based on Proxy Mobile IPv6 in which 28 mobility sessions are anchored at the last IP hop router (called 29 mobility anchor and access router). The mobility anchor and access 30 router is an enhanced access router which is also able to operate as 31 a local mobility anchor or mobility access gateway, on a per prefix 32 basis. The document focuses on the required extensions to 33 effectively support simultaneously anchoring several flows at 34 different distributed gateways. 36 Requirements Language 38 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 39 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 40 "OPTIONAL" in this document are to be interpreted as described in BCP 41 14 [RFC2119] [RFC8174] when, and only when, they appear in all 42 capitals, as shown here. 44 Status of This Memo 46 This Internet-Draft is submitted in full conformance with the 47 provisions of BCP 78 and BCP 79. 49 Internet-Drafts are working documents of the Internet Engineering 50 Task Force (IETF). Note that other groups may also distribute 51 working documents as Internet-Drafts. The list of current Internet- 52 Drafts is at https://datatracker.ietf.org/drafts/current/. 54 Internet-Drafts are draft documents valid for a maximum of six months 55 and may be updated, replaced, or obsoleted by other documents at any 56 time. It is inappropriate to use Internet-Drafts as reference 57 material or to cite them other than as "work in progress." 59 This Internet-Draft will expire on May 5, 2020. 61 Copyright Notice 63 Copyright (c) 2019 IETF Trust and the persons identified as the 64 document authors. All rights reserved. 66 This document is subject to BCP 78 and the IETF Trust's Legal 67 Provisions Relating to IETF Documents 68 (https://trustee.ietf.org/license-info) in effect on the date of 69 publication of this document. Please review these documents 70 carefully, as they describe your rights and restrictions with respect 71 to this document. Code Components extracted from this document must 72 include Simplified BSD License text as described in Section 4.e of 73 the Trust Legal Provisions and are provided without warranty as 74 described in the Simplified BSD License. 76 Table of Contents 78 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 79 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 80 3. PMIPv6 DMM extensions . . . . . . . . . . . . . . . . . . . . 5 81 3.1. Initial registration . . . . . . . . . . . . . . . . . . 7 82 3.2. The CMD as PBU/PBA relay . . . . . . . . . . . . . . . . 8 83 3.3. The CMD as MAAR locator . . . . . . . . . . . . . . . . . 11 84 3.4. The CMD as MAAR proxy . . . . . . . . . . . . . . . . . . 12 85 3.5. De-registration . . . . . . . . . . . . . . . . . . . . . 13 86 3.6. The Distributed Logical Interface (DLIF) concept . . . . 14 87 4. Message Format . . . . . . . . . . . . . . . . . . . . . . . 18 88 4.1. Proxy Binding Update . . . . . . . . . . . . . . . . . . 18 89 4.2. Proxy Binding Acknowledgment . . . . . . . . . . . . . . 19 90 4.3. Anchored Prefix Option . . . . . . . . . . . . . . . . . 19 91 4.4. Local Prefix Option . . . . . . . . . . . . . . . . . . . 20 92 4.5. Previous MAAR Option . . . . . . . . . . . . . . . . . . 22 93 4.6. Serving MAAR Option . . . . . . . . . . . . . . . . . . . 23 94 4.7. DLIF Link-local Address Option . . . . . . . . . . . . . 23 95 4.8. DLIF Link-layer Address Option . . . . . . . . . . . . . 24 96 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 97 6. Security Considerations . . . . . . . . . . . . . . . . . . . 25 98 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 26 99 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 100 8.1. Normative References . . . . . . . . . . . . . . . . . . 26 101 8.2. Informative References . . . . . . . . . . . . . . . . . 27 102 Appendix A. Comparison with Requirement document . . . . . . . . 28 103 A.1. Distributed mobility management . . . . . . . . . . . . . 28 104 A.2. Bypassable network-layer mobility support for each 105 application session . . . . . . . . . . . . . . . . . . . 28 106 A.3. IPv6 deployment . . . . . . . . . . . . . . . . . . . . . 29 107 A.4. Existing mobility protocols . . . . . . . . . . . . . . . 29 108 A.5. Coexistence with deployed networks/hosts and operability 109 across different networks . . . . . . . . . . . . . . . . 29 110 A.6. Operation and management considerations . . . . . . . . . 30 111 A.7. Security considerations . . . . . . . . . . . . . . . . . 30 112 A.8. Multicast considerations . . . . . . . . . . . . . . . . 30 113 Appendix B. Implementation experience . . . . . . . . . . . . . 30 114 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 116 1. Introduction 118 The Distributed Mobility Management (DMM) paradigm aims at minimizing 119 the impact of currently standardized mobility management solutions 120 which are centralized (at least to a considerable extent). 122 Current IP mobility solutions, standardized with the names of Mobile 123 IPv6 [RFC6275], or Proxy Mobile IPv6 (PMIPv6) [RFC5213], just to cite 124 the two most relevant examples, offer mobility support at the cost of 125 handling operations at a cardinal point, the mobility anchor (i.e., 126 the home agent for Mobile IPv6, and the local mobility anchor for 127 Proxy Mobile IPv6), and burdening it with data forwarding and control 128 mechanisms for a great amount of users. As stated in [RFC7333], 129 centralized mobility solutions are prone to several problems and 130 limitations: longer (sub-optimal) routing paths, scalability 131 problems, signaling overhead (and most likely a longer associated 132 handover latency), more complex network deployment, higher 133 vulnerability due to the existence of a potential single point of 134 failure, and lack of granularity of the mobility management service 135 (i.e., mobility is offered on a per-node basis, not being possible to 136 define finer granularity policies, as for example per-application). 138 The purpose of Distributed Mobility Management is to overcome the 139 limitations of the traditional centralized mobility management 140 [RFC7333] [RFC7429]; the main concept behind DMM solutions is indeed 141 bringing the mobility anchor closer to the Mobile Node (MN). 142 Following this idea, in our proposal, the central anchor is moved to 143 the edge of the network, being deployed in the default gateway of the 144 mobile node. That is, the first elements that provide IP 145 connectivity to a set of MNs are also the mobility managers for those 146 MNs. In this document, we call these entities Mobility Anchors and 147 Access Routers (MAARs). 149 This document focuses on network-based DMM, hence the starting point 150 is making PMIPv6 work in a distributed manner [RFC7429]. Mobility is 151 handled by the network without the MNs involvement, but, differently 152 from PMIPv6, when the MN moves from one access network to another, it 153 may also change anchor router, hence requiring signaling between the 154 anchors to retrieve the MN's previous location(s). Also, a key- 155 aspect of network-based DMM, is that a prefix pool belongs 156 exclusively to each MAAR, in the sense that those prefixes are 157 assigned by the MAAR to the MNs attached to it, and they are routable 158 at that MAAR. 160 We consider partially distributed schemes, where the data plane only 161 is distributed among access routers similar to MAGs, whereas the 162 control plane is kept centralized towards a cardinal node used as 163 information store, but relieved from any route management and MN's 164 data forwarding task. 166 2. Terminology 168 The following terms used in this document are defined in the Proxy 169 Mobile IPv6 specification [RFC5213]: 171 Local Mobility Anchor (LMA) 173 Mobile Access Gateway (MAG) 175 Mobile Node (MN) 177 Binding Cache Entry (BCE) 179 Proxy Care-of Address (P-CoA) 181 Proxy Binding Update (PBU) 183 Proxy Binding Acknowledgement (PBA) 185 The following terms used in this document are defined in the DMM 186 Deployment Models and Architectural Considerations document 187 [I-D.ietf-dmm-deployment-models]: 189 Home Control-Plane Anchor (Home-CPA) 191 Home Data Plane Anchor (Home-DPA) 192 Access Control Plane Node (Access-CPN) 194 Access Data Plane Node (Access-DPN) 196 The following terms are defined and used in this document: 198 MAAR (Mobility Anchor and Access Router). First hop router where the 199 mobile nodes attach to. It also plays the role of mobility 200 manager for the IPv6 prefixes it anchors, running the 201 functionalities of PMIP's MAG and LMA. Depending on the prefix, 202 it plays the role of Access-DPN, Home-DPA and Access-CPN. 204 CMD (Central Mobility Database). The node that stores the BCEs 205 allocated for the MNs in the mobility domain. It plays the role 206 of Home-CPA. 208 P-MAAR (Previous MAAR). When a MN moves to a new point of attachment 209 a new MAAR might be allocated as its anchor point for future IPv6 210 prefixes. The MAAR that served the MN prior to new attachment 211 becomes the P-MAAR. It is still the anchor point for the IPv6 212 prefixes it had allocated to the MN in the past and serves as the 213 Home-DPA for flows using these prefixes. There might be several 214 P-MAARs serving a MN when the MN is frequently switching points of 215 attachment while maintaining long-lasting flows. 217 S-MAAR (Serving MAAR). The MAAR which the MN is currently attached 218 to. Depending on the prefix, it plays the role of Access-DPN, 219 Home-DPA and Access-CPN. 221 DLIF (Distributed Logical Interface). It is a logical interface at 222 the IP stack of the MAAR. For each active prefix used by the MN, 223 the S-MAAR has a DLIF configured (associated to each MAAR still 224 anchoring flows). In this way, an S-MAAR exposes itself towards 225 each MN as multiple routers, one as itself and one per P-MAAR. 227 3. PMIPv6 DMM extensions 229 The solution consists of de-coupling the entities that participate in 230 the data and the control planes: the data plane becomes distributed 231 and managed by the MAARs near the edge of the network, while the 232 control plane, besides those on the MAARs, relies on a central entity 233 called Central Mobility Database (CMD). In the proposed 234 architecture, the hierarchy present in PMIPv6 between LMA and MAG is 235 preserved, but with the following substantial variations: 237 o The LMA is relieved from the data forwarding role, only the 238 Binding Cache and its management operations are maintained. Hence 239 the LMA is renamed into Central Mobility Database (CMD), which is 240 therefore a Home-CPA. Also, the CMD is able to send and parse 241 both PBU and PBA messages. 243 o The MAG is enriched with the LMA functionalities, hence the name 244 Mobility Anchor and Access Router (MAAR). It maintains a local 245 Binding Cache for the MNs that are attached to it and it is able 246 to send and parse PBU and PBA messages. 248 o The binding cache will be extended to include information 249 regarding P-MAARs where the mobile node was anchored and still 250 retains active data sessions, see Appendix B for further details. 252 o Each MAAR has a unique set of global prefixes (which are 253 configurable), that can be allocated by the MAAR to the MNs, but 254 must be exclusive to that MAAR, i.e. no other MAAR can allocate 255 the same prefixes. 257 The MAARs leverage the Central Mobility Database (CMD) to access and 258 update information related to the MNs, stored as mobility sessions; 259 hence, a centralized node maintains a global view of the network 260 status. The CMD is queried whenever a MN is detected to join/leave 261 the mobility domain. It might be a fresh attachment, a detachment or 262 a handover, but as MAARs are not aware of past information related to 263 a mobility session, they contact the CMD to retrieve the data of 264 interest and eventually take the appropriate action. The procedure 265 adopted for the query and the messages exchange sequence might vary 266 to optimize the update latency and/or the signaling overhead. Here 267 is presented one method for the initial registration, and three 268 different approaches for updating the mobility sessions using PBUs 269 and PBAs. Each approach assigns a different role to the CMD: 271 o The CMD is a PBU/PBA relay; 273 o The CMD is only a MAAR locator; 275 o The CMD is a PBU/PBA proxy. 277 This solution can be categorized under Model-1: Split Home Anchor 278 Mode in [I-D.ietf-dmm-deployment-models]. As another note, the 279 solution described in this document allows performing per-prefix 280 anchoring decisions, to support e.g., some flows to be anchored at a 281 central Home-DPA (like a traditional LMA) or to enable an application 282 to switch to the locally anchored prefix to gain route optimization, 283 as indicated in [RFC8563]. This type of per-prefix treatment would 284 potentially require additional extensions to the MAARs and signaling 285 between the MAARs and the MNs to convey the per-flow anchor 286 preference (central, distributed), which are not covered in this 287 document. 289 Note that a MN MAY move across different MAARs, which might result in 290 several P-MAARs existing at a given moment of time, each of them 291 anchoring a different prefix used by the MN. 293 3.1. Initial registration 295 Initial registration is performed when an MN attaches to a network 296 for the first time (rather than attaching to a new network after 297 moving from a previous one). 299 In this description (shown in Figure 1), it is assumed that: 301 1. The MN is attaching to MAAR1. 303 2. The MN is authorized to attach to the network. 305 Upon MN attachment, the following operations take place: 307 1. MAAR1 assigns an IPv6 global prefix from its own prefix pool to 308 the MN (Pref1). It also stores this prefix (Pref1) in the 309 locally allocated temporary Binding Cache Entry (BCE). 311 2. MAAR1 sends a PBU [RFC5213] with Pref1 and the MN's MN-ID to the 312 CMD. 314 3. Since this is an initial registration, the CMD stores a permanent 315 BCE containing as primary fields the MN-ID, Pref1 and MAAR1's 316 address as a Proxy-CoA. 318 4. The CMD replies with a PBA with the usual options defined in 319 PMIPv6 [RFC5213], meaning that the MN's registration is fresh and 320 no past status is available. 322 5. MAAR1 stores the BCE described in (1) and unicasts a Router 323 Advertisement (RA) to the MN with Pref1. 325 6. The MN uses Pref1 to configure an IPv6 address (IP1) (e.g., with 326 stateless auto-configuration, SLAAC). 328 Note that: 330 1. Alternative IPv6 auto-configuration mechanisms can also be used, 331 though this document describes the SLAAC-based one. 333 2. IP1 is routable at MAAR1, in the sense that it is on the path of 334 packets addressed to the MN. 336 3. MAAR1 acts as a plain router for packets destined to the MN, as 337 no encapsulation nor special handling takes place. 339 In the diagram shown in Figure 1 (and subsequent diagrams), the flow 340 of packets is presented using '*'. 342 +-----+ +---+ +--+ 343 |MAAR1| |CMD| |CN| 344 +-----+ +---+ +*-+ 345 | | * 346 MN | * +---+ 347 attach. | ***** _|CMD|_ 348 detection | flow1 * / +-+-+ \ 349 | | * / | \ 350 local BCE | * / | \ 351 allocation | * / | \ 352 |--- PBU -->| +---*-+-' +--+--+ `+-----+ 353 | BCE | * | | | | | 354 | creation |MAAR1+------+MAAR2+-----+MAAR3| 355 |<-- PBA ---| | * | | | | | 356 local BCE | +---*-+ +-----+ +-----+ 357 finalized | * 358 | | Pref1 * 359 | | +*-+ 360 | | |MN| 361 | | +--+ 363 Operations sequence Packets flow 365 Figure 1: First attachment to the network 367 Note that the registration process does not change regardless of the 368 CMD's modes (relay, locator or proxy) described next. The procedure 369 is depicted in Figure 1. 371 3.2. The CMD as PBU/PBA relay 373 Upon MN mobility, if the CMD behaves as PBU/PBA relay, the following 374 operations take place: 376 1. When the MN moves from its current point of attachment and 377 attaches to MAAR2 (now the S-MAAR), MAAR2 reserves another IPv6 378 prefix (Pref2), it stores a temporary BCE, and it sends a plain 379 PBU to the CMD for registration. 381 2. Upon PBU reception and BC lookup, the CMD retrieves an already 382 existing entry for the MN, binding the MN-ID to its former 383 location; thus, the CMD forwards the PBU to the MAAR indicated as 384 Proxy CoA (MAAR1), including a new mobility option to communicate 385 the S-MAAR's global address to MAAR1, defined as Serving MAAR 386 Option in Section 4.6. The CMD updates the P-CoA field in the 387 BCE related to the MN with the S-MAAR's address. 389 3. Upon PBU reception, MAAR1 can install a tunnel on its side 390 towards MAAR2 and the related routes for Pref1. Then MAAR1 391 replies to the CMD with a PBA (including the option mentioned 392 before) to ensure that the new location has successfully changed, 393 containing the prefix anchored at MAAR1 in the Home Network 394 Prefix option. 396 4. The CMD, after receiving the PBA, updates the BCE populating an 397 instance of the P-MAAR list. The P-MAAR list is an additional 398 field on the BCE that contains an element for each P-MAAR 399 involved in the MN's mobility session. The list element contains 400 the P-MAAR's global address and the prefix it has delegated (see 401 Appendix B for further details). Also, the CMD sends a PBA to 402 the new S-MAAR, containing the previous Proxy-CoA and the prefix 403 anchored to it embedded into a new mobility option called 404 Previous MAAR Option (defined in Section 4.5), so that, upon PBA 405 arrival, a bi-directional tunnel can be established between the 406 two MAARs and new routes are set appropriately to recover the IP 407 flow(s) carrying Pref1. 409 5. Now packets destined to Pref1 are first received by MAAR1, 410 encapsulated into the tunnel and forwarded to MAAR2, which 411 finally delivers them to their destination. In uplink, when the 412 MN transmits packets using Pref1 as source address, they are sent 413 to MAAR2, as it is MN's new default gateway, then tunneled to 414 MAAR1 which routes them towards the next hop to destination. 415 Conversely, packets carrying Pref2 are routed by MAAR2 without 416 any special packet handling both for uplink and downlink. 418 +-----+ +---+ +-----+ +--+ +--+ 419 |MAAR1| |CMD| |MAAR2| |CN| |CN| 420 +-----+ +---+ +-----+ +*-+ +*-+ 421 | | | * * 422 | | MN * +---+ * 423 | | attach. ***** _|CMD|_ * 424 | | det. flow1 * / +-+-+ \ *flow2 425 | |<-- PBU ---| * / | \ * 426 | BCE | * / | ******* 427 | check+ | * / | * \ 428 | update | +---*-+-' +--+-*+ `+-----+ 429 |<-- PBU*---| | | * | | *| | | 430 route | | |MAAR1|______|MAAR2+-----+MAAR3| 431 update | | | **(______)** *| | | 432 |--- PBA*-->| | +-----+ +-*--*+ +-----+ 433 | BCE | * * 434 | update | Pref1 * *Pref2 435 | |--- PBA*-->| +*--*+ 436 | | route ---move-->|*MN*| 437 | | update +----+ 439 Operations sequence Data Packets flow 440 PBU/PBA Messages with * contain 441 a new mobility option 443 Figure 2: Scenario after a handover, CMD as relay 445 For MN's next movements the process is repeated except the number of 446 P-MAARs involved increases (accordingly to the number of prefixes 447 that the MN wishes to maintain). Indeed, once the CMD receives the 448 first PBU from the new S-MAAR, it forwards copies of the PBU to all 449 the P-MAARs indicated in the BCE as current P-CoA (i.e., the MAAR 450 prior to handover) and in the P-MAARs list. They reply with a PBA to 451 the CMD, which aggregates them into a single one to notify the 452 S-MAAR, that finally can establish the tunnels with the P-MAARs. 454 It should be noted that this design separates the mobility management 455 at the prefix granularity, and it can be tuned in order to erase old 456 mobility sessions when not required, while the MN is reachable 457 through the latest prefix acquired. Moreover, the latency associated 458 to the mobility update is bound to the PBA sent by the furthest 459 P-MAAR, in terms of RTT, that takes the longest time to reach the 460 CMD. The drawback can be mitigated introducing a timeout at the CMD, 461 by which, after its expiration, all the PBAs so far collected are 462 transmitted, and the remaining are sent later upon their arrival. 463 Note that in this case the S-MAAR might receive multiple PBAs from 464 the CMD in response to a PBU. When aggregating and relaying PBAs, 465 the CMD SHOULD make use of the timeout also to deal with missing PBAs 466 (to retransmit PBUs). The INITIAL_BINDACK_TIMEOUT [RFC6275] SHOULD 467 be used for configuring the retransmission timer. 469 When there are multiple previous MAARs, e.g., k MAARs, a single PBU 470 received by the CMD triggers k outgoing packets from a single 471 incoming packet. This may lead to packet bursts originated from the 472 CMD, albeit to different targets. Pacing mechanisms MAY be 473 introduced to avoid bursts on the outgoing link. 475 3.3. The CMD as MAAR locator 477 The handover latency experienced in the approach shown before can be 478 reduced if the P-MAARs are allowed to signal directly their 479 information to the new S-MAAR. This procedure reflects what was 480 described in Section 3.2 up to the moment the P-MAAR receives the PBU 481 with the P-MAAR option. At that point a P-MAAR is aware of the new 482 MN's location (because of the S-MAAR's address in the S-MAAR option), 483 and, besides sending a PBA to the CMD, it also sends a PBA to the 484 S-MAAR including the prefix it is anchoring. This latter PBA does 485 not need to include new options, as the prefix is embedded in the HNP 486 option and the P-MAAR's address is taken from the message's source 487 address. The CMD is relieved from forwarding the PBA to the S-MAAR, 488 as the latter receives a copy directly from the P-MAAR with the 489 necessary information to build the tunnels and set the appropriate 490 routes. Figure 3 illustrates the new message sequence, while the 491 data forwarding is unaltered. 493 +-----+ +---+ +-----+ +--+ +--+ 494 |MAAR1| |CMD| |MAAR2| |CN| |CN| 495 +-----+ +---+ +-----+ +*-+ +*-+ 496 | | | * * 497 | | MN * +---+ * 498 | | attach. ***** _|CMD|_ * 499 | | det. flow1 * / +-+-+ \ *flow2 500 | |<-- PBU ---| * / | \ * 501 | BCE | * / | ******* 502 | check+ | * / | * \ 503 | update | +---*-+-' +--+-*+ `+-----+ 504 |<-- PBU*---| | | * | | *| | | 505 route | | |MAAR1|______|MAAR2+-----+MAAR3| 506 update | | | **(______)** *| | | 507 |--------- PBA -------->| +-----+ +-*--*+ +-----+ 508 |--- PBA*-->| route * * 509 | BCE update Pref1 * *Pref2 510 | update | +*--*+ 511 | | | ---move-->|*MN*| 512 | | | +----+ 514 Operations sequence Data Packets flow 515 PBU/PBA Messages with * contain 516 a new mobility option 518 Figure 3: Scenario after a handover, CMD as locator 520 3.4. The CMD as MAAR proxy 522 A further enhancement of previous solutions can be achieved when the 523 CMD sends the PBA to the new S-MAAR before notifying the P-MAARs of 524 the location change. Indeed, when the CMD receives the PBU for the 525 new registration, it is already in possession of all the information 526 that the new S-MAAR requires to set up the tunnels and the routes. 527 Thus the PBA is sent to the S-MAAR immediately after a PBU is 528 received, including also in this case the P-MAAR option. In 529 parallel, a PBU is sent by the CMD to the P-MAARs containing the 530 S-MAAR option, to notify them about the new MN's location, so they 531 receive the information to establish the tunnels and routes on their 532 side. When P-MAARs complete the update, they send a PBA to the CMD 533 to indicate that the operation is concluded and the information is 534 updated in all network nodes. This procedure is obtained from the 535 first one re-arranging the order of the messages, but the parameters 536 communicated are the same. This scheme is depicted in Figure 4, 537 where, again, the data forwarding is kept untouched. 539 +-----+ +---+ +-----+ +--+ +--+ 540 |MAAR1| |CMD| |MAAR2| |CN| |CN| 541 +-----+ +---+ +-----+ +*-+ +*-+ 542 | | | * * 543 | | MN * +---+ * 544 | | attach. ***** _|CMD|_ * 545 | | det. flow1 * / +-+-+ \ *flow2 546 | |<-- PBU ---| * / | \ * 547 | BCE | * / | ******* 548 | check+ | * / | * \ 549 | update | +---*-+-' +--+-*+ `+-----+ 550 |<-- PBU*---x--- PBA*-->| | * | | *| | | 551 route | route |MAAR1|______|MAAR2+-----+MAAR3| 552 update | update | **(______)** *| | | 553 |--- PBA*-->| | +-----+ +-*--*+ +-----+ 554 | BCE | * * 555 | update | Pref1 * *Pref2 556 | | | +*--*+ 557 | | | ---move-->|*MN*| 558 | | | +----+ 560 Operations sequence Data Packets flow 561 PBU/PBA Messages with * contain 562 a new mobility option 564 Figure 4: Scenario after a handover, CMD as proxy 566 3.5. De-registration 568 The de-registration mechanism devised for PMIPv6 cannot be used as is 569 in this solution. The reason for this is that each MAAR handles an 570 independent mobility session (i.e., a single or a set of prefixes) 571 for a given MN, whereas the aggregated session is stored at the CMD. 572 Indeed, when a previous MAAR initiates a de-registration procedure, 573 because the MN is no longer present on the MAAR's access link, it 574 removes the routing state for that (those) prefix(es), that would be 575 deleted by the CMD as well, hence defeating any prefix continuity 576 attempt. The simplest approach to overcome this limitation is to 577 deny a P-MAAR to de-register a prefix, that is, allowing only a 578 serving MAAR to de-register the whole MN session. This can be 579 achieved by first removing any layer-2 detachment event, so that de- 580 registration is triggered only when the session lifetime expires, 581 hence providing a guard interval for the MN to connect to a new MAAR. 582 Then, a change in the MAAR operations is required, and at this stage 583 two possible solutions can be deployed: 585 o A previous MAAR stops the BCE timer upon receiving a PBU from the 586 CMD containing a "Serving MAAR" option. In this way only the 587 Serving MAAR is allowed to de-register the mobility session, 588 arguing that the MN definitely left the domain. 590 o Previous MAARs can, upon BCE expiry, send de-registration messages 591 to the CMD, which, instead of acknowledging the message with a 0 592 lifetime, sends back a PBA with a non-zero lifetime, hence re- 593 newing the session, if the MN is still connected to the domain. 595 3.6. The Distributed Logical Interface (DLIF) concept 597 One of the main challenges of a network-based DMM solution is how to 598 allow a mobile node to simultaneously send/receive traffic which is 599 anchored at different MAARs, and how to influence the mobile node's 600 selection process of its source IPv6 address for a new flow, without 601 requiring special support from the mobile node's IP stack. This 602 document defines the Distributed Logical Interface (DLIF), which is a 603 software construct that allows to easily hide the change of 604 associated anchors from the mobile node. 606 +---------------------------------------------------+ 607 ( Operator's ) 608 ( core ) 609 +---------------------------------------------------+ 610 | | 611 +---------------+ tunnel +---------------+ 612 | IP stack |===============| IP stack | 613 +---------------+ +-------+-------+ 614 | mn1mar1 |--+ (DLIFs) +--|mn1mar1|mn1mar2|--+ 615 +---------------+ | | +-------+-------+ | 616 | phy interface | | | | phy interface | | 617 +---------------+ | | +---------------+ | 618 MAAR1 (o) (o) MAAR2 (o) 619 x x 620 x x 621 prefA::/64 x x prefB::/64 622 (AdvPrefLft=0) x x 623 (o) 624 | 625 +-----+ 626 prefA::MN1 | MN1 | prefB::MN1 627 (deprecated) +-----+ 629 Figure 5: DLIF: exposing multiple routers (one per P-MAAR) 631 The basic idea of the DLIF concept is the following: each serving 632 MAAR exposes itself towards a given MN as multiple routers, one per 633 P-MAAR associated to the MN. Let's consider the example shown in 634 Figure 5, MN1 initially attaches to MAAR1, configuring an IPv6 635 address (prefA::MN1) from a prefix locally anchored at MAAR1 636 (prefA::/64). At this stage, MAAR1 plays both the role of anchoring 637 and serving MAAR, and also behaves as a plain IPv6 access router. 638 MAAR1 creates a distributed logical interface to communicate (point- 639 to-point link) with MN1, exposing itself as a (logical) router with a 640 specific MAC (e.g., 00:11:22:33:01:01) and IPv6 addresses (e.g., 641 prefA::MAAR1/64 and fe80:211:22ff:fe33:101/64) using the DLIF 642 mn1mar1. As explained below, these addresses represent the "logical" 643 identity of MAAR1 towards MN1, and will "follow" the mobile node 644 while roaming within the domain (note that the place where all this 645 information is maintained and updated is out-of-scope of this draft; 646 potential examples are to keep it on the home subscriber server -- 647 HSS -- or the user's profile). 649 If MN1 moves and attaches to a different MAAR of the domain (MAAR2 in 650 the example of Figure 5), this MAAR will create a new logical 651 interface (mn1mar2) to expose itself towards MN1, providing it with a 652 locally anchored prefix (prefB::/64). In this case, since the MN1 653 has another active IPv6 address anchored at a MAAR1, MAAR2 also needs 654 to create an additional logical interface configured to exactly 655 resemble the one used by MAAR1 to communicate with MN1. In this 656 example, there is only one P-MAAR (in addition to MAAR2, which is the 657 serving one): MAAR1, so only the logical interface mn1mar1 is 658 created, but the same process would be repeated in case there were 659 more P-MAARs involved. In order to maintain the prefix anchored at 660 MAAR1 reachable, a tunnel between MAAR1 and MAAR2 is established and 661 the routing is modified accordingly. The PBU/PBA signaling is used 662 to set-up the bi-directional tunnel between MAAR1 and MAAR2, and it 663 might also be used to convey to MAAR2 the information about the 664 prefix(es) anchored at MAAR1 and about the addresses of the 665 associated DLIF (i.e., mn1mar1). 667 +------------------------------------------+ +----------------------+ 668 | MAAR1 | | MAAR2 | 669 |+----------------------------------------+| |+--------------------+| 670 ||+------------------++------------------+|| ||+------------------+|| 671 |||+-------++-------+||+-------++-------+||| |||+-------++-------+||| 672 ||||mn3mar1||mn3mar2||||mn2mar1||mn2mar2|||| ||||mn1mar1||mn1mar2|||| 673 |||| LMAC1 || LMAC2 |||| LMAC3 || LMAC4 |||| |||| LMAC5 || LMAC6 |||| 674 |||+-------++-------+||+-------++-------+||| |||+-------++-------+||| 675 ||| LIFs of MN3 || LIFs of MN2 ||| ||| LIFs of MN1 ||| 676 ||+------------------++------------------+|| ||+------------------+|| 677 || HMAC1 (phy if MAAR1) || ||HMAC2 (phy if MAAR2)|| 678 |+----------------------------------------+| |+--------------------+| 679 +------------------------------------------+ +----------------------+ 680 x x x 681 x x x 682 (o) (o) (o) 683 | | | 684 +--+--+ +--+--+ +--+--+ 685 | MN3 | | MN2 | | MN1 | 686 +-----+ +-----+ +-----+ 688 Figure 6: Distributed Logical Interface concept 690 Figure 6 shows the logical interface concept in more detail. The 691 figure shows two MAARs and three MNs. MAAR1 is currently serving MN2 692 and MN3, while MAAR2 is serving MN1. MN1, MN2 and MN3 have two 693 P-MAARs: MAAR1 and MAAR2. Note that a serving MAAR always plays the 694 role of anchoring MAAR for the attached (served) MNs. Each MAAR has 695 one single physical wireless interface. 697 As introduced before, each MN always "sees" multiple logical routers 698 -- one per P-MAAR -- independently of its currently serving MAAR. 699 From the point of view of the MN, these MAARs are portrayed as 700 different routers, although the MN is physically attached to one 701 single interface. The way this is achieved is by the serving MAAR 702 configuring different logical interfaces. Focusing on MN1, it is 703 currently attached to MAAR2 (i.e., MAAR2 is its serving MAAR) and, 704 therefore, it has configured an IPv6 address from MAAR2's pool (e.g., 705 prefB::/64). MAAR2 has set-up a logical interface (mn1mar2) on top 706 of its wireless physical interface (phy if MAAR2) which is used to 707 serve MN1. This interface has a logical MAC address (LMAC6), 708 different from the hardware MAC address (HMAC2) of the physical 709 interface of MAAR2. Over the mn1mar2 interface, MAAR2 advertises its 710 locally anchored prefix prefB::/64. Before attaching to MAAR2, MN1 711 was attached to MAAR1, configuring also an address locally anchored 712 at that MAAR, which is still being used by MN1 in active 713 communications. MN1 keeps "seeing" an interface connecting to MAAR1, 714 as if it were directly connected to the two MAARs. This is achieved 715 by the serving MAAR (MAAR2) configuring an additional distributed 716 logical interface: mn1mar1, which behaves exactly as the logical 717 interface configured by MAAR1 when MN1 was attached to it. This 718 means that both the MAC and IPv6 addresses configured on this logical 719 interface remain the same regardless of the physical MAAR which is 720 serving the MN. The information required by a serving MAAR to 721 properly configure this logical interfaces can be obtained in 722 different ways: as part of the information conveyed in the PBA, from 723 an external database (e.g., the HSS) or by other means. As shown in 724 the figure, each MAAR may have several logical interfaces associated 725 to each attached MN, having always at least one (since a serving MAAR 726 is also an anchoring MAAR for the attached MN). 728 In order to enforce the use of the prefix locally anchored at the 729 serving MAAR, the router advertisements sent over those logical 730 interfaces playing the role of anchoring MAARs (different from the 731 serving one) include a zero preferred prefix lifetime (and a non-zero 732 valid prefix lifetime, so the prefix remains valid, while being 733 deprecated). The goal is to deprecate the prefixes delegated by 734 these MAARs (which will be no longer serving the MN). Note that on- 735 going communications may keep on using those addresses, even if they 736 are deprecated, so this only affects the establishment of new 737 sessions. 739 The distributed logical interface concept also enables the following 740 use case: suppose that access to a local IP network is provided by a 741 given MAAR (e.g., MAAR1 in the example shown in Figure 5) and that 742 the resources available at that network cannot be reached from 743 outside the local network (e.g., cannot be accessed by an MN attached 744 to MAAR2). This is similar to the local IP access scenario 745 considered by 3GPP, where a local gateway node is selected for 746 sessions requiring access to services provided locally (instead of 747 going through a central gateway). The goal is to allow an MN to be 748 able to roam while still being able to have connectivity to this 749 local IP network. The solution adopted to support this case makes 750 use of RFC 4191 [RFC4191] more specific routes when the MN moves to a 751 MAAR different from the one providing access to the local IP network 752 (MAAR1 in the example). These routes are advertised through the 753 distributed logical interface representing the MAAR providing access 754 to the local network (MAAR1 in this example). In this way, if MN1 755 moves from MAAR1 to MAAR2, any active session that MN1 may have with 756 a node on the local network connected to MAAR1 will survive via the 757 tunnel between MAAR1 and MAAR2. Also, any potential future 758 connection attempt towards the local network will be supported, even 759 though MN1 is no longer attached to MAAR1. 761 4. Message Format 763 This section defines extensions to the Proxy Mobile IPv6 [RFC5213] 764 protocol messages. 766 4.1. Proxy Binding Update 768 A new flag (D) is included in the Proxy Binding Update to indicate 769 that the Proxy Binding Update is coming from a Mobility Anchor and 770 Access Router and not from a mobile access gateway. The rest of the 771 Proxy Binding Update format remains the same as defined in [RFC5213]. 773 0 1 2 3 774 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 775 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 776 | Sequence # | 777 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 778 |A|H|L|K|M|R|P|F|T|B|S|D| Reser | Lifetime | 779 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 780 | | 781 . . 782 . Mobility options . 783 . . 785 | | 786 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 788 MAAR Flag (D) 790 The D Flag is set to indicate to the receiver of the message that 791 the Proxy Binding Update is from a MAAR. When an LMA that does 792 not support the extensions described in this document receives a 793 message with the D-Flag set, the PBU in that case MUST NOT be 794 processed by the LMA and an error MUST be returned. 796 Mobility Options 798 Variable-length field of such length that the complete Mobility 799 Header is an integer multiple of 8 octets long. This field 800 contains zero or more TLV-encoded mobility options. The encoding 801 and format of defined options are described in Section 6.2 of 802 [RFC6275]. The MAAR MUST ignore and skip any options that it does 803 not understand. 805 4.2. Proxy Binding Acknowledgment 807 A new flag (D) is included in the Proxy Binding Acknowledgment to 808 indicate that the sender supports operating as a Mobility Anchor and 809 Access Router. The rest of the Proxy Binding Acknowledgment format 810 remains the same as defined in [RFC5213]. 812 0 1 2 3 813 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 814 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 815 | Status |K|R|P|T|B|S|D| | 816 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 817 | Sequence # | Lifetime | 818 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 819 | | 820 . . 821 . Mobility options . 822 . . 823 | | 824 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 826 MAAR (D) 828 The D is set to indicate that the sender of the message supports 829 operating as a Mobility Anchor and Access Router. When a MAG that 830 does not support the extensions described in this document 831 receives a message with the D-Flag set, it MUST ignore the message 832 and an error MUST be returned. 834 Mobility Options 836 Variable-length field of such length that the complete Mobility 837 Header is an integer multiple of 8 octets long. This field 838 contains zero or more TLV-encoded mobility options. The encoding 839 and format of defined options are described in Section 6.2 of 840 [RFC6275]. The MAAR MUST ignore and skip any options that it does 841 not understand. 843 4.3. Anchored Prefix Option 845 A new Anchored Prefix option is defined for use with the Proxy 846 Binding Update and Proxy Binding Acknowledgment messages exchanged 847 between MAARs and CMDs. Therefore, this option can only appear if 848 the D bit is set in a PBU/PBA. This option is used for exchanging 849 the mobile node's prefix anchored at the anchoring MAAR. There can 850 be multiple Anchored Prefix options present in the message. 852 The Anchored Prefix Option has an alignment requirement of 8n+4. Its 853 format is as follows: 855 0 1 2 3 856 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 857 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 858 | Type | Length | Reserved | Prefix Length | 859 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 860 | | 861 + + 862 | | 863 + Anchored Prefix + 864 | | 865 + + 866 | | 867 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 869 Type 871 IANA-1. 873 Length 875 8-bit unsigned integer indicating the length of the option in 876 octets, excluding the type and length fields. This field MUST be 877 set to 18. 879 Reserved 881 This field is unused for now. The value MUST be initialized to 0 882 by the sender and MUST be ignored by the receiver. 884 Prefix Length 886 8-bit unsigned integer indicating the prefix length of the IPv6 887 prefix contained in the option. 889 Anchored Prefix 891 A sixteen-byte field containing the mobile node's IPv6 Anchored 892 Prefix. Only the first Prefix Length bytes are valid for the 893 Anchored Prefix. The rest of the bytes MUST be ignored. 895 4.4. Local Prefix Option 897 A new Local Prefix option is defined for use with the Proxy Binding 898 Update and Proxy Binding Acknowledgment messages exchanged between 899 MAARs. Therefore, this option can only appear if the D bit is set in 900 a PBU/PBA. This option is used for exchanging a prefix of a local 901 network that is only reachable via the anchoring MAAR. There can be 902 multiple Local Prefix options present in the message. 904 The Local Prefix Option has an alignment requirement of 8n+4. Its 905 format is as follows: 907 0 1 2 3 908 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 909 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 910 | Type | Length | Reserved | Prefix Length | 911 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 912 | | 913 + + 914 | | 915 + Local Prefix + 916 | | 917 + + 918 | | 919 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 921 Type 923 IANA-2. 925 Length 927 8-bit unsigned integer indicating the length of the option in 928 octets, excluding the type and length fields. This field MUST be 929 set to 18. 931 Reserved 933 This field is unused for now. The value MUST be initialized to 0 934 by the sender and MUST be ignored by the receiver. 936 Prefix Length 938 8-bit unsigned integer indicating the prefix length of the IPv6 939 prefix contained in the option. 941 Local Prefix 943 A sixteen-byte field containing the IPv6 Local Prefix. Only the 944 first Prefix Length bytes are valid for the IPv6 Local Prefix. 945 The rest of the bytes MUST be ignored. 947 4.5. Previous MAAR Option 949 This new option is defined for use with the Proxy Binding 950 Acknowledgement messages exchanged by the CMD to a MAAR. This option 951 is used to notify the S-MAAR about the previous MAAR's global address 952 and the prefix anchored to it. There can be multiple Previous MAAR 953 options present in the message. Its format is as follows: 955 0 1 2 3 956 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 957 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 958 | Type | Length | Prefix Length | 959 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 960 | | 961 + + 962 | | 963 + P-MAAR's address + 964 | | 965 + + 966 | | 967 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 968 | | 969 + + 970 | | 971 + Home Network Prefix + 972 | | 973 + + 974 | | 975 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 977 Type 979 IANA-3. 981 Length 983 8-bit unsigned integer indicating the length of the option in 984 octets, excluding the type and length fields. This field MUST be 985 set to 33. 987 Prefix Length 989 8-bit unsigned integer indicating the prefix length of the IPv6 990 prefix contained in the option. 992 Previous MAAR's address 994 A sixteen-byte field containing the P-MAAR's IPv6 global address. 996 Home Network Prefix 998 A sixteen-byte field containing the mobile node's IPv6 Home 999 Network Prefix. Only the first Prefix Length bytes are valid for 1000 the mobile node's IPv6 Home Network Prefix. The rest of the bytes 1001 MUST be ignored. 1003 4.6. Serving MAAR Option 1005 This new option is defined for use with the Proxy Binding Update and 1006 Proxy Binding Acknowledgement messages exchanged between the CMD and 1007 a Previous MAAR. This option is used to notify the P-MAAR about the 1008 current Serving MAAR's global address. Its format is as follows: 1010 0 1 2 3 1011 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1012 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1013 | Type | Length | 1014 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1015 | | 1016 + + 1017 | | 1018 + S-MAAR's address + 1019 | | 1020 + + 1021 | | 1022 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1024 Type 1026 IANA-4. 1028 Length 1030 8-bit unsigned integer indicating the length of the option in 1031 octets, excluding the type and length fields. This field MUST be 1032 set to 16. 1034 Serving MAAR's address 1036 A sixteen-byte field containing the S-MAAR's IPv6 global address. 1038 4.7. DLIF Link-local Address Option 1040 A new DLIF Link-local Address option is defined for use with the 1041 Proxy Binding Update and Proxy Binding Acknowledgment messages 1042 exchanged between MAARs. This option is used for exchanging the 1043 link-local address of the DLIF to be configured on the serving MAAR 1044 so it resembles the DLIF configured on the P-MAAR. 1046 The DLIF Link-local Address option has an alignment requirement of 1047 8n+6. Its format is as follows: 1049 0 1 2 3 1050 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1051 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1052 | Type | Length | 1053 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1054 | | 1055 + + 1056 | | 1057 + DLIF Link-local Address + 1058 | | 1059 + + 1060 | | 1061 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1063 Type 1065 IANA-5. 1067 Length 1069 8-bit unsigned integer indicating the length of the option in 1070 octets, excluding the type and length fields. This field MUST be 1071 set to 16. 1073 DLIF Link-local Address 1075 A sixteen-byte field containing the link-local address of the 1076 logical interface. 1078 4.8. DLIF Link-layer Address Option 1080 A new DLIF Link-layer Address option is defined for use with the 1081 Proxy Binding Update and Proxy Binding Acknowledgment messages 1082 exchanged between MAARs. This option is used for exchanging the 1083 link-layer address of the DLIF to be configured on the serving MAAR 1084 so it resembles the DLIF configured on the P-MAAR. 1086 The format of the DLIF Link-layer Address option is shown below. 1087 Based on the size of the address, the option MUST be aligned 1088 appropriately, as per mobility option alignment requirements 1089 specified in [RFC6275]. 1091 0 1 2 3 1092 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1093 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1094 | Type | Length | Reserved | 1095 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1096 | | 1097 + DLIF Link-layer Address + 1098 . ... . 1099 | | 1100 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1102 Type 1104 IANA-6. 1106 Length 1108 8-bit unsigned integer indicating the length of the option in 1109 octets, excluding the type and length fields. 1111 Reserved 1113 This field is unused for now. The value MUST be initialized to 0 1114 by the sender and MUST be ignored by the receiver. 1116 DLIF Link-layer Address 1118 A variable length field containing the link-layer address of the 1119 logical interface to be configured on the S-MAAR. 1121 The content and format of this field (including byte and bit 1122 ordering) is as specified in Section 4.6 of [RFC4861] for carrying 1123 link-layer addresses. On certain access links, where the link- 1124 layer address is not used or cannot be determined, this option 1125 cannot be used. 1127 5. IANA Considerations 1129 This document defines six new mobility options that need to be 1130 registered in the Mobility Options registry on the Mobile IPv6 1131 parameters registry. The required IANA actions are marked as IANA-1 1132 to IANA-6. 1134 6. Security Considerations 1136 The protocol extensions defined in this document share the same 1137 security concerns of Proxy Mobile IPv6 [RFC5213]. It is recommended 1138 that the signaling messages, Proxy Binding Update and Proxy Binding 1139 Acknowledgment, exchanged between the MAARs are protected using IPsec 1140 using the established security association between them. This 1141 essentially eliminates the threats related to the impersonation of a 1142 MAAR. 1144 When the CMD acts as a PBU/PBA relay, the CMD may act as a relay of a 1145 single PBU to multiple previous MAARs. In situations of many fast 1146 handovers (e.g., with vehicular networks), there may exist multiple 1147 previous (e.g., k) MAARs exist. In this situation, the CMD creates k 1148 outgoing packets from a single incoming packet. This bears a certain 1149 amplification risk. The CMD SHOULD use a pacing approach to limit 1150 this amplification risk. 1152 When the CMD acts as MAAR locator, mobility signaling (PBAs) is 1153 exchanged between P-MAARs and current S-MAAR. This requires security 1154 associations to exist between the involved MAARs (in addition to the 1155 ones needed with the CMD). 1157 Since deregistration is performed by timeout, measures SHOULD be 1158 implemented to minimize the risks associated to continued resource 1159 consumption (DoS attacks), e.g., imposing a limit of the number of 1160 P-MAARs associated to a given MN. 1162 7. Acknowledgments 1164 The authors would like to thank Dirk von Hugo, John Kaippallimalil, 1165 Ines Robles and Joerg Ott for the comments on this document. The 1166 authors would also like to thank Marco Liebsch, Dirk von Hugo, Alex 1167 Petrescu, Daniel Corujo, Akbar Rahman, Danny Moses, Xinpeng Wei and 1168 Satoru Matsushima for their comments and discussion on the documents 1169 [I-D.bernardos-dmm-distributed-anchoring] and 1170 [I-D.bernardos-dmm-pmip] on which the present document is based. 1172 The authors would also like to thank Lyle Bertz and Danny Moses for 1173 their in-deep review of this document and their very valuable 1174 comments and suggestions. 1176 8. References 1178 8.1. Normative References 1180 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1181 Requirement Levels", BCP 14, RFC 2119, 1182 DOI 10.17487/RFC2119, March 1997, 1183 . 1185 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 1186 More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191, 1187 November 2005, . 1189 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 1190 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 1191 DOI 10.17487/RFC4861, September 2007, 1192 . 1194 [RFC5213] Gundavelli, S., Ed., Leung, K., Devarapalli, V., 1195 Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", 1196 RFC 5213, DOI 10.17487/RFC5213, August 2008, 1197 . 1199 [RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility 1200 Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July 1201 2011, . 1203 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1204 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1205 May 2017, . 1207 8.2. Informative References 1209 [I-D.bernardos-dmm-distributed-anchoring] 1210 Bernardos, C. and J. Zuniga, "PMIPv6-based distributed 1211 anchoring", draft-bernardos-dmm-distributed-anchoring-09 1212 (work in progress), May 2017. 1214 [I-D.bernardos-dmm-pmip] 1215 Bernardos, C., Oliva, A., and F. Giust, "A PMIPv6-based 1216 solution for Distributed Mobility Management", draft- 1217 bernardos-dmm-pmip-09 (work in progress), September 2017. 1219 [I-D.ietf-dmm-deployment-models] 1220 Gundavelli, S. and S. Jeon, "DMM Deployment Models and 1221 Architectural Considerations", draft-ietf-dmm-deployment- 1222 models-04 (work in progress), May 2018. 1224 [RFC7333] Chan, H., Ed., Liu, D., Seite, P., Yokota, H., and J. 1225 Korhonen, "Requirements for Distributed Mobility 1226 Management", RFC 7333, DOI 10.17487/RFC7333, August 2014, 1227 . 1229 [RFC7429] Liu, D., Ed., Zuniga, JC., Ed., Seite, P., Chan, H., and 1230 CJ. Bernardos, "Distributed Mobility Management: Current 1231 Practices and Gap Analysis", RFC 7429, 1232 DOI 10.17487/RFC7429, January 2015, 1233 . 1235 [RFC8563] Katz, D., Ward, D., Pallagatti, S., Ed., and G. Mirsky, 1236 Ed., "Bidirectional Forwarding Detection (BFD) Multipoint 1237 Active Tails", RFC 8563, DOI 10.17487/RFC8563, April 2019, 1238 . 1240 Appendix A. Comparison with Requirement document 1242 In this section we describe how our solution addresses the DMM 1243 requirements listed in [RFC7333]. 1245 A.1. Distributed mobility management 1247 "IP mobility, network access solutions, and forwarding solutions 1248 provided by DMM MUST enable traffic to avoid traversing a single 1249 mobility anchor far from the optimal route." 1251 In our solution, a MAAR is responsible to handle the mobility for 1252 those IP flows started when the MN is attached to it. As long as the 1253 MN remains connected to the MAAR's access links, the IP packets of 1254 such flows can benefit from the optimal path. When the MN moves to 1255 another MAAR, the path becomes non-optimal for ongoing flows, as they 1256 are anchored to the previous MAAR, but newly started IP sessions are 1257 forwarded by the new MAAR through the optimal path. 1259 A.2. Bypassable network-layer mobility support for each application 1260 session 1262 "DMM solutions MUST enable network-layer mobility, but it MUST be 1263 possible for any individual active application session (flow) to not 1264 use it. Mobility support is needed, for example, when a mobile host 1265 moves and an application cannot cope with a change in the IP address. 1266 Mobility support is also needed when a mobile router changes its IP 1267 address as it moves together with a host and, in the presence of 1268 ingress filtering, an application in the host is interrupted. 1269 However, mobility support at the network layer is not always needed; 1270 a mobile node can often be stationary, and mobility support can also 1271 be provided at other layers. It is then not always necessary to 1272 maintain a stable IP address or prefix for an active application 1273 session." 1275 Our DMM solution operates at the IP layer, hence upper layers are 1276 totally transparent to the mobility operations. In particular, 1277 ongoing IP sessions are not disrupted after a change of access 1278 network. The routability of the old address is ensured by the IP 1279 tunnel with the old MAAR. New IP sessions are started with the new 1280 address. From the application's perspective, those processes which 1281 sockets are bound to a unique IP address do not suffer any impact. 1282 For the other applications, the sockets bound to the old address are 1283 preserved, whereas next sockets use the new address. 1285 A.3. IPv6 deployment 1287 "DMM solutions SHOULD target IPv6 as the primary deployment 1288 environment and SHOULD NOT be tailored specifically to support IPv4, 1289 particularly in situations where private IPv4 addresses and/or NATs 1290 are used." 1292 The DMM solution we propose targets IPv6 only. 1294 A.4. Existing mobility protocols 1296 "A DMM solution MUST first consider reusing and extending IETF 1297 standard protocols before specifying new protocols." 1299 This DMM solution is derived from the operations and messages 1300 specified in [RFC5213]. 1302 A.5. Coexistence with deployed networks/hosts and operability across 1303 different networks 1305 "A DMM solution may require loose, tight, or no integration into 1306 existing mobility protocols and host IP stacks. Regardless of the 1307 integration level, DMM implementations MUST be able to coexist with 1308 existing network deployments, end hosts, and routers that may or may 1309 not implement existing mobility protocols. Furthermore, a DMM 1310 solution SHOULD work across different networks, possibly operated as 1311 separate administrative domains, when the needed mobility management 1312 signaling, forwarding, and network access are allowed by the trust 1313 relationship between them" 1315 The partially distributed DMM solution (distributed data plane and 1316 centralized control plane) can be extended to provide a fallback 1317 mechanism to operate as legacy Proxy Mobile IPv6. It is necessary to 1318 instruct MAARs to always establish a tunnel with the same MAAR, 1319 working as LMA. The fully distributed DMM solution (distributed data 1320 and control plane) can be extended as well, but it requires more 1321 intervention. The partially distributed DMM solution can be deployed 1322 across different domains with trust agreements if the CMDs of the 1323 operators are enabled to transfer context from one node to another. 1325 The fully distributed DMM solution works across multiple domains if 1326 the same signalling scheme is used in both domains. 1328 A.6. Operation and management considerations 1330 "A DMM solution needs to consider configuring a device, monitoring 1331 the current operational state of a device, and responding to events 1332 that impact the device, possibly by modifying the configuration and 1333 storing the data in a format that can be analyzed later. 1335 The proposed solution can re-use existing mechanisms defined for the 1336 operation and management of Proxy Mobile IPv6. 1338 A.7. Security considerations 1340 "A DMM solution MUST support any security protocols and mechanisms 1341 needed to secure the network and to make continuous security 1342 improvements. In addition, with security taken into consideration 1343 early in the design, a DMM solution MUST NOT introduce new security 1344 risks or amplify existing security risks that cannot be mitigated by 1345 existing security protocols and mechanisms." 1347 The proposed solution does not specify a security mechanism, given 1348 that the same mechanism for PMIPv6 can be used. 1350 A.8. Multicast considerations 1352 "DMM SHOULD enable multicast solutions to be developed to avoid 1353 network inefficiency in multicast traffic delivery." 1355 This solution in its current version does not specify any support for 1356 multicast traffic. 1358 Appendix B. Implementation experience 1360 The network-based DMM solution described in section Section 3.4 is 1361 now available at the Open Distributed Mobility Management (ODMM) 1362 project (http://www.odmm.net/), under the name of Mobility Anchors 1363 Distribution for PMIPv6 (MAD-PMIPv6). The ODMM platform is intended 1364 to foster DMM development and deployment, by serving as a framework 1365 to host open source implementations. 1367 The MAD-PMIPv6 code is developed in ANSI C from the existing UMIP 1368 implementation for PMIP. The most relevant changes with respect to 1369 the UMIP original version are related to how to create the CMD and 1370 MAAR's state machines from those of an LMA and a MAG; for this 1371 purpose, part of the LMA code was copied to the MAG, in order to send 1372 PBA messages and parse PBU. Also, the LMA routing functions were 1373 removed completely, and moved to the MAG, because MAARs need to route 1374 through the tunnels in downlink (as an LMA) and in uplink (as a MAG). 1376 Tunnel management is hence a relevant technical aspect, as multiple 1377 tunnels are established by a single MAAR, which keeps their status 1378 directly into the MN's BCE. Indeed, from the implementation 1379 experience it was chosen to create an ancillary data structure as 1380 field within a BCE: the data structure is called "MAAR list" and 1381 stores the previous MAARs' address and the corresponding prefix(es) 1382 assigned for the MN. Only the CMD and the serving MAAR store this 1383 data structure, because the CMD maintains the global MN's mobility 1384 session formed during the MN's roaming within the domain, and the 1385 serving MAAR needs to know which previous MAARs were visited, the 1386 prefix(es) they assigned and the tunnels established with them. 1387 Conversely, a previous MAAR only needs to know which is the current 1388 Serving MAAR and establish a single tunnel with it. For this reason, 1389 a MAAR that receives a PBU from the CMD (meaning that the MN attached 1390 to another MAAR), first sets up the routing state for the MN's 1391 prefix(es) it is anchoring, then stops the BCE expiry timer and 1392 deletes the MAAR list (if present) since it is no longer useful. 1394 In order to have the MN totally unaware of the changes in the access 1395 link, all MAARs implement the Distributed Logical Interface (DLIF) 1396 concept. Moreover, it should be noted that the protocols designed in 1397 the document work only at the network layer to handle the MNs joining 1398 or leaving the domain. This should guarantee a certain independency 1399 to a particular access technology. The implementation reflects this 1400 reasoning, but we argue that an interaction with lower layers 1401 produces a more effective attachment and detachment detection, 1402 therefore improving the performance, also regarding de-registration 1403 mechanisms. 1405 It was chosen to implement the "proxy" solution because it produces 1406 the shortest handover latency, but a slight modification on the CMD 1407 state machine can produce the first scenario described ("relay") 1408 which guarantees a more consistent request/ack scheme between the 1409 MAARS. By modifying also the MAAR's state machine it can be 1410 implemented the second solution ("locator"). 1412 An early MAD-PMIPv6 implementation was shown during a demo session at 1413 the IETF 83rd, in Paris in March 2012. An enhancement version of the 1414 prototype has been presented at the 87th IETF meeting in Berlin, July 1415 2013. The updated demo included a use case scenario employing a CDN 1416 system for video delivery. More, MAD-PMIPv6 has been extensively 1417 used and evaluated within a testbed employing heterogeneous radio 1418 accesses within the framework of the MEDIEVAL EU project. MAD-PMIPv6 1419 software is currently part of a DMM test-bed comprising 3 MAARs, one 1420 CMD, one MN and a CN. All the machines used in the demos were Linux 1421 UBUNTU 10.04 systems with kernel 2.6.32, but the prototype has been 1422 tested also under newer systems. This testbed was also used by the 1423 iJOIN EU project. 1425 Authors' Addresses 1427 Carlos J. Bernardos 1428 Universidad Carlos III de Madrid 1429 Av. Universidad, 30 1430 Leganes, Madrid 28911 1431 Spain 1433 Phone: +34 91624 6236 1434 Email: cjbc@it.uc3m.es 1435 URI: http://www.it.uc3m.es/cjbc/ 1437 Antonio de la Oliva 1438 Universidad Carlos III de Madrid 1439 Av. Universidad, 30 1440 Leganes, Madrid 28911 1441 Spain 1443 Phone: +34 91624 8803 1444 Email: aoliva@it.uc3m.es 1445 URI: http://www.it.uc3m.es/aoliva/ 1447 Fabio Giust 1448 Athonet S.r.l. 1450 Email: fabio.giust.2011@ieee.org 1452 Juan Carlos Zuniga 1453 SIGFOX 1454 425 rue Jean Rostand 1455 Labege 31670 1456 France 1458 Email: j.c.zuniga@ieee.org 1459 URI: http://www.sigfox.com/ 1460 Alain Mourad 1461 InterDigital Europe 1463 Email: Alain.Mourad@InterDigital.com 1464 URI: http://www.InterDigital.com/