idnits 2.17.1 draft-bernardos-dmm-distributed-anchoring-03.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 (October 9, 2013) is 3852 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-02 == Outdated reference: A later version (-09) exists of draft-ietf-dmm-best-practices-gap-analysis-01 == Outdated reference: A later version (-17) exists of draft-ietf-dmm-requirements-09 == Outdated reference: A later version (-07) exists of draft-seite-dmm-dma-06 Summary: 0 errors (**), 0 flaws (~~), 5 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: April 12, 2014 InterDigital 6 October 9, 2013 8 PMIPv6-based distributed anchoring 9 draft-bernardos-dmm-distributed-anchoring-03 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 April 12, 2014. 60 Copyright Notice 62 Copyright (c) 2013 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 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 . . . . . 8 82 4.2. D-GW protocol operation . . . . . . . . . . . . . . . . . 11 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 91 operators) . . . . . . . . . . . . . . . . . . . . . . . . . . 19 92 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 93 7. Security Considerations . . . . . . . . . . . . . . . . . . . 21 94 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 95 8.1. Normative References . . . . . . . . . . . . . . . . . . . 21 96 8.2. Informative References . . . . . . . . . . . . . . . . . . 22 97 Appendix A. Implementation experience . . . . . . . . . . . . . . 22 98 Appendix B. Public demonstrations . . . . . . . . . . . . . . . . 23 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 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) 146 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) 284 In this section we describe the mechanisms required in the network to 285 enable simultaneous anchoring of several flows at different D-GWs 286 within the same operator. 288 4.1. The Distributed Logical Interface (DLIF) concept 290 One of the main challenges of a network-based DMM solution is how to 291 allow a mobile node to simultaneously send/receive traffic which is 292 anchored at different D-GWs, and how to influence on the preference 293 of the mobile selecting the source IPv6 address for a new 294 communication, without requiring special support on the mobile node 295 stack. This document defines the Distributed Logical Interface 296 (DLIF), which is a software construct that allows to easily hide the 297 change of anchor from the mobile node. 299 +---------------------------------------------------+ 300 ( Operator's ) 301 ( core ) 302 +---------------------------------------------------+ 303 | | 304 +---------------+ tunnel +---------------+ 305 | IP stack |===============| IP stack | 306 +---------------+ +-------+-------+ 307 | mn1dgw1 |--+ (DLIFs) +--|mn1dgw1|mn1dgw2|--+ 308 +---------------+ | | +-------+-------+ | 309 | phy interface | | | | phy interface | | 310 +---------------+ | | +---------------+ | 311 D-GW1 (o) (o) D-GW2 (o) 312 x x 313 x x 314 prefA::/64 x x prefB::/64 315 (AdvPrefLft=0) x x 316 (o) 317 | 318 +-----+ 319 prefA::MN1 | MN1 | prefB::MN1 320 (deprecated) +-----+ 322 Figure 2: DLIF: exposing multiple routers (one per active anchoring 323 D-GW) 325 The basic idea of the DLIF concept is the following. Each serving 326 D-GW exposes itself towards a given MN as multiple routers, one per 327 active anchoring D-GW associated to the MN. Let's consider the 328 example shown in Figure 2, MN1 initially attaches to D-GW1, 329 configuring an IPv6 address (prefA::MN1) from a prefix locally 330 anchored at D-GW1 (prefA::/64). At this stage, D-GW1 plays both the 331 role of anchoring and serving D-GW, and also it behaves as a plain 332 IPv6 access router. D-GW1 creates a distributed logical interface to 333 communicate (point-to-point link) with MN1, exposing itself as a 334 (logical) router with a specific MAC (e.g., 00:11:22:33:01:01) and 335 IPv6 addresses (e.g., prefA::DGW1/64 and fe80:211:22ff:fe33:101/64) 336 using the DLIF mn1dgw1. As explained below, these addresses 337 represent the "logical" identity of D-GW1 towards MN1, and will 338 "follow" the mobile node while roaming within the domain (note that 339 the place where all this information is maintained and updated is 340 out-of-scope of this draft; potential examples are to keep it on the 341 HSS or the user's profile). 343 If MN1 moves and attaches to a different D-GW of the domain (D-GW2 in 344 the example of Figure 2), this D-GW will create a new logical 345 interface (mn1dgw2) to expose itself towards MN1, providing it with a 346 locally anchored prefix (prefB::/64). In this case, since the MN1 347 has another active IPv6 address anchored at a D-GW1, D-GW2 also needs 348 to create an additional logical interface configured to exactly 349 resemble the one used by D-GW1 to communicate with MN1. In this 350 example, there is only one active anchoring D-GW (in addition to 351 D-GW2, which is the serving one): D-GW1, so only the logical 352 interface mn1dgw1 is created, but the same process would be repeated 353 in case there were more active anchoring D-GWs involved. In order to 354 maintain the prefix anchored at D-GW1 reachable, a tunnel between 355 D-GW1 and D-GW2 is established and the routing is modified 356 accordingly. The PBU/PBA signaling is used to set-up the bi- 357 directional tunnel between D-GW1 and D-GW2, and it might also be used 358 to convey to D-GW2 the information about the prefix(es) anchored at 359 D-GW1 and about the addresses of the associated DLIF (i.e., mn1dgw1). 361 +------------------------------------------+ +----------------------+ 362 | D-GW1 | | D-GW2 | 363 |+----------------------------------------+| |+--------------------+| 364 ||+------------------++------------------+|| ||+------------------+|| 365 |||+-------++-------+||+-------++-------+||| |||+-------++-------+||| 366 ||||mn3dgw1||mn3dgw2||||mn2dgw1||mn2dgw2|||| ||||mn1dgw1||mn1dgw2|||| 367 |||| LMAC1 || LMAC2 |||| LMAC3 || LMAC4 |||| |||| LMAC5 || LMAC6 |||| 368 |||+-------++-------+||+-------++-------+||| |||+-------++-------+||| 369 ||| LIFs of MN3 || LIFs of MN2 ||| ||| LIFs of MN1 ||| 370 ||+------------------++------------------+|| ||+------------------+|| 371 || HMAC1 (phy if D-GW1) || ||HMAC2 (phy if D-GW2)|| 372 |+----------------------------------------+| |+--------------------+| 373 +------------------------------------------+ +----------------------+ 374 x x x 375 x x x 376 (o) (o) (o) 377 | | | 378 +--+--+ +--+--+ +--+--+ 379 | MN3 | | MN2 | | MN1 | 380 +-----+ +-----+ +-----+ 382 Figure 3: Distributed Logical Interface concept 384 Figure 3 shows the logical interface concept in more detail. The 385 figure shows two D-GWs and three MNs. D-GW1 is currently serving MN2 386 and MN3, while D-GW2 is serving MN1. MN1, MN2 and MN3 have two 387 active anchoring D-GWs: D-GW1 and D-GW2. Note that a serving D-GW 388 always plays the role of anchoring D-GW for the attached (served) 389 MNs. Each D-GW has one single physical wireless interface. 391 As introduced before, each MN always "sees" multiple logical routers 392 -- one per active anchoring D-GW -- independently of to which serving 393 D-GW the MN is currently attached. From the point of view of the MN, 394 these D-GWs are portrayed as different routers, although the MN is 395 physically attached to one single interface . The way this is 396 achieved is by the serving D-GW configuring different logical 397 interfaces. If we focus on MN1, it is currently attached to D-GW2 398 (i.e., D-GW2 is its serving D-GW) and, therefore, it has configured 399 an IPv6 address from D-GW2's pool (e.g., prefB::/64). D-GW2 has 400 set-up a logical interface (mn1dgw2) on top of its wireless physical 401 interface (phy if D-GW2) which is used to serve MN1. This interface 402 has a logical MAC address (LMAC6), different from the hardware MAC 403 address (HMAC2) of the physical interface of D-GW2. Over the mn1dgw2 404 interface, D-GW2 advertises its locally anchored prefix prefB::/64. 405 Before attaching to D-GW2, MN1 visited D-GW1, configuring also an 406 address locally anchored at this D-GW, which is still being used by 407 the MN1 in active communications. MN1 keeps "seeing" an interface 408 connecting to D-GW1, as if it were directly connected to the two 409 D-GWs. This is achieved by the serving D-GW (D-GW1) configuring an 410 additional distributed logical interface: mn1dgw1, which behaves 411 exactly as the logical interface configured by the actual D-GW1 when 412 MN1 was attached to it. This means that both the MAC and IPv6 413 addresses configured on this logical interface remain the same 414 regardless of the physical D-GW which is serving the MN. The 415 information required by a serving D-GW to properly configure this 416 logical interfaces can be obtained in different ways: as part of the 417 information conveyed in the PBA, from an external database (e.g., the 418 HSS) or by other means. As shown in the figure, each D-GW may have 419 several logical interfaces associated to each attached MN, having 420 always at least one (since a serving D-GW is also an anchoring D-GW 421 for the attached MN). 423 In order to enforce the use of the prefix locally anchored at the 424 serving D-GW, the router advertisements sent over those logical 425 interfaces playing the role of anchoring D-GWs (different from the 426 serving one) include a zero prefix lifetime. The goal is to 427 deprecate the prefixes delegated by these D-GWs (which will be no 428 longer serving the MN). Note that on-going communications keep on 429 using those addresses, even if they are deprecated, so this only 430 affects to new sessions. 432 The distributed logical interface concept also enables the following 433 use case. Suppose that access to a local IP network is provided by a 434 given D-GW (e.g., D-GW1 in the example shown in Figure 2) and that 435 the resources available at that network cannot be reached from 436 outside the local network (e.g., cannot be accessed by an MN attached 437 to D-GW2). This is similar to the LIPA scenario currently being 438 consider by 3GPP. The goal is to allow an MN to be able to roam 439 while still being able to have connectivity to this local IP network. 440 The solution adopted to support this case makes use of RFC 4191 441 [RFC4191] more specific routes when the MN moves to a D-GW different 442 from the one providing access to the local IP network (D-GW1 in the 443 example). These routes are advertised through the distributed 444 logical interface representing the D-GW providing access to the local 445 network (D-GW1 in this example). In this way, if MN1 moves from 446 D-GW1 to D-GW2, any active session that MN1 may have with a node of 447 the local network connected to D-GW1 will survive, being the traffic 448 forwarded via the tunnel between D-GW1 and D-GW2. Also, any 449 potential future connection attempt towards the local network will be 450 supported, even though MN1 is no longer attached to D-GW1. 452 4.2. D-GW protocol operation 454 This section describes the D-GW operation in more detail. 456 Figure 4 shows an example of the D-GW operation: 458 1. MN1 attaches to D-GW1. This event is detected by D-GW1 (based on 459 layer 2 signaling/triggers or the reception of a Router 460 Solicitation sent by MN1). 462 2. An IPv6 prefix from the pool of locally anchored prefixes is 463 selected by D-GW1 to be delegated to MN1 (prefA::/64). D-GW1 464 sets up a distributed logical interface aimed at interfacing with 465 MN1, called mn1dgw1. D-GW1 starts sending router advertisements 466 to MN1, including the delegated prefix. 468 3. D-GW1 learns if it is an attachment due to a handover (how this 469 is done is out-of-scope of this draft). In this case it is an 470 initial attachment, so nothing else is required. 472 4. The DLIF mn1dgw1 is used by D-GW1 to advertise the locally 473 anchored prefix (prefA::/64) to MN1. Using this prefix, MN1 474 configures an IPv6 address (prefA::MN1/64) that can be used to 475 start new sessions (which will be anchored at D-GW1). Traffic 476 using the address prefA::MN1 is received at the interface mn1dgw1 477 and directly forwarded by D-GW1 towards its destination. Traffic 478 between MN1 and the local network reachable via D-GW1 (localnet) 479 is handled normally by D-GW1 (as MN1 is locally attached). 481 5. MN1 performs a handover to D-GW2. This event is detected by 482 D-GW2. 484 6. An IPv6 prefix from the pool of locally anchored prefixes is 485 selected by D-GW2 to be delegated to MN1 (prefB::/64). D-GW2 486 sets up a distributed logical interface aimed at interfacing with 487 MN1, called mn1dgw2. D-GW2 starts sending router advertisements 488 to MN1, including the delegated prefix. Traffic using the 489 address prefB::MN1 is received at the interface mn1dgw2 and 490 directly forwarded by D-GW2 towards its destination. 492 7. D-GW2 learns that this is a handover of MN1, and that it 493 previously visited D-GW1. D-GW2 sends a PBU to D-GW1, which 494 replies with a PBA. This PBA MAY include information about the 495 prefix(es) anchored at D-GW1, the parameters needed by D-GW2 to 496 set-up the DLIF mn1dgw1, and the prefixes of local networks 497 reachable via D-GW (if any). Alternatively, this information MAY 498 be obtained using a different approach (such as storing it in the 499 HSS or some other external repository). A bi-directional tunnel 500 between D-GW1 and D-GW2 is set-up, as well as the required 501 routing entries. 503 8. D-GW2 sets up the DLIF mn1dgw1, aimed at "logically" resembling 504 D-GW1, so MN1 does not detect any change at layer-3. D-GW2 505 starts sending router advertisements to MN1 through mn1dgw2, 506 which include the prefix anchored at D-GW1 (prefA::/64) with zero 507 lifetime to deprecate the prefix (or alternatively it MAY include 508 a low Default Router Preference [RFC4191] if communication to 509 this D-GW is still needed in the future). In this way, prefA:: 510 MN1 is not preferred for new communications. The RAs MAY also 511 include a Route Information Option (RIO) [RFC4191] with the 512 prefix of localnet, which is the network that is only locally 513 reachable via D-GW1 (e.g., as in the LIPA scenarios considered by 514 the 3GPP), so MN1 picks D-GW1 (the "logical" version of it 515 portrayed by D-GW2) when sending traffic to that network , 516 including the delegated prefix. Traffic using the address 517 prefA::MN1 is received at the interface mn1dgw1 and forwarded via 518 the tunnel with D-GW1, which then forwards it towards its 519 destination. Traffic between MN1 and the network locally 520 reachable via D-GW1 (localnet) is also handled via mn1dgw1 and 521 sent through the tunnel. 523 +-----+ +-------+ +-------+ +-------------+ 524 | MN1 | | D-GW1 | | D-GW2 | | CN@Internet | 525 +-----+ +-------+ +-------+ +-------------+ 526 | | | | 527 | attachment | | | 528 |<...........>|set-up of new | | 529 | RA@mn1dgw1 |DLIF: mn1dgw1 | | 530 |<------------| | | 531 configures | (prefA::/64)| | | 532 prefA::MN1 | | | | 533 | (traffic using prefA::MN1) | 534 |<------------|------------------------------->| 535 | (traffic with local net) | | 536 |<----------->|<----> | | 537 | | | | 538 | handover | | 539 /............................/set-up of new | 540 | | RA@mn1dwg2 |DLIF: mn1dgw2 | 541 configures |<---------------------------| | 542 prefB::MN1 | | (prefB::/64)| | 543 and keeps | | PBU | | 544 using | tunnel |<-------------| | 545 prefA::MN1 | set-up | PBA(mn1dgw1, | | 546 | | prefA::/64, | | 547 | | preflocalnet)| | 548 | |------------->|set-up of tunnel | 549 | | RA@mn1dgw1 | & DLIF mn1dgw1 | 550 |<---------------------------| | 551 | | (prefA::/64, lft=0, | 552 | | RIO: preflocalnet) | 553 | | | | 554 | (traffic using prefB::MN1) | 555 |<-------------------------->|<--------------->| 556 | | | | 557 | (traffic using prefA::MN1) | 558 |<-------------------------->| | 559 | |<============>| | 560 | |<------------------------------>| 561 | | | | 562 | (traffic with local net) | | 563 |<-------------------------->| | 564 | |<============>| | 565 | |<---> | | 566 | | | | 568 Figure 4: D-GW protocol operation 570 4.3. Message format 572 This section defines extensions to the Proxy Mobile IPv6 [RFC5213] 573 protocol messages. 575 4.3.1. Proxy Binding Update 577 A new flag (D) is included in the Proxy Binding Update to indicate 578 that the Proxy Binding Update is coming from a Distributed Gateway 579 and not from a mobile access gateway. The rest of the Proxy Binding 580 Update format remains the same as defined in [RFC5213]. 582 0 1 2 3 583 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 584 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 585 | Sequence # | 586 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 587 |A|H|L|K|M|R|P|D| Reserved | Lifetime | 588 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 589 | | 590 . . 591 . Mobility options . 592 . . 594 | | 595 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 597 Distributed Gateway Flag (D) 599 The Distributed Gateway Flag is set to indicate to the receiver of 600 the message that the Proxy Binding Update is from a Distributed 601 Gateway. 603 Mobility Options 605 Variable-length field of such length that the complete Mobility 606 Header is an integer multiple of 8 octets long. This field 607 contains zero or more TLV-encoded mobility options. The encoding 608 and format of defined options are described in Section 6.2 of 609 [RFC6275]. The distributed gateway MUST ignore and skip any 610 options that it does not understand. 612 4.3.2. Proxy Binding Acknowledgment 614 A new flag (D) is included in the Proxy Binding Acknowledgment to 615 indicate that the sender supports operating as a distributed gateway. 616 The rest of the Proxy Binding Acknowledgment format remains the same 617 as defined in [RFC5213]. 619 0 1 2 3 620 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 621 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 622 | Status |K|R|P|D| Reser | 623 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 624 | Sequence # | Lifetime | 625 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 626 | | 627 . . 628 . Mobility options . 629 . . 630 | | 631 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 633 Distributed Gateway Flag (D) 635 The Distributed Gateway Flag is set to indicate that the sender of 636 the message supports operating as a distributed gateway. 638 Mobility Options 640 Variable-length field of such length that the complete Mobility 641 Header is an integer multiple of 8 octets long. This field 642 contains zero or more TLV-encoded mobility options. The encoding 643 and format of defined options are described in Section 6.2 of 644 [RFC6275]. The distributed gateway MUST ignore and skip any 645 options that it does not understand. 647 4.3.3. Anchored Prefix Option 649 A new Anchored Prefix option is defined for use with the Proxy 650 Binding Update and Proxy Binding Acknowledgment messages exchanged 651 between distributed gateways. This option is used for exchanging the 652 mobile node's prefix anchored at the anchoring D-GW. There can be 653 multiple Anchored Prefix options present in the message. 655 The Anchored Prefix Option has an alignment requirement of 8n+4. Its 656 format is as follows: 658 0 1 2 3 659 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 660 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 661 | Type | Length | Reserved | Prefix Length | 662 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 663 | | 664 + + 665 | | 666 + Anchored Prefix + 667 | | 668 + + 669 | | 670 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 672 Type 674 To be assigned by IANA. 676 Length 678 8-bit unsigned integer indicating the length of the option in 679 octets, excluding the type and length fields. This field MUST be 680 set to 18. 682 Reserved 684 This field is unused for now. The value MUST be initialized to 0 685 by the sender and MUST be ignored by the receiver. 687 Prefix Length 689 8-bit unsigned integer indicating the prefix length of the IPv6 690 prefix contained in the option. 692 Anchored Prefix 694 A sixteen-byte field containing the mobile node's IPv6 Anchored 695 Prefix. 697 4.3.4. Local Prefix Option 699 A new Local Prefix option is defined for use with the Proxy Binding 700 Update and Proxy Binding Acknowledgment messages exchanged between 701 distributed gateways. This option is used for exchanging a prefix of 702 a local network that is only reachable via the anchoring D-GW. There 703 can be multiple Local Prefix options present in the message. 705 The Local Prefix Option has an alignment requirement of 8n+4. Its 706 format is as follows: 708 0 1 2 3 709 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 710 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 711 | Type | Length | Reserved | Prefix Length | 712 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 713 | | 714 + + 715 | | 716 + Local Prefix + 717 | | 718 + + 719 | | 720 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 722 Type 724 To be assigned by IANA. 726 Length 728 8-bit unsigned integer indicating the length of the option in 729 octets, excluding the type and length fields. This field MUST be 730 set to 18. 732 Reserved 734 This field is unused for now. The value MUST be initialized to 0 735 by the sender and MUST be ignored by the receiver. 737 Prefix Length 739 8-bit unsigned integer indicating the prefix length of the IPv6 740 prefix contained in the option. 742 Local Prefix 744 A sixteen-byte field containing the IPv6 Local Prefix. 746 4.3.5. DLIF Link-local Address Option 748 A new DLIF Link-local Address option is defined for use with the 749 Proxy Binding Update and Proxy Binding Acknowledgment messages 750 exchanged between distributed gateways. This option is used for 751 exchanging the link-local address of the DLIF to be configured on the 752 serving D-GW so it resembles the DLIF configured on the anchoring 753 D-GW. 755 The DLIF Link-local Address option has an alignment requirement of 756 8n+6. Its format is as follows: 758 0 1 2 3 759 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 760 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 761 | Type | Length | 762 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 763 | | 764 + + 765 | | 766 + DLIF Link-local Address + 767 | | 768 + + 769 | | 770 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 772 Type 774 To be assigned by IANA. 776 Length 778 8-bit unsigned integer indicating the length of the option in 779 octets, excluding the type and length fields. This field MUST be 780 set to 16. 782 DLIF Link-local Address 784 A sixteen-byte field containing the link-local address of the 785 logical interface. 787 4.3.6. DLIF Link-layer Address Option 789 A new DLIF Link-layer Address option is defined for use with the 790 Proxy Binding Update and Proxy Binding Acknowledgment messages 791 exchanged between distributed gateways. This option is used for 792 exchanging the link-layer address of the DLIF to be configured on the 793 serving D-GW so it resembles the DLIF configured on the anchoring 794 D-GW. 796 The format of the DLIF Link-layer Address option is shown below. 797 Based on the size of the address, the option MUST be aligned 798 appropriately, as per mobility option alignment requirements 799 specified in [RFC6275]. 801 0 1 2 3 802 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 803 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 804 | Type | Length | Reserved | 805 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 806 | | 807 + DLIF Link-layer Address + 808 . ... . 809 | | 810 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 812 Type 814 To be assigned by IANA. 816 Length 818 8-bit unsigned integer indicating the length of the option in 819 octets, excluding the type and length fields. 821 Reserved 823 This field is unused for now. The value MUST be initialized to 0 824 by the sender and MUST be ignored by the receiver. 826 DLIF Link-layer Address 828 A variable length field containing the link-layer address of the 829 logical interface to be configured on the serving distributed 830 gateway. 832 The content and format of this field (including byte and bit 833 ordering) is as specified in Section 4.6 of [RFC4861] for carrying 834 link-layer addresses. On certain access links, where the link- 835 layer address is not used or cannot be determined, this option 836 cannot be used. 838 5. Simultaneous anchoring of multiple flows (multiple operators) 840 An MN may roam between D-GWs that do not belong to the same operator, 841 and therefore might end up having multiple simultaneous flows, 842 anchored at different operators. Since dynamically setting up 843 tunnels between different operators (i.e., between D-GWs belonging to 844 different operators) is usually not supported, a solution should be 845 devised to ensure session continuity in this scenario, even if it is 846 at the cost of a sub-optimal routing. 848 In this section we describe the required extensions to support inter- 849 domain operation. The basic solution consists in using a centralized 850 LMA (usually located in the home domain) as top-level anchor to 851 guarantee session continuity when crossing operator borders. We 852 assume that the necessary roaming agreements are in place in order to 853 support setting up tunnels between the LMA located at the home domain 854 of the MN and the visited D-GWs. 856 +---------------------------------------------------+ 857 ( Home Operator's core ) 858 ( ) 859 ( +-----+ ) 860 ( /| LMA |\ ) 861 ( //+-----+\\ ) 862 ( // \\ ) 863 +------------------//-----------\\------------------+ 864 . (tunnel) // \\ (tunnel) . 865 . // \\ . 866 . // \\ . 867 . // \\ . 868 +---------------+ +---------------+ 869 | IP stack | | IP stack | 870 +---------------+ +-------+-------+ 871 | mn1dgw1 |--+ (DLIFs) +--|mn1dgw1|mn1dgw2|--+ 872 +---------------+ | | +-------+-------+ | 873 | phy interface | | | | phy interface | | 874 +---------------+ | | +---------------+ | 875 D-GW1@OperatorA (o) (o) D-GW2@OperatorB (o) 876 x x 877 x x 878 prefA::/64 x x prefB::/64 879 (AdvPrefLft=0) x x 880 (o) 881 | 882 +-----+ 883 prefA::MN1 | MN1 | prefB::MN1 884 (deprecated) +-----+ 886 Figure 5: Simultaneous anchoring of multiple flows across multiple 887 operators 889 Figure 5 shows an example of the inter-domain operation. MN1 890 initially attaches to D-GW1 (which belongs to OperatorA), and 891 configures prefA::MN1 address out of one prefix anchored at D-GW1 892 (prefA::/64). If MN1 moves to D-GW2, which is managed by OperatorB, 893 tunnels need to be established via the centralized LMA at the MN1's 894 operators core, since we assume that no direct tunneling is possible 895 between D-GWs belonging to different operators. In this case, D-GW3 896 establishes one tunnel with the centralized LMA to send/receive 897 traffic using prefA::/64. From the point of view of D-GW2, the 898 operation is just as if the LMA was the D-GW anchoring this prefix. 899 Analogously, the LMA establishes one tunnel with D-GW1 (from the 900 point of view of D-GW1, the LMA is the current serving D-GW of MN1). 901 Regarding the signaling, it is similar to the intra-operator 902 scenario, though in this case the PBU/PBA sequence is performed 903 twice, once between D-GW2 and the LMA, and another one between the 904 LMA and D-GW1 (i.e., because two different tunnels are created). 906 6. IANA Considerations 908 This document defines new mobility options that require IANA actions. 910 7. Security Considerations 912 The protocol extensions defined in this document share the same 913 security concerns of Proxy Mobile IPv6 [RFC5213]. It is recommended 914 that the signaling messages, Proxy Binding Update and Proxy Binding 915 Acknowledgment, exchanged between the distributed gateways, or 916 between a distributed gateway and a centralized local mobility 917 anchor, are protected using IPsec using the established security 918 association between them. This essentially eliminates the threats 919 related to the impersonation of a distributed gateway or the local 920 mobility anchor. 922 8. References 924 8.1. Normative References 926 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 927 Requirement Levels", BCP 14, RFC 2119, March 1997. 929 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 930 More-Specific Routes", RFC 4191, November 2005. 932 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 933 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 934 September 2007. 936 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 937 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 939 [RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support 940 in IPv6", RFC 6275, July 2011. 942 8.2. Informative References 944 [I-D.bernardos-dmm-pmip] 945 Bernardos, C., Oliva, A., and F. Giust, "A PMIPv6-based 946 solution for Distributed Mobility Management", 947 draft-bernardos-dmm-pmip-02 (work in progress), July 2013. 949 [I-D.chan-distributed-mobility-ps] 950 Chan, A., "Problem statement for distributed and dynamic 951 mobility management", 952 draft-chan-distributed-mobility-ps-05 (work in progress), 953 October 2011. 955 [I-D.ietf-dmm-best-practices-gap-analysis] 956 Liu, D., Zuniga, J., Seite, P., Chan, A., and C. 957 Bernardos, "Distributed Mobility Management: Current 958 practices and gap analysis", 959 draft-ietf-dmm-best-practices-gap-analysis-01 (work in 960 progress), June 2013. 962 [I-D.ietf-dmm-requirements] 963 Chan, A., Liu, D., Seite, P., Yokota, H., and J. Korhonen, 964 "Requirements for Distributed Mobility Management", 965 draft-ietf-dmm-requirements-09 (work in progress), 966 September 2013. 968 [I-D.seite-dmm-dma] 969 Seite, P., Bertin, P., and J. Lee, "Distributed Mobility 970 Anchoring", draft-seite-dmm-dma-06 (work in progress), 971 January 2013. 973 [commag.dmm-standards] 974 Zuniga, JC., Bernardos, CJ., de la Oliva, A., Melia, T., 975 Costa, R., and A. Reznik, "Distributed mobility 976 management: a standards landscape", IEEE Communications 977 Magazine Vol. 51, No. 3, March 2013. 979 Appendix A. Implementation experience 981 The DLIF concept can be easily implemented using features that are 982 usually available on several OSs. Among the possible mechanisms that 983 can be used to do it, the Linux macvlan support allows the creation 984 of different logical interfaces over the same physical one. Each 985 logical interface appears as a regular interface to the Linux OS 986 (which can be configured normally), and it supports configuring the 987 MAC address exposed by the logical interface. The destination MAC 988 address is used by the OS to decide which logical interface 989 (configured on top of a physical interface) is in charge of 990 processing an incoming L2 frame. 992 The EU FP7 MEDIEVAL project implemented a prototype of the DLIF 993 concept using the Linux macvlan support, the radvd daemon, the Linux 994 Advanced Routing and Traffic Control features and the standard 995 iproute2 collection of utilities: 997 o The macvlan support enables iproute2 tools to be able to create, 998 destroy and configure DLIFs on demand over a single physical 999 interface. One of the important features that needs to be 1000 configured is the logical MAC address exposed by the DLIF, as well 1001 as the IPv6 addresses, as they should remain the same regardless 1002 of the serving D-GW where the DLIF is configured. 1004 o Since the distributed logical interfaces created using the macvlan 1005 support appear as regular network interfaces, they can be used 1006 normally in the radvd configuration file. Them, by dynamically 1007 modifying the radvd configuration file and reloading it, we can 1008 control the router advertisements sent to each MN (e.g., 1009 advertizing new IPv6 prefixes, deprecating prefixes anchored at 1010 other serving D-GWs, announcing RFC 4191 specific routes or 1011 changing router preferences). 1013 o Each time a DLIF is created, it is also needed to properly 1014 configure source-based IPv6 routes, as well as tunnels (in case of 1015 handover). This is supported by the Linux Advanced Routing and 1016 Traffic Control features. 1018 o Last, but not least, current Linux kernels support the 1019 configuration of RFC 4191 specific routes (by processing Route 1020 Information Options contained in RAs). The kernel support can be 1021 easily enabled by using the 1022 net.conf.ipv6.*.accept_ra_rt_info_max_plen kernel configuration 1023 parameter. 1025 Appendix B. Public demonstrations 1027 The DLIF concept has been demonstrated, together with the network- 1028 based DMM solution described in [I-D.bernardos-dmm-pmip], during the 1029 83rd IETF in Paris (March 2012) and the 87th IETF in Berlin (August 1030 2013). 1032 The first demo showcased a scenario composed of three "anchor 1033 routers", a "centralized LMA" for control plane, a "mobile node" and 1034 two "correspondent nodes" (one of them being a legacy IPv6 camera). 1035 The mobile node could move between the different anchor routers, 1036 getting a different locally anchor IPv6 address at each location, and 1037 being the reachability of each address maintained. 1039 In the second demo, integration with content delivery nodes (CDNs) 1040 was also shown, showcasing the advantages that the use of a DMM 1041 solution brings to this popular scenario. 1043 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/