idnits 2.17.1 draft-ietf-monami6-mipv6-analysis-05.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 22. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1388. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1399. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1406. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1412. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 1033: '... Update MUST be silently discarded i...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 3, 2008) is 5835 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 3775 (ref. '1') (Obsoleted by RFC 6275) ** Obsolete normative reference: RFC 2960 (ref. '5') (Obsoleted by RFC 4960) == Outdated reference: A later version (-09) exists of draft-ietf-mip6-hareliability-03 -- Obsolete informational reference (is this intentional?): RFC 3484 (ref. '10') (Obsoleted by RFC 6724) == Outdated reference: A later version (-02) exists of draft-larsson-mext-flow-distribution-rules-00 == Outdated reference: A later version (-12) exists of draft-ietf-shim6-proto-10 == Outdated reference: A later version (-14) exists of draft-ietf-monami6-multiplecoa-07 == Outdated reference: A later version (-02) exists of draft-lim-mext-multiple-coa-verify-01 -- No information found for draft-koh-mip6-nemo-dhap - is the name correct? Summary: 4 errors (**), 0 flaws (~~), 6 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MEXT Working Group N. Montavont 3 Internet-Draft IT/Telecom Bretagne 4 Intended status: Informational R. Wakikawa 5 Expires: November 4, 2008 Toyota ITC/Keio Univ. 6 T. Ernst 7 INRIA 8 C. Ng 9 Panasonic Singapore Labs 10 K. Kuladinithi 11 University of Bremen 12 May 3, 2008 14 Analysis of Multihoming in Mobile IPv6 15 draft-ietf-monami6-mipv6-analysis-05 17 Status of this Memo 19 By submitting this Internet-Draft, each author represents that any 20 applicable patent or other IPR claims of which he or she is aware 21 have been or will be disclosed, and any of which he or she becomes 22 aware will be disclosed, in accordance with Section 6 of BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as Internet- 27 Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt. 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 This Internet-Draft will expire on November 4, 2008. 42 Abstract 44 Mobile IPv6 as specified in RFC 3775 allows a mobile node to maintain 45 its IPv6 communications while moving between subnets. This document 46 investigates configurations where a mobile node running Mobile IPv6 47 is multihomed. The use of multiple addresses is foreseen to provide 48 ubiquitous, permanent and fault-tolerant access to the Internet, 49 particularly on mobile nodes which are more prone to failure or 50 sudden lack of connectivity. However, Mobile IPv6 currently lacks 51 support for such multihomed nodes. The purpose of this document is 52 to detail all the issues arising through the operation of Mobile IPv6 53 on multihomed mobile nodes. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 3. Goals and Node Capabilities . . . . . . . . . . . . . . . . . 6 60 4. Taxonomy . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 61 5. Analysis of Multihoming Configurations . . . . . . . . . . . . 9 62 5.1. (1,1): 1 HoA, 1 CoA . . . . . . . . . . . . . . . . . . . 9 63 5.2. (n,1): n HoAs, 1 CoA . . . . . . . . . . . . . . . . . . . 11 64 5.3. (1,n): 1 HoA, n CoAs . . . . . . . . . . . . . . . . . . . 13 65 5.4. (n,n): n HoAs, n CoAs . . . . . . . . . . . . . . . . . . 14 66 5.5. (n,0): n HoAs, no CoAs . . . . . . . . . . . . . . . . . . 16 67 6. Multihoming Issues . . . . . . . . . . . . . . . . . . . . . . 16 68 6.1. General IPv6-related Issues . . . . . . . . . . . . . . . 16 69 6.1.1. Failure Detection . . . . . . . . . . . . . . . . . . 16 70 6.1.2. Path Exploration . . . . . . . . . . . . . . . . . . . 17 71 6.1.3. Path Selection . . . . . . . . . . . . . . . . . . . . 18 72 6.1.4. Rehoming . . . . . . . . . . . . . . . . . . . . . . . 19 73 6.1.5. Ingress Filtering . . . . . . . . . . . . . . . . . . 20 74 6.2. MIPv6-specific Issues . . . . . . . . . . . . . . . . . . 21 75 6.2.1. Binding Multiple CoAs to a given HoA . . . . . . . . . 21 76 6.2.2. Simultaneous Location in Home and Foreign Networks . . 21 77 6.2.3. HA Synchronization . . . . . . . . . . . . . . . . . . 22 78 6.3. Considerations for MIPv6 Implementation . . . . . . . . . 22 79 6.3.1. Using one HoA as a CoA . . . . . . . . . . . . . . . . 22 80 6.3.2. Binding a new CoA to the Right HoA . . . . . . . . . . 23 81 6.3.3. Binding HoA to interface . . . . . . . . . . . . . . . 23 82 6.4. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 24 83 7. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 25 84 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 85 9. Security Considerations . . . . . . . . . . . . . . . . . . . 25 86 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 25 87 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 26 88 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 89 12.1. Normative References . . . . . . . . . . . . . . . . . . . 26 90 12.2. Informative References . . . . . . . . . . . . . . . . . . 26 91 Appendix A. Why a MN may want to redirect flows . . . . . . . . . 28 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29 93 Intellectual Property and Copyright Statements . . . . . . . . . . 31 95 1. Introduction 97 With the emergence of performant wireless technologies, nodes are 98 highly mobile and can change their point of attachment to the 99 Internet at any time, even during active network connections. To 100 support such mobility in IPv6, Mobile IPv6 (RFC 3775 [1] and RFC 3776 101 [2]) allows mobile nodes to maintain ongoing sessions while changing 102 their points of attachment to the Internet. 104 Additionally, as explained in [3], ubiquitous, permanent, fault- 105 tolerant and heterogeneous access to the Internet is required. For 106 doing so, mobile nodes which are prone to failure or sudden lack of 107 connectivity may be equipped with multiple interfaces. They may also 108 be connected to multihomed networks. In such a situation, mobile 109 nodes would be allocated multiple addresses and are said to be 110 multihomed. These addresses would be assigned to a single interface 111 or to multiple interfaces. However, the current specification of 112 Mobile IPv6 lacks support for using multiple addresses 113 simultaneously. 115 Individual solutions have been proposed to extend Mobile IPv6 in such 116 a way but all issues have not been addressed and not even discussed 117 in some document. 119 This study aims at fulfilling this gap and has two goals. The first 120 goal is to determine the capabilities required for providing 121 ubiquitous, permanent, fault-tolerant and heterogeneous access to the 122 Internet to multihomed mobile nodes operating Mobile IPv6. The 123 second goal is to define the issues arising when we attempt to 124 fulfill these requirements. The definition of solutions addressing 125 these issues is out of scope of this document. 127 To understand the foundation of this study, readers should 128 familiarize themselves with the companion document [3] which outlines 129 the motivations, the goals and the benefits of multihoming for both 130 fixed and mobile nodes (i.e. generic IPv6 nodes). Real-life 131 scenarios as illustrated in that document are the base motivations 132 for the present study. The reader should also has basic 133 understanding of the operation of the Mobile IPv6 protocol specified 134 in RFC3775 [1]. 136 The document is organized as follows: in Section 2, we introduce the 137 terminology related to multihoming and used in this document. In 138 Section 3 we recall and refine the design goals behind multihoming 139 and we discuss what are the required capabilities on the mobile nodes 140 to fully meet these design goals. Then we propose in Section 4 a 141 taxonomy to classify the different cases where mobile nodes are 142 multihomed. Thereafter the taxonomy is used in Section 5 to describe 143 a number of multihomed configurations specific to Mobile IPv6. For 144 each case, we show the resulting addressing configuration (number of 145 Home Addresses, and the number of Care-of Addresses). Each 146 configuration is illustrated with example diagrams and the means to 147 meet the requirements are outlined. Finally we discuss in Section 6 148 all issues related to a multihomed mobile node and we identify what 149 is missing in order to reach the goals outlined in [3]. These issues 150 are classified into IPv6 issues, Mobile IPv6-specific issues, and 151 advices to implementers. 153 2. Terminology 155 The terms used in the present document are defined in RFC3753 [4], 156 RFC3775 [1] and [3]. 158 In this document we are using the following terms and abbreviations: 160 o MIPv6 162 The Mobile IPv6 protocol specified in RFC3775 [1] 164 o Mobile Node (MN) 166 a Mobile Node operating Mobile IPv6 168 o HA 170 a Mobile IPv6 Home Agent 172 o HoA 174 a Mobile IPv6 Home Address 176 o CoA 178 a Mobile IPv6 Care-of Address 180 o Multihomed Mobile Node 182 In the companion document [3], a node is said to be multihomed 183 when it has multiple IPv6 addresses, either because multiple 184 prefixes are advertised on the link(s) the node is attached to, or 185 because the node has multiple interfaces (see the entire 186 definition). For a mobile node operating Mobile IPv6, this may 187 translate into the following definition: 189 A mobile node is said multihomed when it has either i) multiple 190 addresses which are used as source addresses or ii) multiple 191 tunnels to transmit packets, or both. 193 A mobile node may have multiple tunnels in the following cases: 195 * When it has multiple home addresses, that is if multiple 196 prefixes are available on the home link or if it has multiple 197 interfaces named on (presumably) distinct home links. 199 * When it has multiple care-of addresses, that is if multiple 200 prefixes are available on the foreign link or if it has 201 multiple interfaces attached to (presumably) distinct foreign 202 links. 204 * When the home agent has multiple addresses. 206 o A valid address 208 An address that is topologically correct (it is configured from 209 the prefix available on the link the interface is attached to) and 210 routable. 212 o Simultaneously using multiple addresses 214 A mobile node is using multiple addresses simultaneously when an 215 incoming packet with the destination address set to any of these 216 addresses reaches the mobile node, or when any of these addresses 217 can be used by the mobile node as the source address of outcoming 218 packets. 220 o Simultaneously using multiple interfaces 222 A mobile node is using multiple interfaces simultaneously when it 223 can transmit IP packets over any of these interfaces. 225 o Bidirectional Tunnel (BT) Mode 227 Mobile IPv6 Bidirectional tunnel between the mobile node and its 228 home agent. 230 o Route Optimization (RO) Mode 232 Mobile IPv6 Route optimization between the mobile node and its 233 correspondent node. 235 3. Goals and Node Capabilities 237 In this section, we determine what are the capabilities required on 238 the mobile nodes in order to benefit from multihoming configurations, 239 as indicated in [3] where a number of goals/benefits are listed: 240 ubiquitous access, flow redirection, reliability, load sharing, 241 interface switching, preference settings, and aggregate bandwidth. 242 These do somewhat overlap, i.e., they are not totally independent. 243 Reaching one of them may imply reaching another one as well. For 244 this reason, the following non-overlapping goals could be extracted: 246 1. Reliability 248 2. Load Sharing 250 3. Flow Distribution 252 From now on, this document will focus on these three non-overlapping 253 goals, as in this section to determine capabilities. We will 254 determine later in Section 5 which capabilities are already fulfilled 255 by Mobile IPv6 and what issues still remain. 257 Basically, Internet connectivity is guaranteed for a mobile node as 258 long as at least one path is maintained between the mobile node and 259 the fixed Internet. This path can be divided into two portions: the 260 path between the mobile node and its home agent(s) and the path 261 between the home agent(s) and the correspondent node. If route 262 optimization is in place between the mobile node and the 263 correspondent node, an additional path between the mobile node and 264 the correspondent node must be guaranteed. In essence, the benefit 265 of multihoming is to allow all or parts of these paths to have 266 multiple alternatives, so as to achieve reliability, load sharing 267 and/or flow distribution. In some cases, it may be necessary to 268 divert packets from a (perhaps failed) path to an alternative 269 (perhaps newly established) path (e.g. for matters of reliability, 270 preferences), or to split traffic between multiple paths (e.g. for 271 load sharing, flow distribution). The use of an alternative path 272 must be transparent at layers above layer 3 if broken sessions and 273 the establishment of new transport sessions has to be avoided. 275 In order to meet some of the goals (particularly flow distribution 276 and load sharing), multiple paths must be maintained simultaneously 277 between the mobile node and its correspondent node. 279 This translates into the following capabilities: 281 1. A mechanism should be available to quickly activate a backup 282 interface and redirect traffic when an interface fails (e.g., 283 loss of connection). 285 2. A mechanism should be available to quickly redirect flows from 286 one address to another when it is needed. Some of the triggers 287 of flow redirection are given in Appendix A. 289 3. A mobile node allocated with multiple valid addresses must be 290 able to use them simultaneously. 292 4. A mobile node equipped with multiple interfaces (attached to 293 distinct foreign links or distinct home links, or a combination 294 of both) must be able to use them simultaneously. 296 5. A mobile node should be able to distribute its traffic load among 297 its valid global addresses. 299 6. If multiple home agents are available to manage bindings for a 300 given home address, the mobile node should be able to use them 301 simultaneously or to switch between them. 303 One has to consider whether these goals can be achieved with 304 transparency or without transparency. Transparency is achieved when 305 switching between interfaces/addresses does not cause the disruption 306 of ongoing sessions. To achieve transparency, a necessary (may or 307 may not be sufficient) condition is for the end-point addresses at 308 the transport/application layer to remain unchanged. This is in view 309 of the large amount of Internet traffic currently carried by TCP, 310 which unlike SCTP, cannot handle multiple end-point address pairs. 312 Each of the aforementioned goals can be achieved independently. We 313 define here which of the above capabilities are needed for each goal: 315 1. Reliability: 1, 2, 3, 6 317 2. Load Sharing: 3, 6 319 3. Flow Distribution: 2, 3, 4, 5, 6 321 4. Taxonomy 323 In order to examine the issues preventing a mobile node to meet the 324 requirements listed in Section 3 we use in the present document the 325 following taxonomy (x,y) where: 327 o x = number of Home Addresses (HoAs) 329 o y = number of Care-of Addresses (CoAs) 331 A value of '1' implies there is a single instance of the parameter, 332 whereas a value of 'n' indicates that there are multiple instances of 333 the parameter. A value of '0' implies that there is no instance of 334 this parameter. A value '*' indicates that the number can be '0', 335 '1' or 'n'. 337 An illustration of this taxonomy is given in Figure 1. 339 Mobile Node 341 HoA1 HoA2 ... HoAn --> Permanent Address (x) 342 | | | 343 +-----+--------+ | | 344 | | | | | 345 CoA1 +--CoA2 +---CoA3 ... CoAn --> Temporary Address (y) 346 | | | | 347 Link1 Link2 Link3 ... Linkn --> IPv6 Link (n/a *) 348 | | | | 349 +-----+----+ | | 350 | | | 351 IF1 IF2 ... IFn --> Physical layer 353 CoA1, CoA2, CoA3 are bound to HoA1 on IF1 and IF2 354 CoA3 is bound to HoA2 on IF2 356 * n/a because the number of IPv6 links is equal to number of CoAs (y) 358 Figure 1: Illustration of the Taxonomy 360 As the taxonomy suggests, the fact that a mobile node has several 361 home addresses is independent from it having multiple interfaces. 362 Having multiple interfaces does not imply that it has multiple home 363 addresses and vice-versa. Similarly, the number of care-of addresses 364 is independent from the number of home addresses and the number of 365 interfaces. While a node would probably have at least one care-of 366 address per interface, multiple prefixes available on a link may lead 367 the node to configure several care-of addresses on that link. 369 The proposed taxonomy has two parameters because each of them has an 370 influence on either the mobile node behavior / management, or the 371 potential benefits the mobile node may obtain from such a 372 configuration. 374 The configurations denoted by these parameters will have an impact on 375 how multihoming is supported. Depending on the number of home and 376 care-of addresses, different policies will be needed, such as "which 377 care-of address has to be mapped to which home address", "all the 378 care-of addresses must be mapped with all the home addresses", etc. 380 The readers should note that for Mobile IPv6, home address is used to 381 identify a binding. Thus when a mobile node has multiple home 382 addresses, it would imply the mobile node is using multiple Mobile 383 IPv6 sessions, regardless of whether all the home addresses are 384 handled by a single home agent. 386 5. Analysis of Multihoming Configurations 388 In this section, we detail all the possible multihoming 389 configurations. We briefly discuss the current situation with Mobile 390 IPv6 and we point to issues that will be further detailed in 391 Section 6.1, Section 6.2 and Section 6.3. 393 As it is demonstrated below, we notice that: 395 o When the mobile nodes is equipped with multiple interfaces, 396 reliability, load sharing and flow distribution can be achieved in 397 all (*,*) cases. 399 o When a single interface is available, none of the goals can be 400 achieved in the (1,1) case (the mobile node is not multihomed). 401 In all the other cases, only reliability and load sharing can be 402 achieved. 404 5.1. (1,1): 1 HoA, 1 CoA 406 A mobile node in this configuration with only a single network 407 interface is not multihomed. This configuration is the common case 408 of a mobile node is away from its home link: the node has one home 409 address and one care-of address which is configured on the foreign 410 link. None of the multihoming goals are achievable. 412 A mobile node in the same configuration but with several interfaces 413 is multihomed and lead to a special situation where the mobile node 414 is connected to both its home link and a foreign link. In order to 415 use both interfaces simultaneously, the home address would be 416 directly used on the interface connected to the home link, and a 417 care-of address configured on the other interface connected to a 418 foreign link. There cannot be more than two active interfaces in the 419 (1,1) case, otherwise the mobile node would either have (A) multiple 420 interfaces on the home link, or (B) multiple interfaces on foreign 421 links. For (A), there would be multiple home addresses. For (B) 422 there would be multiple care-of addresses. These are indeed cases 423 (n,*) (see Section 5.2 , Section 5.4 and Section 5.5) and (*,n) (see 424 Section 5.3 and Section 5.4), respectively. 426 We next analyze if Mobile IPv6 can be used to achieve the following 427 multihoming benefits: 429 o Reliability 431 What Mobile IPv6 can achieve 433 Reliability is achievable, but in a limited manner. Although 434 the mobile node cannot register its care-of address at its home 435 agent and use its home link at the same time, it could register 436 the care-of address with selected correspondent nodes (i.e. 437 route optimization). In this case, the mobile node can enjoy a 438 better reliability for communications sessions opened with 439 these corrrespondent nodes. When the care-of address fails, 440 the mobile node can either bind a new care-of address with its 441 home address at the correspondent nodes, or remove the binding 442 and directly get the packets via the home link. 444 What is missing for Mobile IPv6 446 The mobile node cannot register the care-of address configured 447 on the foreign network with its home address and receive 448 packets from the home agent via a tunnel to the care-of address 449 at the same time it receives packet on the home address from 450 the home link. In addition, if the mobile node looses its 451 connection on the foreign link, flows that are started by using 452 the care-of address as a source address must be re-initiated 453 with another address (either the home address, or a new care-of 454 address obtained on another foreign link). Fault recovery is 455 thus only possible without transparency, and Mobile IPv6 456 features can only recover the failure of the home address. 457 This issue is detailed in Section 6.2.2. 459 Reliability could also be achieved through bi-casting since the 460 mobile node has two addresses and should be able to request any 461 correspondent node to duplicate traffic to both of them. 462 However, Mobile IPv6 does not allow the mobile node to request 463 bi-casting on the correspondent node (see Section 6.2.2). 465 o Load Sharing, Flow Distribution 467 What Mobile IPv6 can achieve 469 The mobile node is able to use both interfaces at the same 470 time, according to some preference settings on its side to 471 decide which one to use for which application. Therefore load 472 sharing and flow distribution can be achieved when sessions are 473 initiated by the mobile node. When a correspondent node 474 initiates a session with the mobile node, it would choose the 475 destination address depending on the available information 476 about the mobile node (e.g., DNS request). Presently there is 477 no mechanism allowing the mobile node to indicate on which 478 interface (i.e., address) a correspondent node may reach it. 479 If only one address is known by the distant node, load sharing 480 and flow distribution cannot be achieved. See in Section 6.1.3 481 where such path selection issues are discussed. 483 What is missing for Mobile IPv6 485 Although the mobile node is able to use both interfaces at the 486 same time, there is no mechanism that allows the mobile node to 487 indicate to which interface (i.e., address) a correspondent 488 node send packets for a particular flow. Section 6.1.3 489 discusses such path selection issues. 491 5.2. (n,1): n HoAs, 1 CoA 493 A mobile node in this configuration is multihomed since it has 494 several home addresses. This case may happen when a node gets access 495 to the Internet through different home agents (possibly distinct 496 operators), each offering a Mobile IPv6 service to the node. That 497 way, the mobile node would have a home address per home agent. 498 Alternatively, a single home network may be multihomed to the 499 Internet, leading to the advertisement of multiple prefixes on the 500 home link. The mobile node would thus have multiple home addresses 501 on a single home link. 503 In either cases, the node would configure a single care-of address on 504 the visited IPv6 subnet, and bind that single care-of address to all 505 its home addresses. If the mobile node has multiple interfaces, only 506 one interface is connected to a foreign network. The other 507 interfaces are connected to their home links, or are inactive. 509 We next analyze if Mobile IPv6 can be used to achieve the following 510 multihoming benefits: 512 o Reliability 514 What Mobile IPv6 can achieve 516 The care-of address may change when the mobile node has 517 multiple interfaces and is disconnected from its home link 518 (e.g. failure of the interface, or movement). In such a 519 situation, Mobile IPv6 allows transparent redirection of flows 520 using the old care-of address (i.e. the session was initiated 521 using the home address) to another care-of address. For 522 sessions directly opened via the care-of address, the loss of 523 the address implies a re-initiation of the session. 525 What is missing for Mobile IPv6 527 If the home agent fails, the session using the failed home 528 agent must be restarted since Mobile IPv6 does not provide any 529 mechanism to hand-over transparently from a home agent to 530 another one. Fault tolerance cannot be achieved in this case, 531 since established communications cannot be preserved (unless 532 mechanism such as [6] is used). See the corresponding 533 discussion in Section 6.1.4 and Section 6.2.3. 535 If one of the home addresses of the mobile node fails, it means 536 either that the corresponding home agent has failed (which is 537 the case discussed above), or the home address is no longer 538 routed to the home agent. In that latter case, sessions using 539 that HoA would be terminated, since the home address cannot be 540 changed transparently. 542 Reliability through bi-casting could also be achieved by 543 registering two addresses with a single home address. However 544 Mobile IPv6 does not provide any mechanism to associate more 545 than one care-of address with one home address. Moreover, in 546 this particular case, one home address should be used as a 547 care-of address bound to the other home address. (see in 548 Section 6.2.1 and Section 6.3.1). 550 o Load Sharing 552 What Mobile IPv6 can achieve 554 In bidirectional tunnel mode, load sharing only affects the 555 path between the correspondent node and the home agent(s), and 556 not the path between the mobile node and the home agent(s), as 557 long as the care-of address does not change. In route 558 optimization mode, the path between the mobile node and the 559 correspondent node does not change if the care-of address does 560 not change. As an entry in the binding cache is identified by 561 a home address, the mobile node can register the same care-of 562 address with all home address, on any distant node. 564 What is missing for Mobile IPv6 566 A mechanism would be needed for the mobile node to select which 567 home address should be used when a new communication flow is 568 initiated. A similar mechanism is needed on the correspondent 569 node side if it knows that multiple home addresses are assigned 570 to the same mobile node. With such mechanisms, it would be 571 possible to use multiple home addresses at the same time, and 572 load sharing could be performed. However, it can be noted that 573 load sharing on the path between the correspondent node and the 574 home agent might not be the most bandwidth contraint part of 575 the overall path from the correspondent node to the mobile 576 node. Thus load sharing might not bring important benefits. 577 See in Section 6.1.3 where such path selection issues are 578 discussed. It is also possible that the mobile node register 579 one home address as a care-of address for another home address 580 (see in Section 6.3.1). 582 o Flow Distribution 584 What Mobile IPv6 can achieve 586 Flow distribution is achievable when the mobile node is 587 attached to one foreign link via one of its interfaces and to 588 the home link(s) via its other interface(s). In this case, the 589 mobile node can spread flows over its interfaces. Note that if 590 a correspondent node initiates a communication, the interface 591 that it will use on the mobile node would depend on which 592 mobile node's address is advertised to the correspondent node. 594 5.3. (1,n): 1 HoA, n CoAs 596 A mobile node in this configuration is multihomed since it has 597 several care-of addresses. This may occur when the mobile node has 598 multiple interfaces connected to different links, or when the only 599 interface is connected to a link where multiple IPv6 prefixes are 600 advertised (i.e. the visited network is multihomed). Note that one 601 of the interfaces of the mobile node may be connected to its home 602 link. 604 We next analyze if Mobile IPv6 can be used to achieve the following 605 multihoming benefits: 607 o Reliability 609 What Mobile IPv6 can achieve 611 Reliability support is limited to recover from a failed care-of 612 address. Fault recovery is achieved in Mobile IPv6 by 613 associating an alternate care-of address to replace the failed 614 one. 616 What is missing for Mobile IPv6 618 Efficient mechanisms are needed to determine that a care-of 619 address has failed (see Section 6.1.1), to check reachability 620 (Section 6.1.2), to determine which care-of address should be 621 used instead (Section 6.1.3) and to redirect flows to the new 622 care-of address (Section 6.1.4). 624 o Load Sharing and Flow Distribution 626 What Mobile IPv6 can achieve 628 This configuration allows sharing of the load and setting of 629 preferences among different paths between the home agent and 630 the mobile node when bidirectional tunnel mode is used, and 631 between the correspondent node and the mobile node when route 632 optimized mode is used. 634 What is missing for Mobile IPv6 636 In order to achieve load sharing and flow distribution under 637 this scenario, the mobile node would need to register several 638 care-of addresses with its unique home addresses. However, the 639 present specification of Mobile IPv6 only allows the mobile 640 node to register a single care-of address per home address. 641 This is discussed in Section 6.2.1. When a single home address 642 is bounded to several care-of addresses at the same time, the 643 mobile node, home agent, or correspondent node must be able to 644 select the appropriate care-of address. This selection could 645 be done based on user/application preferences (see 646 Section 6.1.3). 648 5.4. (n,n): n HoAs, n CoAs 650 A mobile node in this configuration is multihomed since it has 651 multiple addresses. This case can be viewed as a combination of the 652 two cases described above: the mobile node has several home 653 addresses, e.g. given by different operators (similar to case (n,1) 654 in Section 5.2) and several care-of addresses, e.g. because the node 655 is receiving multiple IPv6 prefixes (similar to case (1,n) in 656 Section 5.3). 658 We next analyze if Mobile IPv6 can be used to achieve the following 659 multihoming benefits: 661 o Reliability 663 What Mobile IPv6 can achieve 665 If one care-of address becomes unreachable (similar to (1,n)), 666 the mobile node can redirect flows to another care-of address 667 by binding any of the other available care-of address to the 668 corresponding home address. If the mobile node can not use one 669 of its home addresses anymore (similar to (n,1)), the mobile 670 node will have to re-initiate all flows which were using the 671 corresponding home address. Redirection between the addresses 672 available for the mobile node will be different depending on 673 the binding policies. 675 What is missing for Mobile IPv6 677 None specific to (n,n) configuration. 679 o Load Sharing and Flow Distribution 681 What Mobile IPv6 can achieve 683 Although Mobile IPv6 allows the mobile node to register only 684 one care-of address per home address (see Section 6.2.1), it 685 can register the same or different care-of addresses with 686 multiple home addresses. If the mobile node chooses to bind 687 the same care-of address to all its home addresses, we fall in 688 the (n,1) case. In this case, load sharing can only be 689 performed if route optimization is not used, on the CN-HA path, 690 as a different home address may be used per correspondent node. 691 If the mobile node chooses to bind a different care-of address 692 for each home address, load sharing will be done along the 693 whole path across the mobile node and its correspondent nodes. 694 Preference settings may define which care-of address should be 695 bound to which home address (see Section 6.1.3). 697 In a very specific situation, one of the routable address of 698 the mobile node (i.e., which can be directly used without 699 tunneling to reach the mobile node) can be one of its home 700 addresses. This home address would then be viewed as a care-of 701 address bound to another home address (similar to (n,1)). 702 Mobile IPv6 does not prevent this behavior, which allows to set 703 a certain preference on addresses usage. See Section 6.3.1 for 704 the corresponding issue. 706 What is missing for Mobile IPv6 708 None specific to (n,n) configuration. 710 5.5. (n,0): n HoAs, no CoAs 712 This case happens when all the interfaces are connected to their 713 respective home links. This situation is quite similar to a 714 multihomed fixed node. The node would no longer be in the (n,0) 715 configuration when one or more of the interfaces are attached to 716 foreign links. 718 The mobile node may wish to use one or more home addresses to serve 719 as the care-of address of another home address (see Section 6.3.1). 720 In such situations, this scenario is reduced to a (1,1) or (1,n) 721 configuration as described in Section 5.1 and Section 5.3, 722 respectively. Analysis of which are already done in those section 723 and is thus omitted. 725 6. Multihoming Issues 727 Existing protocols may not allow reaching the goals expressed in 728 Section 3. For doing so, the issues discussed in this section must 729 be addressed, and solved preferably by dynamic mechanisms. Note that 730 some issues are pertaining to Mobile IPv6 solely, whereas other 731 issues are not at all related to Mobile IPv6. However, such non 732 MIPv6 issues must be solved in order to meet the goals outlined in 733 Section 3. 735 In this section, we describe some of these issues in two main 736 headings: general IPv6-related issues (Section 6.1), and issues that 737 are specific to Mobile IPv6 (Section 6.2). Other concerns related to 738 implementations of Mobile IPv6 are described in Section 6.3. Issues 739 and their area of application are summarized in Section 6.4 741 6.1. General IPv6-related Issues 743 6.1.1. Failure Detection 745 It is expected for faults to occur more readily at the edge of the 746 network (i.e. the mobile nodes), due to the use of wireless 747 connections. Efficient fault detection mechanisms are necessary to 748 recover in timely fashion. A failure in the path between two nodes 749 can be located at many different places: the media of one of the node 750 is broken (i.e., loss of connectivity), the path between the mobile 751 node and the home agent is broken, the home link is disconnected from 752 the Internet, etc. The failure protection domain greatly varies. In 753 some configurations, the protection domain is limited to a portion of 754 the path. 756 So far, Mobile IPv6 only relies on the ability or the inability to 757 receive Router Advertisements within a stipulated period to detect 758 the availability or loss of media (local failure). 760 [7] is addressing such concerns through the use of layer 2 triggers 761 [8]. Movement detection might be extended to include other triggers 762 such as the loss of connectivity on one interface. Additional 763 mechanisms would be needed to detect a failure in the path between a 764 mobile node and its correspondent node(s), as well as between the 765 mobile node and its home agent(s), and between the home agent and 766 correspondent node(s). 768 6.1.2. Path Exploration 770 When the mobile node needs to re-home a communication to an 771 alternative path, a path exploration may take place. The path 772 exploration is a step that occurs after the failure detection, and 773 before the path selection. It consists of identifying a set of paths 774 that are known to provide bidirectional connectivity between the 775 mobile node and its home agent, and optionally between the mobile 776 node and its correspondent node. It may be noted that the step of 777 path exploration may be avoided by selecting a new path, and trying 778 to re-home the communications on this new path. If the re- homing 779 fails, a new path is selected until there is no alternate path, or 780 the re-homing signaling succeed. 782 Path exploration requires some signaling between pairs of addresses 783 to check reachability. An additional protocol may be needed to 784 perform this task. 786 In (1,*), the path exploration consists in checking reachability 787 between each care-of address and each home agent address. If RO mode 788 is used, the mobile node may also insure reachability between its 789 correspondent nodes' address(es) and each care-of address. 791 In (n,*), the path exploration consists in checking reachability 792 between the home address that is used with the session that must be 793 re-homed and each care-of address (and optionally with the 794 correspondent nodes' address(es)). In addition, the session may need 795 to be re-homed to a different home address. In this case, each path 796 between a pair (HoA, CoA) must to be validated. 798 In all these cases the path between the home agent and the 799 correspondent node is not checked. A specific mechanism may be 800 defined to check reachability between a home agent and a 801 correspondent node. 803 6.1.3. Path Selection 805 When there exists multiple paths from and to the mobile node, the 806 mobile node ends up choosing a source address, and possibly the 807 interface that should be used. A correspondent node that wants to 808 establish a communication with such a mobile node may end up by 809 choosing a destination address for this mobile node. 811 o Interface selection 813 When the mobile node has multiple available interfaces, the 814 simultaneous or selective use of several interfaces would allow a 815 mobile node to spread flows between its different interfaces. 817 Each interface could be used differently according to some user 818 and applications policies and preferences that would define which 819 flow would be mapped to which interface and/or which flow should 820 not be used over a given interface. How such preferences would be 821 set on the mobile node is out of scope of Mobile IPv6 and might be 822 implementation specific. On the other hand, if the mobile node 823 wishes to influence how preferences are set on distant nodes 824 (correspondent node or home agent), mechanisms such as those 825 proposed in draft-soliman-flow-binding [9] could be used. 827 o Home Address Selection 829 When multiple home addresses are available, the mobile node and 830 its communicating peers (home agent and correspondent nodes) must 831 be able to select the appropriate home address to be used for a 832 particular packet or flow. 834 This choice would be made at the time of a new communication flow 835 set up. Usual IPv6 mechanisms for source and destination address 836 selection, such as "Default Address Selection for IPv6" (RFC3484) 837 [10] or DNS SRV Protocol (RFC2782) [11] could be used. 839 However, in RFC3484 it is said that "if the eight rules fail to 840 choose a single address, some unspecified tie-breaker should be 841 used". Therefore more specific rules in addition to those 842 described in RFC3484 may be defined for home address selection. 844 o CoA Selection 846 When multiple care-of addresses are available, the mobile node and 847 its communicating peers must be able to select the appropriate 848 care-of address to be used for a particular packet or flow. The 849 mobile node may use its internal policies to (i) distribute its 850 flow, and (ii) distribute policies on distant nodes to allow them 851 to select the preferred care-of address. Solutions like [12] or 852 [13] may be used. 854 Another related aspect of path selection is the concern of ingress 855 filtering. This is covered below in Section 6.1.5. 857 6.1.4. Rehoming 859 Re-homing takes place after an outage has been detected or an 860 alternative path has been identified (see previous issues 861 Section 6.1.1, Section 6.1.2 and Section 6.1.3), therefrom diverting 862 existing sessions from one path to another. New transport sessions 863 would have to be established over the alternate path if no mechanism 864 is provided to redirect flow transparently at layers above layer 3. 865 The need for re-homing or flow redirection is explained in Appendix A 867 The different mechanisms that can be used to provide re-homing can be 868 split into three categories, depending on the part of the path that 869 needs to be changed. 871 The first category is the care-of address changes : it influences the 872 path between the mobile node and its home agent, and the path between 873 the mobile node and its correspondent node in RO mode. This may hold 874 in case (n, n). 876 The second category is when the home address changes (: it influences 877 the entire path. As the home address is the address shown to the 878 higher layer (above layer 3), an additional mechanism is needed to 879 manage this change. Solution with a shim layer (e.g., Shim6 [14]), 880 or solution at the transport layer such as SCTP [5] may be useful. 882 The third category is when the home agent address changes. In this 883 case, the bidirectional tunnel between the mobile node and its home 884 agent as to be switched to the new address of the home agent. This 885 can be managed transparently by Mobile IPv6 if the home address 886 doesn't change at the same time. Otherwise, sessions continuity is 887 not ensured, as explained in the above paragraph. 889 6.1.5. Ingress Filtering 891 Ingress filtering mechanisms [15][16] may drop the outgoing packets 892 when multiple bi-directional tunnels end up at different home agents. 893 This could particularly occur if different prefixes are handled by 894 different home agents. If a packet with a source address configured 895 from a specific prefix is tunneled to a home agent that does not 896 handle that specific prefix, the packet may be discarded either by 897 the home agent or by a border router in the home network. The 898 problem of ingress filtering however, is two-fold. It can occur in 899 the access network as well as the home network. 901 Suppose the mobile node selects the interface (which would determine 902 the care-of address) and the home network (which would determine the 903 home address): the chosen care-of address may not be registered with 904 the chosen home address. For instance, consider Figure 2 below. In 905 the access network, the mobile node MN must use CoA=PA.MN when it 906 sends packets through AR-A and it must use CoA=PB.MN when it sends a 907 packet through AR-B. In the home network, it must use HoA=P1.MN when 908 it tunnels the packet to home agent HA-1, and it must use HoA=P2.MN 909 when it tunnels the packet to home agent HA-2. To avoid ingress 910 filtering, the choice is thus limited to a of valid (HoA,CoA) pairs. 911 This issue is related to Section 6.1.3 and greatly limits the way 912 mobile node can benefit from its multihoming configuration 913 (particularly in case of the home agent failure since flows cannot be 914 diverted to the other home agent). 916 Prefix: PA +------+ +----------+ +------+ 917 HoA: P1.MN /-----| AR-A |----| |----| HA-1 | 918 CoA: PA.MN / +------+ | | +------+ 919 +----+ | | Prefix: P1 920 | MN | | Internet | 921 +----+ | | Prefix: P2 922 HoA: P2.MN \ +------+ | | +------+ 923 CoA: PB.MN \-----| AR-B |----| |----| HA-2 | 924 Prefix: PB +------+ +----------+ +------+ 926 Figure 2: MN connected to Multiple Access/Home Networks 928 Should the mobile node be able to bind both care-of addresses PA.MN 929 and PB.MN simultaneously to home addresses P1.MN and P2.MN 930 respectively (see Section 6.2.1), it would be able to choose the 931 (HoA,CoA) pair based on the access network it wishes to use for 932 outgoing packets. It is, nonetheless, still limited to transmit all 933 packets to a specific home agent for the selected (HoA,CoA) pair, 934 i.e. ingress filtering at the home network remains unsolved). 936 Ingress filtering in the home network concerns only the (n,n) case 937 since the choice of the home and care-of addresses is limited to a 938 single (HoA, CoA) pair in other cases. In (n,n), the mobile node may 939 be connected to multiple access networks or multiple home networks 940 each practicing ingress filtering. To overcome this, mechanisms such 941 as those provided by Shim6 (see RFC3582 [17] and [14]) may be used. 943 6.2. MIPv6-specific Issues 945 6.2.1. Binding Multiple CoAs to a given HoA 947 In the (1,n) cases, multiple care-of addresses would be available to 948 the mobile node. In order to use them simultaneously, the mobile 949 node must be able to bind and register multiple care-of addresses for 950 a single home address with both the home agent and the correspondent 951 nodes. The Mobile IPv6 specification is currently lacking such 952 ability. 954 Although in the (n,n) cases, Mobile IPv6 allows the mobile node to 955 have multiple (HoA,CoA) pairs, the upper layer's choice of using a 956 particular home address would mean that the mobile node is forced to 957 use the corresponding care-of address. This constrains the mobile 958 node from choosing the best (in terms of cost, bandwidth etc) access 959 link for a particular flow, since care-of address is normally bound 960 to a particular interface. If the mobile node can register all 961 available care-of addresses with each home address, this would 962 completely decouple the home address from the interface, and allow 963 the mobile node to fully exploit its multihoming capabilities. 965 To counter this issue, a solution like [18] may be used. However, 966 with simultaneous binding support, there exists a possibility that a 967 malicious mobile node can successfully bind a number of victims' 968 addresses as valid care-of addresses for the mobile node with its 969 home agent. This is further elaborated in [19]. In view of such 970 risk, it might be avisable for home agent implementations to employ 971 some form of care-of addresses verification before using the care-of 972 addresses as a valid routing path to mobile node when accepting 973 multiple care-of address registrations. 975 6.2.2. Simultaneous Location in Home and Foreign Networks 977 Rule 4 of RFC3484 (section 5) specifies that a home address should be 978 preferred to a care-of address. While this rule allows the host to 979 choose which address to use, it does not allow the mobile node to 980 benefit from being multihomed in a situation where it may have one of 981 its interfaces directly connected to a home link. That is, addresses 982 from other interfaces cannot be registered as care-of addresses for 983 the home address associated to the home link the mobile node is 984 connected to. As a result, flows cannot be redirected transparently 985 from one care-of address to another and Mobile IPv6 features can only 986 recover the failure of the home address. 988 In the case of (1,*) where one of the interface is connected to the 989 home link, none of the other addresses can be used to achieve 990 multihoming goals with the home agent. 992 This issue is currently being resolved by [18]. 994 6.2.3. HA Synchronization 996 For a single home address obtained from a single home network, when a 997 failure is affecting ongoing sessions on a given home agent (i.e. 998 home agent has failed or is overloaded), solutions like [6] may be 999 used to allowing existing sessions to be shifted from one home agent 1000 to another. However, in the (n,*) cases where home addresses may be 1001 obtained from different home agents on different home networks, such 1002 coordination is not currently available. To achieve a global home 1003 agent synchronization, it might be necessary to extend mechanisms 1004 such as proposed in [6], [20] and [21]. 1006 6.3. Considerations for MIPv6 Implementation 1008 In addition to the issues described in Section 6.1 and Section 6.2, 1009 there are other concerns implementers should take into consideration 1010 so that their Mobile IPv6 implementations are more "friendly" to 1011 multihoming, particularly the use of multiple interfaces. These 1012 implementation-related considerations are described in the sub- 1013 sections below. 1015 6.3.1. Using one HoA as a CoA 1017 In (n,*) cases, the mobile node has multiple home addresses. A home 1018 address may be seen as a care-of address from the perspective of 1019 another home link of the same mobile node. 1021 As an example, a mobile node has two home addresses (HoA1 and HoA2) 1022 on two distinct home links. The mobile node is connected to these 1023 two home links via two interfaces. When the mobile node looses its 1024 connectivity on its first interface and HoA1 is not reachable, it may 1025 want to register HoA2 as a care-of address for HoA1 in order to keep 1026 receiving packets intended to HoA1, via the second interface. 1028 According to the definition of a care-of address, the current Mobile 1029 IPv6 specification does not prohibit to register a home address as 1030 the care-of address from the perspective of another home address. 1032 In RFC3775 section 6.1.7 it is written: "Similarly, the Binding 1033 Update MUST be silently discarded if the care-of address appears as a 1034 home address in an existing Binding Cache entry, with its current 1035 location creating a circular reference back to the home address 1036 specified in the Binding Update (possibly through additional 1037 entries)." 1039 In order to benefit from any multihoming configuration, a mobile node 1040 must be able to register whatever address it owns with any of its 1041 home address, as long as the above statement is observed. 1043 6.3.2. Binding a new CoA to the Right HoA 1045 In the (n,*) cases, the mobile node has multiple home addresses. 1046 When the mobile node moves and configures a new care-of address, the 1047 newly obtained care-of address must be bound to a specific home 1048 address. The current Mobile IPv6 specification doesn't provide a 1049 decision mechanism to determine to which home address this newly 1050 acquired care-of address should be bound to. 1052 With no such mechanism, the mobile node may be confused and may bind 1053 this care-of address to a possibly wrong home address. The result 1054 might be to bind the care-of address to the same home address the 1055 previous care-of address was bound to or to another one, depending on 1056 the implementation. It would indeed be better to specify the 1057 behavior so that all implementations are compliant. 1059 6.3.3. Binding HoA to interface 1061 In (n,*) cases, Mobile IPv6 does not provide any information on how 1062 home addresses should be bound to a device, and particularly there is 1063 no mechanism to bind home addresses to interfaces. 1065 This may be troublesome, for example, when we consider a mobile node 1066 configured with two home addresses and equipped with three 1067 interfaces. When the mobile node is connected to a home link via one 1068 interface, it will need to bind the corresponding home address to 1069 this interface, even if the home address was initially assigned to 1070 another one. 1072 HoA1 HoA2 1074 CoA1 CoA2 CoA3 1075 Iface1 Iface2 Iface3 1077 Figure 3: Illustration of the case (2,3) 1079 Home address must always be assigned to an activated interface and if 1080 the mobile node is connected to its home link, the corresponding home 1081 address must be used on this interface. In some cases, the home 1082 address then would have to be re-assigned to another interface in 1083 case of connection loss or attachment to the home link. 1085 6.4. Summary 1087 The table below summarizes the cases where each issue applies. 1089 +==========================================================+ 1090 | # of HoAs: | 1 | 1 | n | n | n | 1091 | # of CoAs: | 1 | n | 0 | 1 | n | 1092 +==========================================================+ 1093 | General IPv6 Issues | 1094 +--------------------------------------+---+---+---+---+---+ 1095 | Failure Detection | o | o | ? | o | o | 1096 +--------------------------------------+---+---+---+---+---+ 1097 | Path Exploration | | | | | | 1098 +--------------------------------------+---+---+---+---+---+ 1099 | Path Selection | | o | ? | o | o | 1100 +--------------------------------------+---+---+---+---+---+ 1101 | Flow Redirection | o | o | ? | o | o | 1102 +--------------------------------------+---+---+---+---+---+ 1103 | Ingress Filtering | | | ? | o | o | 1104 +--------------------------------------+---+---+---+---+---+ 1105 | MIPv6-Specific Issues | 1106 +--------------------------------------+---+---+---+---+---+ 1107 | Binding Multiple CoAs to a given HoA | | o | ? | o | o | 1108 +--------------------------------------+---+---+---+---+---+ 1109 | Simultaneous Location in Home and | | o | ? | o | o | 1110 | Foreign Networks | | | | | | 1111 +--------------------------------------+---+---+---+---+---+ 1112 | HA Synchronization | | | | | | 1113 +--------------------------------------+---+---+---+---+---+ 1114 | Implementation-Related Concerns | 1115 +--------------------------------------+---+---+---+---+---+ 1116 | Using one HoA as a CoA | | | ? | o | o | 1117 +--------------------------------------+---+---+---+---+---+ 1118 | Binding a new CoA to the Right HoA | | | ? | o | o | 1119 +--------------------------------------+---+---+---+---+---+ 1120 | Binding HoA to Interface(s) | o | o | ? | o | o | 1121 +==========================================================+ 1123 Figure 4: Summary of Issues and Categorization 1125 7. Conclusion 1127 In this document, we have demonstrated issues arising for multihomed 1128 mobile nodes operating Mobile IPv6. We have seen that mechanisms are 1129 needed: 1131 o to redirect flows from a failed path to a new path, 1133 o to decide which path should better be taken when multiple paths 1134 are available, 1136 o to register multiple care-of addresses 1138 o to exchange policies between the mobile node and the home agent 1140 Even if Mobile IPv6 can be used as a mechanism to manage multihomed 1141 mobile nodes, triggers of flow redirection between interfaces/ 1142 addresses are not adapted to the multihoming status of the node. 1143 Also, we have shown that in some configurations Mobile IPv6 is 1144 ambiguous in the definitions of CoA/HoA and in the mappings between 1145 home addresses, care-of addresses and network interfaces. Finally, 1146 we have also raised issues not directly related to Mobile IPv6, but 1147 solutions for these issues are needed for mobile nodes to fully take 1148 advantage of their multihomed configuration. 1150 8. IANA Considerations 1152 This is an informational document and as such does not require any 1153 IANA action. 1155 9. Security Considerations 1157 This is an informational document where the multihoming 1158 configurations under the operation of Mobile IPv6 are analyzed. 1159 Security considerations of these multihoming configurations, should 1160 they be different from those that concern Mobile IPv6, must be 1161 considered by forthcoming solutions. For instance, Section 6.2.1 1162 described a potential threat that should be considered when 1163 developing a proposed solution for multiple care-of addresses 1164 registration. 1166 10. Contributors 1168 The following people have contributed ideas, text and comments to 1169 earlier versions of this document: Eun Kyoung Paik from Seoul 1170 National University, South Korea and Thomas Noel from Universite 1171 Louis Pasteur, Strasbourg, France. 1173 11. Acknowledgments 1175 The authors would like to thank all the people who have sent comments 1176 so far, particularly Marcelo Bagnulo, Romain Kuntz, Tobias Kufner, 1177 Henrik Levkowetz, George Tsirtsis for their in-depth comments and 1178 raising new issues. 1180 12. References 1182 12.1. Normative References 1184 [1] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in 1185 IPv6", RFC 3775, June 2004. 1187 [2] Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to 1188 Protect Mobile IPv6 Signaling Between Mobile Nodes and Home 1189 Agents", RFC 3776, June 2004. 1191 [3] Ernst, T., Montavont, N., Wakikawa, R., Ng, C., and K. 1192 Kuladinithi, "Motivations and Scenarios for Using Multiple 1193 Interfaces and Global Addresses", 1194 draft-ietf-monami6-multihoming-motivation-scenario-03 (work in 1195 progress), May 2008. 1197 [4] Manner, J. and M. Kojo, "Mobility Related Terminology", 1198 RFC 3753, June 2004. 1200 [5] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, 1201 H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V. 1202 Paxson, "Stream Control Transmission Protocol", RFC 2960, 1203 October 2000. 1205 12.2. Informative References 1207 [6] Wakikawa, R., "Home Agent Reliability Protocol", 1208 draft-ietf-mip6-hareliability-03 (work in progress), 1209 November 2007. 1211 [7] Choi, JH. and G. Daley, "Goals of Detecting Network Attachment 1212 in IPv6", RFC 4135, August 2005. 1214 [8] Krishnan, S., Montavont, N., Njedjou, E., Veerepalli, S., and 1215 A. Yegin, "Link-Layer Event Notifications for Detecting Network 1216 Attachments", RFC 4957, August 2007. 1218 [9] Soliman, H., Montavont, N., Fikouras, N., and K. Kuladinithi, 1219 "Flow Bindings in Mobile IPv6 and Nemo Basic Support", 1220 draft-soliman-monami6-flow-binding-05 (work in progress), 1221 November 2007. 1223 [10] Draves, R., "Default Address Selection for Internet Protocol 1224 version 6 (IPv6)", RFC 3484, February 2003. 1226 [11] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 1227 specifying the location of services (DNS SRV)", RFC 2782, 1228 February 2000. 1230 [12] Larsson, C., Eriksson, M., Mitsuya, K., Tasaka, K., and R. 1231 Kuntz, "Flow Distribution Rule Language for Multi-Access 1232 Nodes", draft-larsson-mext-flow-distribution-rules-00 (work in 1233 progress), November 2007. 1235 [13] Mitsuya, K., "A Policy Data Set for Flow Distribution", 1236 draft-mitsuya-monami6-flow-distribution-policy-04 (work in 1237 progress), August 2007. 1239 [14] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming Shim 1240 Protocol for IPv6", draft-ietf-shim6-proto-10 (work in 1241 progress), February 2008. 1243 [15] Ferguson, P. and D. Senie, "Network Ingress Filtering: 1244 Defeating Denial of Service Attacks which employ IP Source 1245 Address Spoofing", BCP 38, RFC 2827, May 2000. 1247 [16] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 1248 Networks", BCP 84, RFC 3704, March 2004. 1250 [17] Abley, J., Black, B., and V. Gill, "Goals for IPv6 Site- 1251 Multihoming Architectures", RFC 3582, August 2003. 1253 [18] Wakikawa, R., Ernst, T., Nagami, K., and V. Devarapalli, 1254 "Multiple Care-of Addresses Registration", 1255 draft-ietf-monami6-multiplecoa-07 (work in progress), 1256 April 2008. 1258 [19] Lim, B., Ng, C., and K. Aso, "Verification of Care-of Addresses 1259 in Multiple Bindings Registration", 1260 draft-lim-mext-multiple-coa-verify-01 (work in progress), 1261 February 2008. 1263 [20] Wakikawa, R., Devarapalli, V., and P. Thubert, "Inter Home 1264 Agents Protocol (HAHA)", draft-wakikawa-mip6-nemo-haha-01 (work 1265 in progress), February 2004. 1267 [21] Koh, B., Ng, C., and J. Hirano, "Dynamic Inter Home Agent 1268 Protocol", draft-koh-mip6-nemo-dhap-00 (work in progress), 1269 July 2004. 1271 Appendix A. Why a MN may want to redirect flows 1273 When a mobile node is multihomed, an addresses selection mechanism is 1274 needed to distribute flows over interfaces. As policies may change 1275 over time, as well as the available addresses/interfaces, flow 1276 redirection mechanisms are needed. While the selection policy is out 1277 of scope of this document, the following reasons may trigger the 1278 mobile node to redirect flow from one address to another: 1280 o Failure detection: the path between the mobile node and its 1281 correspondent node(s) is broken. The failure can occur at 1282 different places onto this path; The failure can be local on the 1283 mobile node, where the interface used on the mobile node is 1284 disconnected from the network (e.g., a wireless interface which 1285 comes out of range from its point of attachment). Alternatively, 1286 the failure can be on the path between the mobile node and one of 1287 its home agent. Yet another alternative is that the failure can 1288 be on the path between the home agent and the correspondent node. 1289 If route optimization is used, it can also be a failure between 1290 the mobile node and its correspondent node(s). 1292 o New address: a new address on the mobile node may become 1293 available, e.g. when the mobile node connects to the network with 1294 a new interface. The mobile node may decide that this new 1295 interface is most suitable for its current flows that are using 1296 another interface. 1298 o Uninterrupted horizontal handover in mobility: if the mobile node 1299 is mobile, it may have to change its point of attachment. When a 1300 mobile node performs a horizontal handover, the handover latency 1301 (the time during which the mobile node can not send nor receive 1302 packets) can be long and the flows exchanged on the interface can 1303 be interrupted. If the mobile node wants to minimize such 1304 perturbation, it can redirect some or all the flows on another 1305 available interface. This redirection can be done prior to the 1306 handover if L2 triggering is considered [8]. 1308 o Change in the network capabilities: the mobile node can observe a 1309 degradation of service on one of its interface, or conversely an 1310 improvement of capacity on an interface. The mobile node may then 1311 decide to redirect some or all flows on another interface that it 1312 considers most suitable for the target flows. 1314 o Initiation of a new flow: a new flow is initiated between the 1315 mobile node and a correspondent node. According to internal 1316 policies, the mobile node may want to redirect this flow on a most 1317 suitable interface. 1319 Authors' Addresses 1321 Nicolas Montavont 1322 Institut Telecom - Telecom Bretagne 1323 2, rue de la chataigneraie 1324 Cesson Sevigne 35576 1325 France 1327 Phone: (+33) 2 99 12 70 23 1328 Email: nicolas.montavont@telecom-bretagne.eu 1329 URI: http://www.rennes.enst-bretagne.fr/~montavont/ 1331 Ryuji Wakikawa 1332 Toyota ITC / Keio University 1333 6-6-20 Akasaka, Minato-ku 1334 Tokyo 107-0052 1335 Japan 1337 Phone: +81-3-5561-8276 1338 Fax: +81-3-5561-8292 1339 Email: ryuji@jp.toyota-itc.com 1341 Thierry Ernst 1342 INRIA 1343 INRIA Rocquencourt 1344 Domaine de Voluceau B.P. 105 1345 Le Chesnay, 78153 1346 France 1348 Phone: +33-1-39-63-59-30 1349 Fax: +33-1-39-63-54-91 1350 Email: thierry.ernst@inria.fr 1351 URI: http://www.nautilus6.org/~thierry 1352 Chan-Wah Ng 1353 Panasonic Singapore Laboratories Pte Ltd 1354 Blk 1022 Tai Seng Ave #06-3530 1355 Tai Seng Industrial Estate 1356 Singapore 534415 1357 Singapore 1359 Phone: +65 65505420 1360 Email: chanwah.ng@sg.panasonic.com 1362 Koojana Kuladinithi 1363 University of Bremen 1364 ComNets-ikom,University of Bremen. 1365 Otto-Hahn-Allee NW 1 1366 Bremen, Bremen 28359 1367 Germany 1369 Phone: +49-421-218-8264 1370 Fax: +49-421-218-3601 1371 Email: koo@comnets.uni-bremen.de 1372 URI: http://www.comnets.uni-bremen.de/~koo/ 1374 Full Copyright Statement 1376 Copyright (C) The IETF Trust (2008). 1378 This document is subject to the rights, licenses and restrictions 1379 contained in BCP 78, and except as set forth therein, the authors 1380 retain all their rights. 1382 This document and the information contained herein are provided on an 1383 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1384 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1385 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1386 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1387 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1388 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1390 Intellectual Property 1392 The IETF takes no position regarding the validity or scope of any 1393 Intellectual Property Rights or other rights that might be claimed to 1394 pertain to the implementation or use of the technology described in 1395 this document or the extent to which any license under such rights 1396 might or might not be available; nor does it represent that it has 1397 made any independent effort to identify any such rights. Information 1398 on the procedures with respect to rights in RFC documents can be 1399 found in BCP 78 and BCP 79. 1401 Copies of IPR disclosures made to the IETF Secretariat and any 1402 assurances of licenses to be made available, or the result of an 1403 attempt made to obtain a general license or permission for the use of 1404 such proprietary rights by implementers or users of this 1405 specification can be obtained from the IETF on-line IPR repository at 1406 http://www.ietf.org/ipr. 1408 The IETF invites any interested party to bring to its attention any 1409 copyrights, patents or patent applications, or other proprietary 1410 rights that may cover technology that may be required to implement 1411 this standard. Please address the information to the IETF at 1412 ietf-ipr@ietf.org.