idnits 2.17.00 (12 Aug 2021) /tmp/idnits30230/draft-thubert-nemo-global-haha-02.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 on line 1074. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1051. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1058. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1064. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([15], [16]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 360 has weird spacing: '...binding v ...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (September 28, 2006) is 5707 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) == Unused Reference: '1' is defined on line 952, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 956, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 980, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 986, but no explicit reference was found in the text == Unused Reference: '12' is defined on line 992, but no explicit reference was found in the text == Unused Reference: '13' is defined on line 995, but no explicit reference was found in the text == Outdated reference: draft-ietf-mip6-bootstrap-ps has been published as RFC 4640 == Outdated reference: draft-ietf-nemo-home-network-models has been published as RFC 4887 == Outdated reference: draft-ietf-nemo-terminology has been published as RFC 4885 == Outdated reference: draft-ietf-nemo-requirements has been published as RFC 4886 == Outdated reference: draft-ietf-nemo-multihoming-issues has been published as RFC 4980 ** Obsolete normative reference: RFC 2460 (ref. '8') (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 2461 (ref. '9') (Obsoleted by RFC 4861) ** Obsolete normative reference: RFC 2462 (ref. '10') (Obsoleted by RFC 4862) ** Obsolete normative reference: RFC 3513 (ref. '12') (Obsoleted by RFC 4291) ** Obsolete normative reference: RFC 3633 (ref. '13') (Obsoleted by RFC 8415) ** Downref: Normative reference to an Informational RFC: RFC 3753 (ref. '14') ** Obsolete normative reference: RFC 3775 (ref. '15') (Obsoleted by RFC 6275) -- Possible downref: Normative reference to a draft: ref. '17' Summary: 11 errors (**), 0 flaws (~~), 15 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Mobility P. Thubert 3 Internet-Draft Cisco 4 Expires: April 1, 2007 R. Wakikawa 5 Keio University 6 V. Devarapalli 7 Nokia 8 September 28, 2006 10 Global HA to HA protocol 11 draft-thubert-nemo-global-haha-02 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 April 1, 2007. 38 Copyright Notice 40 Copyright (C) The Internet Society (2006). 42 Abstract 44 This HAHA protocol extends MIPv6 [15] and NEMO [16] to remove their 45 link layer dependencies on the Home Link and distribute the HAs at IP 46 layer. Global HAHA considers the distribution at the scale of the 47 Internet, and introduces the MIP proxy for Local Mobility Management 48 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. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . 23 84 14.1 Changes from version 00 to 01 . . . . . . . . . . . . . . 23 85 14.2 Changes from version 01 to 02 . . . . . . . . . . . . . . 23 86 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 87 15.1 informative reference . . . . . . . . . . . . . . . . . . 23 88 15.2 normative reference . . . . . . . . . . . . . . . . . . . 24 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 25 90 Intellectual Property and Copyright Statements . . . . . . . . 26 92 1. Introduction 94 The reader of this document is expected to be familiar with both the 95 Mobile IPv6 [15] and NEMO Basic Support [16] documents. As such, the 96 reader is expected to understand the concept of a Home Link and the 97 Neighbor Discovery related operations that take place over that link. 99 Home Agent global distribution is useful when a Mobile Router moves 100 geographically large area such as airplane, vehicle, etc... The 101 overhead of the basic NEMO protocol is redundant route caused by the 102 bi-directional tunnel between a Home Agent and a Mobile Router. If a 103 Mobile Router moves far away from a Home Agent, the overhead can not 104 be ignored. 106 Thus, it is reasonable to consider that a Mobile Router dynamically 107 switches to the topologically closest Home Agent (Home Link). This 108 distribution is also effective for load-balancing. The Home Agent is 109 expected to serve thousands of Mobile Routers on its Home Link and 110 tunnels all packets for the Mobile Routers by itself. 112 But with NEMO basic support and MIPv6, Home is locally anchored to 113 the Home Link at Layer 2, so Home can not be distributed 114 geographically. In particular for NEMO, what's needed is a route to 115 a mobile prefix via a tunnel end point that is the CareOf address of 116 the Mobile Router. The Home Address is but a practical artifact that 117 is mostly needed as a correlator for the registration. 119 This draft proposes a model that enables the HA to HA communication 120 at Layer 3, allowing to get rid of the Home Link in configurations 121 where it's not needed. 123 This draft also introduces the concept of proxy Home Agent, enabling 124 a Mobile Router to binding locally as it is roaming far from any of 125 its own Home Agents. 127 Finally, the draft presents how the Home Agents and the proxy Home 128 Agents can use the concept of route projection to improve the data 129 path between Mobile Routers. 131 2. Motivations 133 2.1 Requirements 135 This draft addresses two generic requirements expressed in the Nemo 136 requirements [5]: 138 Local Mobility and Global Mobility: Multihoming is mentioned as 139 desirable. The global mobility type is not expected to be limited 140 for any consideration other than administrative and security 141 policies. 143 Scalability: NEMO support signaling and processing is expected to 144 scale to a potentially large number of mobile networks. Thus 145 draft extends the scalality of the NEMO basic protocol. 147 There is a requirement from airplane companies which want to be at 148 Home in the various airports that their planes visit. In fact, this 149 is expressed in an abstract fashion by the case (1,n,1) of the NEMO 150 multihoming issues [6] draft: "Single MR, Multiple HAs, Single NEMO- 151 Prefix". 153 There is also a general direction that indicates that NEMO could be 154 extended as a solution for VPN. To get there, we must ensure that 155 NEMO is upscaled to the classical capabilities of VPN, including the 156 global distribution of Points Of Presence. It is a classical feature 157 for VPNs to allow the roaming users to connect to the closest point 158 of presence into their company VPN. The same feature can not be 159 provided with MIPv6 or NEMO, because the Home depends on a link that 160 has a unique physical location. 162 2.2 Layer 3 operations 164 Mobile IPv6 [15] standarizes an interface between a Mobile Node and 165 its Home Agent and its correspondents, as well as an interface 166 between Home Agents. One angle of the MIPv6 operation is that the 167 protocols hides the MN mobility by making as if the Mobile Node was 168 always connected to a Home Link. The connectivity is maintained by 169 Home Agents that are permanently and physically attached to that Home 170 Link. 172 So the model for MIPv6 is Home Link centric and it is no surprise 173 that it extends IPv6 Neighbor Discovery [9] for its operations, in 174 particular for HAs to discover each others, and to discover when one 175 of them has a binding for a Mobile Node, and which one. An immediate 176 consequence of being Link centric is that Home can not be distributed 177 at Layer 3, locally within a site or over the Internet. 179 the NEMO Basic Support [16] inherits the concept of Home Link and 180 MIPv6 operations on that link, making NEMO partially a link layer 181 operation. On the other hand, the NEMO Basic Support also operates 182 as a routing protocol at L3, for example when it injects routes in 183 the explicit prefix mode. So NEMO operations are somewhat half L2 184 and half L3. 186 What we are getting at with the HAHA protocol is placing NEMO fully 187 at L3. This mostly means the replacement of all ND based exchanges 188 by some equivalent, but at Layer 3, over the Internet Protocol. This 189 also means the abstraction of the concept of Home Address into a 190 globally unique router ID, as opposed to an address from a Home Link. 192 So even if this paper trivially applies to Mobile IPv6, we place our 193 descriptions in the context of NEMO, and use MRs where MIPv6 MNs 194 could fit as well. 196 2.3 Route Optimization 198 MIPv6 comes with a Route Optimization scheme that enables a direct 199 MR-CN conversation, bypassing the Home Agent. With the basic 200 support, NEMO does not have such a support yet. In any case, RO 201 comes at an additional cost in terms of protocol, which varies with 202 the degree of expected trust. 204 Without Route optimization, all the packets MR-CN flow via the Home 205 Agent; this increases both the cost and the latency. The resulting 206 path can be illustrated like this: 208 CN1 <--------------------- -- -- -----------------+ +---> CN2 209 (NYC) | | (NICE) 210 | | 211 | | 212 | | 213 | | 214 MRHA tunnel | | 215 ===================== == == ================ 216 MR <--------------------- -- -- ----------------- HA (BRITTANY) 217 (NJ) ===================== == == ================ 218 | 219 | 220 ----- 221 ///// 222 Home Link 224 Figure 1: Current model with a Home Link 226 The routing overhead becomes costly when: 228 The distance ||MR, CN|| is much smaller then the sum of the 229 distances ||MR, HA|| + ||HA, CN||. 231 AND 233 ||MR, HA||+||HA, CN|| is costly. If the 3 points are very close, 234 the overhead is relatively important, but small in absolute terms. 236 In the picture above, say that a European phone (MR) is roaming in 237 New Jersey but Homed in Brittany. And say that the phone owner 238 places a call in New York city to CN1. Without RO, the voice packets 239 flow back and forth over the peering lines between Brittany and the 240 US, and the routing overhead causes an additional latency that 241 decreases the perceived quality of the phone call. 243 On the other hand, calling CN2 would result in a small, acceptable 244 overhead, considering that the distance ||HA, CN2|| is very small 245 with regards to ||MR, HA|| or ||MR, CN2||. Now, when the MR moves 246 back to Brittany and places a new call to CN2, going via the HA might 247 double the distance, but the whole thing being local, it is 248 negligible. 250 The geographical distribution of Home generalizes this latter 251 situation. If we can get rid of the concept of a Home Link that 252 anchors the HA in a single location, then we can distribute HAs 253 geographically, and, hopefully, one is close to our MR when it's 254 roaming. 256 So if a MR can locate and bind with a closeby HA, then ||MR, HA|| is 257 contained and the overhead is globally limited. In a same fashion, 258 when a CN sends a packet to the MR, it finds a HA closeby and the 259 overhead ||HA, CN|| is contained as well. 261 CN1 <-----+ +-----> CN2 262 (NYC) | | (NICE) 263 | | 264 | | 265 | | 266 | long distance | 267 | HAHA tunnel | 268 =========== == == ================= 269 HA' ------------ -- -- ------------------ HA (BRITTANY) 270 (DC) =========== == == ================= 271 || | || (under the Atlantic :) 272 || | || 273 || | || short distance 274 || | || MRHA Tunnel 275 || | || 276 v 277 MR (NJ) 279 Figure 2: Globally Distributed HA for World Wide service 281 In our previous example, we see that a HA' deployed in the East Coast 282 saves the round trip over the Atlantic. There is a new overhead for 283 the call to Europe, though, since an additional path is involved 284 between MR and HA'. Then again, if both ||MR, HA'|| and ||CN2, HA|| 285 are relatively small compared to ||HA, HA'|| then the overhead is 286 acceptable; unless all 3 points are located closeby, in which case, 287 again, the additional cost is acceptable. 289 CN2 (NICE) 290 ^ 291 | 292 HA'(DC) ------------------------------------------------- HA 293 | (BRITTANY) 294 v 295 MR (NJ) 297 <-------------------------------------------------------------> 298 Diagonal (direct path) cost 300 <---------------------------------------------------------------> 301 Via HAs 303 Figure 3: Illustrating that the overhead can be relatively small 305 2.4 Single point of failure 307 The Home Link is a single point of failure for MIPv6/NEMO operations. 309 Should the Home Link fail, the whole set of MNs / MRs is disconnected 310 from the rest of the world. One could decide to use a virtual link 311 for Home, but then: 313 MIPv6 provides a support for multiple HAs, with the DHAAD mechanism. 314 This mechanism helps scaling up the Home by adding HAs dynamically, 315 and eventually load balancing the bindings between them. But this 316 all relies on HAHA communication over the PHYSICAL Home Link; so 317 making that link virtual implies a single Home Agent. 319 In turn this makes the HA a single point of failure, and disables the 320 scalability that the DHAAD mechanism provides to MIPv6. 322 3. Rationale for the proposed solution 324 For the time being, the precise flows are not elaborated. One idea 325 is that a protocol such as IS-IS or OSPFv3 could help a lot, mostly 326 in the registration phase. Another is that HAs should be proactively 327 preassigned to receive a given set of registration, in order to allow 328 a certain degree of aggregation within sites and in between site. 329 Finally, the concept of proxy is introduced to limit the number of 330 primary sites (to 1?) and as a key element for an upcoming NEMO route 331 optimization scheme, where routes can be echanged in a trusted 332 fashion between proxies. 334 4. A proxy for Mobile IP 336 The draft references extensively a MIP proxy HA function. The word 337 proxy, here, is taken in a classical sense, like, for instance, a web 338 proxy: a MIP proxy Home Agent acts as a HA for the MN and as a MN for 339 the HA, the CN, and other proxies. In particular, the MIP proxy 340 terminates the MR-HA tunnel and the associated encryption, extracts 341 the packets, and reencapsulates them to the destination. 343 This differs from a proxy-MIP function, which performs the Mobile 344 Node operation on behalf of a non MIP-enabled node, in order to 345 manage its mobility transparently. 347 +-------+ +-------+ 348 | | | | 349 | HA 1 | | HA 2 | 350 | | | | 351 +-------+ +-------+ 352 primary ^ primary ^ 353 binding | binding | 354 +-------+ +-------+ +-------+ 355 | | --------->| |---------->| | 356 | MN/MR | proxy |proxy 1| secondary |proxy 2| 357 | 1 | binding | | binding | | 358 +-------+ +-------+ +-------+ 359 RO | proxy ^ 360 binding v binding | 361 +-------+ +-------+ 362 | | | | 363 | CN | | MN/MR | 364 | | | 2 | 365 +-------+ +-------+ 367 Figure 4: MIP proxy Home Agent 369 Distributing widely the MIP proxies presents a number of advantages: 371 Route Optimization: a proxy-to-proxy path between to MNs/MRs could be 372 much shorter then the path via the HAs. 374 Local Mobility Management: when the MN moves around a given proxy, 375 but keeps binding to that same proxy, the proxy does not need to 376 inform the primary HA. 378 Nested NEMO: when Mobile Routers attach to one another and form a 379 nested NEMO, the corresponding MRHA tunnel are nested as well. If 380 they all bind to a same proxy, the proxy will decapsulate all the 381 levels of tunneling, and retunnel only once towards the Internet 383 5. Overview 385 This description covers the specific case of a Partitioned Home 386 Network. Home is subnetted and the subnets are attributed to the 387 distributed sites. As a result, in a given location, HAs will be 388 operating both as primary HA taking the registrations for the local 389 partition and proxy HA for registrations that belong to other sites. 390 Additional satellite sites might be deployed around some of the main 391 sites. 393 ## ## 394 ## ## ## 395 ##\ || ||proxy/parent 396 \\ || || tunnel 397 \\ ---||---- ...... ... ----||--- 398 \\| | .... .... ... | | 399 \ @---@ | .... ..... | @---@ | 400 ## ----- | X | --------------------------------- \ / ------## 401 ## ----- @---@ .... HAHA tunnel .... @ ------## 402 | --------------------------------- | 403 ------\ \ ... .... / /-||--- 404 \ \... .../ / || 405 \.\. /./ || 406 .\.\ internet /./. || 407 .\.\ ........... / /... ## 408 ...\ \ / / .. ## 409 .. \ \ / / ... 410 ...\ \ / / ... 411 ..\ \ ...... / /... 412 \.\ . ...... .././ 413 @ primary HA \ \ .. / / 414 \ \ --------- / / 415 ## proxy HA or \ \ @ @ / / 416 ## satellite site \ \ / / 417 \ @ /-----## 418 -- | / \ ------## 419 | | primary site | @ @ | 420 -- --------- 422 Figure 5: Overview 424 It is out of the scope of this document to discuss how the subnetting 425 was decided and configured. It is also out of the scope of this 426 document to describe the operations within a site where more than one 427 HA is deployed. It is expected that in each primary site, HAs 428 discover each other, mesh using tunnels, and form an area that owns 429 the partition of Home that was assigned to that site. 431 5.1 Initial routing 433 5.1.1 External routing 435 Sites are expected to be connected locally to the internet, via the 436 network of one or more service provider. Each site has a default 437 route to the internet via that connection. 439 . .. / 440 --------- ........ ..;. --------- 441 | | .. / ..... | | 442 | ::/0 -> .... ; ... <- ::/0 | 443 | ============HAHA=TUNNEL=========== | 444 | | .... ; .... | | 445 | | .<- Home::/16 / Home::/16 ->..| | 446 --------- ... ; ... --------- 447 ..... / .. 448 . ;.... ...... 449 / .......... 451 In return, each site advertises a Home aggregation to the internet. 452 The Home aggregation has a very short prefix which should be 453 partitioned amongst a number of Service Providers and subnetted to 454 serve as Distributed Home Networks for their customers. One could 455 visualize this aggregation as a subway for Mobile Nodes. 457 ...... 458 --------- ....... .../ --------- 459 | | ..... ; .... | | 460 | ---------------------------------- | 461 | <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< | 462 | v ------------HAHA-tunnel----------- ^ | 463 | v | / .| ^ | 464 | \ ==MRHA== / ... | ^ | 465 | HA >---------- MR ; .. | ^ | 466 | / =tunnel= / .| ^ | 467 | v | ; | ^ | 468 | >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> CN >>>>>> HA | 469 | | . ; ... | | 470 --------- . / ... --------- 471 ... ;.... ...... 472 / .......... 474 Thus, a site attracts the DHAAD requests from any MR that happens to 475 be roaming close to the site, regardless of the MR primary site. So 476 MRs bind to the closest site from their physical location. In a same 477 fashion, CNs send all packets to LFNs via the closest Home site. But 478 packets back flow directly from the site where the MR is bound. 480 5.1.2 Internal routing 482 In each site, border HAs are elected to mesh with peers in other 483 sites. Sites are interconnected over a mesh tunnels and private 484 links. Routing between sites obeys the traditional rules of the 485 Internet, using for instance an Exterior Gateway Protocol (like BGP) 486 between different service providers, and an IGP within a Distributed 487 Home Network. 489 Between sites of a given Distributed Home Network, it might be 490 preferable to form a fully meshed backbone, in order to limit the 491 cost of routing and optimize the paths. 493 ...... 494 --------- ....... .../ --------- 495 | site1 | ..... ; .... | Site2| 496 | ---------------------------------- | 497 | Home:Site2::/48 -> <- Home:Site1::/48 | 498 | ------------HAHA-tunnel----------- | 499 | @ @ @ | / .| @ @ | 500 | @ @ | <- Home::/16 ; Home::/16 -> | @ @ @ | 501 --------- . / ... --------- 502 ... ....; ...... 503 /.......... 505 It can be expected that, in order to scale, satellite sites would be 506 deployed to take the proxy bindings but would not participate to the 507 HAHA protocol that happens between the primary sites - at least when 508 a proactive version of HAHA is being used. 510 ...... 511 --------- ....... .../. --------- 512 | Sat1 | ..... ; .... | Site1 | 513 | ---------------------------------- | 514 | Home::/16 -> <- Home:Site1:Sat1:/64 | 515 | ----proxyHAHA-tunnel-------------- | 516 | #### | / .| @ @ @ | 517 | #### | <- Home::/16 ; Home::/16 -> | @ @ | 518 --------- . / ... --------- 519 ... ....; ...... 520 /.......... 522 In a satellite site, HAs are only proxy, never primary. Each proxy 523 HA has at least one assigned parent HA, which belongs to a primary 524 site. A tunnel is established between the proxy HA and the parent 525 HA. The parent advertises the Home Aggregation to the proxy over 526 that tunnel, as it does over the internet. In return, the proxy 527 advertises its own prefixes, and redistributes the Home Aggregation 528 over the internet. Finally, the parent redistributes the route to 529 the proxy's network into its area, via itself, as an external route. 531 5.2 Binding 533 At that point, the primary sites are ready to accept bindings, either 534 directly from Mobile Routers or via proxy HAs. This is the runtime 535 phase for HAHA. 537 A MR that is located close to its primary site will register there 538 for its primary binding. In that case, the binding is direct. 539 Otherwise, the MR will use a proxy in order to bind locally, and the 540 proxy will perform the primary binding on behalf of the MR. If the 541 proxy is parented at the primary site, the binding is local; 542 otherwise, it is called a foreign binding. 544 5.2.1 Direct primary binding 546 When the primary HA accepts a direct binding from a MR, then it must 547 let the other primaries know that it owns the binding for that Home 548 Address, in a fashion that is discussed in Section 10.2. 550 ...... 551 ......../. ... --------------------------- 552 ... ; .. | Site1 | 553 .. / Home::/16 ->.| @--@--@ | 554 ... ; .. | / | 555 .... / MR ==MRHA==== @ <- Home:site1:MNP::/64 | 556 .... ; | .. | \ | 557 ... / ------ ... | @--@ | 558 ... ; MNP | | 559 ... / .. ... --------------------------- 560 ........... 562 Figure 10: Primary HA injects necessary MR routes in area 564 The primary HA installs all (implicit and explicit) routes to the MR 565 MNPs over the MRHA tunnel. It must also inject any required route, 566 such as explicit prefix routes, into the primary area, as external 567 routes via itself. All these routes are summarized at the area 568 border and the other areas are not affected by the routing change. 570 5.2.2 local proxy binding 572 When a MR binds to a satellite site, a HA acts as a proxy and binds 573 in turn with a primary site, on behalf of that MR, to create the 574 primary binding. The proxy binding can only succeed if the primary 575 binding does. If the primary accepts the binding, then it returns a 576 positive Binding Ack, with the list of the prefixes that are routed 577 via the Mobile Router. 579 .. ........ 580 --------- .. . ... ------------------ 581 | Sat1 | .. /. | Site1 | 582 | | <- Home::/16 ; . | | 583 | | .. / .. | | 584 | ---> =========================== @ <- Home:site1 | 585 | | |. / .. | :MNP::/64 | 586 | -- # ======= MR ; ... | | 587 | | . | / | | 588 --------- . ----- ; ... ------------------ 589 MNP.../.. 591 Then the proxy HA installs the routes that it got from the the 592 positive Binding Acknowledgement over the proxy MRHA tunnel, and 593 Acknowledges the proxy BU. Once a primary binding has succeeded, the 594 proxy might establish secondary bindings with other sites. 596 5.2.3 Foreign proxy binding 598 When a MR binds to a foreign site, whether the site is primary or 599 satellite, a HA from the site acts as a proxy as if the site was a 600 satellite from the primary. 602 ----------------- .. .. ... ----------------- 603 | Foreign site | .. .. | . | MR primary Site | 604 | ------------------------ | 605 | +-------------------------------------- primary | 606 | | +----------proxyHAHA----------------- | 607 | | | ------------------------ ^ | 608 | | | | . | ^ | 609 -------|| ||----- .. | .. ----------------- 610 || || - . - . - . - . - . 611 -------|| ||----- | . 612 | | | |. |MNP . .. 613 | proxy --MRHA--- MR-| | ... 614 | HA --------- | | ... 615 | | .. . . 616 |Foreign satellite|<- Home::/16 | . 617 ----------------- ... .. ... 619 5.3 Route Optimizations 621 When the MR binds in a foreign location, the transport between an 622 arbitrary correspondent and the MR within the HAHA network might be 623 far from optimized. 625 As a result of the primary binding, a proxyHAHA tunnel is established 626 between the proxy and the primary HA. That tunnel is itself 627 encapsulated in the HAHA tunnels when packets flow over the internet. 629 .. .. |... 630 ----------------- .. . ... ----------------- 631 | Foreign site | .. | . | MR primary Site | 632 | ------------------------ | 633 | +-------------------------------------- primary | 634 | |v<<<<<<<<<<>>>>>>>>> MR-| . .. | site:: | 644 | --------- | | ...| /48 | 645 | | . ..| ^ | 646 |Foreign satellite|<- Home::/16 | . |Foreign ^ site | 647 ----------------- . .. ------| ^ |------ 648 - . - . - . - .- . - . - . - | ^ | 649 ... .. ------| ^ |------ 650 .. ...| ^ | 651 ... CN >>>>Home::/16>>>>> | 652 ... ..| | 653 .. ..| | 654 ..... Home::/16 ->| | 655 ..... ....... |Foreign satellite| 656 .......... ----------------- 658 Figure 13: The path from CN to MR is not optimized 660 Also, packets from an arbitrary correspondent reach the site that is 661 closest to the correspondent, then forwarded to the primary site for 662 the destination. Within the primary site, they are encapsulated 663 towards the proxy and sent across the HAHA network again. Finally 664 they reach the proxy that decapsulates the packets and encapsulates 665 them back. 667 In order to improve this, various possibilities are offered: 669 5.3.1 Leaking MNP routes in the HAHA network 671 The proxy can establish a secondary binding with its parent. In 672 return, the parent redistributes an external route to the MNP via 673 itself, and leaks that route inside the whole HAHA network. 675 .. .. |... 676 ----------------- .. . .. 677 | Foreign site | .. | . 678 | ----------------------------------+ 679 | parentHA <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< | 680 | ------------------------------+ ^ | 681 | |v| | . | ^ | 682 -------||v||----- .. | .. | ^ | 683 ||v|| - . - . - . - . - . - . - | ^ | 684 -------||v||----- | . ------| ^ |------ 685 | |v| |. . .. | home: | 686 | --MRHA--- |MNP | ... | site: | 687 | proxyHA >>>>>>>>>> MR-| . .. | mnp:: | 688 | --------- | | ...| /64 | 689 | | . ..| ^ | 690 | egress satellite|<- Home::/16 | . |Foreign ^ site | 691 ----------------- . .. ------| ^ |------ 692 - . - . - . - .- . - . - . - | ^ | 693 ... .. ------| ^ |------ 694 .. ...| ^ | 695 ... CN >>>>Home::/16>>>>> | 696 ... ..| | 697 .. ..| | 698 ..... Home::/16 ->| | 699 ..... ....... |ingress satellite| 700 .......... ----------------- 702 Figure 14: The path from CN to MR bypasses the primary HA 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 [11] for IPv6 in order to discover the remote tunnel end point. 719 ----------------- .... 720 | | .... .. 721 | egress satellite|<- Home::/16 | . .. 722 | | .. . 723 | --MRHA--- |MNP1 .. 724 | proxyHA >>>>>>>>>> MR1-| .. 725 | --------- | ... 726 | ^ | .. 727 ------| ^ |------ .. 728 .... | ^ | . 729 .. | ^ | proxy-to-proxy ... 730 ... | ^ | on demand tunnel ... 731 .. | ^ | .. 732 - . -| ^ |. - . - . - .- . - . - . - . - 733 ------| ^ |------ .. 734 | ^ | ..... 735 | ^ --MRHA--- |MNP2 ..... 736 | proxyHA <<<<<<<<<< MR2-| .... 737 | --------- | ... 738 | |. .. 739 |ingress satellite|<- Home::/16 ... 740 | | ... .... 741 ----------------- ............ 743 Figure 15: The path is now direct between the proxies 745 An example of application is when two proxies from a same Home 746 establish a cross binding. In fact, the Mobile Routers are unaware 747 of the Route Optimization that takes place. This feature might be 748 desirable when the privacy of the location is an issue for the 749 service provider. 751 As part of the secondary binding to the ingress proxy, the egress 752 proxy passes all the MNPs for the MR. This can be done using HAHA 753 signalling, as explicit prefix routes. It is expected that the 754 proxies belong to a chain of trust that links the primary and the 755 satellite sites together. This, the ingress proxy trusts the egress 756 proxy both for the binding and for the explicit prefixes. 758 The routes are literally projected from a proxy to the other while 759 unseen by node in between; this is why this model is called Route 760 Projection, by opposition with the traditional model of route 761 injection which impacts the nodes on the way and is problematic with 762 mobility. 764 Note that in that case, the binding uses the proxy's external address 765 as careof. The packets are thus routed straight between the proxies, 766 outside of the HAHA network. 768 6. Terminology and concepts 770 The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 771 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this document are to be 772 interpreted as described in RFC2119 [7]. 774 Most of the mobility related terms used in this document are defined 775 in the Mobility Related Terminology document [14] and in the Mobile 776 IPv6 specification [15]. 778 Additionally, some terms were created or extended for NEMO. These 779 specific terms are defined in the NEMO Terminology document [4]. 781 This draft introduces the following definitions: 783 Distributed Home Network: In distributed home network, a global Home 784 is advertised by several sites that are geographically distributed 785 and meshed using tunnels in a VPN fashion. Mobile Nodes locate 786 the closest site using DHAAD and bind there. More in Section 7... 788 Partitioned Home Network: A Partitioned Home is a specific deployment 789 of a Distributed Home Network where each location owns a subnet of 790 Home. The local Home Agents accept registration for the local 791 partition. The local HAs also act as NEMO proxy HAs for the rest 792 of Home. 794 Primary Home Agent: A Home Agent that can serve a Binding Update from 795 a Mobile Router. The Mobile Router is always associated with a 796 (set of) primary Home Agent (s) to register its binding. 798 Proxy Home Agent: This is a form of proxy, for the NEMO protocol. A 799 proxy HA acts as a HA for MRs to register, but needs to register 800 to a primary HA in order to accept the binding. 802 Primary site: A site is primary for a MR if at least one local HA on 803 that site can accept a registration for that MR. When Home is not 804 partitioned and sites overlap, primary HAs for a same subnet have 805 to be aware of each other in order to find if a binding already 806 exists in one of the sites and in which Home Agent. 808 satellite site: A site that is not primary for any binding. It is 809 dependent on a parent primary site for HAHA operations. satellite 810 sites are deployed around central primary sites, and one final 811 goal for HAHA is to dynamically draw routes between satellite 812 sites in order to shortcut the backbone of primary HAs. 814 Secondary site: A site is secondary for a MR if it is primary for 815 other MRs but not that one. HAs in a secondary site can act as 816 proxies for that MR, and the site is its own parent. 818 Primary Binding: A Binding is primary if it happens with a primary 819 Home Agent, whether the client is a MR or a proxy HA. 821 Secondary Binding: A Binding is secondary if it happens between a 822 proxy and a non primary Home Agent. It is used to improve the 823 path between sites towards the HA where a MR is registered. 825 Proxy Binding: A Binding is proxy if it happens between a MR and a 826 proxy HA, whether the proxy is a pure proxy HA or a secondary HA 827 acting as proxy for that MR. The proxy HA relays the proxy 828 binding to a primary HA in a primary binding. It may maintain a 829 set of secondary bindings, depending on the deployment. 831 Direct Binding: A Binding that does not pass via a proxy, straight 832 between the MR and its Home Agent. 834 7. Distributed Home Network 836 This section describes a detailed example how multiple Home Agents 837 are configured in different routing domains. You are encouraged to 838 read the nemo basic Home Network Models [3] draft before going 839 through this section. 841 HA HA 842 | ______ | 843 --+-----+--+- . -+- . -+-- TUNNEL --+-----+--+- . -+- .. -+-- 844 | | | | ______ | | | | 845 MR1 MR2 MRi MRN MR1 MR2 MRi MRN 846 ------ ------ ------ ------ ------ ------ ---- - ---- 847 /64 A:B:1:i::/64 /64 A:B:n:i::/64 849 Distributed Home Network /48 850 <------------------------------------------------------------------> 852 extended HN Aggregated HN Virtual HN 853 <----------------------><---------------------->...<---------------> 855 Home Mob Mob Mob Mob Mob Mob Mob 856 <-----><----->...<-----><-----><----->...<----->...<----->...<-----> 858 In distributed home network, a global Home is advertised by several 859 sites that are geographically distributed and meshed using tunnels in 860 a VPN fashion. Mobile Nodes locate the closest site using DHAAD 861 against the global Home Network and bind there. Some form of inter- 862 site synchronization (e.g. a routing protocol), which Mobile IPv6 and 863 Nemo Basic Support do not provide, must take place in order to allow 864 packets to be routed between the incoming site to the Mobile Node. 865 The HAHA (Home Agent to Home Agent) protocol is being designed for 866 that purpose. 868 In one model, called the Partitioned Home Network each site is 869 responsible for a subnet of Home. When a Mobile Node roams far from 870 its natural (primary) site, it registers to a Home Agent on a remote 871 site, that takes the registration and notifies at least the natural 872 site of the foreign registration. 874 One specific advantage of not relying on a Home Link for HAHA 875 communication is that for a large configuration, the Home Agents can 876 be organized hierarchically and distributed geographically, as a set 877 of local clusters linked together to form a global Home Network. 879 8. Message Formats 881 A traditional IGP coul be used over the HAHA tunnel. But in order to 882 integrate HAHA smoothly with the rest of the MIP operation, this 883 drafts suggest to use the messages and formats detailed in the HAHA 884 specification [17]. 886 9. Mobile Router Operation 888 9.1 Locating Home 890 9.2 Proxy MIP client 892 10. Home Agent Operation 894 10.1 Locating the other HAs that serve the same Home 896 10.2 Locating the HA that owns the binding for a HoA 898 At the time of processing a binding update, a Home Agent (be it 899 primary or simply proxy for the binding Home Address) needs to 900 discover if the binding already exists with a primary Home Agent. 901 There are at least 3 approaches that might be deployed for that 902 purpose: 904 Reactive: This method is also referred to as 'on-demand'. In case of 905 a binding cache miss, a primary Home Agent floods a Binding 906 Information Request message to all the other primary Home Agents 907 for the home address that is sought for. The reactive approach 908 can be used between a satellite site and its parent site even when 909 the primary HAs use an other method in the backbone. 911 Proactive: The binding information is shared proactively between the 912 primary Home Agents for the existing bindings. All primary HAs 913 know at any point of time which Home Addresses are bound and with 914 which primary Home Agent. This approach is preferred for stable 915 configurations, for instance if NEMO is used as a tool to simplify 916 the configuration and reconfiguration of mostly stable networks. 918 Predictive: Ranges of Home Addresses and prefixes are preassigned to 919 the Home Agents, following a rule that is shared or commonly 920 computed by all HAs. A partitioned Home Network is an example of 921 that, but this is mostly useful within a site between local Home 922 Agents. 924 11. Acknowledgements 926 The authors wish to thank: 928 12. IANA considerations 930 This document does not require any IANA action. 932 13. Security Considerations 934 This document explores how t use the haha protocol but does not 935 standardize any new operation that would be harmful. 937 14. Changes 939 14.1 Changes from version 00 to 01 941 Added a proxy section to introduce the concept 943 14.2 Changes from version 01 to 02 945 Address aggregation that can be done between ISPs so that a 946 shorter prefix is injected in the DFZ. 948 15. References 950 15.1 informative reference 952 [1] Devarapalli, V., "Local HA to HA protocol", 953 draft-devarapalli-mip6-nemo-local-haha-01 (work in progress), 954 March 2006. 956 [2] Giaretta, G. and A. Patel, "Problem Statement for bootstrapping 957 Mobile IPv6", draft-ietf-mip6-bootstrap-ps-05 (work in 958 progress), May 2006. 960 [3] Thubert, P., "NEMO Home Network models", 961 draft-ietf-nemo-home-network-models-06 (work in progress), 962 February 2006. 964 [4] Ernst, T. and H. Lach, "Network Mobility Support Terminology", 965 draft-ietf-nemo-terminology-05 (work in progress), March 2006. 967 [5] Ernst, T., "Network Mobility Support Goals and Requirements", 968 draft-ietf-nemo-requirements-05 (work in progress), 969 October 2005. 971 [6] Ng, C., "Analysis of Multihoming in Network Mobility Support", 972 draft-ietf-nemo-multihoming-issues-06 (work in progress), 973 June 2006. 975 15.2 normative reference 977 [7] Bradner, S., "Key words for use in RFCs to Indicate Requirement 978 Levels", BCP 14, RFC 2119, March 1997. 980 [8] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) 981 Specification", RFC 2460, December 1998. 983 [9] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery 984 for IP Version 6 (IPv6)", RFC 2461, December 1998. 986 [10] Thomson, S. and T. Narten, "IPv6 Stateless Address 987 Autoconfiguration", RFC 2462, December 1998. 989 [11] Fox, B. and B. Petri, "NHRP Support for Virtual Private 990 Networks", RFC 2735, December 1999. 992 [12] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) 993 Addressing Architecture", RFC 3513, April 2003. 995 [13] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host 996 Configuration Protocol (DHCP) version 6", RFC 3633, 997 December 2003. 999 [14] Manner, J. and M. Kojo, "Mobility Related Terminology", 1000 RFC 3753, June 2004. 1002 [15] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in 1003 IPv6", RFC 3775, June 2004. 1005 [16] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, 1006 "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, 1007 January 2005. 1009 [17] Wakikawa, R., "Inter Home Agents Protocol Specification", 1010 draft-wakikawa-mip6-nemo-haha-spec-01 (work in progress), 1011 March 2006. 1013 Authors' Addresses 1015 Pascal Thubert 1016 Cisco Systems 1017 Village d'Entreprises Green Side 1018 400, Avenue de Roumanille 1019 Batiment T3 1020 Biot - Sophia Antipolis 06410 1021 FRANCE 1023 Phone: +33 4 97 23 26 34 1024 Email: pthubert@cisco.com 1026 Ryuji Wakikawa 1027 Keio University and WIDE 1028 5322 Endo Fujisawa Kanagawa 1029 252-8520 1030 JAPAN 1032 Email: ryuji@sfc.wide.ad.jp 1034 Vijay Devarapalli 1035 Nokia Research Center 1036 313 Fairchild Drive 1037 Mountain View, CA 94043 1038 USA 1040 Email: vijay.devarapalli@nokia.com 1042 Intellectual Property Statement 1044 The IETF takes no position regarding the validity or scope of any 1045 Intellectual Property Rights or other rights that might be claimed to 1046 pertain to the implementation or use of the technology described in 1047 this document or the extent to which any license under such rights 1048 might or might not be available; nor does it represent that it has 1049 made any independent effort to identify any such rights. Information 1050 on the procedures with respect to rights in RFC documents can be 1051 found in BCP 78 and BCP 79. 1053 Copies of IPR disclosures made to the IETF Secretariat and any 1054 assurances of licenses to be made available, or the result of an 1055 attempt made to obtain a general license or permission for the use of 1056 such proprietary rights by implementers or users of this 1057 specification can be obtained from the IETF on-line IPR repository at 1058 http://www.ietf.org/ipr. 1060 The IETF invites any interested party to bring to its attention any 1061 copyrights, patents or patent applications, or other proprietary 1062 rights that may cover technology that may be required to implement 1063 this standard. Please address the information to the IETF at 1064 ietf-ipr@ietf.org. 1066 Disclaimer of Validity 1068 This document and the information contained herein are provided on an 1069 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1070 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1071 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1072 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1073 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1074 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1076 Copyright Statement 1078 Copyright (C) The Internet Society (2006). This document is subject 1079 to the rights, licenses and restrictions contained in BCP 78, and 1080 except as set forth therein, the authors retain all their rights. 1082 Acknowledgment 1084 Funding for the RFC Editor function is currently provided by the 1085 Internet Society.