idnits 2.17.1 draft-ietf-dmm-pmipv6-dlif-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 -- The document date (March 8, 2020) is 1502 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: September 9, 2020 F. Giust 6 Athonet 7 JC. Zuniga 8 SIGFOX 9 A. Mourad 10 InterDigital 11 March 8, 2020 13 Proxy Mobile IPv6 extensions for Distributed Mobility Management 14 draft-ietf-dmm-pmipv6-dlif-06 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 September 9, 2020. 61 Copyright Notice 63 Copyright (c) 2020 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 . . . . . . . . . . . . . . . . . . . . 6 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. Retransmissions and Rate Limiting . . . . . . . . . . . . 14 87 3.7. The Distributed Logical Interface (DLIF) concept . . . . 14 88 4. Message Format . . . . . . . . . . . . . . . . . . . . . . . 18 89 4.1. Proxy Binding Update . . . . . . . . . . . . . . . . . . 18 90 4.2. Proxy Binding Acknowledgment . . . . . . . . . . . . . . 19 91 4.3. Anchored Prefix Option . . . . . . . . . . . . . . . . . 19 92 4.4. Local Prefix Option . . . . . . . . . . . . . . . . . . . 21 93 4.5. Previous MAAR Option . . . . . . . . . . . . . . . . . . 22 94 4.6. Serving MAAR Option . . . . . . . . . . . . . . . . . . . 23 95 4.7. DLIF Link-local Address Option . . . . . . . . . . . . . 24 96 4.8. DLIF Link-layer Address Option . . . . . . . . . . . . . 25 98 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 99 6. Security Considerations . . . . . . . . . . . . . . . . . . . 26 100 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27 101 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 102 8.1. Normative References . . . . . . . . . . . . . . . . . . 27 103 8.2. Informative References . . . . . . . . . . . . . . . . . 28 104 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 106 1. Introduction 108 The Distributed Mobility Management (DMM) paradigm aims at minimizing 109 the impact of currently standardized mobility management solutions 110 which are centralized (at least to a considerable extent) [RFC7333]. 112 Current IP mobility solutions, standardized with the names of Mobile 113 IPv6 [RFC6275], or Proxy Mobile IPv6 (PMIPv6) [RFC5213], just to cite 114 the two most relevant examples, offer mobility support at the cost of 115 handling operations at a cardinal point, the mobility anchor (i.e., 116 the home agent for Mobile IPv6, and the local mobility anchor for 117 Proxy Mobile IPv6), and burdening it with data forwarding and control 118 mechanisms for a great amount of users. As stated in [RFC7333], 119 centralized mobility solutions are prone to several problems and 120 limitations: longer (sub-optimal) routing paths, scalability 121 problems, signaling overhead (and most likely a longer associated 122 handover latency), more complex network deployment, higher 123 vulnerability due to the existence of a potential single point of 124 failure, and lack of granularity of the mobility management service 125 (i.e., mobility is offered on a per-node basis, not being possible to 126 define finer granularity policies, as for example per-application). 128 The purpose of Distributed Mobility Management is to overcome the 129 limitations of the traditional centralized mobility management 130 [RFC7333] [RFC7429]; the main concept behind DMM solutions is indeed 131 bringing the mobility anchor closer to the Mobile Node (MN). 132 Following this idea, the central anchor is moved to the edge of the 133 network, being deployed in the default gateway of the mobile node. 134 That is, the first elements that provide IP connectivity to a set of 135 MNs are also the mobility managers for those MNs. In this document, 136 we call these entities Mobility Anchors and Access Routers (MAARs). 138 This document focuses on network-based DMM, hence the starting point 139 is making PMIPv6 work in a distributed manner [RFC7429]. Mobility is 140 handled by the network without the MNs involvement, but, differently 141 from PMIPv6, when the MN moves from one access network to another, it 142 may also change anchor router, hence requiring signaling between the 143 anchors to retrieve the MN's previous location(s). Also, a key- 144 aspect of network-based DMM, is that a prefix pool belongs 145 exclusively to each MAAR, in the sense that those prefixes are 146 assigned by the MAAR to the MNs attached to it, and they are routable 147 at that MAAR. Prefixes are assigned to MNs attached a MAAR at that 148 time, but remain with those MNs as mobility occurs, remaining always 149 routable at that MAAR as well as towards the MN itself. 151 We consider partially distributed schemes, where only the data plane 152 is distributed among access routers similar to MAGs, whereas the 153 control plane is kept centralized towards a cardinal node used as 154 information store, but relieved from any route management and MN's 155 data forwarding task. 157 2. Terminology 159 The following terms used in this document are defined in the Proxy 160 Mobile IPv6 specification [RFC5213]: 162 Local Mobility Anchor (LMA) 164 Mobile Access Gateway (MAG) 166 Mobile Node (MN) 168 Binding Cache Entry (BCE) 170 Proxy Care-of Address (P-CoA) 172 Proxy Binding Update (PBU) 174 Proxy Binding Acknowledgement (PBA) 176 The following terms are used in this document: 178 Home Control-Plane Anchor (Home-CPA or H-CPA): The Home-CPA function 179 hosts the mobile node (MN)'s mobility session. There can be more 180 than one mobility session for a mobile node and those sessions may 181 be anchored on the same or different Home-CPA's. The home-CPA 182 will interface with the home-DPA for managing the forwarding 183 state. 185 Home Data Plane Anchor (Home-DPA or H-DPA): The Home-DPA is the 186 topological anchor for the MN's IP address/ prefix(es). The Home- 187 DPA is chosen by the Home-CPA on a session- basis. The Home-DPA 188 is in the forwarding path for all the mobile node's IP traffic. 190 Access Control Plane Node (Access-CPN or A-CPN): The Access-CPN is 191 responsible for interfacing with the mobile node's Home-CPA and 192 with the Access-DPN. The Access-CPN has a protocol interface to 193 the Home-CPA. 195 Access Data Plane Node (Access-DPN or A-DPN): The Access-DPN 196 function is hosted on the first-hop router where the mobile node 197 is attached. This function is not hosted on a layer-2 bridging 198 device such as a eNode(B) or Access Point. 200 The following terms are defined and used in this document: 202 MAAR (Mobility Anchor and Access Router). First hop router where the 203 mobile nodes attach to. It also plays the role of mobility 204 manager for the IPv6 prefixes it anchors, running the 205 functionalities of PMIP's MAG and LMA. Depending on the prefix, 206 it plays the role of Access-DPN, Home-DPA and Access-CPN. 208 CMD (Central Mobility Database). The node that stores the BCEs 209 allocated for the MNs in the mobility domain. It plays the role 210 of Home-CPA. 212 P-MAAR (Previous MAAR). When a MN moves to a new point of attachment 213 a new MAAR might be allocated as its anchor point for future IPv6 214 prefixes. The MAAR that served the MN prior to new attachment 215 becomes the P-MAAR. It is still the anchor point for the IPv6 216 prefixes it had allocated to the MN in the past and serves as the 217 Home-DPA for flows using these prefixes. There might be several 218 P-MAARs serving a MN when the MN is frequently switching points of 219 attachment while maintaining long-lasting flows. 221 S-MAAR (Serving MAAR). The MAAR which the MN is currently attached 222 to. Depending on the prefix, it plays the role of Access-DPN, 223 Home-DPA and Access-CPN. 225 Anchoring MAAR. A MAAR anchoring an IPv6 prefix used by an MN. 227 DLIF (Distributed Logical Interface). It is a logical interface at 228 the IP stack of the MAAR. For each active prefix used by the MN, 229 the S-MAAR has a DLIF configured (associated to each MAAR still 230 anchoring flows). In this way, an S-MAAR exposes itself towards 231 each MN as multiple routers, one as itself and one per P-MAAR. 233 3. PMIPv6 DMM extensions 235 The solution consists of de-coupling the entities that participate in 236 the data and the control planes: the data plane becomes distributed 237 and managed by the MAARs near the edge of the network, while the 238 control plane, besides those on the MAARs, relies on a central entity 239 called Central Mobility Database (CMD). In the proposed 240 architecture, the hierarchy present in PMIPv6 between LMA and MAG is 241 preserved, but with the following substantial variations: 243 o The LMA is relieved from the data forwarding role, only the 244 Binding Cache and its management operations are maintained. Hence 245 the LMA is renamed into CMD, which is therefore a Home-CPA. Also, 246 the CMD is able to send and parse both PBU and PBA messages. 248 o The MAG is enriched with the LMA functionalities, hence the name 249 Mobility Anchor and Access Router (MAAR). It maintains a local 250 Binding Cache for the MNs that are attached to it and it is able 251 to send and parse PBU and PBA messages. 253 o The binding cache will be extended to include information 254 regarding P-MAARs where the mobile node was anchored and still 255 retains active data sessions. 257 o Each MAAR has a unique set of global prefixes (which are 258 configurable), that can be allocated by the MAAR to the MNs, but 259 must be exclusive to that MAAR, i.e. no other MAAR can allocate 260 the same prefixes. 262 The MAARs leverage the CMD to access and update information related 263 to the MNs, stored as mobility sessions; hence, a centralized node 264 maintains a global view of the network status. The CMD is queried 265 whenever a MN is detected to join/leave the mobility domain. It 266 might be a fresh attachment, a detachment or a handover, but as MAARs 267 are not aware of past information related to a mobility session, they 268 contact the CMD to retrieve the data of interest and eventually take 269 the appropriate action. The procedure adopted for the query and the 270 message exchange sequence might vary to optimize the update latency 271 and/or the signaling overhead. Here is presented one method for the 272 initial registration, and three different approaches for updating the 273 mobility sessions using PBUs and PBAs. Each approach assigns a 274 different role to the CMD: 276 o The CMD is a PBU/PBA relay; 278 o The CMD is only a MAAR locator; 280 o The CMD is a PBU/PBA proxy. 282 The solution described in this document allows performing per-prefix 283 anchoring decisions, to support e.g., some flows to be anchored at a 284 central Home-DPA (like a traditional LMA) or to enable an application 285 to switch to the locally anchored prefix to gain route optimization, 286 as indicated in [RFC8563]. This type of per-prefix treatment would 287 potentially require additional extensions to the MAARs and signaling 288 between the MAARs and the MNs to convey the per-flow anchor 289 preference (central, distributed), which are not covered in this 290 document. 292 Note that a MN may move across different MAARs, which might result in 293 several P-MAARs existing at a given moment of time, each of them 294 anchoring a different prefix used by the MN. 296 3.1. Initial registration 298 Initial registration is performed when an MN attaches to a network 299 for the first time (rather than attaching to a new network after 300 moving from a previous one). 302 In this description (shown in Figure 1), it is assumed that: 304 1. The MN is attaching to MAAR1. 306 2. The MN is authorized to attach to the network. 308 Upon MN attachment, the following operations take place: 310 1. MAAR1 assigns a global IPv6 prefix from its own prefix pool to 311 the MN (Pref1). It also stores this prefix (Pref1) in the 312 locally allocated temporary Binding Cache Entry (BCE). 314 2. MAAR1 sends a PBU [RFC5213] with Pref1 and the MN's MN-ID to the 315 CMD. 317 3. Since this is an initial registration, the CMD stores a BCE 318 containing as primary fields the MN-ID, Pref1 and MAAR1's address 319 as a Proxy-CoA. 321 4. The CMD replies with a PBA with the usual options defined in 322 PMIPv6 [RFC5213], meaning that the MN's registration is fresh and 323 no past status is available. 325 5. MAAR1 stores the BCE described in (1) and unicasts a Router 326 Advertisement (RA) to the MN with Pref1. 328 6. The MN uses Pref1 to configure an IPv6 address (IP1) (e.g., with 329 stateless auto-configuration, SLAAC). 331 Note that: 333 1. Alternative IPv6 auto-configuration mechanisms can also be used, 334 though this document describes the SLAAC-based one. 336 2. IP1 is routable at MAAR1, in the sense that it is on the path of 337 packets addressed to the MN. 339 3. MAAR1 acts as a plain router for packets destined to the MN, as 340 no encapsulation nor special handling takes place. 342 In the diagram shown in Figure 1 (and subsequent diagrams), the flow 343 of packets is presented using '*'. 345 +-----+ +---+ +--+ 346 |MAAR1| |CMD| |CN| 347 +-----+ +---+ +*-+ 348 | | * 349 MN | * +---+ 350 attach. | ***** _|CMD|_ 351 detection | flow1 * / +-+-+ \ 352 | | * / | \ 353 local BCE | * / | \ 354 allocation | * / | \ 355 |--- PBU -->| +---*-+-' +--+--+ `+-----+ 356 | BCE | * | | | | | 357 | creation |MAAR1+------+MAAR2+-----+MAAR3| 358 |<-- PBA ---| | * | | | | | 359 local BCE | +---*-+ +-----+ +-----+ 360 finalized | * 361 | | Pref1 * 362 | | +*-+ 363 | | |MN| 364 | | +--+ 366 Operations sequence Packets flow 368 Figure 1: First attachment to the network 370 Note that the registration process does not change regardless of the 371 CMD's modes (relay, locator or proxy) described next. The procedure 372 is depicted in Figure 1. 374 3.2. The CMD as PBU/PBA relay 376 Upon MN mobility, if the CMD behaves as PBU/PBA relay, the following 377 operations take place: 379 1. When the MN moves from its current point of attachment and 380 attaches to MAAR2 (now the S-MAAR), MAAR2 reserves an IPv6 prefix 381 (Pref2), it stores a temporary BCE, and it sends a PBU to the CMD 382 for registration. 384 2. Upon PBU reception and BC lookup, the CMD retrieves an already 385 existing entry for the MN, binding the MN-ID to its former 386 location; thus, the CMD forwards the PBU to the MAAR indicated as 387 Proxy CoA (MAAR1), including a new mobility option to communicate 388 the S-MAAR's global address to MAAR1, defined as Serving MAAR 389 Option in Section 4.6. The CMD updates the P-CoA field in the 390 BCE related to the MN with the S-MAAR's address. 392 3. Upon PBU reception, MAAR1 can install a tunnel on its side 393 towards MAAR2 and the related routes for Pref1. Then MAAR1 394 replies to the CMD with a PBA (including the option mentioned 395 before) to ensure that the new location has successfully changed, 396 containing the prefix anchored at MAAR1 in the Home Network 397 Prefix option. 399 4. The CMD, after receiving the PBA, updates the BCE populating an 400 instance of the P-MAAR list. The P-MAAR list is an additional 401 field on the BCE that contains an element for each P-MAAR 402 involved in the MN's mobility session. The list element contains 403 the P-MAAR's global address and the prefix it has delegated. 404 Also, the CMD sends a PBA to the new S-MAAR, containing the 405 previous Proxy-CoA and the prefix anchored to it embedded into a 406 new mobility option called Previous MAAR Option (defined in 407 Section 4.5), so that, upon PBA arrival, a bi-directional tunnel 408 can be established between the two MAARs and new routes are set 409 appropriately to recover the IP flow(s) carrying Pref1. 411 5. Now packets destined to Pref1 are first received by MAAR1, 412 encapsulated into the tunnel and forwarded to MAAR2, which 413 finally delivers them to their destination. In uplink, when the 414 MN transmits packets using Pref1 as source address, they are sent 415 to MAAR2, as it is MN's new default gateway, then tunneled to 416 MAAR1 which routes them towards the next hop to destination. 417 Conversely, packets carrying Pref2 are routed by MAAR2 without 418 any special packet handling both for uplink and downlink. 420 +-----+ +---+ +-----+ +--+ +--+ 421 |MAAR1| |CMD| |MAAR2| |CN| |CN| 422 +-----+ +---+ +-----+ +*-+ +*-+ 423 | | | * * 424 | | MN * +---+ * 425 | | attach. ***** _|CMD|_ * 426 | | det. flow1 * / +-+-+ \ *flow2 427 | |<-- PBU ---| * / | \ * 428 | BCE | * / | ******* 429 | check+ | * / | * \ 430 | update | +---*-+-' +--+-*+ `+-----+ 431 |<-- PBU*---| | | * | | *| | | 432 route | | |MAAR1|______|MAAR2+-----+MAAR3| 433 update | | | **(______)** *| | | 434 |--- PBA*-->| | +-----+ +-*--*+ +-----+ 435 | BCE | * * 436 | update | Pref1 * *Pref2 437 | |--- PBA*-->| +*--*+ 438 | | route ---move-->|*MN*| 439 | | update +----+ 441 Operations sequence Data Packets flow 442 PBU/PBA Messages with * contain 443 a new mobility option 445 Figure 2: Scenario after a handover, CMD as relay 447 For MN's next movements the process is repeated except the number of 448 P-MAARs involved increases (accordingly to the number of prefixes 449 that the MN wishes to maintain). Indeed, once the CMD receives the 450 first PBU from the new S-MAAR, it forwards copies of the PBU to all 451 the P-MAARs indicated in the BCE, namely the one registered as 452 current P-CoA (i.e., the MAAR prior to handover) plus the ones in the 453 P-MAARs list. They reply with a PBA to the CMD, which aggregates 454 them into a single one to notify the S-MAAR, that finally can 455 establish the tunnels with the P-MAARs. 457 It should be noted that this design separates the mobility management 458 at the prefix granularity, and it can be tuned in order to erase old 459 mobility sessions when not required, while the MN is reachable 460 through the latest prefix acquired. Moreover, the latency associated 461 to the mobility update is bound to the PBA sent by the furthest 462 P-MAAR, in terms of RTT, that takes the longest time to reach the 463 CMD. The drawback can be mitigated introducing a timeout at the CMD, 464 by which, after its expiration, all the PBAs so far collected are 465 transmitted, and the remaining are sent later upon their arrival. 466 Note that in this case the S-MAAR might receive multiple PBAs from 467 the CMD in response to a PBU. The CMD SHOULD follow the 468 retransmissions and rate limiting considerations described in 469 Section 3.6, especially when aggregating and relaying PBAs. 471 When there are multiple previous MAARs, e.g., k MAARs, a single PBU 472 received by the CMD triggers k outgoing packets from a single 473 incoming packet. This may lead to packet bursts originated from the 474 CMD, albeit to different targets. Pacing mechanisms MUST be 475 introduced to avoid bursts on the outgoing link. 477 3.3. The CMD as MAAR locator 479 The handover latency experienced in the approach shown before can be 480 reduced if the P-MAARs are allowed to signal directly their 481 information to the new S-MAAR. This procedure reflects what was 482 described in Section 3.2 up to the moment the P-MAAR receives the PBU 483 with the S-MAAR option. At that point a P-MAAR is aware of the new 484 MN's location (because of the S-MAAR's address in the S-MAAR option), 485 and, besides sending a PBA to the CMD, it also sends a PBA to the 486 S-MAAR including the prefix it is anchoring. This latter PBA does 487 not need to include new options, as the prefix is embedded in the HNP 488 option and the P-MAAR's address is taken from the message's source 489 address. The CMD is relieved from forwarding the PBA to the S-MAAR, 490 as the latter receives a copy directly from the P-MAAR with the 491 necessary information to build the tunnels and set the appropriate 492 routes. Figure 3 illustrates the new message sequence, while the 493 data forwarding is unaltered. 495 +-----+ +---+ +-----+ +--+ +--+ 496 |MAAR1| |CMD| |MAAR2| |CN| |CN| 497 +-----+ +---+ +-----+ +*-+ +*-+ 498 | | | * * 499 | | MN * +---+ * 500 | | attach. ***** _|CMD|_ * 501 | | det. flow1 * / +-+-+ \ *flow2 502 | |<-- PBU ---| * / | \ * 503 | BCE | * / | ******* 504 | check+ | * / | * \ 505 | update | +---*-+-' +--+-*+ `+-----+ 506 |<-- PBU*---| | | * | | *| | | 507 route | | |MAAR1|______|MAAR2+-----+MAAR3| 508 update | | | **(______)** *| | | 509 |--------- PBA -------->| +-----+ +-*--*+ +-----+ 510 |--- PBA*-->| route * * 511 | BCE update Pref1 * *Pref2 512 | update | +*--*+ 513 | | | ---move-->|*MN*| 514 | | | +----+ 516 Operations sequence Data Packets flow 517 PBU/PBA Messages with * contain 518 a new mobility option 520 Figure 3: Scenario after a handover, CMD as locator 522 3.4. The CMD as MAAR proxy 524 A further enhancement of previous solutions can be achieved when the 525 CMD sends the PBA to the new S-MAAR before notifying the P-MAARs of 526 the location change. Indeed, when the CMD receives the PBU for the 527 new registration, it is already in possession of all the information 528 that the new S-MAAR requires to set up the tunnels and the routes. 529 Thus the PBA is sent to the S-MAAR immediately after a PBU is 530 received, including also in this case the P-MAAR option. In 531 parallel, a PBU is sent by the CMD to the P-MAARs containing the 532 S-MAAR option, to notify them about the new MN's location, so they 533 receive the information to establish the tunnels and routes on their 534 side. When P-MAARs complete the update, they send a PBA to the CMD 535 to indicate that the operation is concluded and the information is 536 updated in all network nodes. This procedure is obtained from the 537 first one re-arranging the order of the messages, but the parameters 538 communicated are the same. This scheme is depicted in Figure 4, 539 where, again, the data forwarding is kept untouched. 541 +-----+ +---+ +-----+ +--+ +--+ 542 |MAAR1| |CMD| |MAAR2| |CN| |CN| 543 +-----+ +---+ +-----+ +*-+ +*-+ 544 | | | * * 545 | | MN * +---+ * 546 | | attach. ***** _|CMD|_ * 547 | | det. flow1 * / +-+-+ \ *flow2 548 | |<-- PBU ---| * / | \ * 549 | BCE | * / | ******* 550 | check+ | * / | * \ 551 | update | +---*-+-' +--+-*+ `+-----+ 552 |<-- PBU*---x--- PBA*-->| | * | | *| | | 553 route | route |MAAR1|______|MAAR2+-----+MAAR3| 554 update | update | **(______)** *| | | 555 |--- PBA*-->| | +-----+ +-*--*+ +-----+ 556 | BCE | * * 557 | update | Pref1 * *Pref2 558 | | | +*--*+ 559 | | | ---move-->|*MN*| 560 | | | +----+ 562 Operations sequence Data Packets flow 563 PBU/PBA Messages with * contain 564 a new mobility option 566 Figure 4: Scenario after a handover, CMD as proxy 568 3.5. De-registration 570 The de-registration mechanism devised for PMIPv6 cannot be used as-is 571 in this solution. The reason for this is that each MAAR handles an 572 independent mobility session (i.e., a single or a set of prefixes) 573 for a given MN, whereas the aggregated session is stored at the CMD. 574 Indeed, if a previous MAAR initiates a de-registration procedure, 575 because the MN is no longer present on the MAAR's access link, it 576 removes the routing state for that (those) prefix(es), that would be 577 deleted by the CMD as well, hence defeating any prefix continuity 578 attempt. The simplest approach to overcome this limitation is to 579 deny a P-MAAR to de-register a prefix, that is, allowing only a 580 serving MAAR to de-register the whole MN session. This can be 581 achieved by first removing any layer-2 detachment event, so that de- 582 registration is triggered only when the binding lifetime expires, 583 hence providing a guard interval for the MN to connect to a new MAAR. 584 Then, a change in the MAAR operations is required, and at this stage 585 two possible solutions can be deployed: 587 o A previous MAAR stops the BCE timer upon receiving a PBU from the 588 CMD containing a "Serving MAAR" option. In this way only the 589 Serving MAAR is allowed to de-register the mobility session, 590 arguing that the MN definitely left the domain. 592 o Previous MAARs can, upon BCE expiry, send de-registration messages 593 to the CMD, which, instead of acknowledging the message with a 0 594 lifetime, sends back a PBA with a non-zero lifetime, hence re- 595 newing the session, if the MN is still connected to the domain. 597 3.6. Retransmissions and Rate Limiting 599 When sending PBUs, the node sending them (the CMD or S-MAAR) SHOULD 600 make use of the timeout also to deal with missing PBAs (to retransmit 601 PBUs). The INITIAL_BINDACK_TIMEOUT [RFC6275] SHOULD be used for 602 configuring the retransmission timer. The retransmissions by the 603 node MUST use an exponential backoff process in which the timeout 604 period is doubled upon each retransmission, until either the node 605 receives a response or the timeout period reaches the value 606 MAX_BINDACK_TIMEOUT [RFC6275]. The node MAY continue to send these 607 messages at this slower rate indefinitely. The node MUST NOT send 608 PBU messages to a particular node more than MAX_UPDATE_RATE times 609 within a second [RFC6275]. 611 3.7. The Distributed Logical Interface (DLIF) concept 613 One of the main challenges of a network-based DMM solution is how to 614 allow a mobile node to simultaneously send/receive traffic which is 615 anchored at different MAARs, and how to influence the mobile node's 616 selection process of its source IPv6 address for a new flow, without 617 requiring special support from the mobile node's IP stack. This 618 document defines the Distributed Logical Interface (DLIF), which is a 619 software construct in the MAAR that allows to easily hide the change 620 of associated anchors from the mobile node. 622 +---------------------------------------------------+ 623 ( Operator's ) 624 ( core ) 625 +---------------------------------------------------+ 626 | | 627 +---------------+ tunnel +---------------+ 628 | IP stack |===============| IP stack | 629 +---------------+ +-------+-------+ 630 | mn1mar1 |--+ (DLIFs) +--|mn1mar1|mn1mar2|--+ 631 +---------------+ | | +-------+-------+ | 632 | phy interface | | | | phy interface | | 633 +---------------+ | | +---------------+ | 634 MAAR1 (o) (o) MAAR2 (o) 635 x x 636 x x 637 prefA::/64 x x prefB::/64 638 (AdvPrefLft=0) x x 639 (o) 640 | 641 +-----+ 642 prefA::MN1 | MN1 | prefB::MN1 643 (deprecated) +-----+ 645 Figure 5: DLIF: exposing multiple routers (one per P-MAAR) 647 The basic idea of the DLIF concept is the following: each serving 648 MAAR exposes itself towards a given MN as multiple routers, one per 649 P-MAAR associated to the MN. Let's consider the example shown in 650 Figure 5, MN1 initially attaches to MAAR1, configuring an IPv6 651 address (prefA::MN1) from a prefix locally anchored at MAAR1 652 (prefA::/64). At this stage, MAAR1 plays both the role of anchoring 653 and serving MAAR, and also behaves as a plain IPv6 access router. 654 MAAR1 creates a distributed logical interface to communicate (point- 655 to-point link) with MN1, exposing itself as a (logical) router with a 656 specific MAC and IPv6 addresses (e.g., prefA::MAAR1/64 and 657 fe80::MAAR1/64) using the DLIF mn1mar1. As explained below, these 658 addresses represent the "logical" identity of MAAR1 towards MN1, and 659 will "follow" the mobile node while roaming within the domain (note 660 that the place where all this information is maintained and updated 661 is out-of-scope of this draft; potential examples are to keep it on 662 the home subscriber server -- HSS -- or the user's profile). 664 If MN1 moves and attaches to a different MAAR of the domain (MAAR2 in 665 the example of Figure 5), this MAAR will create a new logical 666 interface (mn1mar2) to expose itself towards MN1, providing it with a 667 locally anchored prefix (prefB::/64). In this case, since the MN1 668 has another active IPv6 address anchored at a MAAR1, MAAR2 also needs 669 to create an additional logical interface configured to resemble the 670 one used by MAAR1 to communicate with MN1. In this example, there is 671 only one P-MAAR (in addition to MAAR2, which is the serving one): 672 MAAR1, so only the logical interface mn1mar1 is created, but the same 673 process would be repeated in case there were more P-MAARs involved. 674 In order to maintain the prefix anchored at MAAR1 reachable, a tunnel 675 between MAAR1 and MAAR2 is established and the routing is modified 676 accordingly. The PBU/PBA signaling is used to set-up the bi- 677 directional tunnel between MAAR1 and MAAR2, and it might also be used 678 to convey to MAAR2 the information about the prefix(es) anchored at 679 MAAR1 and about the addresses of the associated DLIF (i.e., mn1mar1). 681 +------------------------------------------+ +----------------------+ 682 | MAAR1 | | MAAR2 | 683 |+----------------------------------------+| |+--------------------+| 684 ||+------------------++------------------+|| ||+------------------+|| 685 |||+-------++-------+||+-------++-------+||| |||+-------++-------+||| 686 ||||mn3mar1||mn3mar2||||mn2mar1||mn2mar2|||| ||||mn1mar1||mn1mar2|||| 687 |||| LMAC1 || LMAC2 |||| LMAC3 || LMAC4 |||| |||| LMAC5 || LMAC6 |||| 688 |||+-------++-------+||+-------++-------+||| |||+-------++-------+||| 689 ||| LIFs of MN3 || LIFs of MN2 ||| ||| LIFs of MN1 ||| 690 ||+------------------++------------------+|| ||+------------------+|| 691 || MAC1 (phy if MAAR1) || || MAC2 (phy if MAAR2)|| 692 |+----------------------------------------+| |+--------------------+| 693 +------------------------------------------+ +----------------------+ 694 x x x 695 x x x 696 (o) (o) (o) 697 | | | 698 +--+--+ +--+--+ +--+--+ 699 | MN3 | | MN2 | | MN1 | 700 +-----+ +-----+ +-----+ 702 Figure 6: Distributed Logical Interface concept 704 Figure 6 shows the logical interface concept in more detail. The 705 figure shows two MAARs and three MNs. MAAR1 is currently serving MN2 706 and MN3, while MAAR2 is serving MN1. Note that a serving MAAR always 707 plays the role of anchoring MAAR for the attached (served) MNs. Each 708 MAAR has one single physical wireless interface as depicted in this 709 example. 711 As introduced before, each MN always "sees" multiple logical routers 712 -- one per anchoring MAAR -- independently of its currently serving 713 MAAR. From the point of view of the MN, these MAARs are portrayed as 714 different routers, although the MN is physically attached to one 715 single interface. The way this is achieved is by the serving MAAR 716 configuring different logical interfaces. Focusing on MN1, it is 717 currently attached to MAAR2 (i.e., MAAR2 is its serving MAAR) and, 718 therefore, it has configured an IPv6 address from MAAR2's pool (e.g., 719 prefB::/64). MAAR2 has set-up a logical interface (mn1mar2) on top 720 of its wireless physical interface (phy if MAAR2) which is used to 721 serve MN1. This interface has a logical MAC address (LMAC6), 722 different from the hardware MAC address (MAC2) of the physical 723 interface of MAAR2. Over the mn1mar2 interface, MAAR2 advertises its 724 locally anchored prefix prefB::/64. Before attaching to MAAR2, MN1 725 was attached to MAAR1, configuring also an address locally anchored 726 at that MAAR, which is still being used by MN1 in active 727 communications. MN1 keeps "seeing" an interface connecting to MAAR1, 728 as if it were directly connected to the two MAARs. This is achieved 729 by the serving MAAR (MAAR2) configuring an additional distributed 730 logical interface: mn1mar1, which behaves as the logical interface 731 configured by MAAR1 when MN1 was attached to it. This means that 732 both the MAC and IPv6 addresses configured on this logical interface 733 remain the same regardless of the physical MAAR which is serving the 734 MN. The information required by a serving MAAR to properly configure 735 this logical interfaces can be obtained in different ways: as part of 736 the information conveyed in the PBA, from an external database (e.g., 737 the HSS) or by other means. As shown in the figure, each MAAR may 738 have several logical interfaces associated to each attached MN, 739 having always at least one (since a serving MAAR is also an anchoring 740 MAAR for the attached MN). 742 In order to enforce the use of the prefix locally anchored at the 743 serving MAAR, the router advertisements sent over those logical 744 interfaces playing the role of anchoring MAARs (different from the 745 serving one) include a zero preferred prefix lifetime (and a non-zero 746 valid prefix lifetime, so the prefix remains valid, while being 747 deprecated). The goal is to deprecate the prefixes delegated by 748 these MAARs (so that they will no longer be serving the MN). Note 749 that on-going communications may keep on using those addresses, even 750 if they are deprecated, so this only affects the establishment of new 751 sessions. 753 The distributed logical interface concept also enables the following 754 use case: suppose that access to a local IP network is provided by a 755 given MAAR (e.g., MAAR1 in the example shown in Figure 5) and that 756 the resources available at that network cannot be reached from 757 outside the local network (e.g., cannot be accessed by an MN attached 758 to MAAR2). This is similar to the local IP access scenario 759 considered by 3GPP, where a local gateway node is selected for 760 sessions requiring access to services provided locally (instead of 761 going through a central gateway). The goal is to allow an MN to be 762 able to roam while still being able to have connectivity to this 763 local IP network. The solution adopted to support this case makes 764 use of RFC 4191 [RFC4191] more specific routes when the MN moves to a 765 MAAR different from the one providing access to the local IP network 766 (MAAR1 in the example). These routes are advertised through the 767 distributed logical interface representing the MAAR providing access 768 to the local network (MAAR1 in this example). In this way, if MN1 769 moves from MAAR1 to MAAR2, any active session that MN1 may have with 770 a node on the local network connected to MAAR1 will survive via the 771 tunnel between MAAR1 and MAAR2. Also, any potential future 772 connection attempt towards the local network will be supported, even 773 though MN1 is no longer attached to MAAR1. 775 4. Message Format 777 This section defines extensions to the Proxy Mobile IPv6 [RFC5213] 778 protocol messages. 780 4.1. Proxy Binding Update 782 A new flag (D) is included in the Proxy Binding Update to indicate 783 that the Proxy Binding Update is coming from a MAAR or a CMD and not 784 from a mobile access gateway. The rest of the Proxy Binding Update 785 format remains the same as defined in [RFC5213]. 787 0 1 2 3 788 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 789 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 790 | Sequence # | 791 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 792 |A|H|L|K|M|R|P|F|T|B|S|D| Rsrvd | Lifetime | 793 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 794 | | 795 . . 796 . Mobility options . 797 . . 798 | | 799 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 801 DMM Flag (D) 803 The D Flag is set to indicate to the receiver of the message that 804 the Proxy Binding Update is from a MAAR or a CMD. When an LMA 805 that does not support the extensions described in this document 806 receives a message with the D-Flag set, the PBU in that case MUST 807 NOT be processed by the LMA and an error MUST be returned. 809 Mobility Options 811 Variable-length field of such length that the complete Mobility 812 Header is an integer multiple of 8 octets long. This field 813 contains zero or more TLV-encoded mobility options. The encoding 814 and format of defined options are described in Section 6.2 of 815 [RFC6275]. The receiving node MUST ignore and skip any options 816 that it does not understand. 818 4.2. Proxy Binding Acknowledgment 820 A new flag (D) is included in the Proxy Binding Acknowledgment to 821 indicate that the sender supports operating as a MAAR or CMD. The 822 rest of the Proxy Binding Acknowledgment format remains the same as 823 defined in [RFC5213]. 825 0 1 2 3 826 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 827 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 828 | Status |K|R|P|T|B|S|D| | 829 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 830 | Sequence # | Lifetime | 831 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 832 | | 833 . . 834 . Mobility options . 835 . . 836 | | 837 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 839 DMM Flag (D) 841 The D flag is set to indicate that the sender of the message 842 supports operating as a MAAR or a CMD. When a MAG that does not 843 support the extensions described in this document receives a 844 message with the D-Flag set, it MUST ignore the message and an 845 error MUST be returned. 847 Mobility Options 849 Variable-length field of such length that the complete Mobility 850 Header is an integer multiple of 8 octets long. This field 851 contains zero or more TLV-encoded mobility options. The encoding 852 and format of defined options are described in Section 6.2 of 853 [RFC6275]. The MAAR MUST ignore and skip any options that it does 854 not understand. 856 4.3. Anchored Prefix Option 858 A new Anchored Prefix option is defined for use with the Proxy 859 Binding Update and Proxy Binding Acknowledgment messages exchanged 860 between MAARs and CMDs. Therefore, this option can only appear if 861 the D bit is set in a PBU/PBA. This option is used for exchanging 862 the mobile node's prefix anchored at the anchoring MAAR. There can 863 be multiple Anchored Prefix options present in the message. 865 The Anchored Prefix Option has an alignment requirement of 8n+4. Its 866 format is as follows: 868 0 1 2 3 869 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 870 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 871 | Type | Length | Reserved | Prefix Length | 872 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 873 | | 874 + + 875 | | 876 + Anchored Prefix + 877 | | 878 + + 879 | | 880 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 882 Type 884 IANA-1. 886 Length 888 8-bit unsigned integer indicating the length of the option in 889 octets, excluding the type and length fields. This field MUST be 890 set to 18. 892 Reserved 894 This field is unused for now. The value MUST be initialized to 0 895 by the sender and MUST be ignored by the receiver. 897 Prefix Length 899 8-bit unsigned integer indicating the prefix length in bits of the 900 IPv6 prefix contained in the option. 902 Anchored Prefix 904 A sixteen-octet field containing the mobile node's IPv6 Anchored 905 Prefix. Only the first Prefix Length bits are valid for the 906 Anchored Prefix. The rest of the bits MUST be ignored. 908 4.4. Local Prefix Option 910 A new Local Prefix option is defined for use with the Proxy Binding 911 Update and Proxy Binding Acknowledgment messages exchanged between 912 MAARs or between a MAAR and a CMD. Therefore, this option can only 913 appear if the D bit is set in a PBU/PBA. This option is used for 914 exchanging a prefix of a local network that is only reachable via the 915 anchoring MAAR. There can be multiple Local Prefix options present 916 in the message. 918 The Local Prefix Option has an alignment requirement of 8n+4. Its 919 format is as follows: 921 0 1 2 3 922 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 923 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 924 | Type | Length | Reserved | Prefix Length | 925 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 926 | | 927 + + 928 | | 929 + Local Prefix + 930 | | 931 + + 932 | | 933 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 935 Type 937 IANA-2. 939 Length 941 8-bit unsigned integer indicating the length of the option in 942 octets, excluding the type and length fields. This field MUST be 943 set to 18. 945 Reserved 947 This field is unused for now. The value MUST be initialized to 0 948 by the sender and MUST be ignored by the receiver. 950 Prefix Length 952 8-bit unsigned integer indicating the prefix length in bits of the 953 IPv6 prefix contained in the option. 955 Local Prefix 956 A sixteen-octet field containing the IPv6 Local Prefix. Only the 957 first Prefix Length bits are valid for the IPv6 Local Prefix. The 958 rest of the bits MUST be ignored. 960 4.5. Previous MAAR Option 962 This new option is defined for use with the Proxy Binding 963 Acknowledgement messages exchanged by the CMD to a MAAR. This option 964 is used to notify the S-MAAR about the previous MAAR's global address 965 and the prefix anchored to it. There can be multiple Previous MAAR 966 options present in the message. Its format is as follows: 968 The Previous MAAR Option has an alignment requirement of 8n+4. Its 969 format is as follows: 971 0 1 2 3 972 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 973 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 974 | Type | Length | Reserved | Prefix Length | 975 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 976 | | 977 + + 978 | | 979 + P-MAAR's address + 980 | | 981 + + 982 | | 983 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 984 | | 985 + + 986 | | 987 + Home Network Prefix + 988 | | 989 + + 990 | | 991 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 993 Type 995 IANA-3. 997 Length 999 8-bit unsigned integer indicating the length of the option in 1000 octets, excluding the type and length fields. This field MUST be 1001 set to 34. 1003 Reserved 1004 This field is unused for now. The value MUST be initialized to 0 1005 by the sender and MUST be ignored by the receiver. 1007 Prefix Length 1009 8-bit unsigned integer indicating the prefix length in bits of the 1010 IPv6 prefix contained in the option. 1012 Previous MAAR's address 1014 A sixteen-octet field containing the P-MAAR's IPv6 global address. 1016 Home Network Prefix 1018 A sixteen-octet field containing the mobile node's IPv6 Home 1019 Network Prefix. Only the first Prefix Length bits are valid for 1020 the mobile node's IPv6 Home Network Prefix. The rest of the bits 1021 MUST be ignored. 1023 4.6. Serving MAAR Option 1025 This new option is defined for use with the Proxy Binding Update 1026 message exchanged between the CMD and a Previous MAAR. This option 1027 is used to notify the P-MAAR about the current Serving MAAR's global 1028 address. Its format is as follows: 1030 The Serving MAAR Option has an alignment requirement of 8n+6. Its 1031 format is as follows: 1033 0 1 2 3 1034 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 1035 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1036 | Type | Length | 1037 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1038 | | 1039 + + 1040 | | 1041 + S-MAAR's address + 1042 | | 1043 + + 1044 | | 1045 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1047 Type 1049 IANA-4. 1051 Length 1053 8-bit unsigned integer indicating the length of the option in 1054 octets, excluding the type and length fields. This field MUST be 1055 set to 16. 1057 Serving MAAR's address 1059 A sixteen-octet field containing the S-MAAR's IPv6 global address. 1061 4.7. DLIF Link-local Address Option 1063 A new DLIF Link-local Address option is defined for use with the 1064 Proxy Binding Acknowledgment message exchanged between MAARs and 1065 between a MAAR and a CMD. This option is used for exchanging the 1066 link-local address of the DLIF to be configured on the serving MAAR 1067 so it resembles the DLIF configured on the P-MAAR. 1069 The DLIF Link-local Address option has an alignment requirement of 1070 8n+6. Its format is as follows: 1072 0 1 2 3 1073 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 1074 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1075 | Type | Length | 1076 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1077 | | 1078 + + 1079 | | 1080 + DLIF Link-local Address + 1081 | | 1082 + + 1083 | | 1084 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1086 Type 1088 IANA-5. 1090 Length 1092 8-bit unsigned integer indicating the length of the option in 1093 octets, excluding the type and length fields. This field MUST be 1094 set to 16. 1096 DLIF Link-local Address 1097 A sixteen-octet field containing the link-local address of the 1098 logical interface. 1100 4.8. DLIF Link-layer Address Option 1102 A new DLIF Link-layer Address option is defined for use with the 1103 Proxy Binding Acknowledgment message exchanged between MAARs and 1104 betwwe a MAAR and a CMD. This option is used for exchanging the 1105 link-layer address of the DLIF to be configured on the serving MAAR 1106 so it resembles the DLIF configured on the P-MAAR. 1108 The format of the DLIF Link-layer Address option is shown below. 1109 Based on the size of the address, the option MUST be aligned 1110 appropriately, as per mobility option alignment requirements 1111 specified in [RFC6275]. 1113 0 1 2 3 1114 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 1115 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1116 | Type | Length | Reserved | 1117 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1118 | | 1119 + DLIF Link-layer Address + 1120 . ... . 1121 | | 1122 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1124 Type 1126 IANA-6. 1128 Length 1130 8-bit unsigned integer indicating the length of the option in 1131 octets, excluding the type and length fields. 1133 Reserved 1135 This field is unused for now. The value MUST be initialized to 0 1136 by the sender and MUST be ignored by the receiver. 1138 DLIF Link-layer Address 1140 A variable length field containing the link-layer address of the 1141 logical interface to be configured on the S-MAAR. 1143 The content and format of this field (including octet and bit 1144 ordering) is as specified in Section 4.6 of [RFC4861] for carrying 1145 link-layer addresses. On certain access links, where the link- 1146 layer address is not used or cannot be determined, this option 1147 cannot be used. 1149 5. IANA Considerations 1151 This document defines six new mobility options, the Anchored Prefix 1152 Option, the Local Prefix Option, the Previous MAAR Option, the 1153 Serving MAAR Option, the DLIF Link-local Address Option and the DLIF 1154 Link-layer Address Option. The Type value for these options needs to 1155 be assigned from the same numbering space as allocated for the other 1156 mobility options in the "Mobility Options" registry defined in 1157 http://www.iana.org/assignments/mobility-parameters. The required 1158 IANA actions are marked as IANA-1 to IANA-6. 1160 This document reserves a new flag (D) in the "Binding Update Flags" 1161 and a new flag (D) in the "Binding Acknowledgment Flags" of the 1162 "Mobile IPv6 parameters" registry http://www.iana.org/assignments/ 1163 mobility-parameters. 1165 6. Security Considerations 1167 The protocol extensions defined in this document share the same 1168 security concerns of Proxy Mobile IPv6 [RFC5213]. It is recommended 1169 that the signaling messages, Proxy Binding Update and Proxy Binding 1170 Acknowledgment, exchanged between the MAARs are protected using IPsec 1171 using the established security association between them. This 1172 essentially eliminates the threats related to the impersonation of a 1173 MAAR. 1175 When the CMD acts as a PBU/PBA relay, the CMD may act as a relay of a 1176 single PBU to multiple previous MAARs. In situations of many fast 1177 handovers (e.g., with vehicular networks), there may exist multiple 1178 previous (e.g., k) MAARs. In this situation, the CMD creates k 1179 outgoing packets from a single incoming packet. This bears a certain 1180 amplification risk. The CMD MUST use a pacing approach in the 1181 outgoing queue to cap the output traffic (i.e., the rate of PBUs 1182 sent) to limit this amplification risk. 1184 When the CMD acts as MAAR locator, mobility signaling (PBAs) is 1185 exchanged between P-MAARs and current S-MAAR. Hence, security 1186 associations are REQUIRED to exist between the involved MAARs (in 1187 addition to the ones needed with the CMD). 1189 Since deregistration is performed by timeout, measures SHOULD be 1190 implemented to minimize the risks associated to continued resource 1191 consumption (DoS attacks), e.g., imposing a limit of the number of 1192 P-MAARs associated to a given MN. 1194 The CMD and the participating MAARs MUST be trusted parties, 1195 authorized perform all operations relevant to their role. 1197 There are some privacy considerations to consider. While the 1198 involved parties trust each other, the signalling involves disclosing 1199 information about the previous locations visited by each MN, as well 1200 as the active prefixes they are using at a given point of time. 1201 Therefore, mechanisms MUST be in place to ensure that MAARs and CMD 1202 do not disclose this information to other parties nor use it for 1203 other ends that providing the distributed mobility support specified 1204 in this document. 1206 7. Acknowledgments 1208 The authors would like to thank Dirk von Hugo, John Kaippallimalil, 1209 Ines Robles, Joerg Ott, Carlos Pignataro, Vincent Roca, Mirja 1210 Kuehlewind, Eric Vyncke, Adam Roach, Benjamin Kaduk and Roman Danyliw 1211 for the comments on this document. The authors would also like to 1212 thank Marco Liebsch, Dirk von Hugo, Alex Petrescu, Daniel Corujo, 1213 Akbar Rahman, Danny Moses, Xinpeng Wei and Satoru Matsushima for 1214 their comments and discussion on the documents 1215 [I-D.bernardos-dmm-distributed-anchoring] and 1216 [I-D.bernardos-dmm-pmip] on which the present document is based. 1218 The authors would also like to thank Lyle Bertz and Danny Moses for 1219 their in-deep review of this document and their very valuable 1220 comments and suggestions. 1222 8. References 1224 8.1. Normative References 1226 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1227 Requirement Levels", BCP 14, RFC 2119, 1228 DOI 10.17487/RFC2119, March 1997, 1229 . 1231 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 1232 More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191, 1233 November 2005, . 1235 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 1236 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 1237 DOI 10.17487/RFC4861, September 2007, 1238 . 1240 [RFC5213] Gundavelli, S., Ed., Leung, K., Devarapalli, V., 1241 Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", 1242 RFC 5213, DOI 10.17487/RFC5213, August 2008, 1243 . 1245 [RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility 1246 Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July 1247 2011, . 1249 [RFC7333] Chan, H., Ed., Liu, D., Seite, P., Yokota, H., and J. 1250 Korhonen, "Requirements for Distributed Mobility 1251 Management", RFC 7333, DOI 10.17487/RFC7333, August 2014, 1252 . 1254 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1255 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1256 May 2017, . 1258 8.2. Informative References 1260 [I-D.bernardos-dmm-distributed-anchoring] 1261 Bernardos, C. and J. Zuniga, "PMIPv6-based distributed 1262 anchoring", draft-bernardos-dmm-distributed-anchoring-09 1263 (work in progress), May 2017. 1265 [I-D.bernardos-dmm-pmip] 1266 Bernardos, C., Oliva, A., and F. Giust, "A PMIPv6-based 1267 solution for Distributed Mobility Management", draft- 1268 bernardos-dmm-pmip-09 (work in progress), September 2017. 1270 [RFC7429] Liu, D., Ed., Zuniga, JC., Ed., Seite, P., Chan, H., and 1271 CJ. Bernardos, "Distributed Mobility Management: Current 1272 Practices and Gap Analysis", RFC 7429, 1273 DOI 10.17487/RFC7429, January 2015, 1274 . 1276 [RFC8563] Katz, D., Ward, D., Pallagatti, S., Ed., and G. Mirsky, 1277 Ed., "Bidirectional Forwarding Detection (BFD) Multipoint 1278 Active Tails", RFC 8563, DOI 10.17487/RFC8563, April 2019, 1279 . 1281 Authors' Addresses 1282 Carlos J. Bernardos 1283 Universidad Carlos III de Madrid 1284 Av. Universidad, 30 1285 Leganes, Madrid 28911 1286 Spain 1288 Phone: +34 91624 6236 1289 Email: cjbc@it.uc3m.es 1290 URI: http://www.it.uc3m.es/cjbc/ 1292 Antonio de la Oliva 1293 Universidad Carlos III de Madrid 1294 Av. Universidad, 30 1295 Leganes, Madrid 28911 1296 Spain 1298 Phone: +34 91624 8803 1299 Email: aoliva@it.uc3m.es 1300 URI: http://www.it.uc3m.es/aoliva/ 1302 Fabio Giust 1303 Athonet S.r.l. 1305 Email: fabio.giust.2011@ieee.org 1307 Juan Carlos Zuniga 1308 SIGFOX 1309 425 rue Jean Rostand 1310 Labege 31670 1311 France 1313 Email: j.c.zuniga@ieee.org 1314 URI: http://www.sigfox.com/ 1316 Alain Mourad 1317 InterDigital Europe 1319 Email: Alain.Mourad@InterDigital.com 1320 URI: http://www.InterDigital.com/