idnits 2.17.1 draft-bernardos-dmm-distributed-anchoring-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 (September 9, 2015) is 3123 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-09) exists of draft-bernardos-dmm-pmip-04 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 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 UC3M 4 Intended status: Standards Track JC. Zuniga 5 Expires: March 12, 2016 InterDigital 6 September 9, 2015 8 PMIPv6-based distributed anchoring 9 draft-bernardos-dmm-distributed-anchoring-06 11 Abstract 13 Distributed Mobility Management solutions allow for setting up 14 networks so that traffic is distributed in an optimal way and does 15 not rely on centralized deployed anchors to provide IP mobility 16 support. 18 There are many different approaches to address Distributed Mobility 19 Management, as for example extending network-based mobility protocols 20 (like Proxy Mobile IPv6), or client-based mobility protocols (as 21 Mobile IPv6), among others. This document follows the former 22 approach, and proposes a solution based on Proxy Mobile IPv6 in which 23 mobility sessions are anchored at the last IP hop router (called 24 distributed gateway). The distributed gateway is an enhanced access 25 router which is also able to operate as local mobility anchor or 26 mobility access gateway, on a per prefix basis. The draft focuses on 27 the required extensions to effectively support simultaneously 28 anchoring several flows at different distributed gateways. 30 This draft introduces the concept of distributed logical interface 31 (at the distributed gateway), which is a software construct that 32 allows to easily hide the change of anchor from the mobile node. 33 Additionally, the draft describes how to provide session continuity 34 in inter-domain scenarios in which dynamic tunneling or signaling 35 between distributed gateways from different operators is not allowed. 37 Requirements Language 39 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 40 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 41 document are to be interpreted as described in RFC 2119 [RFC2119]. 43 Status of This Memo 45 This Internet-Draft is submitted in full conformance with the 46 provisions of BCP 78 and BCP 79. 48 Internet-Drafts are working documents of the Internet Engineering 49 Task Force (IETF). Note that other groups may also distribute 50 working documents as Internet-Drafts. The list of current Internet- 51 Drafts is at http://datatracker.ietf.org/drafts/current/. 53 Internet-Drafts are draft documents valid for a maximum of six months 54 and may be updated, replaced, or obsoleted by other documents at any 55 time. It is inappropriate to use Internet-Drafts as reference 56 material or to cite them other than as "work in progress." 58 This Internet-Draft will expire on March 12, 2016. 60 Copyright Notice 62 Copyright (c) 2015 IETF Trust and the persons identified as the 63 document authors. All rights reserved. 65 This document is subject to BCP 78 and the IETF Trust's Legal 66 Provisions Relating to IETF Documents 67 (http://trustee.ietf.org/license-info) in effect on the date of 68 publication of this document. Please review these documents 69 carefully, as they describe your rights and restrictions with respect 70 to this document. Code Components extracted from this document must 71 include Simplified BSD License text as described in Section 4.e of 72 the Trust Legal Provisions and are provided without warranty as 73 described in the Simplified BSD License. 75 Table of Contents 77 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 78 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 79 3. Solution's overview . . . . . . . . . . . . . . . . . . . . . 5 80 4. Simultaneous anchoring of multiple flows (single operator) . 7 81 4.1. The Distributed Logical Interface (DLIF) concept . . . . 7 82 4.2. D-GW protocol operation . . . . . . . . . . . . . . . . . 10 83 4.3. Message format . . . . . . . . . . . . . . . . . . . . . 14 84 4.3.1. Proxy Binding Update . . . . . . . . . . . . . . . . 14 85 4.3.2. Proxy Binding Acknowledgment . . . . . . . . . . . . 14 86 4.3.3. Anchored Prefix Option . . . . . . . . . . . . . . . 15 87 4.3.4. Local Prefix Option . . . . . . . . . . . . . . . . . 16 88 4.3.5. DLIF Link-local Address Option . . . . . . . . . . . 17 89 4.3.6. DLIF Link-layer Address Option . . . . . . . . . . . 18 90 5. Simultaneous anchoring of multiple flows (multiple operators) 19 91 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 92 7. Security Considerations . . . . . . . . . . . . . . . . . . . 21 93 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 94 8.1. Normative References . . . . . . . . . . . . . . . . . . 21 95 8.2. Informative References . . . . . . . . . . . . . . . . . 22 97 Appendix A. Comparison with Requirement document . . . . . . . . 22 98 A.1. Distributed mobility management . . . . . . . . . . . . . 22 99 A.2. Bypassable network-layer mobility support for 100 each application session . . . . . . . . . . . 23 101 A.3. IPv6 deployment . . . . . . . . . . . . . . . . . . . . . 23 102 A.4. Existing mobility protocols . . . . . . . . . . . . . . . 23 103 A.5. Coexistence with deployed networks/hosts and operability 104 across different networks . . . . . . . . . . . . . . . . 24 105 A.6. Operation and management considerations . . . . . . . . . 24 106 A.7. Security considerations . . . . . . . . . . . . . . . . . 24 107 A.8. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 24 108 Appendix B. Implementation experience . . . . . . . . . . . . . 25 109 Appendix C. Public demonstrations . . . . . . . . . . . . . . . 26 110 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 112 1. Introduction 114 The Distributed Mobility Management (DMM) paradigm aims at minimizing 115 the impact of currently standardized mobility management solutions, 116 which are centralized (at least to a considerable extent). 118 Centralized mobility solutions, such as Mobile IPv6 or the different 119 macro-level mobility management solutions of 3GPP EPS, base their 120 operation on the existence of a central entity (e.g., HA, LMA, PGW or 121 GGSN) that anchors the IP address used by the mobile node and is in 122 charge of coordinating the mobility management (MM) (sometimes helped 123 by a third entity like the MME or the HSS). This central anchor 124 point is in charge of tracking the location of the mobile and 125 redirecting its traffic towards its current topological location. 126 While this way of addressing mobility management has been fully 127 developed by the Mobile IP protocol family and its many extensions, 128 there are also several limitations that have been identified 129 [RFC7333]. Among them, we can just highlight sub-optimal routing, 130 scalability problems (in the network and in the centralized anchor) 131 and reliability [RFC7333]. 133 Several DMM-based approaches are being proposed and explored now 134 [RFC7429], [commag.dmm-standards]. One of them is based on extending 135 network-based mobility protocols (such as Proxy Mobile IPv6 [RFC5213] 136 or GTP) to operate in distributed fashion. This document proposes a 137 solution that falls in this category, defining a new logical entity, 138 called Distributed Gateway (D-GW) which basically encompasses the 139 functionalities of plain IPv6 access router, MAG and LMA, on a per- 140 IPv6 prefix basis. The main contribution of this draft is the 141 definition of the mechanisms required to support the operation of 142 such a network-based mobility solution when several flows are 143 simultaneously anchored at different D-GWs, by introducing the 144 concept of Distributed Logical Interface (DLIF). The document also 145 defines the required PMIPv6 signaling extensions. Last, but not 146 least, the solution is also extended to provide session continuity 147 across different domains. 149 2. Terminology 151 The following terms used in this document are defined in the Proxy 152 Mobile IPv6 specification [RFC5213]: 154 Local Mobility Anchor (LMA) 156 Mobile Access Gateway (MAG) 158 Mobile Node (MN) 160 Binding Cache Entry (BCE) 162 Proxy Care-of Address (P-CoA) 164 Proxy Binding Update (PBU) 166 Proxy Binding Acknowledgment (PBA) 168 The following terms are defined and/or used in this document: 170 D-GW (Distributed Gateway). First IP hop router used by the mobile 171 node. It provides an IPv6 prefix (topologically anchored at the 172 D-GW) to each attaching mobile node. 174 Anchoring D-GW. A previously visited D-GW anchoring an IPv6 prefix 175 which is still used by a mobile node. 177 Serving D-GW. The D-GW the MN is currently attached to. 179 DLIF (Distributed Logical Interface). It is a logical interface at 180 the IP stack of the D-GW. For each active prefix used by the 181 mobile node, the serving D-GW has a DLIF configured (associated to 182 the anchoring D-GW). In this way, a serving D-GW exposes itself 183 towards each MN as multiple routers, one per active anchoring 184 D-GW. 186 HSS (Home Subscriber Server). In a 3GPP architecture, it is the 187 master user database that contains the subscription-related 188 information (subscriber profiles), performs authentication and 189 authorization of the user, and can provide information about the 190 subscriber's location and IP information. 192 3. Solution's overview 194 A new logical network entity, called Distributed Gateway (D-GW) is 195 introduced at the edge of the network, close to the MN. It 196 implements the functionality of a plain IPv6 access router (AR), a 197 mobile access gateway (MAG) and a local mobility anchor (LMA), on a 198 per-MN and per-IPv6-prefix, as described later. 200 The solution basically extends Proxy Mobile IPv6 [RFC5213] to behave 201 in a distributed fashion, similarly as what has been proposed in 202 [I-D.seite-dmm-dma] and [I-D.bernardos-dmm-pmip]. This is achieved 203 by the D-GW logically behaving as a distributed mobility anchor, 204 which comprises the following: 206 o When a mobile node attaches to a D-GW (initial attachment or 207 handover), the D-GW provides an IPv6 prefix to the MN, acting as a 208 regular IPv6 router (with the only difference that the delegated 209 prefix is only assigned to one single MN, not being shared with 210 any other node). The D-GW that the mobile node is currently 211 attached to is called "serving D-GW". 213 o When a mobile node performs a handover, it attaches to a new D-GW 214 and configures a new IPv6 address out of the prefix provided and 215 anchored by the new serving D-GW. As before, the serving D-GW 216 behaves as a plain IPv6 router for that particular MN and the 217 delegated (locally anchored) prefix. If the MN has active traffic 218 using addresses anchored by other D-GWs (which are called 219 "anchoring D-GWs") or it just needs to keep the reachability of 220 these addresses, the current serving D-GW also acts as MAG, by 221 sending the required proxy binding update (PBU) to the 222 corresponding anchoring D-GWs. The anchoring D-GWs therefore 223 behave as LMA for this particular MN and the IPv6 prefixes they 224 are anchoring, replying with a PBA. 226 o Once the PBU/PBA signaling is completed, a bidirectional tunnel is 227 established between the serving D-GW and the anchoring D-GW (one 228 per D-GW anchoring an active prefix used by the MN). These 229 tunnels are used to provide IP address continuity to prefixes that 230 are not anchored at the serving D-GW. 232 o The means for a serving D-GW to obtain the information about the 233 prefixes that a locally attached mobile node wants to keep 234 reachable, and the associated anchoring D-GWs are out of the scope 235 of this draft. Among the possible mechanisms that can be used to 236 let the D-GW know about the prefixes that should be kept 237 reachable, we can cite for instance layer-2 triggers/signaling. 238 Regarding the mapping of IPv6 prefixes to anchoring D-GWs, there 239 might be either fully distributed mechanisms in place, or the 240 information can be maintained in a centralized repository (e.g., 241 in the HSS, using a centralized LMA [I-D.bernardos-dmm-pmip], 242 etc.). 244 The basic operation of the solution is shown with an example in 245 Figure 1. MN1 attaches to D-GW1 (thus becoming its serving D-GW) and 246 configures an IPv6 address (prefA::MN1) out of a prefix locally 247 anchored at D-GW1 (prefA::/64). At this point, MN1 can communicate 248 with any correspondent node of the Internet, being the traffic 249 anchored at D-GW1. If later on MN1 moves to D-GW2, a new IPv6 250 address (PrefB::MN1) is configured by the mobile node, this time out 251 of prefB::/64, which is anchored at D-GW2 (which becomes the new 252 serving D-GW). D-GW2 also exchanges the required PBU/PBA signaling 253 to ensure that data traffic using prefA::MN1 still reaches the mobile 254 node, by setting up a bidirectional tunnel between D-GW1 (anchoring 255 D-GW) and D-GW2 (serving D-GW). 257 +-----+ +-------+ +-------+ +-------------+ 258 | MN1 | | D-GW1 | | D-GW2 | | CN@Internet | 259 +-----+ +-------+ +-------+ +-------------+ 260 | | | | 261 | attachment | | | 262 |<...........>| | | 263 | prefA::/64 | | | 264 |<------------| | | 265 configures | | | | 266 prefA::MN1 | | | | 267 | (traffic using prefA::MN1) | 268 |<------------|------------------------------->| 269 | | | | 270 | handover | | 271 /............................/ | 272 | | prefB::/64 | | 273 |<---------------------------| | 274 configures | | PBU | | 275 prefB::MN1 | tunnel |<-------------| | 276 and keeps | set-up | PBA | | 277 using | |------------->| tunnel | 278 prefA::MN1 | | | set-up | 279 | (traffic using prefB::MN1) | 280 |<---------------------------|---------------->| 281 | (traffic using prefA::MN1) | 282 | |<------------------------------>| 283 | |<============>| | 284 |<-------------------------->| | 285 | | | | 287 Figure 1: Basic operation of the solution 289 The next sections of this draft focus on the detailed operation of 290 the D-GWs when a mobile node has multiple flows anchored at different 291 distributed gateways. 293 4. Simultaneous anchoring of multiple flows (single operator) 295 In this section we describe the mechanisms required in the network to 296 enable simultaneous anchoring of several flows at different D-GWs 297 within the same operator. 299 4.1. The Distributed Logical Interface (DLIF) concept 301 One of the main challenges of a network-based DMM solution is how to 302 allow a mobile node to simultaneously send/receive traffic which is 303 anchored at different D-GWs, and how to influence on the preference 304 of the mobile selecting the source IPv6 address for a new 305 communication, without requiring special support on the mobile node 306 stack. This document defines the Distributed Logical Interface 307 (DLIF), which is a software construct that allows to easily hide the 308 change of anchor from the mobile node. 310 +---------------------------------------------------+ 311 ( Operator's ) 312 ( core ) 313 +---------------------------------------------------+ 314 | | 315 +---------------+ tunnel +---------------+ 316 | IP stack |===============| IP stack | 317 +---------------+ +-------+-------+ 318 | mn1dgw1 |--+ (DLIFs) +--|mn1dgw1|mn1dgw2|--+ 319 +---------------+ | | +-------+-------+ | 320 | phy interface | | | | phy interface | | 321 +---------------+ | | +---------------+ | 322 D-GW1 (o) (o) D-GW2 (o) 323 x x 324 x x 325 prefA::/64 x x prefB::/64 326 (AdvPrefLft=0) x x 327 (o) 328 | 329 +-----+ 330 prefA::MN1 | MN1 | prefB::MN1 331 (deprecated) +-----+ 333 Figure 2: DLIF: exposing multiple routers (one per active anchoring 334 D-GW) 336 The basic idea of the DLIF concept is the following. Each serving 337 D-GW exposes itself towards a given MN as multiple routers, one per 338 active anchoring D-GW associated to the MN. Let's consider the 339 example shown in Figure 2, MN1 initially attaches to D-GW1, 340 configuring an IPv6 address (prefA::MN1) from a prefix locally 341 anchored at D-GW1 (prefA::/64). At this stage, D-GW1 plays both the 342 role of anchoring and serving D-GW, and also it behaves as a plain 343 IPv6 access router. D-GW1 creates a distributed logical interface to 344 communicate (point-to-point link) with MN1, exposing itself as a 345 (logical) router with a specific MAC (e.g., 00:11:22:33:01:01) and 346 IPv6 addresses (e.g., prefA::DGW1/64 and fe80:211:22ff:fe33:101/64) 347 using the DLIF mn1dgw1. As explained below, these addresses 348 represent the "logical" identity of D-GW1 towards MN1, and will 349 "follow" the mobile node while roaming within the domain (note that 350 the place where all this information is maintained and updated is 351 out-of-scope of this draft; potential examples are to keep it on the 352 HSS or the user's profile). 354 If MN1 moves and attaches to a different D-GW of the domain (D-GW2 in 355 the example of Figure 2), this D-GW will create a new logical 356 interface (mn1dgw2) to expose itself towards MN1, providing it with a 357 locally anchored prefix (prefB::/64). In this case, since the MN1 358 has another active IPv6 address anchored at a D-GW1, D-GW2 also needs 359 to create an additional logical interface configured to exactly 360 resemble the one used by D-GW1 to communicate with MN1. In this 361 example, there is only one active anchoring D-GW (in addition to 362 D-GW2, which is the serving one): D-GW1, so only the logical 363 interface mn1dgw1 is created, but the same process would be repeated 364 in case there were more active anchoring D-GWs involved. In order to 365 maintain the prefix anchored at D-GW1 reachable, a tunnel between 366 D-GW1 and D-GW2 is established and the routing is modified 367 accordingly. The PBU/PBA signaling is used to set-up the bi- 368 directional tunnel between D-GW1 and D-GW2, and it might also be used 369 to convey to D-GW2 the information about the prefix(es) anchored at 370 D-GW1 and about the addresses of the associated DLIF (i.e., mn1dgw1). 372 +------------------------------------------+ +----------------------+ 373 | D-GW1 | | D-GW2 | 374 |+----------------------------------------+| |+--------------------+| 375 ||+------------------++------------------+|| ||+------------------+|| 376 |||+-------++-------+||+-------++-------+||| |||+-------++-------+||| 377 ||||mn3dgw1||mn3dgw2||||mn2dgw1||mn2dgw2|||| ||||mn1dgw1||mn1dgw2|||| 378 |||| LMAC1 || LMAC2 |||| LMAC3 || LMAC4 |||| |||| LMAC5 || LMAC6 |||| 379 |||+-------++-------+||+-------++-------+||| |||+-------++-------+||| 380 ||| LIFs of MN3 || LIFs of MN2 ||| ||| LIFs of MN1 ||| 381 ||+------------------++------------------+|| ||+------------------+|| 382 || HMAC1 (phy if D-GW1) || ||HMAC2 (phy if D-GW2)|| 383 |+----------------------------------------+| |+--------------------+| 384 +------------------------------------------+ +----------------------+ 385 x x x 386 x x x 387 (o) (o) (o) 388 | | | 389 +--+--+ +--+--+ +--+--+ 390 | MN3 | | MN2 | | MN1 | 391 +-----+ +-----+ +-----+ 393 Figure 3: Distributed Logical Interface concept 395 Figure 3 shows the logical interface concept in more detail. The 396 figure shows two D-GWs and three MNs. D-GW1 is currently serving MN2 397 and MN3, while D-GW2 is serving MN1. MN1, MN2 and MN3 have two 398 active anchoring D-GWs: D-GW1 and D-GW2. Note that a serving D-GW 399 always plays the role of anchoring D-GW for the attached (served) 400 MNs. Each D-GW has one single physical wireless interface. 402 As introduced before, each MN always "sees" multiple logical routers 403 -- one per active anchoring D-GW -- independently of to which serving 404 D-GW the MN is currently attached. From the point of view of the MN, 405 these D-GWs are portrayed as different routers, although the MN is 406 physically attached to one single interface . The way this is 407 achieved is by the serving D-GW configuring different logical 408 interfaces. If we focus on MN1, it is currently attached to D-GW2 409 (i.e., D-GW2 is its serving D-GW) and, therefore, it has configured 410 an IPv6 address from D-GW2's pool (e.g., prefB::/64). D-GW2 has set- 411 up a logical interface (mn1dgw2) on top of its wireless physical 412 interface (phy if D-GW2) which is used to serve MN1. This interface 413 has a logical MAC address (LMAC6), different from the hardware MAC 414 address (HMAC2) of the physical interface of D-GW2. Over the mn1dgw2 415 interface, D-GW2 advertises its locally anchored prefix prefB::/64. 416 Before attaching to D-GW2, MN1 visited D-GW1, configuring also an 417 address locally anchored at this D-GW, which is still being used by 418 the MN1 in active communications. MN1 keeps "seeing" an interface 419 connecting to D-GW1, as if it were directly connected to the two 420 D-GWs. This is achieved by the serving D-GW (D-GW1) configuring an 421 additional distributed logical interface: mn1dgw1, which behaves 422 exactly as the logical interface configured by the actual D-GW1 when 423 MN1 was attached to it. This means that both the MAC and IPv6 424 addresses configured on this logical interface remain the same 425 regardless of the physical D-GW which is serving the MN. The 426 information required by a serving D-GW to properly configure this 427 logical interfaces can be obtained in different ways: as part of the 428 information conveyed in the PBA, from an external database (e.g., the 429 HSS) or by other means. As shown in the figure, each D-GW may have 430 several logical interfaces associated to each attached MN, having 431 always at least one (since a serving D-GW is also an anchoring D-GW 432 for the attached MN). 434 In order to enforce the use of the prefix locally anchored at the 435 serving D-GW, the router advertisements sent over those logical 436 interfaces playing the role of anchoring D-GWs (different from the 437 serving one) include a zero prefix lifetime. The goal is to 438 deprecate the prefixes delegated by these D-GWs (which will be no 439 longer serving the MN). Note that on-going communications keep on 440 using those addresses, even if they are deprecated, so this only 441 affects to new sessions. 443 The distributed logical interface concept also enables the following 444 use case. Suppose that access to a local IP network is provided by a 445 given D-GW (e.g., D-GW1 in the example shown in Figure 2) and that 446 the resources available at that network cannot be reached from 447 outside the local network (e.g., cannot be accessed by an MN attached 448 to D-GW2). This is similar to the LIPA scenario currently being 449 consider by 3GPP. The goal is to allow an MN to be able to roam 450 while still being able to have connectivity to this local IP network. 451 The solution adopted to support this case makes use of RFC 4191 452 [RFC4191] more specific routes when the MN moves to a D-GW different 453 from the one providing access to the local IP network (D-GW1 in the 454 example). These routes are advertised through the distributed 455 logical interface representing the D-GW providing access to the local 456 network (D-GW1 in this example). In this way, if MN1 moves from 457 D-GW1 to D-GW2, any active session that MN1 may have with a node of 458 the local network connected to D-GW1 will survive, being the traffic 459 forwarded via the tunnel between D-GW1 and D-GW2. Also, any 460 potential future connection attempt towards the local network will be 461 supported, even though MN1 is no longer attached to D-GW1. 463 4.2. D-GW protocol operation 465 This section describes the D-GW operation in more detail. 467 Figure 4 shows an example of the D-GW operation: 469 1. MN1 attaches to D-GW1. This event is detected by D-GW1 (based on 470 layer 2 signaling/triggers or the reception of a Router 471 Solicitation sent by MN1). 473 2. An IPv6 prefix from the pool of locally anchored prefixes is 474 selected by D-GW1 to be delegated to MN1 (prefA::/64). D-GW1 475 sets up a distributed logical interface aimed at interfacing with 476 MN1, called mn1dgw1. D-GW1 starts sending router advertisements 477 to MN1, including the delegated prefix. 479 3. D-GW1 learns if it is an attachment due to a handover (how this 480 is done is out-of-scope of this draft). In this case it is an 481 initial attachment, so nothing else is required. 483 4. The DLIF mn1dgw1 is used by D-GW1 to advertise the locally 484 anchored prefix (prefA::/64) to MN1. Using this prefix, MN1 485 configures an IPv6 address (prefA::MN1/64) that can be used to 486 start new sessions (which will be anchored at D-GW1). Traffic 487 using the address prefA::MN1 is received at the interface mn1dgw1 488 and directly forwarded by D-GW1 towards its destination. Traffic 489 between MN1 and the local network reachable via D-GW1 (localnet) 490 is handled normally by D-GW1 (as MN1 is locally attached). 492 5. MN1 performs a handover to D-GW2. This event is detected by 493 D-GW2. 495 6. An IPv6 prefix from the pool of locally anchored prefixes is 496 selected by D-GW2 to be delegated to MN1 (prefB::/64). D-GW2 497 sets up a distributed logical interface aimed at interfacing with 498 MN1, called mn1dgw2. D-GW2 starts sending router advertisements 499 to MN1, including the delegated prefix. Traffic using the 500 address prefB::MN1 is received at the interface mn1dgw2 and 501 directly forwarded by D-GW2 towards its destination. 503 7. D-GW2 learns that this is a handover of MN1, and that it 504 previously visited D-GW1. D-GW2 sends a PBU to D-GW1, which 505 replies with a PBA. This PBA MAY include information about the 506 prefix(es) anchored at D-GW1, the parameters needed by D-GW2 to 507 set-up the DLIF mn1dgw1, and the prefixes of local networks 508 reachable via D-GW (if any). Alternatively, this information MAY 509 be obtained using a different approach (such as storing it in the 510 HSS or some other external repository). A bi-directional tunnel 511 between D-GW1 and D-GW2 is set-up, as well as the required 512 routing entries. 514 8. D-GW2 sets up the DLIF mn1dgw1, aimed at "logically" resembling 515 D-GW1, so MN1 does not detect any change at layer-3. D-GW2 516 starts sending router advertisements to MN1 through mn1dgw2, 517 which include the prefix anchored at D-GW1 (prefA::/64) with zero 518 lifetime to deprecate the prefix (or alternatively it MAY include 519 a low Default Router Preference [RFC4191] if communication to 520 this D-GW is still needed in the future). In this way, 521 prefA::MN1 is not preferred for new communications. The RAs MAY 522 also include a Route Information Option (RIO) [RFC4191] with the 523 prefix of localnet, which is the network that is only locally 524 reachable via D-GW1 (e.g., as in the LIPA scenarios considered by 525 the 3GPP), so MN1 picks D-GW1 (the "logical" version of it 526 portrayed by D-GW2) when sending traffic to that network , 527 including the delegated prefix. Traffic using the address 528 prefA::MN1 is received at the interface mn1dgw1 and forwarded via 529 the tunnel with D-GW1, which then forwards it towards its 530 destination. Traffic between MN1 and the network locally 531 reachable via D-GW1 (localnet) is also handled via mn1dgw1 and 532 sent through the tunnel. 534 +-----+ +-------+ +-------+ +-------------+ 535 | MN1 | | D-GW1 | | D-GW2 | | CN@Internet | 536 +-----+ +-------+ +-------+ +-------------+ 537 | | | | 538 | attachment | | | 539 |<...........>|set-up of new | | 540 | RA@mn1dgw1 |DLIF: mn1dgw1 | | 541 |<------------| | | 542 configures | (prefA::/64)| | | 543 prefA::MN1 | | | | 544 | (traffic using prefA::MN1) | 545 |<------------|------------------------------->| 546 | (traffic with local net) | | 547 |<----------->|<----> | | 548 | | | | 549 | handover | | 550 /............................/set-up of new | 551 | | RA@mn1dwg2 |DLIF: mn1dgw2 | 552 configures |<---------------------------| | 553 prefB::MN1 | | (prefB::/64)| | 554 and keeps | | PBU | | 555 using | tunnel |<-------------| | 556 prefA::MN1 | set-up | PBA(mn1dgw1, | | 557 | | prefA::/64, | | 558 | | preflocalnet)| | 559 | |------------->|set-up of tunnel | 560 | | RA@mn1dgw1 | & DLIF mn1dgw1 | 561 |<---------------------------| | 562 | | (prefA::/64, lft=0, | 563 | | RIO: preflocalnet) | 564 | | | | 565 | (traffic using prefB::MN1) | 566 |<-------------------------->|<--------------->| 567 | | | | 568 | (traffic using prefA::MN1) | 569 |<-------------------------->| | 570 | |<============>| | 571 | |<------------------------------>| 572 | | | | 573 | (traffic with local net) | | 574 |<-------------------------->| | 575 | |<============>| | 576 | |<---> | | 577 | | | | 579 Figure 4: D-GW protocol operation 581 4.3. Message format 583 This section defines extensions to the Proxy Mobile IPv6 [RFC5213] 584 protocol messages. 586 4.3.1. Proxy Binding Update 588 A new flag (D) is included in the Proxy Binding Update to indicate 589 that the Proxy Binding Update is coming from a Distributed Gateway 590 and not from a mobile access gateway. The rest of the Proxy Binding 591 Update format remains the same as defined in [RFC5213]. 593 0 1 2 3 594 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 595 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 596 | Sequence # | 597 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 598 |A|H|L|K|M|R|P|D| Reserved | Lifetime | 599 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 600 | | 601 . . 602 . Mobility options . 603 . . 605 | | 606 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 608 Distributed Gateway Flag (D) 610 The Distributed Gateway Flag is set to indicate to the receiver of 611 the message that the Proxy Binding Update is from a Distributed 612 Gateway. 614 Mobility Options 616 Variable-length field of such length that the complete Mobility 617 Header is an integer multiple of 8 octets long. This field 618 contains zero or more TLV-encoded mobility options. The encoding 619 and format of defined options are described in Section 6.2 of 620 [RFC6275]. The distributed gateway MUST ignore and skip any 621 options that it does not understand. 623 4.3.2. Proxy Binding Acknowledgment 625 A new flag (D) is included in the Proxy Binding Acknowledgment to 626 indicate that the sender supports operating as a distributed gateway. 627 The rest of the Proxy Binding Acknowledgment format remains the same 628 as defined in [RFC5213]. 630 0 1 2 3 631 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 632 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 633 | Status |K|R|P|D| Reser | 634 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 635 | Sequence # | Lifetime | 636 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 637 | | 638 . . 639 . Mobility options . 640 . . 641 | | 642 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 644 Distributed Gateway Flag (D) 646 The Distributed Gateway Flag is set to indicate that the sender of 647 the message supports operating as a distributed gateway. 649 Mobility Options 651 Variable-length field of such length that the complete Mobility 652 Header is an integer multiple of 8 octets long. This field 653 contains zero or more TLV-encoded mobility options. The encoding 654 and format of defined options are described in Section 6.2 of 655 [RFC6275]. The distributed gateway MUST ignore and skip any 656 options that it does not understand. 658 4.3.3. Anchored Prefix Option 660 A new Anchored Prefix option is defined for use with the Proxy 661 Binding Update and Proxy Binding Acknowledgment messages exchanged 662 between distributed gateways. This option is used for exchanging the 663 mobile node's prefix anchored at the anchoring D-GW. There can be 664 multiple Anchored Prefix options present in the message. 666 The Anchored Prefix Option has an alignment requirement of 8n+4. Its 667 format is as follows: 669 0 1 2 3 670 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 671 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 672 | Type | Length | Reserved | Prefix Length | 673 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 674 | | 675 + + 676 | | 677 + Anchored Prefix + 678 | | 679 + + 680 | | 681 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 683 Type 685 To be assigned by IANA. 687 Length 689 8-bit unsigned integer indicating the length of the option in 690 octets, excluding the type and length fields. This field MUST be 691 set to 18. 693 Reserved 695 This field is unused for now. The value MUST be initialized to 0 696 by the sender and MUST be ignored by the receiver. 698 Prefix Length 700 8-bit unsigned integer indicating the prefix length of the IPv6 701 prefix contained in the option. 703 Anchored Prefix 705 A sixteen-byte field containing the mobile node's IPv6 Anchored 706 Prefix. 708 4.3.4. Local Prefix Option 710 A new Local Prefix option is defined for use with the Proxy Binding 711 Update and Proxy Binding Acknowledgment messages exchanged between 712 distributed gateways. This option is used for exchanging a prefix of 713 a local network that is only reachable via the anchoring D-GW. There 714 can be multiple Local Prefix options present in the message. 716 The Local Prefix Option has an alignment requirement of 8n+4. Its 717 format is as follows: 719 0 1 2 3 720 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 721 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 722 | Type | Length | Reserved | Prefix Length | 723 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 724 | | 725 + + 726 | | 727 + Local Prefix + 728 | | 729 + + 730 | | 731 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 733 Type 735 To be assigned by IANA. 737 Length 739 8-bit unsigned integer indicating the length of the option in 740 octets, excluding the type and length fields. This field MUST be 741 set to 18. 743 Reserved 745 This field is unused for now. The value MUST be initialized to 0 746 by the sender and MUST be ignored by the receiver. 748 Prefix Length 750 8-bit unsigned integer indicating the prefix length of the IPv6 751 prefix contained in the option. 753 Local Prefix 755 A sixteen-byte field containing the IPv6 Local Prefix. 757 4.3.5. DLIF Link-local Address Option 759 A new DLIF Link-local Address option is defined for use with the 760 Proxy Binding Update and Proxy Binding Acknowledgment messages 761 exchanged between distributed gateways. This option is used for 762 exchanging the link-local address of the DLIF to be configured on the 763 serving D-GW so it resembles the DLIF configured on the anchoring 764 D-GW. 766 The DLIF Link-local Address option has an alignment requirement of 767 8n+6. Its format is as follows: 769 0 1 2 3 770 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 771 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 772 | Type | Length | 773 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 774 | | 775 + + 776 | | 777 + DLIF Link-local Address + 778 | | 779 + + 780 | | 781 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 783 Type 785 To be assigned by IANA. 787 Length 789 8-bit unsigned integer indicating the length of the option in 790 octets, excluding the type and length fields. This field MUST be 791 set to 16. 793 DLIF Link-local Address 795 A sixteen-byte field containing the link-local address of the 796 logical interface. 798 4.3.6. DLIF Link-layer Address Option 800 A new DLIF Link-layer Address option is defined for use with the 801 Proxy Binding Update and Proxy Binding Acknowledgment messages 802 exchanged between distributed gateways. This option is used for 803 exchanging the link-layer address of the DLIF to be configured on the 804 serving D-GW so it resembles the DLIF configured on the anchoring 805 D-GW. 807 The format of the DLIF Link-layer Address option is shown below. 808 Based on the size of the address, the option MUST be aligned 809 appropriately, as per mobility option alignment requirements 810 specified in [RFC6275]. 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 | Type | Length | Reserved | 816 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 817 | | 818 + DLIF Link-layer Address + 819 . ... . 820 | | 821 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 823 Type 825 To be assigned by IANA. 827 Length 829 8-bit unsigned integer indicating the length of the option in 830 octets, excluding the type and length fields. 832 Reserved 834 This field is unused for now. The value MUST be initialized to 0 835 by the sender and MUST be ignored by the receiver. 837 DLIF Link-layer Address 839 A variable length field containing the link-layer address of the 840 logical interface to be configured on the serving distributed 841 gateway. 843 The content and format of this field (including byte and bit 844 ordering) is as specified in Section 4.6 of [RFC4861] for carrying 845 link-layer addresses. On certain access links, where the link- 846 layer address is not used or cannot be determined, this option 847 cannot be used. 849 5. Simultaneous anchoring of multiple flows (multiple operators) 851 An MN may roam between D-GWs that do not belong to the same operator, 852 and therefore might end up having multiple simultaneous flows, 853 anchored at different operators. Since dynamically setting up 854 tunnels between different operators (i.e., between D-GWs belonging to 855 different operators) is usually not supported, a solution should be 856 devised to ensure session continuity in this scenario, even if it is 857 at the cost of a sub-optimal routing. 859 In this section we describe the required extensions to support inter- 860 domain operation. The basic solution consists in using a centralized 861 LMA (usually located in the home domain) as top-level anchor to 862 guarantee session continuity when crossing operator borders. We 863 assume that the necessary roaming agreements are in place in order to 864 support setting up tunnels between the LMA located at the home domain 865 of the MN and the visited D-GWs. 867 +---------------------------------------------------+ 868 ( Home Operator's core ) 869 ( ) 870 ( +-----+ ) 871 ( /| LMA |\ ) 872 ( //+-----+\\ ) 873 ( // \\ ) 874 +------------------//-----------\\------------------+ 875 . (tunnel) // \\ (tunnel) . 876 . // \\ . 877 . // \\ . 878 . // \\ . 879 +---------------+ +---------------+ 880 | IP stack | | IP stack | 881 +---------------+ +-------+-------+ 882 | mn1dgw1 |--+ (DLIFs) +--|mn1dgw1|mn1dgw2|--+ 883 +---------------+ | | +-------+-------+ | 884 | phy interface | | | | phy interface | | 885 +---------------+ | | +---------------+ | 886 D-GW1@OperatorA (o) (o) D-GW2@OperatorB (o) 887 x x 888 x x 889 prefA::/64 x x prefB::/64 890 (AdvPrefLft=0) x x 891 (o) 892 | 893 +-----+ 894 prefA::MN1 | MN1 | prefB::MN1 895 (deprecated) +-----+ 897 Figure 5: Simultaneous anchoring of multiple flows across multiple 898 operators 900 Figure 5 shows an example of the inter-domain operation. MN1 901 initially attaches to D-GW1 (which belongs to OperatorA), and 902 configures prefA::MN1 address out of one prefix anchored at D-GW1 903 (prefA::/64). If MN1 moves to D-GW2, which is managed by OperatorB, 904 tunnels need to be established via the centralized LMA at the MN1's 905 operators core, since we assume that no direct tunneling is possible 906 between D-GWs belonging to different operators. In this case, D-GW3 907 establishes one tunnel with the centralized LMA to send/receive 908 traffic using prefA::/64. From the point of view of D-GW2, the 909 operation is just as if the LMA was the D-GW anchoring this prefix. 910 Analogously, the LMA establishes one tunnel with D-GW1 (from the 911 point of view of D-GW1, the LMA is the current serving D-GW of MN1). 912 Regarding the signaling, it is similar to the intra-operator 913 scenario, though in this case the PBU/PBA sequence is performed 914 twice, once between D-GW2 and the LMA, and another one between the 915 LMA and D-GW1 (i.e., because two different tunnels are created). 917 6. IANA Considerations 919 This document defines new mobility options that require IANA actions. 921 7. Security Considerations 923 The protocol extensions defined in this document share the same 924 security concerns of Proxy Mobile IPv6 [RFC5213]. It is recommended 925 that the signaling messages, Proxy Binding Update and Proxy Binding 926 Acknowledgment, exchanged between the distributed gateways, or 927 between a distributed gateway and a centralized local mobility 928 anchor, are protected using IPsec using the established security 929 association between them. This essentially eliminates the threats 930 related to the impersonation of a distributed gateway or the local 931 mobility anchor. 933 8. References 935 8.1. Normative References 937 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 938 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 939 RFC2119, March 1997, 940 . 942 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 943 More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191, 944 November 2005, . 946 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 947 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 948 DOI 10.17487/RFC4861, September 2007, 949 . 951 [RFC5213] Gundavelli, S., Ed., Leung, K., Devarapalli, V., 952 Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 953 5213, DOI 10.17487/RFC5213, August 2008, 954 . 956 [RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility 957 Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July 958 2011, . 960 8.2. Informative References 962 [I-D.bernardos-dmm-pmip] 963 Bernardos, C., Oliva, A., and F. Giust, "A PMIPv6-based 964 solution for Distributed Mobility Management", draft- 965 bernardos-dmm-pmip-04 (work in progress), March 2015. 967 [I-D.seite-dmm-dma] 968 Seite, P., Bertin, P., and J. Lee, "Distributed Mobility 969 Anchoring", draft-seite-dmm-dma-07 (work in progress), 970 February 2014. 972 [RFC7333] Chan, H., Ed., Liu, D., Seite, P., Yokota, H., and J. 973 Korhonen, "Requirements for Distributed Mobility 974 Management", RFC 7333, DOI 10.17487/RFC7333, August 2014, 975 . 977 [RFC7429] Liu, D., Ed., Zuniga, JC., Ed., Seite, P., Chan, H., and 978 CJ. Bernardos, "Distributed Mobility Management: Current 979 Practices and Gap Analysis", RFC 7429, DOI 10.17487/ 980 RFC7429, January 2015, 981 . 983 [commag.dmm-standards] 984 Zuniga, JC., Bernardos, CJ., de la Oliva, A., Melia, T., 985 Costa, R., and A. Reznik, "Distributed mobility 986 management: a standards landscape", IEEE Communications 987 Magazine Vol. 51, No. 3, March 2013. 989 Appendix A. Comparison with Requirement document 991 In this section we descrbe how our solution addresses the DMM 992 requirements listed in [RFC7333]. 994 A.1. Distributed mobility management 996 "IP mobility, network access solutions, and forwarding solutions 997 provided by DMM MUST enable traffic to avoid traversing a single 998 mobility anchor far from the optimal route." 1000 In our solution, the anchoring D-GW is responsible to handle the 1001 mobility for those IP flows started when the MN is attached to it. 1002 As long as the MN remains connected to the anchoring D-GW's access 1003 links, the IP packets of such flows can benefit from the optimal 1004 path. When the MN moves to another D-GW, the path becomes non- 1005 optimal for ongoing flows, but newly started IP sessions are 1006 forwarded by the serving D-GW through the optimal path. 1008 A.2. Bypassable network-layer mobility support for each application 1009 session 1011 "DMM solutions MUST enable network-layer mobility, but it MUST be 1012 possible for any individual active application session (flow) to not 1013 use it. Mobility support is needed, for example, when a mobile host 1014 moves and an application cannot cope with a change in the IP address. 1015 Mobility support is also needed when a mobile router changes its IP 1016 address as it moves together with a host and, in the presence of 1017 ingress filtering, an application in the host is interrupted. 1018 However, mobility support at the network layer is not always needed; 1019 a mobile node can often be stationary, and mobility support can also 1020 be provided at other layers. It is then not always necessary to 1021 maintain a stable IP address or prefix for an active application 1022 session." 1024 The solution operates at the IP layer, hence upper layers are totally 1025 transparent to the mobility operations. In particular, ongoing IP 1026 sessions are not disrupted after a change of access network. The 1027 routability of the old address is ensured by the IP tunnel with the 1028 anchoring D-GW. New IP sessions are started with the new address. 1029 From the application's perspective, those processes which sockets are 1030 bound to a unique IP address do not suffer any impact. For the other 1031 applications, the sockets bound to the old address are preserved, 1032 whereas next sockets use the new address. 1034 Additionally, the use of the DLIF makes easier to implement more 1035 complex policies regarding how traffic is forwarded at the D-GW. 1037 A.3. IPv6 deployment 1039 "DMM solutions SHOULD target IPv6 as the primary deployment 1040 environment and SHOULD NOT be tailored specifically to support IPv4, 1041 particularly in situations where private IPv4 addresses and/or NATs 1042 are used." 1044 The solution targets IPv6 only. 1046 A.4. Existing mobility protocols 1048 "A DMM solution MUST first consider reusing and extending IETF 1049 standard protocols before specifying new protocols." 1050 The is derived from the operations and messages specified in 1051 [RFC5213]. 1053 A.5. Coexistence with deployed networks/hosts and operability across 1054 different networks 1056 "A DMM solution may require loose, tight, or no integration into 1057 existing mobility protocols and host IP stacks. Regardless of the 1058 integration level, DMM implementations MUST be able to coexist with 1059 existing network deployments, end hosts, and routers that may or may 1060 not implement existing mobility protocols. Furthermore, a DMM 1061 solution SHOULD work across different networks, possibly operated as 1062 separate administrative domains, when the needed mobility management 1063 signaling, forwarding, and network access are allowed by the trust 1064 relationship between them." 1066 The solution can be extended to provide a fallback mechanism to 1067 operate as legacy Proxy Mobile IPv6. It is necessary to instruct 1068 D-GWs to always establish a tunnel with the same anchoring D-GW, 1069 working as LMA. 1071 A.6. Operation and management considerations 1073 "A DMM solution needs to consider configuring a device, monitoring 1074 the current operational state of a device, and responding to events 1075 that impact the device, possibly by modifying the configuration and 1076 storing the data in a format that can be analyzed later. 1078 The proposed solution can re-use existing mechanisms defined for the 1079 operation and management of Proxy Mobile IPv6. 1081 A.7. Security considerations 1083 "A DMM solution MUST support any security protocols and mechanisms 1084 needed to secure the network and to make continuous security 1085 improvements. In addition, with security taken into consideration 1086 early in the design, a DMM solution MUST NOT introduce new security 1087 risks or amplify existing security risks that cannot be mitigated by 1088 existing security protocols and mechanisms." 1090 The proposed solution does not specify a security mechanism, given 1091 that the same mechanism for PMIPv6 can be used. 1093 A.8. Multicast 1095 "DMM SHOULD enable multicast solutions to be developed to avoid 1096 network inefficiency in multicast traffic delivery." 1097 This solution in its current version does not specify any support for 1098 multicast traffic, which is left for study in future versions. 1100 Appendix B. Implementation experience 1102 The DLIF concept can be easily implemented using features that are 1103 usually available on several OSs. Among the possible mechanisms that 1104 can be used to do it, the Linux macvlan support allows the creation 1105 of different logical interfaces over the same physical one. Each 1106 logical interface appears as a regular interface to the Linux OS 1107 (which can be configured normally), and it supports configuring the 1108 MAC address exposed by the logical interface. The destination MAC 1109 address is used by the OS to decide which logical interface 1110 (configured on top of a physical interface) is in charge of 1111 processing an incoming L2 frame. 1113 The EU FP7 MEDIEVAL project implemented a prototype of the DLIF 1114 concept using the Linux macvlan support, the radvd daemon, the Linux 1115 Advanced Routing and Traffic Control features and the standard 1116 iproute2 collection of utilities: 1118 o The macvlan support enables iproute2 tools to be able to create, 1119 destroy and configure DLIFs on demand over a single physical 1120 interface. One of the important features that needs to be 1121 configured is the logical MAC address exposed by the DLIF, as well 1122 as the IPv6 addresses, as they should remain the same regardless 1123 of the serving D-GW where the DLIF is configured. 1125 o Since the distributed logical interfaces created using the macvlan 1126 support appear as regular network interfaces, they can be used 1127 normally in the radvd configuration file. Them, by dynamically 1128 modifying the radvd configuration file and reloading it, we can 1129 control the router advertisements sent to each MN (e.g., 1130 advertizing new IPv6 prefixes, deprecating prefixes anchored at 1131 other serving D-GWs, announcing RFC 4191 specific routes or 1132 changing router preferences). 1134 o Each time a DLIF is created, it is also needed to properly 1135 configure source-based IPv6 routes, as well as tunnels (in case of 1136 handover). This is supported by the Linux Advanced Routing and 1137 Traffic Control features. 1139 o Last, but not least, current Linux kernels support the 1140 configuration of RFC 4191 specific routes (by processing Route 1141 Information Options contained in RAs). The kernel support can be 1142 easily enabled by using the 1143 net.conf.ipv6.*.accept_ra_rt_info_max_plen kernel configuration 1144 parameter. 1146 The DLIF concept is implemented by the Open Distributed Mobility 1147 Management (ODMM) project (http://www.odmm.net/), as part of the 1148 Mobility Anchors Distribution for PMIPv6 (MAD-PMIPv6). The ODMM 1149 platform is intended to foster DMM development and deployment, by 1150 serving as a framework to host open source implementations. 1152 Appendix C. Public demonstrations 1154 The DLIF concept has been demonstrated, together with the network- 1155 based DMM solution described in [I-D.bernardos-dmm-pmip], during the 1156 83rd IETF in Paris (March 2012) and the 87th IETF in Berlin (August 1157 2013). 1159 The first demo showcased a scenario composed of three "anchor 1160 routers", a "centralized LMA" for control plane, a "mobile node" and 1161 two "correspondent nodes" (one of them being a legacy IPv6 camera). 1162 The mobile node could move between the different anchor routers, 1163 getting a different locally anchor IPv6 address at each location, and 1164 being the reachability of each address maintained. 1166 In the second demo, integration with content delivery nodes (CDNs) 1167 was also shown, showcasing the advantages that the use of a DMM 1168 solution brings to this popular scenario. 1170 Authors' Addresses 1172 Carlos J. Bernardos 1173 Universidad Carlos III de Madrid 1174 Av. Universidad, 30 1175 Leganes, Madrid 28911 1176 Spain 1178 Phone: +34 91624 6236 1179 Email: cjbc@it.uc3m.es 1180 URI: http://www.it.uc3m.es/cjbc/ 1182 Juan Carlos Zuniga 1183 InterDigital Communications, LLC 1184 1000 Sherbrooke Street West, 10th floor 1185 Montreal, Quebec H3A 3G4 1186 Canada 1188 Email: JuanCarlos.Zuniga@InterDigital.com 1189 URI: http://www.InterDigital.com/