idnits 2.17.1 draft-ietf-nemo-home-network-models-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 931. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 908. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 915. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 921. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == 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). -- 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 17, 2006) is 6643 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) -- Looks like a reference, but probably isn't: 'RFC3963' on line 761 == Unused Reference: '2' is defined on line 827, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 830, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 833, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 836, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 853, 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-04 ** 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-05 ** Downref: Normative reference to an Informational draft: draft-ietf-nemo-requirements (ref. '10') == Outdated reference: A later version (-03) exists of draft-ietf-nemo-ro-problem-statement-02 == Outdated reference: A later version (-07) exists of draft-ietf-nemo-multihoming-issues-04 Summary: 11 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: August 21, 2006 R. Wakikawa 5 Keio University 6 V. Devarapalli 7 Nokia 8 February 17, 2006 10 NEMO Home Network models 11 draft-ietf-nemo-home-network-models-06 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on August 21, 2006. 38 Copyright Notice 40 Copyright (C) The Internet Society (2006). 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. The aim here is specifically to 47 provide some examples of organization of the Home Network, as they 48 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. MIP Home Network . . . . . . . . . . . . . . . . . . . . . . . 6 56 5. NEMO Extended Home Network . . . . . . . . . . . . . . . . . . 7 57 5.1 Configuration . . . . . . . . . . . . . . . . . . . . . . 7 58 5.2 Returning Home . . . . . . . . . . . . . . . . . . . . . . 8 59 5.3 Home Address from MNP . . . . . . . . . . . . . . . . . . 8 60 5.4 Deployment Caveats . . . . . . . . . . . . . . . . . . . . 9 61 5.4.1 Mobile Router side . . . . . . . . . . . . . . . . . . 9 62 5.5 Applicability . . . . . . . . . . . . . . . . . . . . . . 9 63 6. NEMO Aggregated Home Network . . . . . . . . . . . . . . . . . 10 64 6.1 Configuration . . . . . . . . . . . . . . . . . . . . . . 10 65 6.2 Returning Home . . . . . . . . . . . . . . . . . . . . . . 10 66 6.2.1 Returning Home with the Egress interface . . . . . . . 11 67 6.2.2 Returning Home with the Ingress interface . . . . . . 11 68 6.3 Applicability . . . . . . . . . . . . . . . . . . . . . . 12 69 6.4 Deployment Caveats . . . . . . . . . . . . . . . . . . . . 12 70 6.4.1 Home Agent Side . . . . . . . . . . . . . . . . . . . 12 71 6.4.2 Mobile Router side . . . . . . . . . . . . . . . . . . 13 72 7. Virtual Home Network . . . . . . . . . . . . . . . . . . . . . 14 73 7.1 Configuration . . . . . . . . . . . . . . . . . . . . . . 14 74 7.2 Applicability . . . . . . . . . . . . . . . . . . . . . . 15 75 8. Mobile Home . . . . . . . . . . . . . . . . . . . . . . . . . 16 76 8.1 Configuration . . . . . . . . . . . . . . . . . . . . . . 16 77 8.2 Applicability . . . . . . . . . . . . . . . . . . . . . . 18 78 9. IANA considerations . . . . . . . . . . . . . . . . . . . . . 18 79 10. Security Considerations . . . . . . . . . . . . . . . . . . 18 80 11. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . 19 81 11.1 Changes from version 00 to 01 . . . . . . . . . . . . . . 19 82 11.2 Changes from version 01 to 02 . . . . . . . . . . . . . . 19 83 11.3 Changes from version 02 to 03 . . . . . . . . . . . . . . 19 84 11.4 Changes from version 03 to 04 . . . . . . . . . . . . . . 19 85 11.5 Changes from version 04 to 05 . . . . . . . . . . . . . . 19 86 11.6 Changes from version 05 to 06 (IESG review) . . . . . . . 19 87 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 88 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 89 13.1 normative reference . . . . . . . . . . . . . . . . . . . 21 90 13.2 informative reference . . . . . . . . . . . . . . . . . . 22 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 22 92 Intellectual Property and Copyright Statements . . . . . . . . 23 94 1. Introduction 96 This document assumes that the reader is familiar with IPv6 Mobility 97 as defined by Mobile IPv6 and the NEMO Basic Support. In order to 98 read this document properly, it is important to realize that in NEMO, 99 the Home Network can encompass much more than the Home Link, as it 100 spans the Home Link and all the Links that the Mobile Routers (MRs) 101 carry with them. Exactly how the two concepts relate in a given 102 deployment depend on the organization of the Home Network, as 103 described below. 105 Five different organizations of the Home Network including a 106 hierarchical construction are documented: 108 MIPv6 Home Network: A short reminder of what the Home Network is with 109 Mobile IP, in order to help the reader figure out the evolution 110 towards NEMO. 112 NEMO Extended Home Network: In this arrangement, the Home Network is 113 only one subnet of a larger aggregation that encompasses the 114 Mobile Networks, called extended Home Network. When at Home, a 115 Mobile Router performs normal routing between the Home Link and 116 the Mobile Networks. More in Section 5. 118 NEMO Aggregated Home Network: In this arrangement, the Home Network 119 actually overlaps with the Mobile Networks. When at Home, a 120 Mobile Router acts as a bridge between the Home Link and the 121 Mobile Networks. More in Section 6. 123 Virtual Home Network: In this arrangement, there is no physical Home 124 Link at all for the Mobile Routers to come back Home to. More in 125 Section 7. 127 NEMO Mobile Home Network: In this arrangement, there is a bitwise 128 hierarchy of Home Networks. A global Home Network is advertised 129 to the infrastructure by a head Home Agent (HA) and further 130 subnetted into Mobile Networks. Each subnet is owned by a Mobile 131 Router that registers it in a NEMO fashion while acting as a Home 132 Agent for that network. More in Section 8. 134 In all cases, the Home Agents collectively advertise only the 135 aggregation of the Mobile Networks. The subnetting is kept within 136 the Home Agents and the Mobile Routers, as opposed to advertised by 137 means of routing protocols to other parties. 139 The examples provided here aim at illustrating the NEMO Basic Support 140 [8] but do not aim at limiting its scope of application, and 141 additional cases may be added in the future. 143 2. Terminology and concepts 145 The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 146 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this document are to be 147 interpreted as described in RFC2119 [1]. 149 Most of the mobility related terms used in this document are defined 150 in the Mobility Related Terminology document [6] and in the Mobile 151 IPv6 (MIP6) specification [7]. 153 Additionally, some terms were created or extended for NEMO. These 154 specific terms are defined in the Mobile Network Terminology document 155 [9]: 157 Home Link 159 Home Network 161 Home Address 163 MRHA Tunnel 165 Mobile Aggregated Prefix 167 Aggregated Home Network 169 Extended Home Network 171 Virtual Home Network 173 Mobile Home Network 175 3. General Expectations 177 With Mobile IPv6, the Home Network is generally a physical network 178 interconnecting the Home Agents, and the Mobile Nodes that are at 179 Home. NEMO extends the concept of Home so that it is not only a flat 180 subnet composed of Home Addresses but an aggregation that is itself 181 subnetted in mobile and Home Networks. This aggregation is still 182 referred to as Home. 184 As an example, considering the case where the aggregation has a 185 global routing prefix of m = 48 bits (A:B:C::/48), with subnet ID 186 size of n = 16 bits ( n + m = 64): 188 When a Mobile Router, MR1, uses the Mobile Network Prefix (MNP) A:B: 189 C:1::/64 with the NEMO Basic Support, MR1 may register using a Home 190 Address from the Home network (i.e. A:B:C:0::1) or a Home Address 191 from one of its MNPs (i.e. A:B:C:1::1) depending on the deployment. 193 In a given deployment, one subnet may be reserved for the Home Link 194 (A:B:C:0::/64) while the others are attributed to Mobile Routers as 195 Mobile Networks (as A:B:C:1::/64 for MR1). Another approach could be 196 to configure the Aggregation of Mobile Networks as the subnet on the 197 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 201 advertises the virtual network. 203 The following sections provide additional information on these forms 204 of Home Network. 206 4. MIP Home Network 208 In the Mobile IPv6 (MIP6) specification [7] Mobile Nodes are at Home 209 when they are connected to their Home Link, where they recognize 210 their Home Prefix in Router Advertisement messages. Also, a binding 211 is checked using Duplicate Address Detection on the Home Link, and 212 Home Agents discover each other by means of Neighbor Discovery 213 extensions over that link. 215 The Home Prefix that is advertized on the Home Link is a final 216 prefix, as opposed to an aggregation, and it may be used by hosts on 217 the Home Link for autoconfiguration purposes. 219 As we see, the concept of a Home Network for Mobile IPv6 is really a 220 prefix on a link, served by one or more Home Agents as opposed to a 221 routed mesh. We will see in the next sections that NEMO needs 222 additional prefixes for use by the Mobile Networks. For that reason, 223 NEMO extends the concept of Home Network into a more complex, 224 aggregated structure. 226 5. NEMO Extended Home Network 228 5.1 Configuration 230 One simple way of extending the MIP Home Network is to use additional 231 prefixes, contiguous to the Home Link Prefix inherited from MIPv6, as 232 Mobile Network Prefixes. As this model trivially extends the MIP 233 Home Network, the resulting aggregation is called a NEMO Extended 234 Home Network. It is depicted in Figure 1. 236 | 237 route v /48 A:B:C::/48 239 HA 240 | /64 Home Link: A:B:C:0::/64 241 --+-----+--+- . -+- . -+-- 242 | | | | 243 MR1 MR2 MRi MRN 244 | | | | 245 ------ ------ ------ ------ 246 /64 /64 /64 /64 MNP: A:B:C:i::/64 248 Extended Home Network 249 <-----------------------------------------------------------> 251 Home Net Mobile Net Mobile Net ... Mobile Net 252 <------------><------------><------------> ... <------------> 254 Figure 1: Extended Home Network 256 In that arrangement: 258 o There is one physical Home Network and multiple Mobile Networks 260 o The Home and the MNPs are tailored to allow for IPv6 Stateless 261 Address Autoconfiguration with typical interface identifier length 262 for the type of interface (can be for example /64). 264 o The prefix length of the Extended Home Network is shorter than 265 that of the Home Network and the MNPs, since it is an aggregation 266 (can be for example /48). 268 o Since the Extended Home Network operations inherit trivially from 269 MIPv6, it can be seen as natural that the Mobile Routers be 270 assigned their Home Addresses from the prefix on the Home Link. 271 In that case, a Home Agent can perform DAD on the Home Link as 272 prescribed by Mobile IPv6 for the Mobile Router Home Addresses. 274 5.2 Returning Home 276 In the Extended Home Network model, the Home Network is configured on 277 a physical interface of the Home Agent, the Home Link. 279 A Mobile Router returns Home by connecting directly to the Home Link, 280 and dropping the MRHA tunnel. 282 When at home, the Mobile Router ensures the connectivity of the 283 Mobile Network using standard router operations. 285 In implicit mode, the Home Agent has the necessary information to 286 continue routing to the MNPs in the absence of registration, assuming 287 that the Mobile Router is at Home, and the participation of the 288 Mobile Router to the Home Interior Gateway Protocol (IGP) is not 289 required. 291 But in explicit mode, or if the Mobile Router uses an IGP over the 292 MRHA tunnel, then it needs to resume its IGP operations on the Home 293 Link in order to advertise its Mobile Networks to the HA, unless some 294 other means such as static routes are deployed to cover the case. 296 Alternative procedures for ensuring the connectivity of the Mobile 297 Networks when at home are described in Section 7. 299 5.3 Home Address from MNP 301 We saw that a natural extension of the MIP procedure is to derive the 302 Home Address of a Mobile Router from the prefix on the Home Link. 303 Alternatively, NEMO basic support allows that a Mobile Router forms 304 its Home Address from one of its Mobile Network Prefixes. 306 In that case, the Home Address does not match the Home Link Prefix, 307 and there is a need to configure the Home Agent in a specific mode 308 with the support for the Extended Home Network and the range of the 309 Mobile Network Prefixes. Based on that new configuration, the Home 310 Agent can accept a Home Address that is not from the Home Link, and 311 it will know that it should not perform any DAD. 313 Also, if the Mobile Router uses a Home Address that is derived from 314 its MNP, some specific support is required on the Mobile Router as 315 well. In order to determine that it is at Home, the Mobile Router 316 recognizes the well-known prefix of its Home Agent as opposed to 317 matching the prefix on the Home Link with that of its Home Address. 319 When connecting to the Home Link, the Mobile Router also need to 320 autoconfigure an address on the Egress interface as opposed to 321 assigning its Home Address to the interface. 323 For all these reasons, this submode of Extended Home Network is not a 324 trivial extension of the MIPv6 Home Model, and it might not be 325 compatible with all implementations. 327 5.4 Deployment Caveats 329 5.4.1 Mobile Router side 331 In explicit mode, the routing to the MNP via the Mobile Router must 332 be restored when the Mobile Router is at Home. This is normally 333 performed by the Mobile Router by means of the existing IGP. In that 334 case, a specific support is required on the Mobile Router to control 335 the routing protocol operation, enabling the participation in the IGP 336 if and only if the Mobile Router is at home. 338 The NEMO Basic Support does not mandate a specific routing protocol 339 though the support for some well known routing protocols can be 340 expected from many implementations. An implementation might provide 341 an automatic toggle to start/stop routing on an egress interface when 342 the mobile router comes back/leaves Home. When such a toggle is 343 unavailable, then a specific interface should be reserved to attach 344 to Home with the appropriate settings for security and routing. 346 5.5 Applicability 348 The Extended Home Network keeps the MIP6 concept of a Home Network 349 for both Mobile Nodes and Mobile Routers to take their Home Address 350 from. Since there is no overlap between the prefixes that are 351 assigned to MNPs and prefix(es) that are dedicated to the Home Link, 352 it is possible for MNs and Mobile Routers to coexist with that model. 354 Also, when the Home Address is derived from the prefix on the Home 355 Link, the Home Agent behavior on the link trivially extends that of 356 MIP and the support for that configuration should be available with 357 all implementations. 359 There are a number of issues with returning home when a mobile router 360 configures its home address from the MNP as described in Section 5.3. 361 Therefore we do not recommend this mechanism if the mobile routers 362 attach to the home network. 364 6. NEMO Aggregated Home Network 366 6.1 Configuration 368 One other approach is to consider that the Aggregation of all the 369 MNPs is used plainly as the Home Link Prefix. In this model, the 370 Home Network is referred to as a NEMO Aggregated Home Network. This 371 means that the Mobile Aggregated Prefix is configured on the Home 372 Link and advertised by the Home Agent as a subnet, as depicted in 373 Figure 2. 375 HA 376 | /56 Aggreg /56 377 --+-----+--+- . -+- . -+-- 378 | | | | 379 MR1 MR2 MRi MRN 380 | | | | 381 ------ ------ ------ ------ 382 /64 /64 /64 /64 Aggreg|i /64 0 < i <= N 384 Aggregated Home == Home Net 385 <-----------------------------------------------------------> 387 Mobile Net Mobile Net Mobile Net ... Mobile Net 388 <------------><------------><------------> ... <------------> 390 Figure 2: Aggregated Home 392 In that model, it seems natural to subnet the whole range of 393 addresses into Mobile Network prefixes, as opposed to reserving one 394 prefix for the Home Link, which would boil down to the Extended Home 395 Network model. If the prefix on the Home Link is really an 396 aggregation and not a final prefix, it should not be allowed for 397 autoconfiguration or Home Address allocation. 399 Note that in that case, it makes sense for a Mobile Router to 400 register using a Home Address from one of its own MNPs. Taking the 401 Home Address from its own range guarantees the uniqueness of the 402 suffix. That uniqueness can be checked by the Mobile Router on its 403 Ingress network (see [6]) using DAD. 405 6.2 Returning Home 407 The Aggregated Home Prefix is configured on a physical interface of 408 the Home Agent, the Home Link. As a consequence, the Home Agent has 409 a connected route to the Aggregated Home Network over the Home Link. 411 A Mobile Router returns Home by connecting directly to the Home Link, 412 and dropping the MRHA tunnel. The Mobile Router recognizes its Home 413 Link by a prefix match with its Home Agent. 415 When the Mobile Router forms its Home Address out of one of its MNPs, 416 since the Home Network prefix is an aggregation that encompasses all 417 the MNPs, the Home Address actually matches both prefixes. To 418 properly identify the Home Network as it returns Home, the MR must 419 expect a shorter prefix length than that of the MNP from which the 420 Home Address was formed. 422 6.2.1 Returning Home with the Egress interface 424 A Mobile Router coming Home via its Egress interface sees overlapping 425 prefixes between the Ingress and the Egress interface and some 426 specific support may be needed: 428 When a Mobile Router connects to the Home Link using its Egress 429 interface, it might set up a bridge between its Ingress interface(s) 430 and the Home Link, if the interfaces are compatible. 432 Alternatively, the Mobile Router might perform ND proxying for all 433 addresses in its MNPs, between the Egress and the related Ingress 434 interface, as described in [12]. Since the prefixes on the Egress 435 and Ingress interfaces are overlapping, routing is disallowed. 437 The Mobile Router does not need to join the local IGP when returning 438 Home, even if it is using the explicit Prefix Mode. When the Mobile 439 Router is not registered, the Home Agent simply expects that all 440 Mobile Network Nodes (MNNs) will be reachable over the Home Link. 442 HA 443 | 444 -------+--+--- /56 445 | 446 Egress | 447 MR at Home 448 | 449 --+--- /64 451 Figure 3: Bridging between egress and ingress 453 6.2.2 Returning Home with the Ingress interface 455 Alternatively, if the Mobile Router has a single Ingress interface, 456 the Mobile Router may use the NEMO-Link to connect to the Home Link, 457 merging the two links in a single consistent network. 459 HA 460 | 461 -------+-+---- /56 462 | 463 ---+-- /64 464 | 465 MR at Home 466 Egress | 468 Figure 4: Merging the Home and the Mobile Networks 470 This fits the connected route model, since the Aggregated Home is 471 truly located on that network. Note that in that case, it makes 472 sense for a Mobile Router to register using a Home Address from one 473 of its own MNPs. 475 6.3 Applicability 477 With this model, there is no specific space for independent nodes, as 478 any address in the aggregation belongs to a MNP, and thus to a Mobile 479 Router. This configuration excludes the cohabitation with MIP6 MNs 480 on the Home Link. 482 6.4 Deployment Caveats 484 6.4.1 Home Agent Side 486 A node on the Home Link receiving a Router Advertisement that 487 includes the Aggregated Home Network prefix might use that prefix for 488 Address Autoconfiguration. Such a node would also install a 489 connected route to the Aggregated Home Network over the Home Link. 491 As a result, unless the node has a better (longest match) route to a 492 given Mobile Network Prefix, it would lookup all MNNs on that MNP 493 using Neighbor Discovery over its interface to the Home Link, and 494 fail. 496 Thus, on the Home Link, the Home Agent must intercept all the packets 497 for ALL the Mobile Network Nodes on the registered prefixes - that is 498 for ALL nodes attached to Mobile Routers that are away from Home. 499 This should be a layer 2 operation, rather than layer 3. The Home 500 agent might, for example, perform some form of ND proxying for all 501 addresses in all registered Mobile Network Prefixes. 503 The Home Agent must also protect the MNP space from autoconfiguration 504 by uncontrolled visitors at Neighbor Discovery level. 506 There is a need to provide a specific configuration on the Home Agent 507 to specify that it operates in Aggregated Mode. If a Home Agent 508 implementation is simply derived from that of MIP, then the 509 capability to perform the required proxying might not exist, and the 510 Aggregated Mode will not operate properly for nodes on the Home Link. 512 6.4.2 Mobile Router side 514 If the Mobile Router returns Home by Egress, a specific support is 515 required to control the bridging operation depending on whether a 516 Mobile Router is at Home or not. This support might not be present 517 in all implementations. 519 The NEMO Basic Support does not mention a specific behavior for 520 bridging though Bridging capabilities can be expected from many 521 implementations. An implementation might provide an automatic toggle 522 to start/stop bridging on an egress interface when the mobile router 523 comes back/leaves Home. When such a toggle is unavailable, then a 524 specific interface should be reserved to attach to Home with the 525 appropriate settings for security and bridging. 527 Also, note that NEMO authorizes multiple registrations for a same MNP 528 by different Mobile Routers. This is a case of multihoming, and it 529 normally means that the Mobile Routers are interconnected by the 530 Ingress network that bears the common MNP. But there is no provision 531 in NEMO basic support to test that this condition is met at binding 532 time and maintained over time. 534 It is thus possible for 2 different Mobile Routers to register the 535 same prefix with different Home Addresses, and this will cause an 536 undetected problem if the corresponding Ingress interfaces are not 537 connected. 539 When the Home Address of a Mobile Router is derived from its MNP, 540 there is thus an additional risk of an undetected misconfiguration if 541 the Home Address is autoconfigured from the Ingress interface as 542 opposed to statically assigning an address and MNP. 544 A Mobile Router that is at Home must own an address from the 545 aggregation on its Egress interface and an address from its MNP - a 546 subnet of that aggregation - on its Ingress interface. A pure router 547 will reject that configuration, and the Mobile Router needs to act as 548 a bridge to use it. In order to deploy the aggregated Home Network 549 model, one must check whether that support is available in the Mobile 550 Routers if returning Home is required. 552 7. Virtual Home Network 554 7.1 Configuration 556 The Home Link can be configured on the Home Agent on a virtual link, 557 in which case there's no physical Home Link for Mobile Routers to 558 return Home to, or for Home Agents to discover each others and 559 perform the ND level interactions on, as described in Mobile IPv6 560 [7]. 562 /48 e.g.: A:B:C::/48 563 HA 564 | /64 A:B:C::/64 565 --+-----+--+- . -+- . -+-- 566 | | | | 567 MR1 MR2 MRi MRN 568 /64 /64 /64 /64 A:B:C:i::/64 0 < i <= N 570 Figure 5: Virtual Home Network 572 The Extended Home Network and the Aggregated Home Network models can 573 be adapted for virtual links. 575 As in the case of a physical link, the Home Address of a Mobile 576 router can be constructed based on a dedicated subnet of the Home 577 Prefix or one of the Mobile Router MNPs. 579 Note that since the Home Address is never checked for DAD, it makes 580 the configuration easier to take it from the MNP as opposed to a 581 specific subnet. 583 There are certain advantages to making the Home Link a virtual link: 585 A virtual link may not experience any disruption related to 586 physical maintenance or to hardware problems, so it is more 587 available than a physical link. The high availability of the Home 588 Link is critical for the mobility service. 590 The Home Agent does not have to defend the Mobile Router's Home 591 Address through Proxy Neighbor Discovery. The Home Agent does not 592 also have to perform Duplicate Address Detection (DAD) for the 593 Mobile Router's Home Address when it receives a Binding Update 594 from the Mobile Router. 596 The Mobile Router does not have to implement the Returning Home 597 procedure (section 11.5.4 of Mobile IPv6 [7]). 599 There are also some drawbacks to the Virtual Home Link approach: 601 RFC 3775 [7] and RFC 3963 [8] do not provide the specific support 602 for a Mobile Node to emulate returning Home on a Virtual Home 603 Network. In particular, in the case of NEMO, the routing 604 information from the Mobile Router being injected on the IGP might 605 adversely affect IPv6 route aggregation on the Home Network. 607 There can be only one Home Agent since Mobile IPv6 relies on 608 Neighbor Discovery on the Home Link for other Home Agent discovery 609 and for Duplicate Address Detection. 611 The Home Agent must maintain a Binding Cache entry for a Mobile 612 Router and forwarding state for its Mobile Network even when the 613 Mobile Router is directly connected to it. All traffic to and 614 from the Mobile Network is sent through the bi-directional tunnel 615 regardless of the Mobile Router location. This results in a 616 tunneling overhead even though the Mobile Router is connected to 617 the Home Network. 619 Suggestions on how to perform an equivalent of returning Home on a 620 Virtual Home Network have been proposed, but this topic is outside of 621 the scope of this document. 623 7.2 Applicability 625 NEMO operations rely on ND extensions over the Home Link for the Home 626 Agent to Home Agent communication. 628 Making the Home Link virtual bars the deployment of multiple Home 629 Agents, which may be desirable for reasons of load balancing. Please 630 refer to the NEMO multihoming issues [13] for more on this. 632 Yet, for a deployment where a single Home Agent is enough, making the 633 Home Link virtual reduces the vulnerability to some attacks and to 634 some hardware failures, while making the Home Agent operation faster. 636 Note that NEMO basic does not mandate the support of Virtual Home 637 Networks. 639 8. Mobile Home 641 8.1 Configuration 643 In this arrangement, there is a bitwise hierarchy of Home Networks. 644 A global Home Network is advertised to the infrastructure by a head 645 Home Agent(s) and further subnetted into Mobile Networks. As a 646 result, only the Home Agent(s) responsible for the most global 647 (shortest prefix) aggregation receive all the packets for all the 648 MNPs, which are leaves in the hierarchy tree. 650 Each subnet is owned by a Mobile Router that registers it in a NEMO 651 fashion while acting as a Home Agent for that network This Mobile 652 Router is at Home at the upper level of hierarchy. This 653 configuration is referred to as Mobile Home. 655 An example of this is the Cab Co configuration. Cab Co is a taxi 656 Company that uses a /32 prefix for its Home Network, this prefix 657 being advertised by the company Head Quarters. Regional offices are 658 deployed around the coutry. Even though these regional offices are 659 relatively stable in terms of location and prefix requirement -say 660 this changes every few years- making them mobile allows a simpler 661 management when a move has to take place, or should the ISP service 662 change. 664 To illustrate this configuration, we make up the prefixes to reflect 665 their role, like CAB:C0::/32 for the Home Network: 667 global Home Network CAB:C0::/32 advertised by HQ 668 <------------------------------------------------------------------> 670 HQ Extended Home Net Mobile Home for SFO office 671 (casa) 672 CAB:C0:CA5A::/48 CAB:C0:5F0::/48 673 <----------------------------> ... <-------------------------------> 674 | 675 Home for offices HQ | 676 CAB:C0:CA5A:CA5A::/64 MN | 677 <----------------------><----> | 678 CAB:C0:CA5A:CA5A::CA5A | 679 CAB:C0:CA5A:CA5A::CA5B | 680 are HAs on link with for each office a route like | 681 | 682 CAB:C0:CA5A:CA5A::5F0 <---------------------- via 683 is the Home addr 684 of SFO office 686 Figure 6: CAB Company HQ configuration 688 Finally, each regional office owns a number of taxis, each one 689 equipped with a mobile router and an associated /64 prefix. 691 For each Office, say San Francisco (SFO) as an example: 693 Mobile Home Network CAB:C0:5F0::/48 owned by SFO office 694 <------------------------------------------------------------------> 696 SFO Home Network Mobile Networks for taxis 697 for taxis <---------------------...---------------------> 698 CAB:C0:5F0:5F0::/64 CAB:C0:5F0:CAB1::/64 CAB:C0:5F0:....::/64 699 <-------------------><-------------------> ... <-------------------> 700 CAB:C0:5F0:5F0::5F0 | 701 is HA on link with for | 702 each taxi a route like | 703 | 704 CAB:C0:5F0:5F0::CAB1 <------ via 705 is the Home Address 706 of CAB 1 708 Figure 7: CAB Company regional configuration 710 Note that this is a hierarchy in terms of MR-HA relationship, which 711 may not be reflected in the physical arrangement of nodes at a given 712 point of time. For instance, in the Cab Co case, some SFO Cabs might 713 attach to any hot spot or Cab Co office in a different city, and the 714 SFO office might be at Home if it is co-located with the 715 Headquarters. But note that SFO should never attach to one of its 716 own Cabs. This would create a stalemate situation, as documented in 717 the NEMO RO problem statement [11]. 719 But it is also possible to reflect the organizational hierarchy in a 720 moving cloud of Mobile Routers. If a Mobile Home Agent acts as 721 root-MR for a nested configuration of its own Mobile Routers, then 722 the communication between Mobile Routers is confined within the 723 nested structure. 725 This can be illustrated in the case of a fleet at sea. Assuming that 726 SFO is a communication ship of a fleet, using a satellite link to 727 join the infrastructure, and that the cabs are Mobile Routers 728 installed on smaller ships, equipped with low range radios. 730 If SFO is also the root-MR of a nested structure of its own cabs, the 731 communication between cabs is relayed by SFO and does not require the 732 satellite link. As for traffic to the outside of the nested NEMO, 733 SFO recursively terminates the nested tunnels from its cabs and 734 reencapsulates all the packets between the nested cloud and 735 correspondents in the infrastructure in a single tunnel to CA5A. As a 736 result, the unwanted effect of nesting of tunnels is avoided over the 737 Internet part of the packet path. 739 8.2 Applicability 741 This complex topology applies to a large distributed fleet, mostly if 742 there is a single interchange point with the internet (e.g. a NAT or 743 a socks farm) where the super Home Agent could be located. 745 One specific benefit is that when 2 Mobile Routers travel together 746 with a common Home Agent, the traffic between the 2 is not 747 necessarily routed via the infrastructure, but can stay confined 748 within the mobile cloud, the Mobile Home Agent acting as a rendez- 749 vous point between the Mobile Routers. This applies particularly 750 well for a fleet at sea when the long haul access may be as expensive 751 as a satellite link. 753 9. IANA considerations 755 This document does not require any IANA action. 757 10. Security Considerations 759 This document only explains how a home network can be deployed to 760 support Mobile Routers and does not introduce any additional security 761 concerns. Please see [RFC3963] for security considerations for the 762 NEMO Basic Support protocol. 764 11. Changes 766 An issue list is maintained at http://www.mobilenetworks.org/ 767 ~pthubert/draft-ietf-nemo-home-network-models-issues.html . 769 11.1 Changes from version 00 to 01 771 Removed terminology (moved to the Nemo terminology). 773 Added an applicability statement for all documented cases 775 11.2 Changes from version 01 to 02 777 Issue 1: Editorial 779 Issue 2: Added a caveat part in Extended and Aggregated Home Network 780 sections. Also added a MIP Home Network section prior to those. 782 Issue 4: Added a subsection to the Extended Home Network case for the 783 case when the mr takes a home address from its MNP 785 11.3 Changes from version 02 to 03 787 Issue 5: Editorial fixes. 789 11.4 Changes from version 03 to 04 791 Issue 6: Pass idnits. Thanks Henrik for this great tool :) 793 11.5 Changes from version 04 to 05 795 Issue 7: Virtual Home discussion 797 Issue 8: Whether to recommend not to form a Home Address from MNP in 798 Extended HN. 800 Jari and Henrik's reviews Editorial changes 802 11.6 Changes from version 05 to 06 (IESG review) 803 Issue 9: "Alternatives based on a routing protocol or ICMP redirect 804 may apply in some cases." is not clear 806 Issue 10: in a number of places text says "present in ... 807 implementations" .. but what about the specifications?. 809 Other review comments Editorial changes 811 12. Acknowledgements 813 The authors wish to thank: 815 Erik Nordmark, Jari Arkko, Henrik Levkowetz, Scott Hollenbeck, Ted 816 Hardie, David Kessens, Pekka Savola, Kent Leung, Thierry Ernst, TJ 817 Kniveton, Patrick Wetterwald, Alexandru Petrescu and David Binet for 818 their contributions. 820 13. References 822 13.1 normative reference 824 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 825 Levels", BCP 14, RFC 2119, March 1997. 827 [2] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) 828 Specification", RFC 2460, December 1998. 830 [3] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery 831 for IP Version 6 (IPv6)", RFC 2461, December 1998. 833 [4] Thomson, S. and T. Narten, "IPv6 Stateless Address 834 Autoconfiguration", RFC 2462, December 1998. 836 [5] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) 837 Addressing Architecture", RFC 3513, April 2003. 839 [6] Manner, J. and M. Kojo, "Mobility Related Terminology", 840 RFC 3753, June 2004. 842 [7] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in 843 IPv6", RFC 3775, June 2004. 845 [8] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, 846 "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, 847 January 2005. 849 [9] Ernst, T. and H. Lach, "Network Mobility Support Terminology", 850 draft-ietf-nemo-terminology-04 (work in progress), 851 October 2005. 853 [10] Ernst, T., "Network Mobility Support Goals and Requirements", 854 draft-ietf-nemo-requirements-05 (work in progress), 855 October 2005. 857 13.2 informative reference 859 [11] Ng, C., "Network Mobility Route Optimization Problem 860 Statement", draft-ietf-nemo-ro-problem-statement-02 (work in 861 progress), December 2005. 863 [12] Thaler, D., "Neighbor Discovery Proxies (ND Proxy)", 864 draft-ietf-ipv6-ndproxy-04 (work in progress), October 2005. 866 [13] Ng, C., "Analysis of Multihoming in Network Mobility Support", 867 draft-ietf-nemo-multihoming-issues-04 (work in progress), 868 October 2005. 870 Authors' Addresses 872 Pascal Thubert 873 Cisco Systems 874 Village d'Entreprises Green Side 875 400, Avenue de Roumanille 876 Batiment T3 877 Biot - Sophia Antipolis 06410 878 FRANCE 880 Phone: +33 4 97 23 26 34 881 Email: pthubert@cisco.com 883 Ryuji Wakikawa 884 Keio University and WIDE 885 5322 Endo Fujisawa Kanagawa 886 252-8520 887 JAPAN 889 Email: ryuji@sfc.wide.ad.jp 891 Vijay Devarapalli 892 Nokia Research Center 893 313 Fairchild Drive 894 Mountain View, CA 94043 895 USA 897 Email: vijay.devarapalli@nokia.com 899 Intellectual Property Statement 901 The IETF takes no position regarding the validity or scope of any 902 Intellectual Property Rights or other rights that might be claimed to 903 pertain to the implementation or use of the technology described in 904 this document or the extent to which any license under such rights 905 might or might not be available; nor does it represent that it has 906 made any independent effort to identify any such rights. Information 907 on the procedures with respect to rights in RFC documents can be 908 found in BCP 78 and BCP 79. 910 Copies of IPR disclosures made to the IETF Secretariat and any 911 assurances of licenses to be made available, or the result of an 912 attempt made to obtain a general license or permission for the use of 913 such proprietary rights by implementers or users of this 914 specification can be obtained from the IETF on-line IPR repository at 915 http://www.ietf.org/ipr. 917 The IETF invites any interested party to bring to its attention any 918 copyrights, patents or patent applications, or other proprietary 919 rights that may cover technology that may be required to implement 920 this standard. Please address the information to the IETF at 921 ietf-ipr@ietf.org. 923 Disclaimer of Validity 925 This document and the information contained herein are provided on an 926 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 927 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 928 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 929 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 930 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 931 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 933 Copyright Statement 935 Copyright (C) The Internet Society (2006). This document is subject 936 to the rights, licenses and restrictions contained in BCP 78, and 937 except as set forth therein, the authors retain all their rights. 939 Acknowledgment 941 Funding for the RFC Editor function is currently provided by the 942 Internet Society.