idnits 2.17.1 draft-ietf-nemo-multihoming-issues-07.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, updated by RFC 4748 on line 1946. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1957. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1964. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1970. 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 IETF Trust Copyright Line does not match the current year -- 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 (February 5, 2007) is 6289 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) ** Downref: Normative reference to an Informational draft: draft-ietf-nemo-requirements (ref. '1') ** Downref: Normative reference to an Informational RFC: RFC 3753 (ref. '2') ** 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-01 == Outdated reference: A later version (-05) exists of draft-ietf-monami6-mipv6-analysis-00 == Outdated reference: A later version (-13) exists of draft-ietf-shim6-failure-detection-07 == Outdated reference: A later version (-06) exists of draft-ietf-dna-link-information-05 == Outdated reference: A later version (-09) exists of draft-ietf-dna-protocol-03 -- Obsolete informational reference (is this intentional?): RFC 2461 (ref. '11') (Obsoleted by RFC 4861) == Outdated reference: A later version (-12) exists of draft-ietf-shim6-proto-07 -- No information found for draft-koh-mip6-nemo-dhap - is the name correct? == Outdated reference: A later version (-03) exists of draft-ietf-nemo-dhcpv6-pd-02 == Outdated reference: A later version (-02) exists of draft-ietf-nemo-prefix-delegation-01 == Outdated reference: A later version (-14) exists of draft-ietf-monami6-multiplecoa-00 -- Obsolete informational reference (is this intentional?): RFC 3484 (ref. '23') (Obsoleted by RFC 6724) == Outdated reference: A later version (-08) exists of draft-thubert-tree-discovery-04 Summary: 5 errors (**), 0 flaws (~~), 12 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: August 9, 2007 T. Ernst 5 INRIA 6 E. Paik 7 KT 8 M. Bagnulo 9 UC3M 10 February 5, 2007 12 Analysis of Multihoming in Network Mobility Support 13 draft-ietf-nemo-multihoming-issues-07 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 August 9, 2007. 40 Copyright Notice 42 Copyright (C) The IETF Trust (2007). 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 . . . . . . . . . . . . . . . . . . . . . . 17 74 4.1. Fault Tolerance . . . . . . . . . . . . . . . . . . . . . 17 75 4.1.1. Failure Detection . . . . . . . . . . . . . . . . . . 17 76 4.1.2. Path Exploration . . . . . . . . . . . . . . . . . . . 19 77 4.1.3. Path Selection . . . . . . . . . . . . . . . . . . . . 20 78 4.1.4. Re-Homing . . . . . . . . . . . . . . . . . . . . . . 22 79 4.2. Ingress Filtering . . . . . . . . . . . . . . . . . . . . 22 80 4.3. HA Synchronization . . . . . . . . . . . . . . . . . . . . 24 81 4.4. MR Synchronization . . . . . . . . . . . . . . . . . . . . 24 82 4.5. Prefix Delegation . . . . . . . . . . . . . . . . . . . . 25 83 4.6. Multiple Bindings/Registrations . . . . . . . . . . . . . 26 84 4.7. Source Address Selection . . . . . . . . . . . . . . . . . 26 85 4.8. Loop Prevention in Nested Mobile Networks . . . . . . . . 26 86 4.9. Prefix Ownership . . . . . . . . . . . . . . . . . . . . . 27 87 4.10. Preference Settings . . . . . . . . . . . . . . . . . . . 27 89 5. Recommendations to the Working Group . . . . . . . . . . . . . 29 90 6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 32 92 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 94 8. Security Considerations . . . . . . . . . . . . . . . . . . . 32 96 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 32 98 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33 99 10.1. Normative References . . . . . . . . . . . . . . . . . . . 33 100 10.2. Informative References . . . . . . . . . . . . . . . . . . 33 102 Appendix A. Alternative Classifications Approach . . . . . . . . 36 103 A.1. Ownership-Oriented Approach . . . . . . . . . . . . . . . 36 104 A.1.1. ISP Model . . . . . . . . . . . . . . . . . . . . . . 36 105 A.1.2. Subscriber/Provider Model . . . . . . . . . . . . . . 37 106 A.2. Problem-Oriented Approach . . . . . . . . . . . . . . . . 39 108 Appendix B. Nested Tunneling for Fault Tolerance . . . . . . . . 40 109 B.1. Detecting Presence of Alternate Routes . . . . . . . . . . 40 110 B.2. Re-Establishment of Bi-Directional Tunnels . . . . . . . . 41 111 B.2.1. Using Alternate Egress Interface . . . . . . . . . . . 41 112 B.2.2. Using Alternate Mobile Router . . . . . . . . . . . . 41 113 B.3. To Avoid Tunneling Loop . . . . . . . . . . . . . . . . . 42 114 B.4. Points of Considerations . . . . . . . . . . . . . . . . . 42 116 Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 43 118 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 47 119 Intellectual Property and Copyright Statements . . . . . . . . . . 48 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 does so by setting up bi-directional tunnels between the mobile 130 routers (MRs) connecting the mobile network to the Internet and their 131 respective home agents (HAs), much like how this is done in Mobile 132 IPv6 [5], the solution for host mobility support. NEMO Basic Support 133 is transparent to nodes located behind the mobile router (i.e. the 134 mobile network nodes, or MNNs) and as such does not require MNNs to 135 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 in section 5 of the NEMO Basic Support Requirements [1] 149 (R.12), the NEMO WG must ensure that NEMO Basic Support does not 150 prevent mobile networks to be multihomed, i.e. when there is more 151 than one point of attachment between the mobile network and the 152 Internet (see definitions in [3]). 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 objectives of this memo 167 are thus multifold: 169 o to determine all the potential multihomed configurations for a 170 NEMO, and then to identify which of these 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 the ones 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 decide which issues are worth solving and to determine which WG 181 is the most appropriate to address these; 183 o to identify potential solutions to the previously identified 184 issues. 186 In order to reach these objectives, a taxonomy for classifying 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 Scenarios for Multihoming 202 [6], Goals and Requirements of Network Mobility Support [1], and the 203 NEMO Basic Support specification [4]. Goals and benefits of 204 multihoming as discussed in [6] are applicable to fixed nodes, mobile 205 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 that a mobile network has only a single MR, 228 presumably multihomed. 230 x=n implies that 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 with 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 foreign 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]. 258 In addition, the readers should also keep in mind that when "MNP(s) 259 is/are available in the NEMO", the MNP(s) may either be explicitly 260 announced by the MR via router advertisement, or made available 261 through Dynamic Host Configuration Protocol (DHCP). 263 2.1. (1,1,1): Single MR, Single HA, Single MNP 265 The (1,1,1) configuration has only one MR, it is associated with a 266 single HA, and a single MNP is available in the NEMO. To fall into a 267 multihomed configuration, at least one of the following conditions 268 must hold: 270 o The MR has multiple interfaces and thus it has multiple CoAs; 272 o Multiple global prefixes are available on the foreign link, and 273 thus it has multiple CoAs; or 275 Note that the case where multiple prefixes are available on the 276 foreign link does not have any bearing on the MNPs. MNPs are 277 independent of prefixes available on the link where the MR is 278 attached to, thus prefixes available on the foreign link are not 279 announced on the NEMO link. For the case where multiple prefixes are 280 available on the home link, these are only announced on the NEMO link 281 if the MR is configured to do so. In this configuration, only one 282 MNP is announced. 284 A bi-directional tunnel would then be established between each {HA 285 address,CoA} pair. 287 Regarding MNNs, they are (usually) not multihomed since they would 288 configure a single global address from the single MNP available on 289 the link they are attached to. 291 _____ 292 _ p _ | | 293 |_|-|<-_ |-|_|-| |-| _ 294 _ |-|_|=| |_____| | _ |-|_| 295 |_|-| | |-|_|-| 296 | 297 MNNs MR AR Internet AR HA 299 Figure 1: (1,1,1): 1 MR, 1 HA, 1 MNP 301 2.2. (1,1,n): Single MR, Single HA, Multiple MNPs 303 The (1,1,n) configuration has only one MR, it is associated with a 304 single HA and two or more MNPs are available in the NEMO. 306 The MR may itself be multihomed, as detailed in Section 2.1. A bi- 307 directional tunnel would be established between each {HA address,CoA} 308 pair. 310 Regarding MNNs, they are multihomed because several MNPs are 311 available on the link they are attached to. The MNNs would then 312 configure a global address from each MNP available on the link. 314 _____ 315 _ p1,p2 _ | | 316 |_|-|<-_ |-|_|-| |-| _ 317 _ |-|_|=| |_____| | _ |-|_| 318 |_|-| | |-|_|-| 319 | 320 MNNs MR AR Internet AR HA 322 Figure 2: (1,1,n): 1 MR, 1 HA, multiple MNPs 324 2.3. (1,n,1): Single MR, Multiple HAs, Single MNP 326 The (1,n,1) configuration has only one MR and a single MNP is 327 available in the NEMO. The MR, however, is associated with multiple 328 HAs. 330 The NEMO is multihomed since it has multiple HAs, but in addition the 331 conditions detailed in Section 2.1 may also hold for the MR. A bi- 332 directional tunnel would be established between each {HA address,CoA} 333 pair. 335 Regarding MNNs, they are (usually) not multihomed since they would 336 configure a single global address from the single MNP available on 337 the link they are attached to. 339 AR HA2 340 _ | 341 |-|_|-| _ 342 _____ | |-|_| 343 _ p _ | |-| 344 |_|-|<-_ |-|_|-| | 345 _ |-|_|=| |_____|-| _ 346 |_|-| | | _ |-|_| 347 |-|_|-| 348 | 349 MNNs MR AR Internet AR HA1 351 Figure 3: (1,n,1): 1 MR, multiple HAs, 1 MNP 353 2.4. (1,n,n): Single MR, Multiple HAs, Multiple MNPs 355 The (1,n,n) configuration has only one MR. However, the MR is 356 associated with multiple HAs and more than one MNP is available in 357 the NEMO. 359 The MR is multihomed since it has multiple HAs, but in addition the 360 conditions detailed in Section 2.1 may also hold. A bi-directional 361 tunnel would be established between each {HA address,CoA} pair. 363 Regarding MNNs, they are multihomed because several MNPs are 364 available on the link they are attached to. The MNNs would then 365 configure a global address with each MNP available on the link. 367 AR HA2 368 _ | _ 369 _____ |-|_|-|-|_| 370 _ p1,p2 _ | |-| | 371 |_|-|<-_ |-|_|-| | _ 372 _ |-|_|=| |_____|-| _ |-|_| 373 |_|-| | |-|_|-| 374 | | 375 MNNs MR AR Internet AR HA1 377 Figure 4: (1,n,n): 1 MR, multiple HAs, multiple MNPs 379 2.5. (n,1,1): Multiple MRs, Single HA, Single MNP 381 The (n,1,1) configuration has more than one MR advertising global 382 routes. However, the MR(s) are associated with as single HA, and 383 there in a single MNP available in the NEMO. 385 The NEMO is multihomed since it has multiple MRs, but in addition the 386 conditions detailed in Section 2.1 may also hold for each MR. A bi- 387 directional tunnel would be established between each {HA address,CoA} 388 pair. 390 Regarding MNNs, they are (usually) not multihomed since they would 391 configure a single global address from the single MNP available on 392 the link they are attached to. 394 MR2 395 p<-_ | 396 _ |-|_|-| _____ 397 |_|-| |-| | 398 _ | | |-| _ 399 |_|-| _ |-|_____| | _ |-|_| 400 |-|_|-| |-|_|-| 401 p<- | | 402 MNNs MR1 Internet AR HA 404 Figure 5: (n,1,1): Multiple MRs, 1 HA, 1 MNP 406 2.6. (n,1,n): Multiple MRs, Single HA, Multiple MNPs 408 The (n,1,n) configuration has more than one MR; multiple global 409 routes are advertised by the MRs and multiple MNPs are available 410 within the NEMO. 412 The NEMO is multihomed since it has multiple MRs, but in addition the 413 conditions detailed in Section 2.1 may also hold for each MR. A bi- 414 directional tunnel would be established between each {HA address,CoA} 415 pair. 417 Regarding MNNs, they are multihomed because several MNPs are 418 available on the link they are attached to. The MNNs would then 419 configure a global address with each MNP available on the link. 421 MR2 422 p2<-_ | 423 _ |-|_|-| _____ 424 |_|-| |-| | 425 _ | | |-| _ 426 |_|-| _ |-|_____| | _ |-|_| 427 |-|_|-| |-|_|-| 428 p1<- | | 429 MNNs MR1 Internet AR HA 431 Figure 6: (n,1,n): Multiple MRs, 1 HA, multiple MNPs 433 2.7. (n,n,1): Multiple MRs, Multiple HAs, Single MNP 435 The (n,n,1) configuration has more than one MR advertising multiple 436 global routes. The mobile network is simultaneously associated with 437 multiple HAs and a single MNP is available in the NEMO. 439 The NEMO is multihomed since it has multiple MRs and HAs, but in 440 addition the conditions detailed in Section 2.1 may also hold for 441 each MR. A bi-directional tunnel would be established between each 442 {HA address,CoA} pair. 444 Regarding MNNs, they are (usually) not multihomed since they would 445 configure a single global address from the single MNP available on 446 the link they are attached to. 448 MR2 AR HA2 449 p _ | 450 <-_ | |-|_|-| _ 451 _ |-|_|-| _____ | |-|_| 452 |_|-| |-| |-| 453 _ | | | 454 |_|-| _ |-|_____|-| _ 455 |-|_|-| | _ |-|_| 456 <- | |-|_|-| 457 p | 458 MNNs MR1 Internet AR HA1 460 Figure 7: (n,n,1): Multiple MRs, Multiple HAs, 1 MNP 462 2.8. (n,n,n): Multiple MRs, Multiple HAs, Multiple MNPs 464 The (n,n,n) configuration has multiple MRs advertising different 465 global routes. The mobile network is simultaneously associated with 466 more than one HA and multiple MNPs are available in the NEMO. 468 The NEMO is multihomed since it has multiple MRs and HAs, but in 469 addition the conditions detailed in Section 2.1 may also hold for 470 each MR. A bi-directional tunnel would be established between each 471 {HA address,CoA} pair. 473 Regarding MNNs, they are multihomed because several MNPs are 474 available on the link they are attached to. The MNNs would then 475 configure a global address with each MNP available on the link. 477 MR2 AR HA2 478 p2 _ | 479 <-_ | |-|_|-| _ 480 _ |-|_|-| _____ | |-|_| 481 |_|-| |-| |-| 482 _ | | | 483 |_|-| _ |-|_____|-| _ 484 |-|_|-| | _ |-|_| 485 <- | |-|_|-| 486 p1 | 487 MNNs MR1 Internet AR HA1 489 Figure 8: (n,n,n): Multiple MRs, HAs, and MNPs 491 3. Deployment Scenarios and Prerequisites 493 The following generic goals and benefits of multihoming are discussed 494 in [6]: 496 1. Permanent and Ubiquitous Access 498 2. Reliability 500 3. Load Sharing 502 4. Load Balancing/Flow Distribution 504 5. Preference Settings 506 6. Aggregate Bandwidth 508 These benefits are now illustrated from a NEMO perspective with a 509 typical instance scenario for each case in the taxonomy. We then 510 discuss the prerequisites to fulfill these. 512 3.1. Deployment Scenarios 514 x=1: Multihomed mobile networks with a single MR 516 o Example 1: 518 MR with dual/multiple access interfaces (e.g. 802.11 and GPRS 519 capabilities). This is a (1,1,*) if both accesses are 520 performed with the same ISP. If the two accesses are offered 521 by independent ISPs, this is a (1,n,n) configuration. 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: 530 Train with one MR in each car, all served by the same HA, thus 531 a (n,1,*) configuration. Alternatively, the train company 532 might be forced to use different ISPs when the train crosses 533 different countries, thus a (n,n,n) configuration. 535 Benefits: Ubiquitous Access, Reliability, Load Sharing, 536 Aggregate Bandwidth. 538 o Example 2: 540 W-PAN with a GPRS-enabled phone and a WiFi-enabled PDA. This 541 is a (n,n,n) configuration if the two access technologies are 542 subscribed separately. 544 Benefits: Ubiquitous Access, Reliability, Preference Settings, 545 Aggregate Bandwidth. 547 y=1: Multihomed mobile networks with a single HA 549 o Example: 551 Most single ISP cases in above examples. 553 y=N: Multihomed mobile networks with multiple HAs 555 o Example 1: 557 Most multiple ISP cases in above examples. 559 o Example 2: 561 Transatlantic flight with a HA in each continent. This is a 562 (1,n,1) configuration if there is only one MR. 564 Benefits: Ubiquitous Access, Reliability, Preference Settings 565 (reduced delay, shortest path). 567 z=1: Multihomed mobile networks with a single MNP 569 o Example: 571 Most single ISP cases in above examples. 573 z=N: Multihomed mobile networks with multiple MNPs 575 o Example 1: 577 Most multiple ISP cases in above examples. 579 o Example 2: 581 Car with a prefix taken from home (personal traffic is 582 transmitted using this prefix and is paid by the owner) and one 583 that belongs to the car manufacturer (maintenance traffic is 584 paid by the car manufacturer). This will typically be a 585 (1,1,n) or a (1,n,n,) configuration. 587 Benefits: Preference Settings 589 3.2. Prerequisites 591 In this section, requirements are stated in order to comply with the 592 expected benefits of multihoming as detailed in [6]. 594 At least one bi-directional tunnel must be available at any point in 595 time between the mobile network and the fixed network to meet all 596 expectations. But for most goals to be effective, multiple tunnels 597 must be maintained simultaneously: 599 o Permanent and Ubiquitous Access: 601 At least one bi-directional tunnel must be available at any point 602 in time. 604 o Reliability: 606 Both the inbound and outbound traffic must be transmitted or 607 diverted over another bi-directional tunnel once a bi-directional 608 tunnel is broken or disrupted. It should be noted that the 609 provision of fault tolerance capabilities does not necessarily 610 require the existence of multiple bi-directional tunnels 611 simultaneously. 613 o Load Sharing and Load Balancing: 615 Multiple tunnels must be maintained simultaneously. 617 o Preference Settings: 619 Implicitly, multiple tunnels must be maintained simultaneously if 620 preferences are set for deciding which of the available bi- 621 directional tunnels should be used. To allow user/application to 622 set the preference, a mechanism should be provided to the user/ 623 application for the notification of the availability of multiple 624 bi-directional tunnels, and perhaps also to set preferences. 625 Similar mechanism should also be provided to network 626 administrators to manage preferences. 628 o Aggregate Bandwidth: 630 Multiple tunnels must be maintained simultaneously in order to 631 increase the total aggregated bandwidth available to the mobile 632 network. 634 4. Multihoming Issues 636 As discussed in the previous section, multiple bi-directional tunnels 637 need to be maintained either sequentially (e.g. for fault tolerance) 638 or simultaneously (e.g. for load sharing). 640 In some cases, it may be necessary to divert packets from a (perhaps 641 failed) bi-directional tunnel to an alternative (perhaps newly 642 established) bi-directional tunnel (i.e. for matters of fault 643 recovery, preferences), or to split traffic between multiple tunnels 644 (load sharing, load balancing). 646 So, depending on the configuration under consideration, the issues 647 discussed below may need to be addressed sometimes dynamically. For 648 each issue, potential ways to solve the problem are investigated. 650 4.1. Fault Tolerance 652 One of the goals of multihoming is the provision of fault tolerance 653 capabilities. In order to provide such features, a set of tasks need 654 to be performed, including: failure detection, alternative available 655 path exploration, path selection, re-homing of established 656 communications. These are also discussed in [8] and [8] by the Shim6 657 WG. In the following sub-sections, we look at these issues in the 658 specific context of NEMO, rather than the general Shim6 perspective 659 in [8]. In addition, in some scenarios, it may also be required to 660 provide the mechanisms for coordination between different HAs (see 661 Section 4.3) and also the coordination between different MRs (see 662 Section 4.4). 664 4.1.1. Failure Detection 666 It is expected for faults to occur more readily at the edge of the 667 network (i.e. the mobile nodes), due to the use of wireless 668 connections. Efficient fault detection mechanisms are necessary to 669 recover in timely fashion. 671 Depending on the NEMO configuration considered, the failure 672 protection domain greatly varies. In some configurations, the 673 protection domain provided by NEMO multihoming is limited to the 674 links between the MR(s) and the HA(s). In other configurations, the 675 protection domain allows to recover from failures in other parts of 676 the path, so an end to end failure detection mechanism is required. 678 Below are detailed which failure detection capabilities are required 679 for each configuration: 681 o For the (1,1,*) cases, multiple paths are available between a 682 single MR and a single HA. All the traffic from and to the NEMO 683 flows through these MR and HA. Failure detection mechanisms need 684 only to be executed between these two devices. This is a NEMO/ 685 MIPv6 specific issue. 687 o For the (n,1,*) cases, there is a single HA, so all the traffic 688 from and to the NEMO will flow through it. The failure detection 689 mechanisms need to be able to detect failure in the path between 690 the used MR and the only HA. Hence, the failure detection 691 mechanism needs only to involve the HA and the MRs. This is a 692 NEMO/MIPv6 specific issue. 694 o For the (n,n,*) cases, there are multiple paths between the 695 different HAs and the different MRs. Moreover, the HAs may be 696 located in different networks, and have different Internet access 697 links. This implies that changing the HA used may not only allow 698 recovering from failures in the link between the HA and the MR, 699 but also from other failure modes, affecting other parts of the 700 path. In this case, an end-to-end failure detection mechanism 701 would provide additional protection. However, a higher number of 702 failures is likely to occur in the link between the HA and the MR, 703 so it may be reasonable to provide optimized failure detection 704 mechanisms for this failure mode. The (n,n,n) case is hybrid, 705 since selecting a different prefix results in a change of path. 706 For this case the Shim6 protocols (such as those discussed in [8]) 707 may be useful. 709 Most of the above cases involve the detection of tunnel failures 710 between HA(s) and MR(s). This is no different from the case of 711 failure detection between a mobile host and its HA(s). As such, a 712 solution for MIPv6 should apply to NEMO as well. For case (n,*,*), a 713 MR synchronization solution (see Section 4.4) should be able to 714 complement a MIPv6 failure detection solution to achieve the desired 715 functionality for NEMO. 717 In order for fault recovery to work, the MRs and HAs must first 718 possess a means to detect failures: 720 o On the MR's side, the MR can rely on router advertisements from 721 access routers, or other layer-2 trigger mechanisms to detect 722 faults, e.g. [9] and [10]. 724 o On the HA's side, it is more difficult to detect tunnel failures. 725 For an ISP deployment model, the HAs and MRs can use proprietary 726 methods (such as constant transmission of heartbeat signals) to 727 detect failures and check tunnel liveness. In the subscriber 728 model (see Appendix A.2: S/P model), a lack of standardized 729 "tunnel liveness" protocol means that it is harder to detect 730 failures. 732 A possible method is for the MRs to send binding updates more 733 regularly with shorter Lifetime values. Similarly, HAs can return 734 binding acknowledgment messages with smaller Lifetime values, thus 735 forcing the MRs to send binding updates more frequently. These 736 binding updates can be used to emulate "tunnel heartbeats". This 737 however may lead to more traffic and processing overhead, since 738 binding updates sent to HAs must be protected (and possibly 739 encrypted) with security associations. 741 4.1.2. Path Exploration 743 Once a failure in the currently used path is detected, alternative 744 paths have to be explored in order to identify an available one. 745 This process is closely related to failure detection in the sense 746 that paths being explored need to be alternative paths to the one 747 that has failed. There are, however, subtle but significant 748 differences between path exploration and failure detection. Failure 749 detection occurs on the currently used path while path exploration 750 occurs on the alternative paths (not on the one currently being used 751 for exchanging packets). Although both path exploration and failure 752 detection are likely to rely on a reachability or keepalive test 753 exchange, failure detection also relies on other information, such as 754 upper layer information (e.g. positive or negative feedback form 755 TCP), lower layer information (e.g. an interface is down), and 756 network layer information (e.g. as an address being deprecated or 757 ICMP error message). 759 Basically, the same cases as in the analysis of the failure detection 760 (Section 4.1.1) issue are identified: 762 o For the (1,1,*) cases, multiple paths are available between a 763 single MR and a single HA. The existing paths between the HA and 764 the MR have to be explored to identify an available one. The 765 mechanism involves only the HA and the MR. This is a NEMO/MIPv6 766 specific issue. 768 o For the (n,1,*) cases, there is a single HA, so all the traffic 769 from and to the NEMO will flow through it. The available 770 alternative paths are the different ones between the different MRs 771 and the HA. The path exploration mechanism only involves the HA 772 and the MRs. This is a NEMO/MIPv6 specific issue. 774 o For the (n,n,*) cases, there are multiple paths between the 775 different HAs and the different MRs. In this case, alternative 776 paths may be routed completely independently one from one another. 778 An end-to-end path exploration mechanism would be able to discover 779 if any of the end-to-end paths is available. The (n,n,1) case, 780 however, seems to be pretty NEMO specific, because of the absence 781 of multiple prefixes. The (n,n,n) case is hybrid, since selecting 782 a different prefix results in a change of path. For this case the 783 Shim6 protocols (such as those discussed in [8]) may be useful. 785 Most of the above cases involve the path exploration of tunnels 786 between HA(s) and MR(s). This is no different from the case of path 787 exploration between a mobile host and its HA(s). As such, a solution 788 for MIPv6 should apply to NEMO as well. For case (n,*,*), a MR 789 synchronization solution (see Section 4.4) should be able to 790 compliment a MIPv6 path exploration solution to achieve the desired 791 functionality for NEMO. 793 In order to perform path exploration, it is sometimes also necessary 794 for the mobile router to detect the availability of network media. 795 This may be achieved using layer 2 triggers [9], or other mechanism 796 developed/recommended by the Detecting Network Attachment (DNA) 797 Working Group [10]. This is related to Section 4.1.1, since the 798 ability to detect media availability would often implies the ability 799 to detect media un-availability. 801 4.1.3. Path Selection 803 A path selection mechanism is required to select among the multiple 804 available paths. Depending on the NEMO multihoming configuration 805 involved, the differences between the paths may affect only the part 806 between the HA and the MR, or they may affect the full end-to-end 807 path. In addition, depending on the configuration, path selection 808 may be performed by the HA(s), the MR(s) or the hosts themselves 809 through address selection, as will be described in details next. 811 The multiple available paths may differ on the tunnel between the MR 812 and the HA used to carry traffic to/from the NEMO. In this case, 813 path selection is performed by the MR and the intra-NEMO routing 814 system for traffic flowing from the NEMO, and path selection is 815 performed by the HA and intra-Home Network routing system for traffic 816 flowing to the NEMO. 818 Alternatively, the multiple paths available may differ in more than 819 just the tunnel between the MR and the HA, since the usage of 820 different prefixes may result in using different providers, hence in 821 completely different paths between the involved endpoints. In this 822 case, besides the mechanisms presented in the previous case, 823 additional mechanisms for the end-to-end path selection may be 824 needed. This mechanism may be closely related to source address 825 selection mechanisms within the hosts, since selecting a given 826 address implies selecting a given prefix, which is associated with a 827 given ISP serving one of the home networks. 829 A dynamic path selection mechanism is thus needed so that this path 830 could be selected by: 832 o The HA: it should be able to select the path based on some 833 information recorded in the binding cache. 835 o The MR: it should be able to select the path based on router 836 advertisements received on both its egress interfaces or on its 837 ingress interfaces for the (n,*,*) case. 839 o The MNN: it should be able to select the path based on "Default 840 Router Selection" (see [Section 6.3.6. Default Router Selection] 841 [11]) in the (n,*,*) case or based on "Source Address Selection" 842 in the (*,*,n) cases (see Section 4.7 of the present memo). 844 o The user or the application: e.g. in case where a user wants to 845 select a particular access technology among the available 846 technologies for reasons e.g. of cost or data rate. 848 o A combination of any of the above: a hybrid mechanism should be 849 also available, e.g. one in which the HA, the MR, and/or the MNNs 850 are coordinated to select the path. 852 When multiple bi-directional tunnels are available and possibly used 853 simultaneously, the mode of operation may be either primary-secondary 854 (one tunnel is precedent over the others and used as the default 855 tunnel, while the other serves as a back-up) or peer-to-peer (no 856 tunnel has precedence over one another, they are used with the same 857 priority). This questions which of the bi-directional tunnels would 858 be selected, and based on which of the parameters (e.g. type of flow 859 that goes into/out of the mobile network). 861 The mechanisms for the selection among the different tunnels between 862 the MR(s) and the HA(s) seems to be quite NEMO/MIPv6 specific. 864 For (1,*,*) cases, they are no different from the case of path 865 selection between a mobile host and its HA(s). As such, a solution 866 for MIPv6 should apply to NEMO as well. For the (n,*,*) cases, a MR 867 synchronization solution (see Section 4.4) should be able to 868 compliment a MIPv6 path selection solution to achieve the desired 869 functionality for NEMO. 871 The mechanisms for selecting among different end-to-end paths based 872 on address selection are similar to the ones used in other 873 multihoming scenarios, as those considered by Shim6 (e.g. [12]). 875 4.1.4. Re-Homing 877 After an outage has been detected and an available alternative path 878 has been identified, a re-homing event takes place, diverting the 879 existing communications from one path to the other. Similar to the 880 previous items involved in this process, the re-homing procedure 881 heavily varies depending on the NEMO multihoming configuration. 883 o For the (*,*,1) configurations, the re-homing procedure involves 884 only the MR(s) and the HA(s). The re-homing procedure may involve 885 the exchange of additional BU messages. These mechanisms are 886 shared between NEMO Basic Support and MIPv6. 888 o For the (*,*,n) cases, in addition to the previous mechanisms, end 889 to end mechanisms may be required. Such mechanisms may involve 890 some form of end to end signaling or may simply rely on using 891 different addresses for the communication. The involved 892 mechanisms may be similar to those required for re-homing Shim6 893 communications (e.g. [12]). 895 4.2. Ingress Filtering 897 Ingress filtering mechanisms [13][14] may drop the outgoing packets 898 when multiple bi-directional tunnels end up at different HAs. This 899 could particularly occur if different MNPs are handled by different 900 HAs. If a packet with a source address configured from a specific 901 MNP is tunneled to a home agent that does not handle that specific 902 MNP the packet may be discarded either by the home agent or by a 903 border router in the home network. 905 The ingress filtering compatibility issue is heavily dependent on the 906 particular NEMO multihoming configuration: 908 o For the (*,*,1) cases, there is not such an issue, since there is 909 a single MNP. 911 o For the (1,1,*) and (n,1,1) cases, there is not such a problem, 912 since there is a single HA, accepting all the MNPs. 914 o For the (n,1,n) case, though ingress filtering would not occur at 915 the HA, it may occur at the MRs, when each MR is handling 916 different MNPs. 918 o (*,n,n) are the cases where the ingress filtering presents some 919 difficulties. In the (1,n,n) case, the problem is simplified 920 because all the traffic from and to the NEMO is routed through a 921 single MR. Such configuration allows the MR to properly route 922 packets respecting the constraints imposed by ingress filtering. 924 In this case, the single MR may face ingress filtering problems 925 that a multihomed mobile node may face, as documented in [7]. The 926 more complex case is the (n,n,n) case. A simplified case occurs 927 when all the prefixes are accepted by all the HAs, so that no 928 problems occur with the ingress filtering. However, this cannot 929 be always assumed, resulting in the problem described below. 931 As an example of how this could happen, consider the deployment 932 scenario illustrated in Figure 9: the mobile network has two mobile 933 routers MR1 and MR2, with home agents HA1 and HA2 respectively. Two 934 bi-directional tunnels are established between the two pairs. Each 935 mobile router advertises a different MNP (P1 and P2 respectively). 936 MNP P1 is registered to HA1, and MNP P2 is registered to HA2. Thus, 937 MNNs should be free to auto-configure their addresses on any of P1 or 938 P2. Ingress filtering could thus happen in two cases: 940 o If the two tunnels are available, MNN cannot forward packet with 941 source address equals P1.MNN to MR2. This would cause ingress 942 filtering at HA2 to occur (or even at MR2). This is contrary to 943 normal Neighbor Discovery [11] practice that an IPv6 node is free 944 to choose any router as its default router regardless of the 945 prefix it chooses to use. 947 o If the tunnel to HA1 is broken, packets that would normally be 948 sent through the tunnel to HA1 should be diverted through the 949 tunnel to HA2. If HA2 (or some border router in HA2's domain) 950 performs ingress filtering, packets with source address configured 951 from MNP P1 may be discarded. 953 Prefix: P1 +-----+ +----+ +----------+ +-----+ 954 +--| MR1 |--| AR |--| |---| HA1 | 955 | +-----+ +----+ | | +-----+ 956 IP: +-----+ | | | Prefix: P1 957 P1.MNN or | MNN |--+ | Internet | 958 P2.MNN +-----+ | | | Prefix: P2 959 | +-----+ +----+ | | +-----+ 960 +--| MR2 |--| AR |--| |---| HA2 | 961 Prefix: P2 +-----+ +----+ +----------+ +-----+ 963 Figure 9: An (n,n,n) mobile network 965 Possible solutions to the ingress filtering incompatibility problem 966 may be based on the following approaches: 968 o Some form of source address dependent routing, whether host-based 969 and/or router-based where the prefix contained in the source 970 address of the packet is considered when deciding which exit 971 router to use when forwarding the packet. 973 o The usage of nested tunnels for (*,n,n) cases. Appendix B 974 describes one such approach. 976 o Deprecating those prefixes associated to non-available exit 977 routers. 979 The ingress filtering incompatibilities problems that appear in some 980 NEMO multihoming configurations are similar to those considered in 981 Shim6 (e.g. see [15]). 983 4.3. HA Synchronization 985 In the (*,n,*) configuration, a single MNP would be registered at 986 different HAs. This gives rise to the following cases: 988 o Only one HA may actively advertise a route to the MNP, 990 o Multiple HAs at different domains may advertise a route to the 991 same MNP. 993 This may pose a problem in the routing infrastructure as a whole if 994 the HAs are located in different administrative domains. The 995 implications of this aspect needs further exploration. Certain level 996 of HA co-ordination may be required. A possible approach is to adopt 997 a HA synchronization mechanism such as that described in [16] and 998 [17]. Such synchronization might also be necessary in a (*,n,*) 999 configuration, when a MR sends binding update messages to only one HA 1000 (instead of all HAs). In such cases, the binding update information 1001 might have to be synchronized between HAs. The mode of 1002 synchronization may be either primary-secondary or peer-to-peer. In 1003 addition, when a MNP is delegated to the MR (see Section 4.5), some 1004 level of co-ordination between the HAs may also be necessary. 1006 This issue is a general mobility issue that will also have to be 1007 dealt with by Mobile IPv6 as well as NEMO Basic Support. 1009 4.4. MR Synchronization 1011 In the (n,*,*) configurations, there are common decisions which may 1012 require synchronization among different MRs [18], such as: 1014 o advertising the same MNP in the (n,*,1) configurations (see also 1015 "prefix delegation" in Section 4.5); 1017 o one MR relaying the advertisement of the MNP from another failed 1018 MR in the (n,*,n) configuration; and 1020 o relaying between MRs everything that needs to be relayed, such as 1021 data packets, creating a tunnel from the ingress interface, etc, 1022 in the (n,*,*) configuration. 1024 However, there is no known standardized protocols for this kind of 1025 router-to-router synchronization. Without such synchronization, it 1026 may not be possible for a (n,*,*) configuration to achieve various 1027 multihoming goals, such as fault tolerance. 1029 Such a synchronization mechanism can be primary-secondary (i.e. a 1030 master MR, with the other MRs as backup) or peer-to-peer (i.e. there 1031 is no clear administrative hierarchy between the MRs). The need for 1032 such mechanism is general in the sense that a multi-router site in 1033 the fixed network would require the same level of router 1034 synchronization. 1036 Thus, this issue is not specific to NEMO Basic Support, though there 1037 is a more pressing need to develop a MR to MR synchronization scheme 1038 for proving fault tolerances and failure recovery in NEMO 1039 configurations due to the higher possibility of links failure. 1041 In conclusion it is recommended to investigate a generic solution to 1042 this issue although the solution would first have to be developed for 1043 NEMO deployments. 1045 4.5. Prefix Delegation 1047 In the (*,*,1) configurations, the same MNP must be advertised to the 1048 MNNs through different paths. There is, however, no synchronization 1049 mechanism available to achieve this. Without a synchronization 1050 mechanism, MR may end up announcing incompatible MNPs. Particularly, 1052 o for the (*,n,1) cases, how can multiple HAs delegate the same MNP 1053 to the mobile network? For doing so, the HAs may be somehow 1054 configured to advertise the same MNP (see also "HA 1055 Synchronization" in Section 4.3). 1057 o for the (n,*,1) cases, how can multiple MRs be synchronized to 1058 advertise the same MNP down the NEMO-link? For doing so, the MRs 1059 may be somehow configured to advertise the same MNP (see also "MR 1060 Synchronization" in Section 4.4). 1062 Prefix delegation mechanisms [19][20][21] could be used to ensure all 1063 routers advertise the same MNP. Their applicability to a multihomed 1064 mobile network should be considered. 1066 4.6. Multiple Bindings/Registrations 1068 When a MR is configured with multiple Care-of Addresses, it is often 1069 necessary for it to bind these Care-of Addresses to the same MNP. 1071 This is a generic mobility issue, since Mobile IPv6 nodes face a 1072 similar problem. This issue is discussed in [7]. It is sufficient 1073 to note that solutions like [22] can solve this for both Mobile IPv6 1074 and NEMO Basic Support. This issue is being dealt with in the 1075 Monami6 WG. 1077 4.7. Source Address Selection 1079 In the (*,*,n) configurations, MNNs would be configured with multiple 1080 addresses. Source address selection mechanisms are needed to decide 1081 which address to choose from. 1083 However, currently available source address selection mechanisms do 1084 not allow MNNs to acquire sufficient information to select their 1085 source addresses intelligently (such as based on the traffic 1086 condition associated with the home network of each MNP). It may be 1087 desirable for MNNs to be able to acquire "preference" information on 1088 each MNP from the MRs. This would allow default address selection 1089 mechanisms such as those specified in [23] to be used. Further 1090 exploration on setting such "preference" information in Router 1091 Advertisement based on performance of the bi-directional tunnel might 1092 prove to be useful. Note that source address selection may be 1093 closely related to path selection procedures (see Section 4.1.3) and 1094 re-homing techniques (see Section 4.1.4). 1096 This is a general issue faced by any node when offered multiple 1097 prefixes. 1099 4.8. Loop Prevention in Nested Mobile Networks 1101 When a multihomed mobile network is nested within another mobile 1102 network, it can result in very complex topologies. For instance, a 1103 nested mobile network may be attached to two different root-MRs, thus 1104 the aggregated network no longer forms a simple tree structure. In 1105 such a situation, infinite loop within the mobile network may occur. 1107 This problem is specific to NEMO Basic Support. However, at the time 1108 of writing, more research is recommended to assess the probability of 1109 loops occurring in a multihomed mobile network. For related work, 1110 see [24] for a mechanism to avoid loops in nested NEMO. 1112 4.9. Prefix Ownership 1114 When a (n,*,1) network splits, (i.e. the two MRs split themselves 1115 up), MRs on distinct links may try to register the only available 1116 MNP. This cannot be allowed, as the HA has no way to know which node 1117 with an address configured from that MNP is attached to which MR. 1118 Some mechanism must be present for the MNP to either be forcibly 1119 removed from one (or all) MRs, or the implementors must not allow a 1120 (n,*,1) network to split. 1122 A possible approach to solving this problem is described in [25]. 1124 This problem is specific to NEMO Basic Support. However, it is 1125 unclear whether there is sufficient deployment scenario for this 1126 problem to occur. 1128 It is recommended that the NEMO WG standardizes a solution to solve 1129 this problem if there is sufficient vendor/operator interest, or 1130 specifies that the split of a (n,*,1) network cannot be allowed 1131 without a router renumbering. 1133 4.10. Preference Settings 1135 When a mobile network is multihomed, the MNNs may be able to benefit 1136 from this configuration, such as to choose among the available paths 1137 based on cost, transmission delays, bandwidth, etc. However, in some 1138 cases, such a choice is not made available to the MNNs. 1139 Particularly: 1141 o In the (*,*,n) configuration, the MNNs can influence the path by 1142 source address selection (see Section 4.1.3, Section 4.7). 1144 o In the (n,*,*) configuration, the MNNs can influence the path by 1145 default router selection (see Section 4.1.3). 1147 o In the (1,*,1) configuration, the MNNs cannot influence the path 1148 selection. 1150 A mechanism that allows the MNN to indicate its preference for a 1151 given traffic might be helpful. In addition, there may also be a 1152 need to exchange some information between the MRs and the MNNs. This 1153 problem is general in the sense that any IPv6 nodes may wish to 1154 influence the routing decision done by the upstream routers. Such 1155 mechanism is currently being explored by various WGs, such as the 1156 NSIS and IPFIX WGs. It is also possible that a Shim6 layer in the 1157 MNNs may possess such capability. 1159 It is recommended that vendors or operators to investigate into the 1160 solutions developed by these WGs when providing multihoming 1161 capabilities to mobile networks. 1163 5. Recommendations to the Working Group 1165 Several issues that might impact the deployment of NEMO with 1166 multihoming capabilities were identified in Section 4. These are 1167 shown in the matrix below, for each of the eight multihoming 1168 configurations, together with indications of from which WG(s) a 1169 solution to each issue is most likely to be found. 1171 +=================================================================+ 1172 | # of MRs: | 1 | 1 | 1 | 1 | n | n | n | n | 1173 | # of HAs: | 1 | 1 | n | n | 1 | 1 | n | n | 1174 | # of Prefixes: | 1 | n | 1 | n | 1 | n | 1 | n | 1175 +=================================================================+ 1176 | Fault Tolerance | * | * | * | * | * | * | * | * | 1177 +---------------------------------+---+---+---+---+---+---+---+---+ 1178 | Failure Detection |N/M|N/M|N/M|N/M|N/M|N/M| N | S | 1179 +---------------------------------+---+---+---+---+---+---+---+---+ 1180 | Path Exploration |N/M|N/M|N/M|N/M|N/M|N/M| N | S | 1181 +---------------------------------+---+---+---+---+---+---+---+---+ 1182 | Path Selection | N |S/M| M |S/M| N |S/N| N |S/N| 1183 +---------------------------------+---+---+---+---+---+---+---+---+ 1184 | Re-Homing |N/M| S |N/M| S |N/M| S |N/M| S | 1185 +---------------------------------+---+---+---+---+---+---+---+---+ 1186 | Ingress Filtering | . | . | . | t | . | . | . | N | 1187 +---------------------------------+---+---+---+---+---+---+---+---+ 1188 | HA Synchronization | . | . |N/M|N/M| . | . |N/M|N/M| 1189 +---------------------------------+---+---+---+---+---+---+---+---+ 1190 | MR Synchronization | . | . | . | . | G | G | G | G | 1191 +---------------------------------+---+---+---+---+---+---+---+---+ 1192 | Prefix Delegation | . | . | N | N | N | N | N | N | 1193 +---------------------------------+---+---+---+---+---+---+---+---+ 1194 | Multiple Binding/Registrations | M | M | M | M | M | M | M | M | 1195 +---------------------------------+---+---+---+---+---+---+---+---+ 1196 | Source Address Selection | . | G | . | G | . | G | . | G | 1197 +---------------------------------+---+---+---+---+---+---+---+---+ 1198 | Loop Prevention in Nested NEMO | N | N | N | N | N | N | N | N | 1199 +---------------------------------+---+---+---+---+---+---+---+---+ 1200 | Prefix Ownership | . | . | . | . | N | . | N | . | 1201 +---------------------------------+---+---+---+---+---+---+---+---+ 1202 | Preference Settings | G | G | G | G | G | G | G | G | 1203 +=================================================================+ 1204 N - NEMO Specific M - MIPv6 Specific G - Generic IPv6 1205 S - SHIM6 WG D - DNA WG 1206 . - Not an Issue t - trivial 1207 * - Fault Tolerance is a combination of Failure Detection, Path 1208 Exploration, Path Selection, and Re-Homing 1210 Figure 10: Matrix of NEMO Multihoming Issues 1212 The above matrix serves to identify which issues are NEMO-specific, 1213 and which are not. The readers are reminded that this matrix is a 1214 simplification of Section 4 as subtle details are not represented in 1215 Figure 10. 1217 As can be seen from Figure 10, the following have some concerns which 1218 are specific to NEMO: Failure Detection, Path Exploration, Path 1219 Selection, Re-Homing, Ingress Filtering, HA Synchronization, Prefix 1220 Delegation, Loop Prevention in Nested NEMO, and Prefix Ownership. 1221 Based on the authors' best knowledge of the possible deployments of 1222 NEMO, it is recommended that: 1224 o A solution for Failure Detection, Path Exploration, Path 1225 Selection, and Re-Homing be solicited from other WGs. 1227 Although Path Selection is reflected in Figure 10 as NEMO- 1228 Specific, the technical consideration of the problem is believed 1229 to be quite similar to the selection of multiple paths in mobile 1230 nodes. As such, we would recommend vendors to solicit a solution 1231 for these issues from other WGs in the IETF, for instance the 1232 Monami6 or Shim6 WG. 1234 o Ingress Filtering on the (n,n,n) configuration be solved by the 1235 NEMO WG. 1237 This problem is clearly defined, and can be solved by the WG. 1238 Deployment of the (n,n,n) configuration can be envisioned on 1239 vehicles for mass transportation (such as buses, trains) where 1240 different service providers may install their own mobile routers 1241 on the vehicle/vessel. 1243 It should be noted that the Shim6 WG may be developing a mechanism 1244 for overcoming ingress filtering in a more general sense. We thus 1245 recommend the NEMO WG to concentrate only on the (n,n,n) 1246 configuration should the WG decide to work on this issue. 1248 o A solution for Home Agent Synchronization be looked at in a 1249 mobility specific WG and taking into consideration both mobile 1250 hosts operating Mobile IPv6 and mobile routers operating NEMO 1251 Basic Support. 1253 o A solution for Multiple Bindings/Registrations be presently looked 1254 at by the Monami6 WG. 1256 o Prefix Delegation be reviewed and checked by the NEMO WG. 1258 The proposed solutions [21] and [20] providing prefix delegation 1259 functionality to NEMO Basic Support should be reviewed in order to 1260 make sure concerns as discussed in Section 4.5 are properly 1261 handled. 1263 o Loop Prevention in Nested NEMO be investigated. 1265 Further research is recommended to assess the risk of having a 1266 loop in the nesting of multihomed mobile networks. 1268 o Prefix Ownership should be considered by the vendors and 1269 operators. 1271 The problem of Prefix Ownership only occurs when a mobile network 1272 with multiple MRs and a single MNP can arbitrarily join and split. 1273 Vendors and operators of mobile networks are encouraged to input 1274 their views on the applicability of deploying such kind of mobile 1275 networks. 1277 6. Conclusion 1279 This memo presented an analysis of multihoming in the context of 1280 network mobility under the operation of NEMO Basic Support (RFC 1281 3963). The purpose was to investigate issues related to such a bi- 1282 directional tunneling mechanism where mobile networks are multihomed 1283 and multiple bi-directional tunnels established between home agent 1284 and mobile router pairs. For doing so, mobile networks were 1285 classified into a taxonomy comprising eight possible multihomed 1286 configurations. Issues were explained one by one and then summarized 1287 into a table showing the multihomed configurations where they apply 1288 and suggesting the most relevant IETF working group where they could 1289 be solved. This analysis will be helpful to extend the existing 1290 standards to support multihoming and to implementors of NEMO Basic 1291 Support and multihoming-related mechanisms. 1293 7. IANA Considerations 1295 This is an informational document and as such does not require any 1296 IANA action. 1298 8. Security Considerations 1300 This is an informational document where the multihoming 1301 configurations under the operation of NEMO Basic Support are 1302 analyzed. Security considerations of these multihoming 1303 configurations, should they be different from those that concern NEMO 1304 Basic Support, must be considered by forthcoming solutions. 1306 9. Acknowledgments 1308 The authors would like to thank people who have given valuable 1309 comments on various multihoming issues on the mailing list, and also 1310 those who have suggested directions in the 56th - 61st IETF Meetings. 1311 The initial evaluation of NEMO Basic Support on multihoming 1312 configurations is a contribution from Julien Charbon. 1314 10. References 1316 10.1. Normative References 1318 [1] Ernst, T., "Network Mobility Support Goals and Requirements", 1319 draft-ietf-nemo-requirements-06 (work in progress), 1320 November 2006. 1322 [2] Manner, J. and M. Kojo, "Mobility Related Terminology", 1323 RFC 3753, June 2004. 1325 [3] Ernst, T. and H. Lach, "Network Mobility Support Terminology", 1326 draft-ietf-nemo-terminology-06 (work in progress), 1327 November 2006. 1329 [4] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, 1330 "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, 1331 January 2005. 1333 [5] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in 1334 IPv6", RFC 3775, June 2004. 1336 10.2. Informative References 1338 [6] Ernst, T., Montavont, N., Wakikawa, R., Ng, C., and K. 1339 Kuladinithi, "Motivations and Scenarios for Using Multiple 1340 Interfaces and Global Addresses", 1341 draft-ietf-monami6-multihoming-motivation-scenario-01 (work in 1342 progress), October 2006. 1344 [7] Montavont, N., Wakikawa, R., Ernst, T., Ng, C., and K. 1345 Kuladinithi, "Analysis of Multihoming in Mobile IPv6", 1346 draft-ietf-monami6-mipv6-analysis-00 (work in progress), 1347 February 2006. 1349 [8] Arkko, J. and I. Beijnum, "Failure Detection and Locator Pair 1350 Exploration Protocol for IPv6 Multihoming", 1351 draft-ietf-shim6-failure-detection-07 (work in progress), 1352 December 2006. 1354 [9] Krishnan, S., Montavont, N., Yegin, A., Veerepalli, S., and A. 1355 Yegin, "Link-layer Event Notifications for Detecting Network 1356 Attachments", draft-ietf-dna-link-information-05 (work in 1357 progress), November 2006. 1359 [10] Narayanan, S., "Detecting Network Attachment in IPv6 Networks 1360 (DNAv6)", draft-ietf-dna-protocol-03.txt (work in progress), 1361 October 2006. 1363 [11] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery 1364 for IP Version 6 (IPv6)", RFC 2461, December 1998. 1366 [12] Nordmark, E. and M. Bagnulo, "Level 3 multihoming shim 1367 protocol", draft-ietf-shim6-proto-07 (work in progress), 1368 November 2006. 1370 [13] Ferguson, P. and D. Senie, "Network Ingress Filtering: 1371 Defeating Denial of Service Attacks which employ IP Source 1372 Address Spoofing", BCP 38, RFC 2827, May 2000. 1374 [14] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 1375 Networks", BCP 84, RFC 3704, March 2004. 1377 [15] Huitema, C. and M. Marcelo, "Ingress filtering compatibility 1378 for IPv6 multihomed sites", 1379 draft-huitema-shim6-ingress-filtering-00 (work in progress), 1380 October 2006. 1382 [16] Wakikawa, R., Devarapalli, V., and P. Thubert, "Inter Home 1383 Agents Protocol (HAHA)", draft-wakikawa-mip6-nemo-haha-01 (work 1384 in progress), February 2004. 1386 [17] Koh, B., Ng, C., and J. Hirano, "Dynamic Inter Home Agent 1387 Protocol", draft-koh-mip6-nemo-dhap-00 (work in progress), 1388 July 2004. 1390 [18] Tsukada, M., "Analysis of Multiple Mobile Routers Cooperation", 1391 draft-tsukada-nemo-mr-cooperation-analysis-00 (work in 1392 progress), October 2005. 1394 [19] Miyakawa, S. and R. Droms, "Requirements for IPv6 Prefix 1395 Delegation", RFC 3769, June 2004. 1397 [20] Droms, R. and P. Thubert, "DHCPv6 Prefix Delegation for NEMO", 1398 draft-ietf-nemo-dhcpv6-pd-02 (work in progress), 1399 September 2006. 1401 [21] Thubert, P. and TJ. Kniveton, "Mobile Network Prefix 1402 Delegation", draft-ietf-nemo-prefix-delegation-01 (work in 1403 progress), November 2006. 1405 [22] Wakikawa, R., "Multiple Care-of Addresses Registration", 1406 draft-ietf-monami6-multiplecoa-00 (work in progress), 1407 June 2006. 1409 [23] Draves, R., "Default Address Selection for Internet Protocol 1410 version 6 (IPv6)", RFC 3484, February 2003. 1412 [24] Thubert, P., Bontous, C., and N. Nicolas, "Nested Nemo Tree 1413 Discovery", draft-thubert-tree-discovery-04 (work in progress), 1414 November 2006. 1416 [25] Kumazawa, M., "Token based Duplicate Network Detection for 1417 split mobile network (Token based DND)", 1418 draft-kumazawa-nemo-tbdnd-02 (work in progress), July 2005. 1420 Appendix A. Alternative Classifications Approach 1422 A.1. Ownership-Oriented Approach 1424 An alternative approach to classifying multihomed mobile network is 1425 proposed by Erik Nordmark (Sun Microsystems) by breaking the 1426 classification of multihomed network based on ownership. This is 1427 more of a tree-like top-down classification. Starting from the 1428 control and ownership of the HA(s) and MR(s), there are two different 1429 possibilities: either (i) the HA(s) and MR(s) are controlled by a 1430 single entity, or (ii) the HA(s) and MR(s) are controlled by separate 1431 entities. We called the first possibility the 'ISP Model', and the 1432 second the 'Subscriber/Provider Model'. 1434 A.1.1. ISP Model 1436 The case of the HA(s) and MR(s) are controlled by the same entity can 1437 be best illustrated as an Internet Service Provider (ISP) installing 1438 mobile routers on trains, ships or planes. It is up to the ISP to 1439 deploy a certain configuration of mobile network; all 8 1440 configurations as described in the Configuration-Oriented Approach 1441 are possible. In the remaining portion of this document, when 1442 specifically referring to a mobile network configuration that is 1443 controlled by a single entity, we will add an 'ISP' prefix: for 1444 example: ISP-(1,1,1) or ISP-(1,N,N). 1446 When the HA(s) and MR(s) are controlled by a single entity (such as 1447 an ISP), the ISP can decide whether it wants to assign one or 1448 multiple MNPs to the mobile network just like it can make the same 1449 decision for any other link in its network (wired or otherwise). In 1450 any case, the ISP will make the routing between the mobile networks 1451 and its core routers (such as the HAs) work. This include not 1452 introducing any aggregation between the HAs which will filter out 1453 routing announcements for the MNP(es). 1455 To such ends, the ISP has various means and mechanisms. For one, the 1456 ISP can run its Interior Gateway Protocol (IGP) over bi-directional 1457 tunnels between the MR(s) and HA(s). Alternatively, static routes 1458 may be used with the tunnels. When static routes are used, a 1459 mechanism to test "tunnel liveness" might be necessary to avoid 1460 maintaining stale routes. Such "tunnel liveness" may be tested by 1461 sending heartbeats signals from MR(s) to the HA(s). A possibility is 1462 to simulate heartbeats using Binding Updates messages by controlling 1463 the "Lifetime" field of the Binding Acknowledgment message to force 1464 the MR to send Binding Update messages at regular interval. However, 1465 a more appropriate tool might be the Binding Refresh Request message, 1466 though conformance to the Binding Refresh Request message may be less 1467 strictly enforced in implementations since it serves a somewhat 1468 secondary role when compared to Binding Update messages. 1470 A.1.2. Subscriber/Provider Model 1472 The case of the HA(s) and MR(s) are controlled by the separate 1473 entities can be best illustrated with a subscriber/provider model, 1474 where the MRs belongs to a single subscriber and subscribes to one or 1475 more ISPs for HA services. There is two sub-categories in this case: 1476 when the subscriber subscribes to a single ISP, and when the 1477 subscriber subscribes to multiple ISPs. In the remaining portion of 1478 this document, when specifically referring to a mobile network 1479 configuration that is in the subscriber/provider model where the 1480 subscriber subscribes to only one ISP, we will add an 'S/P' prefix: 1481 for example: S/P-(1,1,1) or S/P-(1,n,n). When specifically referring 1482 to a mobile network configuration that is in the subscriber/provider 1483 model where the subscriber subscribes to multiple ISPs, we will add 1484 an 'S/mP' prefix: for example: S/mP-(1,1,1) or S/mP-(1,n,n). 1486 Not all 8 configurations are likely to be deployed for the S/P and 1487 S/mP models. For instance, it is unlikely to foresee a S/mP-(*,1,1) 1488 mobile network where there is only a single HA. For the S/P model, 1489 the following configurations are likely to be deployed: 1491 o S/P-(1,1,1): Single Provider, Single MR, Single HA, Single MNP 1493 o S/P-(1,1,n): Single Provider, Single MR, Single HA, Multiple MNPs 1495 o S/P-(1,n,1): Single Provider, Single MR, Multiple HAs, Single MNP 1497 o S/P-(1,n,n): Single Provider, Single MR, Multiple HAs, Multiple 1498 MNPs 1500 o S/P-(n,n,1): Single Provider, Multiple MRs, Single HA, Single MNP 1502 o S/P-(n,1,n): Single Provider, Multiple MRs, Single HA, Multiple 1503 MNPs 1505 o S/P-(n,n,1): Single Provider, Multiple MRs, Multiple HAs, Single 1506 MNP 1508 o S/P-(n,n,n): Single Provider, Multiple MRs, Multiple HAs, Multiple 1509 MNPs 1511 For the S/mP model, the following configurations are likely to be 1512 deployed: 1514 o S/mP-(1,n,1): Multiple Providers, Single MR, Multiple HAs, Single 1515 MNP 1517 o S/mP-(1,n,n): Multiple Providers, Single MR, Multiple HAs, 1518 Multiple MNPs 1520 o S/mP-(n,n,n): Multiple Providers, Multiple MRs, Multiple HAs, 1521 Multiple MNPs 1523 When the HA(s) and MR(s) are controlled by different entities, it is 1524 more likely the scenario where the MR is controlled by one entity 1525 (i.e. the subscriber), and the MR is establishing multiple bi- 1526 directional tunnels to one or more HA(s) provided by one or more 1527 ISP(s). In such case, it is unlikely for the ISP to run IGP over the 1528 bi-directional tunnel, since ISP would most certainly wish to retain 1529 full control of its routing domain. 1531 A.2. Problem-Oriented Approach 1533 A third approach is proposed by Pascal Thubert (Cisco System). This 1534 focused on the problems of multihomed mobile networks rather than the 1535 configuration or ownership. With this approach, there is a set of 4 1536 categories based on two orthogonal parameters: the number of HAs, and 1537 the number of MNPs advertised. Since the two parameters are 1538 orthogonal, the categories are not mutually exclusive. The four 1539 categories are: 1541 o Tarzan: Single HA for Different CoAs of Same MNP 1543 This is the case where one MR registers different Care-of 1544 Addresses to the same HA for the same subnet prefix. This is 1545 equivalent to the case of y=1, i.e. the (1,1,*) mobile network. 1547 o JetSet: Multiple HAs for Different CoAs of Same MNP 1549 This is the case where the MR registers different Care-of 1550 Addresses to different HAs for the same subnet prefix. This is 1551 equivalent to the case of y=n, i.e. the (1,n,*) mobile network. 1553 o Shinkansen: Single MNP Advertised by MR(s) 1555 This is the case where one MNP is announced by different MRs. 1556 This is equivalent to the case of x=n and z=1, i.e. the (n,*,1) 1557 mobile network. 1559 o DoubleBed: Multiple MNPs Advertised by MR(s) 1561 This is the case where more than one MNPs are announced by the 1562 different MRs. This is equivalent to the case of x=n and z=n, 1563 i.e. the (n,*,n) mobile network. 1565 Appendix B. Nested Tunneling for Fault Tolerance 1567 In order to utilize the additional robustness provided by 1568 multihoming, MRs that employ bi-directional tunneling with their HAs 1569 should dynamically change their tunnel exit points depending on the 1570 link status. For instance, if a MR detects that one of its egress 1571 interface is down, it should detect if any other alternate route to 1572 the global Internet exists. This alternate route may be provided by 1573 any other MRs connected to one of its ingress interfaces that has an 1574 independent route to the global Internet, or by another active egress 1575 interface the MR itself possess. If such an alternate route exists, 1576 the MR should re-establish the bi-directional tunnel using this 1577 alternate route. 1579 In the remaining part of this Appendix, we will attempt to 1580 investigate methods of performing such re-establishment of bi- 1581 directional tunnels. This method of tunnel re-establishment is 1582 particularly useful for the (*,n,n) NEMO configuration. The method 1583 described is by no means complete and merely serves as a suggestion 1584 on how to approach the problem. It is also not the objective to 1585 specify a new protocol specifically tailored to provide this form of 1586 re- establishments. Instead, we will limit ourselves to currently 1587 available mechanisms specified in Mobile IPv6 [5] and Neighbor 1588 Discovery in IPv6 [11]. 1590 B.1. Detecting Presence of Alternate Routes 1592 To actively utilize the robustness provided by multihoming, a MR must 1593 first be capable of detecting alternate routes. This can be manually 1594 configured into the MR by the administrators if the configuration of 1595 the mobile network is relatively static. It is however highly 1596 desirable for MRs to be able to discover alternate routes 1597 automatically for greater flexibility. 1599 The case where a MR possesses multiple egress interface (bound to the 1600 same HA or otherwise) should be trivial, since the MR should be able 1601 to "realize" it has multiple routes to the global Internet. 1603 In the case where multiple MRs are on the mobile network, each MR has 1604 to detect the presence of other MR. A MR can do so by listening for 1605 Router Advertisement message on its *ingress* interfaces. When a MR 1606 receives a Router Advertisement message with a non-zero Router 1607 Lifetime field from one of its ingress interfaces, it knows that 1608 another MR which can provide an alternate route to the global 1609 Internet is present in the mobile network. 1611 B.2. Re-Establishment of Bi-Directional Tunnels 1613 When a MR detects that the link by which its current bi-directional 1614 tunnel with its HA is using is down, it needs to re-establish the bi- 1615 directional tunnel using an alternate route detected. We consider 1616 two separate cases here: firstly, the alternate route is provided by 1617 another egress interface that belongs to the MR; secondly, the 1618 alternate route is provided by another MR connected to the mobile 1619 network. We refer to the former case as an alternate route provided 1620 by an alternate egress interface, and the latter case as an alternate 1621 route provided by an alternate MR. 1623 B.2.1. Using Alternate Egress Interface 1625 When an egress interface of a MR loses the connection to the global 1626 Internet, the MR can make use of its alternate egress interface 1627 should it possess multiple egress interfaces. The most direct way to 1628 do so is for the MR to send a binding update to the HA of the failed 1629 interface using the CoA assigned to the alternate interface in order 1630 to re-establish the bi-directional tunneling using the CoA on the 1631 alternate egress interface. After a successful binding update, the 1632 MR encapsulates outgoing packets through the bi-directional tunnel 1633 using the alternate egress interface. 1635 The idea is to use the global address (most likely a CoA) assigned to 1636 an alternate egress interface as the new (back-up) CoA of the MR to 1637 re-establish the bi-directional tunneling with its HA. 1639 B.2.2. Using Alternate Mobile Router 1641 When the MR loses a connection to the global Internet, the MR can 1642 utilize a route provided by an alternate MR (if one exists) to re- 1643 establish the bi-directional tunnel with its HA. First, the MR has 1644 to obtain a CoA from the alternate MR (i.e. attaches itself to the 1645 alternate MR). Next, it sends binding update to its HA using the CoA 1646 obtained from the alternate MR. From then on, the MR can 1647 encapsulates outgoing packets through the bi-directional tunnel using 1648 via the alternate MR. 1650 The idea is to obtain a CoA from the alternate MR and use this as the 1651 new (back-up) CoA of the MR to re-establish the bi-directional 1652 tunneling with its HA. 1654 Note that every packet sent between MNNs and their correspondent 1655 nodes will experience two levels of encapsulation. First level of 1656 tunneling occurs between a MR which the MNN uses as its default 1657 router and the MR's HA. The second level of tunneling occurs between 1658 the alternate MR and its HA. 1660 B.3. To Avoid Tunneling Loop 1662 The method of re-establishing the bi-directional tunnel as described 1663 in Appendix B.2 may lead to infinite loops of tunneling. This 1664 happens when two MRs on a mobile network lose connection to the 1665 global Internet at the same time and each MR tries to re-establish 1666 bi-directional tunnel using the other MR. We refer to this 1667 phenomenon as tunneling loop. 1669 One approach to avoid tunneling loop is for a MR that has lost 1670 connection to the global Internet to insert an option into the Router 1671 Advertisement message it broadcasts periodically. This option serves 1672 to notify other MRs on the link that the sender no longer provides 1673 global connection. Note that setting a zero Router Lifetime field 1674 will not work well since it will cause MNNs that are attached to the 1675 MR to stop using the MR as their default router too (in which case, 1676 things are back to square one). 1678 B.4. Points of Considerations 1680 This method of using tunnel re-establishments is by no means a 1681 complete solution. There are still points to consider to develop it 1682 into a fully functional solution. For instance, in Appendix B.1, it 1683 was suggested that MR detects the presence of other MRs using Router 1684 Advertisements. However, Router Advertisements are link scoped, so 1685 when there is more than one link, some information may be lost. For 1686 instance, suppose a case where there is three MRs and three different 1687 prefixes and each MR is in a different link with regular routers in 1688 between. Suppose now that only a single MR is working, how do the 1689 other MRs identify which prefix they have to use to configure the new 1690 CoA? In this case, there are three prefixes being announced and a MR 1691 whose link has failed, knows that his prefix is not to be used, but 1692 it has not enough information to decide which one of the other two 1693 prefixes to use to configure the new CoA. In such cases, a mechanism 1694 is needed to allow a MR to withdraw its own prefix when it discovers 1695 that its link is no longer working. 1697 Appendix C. Change Log 1699 o Changes from draft-ietf-nemo-multihoming-issues-06 to -07: 1701 * Removed in 2.1 the bullet "Multiple global prefixes are 1702 available on the home link, and thus the MR has more than one 1703 path to reach the home agent." 1705 * In all 2.x sub-sections in the sentence similar to "A bi- 1706 directional tunnel would then be established between each HoA- 1707 CoA pair", replaced the part "HoA-CoA" pair with "{HA address, 1708 CoA} pair." 1710 * Removed in 2.3 ", possibly one HA per HoA, or one HA per egress 1711 interface." and in 2.4 ", possibly one per Home Address (or one 1712 HA per egress interface)," 1714 * In 2.4 and 2.6 and 2.8, replaced "Regarding MNNs, they are 1715 generally multihomed since they would configure a global 1716 address from each MNP available on the link they are attached 1717 to." with the better text in 2.2, i.e. "Regarding MNNs, they 1718 are multihomed because several MNPs are available on the link 1719 they are attached to. The MNNs would then configure a global 1720 address with each MNP available on the link." 1722 * In 4.1.1 and 4.1.2 3rd bullet, rephrased the complex sentence 1723 "The (n,n,n) case is hybrid, since for those cases when[4.1.1]/ 1724 that[4.1.2] selecting a different prefix result in a change of 1725 path, the Shim6 protocols (such as [9]) may be useful." into 1726 "The (n,n,n) case is hybrid, since selecting a different prefix 1727 results in a change of path. For this case the Shim6 protocols 1728 (such as those discussed in [8]) may be useful." 1730 * Probably due to a typo in the table in section 5 line "Path 1731 Selection", changed "N |S/N| N |S/N| N |S/N| N |S/N|" to "M 1732 |S/M| M |S/M| N |S/N| N |S/N|" 1734 * Removed references to draft-yegin-dna-l2-hints-01 and 1735 draft-manyfolks-l2-mobilereq-02. Should now be covered in 1736 draft-ietf-dna-link-information-05.txt. 1738 * Both draft-droms-nemo-dhcpv6-pd-02 and 1739 draft-ietf-nemo-dhcpv6-pd-00 were cited. Removed the former. 1741 * Replaced references to draft-ietf-dna-hosts-02 and 1742 draft-ietf-dna-routers-01 with draft-ietf-dna-protocol-03.txt 1743 where everything was merged. 1745 * Replaced draft-ietf-shim6-reach-detect-01 with 1746 draft-ietf-shim6-failure-detection 1748 * Replaced draft-ietf-shim6-functional-dec with 1749 draft-ietf-shim6-proto 1751 * Rephrased paragraph about "Prefix Delegation" in section 5. 1753 * Rephrased the conclusion. 1755 * Replaced "visited link" with "foreign link" and "border 1756 gateway" with "border router" in several places. 1758 * Reordered author list. 1760 * And, minor editorial corrections and reference update. 1762 o Changes from draft-ietf-nemo-multihoming-issues-05 to -06: 1764 * Minor editorial corrections and reference update 1766 o Changes from draft-ietf-nemo-multihoming-issues-04 to -05: 1768 * Addressed Issue #23: modified text in Sect 4.2: "Ingress 1769 Filtering" 1771 * Re-phrase statements in Sect 4 and 5 where we "... recommend 1772 issue XXX to be worked on by Monami6/Shim6/IPv6/DNA WG" to 1773 instead suggest that solution to the issue be solicited 1774 elsewhere within the IETF. 1776 o Changes from draft-ietf-nemo-multihoming-issues-03 to -04: 1778 * Updated Section 3: "Deployment Scenarios and Prerequisites" 1780 * Modifications to Section 4: 1782 + Removed "Media Detection" and moved the relevant concerns to 1783 "Path Exploration" 1785 + Added new "Preference Settings" issue 1787 + Various text clean-ups in most of the sub-sections 1789 * Modifications to Section 5: 1791 + Changed Section 5: "Matrix" to "Recommendations to the 1792 Working Group" 1794 + Identifies which are the issues that are important, and made 1795 recommendations as to how to resolve these multihoming 1796 issues 1798 * Addressed Issue #12: Added Appendix B.4: "Points of 1799 Considerations" to document the concerns raised for this tunnel 1800 re-establishment mechanism. 1802 o Changes from draft-ietf-nemo-multihoming-issues-02 to -03: 1804 * Enlisted Marcelo Bagnulo as co-author 1806 * Restructuring of Section 4: 1808 + Re-named 'Path Survival' to 'Fault Tolerance' 1810 + Moved 'Path Failure Detection' and 'Path Selection' as sub- 1811 issues of 'Fault Tolerance' 1813 + Added 'Path Exploration' and 'Re-homing' as sub-issues of 1814 'Fault Tolerance' 1816 + Removed 'Impact on Routing Infrastructure' 1818 * Breaking references into Normative and Informative 1820 o Changes from draft-ietf-nemo-multihoming-issues-01 to -02: 1822 * Added recommendations/suggestion of which WG each issue should 1823 be addressed as pointed out in 61st IETF. 1825 * Minor updates on references. 1827 o Changes from draft-ietf-nemo-multihoming-issues-00 to -01: 1829 * Replaced NEMO-Prefix with MNP as decided by the WG at 60th IETF 1831 * Addressed Issue #1 in Section 1: Added a note to remind readers 1832 that IPv6 is implicitly assumed 1834 * Addressed Issue #3 in Sect 2.3: Removed text on assumption 1836 * Addressed Issue #6 in Sect 3.1 "Deployment Scenarios": Added 1837 benefits 1839 * Addressed Issue #7 in Sect 3.2 "Prerequisites": Modified text 1840 * Addressed Issue #9 in Sect 4.3 "Ingress Filtering": Modified 1841 text 1843 * Addressed Issue #10 in Sect 4.4: Added paragraph on other 1844 failure modes 1846 * Addressed Issue #10: New Sect 4.5 on media detection 1848 * Addressed Issue #11 in Section 4.11: modified text 1850 o Changes from draft-ng-multihoming-issues-03 to 1851 draft-ietf-nemo-multihoming-issues-00: 1853 * Expanded Section 4: "Problem Statement" 1855 * Merged "Evaluation" Section into Section 4: "Problem Statement" 1857 * Cleaned up description in Section 2: "Classification", and 1858 clearly indicate in each classification, what are the 1859 multihomed entities 1861 * Re-organized Section 2: "Deployment Scenarios and 1862 Prerequisites", and created the "Prerequisites" sub-section. 1864 o Changes from draft-ng-multihoming-issues-02 to 1865 draft-ng-multihoming-issues-03: 1867 * Merged with draft-eun-nemo-multihoming-problem-statement (see 1868 Section 4: "Problem Statement") 1870 * Included conclusions from 1871 draft-charbon-nemo-multihoming-evaluation-00 1873 * Re-organized some part of "Benefits/Issues of Multihoming in 1874 NEMO" to Section 4: "Problem Statement" 1876 * Removed lots of text to be in sync with [6]. 1878 * Title changed from "Multihoming Issues in NEMO Basic Support" 1879 to "Analysis of Multihoming in NEMO" 1881 * Changed (w,x,y) to (x,y,z) in taxonomy. 1883 * Moved alternative approaches of classification to Appendix 1885 * Creation of this Change-Log itself ;-) 1887 Authors' Addresses 1889 Chan-Wah Ng 1890 Panasonic Singapore Laboratories Pte Ltd 1891 Blk 1022 Tai Seng Ave #06-3530 1892 Tai Seng Industrial Estate 1893 Singapore 534415 1894 SG 1896 Phone: +65 65505420 1897 Email: chanwah.ng@sg.panasonic.com 1899 Thierry Ernst 1900 INRIA 1901 INRIA Rocquencourt 1902 Domaine de Voluceau B.P. 105 1903 Le Chesnay, 78153 1904 France 1906 Phone: +33-1-39-63-59-30 1907 Fax: +33-1-39-63-54-91 1908 Email: thierry.ernst@inria.fr 1909 URI: http://www.nautilus6.org/~thierry 1911 Eun Kyoung Paik 1912 KT 1913 Portable Internet Team, Convergence Lab., KT 1914 17 Woomyeon-dong, Seocho-gu 1915 Seoul 137-792 1916 Korea 1918 Phone: +82-2-526-5233 1919 Fax: +82-2-526-5200 1920 Email: euna@kt.co.kr 1921 URI: http://mmlab.snu.ac.kr/~eun/ 1923 Marcelo Bagnulo 1924 Universidad Carlos III de Madrid 1925 Av. Universidad, 30 1926 Leganes, Madrid 28911 1927 Spain 1929 Phone: +34 91624 8837 1930 Email: marcelo@it.uc3m.es 1932 Full Copyright Statement 1934 Copyright (C) The IETF Trust (2007). 1936 This document is subject to the rights, licenses and restrictions 1937 contained in BCP 78, and except as set forth therein, the authors 1938 retain all their rights. 1940 This document and the information contained herein are provided on an 1941 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1942 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1943 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1944 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1945 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1946 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1948 Intellectual Property 1950 The IETF takes no position regarding the validity or scope of any 1951 Intellectual Property Rights or other rights that might be claimed to 1952 pertain to the implementation or use of the technology described in 1953 this document or the extent to which any license under such rights 1954 might or might not be available; nor does it represent that it has 1955 made any independent effort to identify any such rights. Information 1956 on the procedures with respect to rights in RFC documents can be 1957 found in BCP 78 and BCP 79. 1959 Copies of IPR disclosures made to the IETF Secretariat and any 1960 assurances of licenses to be made available, or the result of an 1961 attempt made to obtain a general license or permission for the use of 1962 such proprietary rights by implementers or users of this 1963 specification can be obtained from the IETF on-line IPR repository at 1964 http://www.ietf.org/ipr. 1966 The IETF invites any interested party to bring to its attention any 1967 copyrights, patents or patent applications, or other proprietary 1968 rights that may cover technology that may be required to implement 1969 this standard. Please address the information to the IETF at 1970 ietf-ipr@ietf.org. 1972 Acknowledgment 1974 Funding for the RFC Editor function is provided by the IETF 1975 Administrative Support Activity (IASA).