idnits 2.17.1 draft-ietf-nemo-multihoming-issues-04.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 1865. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1842. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1849. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1855. ** 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 1384 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 (October 24, 2005) is 6756 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-06) exists of draft-ietf-nemo-requirements-05 ** Downref: Normative reference to an Informational draft: draft-ietf-nemo-requirements (ref. '1') ** Downref: Normative reference to an Informational RFC: RFC 3753 (ref. '2') == Outdated reference: A later version (-06) exists of draft-ietf-nemo-terminology-04 ** Downref: Normative reference to an Informational draft: draft-ietf-nemo-terminology (ref. '3') ** Obsolete normative reference: RFC 3775 (ref. '5') (Obsoleted by RFC 6275) -- Unexpected draft version: The latest known version of draft-multihoming-generic-goals-and-benefits is -00, but you're referring to -02. == Outdated reference: A later version (-13) exists of draft-ietf-shim6-failure-detection-01 == Outdated reference: A later version (-01) exists of draft-ietf-shim6-reach-detect-00 == Outdated reference: A later version (-06) exists of draft-ietf-dna-link-information-02 == Outdated reference: A later version (-03) exists of draft-ietf-dna-hosts-01 == Outdated reference: A later version (-02) exists of draft-ietf-dna-routers-00 -- 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: A later version (-05) exists of draft-wakikawa-mobileip-multiplecoa-04 -- Obsolete informational reference (is this intentional?): RFC 3484 (ref. '26') (Obsoleted by RFC 6724) == Outdated reference: A later version (-08) exists of draft-thubert-tree-discovery-02 Summary: 7 errors (**), 0 flaws (~~), 13 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NEMO Working Group C. Ng 3 Internet-Draft Panasonic Singapore Labs 4 Expires: April 27, 2006 E. Paik 5 KT 6 T. Ernst 7 Keio University / WIDE 8 M. Bagnulo 9 UC3M 10 October 24, 2005 12 Analysis of Multihoming in Network Mobility Support 13 draft-ietf-nemo-multihoming-issues-04 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 April 27, 2006. 40 Copyright Notice 42 Copyright (C) The Internet Society (2005). 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). Issues are classified according to the Working Group which 53 is the best chartered to solve them. 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 . . . . . . . 7 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 . . . . . 8 64 2.5. (n,1,1): Multiple MRs, Single HA, Single MNP . . . . . . . 9 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 . . . . . 10 67 2.8. (n,n,n): Multiple MRs, Multiple HAs, Multiple MNPs . . . . 11 69 3. Deployment Scenarios and Prerequisites . . . . . . . . . . . . 12 70 3.1. Deployment Scenarios . . . . . . . . . . . . . . . . . . . 12 71 3.2. Prerequisites . . . . . . . . . . . . . . . . . . . . . . 13 73 4. Multihoming Issues . . . . . . . . . . . . . . . . . . . . . . 15 74 4.1. Fault Tolerance . . . . . . . . . . . . . . . . . . . . . 15 75 4.1.1. Failure Detection . . . . . . . . . . . . . . . . . . 15 76 4.1.2. Path Exploration . . . . . . . . . . . . . . . . . . . 17 77 4.1.3. Path Selection . . . . . . . . . . . . . . . . . . . . 18 78 4.1.4. Re-Homing . . . . . . . . . . . . . . . . . . . . . . 20 79 4.2. Ingress Filtering . . . . . . . . . . . . . . . . . . . . 20 80 4.3. HA Synchronization . . . . . . . . . . . . . . . . . . . . 22 81 4.4. MR Synchronization . . . . . . . . . . . . . . . . . . . . 22 82 4.5. Prefix Delegation . . . . . . . . . . . . . . . . . . . . 23 83 4.6. Multiple Bindings/Registrations . . . . . . . . . . . . . 23 84 4.7. Source Address Selection . . . . . . . . . . . . . . . . . 24 85 4.8. Loop Prevention in Nested Mobile Networks . . . . . . . . 24 86 4.9. Prefix Ownership . . . . . . . . . . . . . . . . . . . . . 24 87 4.10. Preference Settings . . . . . . . . . . . . . . . . . . . 25 89 5. Recommendations to the Working Group . . . . . . . . . . . . . 26 91 6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 29 93 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 95 8. Security Considerations . . . . . . . . . . . . . . . . . . . 29 96 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 29 98 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30 99 10.1. Normative References . . . . . . . . . . . . . . . . . . . 30 100 10.2. Informative References . . . . . . . . . . . . . . . . . . 30 102 Appendix A. Alternative Classifications Approach . . . . . . . . 33 103 A.1. Ownership-Oriented Approach . . . . . . . . . . . . . . . 33 104 A.1.1. ISP Model . . . . . . . . . . . . . . . . . . . . . . 33 105 A.1.2. Subscriber/Provider Model . . . . . . . . . . . . . . 34 106 A.2. Problem-Oriented Approach . . . . . . . . . . . . . . . . 36 108 Appendix B. Nested Tunneling for Fault Tolerance . . . . . . . . 37 109 B.1. Detecting Presence of Alternate Routes . . . . . . . . . . 37 110 B.2. Re-Establishment of Bi-Directional Tunnels . . . . . . . . 38 111 B.2.1. Using Alternate Egress Interface . . . . . . . . . . . 38 112 B.2.2. Using Alternate Mobile Router . . . . . . . . . . . . 38 113 B.3. To Avoid Tunneling Loop . . . . . . . . . . . . . . . . . 39 114 B.4. Points of Considerations . . . . . . . . . . . . . . . . . 39 116 Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 40 118 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 43 119 Intellectual Property and Copyright Statements . . . . . . . . . . 44 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. 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], Goals and Benefits of Multihoming [6], Goals 202 and Requirements of Network Mobility Support [1], and the NEMO Basic 203 Support specification [4]. Goals and benefits of multihoming as 204 discussed in [6] are applicable to fixed nodes, mobile nodes, fixed 205 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 Home 255 Address / Care-of Address pairs. Issues pertaining to a multihomed 256 MR are also addressed in [7]. In addition, the readers should also 257 keep in mind that when "MNP(s) is/are available in the NEMO", the 258 MNP(s) may either be explicitly announced by the MR via router 259 advertisement, or made available through Dynamic Host Configuration 260 Protocol (DHCP). 262 2.1. (1,1,1): Single MR, Single HA, Single MNP 264 The (1,1,1) mobile network has only one MR, it is associated with a 265 single HA, and a single MNP is available in the NEMO. To fall into a 266 multihomed configuration, at least one of the following conditions 267 must hold: 269 o The MR has multiple interfaces, or 271 o Multiple global prefixes are available on the visited link, or 273 o Multiple global prefixes are available on the home link (Note that 274 in this case, those prefixes are not all available in the NEMO, 275 since there is only a single MNP in the NEMO) 277 A bi-directional tunnel would then be established between each pair 278 of Home Address / Care-of Address. 280 Regarding MNNs, they are (usually) not multihomed since they would 281 configure a single global address from the single MNP available on 282 the link they are attached to. 284 _____ 285 _ p _ | | 286 |_|-|<-_ |-|_|-| |-| _ 287 _ |-|_|=| |_____| | _ |-|_| 288 |_|-| | |-|_|-| 289 | 290 MNNs MR AR Internet AR HA 292 Figure 1: (1,1,1): 1 MR, 1 HA, 1 MNP 294 2.2. (1,1,n): Single MR, Single HA, Multiple MNPs 296 The (1,1,n) mobile network has only one MR, it is associated with a 297 single HA and two or more MNPs are available in the NEMO. 299 The MR may be itself multihomed, as detailed in Section 2.1. In such 300 a case, a bi-directional tunnel would be established between each 301 pair of Home Address / Care-of Address. 303 Regarding MNNs, they are multihomed because several MNPs are 304 available on the link they are attached to. The MNNs would then 305 configure a global address with each MNP available on the link. 307 _____ 308 _ p1,p2 _ | | 309 |_|-|<-_ |-|_|-| |-| _ 310 _ |-|_|=| |_____| | _ |-|_| 311 |_|-| | |-|_|-| 312 | 313 MNNs MR AR Internet AR HA 315 Figure 2: (1,1,n): 1 MR, 1 HA, multiple MNPs 317 2.3. (1,n,1): Single MR, Multiple HAs, Single MNP 319 The (1,n,1) mobile network has only one MR and a single MNP is 320 available in the NEMO. The MR, however, is associated with multiple 321 HAs, possibly one HA per Home Address, or one HA per egress 322 interface. 324 The NEMO is multihomed since it has multiple HAs, but in addition the 325 conditions detailed in Section 2.1 may also hold for the MR. A bi- 326 directional tunnel would then be established between each pair of 327 Home Address / Care-of Address. 329 Regarding MNNs, they are (usually) not multihomed since they would 330 configure a single global address from the single MNP available on 331 the link they are attached to. 333 AR HA2 334 _ | 335 |-|_|-| _ 336 _____ | |-|_| 337 _ p _ | |-| 338 |_|-|<-_ |-|_|-| | 339 _ |-|_|=| |_____|-| _ 340 |_|-| | | _ |-|_| 341 |-|_|-| 342 | 343 MNNs MR AR Internet AR HA1 345 Figure 3: (1,n,1): 1 MR, multiple HAs, 1 MNP 347 2.4. (1,n,n): Single MR, Multiple HAs, Multiple MNPs 349 The (1,n,n) mobile network has only one MR. However, the MR is 350 associated with multiple HAs, possibly one per Home Address (or one 351 HA per egress interface), and more than one MNP is available in the 352 NEMO. 354 The MR is multihomed since it has multiple HAs, but in addition the 355 conditions detailed in Section 2.1 may also hold. A bi-directional 356 tunnel would then be established between each pair of Home Address / 357 Care-of Address. 359 Regarding MNNs, they are generally multihomed since they would 360 configure a global address from each MNP available on the link they 361 are attached to. 363 AR HA2 364 _ | _ 365 _____ |-|_|-|-|_| 366 _ p1,p2 _ | |-| | 367 |_|-|<-_ |-|_|-| | _ 368 _ |-|_|=| |_____|-| _ |-|_| 369 |_|-| | |-|_|-| 370 | | 371 MNNs MR AR Internet AR HA1 373 Figure 4: (1,n,n): 1 MR, multiple HAs, multiple MNPs 375 2.5. (n,1,1): Multiple MRs, Single HA, Single MNP 377 The (n,1,1) mobile network has more than one MR advertising global 378 routes. However, the MR(s) are associated with as single HA, and 379 there in a single MNP available in the NEMO. 381 The NEMO is multihomed since it has multiple MRs, but in addition the 382 conditions detailed in Section 2.1 may also hold for each MR. A bi- 383 directional tunnel would then be established between each pair of 384 Home Address / Care-of Address. 386 Regarding MNNs, they are (usually) not multihomed since they would 387 configure a single global address from the single MNP available on 388 the link they are attached to. 390 MR2 391 p<-_ | 392 _ |-|_|-| _____ 393 |_|-| |-| | 394 _ | | |-| _ 395 |_|-| _ |-|_____| | _ |-|_| 396 |-|_|-| |-|_|-| 397 p<- | | 398 MNNs MR1 Internet AR HA 400 Figure 5: (n,1,1): Multiple MRs, 1 HA, 1 MNP 402 2.6. (n,1,n): Multiple MRs, Single HA, Multiple MNPs 404 The (n,1,n) mobile network has more than one MR; multiple global 405 routes are advertised by the MRs and multiple MNPs are available 406 within the NEMO. 408 The NEMO is multihomed since it has multiple MRs, but in addition the 409 conditions detailed in Section 2.1 may also hold for each MR. A bi- 410 directional tunnel would then be established between each pair of 411 Home Address / Care-of Address. 413 Regarding MNNs, they are generally multihomed since they would 414 configure a global address from each MNP available on the link they 415 are attached to. 417 MR2 418 p2<-_ | 419 _ |-|_|-| _____ 420 |_|-| |-| | 421 _ | | |-| _ 422 |_|-| _ |-|_____| | _ |-|_| 423 |-|_|-| |-|_|-| 424 p1<- | | 425 MNNs MR1 Internet AR HA 427 Figure 6: (n,1,n): Multiple MRs, 1 HA, multiple MNPs 429 2.7. (n,n,1): Multiple MRs, Multiple HAs, Single MNP 431 The (n,n,1) mobile network has more than one MR advertising multiple 432 global routes. The mobile network is simultaneously associated with 433 multiple HAs and a single MNP is available in the NEMO. 435 The NEMO is multihomed since it has multiple MRs and HAs, but in 436 addition the conditions detailed in Section 2.1 may also hold for 437 each MR. A bi-directional tunnel would then be established between 438 each pair of Home Address / Care-of Address. 440 Regarding MNNs, they are (usually) not multihomed since they would 441 configure a single global address from the single MNP available on 442 the link they are attached to. 444 MR2 AR HA2 445 p _ | 446 <-_ | |-|_|-| _ 447 _ |-|_|-| _____ | |-|_| 448 |_|-| |-| |-| 449 _ | | | 450 |_|-| _ |-|_____|-| _ 451 |-|_|-| | _ |-|_| 452 <- | |-|_|-| 453 p | 454 MNNs MR1 Internet AR HA1 456 Figure 7: (n,n,1): Multiple MRs, Multiple HAs, 1 MNP 458 2.8. (n,n,n): Multiple MRs, Multiple HAs, Multiple MNPs 460 The (n,n,n) mobile network has multiple MRs advertising different 461 global routes. The mobile network is simultaneously associated with 462 more than one HA and multiple MNPs are available in the NEMO. 464 The NEMO is multihomed since it has multiple MRs and HAs, but in 465 addition the conditions detailed in Section 2.1 may also hold for 466 each MR. A bi-directional tunnel would then be established between 467 each pair of Home Address / Care-of Address. 469 Regarding MNNs, they are generally multihomed since they would 470 configure a global address from each MNP available on the link they 471 are attached to. 473 MR2 AR HA2 474 p2 _ | 475 <-_ | |-|_|-| _ 476 _ |-|_|-| _____ | |-|_| 477 |_|-| |-| |-| 478 _ | | | 479 |_|-| _ |-|_____|-| _ 480 |-|_|-| | _ |-|_| 481 <- | |-|_|-| 482 p1 | 483 MNNs MR1 Internet AR HA1 485 Figure 8: (n,n,n): Multiple MRs, HAs, and MNPs 487 3. Deployment Scenarios and Prerequisites 489 The following generic goals and benefits of multihoming are discussed 490 in [6]: 492 1. Permanent and Ubiquitous Access 494 2. Reliability 496 3. Load Sharing 498 4. Load Balancing/Flow Distribution 500 5. Preference Settings 502 6. Aggregate Bandwidth 504 These benefits are now illustrated from a NEMO perspective with a 505 typical instance scenario for each case in the taxonomy. We then 506 discuss the prerequisites to fulfill these. 508 3.1. Deployment Scenarios 510 x=1: Multihomed mobile networks with a single MR 512 o Example: an MR with dual/multiple access interfaces (e.g. 513 802.11 and GPRS capabilities). This is a (1,1,*) if both 514 accesses are subscribed to the same ISP. If the two accesses 515 are offered by independent ISPs, this is a (1,n,n) 517 Benefits: Ubiquitous Access, Reliability, Load Sharing, 518 Preference Settings, Aggregate Bandwidth 520 x=N: Multihomed mobile networks with multiple MRs 522 o Example 1: a train with one MR in each car, all served by the 523 same HA, thus a (n,1,*). Alternatively, the train company 524 might be forced to use different ISPs when the train go to 525 different locations, thus it is a (n,n,n). 527 Benefits: Load Sharing, Reliability, Ubiquitous Access, 528 Aggregate Bandwidth 530 o Example 2: W-PAN with a GPRS-enabled phone and a WiFi-enabled 531 PDA. This is a (n,n,n) if the two access technologies are 532 subscribed separately. 534 Benefits: Ubiquitous Access, Reliability, Preference Settings, 535 Aggregate Bandwidth 537 y=1: Multihomed mobile networks with a single HA 539 o Most single ISP cases in above examples. 541 y=N: Multihomed mobile networks with multiple HAs 543 o Most multiple ISP cases in above examples. 545 o Example: a transatlantic flight with a HA in each continent. 546 This is a (1,n,1) network if there is only one MR. 548 Benefits: Ubiquity, Preferences (reduced delay, shortest path), 549 Reliability 551 z=1: Multihomed mobile networks with a single MNP 553 o Most single ISP cases in above examples. 555 z=N: Multihomed mobile networks with multiple MNPs 557 o Most multiple ISP cases in above examples. 559 o Example: a car with a prefix taken from home (personal traffic 560 transit on this prefix and is paid by the owner) and one that 561 belongs to the car manufacturer (maintenance traffic is paid by 562 the car-manufacturer). This will typically be a (1,1,n) or a 563 (1,n,n,). 565 Benefits: Preference Settings 567 3.2. Prerequisites 569 In this section, requirements are started in order to comply with the 570 expected benefits of multihoming as detailed in [6]. 572 At least one bi-directional tunnel must be available at any point in 573 time between the mobile network and the fixed network to meet all 574 expectations. But for most goals to be effective, multiple tunnels 575 must be maintained simultaneously: 577 o Permanent and Ubiquitous Access: 579 At least one bi-directional tunnel must be available at any point 580 in time. 582 o Reliability: 584 Both the inbound and outbound traffic must be transmitted or 585 diverted over another bi-directional tunnel once a bi-directional 586 tunnel is broken or disrupted. It should be noted that the 587 provision of fault tolerance capabilities does not necessarily 588 require the existence of multiple bi-directional tunnels 589 simultaneously. 591 o Load Sharing and Load Balancing: 593 Multiple tunnels must be maintained simultaneously. 595 o Preference Settings: 597 Implicitly, multiple tunnels must be maintained simultaneously if 598 preferences are set for deciding which of the available bi- 599 directional tunnels should be used. To allow user/application to 600 set the preference, a mechanism should be provided to the user/ 601 application for the notification of the availability of multiple 602 bi-directional tunnels, and perhaps also to set preferences. 603 Similar mechanism should also be provided to network 604 administrators for the administration of the preferences. 606 o Aggregate Bandwidth: 608 Multiple tunnels must be maintained simultaneously in order to 609 have an increase in the total aggregated bandwidth available to 610 the mobile network. 612 4. Multihoming Issues 614 As discussed in the previous section, multiple bi-directional tunnels 615 need to be maintained either sequentially (e.g. for fault tolerance) 616 or simultaneously (e.g. for load sharing). 618 In some cases, it may be necessary to divert packets from a (perhaps 619 failed) bi-directional tunnel to an alternative (perhaps newly 620 established) bi-directional tunnel (i.e. for matters of fault 621 recovery, preferences), or to split traffic between multiple tunnels 622 (load sharing, load balancing). 624 So, depending on the configuration under consideration, the issues 625 discussed below may need to be addressed, sometimes dynamically. For 626 each issue, potential ways to solve the problem are investigated and 627 an a recommendation is made on which IETF WG(s) should look into 628 these issues. 630 4.1. Fault Tolerance 632 One of the goals of multihoming is the provision of fault tolerance 633 capabilities. In order to provide such features, a set of tasks need 634 to be performed, including: failure detection, alternative available 635 path exploration, path selection, re-homing of established 636 communications. These are also discussed in [8] and [9] by the Shim6 637 WG. In the following sub-sections, we look at these issues in the 638 specific context of NEMO, rather than the general Shim6 perspective 639 in [8] [9]. In addition, in some scenarios, it may also be required 640 to provide the mechanisms for coordination between different HAs (see 641 Section 4.3) and also the coordination between different MRs (see 642 Section 4.4). 644 4.1.1. Failure Detection 646 It is expected for faults to occur more readily at the edge of the 647 network (i.e. the mobile nodes), due to the use of wireless 648 connections. Efficient fault detection mechanisms are necessary to 649 recover in timely fashion. Depending on the NEMO configuration 650 considered, the failure protection domain greatly varies. In some 651 configurations, the protection domain provided by NEMO multihoming is 652 limited to the links between the MR(s) and the HA(s). In other 653 configurations, the protection domain allows to recover from failures 654 in other parts of the path, so an end to end failure detection 655 mechanism is required. 657 Below are detailed which failure detection capabilities are required 658 for each configuration: 660 o For the (1,1,*) cases, multiple paths are available between a 661 single MR and a single HA. All the traffic from and to the NEMO 662 flows through these MR and HA. Failure detection mechanisms need 663 only to be executed between these two devices. This is a NEMO/ 664 MIPv6 specific issue. 666 o For the (n,1,*) cases, there is a single HA, so all the traffic 667 from and to the NEMO will flow through it. The failure detection 668 mechanisms need to be able to detect failure in the path between 669 the used MR and the only HA. Hence, the failure detection 670 mechanism needs only to involve the HA and the MRs. This is a 671 NEMO/MIPv6 specific issue. 673 o For the (n,n,*) cases, there are multiple paths between the 674 different HAs and the different MRs. Moreover, the HAs may be 675 located in different networks, and have different Internet access 676 links. This implies that changing the HA used may not only allow 677 recovering from failures in the link between the HA and the MR, 678 but also from other failure modes, affecting other parts of the 679 path. In this case, an end-to-end failure detection mechanism 680 would provide additional protection. However, a higher number of 681 failures is likely to occur in the link between the HA and the MR, 682 so it may be reasonable to provide optimized failure detection 683 mechanisms for this failure mode. The (n,n,1) case, however, 684 seems to be pretty NEMO specific, because of the absence of 685 multiple prefixes. The (n,n,n) case is hybrid, since for those 686 cases when selecting a different prefix results in a change of 687 path, the Shim6 protocols (such as those discussed in [8]) may be 688 useful. The other cases are NEMO specific. 690 Most of the above cases involve the detection of tunnel failures 691 between HA(s) and MR(s). This is no different from the case of 692 failure detection between a mobile host and its HA(s). As such, a 693 solution for MIPv6 should apply to NEMO as well. For the case of 694 (n,*,*), a MR synchronization solution (see Section 4.4) should be 695 able to compliment a MIPv6 failure detection solution to achieve the 696 desired functionality for NEMO. 698 In order for fault recovery to work, the MRs and HAs must first 699 possess a means to detect failures: 701 o On the MR's side, the MR can rely on router advertisements from 702 access routers, or other layer-2 trigger mechanisms to detect 703 faults, e.g. [10], [11], [12] or [13]. 705 o On the HA's side, it is more difficult to detect tunnel failures. 706 For an ISP deployment model, the HAs and MRs can use proprietary 707 methods (such as constant transmission of heartbeat signals) to 708 detect failures and check tunnel liveness. In the subscriber 709 model (see Appendix A.2: S/P model), a lack of standardized 710 "tunnel liveness" protocol means that it is harder to detect 711 failures. 713 A possible method is for the MRs to send binding updates more 714 regularly with shorter Lifetime values. Similarly, HAs can return 715 binding acknowledgment messages with smaller Lifetime values, thus 716 forcing the MRs to send binding updates more frequently. These 717 binding updates can be used to emulate "tunnel heartbeats". This 718 however may lead to more traffic and processing overhead, since 719 binding updates sent to HAs must be protected (and possibly 720 encrypted) with security associations. 722 4.1.2. Path Exploration 724 Once a failure in the currently used path is detected, alternative 725 paths need to be explored in order to identify an available one. 726 This process is closely related to failure detection in the sense 727 that paths being explored need to be alternative paths to the one 728 that has failed. There are, however, subtle but significant 729 differences between path exploration and failure detection. Failure 730 detection occurs on the currently used path while path exploration 731 occurs on the alternative paths (not on the one currently being used 732 for exchanging packets). Although both path exploration and failure 733 detection are likely to rely on a reachability or keepalive test 734 exchange, failure detection also relies on other information, such as 735 upper layer information (e.g. positive or negative feedback form 736 TCP), lower layer information (e.g. an interface is down), and 737 network layer information (e.g. as an address being deprecated or 738 ICMP error message). 740 Basically, the same cases as in the analysis of the failure detection 741 (Section 4.1.1) issue are identified: 743 o For the (1,1,*) cases, multiple paths are available between a 744 single MR and a single HA. The existing paths between the HA and 745 the MR need to be explored to identify an available one. The 746 mechanism involves only the HA and the MR. This is a NEMO/MIPv6 747 specific issue. 749 o For the (n,1,*) cases, there is a single HA, so all the traffic 750 from and to the NEMO will flow through it. The available 751 alternative paths are the different ones between the different MRs 752 and the HA. The path exploration mechanism needs only to involve 753 the HA and the MRs. This is a NEMO/MIPv6 specific issue. 755 o For the (n,n,*) cases, there are multiple paths between the 756 different HAs and the different MRs. In this case, alternative 757 paths may be routed completely independently one from each other. 758 An end-to-end path exploration mechanism would be able to discover 759 if any of the end-to-end paths is available. The (n,n,1) case, 760 however, seems to be pretty NEMO specific, because of the absence 761 of multiple prefixes. The (n,n,n) case is hybrid, since for those 762 cases that selecting a different prefix result in a change of 763 path, the Shim6 protocols (such as [9]) may be useful. The other 764 cases, are NEMO specific. 766 Most of the above cases involve the path exploration of tunnels 767 between HA(s) and MR(s). This is no different from the case of path 768 exploration between a mobile host and its HA(s). As such, a solution 769 for MIPv6 should apply to NEMO as well. For the case of (n,*,*), a 770 MR synchronization solution (see Section 4.4) should be able to 771 compliment a MIPv6 path exploration solution to achieve the desired 772 functionality for NEMO. 774 In order to perform path exploration, it is sometimes also necessary 775 for the mobile router to detect the availability of network media. 776 This may be achieved using layer 2 triggers [10], or other mechanism 777 developed/recommended by the Detecting Network Attachment (DNA) 778 Working Group [11][14]. This is related to Section 4.1.1, since the 779 ability to detect media availability would often implies the ability 780 to detect media un-availability. 782 4.1.3. Path Selection 784 A path selection mechanism is required to select among the multiple 785 available paths. Depending on the NEMO multihoming configuration 786 involved, the differences between the paths may affect only the part 787 between the HA and the MR, or they may affect the full end-to-end 788 path. In addition, depending on the configuration, path selection 789 may be performed by the HA(s), the MR(s) or the hosts themselves 790 through address selection, as will be described in details next. 792 The multiple available paths may differ on the tunnel between the MR 793 and the HA used to carry traffic to/from the NEMO. In this case, 794 path selection is performed by the MR and the intra-NEMO routing 795 system for traffic flowing from the NEMO, and path selection is 796 performed by the HA and intra-Home Network routing system for traffic 797 flowing to the NEMO. 799 Alternatively, the multiple paths available may differ in more than 800 just the tunnel between the MR and the HA, since the usage of 801 different prefixes may result in using different providers, hence in 802 completely different paths between the involved endpoints. In this 803 case, besides the mechanisms presented in the previous case, 804 additional mechanisms for the end-to-end path selection may be 805 needed. This mechanism may be closely related to source address 806 selection mechanisms within the hosts, since selecting a given 807 address implies selecting a given prefix, which is associated with a 808 given ISP serving one of the home networks. 810 A dynamic path selection mechanism is thus needed so that this path 811 could be selected by: 813 o The HA: it should be able to select the path based on some 814 information recorded in the binding cache. 816 o The MR: it should be able to select the path based on router 817 advertisements received on both its egress interfaces or on its 818 ingress interfaces for the (n,*,*) case. 820 o The MNN: it should be able to select the path based on "Default 821 Router Selection" (see [Section 6.3.6. Default Router Selection] 822 [15]) in the (n,*,*) case or based on "Source Address Selection" 823 in the (*,*,n) cases (see Section 4.7 of the present memo). 825 o The user or the application: e.g. in case where a user wants to 826 select a particular access technology among the available 827 technologies for reasons of cost or data rate. 829 o A combination of any of the above: a hybrid mechanism should be 830 also available, e.g. one in which the HA, the MR, and/or the MNNs 831 are coordinated to select the path. 833 When multiple bi-directional tunnels are available and possibly used 834 simultaneously, the mode of operation may be either primary-secondary 835 (one tunnel is precedent over the others and used as the default 836 tunnel, while the other serves as a back-up) or peer-to-peer (no 837 tunnel has precedence over one another, they are used with the same 838 priority). This questions which of the bi-directional tunnels would 839 be selected, and based on which of the parameters (e.g. type of flow 840 that goes into/out of the mobile network). 842 The mechanisms for the selection among the different tunnels between 843 the MR(s) and the HA(s) seems to be quite NEMO/MIPv6 specific. For 844 (1,*,*) cases, they are no different from the case of path selection 845 between a mobile host and its HA(s). As such, a solution for MIPv6 846 should apply to NEMO as well. For the case of (n,*,*), a MR 847 synchronization solution (see Section 4.4) should be able to 848 compliment a MIPv6 path selection solution to achieve the desired 849 functionality for NEMO. The mechanisms for selecting among different 850 end-to-end paths based on address selection are similar to the ones 851 used in other multihoming scenarios, as those considered by Shim6 852 (e.g. [16]). 854 4.1.4. Re-Homing 856 After an outage has been detected and an available alternative path 857 has been identified, a re-homing event takes place, diverting the 858 existing communications from one path to the other. Similar to the 859 previous items involved in this process, the re-homing procedure 860 heavily varies depending on the NEMO multihoming configuration. 862 o For the (*,*,1) configurations, the re-homing procedure involves 863 only the MR(s) and the HA(s). The re-homing procedure may involve 864 the exchange of additional BU messages. These mechanisms are 865 shared between NEMO Basic Support and MIPv6. 867 o For the (*,*,n) cases, in addition to the previous mechanisms, end 868 to end mechanisms may be required. Such mechanisms may involve 869 some form of end to end signaling or may simply rely on using 870 different addresses for the communication. The involved 871 mechanisms may be similar to those required for re-homing Shim6 872 communications (e.g. [16]). 874 4.2. Ingress Filtering 876 Ingress filtering mechanisms [17][18] may drop the outgoing packets 877 when multiple bi-directional tunnels end up at different HAs. This 878 could particularly occur if different MNPs are handled by different 879 HAs. If a packet with a source address configured from a specific 880 MNP is tunnelled to a home agent that does not handle that specific 881 MNP the packet may be discarded either by the home agent or by a 882 border gateway in the home network. 884 The ingress filtering compatibility issue is heavily dependent on the 885 particular NEMO multihoming configuration: 887 o For the (*,*,1) cases, there is not such an issue, since there is 888 a single MNP. 890 o For the (*,1,n) cases, there is not such a problem, since there is 891 a single HA, accepting all the MNPs. 893 o (*,n,n) are the cases where the ingress filtering presents some 894 difficulties. In the (1,n,n) case, the problem is simplified 895 because all the traffic from and to the NEMO is routed through a 896 single MR. Such configuration allows the MR to properly route 897 packets respecting the constraints imposed by ingress filtering. 898 The more complex case is the (n,n,n) case. A simplified case 899 occurs when all the prefixes are accepted by all the HAs, so that 900 no problems occur with the ingress filtering. However, this 901 cannot be always assumed, resulting in the problem described 902 below. 904 As an example of how this could happen, consider the deployment 905 scenario illustrated in Figure 9: the mobile network has two mobile 906 routers MR1 and MR2, with home agents HA1 and HA2 respectively. Two 907 bi-directional tunnels are established between the two pairs. Each 908 mobile router advertises a different MNP (P1 and P2 respectively). 909 MNP P1 is registered to HA1, and MNP P2 is registered to HA2. Thus, 910 MNNs should be free to auto-configure their addresses on any of P1 or 911 P2. Ingress filtering could thus happen in two cases: 913 o If the two tunnels are available, MNN cannot forward packet with 914 source address equals P1.MNN to MR2. This would cause ingress 915 filtering at HA2 to occur (or even at MR2). This is contrary to 916 normal Neighbor Discovery [15] practice that an IPv6 node is free 917 to choose any router as its default router regardless of the 918 prefix it chooses to use. 920 o If the tunnel to HA1 is broken, packets that would normally be 921 sent through the tunnel to HA1 should be diverted through the 922 tunnel to HA2. If HA2 (or some border gateway in the domain of 923 HA2) performs ingress filtering, packets with source address 924 configured from MNP P1 may be discarded. 926 Prefix: P1 +-----+ +----+ +----------+ +-----+ 927 +--| MR1 |--| AR |--| |---| HA1 | 928 | +-----+ +----+ | | +-----+ 929 IP: +-----+ | | | Prefix: P1 930 P1.MNN or | MNN |--+ | Internet | 931 P2.MNN +-----+ | | | Prefix: P2 932 | +-----+ +----+ | | +-----+ 933 +--| MR2 |--| AR |--| |---| HA2 | 934 Prefix: P2 +-----+ +----+ +----------+ +-----+ 936 Figure 9: An (n,n,n) mobile network 938 Possible solutions to the ingress filtering incompatibility problem 939 may be based on the following approaches: 941 o Some form of source address dependent routing, whether host-based 942 and/or router-based where the prefix contained in the source 943 address of the packet is considered when deciding which exit 944 router to use when forwarding the packet. 946 o The usage of nested tunnels for (*,n,n) cases. Appendix B 947 describes one such approach. 949 o Deprecating those prefixes associated to non-available exit 950 routers 952 The ingress filtering incompatibilities problems that appear in some 953 NEMO multihoming configurations are similar to those considered in 954 Shim6 (eg. see [19]). 956 4.3. HA Synchronization 958 In the (*,n,*) mobile networks, a single MNP would be registered at 959 different HAs. This gives rise to the following cases: 961 o Only one HA may actively advertise a route to the MNP, 963 o Multiple HAs at different domains may advertise a route to the 964 same MNP. 966 This may pose a problem in the routing infrastructure as a whole if 967 the HAs are located in different administrative domains. The 968 implications of this aspect needs further exploration. Certain level 969 of HA co-ordination may be required. A possible approach is to adopt 970 a HA synchronization mechanism such as that described in [20] and 971 [21]. Such synchronization might also be necessary in a (*,n,*) 972 mobile network, when a MR sends binding update messages to only one 973 HA (instead of all HAs). In such cases, the binding update 974 information might have to be synchronized between HAs. The mode of 975 synchronization may be either primary-secondary or peer-to-peer. In 976 addition, when MNP is delegated to the MR (see Section 4.5), some 977 level of co-ordination between the HAs may also be necessary. 979 This issue is a general mobility issue that will also have to be 980 dealt with by Mobile IPv6 as well as NEMO Basic Support. It is 981 recommended that the Monami6 WG take this issue into consideration. 983 4.4. MR Synchronization 985 In the (n,*,*) mobile network, different MRs may need to be 986 synchronized in order to take common decisions, such as: 988 o advertising the same MNP in the (n,*,1) mobile network (see also 989 "prefix delegation" in Section 4.5); 991 o one MR relaying the advertisement of the MNP from another failed 992 MR in the (n,*,n) mobile network; and 994 o relaying between MRs everything that needs to be relayed, such as 995 data packets, creating a tunnel from the ingress interface, etc, 996 in the (n,*,*) mobile network. 998 However, there is no known standardized protocols for this kind of 999 router-to-router synchronization. Without such synchronization, it 1000 may not be possible for a (n,*,*) mobile network to achieve various 1001 multihoming goals, such as fault tolerance. 1003 Such a synchronization mechanism can be primary-secondary (i.e. a 1004 master MR, with the other MRs as backup) or peer-to-peer (i.e. there 1005 is no clear administrative hierarchy between the MRs). The need for 1006 such mechanism is general in the sense that a multi-router site in 1007 the fixed network would require the same level of router 1008 synchronization. It is recommended that the issue be looked at in 1009 the IPv6 or Shim6 WG, and the NEMO WG to contribute any NEMO specific 1010 requirement. 1012 4.5. Prefix Delegation 1014 In the (*,*,1) mobile network, the same MNP must be advertised to the 1015 MNNs through different paths. There is, however, no synchronization 1016 mechanism available to achieve this. Particularly, 1018 o for the (*,n,1) mobile network, how can multiple HAs delegate the 1019 same MNP to the mobile network? For doing so, the HAs may be 1020 somehow configured to advertise the same MNP. (see also "HA 1021 Synchronization" in Section 4.3). 1023 o for the (n,*,1) mobile network, how can multiple MRs be 1024 synchronized to advertise the same MNP down the NEMO-link? For 1025 doing so, the MRs may be somehow configured to advertise the same 1026 MNP (see also "MR Synchronization" in Section 4.4). 1028 Prefix delegation mechanisms [22][23][24] could be used to ensure all 1029 routers advertise the same MNP. The WG should consider their 1030 application to a multihomed mobile network. 1032 4.6. Multiple Bindings/Registrations 1034 When a MR is configured with multiple Care-of Addresses, it is often 1035 necessary for it to bind these Care-of Addresses to the same MNP. 1037 This is a generic mobility issue, since Mobile IPv6 nodes face a 1038 similar problem. This issue is discussed in [7]. It is sufficient 1039 to note that solutions like [25] can solve this for both Mobile IPv6 1040 and NEMO Basic Support. This issue should be dealt with in the 1041 Monami6 WG. 1043 4.7. Source Address Selection 1045 In the (*,*,n) mobile networks, MNNs would be configured with 1046 multiple addresses. Source address selection mechanisms are needed 1047 to decide which address to choose from. In addition, source address 1048 selection may be closely related to path selection procedures (see 1049 Section 4.1.3) and re-homing techniques (see Section 4.1.4). 1051 However, currently available source address selection mechanisms do 1052 not allow MNNs to acquire sufficient information to select their 1053 source addresses intelligently (such as based on the traffic 1054 condition associated with the home network of each MNP). It may be 1055 desirable for MNNs to be able to acquire "preference" information on 1056 each MNP from the MRs. This would allow default address selection 1057 mechanisms such as those specified in [26] to be used. Further 1058 exploration on setting such "preference" information in Router 1059 Advertisement based on performance of the bi-directional tunnel might 1060 prove to be useful. 1062 This is a general issue faced by any node when offered multiple 1063 prefixes. It is recommended that the issue be examined by other WG 1064 (such as IPv6). 1066 4.8. Loop Prevention in Nested Mobile Networks 1068 When a multihomed mobile network is nested within another mobile 1069 network, it can result in very complex topologies. For instance, a 1070 nested mobile network may be attached to two different root-MRs, thus 1071 the aggregated network no longer forms a simple tree structure. As 1072 such, a solution to prevent an infinite loop of multiple mobile 1073 routers must be provided. 1075 This problem is specific to NEMO Basic Support. It is recommended 1076 that the NEMO WG standardizes a solution to solve this problem (such 1077 as the use of a tree-spanning algorithm, or [27]). 1079 4.9. Prefix Ownership 1081 When a (n,*,1) network splits, (i.e. the two MRs split themselves 1082 up), MRs on distinct links may try to register the only available 1083 MNP. This cannot be allowed, as the HA has no way to know which node 1084 with an address configured from that MNP is attached to which MR. 1085 Some mechanism must be present for the MNP to either be forcibly 1086 removed from one (or all) MRs, or the implementors must not allow a 1087 (n,*,1) network to split. 1089 A possible approach to solving this problem is described in [28]. 1091 This problem is specific to NEMO Basic Support. However, it is 1092 unclear whether there is sufficient deployment scenario for this 1093 problem to occur. It is recommended that the NEMO WG standardizes a 1094 solution to solve this problem if there is sufficient vendor/operator 1095 interest, or specifies that the split of a (n,*,1) network cannot be 1096 allowed without a router renumbering. 1098 4.10. Preference Settings 1100 When a mobile network is multihomed, the MNNs may be able to enjoy 1101 the benefits of multihoming, such as to choose among the available 1102 paths based on cost, transmission delays, bandwidth, etc. However, 1103 in some cases, such a choice is not made available to the MNNs. 1104 Particularly, 1106 o In the (*,*,n) mobile network, the MNNs can influence the path by 1107 source address selection (see Section 4.1.3, Section 4.7). 1109 o In the (n,*,*) mobile network, the MNNs can influence the path by 1110 default router selection (see Section 4.1.3). 1112 o In the (1,*,1) mobile network, the MNNs cannot influence the path 1113 selection. 1115 A mechanism that allows the MNN to indicate its preference for a 1116 given traffic might be helpful. In addition, there may also be a 1117 need to exchange some information between the MRs and the MNNs. This 1118 problem is general in the sense that any IPv6 nodes may wish to 1119 influence the routing decision done by the upstream routers. Such 1120 mechanism is currently being explored by various WGs, such as the 1121 NSIS and IPFIX WGs. It is also possible that a Shim6 layer in the 1122 MNNs may possess such capability. It is recommended that vendors or 1123 operators to investigate into the solutions developed by these WGs 1124 when providing multihoming capabilities to mobile networks. 1126 5. Recommendations to the Working Group 1128 Several issues that might impact the deployment of NEMO with 1129 multihoming capabilities were identified in Section 4. These are 1130 shown in the matrix below, for each of the eight multihoming 1131 configurations, together with indications of the WG(s) in which each 1132 issue is the most likely to be solved. 1134 +=================================================================+ 1135 | # of MRs: | 1 | 1 | 1 | 1 | n | n | n | n | 1136 | # of HAs: | 1 | 1 | n | n | 1 | 1 | n | n | 1137 | # of Prefixes: | 1 | n | 1 | n | 1 | n | 1 | n | 1138 +=================================================================+ 1139 | Fault Tolerance | * | * | * | * | * | * | * | * | 1140 +---------------------------------+---+---+---+---+---+---+---+---+ 1141 | Failure Detection |N/M|N/M|N/M|N/M|N/M|N/M| N | S | 1142 +---------------------------------+---+---+---+---+---+---+---+---+ 1143 | Path Exploration |N/M|N/M|N/M|N/M|N/M|N/M| N | S | 1144 +---------------------------------+---+---+---+---+---+---+---+---+ 1145 | Path Selection | N |S/N| N |S/N| N |S/N| N |S/N| 1146 +---------------------------------+---+---+---+---+---+---+---+---+ 1147 | Re-Homing |N/M| S |N/M| S |N/M| S |N/M| S | 1148 +---------------------------------+---+---+---+---+---+---+---+---+ 1149 | Ingress Filtering | . | . | . | t | . | . | . | N | 1150 +---------------------------------+---+---+---+---+---+---+---+---+ 1151 | HA Synchronization | . | . |N/M|N/M| . | . |N/M|N/M| 1152 +---------------------------------+---+---+---+---+---+---+---+---+ 1153 | MR Synchronization | . | . | . | . | G | G | G | G | 1154 +---------------------------------+---+---+---+---+---+---+---+---+ 1155 | Prefix Delegation | . | . | N | N | N | N | N | N | 1156 +---------------------------------+---+---+---+---+---+---+---+---+ 1157 | Multiple Binding/Registrations | M | M | M | M | M | M | M | M | 1158 +---------------------------------+---+---+---+---+---+---+---+---+ 1159 | Source Address Selection | . | G | . | G | . | G | . | G | 1160 +---------------------------------+---+---+---+---+---+---+---+---+ 1161 | Loop Prevention in Nested NEMO | N | N | N | N | N | N | N | N | 1162 +---------------------------------+---+---+---+---+---+---+---+---+ 1163 | Prefix Ownership | . | . | . | . | N | . | N | . | 1164 +---------------------------------+---+---+---+---+---+---+---+---+ 1165 | Preference Settings | G | G | G | G | G | G | G | G | 1166 +=================================================================+ 1167 N - NEMO Specific M - MIPv6 Specific G - Generic IPv6 1168 S - SHIM6 WG D - DNA WG 1169 . - Not an Issue t - trivial 1170 * - Fault Tolerance is a combination of Failure Detection, Path 1171 Exploration, Path Selection, and Re-Homing 1173 Figure 10: Matrix of NEMO Multihoming Issues 1174 The above matrix serves to identify which issues are NEMO-specific, 1175 and which concern other Working Groups. The readers are reminded 1176 that this matrix is a simplification of Section 4 as subtle details 1177 are not represented in Figure 10. 1179 As can be seen from Figure 10, the following have some concerns which 1180 are specific to NEMO: Failure Detection, Path Exploration, Path 1181 Selection, Re-Homing, Ingress Filtering, HA Synchronization, Prefix 1182 Delegation, Loop Prevention in Nested NEMO, and Prefix Ownership. 1183 Based on the authors' best knowledge of the possible deployments of 1184 NEMO, it is recommended that: 1186 o Failure Detection, Path Exploration, Path Selection, and Re-Homing 1187 be worked on by the Monami6 WG 1189 Although Path Selection is reflected in Figure 10 as NEMO- 1190 Specific, the technical consideration of the problem is believed 1191 to be quite similar to the selection of multiple paths in mobile 1192 nodes. As such, we would recommend that such issues be taken into 1193 consideration by the Monami6 WG. In addition, a Shim6 mechanism 1194 is expected to be useful for the issues of Path Selection and Re- 1195 Homing. It is thus our recommendation that the NEMO WG would re- 1196 evaluate the applicability of mechanisms developed by the Shim6 1197 and Monami6 WGs when they are available. 1199 o Ingress Filtering on the (n,n,n) configuration be solved by the 1200 NEMO WG 1202 This problem is clearly defined, and can be solved by the WG. 1203 Deployment of the (n,n,n) NEMO can be envisioned on vehicles for 1204 mass transportation (such as buses, trains) where different 1205 service providers may install their own mobile routers on the 1206 vehicle/vessel. 1208 It should be noted that the Shim6 WG may be developing a mechanism 1209 for overcoming ingress filtering in a more general sense. We thus 1210 recommend that the NEMO WG to concentrate only on the (n,n,n) 1211 configuration should the WG decide to work on this issue. 1213 o Home Agent Synchronization and Multiple Bindings/Registrations be 1214 worked on by the Monami6 WG 1216 These are problems that will be addressed by the Monami6 WG, and 1217 it is believed that a solution that applies to mobile hosts would 1218 applies to mobile routers running the NEMO Basic Support protocol. 1220 o Prefix Delegation be reviewed and checked by the NEMO WG 1222 There is already a WG draft providing prefix delegation 1223 functionality to NEMO Basic Support. The WG should review the 1224 draft and verified that it addresses any concern a multihomed NEMO 1225 might have, as discussed in Section 4.5. 1227 o Loop Prevention in Nested NEMO be worked on by the NEMO WG 1229 Having a loop in nested NEMO is a real and serious problem, 1230 especially when connections are wireless (therefore there is no 1231 physical structure to avoid loops). 1233 o Prefix Ownership should be considered by the vendors and operators 1235 The problem of Prefix Ownership only occurs when a mobile network 1236 with multiple MRs and a single MNP can arbitrarily join and split. 1237 Vendors and operators of mobile networks are encouraged to input 1238 their views on the applicability of deploying such kind of mobile 1239 networks. 1241 6. Conclusion 1243 This memo is an analysis of multihoming in the context of network 1244 mobility under the operation of NEMO Basic Support. The purpose of 1245 this memo is to investigate issues related to such a bi-directional 1246 tunneling mechanism when mobile networks are multihomed. For doing 1247 so, a taxonomy was proposed to classify the mobile networks in eight 1248 possible multihomed configurations. The issue were explained and 1249 were then summarized in a table showing under which multihoming 1250 configuration it applies, and which IETF working group is the best 1251 chartered to solve it. This analysis will be helpful to extend the 1252 existing standards to support multihoming and to implementors of NEMO 1253 Basic Support and multihoming-related mechanisms. 1255 7. IANA Considerations 1257 This is an informational document and does not require any IANA 1258 action. 1260 8. Security Considerations 1262 This is an informational document where the multihoming 1263 configurations under the operation of NEMO Basic Support are 1264 analyzed. Security considerations of these multihoming 1265 configurations, should they be different from those that concern NEMO 1266 Basic Support, must be considered by forthcoming solutions. 1268 9. Acknowledgments 1270 The authors would like to thank people who have given valuable 1271 comments on various multihoming issues on the mailing list, and also 1272 those who have suggested directions in the 56th - 61st IETF Meetings. 1273 The initial evaluation of NEMO Basic Support is a contribution from 1274 Julien Charbon. 1276 10. References 1278 10.1. Normative References 1280 [1] Ernst, T., "Network Mobility Support Goals and Requirements", 1281 draft-ietf-nemo-requirements-05 (work in progress), 1282 October 2005. 1284 [2] Manner, J. and M. Kojo, "Mobility Related Terminology", 1285 RFC 3753, June 2004. 1287 [3] Ernst, T. and H. Lach, "Network Mobility Support Terminology", 1288 draft-ietf-nemo-terminology-04 (work in progress), October 2005. 1290 [4] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, 1291 "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, 1292 January 2005. 1294 [5] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in 1295 IPv6", RFC 3775, June 2004. 1297 10.2. Informative References 1299 [6] Ernst, T., Montavont, N., Wakikawa, R., Paik, E., Ng, C., 1300 Kuladinithi, K., and T. Noel, "Goals and Benefits of 1301 Multihoming", draft-multihoming-generic-goals-and-benefits-02 1302 (work in progress), October 2005. 1304 [7] Montavont, N., Wakikawa, R., Ernst, T., Ng, C., and K. 1305 Kuladinithi, "Analysis of Multihoming in Mobile IPv6", 1306 draft-montavont-mobileip-multihoming-pb-statement-05 (work in 1307 progress), October 2005. 1309 [8] Arkko, J., "Failure Detection and Locator Pair Exploration 1310 Design for IPv6 Multihoming", 1311 draft-ietf-shim6-failure-detection-01 (work in progress), 1312 October 2005. 1314 [9] Beijnum, I., "Shim6 Reachability Detection", 1315 draft-ietf-shim6-reach-detect-00 (work in progress), July 2005. 1317 [10] Yegin, A., "Link-layer Event Notifications for Detecting 1318 Network Attachments", draft-ietf-dna-link-information-02 (work 1319 in progress), July 2005. 1321 [11] Narayanan, S., "Detecting Network Attachment in IPv6 - Best 1322 Current Practices for hosts.", draft-ietf-dna-hosts-01 (work in 1323 progress), July 2005. 1325 [12] Yegin, A., "Link-layer Hints for Detecting Network 1326 Attachments", draft-yegin-dna-l2-hints-01 (work in progress), 1327 February 2004. 1329 [13] Yegin, A., "Supporting Optimized Handover for IP Mobility 1330 -Requirements for Underlying Systems", 1331 draft-manyfolks-l2-mobilereq-02 (work in progress), July 2002. 1333 [14] Narayanan, S., "Detecting Network Attachment in IPv6 - Best 1334 Current Practices for Routers", draft-ietf-dna-routers-00 (work 1335 in progress), July 2005. 1337 [15] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery 1338 for IP Version 6 (IPv6)", RFC 2461, December 1998. 1340 [16] Bagnulo, M. and J. Arkko, "Functional decomposition of the 1341 multihoming protocol", draft-ietf-shim6-functional-dec-00 (work 1342 in progress), July 2005. 1344 [17] Ferguson, P. and D. Senie, "Network Ingress Filtering: 1345 Defeating Denial of Service Attacks which employ IP Source 1346 Address Spoofing", BCP 38, RFC 2827, May 2000. 1348 [18] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 1349 Networks", BCP 84, RFC 3704, March 2004. 1351 [19] Huitema, C., "Ingress filtering compatibility for IPv6 1352 multihomed sites", draft-huitema-shim6-ingress-filtering-00 1353 (work in progress), September 2005. 1355 [20] Wakikawa, R., Devarapalli, V., and P. Thubert, "Inter Home 1356 Agents Protocol (HAHA)", draft-wakikawa-mip6-nemo-haha-01 (work 1357 in progress), February 2004. 1359 [21] Koh, B., Ng, C., and J. Hirano, "Dynamic Inter Home Agent 1360 Protocol", draft-koh-mip6-nemo-dhap-00 (work in progress), 1361 July 2004. 1363 [22] Miyakawa, S. and R. Droms, "Requirements for IPv6 Prefix 1364 Delegation", RFC 3769, June 2004. 1366 [23] Droms, R. and P. Thubert, "DHCPv6 Prefix Delegation for NEMO", 1367 draft-droms-nemo-dhcpv6-pd-02 (work in progress), April 2005. 1369 [24] Kniveton, T. and P. Thubert, "Mobile Network Prefix 1370 Delegation", draft-ietf-nemo-prefix-delegation-00 (work in 1371 progress), August 2005. 1373 [25] Wakikawa, R., "Multiple Care-of Addresses Registration", 1374 draft-wakikawa-mobileip-multiplecoa-04 (work in progress), 1375 June 2005. 1377 [26] Draves, R., "Default Address Selection for Internet Protocol 1378 version 6 (IPv6)", RFC 3484, February 2003. 1380 [27] Thubert, P., "Nested Nemo Tree Discovery", 1381 draft-thubert-tree-discovery-02 (work in progress), July 2005. 1383 [28] Kumazawa, M., "Token based Duplicate Network Detection for 1384 split mobile network (Token based DND)", 1385 draft-kumazawa-nemo-tbdnd-02 (work in progress), July 2005. 1387 Appendix A. Alternative Classifications Approach 1389 A.1. Ownership-Oriented Approach 1391 An alternative approach to classifying multihomed mobile network is 1392 proposed by Erik Nordmark (Sun Microsystems) by breaking the 1393 classification of multihomed network based on ownership. This is 1394 more of a tree-like top-down classification. Starting from the 1395 control and ownership of the HA(s) and MR(s), there are two different 1396 possibilities: either (i) the HA(s) and MR(s) are controlled by a 1397 single entity, or (ii) the HA(s) and MR(s) are controlled by separate 1398 entities. We called the first possibility the 'ISP Model', and the 1399 second the 'Subscriber/Provider Model'. 1401 A.1.1. ISP Model 1403 The case of the HA(s) and MR(s) are controlled by the same entity can 1404 be best illustrated as an Internet Service Provider (ISP) installing 1405 mobile routers on trains, ships or planes. It is up to the ISP to 1406 deploy a certain configuration of mobile network; all 8 1407 configurations as described in the Configuration-Oriented Approach 1408 are possible. In the remaining portion of this document, when 1409 specifically referring to a mobile network configuration that is 1410 controlled by a single entity, we will add an 'ISP' prefix: for 1411 example: ISP-(1,1,1) or ISP-(1,N,N). 1413 When the HA(s) and MR(s) are controlled by a single entity (such as 1414 an ISP), the ISP can decide whether it wants to assign one or 1415 multiple MNPs to the mobile network just like it can make the same 1416 decision for any other link in its network (wired or otherwise). In 1417 any case, the ISP will make the routing between the mobile networks 1418 and its core routers (such as the HAs) work. This include not 1419 introducing any aggregation between the HAs which will filter out 1420 routing announcements for the MNP(es). 1422 To such ends, the ISP has various means and mechanisms. For one, the 1423 ISP can run its Interior Gateway Protocol (IGP) over bi-directional 1424 tunnels between the MR(s) and HA(s). Alternatively, static routes 1425 may be used with the tunnels. When static routes are used, a 1426 mechanism to test "tunnel liveness" might be necessary to avoid 1427 maintaining stale routes. Such "tunnel liveness" may be tested by 1428 sending heartbeats signals from MR(s) to the HA(s). A possibility is 1429 to simulate heartbeats using Binding Updates messages by controlling 1430 the "Lifetime" field of the Binding Acknowledgment message to force 1431 the MR to send Binding Update messages at regular interval. However, 1432 a more appropriate tool might be the Binding Refresh Request message, 1433 though conformance to the Binding Refresh Request message may be less 1434 strictly enforced in implementations since it serves a somewhat 1435 secondary role when compared to Binding Update messages. 1437 A.1.2. Subscriber/Provider Model 1439 The case of the HA(s) and MR(s) are controlled by the separate 1440 entities can be best illustrated with a subscriber/provider model, 1441 where the MRs belongs to a single subscriber and subscribes to one or 1442 more ISPs for HA services. There is two sub-categories in this case: 1443 when the subscriber subscribes to a single ISP, and when the 1444 subscriber subscribes to multiple ISPs. In the remaining portion of 1445 this document, when specifically referring to a mobile network 1446 configuration that is in the subscriber/provider model where the 1447 subscriber subscribes to only one ISP, we will add an 'S/P' prefix: 1448 for example: S/P-(1,1,1) or S/P-(1,n,n). When specifically referring 1449 to a mobile network configuration that is in the subscriber/provider 1450 model where the subscriber subscribes to multiple ISPs, we will add 1451 an 'S/mP' prefix: for example: S/mP-(1,1,1) or S/mP-(1,n,n). 1453 Not all 8 configurations are likely to be deployed for the S/P and 1454 S/mP models. For instance, it is unlikely to foresee a S/mP-(*,1,1) 1455 mobile network where there is only a single HA. For the S/P model, 1456 the following configurations are likely to be deployed: 1458 o S/P-(1,1,1): Single Provider, Single MR, Single HA, Single MNP 1460 o S/P-(1,1,n): Single Provider, Single MR, Single HA, Multiple MNPs 1462 o S/P-(1,n,1): Single Provider, Single MR, Multiple HAs, Single MNP 1464 o S/P-(1,n,n): Single Provider, Single MR, Multiple HAs, Multiple 1465 MNPs 1467 o S/P-(n,n,1): Single Provider, Multiple MRs, Single HA, Single MNP 1469 o S/P-(n,1,n): Single Provider, Multiple MRs, Single HA, Multiple 1470 MNPs 1472 o S/P-(n,n,1): Single Provider, Multiple MRs, Multiple HAs, Single 1473 MNP 1475 o S/P-(n,n,n): Single Provider, Multiple MRs, Multiple HAs, Multiple 1476 MNPs 1478 For the S/mP model, the following configurations are likely to be 1479 deployed: 1481 o S/mP-(1,n,1): Multiple Providers, Single MR, Multiple HAs, Single 1482 MNP 1484 o S/mP-(1,n,n): Multiple Providers, Single MR, Multiple HAs, 1485 Multiple MNPs 1487 o S/mP-(n,n,n): Multiple Providers, Multiple MRs, Multiple HAs, 1488 Multiple MNPs 1490 When the HA(s) and MR(s) are controlled by different entities, it is 1491 more likely the scenario where the MR is controlled by one entity 1492 (i.e. the subscriber), and the MR is establishing multiple bi- 1493 directional tunnels to one or more HA(s) provided by one or more 1494 ISP(s). In such case, it is unlikely for the ISP to run IGP over the 1495 bi-directional tunnel, since ISP would most certainly wish to retain 1496 full control of its routing domain. 1498 A.2. Problem-Oriented Approach 1500 A third approach is proposed by Pascal Thubert (Cisco System). This 1501 focused on the problems of multihomed mobile networks rather than the 1502 configuration or ownership. With this approach, there is a set of 4 1503 categories based on two orthogonal parameters: the number of HAs, and 1504 the number of MNPs advertised. Since the two parameters are 1505 orthogonal, the categories are not mutually exclusive. The four 1506 categories are: 1508 o Tarzan: Single HA for Different Care-of Addresses of Same MNP 1510 This is the case where one mobile router registers different 1511 Care-of Addresses to the same home agent for the same subnet 1512 prefix. This is equivalent to the case of y=1, i.e. the (1,1,*) 1513 mobile network. 1515 o JetSet: Multiple HAs for Different Care-of Addresses of Same MNP 1517 This is the case where the mobile router registers different 1518 Care-of Addresses to different home agents for the same subnet 1519 prefix. This is equivalent to the case of y=n, i.e. the (1,n,*) 1520 mobile network. 1522 o Shinkansen: Single MNP Advertised by MR(s) 1524 This is the case where one MNP is announced by different MRs. 1525 This is equivalent to the case of x=n and z=1, i.e. the (n,*,1) 1526 mobile network. 1528 o DoubleBed: Multiple MNPs Advertised by MR(s) 1530 This is the case where more than one MNPs are announced by the 1531 different MRs. This is equivalent to the case of x=n and z=n, 1532 i.e. the (n,*,n) mobile network. 1534 Appendix B. Nested Tunneling for Fault Tolerance 1536 In order to utilize the additional robustness provided by 1537 multihoming, MRs that employ bi-directional tunneling with their HAs 1538 should dynamically change their tunnel exit points depending on the 1539 link status. For instance, if a MR detects that one of its egress 1540 interface is down, it should detect if any other alternate route to 1541 the global Internet exists. This alternate route may be provided by 1542 any other MRs connected to one of its ingress interfaces that has an 1543 independent route to the global Internet, or by another active egress 1544 interface the MR itself possess. If such an alternate route exists, 1545 the MR should re-establish the bi-directional tunnel using this 1546 alternate route. 1548 In the remaining part of this Appendix, we will attempt to 1549 investigate methods of performing such re-establishment of bi- 1550 directional tunnels. This method of tunnel re-establishment is 1551 particularly useful for the (*,n,n) NEMO configuration. The method 1552 described is by no means complete and merely serves as a suggestion 1553 on how to approach the problem. It is also not the objective to 1554 specify a new protocol specifically tailored to provide this form of 1555 re- establishments. Instead, we will limit ourselves to currently 1556 available mechanisms specified in Mobile IPv6 [5] and Neighbor 1557 Discovery in IPv6 [15]. 1559 B.1. Detecting Presence of Alternate Routes 1561 To actively utilize the robustness provided by multihoming, a MR must 1562 first be capable of detecting alternate routes. This can be manually 1563 configured into the MR by the administrators if the configuration of 1564 the mobile network is relatively static. It is however highly 1565 desirable for MRs to be able to discover alternate routes 1566 automatically for greater flexibility. 1568 The case where a MR possesses multiple egress interface (bound to the 1569 same HA or otherwise) should be trivial, since the MR should be able 1570 to "realize" it has multiple routes to the global Internet. 1572 In the case where multiple MRs are on the mobile network, each MR has 1573 to detect the presence of other MR. A MR can do so by listening for 1574 Router Advertisement message on its *ingress* interfaces. When a MR 1575 receives a Router Advertisement message with a non-zero Router 1576 Lifetime field from one of its ingress interfaces, it knows that 1577 another MR which can provide an alternate route to the global 1578 Internet is present in the mobile network. 1580 B.2. Re-Establishment of Bi-Directional Tunnels 1582 When a MR detects that the link by which its current bi-directional 1583 tunnel with its HA is using is down, it needs to re-establish the bi- 1584 directional tunnel using an alternate route detected. We consider 1585 two separate cases here: firstly, the alternate route is provided by 1586 another egress interface that belongs to the MR; secondly, the 1587 alternate route is provided by another MR connected to the mobile 1588 network. We refer to the former case as an alternate route provided 1589 by an alternate egress interface, and the latter case as an alternate 1590 route provided by an alternate MR. 1592 B.2.1. Using Alternate Egress Interface 1594 When an egress interface of a MR loses the connection to the global 1595 Internet, the MR can make use of its alternate egress interface 1596 should it possess multiple egress interfaces. The most direct way to 1597 do so is for the mobile router to send a binding update to the home 1598 agent of the failed interface using the Care-of Address assigned to 1599 the alternate interface in order to re-establish the bi-directional 1600 tunneling using the Care-of Address on the alternate egress 1601 interface. After a successful binding update, the MR encapsulates 1602 outgoing packets through the bi-directional tunnel using the 1603 alternate egress interface. 1605 The idea is to use the global address (most likely a Care-of Address) 1606 assigned to an alternate egress interface as the new (back-up) 1607 Care-of Address of the mobile router to re-establish the bi- 1608 directional tunneling with its home agent. 1610 B.2.2. Using Alternate Mobile Router 1612 When the MR loses a connection to the global Internet, the MR can 1613 utilize a route provided by an alternate MR (if one exists) to re- 1614 establish the bi-directional tunnel with its HA. First, the MR has 1615 to obtain a Care-of Address from the alternate MR (i.e. attaches 1616 itself to the alternate MR). Next, it sends binding update to its HA 1617 using the Care-of Address obtained from the alternate MR. From then 1618 on, the MR can encapsulates outgoing packets through the bi- 1619 directional tunnel using via the alternate MR. 1621 The idea is to obtain a Care-of Address from the alternate MR and use 1622 this as the new (back-up) Care-of Address of the MR to re-establish 1623 the bi-directional tunneling with its HA. 1625 Note that every packet sent between MNNs and their correspondent 1626 nodes will experience two levels of encapsulation. First level of 1627 tunneling occurs between a MR which the MNN uses as its default 1628 router and the MR's HA. The second level of tunneling occurs between 1629 the alternate MR and its HA. 1631 B.3. To Avoid Tunneling Loop 1633 The method of re-establishing the bi-directional tunnel as described 1634 in Appendix B.2 may lead to infinite loops of tunneling. This 1635 happens when two MRs on a mobile network lose connection to the 1636 global Internet at the same time and each MR tries to re-establish 1637 bi-directional tunnel using the other MR. We refer to this 1638 phenomenon as tunneling loop. 1640 One approach to avoid tunneling loop is for a MR that has lost 1641 connection to the global Internet to insert an option into the Router 1642 Advertisement message it broadcasts periodically. This option serves 1643 to notify other MRs on the link that the sender no longer provides 1644 global connection. Note that setting a zero Router Lifetime field 1645 will not work well since it will cause MNNs that are attached to the 1646 MR to stop using the MR as their default router too (in which case, 1647 things are back to square one). 1649 B.4. Points of Considerations 1651 This method of using tunnel re-establishments is by no means a 1652 complete solution. There are still points to consider to develop it 1653 into a fully functional solution. For instance, in Appendix B.1, it 1654 was suggested that MR detects the presence of other MRs using Router 1655 Advertisements. However, Router Advertisements are link scoped, so 1656 when there is more than one link, some information may be lost. For 1657 instance, suppose a case where there is three MRs and three different 1658 prefixes and each MR is in a different link with regular routers in 1659 between. Suppose now that only a single MR is working, how do the 1660 other MRs identify which prefix they have to use to configure the new 1661 CoA? In this case, there are three prefixes being announced and a MR 1662 whose link has failed, knows that his prefix is not to be used, but 1663 it has not enough information to decide which one of the other two 1664 prefixes to use to configure the new CoA. In such cases, a mechanism 1665 is needed to allow a MR to withdraw its own prefix when it discovers 1666 that its link is no longer working. 1668 Appendix C. Change Log 1670 o This draft is an update of draft-ng-nemo-multihoming-issues-03.txt 1671 which is itself a merge of 3 previous drafts 1672 draft-ng-nemo-multihoming-issues-02.txt, 1673 draft-eun-nemo-multihoming-problem-statement-00.txt, and 1674 draft-charbon-nemo-multihoming-evaluation-00.txt 1676 o Changes from draft-ietf-nemo-multihoming-issues-03 to -04: 1678 * Updated Section 3: "Deployment Scenarios and Prerequisites" 1680 * Modifications to Section 4: 1682 + Removed "Media Detection" and moved the relevant concerns to 1683 "Path Exploration" 1685 + Added new "Preference Settings" issue 1687 + Various text clean-ups in mopst of the sub-sections 1689 * Modifications to Section 5: 1691 + Changed Section 5: "Matrix" to "Recommendations to the 1692 Working Group" 1694 + Identifies which are the issues that are important, and made 1695 recommendations as to how to resolve these multihoming 1696 issues 1698 * Addressed Issue #12: Added Appendix B.4: "Points of 1699 Considerations" to document the concerns raised for this tunnel 1700 re-eatblishment mechanism. 1702 o Changes from draft-ietf-nemo-multihoming-issues-02 to -03: 1704 * Enlisted Marcelo Bagnulo as co-author 1706 * Restructuring of Section 4: 1708 + Re-named 'Path Survival' to 'Fault Tolerance' 1710 + Moved 'Path Failure Detection' and 'Path Selection' as sub- 1711 issues of 'Fault Tolerance' 1713 + Added 'Path Exploration' and 'Re-homing' as sub-issues of 1714 'Fault Tolerance' 1716 + Removed 'Impact on Routing Infrastructure' 1718 * Breaking references into Normative and Informative 1720 o Changes from draft-ietf-nemo-multihoming-issues-01 to -02: 1722 * Added recommendations/suggestion of which WG each issue should 1723 be addressed as pointed out in 61st IETF. 1725 * Minor updates on references. 1727 o Changes from draft-ietf-nemo-multihoming-issues-00 to -01: 1729 * Replaced NEMO-Prefix with MNP as decided by the WG at 60th IETF 1731 * Addressed Issue #1 in Section 1: Added a note to remind readers 1732 that IPv6 is implicitly assumed 1734 * Addressed Issue #3 in Sect 2.3: Removed text on assumption 1736 * Addressed Issue #6 in Sect 3.1 "Deployment Scenarios": Added 1737 benefits 1739 * Addressed Issue #7 in Sect 3.2 "Prerequisites": Modified text 1741 * Addressed Issue #9 in Sect 4.3 "Ingress Filtering": Modified 1742 text 1744 * Addressed Issue #10 in Sect 4.4: Added paragraph on other 1745 failure modes 1747 * Addressed Issue #10: New Sect 4.5 on media detection 1749 * Addressed Issue #11 in Section 4.11: modified text 1751 o Changes from draft-ng-multihoming-issues-03 to 1752 draft-ietf-nemo-multihoming-issues-00: 1754 * Expanded Section 4: "Problem Statement" 1756 * Merged "Evaluation" Section into Section 4: "Problem Statement" 1758 * Cleaned up description in Section 2: "Classification", and 1759 clearly indicate in each classification, what are the 1760 multihomed entities 1762 * Re-organized Section 2: "Deployment Scenarios and 1763 Prerequisites", and created the "Prerequisites" sub-section. 1765 o Changes from draft-ng-multihoming-issues-02 to 1766 draft-ng-multihoming-issues-03: 1768 * Merged with draft-eun-nemo-multihoming-problem-statement (see 1769 Section 4: "Problem Statement") 1771 * Included conclusions from 1772 draft-charbon-nemo-multihoming-evaluation-00 1774 * Re-organized some part of "Benefits/Issues of Multihoming in 1775 NEMO" to Section 4: "Problem Statement" 1777 * Removed lots of text to be in sync with [6]. 1779 * Title changed from "Multihoming Issues in NEMO Basic Support" 1780 to "Analysis of Multihoming in NEMO" 1782 * Changed (w,x,y) to (x,y,z) in taxonomy. 1784 * Moved alternative approaches of classification to Appendix 1786 * Creation of this Change-Log itself ;-) 1788 Authors' Addresses 1790 Chan-Wah Ng 1791 Panasonic Singapore Laboratories Pte Ltd 1792 Blk 1022 Tai Seng Ave #06-3530 1793 Tai Seng Industrial Estate 1794 Singapore 534415 1795 SG 1797 Phone: +65 65505420 1798 Email: chanwah.ng@sg.panasonic.com 1800 Eun Kyoung Paik 1801 KT 1802 Portable Internet Team, Convergence Lab., KT 1803 17 Woomyeon-dong, Seocho-gu 1804 Seoul 137-792 1805 Korea 1807 Phone: +82-2-526-5233 1808 Fax: +82-2-526-5200 1809 Email: euna@kt.co.kr 1810 URI: http://mmlab.snu.ac.kr/~eun/ 1812 Thierry Ernst 1813 Keio University / WIDE 1814 Jun Murai Lab., Keio University. 1815 K-square Town Campus, 1488-8 Ogura, Saiwa-Ku 1816 Kawasaki, Kanagawa 212-0054 1817 Japan 1819 Phone: +81-44-580-1600 1820 Fax: +81-44-580-1437 1821 Email: ernst@sfc.wide.ad.jp 1822 URI: http://www.sfc.wide.ad.jp/~ernst/ 1824 Marcelo Bagnulo 1825 Universidad Carlos III de Madrid 1826 Av. Universidad, 30 1827 Leganes, Madrid 28911 1828 Spain 1830 Phone: +34 91624 8837 1831 Email: marcelo@it.uc3m.es 1833 Intellectual Property Statement 1835 The IETF takes no position regarding the validity or scope of any 1836 Intellectual Property Rights or other rights that might be claimed to 1837 pertain to the implementation or use of the technology described in 1838 this document or the extent to which any license under such rights 1839 might or might not be available; nor does it represent that it has 1840 made any independent effort to identify any such rights. Information 1841 on the procedures with respect to rights in RFC documents can be 1842 found in BCP 78 and BCP 79. 1844 Copies of IPR disclosures made to the IETF Secretariat and any 1845 assurances of licenses to be made available, or the result of an 1846 attempt made to obtain a general license or permission for the use of 1847 such proprietary rights by implementers or users of this 1848 specification can be obtained from the IETF on-line IPR repository at 1849 http://www.ietf.org/ipr. 1851 The IETF invites any interested party to bring to its attention any 1852 copyrights, patents or patent applications, or other proprietary 1853 rights that may cover technology that may be required to implement 1854 this standard. Please address the information to the IETF at 1855 ietf-ipr@ietf.org. 1857 Disclaimer of Validity 1859 This document and the information contained herein are provided on an 1860 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1861 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1862 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1863 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1864 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1865 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1867 Copyright Statement 1869 Copyright (C) The Internet Society (2005). This document is subject 1870 to the rights, licenses and restrictions contained in BCP 78, and 1871 except as set forth therein, the authors retain all their rights. 1873 Acknowledgment 1875 Funding for the RFC Editor function is currently provided by the 1876 Internet Society.