idnits 2.17.1 draft-thubert-nemo-basic-usages-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by 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 == It seems as if not all pages are separated by form feeds - found 0 form feeds but 20 pages 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 are 5 instances of too long lines in the document, the longest one being 2 characters in excess of 72. ** The abstract seems to contain references ([7]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 9 instances of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. 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). == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: In order for a Mobile Router to emulate returning Home, it can connect to one or more access link(s) configured for that purpose on the Home Agent. The Mobile Router, after connecting to the access link, SHOULD not send any routing protocol updates on the egress interface because the routing information from the Mobile Router might adversely affect IPv6 route aggregation on the Home Network. However, the Mobile Router must register its binding as if it was accessing a foreign link. -- 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 (February 14, 2004) is 7349 days in the past. Is this intentional? 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 541, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 544, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 547, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 564, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 570, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2460 (ref. '1') (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 2461 (ref. '2') (Obsoleted by RFC 4861) ** Obsolete normative reference: RFC 2462 (ref. '3') (Obsoleted by RFC 4862) ** Obsolete normative reference: RFC 3513 (ref. '4') (Obsoleted by RFC 4291) == Outdated reference: A later version (-03) exists of draft-ietf-nemo-basic-support-02 == Outdated reference: A later version (-06) exists of draft-ietf-nemo-requirements-01 ** Downref: Normative reference to an Informational draft: draft-ietf-nemo-requirements (ref. '8') == Outdated reference: A later version (-06) exists of draft-ietf-nemo-terminology-00 ** Downref: Normative reference to an Informational draft: draft-ietf-nemo-terminology (ref. '9') == Outdated reference: A later version (-01) exists of draft-wakikawa-mip6-nemo-haha-00 -- Possible downref: Normative reference to a draft: ref. '10' Summary: 12 errors (**), 0 flaws (~~), 15 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Mobility P. Thubert 3 Internet-Draft Cisco Systems 4 Expires: August 14, 2004 R. Wakikawa 5 Keio University 6 V. Devarapalli 7 Nokia 8 February 14, 2004 10 Examples of basic Nemo usage 11 draft-thubert-nemo-basic-usages-01 13 Status of this Memo 15 This document is an Internet-Draft and is in full conformance with 16 all provisions of Section 10 of RFC2026. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that other 20 groups may also distribute working documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at http:// 28 www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on August 14, 2004. 35 Copyright Notice 37 Copyright (C) The Internet Society (2004). All Rights Reserved. 39 Abstract 41 This paper documents some practical scenarios and the associated 42 issues when deploying Mobile Routers, conforming the Nemo Basic 43 Support draft [7]. 45 The aim here is specifically to provide some examples of organization 46 of the Home Network, as they were discussed in the Nemo and Nemo 47 Design mailing lists. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Terminology and concepts . . . . . . . . . . . . . . . . . . . 4 53 3. General Expectations . . . . . . . . . . . . . . . . . . . . . 6 54 4. Extended Home Network . . . . . . . . . . . . . . . . . . . . 7 55 4.1 Returning Home . . . . . . . . . . . . . . . . . . . . . . . . 8 56 5. Aggregated Home . . . . . . . . . . . . . . . . . . . . . . . 9 57 5.1 Returning Home . . . . . . . . . . . . . . . . . . . . . . . . 10 58 6. Virtual Home Network . . . . . . . . . . . . . . . . . . . . . 11 59 7. Mobile Home . . . . . . . . . . . . . . . . . . . . . . . . . 13 60 8. Changes from version 00 to 01 . . . . . . . . . . . . . . . . 15 61 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 62 References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 63 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 17 64 A. Returning Home emulation in the virtual case . . . . . . . . . 18 65 Intellectual Property and Copyright Statements . . . . . . . . 19 67 1. Introduction 69 This document assumes that the reader is familiar with Mobile IPv6 as 70 defined in [6], and with the concept of Mobile Router defined in the 71 Nemo terminology document [9]. 73 Four different organizations of the Home Network including a 74 hierachical construction are documented: 76 Extended Home Network: In this disposition, the Home Network is but 77 one subnet of a larger aggregation that encompasses the Mobile 78 Networks, called extended Home Network. When at Home, a Mobile 79 Router performs normal routing between the Home Link and the 80 Mobile Networks. 82 Aggregated Home Network: In this disposition, the Home Network 83 actually overlaps with the Mobile Networks. When at Home, a Mobile 84 Router acts as a bridge between the Home Link and the Mobile 85 Networks. 87 Virtual Home Network: In this disposition, there is no physical Home 88 Link at all for the Mobile Routers to come back Home to. 90 Mobile Home Network: In this disposition, there is a bitwise 91 hierarchy of Home Networks. A global Home Network is advertised to 92 the infrastructure by a head Home Agent and further subnetted into 93 Mobile Networks. Each subnet is owned by a Mobile Router that 94 registers it in a Nemo fashion while acting as a Home Agent for 95 that network. 97 In all cases, the Home Agents collectively advertise only the 98 aggregation of the Mobile Networks. The dichotomy is kept within the 99 Home Agents and the Mobile Routers, as opposed to advertised by means 100 of routing protocols to other parties. 102 Also, it is valid for a Mobile Router to register using an address 103 from one of its own Mobile Network Prefixes in all three cases. 105 The examples provided here aim at illustrating the Nemo Basic Support 106 draft [7] but are by no mean at limiting its scope of application. 108 2. Terminology and concepts 110 The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 111 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this document are to be 112 interpreted as described in RFC2119 [5]. 114 The following terms used in this document are defined in the IPv6 115 Addressing Architecture document [4]: 117 link-local unicast address 119 link-local scope multicast address 121 The following terms used in this document are defined in the mobile 122 IPv6 specification [6]: 124 home agent (HA) 126 The following terms used in this document are defined in the mobile 127 network terminology document [9]: 129 mobile router (MR) 131 mobile network 133 mobile host (MH) 135 This draft uses the following additional or modified terminology: 137 Home Link: The link attached to the interface at the Home Agent on 138 which the Home Prefix is configured. The interface can be a 139 virtual interface, in which case the Home Link is a virtual Home 140 Link. 142 Home Network: The Network formed by the application of the Home 143 Prefix on the Home Link. With Nemo, the concept of Home Network is 144 extended as explained below. 146 Home Address: With Mobile IPv6, a Home Address is derived from the 147 Home Network prefix. This is generalized in Nemo, with some 148 limitations: A Home Address can be either derived from the Home 149 Network or from one of the Mobile Router's Mobile Network 150 prefixes. 152 MRHA Tunnel: The bi-directional tunnel between a Mobile Router and 153 its Home Agent 155 Mobile Aggregated Prefix: An aggregation of Mobile Network Prefixes. 157 Aggregated Home Network: The Home Network associated with a Mobile 158 Aggregated Prefix. This Aggregation is advertised as a subnet on 159 the Home Link, and thus used as Home Network for Nemo purposes. 161 Extended Home Network: The network associated with the aggregation of 162 one or more Home Network(s) and Mobile Network(s). As opposed to 163 the Mobile IPv6 Home Network that is a subnet, the extended Home 164 Network is an aggregation and is further subnetted. 166 Virtual Home Network: The Home Network associated with a Virtual 167 Network. The Extended Home Network and the Aggregated Home Network 168 can be configured as Virtual Home Network. 170 Mobile Home Network: A Mobile Network that is also a Home Network. 171 The MR that own the Mobile Network Prefix acts as a Home Agent for 172 it. 174 3. General Expectations 176 With Mobile IPv6, the Home Network is generally a physical network 177 interconnecting the Home Agents, and the Mobile Nodes that are at 178 Home. Nemo extends the concept of Home so that it is not only a flat 179 subnet composed of Home Addresses but an aggregation that is itself 180 subnetted in mobile and Home Networks. This aggregation is still 181 referred to as Home. 183 As an example, say that the aggregation has a global routing prefix 184 of m = 48 bits (A:B:C::/48), with subnet ID size of n = 16 bits ( n + 185 m = 64). 187 Say that a Mobile Router, MR1, owns the Mobile Network Prefix 188 A:B:C:1::/64: With basic Nemo, and depending on the deployment, MR1 189 may register using a Home Address from the Home network, A:B:C:0::1, 190 say, or a Home Address, A:B:C:1::1, say, from one of its Mobile 191 Network Prefixes. 193 In a given deployment, one subnet may be reserved for the Home Link 194 (say A:B:C:0::/64) while the others are attributed to Mobile Routers 195 as Mobile Networks (as A:B:C:1::/64 for MR1). Another approach could 196 be to configure the Aggregation of Mobile Networks as the subnet on 197 the Home Link, and let the Mobile Routers manage the overlapping 198 networks. Finally, the aggregation could be configured on a virtual 199 network, with no physical Home Link at all, in which case Home means 200 topologically and administratively close to the Home Agent that owns 201 the virtual network. 203 The following sections provide additional information on these forms 204 of Home Network: 206 4. Extended Home Network 208 One simple approach can be to reserve one or several subnets from an 209 aggregation for the Home Link, and to use the other subnets as Mobile 210 Network Prefixes. In that case, the Home Network and the Mobile 211 Networks do not overlap. The aggregation is called an extended Home 212 Network. 214 | 215 route v /48 A:B:C::/48 217 HA 218 | /64 A:B:C:0::/64 219 --+-----+--+- . -+- . -+-- 220 | | | | 221 MR1 MR2 MRi MRN 222 /64 /64 /64 /64 A:B:C:i::/64 0 < i <= N 224 extended Home Network 225 <-----------------------------------------------------------> 227 Home Net Mobile Net Mobile Net ... Mobile Net 228 <------------><------------><------------> ... <------------> 230 In that configuration: 232 o There is one physical Home Network and multiple Mobile Networks 234 o The Home and the Mobile Network prefixes are tailored to allow for 235 IPv6 Stateless Address Autoconfiguration with typical interface 236 identifier length for the type of interface (can be for example / 237 64). 239 o The prefix length of the extended Home Network is shorter than 240 that of the Home Network and the Mobile Network prefixes, since it 241 is an aggregation (can be for example /48). 243 o The Mobile Routers are assigned individually a Home Address from 244 the Home Network and use is to register their Mobile Network 245 Prefix(es). In that case, the Home Agent performs DAD in the Home 246 Network as prescribed by Mobile IPv6 for the Home Addresses. 248 o Alternatively, a Mobile Router could also form a Home Address from 249 one of its prefixes and use it to register, performing its own DAD 250 on its ingress network. 252 4.1 Returning Home 254 In the extended Home Network model, the Home Network is configured on 255 a physical interface of the Home Agent, the Home Link. 257 A Mobile Router returns Home by connecting directly to the Home Link, 258 and dropping the MRHA tunnel. 260 If the Home Address of the Mobile Router is derived from one of its 261 Mobile Networks, then the MR may connect to the Home Link using an 262 egress interface and autoconfigure an address on the Home Link. The 263 MR recognizes the prefix of its Home Agent in order to decide that it 264 is Home. Note that in that case the Home Address does not match the 265 Home Prefix. 267 When at Home, the Mobile Router ensures the connectivity of the 268 Mobile Network using standard router operations. 270 In particular, if the HA has the necessary information to continue 271 routing to the Mobile Network Prefixes in the absence of 272 registration, for instance if the Home Address of the Mobile Router 273 is derived from the Home Network, and if the HA uses a static route 274 to the Mobile Network Prefix(es) via that address, then the 275 participation of the MR to the Home IGP is not required. 277 But in the general case, when the MR is at Home, it resumes IGP 278 operations on the Home Link in order to advertise its Mobile 279 Networks. 281 Alternate procedures for ensuring the connectivity of the Mobile 282 Networks when at Home are described in Section 6. In Particular, it 283 is 285 5. Aggregated Home 287 One other approach is to consider that the Aggregation of all the 288 mobile network prefixes is used plainly as the Home Network, refered 289 to as the Aggregated Home Network. This means that the Mobile 290 Aggregated Prefix is configured on the Home Link and advertised by 291 the Home Agent as a subnet. 293 HA 294 | /56 Aggreg /56 295 --+-----+--+- . -+- . -+-- 296 | | | | 297 MR1 MR2 MRi MRN 298 ------ ------ ------ ------ 299 /64 /64 /64 /64 Aggreg|i /64 0 < i <= N 301 Aggregated Home 302 <-----------------------------------------------------------> 304 Mobile Net Mobile Net Mobile Net ... Mobile Net 305 <------------><------------><------------> ... <------------> 307 Note: a Mobile Router coming Home sees overlapping prefixes between 308 the ingress and the egress interface and some specific support may be 309 needed. 311 A node on the Home Link will compute that the Aggregated Home Network 312 is actually a subnet on the Home Link and may use it for 313 autoconfiguration purposes. Such a node may also install a connected 314 route to the Aggregated Home Network over the Home Link. 316 As a result, unless the node has a better (longest match) route to a 317 given Mobile Network Prefix, it will lookup all MNNs using Neighbor 318 Discovery over the Home Link. 320 Thus, the Home Agent MUST intercept all the packets to the MNNs on 321 the registered prefixes. In order to do so, the Home Agent MAY 322 perform ND proxying for all addresses in all registered Mobile 323 Network Prefixes, and protect the Mobile Network Prefix space from 324 autoconfiguration by uncontrolled visitors on the Home Link. 326 Alternatives based on a routing protocol or ICMP redirect may apply 327 in some cases. 329 5.1 Returning Home 331 The Aggregated Home Prefix is configured on a physical interface of 332 the Home Agent, the Home Link. As a consequence, the Home Agent has a 333 connected route to the Aggregated Home Network over the Home Link. 335 A Mobile Router returns Home by connecting directly to the Home Link, 336 and dropping the MRHA tunnel. The Mobile Router recognizes its Home 337 Link by a prefix match with its Home Agent. Note that it must expect 338 a shorter prefix than that of its Mobile Networks, even if its Home 339 Address is formed out of one of its Mobile Network Prefixes, but that 340 the Home Address matches the Home Network Prefix. 342 When a Mobile Router connects to the Home Link using its egress 343 interface, it MAY set up a bridge between its ingress interface(s) 344 and the Home Link. Alternatively, the Mobile Router MAY perform ND 345 proxying for all addresses in its Mobile Network Prefixes, between 346 the egress and the related ingress interface. Since the prefixes on 347 the egress and ingress interfaces are overlapping, routing is 348 disallowed. 350 HA 351 | /56 Aggreg /56 352 --+-----+--+- . -+- . -+-- 353 | | | | 354 MR1 MR2 MRi MRN 355 ------ ------ ------ ------ 356 /64 /64 /64 /64 Aggreg|i /64 0 < i <= N 358 Bridging between egress and ingress 360 Alternatively, if the MR has a single ingress Interface, the Mobile 361 Router may use the Mobile Link to connect to the Home Link, merging 362 the two links in a single consistent network. 364 HA 365 | /56 Aggreg /56 366 --+-----+--+- . -+- . -+-- 367 /64 /64 /64 /64 Aggreg|i /64 0 < i <= N 368 ------ ------ ------ ------ 369 MR1 MR2 MRi MRN 370 | | | | 372 Merging the Home and the Mobile Networks 374 This fits the connected route model, since the Aggregated Home is 375 truly located on that network. 377 6. Virtual Home Network 379 The Home Link can be configured on the Home Agent on a virtual link, 380 in which case there's no physical Home Link for Mobile Routers to 381 return Home or for Home Agents to discover each others and perform 382 the ND level interactions as described in Mobile IPv6. [6] 384 /48 eg: A:B:C::/48 385 HA 386 | /64 A:C:C:E::/64 387 --+-----+--+- . -+- . -+-- 388 | | | | 389 MR1 MR2 MRi MRN 390 /64 /64 /64 /64 A:B:C:i::/64 0 < i <= N 392 Virtual Home Network 394 The Extended Home network and the Aggregated Home network models can 395 be adapted for virtual links. There is no change in the way Home 396 Addresses are allocated. As in the case of a physical link, the Home 397 Address of a Mobile router is constructed based on the Home Prefix or 398 one of the prefixes of its Mobile Network(s). 400 There are certain advantages to making the Home Link a virtual link: 402 A virtual link may not experience any disruption related to 403 physical maintenance or to hardware problems, so it is more 404 available than a physical link. The high availability of the Home 405 Link is critical for the mobility service. 407 The Home Agent does not have to defend the Mobile Router's Home 408 Address through Proxy Neighbor Discovery. The Home Agent does not 409 also have to perform Duplicate Address Detection (DAD) for the 410 Mobile Router's Home Address when it receives a Binding Update 411 from the Mobile Router. 413 The Mobile Router does not have to implement the Returning Home 414 procedure (section 11.5.4 of Mobile IPv6. [6]). 416 In order for a Mobile Router to emulate returning Home, it can 417 connect to one or more access link(s) configured for that purpose on 418 the Home Agent. The Mobile Router, after connecting to the access 419 link, SHOULD not send any routing protocol updates on the egress 420 interface because the routing information from the Mobile Router 421 might adversely affect IPv6 route aggregation on the Home Network. 422 However, the Mobile Router must register its binding as if it was 423 accessing a foreign link. 425 There are also some drawbacks to the virtual Home Link approach: 427 There can be only one Home Agent since Mobile IPv6 relies on 428 Neighbor Discovery on the Home Link for other HA discovery and for 429 Duplicate Address Detection. 431 The Home Agent must maintain a Binding Cache entry for a Mobile 432 Router and forwarding state for its Mobile Network even when the 433 Mobile Router is directly connected to it. All traffic to and from 434 the Mobile Network is sent through the bi-directional tunnel 435 regardless of the Mobile Router location. This results in a 436 tunneling overhead even though the Mobile Router is connected to 437 the Home Network. 439 Some solutions can be proposed in order to perform an equivalent of 440 returning Home on a virtual Home Network. One such approach is 441 sketched in appendix as an illustration. 443 7. Mobile Home 445 In this disposition, there is a bitwise hierarchy of Home Networks. A 446 global Home Network is advertised to the infrastructure by a head 447 Home Agent(s) and further subnetted into Mobile Networks. As a 448 result, only the Home Agent(s) responsible for the most global 449 (shortest prefix) aggregation receive all the packets for all the 450 Mobile Network prefixes, which are leaves in the hierarchy tree. 452 Each subnet is owned by a Mobile Router that registers it in a Nemo 453 fashion while acting as a Home Agent for that network. This Mobile 454 Router is at Home at the upper level of hierarchy. This configuration 455 is referred to as Mobile Home. 457 An example of that is the Cab Co configuration. Say a Taxi Company 458 owns a /32 prefix. This prefix is advertised at a fixed point, the 459 Headquarters say. Regional offices are deployed around the world. 460 Even though these regional offices are relatively stable in terms of 461 location and prefix requirement -say this changes every few years- 462 making them mobile allows a simpler management when a move has to 463 take place, or should the ISP service change. Finally, each regional 464 office owns a number of taxis, each one equipped with a mobile router 465 and an associated /64 prefix. 467 To illustrate this, here is a possible addressing scheme: 469 global Home Network CAB:C0::/32 owned by HQ 470 <-------------------------------------------------------------------> 472 HQ extended Home Net Mobile Home for SFO office 473 (casa) 474 CAB:C0:CA5A::/48 CAB:C0:5F0::/48 475 <----------------------------> ... <--------------------------------> 476 | 477 Home for offices HQ | 478 CAB:C0:CA5A:CA5A::/64 MN | 479 <----------------------><----> | 480 CAB:C0:CA5A:CA5A::CA5A | 481 CAB:C0:CA5A:CA5A::CA5B | 482 are HAs on link with for each office a route like | 483 | 484 CAB:C0:CA5A:CA5A::5F0 <---------------------- via 485 is the Home addr 486 of SFO office 488 and recursively for each Office, say San Francisco (SFO) as example: 490 Mobile Home Network CAB:C0:5f0::/48 owned by SFO office 491 <------------------------------------------------------------------> 493 HQ Home Network Mobile Networks for taxis 494 for offices 495 CAB:C0:5F0:5F0::/64 CAB:C0:5F0:CAB1::/64 CAB:C0:5F0:....::/6 496 <-------------------><-------------------> ... <-------------------> 497 CAB:C0:5F0:5F0::5F0 | 498 is HA on link with for | 499 each taxi a route like | 500 | 501 CAB:C0:5F0:5F0::CAB1 <------ via 502 is the Home addrSsync 503 of CAB 1 505 Note that the hierarchy occurs at a configuration level and may not 506 be reflected in the actual connection between nodes. For instance in 507 the Cab Co case, cabs are roaming within the city, each one attaching 508 to a different hot spot, while the regional office is connected to 509 the infrastructure using some ISP connection. 511 But it is also possible to reflect the organizational hierarchy in a 512 moving cloud of Mobile Router. If a Mobile Home Agent acts as root-MR 513 for a nested configuration of its own MRs, then the communication 514 between MRs is confined within the nested structure. 516 This can be illustrated in the case of a fleet at sea. Say that now 517 SFO is a communication ship of a fleet, using a satellite link to 518 join the infrastructure, and that the cabs are Mobile Routers 519 installed on smaller ships, equipped with low range radios. 521 If SFO is also the root-MR of a nested structure of cabs, the 522 communication between cabs is relayed by SFO and does not require the 523 satellite link. SFO recursively terminates the nested tunnels to the 524 cabs and reencapsulates all the packets between the nested cloud and 525 correspondents in the infrastructure in a single tunnel to CA5A, this 526 providing for nested Nemo Route Optimization. 528 8. Changes from version 00 to 01 530 Added Mobile Home Section 532 9. Acknowledgements 534 The authors wish to thank: 536 Erik Nordmark, Kent Leung, Thierry Ernst, TJ Kniveton, Patrick 537 Wetterwald and Alexandru Petrescu for their contributions. 539 References 541 [1] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) 542 Specification", RFC 2460, December 1998. 544 [2] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery 545 for IP Version 6 (IPv6)", RFC 2461, December 1998. 547 [3] Thomson, S. and T. Narten, "IPv6 Stateless Address 548 Autoconfiguration", RFC 2462, December 1998. 550 [4] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) 551 Addressing Architecture", RFC 3513, April 2003. 553 [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement 554 Levels", BCP 14, RFC 2119, March 1997. 556 [6] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in 557 IPv6", draft-ietf-mobileip-ipv6-24 (work in progress), July 558 2003. 560 [7] Devarapalli, V., "Nemo Basic Support Protocol", 561 draft-ietf-nemo-basic-support-02 (work in progress), December 562 2003. 564 [8] Ernst, T., "Network Mobility Support Goals and Requirements", 565 draft-ietf-nemo-requirements-01 (work in progress), May 2003. 567 [9] Ernst, T. and H. Lach, "Network Mobility Support Terminology", 568 draft-ietf-nemo-terminology-00 (work in progress), May 2003. 570 [10] Wakikawa, R., Devarapalli, V. and P. Thubert, "Inter Home 571 Agents Protocol (HAHA)", draft-wakikawa-mip6-nemo-haha-00 (work 572 in progress), October 2003. 574 Authors' Addresses 576 Pascal Thubert 577 Cisco Systems Technology Center 578 Village d'Entreprises Green Side 579 400, Avenue Roumanille 580 Biot - Sophia Antipolis 06410 581 FRANCE 583 EMail: pthubert@cisco.com 585 Ryuji Wakikawa 586 Keio University and WIDE 587 5322 Endo Fujisawa Kanagawa 588 252-8520 589 JAPAN 591 EMail: ryuji@sfc.wide.ad.jp 593 Vijay Devarapalli 594 Nokia Research Center 595 313 Fairchild Drive 596 Mountain View, CA 94043 597 USA 599 EMail: vijay.devarapalli@nokia.com 601 Appendix A. Returning Home emulation in the virtual case 603 When a Home Link is virtual, all traffic to and from the Mobile 604 Network is sent through the bi-directional tunnel even at the Home 605 Link. This section describes one possible mechanism that extends 606 basic Nemo to eliminate this tunneling overhead. 608 Although the Home Link is virtual, the Home Agent has at least one 609 physical link to communicate with the external world. One or several 610 of such links, called the virtual Home Access Links, are conceptually 611 associated with the virtual Home Link and considered as part of Home. 613 When accessing one of its virtual Home Access Links, a Mobile Router 614 autoconfigures a Care-of Address from a Router Advertisement as it 615 would do on any visited link, in order to perform the next binding 616 flow. 618 If the Mobile Router is configured to recognize the virtual Home 619 Access Links as part of Home, it deregisters by sending a Binding 620 update with null lifetime sourced at the CareOf. Alternatively, the 621 Home Agent may indicate that the MR has moved to the virtual Home 622 Access Links as a status code in the binding acknowledgement. The 623 status code implies that Home Agent successsful de-register the 624 binding at the virtual Home Access Link. Detection of the virtual 625 Home Access Links is achieved by a prefix comparison(s) between the 626 care-of address and the prefix(es) on the virtual Home Access 627 Link(s). 629 With both approaches, the result of the binding flow is a 630 deregistration. Consequently, both the Mobile Router and the Home 631 Agent disable the bi-directional tunnel. At that point, the Home 632 Agent configures its forwarding in order to reach the Mobile Router 633 and its mobile networks at Home. For instance, this may take the form 634 of a route to the Mobile Network prefixes via the MR Home Address, 635 and a connected host route to the MR Home Address via the virtual 636 Home Access link. 638 After successful binding de-registration, the Mobile Router MUST 639 receive packets meant to the Mobile Router's Home Address at the 640 Virtual Home Link. How to intercept packets addressed to the Home 641 Address depends on implementations of the Mobile Router. If the Home 642 Address is not configured at the egress interface, the Mobile Router 643 MUST use proxy Neighbor Discovery to intercept all packets addressed 644 to the Home Address on the virtual Home Link. Otherwise, the Mobile 645 Router does not have to perform any special operation at the virtual 646 Home Link. 648 Intellectual Property Statement 650 The IETF takes no position regarding the validity or scope of any 651 intellectual property or other rights that might be claimed to 652 pertain to the implementation or use of the technology described in 653 this document or the extent to which any license under such rights 654 might or might not be available; neither does it represent that it 655 has made any effort to identify any such rights. Information on the 656 IETF's procedures with respect to rights in standards-track and 657 standards-related documentation can be found in BCP-11. Copies of 658 claims of rights made available for publication and any assurances of 659 licenses to be made available, or the result of an attempt made to 660 obtain a general license or permission for the use of such 661 proprietary rights by implementors or users of this specification can 662 be obtained from the IETF Secretariat. 664 The IETF invites any interested party to bring to its attention any 665 copyrights, patents or patent applications, or other proprietary 666 rights which may cover technology that may be required to practice 667 this standard. Please address the information to the IETF Executive 668 Director. 670 Full Copyright Statement 672 Copyright (C) The Internet Society (2004). All Rights Reserved. 674 This document and translations of it may be copied and furnished to 675 others, and derivative works that comment on or otherwise explain it 676 or assist in its implementation may be prepared, copied, published 677 and distributed, in whole or in part, without restriction of any 678 kind, provided that the above copyright notice and this paragraph are 679 included on all such copies and derivative works. However, this 680 document itself may not be modified in any way, such as by removing 681 the copyright notice or references to the Internet Society or other 682 Internet organizations, except as needed for the purpose of 683 developing Internet standards in which case the procedures for 684 copyrights defined in the Internet Standards process must be 685 followed, or as required to translate it into languages other than 686 English. 688 The limited permissions granted above are perpetual and will not be 689 revoked by the Internet Society or its successors or assignees. 691 This document and the information contained herein is provided on an 692 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 693 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 694 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 695 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 696 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 698 Acknowledgment 700 Funding for the RFC Editor function is currently provided by the 701 Internet Society.