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