idnits 2.17.1 draft-ietf-nemo-multihoming-issues-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1.a on line 20. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1376. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1353. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1360. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1366. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** 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: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 974 has weird spacing: '... (Token based...' == Line 1056 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 (October 25, 2004) is 7123 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-03 ** 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-02 ** Downref: Normative reference to an Informational draft: draft-ietf-nemo-terminology (ref. '3') ** Obsolete normative reference: RFC 3775 (ref. '5') (Obsoleted by RFC 6275) == Outdated reference: A later version (-02) exists of draft-ernst-generic-goals-and-benefits-00 -- 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' ** Obsolete normative reference: RFC 3484 (ref. '9') (Obsoleted by RFC 6724) -- 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-06 -- Possible downref: Normative reference to a draft: ref. '13' -- Possible downref: Normative reference to a draft: ref. '14' -- Possible downref: Normative reference to a draft: ref. '15' -- No information found for draft-koh-mip6-nemo-dhap - is the name correct? -- Possible downref: Normative reference to a draft: ref. '16' ** Downref: Normative reference to an Informational RFC: RFC 3769 (ref. '17') == Outdated reference: A later version (-02) exists of draft-droms-nemo-dhcpv6-pd-01 -- Possible downref: Normative reference to a draft: ref. '18' == Outdated reference: A later version (-05) exists of draft-wakikawa-mobileip-multiplecoa-03 -- Possible downref: Normative reference to a draft: ref. '19' == Outdated reference: A later version (-02) exists of draft-kumazawa-nemo-tbdnd-01 -- Possible downref: Normative reference to a draft: ref. '20' -- Possible downref: Normative reference to a draft: ref. '21' Summary: 15 errors (**), 0 flaws (~~), 12 warnings (==), 21 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NEMO Working Group C. Ng 3 Internet-Draft Panasonic Singapore Labs 4 Expires: April 25, 2005 E. Paik 5 KT 6 T. Ernst 7 WIDE at Keio University 8 October 25, 2004 10 Analysis of Multihoming in Network Mobility Support 11 draft-ietf-nemo-multihoming-issues-01 13 Status of this Memo 15 This document is an Internet-Draft and is subject to all provisions 16 of section 3 of RFC 3667. By submitting this Internet-Draft, each 17 author represents that any applicable patent or other IPR claims of 18 which he or she is aware have been or will be disclosed, and any of 19 which he or she become aware will be disclosed, in accordance with 20 RFC 3668. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as 25 Internet-Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on April 25, 2005. 40 Copyright Notice 42 Copyright (C) The Internet Society (2004). 44 Abstract 46 This document is an analysis of multihoming in the context of network 47 mobility (NEMO). As there are many situations in which mobile 48 networks may be multihomed, a taxonomy is proposed to classify the 49 possible configurations. We also describe possible deployment 50 scenarios and we attempt to identify issues that arise when mobile 51 networks are multihomed while mobility supports is taken care by NEMO 52 Basic Support. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 2. Classification . . . . . . . . . . . . . . . . . . . . . . . . 6 59 2.1 (1,1,1): Single MR, Single HA, Single MNP . . . . . . . . 7 60 2.2 (1,1,n): Single MR, Single HA, Multiple MNPs . . . . . . . 7 61 2.3 (1,n,1): Single MR, Multiple HAs, Single MNP . . . . . . . 8 62 2.4 (1,n,n): Single MR, Multiple HAs, Multiple MNPs . . . . . 8 63 2.5 (n,1,1): Multiple MRs, Single HA, Single MNP . . . . . . . 9 64 2.6 (n,1,n): Multiple MRs, Single HA, Multiple MNPs . . . . . 9 65 2.7 (n,n,1): Multiple MRs, Multiple HAs, Single MNP . . . . . 10 66 2.8 (n,n,n): Multiple MRs, Multiple HAs, Multiple MNPs . . . . 10 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 . . . . . . . . . . . . . . . . . . . . 18 77 4.5 Media Detection . . . . . . . . . . . . . . . . . . . . . 19 78 4.6 HA Synchronization . . . . . . . . . . . . . . . . . . . . 19 79 4.7 MR Synchronization . . . . . . . . . . . . . . . . . . . . 19 80 4.8 Prefix Delegation . . . . . . . . . . . . . . . . . . . . 20 81 4.9 Multiple Bindings/Registrations . . . . . . . . . . . . . 20 82 4.10 Source Address Selection . . . . . . . . . . . . . . . . . 20 83 4.11 Impact on the Routing Infrastructure . . . . . . . . . . . 21 84 4.12 Nested Mobile Networks . . . . . . . . . . . . . . . . . . 21 85 4.13 Split Mobile Networks . . . . . . . . . . . . . . . . . . 21 87 5. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 22 89 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23 91 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 25 95 A. Alternative Classifications Approach . . . . . . . . . . . . . 26 96 A.1 Ownership-Oriented Approach . . . . . . . . . . . . . . . 26 97 A.1.1 ISP Model . . . . . . . . . . . . . . . . . . . . . . 26 98 A.1.2 Subscriber/Provider Model . . . . . . . . . . . . . . 27 99 A.2 Problem-Oriented Approach . . . . . . . . . . . . . . . . 29 101 B. Nested Tunneling for Fault Tolerance . . . . . . . . . . . . . 30 102 B.1 Detecting Presence of Alternate Routes . . . . . . . . . . 30 103 B.2 Re-Establishment of Bi-Directional Tunnels . . . . . . . . 30 104 B.2.1 Using Alternate Egress Interface . . . . . . . . . . . 31 105 B.2.2 Using Alternate Mobile Router . . . . . . . . . . . . 31 106 B.3 To Avoid Tunneling Loop . . . . . . . . . . . . . . . . . 32 108 C. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 33 110 Intellectual Property and Copyright Statements . . . . . . . . 35 112 1. Introduction 114 The goals and objectives of Network Mobility Support (NEMO) are 115 identified in [1] while the terminology is being described in [2] and 116 [3]. NEMO Basic Support [4] is the solution proposed by the NEMO 117 Working Group to provide continuous Internet connectivity to nodes 118 located in a mobile network. This solutions basically solves the 119 problem by setting up bi-directional tunnels between the mobile 120 routers (MRs) connecting the mobile network to the Internet and their 121 respective Home Agents (HAs), much how this is done in Mobile IPv6 122 [5], the solution for host mobility. NEMO Basic Support is 123 transparent to nodes located behind the mobile router (i.e. the 124 mobile network nodes, or MNNs) and as such doesn't require MNNs to 125 take any action in the mobility management. 127 We note that mobile networks are typically connected by means of 128 wireless and thus less reliable links. In addition, there could be 129 many nodes behind the MR, so a loss of connectivity or a failure to 130 connect to the Internet has a more significant impact than for a 131 single node. Real-life scenarios as illustrated in [6] demonstrate 132 that providing a permanent access to mobile networks such as vehicles 133 typically require the use of several interfaces and technologies 134 since the mobile network may be moving in distant geographical 135 locations where different access technologies are provided and 136 governed by distinct access control policies. 138 The purpose of this memo is to investigate issues related to such a 139 bi-directional tunneling mechanism when mobile networks are 140 multihomed, i.e. when there is more than one point of attachment 141 between the mobile network and the Internet. This arises either when 142 a MR has multiple egress interfaces, or the mobile network has 143 multiple MRs or is associated with multiple HAs, or multiple prefixes 144 are advertised down to the mobile network (see definitions in [3]). 146 As specified by R.12 in section 5 of [1], the NEMO WG must ensure 147 that NEMO Basic Support does not prevent mobile networks to be 148 multihomed. Using NEMO Basic Support, this translates into having 149 multiple bi-directional tunnels between the mobile network and its 150 HA(s), and may result into multiple MNPs being advertised to the 151 MNNs. However, NEMO Basic Support does not specify any particular 152 mechanism to manage multiple bi-directional tunnels. The objective 153 of this memo is thus three-folds: 155 o to capture issues for deploying a multihomed mobile network, 157 o to identify which multihoming configurations are useful, 159 o to identify issues that may prevent useful multihomed 160 configurations to be supported under the operation of NEMO Basic 161 Support. It doesn't mean that those not supported will not work 162 with NEMO Basic Support, just that it is up to the implementors to 163 make it work (hopefully issues discussed in this memo will be 164 helpful to these implementors). 166 For doing so, a taxonomy to classify the possible multihomed 167 configurations is described in Section 2. Deployment scenarios, 168 their benefits, and requirements to meet these benefits are 169 illustrated in Section 3. Following this, we study the general 170 issues in Section 4, and we conclude with an evaluation of NEMO Basic 171 Support for multihomed configurations. Alternative classifications 172 are outlined in the Appendix. 174 In order to understand this memo, the reader is expected to be 175 familiar with the above cited documents, i.e. with the NEMO 176 terminology as defined in [2] (section 3) and [3], Goals and Benefits 177 of Multihoming [6], Goals and Requirements of Network Mobility 178 Support [1], and the NEMO Basic Support specification [4]. The 179 readers are reminded when describing the issues, we implicitly have 180 an IPv6 environment in mind (as NEMO Basic Support [4] is for IPv6), 181 though some of the issues are independent of IP version. 183 Note that goals and benefits for multihoming as discussed in [6] is 184 applicable to fixed nodes, mobile nodes, fixed networks and mobile 185 networks, so we won't re-state the motivations in the present memo. 187 2. Classification 189 Various discussions on the topic of multihoming issues in NEMO have 190 been carried out on the mailing list and at IETF meetings. As there 191 are several configurations in which mobile networks are multihomed, 192 there is a need to classify them into a clearly defined taxonomy. 193 This can be done in various ways. Three approaches have been 194 proposed on the NEMO mailing list. These are, namely, (i) the 195 Configuration-Oriented Approach, (ii) the Ownership-Oriented 196 Approach, and (iii) the Problem-Oriented Approach. As the WG 197 consensus seems to have converged to the Configuration-Oriented 198 Approach, we only describe this approach here. The other two 199 approaches are outlined in Appendix A.1 and Appendix A.2. 201 Multihomed configurations can be classified depending on how many 202 mobile routers are present, how many egress interfaces, Care-of 203 Address (CoA) and Home Addresses (HoA) the mobile routers have, how 204 many prefixes (MNPs) are advertised to the mobile network nodes, etc. 205 For doing so, we use three key parameters differentiating different 206 multihomed configurations. With these parameters, we can refer to 207 each configuration by the 3-tuple (x,y,z), where 'x', 'y', 'z' are 208 defined as follows: 210 o 'x' indicates the number of MRs where: 212 x=1 implies a mobile network has only a single MR, presumably 213 multihomed. 215 x=N implies a mobile network has more than one MR. 217 o 'y' indicates the number of HAs associated with the entire mobile 218 network, where: 220 y=1 implies that a single HA is assigned to the mobile network. 222 y=N implies that multiple HAs (possibly in different 223 administrative domains) are assigned to the mobile network. 225 o 'z' indicates the number of MNPs announced to MNNs, where: 227 z=1 implies that a single MNP is advertised to the MNNs. 229 z=N implies that multiple MNPs are advertised to the 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 MNP 250 The (1,1,1) mobile network has only one MR advertising a single MNP. 251 In addition, the MR is associated with only one HA at any one time. 252 A bi-directional tunnel may be established between each pair of Home 253 Address / Care-of address if the MR is itself multihomed. 255 The MR may be multihomed and MNNs are (usually) not multihomed since 256 they would configure a single address on the single MNP announced on 257 the link they are attached to. 259 _____ 260 _ p _ | | 261 |_|-|<-_ |-|_|-| |-| _ 262 _ |-|_|=| |_____| | _ |-|_| 263 |_|-| | |-|_|-| 264 | 265 MNNs MR AR Internet AR HA 267 Figure 1: (1,1,1): 1 MR, 1 HA, 1 MNP 269 2.2 (1,1,n): Single MR, Single HA, Multiple MNPs 271 The (1,1,n) mobile network has only one MR, which is associated to 272 only one HA at any one time. However, two or more MNPs are 273 advertised to the mobile network nodes. 275 The MR may be itself multihomed, and MNNs are multihomed if several 276 MNPs are advertised on the link they are attached to. If that 277 conditions holds, MNNs would configure an address with each MNP 278 announced on the link. 280 _____ 281 _ p1,p2 _ | | 282 |_|-|<-_ |-|_|-| |-| _ 283 _ |-|_|=| |_____| | _ |-|_| 284 |_|-| | |-|_|-| 285 | 286 MNNs MR AR Internet AR HA 288 Figure 2: (1,1,n): 1 MR, 1 HA, multiple MNPs 290 2.3 (1,n,1): Single MR, Multiple HAs, Single MNP 292 The (1,n,1) mobile network has only one MR advertising a single MNP. 293 The MR, however, is associated to multiple HAs, possibly one HA per 294 Home Address, or one HA per egress interface. 296 The MR may be multihomed whereas MNNs are (usually) not multihomed 297 since they would configure a single address on the single MNP 298 announced on the link they are attached to. 300 AR HA2 301 _ | 302 |-|_|-| _ 303 _____ | |-|_| 304 _ p _ | |-| 305 |_|-|<-_ |-|_|-| | 306 _ |-|_|=| |_____|-| _ 307 |_|-| | | _ |-|_| 308 |-|_|-| 309 | 310 MNNs MR AR Internet AR HA1 312 Figure 3: (1,n,1): 1 MR, multiple HAs, 1 MNP 314 2.4 (1,n,n): Single MR, Multiple HAs, Multiple MNPs 316 The (1,n,n) mobile network has only one MR. However, the MR is 317 associated with multiple HAs, possibly one per Home Address (or one 318 HA per egress interface), and the MR advertises more than one MNP on 319 its ingress interfaces. No assumption is made on whether or not the 320 HAs belongs to the same administrative domain. 322 The MR may be multihomed, and the MNNs are generally multihomed since 323 they would configure an address on each MNP announced on the link 324 they are attached to. 326 AR HA2 327 _ | _ 328 _____ |-|_|-|-|_| 329 _ p1,p2 _ | |-| | 330 |_|-|<-_ |-|_|-| | _ 331 _ |-|_|=| |_____|-| _ |-|_| 332 |_|-| | |-|_|-| 333 | | 334 MNNs MR AR Internet AR HA1 336 Figure 4: (1,n,n): 1 MR, multiple HAs, multiple MNPs 338 2.5 (n,1,1): Multiple MRs, Single HA, Single MNP 340 The (n,1,1) mobile network has more than one MR advertising global 341 routes. These MRs, however, advertise the same MNP and are 342 associated with the same HA. 344 Each MR may be itself multihomed, whereas MNNs are (usually) not 345 multihomed since they would configure a single address on the single 346 MNP announced on the link they are attached to. 348 MR2 349 p<-_ | 350 _ |-|_|-| _____ 351 |_|-| |-| | 352 _ | | |-| _ 353 |_|-| _ |-|_____| | _ |-|_| 354 |-|_|-| |-|_|-| 355 p<- | | 356 MNNs MR1 Internet AR HA 358 Figure 5: (n,1,1): Multiple MRs, 1 HA, 1 MNP 360 2.6 (n,1,n): Multiple MRs, Single HA, Multiple MNPs 362 The (n,1,n) mobile network has more than one MR advertising different 363 global routes and different MNPs. However, these MRs are associated 364 to the same HA. 366 Each MR may be itself multihomed, and MNNs are generally multihomed 367 since they would configure an address on each MNP announced on the 368 link they are attached to. 370 MR2 371 p2<-_ | 372 _ |-|_|-| _____ 373 |_|-| |-| | 374 _ | | |-| _ 375 |_|-| _ |-|_____| | _ |-|_| 376 |-|_|-| |-|_|-| 377 p1<- | | 378 MNNs MR1 Internet AR HA 380 Figure 6: (n,1,n): Multiple MRs, 1 HA, multiple MNPs 382 2.7 (n,n,1): Multiple MRs, Multiple HAs, Single MNP 384 The (n,n,1) mobile network has more than one MR advertising different 385 global routes. The mobile network is associated with multiple HAs at 386 any one time. No assumptions are made on whether or not the HAs 387 belongs to the same administrative domain. However, the MRs 388 advertises the same MNP. 390 Each MR may be itself multihomed whereas MNNs are (usually) not 391 multihomed since they would configure a single address on the single 392 MNP announced on the link they are attached to. 394 MR2 AR HA2 395 p _ | 396 <-_ | |-|_|-| _ 397 _ |-|_|-| _____ | |-|_| 398 |_|-| |-| |-| 399 _ | | | 400 |_|-| _ |-|_____|-| _ 401 |-|_|-| | _ |-|_| 402 <- | |-|_|-| 403 p | 404 MNNs MR1 Internet AR HA1 406 Figure 7: (n,n,1): Multiple MRs, Multiple HAs, 1 MNP 408 2.8 (n,n,n): Multiple MRs, Multiple HAs, Multiple MNPs 410 The (n,n,n) mobile network has multiple MRs advertising different 411 global routes and different MNPs. The mobile network is associated 412 with more than one HA at any one time. No assumptions is made on 413 whether or not the HA belongs to the same administrative domain. 415 Each MR may be itself multihomed and MNNs are generally multihomed 416 since they would configure an address on each MNP announced on the 417 link they are attached to 419 MR2 AR HA2 420 p2 _ | 421 <-_ | |-|_|-| _ 422 _ |-|_|-| _____ | |-|_| 423 |_|-| |-| |-| 424 _ | | | 425 |_|-| _ |-|_____|-| _ 426 |-|_|-| | _ |-|_| 427 <- | |-|_|-| 428 p1 | 429 MNNs MR1 Internet AR HA1 431 Figure 8: (n,n,n): Multiple MRs, HAs, and MNPs 433 3. Deployment Scenarios and Prerequisites 435 The following generic goals and benefits of multihoming are discussed 436 in a companion document [6]: 438 1. Permanent and Ubiquitous Access 440 2. Redundancy/Fault-Recovery 442 3. Load Sharing 444 4. Load Balancing 446 5. Preference Settings 448 These benefits are now illustrated from a NEMO perspective with a 449 typical instance scenario for each case in the taxonomy. We then 450 discuss the prerequisites to fulfill these. 452 3.1 Deployment Scenarios 454 x=1: Multihomed mobile network with a single MR 456 o Example: an MR with dual/multiple access interfaces (e.g. 457 802.11 and GPRS capabilities). This is a S/P-(1,1,*) if both 458 accesses are subscribed to the same ISP. If the two accesses 459 are offered by independent ISPs, this is a S/mP-(1,n,n) [for 460 the meaning of this abbreviation, see Appendix A.1]. 462 Benefits: Ubiquity, Redundancy/Fault-Recovery, Load Sharing, 463 Preference Settings 465 x=N: Multihomed mobile networks with multiple MRs 467 o Example 1: a train with one MR in each car, all served by the 468 same HA, thus a (n,1,*). Alternatively, the train company 469 might be forced to use different ISP when the train go to 470 different locations, thus it is a (n,n,n). 472 Benefits: Load Sharing, Redundancy/Fault-Recovery, Ubiquity 474 o Example 2: W-PAN with a GPRS_enabled phone and a WiFi-enabled 475 PDA. This is a S/mP-(n,n,n) if the two access technologies are 476 subscribed separately. 478 Benefits: Ubiquity, Redundancy/Fault-Recovery, Preference 479 Settings 481 y=1: Multihomed mobile networks with a single HA 483 o Most single ISP cases in above examples. 485 y=N: Multihomed mobile networks with multiple HAs 487 o Most multiple ISP cases in above examples. 489 o Example: a transatlantic flight with a HA in each continent. 490 This is a (1,n,1) network if there is only one MR. 492 Benefits: Ubiquity (reduced delay, shortest path) 494 z=1: Multihomed mobile networks with a single MNP 496 o Most single ISP cases in above examples. 498 z=N: Multihomed mobile networks with multiple MNPs 500 o Most multiple ISP cases in above examples. 502 o Example: a car with a prefix taken from home (personal traffic 503 transit on this prefix and is paid by the owner) and one that 504 belongs to the car manufacturer (maintenance traffic is paid by 505 the car-manufacturer). This will typically be a (1,1,n). 507 Benefits: preference settings 509 3.2 Prerequisites 511 In this section, we try to define the requirements in order to 512 fulfill the expected multihoming benefits as detailed in [6]. 514 At least one bi-directional tunnel must be available at any point in 515 time between the mobile network and the fixed network to meet all 516 expectations. But for most goals to be effective, multiple tunnels 517 must be maintained simultaneously: 519 o Permanent and Ubiquitous Access: 521 At least one bi-directional tunnel must be available at any point 522 in time. 524 o Redundancy and Fault-Recovery: 526 Both the inbound and outbound traffic must be transmitted or 527 diverted over another bi-directional tunnel once a bi-directional 528 tunnel is broken or disrupted. 530 o Load Sharing and Load Balancing: 532 Multiple tunnels must be maintained simultaneously. 534 o Preference Settings: 536 Implicitly, multiple tunnels must be maintained simultaneously if 537 preferences are set for deciding which of the available 538 bi-directional tunnels should be used. A mechanism must be 539 provided to the user/application about the availability of 540 multiple bi-direction tunnels, and perhaps also to set the 541 preference. The preference may reside in the mobile router or 542 mobile network nodes (using [9] for instance). 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 570 to/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.10 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. This could 613 occur if different MNPs are handled by different home agents. If 614 packet with a source address configured from a specific MNP is 615 tunnelled to a home agent that does not handle that specific MNP, the 616 packet may be discarded due to ingress filtering (either by the home 617 agent or by a border gateway in the home network). 619 As an example of how this could happen, consider the deployment 620 scenario illustrated in Figure 9. In Figure 9, the mobile network 621 has two mobile routers MR1 and MR2, with home agents HA1 and HA2 622 respectively. Two bi-directional tunnels are established are 623 established between the two pairs. Each mobile router advertises a 624 different MNP (P1 and P2). MNP P1 is registered to HA1, and MNP P2 625 is registered to HA2. Thus, MNNs should be free to auto-configure 626 their addresses on any of P1 or P2. Ingress filtering could thus 627 happen in two cases: 629 o If the two tunnels are available, MNN cannot forward packet with 630 source address equals P1.MNN to MR2. This would cause ingress 631 filtering at HA2 to occur (or even at MR2). This is contrary to 632 normal Neighbor Discovery [11] practice that an IPv6 node is free 633 to choose any router as its default router regardless of the 634 prefix it chooses to use. A simple solution is to require all 635 MNNs to set their default router to the MR that advertises the MNP 636 the MNNs configured their addresses from. If such requirement is 637 not placed on mobile network nodes, then a multihoming solution 638 for mobile networks must address this problem. For a possible 639 approach, see [12]. However, this is not enough to maintain 640 connectivity if a tunnel fails (see Section 4.1 for a discussion 641 of this issue). 643 o If the tunnel to HA1 is broken, packets would be sent through the 644 tunnel to HA1 are diverted through the tunnel to HA2. If HA2 (or 645 some border gateway in the domain of HA2) performs ingress 646 filtering, packets with source address configured from MNP P1 may 647 be discarded. It should be noted that this problem may be faced 648 by any (*,n,n) mobile network, even if MR1 and MR2 are in fact the 649 same entity in Figure 9. 651 To avoid ingress filtering mechanisms dropping packets in such 652 situations, MR(s) can stop advertising P1. This would prevent MNNs 653 from using the address auto-configured on this prefix. However, such 654 a method suffers from the following two limitations: 656 o Switching addresses is time consuming since nodes have to wait for 657 addresses to get deprecated [9]. 659 o Switching addresses force transport sessions without multihoming 660 capabilities (such as TCP) to terminate, and be re-established 661 using the alternative source address. Transport sessions with 662 multihoming capabilities (such as SCTP) may be able to continue 663 without disruption (see also Section 4.1) 665 Although one way to avoid the long wait for address deprecation by 666 sending a router advertisement with zero Lifetime, the 667 termination/disruption of transport sessions may render this solution 668 unattractive. It is possible to overcome these limitations by using 669 nested tunnels. Appendix B describes one such approach. 671 Prefix: P1 +-----+ +----+ +----------+ +-----+ 672 +--| MR1 |--| AR |--| |---| HA1 | 673 | +-----+ +----+ | | +-----+ 674 IP: +-----+ | | | Prefix: P1 675 P1.MNN or | MNN |--+ | Internet | 676 P2.MNN +-----+ | | | Prefix: P2 677 | +-----+ +----+ | | +-----+ 678 +--| MR2 |--| AR |--| |---| HA2 | 679 Prefix: P2 +-----+ +----+ +----------+ +-----+ 681 Figure 9: An (n,n,n) mobile network 683 4.4 Failure Detection 685 It is expected for faults to occur more readily at the edge of the 686 network (i.e. the mobile nodes), due to the use of wireless 687 connections. Efficient fault detection mechanisms are necessary to 688 recover in timely fashion. In order for fault recovery to work, the 689 MRs and HAs must first possess a means to detect failures: 691 o On the MR's side, the MR can also rely on router advertisements 692 from access routers, or other layer-2 trigger mechanisms to detect 693 faults, e.g. [13] or [14]. (For a related issue, see Section 694 4.5.) 696 o On the HA's side, it is more difficult for HAs to detect tunnel 697 failures. For an ISP deployment model, the HAs and MRs can use 698 proprietary methods (such as constant transmission of heartbeat 699 signals) to detect failures and check tunnel liveness. In the S/P 700 model (see Appendix A.2), a lack of standardized "tunnel liveness" 701 protocol means that it is harder to detect failures. 703 A possible method is for the MRs to send binding updates more 704 regularly with shorter Lifetime values. Similarly, HAs can return 705 binding acknowledgment messages with smaller Lifetime values, thus 706 forcing the MRs to send binding updates more frequently. These 707 binding updates can be used to emulate "tunnel heartbeats". This 708 however may lead to more traffic and processing overhead, since 709 binding updates sent to HAs must be protected (and possibly 710 encrypted) with security associations. 712 There are other failure modes to consider as well, such as failure at 713 home agent, failure at access routers, or in general failure of a 714 link or node along the path from the mobile router to the home agent. 715 By the nature of the routing infrastructure, failure of intermediate 716 nodes or links are recovered by the the routing infrastructure by 717 choosing a different route. For those failures that can't be 718 receovered (such a failure of the access router), a heartbeadt 719 protocol or the use of small-lifetime binding updates described above 720 can also be used to detect tunnel failures. 722 4.5 Media Detection 724 In order to achieve benefits such as ubiquity or fault recovery, it 725 is necessary for mobile router to detect the availability of network 726 media. This may be achieved using layer 2 triggers [13], or other 727 mechanism developed/recommended by the Detecting Network Attachment 728 (DNA) Working Group. 730 This is related to Section 4.4, since the ability to detect media 731 availability would often implies the ability to detect media 732 in-availability. 734 4.6 HA Synchronization 736 In the (*,n,1) mobile networks, a single MNP would be registered at 737 different HAs. This gives rise to the following issues: 739 o Only one HA may actively advertise a route to the MNP. 741 o Multiple HAs at different domains may advertise a route to the 742 same MNP 744 This may pose a problem in the routing infrastructure as a whole. 745 The implications of this aspect needs further exploration. Certain 746 level of HA co-ordination may be required. A possible approach is to 747 adopt a HA synchronization mechanism such as that described in [15] 748 and [16]. Such synchronization might also be necessary in a (*,n,*) 749 mobile network, when a MR sends binding update messages to only one 750 HA (instead of all HAs). In such cases, the binding update 751 information might have to be synchronized betweeen HAs. The mode of 752 synchoronization may be either primary-secondary or peer-to-peer. 753 See also Section 4.7. 755 4.7 MR Synchronization 757 In the (n,*,*) mobile network, different MRs may need to be 758 synchronized in order to take common decisions. The mode of 759 synchoronization may be either primary-secondary or peer-to-peer. 760 This may include: 762 o In the (n,*,1) case, advertising the same MNP (see also "prefix 763 delegation" in Section 4.8). 765 o In the (n,*,n) case, a MR relaying the advertisement of the MNP 766 from another failed MR. 768 o In the (n,*,*) cases, relaying between MRs everything that needs 769 to be relayed, such as data packets, creating a tunnel from the 770 ingress interface, etc. 772 4.8 Prefix Delegation 774 In the (*,*,1) mobile network, the same MNP must be advertised to the 775 MNNs through different paths. This questions how to perform prefix 776 delegation: 778 o For the (*,n,1) mobile network, how multiple HAs would delegate 779 the same MNP to the mobile network. For doing so, the HAs may be 780 somehow configured to advertise the same MNP. (see also "HA 781 Synchronization" in Section 4.6). 783 o For the (n,*,n) mobile network, how multiple mobile routers would 784 be synchronized to advertise the same MNP down the NEMO-link. For 785 doing so, the MRs may be somehow configured to advertise the same 786 MNP (see also "MR Synchronization" in Section 4.7). 788 This could be configured manually, or dynamically. Alternatively, 789 prefix delegation mechanisms [17][18] could be used to ensure all 790 routers advertise the same MNP. 792 4.9 Multiple Bindings/Registrations 794 When a MR is configured with multiple Care-of Addresses, it is often 795 necessary for it to bind these Care-of Addresses to the same MNP. 797 This is a generic issue, since Mobile IPv6 nodes face a similar 798 problem if they wish to bind multiple Care-of Addresses to the same 799 Home Address". This is better discussed in [7]. It is sufficient to 800 note that solutions like [19] can solve this. 802 4.10 Source Address Selection 804 In the (*,*,n) mobile networks, MNNs would be configured with 805 multiple addresses. Source address selection mechanisms are needed 806 to decide which address to choose from. 808 It may be desirable for MNN to be able to acquire "preference" 809 information on each MNP from the MRs. This allows default address 810 selection mechanism such as that specified in [9] to be used. 811 Further exploration on setting such "preference" information in 812 Router Advertisement based on performance of the bi-directional 813 tunnel might prove to be useful. 815 4.11 Impact on the Routing Infrastructure 817 In the (1,n,1) case with HAs located in distinct ISPs/ASs, multiple 818 routes directed to the mobile network may be advertised in the 819 Internet. Although this may provide shorter paths, it also adds 820 burden to routing tables as multiple routes to the same prefix are 821 injected into the routing infrastructure. Such issues are 822 investigated in the MULTI6 working group at the IETF. 824 4.12 Nested Mobile Networks 826 When a multihomed mobile network is nested within another mobile 827 network, it can result in very complex topologies. For instance, a 828 nested mobile network may be attached two different root-MRs, thus 829 the aggregated network no longer forms a simple tree structure. As 830 such, a solution to prevent an infinite loop must be provided. 832 4.13 Split Mobile Networks 834 When a (n,*,1) network splits, (i.e. the two MRs split themselves 835 up), the only available MNP will then be registered by two different 836 MRs on different links. This cannot be allowed, as the HA has no way 837 to know which node with an address configured from that MNP is 838 attached to which MR. Some mechanism must be present for the MNP to 839 either be forcibly removed from one (or all) MRs, or the implementors 840 must not allow a (n,*,1) network to split. 842 A possible approach to solving this problem is described in [20]. 844 5. Conclusion 846 This document is an analysis of multihoming in the context of network 847 mobility. The purpose of this memo is to investigate issues related 848 to such a bi-directional tunneling mechanism when mobile networks are 849 multihomed. 851 Several issues that might impact the deployment of NEMO with 852 multihoming capabilities were identified in Section 4. They include: 854 1. Path Survival 856 2. Path Availability 858 3. Ingress Filtering 860 4. Failure Detection 862 5. Media Detection 864 6. HA Synchronization 866 7. MR Synchronization 868 8. Prefix Delegation 870 9. Multiple Binding/Registrations 872 10. Source Address Selection 874 11. Imapct on the Routing Infrastructure 876 12. Nested Mobile Networks 878 13. Split Mobile Networks. 880 This study is a work in progress and need to be improved by a 881 thorough study of each individual issues. Particularly, this memo 882 should be completed by a thorough threat analysis of multihoming 883 configurations of mobile network. We will add security threat issues 884 here as and when they are encountered, such as those described in 885 [21]. We also encourage interested people to contribute to this 886 part. 888 6. Acknowledgments 890 The authors would like to thank people who have given valuable 891 comments on various multihoming issues on the mailing list, and also 892 those who have suggested directions in the 56th - 60th IETF Meetings. 893 Sincere gratitude is also extended to Marcelo Bagnulo Braun for his 894 extensive review and comments on the -00 version of this draft. The 895 initial evaluation of NEMO Basic Support is a contribution from 896 Julien Charbon. 898 7 References 900 [1] Ernst, T., "Network Mobility Support Goals and Requirements", 901 draft-ietf-nemo-requirements-03 (work in progress), October 902 2004. 904 [2] Manner, J. and M. Kojo, "Mobility Related Terminology", RFC 905 3753, June 2004. 907 [3] Ernst, T. and H. Lach, "Network Mobility Support Terminology", 908 draft-ietf-nemo-terminology-02 (work in progress), October 909 2004. 911 [4] Devarapalli, V., "Network Mobility (NEMO) Basic Support 912 Protocol", draft-ietf-nemo-basic-support-03 (work in progress), 913 June 2004. 915 [5] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in 916 IPv6", RFC 3775, June 2004. 918 [6] Ernst, T., Montavont, N., Wakikawa, R. and E-K. Paik, "Goals 919 and Benefits of Multihoming", 920 draft-ernst-generic-goals-and-benefits-00 (work in progress), 921 July 2004. 923 [7] Montavont, N., Wakikawa, R. and T. Ernst, "Analysis of 924 Multihoming in Mobile IPv6", 925 draft-montavont-mobileip-multihoming-pb-statement-01 (work in 926 progress), Feb 2004. 928 [8] Ernst, T. and J. Charbon, "Multihoming with NEMO Basic 929 Support", Proceedings First International Conference on Mobile 930 Computing and Ubiquitous Networking (ICMU), January 2004. 932 [9] Draves, R., "Default Address Selection for Internet Protocol 933 version 6 (IPv6)", RFC 3484, February 2003. 935 [10] Montavont, N., Noel, T. and M. Kassi-Lahlou, "MIPv6 for 936 Multiple Interfaces", draft-montavont-mobileip-mmi-02 (work in 937 progress), October 2003. 939 [11] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery 940 for IP Version 6 (IPv6)", RFC 2461, December 1998. 942 [12] Draves, R. and D. Thaler, "Default Router Preferences and 943 More-Specific Routes", draft-ietf-ipv6-router-selection-06 944 (work in progress), October 2004. 946 [13] Yegin, A., "Link-layer Hints for Detecting Network 947 Attachments", draft-yegin-dna-l2-hints-01 (work in progress), 948 February 2004. 950 [14] Yegin, A., "Supporting Optimized Handover for IP Mobility 951 -Requirements for Underlying Systems", 952 draft-manyfolks-l2-mobilereq-02 (work in progress), July 2002. 954 [15] Wakikawa, R., Devarapalli, V. and P. Thubert, "Inter Home 955 Agents Protocol (HAHA)", draft-wakikawa-mip6-nemo-haha-01 (work 956 in progress), February 2004. 958 [16] Koh, B., Ng, C. and J. Hirano, "Dynamic Inter Home Agent 959 Protocol", draft-koh-mip6-nemo-dhap-00 (work in progress), July 960 2004. 962 [17] Miyakawa, S. and R. Droms, "Requirements for IPv6 Prefix 963 Delegation", RFC 3769, June 2004. 965 [18] Droms, R. and P. Thubert, "DHCPv6 Prefix Delegation for NEMO", 966 draft-droms-nemo-dhcpv6-pd-01 (work in progress), February 967 2004. 969 [19] Wakikawa, R., "Multiple Care-of Addresses Registration", 970 draft-wakikawa-mobileip-multiplecoa-03 (work in progress), July 971 2004. 973 [20] Kumazawa, M., "Token based Duplicate Network Detection for 974 split mobile network (Token based DND)", 975 draft-kumazawa-nemo-tbdnd-01 (work in progress), October 2004. 977 [21] Choi, S., "Threat for Multi-homed Mobile Networks", 978 draft-cho-nemo-threat-multihoming-00 (work in progress), 979 February 2004. 981 Authors' Addresses 983 Chan-Wah Ng 984 Panasonic Singapore Laboratories Pte Ltd 985 Blk 1022 Tai Seng Ave #06-3530 986 Tai Seng Industrial Estate 987 Singapore 534415 988 SG 990 Phone: +65 65505420 991 EMail: cwng@psl.com.sg 993 Eun Kyoung Paik 994 KT 995 Portable Internet Team, Convergence Lab., KT 996 17 Woomyeon-dong, Seocho-gu 997 Seoul 137-792 998 Korea 1000 Phone: +82-2-526-5233 1001 Fax: +82-2-526-5200 1002 EMail: euna@kt.co.kr 1003 URI: http://mmlab.snu.ac.kr/~eun/ 1005 Thierry Ernst 1006 WIDE at Keio University 1007 Jun Murai Lab., Keio University. 1008 K-square Town Campus, 1488-8 Ogura, Saiwa-Ku 1009 Kawasaki, Kanagawa 212-0054 1010 Japan 1012 Phone: +81-44-580-1600 1013 Fax: +81-44-580-1437 1014 EMail: ernst@sfc.wide.ad.jp 1015 URI: http://www.sfc.wide.ad.jp/~ernst/ 1017 Appendix A. Alternative Classifications Approach 1019 A.1 Ownership-Oriented Approach 1021 An alternative approach to classifying multihomed mobile network is 1022 proposed by Erik Nordmark (Sun Microsystems) by breaking the 1023 classification of multihomed network based on ownership. This is 1024 more of a tree-like top-down classification. Starting from the 1025 control and ownership of the HA(s) and MR(s), there are two different 1026 possibilities: either (i) the HA(s) and MR(s) are controlled by a 1027 single entity, or (ii) the HA(s) and MR(s) are controlled by separate 1028 entities. We called the first possibility the 'ISP Model', and the 1029 second the 'Subscriber/Provider Model'. 1031 A.1.1 ISP Model 1033 The case of the HA(s) and MR(s) are controlled by the same entity can 1034 be best illustrated as an Internet Service Provider (ISP) installing 1035 mobile routers on trains, ships or planes. It is up to the ISP to 1036 deploy a certain configuration of mobile network; all 8 1037 configurations as described in the Configuration-Oriented Approach 1038 are possible. In the remaining portion of this document, when 1039 specifically referring to a mobile network configuration that is 1040 controlled by a single entity, we will add an 'ISP' prefix: for 1041 example: ISP-(1,1,1) or ISP-(1,N,N). 1043 When the HA(s) and MR(s) are controlled by a single entity (such as 1044 an ISP), the ISP can decide whether it wants to assign one or 1045 multiple MNPs to the mobile network just like it can make the same 1046 decision for any other link in its network (wired or otherwise). In 1047 any case, the ISP will make the routing between the mobile networks 1048 and its core routers (such as the HAs) work. This include not 1049 introducing any aggregation between the HAs which will filter out 1050 routing announcements for the MNP(es). 1052 To such ends, the ISP has various means and mechanisms. For one, the 1053 ISP can run its Interior Gateway Protocol (IGP) over bi-directional 1054 tunnels between the MR(s) and HA(s). Alternatively, static routes 1055 may be used with the tunnels. When static routes are used, a 1056 mechanism to test "tunnel liveness" might be necessary to avoid 1057 maintaining stale routes. Such "tunnel liveness" may be tested by 1058 sending heartbeats signals from MR(s) to the HA(s). A possibility is 1059 to simulate heartbeats using Binding Updates messages by controlling 1060 the "Lifetime" field of the Binding Acknowledgment message to force 1061 the MR to send Binding Update messages at regular interval. However, 1062 a more appropriate tool might be the Binding Refresh Request message, 1063 though conformance to the Binding Refresh Request message may be less 1064 strictly enforced in implementations since it serves a somewhat 1065 secondary role when compared to Binding Update messages. 1067 A.1.2 Subscriber/Provider Model 1069 The case of the HA(s) and MR(s) are controlled by the separate 1070 entities can be best illustrated with a subscriber/provider model, 1071 where the MRs belongs to a single subscriber and subscribes to one or 1072 more ISPs for HA services. There is two sub-categories in this case: 1073 when the subscriber subscribes to a single ISP, and when the 1074 subscriber subscribes to multiple ISPs. In the remaining portion of 1075 this document, when specifically referring to a mobile network 1076 configuration that is in the subscriber/provider model where the 1077 subscriber subscribes to only one ISP, we will add an 'S/P' prefix: 1078 for example: S/P-(1,1,1) or S/P-(1,n,n). When specifically referring 1079 to a mobile network configuration that is in the subscriber/provider 1080 model where the subscriber subscribes to multiple ISPs, we will add 1081 an 'S/mP' prefix: for example: S/mP-(1,1,1) or S/mP-(1,n,n). 1083 Not all 8 configurations are likely to be deployed for the S/P and 1084 S/mP models. For instance, it is unlikely to foresee a S/mP-(*,1,1) 1085 mobile network where there is only a single HA. For the S/P model, 1086 the following configurations are likely to be deployed: 1088 o S/P-(1,1,1): Single Provider, Single MR, Single HA, Single MNP 1090 o S/P-(1,1,n): Single Provider, Single MR, Single HA, Multiple MNPs 1092 o S/P-(1,n,1): Single Provider, Single MR, Multiple HAs, Single MNP 1094 o S/P-(1,n,n): Single Provider, Single MR, Multiple HAs, Multiple 1095 MNPs 1097 o S/P-(n,n,1): Single Provider, Multiple MRs, Single HA, Single MNP 1099 o S/P-(n,1,n): Single Provider, Multiple MRs, Single HA, Multiple 1100 MNPs 1102 o S/P-(n,n,1): Single Provider, Multiple MRs, Multiple HAs, Single 1103 MNP 1105 o S/P-(n,n,n): Single Provider, Multiple MRs, Multiple HAs, Multiple 1106 MNPs 1108 For the S/mP model, the following configurations are likely to be 1109 deployed: 1111 o S/mP-(1,n,1): Multiple Providers, Single MR, Multiple HAs, Single 1112 MNP 1114 o S/mP-(1,n,n): Multiple Providers, Single MR, Multiple HAs, 1115 Multiple MNPs 1117 o S/mP-(n,n,n): Multiple Providers, Multiple MRs, Multiple HAs, 1118 Multiple MNPs 1120 When the HA(s) and MR(s) are controlled by different entities, it is 1121 more likely the scenario where the MR is controlled by one entity 1122 (i.e. the subscriber), and the MR is establishing multiple 1123 bi-directional tunnels to one or more HA(s) provided by one or more 1124 ISP(s). In such case, it is unlikely for the ISP to run IGP over the 1125 bi-directional tunnel, since ISP would most certainly wish to retain 1126 full control of its routing domain. 1128 A.2 Problem-Oriented Approach 1130 A third approach is proposed by Pascal Thubert (Cisco System). This 1131 focused on the problems of multihomed mobile networks rather than the 1132 configuration or ownership. With this approach, there is a set of 4 1133 categories based on two orthogonal parameters: the number of HAs, and 1134 the number of MNPs advertised. Since the two parameters are 1135 orthogonal, the categories are not mutually exclusive. The four 1136 categories are: 1138 o Tarzan: Single HA for Different Care-of Addresses of Same MNP 1140 This is the case where one mobile router registers different 1141 Care-of Addresses to the same home agent for the same subnet 1142 prefix. This is equivalent to the case of y=1, i.e. the (1,1,n) 1143 mobile network. 1145 o JetSet: Multiple HAs for Different Care-of Addresses of Same MNP 1147 This is the case where the mobile router registers different 1148 Care-of Addresses to different home agents for the same subnet 1149 prefix. This is equivalent to the case of y=n, i.e. the (1,n,*) 1150 mobile network. 1152 o Shinkansen: Single MNP Advertised by MR(s) 1154 This is the case where one MNP is announced by different MRs. 1155 This is equivalent to the case of z=n, i.e. the (1,*,n) mobile 1156 network. 1158 o DoubleBed: Multiple MNPs Advertised by MR(s) 1160 This is the case where more than one MNPs are announced by the 1161 different MRs. This is equivalent to the case of z=n, i.e. the 1162 (n,*,n) mobile network. 1164 Appendix B. Nested Tunneling for Fault Tolerance 1166 In order to utilize the additional robustness provided by 1167 multihoming, MRs that employ bi-directional tunneling with their HAs 1168 should dynamically change their tunnel exit points depending on the 1169 link status. For instance, if a MR detects that one of its egress 1170 interface is down, it should detect if any other alternate route to 1171 the global Internet exists. This alternate route may be provided by 1172 any other MRs connected to one of its ingress interfaces that has an 1173 independent route to the global Internet, or by another active egress 1174 interface the MR itself possess. If such an alternate route exists, 1175 the MR should re-establish the bi-directional tunnel using this 1176 alternate route. 1178 In the remaining part of this section, we will attempt to investigate 1179 methods of performing such re-establishment of bi-directional 1180 tunnels. It is not the objective of this memo to specify a new 1181 protocol specifically tailored to provide this form of re- 1182 establishments. Instead, we will limit ourselves to currently 1183 available mechanisms specified in Mobile IPv6 [5] and Neighbor 1184 Discovery in IPv6 [11]. 1186 B.1 Detecting Presence of Alternate Routes 1188 To actively utilize the robustness provided by multihoming, a MR must 1189 first be capable of detecting alternate routes. This can be manually 1190 configured into the MR by the administrators if the configuration of 1191 the mobile network is relatively static. It is however highly 1192 desirable for MRs to be able to discover alternate routes 1193 automatically for greater flexibility. 1195 The case where a MR possesses multiple egress interface (bound to the 1196 same HA or otherwise) should be trivial, since the MR should be able 1197 to "realize" it has multiple routes to the global Internet. 1199 In the case where multiple MRs are on the mobile network, each MR has 1200 to detect the presence of other MR. A MR can do so by listening for 1201 Router Advertisement message on its *ingress* interfaces. When a MR 1202 receives a Router Advertisement message with a non-zero Router 1203 Lifetime field from one of its ingress interfaces, it knows that 1204 another MR which can provide an alternate route to the global 1205 Internet is present in the mobile network. 1207 B.2 Re-Establishment of Bi-Directional Tunnels 1209 When a MR detects that the link by which its current bi-directional 1210 tunnel with its HA is using is down, it needs to re-establish the 1211 bi-directional tunnel using an alternate route detected. We consider 1212 two separate cases here: firstly, the alternate route is provided by 1213 another egress interface that belongs to the MR; secondly, the 1214 alternate route is provided by another MR connected to the mobile 1215 network. We refer to the former case as an alternate route provided 1216 by an alternate egress interface, and the latter case as an alternate 1217 route provided by an alternate MR. 1219 B.2.1 Using Alternate Egress Interface 1221 When an egress interface of a MR loses the connection to the global 1222 Internet, the MR can make use of its alternate egress interface 1223 should it possess multiple egress interfaces. The most direct way to 1224 do so is for the mobile router to send a binding update to the home 1225 agent of the failed interface using the Care-of Address assigned to 1226 the alternate interface in order to re-establish the bi-directional 1227 tunneling using the Care-of Address on the alternate egress 1228 interface. After a successful binding update, the MR encapsulates 1229 outgoing packets through the bi-directional tunnel using the 1230 alternate egress interface. 1232 The idea is to use the global address (most likely a Care-of Address) 1233 assigned to an alternate egress interface as the new (back-up) 1234 Care-of Address of the mobile router to re-establish the 1235 bi-directional tunneling with its home agent. 1237 B.2.2 Using Alternate Mobile Router 1239 When the MR loses a connection to the global Internet, the MR can 1240 utilize a route provided by an alternate MR (if one exists) to 1241 re-establish the bi-directional tunnel with its HA. First, the MR 1242 has to obtain a Care-of Address from the alternate MR (i.e. attaches 1243 itself to the alternate MR). Next, it sends binding update to its HA 1244 using the Care-of Address obtained from the alternate MR. From then 1245 on, the MR can encapsulates outgoing packets through the 1246 bi-directional tunnel using via the alternate MR. 1248 The idea is to obtain a Care-of Address from the alternate MR and use 1249 this as the new (back-up) Care-of Address of the MR to re-establish 1250 the bi-directional tunneling with its HA. 1252 Note that every packet sent between MNNs and their correspondent 1253 nodes will experience two levels of encapsulation. First level of 1254 tunneling occurs between a MR which the MNN uses as its default 1255 router and the MR's HA. The second level of tunneling occurs between 1256 the alternate MR and its HA. 1258 B.3 To Avoid Tunneling Loop 1260 The method of re-establishing the bi-directional tunnel as described 1261 in Appendix B.2 may lead to infinite loops of tunneling. This 1262 happens when two MRs on a mobile network lose connection to the 1263 global Internet at the same time and each MR tries to re-establish 1264 bi-directional tunnel using the other MR. We refer to this 1265 phenomenon as tunneling loop. 1267 One approach to avoid tunneling loop is for a MR that has lost 1268 connection to the global Internet to insert an option into the Router 1269 Advertisement message it broadcasts periodically. This option serves 1270 to notify other MRs on the link that the sender no longer provides 1271 global connection. Note that setting a zero Router Lifetime field 1272 will not work well since it will cause MNNs that are attached to the 1273 MR to stop using the MR as their default router too (in which case, 1274 things are back to square one). 1276 Appendix C. Change Log 1278 o This draft is an update of draft-ng-nemo-multihoming-issues-03.txt 1279 which is itself a merge of 3 previous drafts 1280 draft-ng-nemo-multihoming-issues-02.txt, 1281 draft-eun-nemo-multihoming-problem-statement-00.txt, and 1282 draft-charbon-nemo-multihoming-evaluation-00.txt 1284 o Changes from draft-ietf-nemo-multihoming-issues-00 to -01: 1286 * Replaced NEMO-Prefix with MNP as decided by the WG at 60th IETF 1288 * Addressed Issue #1 in Section 1: Added a note to remind readers 1289 that IPv6 is implicitly assumed 1291 * Addressed Issue #3 in Section 2.3: Removed text on assumption 1293 * Addressed Issue #6 in Section 3.1: Added benefits 1295 * Addressed Issue #7 in Section 3.2: Modified text 1297 * Addressed Issue #9 in Section 4.3: Modified text 1299 * Addressed Issue #10 in Section 4.4: Added paragraph on other 1300 failure modes 1302 * Addressed Issue #10: New Section 4.5 on media detection 1304 * Addressed Issue #11 in Section 4.11: modified text 1306 o Changes from draft-ng-multihoming-issues-03 to 1307 draft-ietf-nemo-multihoming-issues-00: 1309 * Expanded "Problem Statement" (Section 4) 1311 * Merged "Evaluation" Section into "Problem Statement" (Section 1312 4) 1314 * Cleaned up description in "Classification" (Section 2), and 1315 clearly indicate in each classification, what are the 1316 multihomed entities 1318 * Re-organized "Deployment Scenarios and Prerequisites" (Section 1319 3), and created the "Prerequisites" sub-section. 1321 o Changes from draft-ng-multihoming-issues-02 to 1322 draft-ng-multihoming-issues-03: 1324 * Merged with draft-eun-nemo-multihoming-problem-statement (see 1325 "Problem Statement" (Section 4)) 1327 * Included conclusions from 1328 draft-charbon-nemo-multihoming-evaluation-00 1330 * Re-organized some part of "Benefits/Issues of Multhoming in 1331 NEMO" to "Problem Statement" (Section 4) 1333 * Removed lots of text to be in sync with [6]. 1335 * Title changed from "Multihoming Issues in NEMO Basic Support" 1336 to "Analysis of Multihoming in NEMO" 1338 * Changed (w,x,y) to (x,y,z) in taxonomy. 1340 * Moved alternative approaches of classification to Appendix 1342 * Creation of this Change-Log itself ;-) 1344 Intellectual Property Statement 1346 The IETF takes no position regarding the validity or scope of any 1347 Intellectual Property Rights or other rights that might be claimed to 1348 pertain to the implementation or use of the technology described in 1349 this document or the extent to which any license under such rights 1350 might or might not be available; nor does it represent that it has 1351 made any independent effort to identify any such rights. Information 1352 on the procedures with respect to rights in RFC documents can be 1353 found in BCP 78 and BCP 79. 1355 Copies of IPR disclosures made to the IETF Secretariat and any 1356 assurances of licenses to be made available, or the result of an 1357 attempt made to obtain a general license or permission for the use of 1358 such proprietary rights by implementers or users of this 1359 specification can be obtained from the IETF on-line IPR repository at 1360 http://www.ietf.org/ipr. 1362 The IETF invites any interested party to bring to its attention any 1363 copyrights, patents or patent applications, or other proprietary 1364 rights that may cover technology that may be required to implement 1365 this standard. Please address the information to the IETF at 1366 ietf-ipr@ietf.org. 1368 Disclaimer of Validity 1370 This document and the information contained herein are provided on an 1371 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1372 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1373 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1374 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1375 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1376 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1378 Copyright Statement 1380 Copyright (C) The Internet Society (2004). This document is subject 1381 to the rights, licenses and restrictions contained in BCP 78, and 1382 except as set forth therein, the authors retain all their rights. 1384 Acknowledgment 1386 Funding for the RFC Editor function is currently provided by the 1387 Internet Society.