idnits 2.17.1 draft-bernardos-dmm-distributed-anchoring-04.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 (May 15, 2014) is 3633 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-03 == Outdated reference: A later version (-09) exists of draft-ietf-dmm-best-practices-gap-analysis-03 == Outdated reference: A later version (-17) exists of draft-ietf-dmm-requirements-16 Summary: 0 errors (**), 0 flaws (~~), 4 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: November 16, 2014 InterDigital 6 May 15, 2014 8 PMIPv6-based distributed anchoring 9 draft-bernardos-dmm-distributed-anchoring-04 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 November 16, 2014. 60 Copyright Notice 62 Copyright (c) 2014 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 79 3. Solution's overview . . . . . . . . . . . . . . . . . . . . . 4 80 4. Simultaneous anchoring of multiple flows (single operator) . 6 81 4.1. The Distributed Logical Interface (DLIF) concept . . . . 7 82 4.2. D-GW protocol operation . . . . . . . . . . . . . . . . . 10 83 4.3. Message format . . . . . . . . . . . . . . . . . . . . . 13 84 4.3.1. Proxy Binding Update . . . . . . . . . . . . . . . . 13 85 4.3.2. Proxy Binding Acknowledgment . . . . . . . . . . . . 13 86 4.3.3. Anchored Prefix Option . . . . . . . . . . . . . . . 14 87 4.3.4. Local Prefix Option . . . . . . . . . . . . . . . . . 15 88 4.3.5. DLIF Link-local Address Option . . . . . . . . . . . 16 89 4.3.6. DLIF Link-layer Address Option . . . . . . . . . . . 17 90 5. Simultaneous anchoring of multiple flows (multiple operators) 18 91 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 92 7. Security Considerations . . . . . . . . . . . . . . . . . . . 20 93 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 94 8.1. Normative References . . . . . . . . . . . . . . . . . . 20 95 8.2. Informative References . . . . . . . . . . . . . . . . . 20 97 Appendix A. Implementation experience . . . . . . . . . . . . . 21 98 Appendix B. Public demonstrations . . . . . . . . . . . . . . . 22 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 101 1. Introduction 103 The Distributed Mobility Management (DMM) paradigm aims at minimizing 104 the impact of currently standardized mobility management solutions, 105 which are centralized (at least to a considerable extent). 107 Centralized mobility solutions, such as Mobile IPv6 or the different 108 macro-level mobility management solutions of 3GPP EPS, base their 109 operation on the existence of a central entity (e.g., HA, LMA, PGW or 110 GGSN) that anchors the IP address used by the mobile node and is in 111 charge of coordinating the mobility management (MM) (sometimes helped 112 by a third entity like the MME or the HSS). This central anchor 113 point is in charge of tracking the location of the mobile and 114 redirecting its traffic towards its current topological location. 115 While this way of addressing mobility management has been fully 116 developed by the Mobile IP protocol family and its many extensions, 117 there are also several limitations that have been identified 118 [I-D.chan-distributed-mobility-ps]. Among them, we can just 119 highlight sub-optimal routing, scalability problems (in the network 120 and in the centralized anchor) and reliability 121 [I-D.ietf-dmm-requirements]. 123 Several DMM-based approaches are being proposed and explored now 124 [I-D.ietf-dmm-best-practices-gap-analysis], [commag.dmm-standards]. 125 One of them is based on extending network-based mobility protocols 126 (such as Proxy Mobile IPv6 [RFC5213] or GTP) to operate in 127 distributed fashion. This document proposes a solution that falls in 128 this category, defining a new logical entity, called Distributed 129 Gateway (D-GW) which basically encompasses the functionalities of 130 plain IPv6 access router, MAG and LMA, on a per-IPv6 prefix basis. 131 The main contribution of this draft is the definition of the 132 mechanisms required to support the operation of such a network-based 133 mobility solution when several flows are simultaneously anchored at 134 different D-GWs, by introducing the concept of Distributed Logical 135 Interface (DLIF). The document also defines the required PMIPv6 136 signaling extensions. Last, but not least, the solution is also 137 extended to provide session continuity across different domains. 139 2. Terminology 141 The following terms used in this document are defined in the Proxy 142 Mobile IPv6 specification [RFC5213]: 144 Local Mobility Anchor (LMA) 145 Mobile Access Gateway (MAG) 147 Mobile Node (MN) 149 Binding Cache Entry (BCE) 151 Proxy Care-of Address (P-CoA) 153 Proxy Binding Update (PBU) 155 Proxy Binding Acknowledgment (PBA) 157 The following terms are defined and/or used in this document: 159 D-GW (Distributed Gateway). First IP hop router used by the mobile 160 node. It provides an IPv6 prefix (topologically anchored at the 161 D-GW) to each attaching mobile node. 163 Anchoring D-GW. A previously visited D-GW anchoring an IPv6 prefix 164 which is still used by a mobile node. 166 Serving D-GW. The D-GW the MN is currently attached to. 168 DLIF (Distributed Logical Interface). It is a logical interface at 169 the IP stack of the D-GW. For each active prefix used by the 170 mobile node, the serving D-GW has a DLIF configured (associated to 171 the anchoring D-GW). In this way, a serving D-GW exposes itself 172 towards each MN as multiple routers, one per active anchoring 173 D-GW. 175 HSS (Home Subscriber Server). In a 3GPP architecture, it is the 176 master user database that contains the subscription-related 177 information (subscriber profiles), performs authentication and 178 authorization of the user, and can provide information about the 179 subscriber's location and IP information. 181 3. Solution's overview 183 A new logical network entity, called Distributed Gateway (D-GW) is 184 introduced at the edge of the network, close to the MN. It 185 implements the functionality of a plain IPv6 access router (AR), a 186 mobile access gateway (MAG) and a local mobility anchor (LMA), on a 187 per-MN and per-IPv6-prefix, as described later. 189 The solution basically extends Proxy Mobile IPv6 [RFC5213] to behave 190 in a distributed fashion, similarly as what has been proposed in 191 [I-D.seite-dmm-dma] and [I-D.bernardos-dmm-pmip]. This is achieved 192 by the D-GW logically behaving as a distributed mobility anchor, 193 which comprises the following: 195 o When a mobile node attaches to a D-GW (initial attachment or 196 handover), the D-GW provides an IPv6 prefix to the MN, acting as a 197 regular IPv6 router (with the only difference that the delegated 198 prefix is only assigned to one single MN, not being shared with 199 any other node). The D-GW that the mobile node is currently 200 attached to is called "serving D-GW". 202 o When a mobile node performs a handover, it attaches to a new D-GW 203 and configures a new IPv6 address out of the prefix provided and 204 anchored by the new serving D-GW. As before, the serving D-GW 205 behaves as a plain IPv6 router for that particular MN and the 206 delegated (locally anchored) prefix. If the MN has active traffic 207 using addresses anchored by other D-GWs (which are called 208 "anchoring D-GWs") or it just needs to keep the reachability of 209 these addresses, the current serving D-GW also acts as MAG, by 210 sending the required proxy binding update (PBU) to the 211 corresponding anchoring D-GWs. The anchoring D-GWs therefore 212 behave as LMA for this particular MN and the IPv6 prefixes they 213 are anchoring, replying with a PBA. 215 o Once the PBU/PBA signaling is completed, a bidirectional tunnel is 216 established between the serving D-GW and the anchoring D-GW (one 217 per D-GW anchoring an active prefix used by the MN). These 218 tunnels are used to provide IP address continuity to prefixes that 219 are not anchored at the serving D-GW. 221 o The means for a serving D-GW to obtain the information about the 222 prefixes that a locally attached mobile node wants to keep 223 reachable, and the associated anchoring D-GWs are out of the scope 224 of this draft. Among the possible mechanisms that can be used to 225 let the D-GW know about the prefixes that should be kept 226 reachable, we can cite for instance layer-2 triggers/signaling. 227 Regarding the mapping of IPv6 prefixes to anchoring D-GWs, there 228 might be either fully distributed mechanisms in place, or the 229 information can be maintained in a centralized repository (e.g., 230 in the HSS, using a centralized LMA [I-D.bernardos-dmm-pmip], 231 etc.). 233 The basic operation of the solution is shown with an example in 234 Figure 1. MN1 attaches to D-GW1 (thus becoming its serving D-GW) and 235 configures an IPv6 address (prefA::MN1) out of a prefix locally 236 anchored at D-GW1 (prefA::/64). At this point, MN1 can communicate 237 with any correspondent node of the Internet, being the traffic 238 anchored at D-GW1. If later on MN1 moves to D-GW2, a new IPv6 239 address (PrefB::MN1) is configured by the mobile node, this time out 240 of prefB::/64, which is anchored at D-GW2 (which becomes the new 241 serving D-GW). D-GW2 also exchanges the required PBU/PBA signaling 242 to ensure that data traffic using prefA::MN1 still reaches the mobile 243 node, by setting up a bidirectional tunnel between D-GW1 (anchoring 244 D-GW) and D-GW2 (serving D-GW). 246 +-----+ +-------+ +-------+ +-------------+ 247 | MN1 | | D-GW1 | | D-GW2 | | CN@Internet | 248 +-----+ +-------+ +-------+ +-------------+ 249 | | | | 250 | attachment | | | 251 |<...........>| | | 252 | prefA::/64 | | | 253 |<------------| | | 254 configures | | | | 255 prefA::MN1 | | | | 256 | (traffic using prefA::MN1) | 257 |<------------|------------------------------->| 258 | | | | 259 | handover | | 260 /............................/ | 261 | | prefB::/64 | | 262 |<---------------------------| | 263 configures | | PBU | | 264 prefB::MN1 | tunnel |<-------------| | 265 and keeps | set-up | PBA | | 266 using | |------------->| tunnel | 267 prefA::MN1 | | | set-up | 268 | (traffic using prefB::MN1) | 269 |<---------------------------|---------------->| 270 | (traffic using prefA::MN1) | 271 | |<------------------------------>| 272 | |<============>| | 273 |<-------------------------->| | 274 | | | | 276 Figure 1: Basic operation of the solution 278 The next sections of this draft focus on the detailed operation of 279 the D-GWs when a mobile node has multiple flows anchored at different 280 distributed gateways. 282 4. Simultaneous anchoring of multiple flows (single operator) 283 In this section we describe the mechanisms required in the network to 284 enable simultaneous anchoring of several flows at different D-GWs 285 within the same operator. 287 4.1. The Distributed Logical Interface (DLIF) concept 289 One of the main challenges of a network-based DMM solution is how to 290 allow a mobile node to simultaneously send/receive traffic which is 291 anchored at different D-GWs, and how to influence on the preference 292 of the mobile selecting the source IPv6 address for a new 293 communication, without requiring special support on the mobile node 294 stack. This document defines the Distributed Logical Interface 295 (DLIF), which is a software construct that allows to easily hide the 296 change of anchor from the mobile node. 298 +---------------------------------------------------+ 299 ( Operator's ) 300 ( core ) 301 +---------------------------------------------------+ 302 | | 303 +---------------+ tunnel +---------------+ 304 | IP stack |===============| IP stack | 305 +---------------+ +-------+-------+ 306 | mn1dgw1 |--+ (DLIFs) +--|mn1dgw1|mn1dgw2|--+ 307 +---------------+ | | +-------+-------+ | 308 | phy interface | | | | phy interface | | 309 +---------------+ | | +---------------+ | 310 D-GW1 (o) (o) D-GW2 (o) 311 x x 312 x x 313 prefA::/64 x x prefB::/64 314 (AdvPrefLft=0) x x 315 (o) 316 | 317 +-----+ 318 prefA::MN1 | MN1 | prefB::MN1 319 (deprecated) +-----+ 321 Figure 2: DLIF: exposing multiple routers (one per active anchoring 322 D-GW) 324 The basic idea of the DLIF concept is the following. Each serving 325 D-GW exposes itself towards a given MN as multiple routers, one per 326 active anchoring D-GW associated to the MN. Let's consider the 327 example shown in Figure 2, MN1 initially attaches to D-GW1, 328 configuring an IPv6 address (prefA::MN1) from a prefix locally 329 anchored at D-GW1 (prefA::/64). At this stage, D-GW1 plays both the 330 role of anchoring and serving D-GW, and also it behaves as a plain 331 IPv6 access router. D-GW1 creates a distributed logical interface to 332 communicate (point-to-point link) with MN1, exposing itself as a 333 (logical) router with a specific MAC (e.g., 00:11:22:33:01:01) and 334 IPv6 addresses (e.g., prefA::DGW1/64 and fe80:211:22ff:fe33:101/64) 335 using the DLIF mn1dgw1. As explained below, these addresses 336 represent the "logical" identity of D-GW1 towards MN1, and will 337 "follow" the mobile node while roaming within the domain (note that 338 the place where all this information is maintained and updated is 339 out-of-scope of this draft; potential examples are to keep it on the 340 HSS or the user's profile). 342 If MN1 moves and attaches to a different D-GW of the domain (D-GW2 in 343 the example of Figure 2), this D-GW will create a new logical 344 interface (mn1dgw2) to expose itself towards MN1, providing it with a 345 locally anchored prefix (prefB::/64). In this case, since the MN1 346 has another active IPv6 address anchored at a D-GW1, D-GW2 also needs 347 to create an additional logical interface configured to exactly 348 resemble the one used by D-GW1 to communicate with MN1. In this 349 example, there is only one active anchoring D-GW (in addition to 350 D-GW2, which is the serving one): D-GW1, so only the logical 351 interface mn1dgw1 is created, but the same process would be repeated 352 in case there were more active anchoring D-GWs involved. In order to 353 maintain the prefix anchored at D-GW1 reachable, a tunnel between 354 D-GW1 and D-GW2 is established and the routing is modified 355 accordingly. The PBU/PBA signaling is used to set-up the bi- 356 directional tunnel between D-GW1 and D-GW2, and it might also be used 357 to convey to D-GW2 the information about the prefix(es) anchored at 358 D-GW1 and about the addresses of the associated DLIF (i.e., mn1dgw1). 360 +------------------------------------------+ +----------------------+ 361 | D-GW1 | | D-GW2 | 362 |+----------------------------------------+| |+--------------------+| 363 ||+------------------++------------------+|| ||+------------------+|| 364 |||+-------++-------+||+-------++-------+||| |||+-------++-------+||| 365 ||||mn3dgw1||mn3dgw2||||mn2dgw1||mn2dgw2|||| ||||mn1dgw1||mn1dgw2|||| 366 |||| LMAC1 || LMAC2 |||| LMAC3 || LMAC4 |||| |||| LMAC5 || LMAC6 |||| 367 |||+-------++-------+||+-------++-------+||| |||+-------++-------+||| 368 ||| LIFs of MN3 || LIFs of MN2 ||| ||| LIFs of MN1 ||| 369 ||+------------------++------------------+|| ||+------------------+|| 370 || HMAC1 (phy if D-GW1) || ||HMAC2 (phy if D-GW2)|| 371 |+----------------------------------------+| |+--------------------+| 372 +------------------------------------------+ +----------------------+ 373 x x x 374 x x x 375 (o) (o) (o) 376 | | | 377 +--+--+ +--+--+ +--+--+ 378 | MN3 | | MN2 | | MN1 | 379 +-----+ +-----+ +-----+ 381 Figure 3: Distributed Logical Interface concept 383 Figure 3 shows the logical interface concept in more detail. The 384 figure shows two D-GWs and three MNs. D-GW1 is currently serving MN2 385 and MN3, while D-GW2 is serving MN1. MN1, MN2 and MN3 have two 386 active anchoring D-GWs: D-GW1 and D-GW2. Note that a serving D-GW 387 always plays the role of anchoring D-GW for the attached (served) 388 MNs. Each D-GW has one single physical wireless interface. 390 As introduced before, each MN always "sees" multiple logical routers 391 -- one per active anchoring D-GW -- independently of to which serving 392 D-GW the MN is currently attached. From the point of view of the MN, 393 these D-GWs are portrayed as different routers, although the MN is 394 physically attached to one single interface . The way this is 395 achieved is by the serving D-GW configuring different logical 396 interfaces. If we focus on MN1, it is currently attached to D-GW2 397 (i.e., D-GW2 is its serving D-GW) and, therefore, it has configured 398 an IPv6 address from D-GW2's pool (e.g., prefB::/64). D-GW2 has set- 399 up a logical interface (mn1dgw2) on top of its wireless physical 400 interface (phy if D-GW2) which is used to serve MN1. This interface 401 has a logical MAC address (LMAC6), different from the hardware MAC 402 address (HMAC2) of the physical interface of D-GW2. Over the mn1dgw2 403 interface, D-GW2 advertises its locally anchored prefix prefB::/64. 404 Before attaching to D-GW2, MN1 visited D-GW1, configuring also an 405 address locally anchored at this D-GW, which is still being used by 406 the MN1 in active communications. MN1 keeps "seeing" an interface 407 connecting to D-GW1, as if it were directly connected to the two 408 D-GWs. This is achieved by the serving D-GW (D-GW1) configuring an 409 additional distributed logical interface: mn1dgw1, which behaves 410 exactly as the logical interface configured by the actual D-GW1 when 411 MN1 was attached to it. This means that both the MAC and IPv6 412 addresses configured on this logical interface remain the same 413 regardless of the physical D-GW which is serving the MN. The 414 information required by a serving D-GW to properly configure this 415 logical interfaces can be obtained in different ways: as part of the 416 information conveyed in the PBA, from an external database (e.g., the 417 HSS) or by other means. As shown in the figure, each D-GW may have 418 several logical interfaces associated to each attached MN, having 419 always at least one (since a serving D-GW is also an anchoring D-GW 420 for the attached MN). 422 In order to enforce the use of the prefix locally anchored at the 423 serving D-GW, the router advertisements sent over those logical 424 interfaces playing the role of anchoring D-GWs (different from the 425 serving one) include a zero prefix lifetime. The goal is to 426 deprecate the prefixes delegated by these D-GWs (which will be no 427 longer serving the MN). Note that on-going communications keep on 428 using those addresses, even if they are deprecated, so this only 429 affects to new sessions. 431 The distributed logical interface concept also enables the following 432 use case. Suppose that access to a local IP network is provided by a 433 given D-GW (e.g., D-GW1 in the example shown in Figure 2) and that 434 the resources available at that network cannot be reached from 435 outside the local network (e.g., cannot be accessed by an MN attached 436 to D-GW2). This is similar to the LIPA scenario currently being 437 consider by 3GPP. The goal is to allow an MN to be able to roam 438 while still being able to have connectivity to this local IP network. 439 The solution adopted to support this case makes use of RFC 4191 440 [RFC4191] more specific routes when the MN moves to a D-GW different 441 from the one providing access to the local IP network (D-GW1 in the 442 example). These routes are advertised through the distributed 443 logical interface representing the D-GW providing access to the local 444 network (D-GW1 in this example). In this way, if MN1 moves from 445 D-GW1 to D-GW2, any active session that MN1 may have with a node of 446 the local network connected to D-GW1 will survive, being the traffic 447 forwarded via the tunnel between D-GW1 and D-GW2. Also, any 448 potential future connection attempt towards the local network will be 449 supported, even though MN1 is no longer attached to D-GW1. 451 4.2. D-GW protocol operation 453 This section describes the D-GW operation in more detail. 455 Figure 4 shows an example of the D-GW operation: 457 1. MN1 attaches to D-GW1. This event is detected by D-GW1 (based on 458 layer 2 signaling/triggers or the reception of a Router 459 Solicitation sent by MN1). 461 2. An IPv6 prefix from the pool of locally anchored prefixes is 462 selected by D-GW1 to be delegated to MN1 (prefA::/64). D-GW1 463 sets up a distributed logical interface aimed at interfacing with 464 MN1, called mn1dgw1. D-GW1 starts sending router advertisements 465 to MN1, including the delegated prefix. 467 3. D-GW1 learns if it is an attachment due to a handover (how this 468 is done is out-of-scope of this draft). In this case it is an 469 initial attachment, so nothing else is required. 471 4. The DLIF mn1dgw1 is used by D-GW1 to advertise the locally 472 anchored prefix (prefA::/64) to MN1. Using this prefix, MN1 473 configures an IPv6 address (prefA::MN1/64) that can be used to 474 start new sessions (which will be anchored at D-GW1). Traffic 475 using the address prefA::MN1 is received at the interface mn1dgw1 476 and directly forwarded by D-GW1 towards its destination. Traffic 477 between MN1 and the local network reachable via D-GW1 (localnet) 478 is handled normally by D-GW1 (as MN1 is locally attached). 480 5. MN1 performs a handover to D-GW2. This event is detected by 481 D-GW2. 483 6. An IPv6 prefix from the pool of locally anchored prefixes is 484 selected by D-GW2 to be delegated to MN1 (prefB::/64). D-GW2 485 sets up a distributed logical interface aimed at interfacing with 486 MN1, called mn1dgw2. D-GW2 starts sending router advertisements 487 to MN1, including the delegated prefix. Traffic using the 488 address prefB::MN1 is received at the interface mn1dgw2 and 489 directly forwarded by D-GW2 towards its destination. 491 7. D-GW2 learns that this is a handover of MN1, and that it 492 previously visited D-GW1. D-GW2 sends a PBU to D-GW1, which 493 replies with a PBA. This PBA MAY include information about the 494 prefix(es) anchored at D-GW1, the parameters needed by D-GW2 to 495 set-up the DLIF mn1dgw1, and the prefixes of local networks 496 reachable via D-GW (if any). Alternatively, this information MAY 497 be obtained using a different approach (such as storing it in the 498 HSS or some other external repository). A bi-directional tunnel 499 between D-GW1 and D-GW2 is set-up, as well as the required 500 routing entries. 502 8. D-GW2 sets up the DLIF mn1dgw1, aimed at "logically" resembling 503 D-GW1, so MN1 does not detect any change at layer-3. D-GW2 504 starts sending router advertisements to MN1 through mn1dgw2, 505 which include the prefix anchored at D-GW1 (prefA::/64) with zero 506 lifetime to deprecate the prefix (or alternatively it MAY include 507 a low Default Router Preference [RFC4191] if communication to 508 this D-GW is still needed in the future). In this way, 509 prefA::MN1 is not preferred for new communications. The RAs MAY 510 also include a Route Information Option (RIO) [RFC4191] with the 511 prefix of localnet, which is the network that is only locally 512 reachable via D-GW1 (e.g., as in the LIPA scenarios considered by 513 the 3GPP), so MN1 picks D-GW1 (the "logical" version of it 514 portrayed by D-GW2) when sending traffic to that network , 515 including the delegated prefix. Traffic using the address 516 prefA::MN1 is received at the interface mn1dgw1 and forwarded via 517 the tunnel with D-GW1, which then forwards it towards its 518 destination. Traffic between MN1 and the network locally 519 reachable via D-GW1 (localnet) is also handled via mn1dgw1 and 520 sent through the tunnel. 522 +-----+ +-------+ +-------+ +-------------+ 523 | MN1 | | D-GW1 | | D-GW2 | | CN@Internet | 524 +-----+ +-------+ +-------+ +-------------+ 525 | | | | 526 | attachment | | | 527 |<...........>|set-up of new | | 528 | RA@mn1dgw1 |DLIF: mn1dgw1 | | 529 |<------------| | | 530 configures | (prefA::/64)| | | 531 prefA::MN1 | | | | 532 | (traffic using prefA::MN1) | 533 |<------------|------------------------------->| 534 | (traffic with local net) | | 535 |<----------->|<----> | | 536 | | | | 537 | handover | | 538 /............................/set-up of new | 539 | | RA@mn1dwg2 |DLIF: mn1dgw2 | 540 configures |<---------------------------| | 541 prefB::MN1 | | (prefB::/64)| | 542 and keeps | | PBU | | 543 using | tunnel |<-------------| | 544 prefA::MN1 | set-up | PBA(mn1dgw1, | | 545 | | prefA::/64, | | 546 | | preflocalnet)| | 547 | |------------->|set-up of tunnel | 548 | | RA@mn1dgw1 | & DLIF mn1dgw1 | 549 |<---------------------------| | 550 | | (prefA::/64, lft=0, | 551 | | RIO: preflocalnet) | 552 | | | | 553 | (traffic using prefB::MN1) | 554 |<-------------------------->|<--------------->| 555 | | | | 556 | (traffic using prefA::MN1) | 557 |<-------------------------->| | 558 | |<============>| | 559 | |<------------------------------>| 560 | | | | 561 | (traffic with local net) | | 562 |<-------------------------->| | 563 | |<============>| | 564 | |<---> | | 565 | | | | 567 Figure 4: D-GW protocol operation 569 4.3. Message format 571 This section defines extensions to the Proxy Mobile IPv6 [RFC5213] 572 protocol messages. 574 4.3.1. Proxy Binding Update 576 A new flag (D) is included in the Proxy Binding Update to indicate 577 that the Proxy Binding Update is coming from a Distributed Gateway 578 and not from a mobile access gateway. The rest of the Proxy Binding 579 Update format remains the same as defined in [RFC5213]. 581 0 1 2 3 582 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 583 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 584 | Sequence # | 585 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 586 |A|H|L|K|M|R|P|D| Reserved | Lifetime | 587 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 588 | | 589 . . 590 . Mobility options . 591 . . 593 | | 594 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 596 Distributed Gateway Flag (D) 598 The Distributed Gateway Flag is set to indicate to the receiver of 599 the message that the Proxy Binding Update is from a Distributed 600 Gateway. 602 Mobility Options 604 Variable-length field of such length that the complete Mobility 605 Header is an integer multiple of 8 octets long. This field 606 contains zero or more TLV-encoded mobility options. The encoding 607 and format of defined options are described in Section 6.2 of 608 [RFC6275]. The distributed gateway MUST ignore and skip any 609 options that it does not understand. 611 4.3.2. Proxy Binding Acknowledgment 613 A new flag (D) is included in the Proxy Binding Acknowledgment to 614 indicate that the sender supports operating as a distributed gateway. 615 The rest of the Proxy Binding Acknowledgment format remains the same 616 as defined in [RFC5213]. 618 0 1 2 3 619 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 620 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 621 | Status |K|R|P|D| Reser | 622 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 623 | Sequence # | Lifetime | 624 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 625 | | 626 . . 627 . Mobility options . 628 . . 629 | | 630 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 632 Distributed Gateway Flag (D) 634 The Distributed Gateway Flag is set to indicate that the sender of 635 the message supports operating as a distributed gateway. 637 Mobility Options 639 Variable-length field of such length that the complete Mobility 640 Header is an integer multiple of 8 octets long. This field 641 contains zero or more TLV-encoded mobility options. The encoding 642 and format of defined options are described in Section 6.2 of 643 [RFC6275]. The distributed gateway MUST ignore and skip any 644 options that it does not understand. 646 4.3.3. Anchored Prefix Option 648 A new Anchored Prefix option is defined for use with the Proxy 649 Binding Update and Proxy Binding Acknowledgment messages exchanged 650 between distributed gateways. This option is used for exchanging the 651 mobile node's prefix anchored at the anchoring D-GW. There can be 652 multiple Anchored Prefix options present in the message. 654 The Anchored Prefix Option has an alignment requirement of 8n+4. Its 655 format is as follows: 657 0 1 2 3 658 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 659 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 660 | Type | Length | Reserved | Prefix Length | 661 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 662 | | 663 + + 664 | | 665 + Anchored Prefix + 666 | | 667 + + 668 | | 669 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 671 Type 673 To be assigned by IANA. 675 Length 677 8-bit unsigned integer indicating the length of the option in 678 octets, excluding the type and length fields. This field MUST be 679 set to 18. 681 Reserved 683 This field is unused for now. The value MUST be initialized to 0 684 by the sender and MUST be ignored by the receiver. 686 Prefix Length 688 8-bit unsigned integer indicating the prefix length of the IPv6 689 prefix contained in the option. 691 Anchored Prefix 693 A sixteen-byte field containing the mobile node's IPv6 Anchored 694 Prefix. 696 4.3.4. Local Prefix Option 698 A new Local Prefix option is defined for use with the Proxy Binding 699 Update and Proxy Binding Acknowledgment messages exchanged between 700 distributed gateways. This option is used for exchanging a prefix of 701 a local network that is only reachable via the anchoring D-GW. There 702 can be multiple Local Prefix options present in the message. 704 The Local Prefix Option has an alignment requirement of 8n+4. Its 705 format is as follows: 707 0 1 2 3 708 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 709 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 710 | Type | Length | Reserved | Prefix Length | 711 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 712 | | 713 + + 714 | | 715 + Local Prefix + 716 | | 717 + + 718 | | 719 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 721 Type 723 To be assigned by IANA. 725 Length 727 8-bit unsigned integer indicating the length of the option in 728 octets, excluding the type and length fields. This field MUST be 729 set to 18. 731 Reserved 733 This field is unused for now. The value MUST be initialized to 0 734 by the sender and MUST be ignored by the receiver. 736 Prefix Length 738 8-bit unsigned integer indicating the prefix length of the IPv6 739 prefix contained in the option. 741 Local Prefix 743 A sixteen-byte field containing the IPv6 Local Prefix. 745 4.3.5. DLIF Link-local Address Option 747 A new DLIF Link-local Address option is defined for use with the 748 Proxy Binding Update and Proxy Binding Acknowledgment messages 749 exchanged between distributed gateways. This option is used for 750 exchanging the link-local address of the DLIF to be configured on the 751 serving D-GW so it resembles the DLIF configured on the anchoring 752 D-GW. 754 The DLIF Link-local Address option has an alignment requirement of 755 8n+6. Its format is as follows: 757 0 1 2 3 758 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 759 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 760 | Type | Length | 761 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 762 | | 763 + + 764 | | 765 + DLIF Link-local Address + 766 | | 767 + + 768 | | 769 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 771 Type 773 To be assigned by IANA. 775 Length 777 8-bit unsigned integer indicating the length of the option in 778 octets, excluding the type and length fields. This field MUST be 779 set to 16. 781 DLIF Link-local Address 783 A sixteen-byte field containing the link-local address of the 784 logical interface. 786 4.3.6. DLIF Link-layer Address Option 788 A new DLIF Link-layer Address option is defined for use with the 789 Proxy Binding Update and Proxy Binding Acknowledgment messages 790 exchanged between distributed gateways. This option is used for 791 exchanging the link-layer address of the DLIF to be configured on the 792 serving D-GW so it resembles the DLIF configured on the anchoring 793 D-GW. 795 The format of the DLIF Link-layer Address option is shown below. 796 Based on the size of the address, the option MUST be aligned 797 appropriately, as per mobility option alignment requirements 798 specified in [RFC6275]. 800 0 1 2 3 801 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 802 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 803 | Type | Length | Reserved | 804 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 805 | | 806 + DLIF Link-layer Address + 807 . ... . 808 | | 809 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 810 Type 812 To be assigned by IANA. 814 Length 816 8-bit unsigned integer indicating the length of the option in 817 octets, excluding the type and length fields. 819 Reserved 821 This field is unused for now. The value MUST be initialized to 0 822 by the sender and MUST be ignored by the receiver. 824 DLIF Link-layer Address 826 A variable length field containing the link-layer address of the 827 logical interface to be configured on the serving distributed 828 gateway. 830 The content and format of this field (including byte and bit 831 ordering) is as specified in Section 4.6 of [RFC4861] for carrying 832 link-layer addresses. On certain access links, where the link- 833 layer address is not used or cannot be determined, this option 834 cannot be used. 836 5. Simultaneous anchoring of multiple flows (multiple operators) 838 An MN may roam between D-GWs that do not belong to the same operator, 839 and therefore might end up having multiple simultaneous flows, 840 anchored at different operators. Since dynamically setting up 841 tunnels between different operators (i.e., between D-GWs belonging to 842 different operators) is usually not supported, a solution should be 843 devised to ensure session continuity in this scenario, even if it is 844 at the cost of a sub-optimal routing. 846 In this section we describe the required extensions to support inter- 847 domain operation. The basic solution consists in using a centralized 848 LMA (usually located in the home domain) as top-level anchor to 849 guarantee session continuity when crossing operator borders. We 850 assume that the necessary roaming agreements are in place in order to 851 support setting up tunnels between the LMA located at the home domain 852 of the MN and the visited D-GWs. 854 +---------------------------------------------------+ 855 ( Home Operator's core ) 856 ( ) 857 ( +-----+ ) 858 ( /| LMA |\ ) 859 ( //+-----+\\ ) 860 ( // \\ ) 861 +------------------//-----------\\------------------+ 862 . (tunnel) // \\ (tunnel) . 863 . // \\ . 864 . // \\ . 865 . // \\ . 866 +---------------+ +---------------+ 867 | IP stack | | IP stack | 868 +---------------+ +-------+-------+ 869 | mn1dgw1 |--+ (DLIFs) +--|mn1dgw1|mn1dgw2|--+ 870 +---------------+ | | +-------+-------+ | 871 | phy interface | | | | phy interface | | 872 +---------------+ | | +---------------+ | 873 D-GW1@OperatorA (o) (o) D-GW2@OperatorB (o) 874 x x 875 x x 876 prefA::/64 x x prefB::/64 877 (AdvPrefLft=0) x x 878 (o) 879 | 880 +-----+ 881 prefA::MN1 | MN1 | prefB::MN1 882 (deprecated) +-----+ 884 Figure 5: Simultaneous anchoring of multiple flows across multiple 885 operators 887 Figure 5 shows an example of the inter-domain operation. MN1 888 initially attaches to D-GW1 (which belongs to OperatorA), and 889 configures prefA::MN1 address out of one prefix anchored at D-GW1 890 (prefA::/64). If MN1 moves to D-GW2, which is managed by OperatorB, 891 tunnels need to be established via the centralized LMA at the MN1's 892 operators core, since we assume that no direct tunneling is possible 893 between D-GWs belonging to different operators. In this case, D-GW3 894 establishes one tunnel with the centralized LMA to send/receive 895 traffic using prefA::/64. From the point of view of D-GW2, the 896 operation is just as if the LMA was the D-GW anchoring this prefix. 897 Analogously, the LMA establishes one tunnel with D-GW1 (from the 898 point of view of D-GW1, the LMA is the current serving D-GW of MN1). 899 Regarding the signaling, it is similar to the intra-operator 900 scenario, though in this case the PBU/PBA sequence is performed 901 twice, once between D-GW2 and the LMA, and another one between the 902 LMA and D-GW1 (i.e., because two different tunnels are created). 904 6. IANA Considerations 905 This document defines new mobility options that require IANA actions. 907 7. Security Considerations 909 The protocol extensions defined in this document share the same 910 security concerns of Proxy Mobile IPv6 [RFC5213]. It is recommended 911 that the signaling messages, Proxy Binding Update and Proxy Binding 912 Acknowledgment, exchanged between the distributed gateways, or 913 between a distributed gateway and a centralized local mobility 914 anchor, are protected using IPsec using the established security 915 association between them. This essentially eliminates the threats 916 related to the impersonation of a distributed gateway or the local 917 mobility anchor. 919 8. References 921 8.1. Normative References 923 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 924 Requirement Levels", BCP 14, RFC 2119, March 1997. 926 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 927 More-Specific Routes", RFC 4191, November 2005. 929 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 930 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 931 September 2007. 933 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 934 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 936 [RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support 937 in IPv6", RFC 6275, July 2011. 939 8.2. Informative References 941 [I-D.bernardos-dmm-pmip] 942 Bernardos, C., Oliva, A., and F. Giust, "A PMIPv6-based 943 solution for Distributed Mobility Management", draft- 944 bernardos-dmm-pmip-03 (work in progress), February 2014. 946 [I-D.chan-distributed-mobility-ps] 947 Chan, A., "Problem statement for distributed and dynamic 948 mobility management", draft-chan-distributed-mobility- 949 ps-05 (work in progress), October 2011. 951 [I-D.ietf-dmm-best-practices-gap-analysis] 952 Liu, D., Zuniga, J., Seite, P., Chan, A., and C. 953 Bernardos, "Distributed Mobility Management: Current 954 practices and gap analysis", draft-ietf-dmm-best- 955 practices-gap-analysis-03 (work in progress), February 956 2014. 958 [I-D.ietf-dmm-requirements] 959 Chan, A., Liu, D., Seite, P., Yokota, H., and J. Korhonen, 960 "Requirements for Distributed Mobility Management", draft- 961 ietf-dmm-requirements-16 (work in progress), April 2014. 963 [I-D.seite-dmm-dma] 964 Seite, P., Bertin, P., and J. Lee, "Distributed Mobility 965 Anchoring", draft-seite-dmm-dma-07 (work in progress), 966 February 2014. 968 [commag.dmm-standards] 969 Zuniga, JC., Bernardos, CJ., de la Oliva, A., Melia, T., 970 Costa, R., and A. Reznik, "Distributed mobility 971 management: a standards landscape", IEEE Communications 972 Magazine Vol. 51, No. 3, March 2013. 974 Appendix A. Implementation experience 976 The DLIF concept can be easily implemented using features that are 977 usually available on several OSs. Among the possible mechanisms that 978 can be used to do it, the Linux macvlan support allows the creation 979 of different logical interfaces over the same physical one. Each 980 logical interface appears as a regular interface to the Linux OS 981 (which can be configured normally), and it supports configuring the 982 MAC address exposed by the logical interface. The destination MAC 983 address is used by the OS to decide which logical interface 984 (configured on top of a physical interface) is in charge of 985 processing an incoming L2 frame. 987 The EU FP7 MEDIEVAL project implemented a prototype of the DLIF 988 concept using the Linux macvlan support, the radvd daemon, the Linux 989 Advanced Routing and Traffic Control features and the standard 990 iproute2 collection of utilities: 992 o The macvlan support enables iproute2 tools to be able to create, 993 destroy and configure DLIFs on demand over a single physical 994 interface. One of the important features that needs to be 995 configured is the logical MAC address exposed by the DLIF, as well 996 as the IPv6 addresses, as they should remain the same regardless 997 of the serving D-GW where the DLIF is configured. 999 o Since the distributed logical interfaces created using the macvlan 1000 support appear as regular network interfaces, they can be used 1001 normally in the radvd configuration file. Them, by dynamically 1002 modifying the radvd configuration file and reloading it, we can 1003 control the router advertisements sent to each MN (e.g., 1004 advertizing new IPv6 prefixes, deprecating prefixes anchored at 1005 other serving D-GWs, announcing RFC 4191 specific routes or 1006 changing router preferences). 1008 o Each time a DLIF is created, it is also needed to properly 1009 configure source-based IPv6 routes, as well as tunnels (in case of 1010 handover). This is supported by the Linux Advanced Routing and 1011 Traffic Control features. 1013 o Last, but not least, current Linux kernels support the 1014 configuration of RFC 4191 specific routes (by processing Route 1015 Information Options contained in RAs). The kernel support can be 1016 easily enabled by using the 1017 net.conf.ipv6.*.accept_ra_rt_info_max_plen kernel configuration 1018 parameter. 1020 The DLIF concept is implemented by the Open Distributed Mobility 1021 Management (ODMM) project (http://www.odmm.net/), as part of the 1022 Mobility Anchors Distribution for PMIPv6 (MAD-PMIPv6). The ODMM 1023 platform is intended to foster DMM development and deployment, by 1024 serving as a framework to host open source implementations. 1026 Appendix B. Public demonstrations 1028 The DLIF concept has been demonstrated, together with the network- 1029 based DMM solution described in [I-D.bernardos-dmm-pmip], during the 1030 83rd IETF in Paris (March 2012) and the 87th IETF in Berlin (August 1031 2013). 1033 The first demo showcased a scenario composed of three "anchor 1034 routers", a "centralized LMA" for control plane, a "mobile node" and 1035 two "correspondent nodes" (one of them being a legacy IPv6 camera). 1036 The mobile node could move between the different anchor routers, 1037 getting a different locally anchor IPv6 address at each location, and 1038 being the reachability of each address maintained. 1040 In the second demo, integration with content delivery nodes (CDNs) 1041 was also shown, showcasing the advantages that the use of a DMM 1042 solution brings to this popular scenario. 1044 Authors' Addresses 1045 Carlos J. Bernardos 1046 Universidad Carlos III de Madrid 1047 Av. Universidad, 30 1048 Leganes, Madrid 28911 1049 Spain 1051 Phone: +34 91624 6236 1052 Email: cjbc@it.uc3m.es 1053 URI: http://www.it.uc3m.es/cjbc/ 1055 Juan Carlos Zuniga 1056 InterDigital Communications, LLC 1057 1000 Sherbrooke Street West, 10th floor 1058 Montreal, Quebec H3A 3G4 1059 Canada 1061 Email: JuanCarlos.Zuniga@InterDigital.com 1062 URI: http://www.InterDigital.com/