idnits 2.17.00 (12 Aug 2021) /tmp/idnits25736/draft-thubert-mext-global-haha-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1018. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1029. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1036. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1042. 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 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 18, 2008) is 5177 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 (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MEXT P. Thubert 3 Internet-Draft Cisco 4 Intended status: Standards Track R. Wakikawa 5 Expires: September 19, 2008 Keio University 6 V. Devarapalli 7 Azaire Networks 8 March 18, 2008 10 Global HA to HA protocol 11 draft-thubert-mext-global-haha-00 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on September 19, 2008. 38 Copyright Notice 40 Copyright (C) The IETF Trust (2008). 42 Abstract 44 This HAHA protocol extends MIPv6 [RFC3775] and NEMO [RFC3963] to 45 remove their link layer dependencies on the Home Link and distribute 46 the HAs at IP layer. Global HAHA considers the distribution at the 47 scale of the Internet, and introduces the MIP proxy for Local 48 Mobility Management and Route Optimization in the Infrastructure. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Motivations . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 2.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 4 55 2.2. Layer 3 operations . . . . . . . . . . . . . . . . . . . . 4 56 2.3. Route Optimization . . . . . . . . . . . . . . . . . . . . 5 57 2.4. Single point of failure . . . . . . . . . . . . . . . . . 8 58 3. Rationale for the proposed solution . . . . . . . . . . . . . 8 59 4. A proxy for Mobile IP . . . . . . . . . . . . . . . . . . . . 8 60 5. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 61 5.1. Initial routing . . . . . . . . . . . . . . . . . . . . . 11 62 5.1.1. External routing . . . . . . . . . . . . . . . . . . . 11 63 5.1.2. Internal routing . . . . . . . . . . . . . . . . . . . 12 64 5.2. Binding . . . . . . . . . . . . . . . . . . . . . . . . . 13 65 5.2.1. Direct primary binding . . . . . . . . . . . . . . . . 13 66 5.2.2. local proxy binding . . . . . . . . . . . . . . . . . 13 67 5.2.3. Foreign proxy binding . . . . . . . . . . . . . . . . 14 68 5.3. Route Optimizations . . . . . . . . . . . . . . . . . . . 15 69 5.3.1. Leaking MNP routes in the HAHA network . . . . . . . . 16 70 5.3.2. On-demand proxy routes . . . . . . . . . . . . . . . . 17 71 6. Terminology and concepts . . . . . . . . . . . . . . . . . . . 19 72 7. Distributed Home Network . . . . . . . . . . . . . . . . . . . 21 73 8. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 22 74 9. Mobile Router Operation . . . . . . . . . . . . . . . . . . . 22 75 9.1. Locating Home . . . . . . . . . . . . . . . . . . . . . . 22 76 9.2. Proxy MIP client . . . . . . . . . . . . . . . . . . . . . 22 77 10. Home Agent Operation . . . . . . . . . . . . . . . . . . . . . 22 78 10.1. Locating the other HAs that serve the same Home . . . . . 22 79 10.2. Locating the HA that owns the binding for a HoA . . . . . 22 80 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23 81 12. IANA considerations . . . . . . . . . . . . . . . . . . . . . 23 82 13. Security Considerations . . . . . . . . . . . . . . . . . . . 23 83 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 84 14.1. informative reference . . . . . . . . . . . . . . . . . . 23 85 14.2. normative reference . . . . . . . . . . . . . . . . . . . 23 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 87 Intellectual Property and Copyright Statements . . . . . . . . . . 25 89 1. Introduction 91 The reader of this document is expected to be familiar with both the 92 Mobile IPv6 [RFC3775] and NEMO Basic Support [RFC3963] documents. As 93 such, the reader is expected to understand the concept of a Home Link 94 and the Neighbor Discovery related operations that take place over 95 that link. 97 Home Agent global distribution is useful when a Mobile Router moves 98 geographically large area such as airplane, vehicle, etc... The 99 overhead of the basic NEMO protocol is redundant route caused by the 100 bi-directional tunnel between a Home Agent and a Mobile Router. If a 101 Mobile Router moves far away from a Home Agent, the overhead can not 102 be ignored. 104 Thus, it is reasonable to consider that a Mobile Router dynamically 105 switches to the topologically closest Home Agent (Home Link). This 106 distribution is also effective for load-balancing. The Home Agent is 107 expected to serve thousands of Mobile Routers on its Home Link and 108 tunnels all packets for the Mobile Routers by itself. 110 But with NEMO basic support and MIPv6, Home is locally anchored to 111 the Home Link at Layer 2, so Home can not be distributed 112 geographically. In particular for NEMO, what's needed is a route to 113 a mobile prefix via a tunnel end point that is the CareOf address of 114 the Mobile Router. The Home Address is but a practical artifact that 115 is mostly needed as a correlator for the registration. 117 This draft proposes a model that enables the HA to HA communication 118 at Layer 3, allowing to get rid of the Home Link in configurations 119 where it's not needed. 121 This draft also introduces the concept of proxy Home Agent, enabling 122 a Mobile Router to binding locally as it is roaming far from any of 123 its own Home Agents. 125 Finally, the draft presents how the Home Agents and the proxy Home 126 Agents can use the concept of route projection to improve the data 127 path between Mobile Routers. 129 2. Motivations 131 2.1. Requirements 133 This draft addresses two generic requirements expressed in the Nemo 134 requirements [RFC4886]: 136 Local Mobility and Global Mobility: Multihoming is mentioned as 137 desirable. The global mobility type is not expected to be limited 138 for any consideration other than administrative and security 139 policies. 141 Scalability: NEMO support signaling and processing is expected to 142 scale to a potentially large number of mobile networks. Thus 143 draft extends the scalality of the NEMO basic protocol. 145 There is a requirement from airplane companies which want to be at 146 Home in the various airports that their planes visit. In fact, this 147 is expressed in an abstract fashion by the case (1,n,1) of the NEMO 148 multihoming issues [RFC4980] draft: "Single MR, Multiple HAs, Single 149 NEMO-Prefix". 151 There is also a general direction that indicates that NEMO could be 152 extended as a solution for VPN. To get there, we must ensure that 153 NEMO is upscaled to the classical capabilities of VPN, including the 154 global distribution of Points Of Presence. It is a classical feature 155 for VPNs to allow the roaming users to connect to the closest point 156 of presence into their company VPN. The same feature can not be 157 provided with MIPv6 or NEMO, because the Home depends on a link that 158 has a unique physical location. 160 2.2. Layer 3 operations 162 Mobile IPv6 [RFC3775] standarizes an interface between a Mobile Node 163 and its Home Agent and its correspondents, as well as an interface 164 between Home Agents. One angle of the MIPv6 operation is that the 165 protocols hides the MN mobility by making as if the Mobile Node was 166 always connected to a Home Link. The connectivity is maintained by 167 Home Agents that are permanently and physically attached to that Home 168 Link. 170 So the model for MIPv6 is Home Link centric and it is no surprise 171 that it extends IPv6 Neighbor Discovery [RFC4861] for its operations, 172 in particular for HAs to discover each others, and to discover when 173 one of them has a binding for a Mobile Node, and which one. An 174 immediate consequence of being Link centric is that Home can not be 175 distributed at Layer 3, locally within a site or over the Internet. 177 the NEMO Basic Support [RFC3963] inherits the concept of Home Link 178 and MIPv6 operations on that link, making NEMO partially a link layer 179 operation. On the other hand, the NEMO Basic Support also operates 180 as a routing protocol at L3, for example when it injects routes in 181 the explicit prefix mode. So NEMO operations are somewhat half L2 182 and half L3. 184 What we are getting at with the HAHA protocol is placing NEMO fully 185 at L3. This mostly means the replacement of all ND based exchanges 186 by some equivalent, but at Layer 3, over the Internet Protocol. This 187 also means the abstraction of the concept of Home Address into a 188 globally unique router ID, as opposed to an address from a Home Link. 190 So even if this paper trivially applies to Mobile IPv6, we place our 191 descriptions in the context of NEMO, and use MRs where MIPv6 MNs 192 could fit as well. 194 2.3. Route Optimization 196 MIPv6 comes with a Route Optimization scheme that enables a direct 197 MR-CN conversation, bypassing the Home Agent. With the basic 198 support, NEMO does not have such a support yet. In any case, RO 199 comes at an additional cost in terms of protocol, which varies with 200 the degree of expected trust. 202 Without Route optimization, all the packets MR-CN flow via the Home 203 Agent; this increases both the cost and the latency. The resulting 204 path can be illustrated like this: 206 CN1 <--------------------- -- -- -----------------+ +---> CN2 207 (NYC) | | (NICE) 208 | | 209 | | 210 | | 211 | | 212 MRHA tunnel | | 213 ===================== == == ================ 214 MR <--------------------- -- -- ----------------- HA (BRITTANY) 215 (NJ) ===================== == == ================ 216 | 217 | 218 ----- 219 ///// 220 Home Link 222 Figure 1: Current model with a Home Link 224 The routing overhead becomes costly when: 226 The distance ||MR, CN|| is much smaller then the sum of the 227 distances ||MR, HA|| + ||HA, CN||. 229 AND 231 ||MR, HA||+||HA, CN|| is costly. If the 3 points are very close, 232 the overhead is relatively important, but small in absolute terms. 234 In the picture above, say that a European phone (MR) is roaming in 235 New Jersey but Homed in Brittany. And say that the phone owner 236 places a call in New York city to CN1. Without RO, the voice packets 237 flow back and forth over the peering lines between Brittany and the 238 US, and the routing overhead causes an additional latency that 239 decreases the perceived quality of the phone call. 241 On the other hand, calling CN2 would result in a small, acceptable 242 overhead, considering that the distance ||HA, CN2|| is very small 243 with regards to ||MR, HA|| or ||MR, CN2||. Now, when the MR moves 244 back to Brittany and places a new call to CN2, going via the HA might 245 double the distance, but the whole thing being local, it is 246 negligible. 248 The geographical distribution of Home generalizes this latter 249 situation. If we can get rid of the concept of a Home Link that 250 anchors the HA in a single location, then we can distribute HAs 251 geographically, and, hopefully, one is close to our MR when it's 252 roaming. 254 So if a MR can locate and bind with a closeby HA, then ||MR, HA|| is 255 contained and the overhead is globally limited. In a same fashion, 256 when a CN sends a packet to the MR, it finds a HA closeby and the 257 overhead ||HA, CN|| is contained as well. 259 CN1 <-----+ +-----> CN2 260 (NYC) | | (NICE) 261 | | 262 | | 263 | | 264 | long distance | 265 | HAHA tunnel | 266 =========== == == ================= 267 HA' ------------ -- -- ------------------ HA (BRITTANY) 268 (DC) =========== == == ================= 269 || | || (under the Atlantic :) 270 || | || 271 || | || short distance 272 || | || MRHA Tunnel 273 || | || 274 v 275 MR (NJ) 277 Figure 2: Globally Distributed HA for World Wide service 279 In our previous example, we see that a HA' deployed in the East Coast 280 saves the round trip over the Atlantic. There is a new overhead for 281 the call to Europe, though, since an additional path is involved 282 between MR and HA'. Then again, if both ||MR, HA'|| and ||CN2, HA|| 283 are relatively small compared to ||HA, HA'|| then the overhead is 284 acceptable; unless all 3 points are located closeby, in which case, 285 again, the additional cost is acceptable. 287 CN2 (NICE) 288 ^ 289 | 290 HA'(DC) ------------------------------------------------- HA 291 | (BRITTANY) 292 v 293 MR (NJ) 295 <-------------------------------------------------------------> 296 Diagonal (direct path) cost 298 <---------------------------------------------------------------> 299 Via HAs 301 Figure 3: Illustrating that the overhead can be relatively small 303 2.4. Single point of failure 305 The Home Link is a single point of failure for MIPv6/NEMO operations. 307 Should the Home Link fail, the whole set of MNs / MRs is disconnected 308 from the rest of the world. One could decide to use a virtual link 309 for Home, but then: 311 MIPv6 provides a support for multiple HAs, with the DHAAD mechanism. 312 This mechanism helps scaling up the Home by adding HAs dynamically, 313 and eventually load balancing the bindings between them. But this 314 all relies on HAHA communication over the PHYSICAL Home Link; so 315 making that link virtual implies a single Home Agent. 317 In turn this makes the HA a single point of failure, and disables the 318 scalability that the DHAAD mechanism provides to MIPv6. 320 3. Rationale for the proposed solution 322 For the time being, the precise flows are not elaborated. One idea 323 is that a protocol such as IS-IS or OSPFv3 could help a lot, mostly 324 in the registration phase. Another is that HAs should be proactively 325 preassigned to receive a given set of registration, in order to allow 326 a certain degree of aggregation within sites and in between site. 327 Finally, the concept of proxy is introduced to limit the number of 328 primary sites (to 1?) and as a key element for an upcoming NEMO route 329 optimization scheme, where routes can be echanged in a trusted 330 fashion between proxies. 332 4. A proxy for Mobile IP 334 The draft references extensively a MIP proxy HA function. The word 335 proxy, here, is taken in a classical sense, like, for instance, a web 336 proxy: a MIP proxy Home Agent acts as a HA for the MN and as a MN for 337 the HA, the CN, and other proxies. In particular, the MIP proxy 338 terminates the MR-HA tunnel and the associated encryption, extracts 339 the packets, and reencapsulates them to the destination. 341 This differs from a proxy-MIP function, which performs the Mobile 342 Node operation on behalf of a non MIP-enabled node, in order to 343 manage its mobility transparently. 345 +-------+ +-------+ 346 | | | | 347 | HA 1 | | HA 2 | 348 | | | | 349 +-------+ +-------+ 350 primary ^ primary ^ 351 binding | binding | 352 +-------+ +-------+ +-------+ 353 | | --------->| |---------->| | 354 | MN/MR | proxy |proxy 1| secondary |proxy 2| 355 | 1 | binding | | binding | | 356 +-------+ +-------+ +-------+ 357 RO | proxy ^ 358 binding v binding | 359 +-------+ +-------+ 360 | | | | 361 | CN | | MN/MR | 362 | | | 2 | 363 +-------+ +-------+ 365 Figure 4: MIP proxy Home Agent 367 Distributing widely the MIP proxies presents a number of advantages: 369 Route Optimization: a proxy-to-proxy path between to MNs/MRs could 370 be much shorter then the path via the HAs. 372 Local Mobility Management: when the MN moves around a given proxy, 373 but keeps binding to that same proxy, the proxy does not need to 374 inform the primary HA. 376 Nested NEMO: when Mobile Routers attach to one another and form a 377 nested NEMO, the corresponding MRHA tunnel are nested as well. If 378 they all bind to a same proxy, the proxy will decapsulate all the 379 levels of tunneling, and retunnel only once towards the Internet 381 5. Overview 383 This description covers the specific case of a Partitioned Home 384 Network. Home is subnetted and the subnets are attributed to the 385 distributed sites. As a result, in a given location, HAs will be 386 operating both as primary HA taking the registrations for the local 387 partition and proxy HA for registrations that belong to other sites. 388 Additional satellite sites might be deployed around some of the main 389 sites. 391 ## ## 392 ## ## ## 393 ##\ || ||proxy/parent 394 \\ || || tunnel 395 \\ ---||---- ...... ... ----||--- 396 \\| | .... .... ... | | 397 \ @---@ | .... ..... | @---@ | 398 ## ----- | X | --------------------------------- \ / ------## 399 ## ----- @---@ .... HAHA tunnel .... @ ------## 400 | --------------------------------- | 401 ------\ \ ... .... / /-||--- 402 \ \... .../ / || 403 \.\. /./ || 404 .\.\ internet /./. || 405 .\.\ ........... / /... ## 406 ...\ \ / / .. ## 407 .. \ \ / / ... 408 ...\ \ / / ... 409 ..\ \ ...... / /... 410 \.\ . ...... .././ 411 @ primary HA \ \ .. / / 412 \ \ --------- / / 413 ## proxy HA or \ \ @ @ / / 414 ## satellite site \ \ / / 415 \ @ /-----## 416 -- | / \ ------## 417 | | primary site | @ @ | 418 -- --------- 420 Figure 5: Overview 422 It is out of the scope of this document to discuss how the subnetting 423 was decided and configured. It is also out of the scope of this 424 document to describe the operations within a site where more than one 425 HA is deployed. It is expected that in each primary site, HAs 426 discover each other, mesh using tunnels, and form an area that owns 427 the partition of Home that was assigned to that site. 429 5.1. Initial routing 431 5.1.1. External routing 433 Sites are expected to be connected locally to the internet, via the 434 network of one or more service provider. Each site has a default 435 route to the internet via that connection. 437 . .. / 438 --------- ........ ..;. --------- 439 | | .. / ..... | | 440 | ::/0 -> .... ; ... <- ::/0 | 441 | ============HAHA=TUNNEL=========== | 442 | | .... ; .... | | 443 | | .<- Home::/16 / Home::/16 ->..| | 444 --------- ... ; ... --------- 445 ..... / .. 446 . ;.... ...... 447 / .......... 449 In return, each site advertises a Home aggregation to the internet. 450 The Home aggregation has a very short prefix which should be 451 partitioned amongst a number of Service Providers and subnetted to 452 serve as Distributed Home Networks for their customers. One could 453 visualize this aggregation as a subway for Mobile Nodes. 455 ...... 456 --------- ....... .../ --------- 457 | | ..... ; .... | | 458 | ---------------------------------- | 459 | <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< | 460 | v ------------HAHA-tunnel----------- ^ | 461 | v | / .| ^ | 462 | \ ==MRHA== / ... | ^ | 463 | HA >---------- MR ; .. | ^ | 464 | / =tunnel= / .| ^ | 465 | v | ; | ^ | 466 | >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> CN >>>>>> HA | 467 | | . ; ... | | 468 --------- . / ... --------- 469 ... ;.... ...... 470 / .......... 472 Thus, a site attracts the DHAAD requests from any MR that happens to 473 be roaming close to the site, regardless of the MR primary site. So 474 MRs bind to the closest site from their physical location. In a same 475 fashion, CNs send all packets to LFNs via the closest Home site. But 476 packets back flow directly from the site where the MR is bound. 478 5.1.2. Internal routing 480 In each site, border HAs are elected to mesh with peers in other 481 sites. Sites are interconnected over a mesh tunnels and private 482 links. Routing between sites obeys the traditional rules of the 483 Internet, using for instance an Exterior Gateway Protocol (like BGP) 484 between different service providers, and an IGP within a Distributed 485 Home Network. 487 Between sites of a given Distributed Home Network, it might be 488 preferable to form a fully meshed backbone, in order to limit the 489 cost of routing and optimize the paths. 491 ...... 492 --------- ....... .../ --------- 493 | site1 | ..... ; .... | Site2| 494 | ---------------------------------- | 495 | Home:Site2::/48 -> <- Home:Site1::/48 | 496 | ------------HAHA-tunnel----------- | 497 | @ @ @ | / .| @ @ | 498 | @ @ | <- Home::/16 ; Home::/16 -> | @ @ @ | 499 --------- . / ... --------- 500 ... ....; ...... 501 /.......... 503 It can be expected that, in order to scale, satellite sites would be 504 deployed to take the proxy bindings but would not participate to the 505 HAHA protocol that happens between the primary sites - at least when 506 a proactive version of HAHA is being used. 508 ...... 509 --------- ....... .../. --------- 510 | Sat1 | ..... ; .... | Site1 | 511 | ---------------------------------- | 512 | Home::/16 -> <- Home:Site1:Sat1:/64 | 513 | ----proxyHAHA-tunnel-------------- | 514 | #### | / .| @ @ @ | 515 | #### | <- Home::/16 ; Home::/16 -> | @ @ | 516 --------- . / ... --------- 517 ... ....; ...... 518 /.......... 520 In a satellite site, HAs are only proxy, never primary. Each proxy 521 HA has at least one assigned parent HA, which belongs to a primary 522 site. A tunnel is established between the proxy HA and the parent 523 HA. The parent advertises the Home Aggregation to the proxy over 524 that tunnel, as it does over the internet. In return, the proxy 525 advertises its own prefixes, and redistributes the Home Aggregation 526 over the internet. Finally, the parent redistributes the route to 527 the proxy's network into its area, via itself, as an external route. 529 5.2. Binding 531 At that point, the primary sites are ready to accept bindings, either 532 directly from Mobile Routers or via proxy HAs. This is the runtime 533 phase for HAHA. 535 A MR that is located close to its primary site will register there 536 for its primary binding. In that case, the binding is direct. 537 Otherwise, the MR will use a proxy in order to bind locally, and the 538 proxy will perform the primary binding on behalf of the MR. If the 539 proxy is parented at the primary site, the binding is local; 540 otherwise, it is called a foreign binding. 542 5.2.1. Direct primary binding 544 When the primary HA accepts a direct binding from a MR, then it must 545 let the other primaries know that it owns the binding for that Home 546 Address, in a fashion that is discussed in Section 10.2. 548 ...... 549 ......../. ... --------------------------- 550 ... ; .. | Site1 | 551 .. / Home::/16 ->.| @--@--@ | 552 ... ; .. | / | 553 .... / MR ==MRHA==== @ <- Home:site1:MNP::/64 | 554 .... ; | .. | \ | 555 ... / ------ ... | @--@ | 556 ... ; MNP | | 557 ... / .. ... --------------------------- 558 ........... 560 Figure 10: Primary HA injects necessary MR routes in area 562 The primary HA installs all (implicit and explicit) routes to the MR 563 MNPs over the MRHA tunnel. It must also inject any required route, 564 such as explicit prefix routes, into the primary area, as external 565 routes via itself. All these routes are summarized at the area 566 border and the other areas are not affected by the routing change. 568 5.2.2. local proxy binding 570 When a MR binds to a satellite site, a HA acts as a proxy and binds 571 in turn with a primary site, on behalf of that MR, to create the 572 primary binding. The proxy binding can only succeed if the primary 573 binding does. If the primary accepts the binding, then it returns a 574 positive Binding Ack, with the list of the prefixes that are routed 575 via the Mobile Router. 577 .. ........ 578 --------- .. . ... ------------------ 579 | Sat1 | .. /. | Site1 | 580 | | <- Home::/16 ; . | | 581 | | .. / .. | | 582 | ---> =========================== @ <- Home:site1 | 583 | | |. / .. | :MNP::/64 | 584 | -- # ======= MR ; ... | | 585 | | . | / | | 586 --------- . ----- ; ... ------------------ 587 MNP.../.. 589 Then the proxy HA installs the routes that it got from the the 590 positive Binding Acknowledgement over the proxy MRHA tunnel, and 591 Acknowledges the proxy BU. Once a primary binding has succeeded, the 592 proxy might establish secondary bindings with other sites. 594 5.2.3. Foreign proxy binding 596 When a MR binds to a foreign site, whether the site is primary or 597 satellite, a HA from the site acts as a proxy as if the site was a 598 satellite from the primary. 600 ----------------- .. .. ... ----------------- 601 | Foreign site | .. .. | . | MR primary Site | 602 | ------------------------ | 603 | +-------------------------------------- primary | 604 | | +----------proxyHAHA----------------- | 605 | | | ------------------------ ^ | 606 | | | | . | ^ | 607 -------|| ||----- .. | .. ----------------- 608 || || - . - . - . - . - . 609 -------|| ||----- | . 610 | | | |. |MNP . .. 611 | proxy --MRHA--- MR-| | ... 612 | HA --------- | | ... 613 | | .. . . 614 |Foreign satellite|<- Home::/16 | . 615 ----------------- ... .. ... 617 5.3. Route Optimizations 619 When the MR binds in a foreign location, the transport between an 620 arbitrary correspondent and the MR within the HAHA network might be 621 far from optimized. 623 As a result of the primary binding, a proxyHAHA tunnel is established 624 between the proxy and the primary HA. That tunnel is itself 625 encapsulated in the HAHA tunnels when packets flow over the internet. 627 .. .. |... 628 ----------------- .. . ... ----------------- 629 | Foreign site | .. | . | MR primary Site | 630 | ------------------------ | 631 | +-------------------------------------- primary | 632 | |v<<<<<<<<<<>>>>>>>>> MR-| . .. | site:: | 642 | --------- | | ...| /48 | 643 | | . ..| ^ | 644 |Foreign satellite|<- Home::/16 | . |Foreign ^ site | 645 ----------------- . .. ------| ^ |------ 646 - . - . - . - .- . - . - . - | ^ | 647 ... .. ------| ^ |------ 648 .. ...| ^ | 649 ... CN >>>>Home::/16>>>>> | 650 ... ..| | 651 .. ..| | 652 ..... Home::/16 ->| | 653 ..... ....... |Foreign satellite| 654 .......... ----------------- 656 Figure 13: The path from CN to MR is not optimized 658 Also, packets from an arbitrary correspondent reach the site that is 659 closest to the correspondent, then forwarded to the primary site for 660 the destination. Within the primary site, they are encapsulated 661 towards the proxy and sent across the HAHA network again. Finally 662 they reach the proxy that decapsulates the packets and encapsulates 663 them back. 665 In order to improve this, various possibilities are offered: 667 5.3.1. Leaking MNP routes in the HAHA network 669 The proxy can establish a secondary binding with its parent. In 670 return, the parent redistributes an external route to the MNP via 671 itself, and leaks that route inside the whole HAHA network. 673 .. .. |... 674 ----------------- .. . .. 675 | Foreign site | .. | . 676 | ----------------------------------+ 677 | parentHA <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< | 678 | ------------------------------+ ^ | 679 | |v| | . | ^ | 680 -------||v||----- .. | .. | ^ | 681 ||v|| - . - . - . - . - . - . - | ^ | 682 -------||v||----- | . ------| ^ |------ 683 | |v| |. . .. | home: | 684 | --MRHA--- |MNP | ... | site: | 685 | proxyHA >>>>>>>>>> MR-| . .. | mnp:: | 686 | --------- | | ...| /64 | 687 | | . ..| ^ | 688 | egress satellite|<- Home::/16 | . |Foreign ^ site | 689 ----------------- . .. ------| ^ |------ 690 - . - . - . - .- . - . - . - | ^ | 691 ... .. ------| ^ |------ 692 .. ...| ^ | 693 ... CN >>>>Home::/16>>>>> | 694 ... ..| | 695 .. ..| | 696 ..... Home::/16 ->| | 697 ..... ....... |ingress satellite| 698 .......... ----------------- 700 Figure 14: The path from CN to MR bypasses the primary HA 702 This bypasses the primary home agent for packet forwarding. Note 703 that the packets still flow within the HAHA network between the 704 ingress site close to the correspondent and the egress (satellite) 705 site. 707 Note also that when the proxy HA binds to either its parent or the 708 primary HA, it uses an address from within the HAHA network (its HAHA 709 Address), as CareOf. 711 5.3.2. On-demand proxy routes 713 The proxy can establish a secondary binding with the correspondent's 714 proxy provided there's such a node. It might be envisioned to adapt 715 NHRP [RFC2735] for IPv6 in order to discover the remote tunnel end 716 point. 718 ----------------- .... 719 | | .... .. 720 | egress satellite|<- Home::/16 | . .. 721 | | .. . 722 | --MRHA--- |MNP1 .. 723 | proxyHA >>>>>>>>>> MR1-| .. 724 | --------- | ... 725 | ^ | .. 726 ------| ^ |------ .. 727 .... | ^ | . 728 .. | ^ | proxy-to-proxy ... 729 ... | ^ | on demand tunnel ... 730 .. | ^ | .. 731 - . -| ^ |. - . - . - .- . - . - . - . - 732 ------| ^ |------ .. 733 | ^ | ..... 734 | ^ --MRHA--- |MNP2 ..... 735 | proxyHA <<<<<<<<<< MR2-| .... 736 | --------- | ... 737 | |. .. 738 |ingress satellite|<- Home::/16 ... 739 | | ... .... 740 ----------------- ............ 742 Figure 15: The path is now direct between the proxies 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 [RFC3775]. 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 785 deployment of a Distributed Home Network where each location owns 786 a subnet of Home. The local Home Agents accept registration for 787 the local partition. The local HAs also act as NEMO proxy HAs for 788 the rest of Home. 790 Primary Home Agent: A Home Agent that can serve a Binding Update 791 from a Mobile Router. The Mobile Router is always associated with 792 a (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 824 binding to a primary HA in a primary binding. It may maintain a 825 set of 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 and 859 Nemo Basic Support do not provide, must take place in order to allow 860 packets to be routed between the incoming site to the Mobile Node. 861 The HAHA (Home Agent to Home Agent) protocol is being designed for 862 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 877 A traditional IGP coul be used over the HAHA tunnel. But in order to 878 integrate HAHA smoothly with the rest of the MIP operation, this 879 drafts suggest to use the messages and formats detailed in the HAHA 880 specification [I-D.wakikawa-mip6-nemo-haha-spec]. 882 9. Mobile Router Operation 884 9.1. Locating Home 886 9.2. Proxy MIP client 888 10. Home Agent Operation 890 10.1. Locating the other HAs that serve the same Home 892 10.2. Locating the HA that owns the binding for a HoA 894 At the time of processing a binding update, a Home Agent (be it 895 primary or simply proxy for the binding Home Address) needs to 896 discover if the binding already exists with a primary Home Agent. 897 There are at least 3 approaches that might be deployed for that 898 purpose: 900 Reactive: This method is also referred to as 'on-demand'. In case 901 of a binding cache miss, a primary Home Agent floods a Binding 902 Information Request message to all the other primary Home Agents 903 for the home address that is sought for. The reactive approach 904 can be used between a satellite site and its parent site even when 905 the primary HAs use an other method in the backbone. 907 Proactive: The binding information is shared proactively between the 908 primary Home Agents for the existing bindings. All primary HAs 909 know at any point of time which Home Addresses are bound and with 910 which primary Home Agent. This approach is preferred for stable 911 configurations, for instance if NEMO is used as a tool to simplify 912 the configuration and reconfiguration of mostly stable networks. 914 Predictive: Ranges of Home Addresses and prefixes are preassigned to 915 the Home Agents, following a rule that is shared or commonly 916 computed by all HAs. A partitioned Home Network is an example of 917 that, but this is mostly useful within a site between local Home 918 Agents. 920 11. Acknowledgements 922 The authors wish to thank: 924 12. IANA considerations 926 This document does not require any IANA action. 928 13. Security Considerations 930 This document explores how t use the haha protocol but does not 931 standardize any new operation that would be harmful. 933 14. References 935 14.1. informative reference 937 [I-D.wakikawa-mip6-nemo-haha-spec] 938 Wakikawa, R., "Inter Home Agents Protocol Specification", 939 draft-wakikawa-mip6-nemo-haha-spec-01 (work in progress), 940 March 2006. 942 [RFC3753] Manner, J. and M. Kojo, "Mobility Related Terminology", 943 RFC 3753, June 2004. 945 [RFC4885] Ernst, T. and H-Y. Lach, "Network Mobility Support 946 Terminology", RFC 4885, July 2007. 948 [RFC4886] Ernst, T., "Network Mobility Support Goals and 949 Requirements", RFC 4886, July 2007. 951 [RFC4887] Thubert, P., Wakikawa, R., and V. Devarapalli, "Network 952 Mobility Home Network Models", RFC 4887, July 2007. 954 [RFC4980] Ng, C., Ernst, T., Paik, E., and M. Bagnulo, "Analysis of 955 Multihoming in Network Mobility Support", RFC 4980, 956 October 2007. 958 14.2. normative reference 960 [RFC2735] Fox, B. and B. Petri, "NHRP Support for Virtual Private 961 Networks", RFC 2735, December 1999. 963 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 964 in IPv6", RFC 3775, June 2004. 966 [RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. 967 Thubert, "Network Mobility (NEMO) Basic Support Protocol", 968 RFC 3963, January 2005. 970 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 971 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 972 September 2007. 974 Authors' Addresses 976 Pascal Thubert 977 Cisco Systems 978 Village d'Entreprises Green Side 979 400, Avenue de Roumanille 980 Batiment T3 981 Biot - Sophia Antipolis 06410 982 FRANCE 984 Phone: +33 4 97 23 26 34 985 Email: pthubert@cisco.com 987 Ryuji Wakikawa 988 Keio University Department of Environmental Information 989 5322 Endo Fujisawa Kanagawa 990 252-8520 991 JAPAN 993 Phone: +81-466-49-1100 994 Email: ryuji@sfc.wide.ad.jp 996 Vijay Devarapalli 997 Azaire Networks 998 3121 Jay Street 999 Santa Clara, CA 94054 1000 USA 1002 Email: vijay.devarapalli@azairenet.com 1004 Full Copyright Statement 1006 Copyright (C) The IETF Trust (2008). 1008 This document is subject to the rights, licenses and restrictions 1009 contained in BCP 78, and except as set forth therein, the authors 1010 retain all their rights. 1012 This document and the information contained herein are provided on an 1013 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1014 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1015 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1016 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1017 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1018 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1020 Intellectual Property 1022 The IETF takes no position regarding the validity or scope of any 1023 Intellectual Property Rights or other rights that might be claimed to 1024 pertain to the implementation or use of the technology described in 1025 this document or the extent to which any license under such rights 1026 might or might not be available; nor does it represent that it has 1027 made any independent effort to identify any such rights. Information 1028 on the procedures with respect to rights in RFC documents can be 1029 found in BCP 78 and BCP 79. 1031 Copies of IPR disclosures made to the IETF Secretariat and any 1032 assurances of licenses to be made available, or the result of an 1033 attempt made to obtain a general license or permission for the use of 1034 such proprietary rights by implementers or users of this 1035 specification can be obtained from the IETF on-line IPR repository at 1036 http://www.ietf.org/ipr. 1038 The IETF invites any interested party to bring to its attention any 1039 copyrights, patents or patent applications, or other proprietary 1040 rights that may cover technology that may be required to implement 1041 this standard. Please address the information to the IETF at 1042 ietf-ipr@ietf.org. 1044 Acknowledgment 1046 Funding for the RFC Editor function is provided by the IETF 1047 Administrative Support Activity (IASA).