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