idnits 2.17.1 draft-ietf-nemo-multihoming-issues-00.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 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1332. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1309. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1316. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1322. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 1338), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 39. ** 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. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 1028 has weird spacing: '...chanism to te...' -- 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 (July 12, 2004) is 7221 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) == Outdated reference: A later version (-06) exists of draft-ietf-nemo-requirements-02 ** Downref: Normative reference to an Informational draft: draft-ietf-nemo-requirements (ref. '1') ** Downref: Normative reference to an Informational RFC: RFC 3753 (ref. '2') == Outdated reference: A later version (-06) exists of draft-ietf-nemo-terminology-01 ** Downref: Normative reference to an Informational draft: draft-ietf-nemo-terminology (ref. '3') ** Obsolete normative reference: RFC 3775 (ref. '5') (Obsoleted by RFC 6275) -- Possible downref: Normative reference to a draft: ref. '6' == Outdated reference: A later version (-05) exists of draft-montavont-mobileip-multihoming-pb-statement-01 -- Possible downref: Normative reference to a draft: ref. '7' -- Possible downref: Non-RFC (?) normative reference: ref. '8' -- Possible downref: Non-RFC (?) normative reference: ref. '9' -- No information found for draft-montavont-mobileip-mmi - is the name correct? -- Possible downref: Normative reference to a draft: ref. '10' ** Obsolete normative reference: RFC 2461 (ref. '11') (Obsoleted by RFC 4861) == Outdated reference: A later version (-07) exists of draft-ietf-ipv6-router-selection-04 ** Obsolete normative reference: RFC 3484 (ref. '13') (Obsoleted by RFC 6724) -- Possible downref: Normative reference to a draft: ref. '14' -- Possible downref: Normative reference to a draft: ref. '15' -- Possible downref: Normative reference to a draft: ref. '16' -- No information found for draft-koh-mip6-nemo-dhap - is the name correct? -- Possible downref: Normative reference to a draft: ref. '17' ** Downref: Normative reference to an Informational RFC: RFC 3769 (ref. '18') == Outdated reference: A later version (-02) exists of draft-droms-nemo-dhcpv6-pd-01 -- Possible downref: Normative reference to a draft: ref. '19' == Outdated reference: A later version (-05) exists of draft-wakikawa-mobileip-multiplecoa-02 -- Possible downref: Normative reference to a draft: ref. '20' == Outdated reference: A later version (-02) exists of draft-kumazawa-nemo-tbdnd-00 -- Possible downref: Normative reference to a draft: ref. '21' -- Possible downref: Normative reference to a draft: ref. '22' Summary: 16 errors (**), 0 flaws (~~), 10 warnings (==), 22 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 NEMO Working Group C. Ng 2 Internet-Draft Panasonic Singapore Labs 3 Expires: January 10, 2005 E. Paik 4 Seoul National University 5 T. Ernst 6 WIDE at Keio University 7 July 12, 2004 9 Analysis of Multihoming in Network Mobility Support 10 draft-ietf-nemo-multihoming-issues-00 12 Status of this Memo 14 By submitting this Internet-Draft, I certify that any applicable 15 patent or other IPR claims of which I am aware have been disclosed, 16 and any of which I become aware will be disclosed, in accordance with 17 RFC 3668. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as 22 Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on January 10, 2005. 37 Copyright Notice 39 Copyright (C) The Internet Society (2004). All Rights Reserved. 41 Abstract 43 This document is an analysis of multihoming in the context of network 44 mobility (NEMO). As there are many situations in which mobile 45 networks may be multihomed, a taxonomy is proposed to classify the 46 possible configurations. We also describe possible deployment 47 scenarios and we attempt to identify issues that arise when mobile 48 networks are multihomed while mobility supports is taken care by NEMO 49 Basic Support. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 2. Classification . . . . . . . . . . . . . . . . . . . . . . . . 6 56 2.1 (1,1,1): Single MR, Single HA, Single NEMO-Prefix . . . . 7 57 2.2 (1,1,n): Single MR, Single HA, Multiple NEMO-Prefixes . . 7 58 2.3 (1,n,1): Single MR, Multiple HAs, Single NEMO-Prefix . . . 8 59 2.4 (1,n,n): Single MR, Multiple HAs, Multiple 60 NEMO-Prefixes . . . . . . . . . . . . . . . . . . . . . . 8 61 2.5 (n,1,1): Multiple MRs, Single HA, Single NEMO-Prefix . . . 9 62 2.6 (n,1,n): Multiple MRs, Single HA, Multiple 63 NEMO-Prefixes . . . . . . . . . . . . . . . . . . . . . . 9 64 2.7 (n,n,1): Multiple MRs, Multiple HAs, Single NEMO-Prefix . 10 65 2.8 (n,n,n): Multiple MRs, Multiple HAs, Multiple 66 NEMO-Prefixes . . . . . . . . . . . . . . . . . . . . . . 11 68 3. Deployment Scenarios and Prerequisites . . . . . . . . . . . . 12 69 3.1 Deployment Scenarios . . . . . . . . . . . . . . . . . . . 12 70 3.2 Prerequisites . . . . . . . . . . . . . . . . . . . . . . 13 72 4. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 15 73 4.1 Path Survival . . . . . . . . . . . . . . . . . . . . . . 15 74 4.2 Path Selection . . . . . . . . . . . . . . . . . . . . . . 15 75 4.3 Ingress Filtering . . . . . . . . . . . . . . . . . . . . 16 76 4.4 Failure Detection . . . . . . . . . . . . . . . . . . . . 17 77 4.5 HA Synchronization . . . . . . . . . . . . . . . . . . . . 18 78 4.6 MR Synchronization . . . . . . . . . . . . . . . . . . . . 18 79 4.7 Prefix Delegation . . . . . . . . . . . . . . . . . . . . 19 80 4.8 Multiple Bindings/Registrations . . . . . . . . . . . . . 19 81 4.9 Source Address Selection . . . . . . . . . . . . . . . . . 19 82 4.10 Impact on the Routing Infrastructure . . . . . . . . . . . 20 83 4.11 Nested Mobile Networks . . . . . . . . . . . . . . . . . . 20 84 4.12 Split Mobile Networks . . . . . . . . . . . . . . . . . . 20 86 5. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 21 88 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21 90 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 24 94 A. Alternative Classifications Approach . . . . . . . . . . . . . 25 95 A.1 Ownership-Oriented Approach . . . . . . . . . . . . . . . 25 96 A.1.1 ISP Model . . . . . . . . . . . . . . . . . . . . . . 25 97 A.1.2 Subscriber/Provider Model . . . . . . . . . . . . . . 26 98 A.2 Problem-Oriented Approach . . . . . . . . . . . . . . . . 28 100 B. Nested Tunneling for Fault Tolerance . . . . . . . . . . . . . 29 101 B.1 Detecting Presence of Alternate Routes . . . . . . . . . . 29 102 B.2 Re-Establishment of Bi-Directional Tunnels . . . . . . . . 29 103 B.2.1 Using Alternate Egress Interface . . . . . . . . . . . 30 104 B.2.2 Using Alternate Mobile Router . . . . . . . . . . . . 30 105 B.3 To Avoid Tunneling Loop . . . . . . . . . . . . . . . . . 31 107 C. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 32 109 Intellectual Property and Copyright Statements . . . . . . . . 33 111 1. Introduction 113 The goals and objectives of Network Mobility Support (NEMO) are 114 identified in [1] while the terminology is being described in [2] and 115 [3]. NEMO Basic Support [4] is the solution proposed by the NEMO 116 Working Group to provide continuous Internet connectivity to nodes 117 located in a mobile network. This solutions basically solves the 118 problem by setting up bi-directional tunnels between the mobile 119 routers (MRs) connecting the mobile network to the Internet and their 120 respective Home Agents (HAs), much how this is done in Mobile IPv6 121 [5], the solution for host mobility. NEMO Basic Support is 122 transparent to nodes located behind the mobile router (i.e. the 123 mobile network nodes, or MNNs) and as such doesn't require MNNs to 124 take any action in the mobility management. 126 We note that mobile networks are typically connected by means of 127 wireless and thus less reliable links. In addition, there could be 128 many nodes behind the MR, so a loss of connectivity or a failure to 129 connect to the Internet has a more significant impact than for a 130 single node. Real-life scenarios as illustrated in [6] demonstrate 131 that providing a permanent access to mobile networks such as vehicles 132 typically require the use of several interfaces and technologies 133 since the mobile network may be moving in distant geographical 134 locations where different access technologies are provided and 135 governed by distinct access control policies. 137 The purpose of this memo is to investigate issues related to such a 138 bi-directional tunneling mechanism when mobile networks are 139 multihomed, i.e. when there is more than one point of attachment 140 between the mobile network and the Internet. This arises when the 141 mobile network is either associated with multiple HAs, when it has 142 multiple MRs, or when an MR has multiple egress interfaces (see 143 definitions in [3]). 145 As specified by R.12 in section 5 of [1], the NEMO WG must ensure 146 that NEMO Basic Support does not prevent mobile networks to be 147 multihomed. Using NEMO Basic Support, this translates into having 148 multiple bi-directional tunnels between the mobile network and its 149 HA(s), and may result into multiple NEMO-Prefixes being advertised to 150 the MNNs. However, NEMO Basic Support does not specify any 151 particular mechanism to manage multiple bi-directional tunnels. The 152 objective of this memo is thus three-folds: 154 o to capture issues for deploying a multihomed mobile network, 156 o to identify which multihoming configurations are useful, 158 o to identify issues that may prevent useful multihomed 159 configurations to be supported under the operation of NEMO Basic 160 Support. It doesn't mean that those not supported will not work 161 with NEMO Basic Support, just that it is up to the implementors to 162 make it work (hopefully issues discussed in this memo will be 163 helpful to these implementors). 165 For doing so, a taxonomy to classify the possible multihomed 166 configurations is described in Section 2. Deployment scenarios, 167 their benefits, and requirements to meet these benefits are 168 illustrated in Section 3. Following this, we study the general 169 issues in Section 4, and we conclude with an evaluation of NEMO Basic 170 Support for multihomed configurations. Alternative classifications 171 are outlined in the Appendix. 173 In order to understand this memo, the reader is expected to be 174 familiar with the above cited documents, i.e. with the NEMO 175 terminology as defined in [2] (section 3) and [3], Goals and Benefits 176 of Multihoming [6], Goals and Requirements of Network Mobility 177 Support [1], and the NEMO Basic Support specification [4]. 179 Note that goals and benefits for multihoming as discussed in [6] is 180 applicable to fixed nodes, mobile nodes, fixed networks and mobile 181 networks, so we won't re-state the motivations in the present memo. 183 2. Classification 185 Various discussions on the topic of multihoming issues in NEMO have 186 been carried out on the mailing list and at IETF meetings. As there 187 are several configurations in which mobile networks are multihomed, 188 there is a need to classify them into a clearly defined taxonomy. 189 This can be done in various ways. Three approaches have been 190 proposed on the NEMO mailing list. These are, namely, (i) the 191 Configuration-Oriented Approach, (ii) the Ownership-Oriented 192 Approach, and (iii) the Problem-Oriented Approach. As the WG 193 consensus seems to have converged to the Configuration-Oriented 194 Approach, we only describe this approach here. The other two 195 approaches are outlined in Appendix A.1 and Appendix A.2. 197 The Configuration-Oriented Approach 199 Multihomed configurations can be classified depending on how many 200 mobile routers are present, how many egress interfaces, Care-of 201 Address (CoA) and Home Addresses (HoA) the mobile routers have, how 202 many prefixes (NEMO-prefixes) are advertised to the mobile network 203 nodes, etc. For doing so, we use three key parameters 204 differentiating different multihomed configurations. With these 205 parameters, we can refer to each configuration by the 3-tuple 206 (x,y,z), where 'x', 'y', 'z' are defined as follows: 208 o 'x' indicates the number of MRs where: 210 x=1 implies a mobile network has only a single MR, presumably 211 multihomed. 213 x=N implies a mobile network has more than one MR. 215 o 'y' indicates the number of HAs associated with the entire mobile 216 network, where: 218 y=1 implies that a single HA is assigned to the mobile network. 220 y=N implies that multiple HAs (possibly in different 221 administrative domains) are assigned to the mobile network. 223 o 'z' indicates the number of NEMO-prefixes announced to MNNs, 224 where: 226 z=1 implies that a single NEMO-prefix is advertised to the MNNs. 228 z=N implies that multiple NEMO-prefixes are advertised to the 229 MNNs. 231 It can be seen that the above three parameters are fairly orthogonal 232 to one another. Thus different values of 'x', 'y' and 'z' give rise 233 to different combinations of the 3-tuple (x,y,z). As described in 234 the sub-sections below, a total of 8 possible configurations can be 235 identified. 237 One thing the reader has to keep in mind is that in each of the 238 following 8 cases, the MR may be multihomed if either (i) multiple 239 prefixes are advertised on the home link, (ii) multiple prefixes are 240 advertised on the visited link, or (iii) the MR is equipped with 241 multiple interfaces. In such a case, the MR would have a combination 242 of Home Address / Care-of Address pairs. Issues pertaining to a 243 multihomed MR are also addressed in the companion document [7]. 245 A simplified analysis of multihoming configuration in NEMO Basic 246 Support using the same classification can be found in [8]. 248 2.1 (1,1,1): Single MR, Single HA, Single NEMO-Prefix 250 The (1,1,1) mobile network has only one MR advertising a single 251 NEMO-prefix. In addition, the MR is associated with only one HA at 252 any one time. A bi-directional tunnel may be established between 253 each pair of Home Address / Care-of address if the MR is itself 254 multihomed. 256 The MR may be multihomed and MNNs are (usually) not multihomed since 257 they would configure a single address on the single NEMO-prefix 258 announced on the link they are attached to. 260 _____ 261 _ p _ | | 262 |_|-|<-_ |-|_|-| |-| _ 263 _ |-|_|=| |_____| | _ |-|_| 264 |_|-| | |-|_|-| 265 | 266 MNNs MR AR Internet AR HA 268 Figure 1: (1,1,1): 1 MR, 1 HA, 1 NEMO-prefix 270 2.2 (1,1,n): Single MR, Single HA, Multiple NEMO-Prefixes 272 The (1,1,n) mobile network has only one MR, which is associated to 273 only one HA at any one time. However, two or more NEMO-prefixes are 274 advertised to the mobile network nodes. 276 The MR may be itself multihomed, and MNNs are multihomed if several 277 NEMO-Prefixes are advertised on the link they are attached to. If 278 that conditions holds, MNNs would configure an address with each 279 NEMO-prefix announced on the link. 281 _____ 282 _ p1,p2 _ | | 283 |_|-|<-_ |-|_|-| |-| _ 284 _ |-|_|=| |_____| | _ |-|_| 285 |_|-| | |-|_|-| 286 | 287 MNNs MR AR Internet AR HA 289 Figure 2: (1,1,n): 1 MR, 1 HA, multiple NEMO-prefixes 291 2.3 (1,n,1): Single MR, Multiple HAs, Single NEMO-Prefix 293 The (1,n,1) mobile network has only one MR advertising a single 294 NEMO-prefix. The MR, however, is associated to multiple HAs, 295 possibly one HA per Home Address, or one HA per egress interface. No 296 assumption is made on whether or not the HAs belongs to the same 297 administrative domain (it may be justified to locate HAs in distinct 298 ISPs according to [Section 5.1.2. Possibly Multihomed, An Identical 299 Prefix from a Different Origin] [9]) 301 The MR may be multihomed whereas MNNs are (usually) not multihomed 302 since they would configure a single address on the single NEMO-prefix 303 announced on the link they are attached to. 305 AR HA2 306 _ | 307 |-|_|-| _ 308 _____ | |-|_| 309 _ p _ | |-| 310 |_|-|<-_ |-|_|-| | 311 _ |-|_|=| |_____|-| _ 312 |_|-| | | _ |-|_| 313 |-|_|-| 314 | 315 MNNs MR AR Internet AR HA1 317 Figure 3: (1,n,1): 1 MR, multiple HAs, 1 NEMO-prefix 319 2.4 (1,n,n): Single MR, Multiple HAs, Multiple NEMO-Prefixes 321 The (1,n,n) mobile network has only one MR. However, the MR is 322 associated with multiple HAs, possibly one per Home Address (or one 323 HA per egress interface), and the MR advertises more than one 324 NEMO-prefix on its ingress interfaces. No assumption is made on 325 whether or not the HAs belongs to the same administrative domain. 327 The MR may be multihomed, and the MNNs are generally multihomed since 328 they would configure an address on each NEMO-prefix announced on the 329 link they are attached to. 331 AR HA2 332 _ | _ 333 _____ |-|_|-|-|_| 334 _ p1,p2 _ | |-| | 335 |_|-|<-_ |-|_|-| | _ 336 _ |-|_|=| |_____|-| _ |-|_| 337 |_|-| | |-|_|-| 338 | | 339 MNNs MR AR Internet AR HA1 341 Figure 4: (1,n,n): 1 MR, multiple HAs, multiple NEMO-prefixes 343 2.5 (n,1,1): Multiple MRs, Single HA, Single NEMO-Prefix 345 The (n,1,1) mobile network has more than one MR advertising global 346 routes. These MRs, however, advertise the same NEMO-prefix and are 347 associated with the same HA. 349 Each MR may be itself multihomed, whereas MNNs are (usually) not 350 multihomed since they would configure a single address on the single 351 NEMO-prefix announced on the link they are attached to. 353 MR2 354 p<-_ | 355 _ |-|_|-| _____ 356 |_|-| |-| | 357 _ | | |-| _ 358 |_|-| _ |-|_____| | _ |-|_| 359 |-|_|-| |-|_|-| 360 p<- | | 361 MNNs MR1 Internet AR HA 363 Figure 5: (n,1,1): Multiple MRs, 1 HA, 1 NEMO-prefix 365 2.6 (n,1,n): Multiple MRs, Single HA, Multiple NEMO-Prefixes 367 The (n,1,n) mobile network has more than one MR advertising different 368 global routes and different NEMO-prefixes. However, these MRs are 369 associated to the same HA. 371 Each MR may be itself multihomed, and MNNs are generally multihomed 372 since they would configure an address on each NEMO-prefix announced 373 on the link they are attached to. 375 MR2 376 p2<-_ | 377 _ |-|_|-| _____ 378 |_|-| |-| | 379 _ | | |-| _ 380 |_|-| _ |-|_____| | _ |-|_| 381 |-|_|-| |-|_|-| 382 p1<- | | 383 MNNs MR1 Internet AR HA 385 Figure 6: (n,1,n): Multiple MRs, 1 HA, multiple NEMO-prefixes 387 2.7 (n,n,1): Multiple MRs, Multiple HAs, Single NEMO-Prefix 389 The (n,n,1) mobile network has more than one MR advertising different 390 global routes. The mobile network is associated with multiple HAs at 391 any one time. No assumptions are made on whether or not the HAs 392 belongs to the same administrative domain. However, the MRs 393 advertises the same NEMO-prefix. 395 Each MR may be itself multihomed whereas MNNs are (usually) not 396 multihomed since they would configure a single address on the single 397 NEMO-prefix announced on the link they are attached to. 399 MR2 AR HA2 400 p _ | 401 <-_ | |-|_|-| _ 402 _ |-|_|-| _____ | |-|_| 403 |_|-| |-| |-| 404 _ | | | 405 |_|-| _ |-|_____|-| _ 406 |-|_|-| | _ |-|_| 407 <- | |-|_|-| 408 p | 409 MNNs MR1 Internet AR HA1 411 Figure 7: (n,n,1): Multiple MRs, Multiple HAs, 1 NEMO-prefix 413 2.8 (n,n,n): Multiple MRs, Multiple HAs, Multiple NEMO-Prefixes 415 The (n,n,n) mobile network has multiple MRs advertising different 416 global routes and different NEMO-prefixes. The mobile network is 417 associated with more than one HA at any one time. No assumptions is 418 made on whether or not the HA belongs to the same administrative 419 domain. 421 Each MR may be itself multihomed and MNNs are generally multihomed 422 since they would configure an address on each NEMO-prefix announced 423 on the link they are attached to 425 MR2 AR HA2 426 p2 _ | 427 <-_ | |-|_|-| _ 428 _ |-|_|-| _____ | |-|_| 429 |_|-| |-| |-| 430 _ | | | 431 |_|-| _ |-|_____|-| _ 432 |-|_|-| | _ |-|_| 433 <- | |-|_|-| 434 p1 | 435 MNNs MR1 Internet AR HA1 437 Figure 8: (n,n,n): Multiple MRs, HAs, and NEMO-prefixes 439 3. Deployment Scenarios and Prerequisites 441 The following generic goals and benefits of multihoming are discussed 442 in a companion document [6]: 444 1. Permanent and Ubiquitous Access 446 2. Redundancy/Fault-Recovery 448 3. Load Sharing 450 4. Load Balancing 452 5. Preference Settings 454 These benefits are now illustrated from a NEMO perspective with a 455 typical instance scenario for each case in the taxonomy. We then 456 discuss the prerequisites to fulfill these. 458 3.1 Deployment Scenarios 460 x=1: Multihomed mobile network with a single MR 462 o Example: an MR with dual/multiple access interfaces (e.g. 463 802.11 and GPRS capabilities). This is a S/P-(1,1,*) if both 464 accesses are subscribed to the same ISP. If the two accesses 465 are offered by independent ISPs, this is a S/mP-(1,n,n) [for 466 the meaning of this abbreviation, see Appendix A.1]. 468 Benefits: Ubiquity, Redundancy/Fault-Recovery 470 x=N: Multihomed mobile networks with multiple MRs 472 o Example 1: a train with one MR in each car, all served by the 473 same HA, thus a (n,1,*). Alternatively, the train company 474 might be forced to use different ISP when the train go to 475 different locations, thus it is a (n,n,n). 477 Benefits: Load Sharing 479 o Example 2: W-PAN with a GPRS_enabled phone and a WiFi-enabled 480 PDA. This is a S/mP-(n,n,n) if the two access technologies are 481 subscribed separately. 483 Benefits: Ubiquity, Redundancy/Fault-Recovery 485 y=1: Multihomed mobile networks with a single HA 487 o Most single ISP cases in above examples. 489 y=N: Multihomed mobile networks with multiple HAs 491 o Most multiple ISP cases in above examples. 493 o Example: a transatlantic flight with a HA in each continent. 494 This is a (1,n,1) network if there is only one MR. 496 Benefits: Ubiquity (reduced delay, shortest path) 498 z=1: Multihomed mobile networks with a single NEMO-prefix 500 o Most single ISP cases in above examples. 502 z=N: Multihomed mobile networks with multiple NEMO-prefixes 504 o Most multiple ISP cases in above examples. 506 o Example: a car with a prefix taken from home (personal traffic 507 transit on this prefix and is paid by the owner) and one that 508 belongs to the car manufacturer (maintenance traffic is paid by 509 the car-manufacturer). This will typically be a (1,1,n). 511 Benefits: preference settings 513 3.2 Prerequisites 515 In this section, we try to define the requirements in order to 516 fulfill the expected multihoming benefits as detailed in [6]. 518 At least one bi-directional tunnel must be available at any point in 519 time between the mobile network and the fixed network to meet all 520 expectations. But for most goals to be effective, multiple tunnels 521 must be maintained simultaneously: 523 o Permanent and Ubiquitous Access: 525 At least one bi-directional tunnel must be available at any point 526 in time. 528 o Redundancy and Fault-Recovery: 530 Both the inbound and outbound traffic must be transmitted or 531 diverted over another bi-directional tunnel once a bi-directional 532 tunnel is broken or disrupted. 534 o Load Sharing and Load Balancing: 536 Multiple tunnels must be maintained simultaneously. 538 o Preference Settings: 540 A mechanism must be provided to the user or the application to 541 decide which of the available bi-directional tunnel should be 542 used. 544 4. Problem Statement 546 In order to reach the multihoming benefits, multiple tunnels may be 547 maintained simultaneously (e.g. load balancing, load sharing) or not 548 (e.g. redundancy) between the mobile network and the fixed network. 549 In some cases, it may be necessary to divert packets from a (perhaps 550 failed) bi-directional tunnel to an alternative (perhaps newly 551 established) bi-directional tunnel (i.e. for matters of fault 552 recovery, preferences), or to split traffic between multiple tunnel 553 (load sharing, load balancing). 555 For doing so, the issues discussed below must be addressed, 556 preferably dynamically. For each issue, we also investigate 557 potential ways to solve the problem. 559 4.1 Path Survival 561 Internet connectivity is guaranteed for all MNNs as long as at least 562 one bi-directional tunnel is maintained between the mobile network 563 and the fixed Internet. When an alternative tunnel must be found to 564 substitute for the failed one, the loss of one tunnel to the Internet 565 may result in broken sessions. In this case, new transport sessions 566 will have to be established over the alternate tunnel if no mechanism 567 is provided to make this change transparent at layers above layer 3. 569 In the (1,1,1) case specifically, packets are always transmitted to/ 570 from the same MR's ingress interface, i.e. independently of MR's 571 links connectivity status. The tunnel can be changed transparently 572 to the MNNs if mechanisms such as those studied in [10] are brought 573 to the MR. 575 4.2 Path Selection 577 When multiple bi-directional tunnels are available and possibly used 578 simultaneously, the mode of operation may be either primary-secondary 579 (one tunnel is precedent over the others and used as the default 580 tunnel, while the other serves as a back-up) or peer-to-peer (no 581 tunnel has precedence over one another, they are used with the same 582 priority). This questions which bi-directional tunnel would be 583 selected, and based on which parameter (e.g. type of flow that goes 584 into/out of the mobile network). 586 A dynamic path selection mechanism is thus needed so that this path 587 could be selected by: 589 o The HA: it should be able to select the path based on some 590 information recorded in the binding cache. 592 o The MR: it should be able to select the path based on router 593 advertisements received on both its egress interfaces or on its 594 ingress interfaces for the (n,*,*) case. 596 o The MNN: it should be able to select the path based on "Default 597 Router Selection" (see [Section 6.3.6. Default Router Selection] 598 [11]) in the (n,*,*) case or based on "Source Address Selection" 599 in the (*,*,n) cases (see Section 4.9 of the present memo). 601 o The user or the application: e.g. in case where a user wants to 602 select a particular access technology among the available 603 technologies for reasons of cost or data rate. 605 o A combination of any of the above: a hybrid mechanism should be 606 also available, e.g. one in which the HA, the MR, and/or the MNNs 607 are coordinated to select the path. 609 4.3 Ingress Filtering 611 Ingress filtering mechanisms may drop the outgoing packets when 612 multiple bi-directional tunnels end up at different HAs. 614 This could occur when different NEMO-prefixes are handled by 615 different HAs such as the one illustrated in Figure 9. In Figure 9, 616 the mobile network has two mobile routers MR1 and MR2, with home 617 agents HA1 and HA2 respectively. Two bi-directional tunnels are 618 established are established between the two pairs. Each mobile 619 router advertises a different NEMO-prefix (P1 and P2). NEMO-prefix 620 P1 is registered to HA1, and NEMO-prefix P2 is registered to HA2. 621 Thus, MNNs should be free to auto-configure their addresses on any of 622 P1 or P2. Ingress filtering could thus happen in two cases: 624 o If the two tunnels are available, MNN cannot forward packet with 625 source address equals P1.MNN to MR2. This would cause ingress 626 filtering at HA2 to occur (or even at MR2). This is contrary to 627 normal Neighbor Discovery [11] practice that an IPv6 node is free 628 to choose any router as its default router regardless of the 629 prefix it chooses to use. A simple solution is to require all 630 MNNs to set their default router to the MR that advertises the 631 NEMO-prefix the MNNs configured their addresses from. If such 632 requirement is not placed on mobile network nodes, then a 633 multihoming solution for mobile networks must address this 634 problem. For a possible approach, see [12]. However, this is not 635 enough to maintain connectivity if a tunnel fails (see Section 4.1 636 for a discussion of this issue). 638 o If the tunnel to HA1 is broken, packets would be sent through the 639 tunnel to HA1 are diverted through the tunnel to HA2. If HA2 (or 640 some border gateway in the domain of HA2) performs ingress 641 filtering, packets with source address configured from NEMO-Prefix 642 P1 may be discarded. It should be noted that this problem may be 643 faced by any (*,n,n) mobile network, even if MR1 and MR2 are in 644 fact the same entity in Figure 9. 646 To avoid ingress filtering mechanisms dropping packets in such 647 situations, MR(s) can stop advertising P1. This would prevent MNNs 648 from using the address auto-configured on this prefix. However, such 649 a method suffers from the following two limitations: 651 o Switching addresses is time consuming since nodes have to wait for 652 addresses to get deprecated [13]. 654 o Switching addresses force transport sessions without multihoming 655 capabilities (such as TCP) to terminate, and be re-established 656 using the alternative source address. Transport sessions with 657 multihoming capabilities (such as SCTP) may be able to continue 658 without disruption (see also Section 4.1) 660 It is possible to overcome these limitations by using nested tunnels. 661 Appendix B describes one such approach. 663 Prefix: P1 +-----+ +----+ +----------+ +-----+ 664 +--| MR1 |--| AR |--| |---| HA1 | 665 | +-----+ +----+ | | +-----+ 666 IP: +-----+ | | | Prefix: P1 667 P1.MNN or | MNN |--+ | Internet | 668 P2.MNN +-----+ | | | Prefix: P2 669 | +-----+ +----+ | | +-----+ 670 +--| MR2 |--| AR |--| |---| HA2 | 671 Prefix: P2 +-----+ +----+ +----------+ +-----+ 673 Figure 9: An (n,n,n) mobile network 675 4.4 Failure Detection 677 It is expected for faults to occur more readily at the edge of the 678 network (i.e. the mobile nodes), due to the use of wireless 679 connections. Efficient fault detection mechanisms are necessary to 680 recover in timely fashion. In order for fault recovery to work, the 681 MRs and HAs must first possess a means to detect failures: 683 o On the MR's side, the MR can also rely on router advertisements 684 from access routers, or other layer-2 trigger mechanisms to detect 685 faults (e.g. [14] or [15]) . 687 o On the HA's side, it is more difficult for HAs to detect tunnel 688 failures. For an ISP deployment model, the HAs and MRs can use 689 proprietary methods (such as constant transmission of heartbeat 690 signals) to detect failures and check tunnel liveness. In the S/P 691 model (see Appendix A.2), a lack of standardized "tunnel liveness" 692 protocol means that it is harder to detect failures. 694 A possible method is for the MRs to send binding updates more 695 regularly with shorter Lifetime values. Similarly, HAs can return 696 binding acknowledgment messages with smaller Lifetime values, thus 697 forcing the MRs to send binding updates more frequently. These 698 binding updates can be used to emulate "tunnel heartbeats". This 699 however may lead to more traffic and processing overhead, since 700 binding updates sent to HAs must be protected (and possibly 701 encrypted) with security associations. 703 4.5 HA Synchronization 705 In the (*,n,1) mobile networks, a single NEMO-prefix would be 706 registered at different HAs. This gives rise to the following 707 issues: 709 o Only one HA may actively advertise a route to the NEMO-prefix. 711 o Multiple HAs at different domains may advertise a route to the 712 same NEMO-prefix 714 This may pose a problem in the routing infrastructure as a whole. 715 The implications of this aspect needs further exploration. Certain 716 level of HA co-ordination may be required. A possible approach is to 717 adopt a HA synchronization mechanism such as that described in [16] 718 and [17]. Such synchronization might also be necessary in a (*,n,*) 719 mobile network, when a MR sends binding update messages to only one 720 HA (instead of all HAs). In such cases, the binding update 721 information might have to be synchronized betweeen HAs. The mode of 722 synchoronization may be either primary-secondary or peer-to-peer. 723 See also Section 4.6. 725 4.6 MR Synchronization 727 In the (n,*,*) mobile network, different MRs may need to be 728 synchronized in order to take common decisions. The mode of 729 synchoronization may be either primary-secondary or peer-to-peer. 730 This may include: 732 o In the (n,*,1) case, advertising the same NEMO-Prefix (see also 733 "prefix delegation" in Section 4.7). 735 o In the (n,*,n) case, a MR relaying the advertisement of the 736 NEMO-Prefix from another failed MR. 738 o In the (n,*,*) cases, relaying between MRs everything that needs 739 to be relayed, such as data packets, creating a tunnel from the 740 ingress interface, etc. 742 4.7 Prefix Delegation 744 In the (*,*,1) mobile network, the same NEMO-prefix must be 745 advertised to the MNNs through different paths. This questions how 746 to perform prefix delegation: 748 o For the (*,n,1) mobile network, how multiple HAs would delegate 749 the same NEMO-prefix to the mobile network. For doing so, the HAs 750 may be somehow configured to advertise the same NEMO-prefix. (see 751 also "HA Synchronization" in Section 4.5). 753 o For the (n,*,n) mobile network, how multiple mobile routers would 754 be synchronized to advertise the same NEMO-Prefix down the 755 NEMO-link. For doing so, the MRs may be somehow configured to 756 advertise the same NEMO-prefix (see also "MR Synchronization" in 757 Section 4.6). 759 This could be configured manually, or dynamically. Alternatively, 760 prefix delegation mechanisms [18][19] could be used to ensure all 761 routers advertise the same NEMO-prefix. 763 4.8 Multiple Bindings/Registrations 765 When a MR is configured with multiple Care-of Addresses, it is often 766 necessary for it to bind these Care-of Addresses to the same 767 NEMO-Prefix. 769 This is a generic issue, since Mobile IPv6 nodes face a similar 770 problem if they wish to bind multiple Care-of Addresses to the same 771 Home Address". This is better discussed in [7]. It is sufficient to 772 note that solutions like [20] can solve this. 774 4.9 Source Address Selection 776 In the (*,*,n) mobile networks, MNNs would be configured with 777 multiple addresses. Source address selection mechanisms are needed 778 to decide which address to choose from. 780 It may be desirable for MNN to be able to acquire "preference" 781 information on each NEMO-prefix from the MRs. This allows default 782 address selection mechanism such as that specified in [13] to be 783 used. Further exploration on setting such "preference" information 784 in Router Advertisement based on performance of the bi-directional 785 tunnel might prove to be useful. 787 4.10 Impact on the Routing Infrastructure 789 In the (1,n,1) case with HAs located in distinct ISPs/ASs, multiple 790 routes directed to the mobile network may be advertised in the 791 Internet. This may provide shorter paths, but this would add a 792 burden in routing tables as the route would be published in the 793 Internet Router Registry for multiple ASs. Such issues are 794 investigated in the MULTI6 working group at the IETF. 796 4.11 Nested Mobile Networks 798 When a multihomed mobile network is nested within another mobile 799 network, it can result in very complex topologies. For instance, a 800 nested mobile network may be attached two different root-MRs, thus 801 the aggregated network no longer forms a simple tree structure. As 802 such, a solution to prevent an infinite loop must be provided. 804 4.12 Split Mobile Networks 806 When a (n,*,1) network splits, (i.e. the two MRs split themselves 807 up), the only available NEMO-prefix will then be registered by two 808 different MRs on different links. This cannot be allowed, as the HA 809 has no way to know which node with an address configured from that 810 NEMO-prefix is attached to which MR. Some mechanism must be present 811 for the NEMO-prefix to either be forcibly removed from one (or all) 812 MRs, or the implementors must not allow a (n,*,1) network to split. 814 A possible approach to solving this problem is described in [21]. 816 5. Conclusion 818 This document is an analysis of multihoming in the context of network 819 mobility. The purpose of this memo is to investigate issues related 820 to such a bi-directional tunneling mechanism when mobile networks are 821 multihomed. 823 Several issues that might impact the deployment of NEMO with 824 multihoming capabilities were identified in Section 4. They include: 826 1. Path Survival 828 2. Path Availability 830 3. Ingress Filtering 832 4. Failure Detection 834 5. HA Synchronization 836 6. MR Synchronization 838 7. Prefix Delegation 840 8. Multiple Binding/Registrations 842 9. Source Address Selection 844 10. Imapct on the Routing Infrastructure 846 11. Nested Mobile Networks 848 12. Split Mobile Networks. 850 This study is a work in progress and need to be improved by a 851 thorough study of each individual issues. Particularly, this memo 852 should be completed by a thorough threat analysis of multihoming 853 configurations of mobile network. We will add security threat issues 854 here as and when they are encountered, such as those described in 855 [22]. We also encourage interested people to contribute to this 856 part. 858 6. Acknowledgments 860 The authors would like to thank people who have given valuable 861 comments on various multihoming issues on the mailing list, and also 862 those who have suggested directions in the 56th - 59th IETF Meetings. 864 The initial evaluation of NEMO Basic Support is a contribution from 865 Julien Charbon. 867 7 References 869 [1] Ernst, T., "Network Mobility Support Goals and Requirements", 870 draft-ietf-nemo-requirements-02 (work in progress), February 871 2004. 873 [2] Manner, J. and M. Kojo, "Mobility Related Terminology", RFC 874 3753, June 2004. 876 [3] Ernst, T. and H. Lach, "Network Mobility Support Terminology", 877 draft-ietf-nemo-terminology-01 (work in progress), February 878 2004. 880 [4] Devarapalli, V., "Network Mobility (NEMO) Basic Support 881 Protocol", draft-ietf-nemo-basic-support-03 (work in progress), 882 June 2004. 884 [5] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in 885 IPv6", RFC 3775, June 2004. 887 [6] Ernst, T., "Goals and Benefits of Multihoming", 888 draft-multihoming-generic-goals-and-benefits-00 (work in 889 progress), February 2004. 891 [7] Montavont, N., Wakikawa, R. and T. Ernst, "Analysis of 892 Multihoming in Mobile IPv6", 893 draft-montavont-mobileip-multihoming-pb-statement-01 (work in 894 progress), Feb 2004. 896 [8] Ernst, T. and J. Charbon, "Multihoming with NEMO Basic 897 Support", Proceedings First International Conference on Mobile 898 Computing and Ubiquitous Networking (ICMU), January 2004. 900 [9] Savola, P., "Examining Site Multi-homing in Finnish Networks", 901 Master's Thesis. , April 2003. 903 [10] Montavont, N., Noel, T. and M. Kassi-Lahlou, "MIPv6 for 904 Multiple Interfaces", draft-montavont-mobileip-mmi-00 (work in 905 progress), July 2002. 907 [11] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery 908 for IP Version 6 (IPv6)", RFC 2461, December 1998. 910 [12] Draves, R. and D. Thaler, "Default Router Preferences and 911 More-Specific Routes", draft-ietf-ipv6-router-selection-04 912 (work in progress), June 2004. 914 [13] Draves, R., "Default Address Selection for Internet Protocol 915 version 6 (IPv6)", RFC 3484, February 2003. 917 [14] Yegin, A., "Link-layer Hints for Detecting Network 918 Attachments", draft-yegin-dna-l2-hints-01 (work in progress), 919 February 2004. 921 [15] Yegin, A., "Supporting Optimized Handover for IP Mobility 922 -Requirements for Underlying Systems", 923 draft-manyfolks-l2-mobilereq-02 (work in progress), July 2002. 925 [16] Wakikawa, R., Devarapalli, V. and P. Thubert, "Inter Home 926 Agents Protocol (HAHA)", draft-wakikawa-mip6-nemo-haha-01 (work 927 in progress), February 2004. 929 [17] Koh, B., Ng, C. and J. Hirano, "Dynamic Inter Home Agent 930 Protocol", draft-koh-mip6-nemo-dhap-00 (work in progress), July 931 2004. 933 [18] Miyakawa, S. and R. Droms, "Requirements for IPv6 Prefix 934 Delegation", RFC 3769, June 2004. 936 [19] Droms, R. and P. Thubert, "DHCPv6 Prefix Delegation for NEMO", 937 draft-droms-nemo-dhcpv6-pd-01 (work in progress), February 938 2004. 940 [20] Wakikawa, R., "Multiple Care-of Addresses Registration", 941 draft-wakikawa-mobileip-multiplecoa-02 (work in progress), 942 September 2003. 944 [21] Kumazawa, M., Watanabe, Y., Matsumoto, T. and S. Narayana, 945 "Token based Duplicate Network Detection for split mobile 946 network (Token based DND)", draft-kumazawa-nemo-tbdnd-00 (work 947 in progress), July 2004. 949 [22] Choi, S., "Threat for Multi-homed Mobile Networks", 950 draft-cho-nemo-threat-multihoming-00 (work in progress), 951 February 2004. 953 Authors' Addresses 955 Chan-Wah Ng 956 Panasonic Singapore Laboratories Pte Ltd 957 Blk 1022 Tai Seng Ave #06-3530 958 Tai Seng Industrial Estate 959 Singapore 534415 960 SG 962 Phone: +65 65505420 963 EMail: cwng@psl.com.sg 965 Paik, Eun Kyoung 966 Seoul National University 967 Multimedia and Mobile communications Lab., Seoul National Univ. 968 Shillim-dong, Kwanak-gu 969 Seoul 151-744 970 Korea 972 Phone: +82-2-880-1832 973 Fax: +82-2-872-2045 974 EMail: eun@mmlab.snu.ac.kr 975 URI: http://mmlab.snu.ac.kr/~eun/ 977 Ernst Thierry 978 WIDE at Keio University 979 Jun Murai Lab., Keio University. 980 K-square Town Campus, 1488-8 Ogura, Saiwa-Ku 981 Kawasaki, Kanagawa 212-0054 982 Japan 984 Phone: +81-44-580-1600 985 Fax: +81-44-580-1437 986 EMail: ernst@sfc.wide.ad.jp 987 URI: http://www.sfc.wide.ad.jp/~ernst/ 989 Appendix A. Alternative Classifications Approach 991 A.1 Ownership-Oriented Approach 993 An alternative approach to classifying multihomed mobile network is 994 proposed by Eric Nordmark (Sun Microsystems) by breaking the 995 classification of multihomed network based on ownership. This is 996 more of a tree-like top-down classification. Starting from the 997 control and ownership of the HA(s) and MR(s), there are two different 998 possibilities: either (i) the HA(s) and MR(s) are controlled by a 999 single entity, or (ii) the HA(s) and MR(s) are controlled by separate 1000 entities. We called the first possibility the 'ISP Model', and the 1001 second the 'Subscriber/Provider Model'. 1003 A.1.1 ISP Model 1005 The case of the HA(s) and MR(s) are controlled by the same entity can 1006 be best illustrated as an Internet Service Provider (ISP) installing 1007 mobile routers on trains, ships or planes. It is up to the ISP to 1008 deploy a certain configuration of mobile network; all 8 1009 configurations as described in the Configuration-Oriented Approach 1010 are possible. In the remaining portion of this document, when 1011 specifically referring to a mobile network configuration that is 1012 controlled by a single entity, we will add an 'ISP' prefix: for 1013 example: ISP-(1,1,1) or ISP-(1,N,N). 1015 When the HA(s) and MR(s) are controlled by a single entity (such as 1016 an ISP), the ISP can decide whether it wants to assign one or 1017 multiple NEMO-prefixes to the mobile network just like it can make 1018 the same decision for any other link in its network (wired or 1019 otherwise). In any case, the ISP will make the routing between the 1020 mobile networks and its core routers (such as the HAs) work. This 1021 include not introducing any aggregation between the HAs which will 1022 filter out routing announcements for the NEMO-prefix(es). 1024 To such ends, the ISP has various means and mechanisms. For one, the 1025 ISP can run its Interior Gateway Protocol (IGP) over bi-directional 1026 tunnels between the MR(s) and HA(s). Alternatively, static routes 1027 may be used with the tunnels. When static routes are used, a 1028 mechanism to test "tunnel liveness" might be necessary to avoid 1029 maintaining stale routes. Such "tunnel liveness" may be tested by 1030 sending heartbeats signals from MR(s) to the HA(s). A possibility is 1031 to simulate heartbeats using Binding Updates messages by controlling 1032 the "Lifetime" field of the Binding Acknowledgment message to force 1033 the MR to send Binding Update messages at regular interval. However, 1034 a more appropriate tool might be the Binding Refresh Request message, 1035 though conformance to the Binding Refresh Request message may be less 1036 strictly enforced in implementations since it serves a somewhat 1037 secondary role when compared to Binding Update messages. 1039 A.1.2 Subscriber/Provider Model 1041 The case of the HA(s) and MR(s) are controlled by the separate 1042 entities can be best illustrated with a subscriber/provider model, 1043 where the MRs belongs to a single subscriber and subscribes to one or 1044 more ISPs for HA services. There is two sub-categories in this case: 1045 when the subscriber subscribes to a single ISP, and when the 1046 subscriber subscribes to multiple ISPs. In the remaining portion of 1047 this document, when specifically referring to a mobile network 1048 configuration that is in the subscriber/provider model where the 1049 subscriber subscribes to only one ISP, we will add an 'S/P' prefix: 1050 for example: S/P-(1,1,1) or S/P-(1,n,n). When specifically referring 1051 to a mobile network configuration that is in the subscriber/provider 1052 model where the subscriber subscribes to multiple ISPs, we will add 1053 an 'S/mP' prefix: for example: S/mP-(1,1,1) or S/mP-(1,n,n). 1055 Not all 8 configurations are likely to be deployed for the S/P and S/ 1056 mP models. For instance, it is unlikely to foresee a S/mP-(*,1,1) 1057 mobile network where there is only a single HA. For the S/P model, 1058 the following configurations are likely to be deployed: 1060 o S/P-(1,1,1): Single Provider, Single MR, Single HA, Single 1061 NEMO-Prefix 1063 o S/P-(1,1,n): Single Provider, Single MR, Single HA, Multiple 1064 NEMO-Prefixes 1066 o S/P-(1,n,1): Single Provider, Single MR, Multiple HAs, Single 1067 NEMO-Prefix 1069 o S/P-(1,n,n): Single Provider, Single MR, Multiple HAs, Multiple 1070 NEMO-Prefixes 1072 o S/P-(n,n,1): Single Provider, Multiple MRs, Single HA, Single 1073 NEMO-Prefix 1075 o S/P-(n,1,n): Single Provider, Multiple MRs, Single HA, Multiple 1076 NEMO-Prefixes 1078 o S/P-(n,n,1): Single Provider, Multiple MRs, Multiple HAs, Single 1079 NEMO-Prefix 1081 o S/P-(n,n,n): Single Provider, Multiple MRs, Multiple HAs, Multiple 1082 NEMO-Prefixes 1084 For the S/mP model, the following configurations are likely to be 1085 deployed: 1087 o S/mP-(1,n,1): Multiple Providers, Single MR, Multiple HAs, Single 1088 NEMO-Prefix 1090 o S/mP-(1,n,n): Multiple Providers, Single MR, Multiple HAs, 1091 Multiple NEMO-Prefixes 1093 o S/mP-(n,n,n): Multiple Providers, Multiple MRs, Multiple HAs, 1094 Multiple NEMO-Prefixes 1096 When the HA(s) and MR(s) are controlled by different entities, it is 1097 more likely the scenario where the MR is controlled by one entity 1098 (i.e. the subscriber), and the MR is establishing multiple 1099 bi-directional tunnels to one or more HA(s) provided by one or more 1100 ISP(s). In such case, it is unlikely for the ISP to run IGP over the 1101 bi-directional tunnel, since ISP would most certainly wish to retain 1102 full control of its routing domain. 1104 A.2 Problem-Oriented Approach 1106 A third approach is proposed by Pascal Thubert (Cisco System). This 1107 focused on the problems of multihomed mobile networks rather than the 1108 configuration or ownership. With this approach, there is a set of 4 1109 categories based on two orthogonal parameters: the number of HAs, and 1110 the number of NEMO-prefixes advertised. Since the two parameters are 1111 orthogonal, the categories are not mutually exclusive. The four 1112 categories are: 1114 o Tarzan: Single HA for Different Care-of Addresses of Same 1115 NEMO-Prefix 1117 This is the case where one mobile router registers different 1118 Care-of Addresses to the same home agent for the same subnet 1119 prefix. This is equivalent to the case of y=1, i.e. the (1,1,n) 1120 mobile network. 1122 o JetSet: Multiple HAs for Different Care-of Addresses of Same 1123 NEMO-Prefix 1125 This is the case where the mobile router registers different 1126 Care-of Addresses to different home agents for the same subnet 1127 prefix. This is equivalent to the case of y=n, i.e. the (1,n,*) 1128 mobile network. 1130 o Shinkansen: Single NEMO-Prefix Advertised by MR(s) 1132 This is the case where one NEMO-prefix is announced by different 1133 MRs. This is equivalent to the case of z=n, i.e. the (1,*,n) 1134 mobile network. 1136 o DoubleBed: Multiple NEMO-Prefixes Advertised by MR(s) 1138 This is the case where more than one NEMO-prefixes are announced 1139 by the different MRs. This is equivalent to the case of z=n, i.e. 1140 the (n,*,n) mobile network. 1142 Appendix B. Nested Tunneling for Fault Tolerance 1144 In order to utilize the additional robustness provided by 1145 multihoming, MRs that employ bi-directional tunneling with their HAs 1146 should dynamically change their tunnel exit points depending on the 1147 link status. For instance, if a MR detects that one of its egress 1148 interface is down, it should detect if any other alternate route to 1149 the global Internet exists. This alternate route may be provided by 1150 any other MRs connected to one of its ingress interfaces that has an 1151 independent route to the global Internet, or by another active egress 1152 interface the MR itself possess. If such an alternate route exists, 1153 the MR should re-establish the bi-directional tunnel using this 1154 alternate route. 1156 In the remaining part of this section, we will attempt to investigate 1157 methods of performing such re-establishment of bi-directional 1158 tunnels. It is not the objective of this memo to specify a new 1159 protocol specifically tailored to provide this form of re- 1160 establishments. Instead, we will limit ourselves to currently 1161 available mechanisms specified in Mobile IPv6 [5] and Neighbor 1162 Discovery in IPv6 [11]. 1164 B.1 Detecting Presence of Alternate Routes 1166 To actively utilize the robustness provided by multihoming, a MR must 1167 first be capable of detecting alternate routes. This can be manually 1168 configured into the MR by the administrators if the configuration of 1169 the mobile network is relatively static. It is however highly 1170 desirable for MRs to be able to discover alternate routes 1171 automatically for greater flexibility. 1173 The case where a MR possesses multiple egress interface (bound to the 1174 same HA or otherwise) should be trivial, since the MR should be able 1175 to "realize" it has multiple routes to the global Internet. 1177 In the case where multiple MRs are on the mobile network, each MR has 1178 to detect the presence of other MR. A MR can do so by listening for 1179 Router Advertisement message on its *ingress* interfaces. When a MR 1180 receives a Router Advertisement message with a non-zero Router 1181 Lifetime field from one of its ingress interfaces, it knows that 1182 another MR which can provide an alternate route to the global 1183 Internet is present in the mobile network. 1185 B.2 Re-Establishment of Bi-Directional Tunnels 1187 When a MR detects that the link be which its current bi-directional 1188 tunnel with its HA is using is down, it needs to re-establish the 1189 bi-directional tunnel using an alternate route detected. We consider 1190 two separate cases here: firstly, the alternate route is provided by 1191 another egress interface that belongs to the MR; secondly, the 1192 alternate route is provided by another MR connected to the mobile 1193 network. We refer to the former case as an alternate route provided 1194 by an alternate egress interface, and the latter case as an alternate 1195 route provided by an alternate MR. 1197 B.2.1 Using Alternate Egress Interface 1199 When an egress interface of a MR loses the connection to the global 1200 Internet, the MR can make use of its alternate egress interface 1201 should it possess multiple egress interfaces. The most direct way to 1202 do so is for the mobile router to send a binding update to the home 1203 agent of the failed interface using the Care-of Address assigned to 1204 the alternate interface in order to re-establish the bi-directional 1205 tunneling using the Care-of Address on the alternate egress 1206 interface. After a successful binding update, the MR encapsulates 1207 outgoing packets through the bi-directional tunnel using the 1208 alternate egress interface. 1210 The idea is to use the global address (most likely a Care-of Address) 1211 assigned to an alternate egress interface as the new (back-up) 1212 Care-of Address of the mobile router to re-establish the 1213 bi-directional tunneling with its home agent. 1215 B.2.2 Using Alternate Mobile Router 1217 When the MR loses a connection to the global Internet, the MR can 1218 utilize a route provided by an alternate MR (if one exists) to 1219 re-establish the bi-directional tunnel with its HA. First, the MR 1220 has to obtain a Care-of Address from the alternate MR (i.e. attaches 1221 itself to the alternate MR). Next, it sends binding update to its HA 1222 using the Care-of Address obtained from the alternate MR. From then 1223 on, the MR can encapsulates outgoing packets through the 1224 bi-directional tunnel using via the alternate MR. 1226 The idea is to obtain a Care-of Address from the alternate MR and use 1227 this as the new (back-up) Care-of Address of the MR to re-establish 1228 the bi-directional tunneling with its HA. 1230 Note that every packet sent between MNNs and their correspondent 1231 nodes will experience two levels of encapsulation. First level of 1232 tunneling occurs between a MR which the MNN uses as its default 1233 router and the MR's HA. The second level of tunneling occurs between 1234 the alternate MR and its HA. 1236 B.3 To Avoid Tunneling Loop 1238 The method of re-establishing the bi-directional tunnel as described 1239 in Appendix B.2 may lead to infinite loops of tunneling. This 1240 happens when two MRs on a mobile network lose connection to the 1241 global Internet at the same time and each MR tries to re-establish 1242 bi-directional tunnel using the other MR. We refer to this 1243 phenomenon as tunneling loop. 1245 One approach to avoid tunneling loop is for a MR that has lost 1246 connection to the global Internet to insert an option into the Router 1247 Advertisement message it broadcasts periodically. This option serves 1248 to notify other MRs on the link that the sender no longer provides 1249 global connection. Note that setting a zero Router Lifetime field 1250 will not work well since it will cause MNNs that are attached to the 1251 MR to stop using the MR as their default router too (in which case, 1252 things are back to square one). 1254 Appendix C. Change Log 1256 o This draft is an update of draft-ng-nemo-multihoming-issues-03.txt 1257 which is itself a merge of 3 previous drafts 1258 draft-ng-nemo-multihoming-issues-02.txt, 1259 draft-eun-nemo-multihoming-problem-statement-00.txt, and 1260 draft-charbon-nemo-multihoming-evaluation-00.txt 1262 o Changes from draft-ng-multihoming-issues-03 to 1263 draft-ietf-nemo-multihoming-issues-00: 1265 * Expanded "Problem Statement" (Section 4) 1267 * Merged "Evaluation" Section into "Problem Statement" (Section 1268 4) 1270 * Cleaned up description in "Classification" (Section 2), and 1271 clearly indicate in each classification, what are the 1272 multihomed entities 1274 * Re-organized "Deployment Scenarios and Prerequisites" (Section 1275 3), and created the "Prerequisites" sub-section. 1277 o Changes from draft-ng-multihoming-issues-02 to 1278 draft-ng-multihoming-issues-03: 1280 * Merged with draft-eun-nemo-multihoming-problem-statement (see 1281 "Problem Statement" (Section 4)) 1283 * Included conclusions from 1284 draft-charbon-nemo-multihoming-evaluation-00 1286 * Re-organized some part of "Benefits/Issues of Multhoming in 1287 NEMO" to "Problem Statement" (Section 4) 1289 * Removed lots of text to be in sync with [6]. 1291 * Title changed from "Multihoming Issues in NEMO Basic Support" 1292 to "Analysis of Multihoming in NEMO" 1294 * Changed (w,x,y) to (x,y,z) in taxonomy. 1296 * Moved alternative approaches of classification to Appendix 1298 * Creation of this Change-Log itself ;-) 1300 Intellectual Property Statement 1302 The IETF takes no position regarding the validity or scope of any 1303 Intellectual Property Rights or other rights that might be claimed to 1304 pertain to the implementation or use of the technology described in 1305 this document or the extent to which any license under such rights 1306 might or might not be available; nor does it represent that it has 1307 made any independent effort to identify any such rights. Information 1308 on the procedures with respect to rights in RFC documents can be 1309 found in BCP 78 and BCP 79. 1311 Copies of IPR disclosures made to the IETF Secretariat and any 1312 assurances of licenses to be made available, or the result of an 1313 attempt made to obtain a general license or permission for the use of 1314 such proprietary rights by implementers or users of this 1315 specification can be obtained from the IETF on-line IPR repository at 1316 http://www.ietf.org/ipr. 1318 The IETF invites any interested party to bring to its attention any 1319 copyrights, patents or patent applications, or other proprietary 1320 rights that may cover technology that may be required to implement 1321 this standard. Please address the information to the IETF at 1322 ietf-ipr@ietf.org. 1324 Disclaimer of Validity 1326 This document and the information contained herein are provided on an 1327 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1328 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1329 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1330 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1331 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1332 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1334 Copyright Statement 1336 Copyright (C) The Internet Society (2004). This document is subject 1337 to the rights, licenses and restrictions contained in BCP 78, and 1338 except as set forth therein, the authors retain all their rights. 1340 Acknowledgment 1342 Funding for the RFC Editor function is currently provided by the 1343 Internet Society.