idnits 2.17.00 (12 Aug 2021) /tmp/idnits5114/draft-ietf-nemo-multihoming-issues-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 20. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1905. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1882. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1889. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1895. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 1412 has weird spacing: '... (Token based...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 22, 2006) is 5812 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: draft-ietf-nemo-requirements has been published as RFC 4886 ** 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: draft-ietf-nemo-terminology has been published as RFC 4885 ** 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 (-03) exists of draft-ietf-monami6-multihoming-motivation-scenario-00 == Outdated reference: A later version (-05) exists of draft-ietf-monami6-mipv6-analysis-00 == Outdated reference: draft-ietf-shim6-failure-detection has been published as RFC 5534 == Outdated reference: draft-ietf-dna-link-information has been published as RFC 4957 == Outdated reference: A later version (-03) exists of draft-ietf-dna-hosts-02 == Outdated reference: A later version (-02) exists of draft-ietf-dna-routers-01 -- Obsolete informational reference (is this intentional?): RFC 2461 (ref. '15') (Obsoleted by RFC 4861) -- No information found for draft-koh-mip6-nemo-dhap - is the name correct? == Outdated reference: A later version (-02) exists of draft-ietf-nemo-prefix-delegation-00 == Outdated reference: draft-ietf-monami6-multiplecoa has been published as RFC 5648 -- Obsolete informational reference (is this intentional?): RFC 3484 (ref. '27') (Obsoleted by RFC 6724) == Outdated reference: A later version (-08) exists of draft-thubert-tree-discovery-02 == Outdated reference: A later version (-03) exists of draft-ietf-nemo-dhcpv6-pd-00 Summary: 7 errors (**), 0 flaws (~~), 15 warnings (==), 10 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: December 24, 2006 E. Paik 5 KT 6 T. Ernst 7 INRIA 8 M. Bagnulo 9 UC3M 10 June 22, 2006 12 Analysis of Multihoming in Network Mobility Support 13 draft-ietf-nemo-multihoming-issues-06 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of BCP 79. 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 Internet- 25 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 December 24, 2006. 40 Copyright Notice 42 Copyright (C) The Internet Society (2006). 44 Abstract 46 This document is an analysis of multihoming in the context of network 47 mobility (NEMO) in IPv6. As there are many situations in which 48 mobile networks may be multihomed, a taxonomy is proposed to classify 49 the possible configurations. The possible deployment scenarios of 50 multihomed mobile networks are described together with the associated 51 issues when network mobility is supported by RFC 3963 (NEMO Basic 52 Support). Recommendations are offered on how to address these 53 issues. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 2. Classification . . . . . . . . . . . . . . . . . . . . . . . . 6 60 2.1. (1,1,1): Single MR, Single HA, Single MNP . . . . . . . . 7 61 2.2. (1,1,n): Single MR, Single HA, Multiple MNPs . . . . . . . 8 62 2.3. (1,n,1): Single MR, Multiple HAs, Single MNP . . . . . . . 8 63 2.4. (1,n,n): Single MR, Multiple HAs, Multiple MNPs . . . . . 9 64 2.5. (n,1,1): Multiple MRs, Single HA, Single MNP . . . . . . . 10 65 2.6. (n,1,n): Multiple MRs, Single HA, Multiple MNPs . . . . . 10 66 2.7. (n,n,1): Multiple MRs, Multiple HAs, Single MNP . . . . . 11 67 2.8. (n,n,n): Multiple MRs, Multiple HAs, Multiple MNPs . . . . 12 69 3. Deployment Scenarios and Prerequisites . . . . . . . . . . . . 13 70 3.1. Deployment Scenarios . . . . . . . . . . . . . . . . . . . 13 71 3.2. Prerequisites . . . . . . . . . . . . . . . . . . . . . . 15 73 4. Multihoming Issues . . . . . . . . . . . . . . . . . . . . . . 16 74 4.1. Fault Tolerance . . . . . . . . . . . . . . . . . . . . . 16 75 4.1.1. Failure Detection . . . . . . . . . . . . . . . . . . 16 76 4.1.2. Path Exploration . . . . . . . . . . . . . . . . . . . 18 77 4.1.3. Path Selection . . . . . . . . . . . . . . . . . . . . 19 78 4.1.4. Re-Homing . . . . . . . . . . . . . . . . . . . . . . 21 79 4.2. Ingress Filtering . . . . . . . . . . . . . . . . . . . . 21 80 4.3. HA Synchronization . . . . . . . . . . . . . . . . . . . . 23 81 4.4. MR Synchronization . . . . . . . . . . . . . . . . . . . . 24 82 4.5. Prefix Delegation . . . . . . . . . . . . . . . . . . . . 24 83 4.6. Multiple Bindings/Registrations . . . . . . . . . . . . . 25 84 4.7. Source Address Selection . . . . . . . . . . . . . . . . . 25 85 4.8. Loop Prevention in Nested Mobile Networks . . . . . . . . 26 86 4.9. Prefix Ownership . . . . . . . . . . . . . . . . . . . . . 26 87 4.10. Preference Settings . . . . . . . . . . . . . . . . . . . 26 89 5. Recommendations to the Working Group . . . . . . . . . . . . . 28 91 6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 31 93 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 95 8. Security Considerations . . . . . . . . . . . . . . . . . . . 31 96 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 31 98 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32 99 10.1. Normative References . . . . . . . . . . . . . . . . . . . 32 100 10.2. Informative References . . . . . . . . . . . . . . . . . . 32 102 Appendix A. Alternative Classifications Approach . . . . . . . . 35 103 A.1. Ownership-Oriented Approach . . . . . . . . . . . . . . . 35 104 A.1.1. ISP Model . . . . . . . . . . . . . . . . . . . . . . 35 105 A.1.2. Subscriber/Provider Model . . . . . . . . . . . . . . 36 106 A.2. Problem-Oriented Approach . . . . . . . . . . . . . . . . 38 108 Appendix B. Nested Tunneling for Fault Tolerance . . . . . . . . 39 109 B.1. Detecting Presence of Alternate Routes . . . . . . . . . . 39 110 B.2. Re-Establishment of Bi-Directional Tunnels . . . . . . . . 40 111 B.2.1. Using Alternate Egress Interface . . . . . . . . . . . 40 112 B.2.2. Using Alternate Mobile Router . . . . . . . . . . . . 40 113 B.3. To Avoid Tunneling Loop . . . . . . . . . . . . . . . . . 41 114 B.4. Points of Considerations . . . . . . . . . . . . . . . . . 41 116 Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 42 118 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 45 119 Intellectual Property and Copyright Statements . . . . . . . . . . 46 121 1. Introduction 123 The design goals and objectives of Network Mobility Support (NEMO) in 124 IPv6 are identified in [1] while the terminology is being described 125 in [2] and [3]. NEMO Basic Support (RFC 3963) [4] is the solution 126 proposed by the NEMO Working Group to provide continuous Internet 127 connectivity to nodes located in an IPv6 mobile network, e.g. like in 128 an in-vehicle embedded IP network. The NEMO Basic Support solution 129 basically solves the problem by setting up bi-directional tunnels 130 between the mobile routers (MRs) connecting the mobile network to the 131 Internet and their respective Home Agents (HAs), much how this is 132 done in Mobile IPv6 [5], the solution for host mobility support. 133 NEMO Basic Support is transparent to nodes located behind the mobile 134 router (i.e. the mobile network nodes, or MNNs) and as such does not 135 require MNNs to take any action in the mobility management. 137 However, mobile networks are typically connected by means of wireless 138 and thus less reliable links; there could also be many nodes behind 139 the MR. A loss of connectivity or a failure to connect to the 140 Internet has thus a more significant impact than for a single mobile 141 node. Scenarios illustrated in [6] demonstrate that providing a 142 permanent access to mobile networks such as vehicles typically 143 require the use of several interfaces and technologies since the 144 mobile network may be moving in distant geographical locations where 145 different access technologies are provided and governed by distinct 146 access control policies. 148 As specified by R.12 in section 5 of [1], the NEMO WG must ensure 149 that NEMO Basic Support does not prevent mobile networks to be 150 multihomed, i.e. when there is more than one point of attachment 151 between the mobile network and the Internet (see definitions in [3]). 152 This arises either: 154 o when a MR has multiple egress interfaces, or 156 o the mobile network has multiple MRs, or 158 o the mobile network is associated with multiple HAs, or 160 o multiple global prefixes are available in the mobile network. 162 Using NEMO Basic Support, this would translate into having multiple 163 bi-directional tunnels between the MR(s) and the corresponding HA, 164 and may result into multiple MNPs available to the MNNs. However, 165 NEMO Basic Support does not specify any particular mechanism to 166 manage multiple bi-directional tunnels. The objective of this memo 167 is thus multi-folded: 169 o to determine all the potential multihomed configurations for a 170 NEMO, and then to identify which of those may be useful in a real 171 life scenario; 173 o to capture issues that may prevent some multihomed configurations 174 to be supported under the operation of NEMO Basic Support. It 175 doesn't necessarily mean that those not supported will not work 176 with NEMO Basic Support, as it may be up to the implementors to 177 make it work (hopefully this memo will be helpful to these 178 implementors); 180 o to identify potential solutions to the previously identified 181 issues; and 183 o to decide which issues are worth to be solved, and to determine 184 which WG should address each of the issues that are worth solving. 186 In order to reach these objectives, a taxonomy to classify the 187 possible multihomed configurations is described in Section 2. 188 Deployment scenarios, their benefits, and requirements to meet these 189 benefits are illustrated in Section 3. Following this, the related 190 issues are studied in Section 4. The issues are then summarized in a 191 matrix for each of the deployment scenario, and recommendations are 192 made on which of the issues should be worked on and where in 193 Section 5. This memo concludes with an evaluation of NEMO Basic 194 Support for multihomed configurations. Alternative classifications 195 are outlined in the Appendix. 197 The readers should note that this document considers multihoming only 198 from the point of view of an IPv6 environment. In order to 199 understand this memo, the reader is expected to be familiar with the 200 above cited documents, i.e. with the NEMO terminology as defined in 201 [2] (section 3) and [3], Motivations and and Scenarios for 202 Multihoming [6], Goals and Requirements of Network Mobility Support 203 [1], and the NEMO Basic Support specification [4]. Goals and 204 benefits of multihoming as discussed in [6] are applicable to fixed 205 nodes, mobile nodes, fixed networks and mobile networks. 207 2. Classification 209 As there are several configurations in which mobile networks are 210 multihomed, there is a need to classify them into a clearly defined 211 taxonomy. This can be done in various ways. A Configuration- 212 Oriented taxonomy is described in this section. Two other 213 taxonomies, namely, the Ownership-Oriented Approach, and the Problem- 214 Oriented Approach are outlined in Appendix A.1 and Appendix A.2. 216 Multihomed configurations can be classified depending on how many 217 mobile routers are present, how many egress interfaces, Care-of 218 Address (CoA) and Home Addresses (HoA) the mobile routers have, how 219 many prefixes (MNPs) are available to the mobile network nodes, etc. 220 We use three key parameters to differentiate the multihomed 221 configurations. Using these parameters, each configuration is 222 referred by the 3-tuple (x,y,z), where 'x', 'y', 'z' are defined as 223 follows: 225 o 'x' indicates the number of MRs where: 227 x=1 implies a mobile network has only a single MR, presumably 228 multihomed. 230 x=n implies a mobile network has more than one MR. 232 o 'y' indicates the number of HAs associated with the entire mobile 233 network, where: 235 y=1 implies that a single HA is assigned to the mobile network. 237 y=n implies that multiple HAs are assigned to the mobile network. 239 o 'z' indicates the number of MNPs available within the NEMO, where: 241 z=1 implies that a single MNP is available in the NEMO. 243 z=N implies that multiple MNPs are available in the NEMO 245 It can be seen that the above three parameters are fairly orthogonal 246 to one another. Thus different values of 'x', 'y' and 'z' result 247 into different combinations of the 3-tuple (x,y,z). 249 As described in the sub-sections below, a total of 8 possible 250 configurations can be identified. One thing the reader has to keep 251 in mind is that in each of the following 8 cases, the MR may be 252 multihomed if either (i) multiple prefixes are available (on the home 253 link, or on the visited link), or (ii) the MR is equipped with 254 multiple interfaces. In such a case, the MR would have multiple HoA- 255 CoA pairs. Issues pertaining to a multihomed MR are also addressed 256 in [7]. In addition, the readers should also keep in mind that when 257 "MNP(s) is/are available in the NEMO", the MNP(s) may either be 258 explicitly announced by the MR via router advertisement, or made 259 available through Dynamic Host Configuration Protocol (DHCP). 261 2.1. (1,1,1): Single MR, Single HA, Single MNP 263 The (1,1,1) configuration has only one MR, it is associated with a 264 single HA, and a single MNP is available in the NEMO. To fall into a 265 multihomed configuration, at least one of the following conditions 266 must hold: 268 o The MR has multiple interfaces and thus its has multiple CoAs; 270 o Multiple global prefixes are available on the visited link, and 271 thus it has multiple CoAs; or 273 o Multiple global prefixes are available on the home link, and thus 274 the MR has more than one path to reach the home agent. 276 Note that the case where multiple prefixes are available on the 277 visited link does not have any bearing on the MNPs. MNPs are 278 independent of prefixes available on the link where MR is attached, 279 thus prefixes available on the foreign link are not announced on the 280 NEMO link. For the case where multiple prefixes are available on the 281 home link, these are only announced on the NEMO link if the MR is 282 configured to do so. In this configuration, only one MNP is 283 announced. 285 A bi-directional tunnel would then be established between each HoA- 286 CoA pair. 288 Regarding MNNs, they are (usually) not multihomed since they would 289 configure a single global address from the single MNP available on 290 the link they are attached to. 292 _____ 293 _ p _ | | 294 |_|-|<-_ |-|_|-| |-| _ 295 _ |-|_|=| |_____| | _ |-|_| 296 |_|-| | |-|_|-| 297 | 298 MNNs MR AR Internet AR HA 300 Figure 1: (1,1,1): 1 MR, 1 HA, 1 MNP 302 2.2. (1,1,n): Single MR, Single HA, Multiple MNPs 304 The (1,1,n) configuration has only one MR, it is associated with a 305 single HA and two or more MNPs are available in the NEMO. 307 The MR may itself be multihomed, as detailed in Section 2.1. In such 308 a case, a bi-directional tunnel would be established between each 309 HoA-CoA pair. 311 Regarding MNNs, they are multihomed because several MNPs are 312 available on the link they are attached to. The MNNs would then 313 configure a global address with each MNP available on the link. 315 _____ 316 _ p1,p2 _ | | 317 |_|-|<-_ |-|_|-| |-| _ 318 _ |-|_|=| |_____| | _ |-|_| 319 |_|-| | |-|_|-| 320 | 321 MNNs MR AR Internet AR HA 323 Figure 2: (1,1,n): 1 MR, 1 HA, multiple MNPs 325 2.3. (1,n,1): Single MR, Multiple HAs, Single MNP 327 The (1,n,1) configuration has only one MR and a single MNP is 328 available in the NEMO. The MR, however, is associated with multiple 329 HAs, possibly one HA per HoA, or one HA per egress interface. 331 The NEMO is multihomed since it has multiple HAs, but in addition the 332 conditions detailed in Section 2.1 may also hold for the MR. A bi- 333 directional tunnel would then be established between each HoA-CoA 334 pair. 336 Regarding MNNs, they are (usually) not multihomed since they would 337 configure a single global address from the single MNP available on 338 the link they are attached to. 340 AR HA2 341 _ | 342 |-|_|-| _ 343 _____ | |-|_| 344 _ p _ | |-| 345 |_|-|<-_ |-|_|-| | 346 _ |-|_|=| |_____|-| _ 347 |_|-| | | _ |-|_| 348 |-|_|-| 349 | 350 MNNs MR AR Internet AR HA1 352 Figure 3: (1,n,1): 1 MR, multiple HAs, 1 MNP 354 2.4. (1,n,n): Single MR, Multiple HAs, Multiple MNPs 356 The (1,n,n) configuration has only one MR. However, the MR is 357 associated with multiple HAs, possibly one per Home Address (or one 358 HA per egress interface), and more than one MNP is available in the 359 NEMO. 361 The MR is multihomed since it has multiple HAs, but in addition the 362 conditions detailed in Section 2.1 may also hold. A bi-directional 363 tunnel would then be established between each HoA-CoA pair. 365 Regarding MNNs, they are generally multihomed since they would 366 configure a global address from each MNP available on the link they 367 are attached to. 369 AR HA2 370 _ | _ 371 _____ |-|_|-|-|_| 372 _ p1,p2 _ | |-| | 373 |_|-|<-_ |-|_|-| | _ 374 _ |-|_|=| |_____|-| _ |-|_| 375 |_|-| | |-|_|-| 376 | | 377 MNNs MR AR Internet AR HA1 379 Figure 4: (1,n,n): 1 MR, multiple HAs, multiple MNPs 381 2.5. (n,1,1): Multiple MRs, Single HA, Single MNP 383 The (n,1,1) configuration has more than one MR advertising global 384 routes. However, the MR(s) are associated with as single HA, and 385 there in a single MNP available in the NEMO. 387 The NEMO is multihomed since it has multiple MRs, but in addition the 388 conditions detailed in Section 2.1 may also hold for each MR. A bi- 389 directional tunnel would then be established between each HoA-CoA 390 pair. 392 Regarding MNNs, they are (usually) not multihomed since they would 393 configure a single global address from the single MNP available on 394 the link they are attached to. 396 MR2 397 p<-_ | 398 _ |-|_|-| _____ 399 |_|-| |-| | 400 _ | | |-| _ 401 |_|-| _ |-|_____| | _ |-|_| 402 |-|_|-| |-|_|-| 403 p<- | | 404 MNNs MR1 Internet AR HA 406 Figure 5: (n,1,1): Multiple MRs, 1 HA, 1 MNP 408 2.6. (n,1,n): Multiple MRs, Single HA, Multiple MNPs 410 The (n,1,n) configuration has more than one MR; multiple global 411 routes are advertised by the MRs and multiple MNPs are available 412 within the NEMO. 414 The NEMO is multihomed since it has multiple MRs, but in addition the 415 conditions detailed in Section 2.1 may also hold for each MR. A bi- 416 directional tunnel would then be established between each HoA-CoA 417 pair. 419 Regarding MNNs, they are generally multihomed since they would 420 configure a global address from each MNP available on the link they 421 are attached to. 423 MR2 424 p2<-_ | 425 _ |-|_|-| _____ 426 |_|-| |-| | 427 _ | | |-| _ 428 |_|-| _ |-|_____| | _ |-|_| 429 |-|_|-| |-|_|-| 430 p1<- | | 431 MNNs MR1 Internet AR HA 433 Figure 6: (n,1,n): Multiple MRs, 1 HA, multiple MNPs 435 2.7. (n,n,1): Multiple MRs, Multiple HAs, Single MNP 437 The (n,n,1) configuration has more than one MR advertising multiple 438 global routes. The mobile network is simultaneously associated with 439 multiple HAs and a single MNP is available in the NEMO. 441 The NEMO is multihomed since it has multiple MRs and HAs, but in 442 addition the conditions detailed in Section 2.1 may also hold for 443 each MR. A bi-directional tunnel would then be established between 444 each HoA-CoA pair. 446 Regarding MNNs, they are (usually) not multihomed since they would 447 configure a single global address from the single MNP available on 448 the link they are attached to. 450 MR2 AR HA2 451 p _ | 452 <-_ | |-|_|-| _ 453 _ |-|_|-| _____ | |-|_| 454 |_|-| |-| |-| 455 _ | | | 456 |_|-| _ |-|_____|-| _ 457 |-|_|-| | _ |-|_| 458 <- | |-|_|-| 459 p | 460 MNNs MR1 Internet AR HA1 462 Figure 7: (n,n,1): Multiple MRs, Multiple HAs, 1 MNP 464 2.8. (n,n,n): Multiple MRs, Multiple HAs, Multiple MNPs 466 The (n,n,n) configuration has multiple MRs advertising different 467 global routes. The mobile network is simultaneously associated with 468 more than one HA and multiple MNPs are available in the NEMO. 470 The NEMO is multihomed since it has multiple MRs and HAs, but in 471 addition the conditions detailed in Section 2.1 may also hold for 472 each MR. A bi-directional tunnel would then be established between 473 each HoA-CoA pair. 475 Regarding MNNs, they are generally multihomed since they would 476 configure a global address from each MNP available on the link they 477 are attached to. 479 MR2 AR HA2 480 p2 _ | 481 <-_ | |-|_|-| _ 482 _ |-|_|-| _____ | |-|_| 483 |_|-| |-| |-| 484 _ | | | 485 |_|-| _ |-|_____|-| _ 486 |-|_|-| | _ |-|_| 487 <- | |-|_|-| 488 p1 | 489 MNNs MR1 Internet AR HA1 491 Figure 8: (n,n,n): Multiple MRs, HAs, and MNPs 493 3. Deployment Scenarios and Prerequisites 495 The following generic goals and benefits of multihoming are discussed 496 in [6]: 498 1. Permanent and Ubiquitous Access 500 2. Reliability 502 3. Load Sharing 504 4. Load Balancing/Flow Distribution 506 5. Preference Settings 508 6. Aggregate Bandwidth 510 These benefits are now illustrated from a NEMO perspective with a 511 typical instance scenario for each case in the taxonomy. We then 512 discuss the prerequisites to fulfill these. 514 3.1. Deployment Scenarios 516 x=1: Multihomed mobile networks with a single MR 518 o Example: an MR with dual/multiple access interfaces (e.g. 519 802.11 and GPRS capabilities). This is a (1,1,*) if both 520 accesses are subscribed to the same ISP. If the two accesses 521 are offered by independent ISPs, this is a (1,n,n) 523 Benefits: Ubiquitous Access, Reliability, Load Sharing, 524 Preference Settings, Aggregate Bandwidth 526 x=N: Multihomed mobile networks with multiple MRs 528 o Example 1: a train with one MR in each car, all served by the 529 same HA, thus a (n,1,*) configuration. Alternatively, the 530 train company might be forced to use different ISPs when the 531 train go to different locations, thus it is a (n,n,n) 532 configuration. 534 Benefits: Load Sharing, Reliability, Ubiquitous Access, 535 Aggregate Bandwidth 537 o Example 2: W-PAN with a GPRS-enabled phone and a WiFi-enabled 538 PDA. This is a (n,n,n) configuration if the two access 539 technologies are subscribed separately. 541 Benefits: Ubiquitous Access, Reliability, Preference Settings, 542 Aggregate Bandwidth 544 y=1: Multihomed mobile networks with a single HA 546 o Most single ISP cases in above examples. 548 y=N: Multihomed mobile networks with multiple HAs 550 o Most multiple ISP cases in above examples. 552 o Example: a transatlantic flight with a HA in each continent. 553 This is a (1,n,1) configuration if there is only one MR. 555 Benefits: Ubiquity, Preferences (reduced delay, shortest path), 556 Reliability 558 z=1: Multihomed mobile networks with a single MNP 560 o Most single ISP cases in above examples. 562 z=N: Multihomed mobile networks with multiple MNPs 564 o Most multiple ISP cases in above examples. 566 o Example: a car with a prefix taken from home (personal traffic 567 transit on this prefix and is paid by the owner) and one that 568 belongs to the car manufacturer (maintenance traffic is paid by 569 the car manufacturer). This will typically be a (1,1,n) or a 570 (1,n,n,) configuration. 572 Benefits: Preference Settings 574 3.2. Prerequisites 576 In this section, requirements are started in order to comply with the 577 expected benefits of multihoming as detailed in [6]. 579 At least one bi-directional tunnel must be available at any point in 580 time between the mobile network and the fixed network to meet all 581 expectations. But for most goals to be effective, multiple tunnels 582 must be maintained simultaneously: 584 o Permanent and Ubiquitous Access: 586 At least one bi-directional tunnel must be available at any point 587 in time. 589 o Reliability: 591 Both the inbound and outbound traffic must be transmitted or 592 diverted over another bi-directional tunnel once a bi-directional 593 tunnel is broken or disrupted. It should be noted that the 594 provision of fault tolerance capabilities does not necessarily 595 require the existence of multiple bi-directional tunnels 596 simultaneously. 598 o Load Sharing and Load Balancing: 600 Multiple tunnels must be maintained simultaneously. 602 o Preference Settings: 604 Implicitly, multiple tunnels must be maintained simultaneously if 605 preferences are set for deciding which of the available bi- 606 directional tunnels should be used. To allow user/application to 607 set the preference, a mechanism should be provided to the user/ 608 application for the notification of the availability of multiple 609 bi-directional tunnels, and perhaps also to set preferences. 610 Similar mechanism should also be provided to network 611 administrators for the administration of the preferences. 613 o Aggregate Bandwidth: 615 Multiple tunnels must be maintained simultaneously in order to 616 increase the total aggregated bandwidth available to the mobile 617 network. 619 4. Multihoming Issues 621 As discussed in the previous section, multiple bi-directional tunnels 622 need to be maintained either sequentially (e.g. for fault tolerance) 623 or simultaneously (e.g. for load sharing). 625 In some cases, it may be necessary to divert packets from a (perhaps 626 failed) bi-directional tunnel to an alternative (perhaps newly 627 established) bi-directional tunnel (i.e. for matters of fault 628 recovery, preferences), or to split traffic between multiple tunnels 629 (load sharing, load balancing). 631 So, depending on the configuration under consideration, the issues 632 discussed below may need to be addressed, sometimes dynamically. For 633 each issue, potential ways to solve the problem are investigated. 635 4.1. Fault Tolerance 637 One of the goals of multihoming is the provision of fault tolerance 638 capabilities. In order to provide such features, a set of tasks need 639 to be performed, including: failure detection, alternative available 640 path exploration, path selection, re-homing of established 641 communications. These are also discussed in [8] and [9] by the Shim6 642 WG. In the following sub-sections, we look at these issues in the 643 specific context of NEMO, rather than the general Shim6 perspective 644 in [8] [9]. In addition, in some scenarios, it may also be required 645 to provide the mechanisms for coordination between different HAs (see 646 Section 4.3) and also the coordination between different MRs (see 647 Section 4.4). 649 4.1.1. Failure Detection 651 It is expected for faults to occur more readily at the edge of the 652 network (i.e. the mobile nodes), due to the use of wireless 653 connections. Efficient fault detection mechanisms are necessary to 654 recover in timely fashion. Depending on the NEMO configuration 655 considered, the failure protection domain greatly varies. In some 656 configurations, the protection domain provided by NEMO multihoming is 657 limited to the links between the MR(s) and the HA(s). In other 658 configurations, the protection domain allows to recover from failures 659 in other parts of the path, so an end to end failure detection 660 mechanism is required. 662 Below are detailed which failure detection capabilities are required 663 for each configuration: 665 o For the (1,1,*) cases, multiple paths are available between a 666 single MR and a single HA. All the traffic from and to the NEMO 667 flows through these MR and HA. Failure detection mechanisms need 668 only to be executed between these two devices. This is a NEMO/ 669 MIPv6 specific issue. 671 o For the (n,1,*) cases, there is a single HA, so all the traffic 672 from and to the NEMO will flow through it. The failure detection 673 mechanisms need to be able to detect failure in the path between 674 the used MR and the only HA. Hence, the failure detection 675 mechanism needs only to involve the HA and the MRs. This is a 676 NEMO/MIPv6 specific issue. 678 o For the (n,n,*) cases, there are multiple paths between the 679 different HAs and the different MRs. Moreover, the HAs may be 680 located in different networks, and have different Internet access 681 links. This implies that changing the HA used may not only allow 682 recovering from failures in the link between the HA and the MR, 683 but also from other failure modes, affecting other parts of the 684 path. In this case, an end-to-end failure detection mechanism 685 would provide additional protection. However, a higher number of 686 failures is likely to occur in the link between the HA and the MR, 687 so it may be reasonable to provide optimized failure detection 688 mechanisms for this failure mode. The (n,n,1) case, however, 689 seems to be pretty NEMO specific, because of the absence of 690 multiple prefixes. The (n,n,n) case is hybrid, since for those 691 cases when selecting a different prefix results in a change of 692 path, the Shim6 protocols (such as those discussed in [8]) may be 693 useful. The other cases are NEMO specific. 695 Most of the above cases involve the detection of tunnel failures 696 between HA(s) and MR(s). This is no different from the case of 697 failure detection between a mobile host and its HA(s). As such, a 698 solution for MIPv6 should apply to NEMO as well. For the case of 699 (n,*,*), a MR synchronization solution (see Section 4.4) should be 700 able to compliment a MIPv6 failure detection solution to achieve the 701 desired functionality for NEMO. 703 In order for fault recovery to work, the MRs and HAs must first 704 possess a means to detect failures: 706 o On the MR's side, the MR can rely on router advertisements from 707 access routers, or other layer-2 trigger mechanisms to detect 708 faults, e.g. [10], [11], [12] or [13]. 710 o On the HA's side, it is more difficult to detect tunnel failures. 711 For an ISP deployment model, the HAs and MRs can use proprietary 712 methods (such as constant transmission of heartbeat signals) to 713 detect failures and check tunnel liveness. In the subscriber 714 model (see Appendix A.2: S/P model), a lack of standardized 715 "tunnel liveness" protocol means that it is harder to detect 716 failures. 718 A possible method is for the MRs to send binding updates more 719 regularly with shorter Lifetime values. Similarly, HAs can return 720 binding acknowledgment messages with smaller Lifetime values, thus 721 forcing the MRs to send binding updates more frequently. These 722 binding updates can be used to emulate "tunnel heartbeats". This 723 however may lead to more traffic and processing overhead, since 724 binding updates sent to HAs must be protected (and possibly 725 encrypted) with security associations. 727 4.1.2. Path Exploration 729 Once a failure in the currently used path is detected, alternative 730 paths need to be explored in order to identify an available one. 731 This process is closely related to failure detection in the sense 732 that paths being explored need to be alternative paths to the one 733 that has failed. There are, however, subtle but significant 734 differences between path exploration and failure detection. Failure 735 detection occurs on the currently used path while path exploration 736 occurs on the alternative paths (not on the one currently being used 737 for exchanging packets). Although both path exploration and failure 738 detection are likely to rely on a reachability or keepalive test 739 exchange, failure detection also relies on other information, such as 740 upper layer information (e.g. positive or negative feedback form 741 TCP), lower layer information (e.g. an interface is down), and 742 network layer information (e.g. as an address being deprecated or 743 ICMP error message). 745 Basically, the same cases as in the analysis of the failure detection 746 (Section 4.1.1) issue are identified: 748 o For the (1,1,*) cases, multiple paths are available between a 749 single MR and a single HA. The existing paths between the HA and 750 the MR need to be explored to identify an available one. The 751 mechanism involves only the HA and the MR. This is a NEMO/MIPv6 752 specific issue. 754 o For the (n,1,*) cases, there is a single HA, so all the traffic 755 from and to the NEMO will flow through it. The available 756 alternative paths are the different ones between the different MRs 757 and the HA. The path exploration mechanism needs only to involve 758 the HA and the MRs. This is a NEMO/MIPv6 specific issue. 760 o For the (n,n,*) cases, there are multiple paths between the 761 different HAs and the different MRs. In this case, alternative 762 paths may be routed completely independently one from one another. 764 An end-to-end path exploration mechanism would be able to discover 765 if any of the end-to-end paths is available. The (n,n,1) case, 766 however, seems to be pretty NEMO specific, because of the absence 767 of multiple prefixes. The (n,n,n) case is hybrid, since for those 768 cases that selecting a different prefix result in a change of 769 path, the Shim6 protocols (such as [9]) may be useful. The other 770 cases, are NEMO specific. 772 Most of the above cases involve the path exploration of tunnels 773 between HA(s) and MR(s). This is no different from the case of path 774 exploration between a mobile host and its HA(s). As such, a solution 775 for MIPv6 should apply to NEMO as well. For the case of (n,*,*), a 776 MR synchronization solution (see Section 4.4) should be able to 777 compliment a MIPv6 path exploration solution to achieve the desired 778 functionality for NEMO. 780 In order to perform path exploration, it is sometimes also necessary 781 for the mobile router to detect the availability of network media. 782 This may be achieved using layer 2 triggers [10], or other mechanism 783 developed/recommended by the Detecting Network Attachment (DNA) 784 Working Group [11][14]. This is related to Section 4.1.1, since the 785 ability to detect media availability would often implies the ability 786 to detect media un-availability. 788 4.1.3. Path Selection 790 A path selection mechanism is required to select among the multiple 791 available paths. Depending on the NEMO multihoming configuration 792 involved, the differences between the paths may affect only the part 793 between the HA and the MR, or they may affect the full end-to-end 794 path. In addition, depending on the configuration, path selection 795 may be performed by the HA(s), the MR(s) or the hosts themselves 796 through address selection, as will be described in details next. 798 The multiple available paths may differ on the tunnel between the MR 799 and the HA used to carry traffic to/from the NEMO. In this case, 800 path selection is performed by the MR and the intra-NEMO routing 801 system for traffic flowing from the NEMO, and path selection is 802 performed by the HA and intra-Home Network routing system for traffic 803 flowing to the NEMO. 805 Alternatively, the multiple paths available may differ in more than 806 just the tunnel between the MR and the HA, since the usage of 807 different prefixes may result in using different providers, hence in 808 completely different paths between the involved endpoints. In this 809 case, besides the mechanisms presented in the previous case, 810 additional mechanisms for the end-to-end path selection may be 811 needed. This mechanism may be closely related to source address 812 selection mechanisms within the hosts, since selecting a given 813 address implies selecting a given prefix, which is associated with a 814 given ISP serving one of the home networks. 816 A dynamic path selection mechanism is thus needed so that this path 817 could be selected by: 819 o The HA: it should be able to select the path based on some 820 information recorded in the binding cache. 822 o The MR: it should be able to select the path based on router 823 advertisements received on both its egress interfaces or on its 824 ingress interfaces for the (n,*,*) case. 826 o The MNN: it should be able to select the path based on "Default 827 Router Selection" (see [Section 6.3.6. Default Router Selection] 828 [15]) in the (n,*,*) case or based on "Source Address Selection" 829 in the (*,*,n) cases (see Section 4.7 of the present memo). 831 o The user or the application: e.g. in case where a user wants to 832 select a particular access technology among the available 833 technologies for reasons of cost or data rate. 835 o A combination of any of the above: a hybrid mechanism should be 836 also available, e.g. one in which the HA, the MR, and/or the MNNs 837 are coordinated to select the path. 839 When multiple bi-directional tunnels are available and possibly used 840 simultaneously, the mode of operation may be either primary-secondary 841 (one tunnel is precedent over the others and used as the default 842 tunnel, while the other serves as a back-up) or peer-to-peer (no 843 tunnel has precedence over one another, they are used with the same 844 priority). This questions which of the bi-directional tunnels would 845 be selected, and based on which of the parameters (e.g. type of flow 846 that goes into/out of the mobile network). 848 The mechanisms for the selection among the different tunnels between 849 the MR(s) and the HA(s) seems to be quite NEMO/MIPv6 specific. 851 For (1,*,*) cases, they are no different from the case of path 852 selection between a mobile host and its HA(s). As such, a solution 853 for MIPv6 should apply to NEMO as well. For the (n,*,*) cases, a MR 854 synchronization solution (see Section 4.4) should be able to 855 compliment a MIPv6 path selection solution to achieve the desired 856 functionality for NEMO. 858 The mechanisms for selecting among different end-to-end paths based 859 on address selection are similar to the ones used in other 860 multihoming scenarios, as those considered by Shim6 (e.g. [16]). 862 4.1.4. Re-Homing 864 After an outage has been detected and an available alternative path 865 has been identified, a re-homing event takes place, diverting the 866 existing communications from one path to the other. Similar to the 867 previous items involved in this process, the re-homing procedure 868 heavily varies depending on the NEMO multihoming configuration. 870 o For the (*,*,1) configurations, the re-homing procedure involves 871 only the MR(s) and the HA(s). The re-homing procedure may involve 872 the exchange of additional BU messages. These mechanisms are 873 shared between NEMO Basic Support and MIPv6. 875 o For the (*,*,n) cases, in addition to the previous mechanisms, end 876 to end mechanisms may be required. Such mechanisms may involve 877 some form of end to end signaling or may simply rely on using 878 different addresses for the communication. The involved 879 mechanisms may be similar to those required for re-homing Shim6 880 communications (e.g. [16]). 882 4.2. Ingress Filtering 884 Ingress filtering mechanisms [17][18] may drop the outgoing packets 885 when multiple bi-directional tunnels end up at different HAs. This 886 could particularly occur if different MNPs are handled by different 887 HAs. If a packet with a source address configured from a specific 888 MNP is tunnelled to a home agent that does not handle that specific 889 MNP the packet may be discarded either by the home agent or by a 890 border gateway in the home network. 892 The ingress filtering compatibility issue is heavily dependent on the 893 particular NEMO multihoming configuration: 895 o For the (*,*,1) cases, there is not such an issue, since there is 896 a single MNP. 898 o For the (1,1,*) and (n,1,1) cases, there is not such a problem, 899 since there is a single HA, accepting all the MNPs. 901 o For the (n,1,n) case, though ingress filtering would not occur at 902 the HA, it may occur at the MRs, when each MR is handling 903 different MNPs. 905 o (*,n,n) are the cases where the ingress filtering presents some 906 difficulties. In the (1,n,n) case, the problem is simplified 907 because all the traffic from and to the NEMO is routed through a 908 single MR. Such configuration allows the MR to properly route 909 packets respecting the constraints imposed by ingress filtering. 910 In this case, the single MR may face ingress filtering problems 911 that a multihomed mobile node may face, as documented in [7]. 913 The more complex case is the (n,n,n) case. A simplified case 914 occurs when all the prefixes are accepted by all the HAs, so that 915 no problems occur with the ingress filtering. However, this 916 cannot be always assumed, resulting in the problem described 917 below. 919 As an example of how this could happen, consider the deployment 920 scenario illustrated in Figure 9: the mobile network has two mobile 921 routers MR1 and MR2, with home agents HA1 and HA2 respectively. Two 922 bi-directional tunnels are established between the two pairs. Each 923 mobile router advertises a different MNP (P1 and P2 respectively). 924 MNP P1 is registered to HA1, and MNP P2 is registered to HA2. Thus, 925 MNNs should be free to auto-configure their addresses on any of P1 or 926 P2. Ingress filtering could thus happen in two cases: 928 o If the two tunnels are available, MNN cannot forward packet with 929 source address equals P1.MNN to MR2. This would cause ingress 930 filtering at HA2 to occur (or even at MR2). This is contrary to 931 normal Neighbor Discovery [15] practice that an IPv6 node is free 932 to choose any router as its default router regardless of the 933 prefix it chooses to use. 935 o If the tunnel to HA1 is broken, packets that would normally be 936 sent through the tunnel to HA1 should be diverted through the 937 tunnel to HA2. If HA2 (or some border gateway in the domain of 938 HA2) performs ingress filtering, packets with source address 939 configured from MNP P1 may be discarded. 941 Prefix: P1 +-----+ +----+ +----------+ +-----+ 942 +--| MR1 |--| AR |--| |---| HA1 | 943 | +-----+ +----+ | | +-----+ 944 IP: +-----+ | | | Prefix: P1 945 P1.MNN or | MNN |--+ | Internet | 946 P2.MNN +-----+ | | | Prefix: P2 947 | +-----+ +----+ | | +-----+ 948 +--| MR2 |--| AR |--| |---| HA2 | 949 Prefix: P2 +-----+ +----+ +----------+ +-----+ 951 Figure 9: An (n,n,n) mobile network 953 Possible solutions to the ingress filtering incompatibility problem 954 may be based on the following approaches: 956 o Some form of source address dependent routing, whether host-based 957 and/or router-based where the prefix contained in the source 958 address of the packet is considered when deciding which exit 959 router to use when forwarding the packet. 961 o The usage of nested tunnels for (*,n,n) cases. Appendix B 962 describes one such approach. 964 o Deprecating those prefixes associated to non-available exit 965 routers 967 The ingress filtering incompatibilities problems that appear in some 968 NEMO multihoming configurations are similar to those considered in 969 Shim6 (eg. see [19]). 971 4.3. HA Synchronization 973 In the (*,n,*) configuration, a single MNP would be registered at 974 different HAs. This gives rise to the following cases: 976 o Only one HA may actively advertise a route to the MNP, 978 o Multiple HAs at different domains may advertise a route to the 979 same MNP. 981 This may pose a problem in the routing infrastructure as a whole if 982 the HAs are located in different administrative domains. The 983 implications of this aspect needs further exploration. Certain level 984 of HA co-ordination may be required. A possible approach is to adopt 985 a HA synchronization mechanism such as that described in [20] and 986 [21]. Such synchronization might also be necessary in a (*,n,*) 987 configuration, when a MR sends binding update messages to only one HA 988 (instead of all HAs). In such cases, the binding update information 989 might have to be synchronized between HAs. The mode of 990 synchronization may be either primary-secondary or peer-to-peer. In 991 addition, when a MNP is delegated to the MR (see Section 4.5), some 992 level of co-ordination between the HAs may also be necessary. 994 This issue is a general mobility issue that will also have to be 995 dealt with by Mobile IPv6 as well as NEMO Basic Support. 997 4.4. MR Synchronization 999 In the (n,*,*) configurations, there are common decisions which may 1000 require synchronization among different MRs [22], such as: 1002 o advertising the same MNP in the (n,*,1) configurations (see also 1003 "prefix delegation" in Section 4.5); 1005 o one MR relaying the advertisement of the MNP from another failed 1006 MR in the (n,*,n) configuration; and 1008 o relaying between MRs everything that needs to be relayed, such as 1009 data packets, creating a tunnel from the ingress interface, etc, 1010 in the (n,*,*) configuration. 1012 However, there is no known standardized protocols for this kind of 1013 router-to-router synchronization. Without such synchronization, it 1014 may not be possible for a (n,*,*) configuration to achieve various 1015 multihoming goals, such as fault tolerance. 1017 Such a synchronization mechanism can be primary-secondary (i.e. a 1018 master MR, with the other MRs as backup) or peer-to-peer (i.e. there 1019 is no clear administrative hierarchy between the MRs). The need for 1020 such mechanism is general in the sense that a multi-router site in 1021 the fixed network would require the same level of router 1022 synchronization. 1024 Thus, this issue is not specific to NEMO Basic Support, though there 1025 is a more pressing need to develop a MR to MR synchronization scheme 1026 for proving fault tolerances and failure recovery in NEMO 1027 configurations due to the higher possibility of links failure. 1029 In conclusion it is recommended to investigate a generic solution to 1030 this issue although the solution would first have to be developed for 1031 NEMO deployments. 1033 4.5. Prefix Delegation 1035 In the (*,*,1) configurations, the same MNP must be advertised to the 1036 MNNs through different paths. There is, however, no synchronization 1037 mechanism available to achieve this. Without a synchronization 1038 mechanism, MR may end up announcing incompatible MNPs. Particularly, 1040 o for the (*,n,1) cases, how can multiple HAs delegate the same MNP 1041 to the mobile network? For doing so, the HAs may be somehow 1042 configured to advertise the same MNP (see also "HA 1043 Synchronization" in Section 4.3). 1045 o for the (n,*,1) cases, how can multiple MRs be synchronized to 1046 advertise the same MNP down the NEMO-link? For doing so, the MRs 1047 may be somehow configured to advertise the same MNP (see also "MR 1048 Synchronization" in Section 4.4). 1050 Prefix delegation mechanisms [23][24][25] could be used to ensure all 1051 routers advertise the same MNP. Their application to a multihomed 1052 mobile network should be considered. 1054 4.6. Multiple Bindings/Registrations 1056 When a MR is configured with multiple Care-of Addresses, it is often 1057 necessary for it to bind these Care-of Addresses to the same MNP. 1059 This is a generic mobility issue, since Mobile IPv6 nodes face a 1060 similar problem. This issue is discussed in [7]. It is sufficient 1061 to note that solutions like [26] can solve this for both Mobile IPv6 1062 and NEMO Basic Support. This issue is being dealt with in the 1063 Monami6 WG. 1065 4.7. Source Address Selection 1067 In the (*,*,n) configurations, MNNs would be configured with multiple 1068 addresses. Source address selection mechanisms are needed to decide 1069 which address to choose from. 1071 However, currently available source address selection mechanisms do 1072 not allow MNNs to acquire sufficient information to select their 1073 source addresses intelligently (such as based on the traffic 1074 condition associated with the home network of each MNP). It may be 1075 desirable for MNNs to be able to acquire "preference" information on 1076 each MNP from the MRs. This would allow default address selection 1077 mechanisms such as those specified in [27] to be used. Further 1078 exploration on setting such "preference" information in Router 1079 Advertisement based on performance of the bi-directional tunnel might 1080 prove to be useful. Note that source address selection may be 1081 closely related to path selection procedures (see Section 4.1.3) and 1082 re-homing techniques (see Section 4.1.4). 1084 This is a general issue faced by any node when offered multiple 1085 prefixes. 1087 4.8. Loop Prevention in Nested Mobile Networks 1089 When a multihomed mobile network is nested within another mobile 1090 network, it can result in very complex topologies. For instance, a 1091 nested mobile network may be attached to two different root-MRs, thus 1092 the aggregated network no longer forms a simple tree structure. In 1093 such a situation, infinite loop within the mobile network may occur. 1095 This problem is specific to NEMO Basic Support. However, at the time 1096 of writing, more research is recommended to assess the probability of 1097 loops occurring in a multihomed mobile network. For related work, 1098 see [28] for a mechanism to avoid loops in nested NEMO. 1100 4.9. Prefix Ownership 1102 When a (n,*,1) network splits, (i.e. the two MRs split themselves 1103 up), MRs on distinct links may try to register the only available 1104 MNP. This cannot be allowed, as the HA has no way to know which node 1105 with an address configured from that MNP is attached to which MR. 1106 Some mechanism must be present for the MNP to either be forcibly 1107 removed from one (or all) MRs, or the implementors must not allow a 1108 (n,*,1) network to split. 1110 A possible approach to solving this problem is described in [29]. 1112 This problem is specific to NEMO Basic Support. However, it is 1113 unclear whether there is sufficient deployment scenario for this 1114 problem to occur. 1116 It is recommended that the NEMO WG standardizes a solution to solve 1117 this problem if there is sufficient vendor/operator interest, or 1118 specifies that the split of a (n,*,1) network cannot be allowed 1119 without a router renumbering. 1121 4.10. Preference Settings 1123 When a mobile network is multihomed, the MNNs may be able to benefit 1124 from this configuration, such as to choose among the available paths 1125 based on cost, transmission delays, bandwidth, etc. However, in some 1126 cases, such a choice is not made available to the MNNs. 1127 Particularly: 1129 o In the (*,*,n) configuration, the MNNs can influence the path by 1130 source address selection (see Section 4.1.3, Section 4.7). 1132 o In the (n,*,*) configuration, the MNNs can influence the path by 1133 default router selection (see Section 4.1.3). 1135 o In the (1,*,1) configuration, the MNNs cannot influence the path 1136 selection. 1138 A mechanism that allows the MNN to indicate its preference for a 1139 given traffic might be helpful. In addition, there may also be a 1140 need to exchange some information between the MRs and the MNNs. This 1141 problem is general in the sense that any IPv6 nodes may wish to 1142 influence the routing decision done by the upstream routers. Such 1143 mechanism is currently being explored by various WGs, such as the 1144 NSIS and IPFIX WGs. It is also possible that a Shim6 layer in the 1145 MNNs may possess such capability. 1147 It is recommended that vendors or operators to investigate into the 1148 solutions developed by these WGs when providing multihoming 1149 capabilities to mobile networks. 1151 5. Recommendations to the Working Group 1153 Several issues that might impact the deployment of NEMO with 1154 multihoming capabilities were identified in Section 4. These are 1155 shown in the matrix below, for each of the eight multihoming 1156 configurations, together with indications of from which WG(s) a 1157 solution to each issue is most likely to be found. 1159 +=================================================================+ 1160 | # of MRs: | 1 | 1 | 1 | 1 | n | n | n | n | 1161 | # of HAs: | 1 | 1 | n | n | 1 | 1 | n | n | 1162 | # of Prefixes: | 1 | n | 1 | n | 1 | n | 1 | n | 1163 +=================================================================+ 1164 | Fault Tolerance | * | * | * | * | * | * | * | * | 1165 +---------------------------------+---+---+---+---+---+---+---+---+ 1166 | Failure Detection |N/M|N/M|N/M|N/M|N/M|N/M| N | S | 1167 +---------------------------------+---+---+---+---+---+---+---+---+ 1168 | Path Exploration |N/M|N/M|N/M|N/M|N/M|N/M| N | S | 1169 +---------------------------------+---+---+---+---+---+---+---+---+ 1170 | Path Selection | N |S/N| N |S/N| N |S/N| N |S/N| 1171 +---------------------------------+---+---+---+---+---+---+---+---+ 1172 | Re-Homing |N/M| S |N/M| S |N/M| S |N/M| S | 1173 +---------------------------------+---+---+---+---+---+---+---+---+ 1174 | Ingress Filtering | . | . | . | t | . | . | . | N | 1175 +---------------------------------+---+---+---+---+---+---+---+---+ 1176 | HA Synchronization | . | . |N/M|N/M| . | . |N/M|N/M| 1177 +---------------------------------+---+---+---+---+---+---+---+---+ 1178 | MR Synchronization | . | . | . | . | G | G | G | G | 1179 +---------------------------------+---+---+---+---+---+---+---+---+ 1180 | Prefix Delegation | . | . | N | N | N | N | N | N | 1181 +---------------------------------+---+---+---+---+---+---+---+---+ 1182 | Multiple Binding/Registrations | M | M | M | M | M | M | M | M | 1183 +---------------------------------+---+---+---+---+---+---+---+---+ 1184 | Source Address Selection | . | G | . | G | . | G | . | G | 1185 +---------------------------------+---+---+---+---+---+---+---+---+ 1186 | Loop Prevention in Nested NEMO | N | N | N | N | N | N | N | N | 1187 +---------------------------------+---+---+---+---+---+---+---+---+ 1188 | Prefix Ownership | . | . | . | . | N | . | N | . | 1189 +---------------------------------+---+---+---+---+---+---+---+---+ 1190 | Preference Settings | G | G | G | G | G | G | G | G | 1191 +=================================================================+ 1192 N - NEMO Specific M - MIPv6 Specific G - Generic IPv6 1193 S - SHIM6 WG D - DNA WG 1194 . - Not an Issue t - trivial 1195 * - Fault Tolerance is a combination of Failure Detection, Path 1196 Exploration, Path Selection, and Re-Homing 1198 Figure 10: Matrix of NEMO Multihoming Issues 1199 The above matrix serves to identify which issues are NEMO-specific, 1200 and which are not. The readers are reminded that this matrix is a 1201 simplification of Section 4 as subtle details are not represented in 1202 Figure 10. 1204 As can be seen from Figure 10, the following have some concerns which 1205 are specific to NEMO: Failure Detection, Path Exploration, Path 1206 Selection, Re-Homing, Ingress Filtering, HA Synchronization, Prefix 1207 Delegation, Loop Prevention in Nested NEMO, and Prefix Ownership. 1208 Based on the authors' best knowledge of the possible deployments of 1209 NEMO, it is recommended that: 1211 o A solution for Failure Detection, Path Exploration, Path 1212 Selection, and Re-Homing be solicited from other WGs 1214 Although Path Selection is reflected in Figure 10 as NEMO- 1215 Specific, the technical consideration of the problem is believed 1216 to be quite similar to the selection of multiple paths in mobile 1217 nodes. As such, we would recommend vendors to solicit a solution 1218 for these issues from other WGs in the IETF, for instance the 1219 Monami6 or Shim6 WG. 1221 o Ingress Filtering on the (n,n,n) configuration be solved by the 1222 NEMO WG 1224 This problem is clearly defined, and can be solved by the WG. 1225 Deployment of the (n,n,n) configuration can be envisioned on 1226 vehicles for mass transportation (such as buses, trains) where 1227 different service providers may install their own mobile routers 1228 on the vehicle/vessel. 1230 It should be noted that the Shim6 WG may be developing a mechanism 1231 for overcoming ingress filtering in a more general sense. We thus 1232 recommend the NEMO WG to concentrate only on the (n,n,n) 1233 configuration should the WG decide to work on this issue. 1235 o A solution for Home Agent Synchronization be looked at in a 1236 mobility specific WG and taking into consideration both mobile 1237 hosts operating Mobile IPv6 and mobile routers operating NEMO 1238 Basic Support. 1240 o A solution for Multiple Bindings/Registrations be presently looked 1241 at by the Monami6 WG. 1243 o Prefix Delegation be reviewed and checked by the NEMO WG 1245 There are already WG drafts and [30] providing prefix delegation 1246 functionality to NEMO Basic Support. The WG should review these 1247 drafts and verified that they address any concern a multihomed 1248 NEMO might have, as discussed in Section 4.5. 1250 o Loop Prevention in Nested NEMO be investigated 1252 Further research is recommended to assess the risk of having a 1253 loop in the nesting of multihomed mobile networks. 1255 o Prefix Ownership should be considered by the vendors and operators 1257 The problem of Prefix Ownership only occurs when a mobile network 1258 with multiple MRs and a single MNP can arbitrarily join and split. 1259 Vendors and operators of mobile networks are encouraged to input 1260 their views on the applicability of deploying such kind of mobile 1261 networks. 1263 6. Conclusion 1265 This memo is an analysis of multihoming in the context of network 1266 mobility under the operation of NEMO Basic Support. The purpose of 1267 this memo is to investigate issues related to such a bi-directional 1268 tunneling mechanism when mobile networks are multihomed. For doing 1269 so, a taxonomy was proposed to classify the mobile networks in eight 1270 possible multihomed configurations. The issue were explained and 1271 were then summarized in a table showing under which multihoming 1272 configuration it applies, and which IETF working group is the best 1273 chartered to solve it. This analysis will be helpful to extend the 1274 existing standards to support multihoming and to implementors of NEMO 1275 Basic Support and multihoming-related mechanisms. 1277 7. IANA Considerations 1279 This is an informational document and does not require any IANA 1280 action. 1282 8. Security Considerations 1284 This is an informational document where the multihoming 1285 configurations under the operation of NEMO Basic Support are 1286 analyzed. Security considerations of these multihoming 1287 configurations, should they be different from those that concern NEMO 1288 Basic Support, must be considered by forthcoming solutions. 1290 9. Acknowledgments 1292 The authors would like to thank people who have given valuable 1293 comments on various multihoming issues on the mailing list, and also 1294 those who have suggested directions in the 56th - 61st IETF Meetings. 1295 The initial evaluation of NEMO Basic Support on multihoming 1296 configurations is a contribution from Julien Charbon. 1298 10. References 1300 10.1. Normative References 1302 [1] Ernst, T., "Network Mobility Support Goals and Requirements", 1303 draft-ietf-nemo-requirements-05 (work in progress), 1304 October 2005. 1306 [2] Manner, J. and M. Kojo, "Mobility Related Terminology", 1307 RFC 3753, June 2004. 1309 [3] Ernst, T. and H. Lach, "Network Mobility Support Terminology", 1310 draft-ietf-nemo-terminology-05 (work in progress), 1311 February 2006. 1313 [4] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, 1314 "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, 1315 January 2005. 1317 [5] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in 1318 IPv6", RFC 3775, June 2004. 1320 10.2. Informative References 1322 [6] Ernst, T., "Motivations and Scenarios for Using Multiple 1323 Interfaces and Global Addresses", 1324 draft-ietf-monami6-multihoming-motivation-scenario-00 (work in 1325 progress), February 2006. 1327 [7] Montavont, N., Wakikawa, R., Ernst, T., Ng, C., and K. 1328 Kuladinithi, "Analysis of Multihoming in Mobile IPv6", 1329 draft-ietf-monami6-mipv6-analysis-00 (work in progress), 1330 February 2006. 1332 [8] Arkko, J. and I. Beijnum, "Failure Detection and Locator Pair 1333 Exploration Protocol for IPv6 Multihoming", 1334 draft-ietf-shim6-failure-detection-03 (work in progress), 1335 December 2005. 1337 [9] Beijnum, I., "Shim6 Reachability Detection", 1338 draft-ietf-shim6-reach-detect-01 (work in progress), 1339 October 2005. 1341 [10] Yegin, A., "Link-layer Event Notifications for Detecting 1342 Network Attachments", draft-ietf-dna-link-information-03 (work 1343 in progress), October 2005. 1345 [11] Narayanan, S., "Detecting Network Attachment in IPv6 - Best 1346 Current Practices for hosts.", draft-ietf-dna-hosts-02 (work in 1347 progress), October 2005. 1349 [12] Yegin, A., "Link-layer Hints for Detecting Network 1350 Attachments", draft-yegin-dna-l2-hints-01 (work in progress), 1351 February 2004. 1353 [13] Yegin, A., "Supporting Optimized Handover for IP Mobility 1354 -Requirements for Underlying Systems", 1355 draft-manyfolks-l2-mobilereq-02 (work in progress), July 2002. 1357 [14] Narayanan, S., "Detecting Network Attachment in IPv6 - Best 1358 Current Practices for Routers", draft-ietf-dna-routers-01 (work 1359 in progress), October 2005. 1361 [15] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery 1362 for IP Version 6 (IPv6)", RFC 2461, December 1998. 1364 [16] Bagnulo, M. and J. Arkko, "Functional decomposition of the 1365 multihoming protocol", draft-ietf-shim6-functional-dec-00 (work 1366 in progress), July 2005. 1368 [17] Ferguson, P. and D. Senie, "Network Ingress Filtering: 1369 Defeating Denial of Service Attacks which employ IP Source 1370 Address Spoofing", BCP 38, RFC 2827, May 2000. 1372 [18] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 1373 Networks", BCP 84, RFC 3704, March 2004. 1375 [19] Huitema, C., "Ingress filtering compatibility for IPv6 1376 multihomed sites", draft-huitema-shim6-ingress-filtering-00 1377 (work in progress), September 2005. 1379 [20] Wakikawa, R., Devarapalli, V., and P. Thubert, "Inter Home 1380 Agents Protocol (HAHA)", draft-wakikawa-mip6-nemo-haha-01 (work 1381 in progress), February 2004. 1383 [21] Koh, B., Ng, C., and J. Hirano, "Dynamic Inter Home Agent 1384 Protocol", draft-koh-mip6-nemo-dhap-00 (work in progress), 1385 July 2004. 1387 [22] Tsukada, M., "Analysis of Multiple Mobile Routers Cooperation", 1388 draft-tsukada-nemo-mr-cooperation-analysis-00 (work in 1389 progress), October 2005. 1391 [23] Miyakawa, S. and R. Droms, "Requirements for IPv6 Prefix 1392 Delegation", RFC 3769, June 2004. 1394 [24] Droms, R. and P. Thubert, "DHCPv6 Prefix Delegation for NEMO", 1395 draft-droms-nemo-dhcpv6-pd-02 (work in progress), April 2005. 1397 [25] Kniveton, T. and P. Thubert, "Mobile Network Prefix 1398 Delegation", draft-ietf-nemo-prefix-delegation-00 (work in 1399 progress), August 2005. 1401 [26] Wakikawa, R., "Multiple Care-of Addresses Registration", 1402 draft-ietf-monami6-multiplecoa-00 (work in progress), 1403 June 2006. 1405 [27] Draves, R., "Default Address Selection for Internet Protocol 1406 version 6 (IPv6)", RFC 3484, February 2003. 1408 [28] Thubert, P., "Nested Nemo Tree Discovery", 1409 draft-thubert-tree-discovery-02 (work in progress), July 2005. 1411 [29] Kumazawa, M., "Token based Duplicate Network Detection for 1412 split mobile network (Token based DND)", 1413 draft-kumazawa-nemo-tbdnd-02 (work in progress), July 2005. 1415 [30] Droms, R. and P. Thubert, "DHCPv6 Prefix Delegation for NEMO", 1416 draft-ietf-nemo-dhcpv6-pd-00 (work in progress), August 2005. 1418 Appendix A. Alternative Classifications Approach 1420 A.1. Ownership-Oriented Approach 1422 An alternative approach to classifying multihomed mobile network is 1423 proposed by Erik Nordmark (Sun Microsystems) by breaking the 1424 classification of multihomed network based on ownership. This is 1425 more of a tree-like top-down classification. Starting from the 1426 control and ownership of the HA(s) and MR(s), there are two different 1427 possibilities: either (i) the HA(s) and MR(s) are controlled by a 1428 single entity, or (ii) the HA(s) and MR(s) are controlled by separate 1429 entities. We called the first possibility the 'ISP Model', and the 1430 second the 'Subscriber/Provider Model'. 1432 A.1.1. ISP Model 1434 The case of the HA(s) and MR(s) are controlled by the same entity can 1435 be best illustrated as an Internet Service Provider (ISP) installing 1436 mobile routers on trains, ships or planes. It is up to the ISP to 1437 deploy a certain configuration of mobile network; all 8 1438 configurations as described in the Configuration-Oriented Approach 1439 are possible. In the remaining portion of this document, when 1440 specifically referring to a mobile network configuration that is 1441 controlled by a single entity, we will add an 'ISP' prefix: for 1442 example: ISP-(1,1,1) or ISP-(1,N,N). 1444 When the HA(s) and MR(s) are controlled by a single entity (such as 1445 an ISP), the ISP can decide whether it wants to assign one or 1446 multiple MNPs to the mobile network just like it can make the same 1447 decision for any other link in its network (wired or otherwise). In 1448 any case, the ISP will make the routing between the mobile networks 1449 and its core routers (such as the HAs) work. This include not 1450 introducing any aggregation between the HAs which will filter out 1451 routing announcements for the MNP(es). 1453 To such ends, the ISP has various means and mechanisms. For one, the 1454 ISP can run its Interior Gateway Protocol (IGP) over bi-directional 1455 tunnels between the MR(s) and HA(s). Alternatively, static routes 1456 may be used with the tunnels. When static routes are used, a 1457 mechanism to test "tunnel liveness" might be necessary to avoid 1458 maintaining stale routes. Such "tunnel liveness" may be tested by 1459 sending heartbeats signals from MR(s) to the HA(s). A possibility is 1460 to simulate heartbeats using Binding Updates messages by controlling 1461 the "Lifetime" field of the Binding Acknowledgment message to force 1462 the MR to send Binding Update messages at regular interval. However, 1463 a more appropriate tool might be the Binding Refresh Request message, 1464 though conformance to the Binding Refresh Request message may be less 1465 strictly enforced in implementations since it serves a somewhat 1466 secondary role when compared to Binding Update messages. 1468 A.1.2. Subscriber/Provider Model 1470 The case of the HA(s) and MR(s) are controlled by the separate 1471 entities can be best illustrated with a subscriber/provider model, 1472 where the MRs belongs to a single subscriber and subscribes to one or 1473 more ISPs for HA services. There is two sub-categories in this case: 1474 when the subscriber subscribes to a single ISP, and when the 1475 subscriber subscribes to multiple ISPs. In the remaining portion of 1476 this document, when specifically referring to a mobile network 1477 configuration that is in the subscriber/provider model where the 1478 subscriber subscribes to only one ISP, we will add an 'S/P' prefix: 1479 for example: S/P-(1,1,1) or S/P-(1,n,n). When specifically referring 1480 to a mobile network configuration that is in the subscriber/provider 1481 model where the subscriber subscribes to multiple ISPs, we will add 1482 an 'S/mP' prefix: for example: S/mP-(1,1,1) or S/mP-(1,n,n). 1484 Not all 8 configurations are likely to be deployed for the S/P and 1485 S/mP models. For instance, it is unlikely to foresee a S/mP-(*,1,1) 1486 mobile network where there is only a single HA. For the S/P model, 1487 the following configurations are likely to be deployed: 1489 o S/P-(1,1,1): Single Provider, Single MR, Single HA, Single MNP 1491 o S/P-(1,1,n): Single Provider, Single MR, Single HA, Multiple MNPs 1493 o S/P-(1,n,1): Single Provider, Single MR, Multiple HAs, Single MNP 1495 o S/P-(1,n,n): Single Provider, Single MR, Multiple HAs, Multiple 1496 MNPs 1498 o S/P-(n,n,1): Single Provider, Multiple MRs, Single HA, Single MNP 1500 o S/P-(n,1,n): Single Provider, Multiple MRs, Single HA, Multiple 1501 MNPs 1503 o S/P-(n,n,1): Single Provider, Multiple MRs, Multiple HAs, Single 1504 MNP 1506 o S/P-(n,n,n): Single Provider, Multiple MRs, Multiple HAs, Multiple 1507 MNPs 1509 For the S/mP model, the following configurations are likely to be 1510 deployed: 1512 o S/mP-(1,n,1): Multiple Providers, Single MR, Multiple HAs, Single 1513 MNP 1515 o S/mP-(1,n,n): Multiple Providers, Single MR, Multiple HAs, 1516 Multiple MNPs 1518 o S/mP-(n,n,n): Multiple Providers, Multiple MRs, Multiple HAs, 1519 Multiple MNPs 1521 When the HA(s) and MR(s) are controlled by different entities, it is 1522 more likely the scenario where the MR is controlled by one entity 1523 (i.e. the subscriber), and the MR is establishing multiple bi- 1524 directional tunnels to one or more HA(s) provided by one or more 1525 ISP(s). In such case, it is unlikely for the ISP to run IGP over the 1526 bi-directional tunnel, since ISP would most certainly wish to retain 1527 full control of its routing domain. 1529 A.2. Problem-Oriented Approach 1531 A third approach is proposed by Pascal Thubert (Cisco System). This 1532 focused on the problems of multihomed mobile networks rather than the 1533 configuration or ownership. With this approach, there is a set of 4 1534 categories based on two orthogonal parameters: the number of HAs, and 1535 the number of MNPs advertised. Since the two parameters are 1536 orthogonal, the categories are not mutually exclusive. The four 1537 categories are: 1539 o Tarzan: Single HA for Different CoAs of Same MNP 1541 This is the case where one MR registers different Care-of 1542 Addresses to the same HA for the same subnet prefix. This is 1543 equivalent to the case of y=1, i.e. the (1,1,*) mobile network. 1545 o JetSet: Multiple HAs for Different CoAs of Same MNP 1547 This is the case where the MR registers different Care-of 1548 Addresses to different HAs for the same subnet prefix. This is 1549 equivalent to the case of y=n, i.e. the (1,n,*) mobile network. 1551 o Shinkansen: Single MNP Advertised by MR(s) 1553 This is the case where one MNP is announced by different MRs. 1554 This is equivalent to the case of x=n and z=1, i.e. the (n,*,1) 1555 mobile network. 1557 o DoubleBed: Multiple MNPs Advertised by MR(s) 1559 This is the case where more than one MNPs are announced by the 1560 different MRs. This is equivalent to the case of x=n and z=n, 1561 i.e. the (n,*,n) mobile network. 1563 Appendix B. Nested Tunneling for Fault Tolerance 1565 In order to utilize the additional robustness provided by 1566 multihoming, MRs that employ bi-directional tunneling with their HAs 1567 should dynamically change their tunnel exit points depending on the 1568 link status. For instance, if a MR detects that one of its egress 1569 interface is down, it should detect if any other alternate route to 1570 the global Internet exists. This alternate route may be provided by 1571 any other MRs connected to one of its ingress interfaces that has an 1572 independent route to the global Internet, or by another active egress 1573 interface the MR itself possess. If such an alternate route exists, 1574 the MR should re-establish the bi-directional tunnel using this 1575 alternate route. 1577 In the remaining part of this Appendix, we will attempt to 1578 investigate methods of performing such re-establishment of bi- 1579 directional tunnels. This method of tunnel re-establishment is 1580 particularly useful for the (*,n,n) NEMO configuration. The method 1581 described is by no means complete and merely serves as a suggestion 1582 on how to approach the problem. It is also not the objective to 1583 specify a new protocol specifically tailored to provide this form of 1584 re- establishments. Instead, we will limit ourselves to currently 1585 available mechanisms specified in Mobile IPv6 [5] and Neighbor 1586 Discovery in IPv6 [15]. 1588 B.1. Detecting Presence of Alternate Routes 1590 To actively utilize the robustness provided by multihoming, a MR must 1591 first be capable of detecting alternate routes. This can be manually 1592 configured into the MR by the administrators if the configuration of 1593 the mobile network is relatively static. It is however highly 1594 desirable for MRs to be able to discover alternate routes 1595 automatically for greater flexibility. 1597 The case where a MR possesses multiple egress interface (bound to the 1598 same HA or otherwise) should be trivial, since the MR should be able 1599 to "realize" it has multiple routes to the global Internet. 1601 In the case where multiple MRs are on the mobile network, each MR has 1602 to detect the presence of other MR. A MR can do so by listening for 1603 Router Advertisement message on its *ingress* interfaces. When a MR 1604 receives a Router Advertisement message with a non-zero Router 1605 Lifetime field from one of its ingress interfaces, it knows that 1606 another MR which can provide an alternate route to the global 1607 Internet is present in the mobile network. 1609 B.2. Re-Establishment of Bi-Directional Tunnels 1611 When a MR detects that the link by which its current bi-directional 1612 tunnel with its HA is using is down, it needs to re-establish the bi- 1613 directional tunnel using an alternate route detected. We consider 1614 two separate cases here: firstly, the alternate route is provided by 1615 another egress interface that belongs to the MR; secondly, the 1616 alternate route is provided by another MR connected to the mobile 1617 network. We refer to the former case as an alternate route provided 1618 by an alternate egress interface, and the latter case as an alternate 1619 route provided by an alternate MR. 1621 B.2.1. Using Alternate Egress Interface 1623 When an egress interface of a MR loses the connection to the global 1624 Internet, the MR can make use of its alternate egress interface 1625 should it possess multiple egress interfaces. The most direct way to 1626 do so is for the MR to send a binding update to the HA of the failed 1627 interface using the CoA assigned to the alternate interface in order 1628 to re-establish the bi-directional tunneling using the CoA on the 1629 alternate egress interface. After a successful binding update, the 1630 MR encapsulates outgoing packets through the bi-directional tunnel 1631 using the alternate egress interface. 1633 The idea is to use the global address (most likely a CoA) assigned to 1634 an alternate egress interface as the new (back-up) CoA of the MR to 1635 re-establish the bi-directional tunneling with its HA. 1637 B.2.2. Using Alternate Mobile Router 1639 When the MR loses a connection to the global Internet, the MR can 1640 utilize a route provided by an alternate MR (if one exists) to re- 1641 establish the bi-directional tunnel with its HA. First, the MR has 1642 to obtain a CoA from the alternate MR (i.e. attaches itself to the 1643 alternate MR). Next, it sends binding update to its HA using the CoA 1644 obtained from the alternate MR. From then on, the MR can 1645 encapsulates outgoing packets through the bi-directional tunnel using 1646 via the alternate MR. 1648 The idea is to obtain a CoA from the alternate MR and use this as the 1649 new (back-up) CoA of the MR to re-establish the bi-directional 1650 tunneling with its HA. 1652 Note that every packet sent between MNNs and their correspondent 1653 nodes will experience two levels of encapsulation. First level of 1654 tunneling occurs between a MR which the MNN uses as its default 1655 router and the MR's HA. The second level of tunneling occurs between 1656 the alternate MR and its HA. 1658 B.3. To Avoid Tunneling Loop 1660 The method of re-establishing the bi-directional tunnel as described 1661 in Appendix B.2 may lead to infinite loops of tunneling. This 1662 happens when two MRs on a mobile network lose connection to the 1663 global Internet at the same time and each MR tries to re-establish 1664 bi-directional tunnel using the other MR. We refer to this 1665 phenomenon as tunneling loop. 1667 One approach to avoid tunneling loop is for a MR that has lost 1668 connection to the global Internet to insert an option into the Router 1669 Advertisement message it broadcasts periodically. This option serves 1670 to notify other MRs on the link that the sender no longer provides 1671 global connection. Note that setting a zero Router Lifetime field 1672 will not work well since it will cause MNNs that are attached to the 1673 MR to stop using the MR as their default router too (in which case, 1674 things are back to square one). 1676 B.4. Points of Considerations 1678 This method of using tunnel re-establishments is by no means a 1679 complete solution. There are still points to consider to develop it 1680 into a fully functional solution. For instance, in Appendix B.1, it 1681 was suggested that MR detects the presence of other MRs using Router 1682 Advertisements. However, Router Advertisements are link scoped, so 1683 when there is more than one link, some information may be lost. For 1684 instance, suppose a case where there is three MRs and three different 1685 prefixes and each MR is in a different link with regular routers in 1686 between. Suppose now that only a single MR is working, how do the 1687 other MRs identify which prefix they have to use to configure the new 1688 CoA? In this case, there are three prefixes being announced and a MR 1689 whose link has failed, knows that his prefix is not to be used, but 1690 it has not enough information to decide which one of the other two 1691 prefixes to use to configure the new CoA. In such cases, a mechanism 1692 is needed to allow a MR to withdraw its own prefix when it discovers 1693 that its link is no longer working. 1695 Appendix C. Change Log 1697 o This draft is an update of draft-ng-nemo-multihoming-issues-03.txt 1698 which is itself a merge of 3 previous drafts 1699 draft-ng-nemo-multihoming-issues-02.txt, 1700 draft-eun-nemo-multihoming-problem-statement-00.txt, and 1701 draft-charbon-nemo-multihoming-evaluation-00.txt 1703 o Changes from draft-ietf-nemo-multihoming-issues-05 to -06: 1705 * Minor editorial corrections and reference update 1707 o Changes from draft-ietf-nemo-multihoming-issues-04 to -05: 1709 * Addressed Issue #23: modified text in Sect 4.2: "Ingress 1710 Filtering" 1712 * Re-phrase statements in Sect 4 and 5 where we "... recommend 1713 issue XXX to be worked on by Monami6/Shim6/IPv6/DNA WG" to 1714 instead suggest that solution to the issue be solicited 1715 elsewhere within the IETF. 1717 o Changes from draft-ietf-nemo-multihoming-issues-03 to -04: 1719 * Updated Section 3: "Deployment Scenarios and Prerequisites" 1721 * Modifications to Section 4: 1723 + Removed "Media Detection" and moved the relevant concerns to 1724 "Path Exploration" 1726 + Added new "Preference Settings" issue 1728 + Various text clean-ups in most of the sub-sections 1730 * Modifications to Section 5: 1732 + Changed Section 5: "Matrix" to "Recommendations to the 1733 Working Group" 1735 + Identifies which are the issues that are important, and made 1736 recommendations as to how to resolve these multihoming 1737 issues 1739 * Addressed Issue #12: Added Appendix B.4: "Points of 1740 Considerations" to document the concerns raised for this tunnel 1741 re-establishment mechanism. 1743 o Changes from draft-ietf-nemo-multihoming-issues-02 to -03: 1745 * Enlisted Marcelo Bagnulo as co-author 1747 * Restructuring of Section 4: 1749 + Re-named 'Path Survival' to 'Fault Tolerance' 1751 + Moved 'Path Failure Detection' and 'Path Selection' as sub- 1752 issues of 'Fault Tolerance' 1754 + Added 'Path Exploration' and 'Re-homing' as sub-issues of 1755 'Fault Tolerance' 1757 + Removed 'Impact on Routing Infrastructure' 1759 * Breaking references into Normative and Informative 1761 o Changes from draft-ietf-nemo-multihoming-issues-01 to -02: 1763 * Added recommendations/suggestion of which WG each issue should 1764 be addressed as pointed out in 61st IETF. 1766 * Minor updates on references. 1768 o Changes from draft-ietf-nemo-multihoming-issues-00 to -01: 1770 * Replaced NEMO-Prefix with MNP as decided by the WG at 60th IETF 1772 * Addressed Issue #1 in Section 1: Added a note to remind readers 1773 that IPv6 is implicitly assumed 1775 * Addressed Issue #3 in Sect 2.3: Removed text on assumption 1777 * Addressed Issue #6 in Sect 3.1 "Deployment Scenarios": Added 1778 benefits 1780 * Addressed Issue #7 in Sect 3.2 "Prerequisites": Modified text 1782 * Addressed Issue #9 in Sect 4.3 "Ingress Filtering": Modified 1783 text 1785 * Addressed Issue #10 in Sect 4.4: Added paragraph on other 1786 failure modes 1788 * Addressed Issue #10: New Sect 4.5 on media detection 1789 * Addressed Issue #11 in Section 4.11: modified text 1791 o Changes from draft-ng-multihoming-issues-03 to 1792 draft-ietf-nemo-multihoming-issues-00: 1794 * Expanded Section 4: "Problem Statement" 1796 * Merged "Evaluation" Section into Section 4: "Problem Statement" 1798 * Cleaned up description in Section 2: "Classification", and 1799 clearly indicate in each classification, what are the 1800 multihomed entities 1802 * Re-organized Section 2: "Deployment Scenarios and 1803 Prerequisites", and created the "Prerequisites" sub-section. 1805 o Changes from draft-ng-multihoming-issues-02 to 1806 draft-ng-multihoming-issues-03: 1808 * Merged with draft-eun-nemo-multihoming-problem-statement (see 1809 Section 4: "Problem Statement") 1811 * Included conclusions from 1812 draft-charbon-nemo-multihoming-evaluation-00 1814 * Re-organized some part of "Benefits/Issues of Multihoming in 1815 NEMO" to Section 4: "Problem Statement" 1817 * Removed lots of text to be in sync with [6]. 1819 * Title changed from "Multihoming Issues in NEMO Basic Support" 1820 to "Analysis of Multihoming in NEMO" 1822 * Changed (w,x,y) to (x,y,z) in taxonomy. 1824 * Moved alternative approaches of classification to Appendix 1826 * Creation of this Change-Log itself ;-) 1828 Authors' Addresses 1830 Chan-Wah Ng 1831 Panasonic Singapore Laboratories Pte Ltd 1832 Blk 1022 Tai Seng Ave #06-3530 1833 Tai Seng Industrial Estate 1834 Singapore 534415 1835 SG 1837 Phone: +65 65505420 1838 Email: chanwah.ng@sg.panasonic.com 1840 Eun Kyoung Paik 1841 KT 1842 Portable Internet Team, Convergence Lab., KT 1843 17 Woomyeon-dong, Seocho-gu 1844 Seoul 137-792 1845 Korea 1847 Phone: +82-2-526-5233 1848 Fax: +82-2-526-5200 1849 Email: euna@kt.co.kr 1850 URI: http://mmlab.snu.ac.kr/~eun/ 1852 Thierry Ernst 1853 INRIA 1854 INRIA Rocquencourt 1855 Domaine de Voluceau B.P. 105 1856 Le Chesnay, 78153 1857 France 1859 Phone: +33-1-39-63-59-30 1860 Fax: +33-1-39-63-54-91 1861 Email: thierry.ernst@inria.fr 1862 URI: http://www.nautilus6.org/~thierry 1864 Marcelo Bagnulo 1865 Universidad Carlos III de Madrid 1866 Av. Universidad, 30 1867 Leganes, Madrid 28911 1868 Spain 1870 Phone: +34 91624 8837 1871 Email: marcelo@it.uc3m.es 1873 Intellectual Property Statement 1875 The IETF takes no position regarding the validity or scope of any 1876 Intellectual Property Rights or other rights that might be claimed to 1877 pertain to the implementation or use of the technology described in 1878 this document or the extent to which any license under such rights 1879 might or might not be available; nor does it represent that it has 1880 made any independent effort to identify any such rights. Information 1881 on the procedures with respect to rights in RFC documents can be 1882 found in BCP 78 and BCP 79. 1884 Copies of IPR disclosures made to the IETF Secretariat and any 1885 assurances of licenses to be made available, or the result of an 1886 attempt made to obtain a general license or permission for the use of 1887 such proprietary rights by implementers or users of this 1888 specification can be obtained from the IETF on-line IPR repository at 1889 http://www.ietf.org/ipr. 1891 The IETF invites any interested party to bring to its attention any 1892 copyrights, patents or patent applications, or other proprietary 1893 rights that may cover technology that may be required to implement 1894 this standard. Please address the information to the IETF at 1895 ietf-ipr@ietf.org. 1897 Disclaimer of Validity 1899 This document and the information contained herein are provided on an 1900 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1901 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1902 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1903 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1904 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1905 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1907 Copyright Statement 1909 Copyright (C) The Internet Society (2006). This document is subject 1910 to the rights, licenses and restrictions contained in BCP 78, and 1911 except as set forth therein, the authors retain all their rights. 1913 Acknowledgment 1915 Funding for the RFC Editor function is currently provided by the 1916 Internet Society.