idnits 2.17.1 draft-ietf-nemo-home-network-models-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 3667, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 775. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 752. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 759. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 765. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 781), 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: ---------------------------------------------------------------------------- == 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 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 ([8]), 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 == Line 406 has weird spacing: '...ace and an ad...' == 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 (October 5, 2004) is 7141 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: '2' is defined on line 629, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 632, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 635, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 651, 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. '5') (Obsoleted by RFC 4291) ** Downref: Normative reference to an Informational RFC: RFC 3753 (ref. '6') ** Obsolete normative reference: RFC 3775 (ref. '7') (Obsoleted by RFC 6275) == Outdated reference: A later version (-06) exists of draft-ietf-nemo-requirements-02 ** Downref: Normative reference to an Informational draft: draft-ietf-nemo-requirements (ref. '9') == Outdated reference: A later version (-06) exists of draft-ietf-nemo-terminology-01 ** Downref: Normative reference to an Informational draft: draft-ietf-nemo-terminology (ref. '10') -- Possible downref: Normative reference to a draft: ref. '11' == Outdated reference: A later version (-07) exists of draft-ietf-nemo-multihoming-issues-00 ** Downref: Normative reference to an Informational draft: draft-ietf-nemo-multihoming-issues (ref. '12') Summary: 20 errors (**), 0 flaws (~~), 13 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 NEMO Home Network models 11 draft-ietf-nemo-home-network-models-01 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 documents some usage patterns and the associated issues 45 when deploying a Home Network for NEMO-enabled Mobile Routers, 46 conforming the NEMO Basic Support draft [8]. The aim here is 47 specifically to provide some examples of organization of the Home 48 Network, as they were discussed in NEMO related mailing lists. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Terminology and concepts . . . . . . . . . . . . . . . . . . . 4 54 3. General Expectations . . . . . . . . . . . . . . . . . . . . . 5 55 4. Extended Home Network . . . . . . . . . . . . . . . . . . . . 6 56 4.1 Configuration . . . . . . . . . . . . . . . . . . . . . . 6 57 4.2 Returning Home . . . . . . . . . . . . . . . . . . . . . . 7 58 4.3 Applicability . . . . . . . . . . . . . . . . . . . . . . 7 59 5. Aggregated Home . . . . . . . . . . . . . . . . . . . . . . . 8 60 5.1 Configuration . . . . . . . . . . . . . . . . . . . . . . 8 61 5.2 Returning Home . . . . . . . . . . . . . . . . . . . . . . 9 62 5.2.1 Returning Home by egress . . . . . . . . . . . . . . . 9 63 5.2.2 Returning Home by ingress . . . . . . . . . . . . . . 10 64 5.3 Applicability . . . . . . . . . . . . . . . . . . . . . . 10 65 6. Virtual Home Network . . . . . . . . . . . . . . . . . . . . . 11 66 6.1 Configuration . . . . . . . . . . . . . . . . . . . . . . 11 67 6.2 Applicability . . . . . . . . . . . . . . . . . . . . . . 12 68 7. Mobile Home . . . . . . . . . . . . . . . . . . . . . . . . . 13 69 7.1 Configuration . . . . . . . . . . . . . . . . . . . . . . 13 70 7.2 Applicability . . . . . . . . . . . . . . . . . . . . . . 14 71 8. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 72 8.1 Changes from version 00 to 01 . . . . . . . . . . . . . . 16 73 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 74 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 18 76 A. Returning Home emulation in the virtual case . . . . . . . . . 19 77 Intellectual Property and Copyright Statements . . . . . . . . 20 79 1. Introduction 81 This document assumes that the reader is familiar with IPv6 Mobility 82 as defined in [7], with the NEMO Basic Support [8] and with the NEMO 83 terminology document [10]. 85 In order to read this document properly, the distinction between the 86 concepts of Home Link and of Home Network must be very clear. A Home 87 Link is a physical or a virtual Link, attached to a Home Agent. A 88 Home Network is an aggregation that can be further subnetted. As a 89 result, the Home Network is not necessarily contained on a Home Link. 90 In fact, the Mobile Network Prefixes are subnets of the Home Network. 91 How the two concepts relate in a given deployment depend on the 92 organization of the Home Network, as described below. 94 Four different organizations of the Home Network including a 95 hierarchical construction are documented: 97 Extended Home Network: In this disposition, the Home Network is only 98 one subnet of a larger aggregation that encompasses the Mobile 99 Networks, called extended Home Network. When at Home, a Mobile 100 Router performs normal routing between the Home Link and the 101 Mobile Networks. More in Section 4. 103 Aggregated Home Network: In this disposition, the Home Network 104 actually overlaps with the Mobile Networks. When at Home, a 105 Mobile Router acts as a bridge between the Home Link and the 106 Mobile Networks. More in Section 5. 108 Virtual Home Network: In this disposition, there is no physical Home 109 Link at all for the Mobile Routers to come back Home to. More in 110 Section 6. 112 Mobile Home Network: In this disposition, there is a bitwise 113 hierarchy of Home Networks. A global Home Network is advertised 114 to the infrastructure by a head Home Agent and further subnetted 115 into Mobile Networks. Each subnet is owned by a Mobile Router 116 that registers it in a NEMO fashion while acting as a Home Agent 117 for that network. More in Section 7. 119 In all cases, the Home Agents collectively advertise only the 120 aggregation of the Mobile Networks. The dichotomy is kept within the 121 Home Agents and the Mobile Routers, as opposed to advertised by means 122 of routing protocols to other parties. 124 The examples provided here aim at illustrating the NEMO Basic Support 125 draft [8] but do not aim at limiting its scope of application, and 126 additional cases may be added in the future. 128 2. Terminology and concepts 130 The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 131 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this document are to be 132 interpreted as described in RFC2119 [1]. 134 The following terms used in this document are defined in the IPv6 135 Addressing Architecture document [5]: 137 link-local unicast address 139 link-local scope multicast address 141 Most of the mobility related terms used in this document are defined 142 in the Mobility Related Terminology document [6] and in the Mobile 143 IPv6 (MIP6) specification [7]. 145 Additionally, some terms were created or extended for NEMO. These 146 specific terms are defined in the Mobile Network Terminology document 147 [10]: 149 Home Link 151 Home Network 153 Home Address 155 MRHA Tunnel 157 Mobile Aggregated Prefix 159 Aggregated Home Network 161 Extended Home Network 163 Virtual Home Network 165 Mobile Home Network 167 3. General Expectations 169 With Mobile IPv6, the Home Network is generally a physical network 170 interconnecting the Home Agents, and the Mobile Nodes that are at 171 Home. NEMO extends the concept of Home so that it is not only a flat 172 subnet composed of Home Addresses but an aggregation that is itself 173 subnetted in mobile and Home Networks. This aggregation is still 174 referred to as Home. 176 As an example, say that the aggregation has a global routing prefix 177 of m = 48 bits (A:B:C::/48), with subnet ID size of n = 16 bits ( n + 178 m = 64). 180 Say that a Mobile Router, MR1, owns the MNP A:B:C:1::/64: With NEMO 181 Basic Support, and depending on the deployment, MR1 may register 182 using a Home Address from the Home network, A:B:C:0::1, say, or a 183 Home Address, A:B:C:1::1, say, from one of its MNPs. 185 In a given deployment, one subnet may be reserved for the Home Link 186 (say A:B:C:0::/64) while the others are attributed to Mobile Routers 187 as Mobile Networks (as A:B:C:1::/64 for MR1). Another approach could 188 be to configure the Aggregation of Mobile Networks as the subnet on 189 the Home Link, and let the Mobile Routers manage the overlapping 190 networks. Finally, the aggregation could be configured on a virtual 191 network, with no physical Home Link at all, in which case Home means 192 topologically and administratively close to the Home Agent that owns 193 the virtual network. 195 The following sections provide additional information on these forms 196 of Home Network. 198 4. Extended Home Network 200 4.1 Configuration 202 One simple approach is to reserve one or several subnets from an 203 aggregation for the Home Link, and to use the other subnets as MNPs. 204 In that case, the Home Network and the Mobile Networks do not 205 overlap. The aggregation is called an Extended Home Network and 206 depicted in Figure 1. 208 | 209 route v /48 A:B:C::/48 211 HA 212 | /64 A:B:C:0::/64 213 --+-----+--+- . -+- . -+-- 214 | | | | 215 MR1 MR2 MRi MRN 216 /64 /64 /64 /64 A:B:C:i::/64 0 < i <= N 218 Extended Home Network 219 <-----------------------------------------------------------> 221 Home Net Mobile Net Mobile Net ... Mobile Net 222 <------------><------------><------------> ... <------------> 224 Figure 1: Extended Home Network 226 In that configuration: 228 o There is one physical Home Network and multiple Mobile Networks 230 o The Home and the MNPs are tailored to allow for IPv6 Stateless 231 Address Autoconfiguration with typical interface identifier length 232 for the type of interface (can be for example /64). 234 o The prefix length of the Extended Home Network is shorter than 235 that of the Home Network and the MNPs, since it is an aggregation 236 (can be for example /48). 238 o The Mobile Routers are assigned individually a Home Address from 239 the Home Network and use is to register their MNP(es). In that 240 case, the Home Agent performs DAD in the Home Network as 241 prescribed by Mobile IPv6 for the Home Addresses. 243 o Alternatively, a Mobile Router could also form a Home Address from 244 one of its prefixes and use it to register, performing its own DAD 245 on its ingress network. 247 4.2 Returning Home 249 In the Extended Home Network model, the Home Network is configured on 250 a physical interface of the Home Agent, the Home Link. 252 A Mobile Router returns Home by connecting directly to the Home Link, 253 and dropping the MRHA tunnel. 255 If the Home Address of the Mobile Router is derived from one of its 256 Mobile Network Prefixes, then the MR may connect to the Home Link 257 using an egress interface and autoconfigure an address on the Home 258 Link. The MR recognizes the prefix of its Home Agent in order to 259 decide that it is Home. Note that in that case the Home Address does 260 not match the Home Prefix. 262 When at home, the Mobile Router ensures the connectivity of the 263 Mobile Network using standard router operations. 265 In particular, if the HA has the necessary information to continue 266 routing to the MNPs in the absence of registration, for instance if 267 the Home Address of the Mobile Router is derived from the Home 268 Network, and if the HA uses a static route to the MNP(es) via that 269 address, then the participation of the MR to the Home IGP is not 270 required. 272 But in the general case, when the MR is at Home, it resumes IGP 273 operations on the Home Link in order to advertise its Mobile 274 Networks. 276 Alternate procedures for ensuring the connectivity of the Mobile 277 Networks when at home are described in Section 6. 279 4.3 Applicability 281 The extended Home Network keeps the MIP6 concept of a Home Network 282 for both Mobile Nodes and Mobile Routers to take their Home Address 283 from. Since there is no overlap between the prefixes that are 284 affected to MNPs and prefix(es) that are dedicated to the Home Link, 285 it is possible for MNs and MRs to coexist with that model. 287 5. Aggregated Home 289 5.1 Configuration 291 One other approach is to consider that the Aggregation of all the 292 MNPs is used plainly as the Home Network, referred to as the 293 Aggregated Home Network. This means that the Mobile Aggregated 294 Prefix is configured on the Home Link and advertised by the Home 295 Agent as a subnet, as depicted in Figure 2. 297 HA 298 | /56 Aggreg /56 299 --+-----+--+- . -+- . -+-- 300 | | | | 301 MR1 MR2 MRi MRN 302 ------ ------ ------ ------ 303 /64 /64 /64 /64 Aggreg|i /64 0 < i <= N 305 Aggregated Home 306 == Home Net 307 <-----------------------------------------------------------> 309 Mobile Net Mobile Net Mobile Net ... Mobile Net 310 <------------><------------><------------> ... <------------> 312 Figure 2: Aggregated Home 314 A node on the Home Link computes that the Aggregated Home Network is 315 actually a subnet on the Home Link and may use it for 316 autoconfiguration purposes. Such a node may also install a connected 317 route to the Aggregated Home Network over the Home Link. 319 As a result, unless the node has a better (longest match) route to a 320 given MNP, it will lookup all MNNs using Neighbor Discovery over the 321 Home Link. 323 Thus, the Home Agent MUST intercept all the packets to the MNNs on 324 the registered prefixes. In order to do so, the Home Agent might 325 perform ND proxying for all addresses in all registered Mobile 326 Network Prefixes, and protect the MNP space from autoconfiguration by 327 uncontrolled visitors on the Home Link. 329 Alternatives based on a routing protocol or ICMP redirect may apply 330 in some cases. 332 5.2 Returning Home 334 The Aggregated Home Prefix is configured on a physical interface of 335 the Home Agent, the Home Link. As a consequence, the Home Agent has 336 a connected route to the Aggregated Home Network over the Home Link. 338 A Mobile Router returns Home by connecting directly to the Home Link, 339 and dropping the MRHA tunnel. The Mobile Router recognizes its Home 340 Link by a prefix match with its Home Agent. 342 Note that it must expect a shorter prefix than that of its Mobile 343 Networks, even if its Home Address is formed out of one of its MNPs, 344 but that the Home Address matches the Home Network Prefix. 346 Also, Note that in that case, it makes sense for a Mobile Router to 347 register using a Home Address from one of its own MNPs. Taking the 348 Home Address from its own range guarantees the unicity of the suffix. 349 That unicity can be checked by the MR on its ingress network using 350 DAD. 352 5.2.1 Returning Home by egress 354 A Mobile Router coming Home via its egress interface sees overlapping 355 prefixes between the ingress and the egress interface and some 356 specific support may be needed: 358 When a Mobile Router connects to the Home Link using its egress 359 interface, it might set up a bridge between its ingress interface(s) 360 and the Home Link. 362 Alternatively, the Mobile Router might perform ND proxying for all 363 addresses in its MNPs, between the egress and the related ingress 364 interface. Since the prefixes on the egress and ingress interfaces 365 are overlapping, routing is disallowed. 367 HA 368 | /56 Aggreg /56 369 --+-----+--+- . -+- . -+-- 370 | | | | 371 MR1 MR2 MRi MRN 372 ------ ------ ------ ------ 373 /64 /64 /64 /64 Aggreg|i /64 0 < i <= N 375 Figure 3: Bridging between egress and ingress 377 5.2.2 Returning Home by ingress 379 Alternatively, if the MR has a single ingress Interface, the Mobile 380 Router may use the NEMO-Link to connect to the Home Link, merging the 381 two links in a single consistent network. 383 HA 384 | /56 Aggreg /56 385 --+-----+--+- . -+- . -+-- 386 /64 /64 /64 /64 Aggreg|i /64 0 < i <= N 387 ------ ------ ------ ------ 388 MR1 MR2 MRi MRN 389 | | | | 391 Figure 4: Merging the Home and the Mobile Networks 393 This fits the connected route model, since the Aggregated Home is 394 truly located on that network. Note that in that case, it makes 395 sense for a Mobile Router to register using a Home Address from one 396 of its own MNPs. . 398 5.3 Applicability 400 With this model, there is no specific space for independent nodes as 401 any address in the aggregation belongs to a MNP, and thus to a Mobile 402 Router. This configuration excludes the cohabitation with MIP6 MNs 403 on the Home Link. 405 A MR that is at Home must own an address from the aggregation on its 406 egress interface and an address from its MNP -a subnet of that 407 aggregation- on its ingress interface. A pure router will reject 408 that configuration, and the MR needs to act as a bridge to enable it. 409 In order to deploy the aggregated Home Network model, one must check 410 whether that support is available in the MRs if returning Home is 411 required. 413 6. Virtual Home Network 415 6.1 Configuration 417 The Home Link can be configured on the Home Agent on a virtual link, 418 in which case there's no physical Home Link for Mobile Routers to 419 return Home or for Home Agents to discover each others and perform 420 the ND level interactions as described in Mobile IPv6. [7] 422 /48 eg: A:B:C::/48 423 HA 424 | /64 A:C:C:E::/64 425 --+-----+--+- . -+- . -+-- 426 | | | | 427 MR1 MR2 MRi MRN 428 /64 /64 /64 /64 A:B:C:i::/64 0 < i <= N 430 Figure 5: Virtual Home Network 432 The Extended Home Network and the Aggregated Home Network models can 433 be adapted for virtual links. 435 As in the case of a physical link, the Home Address of a Mobile 436 router can be constructed based on a dedicated subnet of the Home 437 Prefix or one of the MR MNPs. 439 Note that since the Home Address is never checked for DAD, it makes 440 the configuration easier to take it from the MNP as opposed to a 441 specific subnet. 443 There are certain advantages to making the Home Link a virtual link: 445 A virtual link may not experience any disruption related to 446 physical maintenance or to hardware problems, so it is more 447 available than a physical link. The high availability of the Home 448 Link is critical for the mobility service. 450 The Home Agent does not have to defend the Mobile Router's Home 451 Address through Proxy Neighbor Discovery. The Home Agent does not 452 also have to perform Duplicate Address Detection (DAD) for the 453 Mobile Router's Home Address when it receives a Binding Update 454 from the Mobile Router. 456 The Mobile Router does not have to implement the Returning Home 457 procedure (section 11.5.4 of Mobile IPv6. [7]). 459 In order for a Mobile Router to emulate returning Home, it can 460 connect to one or more access link(s) configured for that purpose on 461 the Home Agent. The Mobile Router, after connecting to the access 462 link, SHOULD not send any routing protocol updates on the egress 463 interface because the routing information from the Mobile Router 464 might adversely affect IPv6 route aggregation on the Home Network. 465 However, the Mobile Router must register its binding as if it was 466 accessing a foreign link. 468 There are also some drawbacks to the virtual Home Link approach: 470 There can be only one Home Agent since Mobile IPv6 relies on 471 Neighbor Discovery on the Home Link for other HA discovery and for 472 Duplicate Address Detection. 474 The Home Agent must maintain a Binding Cache entry for a Mobile 475 Router and forwarding state for its Mobile Network even when the 476 Mobile Router is directly connected to it. All traffic to and 477 from the Mobile Network is sent through the bi-directional tunnel 478 regardless of the Mobile Router location. This results in a 479 tunneling overhead even though the Mobile Router is connected to 480 the Home Network. 482 Some solutions can be proposed in order to perform an equivalent of 483 returning Home on a virtual Home Network. One such approach is 484 sketched in appendix as an illustration. 486 6.2 Applicability 488 At some point in the future, NEMO basic support may be extended to 489 operate fully at L3 for instance if the HAHA protocol [11] gets 490 standardized and deployed. Until then, NEMO operations still inherit 491 from mobile IPv6 [7] for the HA to HA communication, which is 492 basically based on Neighbor Discovery extensions over the Home Link. 493 Making that link virtual bars the deployment of multiple Home Agents, 494 which may be desirable for reasons of load balancing. Please refer 495 to the NEMO multihoming issues [12] draft for more on this. 497 Yet, for a deployment where a single HA is enough, making the Home 498 Link virtual reduces the vulnerability to some attacks and to some 499 hardware failures, while making the HA operation faster. 501 One should check with the product specifications of an HA to see 502 whether the implementation actually supports a Virtual Home Network, 503 and if so, whether in that cases, it is optimized for faster DAD-less 504 bindings. 506 7. Mobile Home 508 7.1 Configuration 510 In this disposition, there is a bitwise hierarchy of Home Networks. 511 A global Home Network is advertised to the infrastructure by a head 512 Home Agent(s) and further subnetted into Mobile Networks. As a 513 result, only the Home Agent(s) responsible for the most global 514 (shortest prefix) aggregation receive all the packets for all the 515 MNPs, which are leaves in the hierarchy tree. 517 Each subnet is owned by a Mobile Router that registers it in a NEMO 518 fashion while acting as a Home Agent for that network. This Mobile 519 Router is at Home at the upper level of hierarchy. This 520 configuration is referred to as Mobile Home. 522 An example of that is the Cab Co configuration. Say a Taxi Company 523 owns a /32 prefix. This prefix is advertised at a fixed point, the 524 Headquarters say. Regional offices are deployed around the world. 525 Even though these regional offices are relatively stable in terms of 526 location and prefix requirement -say this changes every few years- 527 making them mobile allows a simpler management when a move has to 528 take place, or should the ISP service change. 530 global Home Network CAB:C0::/32 owned by HQ 531 <-------------------------------------------------------------------> 533 HQ extended Home Net Mobile Home for SFO office 534 (casa) 535 CAB:C0:CA5A::/48 CAB:C0:5F0::/48 536 <----------------------------> ... <--------------------------------> 537 | 538 Home for offices HQ | 539 CAB:C0:CA5A:CA5A::/64 MN | 540 <----------------------><----> | 541 CAB:C0:CA5A:CA5A::CA5A | 542 CAB:C0:CA5A:CA5A::CA5B | 543 are HAs on link with for each office a route like | 544 | 545 CAB:C0:CA5A:CA5A::5F0 <---------------------- via 546 is the Home addr 547 of SFO office 549 Figure 6: CAB Company HQ configuration 551 Finally, each regional office owns a number of taxis, each one 552 equipped with a mobile router and an associated /64 prefix. 554 For each Office, say San Francisco (SFO) as an example: 556 Mobile Home Network CAB:C0:5F0::/48 owned by SFO office 557 <------------------------------------------------------------------> 559 SFO Home Network Mobile Networks for taxis 560 for taxis <---------------------...---------------------> 561 CAB:C0:5F0:5F0::/64 CAB:C0:5F0:CAB1::/64 CAB:C0:5F0:....::/6 562 <-------------------><-------------------> ... <-------------------> 563 CAB:C0:5F0:5F0::5F0 | 564 is HA on link with for | 565 each taxi a route like | 566 | 567 CAB:C0:5F0:5F0::CAB1 <------ via 568 is the Home addrSsync 569 of CAB 1 571 Figure 7: CAB Company regional configuration 573 Note that the hierarchy occurs at a configuration level and may not 574 be reflected in the actual connection between nodes. For instance in 575 the Cab Co case, cabs are roaming within the city, each one attaching 576 to a different hot spot, while the regional office is connected to 577 the infrastructure using some ISP connection. 579 But it is also possible to reflect the organizational hierarchy in a 580 moving cloud of Mobile Router. If a Mobile Home Agent acts as 581 root-MR for a nested configuration of its own MRs, then the 582 communication between MRs is confined within the nested structure. 584 This can be illustrated in the case of a fleet at sea. Say that now 585 SFO is a communication ship of a fleet, using a satellite link to 586 join the infrastructure, and that the cabs are Mobile Routers 587 installed on smaller ships, equipped with low range radios. 589 If SFO is also the root-MR of a nested structure of cabs, the 590 communication between cabs is relayed by SFO and does not require the 591 satellite link. SFO recursively terminates the nested tunnels to the 592 cabs and reencapsulates all the packets between the nested cloud and 593 correspondents in the infrastructure in a single tunnel to CA5A, this 594 providing for nested NEMO Route Optimization. 596 7.2 Applicability 598 This complex topology applies to large distributed fleet, mostly if 599 there is a single interchange point with the internet (e.g. a NAT or 600 a socks farm) where the super HA could be located. 602 One specific benefit is that when 2 MRs travel together with a common 603 HA, the traffic between the 2 is not necessarily routed via the 604 infrastructure, but can stay confined within the mobile cloud, the 605 Mobile Home Agent acting as a rendez-vous point between the MRs. 606 This applies particularly well for a fleet at sea when the long haul 607 access may be as expensive as a satellite link. 609 8. Changes 611 8.1 Changes from version 00 to 01 613 Removed terminology (moved to the Nemo terminology draft). 615 Added an applicability statement for all documented cases 617 9. Acknowledgements 619 The authors wish to thank: 621 Erik Nordmark, Kent Leung, Thierry Ernst, TJ Kniveton, Patrick 622 Wetterwald and Alexandru Petrescu for their contributions. 624 10 References 626 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 627 Levels", BCP 14, RFC 2119, March 1997. 629 [2] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) 630 Specification", RFC 2460, December 1998. 632 [3] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery 633 for IP Version 6 (IPv6)", RFC 2461, December 1998. 635 [4] Thomson, S. and T. Narten, "IPv6 Stateless Address 636 Autoconfiguration", RFC 2462, December 1998. 638 [5] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) 639 Addressing Architecture", RFC 3513, April 2003. 641 [6] Manner, J. and M. Kojo, "Mobility Related Terminology", RFC 642 3753, June 2004. 644 [7] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in 645 IPv6", RFC 3775, June 2004. 647 [8] Devarapalli, V., "Network Mobility (NEMO) Basic Support 648 Protocol", draft-ietf-nemo-basic-support-03 (work in progress), 649 June 2004. 651 [9] Ernst, T., "Network Mobility Support Goals and Requirements", 652 draft-ietf-nemo-requirements-02 (work in progress), February 653 2004. 655 [10] Ernst, T. and H. Lach, "Network Mobility Support Terminology", 656 draft-ietf-nemo-terminology-01 (work in progress), February 657 2004. 659 [11] Wakikawa, R., Devarapalli, V. and P. Thubert, "Inter Home 660 Agents Protocol (HAHA)", draft-wakikawa-mip6-nemo-haha-01 (work 661 in progress), February 2004. 663 [12] Ernst, T., "Analysis of Multihoming in Network Mobility 664 Support", draft-ietf-nemo-multihoming-issues-00 (work in 665 progress), July 2004. 667 Authors' Addresses 669 Pascal Thubert 670 Cisco Systems 671 Village d'Entreprises Green Side 672 400, Avenue de Roumanille 673 Batiment T3 674 Biot - Sophia Antipolis 06410 675 FRANCE 677 Phone: +33 4 97 23 26 34 678 EMail: pthubert@cisco.com 680 Ryuji Wakikawa 681 Keio University and WIDE 682 5322 Endo Fujisawa Kanagawa 683 252-8520 684 JAPAN 686 EMail: ryuji@sfc.wide.ad.jp 688 Vijay Devarapalli 689 Nokia Research Center 690 313 Fairchild Drive 691 Mountain View, CA 94043 692 USA 694 EMail: vijay.devarapalli@nokia.com 696 Appendix A. Returning Home emulation in the virtual case 698 When a Home Link is virtual, all traffic to and from the Mobile 699 Network is sent through the bi-directional tunnel even at the Home 700 Link. This section describes one possible mechanism that extends 701 NEMO Basic Support to eliminate this tunneling overhead. 703 Although the Home Link is virtual, the Home Agent has at least one 704 physical link to communicate with the external world. One or several 705 of such links, called the virtual Home Access Links, are conceptually 706 associated with the virtual Home Link and considered as part of Home. 708 When accessing one of its virtual Home Access Links, a Mobile Router 709 autoconfigures a Care-of Address from a Router Advertisement as it 710 would do on any visited link, in order to perform the next binding 711 flow. 713 If the Mobile Router is configured to recognize the virtual Home 714 Access Links as part of Home, it deregisters by sending a Binding 715 update with null lifetime sourced at the CareOf. Alternatively, the 716 Home Agent may indicate that the MR has moved to the virtual Home 717 Access Links as a status code in the binding acknowledgement. The 718 status code implies that Home Agent successsful de-register the 719 binding at the virtual Home Access Link. Detection of the virtual 720 Home Access Links is achieved by a prefix comparison(s) between the 721 care-of address and the prefix(es) on the virtual Home Access 722 Link(s). 724 With both approaches, the result of the binding flow is a 725 deregistration. Consequently, both the Mobile Router and the Home 726 Agent disable the bi-directional tunnel. At that point, the Home 727 Agent configures its forwarding in order to reach the Mobile Router 728 and its mobile networks at Home. For instance, this may take the 729 form of a route to the Mobile Network prefixes via the MR Home 730 Address, and a connected host route to the MR Home Address via the 731 virtual Home Access link. 733 After successful binding de-registration, the Mobile Router MUST 734 receive packets meant to the Mobile Router's Home Address at the 735 Virtual Home Link. How to intercept packets addressed to the Home 736 Address depends on implementations of the Mobile Router. If the Home 737 Address is not configured at the egress interface, the Mobile Router 738 MUST use proxy Neighbor Discovery to intercept all packets addressed 739 to the Home Address on the virtual Home Link. Otherwise, the Mobile 740 Router does not have to perform any special operation at the virtual 741 Home Link. 743 Intellectual Property Statement 745 The IETF takes no position regarding the validity or scope of any 746 Intellectual Property Rights or other rights that might be claimed to 747 pertain to the implementation or use of the technology described in 748 this document or the extent to which any license under such rights 749 might or might not be available; nor does it represent that it has 750 made any independent effort to identify any such rights. Information 751 on the procedures with respect to rights in RFC documents can be 752 found in BCP 78 and BCP 79. 754 Copies of IPR disclosures made to the IETF Secretariat and any 755 assurances of licenses to be made available, or the result of an 756 attempt made to obtain a general license or permission for the use of 757 such proprietary rights by implementers or users of this 758 specification can be obtained from the IETF on-line IPR repository at 759 http://www.ietf.org/ipr. 761 The IETF invites any interested party to bring to its attention any 762 copyrights, patents or patent applications, or other proprietary 763 rights that may cover technology that may be required to implement 764 this standard. Please address the information to the IETF at 765 ietf-ipr@ietf.org. 767 Disclaimer of Validity 769 This document and the information contained herein are provided on an 770 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 771 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 772 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 773 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 774 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 775 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 777 Copyright Statement 779 Copyright (C) The Internet Society (2004). This document is subject 780 to the rights, licenses and restrictions contained in BCP 78, and 781 except as set forth therein, the authors retain all their rights. 783 Acknowledgment 785 Funding for the RFC Editor function is currently provided by the 786 Internet Society.