idnits 2.17.00 (12 Aug 2021) /tmp/idnits30811/draft-thubert-nemo-global-haha-01.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 1054. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1031. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1038. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1044. ** 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 351 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 (October 15, 2005) is 6062 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 932, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 936, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 960, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 966, but no explicit reference was found in the text == Unused Reference: '12' is defined on line 972, but no explicit reference was found in the text == Unused Reference: '13' is defined on line 975, but no explicit reference was found in the text == Outdated reference: A later version (-01) exists of draft-devarapalli-mip6-nemo-local-haha-00 == 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) == Outdated reference: A later version (-01) exists of draft-wakikawa-mip6-nemo-haha-spec-00 -- Possible downref: Normative reference to a draft: ref. '17' Summary: 11 errors (**), 0 flaws (~~), 17 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 18, 2006 R. Wakikawa 5 Keio University 6 V. Devarapalli 7 Nokia 8 October 15, 2005 10 Global HA to HA protocol 11 draft-thubert-nemo-global-haha-01 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 18, 2006. 38 Copyright Notice 40 Copyright (C) The Internet Society (2005). 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . 3 55 2.2 Layer 3 operations . . . . . . . . . . . . . . . . . . . . 4 56 2.3 Path improvement . . . . . . . . . . . . . . . . . . . . . 5 57 2.4 Single point of failure . . . . . . . . . . . . . . . . . 7 58 3. Rationale for the proposed solution . . . . . . . . . . . . . 7 59 4. A proxy for Mobile IP . . . . . . . . . . . . . . . . . . . . 8 60 5. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 61 5.1 Initial routing . . . . . . . . . . . . . . . . . . . . . 10 62 5.1.1 External routing . . . . . . . . . . . . . . . . . . . 10 63 5.1.2 Internal routing . . . . . . . . . . . . . . . . . . . 11 64 5.2 Binding . . . . . . . . . . . . . . . . . . . . . . . . . 12 65 5.2.1 Direct primary binding . . . . . . . . . . . . . . . . 12 66 5.2.2 local proxy binding . . . . . . . . . . . . . . . . . 13 67 5.2.3 Foreign proxy binding . . . . . . . . . . . . . . . . 13 68 5.3 Path improvements . . . . . . . . . . . . . . . . . . . . 14 69 5.3.1 Leaking MNP routes in the HAHA network . . . . . . . . 15 70 5.3.2 On-demand proxy routes . . . . . . . . . . . . . . . . 16 71 6. Terminology and concepts . . . . . . . . . . . . . . . . . . . 17 72 7. Distributed Home Network . . . . . . . . . . . . . . . . . . . 19 73 8. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 20 74 9. Mobile Router Operation . . . . . . . . . . . . . . . . . . . 20 75 9.1 Locating Home . . . . . . . . . . . . . . . . . . . . . . 20 76 9.2 Proxy MIP client . . . . . . . . . . . . . . . . . . . . . 20 77 10. Home Agent Operation . . . . . . . . . . . . . . . . . . . . 20 78 10.1 Locating the other HAs that serve the same Home . . . . . 20 79 10.2 Locating the HA that owns the binding for a HoA . . . . . 20 80 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 81 12. IANA considerations . . . . . . . . . . . . . . . . . . . . 21 82 13. Security Considerations . . . . . . . . . . . . . . . . . . 21 83 14. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . 21 84 14.1 Changes from version 00 to 01 . . . . . . . . . . . . . . 21 85 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 86 15.1 informative reference . . . . . . . . . . . . . . . . . . 21 87 15.2 normative reference . . . . . . . . . . . . . . . . . . . 22 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 23 89 Intellectual Property and Copyright Statements . . . . . . . . 24 91 1. Introduction 93 The reader of this document is expected to be familiar with both the 94 Mobile IPv6 [15] and NEMO Basic Support [16] documents. As such, the 95 reader is expected to understand the concept of a Home Link and the 96 Neighbor Discovery related operations that take place over that link. 98 Home Agent global distribution is useful when a Mobile Router moves 99 geographically large area such as airplane, vehicle, etc... The 100 overhead of the basic NEMO protocol is redundant route caused by the 101 bi-directional tunnel between a Home Agent and a Mobile Router. If a 102 Mobile Router moves far away from a Home Agent, the overhead can not 103 be ignored. 105 Thus, it is reasonable to consider that a Mobile Router dynamically 106 switches to the topologically closest Home Agent (Home Link). This 107 distribution is also effective for load-balancing. The Home Agent is 108 expected to serve thousands of Mobile Routers on its Home Link and 109 tunnels all packets for the Mobile Routers by itself. 111 But with NEMO basic support and MIPv6, Home is locally anchored to 112 the Home Link at Layer 2, so Home can not be distributed 113 geographically. In particular for NEMO, what's needed is a route to 114 a mobile prefix via a tunnel end point that is the CareOf address of 115 the Mobile Router. The Home Address is but a practical artifact that 116 is mostly needed as a correlator for the registration. 118 This draft proposes a model that enables the HA to HA communication 119 at Layer 3, allowing to get rid of the Home Link in configurations 120 where it's not needed. 122 2. Motivations 124 2.1 Requirements 126 This draft addresses two generic requirements expressed in the Nemo 127 requirements [5]: 129 Local Mobility and Global Mobility: Multihoming is mentioned as 130 desirable. The global mobility type is not expected to be limited 131 for any consideration other than administrative and security 132 policies. 134 Scalability: NEMO support signaling and processing is expected to 135 scale to a potentially large number of mobile networks. Thus 136 draft extends the scalality of the NEMO basic protocol. 138 There is a requirement from airplane companies which want to be at 139 Home in the various airports that their planes visit. In fact, this 140 is expressed in an abstract fashion by the case (1,n,1) of the NEMO 141 multihoming issues [6] draft: "Single MR, Multiple HAs, Single NEMO- 142 Prefix". 144 There is also a general direction that indicates that NEMO could be 145 extended as a solution for VPN. To get there, we must ensure that 146 NEMO is upscaled to the classical capabilities of VPN, including the 147 global distribution of Points Of Presence. It is a classical feature 148 for VPNs to allow the roaming users to connect to the closest point 149 of presence into their company VPN. The same feature can not be 150 provided with MIPv6 or NEMO, because the Home depends on a link that 151 has a unique physical location. 153 2.2 Layer 3 operations 155 Mobile IPv6 [15] standarizes an interface between a Mobile Node and 156 its Home Agent and its correspondents, as well as an interface 157 between Home Agents. One angle of the MIPv6 operation is that the 158 protocols hides the MN mobility by making as if the Mobile Node was 159 always connected to a Home Link. The connectivity is maintained by 160 Home Agents that are permanently and physically attached to that Home 161 Link. 163 So the model for MIPv6 is Home Link centric and it is no surprise 164 that it extends IPv6 Neighbor Discovery [9] for its operations, in 165 particular for HAs to discover each others, and to discover when one 166 of them has a binding for a Mobile Node, and which one. An immediate 167 consequence of being Link centric is that Home can not be distributed 168 at Layer 3, locally within a site or over the Internet. 170 the NEMO Basic Support [16] inherits the concept of Home Link and 171 MIPv6 operations on that link, making NEMO partially a link layer 172 operation. On the other hand, the NEMO Basic Support also operates 173 as a routing protocol at L3, for example when it injects routes in 174 the explicit prefix mode. So NEMO operations are somewhat half L2 175 and half L3. 177 What we are getting at with the HAHA protocol is placing NEMO fully 178 at L3. This mostly means the replacement of all ND based exchanges 179 by some equivalent, but at Layer 3, over the Internet Protocol. This 180 also means the abstraction of the concept of Home Address into a 181 globally unique router ID, as opposed to an address from a Home Link. 183 So even if this paper trivially applies to Mobile IPv6, we place our 184 descriptions in the context of NEMO, and use MRs where MIPv6 MNs 185 could fit as well. 187 2.3 Path improvement 189 MIPv6 comes with a Route Optimization scheme that enables a direct 190 MR-CN conversation, bypassing the Home Agent. With the basic 191 support, NEMO does not have such a support yet. In any case, RO 192 comes at an additional cost in terms of protocol, which varies with 193 the degree of expected trust. 195 Without Route optimization, all the packets MR-CN flow via the Home 196 Agent; this increases both the cost and the latency. The resulting 197 path can be illustrated like this: 199 CN1 <--------------------- -- -- -----------------+ +---> CN2 200 (NYC) | | (NICE) 201 | | 202 | | 203 | | 204 | | 205 MRHA tunnel | | 206 ===================== == == ================ 207 MR <--------------------- -- -- ----------------- HA (BRITTANY) 208 (NJ) ===================== == == ================ 209 | 210 | 211 ----- 212 ///// 213 Home Link 215 Figure 1: Current model with a Home Link 217 The routing overhead becomes costly when: 219 The distance ||MR, CN|| is much smaller then the sum of the 220 distances ||MR, HA|| + ||HA, CN||. 222 AND 224 ||MR, HA||+||HA, CN|| is costly. If the 3 points are very close, 225 the overhead is relatively important, but small in absolute terms. 227 In the picture above, say that a European phone (MR) is roaming in 228 New Jersey but Homed in Brittany. And say that the phone owner 229 places a call in New York city to CN1. Without RO, the voice packets 230 flow back and forth over the peering lines between Brittany and the 231 US, and the routing overhead causes an additional latency that 232 decreases the perceived quality of the phone call. 234 On the other hand, calling CN2 would result in a small, acceptable 235 overhead, considering that the distance ||HA, CN2|| is very small 236 with regards to ||MR, HA|| or ||MR, CN2||. Now, when the MR moves 237 back to Brittany and places a new call to CN2, going via the HA might 238 double the distance, but the whole thing being local, it is 239 negligible. 241 The geographical distribution of Home generalizes this latter 242 situation. If we can get rid of the concept of a Home Link that 243 anchors the HA in a single location, then we can distribute HAs 244 geographically, and, hopefully, one is close to our MR when it's 245 roaming. 247 So if a MR can locate and bind with a closeby HA, then ||MR, HA|| is 248 contained and the overhead is globally limited. In a same fashion, 249 when a CN sends a packet to the MR, it finds a HA closeby and the 250 overhead ||HA, CN|| is contained as well. 252 CN1 <-----+ +-----> CN2 253 (NYC) | | (NICE) 254 | | 255 | | 256 | | 257 | long distance | 258 | HAHA tunnel | 259 =========== == == ================= 260 HA' ------------ -- -- ------------------ HA (BRITTANY) 261 (DC) =========== == == ================= 262 || | || (under the Atlantic :) 263 || | || 264 || | || short distance 265 || | || MRHA Tunnel 266 || | || 267 v 268 MR (NJ) 270 Figure 2: Globally Distributed HA for World Wide service 272 In our previous example, we see that a HA' deployed in the East Coast 273 saves the round trip over the Atlantic. There is a new overhead for 274 the call to Europe, though, since an additional path is involved 275 between MR and HA'. Then again, if both ||MR, HA'|| and ||CN2, HA|| 276 are relatively small compared to ||HA, HA'|| then the overhead is 277 acceptable; unless all 3 points are located closeby, in which case, 278 again, the additional cost is acceptable. 280 CN2 (NICE) 281 ^ 282 | 283 HA'(DC) ------------------------------------------------- HA 284 | (BRITTANY) 285 v 286 MR (NJ) 288 <-------------------------------------------------------------> 289 Diagonal (direct path) cost 291 <---------------------------------------------------------------> 292 Via HAs 294 Figure 3: Illustrating that the overhead can be relatively small 296 2.4 Single point of failure 298 The Home Link is a single point of failure for MIPv6/NEMO operations. 300 Should the Home Link fail, the whole set of MNs / MRs is disconnected 301 from the rest of the world. One could decide to use a virtual link 302 for Home, but then: 304 MIPv6 provides a support for multiple HAs, with the DHAAD mechanism. 305 This mechanism helps scaling up the Home by adding HAs dynamically, 306 and eventually load balancing the bindings between them. But this 307 all relies on HAHA communication over the PHYSICAL Home Link; so 308 making that link virtual implies a single Home Agent. 310 In turn this makes the HA a single point of failure, and disables the 311 scalability that the DHAAD mechanism provides to MIPv6. 313 3. Rationale for the proposed solution 315 For the time being, the precise flows are not elaborated. One idea 316 is that a protocol such as IS-IS or OSPFv3 could help a lot, mostly 317 in the registration phase. Another is that HAs should be proactively 318 preassigned to receive a given set of registration, in order to allow 319 a certain degree of aggregation within sites and in between site. 320 Finally, the concept of proxy is introduced to limit the number of 321 primary sites (to 1?) and as a key element for an upcoming NEMO route 322 optimization scheme, where routes can be echanged in a trusted 323 fashion between proxies. 325 4. A proxy for Mobile IP 327 The draft references extensively a MIP proxy function. The word 328 proxy, here, is taken in a classical sense, like, for instance, a web 329 proxy: a MIP proxy acts as a HA for the MN and as a MN for the HA, 330 the CN, and other proxies. In particular, the MIP proxy terminates 331 the MR-HA tunnel and the associated encryption, extracts the packets, 332 and reencapsulates them to the destination. 334 This differs from a proxy-MIP function, which performs the Mobile 335 Node operation on behalf of a non MIP-enabled node, in order to 336 manage its mobility transparently. 338 +-------+ +-------+ 339 | | | | 340 | HA 1 | | HA 2 | 341 | | | | 342 +-------+ +-------+ 343 primary ^ primary ^ 344 binding | binding | 345 +-------+ +-------+ +-------+ 346 | | --------->| |---------->| | 347 | MN/MR | proxy |proxy 1| secondary |proxy 2| 348 | 1 | binding | | binding | | 349 +-------+ +-------+ +-------+ 350 RO | proxy ^ 351 binding v binding | 352 +-------+ +-------+ 353 | | | | 354 | CN | | MN/MR | 355 | | | 2 | 356 +-------+ +-------+ 358 Figure 4: MIP proxy 360 Distributing widely the MIP proxies presents a number of advantages: 362 Route Optimization: a proxy-to-proxy path between to MNs/MRs could be 363 much shorter then the path vias the HAs. 365 Local Mobility Management: when the MN moves around a given proxy, 366 but keeps binding to that same proxy, the proxy does not need to 367 inform the primary HA. 369 Nested NEMO: when Mobile Routers attach to one another and form a 370 nested NEMO, the corresponding MRHA tunnel are nested as well. If 371 they all bind to a same proxy, the proxy will decapsulate all the 372 levels of tunneling, and retunnel only once towards the Internet 374 5. Overview 376 This description covers the specific case of a Partitioned Home 377 Network. Home is subnetted and the subnets are attributed to the 378 distributed sites. As a result, in a given location, HAs will be 379 operating both as primary HA taking the registrations for the local 380 partition and proxy HA for registrations that belong to other sites. 381 Additional satellite sites might be deployed around some of the main 382 sites. 384 ## ## 385 ## ## ## 386 ##\ || ||proxy/parent 387 \\ || || tunnel 388 \\ ---||---- ...... ... ----||--- 389 \\| | .... .... ... | | 390 \ @---@ | .... ..... | @---@ | 391 ## ----- | X | --------------------------------- \ / ------## 392 ## ----- @---@ .... HAHA tunnel .... @ ------## 393 | --------------------------------- | 394 ------\ \ ... .... / /-||--- 395 \ \... .../ / || 396 \.\. /./ || 397 .\.\ internet /./. || 398 .\.\ ........... / /... ## 399 ...\ \ / / .. ## 400 .. \ \ / / ... 401 ...\ \ / / ... 402 ..\ \ ...... / /... 403 \.\ . ...... .././ 404 @ primary HA \ \ .. / / 405 \ \ --------- / / 406 ## proxy HA or \ \ @ @ / / 407 ## satellite site \ \ / / 408 \ @ /-----## 409 -- | / \ ------## 410 | | primary site | @ @ | 411 -- --------- 413 Figure 5: Overview 415 It is out of the scope of this document to discuss how the subnetting 416 was decided and configured. It is also out of the scope of this 417 document to describe the operations within a site where more than one 418 HA is deployed. It is expected that in each primary site, HAs 419 discover each other, mesh using tunnels, and form an area that owns 420 the partition of Home that was assigned to that site. 422 5.1 Initial routing 424 5.1.1 External routing 426 Sites are expected to be connected locally to the internet, via the 427 network of one or more service provider. Each site has a default 428 route to the internet via that connection. 430 . .. / 431 --------- ........ ..;. --------- 432 | | .. / ..... | | 433 | ::/0 -> .... ; ... <- ::/0 | 434 | ============HAHA=TUNNEL=========== | 435 | | .... ; .... | | 436 | | .<- Home::/32 / Home::/32 ->..| | 437 --------- ... ; ... --------- 438 ..... / .. 439 . ;.... ...... 440 / .......... 442 In return, each site advertises the aggregation that encompasses the 443 Distributed Home Network aggregation back into the service provider 444 network, to the outside world (the internet). 446 ...... 447 --------- ....... .../ --------- 448 | | ..... ; .... | | 449 | ---------------------------------- | 450 | <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< | 451 | v ------------HAHA-tunnel----------- ^ | 452 | v | / .| ^ | 453 | \ ==MRHA== / ... | ^ | 454 | HA >---------- MR ; .. | ^ | 455 | / =tunnel= / .| ^ | 456 | v | ; | ^ | 457 | >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> CN >>>>>> HA | 458 | | . ; ... | | 459 --------- . / ... --------- 460 ... ;.... ...... 461 / .......... 463 Thus, a site attracts the DHAAD requests from any MR that happens to 464 be roaming close to the site, regardless of the MR primary site. So 465 MRs bind to the closest site from their physical location. In a same 466 fashion, CNs send all packets to LFNs via the closest Home site. But 467 packets back flow directly from the site where the MR is bound. 469 5.1.2 Internal routing 471 In each area, border HAs are elected to mesh with peers in other 472 sites. Again, they discover each other, mesh using tunnels, and form 473 a backbone. It might be preferrable to form a fully meshed backbone, 474 in order to limit the cost of routing between sites. Also, making 475 the backbone a transit area enables the use of a specific HA for the 476 HAHA protocol that acts as an OSPF Designated Router or a BGP Route 477 Reflector. 479 ...... 480 --------- ....... .../ --------- 481 | site1 | ..... ; .... | Site2| 482 | ---------------------------------- | 483 | Home:Site2::/48 -> <- Home:Site1::/48 | 484 | ------------HAHA-tunnel----------- | 485 | @ @ @ | / .| @ @ | 486 | @ @ | <- Home::/32 ; Home::/32 -> | @ @ @ | 487 --------- . / ... --------- 488 ... ....; ...... 489 /.......... 491 If a link state protocol such as OSPFv3 is deployed between the 492 primary HAs, then it uses the meshed backbone as its area zero, and 493 each site as an area. Sites exchange their partitions of Home in the 494 form of summarized routes. 496 It can be expected that, in order to scale, satellite sites would be 497 deployed to take the proxy bindings but would not participate to the 498 HAHA protocol that happens between the primary sites - at least when 499 a proactive version of HAHA is being used. 501 ...... 502 --------- ....... .../. --------- 503 | Sat1 | ..... ; .... | Site1 | 504 | ---------------------------------- | 505 | Home::/32 -> <- Home:Site1:Sat1:/64 | 506 | ----proxyHAHA-tunnel-------------- | 507 | #### | / .| @ @ @ | 508 | #### | <- Home::/32 ; Home::/32 -> | @ @ | 509 --------- . / ... --------- 510 ... ....; ...... 511 /.......... 513 In a satellite site, HAs are only proxy, never primary. Each proxy 514 HA has at least one assigned parent HA, which belongs to a primary 515 site. A tunnel is established between the proxy HA and the parent 516 HA. The parent advertises the Home Aggregation to the proxy over 517 that tunnel, as it does over the internet. In return, the proxy 518 advertises its own prefixes, and redistributes the Home Aggregation 519 over the internet. Finally, the parent redistributes the route to 520 the proxy's network into its area, via itself, as an external route. 522 5.2 Binding 524 At that point, the primary sites are ready to accept bindings, either 525 directly from Mobile Routers or via proxy HAs. This is the runtime 526 phase for HAHA. 528 A MR that is located close to its primary site will register there 529 for its primary binding. In that case, the binding is direct. 530 Otherwise, the MR will use a proxy in order to bind locally, and the 531 proxy will perform the primary binding on behalf of the MR. If the 532 proxy is parented at the primary site, the binding is local; 533 otherwise, it is called a foreign binding. 535 5.2.1 Direct primary binding 537 When the primary HA accepts a direct binding from a MR, then it must 538 let the other primaries know that it owns the binding for that Home 539 Address, in a fashion that is discussed in Section 10.2. 541 ...... 542 ......../. ... --------------------------- 543 ... ; .. | Site1 | 544 .. / Home::/32 ->.| @--@--@ | 545 ... ; .. | / | 546 .... / MR ==MRHA==== @ <- Home:site1:MNP::/64 | 547 .... ; | .. | \ | 548 ... / ------ ... | @--@ | 549 ... ; MNP | | 550 ... / .. ... --------------------------- 551 ........... 553 Primary HA injects necessary MR routes in area 555 The primary HA installs all (implicit and explicit) routes to the MR 556 MNPs over the MRHA tunnel. It must also inject any required route, 557 such as explicit prefix routes, into the primary area, as external 558 routes via itself. All these routes are summarized at the area 559 border and the other areas are not affected by the routing change. 561 5.2.2 local proxy binding 563 When a MR binds to a satellite site, a HA acts as a proxy and binds 564 in turn with a primary site, on behalf of that MR, to create the 565 primary binding. The proxy binding can only succeed if the primary 566 binding does. If the primary accepts the binding, then it returns a 567 positive Binding Ack, with the list of the prefixes that are routed 568 via the Mobile Router. 570 .. ........ 571 --------- .. . ... ------------------ 572 | Sat1 | .. /. | Site1 | 573 | | <- Home::/32 ; . | | 574 | | .. / .. | | 575 | ---> =========================== @ <- Home:site1 | 576 | | |. / .. | :MNP::/64 | 577 | -- # ======= MR ; ... | | 578 | | . | / | | 579 --------- . ----- ; ... ------------------ 580 MNP.../.. 582 Then the proxy HA installs the routes that it got from the the 583 positive Binding Acknowledgement over the proxy MRHA tunnel, and 584 Acknowledges the proxy BU. Once a primary binding has succeeded, the 585 proxy might establish secondary bindings with other sites. 587 5.2.3 Foreign proxy binding 589 When a MR binds to a foreign site, whether the site is primary or 590 satellite, a HA from the site acts as a proxy as if the site was a 591 satellite from the primary. 593 ----------------- .. .. ... ----------------- 594 | Foreign site | .. .. | . | MR primary Site | 595 | ------------------------ | 596 | +-------------------------------------- primary | 597 | | +----------proxyHAHA----------------- | 598 | | | ------------------------ ^ | 599 | | | | . | ^ | 600 -------|| ||----- .. | .. ----------------- 601 || || - . - . - . - . - . 602 -------|| ||----- | . 603 | | | |. |MNP . .. 604 | proxy --MRHA--- MR-| | ... 605 | HA --------- | | ... 606 | | .. . . 607 |Foreign satellite|<- Home::/32 | . 608 ----------------- ... .. ... 610 5.3 Path improvements 612 When the MR binds in a foreign location, the transport between an 613 arbitrary correspondent and the MR within the HAHA network might be 614 far from optimized. 616 As a result of the primary binding, a proxyHAHA tunnel is established 617 between the proxy and the primary HA. That tunnel is itself 618 encapsulated in the HAHA tunnels when packets flow over the internet. 620 .. .. |... 621 ----------------- .. . ... ----------------- 622 | Foreign site | .. | . | MR primary Site | 623 | ------------------------ | 624 | +-------------------------------------- primary | 625 | |v<<<<<<<<<<>>>>>>>>> MR-| . .. | site:: | 635 | --------- | | ...| /48 | 636 | | . ..| ^ | 637 |Foreign satellite|<- Home::/32 | . |Foreign ^ site | 638 ----------------- . .. ------| ^ |------ 639 - . - . - . - .- . - . - . - | ^ | 640 ... .. ------| ^ |------ 641 .. ...| ^ | 642 ... CN >>>>home::/32>>>>> | 643 ... ..| | 644 .. ..| | 645 ..... Home::/32 ->| | 646 ..... ....... |Foreign satellite| 647 .......... ---------------- 649 The path from CN to MR is not optimized 651 Also, packets from an arbitrary correspondent reach the site that is 652 closest to the correspondent, then forwarded to the primary site for 653 the destination. Within the primary site, they are encapsulated 654 towards the proxy and sent across the HAHA network again. Finally 655 they reach the proxy that decapsulates the packets and encapsulates 656 them back. 658 In order to improve this, various possibilities are offered: 660 5.3.1 Leaking MNP routes in the HAHA network 662 The proxy can establish a secondary binding with its parent. In 663 return, the parent redistributes an external route to the MNP via 664 itself, and leaks that route inside the whole HAHA network. 666 .. .. |... 667 ----------------- .. . .. 668 | Foreign site | .. | . 669 | ----------------------------------+ 670 | parentHA <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< | 671 | ------------------------------+ ^ | 672 | |v| | . | ^ | 673 -------||v||----- .. | .. | ^ | 674 ||v|| - . - . - . - . - . - . - | ^ | 675 -------||v||----- | . ------| ^ |------ 676 | |v| |. . .. | home: | 677 | --MRHA--- |MNP | ... | site: | 678 | proxyHA >>>>>>>>>> MR-| . .. | mnp:: | 679 | --------- | | ...| /64 | 680 | | . ..| ^ | 681 | egress satellite|<- Home::/32 | . |Foreign ^ site | 682 ----------------- . .. ------| ^ |------ 683 - . - . - . - .- . - . - . - | ^ | 684 ... .. ------| ^ |------ 685 .. ...| ^ | 686 ... CN >>>>home::/32>>>>> | 687 ... ..| | 688 .. ..| | 689 ..... Home::/32 ->| | 690 ..... ....... |ingress satellite| 691 .......... ---------------- 693 The path from CN to MR bypasses the primary HA 695 This bypasses the primary home agent for packet forwarding. Note 696 that the packets still flow within the HAHA network between the 697 ingress site close to the correspondent and the egress (satellite) 698 site. 700 Note also that when the proxy HA binds to either its parent or the 701 primary HA, it uses an address from within the HAHA network (its HAHA 702 Address), as CareOf. 704 5.3.2 On-demand proxy routes 706 The proxy can establish a secondary binding with the correspondent's 707 proxy provided there's such a node. It might be envisioned to adapt 708 NHRP [11] for IPv6 in order to discover the remote tunnel end point. 710 ----------------- .... 711 | | .... .. 712 | egress satellite|<- Home::/32 | . .. 713 | | .. . 714 | --MRHA--- |MNP1 .. 715 | proxyHA >>>>>>>>>> MR1-| .. 716 | --------- | ... 717 | ^ | .. 718 ------| ^ |------ .. 719 .... | ^ | . 720 .. | ^ | proxy-to-proxy ... 721 ... | ^ | on demand tunnel ... 722 .. | ^ | .. 723 - . -| ^ |. - . - . - .- . - . - . - . - 724 ------| ^ |------ .. 725 | ^ | ..... 726 | ^ --MRHA--- |MNP2 ..... 727 | proxyHA <<<<<<<<<< MR2-| .... 728 | --------- | ... 729 | |. .. 730 |ingress satellite|<- Home::/32 ... 731 | | ... .... 732 ----------------- ............ 734 The path is now direct between the proxies 736 An example of application is when two proxies from a same Home 737 establish a cross binding. In fact, the Mobile Routers are unaware 738 of the path improvement that takes place. This feature might be 739 desirable when the privacy of the location is an issue for the 740 service provider. 742 As part of the secondary binding to the ingress proxy, the egress 743 proxy passes all the MNPs for the MR as explicit prefix routes. It 744 is expected that the proxies belong to a chain of trust that links 745 the primary and the satellite sites together. This, the ingress 746 proxy trusts the egress proxy both for the binding and for the 747 explicit prefixes. 749 Note that in that case, the binding uses the proxy's external address 750 as careof. The packets are thus routed straight between the proxies, 751 outside of the HAHA network. 753 6. Terminology and concepts 755 The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 756 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this document are to be 757 interpreted as described in RFC2119 [7]. 759 Most of the mobility related terms used in this document are defined 760 in the Mobility Related Terminology document [14] and in the Mobile 761 IPv6 specification [15]. 763 Additionally, some terms were created or extended for NEMO. These 764 specific terms are defined in the NEMO Terminology document [4]. 766 This draft introduces the following definitions: 768 Distributed Home Network: In distributed home network, a global Home 769 is advertised by several sites that are geographically distributed 770 and meshed using tunnels in a VPN fashion. Mobile Nodes locate 771 the closest site using DHAAD and bind there. More in Section 7... 773 Partitioned Home Network: A Partitioned Home is a specific deployment 774 of a Distributed Home Network where each location owns a subnet of 775 Home. The local Home Agents accept registration for the local 776 partition. The local HAs also act as NEMO proxy HAs for the rest 777 of Home. 779 Primary Home Agent: A Home Agent that can serve a Binding Update from 780 a Mobile Router. The Mobile Router is always associated with a 781 (set of) primary Home Agent (s) to register its binding. 783 Proxy Home Agent: This is a form of proxy, for the NEMO protocol. A 784 proxy HA acts as a HA for MRs to register, but needs to register 785 to a primary HA in order to accept the binding. 787 Primary site: A site is primary for a MR if at least one local HA on 788 that site can accept a registration for that MR. When Home is not 789 partitioned and sites overlap, primary HAs for a same subnet have 790 to be aware of each other in order to find if a binding already 791 exists in one of the sites and in which Home Agent. 793 satellite site: A site that is not primary for any binding. It is 794 dependent on a parent primary site for HAHA operations. satellite 795 sites are deployed around central primary sites, and one final 796 goal for HAHA is to dynamically draw routes between satellite 797 sites in order to shortcut the backbone of primary HAs. 799 Secondary site: A site is secondary for a MR if it is primary for 800 other MRs but not that one. HAs in a secondary site can act as 801 proxies for that MR, and the site is its own parent. 803 Primary Binding: A Binding is primary if it happens with a primary 804 Home Agent, whether the client is a MR or a proxy HA. 806 Secondary Binding: A Binding is secondary if it happens between a 807 proxy and a non primary Home Agent. It is used to improve the 808 path between sites towards the HA where a MR is registered. 810 Proxy Binding: A Binding is proxy if it happens between a MR and a 811 proxy HA, whether the proxy is a pure proxy HA or a secondary HA 812 acting as proxy for that MR. The proxy HA relays the proxy 813 binding to a primary HA in a primary binding. It may maintain a 814 set of secondary bindings, depending on the deployment. 816 Direct Binding: A Binding that does not pass via a proxy, straight 817 between the MR and its Home Agent. 819 7. Distributed Home Network 821 This section describes a detailed example how multiple Home Agents 822 are configured in different routing domains. You are encouraged to 823 read the nemo basic Home Network Models [3] draft before going 824 through this section. 826 HA HA 827 | ______ | 828 --+-----+--+- . -+- . -+-- TUNNEL --+-----+--+- . -+- .. -+-- 829 | | | | ______ | | | | 830 MR1 MR2 MRi MRN MR1 MR2 MRi MRN 831 ------ ------ ------ ------ ------ ------ ---- - ---- 832 /64 A:B:1:i::/64 /64 A:B:n:i::/64 834 Distributed Home Network /48 835 <------------------------------------------------------------------> 837 extended HN Aggregated HN Virtual HN 838 <----------------------><---------------------->...<---------------> 840 Home Mob Mob Mob Mob Mob Mob Mob 841 <-----><----->...<-----><-----><----->...<----->...<----->...<-----> 843 In distributed home network, a global Home is advertised by several 844 sites that are geographically distributed and meshed using tunnels in 845 a VPN fashion. Mobile Nodes locate the closest site using DHAAD 846 against the global Home Network and bind there. Some form of inter- 847 site synchronization (e.g. a routing protocol), which Mobile IPv6 and 848 Nemo Basic Support do not provide, must take place in order to allow 849 packets to be routed between the incoming site to the Mobile Node. 850 The HAHA (Home Agent to Home Agent) protocol is being designed for 851 that purpose. 853 In one model, called the Partitioned Home Network each site is 854 responsible for a subnet of Home. When a Mobile Node roams far from 855 its natural (primary) site, it registers to a Home Agent on a remote 856 site, that takes the registration and notifies at least the natural 857 site of the foreign registration. 859 One specific advantage of not relying on a Home Link for HAHA 860 communication is that for a large configuration, the Home Agents can 861 be organized hierarchically and distributed geographically, as a set 862 of local clusters linked together to form a global Home Network. 864 8. Message Formats 866 A traditional IGP coul be used over the HAHA tunnel. But in order to 867 integrate HAHA smoothly with the rest of the MIP operation, this 868 drafts suggest to use the messages and formats detailed in the HAHA 869 specification [17]. 871 9. Mobile Router Operation 873 9.1 Locating Home 875 9.2 Proxy MIP client 877 10. Home Agent Operation 879 10.1 Locating the other HAs that serve the same Home 881 10.2 Locating the HA that owns the binding for a HoA 883 At the time of processing a binding update, a Home Agent (be it 884 primary or simply proxy for the binding Home Address) needs to 885 discover if the binding already exists with a primary Home Agent. 886 There are at least 3 approaches that might be deployed for that 887 purpose: 889 Reactive: This method is also referred to as 'on-demand'. In case of 890 a binding cache miss, a primary Home Agent floods a Binding 891 Information Request message to all the other primary Home Agents 892 for the home address that is sought for. The reactive approach 893 can be used between a satellite site and its parent site even when 894 the primary HAs use an other method in the backbone. 896 Proactive: The binding information is shared proactively between the 897 primary Home Agents for the existing bindings. All primary HAs 898 know at any point of time which Home Addresses are bound and with 899 which primary Home Agent. This approach is preferred for stable 900 configurations, for instance if NEMO is used as a tool to simplify 901 the configuration and reconfiguration of mostly stable networks. 903 Predictive: Ranges of Home Addresses and prefixes are preassigned to 904 the Home Agents, following a rule that is shared or commonly 905 computed by all HAs. A partitioned Home Network is an example of 906 that, but this is mostly useful within a site between local Home 907 Agents. 909 11. Acknowledgements 911 The authors wish to thank: 913 12. IANA considerations 915 This document does not require any IANA action. 917 13. Security Considerations 919 This document explores how t use the haha protocol but does not 920 standardize any new operation that would be harmful. 922 14. Changes 924 14.1 Changes from version 00 to 01 926 Added a proxy section to introduce the concept 928 15. References 930 15.1 informative reference 932 [1] Devarapalli, V., "Local HA to HA protocol", 933 draft-devarapalli-mip6-nemo-local-haha-00 (work in progress), 934 July 2005. 936 [2] Patel, A., "Problem Statement for bootstrapping Mobile IPv6", 937 draft-ietf-mip6-bootstrap-ps-03 (work in progress), July 2005. 939 [3] Thubert, P., "NEMO Home Network models", 940 draft-ietf-nemo-home-network-models-04 (work in progress), 941 June 2005. 943 [4] Ernst, T. and H. Lach, "Network Mobility Support Terminology", 944 draft-ietf-nemo-terminology-03 (work in progress), 945 February 2005. 947 [5] Ernst, T., "Network Mobility Support Goals and Requirements", 948 draft-ietf-nemo-requirements-04 (work in progress), 949 February 2005. 951 [6] Ng, C., "Analysis of Multihoming in Network Mobility Support", 952 draft-ietf-nemo-multihoming-issues-03 (work in progress), 953 July 2005. 955 15.2 normative reference 957 [7] Bradner, S., "Key words for use in RFCs to Indicate Requirement 958 Levels", BCP 14, RFC 2119, March 1997. 960 [8] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) 961 Specification", RFC 2460, December 1998. 963 [9] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery 964 for IP Version 6 (IPv6)", RFC 2461, December 1998. 966 [10] Thomson, S. and T. Narten, "IPv6 Stateless Address 967 Autoconfiguration", RFC 2462, December 1998. 969 [11] Fox, B. and B. Petri, "NHRP Support for Virtual Private 970 Networks", RFC 2735, December 1999. 972 [12] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) 973 Addressing Architecture", RFC 3513, April 2003. 975 [13] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host 976 Configuration Protocol (DHCP) version 6", RFC 3633, 977 December 2003. 979 [14] Manner, J. and M. Kojo, "Mobility Related Terminology", 980 RFC 3753, June 2004. 982 [15] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in 983 IPv6", RFC 3775, June 2004. 985 [16] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, 986 "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, 987 January 2005. 989 [17] Wakikawa, R., "Inter Home Agents Protocol Specification", 990 draft-wakikawa-mip6-nemo-haha-spec-00 (work in progress), 991 October 2004. 993 Authors' Addresses 995 Pascal Thubert 996 Cisco Systems 997 Village d'Entreprises Green Side 998 400, Avenue de Roumanille 999 Batiment T3 1000 Biot - Sophia Antipolis 06410 1001 FRANCE 1003 Phone: +33 4 97 23 26 34 1004 Email: pthubert@cisco.com 1006 Ryuji Wakikawa 1007 Keio University and WIDE 1008 5322 Endo Fujisawa Kanagawa 1009 252-8520 1010 JAPAN 1012 Email: ryuji@sfc.wide.ad.jp 1014 Vijay Devarapalli 1015 Nokia Research Center 1016 313 Fairchild Drive 1017 Mountain View, CA 94043 1018 USA 1020 Email: vijay.devarapalli@nokia.com 1022 Intellectual Property Statement 1024 The IETF takes no position regarding the validity or scope of any 1025 Intellectual Property Rights or other rights that might be claimed to 1026 pertain to the implementation or use of the technology described in 1027 this document or the extent to which any license under such rights 1028 might or might not be available; nor does it represent that it has 1029 made any independent effort to identify any such rights. Information 1030 on the procedures with respect to rights in RFC documents can be 1031 found in BCP 78 and BCP 79. 1033 Copies of IPR disclosures made to the IETF Secretariat and any 1034 assurances of licenses to be made available, or the result of an 1035 attempt made to obtain a general license or permission for the use of 1036 such proprietary rights by implementers or users of this 1037 specification can be obtained from the IETF on-line IPR repository at 1038 http://www.ietf.org/ipr. 1040 The IETF invites any interested party to bring to its attention any 1041 copyrights, patents or patent applications, or other proprietary 1042 rights that may cover technology that may be required to implement 1043 this standard. Please address the information to the IETF at 1044 ietf-ipr@ietf.org. 1046 Disclaimer of Validity 1048 This document and the information contained herein are provided on an 1049 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1050 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1051 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1052 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1053 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1054 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1056 Copyright Statement 1058 Copyright (C) The Internet Society (2005). This document is subject 1059 to the rights, licenses and restrictions contained in BCP 78, and 1060 except as set forth therein, the authors retain all their rights. 1062 Acknowledgment 1064 Funding for the RFC Editor function is currently provided by the 1065 Internet Society.