idnits 2.17.00 (12 Aug 2021) /tmp/idnits45644/draft-thubert-nemo-global-haha-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 962. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 939. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 946. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 952. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 968), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 40. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There are 14 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. ** The abstract seems to contain references ([9], [11]), 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 == 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 5, 2004) is 6437 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: '2' is defined on line 853, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 859, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 865, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 868, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 878, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2460 (ref. '2') (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 2461 (ref. '3') (Obsoleted by RFC 4861) ** Obsolete normative reference: RFC 2462 (ref. '4') (Obsoleted by RFC 4862) ** Obsolete normative reference: RFC 3513 (ref. '6') (Obsoleted by RFC 4291) ** Obsolete normative reference: RFC 3633 (ref. '7') (Obsoleted by RFC 8415) ** Downref: Normative reference to an Informational RFC: RFC 3753 (ref. '8') ** Obsolete normative reference: RFC 3775 (ref. '9') (Obsoleted by RFC 6275) == Outdated reference: draft-ietf-mip6-bootstrap-ps has been published as RFC 4640 ** Downref: Normative reference to an Informational draft: draft-ietf-mip6-bootstrap-ps (ref. '10') == Outdated reference: draft-ietf-nemo-basic-support has been published as RFC 3963 == Outdated reference: draft-ietf-nemo-home-network-models has been published as RFC 4887 ** Downref: Normative reference to an Informational draft: draft-ietf-nemo-home-network-models (ref. '12') == Outdated reference: draft-ietf-nemo-terminology has been published as RFC 4885 ** Downref: Normative reference to an Informational draft: draft-ietf-nemo-terminology (ref. '13') == Outdated reference: draft-ietf-nemo-requirements has been published as RFC 4886 ** Downref: Normative reference to an Informational draft: draft-ietf-nemo-requirements (ref. '14') == Outdated reference: draft-ietf-nemo-multihoming-issues has been published as RFC 4980 ** Downref: Normative reference to an Informational draft: draft-ietf-nemo-multihoming-issues (ref. '15') Summary: 23 errors (**), 0 flaws (~~), 15 warnings (==), 8 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 5, 2005 R. Wakikawa 5 Keio University 6 V. Devarapalli 7 Nokia 8 October 5, 2004 10 Global HA to HA protocol 11 draft-thubert-nemo-global-haha-00 13 Status of this Memo 15 By submitting this Internet-Draft, I certify that any applicable 16 patent or other IPR claims of which I am aware have been disclosed, 17 and any of which I become aware will be disclosed, in accordance with 18 RFC 3668. 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 23 Internet-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 5, 2005. 38 Copyright Notice 40 Copyright (C) The Internet Society (2004). All Rights Reserved. 42 Abstract 44 This paper extends Mobile IPv6 [9] and the NEMO Basic Support [11] to 45 remove the Layer 2 dependencies on the Home Link and allow the global 46 (L3) distribution of the HAs that serve a same Home Network. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. Motivations . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . 3 53 2.2 Layer 3 operations . . . . . . . . . . . . . . . . . . . . 4 54 2.3 Path improvement . . . . . . . . . . . . . . . . . . . . . 5 55 2.4 Single point of failure . . . . . . . . . . . . . . . . . 7 56 3. Rationale for the proposed solution . . . . . . . . . . . . . 7 57 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 58 4.1 Initial routing . . . . . . . . . . . . . . . . . . . . . 9 59 4.1.1 External routing . . . . . . . . . . . . . . . . . . . 9 60 4.1.2 Internal routing . . . . . . . . . . . . . . . . . . . 10 61 4.2 Binding . . . . . . . . . . . . . . . . . . . . . . . . . 11 62 4.2.1 Direct primary binding . . . . . . . . . . . . . . . . 11 63 4.2.2 local proxy binding . . . . . . . . . . . . . . . . . 12 64 4.2.3 Foreign proxy binding . . . . . . . . . . . . . . . . 12 65 4.3 Path improvements . . . . . . . . . . . . . . . . . . . . 13 66 4.3.1 Leaking MNP routes in the HAHA network . . . . . . . . 14 67 4.3.2 On-demand proxy routes . . . . . . . . . . . . . . . . 15 68 5. Terminology and concepts . . . . . . . . . . . . . . . . . . . 16 69 6. Distributed Home Network . . . . . . . . . . . . . . . . . . . 18 70 7. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 19 71 8. Mobile Router Operation . . . . . . . . . . . . . . . . . . . 19 72 8.1 Locating Home . . . . . . . . . . . . . . . . . . . . . . 19 73 8.2 Proxy MIP client . . . . . . . . . . . . . . . . . . . . . 19 74 9. Home Agent Operation . . . . . . . . . . . . . . . . . . . . . 19 75 9.1 Locating the other HAs that serve the same Home . . . . . 19 76 9.2 Locating the HA that owns the binding for a HoA . . . . . 19 77 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 78 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 21 80 Intellectual Property and Copyright Statements . . . . . . . . 22 82 1. Introduction 84 The reader of this document is expected to be familiar with both the 85 Mobile IPv6 [9] and NEMO Basic Support [11] documents. As such, the 86 reader is expected to understand the concept of a Home Link and the 87 Neighbor Discovery related operations that take place over that link. 89 Home Agent global distribution is useful when a Mobile Router moves 90 geographically large area such as airplane, vehicle, etc... The 91 overhead of the basic NEMO protocol is redundant route caused by the 92 bi-directional tunnel between a Home Agent and a Mobile Router. If a 93 Mobile Router moves far away from a Home Agent, the overhead can not 94 be ignored. 96 Thus, it is reasonable to consider that a Mobile Router dynamically 97 switches to the topologically closest Home Agent (Home Link). This 98 distribution is also effective for load-balancing. The Home Agent is 99 expected to serve thousands of Mobile Routers on its Home Link and 100 tunnels all packets for the Mobile Routers by itself. 102 But with NEMO basic support and MIPv6, Home is locally anchored to 103 the Home Link at Layer 2, so Home can not be distributed 104 geographically. In particular for NEMO, what's needed is a route to 105 a mobile prefix via a tunnel end point that is the CareOf address of 106 the Mobile Router. The Home Address is but a practical artifact that 107 is mostly needed as a correlator for the registration. 109 This draft proposes extensions that enable the HA to HA communication 110 at Layer 3, allowing to get rid of the Home Link in configurations 111 where it's not needed. 113 2. Motivations 115 2.1 Requirements 117 This draft addresses two generic requirements expressed in the Nemo 118 requirements [14]: 120 Local Mobility and Global Mobility: Multihoming is mentioned as 121 desirable. The global mobility type is not expected to be limited 122 for any consideration other than administrative and security 123 policies. 125 Scalability: NEMO support signaling and processing is expected to 126 scale to a potentially large number of mobile networks. Thus 127 draft extends the scalality of the NEMO basic protocol. 129 There is a requirement from airplane companies which want to be at 130 Home in the various airports that their planes visit. In fact, this 131 is expressed in an abstract fashion by the case (1,n,1) of the NEMO 132 multihoming issues [15] draft: "Single MR, Multiple HAs, Single 133 NEMO-Prefix". 135 There is also a general direction that indicates that NEMO could be 136 extended as a solution for VPN. To get there, we must ensure that 137 NEMO is upscaled to the classical capabilities of VPN, including the 138 global distribution of Points Of Presence. It is a classical feature 139 for VPNs to allow the roaming users to connect to the closest point 140 of presence into their company VPN. The same feature can not be 141 provided with MIPv6 or NEMO, because the Home depends on a link that 142 has a unique physical location. 144 2.2 Layer 3 operations 146 Mobile IPv6 [9] standarizes an interface between a Mobile Node and 147 its Home Agent and its correspondents, as well as an interface 148 between Home Agents. One angle of the MIPv6 operation is that the 149 protocols hides the MN mobility by making as if the Mobile Node was 150 always connected to a Home Link. The connectivity is maintained by 151 Home Agents that are permanently and physically attached to that Home 152 Link. 154 So the model for MIPv6 is Home Link centric and it is no surprise 155 that it extends IPv6 Neighbor Discovery [3] for its operations, in 156 particular for HAs to discover each others, and to discover when one 157 of them has a binding for a Mobile Node, and which one. An immediate 158 consequence of being Link centric is that Home can not be distributed 159 at Layer 3, locally within a site or over the Internet. 161 the NEMO Basic Support [11] inherits the concept of Home Link and 162 MIPv6 operations on that link, making NEMO partially a link layer 163 operation. On the other hand, the NEMO Basic Support also operates 164 as a routing protocol at L3, for example when it injects routes in 165 the explicit prefix mode. So NEMO operations are somewhat half L2 166 and half L3. 168 What we are getting at with the HAHA protocol is placing NEMO fully 169 at L3. This mostly means the replacement of all ND based exchanges 170 by some equivalent, but at Layer 3, over the Internet Protocol. This 171 also means the abstraction of the concept of Home Address into a 172 globally unique router ID, as opposed to an address from a Home Link. 174 So even if this paper trivially applies to Mobile IPv6, we place our 175 descriptions in the context of NEMO, and use MRs where MIPv6 MNs 176 could fit as well. 178 2.3 Path improvement 180 MIPv6 comes with a Route Optimization scheme that enables a direct 181 MR-CN conversation, bypassing the Home Agent. With the basic 182 support, NEMO does not have such a support yet. In any case, RO 183 comes at an additional cost in terms of protocol, which varies with 184 the degree of expected trust. 186 Without Route optimization, all the packets MR-CN flow via the Home 187 Agent; this increases both the cost and the latency. The resulting 188 path can be illustrated like this: 190 CN1 <--------------------- -- -- -----------------+ +---> CN2 191 (NYC) | | (NICE) 192 | | 193 | | 194 | | 195 | | 196 MRHA tunnel | | 197 ===================== == == ================ 198 MR <--------------------- -- -- ----------------- HA (BRITTANY) 199 (NJ) ===================== == == ================ 200 | 201 | 202 ----- 203 ///// 204 Home Link 206 Current model with a Home Link 208 The routing overhead becomes costly when: 210 The distance ||MR, CN|| is much smaller then the sum of the 211 distances ||MR, HA|| + ||HA, CN||. 213 AND 215 ||MR, HA||+||HA, CN|| is costly. If the 3 points are very close, 216 the overhead is relatively important, but small in absolute terms. 218 In the picture above, say that a European phone (MR) is roaming in 219 New Jersey but Homed in Brittany. And say that the phone owner 220 places a call in New York city to CN1. Without RO, the voice packets 221 flow back and forth over the peering lines between Brittany and the 222 US, and the routing overhead causes an additional latency that 223 decreases the perceived quality of the phone call. 225 On the other hand, calling CN2 would result in a small, acceptable 226 overhead, considering that the distance ||HA, CN2|| is very small 227 with regards to ||MR, HA|| or ||MR, CN2||. Now, when the MR moves 228 back to Brittany and places a new call to CN2, going via the HA might 229 double the distance, but the whole thing being local, it is 230 negligible. 232 The geographical distribution of Home generalizes this latter 233 situation. If we can get rid of the concept of a Home Link that 234 anchors the HA in a single location, then we can distribute HAs 235 geographically, and, hopefully, one is close to our MR when it's 236 roaming. 238 So if a MR can locate and bind with a closeby HA, then ||MR, HA|| is 239 contained and the overhead is globally limited. In a same fashion, 240 when a CN sends a packet to the MR, it finds a HA closeby and the 241 overhead ||HA, CN|| is contained as well. 243 CN1 <-----+ +-----> CN2 244 (NYC) | | (NICE) 245 | | 246 | | 247 | | 248 | long distance | 249 | HAHA tunnel | 250 =========== == == ================= 251 HA' ------------ -- -- ------------------ HA (BRITTANY) 252 (DC) =========== == == ================= 253 || | || (under the Atlantic :) 254 || | || 255 || | || short distance 256 || | || MRHA Tunnel 257 || | || 258 v 259 MR (NJ) 261 Globally Distributed HA for World Wide service 263 In our previous example, we see that a HA' deployed in the East Coast 264 saves the round trip over the Atlantic. There is a new overhead for 265 the call to Europe, though, since an additional path is involved 266 between MR and HA'. Then again, if both ||MR, HA'|| and ||CN2, HA|| 267 are relatively small compared to ||HA, HA'|| then the overhead is 268 acceptable; unless all 3 points are located closeby, in which case, 269 again, the additional cost is acceptable. 271 CN2 (NICE) 272 ^ 273 | 274 HA'(DC) ------------------------------------------------- HA 275 | (BRITTANY) 276 v 277 MR (NJ) 279 <-------------------------------------------------------------> 280 Diagonal (direct path) cost 282 <---------------------------------------------------------------> 283 Via HAs 285 Illustrating that the overhead can be relatively small 287 2.4 Single point of failure 289 The Home Link is a single point of failure for MIPv6/NEMO operations. 291 Should the Home Link fail, the whole set of MNs / MRs is disconnected 292 from the rest of the world. One could decide to use a virtual link 293 for Home, but then: 295 MIPv6 provides a support for multiple HAs, with the DHAAD mechanism. 296 This mechanism helps scaling up the Home by adding HAs dynamically, 297 and eventually load balancing the bindings between them. But this 298 all relies on HAHA communication over the PHYSICAL Home Link; so 299 making that link virtual implies a single Home Agent. 301 In turn this makes the HA a single point of failure, and disables the 302 scalability that the DHAAD mechanism provides to MIPv6. 304 3. Rationale for the proposed solution 306 For the time being, the precise flows are not elaborated. One idea 307 is that a protocol such as IS-IS or OSPFv3 could help a lot, mostly 308 in the registration phase. Another is that HAs should be proactively 309 preassigned to receive a given set of registration, in order to allow 310 a certain degree of aggregation within sites and in between site. 311 Finally, the concept of proxy is introduced to limit the number of 312 primary sites (to 1?) and as a key element for an upcoming NEMO route 313 optimization scheme, where routes can be echanged in a trusted 314 fashion between proxies. 316 4. Overview 318 This description covers the specific case of a Partitioned Home 319 Network. Home is subnetted and the subnets are attributed to the 320 distributed sites. As a result, in a given location, HAs will be 321 operating both as primary HA taking the registrations for the local 322 partition and proxy HA for registrations that belong to other sites. 323 Additional satellite sites might be deployed around some of the main 324 sites. 326 ## ## 327 ## ## ## 328 ##\ || || proxy/parent 329 \\ || || tunnel 330 \\ ---||---- ...... ... ----||--- 331 \\| | .... .... ... | | 332 \ ñ---ñ | .... ..... | ñ---ñ | 333 ## ----- | X | --------------------------------- \ / ------## 334 ## ----- ñ---ñ .... HAHA tunnel .... ñ ------## 335 | --------------------------------- | 336 ------\ \ ... .... / /-||--- 337 \ \... .../ / || 338 \.\. /./ || 339 .\.\ internet /./. || 340 .\.\ ........... / /... ## 341 ...\ \ / / .. ## 342 .. \ \ / / ... 343 ...\ \ / / ... 344 ..\ \ ...... / /... 345 \.\ . ...... .././ 346 ñ primary HA \ \ .. / / 347 \ \ --------- / / 348 ## proxy HA or \ \ ñ ñ / / 349 ## satellite site \ \ / / 350 \ ñ /-----## 351 -- | / \ ------## 352 | | primary site | ñ ñ | 353 -- --------- 355 It is out of the scope of this document to discuss how the subnetting 356 was decided and configured. It is also out of the scope of this 357 document to describe the operations within a site where more than one 358 HA is deployed. It is expected that in each primary site, HAs 359 discover each other, mesh using tunnels, and form an area that owns 360 the partition of Home that was assigned to that site. 362 4.1 Initial routing 364 4.1.1 External routing 366 Sites are expected to be connected locally to the internet, via the 367 network of one or more service provider. Each site has a default 368 route to the internet via that connection. 370 . .. / 371 --------- ........ ..;. --------- 372 | | .. / ..... | | 373 | ::/0 -> .... ; ... <- ::/0 | 374 | ============HAHA=TUNNEL=========== | 375 | | .... ; .... | | 376 | | .<- Home::/32 / Home::/32 ->..| | 377 --------- ... ; ... --------- 378 ..... / .. 379 . ;.... ...... 380 / .......... 382 In return, each site advertises the aggregation that encompasses the 383 Distributed Home Network aggregation back into the service provider 384 network, to the outside world (the internet). 386 ...... 387 --------- ....... .../ --------- 388 | | ..... ; .... | | 389 | ---------------------------------- | 390 | <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< | 391 | v ------------HAHA-tunnel----------- ^ | 392 | v | / .| ^ | 393 | \ ==MRHA== / ... | ^ | 394 | HA >---------- MR ; .. | ^ | 395 | / =tunnel= / .| ^ | 396 | v | ; | ^ | 397 | >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> CN >>>>>> HA | 398 | | . ; ... | | 399 --------- . / ... --------- 400 ... ;.... ...... 401 / .......... 403 Thus, a site attracts the DHAAD requests from any MR that happens to 404 be roaming close to the site, regardless of the MR primary site. So 405 MRs bind to the closest site from their physical location. In a same 406 fashion, CNs send all packets to LFNs via the closest Home site. But 407 packets back flow directly from the site where the MR is bound. 409 4.1.2 Internal routing 411 In each area, border HAs are elected to mesh with peers in other 412 sites. Again, they discover each other, mesh using tunnels, and form 413 a backbone. It might be preferrable to form a fully meshed backbone, 414 in order to limit the cost of routing between sites. Also, making 415 the backbone a transit area enables the use of a specific HA for the 416 HAHA protocol that acts as an OSPF Designated Router or a BGP Route 417 Reflector. 419 ...... 420 --------- ....... .../ --------- 421 | site1 | ..... ; .... | Site2| 422 | ---------------------------------- | 423 | Home:Site2::/48 -> <- Home:Site1::/48 | 424 | ------------HAHA-tunnel----------- | 425 | ñ ñ ñ | / .| ñ ñ | 426 | ñ ñ | <- Home::/32 ; Home::/32 -> | ñ ñ ñ | 427 --------- . / ... --------- 428 ... ....; ...... 429 /.......... 431 If a link state protocol such as OSPFv3 is deployed between the 432 primary HAs, then it uses the meshed backbone as its area zero, and 433 each site as an area. Sites exchange their partitions of Home in the 434 form of summarized routes. 436 It can be expected that, in order to scale, satellite sites would be 437 deployed to take the proxy bindings but would not participate to the 438 HAHA protocol that happens between the primary sites - at least when 439 a proactive version of HAHA is being used. 441 ...... 442 --------- ....... .../. --------- 443 | Sat1 | ..... ; .... | Site1 | 444 | ---------------------------------- | 445 | Home::/32 -> <- Home:Site1:Sat1:/64 | 446 | ----proxyHAHA-tunnel-------------- | 447 | #### | / .| ñ ñ ñ | 448 | #### | <- Home::/32 ; Home::/32 -> | ñ ñ | 449 --------- . / ... --------- 450 ... ....; ...... 451 /.......... 453 In a satellite site, HAs are only proxy, never primary. Each proxy 454 HA has at least one assigned parent HA, which belongs to a primary 455 site. A tunnel is established between the proxy HA and the parent 456 HA. The parent advertises the Home Aggregation to the proxy over 457 that tunnel, as it does over the internet. In return, the proxy 458 advertises its own prefixes, and redistributes the Home Aggregation 459 over the internet. Finally, the parent redistributes the route to 460 the proxy's network into its area, via itself, as an external route. 462 4.2 Binding 464 At that point, the primary sites are ready to accept bindings, either 465 directly from Mobile Routers or via proxy HAs. This is the runtime 466 phase for HAHA. 468 A MR that is located close to its primary site will register there 469 for its primary binding. In that case, the binding is direct. 470 Otherwise, the MR will use a proxy in order to bind locally, and the 471 proxy will perform the primary binding on behalf of the MR. If the 472 proxy is parented at the primary site, the binding is local; 473 otherwise, it is called a foreign binding. 475 4.2.1 Direct primary binding 477 When the primary HA accepts a direct binding from a MR, then it must 478 let the other primaries know that it owns the binding for that Home 479 Address, in a fashion that is discussed in Section 9.2. 481 ...... 482 ......../. ... --------------------------- 483 ... ; .. | Site1 | 484 .. / Home::/32 ->.| ñ--ñ--ñ | 485 ... ; .. | / | 486 .... / MR ==MRHA==== ñ <- Home:site1:MNP::/64 | 487 .... ; | .. | \ | 488 ... / ------ ... | ñ--ñ | 489 ... ; MNP | | 490 ... / .. ... --------------------------- 491 ........... 493 Primary HA injects necessary MR routes in area 495 The primary HA installs all (implicit and explicit) routes to the MR 496 MNPs over the MRHA tunnel. It must also inject any required route, 497 such as explicit prefix routes, into the primary area, as external 498 routes via itself. All these routes are summarized at the area 499 border and the other areas are not affected by the routing change. 501 4.2.2 local proxy binding 503 When a MR binds to a satellite site, a HA acts as a proxy and binds 504 in turn with a primary site, on behalf of that MR, to create the 505 primary binding. The proxy binding can only succeed if the primary 506 binding does. If the primary accepts the binding, then it returns a 507 positive Binding Ack, with the list of the prefixes that are routed 508 via the Mobile Router. 510 .. ........ 511 --------- .. . ... ------------------ 512 | Sat1 | .. /. | Site1 | 513 | | <- Home::/32 ; . | | 514 | | .. / .. | | 515 | ---> =========================== ñ <- Home:site1 | 516 | | |. / .. | :MNP::/64 | 517 | -- # ======= MR ; ... | | 518 | | . | / | | 519 --------- . ----- ; ... ------------------ 520 MNP.../.. 522 Then the proxy HA installs the routes that it got from the the 523 positive Binding Acknowledgement over the proxy MRHA tunnel, and 524 Acknowledges the proxy BU. Once a primary binding has succeeded, the 525 proxy might establish secondary bindings with other sites. 527 4.2.3 Foreign proxy binding 529 When a MR binds to a foreign site, whether the site is primary or 530 satellite, a HA from the site acts as a proxy as if the site was a 531 satellite from the primary. 533 ----------------- .. .. ... ----------------- 534 | Foreign site | .. .. | . | MR primary Site | 535 | ------------------------ | 536 | +-------------------------------------- primary | 537 | | +----------proxyHAHA----------------- | 538 | | | ------------------------ ^ | 539 | | | | . | ^ | 540 -------|| ||----- .. | .. ----------------- 541 || || - . - . - . - . - . 542 -------|| ||----- | . 543 | | | |. |MNP . .. 544 | proxy --MRHA--- MR-| | ... 545 | HA --------- | | ... 546 | | .. . . 547 |Foreign satellite|<- Home::/32 | . 548 ----------------- ... .. ... 550 4.3 Path improvements 552 When the MR binds in a foreign location, the transport between an 553 arbitrary correspondent and the MR within the HAHA network might be 554 far from optimized. 556 As a result of the primary binding, a proxyHAHA tunnel is established 557 between the proxy and the primary HA. That tunnel is itself 558 encapsulated in the HAHA tunnels when packets flow over the internet. 560 .. .. |... 561 ----------------- .. . ... ----------------- 562 | Foreign site | .. | . | MR primary Site | 563 | ------------------------ | 564 | +-------------------------------------- primary | 565 | |v<<<<<<<<<<>>>>>>>>> MR-| . .. | site:: | 575 | --------- | | ...| /48 | 576 | | . ..| ^ | 577 |Foreign satellite|<- Home::/32 | . |Foreign ^ site | 578 ----------------- . .. ------| ^ |------ 579 - . - . - . - .- . - . - . - | ^ | 580 ... .. ------| ^ |------ 581 .. ...| ^ | 582 ... CN >>>>home::/32>>>>> | 583 ... ..| | 584 .. ..| | 585 ..... Home::/32 ->| | 586 ..... ....... |Foreign satellite| 587 .......... ---------------- 589 The path from CN to MR is not optimized 591 Also, packets from an arbitrary correspondent reach the site that is 592 closest to the correspondent, then forwarded to the primary site for 593 the destination. Within the primary site, they are encapsulated 594 towards the proxy and sent across the HAHA network again. Finally 595 they reach the proxy that decapsulates the packets and encapsulates 596 them back. 598 In order to improve this, various possibilities are offered: 600 4.3.1 Leaking MNP routes in the HAHA network 602 The proxy can establish a secondary binding with its parent. In 603 return, the parent redistributes an external route to the MNP via 604 itself, and leaks that route inside the whole HAHA network. 606 .. .. |... 607 ----------------- .. . .. 608 | Foreign site | .. | . 609 | ----------------------------------+ 610 | parentHA <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< | 611 | ------------------------------+ ^ | 612 | |v| | . | ^ | 613 -------||v||----- .. | .. | ^ | 614 ||v|| - . - . - . - . - . - . - | ^ | 615 -------||v||----- | . ------| ^ |------ 616 | |v| |. . .. | home: | 617 | --MRHA--- |MNP | ... | site: | 618 | proxyHA >>>>>>>>>> MR-| . .. | mnp:: | 619 | --------- | | ...| /64 | 620 | | . ..| ^ | 621 | egress satellite|<- Home::/32 | . |Foreign ^ site | 622 ----------------- . .. ------| ^ |------ 623 - . - . - . - .- . - . - . - | ^ | 624 ... .. ------| ^ |------ 625 .. ...| ^ | 626 ... CN >>>>home::/32>>>>> | 627 ... ..| | 628 .. ..| | 629 ..... Home::/32 ->| | 630 ..... ....... |ingress satellite| 631 .......... ---------------- 633 The path from CN to MR bypasses the primary HA 635 This bypasses the primary home agent for packet forwarding. Note 636 that the packets still flow within the HAHA network between the 637 ingress site close to the correspondent and the egress (satellite) 638 site. 640 Note also that when the proxy HA binds to either its parent or the 641 primary HA, it uses an address from within the HAHA network (its HAHA 642 Address), as CareOf. 644 4.3.2 On-demand proxy routes 646 The proxy can establish a secondary binding with the correspondent's 647 proxy provided there's such a node. It might be envisioned to adapt 648 NHRP [5] for IPv6 in order to discover the remote tunnel end point. 650 ----------------- .... 651 | | .... .. 652 | egress satellite|<- Home::/32 | . .. 653 | | .. . 654 | --MRHA--- |MNP1 .. 655 | proxyHA >>>>>>>>>> MR1-| .. 656 | --------- | ... 657 | ^ | .. 658 ------| ^ |------ .. 659 .... | ^ | . 660 .. | ^ | proxy-to-proxy ... 661 ... | ^ | on demand tunnel ... 662 .. | ^ | .. 663 - . -| ^ |. - . - . - .- . - . - . - . - 664 ------| ^ |------ .. 665 | ^ | ..... 666 | ^ --MRHA--- |MNP2 ..... 667 | proxyHA <<<<<<<<<< MR2-| .... 668 | --------- | ... 669 | |. .. 670 |ingress satellite|<- Home::/32 ... 671 | | ... .... 672 ----------------- ............ 674 The path is now direct between the proxies 676 An example of application is when two proxies from a same Home 677 establish a cross binding. In fact, the Mobile Routers are unaware 678 of the path improvement that takes place. This feature might be 679 desirable when the privacy of the location is an issue for the 680 service provider. 682 As part of the secondary binding to the ingress proxy, the egress 683 proxy passes all the MNPs for the MR as explicit prefix routes. It 684 is expected that the proxies belong to a chain of trust that links 685 the primary and the satellite sites together. This, the ingress 686 proxy trusts the egress proxy both for the binding and for the 687 explicit prefixes. 689 Note that in that case, the binding uses the proxy's external address 690 as careof. The packets are thus routed straight between the proxies, 691 outside of the HAHA network. 693 5. Terminology and concepts 695 The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 696 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this document are to be 697 interpreted as described in RFC2119 [1]. 699 Most of the mobility related terms used in this document are defined 700 in the Mobility Related Terminology document [8] and in the Mobile 701 IPv6 specification [9]. 703 Additionally, some terms were created or extended for NEMO. These 704 specific terms are defined in the NEMO Terminology document [13]. 706 This draft introduces the following definitions: 708 Distributed Home Network: In distributed home network, a global Home 709 is advertised by several sites that are geographically distributed 710 and meshed using tunnels in a VPN fashion. Mobile Nodes locate 711 the closest site using DHAAD and bind there. More in Section 6... 713 Partitioned Home Network: A Partitioned Home is a specific deployment 714 of a Distributed Home Network where each location owns a subnet of 715 Home. The local Home Agents accept registration for the local 716 partition. The local HAs also act as NEMO proxy HAs for the rest 717 of Home. 719 Primary Home Agent: A Home Agent that can serve a Binding Update from 720 a Mobile Router. The Mobile Router is always associated with a 721 (set of) primary Home Agent (s) to register its binding. 723 Proxy Home Agent: This is a form of proxy, for the NEMO protocol. A 724 proxy HA acts as a HA for MRs to register, but needs to register 725 to a primary HA in order to accept the binding. 727 Primary site: A site is primary for a MR if at least one local HA on 728 that site can accept a registration for that MR. When Home is not 729 partitioned and sites overlap, primary HAs for a same subnet have 730 to be aware of each other in order to find if a binding already 731 exists in one of the sites and in which Home Agent. 733 satellite site: A site that is not primary for any binding. It is 734 dependent on a parent primary site for HAHA operations. satellite 735 sites are deployed around central primary sites, and one final 736 goal for HAHA is to dynamically draw routes between satellite 737 sites in order to shortcut the backbone of primary HAs. 739 Secondary site: A site is secondary for a MR if it is primary for 740 other MRs but not that one. HAs in a secondary site can act as 741 proxies for that MR, and the site is its own parent. 743 Primary Binding: A Binding is primary if it happens with a primary 744 Home Agent, whether the client is a MR or a proxy HA. 746 Secondary Binding: A Binding is secondary if it happens between a 747 proxy and a non primary Home Agent. It is used to improve the 748 path between sites towards the HA where a MR is registered. 750 Proxy Binding: A Binding is proxy if it happens between a MR and a 751 proxy HA, whether the proxy is a pure proxy HA or a secondary HA 752 acting as proxy for that MR. The proxy HA relays the proxy 753 binding to a primary HA in a primary binding. It may maintain a 754 set of secondary bindings, depending on the deployment. 756 Direct Binding: A Binding that does not pass via a proxy, straight 757 between the MR and its Home Agent. 759 6. Distributed Home Network 761 This section describes a detailed example how multiple Home Agents 762 are configured in different routing domains. You are encouraged to 763 read the nemo basic Home Network Models [12] draft before going 764 through this section. 766 HA HA 767 | ______ | 768 --+-----+--+- . -+- . -+-- TUNNEL --+-----+--+- . -+- .. -+-- 769 | | | | ______ | | | | 770 MR1 MR2 MRi MRN MR1 MR2 MRi MRN 771 ------ ------ ------ ------ ------ ------ ---- - ---- 772 /64 A:B:1:i::/64 /64 A:B:n:i::/64 774 Distributed Home Network /48 775 <------------------------------------------------------------------> 777 extended HN Aggregated HN Virtual HN 778 <----------------------><---------------------->...<---------------> 780 Home Mob Mob Mob Mob Mob Mob Mob 781 <-----><----->...<-----><-----><----->...<----->...<----->...<-----> 783 In distributed home network, a global Home is advertised by several 784 sites that are geographically distributed and meshed using tunnels in 785 a VPN fashion. Mobile Nodes locate the closest site using DHAAD 786 against the global Home Network and bind there. Some form of 787 inter-site synchronization (e.g. a routing protocol), which Mobile 788 IPv6 and Nemo Basic Support do not provide, must take place in order 789 to allow packets to be routed between the incoming site to the Mobile 790 Node. The HAHA (Home Agent to Home Agent) protocol is being designed 791 for that purpose. 793 In one model, called the Partitioned Home Network each site is 794 responsible for a subnet of Home. When a Mobile Node roams far from 795 its natural (primary) site, it registers to a Home Agent on a remote 796 site, that takes the registration and notifies at least the natural 797 site of the foreign registration. 799 One specific advantage of not relying on a Home Link for HAHA 800 communication is that for a large configuration, the Home Agents can 801 be organized hierarchically and distributed geographically, as a set 802 of local clusters linked together to form a global Home Network. 804 7. Message Formats 806 8. Mobile Router Operation 808 8.1 Locating Home 810 8.2 Proxy MIP client 812 9. Home Agent Operation 814 9.1 Locating the other HAs that serve the same Home 816 9.2 Locating the HA that owns the binding for a HoA 818 At the time of processing a binding update, a Home Agent (be it 819 primary or simply proxy for the binding Home Address) needs to 820 discover if the binding already exists with a primary Home Agent. 821 There are at least 3 approaches that might be deployed for that 822 purpose: 824 Reactive: This method is also referred to as 'on-demand'. In case of 825 a binding cache miss, a primary Home Agent floods a Binding 826 Information Request message to all the other primary Home Agents 827 for the home address that is sought for. The reactive approach 828 can be used between a satellite site and its parent site even when 829 the primary HAs use an other method in the backbone. 831 Proactive: The binding information is shared proactively between the 832 primary Home Agents for the existing bindings. All primary HAs 833 know at any point of time which Home Addresses are bound and with 834 which primary Home Agent. This approach is preferred for stable 835 configurations, for instance if NEMO is used as a tool to simplify 836 the configuration and reconfiguration of mostly stable networks. 838 Predictive: Ranges of Home Addresses and prefixes are preassigned to 839 the Home Agents, following a rule that is shared or commonly 840 computed by all HAs. A partitioned Home Network is an example of 841 that, but this is mostly useful within a site between local Home 842 Agents. 844 10. Acknowledgements 846 The authors wish to thank: 848 11 References 850 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 851 Levels", BCP 14, RFC 2119, March 1997. 853 [2] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) 854 Specification", RFC 2460, December 1998. 856 [3] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery 857 for IP Version 6 (IPv6)", RFC 2461, December 1998. 859 [4] Thomson, S. and T. Narten, "IPv6 Stateless Address 860 Autoconfiguration", RFC 2462, December 1998. 862 [5] Fox, B. and B. Petri, "NHRP Support for Virtual Private 863 Networks", RFC 2735, December 1999. 865 [6] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) 866 Addressing Architecture", RFC 3513, April 2003. 868 [7] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host 869 Configuration Protocol (DHCP) version 6", RFC 3633, December 870 2003. 872 [8] Manner, J. and M. Kojo, "Mobility Related Terminology", RFC 873 3753, June 2004. 875 [9] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in 876 IPv6", RFC 3775, June 2004. 878 [10] Patel, A., "Problem Statement for bootstrapping Mobile IPv6", 879 draft-ietf-mip6-bootstrap-ps-00 (work in progress), July 2004. 881 [11] Devarapalli, V., "Network Mobility (NEMO) Basic Support 882 Protocol", draft-ietf-nemo-basic-support-03 (work in progress), 883 June 2004. 885 [12] Thubert, P., Wakikawa, R. and V. Devarapalli, "NEMO Home 886 Network models", draft-ietf-nemo-home-network-models-00 (work 887 in progress), April 2004. 889 [13] Ernst, T. and H. Lach, "Network Mobility Support Terminology", 890 draft-ietf-nemo-terminology-01 (work in progress), February 891 2004. 893 [14] Ernst, T., "Network Mobility Support Goals and Requirements", 894 draft-ietf-nemo-requirements-02 (work in progress), February 895 2004. 897 [15] Ernst, T., "Analysis of Multihoming in Network Mobility 898 Support", draft-ietf-nemo-multihoming-issues-00 (work in 899 progress), July 2004. 901 Authors' Addresses 903 Pascal Thubert 904 Cisco Systems 905 Village d'Entreprises Green Side 906 400, Avenue de Roumanille 907 Batiment T3 908 Biot - Sophia Antipolis 06410 909 FRANCE 911 Phone: +33 4 97 23 26 34 912 EMail: pthubert@cisco.com 914 Ryuji Wakikawa 915 Keio University and WIDE 916 5322 Endo Fujisawa Kanagawa 917 252-8520 918 JAPAN 920 EMail: ryuji@sfc.wide.ad.jp 922 Vijay Devarapalli 923 Nokia Research Center 924 313 Fairchild Drive 925 Mountain View, CA 94043 926 USA 928 EMail: vijay.devarapalli@nokia.com 930 Intellectual Property Statement 932 The IETF takes no position regarding the validity or scope of any 933 Intellectual Property Rights or other rights that might be claimed to 934 pertain to the implementation or use of the technology described in 935 this document or the extent to which any license under such rights 936 might or might not be available; nor does it represent that it has 937 made any independent effort to identify any such rights. Information 938 on the procedures with respect to rights in RFC documents can be 939 found in BCP 78 and BCP 79. 941 Copies of IPR disclosures made to the IETF Secretariat and any 942 assurances of licenses to be made available, or the result of an 943 attempt made to obtain a general license or permission for the use of 944 such proprietary rights by implementers or users of this 945 specification can be obtained from the IETF on-line IPR repository at 946 http://www.ietf.org/ipr. 948 The IETF invites any interested party to bring to its attention any 949 copyrights, patents or patent applications, or other proprietary 950 rights that may cover technology that may be required to implement 951 this standard. Please address the information to the IETF at 952 ietf-ipr@ietf.org. 954 Disclaimer of Validity 956 This document and the information contained herein are provided on an 957 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 958 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 959 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 960 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 961 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 962 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 964 Copyright Statement 966 Copyright (C) The Internet Society (2004). This document is subject 967 to the rights, licenses and restrictions contained in BCP 78, and 968 except as set forth therein, the authors retain all their rights. 970 Acknowledgment 972 Funding for the RFC Editor function is currently provided by the 973 Internet Society.