idnits 2.17.00 (12 Aug 2021) /tmp/idnits28014/draft-thubert-mext-global-haha-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC3963], [RFC3775]), 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 seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 3, 2009) is 4698 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: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MEXT P. Thubert, Ed. 3 Internet-Draft Cisco Systems 4 Intended status: Standards Track R. Wakikawa 5 Expires: January 4, 2010 Toyota ITC 6 V. Devarapalli 7 Azaire Networks 8 July 3, 2009 10 Global HA to HA protocol 11 draft-thubert-mext-global-haha-01 13 Status of this Memo 15 This Internet-Draft is submitted to IETF in full conformance with the 16 provisions of BCP 78 and BCP 79. This document may contain material 17 from IETF Documents or IETF Contributions published or made publicly 18 available before November 10, 2008. The person(s) controlling the 19 copyright in some of this material may not have granted the IETF 20 Trust the right to allow modifications of such material outside the 21 IETF Standards Process. Without obtaining an adequate license from 22 the person(s) controlling the copyright in such materials, this 23 document may not be modified outside the IETF Standards Process, and 24 derivative works of it may not be created outside the IETF Standards 25 Process, except to format it for publication as an RFC or to 26 translate it into languages other than English. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF), its areas, and its working groups. Note that 30 other groups may also distribute working documents as Internet- 31 Drafts. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 The list of current Internet-Drafts can be accessed at 39 http://www.ietf.org/ietf/1id-abstracts.txt. 41 The list of Internet-Draft Shadow Directories can be accessed at 42 http://www.ietf.org/shadow.html. 44 This Internet-Draft will expire on January 4, 2010. 46 Copyright Notice 48 Copyright (c) 2009 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents in effect on the date of 53 publication of this document (http://trustee.ietf.org/license-info). 54 Please review these documents carefully, as they describe your rights 55 and restrictions with respect to this document. 57 Abstract 59 This HAHA protocol extends MIPv6 [RFC3775] and NEMO [RFC3963] to 60 remove their link layer dependencies on the Home Link and distribute 61 the HAs at IP layer. Global HAHA considers the distribution at the 62 scale of the Internet, and introduces the MIP proxy for Local 63 Mobility Management and Route Optimization in the Infrastructure. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 2. Motivations . . . . . . . . . . . . . . . . . . . . . . . . . 5 69 2.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 5 70 2.2. Layer 3 operations . . . . . . . . . . . . . . . . . . . . 5 71 2.3. Route Optimization . . . . . . . . . . . . . . . . . . . . 6 72 2.4. Single point of failure . . . . . . . . . . . . . . . . . 9 73 3. Rationale for the proposed solution . . . . . . . . . . . . . 9 74 4. A proxy for Mobile IP . . . . . . . . . . . . . . . . . . . . 9 75 5. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 76 5.1. Initial routing . . . . . . . . . . . . . . . . . . . . . 12 77 5.1.1. External routing . . . . . . . . . . . . . . . . . . . 12 78 5.1.2. Internal routing . . . . . . . . . . . . . . . . . . . 13 79 5.2. Binding . . . . . . . . . . . . . . . . . . . . . . . . . 14 80 5.2.1. Direct primary binding . . . . . . . . . . . . . . . . 14 81 5.2.2. local proxy binding . . . . . . . . . . . . . . . . . 14 82 5.2.3. Foreign proxy binding . . . . . . . . . . . . . . . . 15 83 5.3. Route Optimizations . . . . . . . . . . . . . . . . . . . 16 84 5.3.1. Leaking MNP routes in the HAHA network . . . . . . . . 17 85 5.3.2. On-demand proxy routes . . . . . . . . . . . . . . . . 18 86 6. Terminology and concepts . . . . . . . . . . . . . . . . . . . 20 87 7. Distributed Home Network . . . . . . . . . . . . . . . . . . . 22 88 8. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 23 89 9. Mobile Router Operation . . . . . . . . . . . . . . . . . . . 23 90 9.1. Locating Home . . . . . . . . . . . . . . . . . . . . . . 23 91 9.2. Proxy MIP client . . . . . . . . . . . . . . . . . . . . . 23 92 10. Home Agent Operation . . . . . . . . . . . . . . . . . . . . . 23 93 10.1. Locating the other HAs that serve the same Home . . . . . 23 94 10.2. Locating the HA that owns the binding for a HoA . . . . . 23 95 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24 96 12. IANA considerations . . . . . . . . . . . . . . . . . . . . . 24 97 13. Security Considerations . . . . . . . . . . . . . . . . . . . 24 98 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 99 14.1. informative reference . . . . . . . . . . . . . . . . . . 24 100 14.2. normative reference . . . . . . . . . . . . . . . . . . . 24 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 103 1. Introduction 105 The reader of this document is expected to be familiar with both the 106 Mobile IPv6 [RFC3775] and NEMO Basic Support [RFC3963] documents. As 107 such, the reader is expected to understand the concept of a Home Link 108 and the Neighbor Discovery related operations that take place over 109 that link. 111 Home Agent global distribution is useful when a Mobile Router moves 112 geographically large area such as airplane, vehicle, etc... The 113 overhead of the basic NEMO protocol is redundant route caused by the 114 bi-directional tunnel between a Home Agent and a Mobile Router. If a 115 Mobile Router moves far away from a Home Agent, the overhead can not 116 be ignored. 118 Thus, it is reasonable to consider that a Mobile Router dynamically 119 switches to the topologically closest Home Agent (Home Link). This 120 distribution is also effective for load-balancing. The Home Agent is 121 expected to serve thousands of Mobile Routers on its Home Link and 122 tunnels all packets for the Mobile Routers by itself. 124 But with NEMO basic support and MIPv6, Home is locally anchored to 125 the Home Link at Layer 2, so Home can not be distributed 126 geographically. In particular for NEMO, what's needed is a route to 127 a mobile prefix via a tunnel end point that is the CareOf address of 128 the Mobile Router. The Home Address is but a practical artifact that 129 is mostly needed as a correlator for the registration. 131 This draft proposes a model that enables the HA to HA communication 132 at Layer 3, allowing to get rid of the Home Link in configurations 133 where it's not needed. 135 This draft also introduces the concept of proxy Home Agent, enabling 136 a Mobile Router to binding locally as it is roaming far from any of 137 its own Home Agents. 139 Finally, the draft presents how the Home Agents and the proxy Home 140 Agents can use the concept of route projection to improve the data 141 path between Mobile Routers. 143 2. Motivations 145 2.1. Requirements 147 This draft addresses two generic requirements expressed in the Nemo 148 requirements [RFC4886]: 150 Local Mobility and Global Mobility: Multihoming is mentioned as 151 desirable. The global mobility type is not expected to be limited 152 for any consideration other than administrative and security 153 policies. 155 Scalability: NEMO support signaling and processing is expected to 156 scale to a potentially large number of mobile networks. Thus 157 draft extends the scalality of the NEMO basic protocol. 159 There is a requirement from airplane companies which want to be at 160 Home in the various airports that their planes visit. In fact, this 161 is expressed in an abstract fashion by the case (1,n,1) of the NEMO 162 multihoming issues [RFC4980] draft: "Single MR, Multiple HAs, Single 163 NEMO-Prefix". 165 There is also a general direction that indicates that NEMO could be 166 extended as a solution for VPN. To get there, we must ensure that 167 NEMO is upscaled to the classical capabilities of VPN, including the 168 global distribution of Points Of Presence. It is a classical feature 169 for VPNs to allow the roaming users to connect to the closest point 170 of presence into their company VPN. The same feature can not be 171 provided with MIPv6 or NEMO, because the Home depends on a link that 172 has a unique physical location. 174 2.2. Layer 3 operations 176 Mobile IPv6 [RFC3775] standarizes an interface between a Mobile Node 177 and its Home Agent and its correspondents, as well as an interface 178 between Home Agents. One angle of the MIPv6 operation is that the 179 protocols hides the MN mobility by making as if the Mobile Node was 180 always connected to a Home Link. The connectivity is maintained by 181 Home Agents that are permanently and physically attached to that Home 182 Link. 184 So the model for MIPv6 is Home Link centric and it is no surprise 185 that it extends IPv6 Neighbor Discovery [RFC4861] for its operations, 186 in particular for HAs to discover each others, and to discover when 187 one of them has a binding for a Mobile Node, and which one. An 188 immediate consequence of being Link centric is that Home can not be 189 distributed at Layer 3, locally within a site or over the Internet. 191 the NEMO Basic Support [RFC3963] inherits the concept of Home Link 192 and MIPv6 operations on that link, making NEMO partially a link layer 193 operation. On the other hand, the NEMO Basic Support also operates 194 as a routing protocol at L3, for example when it injects routes in 195 the explicit prefix mode. So NEMO operations are somewhat half L2 196 and half L3. 198 What we are getting at with the HAHA protocol is placing NEMO fully 199 at L3. This mostly means the replacement of all ND based exchanges 200 by some equivalent, but at Layer 3, over the Internet Protocol. This 201 also means the abstraction of the concept of Home Address into a 202 globally unique router ID, as opposed to an address from a Home Link. 204 So even if this paper trivially applies to Mobile IPv6, we place our 205 descriptions in the context of NEMO, and use MRs where MIPv6 MNs 206 could fit as well. 208 2.3. Route Optimization 210 MIPv6 comes with a Route Optimization scheme that enables a direct 211 MR-CN conversation, bypassing the Home Agent. With the basic 212 support, NEMO does not have such a support yet. In any case, RO 213 comes at an additional cost in terms of protocol, which varies with 214 the degree of expected trust. 216 Without Route optimization, all the packets MR-CN flow via the Home 217 Agent; this increases both the cost and the latency. The resulting 218 path can be illustrated like this: 220 CN1 <--------------------- -- -- -----------------+ +---> CN2 221 (NYC) | | (NICE) 222 | | 223 | | 224 | | 225 | | 226 MRHA tunnel | | 227 ===================== == == ================ 228 MR <--------------------- -- -- ----------------- HA (BRITTANY) 229 (NJ) ===================== == == ================ 230 | 231 | 232 ----- 233 ///// 234 Home Link 236 Figure 1: Current model with a Home Link 238 The routing overhead becomes costly when: 240 The distance ||MR, CN|| is much smaller then the sum of the 241 distances ||MR, HA|| + ||HA, CN||. 243 AND 245 ||MR, HA||+||HA, CN|| is costly. If the 3 points are very close, 246 the overhead is relatively important, but small in absolute terms. 248 In the picture above, say that a European phone (MR) is roaming in 249 New Jersey but Homed in Brittany. And say that the phone owner 250 places a call in New York city to CN1. Without RO, the voice packets 251 flow back and forth over the peering lines between Brittany and the 252 US, and the routing overhead causes an additional latency that 253 decreases the perceived quality of the phone call. 255 On the other hand, calling CN2 would result in a small, acceptable 256 overhead, considering that the distance ||HA, CN2|| is very small 257 with regards to ||MR, HA|| or ||MR, CN2||. Now, when the MR moves 258 back to Brittany and places a new call to CN2, going via the HA might 259 double the distance, but the whole thing being local, it is 260 negligible. 262 The geographical distribution of Home generalizes this latter 263 situation. If we can get rid of the concept of a Home Link that 264 anchors the HA in a single location, then we can distribute HAs 265 geographically, and, hopefully, one is close to our MR when it's 266 roaming. 268 So if a MR can locate and bind with a closeby HA, then ||MR, HA|| is 269 contained and the overhead is globally limited. In a same fashion, 270 when a CN sends a packet to the MR, it finds a HA closeby and the 271 overhead ||HA, CN|| is contained as well. 273 CN1 <-----+ +-----> CN2 274 (NYC) | | (NICE) 275 | | 276 | | 277 | | 278 | long distance | 279 | HAHA tunnel | 280 =========== == == ================= 281 HA' ------------ -- -- ------------------ HA (BRITTANY) 282 (DC) =========== == == ================= 283 || | || (under the Atlantic :) 284 || | || 285 || | || short distance 286 || | || MRHA Tunnel 287 || | || 288 v 289 MR (NJ) 291 Figure 2: Globally Distributed HA for World Wide service 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 Figure 3: Illustrating that the overhead can be relatively small 317 2.4. Single point of failure 319 The Home Link is a single point of failure for MIPv6/NEMO operations. 321 Should the Home Link fail, the whole set of MNs / MRs is disconnected 322 from the rest of the world. One could decide to use a virtual link 323 for Home, but then: 325 MIPv6 provides a support for multiple HAs, with the DHAAD mechanism. 326 This mechanism helps scaling up the Home by adding HAs dynamically, 327 and eventually load balancing the bindings between them. But this 328 all relies on HAHA communication over the PHYSICAL Home Link; so 329 making that link virtual implies a single Home Agent. 331 In turn this makes the HA a single point of failure, and disables the 332 scalability that the DHAAD mechanism provides to MIPv6. 334 3. Rationale for the proposed solution 336 For the time being, the precise flows are not elaborated. One idea 337 is that a protocol such as IS-IS or OSPFv3 could help a lot, mostly 338 in the registration phase. Another is that HAs should be proactively 339 preassigned to receive a given set of registration, in order to allow 340 a certain degree of aggregation within sites and in between site. 341 Finally, the concept of proxy is introduced to limit the number of 342 primary sites (to 1?) and as a key element for an upcoming NEMO route 343 optimization scheme, where routes can be echanged in a trusted 344 fashion between proxies. 346 4. A proxy for Mobile IP 348 The draft references extensively a MIP proxy HA function. The word 349 proxy, here, is taken in a classical sense, like, for instance, a web 350 proxy: a MIP proxy Home Agent acts as a HA for the MN and as a MN for 351 the HA, the CN, and other proxies. In particular, the MIP proxy 352 terminates the MR-HA tunnel and the associated encryption, extracts 353 the packets, and reencapsulates them to the destination. 355 This differs from a proxy-MIP function, which performs the Mobile 356 Node operation on behalf of a non MIP-enabled node, in order to 357 manage its mobility transparently. 359 +-------+ +-------+ 360 | | | | 361 | HA 1 | | HA 2 | 362 | | | | 363 +-------+ +-------+ 364 primary ^ primary ^ 365 binding | binding | 366 +-------+ +-------+ +-------+ 367 | | --------->| |---------->| | 368 | MN/MR | proxy |proxy 1| secondary |proxy 2| 369 | 1 | binding | | binding | | 370 +-------+ +-------+ +-------+ 371 RO | proxy ^ 372 binding v binding | 373 +-------+ +-------+ 374 | | | | 375 | CN | | MN/MR | 376 | | | 2 | 377 +-------+ +-------+ 379 Figure 4: MIP proxy Home Agent 381 Distributing widely the MIP proxies presents a number of advantages: 383 Route Optimization: a proxy-to-proxy path between to MNs/MRs could 384 be much shorter then the path via the HAs. 386 Local Mobility Management: when the MN moves around a given proxy, 387 but keeps binding to that same proxy, the proxy does not need to 388 inform the primary HA. 390 Nested NEMO: when Mobile Routers attach to one another and form a 391 nested NEMO, the corresponding MRHA tunnel are nested as well. If 392 they all bind to a same proxy, the proxy will decapsulate all the 393 levels of tunneling, and retunnel only once towards the Internet 395 5. Overview 397 This description covers the specific case of a Partitioned Home 398 Network. Home is subnetted and the subnets are attributed to the 399 distributed sites. As a result, in a given location, HAs will be 400 operating both as primary HA taking the registrations for the local 401 partition and proxy HA for registrations that belong to other sites. 402 Additional satellite sites might be deployed around some of the main 403 sites. 405 ## ## 406 ## ## ## 407 ##\ || ||proxy/parent 408 \\ || || tunnel 409 \\ ---||---- ...... ... ----||--- 410 \\| | .... .... ... | | 411 \ @---@ | .... ..... | @---@ | 412 ## ----- | X | --------------------------------- \ / ------## 413 ## ----- @---@ .... HAHA tunnel .... @ ------## 414 | --------------------------------- | 415 ------\ \ ... .... / /-||--- 416 \ \... .../ / || 417 \.\. /./ || 418 .\.\ internet /./. || 419 .\.\ ........... / /... ## 420 ...\ \ / / .. ## 421 .. \ \ / / ... 422 ...\ \ / / ... 423 ..\ \ ...... / /... 424 \.\ . ...... .././ 425 @ primary HA \ \ .. / / 426 \ \ --------- / / 427 ## proxy HA or \ \ @ @ / / 428 ## satellite site \ \ / / 429 \ @ /-----## 430 -- | / \ ------## 431 | | primary site | @ @ | 432 -- --------- 434 Figure 5: Overview 436 It is out of the scope of this document to discuss how the subnetting 437 was decided and configured. It is also out of the scope of this 438 document to describe the operations within a site where more than one 439 HA is deployed. It is expected that in each primary site, HAs 440 discover each other, mesh using tunnels, and form an area that owns 441 the partition of Home that was assigned to that site. 443 5.1. Initial routing 445 5.1.1. External routing 447 Sites are expected to be connected locally to the internet, via the 448 network of one or more service provider. Each site has a default 449 route to the internet via that connection. 451 . .. / 452 --------- ........ ..;. --------- 453 | | .. / ..... | | 454 | ::/0 -> .... ; ... <- ::/0 | 455 | ============HAHA=TUNNEL=========== | 456 | | .... ; .... | | 457 | | .<- Home::/16 / Home::/16 ->..| | 458 --------- ... ; ... --------- 459 ..... / .. 460 . ;.... ...... 461 / .......... 463 In return, each site advertises a Home aggregation to the internet. 464 The Home aggregation has a very short prefix which should be 465 partitioned amongst a number of Service Providers and subnetted to 466 serve as Distributed Home Networks for their customers. One could 467 visualize this aggregation as a subway for Mobile Nodes. 469 ...... 470 --------- ....... .../ --------- 471 | | ..... ; .... | | 472 | ---------------------------------- | 473 | <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< | 474 | v ------------HAHA-tunnel----------- ^ | 475 | v | / .| ^ | 476 | \ ==MRHA== / ... | ^ | 477 | HA >---------- MR ; .. | ^ | 478 | / =tunnel= / .| ^ | 479 | v | ; | ^ | 480 | >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> CN >>>>>> HA | 481 | | . ; ... | | 482 --------- . / ... --------- 483 ... ;.... ...... 484 / .......... 486 Thus, a site attracts the DHAAD requests from any MR that happens to 487 be roaming close to the site, regardless of the MR primary site. So 488 MRs bind to the closest site from their physical location. In a same 489 fashion, CNs send all packets to LFNs via the closest Home site. But 490 packets back flow directly from the site where the MR is bound. 492 5.1.2. Internal routing 494 In each site, border HAs are elected to mesh with peers in other 495 sites. Sites are interconnected over a mesh tunnels and private 496 links. Routing between sites obeys the traditional rules of the 497 Internet, using for instance an Exterior Gateway Protocol (like BGP) 498 between different service providers, and an IGP within a Distributed 499 Home Network. 501 Between sites of a given Distributed Home Network, it might be 502 preferable to form a fully meshed backbone, in order to limit the 503 cost of routing and optimize the paths. 505 ...... 506 --------- ....... .../ --------- 507 | site1 | ..... ; .... | Site2| 508 | ---------------------------------- | 509 | Home:Site2::/48 -> <- Home:Site1::/48 | 510 | ------------HAHA-tunnel----------- | 511 | @ @ @ | / .| @ @ | 512 | @ @ | <- Home::/16 ; Home::/16 -> | @ @ @ | 513 --------- . / ... --------- 514 ... ....; ...... 515 /.......... 517 It can be expected that, in order to scale, satellite sites would be 518 deployed to take the proxy bindings but would not participate to the 519 HAHA protocol that happens between the primary sites - at least when 520 a proactive version of HAHA is being used. 522 ...... 523 --------- ....... .../. --------- 524 | Sat1 | ..... ; .... | Site1 | 525 | ---------------------------------- | 526 | Home::/16 -> <- Home:Site1:Sat1:/64 | 527 | ----proxyHAHA-tunnel-------------- | 528 | #### | / .| @ @ @ | 529 | #### | <- Home::/16 ; Home::/16 -> | @ @ | 530 --------- . / ... --------- 531 ... ....; ...... 532 /.......... 534 In a satellite site, HAs are only proxy, never primary. Each proxy 535 HA has at least one assigned parent HA, which belongs to a primary 536 site. A tunnel is established between the proxy HA and the parent 537 HA. The parent advertises the Home Aggregation to the proxy over 538 that tunnel, as it does over the internet. In return, the proxy 539 advertises its own prefixes, and redistributes the Home Aggregation 540 over the internet. Finally, the parent redistributes the route to 541 the proxy's network into its area, via itself, as an external route. 543 5.2. Binding 545 At that point, the primary sites are ready to accept bindings, either 546 directly from Mobile Routers or via proxy HAs. This is the runtime 547 phase for HAHA. 549 A MR that is located close to its primary site will register there 550 for its primary binding. In that case, the binding is direct. 551 Otherwise, the MR will use a proxy in order to bind locally, and the 552 proxy will perform the primary binding on behalf of the MR. If the 553 proxy is parented at the primary site, the binding is local; 554 otherwise, it is called a foreign binding. 556 5.2.1. Direct primary binding 558 When the primary HA accepts a direct binding from a MR, then it must 559 let the other primaries know that it owns the binding for that Home 560 Address, in a fashion that is discussed in Section 10.2. 562 ...... 563 ......../. ... --------------------------- 564 ... ; .. | Site1 | 565 .. / Home::/16 ->.| @--@--@ | 566 ... ; .. | / | 567 .... / MR ==MRHA==== @ <- Home:site1:MNP::/64 | 568 .... ; | .. | \ | 569 ... / ------ ... | @--@ | 570 ... ; MNP | | 571 ... / .. ... --------------------------- 572 ........... 574 Figure 6: Primary HA injects necessary MR routes in area 576 The primary HA installs all (implicit and explicit) routes to the MR 577 MNPs over the MRHA tunnel. It must also inject any required route, 578 such as explicit prefix routes, into the primary area, as external 579 routes via itself. All these routes are summarized at the area 580 border and the other areas are not affected by the routing change. 582 5.2.2. local proxy binding 584 When a MR binds to a satellite site, a HA acts as a proxy and binds 585 in turn with a primary site, on behalf of that MR, to create the 586 primary binding. The proxy binding can only succeed if the primary 587 binding does. If the primary accepts the binding, then it returns a 588 positive Binding Ack, with the list of the prefixes that are routed 589 via the Mobile Router. 591 .. ........ 592 --------- .. . ... ------------------ 593 | Sat1 | .. /. | Site1 | 594 | | <- Home::/16 ; . | | 595 | | .. / .. | | 596 | ---> =========================== @ <- Home:site1 | 597 | | |. / .. | :MNP::/64 | 598 | -- # ======= MR ; ... | | 599 | | . | / | | 600 --------- . ----- ; ... ------------------ 601 MNP.../.. 603 Then the proxy HA installs the routes that it got from the the 604 positive Binding Acknowledgement over the proxy MRHA tunnel, and 605 Acknowledges the proxy BU. Once a primary binding has succeeded, the 606 proxy might establish secondary bindings with other sites. 608 5.2.3. Foreign proxy binding 610 When a MR binds to a foreign site, whether the site is primary or 611 satellite, a HA from the site acts as a proxy as if the site was a 612 satellite from the primary. 614 ----------------- .. .. ... ----------------- 615 | Foreign site | .. .. | . | MR primary Site | 616 | ------------------------ | 617 | +-------------------------------------- primary | 618 | | +----------proxyHAHA----------------- | 619 | | | ------------------------ ^ | 620 | | | | . | ^ | 621 -------|| ||----- .. | .. ----------------- 622 || || - . - . - . - . - . 623 -------|| ||----- | . 624 | | | |. |MNP . .. 625 | proxy --MRHA--- MR-| | ... 626 | HA --------- | | ... 627 | | .. . . 628 |Foreign satellite|<- Home::/16 | . 629 ----------------- ... .. ... 631 5.3. Route Optimizations 633 When the MR binds in a foreign location, the transport between an 634 arbitrary correspondent and the MR within the HAHA network might be 635 far from optimized. 637 As a result of the primary binding, a proxyHAHA tunnel is established 638 between the proxy and the primary HA. That tunnel is itself 639 encapsulated in the HAHA tunnels when packets flow over the internet. 641 .. .. |... 642 ----------------- .. . ... ----------------- 643 | Foreign site | .. | . | MR primary Site | 644 | ------------------------ | 645 | +-------------------------------------- primary | 646 | |v<<<<<<<<<<>>>>>>>>> MR-| . .. | site:: | 656 | --------- | | ...| /48 | 657 | | . ..| ^ | 658 |Foreign satellite|<- Home::/16 | . |Foreign ^ site | 659 ----------------- . .. ------| ^ |------ 660 - . - . - . - .- . - . - . - | ^ | 661 ... .. ------| ^ |------ 662 .. ...| ^ | 663 ... CN >>>>Home::/16>>>>> | 664 ... ..| | 665 .. ..| | 666 ..... Home::/16 ->| | 667 ..... ....... |Foreign satellite| 668 .......... ----------------- 670 Figure 7: The path from CN to MR is not optimized 672 Also, packets from an arbitrary correspondent reach the site that is 673 closest to the correspondent, then forwarded to the primary site for 674 the destination. Within the primary site, they are encapsulated 675 towards the proxy and sent across the HAHA network again. Finally 676 they reach the proxy that decapsulates the packets and encapsulates 677 them back. 679 In order to improve this, various possibilities are offered: 681 5.3.1. Leaking MNP routes in the HAHA network 683 The proxy can establish a secondary binding with its parent. In 684 return, the parent redistributes an external route to the MNP via 685 itself, and leaks that route inside the whole HAHA network. 687 .. .. |... 688 ----------------- .. . .. 689 | Foreign site | .. | . 690 | ----------------------------------+ 691 | parentHA <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< | 692 | ------------------------------+ ^ | 693 | |v| | . | ^ | 694 -------||v||----- .. | .. | ^ | 695 ||v|| - . - . - . - . - . - . - | ^ | 696 -------||v||----- | . ------| ^ |------ 697 | |v| |. . .. | home: | 698 | --MRHA--- |MNP | ... | site: | 699 | proxyHA >>>>>>>>>> MR-| . .. | mnp:: | 700 | --------- | | ...| /64 | 701 | | . ..| ^ | 702 | egress satellite|<- Home::/16 | . |Foreign ^ site | 703 ----------------- . .. ------| ^ |------ 704 - . - . - . - .- . - . - . - | ^ | 705 ... .. ------| ^ |------ 706 .. ...| ^ | 707 ... CN >>>>Home::/16>>>>> | 708 ... ..| | 709 .. ..| | 710 ..... Home::/16 ->| | 711 ..... ....... |ingress satellite| 712 .......... ----------------- 714 Figure 8: The path from CN to MR bypasses the primary HA 716 This bypasses the primary home agent for packet forwarding. Note 717 that the packets still flow within the HAHA network between the 718 ingress site close to the correspondent and the egress (satellite) 719 site. 721 Note also that when the proxy HA binds to either its parent or the 722 primary HA, it uses an address from within the HAHA network (its HAHA 723 Address), as CareOf. 725 5.3.2. On-demand proxy routes 727 The proxy can establish a secondary binding with the correspondent's 728 proxy provided there's such a node. It might be envisioned to adapt 729 NHRP [RFC2735] for IPv6 in order to discover the remote tunnel end 730 point. 732 ----------------- .... 733 | | .... .. 734 | egress satellite|<- Home::/16 | . .. 735 | | .. . 736 | --MRHA--- |MNP1 .. 737 | proxyHA >>>>>>>>>> MR1-| .. 738 | --------- | ... 739 | ^ | .. 740 ------| ^ |------ .. 741 .... | ^ | . 742 .. | ^ | proxy-to-proxy ... 743 ... | ^ | on demand tunnel ... 744 .. | ^ | .. 745 - . -| ^ |. - . - . - .- . - . - . - . - 746 ------| ^ |------ .. 747 | ^ | ..... 748 | ^ --MRHA--- |MNP2 ..... 749 | proxyHA <<<<<<<<<< MR2-| .... 750 | --------- | ... 751 | |. .. 752 |ingress satellite|<- Home::/16 ... 753 | | ... .... 754 ----------------- ............ 756 Figure 9: The path is now direct between the proxies 758 An example of application is when two proxies from a same Home 759 establish a cross binding. In fact, the Mobile Routers are unaware 760 of the Route Optimization that takes place. This feature might be 761 desirable when the privacy of the location is an issue for the 762 service provider. 764 As part of the secondary binding to the ingress proxy, the egress 765 proxy passes all the MNPs for the MR. This can be done using HAHA 766 signalling, as explicit prefix routes. It is expected that the 767 proxies belong to a chain of trust that links the primary and the 768 satellite sites together. This, the ingress proxy trusts the egress 769 proxy both for the binding and for the explicit prefixes. 771 The routes are literally projected from a proxy to the other while 772 unseen by node in between; this is why this model is called Route 773 Projection, by opposition with the traditional model of route 774 injection which impacts the nodes on the way and is problematic with 775 mobility. 777 Note that in that case, the binding uses the proxy's external address 778 as careof. The packets are thus routed straight between the proxies, 779 outside of the HAHA network. 781 6. Terminology and concepts 783 Most of the mobility related terms used in this document are defined 784 in the Mobility Related Terminology document [RFC3753] and in the 785 Mobile IPv6 specification [RFC3775]. 787 Additionally, some terms were created or extended for NEMO. These 788 specific terms are defined in the NEMO Terminology document 789 [RFC4885]. 791 This draft introduces the following definitions: 793 Distributed Home Network: In distributed home network, a global Home 794 is advertised by several sites that are geographically distributed 795 and meshed using tunnels in a VPN fashion. Mobile Nodes locate 796 the closest site using DHAAD and bind there. More in Section 7... 798 Partitioned Home Network: A Partitioned Home is a specific 799 deployment of a Distributed Home Network where each location owns 800 a subnet of Home. The local Home Agents accept registration for 801 the local partition. The local HAs also act as NEMO proxy HAs for 802 the rest of Home. 804 Primary Home Agent: A Home Agent that can serve a Binding Update 805 from a Mobile Router. The Mobile Router is always associated with 806 a (set of) primary Home Agent (s) to register its binding. 808 Proxy Home Agent: This is a form of proxy, for the NEMO protocol. A 809 proxy HA acts as a HA for MRs to register, but needs to register 810 to a primary HA in order to accept the binding. 812 Primary site: A site is primary for a MR if at least one local HA on 813 that site can accept a registration for that MR. When Home is not 814 partitioned and sites overlap, primary HAs for a same subnet have 815 to be aware of each other in order to find if a binding already 816 exists in one of the sites and in which Home Agent. 818 satellite site: A site that is not primary for any binding. It is 819 dependent on a parent primary site for HAHA operations. satellite 820 sites are deployed around central primary sites, and one final 821 goal for HAHA is to dynamically draw routes between satellite 822 sites in order to shortcut the backbone of primary HAs. 824 Secondary site: A site is secondary for a MR if it is primary for 825 other MRs but not that one. HAs in a secondary site can act as 826 proxies for that MR, and the site is its own parent. 828 Primary Binding: A Binding is primary if it happens with a primary 829 Home Agent, whether the client is a MR or a proxy HA. 831 Secondary Binding: A Binding is secondary if it happens between a 832 proxy and a non primary Home Agent. It is used to improve the 833 path between sites towards the HA where a MR is registered. 835 Proxy Binding: A Binding is proxy if it happens between a MR and a 836 proxy HA, whether the proxy is a pure proxy HA or a secondary HA 837 acting as proxy for that MR. The proxy HA relays the proxy 838 binding to a primary HA in a primary binding. It may maintain a 839 set of secondary bindings, depending on the deployment. 841 Direct Binding: A Binding that does not pass via a proxy, straight 842 between the MR and its Home Agent. 844 7. Distributed Home Network 846 This section describes a detailed example how multiple Home Agents 847 are configured in different routing domains. You are encouraged to 848 read the nemo basic Home Network Models [RFC4887] draft before going 849 through this section. 851 HA HA 852 | ______ | 853 --+-----+--+- . -+- . -+-- TUNNEL --+-----+--+- . -+- .. -+-- 854 | | | | ______ | | | | 855 MR1 MR2 MRi MRN MR1 MR2 MRi MRN 856 ------ ------ ------ ------ ------ ------ ---- - ---- 857 /64 A:B:1:i::/64 /64 A:B:n:i::/64 859 Distributed Home Network /48 860 <------------------------------------------------------------------> 862 extended HN Aggregated HN Virtual HN 863 <----------------------><---------------------->...<---------------> 865 Home Mob Mob Mob Mob Mob Mob Mob 866 <-----><----->...<-----><-----><----->...<----->...<----->...<-----> 868 In distributed home network, a global Home is advertised by several 869 sites that are geographically distributed and meshed using tunnels in 870 a VPN fashion. Mobile Nodes locate the closest site using DHAAD 871 against the global Home Network and bind there. Some form of inter- 872 site synchronization (e.g. a routing protocol), which Mobile IPv6 and 873 Nemo Basic Support do not provide, must take place in order to allow 874 packets to be routed between the incoming site to the Mobile Node. 875 The HAHA (Home Agent to Home Agent) protocol is being designed for 876 that purpose. 878 In one model, called the Partitioned Home Network each site is 879 responsible for a subnet of Home. When a Mobile Node roams far from 880 its natural (primary) site, it registers to a Home Agent on a remote 881 site, that takes the registration and notifies at least the natural 882 site of the foreign registration. 884 One specific advantage of not relying on a Home Link for HAHA 885 communication is that for a large configuration, the Home Agents can 886 be organized hierarchically and distributed geographically, as a set 887 of local clusters linked together to form a global Home Network. 889 8. Message Formats 891 A traditional IGP coul be used over the HAHA tunnel. But in order to 892 integrate HAHA smoothly with the rest of the MIP operation, this 893 drafts suggest to use the messages and formats detailed in the HAHA 894 specification [I-D.wakikawa-mip6-nemo-haha-spec]. 896 9. Mobile Router Operation 898 9.1. Locating Home 900 9.2. Proxy MIP client 902 10. Home Agent Operation 904 10.1. Locating the other HAs that serve the same Home 906 10.2. Locating the HA that owns the binding for a HoA 908 At the time of processing a binding update, a Home Agent (be it 909 primary or simply proxy for the binding Home Address) needs to 910 discover if the binding already exists with a primary Home Agent. 911 There are at least 3 approaches that might be deployed for that 912 purpose: 914 Reactive: This method is also referred to as 'on-demand'. In case 915 of a binding cache miss, a primary Home Agent floods a Binding 916 Information Request message to all the other primary Home Agents 917 for the home address that is sought for. The reactive approach 918 can be used between a satellite site and its parent site even when 919 the primary HAs use an other method in the backbone. 921 Proactive: The binding information is shared proactively between the 922 primary Home Agents for the existing bindings. All primary HAs 923 know at any point of time which Home Addresses are bound and with 924 which primary Home Agent. This approach is preferred for stable 925 configurations, for instance if NEMO is used as a tool to simplify 926 the configuration and reconfiguration of mostly stable networks. 928 Predictive: Ranges of Home Addresses and prefixes are preassigned to 929 the Home Agents, following a rule that is shared or commonly 930 computed by all HAs. A partitioned Home Network is an example of 931 that, but this is mostly useful within a site between local Home 932 Agents. 934 11. Acknowledgements 936 The authors wish to thank: 938 12. IANA considerations 940 This document does not require any IANA action. 942 13. Security Considerations 944 This document explores how t use the haha protocol but does not 945 standardize any new operation that would be harmful. 947 14. References 949 14.1. informative reference 951 [I-D.wakikawa-mip6-nemo-haha-spec] 952 Wakikawa, R., "Inter Home Agents Protocol Specification", 953 draft-wakikawa-mip6-nemo-haha-spec-01 (work in progress), 954 March 2006. 956 [RFC3753] Manner, J. and M. Kojo, "Mobility Related Terminology", 957 RFC 3753, June 2004. 959 [RFC4885] Ernst, T. and H-Y. Lach, "Network Mobility Support 960 Terminology", RFC 4885, July 2007. 962 [RFC4886] Ernst, T., "Network Mobility Support Goals and 963 Requirements", RFC 4886, July 2007. 965 [RFC4887] Thubert, P., Wakikawa, R., and V. Devarapalli, "Network 966 Mobility Home Network Models", RFC 4887, July 2007. 968 [RFC4980] Ng, C., Ernst, T., Paik, E., and M. Bagnulo, "Analysis of 969 Multihoming in Network Mobility Support", RFC 4980, 970 October 2007. 972 14.2. normative reference 974 [RFC2735] Fox, B. and B. Petri, "NHRP Support for Virtual Private 975 Networks", RFC 2735, December 1999. 977 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 978 in IPv6", RFC 3775, June 2004. 980 [RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. 981 Thubert, "Network Mobility (NEMO) Basic Support Protocol", 982 RFC 3963, January 2005. 984 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 985 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 986 September 2007. 988 Authors' Addresses 990 Pascal Thubert (editor) 991 Cisco Systems 992 Village d'Entreprises Green Side 993 400, Avenue de Roumanille 994 Batiment T3 995 Biot - Sophia Antipolis 06410 996 FRANCE 998 Phone: +33 497 23 26 34 999 Email: pthubert@cisco.com 1001 Ryuji Wakikawa 1002 Toyota ITC 1003 6-6-20 Akasaka, Minato-ku 1004 Tokyo 107-0052 1005 JAPAN 1007 Phone: +81-3-5561-8276 1008 Email: ryuji@jp.toyota-itc.com 1010 Vijay Devarapalli 1011 Azaire Networks 1012 3121 Jay Street 1013 Santa Clara, CA 94054 1014 USA 1016 Email: vijay.devarapalli@azairenet.com