idnits 2.17.1 draft-ietf-nemo-home-network-models-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 900. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 877. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 884. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 890. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 906), 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 7 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 327 has weird spacing: '... and it might...' == Line 469 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 (February 7, 2005) is 7018 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 754, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 757, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 760, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 780, 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-terminology-02 ** Downref: Normative reference to an Informational draft: draft-ietf-nemo-terminology (ref. '9') == Outdated reference: A later version (-06) exists of draft-ietf-nemo-requirements-03 ** Downref: Normative reference to an Informational draft: draft-ietf-nemo-requirements (ref. '10') == Outdated reference: A later version (-02) exists of draft-thubert-nemo-global-haha-00 -- Possible downref: Normative reference to a draft: ref. '11' == Outdated reference: A later version (-07) exists of draft-ietf-nemo-multihoming-issues-01 ** Downref: Normative reference to an Informational draft: draft-ietf-nemo-multihoming-issues (ref. '12') Summary: 20 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: August 8, 2005 R. Wakikawa 5 Keio University 6 V. Devarapalli 7 Nokia 8 February 7, 2005 10 NEMO Home Network models 11 draft-ietf-nemo-home-network-models-02 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 August 8, 2005. 38 Copyright Notice 40 Copyright (C) The Internet Society (2005). 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 . . . . . . . . . . . . . . . . . . . 5 54 3. General Expectations . . . . . . . . . . . . . . . . . . . . . 6 55 4. MIP Home Network . . . . . . . . . . . . . . . . . . . . . . . 7 56 5. NEMO Extended Home Network . . . . . . . . . . . . . . . . . . 8 57 5.1 Configuration . . . . . . . . . . . . . . . . . . . . . . 8 58 5.2 Returning Home . . . . . . . . . . . . . . . . . . . . . . 9 59 5.3 Home Address from MNP . . . . . . . . . . . . . . . . . . 9 60 5.4 Deployment Caveats . . . . . . . . . . . . . . . . . . . . 10 61 5.4.1 MR side . . . . . . . . . . . . . . . . . . . . . . . 10 62 5.5 Applicability . . . . . . . . . . . . . . . . . . . . . . 10 63 6. NEMO Aggregated Home Network . . . . . . . . . . . . . . . . . 11 64 6.1 Configuration . . . . . . . . . . . . . . . . . . . . . . 11 65 6.2 Returning Home . . . . . . . . . . . . . . . . . . . . . . 11 66 6.2.1 Returning Home by egress . . . . . . . . . . . . . . . 12 67 6.2.2 Returning Home by ingress . . . . . . . . . . . . . . 12 68 6.3 Applicability . . . . . . . . . . . . . . . . . . . . . . 13 69 6.4 Deployment Caveats . . . . . . . . . . . . . . . . . . . . 13 70 6.4.1 HA Side . . . . . . . . . . . . . . . . . . . . . . . 13 71 6.4.2 MR side . . . . . . . . . . . . . . . . . . . . . . . 14 72 7. Virtual Home Network . . . . . . . . . . . . . . . . . . . . . 15 73 7.1 Configuration . . . . . . . . . . . . . . . . . . . . . . 15 74 7.2 Applicability . . . . . . . . . . . . . . . . . . . . . . 16 75 8. Mobile Home . . . . . . . . . . . . . . . . . . . . . . . . . 17 76 8.1 Configuration . . . . . . . . . . . . . . . . . . . . . . 17 77 8.2 Applicability . . . . . . . . . . . . . . . . . . . . . . 18 78 9. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 79 9.1 Changes from version 00 to 01 . . . . . . . . . . . . . . 20 80 9.2 Changes from version 01 to 02 . . . . . . . . . . . . . . 20 81 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 82 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 22 84 A. Returning Home emulation in the virtual case . . . . . . . . . 23 85 Intellectual Property and Copyright Statements . . . . . . . . 24 87 1. Introduction 89 This document assumes that the reader is familiar with IPv6 Mobility 90 as defined in [7], with the NEMO Basic Support [8] and with the NEMO 91 terminology document [9]. 93 In order to read this document properly, the distinction between the 94 concepts of Home Link and of Home Network must be very clear. A Home 95 Link is a physical or a virtual Link, attached to a Home Agent. A 96 Home Network is an aggregation that can be further subnetted. As a 97 result, the Home Network is not necessarily contained on a Home Link. 98 In fact, the Mobile Network Prefixes are subnets of the Home Network. 99 How the two concepts relate in a given deployment depend on the 100 organization of the Home Network, as described below. 102 Five different organizations of the Home Network including a 103 hierarchical construction are documented: 105 MIPv6 Home Network: A short reminder of what the Home Network is with 106 Mobile IP, in order to help the reader figure out the evolution 107 towards NEMO. 109 NEMO Extended Home Network: In this disposition, the Home Network is 110 only one subnet of a larger aggregation that encompasses the 111 Mobile Networks, called extended Home Network. When at Home, a 112 Mobile Router performs normal routing between the Home Link and 113 the Mobile Networks. More in Section 5. 115 NEMO Aggregated Home Network: In this disposition, the Home Network 116 actually overlaps with the Mobile Networks. When at Home, a 117 Mobile Router acts as a bridge between the Home Link and the 118 Mobile Networks. More in Section 6. 120 Virtual Home Network: In this disposition, there is no physical Home 121 Link at all for the Mobile Routers to come back Home to. More in 122 Section 7. 124 NEMO Mobile Home Network: In this disposition, there is a bitwise 125 hierarchy of Home Networks. A global Home Network is advertised 126 to the infrastructure by a head Home Agent and further subnetted 127 into Mobile Networks. Each subnet is owned by a Mobile Router 128 that registers it in a NEMO fashion while acting as a Home Agent 129 for that network. More in Section 8. 131 In all cases, the Home Agents collectively advertise only the 132 aggregation of the Mobile Networks. The dichotomy is kept within the 133 Home Agents and the Mobile Routers, as opposed to advertised by means 134 of routing protocols to other parties. 136 The examples provided here aim at illustrating the NEMO Basic Support 137 [8] but do not aim at limiting its scope of application, and 138 additional cases may be added in the future. 140 2. Terminology and concepts 142 The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 143 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this document are to be 144 interpreted as described in RFC2119 [1]. 146 The following terms used in this document are defined in the IPv6 147 Addressing Architecture document [5]: 149 link-local unicast address 151 link-local scope multicast address 153 Most of the mobility related terms used in this document are defined 154 in the Mobility Related Terminology document [6] and in the Mobile 155 IPv6 (MIP6) specification [7]. 157 Additionally, some terms were created or extended for NEMO. These 158 specific terms are defined in the Mobile Network Terminology document 159 [9]: 161 Home Link 163 Home Network 165 Home Address 167 MRHA Tunnel 169 Mobile Aggregated Prefix 171 Aggregated Home Network 173 Extended Home Network 175 Virtual Home Network 177 Mobile Home Network 179 3. General Expectations 181 With Mobile IPv6, the Home Network is generally a physical network 182 interconnecting the Home Agents, and the Mobile Nodes that are at 183 Home. NEMO extends the concept of Home so that it is not only a flat 184 subnet composed of Home Addresses but an aggregation that is itself 185 subnetted in mobile and Home Networks. This aggregation is still 186 referred to as Home. 188 As an example, say that the aggregation has a global routing prefix 189 of m = 48 bits (A:B:C::/48), with subnet ID size of n = 16 bits ( n + 190 m = 64). 192 Say that a Mobile Router, MR1, owns the MNP A:B:C:1::/64: With NEMO 193 Basic Support, and depending on the deployment, MR1 may register 194 using a Home Address from the Home network, A:B:C:0::1, say, or a 195 Home Address, A:B:C:1::1, say, from one of its MNPs. 197 In a given deployment, one subnet may be reserved for the Home Link 198 (say A:B:C:0::/64) while the others are attributed to Mobile Routers 199 as Mobile Networks (as A:B:C:1::/64 for MR1). Another approach could 200 be to configure the Aggregation of Mobile Networks as the subnet on 201 the Home Link, and let the Mobile Routers manage the overlapping 202 networks. Finally, the aggregation could be configured on a virtual 203 network, with no physical Home Link at all, in which case Home means 204 topologically and administratively close to the Home Agent that owns 205 the virtual network. 207 The following sections provide additional information on these forms 208 of Home Network. 210 4. MIP Home Network 212 With Mobile IPv6 (MIP6) specification [7] Mobile Nodes are at Home 213 when they are connected to their Home Link, where they recognize 214 their Home Prefix in Router Advertisement messages. Also, a binding 215 is checked using of Duplicate Address Detection on the Home Link, and 216 Home Agents discover each other by means of Neighbor Discovery 217 extensions over that link. 219 The Home Prefix, that is advertized on the Home Link, is a final 220 prefix, as opposed to an aggregation, and it may be used by hosts on 221 the Home Link for autoconfiguration purposes. 223 As we see, the concept of a Home Network for Mobile IPv6 is really a 224 prefix on a link, served by one or more Home Agents as opposed to a 225 routed mesh. We will see in the next sections that NEMO needs 226 additional prefixes for use by the Mobile Networks. For that reason, 227 NEMO extends the concept of Home Network into a more complex, 228 aggregated structure. 230 5. NEMO Extended Home Network 232 5.1 Configuration 234 One simple way of extending the MIP Home Network is to use additional 235 prefixes, contiguous to the Home Link Prefix inherited from MIPv6, as 236 Mobile Network Prefixes. As this model trivially extends the MIP 237 Home Network, the resulting aggregation is called a NEMO Extended 238 Home Network. It is depicted in Figure 1. 240 | 241 route v /48 A:B:C::/48 243 HA 244 | /64 Home Link: A:B:C:0::/64 245 --+-----+--+- . -+- . -+-- 246 | | | | 247 MR1 MR2 MRi MRN 248 | | | | 249 ------ ------ ------ ------ 250 /64 /64 /64 /64 MNP: A:B:C:i::/64 252 Extended Home Network 253 <-----------------------------------------------------------> 255 Home Net Mobile Net Mobile Net ... Mobile Net 256 <------------><------------><------------> ... <------------> 258 Figure 1: Extended Home Network 260 In that configuration: 262 o There is one physical Home Network and multiple Mobile Networks 264 o The Home and the MNPs are tailored to allow for IPv6 Stateless 265 Address Autoconfiguration with typical interface identifier length 266 for the type of interface (can be for example /64). 268 o The prefix length of the Extended Home Network is shorter than 269 that of the Home Network and the MNPs, since it is an aggregation 270 (can be for example /48). 272 o Since the Extended Home Network operations inherit trivially from 273 MIPv6, it can be seen as natural that the Mobile Routers be 274 assigned their Home Addresses from the prefix on the Home Link, as 275 opposed to their own MNP, which is allowed by the NEMO 276 specification. In that case, a Home Agent can perform DAD on the 277 Home Link as prescribed by Mobile IPv6 for the Mobile Router Home 278 Addresses. 280 5.2 Returning Home 282 In the Extended Home Network model, the Home Network is configured on 283 a physical interface of the Home Agent, the Home Link. 285 A Mobile Router returns Home by connecting directly to the Home Link, 286 and dropping the MRHA tunnel. 288 When at home, the Mobile Router ensures the connectivity of the 289 Mobile Network using standard router operations. 291 In implicit mode, the HA has the necessary information to continue 292 routing to the MNPs in the absence of registration, and the 293 participation of the MR to the Home IGP is not required. 295 But in explicit mode, or if the MR uses an IGP over the MRHA tunnel, 296 then it must resume its IGP operations on the Home Link in order to 297 advertise its Mobile Networks. 299 Alternate procedures for ensuring the connectivity of the Mobile 300 Networks when at home are described in Section 7. 302 5.3 Home Address from MNP 304 We saw that a natural extension of the MIP procedure is to derive the 305 Home Address of a Mobile Router from the prefix on the Home Link. 306 Alternatively, NEMO basic support allows that a Mobile Router forms 307 its Home Address from one of its Mobile Network Prefixes. 309 In that case, the Home Address does not match the Home Link Prefix, 310 and there is a need to configure the HA in a specific mode with the 311 support for the extended Home Network and the range of the Mobile 312 Network Prefixes. Based on that new configuration, the HA can accept 313 a Home Address that is not from the Home Link, and it will know that 314 it should not perform any DAD. 316 Also, if the MR uses a Home Address that is derived from its MNP, 317 some specific support is required on the MR as well. In order to 318 determine that it is at Home, the MR recognizes the well-known prefix 319 of its Home Agent as opposed to matching the prefix on the Home Link 320 with that of its Home Address. 322 When connecting to the Home Link, the MR also need to autoconfigure 323 an address on the egress interface as opposed to assigning its Home 324 Address to the interface. 326 For all these reasons, this submode of extended is no more a trivial 327 extension to the MIPv6 Home Model, and it might not be compatible 328 with all implementations. 330 5.4 Deployment Caveats 332 5.4.1 MR side 334 In explicit mode, the routing to the MNP via the MR must be restored 335 when the MR is at Home. This is normally performed by the MR by 336 means of the existing IGP. In that case, a specific support is 337 required on the MR to control the routing protocol operation, 338 enabling the participation to the IGP if and only if the MR is at 339 home. This support might not be present in all implementations. 341 5.5 Applicability 343 The extended Home Network keeps the MIP6 concept of a Home Network 344 for both Mobile Nodes and Mobile Routers to take their Home Address 345 from. Since there is no overlap between the prefixes that are 346 affected to MNPs and prefix(es) that are dedicated to the Home Link, 347 it is possible for MNs and MRs to coexist with that model. 349 Also, when the Home Address is derived from the prefix on the Home 350 Link, the HA behavior on the link trivially extends that of MIP and 351 the support should for that configuration should be available with 352 all implementations. 354 6. NEMO Aggregated Home Network 356 6.1 Configuration 358 One other approach is to consider that the Aggregation of all the 359 MNPs is used plainly as the Home Link Prefix. In this model, the 360 Home Network is referred to as a NEMO Aggregated Home Network. This 361 means that the Mobile Aggregated Prefix is configured on the Home 362 Link and advertised by the Home Agent as a subnet, as depicted in 363 Figure 2. 365 HA 366 | /56 Aggreg /56 367 --+-----+--+- . -+- . -+-- 368 | | | | 369 MR1 MR2 MRi MRN 370 | | | | 371 ------ ------ ------ ------ 372 /64 /64 /64 /64 Aggreg|i /64 0 < i <= N 374 Aggregated Home 375 == Home Net 376 <-----------------------------------------------------------> 378 Mobile Net Mobile Net Mobile Net ... Mobile Net 379 <------------><------------><------------> ... <------------> 381 Figure 2: Aggregated Home 383 In that model, it seems natural to subnet the whole range of 384 addresses into Mobile Network prefixes, as opposed to reserving one 385 prefix for the Home Link, which would boil down to the Extended Home 386 Network model. If the prefix on the Home Link is really an 387 aggregation and not a final prefix, it should not be allowed for 388 autoconfiguration or Home Address allocation. 390 Note that in that case, it makes sense for a Mobile Router to 391 register using a Home Address from one of its own MNPs. Taking the 392 Home Address from its own range guarantees the uniqueness of the 393 suffix. That uniqueness can be checked by the MR on its ingress 394 network using DAD. 396 6.2 Returning Home 398 The Aggregated Home Prefix is configured on a physical interface of 399 the Home Agent, the Home Link. As a consequence, the Home Agent has 400 a connected route to the Aggregated Home Network over the Home Link. 402 A Mobile Router returns Home by connecting directly to the Home Link, 403 and dropping the MRHA tunnel. The Mobile Router recognizes its Home 404 Link by a prefix match with its Home Agent. 406 Note that it must expect a shorter prefix than that of its Mobile 407 Networks, even if its Home Address is formed out of one of its MNPs, 408 but that the Home Address still matches the Home Network Prefix. 410 6.2.1 Returning Home by egress 412 A Mobile Router coming Home via its egress interface sees overlapping 413 prefixes between the ingress and the egress interface and some 414 specific support may be needed: 416 When a Mobile Router connects to the Home Link using its egress 417 interface, it might set up a bridge between its ingress interface(s) 418 and the Home Link. 420 Alternatively, the Mobile Router might perform ND proxying for all 421 addresses in its MNPs, between the egress and the related ingress 422 interface. Since the prefixes on the egress and ingress interfaces 423 are overlapping, routing is disallowed. 425 On the positive side, the MR does not need to join the local IGP when 426 returning Home, even if it is using the explicit Prefix Mode. When 427 the MR is not registered, the HA simply expects that all MNNs will be 428 reachable over the Home Link. 430 HA 431 | /56 Aggreg /56 432 --+-----+--+- . -+- . -+-- 433 | | | | 434 MR1 MR2 MRi MRN 435 ------ ------ ------ ------ 436 /64 /64 /64 /64 Aggreg|i /64 0 < i <= N 438 Figure 3: Bridging between egress and ingress 440 6.2.2 Returning Home by ingress 442 Alternatively, if the MR has a single ingress Interface, the Mobile 443 Router may use the NEMO-Link to connect to the Home Link, merging the 444 two links in a single consistent network. 446 HA 447 | /56 Aggreg /56 448 --+-----+--+- . -+- . -+-- 449 /64 /64 /64 /64 Aggreg|i /64 0 < i <= N 450 ------ ------ ------ ------ 451 MR1 MR2 MRi MRN 452 | | | | 454 Figure 4: Merging the Home and the Mobile Networks 456 This fits the connected route model, since the Aggregated Home is 457 truly located on that network. Note that in that case, it makes 458 sense for a Mobile Router to register using a Home Address from one 459 of its own MNPs. . 461 6.3 Applicability 463 With this model, there is no specific space for independent nodes as 464 any address in the aggregation belongs to a MNP, and thus to a Mobile 465 Router. This configuration excludes the cohabitation with MIP6 MNs 466 on the Home Link. 468 A MR that is at Home must own an address from the aggregation on its 469 egress interface and an address from its MNP -a subnet of that 470 aggregation- on its ingress interface. A pure router will reject 471 that configuration, and the MR needs to act as a bridge to enable it. 472 In order to deploy the aggregated Home Network model, one must check 473 whether that support is available in the MRs if returning Home is 474 required. 476 6.4 Deployment Caveats 478 6.4.1 HA Side 480 A node on the Home Link discovers that the Aggregated Home Network is 481 actually a subnet on the Home Link and may use the prefix on the Home 482 Link to autoconfigure a Home Address. Such a node may also install a 483 connected route to the Aggregated Home Network over the Home Link. 485 As a result, unless the node has a better (longest match) route to a 486 given Mobile Network Prefix, it will lookup all MNNs on that MNP 487 using Neighbor Discovery over the Home Link. 489 Thus, on the Home Link, the Home Agent MUST intercept all the packets 490 to ALL the Mobile Network Nodes on the registered prefixes. In order 491 to do so, the Home Agent might perform some form of ND proxying for 492 all addresses in all registered Mobile Network Prefixes. The HA must 493 also protect the MNP space from autoconfiguration by uncontrolled 494 visitors at Neighbor Discovery level. 496 Alternatives based on a routing protocol or ICMP redirect may apply 497 in some cases. 499 In any case, there is a need to provide a specific configuration on 500 the HA to specify that it operates in Aggregated Mode. If a HA 501 implementation is simply derived from that of MIP, then the 502 capability to perform the required proxying might not exist, and the 503 Aggregated Mode will not operate properly for nodes on the Home Link. 505 6.4.2 MR side 507 If the MR returns Home by egress, a specific support is required to 508 control the bridging operation depending on whether a MR is at Home 509 or not. This support might not be present in all implementations. 511 Also, note that NEMO authorizes multiple registrations for a same MNP 512 by different Mobile Routers. This is a case of multihoming, and it 513 normally means that the MRs are interconnected by the ingress network 514 that bears the common MNP. But there is no provision in NEMO basic 515 support to test that this condition is met at binding time and 516 maintained overtime. 518 It is thus possible for 2 different MRs to register a same prefix 519 with different Home Addresses, and this will cause an undetected 520 problem if the corresponding ingress links are not connected. 522 When the Home Address of a Mobile Router is derived from its MNP, 523 there is thus an additional risk of an undetected misconfiguration if 524 the Home Address is autoconfigured from the ingress link as opposed 525 to statically assigned with the MNP itself. 527 7. Virtual Home Network 529 7.1 Configuration 531 The Home Link can be configured on the Home Agent on a virtual link, 532 in which case there's no physical Home Link for Mobile Routers to 533 return Home or for Home Agents to discover each others and perform 534 the ND level interactions as described in Mobile IPv6. [7] 536 /48 eg: A:B:C::/48 537 HA 538 | /64 A:C:C:E::/64 539 --+-----+--+- . -+- . -+-- 540 | | | | 541 MR1 MR2 MRi MRN 542 /64 /64 /64 /64 A:B:C:i::/64 0 < i <= N 544 Figure 5: Virtual Home Network 546 The Extended Home Network and the Aggregated Home Network models can 547 be adapted for virtual links. 549 As in the case of a physical link, the Home Address of a Mobile 550 router can be constructed based on a dedicated subnet of the Home 551 Prefix or one of the MR MNPs. 553 Note that since the Home Address is never checked for DAD, it makes 554 the configuration easier to take it from the MNP as opposed to a 555 specific subnet. 557 There are certain advantages to making the Home Link a virtual link: 559 A virtual link may not experience any disruption related to 560 physical maintenance or to hardware problems, so it is more 561 available than a physical link. The high availability of the Home 562 Link is critical for the mobility service. 564 The Home Agent does not have to defend the Mobile Router's Home 565 Address through Proxy Neighbor Discovery. The Home Agent does not 566 also have to perform Duplicate Address Detection (DAD) for the 567 Mobile Router's Home Address when it receives a Binding Update 568 from the Mobile Router. 570 The Mobile Router does not have to implement the Returning Home 571 procedure (section 11.5.4 of Mobile IPv6. [7]). 573 In order for a Mobile Router to emulate returning Home, it can 574 connect to one or more access link(s) configured for that purpose on 575 the Home Agent. The Mobile Router, after connecting to the access 576 link, SHOULD not send any routing protocol updates on the egress 577 interface because the routing information from the Mobile Router 578 might adversely affect IPv6 route aggregation on the Home Network. 579 However, the Mobile Router must register its binding as if it was 580 accessing a foreign link. 582 There are also some drawbacks to the virtual Home Link approach: 584 There can be only one Home Agent since Mobile IPv6 relies on 585 Neighbor Discovery on the Home Link for other HA discovery and for 586 Duplicate Address Detection. 588 The Home Agent must maintain a Binding Cache entry for a Mobile 589 Router and forwarding state for its Mobile Network even when the 590 Mobile Router is directly connected to it. All traffic to and 591 from the Mobile Network is sent through the bi-directional tunnel 592 regardless of the Mobile Router location. This results in a 593 tunneling overhead even though the Mobile Router is connected to 594 the Home Network. 596 Some solutions can be proposed in order to perform an equivalent of 597 returning Home on a virtual Home Network. One such approach is 598 sketched in appendix as an illustration. 600 7.2 Applicability 602 At some point in the future, NEMO basic support may be extended to 603 operate fully at L3 for instance if the HAHA protocol [11] gets 604 standardized and deployed. Until then, NEMO operations still inherit 605 from mobile IPv6 [7] for the HA to HA communication, which is 606 basically based on Neighbor Discovery extensions over the Home Link. 607 Making that link virtual bars the deployment of multiple Home Agents, 608 which may be desirable for reasons of load balancing. Please refer 609 to the NEMO multihoming issues [12] draft for more on this. 611 Yet, for a deployment where a single HA is enough, making the Home 612 Link virtual reduces the vulnerability to some attacks and to some 613 hardware failures, while making the HA operation faster. 615 One should check with the product specifications of an HA to see 616 whether the implementation actually supports a Virtual Home Network, 617 and if so, whether in that cases, it is optimized for faster DAD-less 618 bindings. 620 8. Mobile Home 622 8.1 Configuration 624 In this disposition, there is a bitwise hierarchy of Home Networks. 625 A global Home Network is advertised to the infrastructure by a head 626 Home Agent(s) and further subnetted into Mobile Networks. As a 627 result, only the Home Agent(s) responsible for the most global 628 (shortest prefix) aggregation receive all the packets for all the 629 MNPs, which are leaves in the hierarchy tree. 631 Each subnet is owned by a Mobile Router that registers it in a NEMO 632 fashion while acting as a Home Agent for that network. This Mobile 633 Router is at Home at the upper level of hierarchy. This 634 configuration is referred to as Mobile Home. 636 An example of that is the Cab Co configuration. Say a Taxi Company 637 owns a /32 prefix. This prefix is advertised at a fixed point, the 638 Headquarters say. Regional offices are deployed around the world. 639 Even though these regional offices are relatively stable in terms of 640 location and prefix requirement -say this changes every few years- 641 making them mobile allows a simpler management when a move has to 642 take place, or should the ISP service change. 644 global Home Network CAB:C0::/32 owned by HQ 645 <-------------------------------------------------------------------> 647 HQ extended Home Net Mobile Home for SFO office 648 (casa) 649 CAB:C0:CA5A::/48 CAB:C0:5F0::/48 650 <----------------------------> ... <--------------------------------> 651 | 652 Home for offices HQ | 653 CAB:C0:CA5A:CA5A::/64 MN | 654 <----------------------><----> | 655 CAB:C0:CA5A:CA5A::CA5A | 656 CAB:C0:CA5A:CA5A::CA5B | 657 are HAs on link with for each office a route like | 658 | 659 CAB:C0:CA5A:CA5A::5F0 <---------------------- via 660 is the Home addr 661 of SFO office 663 Figure 6: CAB Company HQ configuration 665 Finally, each regional office owns a number of taxis, each one 666 equipped with a mobile router and an associated /64 prefix. 668 For each Office, say San Francisco (SFO) as an example: 670 Mobile Home Network CAB:C0:5F0::/48 owned by SFO office 671 <------------------------------------------------------------------> 673 SFO Home Network Mobile Networks for taxis 674 for taxis <---------------------...---------------------> 675 CAB:C0:5F0:5F0::/64 CAB:C0:5F0:CAB1::/64 CAB:C0:5F0:....::/6 676 <-------------------><-------------------> ... <-------------------> 677 CAB:C0:5F0:5F0::5F0 | 678 is HA on link with for | 679 each taxi a route like | 680 | 681 CAB:C0:5F0:5F0::CAB1 <------ via 682 is the Home addrSsync 683 of CAB 1 685 Figure 7: CAB Company regional configuration 687 Note that the hierarchy occurs at a configuration level and may not 688 be reflected in the actual connection between nodes. For instance in 689 the Cab Co case, cabs are roaming within the city, each one attaching 690 to a different hot spot, while the regional office is connected to 691 the infrastructure using some ISP connection. 693 But it is also possible to reflect the organizational hierarchy in a 694 moving cloud of Mobile Router. If a Mobile Home Agent acts as 695 root-MR for a nested configuration of its own MRs, then the 696 communication between MRs is confined within the nested structure. 698 This can be illustrated in the case of a fleet at sea. Say that now 699 SFO is a communication ship of a fleet, using a satellite link to 700 join the infrastructure, and that the cabs are Mobile Routers 701 installed on smaller ships, equipped with low range radios. 703 If SFO is also the root-MR of a nested structure of cabs, the 704 communication between cabs is relayed by SFO and does not require the 705 satellite link. SFO recursively terminates the nested tunnels to the 706 cabs and reencapsulates all the packets between the nested cloud and 707 correspondents in the infrastructure in a single tunnel to CA5A, this 708 providing for nested NEMO Route Optimization. 710 8.2 Applicability 712 This complex topology applies to large distributed fleet, mostly if 713 there is a single interchange point with the internet (e.g. a NAT or 714 a socks farm) where the super HA could be located. 716 One specific benefit is that when 2 MRs travel together with a common 717 HA, the traffic between the 2 is not necessarily routed via the 718 infrastructure, but can stay confined within the mobile cloud, the 719 Mobile Home Agent acting as a rendez-vous point between the MRs. 720 This applies particularly well for a fleet at sea when the long haul 721 access may be as expensive as a satellite link. 723 9. Changes 725 9.1 Changes from version 00 to 01 727 Removed terminology (moved to the Nemo terminology draft). 729 Added an applicability statement for all documented cases 731 9.2 Changes from version 01 to 02 733 Issue 1: Editorial 735 Issue 2: Added a caveat part in extended and aggregated sections. 736 Also added a MIP Home Network section prior to those. 738 Issue 4: Added a subsection to the extended case for the case when 739 the mr takes a home address from its MNP 741 10. Acknowledgements 743 The authors wish to thank: 745 Erik Nordmark, Kent Leung, Thierry Ernst, TJ Kniveton, Patrick 746 Wetterwald, Alexandru Petrescu and David Binet. for their 747 contributions. 749 11 References 751 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 752 Levels", BCP 14, RFC 2119, March 1997. 754 [2] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) 755 Specification", RFC 2460, December 1998. 757 [3] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery 758 for IP Version 6 (IPv6)", RFC 2461, December 1998. 760 [4] Thomson, S. and T. Narten, "IPv6 Stateless Address 761 Autoconfiguration", RFC 2462, December 1998. 763 [5] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) 764 Addressing Architecture", RFC 3513, April 2003. 766 [6] Manner, J. and M. Kojo, "Mobility Related Terminology", RFC 767 3753, June 2004. 769 [7] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in 770 IPv6", RFC 3775, June 2004. 772 [8] Devarapalli, V., Wakikawa, R., Petrescu, A. and P. Thubert, 773 "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, 774 January 2005. 776 [9] Ernst, T. and H. Lach, "Network Mobility Support Terminology", 777 draft-ietf-nemo-terminology-02 (work in progress), October 778 2004. 780 [10] Ernst, T., "Network Mobility Support Goals and Requirements", 781 draft-ietf-nemo-requirements-03 (work in progress), October 782 2004. 784 [11] Thubert, P., "Global HA to HA protocol", 785 draft-thubert-nemo-global-haha-00 (work in progress), October 786 2004. 788 [12] Ernst, T., "Analysis of Multihoming in Network Mobility 789 Support", draft-ietf-nemo-multihoming-issues-01 (work in 790 progress), October 2004. 792 Authors' Addresses 794 Pascal Thubert 795 Cisco Systems 796 Village d'Entreprises Green Side 797 400, Avenue de Roumanille 798 Batiment T3 799 Biot - Sophia Antipolis 06410 800 FRANCE 802 Phone: +33 4 97 23 26 34 803 EMail: pthubert@cisco.com 805 Ryuji Wakikawa 806 Keio University and WIDE 807 5322 Endo Fujisawa Kanagawa 808 252-8520 809 JAPAN 811 EMail: ryuji@sfc.wide.ad.jp 813 Vijay Devarapalli 814 Nokia Research Center 815 313 Fairchild Drive 816 Mountain View, CA 94043 817 USA 819 EMail: vijay.devarapalli@nokia.com 821 Appendix A. Returning Home emulation in the virtual case 823 When a Home Link is virtual, all traffic to and from the Mobile 824 Network is sent through the bi-directional tunnel even at the Home 825 Link. This section describes one possible mechanism that extends 826 NEMO Basic Support to eliminate this tunneling overhead. 828 Although the Home Link is virtual, the Home Agent has at least one 829 physical link to communicate with the external world. One or several 830 of such links, called the virtual Home Access Links, are conceptually 831 associated with the virtual Home Link and considered as part of Home. 833 When accessing one of its virtual Home Access Links, a Mobile Router 834 autoconfigures a Care-of Address from a Router Advertisement as it 835 would do on any visited link, in order to perform the next binding 836 flow. 838 If the Mobile Router is configured to recognize the virtual Home 839 Access Links as part of Home, it deregisters by sending a Binding 840 update with null lifetime sourced at the CareOf. Alternatively, the 841 Home Agent may indicate that the MR has moved to the virtual Home 842 Access Links as a status code in the binding acknowledgement. The 843 status code implies that Home Agent successsful de-register the 844 binding at the virtual Home Access Link. Detection of the virtual 845 Home Access Links is achieved by a prefix comparison(s) between the 846 care-of address and the prefix(es) on the virtual Home Access 847 Link(s). 849 With both approaches, the result of the binding flow is a 850 deregistration. Consequently, both the Mobile Router and the Home 851 Agent disable the bi-directional tunnel. At that point, the Home 852 Agent configures its forwarding in order to reach the Mobile Router 853 and its mobile networks at Home. For instance, this may take the 854 form of a route to the Mobile Network prefixes via the MR Home 855 Address, and a connected host route to the MR Home Address via the 856 virtual Home Access link. 858 After successful binding de-registration, the Mobile Router MUST 859 receive packets meant to the Mobile Router's Home Address at the 860 Virtual Home Link. How to intercept packets addressed to the Home 861 Address depends on implementations of the Mobile Router. If the Home 862 Address is not configured at the egress interface, the Mobile Router 863 MUST use proxy Neighbor Discovery to intercept all packets addressed 864 to the Home Address on the virtual Home Link. Otherwise, the Mobile 865 Router does not have to perform any special operation at the virtual 866 Home Link. 868 Intellectual Property Statement 870 The IETF takes no position regarding the validity or scope of any 871 Intellectual Property Rights or other rights that might be claimed to 872 pertain to the implementation or use of the technology described in 873 this document or the extent to which any license under such rights 874 might or might not be available; nor does it represent that it has 875 made any independent effort to identify any such rights. Information 876 on the procedures with respect to rights in RFC documents can be 877 found in BCP 78 and BCP 79. 879 Copies of IPR disclosures made to the IETF Secretariat and any 880 assurances of licenses to be made available, or the result of an 881 attempt made to obtain a general license or permission for the use of 882 such proprietary rights by implementers or users of this 883 specification can be obtained from the IETF on-line IPR repository at 884 http://www.ietf.org/ipr. 886 The IETF invites any interested party to bring to its attention any 887 copyrights, patents or patent applications, or other proprietary 888 rights that may cover technology that may be required to implement 889 this standard. Please address the information to the IETF at 890 ietf-ipr@ietf.org. 892 Disclaimer of Validity 894 This document and the information contained herein are provided on an 895 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 896 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 897 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 898 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 899 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 900 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 902 Copyright Statement 904 Copyright (C) The Internet Society (2005). This document is subject 905 to the rights, licenses and restrictions contained in BCP 78, and 906 except as set forth therein, the authors retain all their rights. 908 Acknowledgment 910 Funding for the RFC Editor function is currently provided by the 911 Internet Society.