idnits 2.17.1 draft-ietf-nemo-multihoming-issues-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1.a on line 19. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1426. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1403. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1410. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1416. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 4 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 1017 has weird spacing: '... (Token based...' == Line 1099 has weird spacing: '...chanism to te...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 21, 2005) is 7003 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-04 ** 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-03 ** Downref: Normative reference to an Informational draft: draft-ietf-nemo-terminology (ref. '3') ** Obsolete normative reference: RFC 3775 (ref. '5') (Obsoleted by RFC 6275) == Outdated reference: A later version (-02) exists of draft-ernst-generic-goals-and-benefits-01 -- Possible downref: Normative reference to a draft: ref. '6' == Outdated reference: A later version (-05) exists of draft-montavont-mobileip-multihoming-pb-statement-03 -- Possible downref: Normative reference to a draft: ref. '7' -- Possible downref: Non-RFC (?) normative reference: ref. '8' ** Obsolete normative reference: RFC 3484 (ref. '9') (Obsoleted by RFC 6724) -- No information found for draft-montavont-mobileip-mmi - is the name correct? -- Possible downref: Normative reference to a draft: ref. '10' ** Obsolete normative reference: RFC 2461 (ref. '11') (Obsoleted by RFC 4861) == Outdated reference: A later version (-07) exists of draft-ietf-ipv6-router-selection-06 -- Possible downref: Normative reference to a draft: ref. '13' -- Possible downref: Normative reference to a draft: ref. '14' -- Possible downref: Normative reference to a draft: ref. '15' -- No information found for draft-koh-mip6-nemo-dhap - is the name correct? -- Possible downref: Normative reference to a draft: ref. '16' ** Downref: Normative reference to an Informational RFC: RFC 3769 (ref. '17') == Outdated reference: A later version (-02) exists of draft-droms-nemo-dhcpv6-pd-01 -- Possible downref: Normative reference to a draft: ref. '18' == Outdated reference: A later version (-05) exists of draft-wakikawa-mobileip-multiplecoa-04 -- Possible downref: Normative reference to a draft: ref. '19' == Outdated reference: A later version (-02) exists of draft-kumazawa-nemo-tbdnd-01 -- Possible downref: Normative reference to a draft: ref. '20' -- Possible downref: Normative reference to a draft: ref. '21' Summary: 16 errors (**), 0 flaws (~~), 12 warnings (==), 21 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 NEMO Working Group C. Ng 2 Internet-Draft Panasonic Singapore Labs 3 Expires: August 25, 2005 E. Paik 4 KT 5 T. Ernst 6 WIDE at Keio University 7 February 21, 2005 9 Analysis of Multihoming in Network Mobility Support 10 draft-ietf-nemo-multihoming-issues-02 12 Status of this Memo 14 This document is an Internet-Draft and is subject to all provisions 15 of Section 3 of RFC 3667. By submitting this Internet-Draft, each 16 author represents that any applicable patent or other IPR claims of 17 which he or she is aware have been or will be disclosed, and any of 18 which he or she become aware will be disclosed, in accordance with 19 RFC 3668. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as 24 Internet-Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on August 25, 2005. 39 Copyright Notice 41 Copyright (C) The Internet Society (2005). 43 Abstract 45 This document is an analysis of multihoming in the context of network 46 mobility (NEMO). As there are many situations in which mobile 47 networks may be multihomed, a taxonomy is proposed to classify the 48 possible configurations. We also describe possible deployment 49 scenarios and we attempt to identify issues that arise when mobile 50 networks are multihomed while mobility supports is taken care by NEMO 51 Basic Support. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 2. Classification . . . . . . . . . . . . . . . . . . . . . . . . 6 58 2.1 (1,1,1): Single MR, Single HA, Single MNP . . . . . . . . 7 59 2.2 (1,1,n): Single MR, Single HA, Multiple MNPs . . . . . . . 7 60 2.3 (1,n,1): Single MR, Multiple HAs, Single MNP . . . . . . . 8 61 2.4 (1,n,n): Single MR, Multiple HAs, Multiple MNPs . . . . . 8 62 2.5 (n,1,1): Multiple MRs, Single HA, Single MNP . . . . . . . 9 63 2.6 (n,1,n): Multiple MRs, Single HA, Multiple MNPs . . . . . 9 64 2.7 (n,n,1): Multiple MRs, Multiple HAs, Single MNP . . . . . 10 65 2.8 (n,n,n): Multiple MRs, Multiple HAs, Multiple MNPs . . . . 10 67 3. Deployment Scenarios and Prerequisites . . . . . . . . . . . . 12 68 3.1 Deployment Scenarios . . . . . . . . . . . . . . . . . . . 12 69 3.2 Prerequisites . . . . . . . . . . . . . . . . . . . . . . 13 71 4. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 15 72 4.1 Path Survival . . . . . . . . . . . . . . . . . . . . . . 15 73 4.2 Path Selection . . . . . . . . . . . . . . . . . . . . . . 15 74 4.3 Ingress Filtering . . . . . . . . . . . . . . . . . . . . 16 75 4.4 Failure Detection . . . . . . . . . . . . . . . . . . . . 18 76 4.5 Media Detection . . . . . . . . . . . . . . . . . . . . . 19 77 4.6 HA Synchronization . . . . . . . . . . . . . . . . . . . . 20 78 4.7 MR Synchronization . . . . . . . . . . . . . . . . . . . . 20 79 4.8 Prefix Delegation . . . . . . . . . . . . . . . . . . . . 21 80 4.9 Multiple Bindings/Registrations . . . . . . . . . . . . . 21 81 4.10 Source Address Selection . . . . . . . . . . . . . . . . . 21 82 4.11 Impact on the Routing Infrastructure . . . . . . . . . . . 22 83 4.12 Nested Mobile Networks . . . . . . . . . . . . . . . . . . 22 84 4.13 Split Mobile Networks . . . . . . . . . . . . . . . . . . 22 86 5. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 23 88 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24 90 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 26 94 A. Alternative Classifications Approach . . . . . . . . . . . . . 27 95 A.1 Ownership-Oriented Approach . . . . . . . . . . . . . . . 27 96 A.1.1 ISP Model . . . . . . . . . . . . . . . . . . . . . . 27 97 A.1.2 Subscriber/Provider Model . . . . . . . . . . . . . . 28 98 A.2 Problem-Oriented Approach . . . . . . . . . . . . . . . . 30 100 B. Nested Tunneling for Fault Tolerance . . . . . . . . . . . . . 31 101 B.1 Detecting Presence of Alternate Routes . . . . . . . . . . 31 102 B.2 Re-Establishment of Bi-Directional Tunnels . . . . . . . . 31 103 B.2.1 Using Alternate Egress Interface . . . . . . . . . . . 32 104 B.2.2 Using Alternate Mobile Router . . . . . . . . . . . . 32 105 B.3 To Avoid Tunneling Loop . . . . . . . . . . . . . . . . . 33 107 C. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 34 109 Intellectual Property and Copyright Statements . . . . . . . . 36 111 1. Introduction 113 The design goals and objectives of Network Mobility Support (NEMO) 114 are identified in [1] while the terminology is being described in [2] 115 and [3]. NEMO Basic Support [4] is the solution proposed by the NEMO 116 Working Group to provide continuous Internet connectivity to nodes 117 located in a mobile network. This solutions basically solves the 118 problem by setting up bi-directional tunnels between the mobile 119 routers (MRs) connecting the mobile network to the Internet and their 120 respective Home Agents (HAs), much how this is done in Mobile IPv6 121 [5], the solution for host mobility. NEMO Basic Support is 122 transparent to nodes located behind the mobile router (i.e. the 123 mobile network nodes, or MNNs) and as such doesn't require MNNs to 124 take any action in the mobility management. 126 However, mobile networks are typically connected by means of wireless 127 and thus less reliable links; there could also be many nodes behind 128 the MR. A loss of connectivity or a failure to connect to the 129 Internet has thus a more significant impact than for a single node. 130 Real-life scenarios as illustrated in [6] demonstrate that providing 131 a permanent access to mobile networks such as vehicles typically 132 require the use of several interfaces and technologies since the 133 mobile network may be moving in distant geographical locations where 134 different access technologies are provided and governed by distinct 135 access control policies. 137 As specified by R.12 in section 5 of [1], the NEMO WG must ensure 138 that NEMO Basic Support does not prevent mobile networks to be 139 multihomed, i.e. when there is more than one point of attachment 140 between the mobile network and the Internet (see definitions in 141 [3]).. This arises either when a MR has multiple egress interfaces. 142 Using NEMO Basic Support, this translates into having multiple 143 bi-directional tunnels between the mobile network and its HA(s), and 144 may result into multiple MNPs being advertised to the MNNs. However, 145 NEMO Basic Support does not specify any particular mechanism to 146 manage multiple bi-directional tunnels. The objective of this memo 147 is thus three-folds: 149 o to identify which multihoming configurations are useful, 151 o to identify issues that may prevent useful multihomed 152 configurations to be supported under the operation of NEMO Basic 153 Support. It doesn't mean that those not supported will not work 154 with NEMO Basic Support, just that it is up to the implementors to 155 make it work (hopefully issues discussed in this memo will be 156 helpful to these implementors). 158 For doing so, a taxonomy to classify the possible multihomed 159 configurations is described in Section 2. Deployment scenarios, 160 their benefits, and requirements to meet these benefits are 161 illustrated in Section 3. Following this, we study the general 162 issues in Section 4, and we conclude with an evaluation of NEMO Basic 163 Support for multihomed configurations. Alternative classifications 164 are outlined in the Appendix. 166 In order to understand this memo, the reader is expected to be 167 familiar with the above cited documents, i.e. with the NEMO 168 terminology as defined in [2] (section 3) and [3], Goals and Benefits 169 of Multihoming [6], Goals and Requirements of Network Mobility 170 Support [1], and the NEMO Basic Support specification [4]. Goals and 171 benefits for multihoming as discussed in [6] are applicable to fixed 172 nodes, mobile nodes, fixed networks and mobile networks. 174 This document considers multihoming only from the IPv6 point of view. 176 2. Classification 178 Various discussions on the topic of multihoming issues in NEMO have 179 been carried out on the mailing list and at IETF meetings. As there 180 are several configurations in which mobile networks are multihomed, 181 there is a need to classify them into a clearly defined taxonomy. 182 This can be done in various ways. Three approaches have been 183 proposed on the NEMO mailing list. These are, namely, (i) the 184 Configuration-Oriented Approach, (ii) the Ownership-Oriented 185 Approach, and (iii) the Problem-Oriented Approach. As the WG 186 consensus seems to have converged to the Configuration-Oriented 187 Approach, we only describe this approach here. The other two 188 approaches are outlined in Appendix A.1 and Appendix A.2. 190 Multihomed configurations can be classified depending on how many 191 mobile routers are present, how many egress interfaces, Care-of 192 Address (CoA) and Home Addresses (HoA) the mobile routers have, how 193 many prefixes (MNPs) are advertised to the mobile network nodes, etc. 194 For doing so, we use three key parameters differentiating different 195 multihomed configurations. With these parameters, we can refer to 196 each configuration by the 3-tuple (x,y,z), where 'x', 'y', 'z' are 197 defined as follows: 199 o 'x' indicates the number of MRs where: 201 x=1 implies a mobile network has only a single MR, presumably 202 multihomed. 204 x=N implies a mobile network has more than one MR. 206 o 'y' indicates the number of HAs associated with the entire mobile 207 network, where: 209 y=1 implies that a single HA is assigned to the mobile network. 211 y=N implies that multiple HAs (possibly in different 212 administrative domains) are assigned to the mobile network. 214 o 'z' indicates the number of MNPs announced to MNNs, where: 216 z=1 implies that a single MNP is advertised to the MNNs. 218 z=N implies that multiple MNPs are advertised to the MNNs. 220 It can be seen that the above three parameters are fairly orthogonal 221 to one another. Thus different values of 'x', 'y' and 'z' give rise 222 to different combinations of the 3-tuple (x,y,z). As described in 223 the sub-sections below, a total of 8 possible configurations can be 224 identified. 226 One thing the reader has to keep in mind is that in each of the 227 following 8 cases, the MR may be multihomed if either (i) multiple 228 prefixes are advertised (on the home link, or on the visited link), 229 or (ii) the MR is equipped with multiple interfaces. In such a case, 230 the MR would have a combination of Home Address / Care-of Address 231 pairs. Issues pertaining to a multihomed MR are also addressed in 232 the companion document [7]. 234 A simplified analysis of multihoming configuration in NEMO Basic 235 Support using the same classification can be found in [8]. 237 2.1 (1,1,1): Single MR, Single HA, Single MNP 239 The (1,1,1) mobile network has only one MR advertising a single MNP. 240 In addition, the MR is associated with only one HA at any one time. 241 A bi-directional tunnel may be established between each pair of Home 242 Address / Care-of address if the MR is itself multihomed. 244 The MR may be multihomed and MNNs are (usually) not multihomed since 245 they would configure a single address on the single MNP announced on 246 the link they are attached to. 248 _____ 249 _ p _ | | 250 |_|-|<-_ |-|_|-| |-| _ 251 _ |-|_|=| |_____| | _ |-|_| 252 |_|-| | |-|_|-| 253 | 254 MNNs MR AR Internet AR HA 256 Figure 1: (1,1,1): 1 MR, 1 HA, 1 MNP 258 2.2 (1,1,n): Single MR, Single HA, Multiple MNPs 260 The (1,1,n) mobile network has only one MR, which is associated to 261 only one HA at any one time. However, two or more MNPs are 262 advertised to the mobile network nodes. 264 The MR may be itself multihomed, and MNNs are multihomed if several 265 MNPs are advertised on the link they are attached to. If that 266 conditions holds, MNNs would configure an address with each MNP 267 announced on the link. 269 _____ 270 _ p1,p2 _ | | 271 |_|-|<-_ |-|_|-| |-| _ 272 _ |-|_|=| |_____| | _ |-|_| 273 |_|-| | |-|_|-| 274 | 275 MNNs MR AR Internet AR HA 277 Figure 2: (1,1,n): 1 MR, 1 HA, multiple MNPs 279 2.3 (1,n,1): Single MR, Multiple HAs, Single MNP 281 The (1,n,1) mobile network has only one MR advertising a single MNP. 282 The MR, however, is associated to multiple HAs, possibly one HA per 283 Home Address, or one HA per egress interface. 285 The MR may be multihomed whereas MNNs are (usually) not multihomed 286 since they would configure a single address on the single MNP 287 announced on the link they are attached to. 289 AR HA2 290 _ | 291 |-|_|-| _ 292 _____ | |-|_| 293 _ p _ | |-| 294 |_|-|<-_ |-|_|-| | 295 _ |-|_|=| |_____|-| _ 296 |_|-| | | _ |-|_| 297 |-|_|-| 298 | 299 MNNs MR AR Internet AR HA1 301 Figure 3: (1,n,1): 1 MR, multiple HAs, 1 MNP 303 2.4 (1,n,n): Single MR, Multiple HAs, Multiple MNPs 305 The (1,n,n) mobile network has only one MR. However, the MR is 306 associated with multiple HAs, possibly one per Home Address (or one 307 HA per egress interface), and the MR advertises more than one MNP on 308 its ingress interfaces. No assumption is made on whether or not the 309 HAs belongs to the same administrative domain. 311 The MR may be multihomed, and the MNNs are generally multihomed since 312 they would configure an address on each MNP announced on the link 313 they are attached to. 315 AR HA2 316 _ | _ 317 _____ |-|_|-|-|_| 318 _ p1,p2 _ | |-| | 319 |_|-|<-_ |-|_|-| | _ 320 _ |-|_|=| |_____|-| _ |-|_| 321 |_|-| | |-|_|-| 322 | | 323 MNNs MR AR Internet AR HA1 325 Figure 4: (1,n,n): 1 MR, multiple HAs, multiple MNPs 327 2.5 (n,1,1): Multiple MRs, Single HA, Single MNP 329 The (n,1,1) mobile network has more than one MR advertising global 330 routes. These MRs, however, advertise the same MNP and are 331 associated with the same HA. 333 Each MR may be itself multihomed, whereas MNNs are (usually) not 334 multihomed since they would configure a single address on the single 335 MNP announced on the link they are attached to. 337 MR2 338 p<-_ | 339 _ |-|_|-| _____ 340 |_|-| |-| | 341 _ | | |-| _ 342 |_|-| _ |-|_____| | _ |-|_| 343 |-|_|-| |-|_|-| 344 p<- | | 345 MNNs MR1 Internet AR HA 347 Figure 5: (n,1,1): Multiple MRs, 1 HA, 1 MNP 349 2.6 (n,1,n): Multiple MRs, Single HA, Multiple MNPs 351 The (n,1,n) mobile network has more than one MR; multiple global 352 routes and different MNPs are advertised by the MRs. 354 Each MR may be itself multihomed, and MNNs are generally multihomed 355 since they would configure an address on each MNP announced on the 356 link they are attached to. 358 MR2 359 p2<-_ | 360 _ |-|_|-| _____ 361 |_|-| |-| | 362 _ | | |-| _ 363 |_|-| _ |-|_____| | _ |-|_| 364 |-|_|-| |-|_|-| 365 p1<- | | 366 MNNs MR1 Internet AR HA 368 Figure 6: (n,1,n): Multiple MRs, 1 HA, multiple MNPs 370 2.7 (n,n,1): Multiple MRs, Multiple HAs, Single MNP 372 The (n,n,1) mobile network has more than one MR advertising multiple 373 global routes. The mobile network is associated with multiple HAs at 374 any one time. No assumptions are made on whether or not the HAs 375 belongs to the same administrative domain. However, the MRs 376 advertises the same MNP. 378 Each MR may be itself multihomed whereas MNNs are (usually) not 379 multihomed since they would configure a single address on the single 380 MNP announced on the link they are attached to. 382 MR2 AR HA2 383 p _ | 384 <-_ | |-|_|-| _ 385 _ |-|_|-| _____ | |-|_| 386 |_|-| |-| |-| 387 _ | | | 388 |_|-| _ |-|_____|-| _ 389 |-|_|-| | _ |-|_| 390 <- | |-|_|-| 391 p | 392 MNNs MR1 Internet AR HA1 394 Figure 7: (n,n,1): Multiple MRs, Multiple HAs, 1 MNP 396 2.8 (n,n,n): Multiple MRs, Multiple HAs, Multiple MNPs 398 The (n,n,n) mobile network has multiple MRs advertising different 399 global routes and different MNPs. The mobile network is associated 400 with more than one HA at any one time. No assumptions is made on 401 whether or not the HA belongs to the same administrative domain. 403 Each MR may be itself multihomed and MNNs are generally multihomed 404 since they would configure an address on each MNP announced on the 405 link they are attached to 407 MR2 AR HA2 408 p2 _ | 409 <-_ | |-|_|-| _ 410 _ |-|_|-| _____ | |-|_| 411 |_|-| |-| |-| 412 _ | | | 413 |_|-| _ |-|_____|-| _ 414 |-|_|-| | _ |-|_| 415 <- | |-|_|-| 416 p1 | 417 MNNs MR1 Internet AR HA1 419 Figure 8: (n,n,n): Multiple MRs, HAs, and MNPs 421 3. Deployment Scenarios and Prerequisites 423 The following generic goals and benefits of multihoming are discussed 424 in a companion document [6]: 426 1. Permanent and Ubiquitous Access 428 2. Redundancy/Fault-Recovery 430 3. Load Sharing 432 4. Load Balancing 434 5. Preference Settings 436 These benefits are now illustrated from a NEMO perspective with a 437 typical instance scenario for each case in the taxonomy. We then 438 discuss the prerequisites to fulfill these. 440 3.1 Deployment Scenarios 442 x=1: Multihomed mobile network with a single MR 444 o Example: an MR with dual/multiple access interfaces (e.g. 445 802.11 and GPRS capabilities). This is a S/P-(1,1,*) if both 446 accesses are subscribed to the same ISP. If the two accesses 447 are offered by independent ISPs, this is a S/mP-(1,n,n) [for 448 the meaning of this abbreviation, see Appendix A.1]. 450 Benefits: Ubiquity, Redundancy/Fault-Recovery, Load Sharing, 451 Preference Settings 453 x=N: Multihomed mobile networks with multiple MRs 455 o Example 1: a train with one MR in each car, all served by the 456 same HA, thus a (n,1,*). Alternatively, the train company 457 might be forced to use different ISPs when the train go to 458 different locations, thus it is a (n,n,n). 460 Benefits: Load Sharing, Redundancy/Fault-Recovery, Ubiquity 462 o Example 2: W-PAN with a GPRS_enabled phone and a WiFi-enabled 463 PDA. This is a S/mP-(n,n,n) if the two access technologies are 464 subscribed separately. 466 Benefits: Ubiquity, Redundancy/Fault-Recovery, Preference 467 Settings 469 y=1: Multihomed mobile networks with a single HA 471 o Most single ISP cases in above examples. 473 y=N: Multihomed mobile networks with multiple HAs 475 o Most multiple ISP cases in above examples. 477 o Example: a transatlantic flight with a HA in each continent. 478 This is a (1,n,1) network if there is only one MR. 480 Benefits: Ubiquity, Preferences (reduced delay, shortest path) 482 z=1: Multihomed mobile networks with a single MNP 484 o Most single ISP cases in above examples. 486 z=N: Multihomed mobile networks with multiple MNPs 488 o Most multiple ISP cases in above examples. 490 o Example: a car with a prefix taken from home (personal traffic 491 transit on this prefix and is paid by the owner) and one that 492 belongs to the car manufacturer (maintenance traffic is paid by 493 the car-manufacturer). This will typically be a (1,1,n) or a 494 (1,n,n,). 496 Benefits: Preference Settings 498 3.2 Prerequisites 500 In this section, we try to define the requirements in order to 501 fulfill the expected multihoming benefits as detailed in [6]. 503 At least one bi-directional tunnel must be available at any point in 504 time between the mobile network and the fixed network to meet all 505 expectations. But for most goals to be effective, multiple tunnels 506 must be maintained simultaneously: 508 o Permanent and Ubiquitous Access: 510 At least one bi-directional tunnel must be available at any point 511 in time. 513 o Redundancy and Fault-Recovery: 515 Both the inbound and outbound traffic must be transmitted or 516 diverted over another bi-directional tunnel once a bi-directional 517 tunnel is broken or disrupted. 519 o Load Sharing and Load Balancing: 521 Multiple tunnels must be maintained simultaneously. 523 o Preference Settings: 525 Implicitly, multiple tunnels must be maintained simultaneously if 526 preferences are set for deciding which of the available 527 bi-directional tunnels should be used. A mechanism must be 528 provided to the user/application about the availability of 529 multiple bi-direction tunnels, and perhaps also to set the 530 preference. The preference may reside in the mobile router or 531 mobile network nodes (using [9] for instance). 533 4. Problem Statement 535 In order to meet the multihoming benefits, multiple tunnels may be 536 maintained simultaneously (e.g. load balancing, load sharing) or not 537 (e.g. redundancy) between the mobile network and the fixed network. 538 In some cases, it may be necessary to divert packets from a (perhaps 539 failed) bi-directional tunnel to an alternative (perhaps newly 540 established) bi-directional tunnel (i.e. for matters of fault 541 recovery, preferences), or to split traffic between multiple tunnel 542 (load sharing, load balancing). 544 For doing so, the issues discussed below must be addressed, 545 preferably dynamically. For each issue, we also investigate 546 potential ways to solve the problem and recommend which IETF WG(s) 547 should look into these issues. 549 4.1 Path Survival 551 Internet connectivity is guaranteed for all MNNs as long as at least 552 one bi-directional tunnel is maintained between the mobile network 553 and the fixed Internet. When an alternative tunnel must be found to 554 substitute for the failed one, the loss of one tunnel to the Internet 555 may result in broken sessions. In this case, new transport sessions 556 will have to be established over the alternate tunnel if no mechanism 557 is provided to make this change transparent at layers above layer 3. 559 The tunnel can be changed transparently to the MNNs if mechanisms 560 such as MMI [10] are brought to the MR. 562 For instance, in the (1,1,1) case specifically, packets are always 563 transmitted to/from the same MR's ingress interface, i.e. 564 independently of MR's links connectivity status. 566 This is a general problem faced by any node with multiple egress 567 paths. It is recommended that this issue be considered by other WGs 568 (such as IPv6, Multi6), and NEMO WG to contribute any NEMO specific 569 requirements. 571 4.2 Path Selection 573 When multiple bi-directional tunnels are available and possibly used 574 simultaneously, the mode of operation may be either primary-secondary 575 (one tunnel is precedent over the others and used as the default 576 tunnel, while the other serves as a back-up) or peer-to-peer (no 577 tunnel has precedence over one another, they are used with the same 578 priority). This questions which bi-directional tunnel would be 579 selected, and based on which parameter (e.g. type of flow that goes 580 into/out of the mobile network). 582 A dynamic path selection mechanism is thus needed so that this path 583 could be selected by: 585 o The HA: it should be able to select the path based on some 586 information recorded in the binding cache. 588 o The MR: it should be able to select the path based on router 589 advertisements received on both its egress interfaces or on its 590 ingress interfaces for the (n,*,*) case. 592 o The MNN: it should be able to select the path based on "Default 593 Router Selection" (see [Section 6.3.6. Default Router Selection] 594 [11]) in the (n,*,*) case or based on "Source Address Selection" 595 in the (*,*,n) cases (see Section 4.10 of the present memo). 597 o The user or the application: e.g. in case where a user wants to 598 select a particular access technology among the available 599 technologies for reasons of cost or data rate. 601 o A combination of any of the above: a hybrid mechanism should be 602 also available, e.g. one in which the HA, the MR, and/or the MNNs 603 are coordinated to select the path. 605 This is a general problem faced by any node with multiple egress 606 paths. It is recommended that this issue be considered by other WGs 607 (such as IPv6, Multi6), and NEMO WG to contribute any NEMO specific 608 requirements. 610 4.3 Ingress Filtering 612 Ingress filtering mechanisms may drop the outgoing packets when 613 multiple bi-directional tunnels end up at different HAs. This could 614 particularly occur if different MNPs are handled by different home 615 agents. If packet with a source address configured from a specific 616 MNP is tunnelled to a home agent that does not handle that specific 617 MNP the packet may be discarded due to ingress filtering (either by 618 the home agent or by a border gateway in the home network). 620 As an example of how this could happen, consider the deployment 621 scenario illustrated in Figure 9. In Figure 9, the mobile network 622 has two mobile routers MR1 and MR2, with home agents HA1 and HA2 623 respectively. Two bi-directional tunnels are established are 624 established between the two pairs. Each mobile router advertises a 625 different MNP (P1 and P2). MNP P1 is registered to HA1, and MNP P2 626 is registered to HA2. Thus, MNNs should be free to auto-configure 627 their addresses on any of P1 or P2. Ingress filtering could thus 628 happen in two cases: 630 o If the two tunnels are available, MNN cannot forward packet with 631 source address equals P1.MNN to MR2. This would cause ingress 632 filtering at HA2 to occur (or even at MR2). This is contrary to 633 normal Neighbor Discovery [11] practice that an IPv6 node is free 634 to choose any router as its default router regardless of the 635 prefix it chooses to use. A simple solution is to require all 636 MNNs to set their default router to the MR that advertises the MNP 637 the MNNs configured their addresses from. If such requirement is 638 not placed on mobile network nodes, then a multihoming solution 639 for mobile networks must address this problem. For a possible 640 approach, see [12]. However, this is not enough to maintain 641 connectivity if a tunnel fails (see Section 4.1 for a discussion 642 of this issue). 644 o If the tunnel to HA1 is broken, packets would be sent through the 645 tunnel to HA1 are diverted through the tunnel to HA2. If HA2 (or 646 some border gateway in the domain of HA2) performs ingress 647 filtering, packets with source address configured from MNP P1 may 648 be discarded. It should be noted that this problem may be faced 649 by any (*,n,n) mobile network, even if MR1 and MR2 are in fact the 650 same entity in Figure 9. 652 To avoid ingress filtering mechanisms dropping packets in such 653 situations, MR(s) can stop advertising P1. This would prevent MNNs 654 from using the address auto-configured on this prefix. However, such 655 a method suffers from the following two limitations: 657 o Switching addresses is time consuming since nodes have to wait for 658 addresses to get deprecated [9]. 660 o Switching addresses force transport sessions without multihoming 661 capabilities (such as TCP) to terminate, and be re-established 662 using the alternative source address. Transport sessions with 663 multihoming capabilities (such as SCTP) may be able to continue 664 without disruption (see also Section 4.1) 666 Although one way to avoid the long wait for address deprecation by 667 sending a router advertisement with zero Lifetime, the 668 termination/disruption of transport sessions may render this solution 669 unattractive. It is possible to overcome these limitations by using 670 nested tunnels. Appendix B describes one such approach. 672 Prefix: P1 +-----+ +----+ +----------+ +-----+ 673 +--| MR1 |--| AR |--| |---| HA1 | 674 | +-----+ +----+ | | +-----+ 675 IP: +-----+ | | | Prefix: P1 676 P1.MNN or | MNN |--+ | Internet | 677 P2.MNN +-----+ | | | Prefix: P2 678 | +-----+ +----+ | | +-----+ 679 +--| MR2 |--| AR |--| |---| HA2 | 680 Prefix: P2 +-----+ +----+ +----------+ +-----+ 682 Figure 9: An (n,n,n) mobile network 684 It is recommended that the NEMO specific issue of ingress filtering 685 be tackled by the NEMO WG, either through the standardization of the 686 technique described in Appendix B, or by specifying a statement to 687 define the mobile router behavior with respect to fault recovery in 688 an (*,n,n) mobile network. 690 4.4 Failure Detection 692 It is expected for faults to occur more readily at the edge of the 693 network (i.e. the mobile nodes), due to the use of wireless 694 connections. Efficient fault detection mechanisms are necessary to 695 recover in timely fashion. In order for fault recovery to work, the 696 MRs and HAs must first possess a means to detect failures: 698 o On the MR's side, the MR can also rely on router advertisements 699 from access routers, or other layer-2 trigger mechanisms to detect 700 faults, e.g. [13] or [14]. (For a related issue, see 701 Section 4.5.) 703 o On the HA's side, it is more difficult for HAs to detect tunnel 704 failures. For an ISP deployment model, the HAs and MRs can use 705 proprietary methods (such as constant transmission of heartbeat 706 signals) to detect failures and check tunnel liveness. In the S/P 707 model (see Appendix A.2), a lack of standardized "tunnel liveness" 708 protocol means that it is harder to detect failures. 710 A possible method is for the MRs to send binding updates more 711 regularly with shorter Lifetime values. Similarly, HAs can return 712 binding acknowledgment messages with smaller Lifetime values, thus 713 forcing the MRs to send binding updates more frequently. These 714 binding updates can be used to emulate "tunnel heartbeats". This 715 however may lead to more traffic and processing overhead, since 716 binding updates sent to HAs must be protected (and possibly 717 encrypted) with security associations. 719 There are other failure modes to consider as well, such as failure at 720 home agent, failure at access routers, or in general failure of a 721 link or node along the path from the mobile router to the home agent. 722 By the nature of the routing infrastructure, failure of intermediate 723 nodes or links are recovered by the the routing infrastructure by 724 choosing a different route. For those failures that can't be 725 receovered (such a failure of the access router), a heartbeat 726 protocol or the use of small-lifetime binding updates described above 727 can also be used to detect tunnel failures. 729 This is a general problem faced by all nodes communicating with a 730 peer. It is recommended that NEMO WG adopts any failure detection 731 mechansim standardized in the IETF, and, should the need arise,adapts 732 such mechanism specifically for detecting tunnel failures. 734 4.5 Media Detection 736 In order to achieve benefits such as ubiquity or fault recovery, it 737 is necessary for mobile router to detect the availability of network 738 media. This may be achieved using layer 2 triggers [13], or other 739 mechanism developed/recommended by the Detecting Network Attachment 740 (DNA) Working Group. 742 This is related to Section 4.4, since the ability to detect media 743 availability would often implies the ability to detect media 744 in-availability. 746 4.6 HA Synchronization 748 In the (*,n,1) mobile networks, a single MNP would be registered at 749 different HAs. This gives rise to the following issues: 751 o Only one HA may actively advertise a route to the MNP. 753 o Multiple HAs at different domains may advertise a route to the 754 same MNP 756 This may pose a problem in the routing infrastructure as a whole. 757 The implications of this aspect needs further exploration. Certain 758 level of HA co-ordination may be required. A possible approach is to 759 adopt a HA synchronization mechanism such as that described in [15] 760 and [16]. Such synchronization might also be necessary in a (*,n,*) 761 mobile network, when a MR sends binding update messages to only one 762 HA (instead of all HAs). In such cases, the binding update 763 information might have to be synchronized betweeen HAs. The mode of 764 synchoronization may be either primary-secondary or peer-to-peer. 765 See also Section 4.7. 767 This problem is general in the sense that Mobile IPv6 will have to 768 consider similar issues. It is recommended that the issue be looked 769 at in one of the Mobile IP WG, and NEMO WG to contribute any NEMO 770 specific requirements. 772 4.7 MR Synchronization 774 In the (n,*,*) mobile network, different MRs may need to be 775 synchronized in order to take common decisions. The mode of 776 synchoronization may be either primary-secondary or peer-to-peer. 777 This may include: 779 o In the (n,*,1) case, advertising the same MNP (see also "prefix 780 delegation" in Section 4.8). 782 o In the (n,*,n) case, a MR relaying the advertisement of the MNP 783 from another failed MR. 785 o In the (n,*,*) cases, relaying between MRs everything that needs 786 to be relayed, such as data packets, creating a tunnel from the 787 ingress interface, etc. 789 This problem is general in the sense that a multi-router site would 790 require the same level of router synchronization as well. It is 791 recommended that the issue be looked at in IPv6 or Multi6 WG, and 792 NEMO WG to contribute any NEMO specific requirements. 794 4.8 Prefix Delegation 796 In the (*,*,1) mobile network, the same MNP must be advertised to the 797 MNNs through different paths. This questions how to perform prefix 798 delegation: 800 o For the (*,n,1) mobile network, how multiple HAs would delegate 801 the same MNP to the mobile network. For doing so, the HAs may be 802 somehow configured to advertise the same MNP. (see also "HA 803 Synchronization" in Section 4.6). 805 o For the (n,*,n) mobile network, how multiple mobile routers would 806 be synchronized to advertise the same MNP down the NEMO-link. For 807 doing so, the MRs may be somehow configured to advertise the same 808 MNP (see also "MR Synchronization" in Section 4.7). 810 This could be configured manually, or dynamically. Alternatively, 811 prefix delegation mechanisms [17][18] could be used to ensure all 812 routers advertise the same MNP. 814 Prefix delegation is currently being explored in the NEMO WG. Should 815 the WG decides to standardize a prefix delegation mechanism, the WG 816 should also consider its application to a multihomed mobile network. 818 4.9 Multiple Bindings/Registrations 820 When a MR is configured with multiple Care-of Addresses, it is often 821 necessary for it to bind these Care-of Addresses to the same MNP. 823 This is a generic issue, since Mobile IPv6 nodes face a similar 824 problem if they wish to bind multiple Care-of Addresses to the same 825 Home Address". This is better discussed in [7]. It is sufficient to 826 note that solutions like [19] can solve this. 828 4.10 Source Address Selection 830 In the (*,*,n) mobile networks, MNNs would be configured with 831 multiple addresses. Source address selection mechanisms are needed 832 to decide which address to choose from. 834 It may be desirable for MNN to be able to acquire "preference" 835 information on each MNP from the MRs. This allows default address 836 selection mechanism such as that specified in [9] to be used. 837 Further exploration on setting such "preference" information in 838 Router Advertisement based on performance of the bi-directional 839 tunnel might prove to be useful. 841 This is a general issue faced by any node when offered multiple 842 prefixes. It is recommended that the issue be examined by other WG 843 (such as IPv6). 845 4.11 Impact on the Routing Infrastructure 847 In the (1,n,1) case with HAs located in distinct ISPs/ASs, multiple 848 routes directed to the mobile network may be advertised in the 849 Internet. Although this may provide shorter paths, it would add a 850 burden to routing tables as multiple routes to the same prefix are 851 injected into the routing infrastructure. 853 Such issues are investigated in the MULTI6 working group at the IETF, 854 and the NEMO WG should adopt solutions designed there whenever 855 appropriate. 857 4.12 Nested Mobile Networks 859 When a multihomed mobile network is nested within another mobile 860 network, it can result in very complex topologies. For instance, a 861 nested mobile network may be attached two different root-MRs, thus 862 the aggregated network no longer forms a simple tree structure. As 863 such, a solution to prevent an infinite loop of multiple mobile 864 routers must be provided. 866 This problem is specific to NEMO WG. It is recommended that the NEMO 867 WG standardizes a solution to solve this problem (such as the use of 868 a tree-spanning algorithm). 870 4.13 Split Mobile Networks 872 When a (n,*,1) network splits, (i.e. the two MRs split themselves 873 up), the only available MNP will then be registered by two different 874 MRs on different links. This cannot be allowed, as the HA has no way 875 to know which node with an address configured from that MNP is 876 attached to which MR. Some mechanism must be present for the MNP to 877 either be forcibly removed from one (or all) MRs, or the implementors 878 must not allow a (n,*,1) network to split. 880 A possible approach to solving this problem is described in [20]. 882 This problem is specific to NEMO WG. It is recommended that the NEMO 883 WG standardizes a solution to solve this problem, or specifies that 884 the split of a (n,*,1) network cannot be allowed without a router 885 renumbering. 887 5. Conclusion 889 This document is an analysis of multihoming in the context of network 890 mobility. The purpose of this memo is to investigate issues related 891 to such a bi-directional tunneling mechanism when mobile networks are 892 multihomed. 894 Several issues that might impact the deployment of NEMO with 895 multihoming capabilities were identified in Section 4. They include 896 : 898 1. Path Survival 900 2. Path Availability 902 3. Ingress Filtering 904 4. Failure Detection 906 5. Media Detection 908 6. HA Synchronization 910 7. MR Synchronization 912 8. Prefix Delegation 914 9. Multiple Binding/Registrations 916 10. Source Address Selection 918 11. Imapct on the Routing Infrastructure 920 12. Nested Mobile Networks 922 13. Split Mobile Networks. 924 This study is a work in progress and need to be improved by a 925 thorough study of each individual issues. Particularly, this memo 926 should be completed by a thorough threat analysis of multihoming 927 configurations of mobile network. We will add security threat issues 928 here as and when they are encountered, such as those described in 929 [21]. We also encourage interested people to contribute to this 930 part. 932 6. Acknowledgments 934 The authors would like to thank people who have given valuable 935 comments on various multihoming issues on the mailing list, and also 936 those who have suggested directions in the 56th - 61st IETF Meetings. 937 Sincere gratitude is also extended to Marcelo Bagnulo Braun for his 938 extensive review and comments on the -00 version of this draft. The 939 initial evaluation of NEMO Basic Support is a contribution from 940 Julien Charbon. 942 7. References 944 [1] Ernst, T., "Network Mobility Support Goals and Requirements", 945 Internet-Draft draft-ietf-nemo-requirements-04, February 2005. 947 [2] Manner, J. and M. Kojo, "Mobility Related Terminology", 948 RFC 3753, June 2004. 950 [3] Ernst, T. and H. Lach, "Network Mobility Support Terminology", 951 Internet-Draft draft-ietf-nemo-terminology-03, February 2005. 953 [4] Devarapalli, V., Wakikawa, R., Petrescu, A. and P. Thubert, 954 "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, 955 January 2005. 957 [5] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in 958 IPv6", RFC 3775, June 2004. 960 [6] Ernst, T., Montavont, N. and R. Wakikawa, "Goals and Benefits 961 of Multihoming", 962 Internet-Draft draft-ernst-generic-goals-and-benefits-01, 963 February 2005. 965 [7] Montavont, N., Wakikawa, R. and T. Ernst, "Analysis of 966 Multihoming in Mobile IPv6", 967 Internet-Draft draft-montavont-mobileip-multihoming-pb-statement-03 968 , January 2005. 970 [8] Ernst, T. and J. Charbon, "Multihoming with NEMO Basic 971 Support", Proceedings First International Conference on Mobile 972 Computing and Ubiquitous Networking (ICMU), January 2004. 974 [9] Draves, R., "Default Address Selection for Internet Protocol 975 version 6 (IPv6)", RFC 3484, February 2003. 977 [10] Montavont, N., Noel, T. and M. Kassi-Lahlou, "MIPv6 for 978 Multiple Interfaces", 979 Internet-Draft draft-montavont-mobileip-mmi-00, July 2002. 981 [11] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery 982 for IP Version 6 (IPv6)", RFC 2461, December 1998. 984 [12] Draves, R. and D. Thaler, "Default Router Preferences and 985 More-Specific Routes", 986 Internet-Draft draft-ietf-ipv6-router-selection-06, October 987 2004. 989 [13] Yegin, A., "Link-layer Hints for Detecting Network 990 Attachments", Internet-Draft draft-yegin-dna-l2-hints-01, 991 February 2004. 993 [14] Yegin, A., "Supporting Optimized Handover for IP Mobility 994 -Requirements for Underlying Systems", 995 Internet-Draft draft-manyfolks-l2-mobilereq-02, July 2002. 997 [15] Wakikawa, R., Devarapalli, V. and P. Thubert, "Inter Home 998 Agents Protocol (HAHA)", 999 Internet-Draft draft-wakikawa-mip6-nemo-haha-01, February 2004. 1001 [16] Koh, B., Ng, C. and J. Hirano, "Dynamic Inter Home Agent 1002 Protocol", Internet-Draft draft-koh-mip6-nemo-dhap-00, July 1003 2004. 1005 [17] Miyakawa, S. and R. Droms, "Requirements for IPv6 Prefix 1006 Delegation", RFC 3769, June 2004. 1008 [18] Droms, R. and P. Thubert, "DHCPv6 Prefix Delegation for NEMO", 1009 Internet-Draft draft-droms-nemo-dhcpv6-pd-01, February 2004. 1011 [19] Wakikawa, R., Uehara, K., Ernst, T. and K. Nagami, "Multiple 1012 Care-of Addresses Registration", 1013 Internet-Draft draft-wakikawa-mobileip-multiplecoa-04, February 1014 2005. 1016 [20] Kumazawa, M., "Token based Duplicate Network Detection for 1017 split mobile network (Token based DND)", 1018 Internet-Draft draft-kumazawa-nemo-tbdnd-01, October 2004. 1020 [21] Choi, S., "Threat for Multi-homed Mobile Networks", 1021 Internet-Draft draft-cho-nemo-threat-multihoming-00, February 1022 2004. 1024 Authors' Addresses 1026 Chan-Wah Ng 1027 Panasonic Singapore Laboratories Pte Ltd 1028 Blk 1022 Tai Seng Ave #06-3530 1029 Tai Seng Industrial Estate 1030 Singapore 534415 1031 SG 1033 Phone: +65 65505420 1034 Email: cwng@psl.com.sg 1036 Eun Kyoung Paik 1037 KT 1038 Portable Internet Team, Convergence Lab., KT 1039 17 Woomyeon-dong, Seocho-gu 1040 Seoul 137-792 1041 Korea 1043 Phone: +82-2-526-5233 1044 Fax: +82-2-526-5200 1045 Email: euna@kt.co.kr 1046 URI: http://mmlab.snu.ac.kr/~eun/ 1048 Thierry Ernst 1049 WIDE at Keio University 1050 Jun Murai Lab., Keio University. 1051 K-square Town Campus, 1488-8 Ogura, Saiwa-Ku 1052 Kawasaki, Kanagawa 212-0054 1053 Japan 1055 Phone: +81-44-580-1600 1056 Fax: +81-44-580-1437 1057 Email: ernst@sfc.wide.ad.jp 1058 URI: http://www.sfc.wide.ad.jp/~ernst/ 1060 Appendix A. Alternative Classifications Approach 1062 A.1 Ownership-Oriented Approach 1064 An alternative approach to classifying multihomed mobile network is 1065 proposed by Erik Nordmark (Sun Microsystems) by breaking the 1066 classification of multihomed network based on ownership. This is 1067 more of a tree-like top-down classification. Starting from the 1068 control and ownership of the HA(s) and MR(s), there are two different 1069 possibilities: either (i) the HA(s) and MR(s) are controlled by a 1070 single entity, or (ii) the HA(s) and MR(s) are controlled by separate 1071 entities. We called the first possibility the 'ISP Model', and the 1072 second the 'Subscriber/Provider Model'. 1074 A.1.1 ISP Model 1076 The case of the HA(s) and MR(s) are controlled by the same entity can 1077 be best illustrated as an Internet Service Provider (ISP) installing 1078 mobile routers on trains, ships or planes. It is up to the ISP to 1079 deploy a certain configuration of mobile network; all 8 1080 configurations as described in the Configuration-Oriented Approach 1081 are possible. In the remaining portion of this document, when 1082 specifically referring to a mobile network configuration that is 1083 controlled by a single entity, we will add an 'ISP' prefix: for 1084 example: ISP-(1,1,1) or ISP-(1,N,N). 1086 When the HA(s) and MR(s) are controlled by a single entity (such as 1087 an ISP), the ISP can decide whether it wants to assign one or 1088 multiple MNPs to the mobile network just like it can make the same 1089 decision for any other link in its network (wired or otherwise). In 1090 any case, the ISP will make the routing between the mobile networks 1091 and its core routers (such as the HAs) work. This include not 1092 introducing any aggregation between the HAs which will filter out 1093 routing announcements for the MNP(es). 1095 To such ends, the ISP has various means and mechanisms. For one, the 1096 ISP can run its Interior Gateway Protocol (IGP) over bi-directional 1097 tunnels between the MR(s) and HA(s). Alternatively, static routes 1098 may be used with the tunnels. When static routes are used, a 1099 mechanism to test "tunnel liveness" might be necessary to avoid 1100 maintaining stale routes. Such "tunnel liveness" may be tested by 1101 sending heartbeats signals from MR(s) to the HA(s). A possibility is 1102 to simulate heartbeats using Binding Updates messages by controlling 1103 the "Lifetime" field of the Binding Acknowledgment message to force 1104 the MR to send Binding Update messages at regular interval. However, 1105 a more appropriate tool might be the Binding Refresh Request message, 1106 though conformance to the Binding Refresh Request message may be less 1107 strictly enforced in implementations since it serves a somewhat 1108 secondary role when compared to Binding Update messages. 1110 A.1.2 Subscriber/Provider Model 1112 The case of the HA(s) and MR(s) are controlled by the separate 1113 entities can be best illustrated with a subscriber/provider model, 1114 where the MRs belongs to a single subscriber and subscribes to one or 1115 more ISPs for HA services. There is two sub-categories in this case: 1116 when the subscriber subscribes to a single ISP, and when the 1117 subscriber subscribes to multiple ISPs. In the remaining portion of 1118 this document, when specifically referring to a mobile network 1119 configuration that is in the subscriber/provider model where the 1120 subscriber subscribes to only one ISP, we will add an 'S/P' prefix: 1121 for example: S/P-(1,1,1) or S/P-(1,n,n). When specifically referring 1122 to a mobile network configuration that is in the subscriber/provider 1123 model where the subscriber subscribes to multiple ISPs, we will add 1124 an 'S/mP' prefix: for example: S/mP-(1,1,1) or S/mP-(1,n,n). 1126 Not all 8 configurations are likely to be deployed for the S/P and 1127 S/mP models. For instance, it is unlikely to foresee a S/mP-(*,1,1) 1128 mobile network where there is only a single HA. For the S/P model, 1129 the following configurations are likely to be deployed: 1131 o S/P-(1,1,1): Single Provider, Single MR, Single HA, Single MNP 1133 o S/P-(1,1,n): Single Provider, Single MR, Single HA, Multiple MNPs 1135 o S/P-(1,n,1): Single Provider, Single MR, Multiple HAs, Single MNP 1137 o S/P-(1,n,n): Single Provider, Single MR, Multiple HAs, Multiple 1138 MNPs 1140 o S/P-(n,n,1): Single Provider, Multiple MRs, Single HA, Single MNP 1142 o S/P-(n,1,n): Single Provider, Multiple MRs, Single HA, Multiple 1143 MNPs 1145 o S/P-(n,n,1): Single Provider, Multiple MRs, Multiple HAs, Single 1146 MNP 1148 o S/P-(n,n,n): Single Provider, Multiple MRs, Multiple HAs, Multiple 1149 MNPs 1151 For the S/mP model, the following configurations are likely to be 1152 deployed: 1154 o S/mP-(1,n,1): Multiple Providers, Single MR, Multiple HAs, Single 1155 MNP 1157 o S/mP-(1,n,n): Multiple Providers, Single MR, Multiple HAs, 1158 Multiple MNPs 1160 o S/mP-(n,n,n): Multiple Providers, Multiple MRs, Multiple HAs, 1161 Multiple MNPs 1163 When the HA(s) and MR(s) are controlled by different entities, it is 1164 more likely the scenario where the MR is controlled by one entity 1165 (i.e. the subscriber), and the MR is establishing multiple 1166 bi-directional tunnels to one or more HA(s) provided by one or more 1167 ISP(s). In such case, it is unlikely for the ISP to run IGP over the 1168 bi-directional tunnel, since ISP would most certainly wish to retain 1169 full control of its routing domain. 1171 A.2 Problem-Oriented Approach 1173 A third approach is proposed by Pascal Thubert (Cisco System). This 1174 focused on the problems of multihomed mobile networks rather than the 1175 configuration or ownership. With this approach, there is a set of 4 1176 categories based on two orthogonal parameters: the number of HAs, and 1177 the number of MNPs advertised. Since the two parameters are 1178 orthogonal, the categories are not mutually exclusive. The four 1179 categories are: 1181 o Tarzan: Single HA for Different Care-of Addresses of Same MNP 1183 This is the case where one mobile router registers different 1184 Care-of Addresses to the same home agent for the same subnet 1185 prefix. This is equivalent to the case of y=1, i.e. the (1,1,*) 1186 mobile network. 1188 o JetSet: Multiple HAs for Different Care-of Addresses of Same MNP 1190 This is the case where the mobile router registers different 1191 Care-of Addresses to different home agents for the same subnet 1192 prefix. This is equivalent to the case of y=n, i.e. the (1,n,*) 1193 mobile network. 1195 o Shinkansen: Single MNP Advertised by MR(s) 1197 This is the case where one MNP is announced by different MRs. 1198 This is equivalent to the case of x=n and z=1, i.e. the (n,*,1) 1199 mobile network. 1201 o DoubleBed: Multiple MNPs Advertised by MR(s) 1203 This is the case where more than one MNPs are announced by the 1204 different MRs. This is equivalent to the case of x=n and z=n, 1205 i.e. the (n,*,n) mobile network. 1207 Appendix B. Nested Tunneling for Fault Tolerance 1209 In order to utilize the additional robustness provided by 1210 multihoming, MRs that employ bi-directional tunneling with their HAs 1211 should dynamically change their tunnel exit points depending on the 1212 link status. For instance, if a MR detects that one of its egress 1213 interface is down, it should detect if any other alternate route to 1214 the global Internet exists. This alternate route may be provided by 1215 any other MRs connected to one of its ingress interfaces that has an 1216 independent route to the global Internet, or by another active egress 1217 interface the MR itself possess. If such an alternate route exists, 1218 the MR should re-establish the bi-directional tunnel using this 1219 alternate route. 1221 In the remaining part of this section, we will attempt to investigate 1222 methods of performing such re-establishment of bi-directional 1223 tunnels. It is not the objective of this memo to specify a new 1224 protocol specifically tailored to provide this form of re- 1225 establishments. Instead, we will limit ourselves to currently 1226 available mechanisms specified in Mobile IPv6 [5] and Neighbor 1227 Discovery in IPv6 [11]. 1229 B.1 Detecting Presence of Alternate Routes 1231 To actively utilize the robustness provided by multihoming, a MR must 1232 first be capable of detecting alternate routes. This can be manually 1233 configured into the MR by the administrators if the configuration of 1234 the mobile network is relatively static. It is however highly 1235 desirable for MRs to be able to discover alternate routes 1236 automatically for greater flexibility. 1238 The case where a MR possesses multiple egress interface (bound to the 1239 same HA or otherwise) should be trivial, since the MR should be able 1240 to "realize" it has multiple routes to the global Internet. 1242 In the case where multiple MRs are on the mobile network, each MR has 1243 to detect the presence of other MR. A MR can do so by listening for 1244 Router Advertisement message on its *ingress* interfaces. When a MR 1245 receives a Router Advertisement message with a non-zero Router 1246 Lifetime field from one of its ingress interfaces, it knows that 1247 another MR which can provide an alternate route to the global 1248 Internet is present in the mobile network. 1250 B.2 Re-Establishment of Bi-Directional Tunnels 1252 When a MR detects that the link by which its current bi-directional 1253 tunnel with its HA is using is down, it needs to re-establish the 1254 bi-directional tunnel using an alternate route detected. We consider 1255 two separate cases here: firstly, the alternate route is provided by 1256 another egress interface that belongs to the MR; secondly, the 1257 alternate route is provided by another MR connected to the mobile 1258 network. We refer to the former case as an alternate route provided 1259 by an alternate egress interface, and the latter case as an alternate 1260 route provided by an alternate MR. 1262 B.2.1 Using Alternate Egress Interface 1264 When an egress interface of a MR loses the connection to the global 1265 Internet, the MR can make use of its alternate egress interface 1266 should it possess multiple egress interfaces. The most direct way to 1267 do so is for the mobile router to send a binding update to the home 1268 agent of the failed interface using the Care-of Address assigned to 1269 the alternate interface in order to re-establish the bi-directional 1270 tunneling using the Care-of Address on the alternate egress 1271 interface. After a successful binding update, the MR encapsulates 1272 outgoing packets through the bi-directional tunnel using the 1273 alternate egress interface. 1275 The idea is to use the global address (most likely a Care-of Address) 1276 assigned to an alternate egress interface as the new (back-up) 1277 Care-of Address of the mobile router to re-establish the 1278 bi-directional tunneling with its home agent. 1280 B.2.2 Using Alternate Mobile Router 1282 When the MR loses a connection to the global Internet, the MR can 1283 utilize a route provided by an alternate MR (if one exists) to 1284 re-establish the bi-directional tunnel with its HA. First, the MR 1285 has to obtain a Care-of Address from the alternate MR (i.e. attaches 1286 itself to the alternate MR). Next, it sends binding update to its HA 1287 using the Care-of Address obtained from the alternate MR. From then 1288 on, the MR can encapsulates outgoing packets through the 1289 bi-directional tunnel using via the alternate MR. 1291 The idea is to obtain a Care-of Address from the alternate MR and use 1292 this as the new (back-up) Care-of Address of the MR to re-establish 1293 the bi-directional tunneling with its HA. 1295 Note that every packet sent between MNNs and their correspondent 1296 nodes will experience two levels of encapsulation. First level of 1297 tunneling occurs between a MR which the MNN uses as its default 1298 router and the MR's HA. The second level of tunneling occurs between 1299 the alternate MR and its HA. 1301 B.3 To Avoid Tunneling Loop 1303 The method of re-establishing the bi-directional tunnel as described 1304 in Appendix B.2 may lead to infinite loops of tunneling. This 1305 happens when two MRs on a mobile network lose connection to the 1306 global Internet at the same time and each MR tries to re-establish 1307 bi-directional tunnel using the other MR. We refer to this 1308 phenomenon as tunneling loop. 1310 One approach to avoid tunneling loop is for a MR that has lost 1311 connection to the global Internet to insert an option into the Router 1312 Advertisement message it broadcasts periodically. This option serves 1313 to notify other MRs on the link that the sender no longer provides 1314 global connection. Note that setting a zero Router Lifetime field 1315 will not work well since it will cause MNNs that are attached to the 1316 MR to stop using the MR as their default router too (in which case, 1317 things are back to square one). 1319 Appendix C. Change Log 1321 o This draft is an update of draft-ng-nemo-multihoming-issues-03.txt 1322 which is itself a merge of 3 previous drafts 1323 draft-ng-nemo-multihoming-issues-02.txt, 1324 draft-eun-nemo-multihoming-problem-statement-00.txt, and 1325 draft-charbon-nemo-multihoming-evaluation-00.txt 1327 o Changes from draft-ietf-nemo-multihoming-issues-01 to -02: 1329 * Added recommendations/suggestion of which WG each issue should 1330 be addressed as pointed out in 61st IETF. 1332 * Minor updates on references. 1334 o Changes from draft-ietf-nemo-multihoming-issues-00 to -01: 1336 * Replaced NEMO-Prefix with MNP as decided by the WG at 60th IETF 1338 * Addressed Issue #1 in Section 1: Added a note to remind readers 1339 that IPv6 is implicitly assumed 1341 * Addressed Issue #3 in Section 2.3: Removed text on assumption 1343 * Addressed Issue #6 in Section 3.1: Added benefits 1345 * Addressed Issue #7 in Section 3.2: Modified text 1347 * Addressed Issue #9 in Section 4.3: Modified text 1349 * Addressed Issue #10 in Section 4.4: Added paragraph on other 1350 failure modes 1352 * Addressed Issue #10: New Section 4.5 on media detection 1354 * Addressed Issue #11 in Section 4.11: modified text 1356 o Changes from draft-ng-multihoming-issues-03 to 1357 draft-ietf-nemo-multihoming-issues-00: 1359 * Expanded "Problem Statement" (Section 4) 1361 * Merged "Evaluation" Section into "Problem Statement" 1362 (Section 4) 1364 * Cleaned up description in "Classification" (Section 2), and 1365 clearly indicate in each classification, what are the 1366 multihomed entities 1368 * Re-organized "Deployment Scenarios and Prerequisites" 1369 (Section 3), and created the "Prerequisites" sub-section. 1371 o Changes from draft-ng-multihoming-issues-02 to 1372 draft-ng-multihoming-issues-03: 1374 * Merged with draft-eun-nemo-multihoming-problem-statement (see 1375 "Problem Statement" (Section 4)) 1377 * Included conclusions from 1378 draft-charbon-nemo-multihoming-evaluation-00 1380 * Re-organized some part of "Benefits/Issues of Multhoming in 1381 NEMO" to "Problem Statement" (Section 4) 1383 * Removed lots of text to be in sync with [6]. 1385 * Title changed from "Multihoming Issues in NEMO Basic Support" 1386 to "Analysis of Multihoming in NEMO" 1388 * Changed (w,x,y) to (x,y,z) in taxonomy. 1390 * Moved alternative approaches of classification to Appendix 1392 * Creation of this Change-Log itself ;-) 1394 Intellectual Property Statement 1396 The IETF takes no position regarding the validity or scope of any 1397 Intellectual Property Rights or other rights that might be claimed to 1398 pertain to the implementation or use of the technology described in 1399 this document or the extent to which any license under such rights 1400 might or might not be available; nor does it represent that it has 1401 made any independent effort to identify any such rights. Information 1402 on the procedures with respect to rights in RFC documents can be 1403 found in BCP 78 and BCP 79. 1405 Copies of IPR disclosures made to the IETF Secretariat and any 1406 assurances of licenses to be made available, or the result of an 1407 attempt made to obtain a general license or permission for the use of 1408 such proprietary rights by implementers or users of this 1409 specification can be obtained from the IETF on-line IPR repository at 1410 http://www.ietf.org/ipr. 1412 The IETF invites any interested party to bring to its attention any 1413 copyrights, patents or patent applications, or other proprietary 1414 rights that may cover technology that may be required to implement 1415 this standard. Please address the information to the IETF at 1416 ietf-ipr@ietf.org. 1418 Disclaimer of Validity 1420 This document and the information contained herein are provided on an 1421 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1422 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1423 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1424 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1425 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1426 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1428 Copyright Statement 1430 Copyright (C) The Internet Society (2005). This document is subject 1431 to the rights, licenses and restrictions contained in BCP 78, and 1432 except as set forth therein, the authors retain all their rights. 1434 Acknowledgment 1436 Funding for the RFC Editor function is currently provided by the 1437 Internet Society.