idnits 2.17.00 (12 Aug 2021) /tmp/idnits1047/draft-thubert-dmm-global-haha-00.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: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 2) being 60 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC3963], [RFC6275]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 18, 2013) is 3130 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'I-D.wakikawa-mip6-nemo-haha-spec' is mentioned on line 879, but not defined Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DMM P. Thubert, Ed. 3 Internet-Draft Cisco 4 Intended status: Informational R. Wakikawa 5 Expires: April 19, 2014 Softbank Mobile 6 V. Devarapalli 7 WiChorus 8 October 18, 2013 10 Global HA to HA protocol 11 draft-thubert-dmm-global-haha-00 13 Abstract 15 This HAHA protocol extends MIPv6 [RFC6275] and NEMO [RFC3963] to 16 remove their link layer dependencies on the Home Link and distribute 17 the HAs at IP layer. Global HAHA considers the distribution at the 18 scale of the Internet, and introduces the MIP proxy for Local 19 Mobility Management and Route Optimization in the Infrastructure. 21 Status of this Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on April 19, 2014. 38 Copyright Notice 40 Copyright (c) 2013 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents (http://trustee.ietf.org/ 45 license-info) in effect on the date of publication of this document. 46 Please review these documents carefully, as they describe your rights 47 and restrictions with respect to this document. Code Components 48 extracted from this document must include Simplified BSD License text 49 as described in Section 4.e of the Trust Legal Provisions and are 50 provided without warranty as described in the Simplified BSD License. 52 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Motivations . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 3 56 2.2. Layer 3 operations . . . . . . . . . . . . . . . . . . . . 4 57 2.3. Route Optimization . . . . . . . . . . . . . . . . . . . . 5 58 2.4. Single point of failure . . . . . . . . . . . . . . . . . 7 59 3. Rationale for the proposed solution . . . . . . . . . . . . . 7 60 4. A proxy for Mobile IP . . . . . . . . . . . . . . . . . . . . 7 61 5. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 62 5.1. Initial routing . . . . . . . . . . . . . . . . . . . . . 9 63 5.1.1. External routing . . . . . . . . . . . . . . . . . . . 9 64 5.1.2. Internal routing . . . . . . . . . . . . . . . . . . . 10 65 5.2. Binding . . . . . . . . . . . . . . . . . . . . . . . . . 11 66 5.2.1. Direct primary binding . . . . . . . . . . . . . . . . 12 67 5.2.2. local proxy binding . . . . . . . . . . . . . . . . . 12 68 5.2.3. Foreign proxy binding . . . . . . . . . . . . . . . . 13 69 5.3. Route Optimizations . . . . . . . . . . . . . . . . . . . 13 70 5.3.1. Leaking MNP routes in the HAHA network . . . . . . . . 14 71 5.3.2. On-demand proxy routes . . . . . . . . . . . . . . . . 15 72 6. Terminology and concepts . . . . . . . . . . . . . . . . . . . 16 73 7. Distributed Home Network . . . . . . . . . . . . . . . . . . . 18 74 8. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 18 75 9. Mobile Router Operation . . . . . . . . . . . . . . . . . . . 19 76 9.1. Locating Home . . . . . . . . . . . . . . . . . . . . . . 19 77 9.2. Proxy MIP client . . . . . . . . . . . . . . . . . . . . . 19 78 10. Home Agent Operation . . . . . . . . . . . . . . . . . . . . . 19 79 10.1. Locating the other HAs that serve the same Home . . . . . 19 80 10.2. Locating the HA that owns the binding for a HoA . . . . . 19 81 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 82 12. IANA considerations . . . . . . . . . . . . . . . . . . . . . 19 83 13. Security Considerations . . . . . . . . . . . . . . . . . . . 19 84 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 85 14.1. informative reference . . . . . . . . . . . . . . . . . . 20 86 14.2. normative reference . . . . . . . . . . . . . . . . . . . 20 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 89 1. Introduction 91 This draft was initially submitted as draft-thubert-nemo-global-haha 92 in 2004, but the object of the work is now being considered at DMM, 93 so the draft is republished there to provide an historical reference. 95 Over the ten years since the draft was originally published, IPv6 96 mobility evolved in particular with the introduction of Proxy Mobile 97 IPv6 (PMIP) [RFC5213] and the Locator/ID Separation Protocol (LISP) 98 [RFC6830]. It can be noted that the MIP proxy introduced in this 99 document is a Route Optimization function, entirely different from a 100 PMIP proxy function. 102 The MIP proxy in global HAHA is probably still relevant since it 103 allows the separation of the interaction with 1) the client, 2) the 104 HAs and 3)other MIP proxies, which can be individually based on 105 traditional protocols such as Mobile IPv6 [RFC6275] and NEMO 106 [RFC3963], or more recent approaches such as PMIP and LISP. 108 The reader of this document is expected to be familiar with both the 109 Mobile IPv6 [RFC6275] and NEMO Basic Support [RFC3963] documents. 110 As such, the reader is expected to understand the concept of a Home 111 Link and the Neighbor Discovery related operations that take place 112 over that link. 114 Home Agent global distribution is useful when a Mobile Router moves 115 geographically large area such as airplane, vehicle, etc... The 116 overhead of the basic NEMO protocol is redundant route caused by the 117 bi-directional tunnel between a Home Agent and a Mobile Router. If a 118 Mobile Router moves far away from a Home Agent, the overhead can not 119 be ignored. 121 Thus, it is reasonable to consider that a Mobile Router dynamically 122 switches to the topologically closest Home Agent (Home Link). This 123 distribution is also effective for load-balancing. The Home Agent is 124 expected to serve thousands of Mobile Routers on its Home Link and 125 tunnels all packets for the Mobile Routers by itself. 127 But with NEMO basic support and MIPv6, Home is locally anchored to 128 the Home Link at Layer 2, so Home can not be distributed 129 geographically. In particular for NEMO, what's needed is a route to 130 a mobile prefix via a tunnel end point that is the CareOf address of 131 the Mobile Router. The Home Address is but a practical artifact that 132 is mostly needed as a correlator for the registration. 134 This draft proposes a model that enables the HA to HA communication 135 at Layer 3, allowing to get rid of the Home Link in configurations 136 where it's not needed. 138 This draft also introduces the concept of proxy Home Agent, enabling 139 a Mobile Router to binding locally as it is roaming far from any of 140 its own Home Agents. 142 Finally, the draft presents how the Home Agents and the proxy Home 143 Agents can use the concept of route projection to improve the data 144 path between Mobile Routers. 146 2. Motivations 148 2.1. Requirements 150 This draft addresses two generic requirements expressed in the Nemo 151 requirements [RFC4886]: 153 Local Mobility and Global Mobility: Multihoming is mentioned as 154 desirable. The global mobility type is not expected to be limited 155 for any consideration other than administrative and security 156 policies. 158 Scalability: NEMO support signaling and processing is expected to 159 scale to a potentially large number of mobile networks. Thus 160 draft extends the scalality of the NEMO basic protocol. 162 There is a requirement from airplane companies which want to be at 163 Home in the various airports that their planes visit. In fact, this 164 is expressed in an abstract fashion by the case (1,n,1) of the NEMO 165 multihoming issues [RFC4980] draft: "Single MR, Multiple HAs, Single 166 NEMO-Prefix". 168 There is also a general direction that indicates that NEMO could be 169 extended as a solution for VPN. To get there, we must ensure that 170 NEMO is upscaled to the classical capabilities of VPN, including the 171 global distribution of Points Of Presence. It is a classical feature 172 for VPNs to allow the roaming users to connect to the closest point 173 of presence into their company VPN. The same feature can not be 174 provided with MIPv6 or NEMO, because the Home depends on a link that 175 has a unique physical location. 177 2.2. Layer 3 operations 179 Mobile IPv6 [RFC6275] standarizes an interface between a Mobile Node 180 and its Home Agent and its correspondents, as well as an interface 181 between Home Agents. One angle of the MIPv6 operation is that the 182 protocols hides the MN mobility by making as if the Mobile Node was 183 always connected to a Home Link. The connectivity is maintained by 184 Home Agents that are permanently and physically attached to that Home 185 Link. 187 So the model for MIPv6 is Home Link centric and it is no surprise 188 that it extends IPv6 Neighbor Discovery [RFC4861] for its 189 operations, in particular for HAs to discover each others, and to 190 discover when one of them has a binding for a Mobile Node, and which 191 one. An immediate consequence of being Link centric is that Home can 192 not be distributed at Layer 3, locally within a site or over the 193 Internet. 195 the NEMO Basic Support [RFC3963] inherits the concept of Home Link 196 and MIPv6 operations on that link, making NEMO partially a link layer 197 operation. On the other hand, the NEMO Basic Support also operates 198 as a routing protocol at L3, for example when it injects routes in 199 the explicit prefix mode. So NEMO operations are somewhat half L2 200 and half L3. 202 What we are getting at with the HAHA protocol is placing NEMO fully 203 at L3. This mostly means the replacement of all ND based exchanges 204 by some equivalent, but at Layer 3, over the Internet Protocol. This 205 also means the abstraction of the concept of Home Address into a 206 globally unique router ID, as opposed to an address from a Home Link. 208 So even if this paper trivially applies to Mobile IPv6, we place our 209 descriptions in the context of NEMO, and use MRs where MIPv6 MNs 210 could fit as well. 212 2.3. Route Optimization 214 MIPv6 comes with a Route Optimization scheme that enables a direct 215 MR-CN conversation, bypassing the Home Agent. With the basic 216 support, NEMO does not have such a support yet. In any case, RO 217 comes at an additional cost in terms of protocol, which varies with 218 the degree of expected trust. 220 Without Route optimization, all the packets MR-CN flow via the Home 221 Agent; this increases both the cost and the latency. The resulting 222 path can be illustrated like this: 224 CN1 <--------------------- -- -- -----------------+ +---> CN2 225 (NYC) | | (NICE) 226 | | 227 | | 228 | | 229 | | 230 MRHA tunnel | | 231 ===================== == == ================ 232 MR <--------------------- -- -- ----------------- HA (BRITTANY) 233 (NJ) ===================== == == ================ 234 | 235 | 236 ----- 237 ///// 238 Home Link 240 The routing overhead becomes costly when: 242 The distance ||MR, CN|| is much smaller then the sum of the 243 distances ||MR, HA|| + ||HA, CN||. 245 AND 247 ||MR, HA||+||HA, CN|| is costly. If the 3 points are very close, 248 the overhead is relatively important, but small in absolute terms. 250 In the picture above, say that a European phone (MR) is roaming in 251 New Jersey but Homed in Brittany. And say that the phone owner 252 places a call in New York city to CN1. Without RO, the voice packets 253 flow back and forth over the peering lines between Brittany and the 254 US, and the routing overhead causes an additional latency that 255 decreases the perceived quality of the phone call. 257 On the other hand, calling CN2 would result in a small, acceptable 258 overhead, considering that the distance ||HA, CN2|| is very small 259 with regards to ||MR, HA|| or ||MR, CN2||. Now, when the MR moves 260 back to Brittany and places a new call to CN2, going via the HA might 261 double the distance, but the whole thing being local, it is 262 negligible. 264 The geographical distribution of Home generalizes this latter 265 situation. If we can get rid of the concept of a Home Link that 266 anchors the HA in a single location, then we can distribute HAs 267 geographically, and, hopefully, one is close to our MR when it's 268 roaming. 270 So if a MR can locate and bind with a closeby HA, then ||MR, HA|| is 271 contained and the overhead is globally limited. In a same fashion, 272 when a CN sends a packet to the MR, it finds a HA closeby and the 273 overhead ||HA, CN|| is contained as well. 275 CN1 <-----+ +-----> CN2 276 (NYC) | | (NICE) 277 | | 278 | | 279 | | 280 | long distance | 281 | HAHA tunnel | 282 =========== == == ================= 283 HA' ------------ -- -- ------------------ HA (BRITTANY) 284 (DC) =========== == == ================= 285 || | || (under the Atlantic :) 286 || | || 287 || | || short distance 288 || | || MRHA Tunnel 289 || | || 290 v 291 MR (NJ) 293 In our previous example, we see that a HA' deployed in the East Coast 294 saves the round trip over the Atlantic. There is a new overhead for 295 the call to Europe, though, since an additional path is involved 296 between MR and HA'. Then again, if both ||MR, HA'|| and ||CN2, HA|| 297 are relatively small compared to ||HA, HA'|| then the overhead is 298 acceptable; unless all 3 points are located closeby, in which case, 299 again, the additional cost is acceptable. 301 CN2 (NICE) 302 ^ 303 | 304 HA'(DC) ------------------------------------------------- HA 305 | (BRITTANY) 306 v 307 MR (NJ) 309 <-------------------------------------------------------------> 310 Diagonal (direct path) cost 312 <---------------------------------------------------------------> 313 Via HAs 315 2.4. Single point of failure 317 The Home Link is a single point of failure for MIPv6/NEMO operations. 319 Should the Home Link fail, the whole set of MNs / MRs is disconnected 320 from the rest of the world. One could decide to use a virtual link 321 for Home, but then: 323 MIPv6 provides a support for multiple HAs, with the DHAAD mechanism. 324 This mechanism helps scaling up the Home by adding HAs dynamically, 325 and eventually load balancing the bindings between them. But this 326 all relies on HAHA communication over the PHYSICAL Home Link; so 327 making that link virtual implies a single Home Agent. 329 In turn this makes the HA a single point of failure, and disables the 330 scalability that the DHAAD mechanism provides to MIPv6. 332 3. Rationale for the proposed solution 334 For the time being, the precise flows are not elaborated. One idea 335 is that a protocol such as IS-IS or OSPFv3 could help a lot, mostly 336 in the registration phase. Another is that HAs should be proactively 337 preassigned to receive a given set of registration, in order to allow 338 a certain degree of aggregation within sites and in between site. 339 Finally, the concept of proxy is introduced to limit the number of 340 primary sites (to 1?) and as a key element for an upcoming NEMO route 341 optimization scheme, where routes can be echanged in a trusted 342 fashion between proxies. 344 4. A proxy for Mobile IP 346 The draft references extensively a MIP proxy HA function. The word 347 proxy, here, is taken in a classical sense, like, for instance, a web 348 proxy: a MIP proxy Home Agent acts as a HA for the MN and as a MN for 349 the HA, the CN, and other proxies. In particular, the MIP proxy 350 terminates the MR-HA tunnel and the associated encryption, extracts 351 the packets, and reencapsulates them to the destination. 353 This differs from a proxy-MIP function, which performs the Mobile 354 Node operation on behalf of a non MIP-enabled node, in order to 355 manage its mobility transparently. 357 +-------+ +-------+ 358 | | | | 359 | HA 1 | | HA 2 | 360 | | | | 361 +-------+ +-------+ 362 primary ^ primary ^ 363 binding | binding | 364 +-------+ +-------+ +-------+ 365 | | --------->| |---------->| | 366 | MN/MR | proxy |proxy 1| secondary |proxy 2| 367 | 1 | binding | | binding | | 368 +-------+ +-------+ +-------+ 369 RO | proxy ^ 370 binding v binding | 371 +-------+ +-------+ 372 | | | | 373 | CN | | MN/MR | 374 | | | 2 | 375 +-------+ +-------+ 377 Distributing widely the MIP proxies presents a number of advantages: 379 Route Optimization: a proxy-to-proxy path between to MNs/MRs could be 380 much shorter then the path via the HAs. 382 Local Mobility Management: when the MN moves around a given proxy, 383 but keeps binding to that same proxy, the proxy does not need to 384 inform the primary HA. 386 Nested NEMO: when Mobile Routers attach to one another and form a 387 nested NEMO, the corresponding MRHA tunnel are nested as well. If 388 they all bind to a same proxy, the proxy will decapsulate all the 389 levels of tunneling, and retunnel only once towards the Internet 391 5. Overview 393 This description covers the specific case of a Partitioned Home 394 Network. Home is subnetted and the subnets are attributed to the 395 distributed sites. As a result, in a given location, HAs will be 396 operating both as primary HA taking the registrations for the local 397 partition and proxy HA for registrations that belong to other sites. 398 Additional satellite sites might be deployed around some of the main 399 sites. 401 ## ## 402 ## ## ## 403 ##\ || ||proxy/parent 404 \\ || || tunnel 405 \\ ---||---- ...... ... ----||--- 406 \\| | .... .... ... | | 407 \ @---@ | .... ..... | @---@ | 408 ## ----- | X | --------------------------------- \ / ------## 409 ## ----- @---@ .... HAHA tunnel .... @ ------## 410 | --------------------------------- | 411 ------\ \ ... .... / /-||--- 412 \ \... .../ / || 413 \.\. /./ || 414 .\.\ internet /./. || 415 .\.\ ........... / /... ## 416 ...\ \ / / .. ## 417 .. \ \ / / ... 418 ...\ \ / / ... 419 ..\ \ ...... / /... 420 \.\ . ...... .././ 421 @ primary HA \ \ .. / / 422 \ \ --------- / / 423 ## proxy HA or \ \ @ @ / / 424 ## satellite site \ \ / / 425 \ @ /-----## 426 -- | / \ ------## 427 | | primary site | @ @ | 428 -- --------- 430 It is out of the scope of this document to discuss how the subnetting 431 was decided and configured. It is also out of the scope of this 432 document to describe the operations within a site where more than one 433 HA is deployed. It is expected that in each primary site, HAs 434 discover each other, mesh using tunnels, and form an area that owns 435 the partition of Home that was assigned to that site. 437 5.1. Initial routing 439 5.1.1. External routing 441 Sites are expected to be connected locally to the internet, via the 442 network of one or more service provider. Each site has a default 443 route to the internet via that connection. 445 . .. / 446 --------- ........ ..;. --------- 447 | | .. / ..... | | 448 | ::/0 -> .... ; ... <- ::/0 | 449 | ============HAHA=TUNNEL=========== | 450 | | .... ; .... | | 451 | | .<- Home::/16 / Home::/16 ->..| | 452 --------- ... ; ... --------- 453 ..... / .. 454 . ;.... ...... 455 / .......... 457 In return, each site advertises a Home aggregation to the internet. 458 The Home aggregation has a very short prefix which should be 459 partitioned amongst a number of Service Providers and subnetted to 460 serve as Distributed Home Networks for their customers. One could 461 visualize this aggregation as a subway for Mobile Nodes. 463 ...... 464 --------- ....... .../ --------- 465 | | ..... ; .... | | 466 | ---------------------------------- | 467 | <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< | 468 | v ------------HAHA-tunnel----------- ^ | 469 | v | / .| ^ | 470 | \ ==MRHA== / ... | ^ | 471 | HA >---------- MR ; .. | ^ | 472 | / =tunnel= / .| ^ | 473 | v | ; | ^ | 474 | >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> CN >>>>>> HA | 475 | | . ; ... | | 476 --------- . / ... --------- 477 ... ;.... ...... 478 / .......... 480 Thus, a site attracts the DHAAD requests from any MR that happens to 481 be roaming close to the site, regardless of the MR primary site. So 482 MRs bind to the closest site from their physical location. In a same 483 fashion, CNs send all packets to LFNs via the closest Home site. But 484 packets back flow directly from the site where the MR is bound. 486 5.1.2. Internal routing 488 In each site, border HAs are elected to mesh with peers in other 489 sites. Sites are interconnected over a mesh tunnels and private 490 links. Routing between sites obeys the traditional rules of the 491 Internet, using for instance an Exterior Gateway Protocol (like BGP) 492 between different service providers, and an IGP within a Distributed 493 Home Network. 495 Between sites of a given Distributed Home Network, it might be 496 preferable to form a fully meshed backbone, in order to limit the 497 cost of routing and optimize the paths. 499 ...... 500 --------- ....... .../ --------- 501 | site1 | ..... ; .... | Site2| 502 | ---------------------------------- | 503 | Home:Site2::/48 -> <- Home:Site1::/48 | 504 | ------------HAHA-tunnel----------- | 505 | @ @ @ | / .| @ @ | 506 | @ @ | <- Home::/16 ; Home::/16 -> | @ @ @ | 507 --------- . / ... --------- 508 ... ....; ...... 509 /.......... 511 It can be expected that, in order to scale, satellite sites would be 512 deployed to take the proxy bindings but would not participate to the 513 HAHA protocol that happens between the primary sites - at least when 514 a proactive version of HAHA is being used. 516 ...... 517 --------- ....... .../. --------- 518 | Sat1 | ..... ; .... | Site1 | 519 | ---------------------------------- | 520 | Home::/16 -> <- Home:Site1:Sat1:/64 | 521 | ----proxyHAHA-tunnel-------------- | 522 | #### | / .| @ @ @ | 523 | #### | <- Home::/16 ; Home::/16 -> | @ @ | 524 --------- . / ... --------- 525 ... ....; ...... 526 /.......... 528 In a satellite site, HAs are only proxy, never primary. Each proxy 529 HA has at least one assigned parent HA, which belongs to a primary 530 site. A tunnel is established between the proxy HA and the parent 531 HA. The parent advertises the Home Aggregation to the proxy over 532 that tunnel, as it does over the internet. In return, the proxy 533 advertises its own prefixes, and redistributes the Home Aggregation 534 over the internet. Finally, the parent redistributes the route to 535 the proxy's network into its area, via itself, as an external route. 537 5.2. Binding 539 At that point, the primary sites are ready to accept bindings, either 540 directly from Mobile Routers or via proxy HAs. This is the runtime 541 phase for HAHA. 543 A MR that is located close to its primary site will register there 544 for its primary binding. In that case, the binding is direct. 545 Otherwise, the MR will use a proxy in order to bind locally, and the 546 proxy will perform the primary binding on behalf of the MR. If the 547 proxy is parented at the primary site, the binding is local; 548 otherwise, it is called a foreign binding. 550 5.2.1. Direct primary binding 552 When the primary HA accepts a direct binding from a MR, then it must 553 let the other primaries know that it owns the binding for that Home 554 Address, in a fashion that is discussed in Section 10.2. 556 ...... 557 ......../. ... --------------------------- 558 ... ; .. | Site1 | 559 .. / Home::/16 ->.| @--@--@ | 560 ... ; .. | / | 561 .... / MR ==MRHA==== @ <- Home:site1:MNP::/64 | 562 .... ; | .. | \ | 563 ... / ------ ... | @--@ | 564 ... ; MNP | | 565 ... / .. ... --------------------------- 566 ........... 568 The primary HA installs all (implicit and explicit) routes to the MR 569 MNPs over the MRHA tunnel. It must also inject any required route, 570 such as explicit prefix routes, into the primary area, as external 571 routes via itself. All these routes are summarized at the area 572 border and the other areas are not affected by the routing change. 574 5.2.2. local proxy binding 576 When a MR binds to a satellite site, a HA acts as a proxy and binds 577 in turn with a primary site, on behalf of that MR, to create the 578 primary binding. The proxy binding can only succeed if the primary 579 binding does. If the primary accepts the binding, then it returns a 580 positive Binding Ack, with the list of the prefixes that are routed 581 via the Mobile Router. 583 .. ........ 584 --------- .. . ... ------------------ 585 | Sat1 | .. /. | Site1 | 586 | | <- Home::/16 ; . | | 587 | | .. / .. | | 588 | ---> =========================== @ <- Home:site1 | 589 | | |. / .. | :MNP::/64 | 590 | -- # ======= MR ; ... | | 591 | | . | / | | 592 --------- . ----- ; ... ------------------ 593 MNP.../.. 595 Then the proxy HA installs the routes that it got from the the 596 positive Binding Acknowledgement over the proxy MRHA tunnel, and 597 Acknowledges the proxy BU. Once a primary binding has succeeded, the 598 proxy might establish secondary bindings with other sites. 600 5.2.3. Foreign proxy binding 602 When a MR binds to a foreign site, whether the site is primary or 603 satellite, a HA from the site acts as a proxy as if the site was a 604 satellite from the primary. 606 ----------------- .. .. ... ----------------- 607 | Foreign site | .. .. | . | MR primary Site | 608 | ------------------------ | 609 | +-------------------------------------- primary | 610 | | +----------proxyHAHA----------------- | 611 | | | ------------------------ ^ | 612 | | | | . | ^ | 613 -------|| ||----- .. | .. ----------------- 614 || || - . - . - . - . - . 615 -------|| ||----- | . 616 | | | |. |MNP . .. 617 | proxy --MRHA--- MR-| | ... 618 | HA --------- | | ... 619 | | .. . . 620 |Foreign satellite|<- Home::/16 | . 621 ----------------- ... .. ... 623 5.3. Route Optimizations 625 When the MR binds in a foreign location, the transport between an 626 arbitrary correspondent and the MR within the HAHA network might be 627 far from optimized. 629 As a result of the primary binding, a proxyHAHA tunnel is established 630 between the proxy and the primary HA. That tunnel is itself 631 encapsulated in the HAHA tunnels when packets flow over the internet. 633 .. .. |... 634 ----------------- .. . ... ----------------- 635 | Foreign site | .. | . | MR primary Site | 636 | ------------------------ | 637 | +-------------------------------------- primary | 638 | |v<<<<<<<<<<>>>>>>>>> MR-| . .. | site:: | 648 | --------- | | ...| /48 | 649 | | . ..| ^ | 650 |Foreign satellite|<- Home::/16 | . |Foreign ^ site | 651 ----------------- . .. ------| ^ |------ 652 - . - . - . - .- . - . - . - | ^ | 653 ... .. ------| ^ |------ 654 .. ...| ^ | 655 ... CN >>>>Home::/16>>>>> | 656 ... ..| | 657 .. ..| | 658 ..... Home::/16 ->| | 659 ..... ....... |Foreign satellite| 660 .......... ----------------- 662 Also, packets from an arbitrary correspondent reach the site that is 663 closest to the correspondent, then forwarded to the primary site for 664 the destination. Within the primary site, they are encapsulated 665 towards the proxy and sent across the HAHA network again. Finally 666 they reach the proxy that decapsulates the packets and encapsulates 667 them back. 669 In order to improve this, various possibilities are offered: 671 5.3.1. Leaking MNP routes in the HAHA network 673 The proxy can establish a secondary binding with its parent. In 674 return, the parent redistributes an external route to the MNP via 675 itself, and leaks that route inside the whole HAHA network. 677 .. .. |... 678 ----------------- .. . .. 679 | Foreign site | .. | . 680 | ----------------------------------+ 681 | parentHA <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< | 682 | ------------------------------+ ^ | 683 | |v| | . | ^ | 684 -------||v||----- .. | .. | ^ | 685 ||v|| - . - . - . - . - . - . - | ^ | 686 -------||v||----- | . ------| ^ |------ 687 | |v| |. . .. | home: | 688 | --MRHA--- |MNP | ... | site: | 689 | proxyHA >>>>>>>>>> MR-| . .. | mnp:: | 690 | --------- | | ...| /64 | 691 | | . ..| ^ | 692 | egress satellite|<- Home::/16 | . |Foreign ^ site | 693 ----------------- . .. ------| ^ |------ 694 - . - . - . - .- . - . - . - | ^ | 695 ... .. ------| ^ |------ 696 .. ...| ^ | 697 ... CN >>>>Home::/16>>>>> | 698 ... ..| | 699 .. ..| | 700 ..... Home::/16 ->| | 701 ..... ....... |ingress satellite| 702 .......... ----------------- 704 This bypasses the primary home agent for packet forwarding. Note 705 that the packets still flow within the HAHA network between the 706 ingress site close to the correspondent and the egress (satellite) 707 site. 709 Note also that when the proxy HA binds to either its parent or the 710 primary HA, it uses an address from within the HAHA network (its HAHA 711 Address), as CareOf. 713 5.3.2. On-demand proxy routes 715 The proxy can establish a secondary binding with the correspondent's 716 proxy provided there's such a node. It might be envisioned to adapt 717 NHRP [RFC2735] for IPv6 in order to discover the remote tunnel end 718 point. 720 ----------------- .... 721 | | .... .. 722 | egress satellite|<- Home::/16 | . .. 723 | | .. . 724 | --MRHA--- |MNP1 .. 725 | proxyHA >>>>>>>>>> MR1-| .. 726 | --------- | ... 727 | ^ | .. 728 ------| ^ |------ .. 729 .... | ^ | . 730 .. | ^ | proxy-to-proxy ... 731 ... | ^ | on demand tunnel ... 732 .. | ^ | .. 733 - . -| ^ |. - . - . - .- . - . - . - . - 734 ------| ^ |------ .. 735 | ^ | ..... 736 | ^ --MRHA--- |MNP2 ..... 737 | proxyHA <<<<<<<<<< MR2-| .... 738 | --------- | ... 739 | |. .. 740 |ingress satellite|<- Home::/16 ... 741 | | ... .... 742 ----------------- ............ 744 An example of application is when two proxies from a same Home 745 establish a cross binding. In fact, the Mobile Routers are unaware 746 of the Route Optimization that takes place. This feature might be 747 desirable when the privacy of the location is an issue for the 748 service provider. 750 As part of the secondary binding to the ingress proxy, the egress 751 proxy passes all the MNPs for the MR. This can be done using HAHA 752 signalling, as explicit prefix routes. It is expected that the 753 proxies belong to a chain of trust that links the primary and the 754 satellite sites together. This, the ingress proxy trusts the egress 755 proxy both for the binding and for the explicit prefixes. 757 The routes are literally projected from a proxy to the other while 758 unseen by node in between; this is why this model is called Route 759 Projection, by opposition with the traditional model of route 760 injection which impacts the nodes on the way and is problematic with 761 mobility. 763 Note that in that case, the binding uses the proxy's external address 764 as careof. The packets are thus routed straight between the proxies, 765 outside of the HAHA network. 767 6. Terminology and concepts 769 Most of the mobility related terms used in this document are defined 770 in the Mobility Related Terminology document [RFC3753] and in the 771 Mobile IPv6 specification [RFC6275]. 773 Additionally, some terms were created or extended for NEMO. These 774 specific terms are defined in the NEMO Terminology document 775 [RFC4885]. 777 This draft introduces the following definitions: 779 Distributed Home Network: In distributed home network, a global Home 780 is advertised by several sites that are geographically distributed 781 and meshed using tunnels in a VPN fashion. Mobile Nodes locate 782 the closest site using DHAAD and bind there. More in Section 7... 784 Partitioned Home Network: A Partitioned Home is a specific deployment 785 of a Distributed Home Network where each location owns a subnet of 786 Home. The local Home Agents accept registration for the local 787 partition. The local HAs also act as NEMO proxy HAs for the rest 788 of Home. 790 Primary Home Agent: A Home Agent that can serve a Binding Update from 791 a Mobile Router. The Mobile Router is always associated with a 792 (set of) primary Home Agent (s) to register its binding. 794 Proxy Home Agent: This is a form of proxy, for the NEMO protocol. A 795 proxy HA acts as a HA for MRs to register, but needs to register 796 to a primary HA in order to accept the binding. 798 Primary site: A site is primary for a MR if at least one local HA on 799 that site can accept a registration for that MR. When Home is not 800 partitioned and sites overlap, primary HAs for a same subnet have 801 to be aware of each other in order to find if a binding already 802 exists in one of the sites and in which Home Agent. 804 satellite site: A site that is not primary for any binding. It is 805 dependent on a parent primary site for HAHA operations. satellite 806 sites are deployed around central primary sites, and one final 807 goal for HAHA is to dynamically draw routes between satellite 808 sites in order to shortcut the backbone of primary HAs. 810 Secondary site: A site is secondary for a MR if it is primary for 811 other MRs but not that one. HAs in a secondary site can act as 812 proxies for that MR, and the site is its own parent. 814 Primary Binding: A Binding is primary if it happens with a primary 815 Home Agent, whether the client is a MR or a proxy HA. 817 Secondary Binding: A Binding is secondary if it happens between a 818 proxy and a non primary Home Agent. It is used to improve the 819 path between sites towards the HA where a MR is registered. 821 Proxy Binding: A Binding is proxy if it happens between a MR and a 822 proxy HA, whether the proxy is a pure proxy HA or a secondary HA 823 acting as proxy for that MR. The proxy HA relays the proxy binding 824 to a primary HA in a primary binding. It may maintain a set of 825 secondary bindings, depending on the deployment. 827 Direct Binding: A Binding that does not pass via a proxy, straight 828 between the MR and its Home Agent. 830 7. Distributed Home Network 832 This section describes a detailed example how multiple Home Agents 833 are configured in different routing domains. You are encouraged to 834 read the nemo basic Home Network Models [RFC4887] draft before going 835 through this section. 837 HA HA 838 | ______ | 839 --+-----+--+- . -+- . -+-- TUNNEL --+-----+--+- . -+- .. -+-- 840 | | | | ______ | | | | 841 MR1 MR2 MRi MRN MR1 MR2 MRi MRN 842 ------ ------ ------ ------ ------ ------ ---- - ---- 843 /64 A:B:1:i::/64 /64 A:B:n:i::/64 845 Distributed Home Network /48 846 <------------------------------------------------------------------> 848 extended HN Aggregated HN Virtual HN 849 <----------------------><---------------------->...<---------------> 851 Home Mob Mob Mob Mob Mob Mob Mob 852 <-----><----->...<-----><-----><----->...<----->...<----->...<-----> 854 In distributed home network, a global Home is advertised by several 855 sites that are geographically distributed and meshed using tunnels in 856 a VPN fashion. Mobile Nodes locate the closest site using DHAAD 857 against the global Home Network and bind there. Some form of inter- 858 site synchronization (e.g. a routing protocol), which Mobile IPv6 859 and Nemo Basic Support do not provide, must take place in order to 860 allow packets to be routed between the incoming site to the Mobile 861 Node. The HAHA (Home Agent to Home Agent) protocol is being designed 862 for that purpose. 864 In one model, called the Partitioned Home Network each site is 865 responsible for a subnet of Home. When a Mobile Node roams far from 866 its natural (primary) site, it registers to a Home Agent on a remote 867 site, that takes the registration and notifies at least the natural 868 site of the foreign registration. 870 One specific advantage of not relying on a Home Link for HAHA 871 communication is that for a large configuration, the Home Agents can 872 be organized hierarchically and distributed geographically, as a set 873 of local clusters linked together to form a global Home Network. 875 8. Message Formats 876 A traditional IGP coul be used over the HAHA tunnel. But in order to 877 integrate HAHA smoothly with the rest of the MIP operation, this 878 drafts suggest to use the messages and formats detailed in the HAHA 879 specification [I-D.wakikawa-mip6-nemo-haha-spec]. 881 9. Mobile Router Operation 883 9.1. Locating Home 885 9.2. Proxy MIP client 887 10. Home Agent Operation 889 10.1. Locating the other HAs that serve the same Home 891 10.2. Locating the HA that owns the binding for a HoA 893 At the time of processing a binding update, a Home Agent (be it 894 primary or simply proxy for the binding Home Address) needs to 895 discover if the binding already exists with a primary Home Agent. 896 There are at least 3 approaches that might be deployed for that 897 purpose: 899 Reactive: This method is also referred to as 'on-demand'. In case of 900 a binding cache miss, a primary Home Agent floods a Binding 901 Information Request message to all the other primary Home Agents 902 for the home address that is sought for. The reactive approach 903 can be used between a satellite site and its parent site even when 904 the primary HAs use an other method in the backbone. 906 Proactive: The binding information is shared proactively between the 907 primary Home Agents for the existing bindings. All primary HAs 908 know at any point of time which Home Addresses are bound and with 909 which primary Home Agent. This approach is preferred for stable 910 configurations, for instance if NEMO is used as a tool to simplify 911 the configuration and reconfiguration of mostly stable networks. 913 Predictive: Ranges of Home Addresses and prefixes are preassigned to 914 the Home Agents, following a rule that is shared or commonly 915 computed by all HAs. A partitioned Home Network is an example of 916 that, but this is mostly useful within a site between local Home 917 Agents. 919 11. Acknowledgements 921 The authors wish to thank: 923 12. IANA considerations 925 This document does not require any IANA action. 927 13. Security Considerations 928 This document explores how t use the haha protocol but does not 929 standardize any new operation that would be harmful. 931 14. References 933 14.1. informative reference 935 [RFC3753] Manner, J. and M. Kojo, "Mobility Related Terminology", 936 RFC 3753, June 2004. 938 [RFC4885] Ernst, T. and H-Y. Lach, "Network Mobility Support 939 Terminology", RFC 4885, July 2007. 941 [RFC4886] Ernst, T., "Network Mobility Support Goals and 942 Requirements", RFC 4886, July 2007. 944 [RFC4887] Thubert, P., Wakikawa, R. and V. Devarapalli, "Network 945 Mobility Home Network Models", RFC 4887, July 2007. 947 [RFC4980] Ng, C., Ernst, T., Paik, E. and M. Bagnulo, "Analysis of 948 Multihoming in Network Mobility Support", RFC 4980, 949 October 2007. 951 14.2. normative reference 953 [RFC2735] Fox, B.A. and B. Petri, "NHRP Support for Virtual Private 954 Networks", RFC 2735, December 1999. 956 [RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A. and P. 957 Thubert, "Network Mobility (NEMO) Basic Support Protocol", 958 RFC 3963, January 2005. 960 [RFC4861] Narten, T., Nordmark, E., Simpson, W. and H. Soliman, 961 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 962 September 2007. 964 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K. 965 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 967 [RFC6275] Perkins, C., Johnson, D. and J. Arkko, "Mobility Support 968 in IPv6", RFC 6275, July 2011. 970 [RFC6830] Farinacci, D., Fuller, V., Meyer, D. and D. Lewis, "The 971 Locator/ID Separation Protocol (LISP)", RFC 6830, January 972 2013. 974 Authors' Addresses 975 Pascal Thubert, editor 976 Cisco Systems, Inc 977 Building D 978 45 Allee des Ormes - BP1200 979 MOUGINS - Sophia Antipolis, 06254 980 FRANCE 982 Phone: +33 497 23 26 34 983 Email: pthubert@cisco.com 985 Ryuji Wakikawa 986 Softbank Mobile 987 1-9-1,Higashi-Shimbashi,Minato-Ku 988 Tokyo, 06254105-7322 989 Japan 991 Email: ryuji.wakikawa@gmail.com 993 Vijay Devarapalli 994 WiChorus 995 3590 North First St 996 San Jose, CA, 95134 997 USA 999 Email: vijay@wichorus.com