idnits 2.17.1 draft-ietf-monami6-mipv6-analysis-03.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 1270. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1281. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1288. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1294. 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 941: '... 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 (July 10, 2007) is 6133 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 3775 (ref. '1') (Obsoleted by RFC 6275) == Outdated reference: A later version (-03) exists of draft-ietf-monami6-multihoming-motivation-scenario-01 == Outdated reference: A later version (-05) exists of draft-soliman-monami6-flow-binding-04 -- Obsolete informational reference (is this intentional?): RFC 3484 (ref. '8') (Obsoleted by RFC 6724) == Outdated reference: A later version (-12) exists of draft-ietf-shim6-proto-08 == Outdated reference: A later version (-14) exists of draft-ietf-monami6-multiplecoa-02 -- No information found for draft-koh-mip6-nemo-dhap - is the name correct? Summary: 3 errors (**), 0 flaws (~~), 5 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MONAMI6 Working Group N. Montavont 3 Internet-Draft GET/ENST-B 4 Intended status: Informational R. Wakikawa 5 Expires: January 11, 2008 Keio University 6 T. Ernst 7 INRIA 8 C. Ng 9 Panasonic Singapore Labs 10 K. Kuladinithi 11 University of Bremen 12 July 10, 2007 14 Analysis of Multihoming in Mobile IPv6 15 draft-ietf-monami6-mipv6-analysis-03 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 January 11, 2008. 42 Copyright Notice 44 Copyright (C) The IETF Trust (2007). 46 Abstract 48 Mobile IPv6 as specified in RFC 3775 allows a mobile node to maintain 49 its IPv6 communications while moving between subnets. This document 50 investigates configurations where a mobile node running Mobile IPv6 51 is multihomed. The use of multiple addresses is foreseen to provide 52 ubiquitous, permanent and fault-tolerant access to the Internet, 53 particularly on mobile nodes which are more prone to failure or 54 sudden lack of connectivity. However, Mobile IPv6 currently lacks 55 support for such multihomed nodes. The purpose of this document is 56 to detail all the issues arising through the operation of Mobile IPv6 57 on multihomed mobile nodes. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 63 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 65 3. Goals and Node Capabilities . . . . . . . . . . . . . . . . . 9 67 4. Taxonomy . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 69 5. Multihoming Configurations . . . . . . . . . . . . . . . . . . 13 70 5.1. (1,1): 1 HoA, 1 CoA . . . . . . . . . . . . . . . . . . . 13 71 5.2. (n,1): n HoAs, 1 CoA . . . . . . . . . . . . . . . . . . . 14 72 5.3. (1,n): 1 HoA, n CoAs . . . . . . . . . . . . . . . . . . . 16 73 5.4. (n,n): n HoAs, n CoAs . . . . . . . . . . . . . . . . . . 17 74 5.5. (n,0): n HoAs, no CoAs . . . . . . . . . . . . . . . . . . 18 76 6. Multihoming Issues . . . . . . . . . . . . . . . . . . . . . . 19 77 6.1. General IPv6-related Issues . . . . . . . . . . . . . . . 19 78 6.1.1. Failure Detection . . . . . . . . . . . . . . . . . . 19 79 6.1.2. Path Exploration . . . . . . . . . . . . . . . . . . . 19 80 6.1.3. Path Selection . . . . . . . . . . . . . . . . . . . . 20 81 6.1.4. Rehoming . . . . . . . . . . . . . . . . . . . . . . . 21 82 6.1.5. Ingress Filtering . . . . . . . . . . . . . . . . . . 22 83 6.2. MIPv6-specific Issues . . . . . . . . . . . . . . . . . . 23 84 6.2.1. Binding Multiple CoAs to a given HoA . . . . . . . . . 23 85 6.2.2. Simultaneous Location in Home and Foreign Networks . . 23 86 6.2.3. HA Synchronization . . . . . . . . . . . . . . . . . . 24 87 6.3. Considerations for MIPv6 Implementation . . . . . . . . . 24 88 6.3.1. Using one HoA as a CoA . . . . . . . . . . . . . . . . 24 89 6.3.2. Binding a new CoA to the Right HoA . . . . . . . . . . 25 90 6.3.3. Binding HoA to interface . . . . . . . . . . . . . . . 25 91 6.4. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 26 93 7. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 27 95 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 97 9. Security Considerations . . . . . . . . . . . . . . . . . . . 29 99 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 30 101 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 31 103 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32 104 12.1. Normative References . . . . . . . . . . . . . . . . . . . 32 105 12.2. Informative References . . . . . . . . . . . . . . . . . . 32 107 Appendix A. Why a MN may want to redirect flows . . . . . . . . . 34 109 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35 110 Intellectual Property and Copyright Statements . . . . . . . . . . 37 112 1. Introduction 114 The emergence of performant wireless technologies has favored node 115 mobility within the Internet. Nowadays, and even more tomorrow, 116 nodes are highly mobile and can change their point of attachment to 117 the Internet at any time, even during active network connections. As 118 such, Mobile IPv6 (RFC 3775 [1] and RFC 3776 [2]) allows mobile nodes 119 to maintain sessions open while changing their point of attachment to 120 the Internet. 122 Besides - as explained in [3] - ubiquitous, permanent, fault-tolerant 123 and heterogeneous access to the Internet is required . For doing so, 124 mobile nodes which are prone to failure or sudden lack of 125 connectivity shall be equipped with multiple interfaces. They may 126 also be connected to multihomed networks. In such a situation, 127 mobile nodes would be allocated multiple addresses and are said to be 128 multihomed. These addresses would be assigned to a single interface 129 or to multiple interfaces. However, the current specification of 130 Mobile IPv6 lacks support for using multiple addresses 131 simultaneously. 133 Individual solutions have been proposed to extend Mobile IPv6 in such 134 a way but all issues have not been addressed and not even discussed 135 in some document. 137 This study aims at fulfilling this gap and has two thus goals. The 138 first goal is to determine the capabilities required for providing 139 ubiquitous, permanent, fault-tolerant and heterogeneous access to the 140 Internet to multihomed mobile nodes operating Mobile IPv6. The 141 second goal is to define the issues arising when we attempt to 142 fulfill these requirements. The definition of solutions addressing 143 these issues is out of scope of this document. 145 To understand the foundation of this study, the reader shall read the 146 companion document [3] which outlines the motivations, the goals and 147 the benefits of multihoming for both fixed and mobile nodes (i.e. 148 generic IPv6 nodes). Real-life scenarios as illustrated in that 149 document are the base motivations for the present study. The reader 150 shall also understand the operation of the Mobile IPv6 protocol 151 (RFC3775 [1]). 153 The document is organized as follows: in Section 2, we introduce the 154 terminology related to multihoming and used in this document. In 155 Section 3 we recall and refine the design goals behind multihoming 156 and we discuss what are the required capabilities on the mobile nodes 157 to fully meet these design goals. Then we propose in Section 4 a 158 taxonomy to classify the different cases where mobile nodes are 159 multihomed. Thereafter the taxonomy is used in Section 5 to describe 160 a number of multihomed configurations specific to Mobile IPv6. For 161 each case, we show the resulting addressing configuration (number of 162 Home Addresses, and the number of Care-of Addresses). Each 163 configuration is illustrated with example diagrams and the means to 164 meet the requirements are outlined. Finally we discuss in Section 6 165 all issues related to a multihomed mobile node and we identify what 166 is missing in order to reach the goals outlined in [3]. These issues 167 are classified into IPv6 issues, Mobile IPv6-specific issues, and 168 advices to implementers. 170 2. Terminology 172 The terms used in the present document are defined in RFC3753 [4], 173 RFC3775 [1] and [3]. 175 In this document we are using the following terms and abbreviations: 177 o MIPv6 179 The Mobile IPv6 protocol specified in RFC3775 [1] 181 o MN 183 a Mobile Node operating MIPv6 185 o HA 187 a Mobile IPv6 Home Agent 189 o HoA 191 a Mobile IPv6 Home Address 193 o CoA 195 a Mobile IPv6 Care-of Address 197 o Multihomed MN 199 In the companion document [3], a node is said to be multihomed 200 when it has multiple IPv6 addresses, either because multiple 201 prefixes are advertised on the link(s) the node is attached to, or 202 because the node has multiple interfaces (see the entire 203 definition). For a mobile node operating MIPv6, this may 204 translate into the following definition: 206 A MN is said multihomed when it has either i) multiple addresses 207 which are used as source addresses or ii) multiple tunnels to 208 transmit packets, or both. 210 A MN may have multiple HoAs/CoAs in the following cases: 212 * A MN would have multiple HoAs if multiple prefixes are 213 available on the home link or if it has multiple interfaces 214 named on (presumably) distinct home links. 216 * A MN would have multiple CoAs if multiple prefixes are 217 available on the foreign link or if it has multiple interfaces 218 attached to (presumably) distinct foreign links. 220 o A valid address 222 An address that is topologically correct (it is configured from 223 the prefix available on the link the interface is attached to) and 224 routable. 226 o Simultaneously using multiple addresses 228 A MN is using multiple addresses simultaneously when an incoming 229 packet with the destination address set to any of these addresses 230 reaches the MN, or when any of these addresses can be used by the 231 MN as the source address of outcoming packets. 233 o Simultaneously using multiple interfaces 235 A MN is using multiple interfaces simultaneously when it can 236 transmit IP packets over any of these interfaces. 238 o BT Mode 240 MIPv6 Bidirectional tunnel between MN and HA. 242 o RO Mode 244 MIPv6 Route optimization between MN and CN. 246 3. Goals and Node Capabilities 248 In this section, we determine what are the capabilities required on 249 the mobile nodes in order to benefit from multihoming configurations, 250 as indicated in [3] where a number of goals/benefits are listed: 251 ubiquitous access, flow redirection, reliability, load sharing, 252 inteface switching, preference settings, and aggregate bandwidth. 253 These do somwhat overlap, i.e., they are not totally independent. 254 Reaching one of them may imply reaching another one as well. For 255 this reason, the following non-overlapping goals could be extracted: 257 1. Reliability 259 2. Load Sharing 261 3. Flow Distribution 263 From now on, this document will focus on these three non-overlapping 264 goals, as in this section to determine capabilities. We will 265 determine later in Section 5 which capabilities are already fulfilled 266 by Mobile IPv6 and what issues still remain. 268 Basically, Internet connectivity is guaranteed for a MN as long as at 269 least one path is maintained between the MN and the fixed Internet. 270 This path can be divided into two portions: the path between the MN 271 and its HA(s) and the path between the HA(s) and the CN. If RO is in 272 place between the MN and a CN, an additional path between the MN and 273 the CN must be guaranteed. In some cases, it may be necessary to 274 divert packets from a (perhaps failed) path to an alternative 275 (perhaps newly established) path (e.g. for matters of reliability, 276 preferences), or to split traffic between multiple paths (e.g. for 277 load sharing, flow distribution). The use of an alternative path 278 must be transparent at layers above layer 3 if broken sessions and 279 the establishment of new transport sessions has to be avoided. 281 In order to meet some of the goals (particularly flow distribution 282 and load sharing), multiple paths must be maintained simultaneously 283 between the MN and its CN. 285 This translates into the following capabilities: 287 1. A mechanism should be available to quickly activate a backup 288 interface and redirect traffic when an interface fails (e.g., 289 loss of connection). 291 2. A mechanism should be available to quickly redirect flows from 292 one address to another when it is needed. Some of the triggers 293 of flow redirection are given in Appendix A. 295 3. A MN allocated with multiple valid addresses must be able to use 296 them simultaneously. 298 4. A MN equipped with multiple interfaces (attached to distinct 299 foreign links or distinct home links, or a combination of both) 300 must be able to use them simultaneoulsy. 302 5. A MN should be able to distribute its traffic load among its 303 valid global addresses. 305 6. If multiple HAs are available to manage bindings for a given HoA, 306 the MN should be able to use them simultaneously. 308 One has to consider whether these goals can be achieved with 309 transparency or without transparency. Transparency is achieved when 310 switching between interfaces does not cause the disruption of on- 311 going sessions. To be achieved with transparency, a necessary (may 312 or may not be sufficient) condition is for the end-point addresses at 313 the transport/application layer to remain unchanged. This is in view 314 of the large amount of Internet traffic currently carried by TCP, 315 which unlike SCTP, cannot handle multiple end-point address pairs. 317 Each of the aforementioned goals can be achieved independently. We 318 define here which of the above capabilities are needed for each goal: 320 1. Reliability: 1, 2, 3, 6 322 2. Load Sharing: 3, 6 324 3. Flow Distribution: 2, 3, 4, 5, 6 326 4. Taxonomy 328 In order to examine the issues preventing a MN to meet the 329 requirements listed in Section 3 we use in the present document the 330 following taxonomy (x,y) where: 332 o x = number of Home Addresses (HoAs) 334 o y = number of Care-of Addresses (CoAs) 336 A value of '1' implies there is a single instance of the parameter, 337 whereas a value of 'n' indicates that there are multiple instances of 338 the parameter. A value of '0' implies that there is no instance of 339 this parameter. A value '*' indicates that the number can be '0', 340 '1' or 'n'. 342 An illustration of this taxonomy is given in Figure 1. 344 Mobile Node 346 HoA1 HoA2 ... HoAn --> Permanent Address (x) 347 | | | 348 +-----+--------+ | | 349 | | | | | 350 CoA1 +--CoA2 +---CoA3 ... CoAn --> Temporary Address (y) 351 | | | | 352 Link1 Link2 Link3 ... Linkn --> IPv6 Link (n/a *) 353 | | | | 354 +-----+----+ | | 355 | | | 356 IF1 IF2 ... IFn --> Physical layer 358 CoA1, CoA2, CoA3 are bound to HoA1 on IF1 and IF2 359 CoA3 is bound to HoA2 on IF2 361 * n/a because the number of IPv6 links is equal to number of CoAs (y) 363 Figure 1: Illustration of the Taxonomy 365 As the taxonomy suggests, the fact that a mobile node has several 366 HoAs is independent from it having multiple interfaces. Having 367 multiple interfaces does not imply that it has multiple HoAs and 368 vice-versa. Similarly, the number of CoAs is independent from the 369 number of HoAs and the number of interfaces. While a node would 370 probably have at least one CoA per interface, multiple prefixes 371 available on a link may lead the node to configure several CoAs on 372 that link. 374 The proposed taxonomy has two parameters because each of them has an 375 influence on either the mobile node behavior / management, or the 376 potential benefits the mobile node may obtain from such a 377 configuration. 379 The configurations denoted by these parameters will have an impact on 380 how multihoming is supported. Depending on the number of HoAs and 381 CoAs, different policies will be needed, such as "which CoA has to be 382 mapped to which HoA", "must all the CoAs be mapped with all the 383 HoAs", etc. 385 5. Multihoming Configurations 387 In this section, we detail all the possible multihoming 388 configurations. For each one, we briefly explain how it may happen. 389 We also list which of the goals outlined in Section 3 are achievable 390 provided that supporting mechanisms are either already existing or 391 could be added. Other goals are not achievable due to the inherent 392 configuration of the node. Then, we briefly discuss the current 393 situation with MIPv6 and we point to issues that will be further 394 detailed in Section 6.1, Section 6.2 and Section 6.3. 396 As it is demonstrated below, we notice that: 398 o When the mobile nodes is equipped with multiple interfaces, 399 reliability, load sharing and flow distribution can be achieved in 400 all (*,*) cases. 402 o When a single interface is available, none of the goals can be 403 achieved in the (1,1) case (the MN is not multihomed). In all the 404 other cases, only reliability and load sharing can be achieved. 406 5.1. (1,1): 1 HoA, 1 CoA 408 A MN in this configuration with only a single network interface is 409 not multihomed. This configuration is the common case of a MN away 410 from its home link: the node has one HoA and one CoA which is 411 configured on the foreign link. None of the multihoming goals are 412 achievable. 414 A MN in the same configuration but with several interfaces is 415 multihomed and lead to a special situation where the MN is connected 416 to both its home link and a foreign link. In order to use both 417 interfaces simultaneously, the HoA would be directly used on the 418 interface connected to the home link, and a CoA configured on the 419 other interface connected to a foreign link. There cannot be more 420 than two active interfaces in the (1,1) case, otherwise the MN would 421 either have (A) multiple interfaces on the home link, or (B) multiple 422 interfaces on foreign links. For (A), there would be multiple HoAs. 423 For (B) there would be multiple CoAs. These are indeed cases (n,*) 424 (see Section 5.2 , Section 5.4 and Section 5.5) and (*,n) (see 425 Section 5.3 and Section 5.4), respectively. 427 Current situation with MIPv6 (when the node has multiple interfaces): 429 o Reliability 431 Reliability is achievable, but in a limited manner. The MN has 432 two valid addresses, but is unable to use both addresses 433 simultaneously: it cannot register the CoA configured on the 434 foreign network with its HA and receive packets from the HA via a 435 tunnel to the CoA at the same time it receives packet on the HoA 436 from the home link. In addition, if the MN looses its connection 437 established using the CoA on the foreign link, flows must be re- 438 initiated with another address (either the HoA, or a new CoA 439 obtained on another foreign link). Fault recovery is thus only 440 possible without transparency, and MIPv6 features can only recover 441 the failure of the HoA. This issue is detailed in Section 6.2.2. 443 However, it might be possible for the MN to register the CoA with 444 selected CNs (i.e. route optimization). In this case, the MN can 445 enjoy a better reliability for communications sessions opened with 446 these CNs. When the CoA fails, the MN can either bind a new CoA, 447 or remove the binding and directly get the packets to its HoA. 449 Reliability could also be achieved through bi-casting since the MN 450 has two addresses and should be able to request any CN to 451 duplicate traffic to both of them. However, MIPv6 does not allow 452 the MN to request bi-casting on the CN (see Section 6.2.2). 454 o Load Sharing, Flow Distribution 456 The MN is able to use both interfaces at the same time, according 457 to some preference settings on its side to decide which one to use 458 for which application. Therefore load sharing and flow 459 distribution can be achieved when sessions are initiated by the 460 MN. When a CN initiates a session with the MN, it would choose 461 the destination address depending on the available information 462 about the MN (e.g., DNS request). Presently there is no mechanism 463 allowing the MN to indicate on which interface (i.e., address) a 464 CN may reach it. If only one address is known by the distant 465 node, load sharing and flow distribution cannot be achieved. See 466 in Section 6.1.3 where such path selection issues are discussed. 468 5.2. (n,1): n HoAs, 1 CoA 470 A MN in this configuration is multihomed since it has several HoAs. 471 This case may happen when a node gets access to the Internet through 472 different HAs (possibly distinct operators), each offering a Mobile 473 IPv6 service to the node. That way, the node would have a HoA per 474 HA. Alternatively, a single home network may be multihomed to the 475 Internet, leading to the advertisement of multiple prefixes on the 476 home link. The MN would thus have multiple HoAs on a single home 477 link. 479 In either cases, the node would configure a single CoA on the visited 480 IPv6 subnet, and bind that single CoA to all its HoAs. If the MN has 481 multiple interfaces, only one interface is connected to a foreign 482 network. The other interfaces are connected to their home links, or 483 are inactive. 485 Current situation with MIPv6: 487 o Reliability 489 In case a HoA fails, the session using the HoA must be restarted 490 since MIPv6 does not provide any mechanism to hand-over 491 transparently from a failed HoA to another one. Fault tolerance 492 cannot be achieved in this case, since established communications 493 cannot be preserved. See the corresponding discussion in 494 Section 6.1.4 and Section 6.2.3. 496 The CoA may change when the MN has multiple interfaces and is 497 disconnected from its home link (e.g. failure of the interface, or 498 movement). In such a situation, MIPv6 allows to transparently 499 redirect flows using the old CoA as a temporarily address (i.e. 500 the HoA was used as the main address) to another CoA. For 501 sessions directly opened via the CoA, the loss of the address 502 implies a re-initiation of the session. 504 Reliability through bi-casting could also be achieved by 505 registering two addresses with a single HoA. However MIPv6 does 506 not provide any mechanism to associate more than one CoA with one 507 HoA. Moreover, in this particular case, one HoA should be used as 508 a CoA bound to the other HoA. (see in Section 6.2.1 and 509 Section 6.3.1). In conclusion, reliability can only be achieved 510 in some cases, when flows are initiated via a HoA. 512 o Load Sharing 514 In Bidirectional Tunnel (BT) mode, load sharing only affects the 515 path between the CN and the HA(s), and not the path between the MN 516 and the HA(s), as long as the CoA does not change. In RO mode, 517 the path between the MN and the CN does not change if the CoA does 518 not change. As an entry in the binding cache is identified by a 519 HoA, the MN can register the same CoA with all HoAs, on any 520 distant node. A mechanism would then be needed for the MN to 521 select which HoA should be used when a new communication flow is 522 initiated. A similar mechanism is needed on the CN side if it 523 knows that multiple HoAs are assigned to the same MN. With such 524 mechanisms, it would be possible to use multiple HoAs at the same 525 time, and load sharing could be performed. However, it can be 526 noted that load sharing on the path between the CN and the HA 527 might not be the most bandwidth contraint part of the overall path 528 from the CN to the MN. Thus load sharing might not bring 529 important benefits. See in Section 6.1.3 where such path 530 selection issues are discussed. It is also possible that the MN 531 register one HoA as a CoA for another HoA (see in Section 6.3.1). 533 o Flow Distribution 535 This is achievable when the MN is attached to one foreign link via 536 one of its interfaces and to the home link(s) via its other 537 interface(s). In this case, the MN can spread flows over its 538 interfaces. Note that if a CN initiates a communication, the 539 interface that it will use on the MN would depend on the 540 information it has about this MN. 542 5.3. (1,n): 1 HoA, n CoAs 544 A MN in this configuration is multihomed since it has several CoAs. 545 It may occur when the MN has multiple interfaces connected to 546 different links, or when the only interface is connected to a link 547 where multiple IPv6 prefixes are advertised (i.e. the visited network 548 is multihomed). Note that one of the interfaces of the MN may be 549 connected to its home link. 551 Current situation with MIPv6: 553 o Reliability 555 Reliability support is limited to recover from a failed CoA. 556 Fault recovery is achieved in MIPv6 by associating an alternate 557 CoA to replace the failed one. However, efficient mechanisms are 558 needed to determine that a CoA has failed (see Section 6.1.1), to 559 check reachability (Section 6.1.2), to determine which CoA should 560 be used instead (Section 6.1.3) and to redirect flows to the new 561 CoA (Section 6.1.4). 563 o Load Sharing and Flow Distribution 565 This configuration allows to share the load and to set preferences 566 among different paths between the HA and the MN when BT mode is 567 used, and between the CN and the MN when RO mode is used. In 568 order to achieve load sharing and flow distribution under this 569 scenario, the MN would need to register several CoAs with its 570 unique HoA. However, the present specification of MIPv6 only 571 allows the MN to register a single CoA per HoA. This is discussed 572 in Section 6.2.1. When a single HoA is bounded to several CoAs at 573 the same time, the MN or HA/CN must be able to select the 574 appropriate CoA. This selection could be done based on user/ 575 application preferences (see Section 6.1.3). 577 5.4. (n,n): n HoAs, n CoAs 579 A MN in this configuration is multihomed since it has multiple 580 addresses. This case can be viewed as a combination of the two cases 581 described above: the MN has several HoAs, e.g. given by different 582 operators (similar to case (n,1) in Section 5.2) and several CoAs, 583 e.g. because the node is receiving multiple IPv6 prefixes (similar to 584 case (1,n) in Section 5.3). As an example, we can consider a node 585 with three interfaces, two of them connected to their home link (two 586 different HoAs) and the last one connected to a visited link where 587 two IPv6 prefixes are available. 589 Current situation with MIPv6: 591 o Reliability 593 If one CoA becomes unreachable (similar to (1,n)), the MN can 594 redirect flows to another CoA by associating any of the other 595 available CoAs to the corresponding HoA. If the MN can not use 596 one of its HoA anymore (similar to (n,1)), the MN will have to re- 597 initiate all flows which were using the corresponding HoA. 598 Redirection between the addresses available for the MN will be 599 different depending on this HoA / CoA binding policies. 601 o Load Sharing and Flow Distribution 603 MIPv6 allows the MN to register only one CoA per HoA (see 604 Section 6.2.1), but it can register the same or different CoAs 605 with multiple HoAs. If the MN chooses to bind the same CoA to all 606 its HoAs, we fall in the (n,1) case. In this case, load sharing 607 can only be performed if route optimization is not used, on the 608 CN-HA path, as a different HoA may be used per CN. If the MN 609 chooses to bind a different CoA for each HoA, load sharing will be 610 done along the whole path across the MN and its CNs. Preference 611 settings may define which CoA (eventually several if bi-casting is 612 used) should be bound to which HoA (see Section 6.1.3). 614 In a very specific situation, one of the routable address of the 615 MN (i.e., which can be directly used without tunneling to reach 616 the MN) can be one of its HoA. This HoA would then be viewed as a 617 CoA bound to another HoA (similar to (n,1)). MIPv6 does not 618 prevent this behavior, which allows to set a certain preference on 619 addresses usage. See Section 6.3.1 for the corresponding issue. 621 5.5. (n,0): n HoAs, no CoAs 623 This case happens when all the interfaces are connected to their 624 respective home links. This situation is quite similar to a 625 multihomed fixed node. The node would no longer be in the (n,0) 626 configuration when one or more of the interfaces are attached to 627 foreign links. 629 The mobile node may wish to use one or more HoAs to serve as the CoA 630 of another HoA (see Section 6.3.1). In such situations, this 631 scenario is reduced to a (1,1) or (1,n) configuration as described in 632 Section 5.1 and Section 5.3, respectively. 634 Current situation with MIPv6 636 o Reliability 638 If the MN is disconnected from one of its interfaces, the MN 639 should be able to register another valid HoA as a CoA bound to its 640 failed HoA (see issue Section 6.3.1). 642 o Load Sharing, Flow Distribution 644 This can be achieved when the MN is initiating the communication 645 flow, as it can choose which HoA should be used. Depending on how 646 CN can discover HoAs of the MN, these goals might also be achieved 647 when the CN is initiating the communication flow. See previous 648 scenario and discussions in Section 6.1.3 about the path 649 selection. If the flows binding on interfaces preferences change 650 over time, the MN should be able to redirect one flow from one 651 interface to another. However, MIPv6 only allows to redirect all 652 flows from one interface to another, assuming one HoA is 653 registered as CoA (see issue Section 6.3.1). If the MN policies 654 indicate to redirect only one flow, a supplementary mechanism 655 would be needed. 657 6. Multihoming Issues 659 Existing protocols may not be able to handle the requirements 660 expressed in Section 3. For doing so, the issues discussed in this 661 section must be addressed, and solved preferably by dynamic 662 mechanisms. Note that some issues are pertaining to MIPv6 solely, 663 whereas other issues are not at all related to MIPv6. However, such 664 non MIPv6 issues must be solved in order to meet the requirements 665 outlined in Section 3. 667 In this section, we describe some of these issues in two main 668 headings: general IPv6-related issues (Section 6.1), and issues that 669 are specific to MIPv6 (Section 6.2). Other concerns related to 670 implementations of MIPv6 are described in Section 6.3. Issues and 671 their area of application are summarized in Section 6.4 673 6.1. General IPv6-related Issues 675 6.1.1. Failure Detection 677 It is expected for faults to occur more readily at the edge of the 678 network (i.e. the mobile nodes), due to the use of wireless 679 connections. Efficient fault detection mechanisms are necessary to 680 recover in timely fashion. A failure in the path between two nodes 681 can be located at many different places: the media of one of the node 682 is broken (i.e., loss of connectivity), the path between the MN and 683 the HA is broken, the home link is disconnected from the Internet, 684 etc. The failure protection domain greatly varies. In some 685 configurations, the protection domain is limited to a portion of the 686 path. 688 So far, MIPv6 only relies on the ability or the inability to receive 689 Router Advertisements within a stipulated period to detect the 690 availability or loss of media (local failure). 692 [5] is addressing such concerns through the use of layer 2 triggers 693 [6]. Movement detection might be extended to include other triggers 694 such as the loss of connectivity on one interface. Additional 695 mechanisms would be needed to detect a failure in the path between a 696 MN and its CN(s), as well as between the MN and its HA(s), between 697 the MN and CN(s), or between the HA and CN(s). 699 6.1.2. Path Exploration 701 When the MN needs to re-home a communication to an alternative path, 702 a path exploration may take place. The path exploration is a step 703 that occurs after the failure detection, and before the path 704 selection. It consists of identifying a set of paths that are known 705 to provide bidirectional connectivity between the MN and its HA, and 706 optionally between the MN and its CN. It may be noted that the step 707 of path exploration may be avoided by selecting a new path, and 708 trying to re-home the communications on this new path. If the re- 709 homing fails, a new path is selected until there is no alternate 710 path, or the re-homing signaling succeed. 712 Path exploration requires some signaling between pairs of address to 713 check reachability. An additional protocol may be needed to perform 714 this task. 716 In (1, *), the path exploration consists in checking reachability 717 between each CoA and each HA address. If RO mode is used, the MN may 718 also insure reachability between its CNs address(es) and each CoA. 720 In (n, *), the path exploration consists in checking reachability 721 between the HoA that is used with the session that must be re-homed 722 and each CoA (and optionnally with the CN address(es)). In addition, 723 the session may need to be re-homed to a different HoA. In this 724 case, each path between a pair (HoA, CoA) must to be validated. 726 In all these cases the path between the HA and the CN is not checked. 727 A specific mechanism may be defined to check reachability between a 728 HA and a CN. 730 6.1.3. Path Selection 732 When there exists multiple paths from and to the MN, the MN ends up 733 choosing a source address, and possibly the interface that should be 734 used. A CN that wants to establish a communication with such a MN 735 may end up by choosing a destination address for this MN. 737 o Interface selection 739 When the node has multiple available interfaces, the simultaneous 740 or selective use of several interfaces would allow a mobile node 741 to spread flows between its different interfaces. 743 Each interface could be used differently according to some user 744 and applications policies and preferences that would define which 745 flow would be mapped to which interface and/or which flow should 746 not be used over a given interface. How such preferences would be 747 set on the MN is out of scope of MIPv6 and might be implementation 748 specific. On the other hand, if the MN wishes to influence how 749 preferences are set on distant nodes (Correspondent Node or Home 750 Agent), mechanisms such as those proposed in 751 draft-soliman-flow-binding [7] could be used. 753 o HoA Selection 755 When multiple HoAs are available, the MN and its communicating 756 peers (HA and CNs) must be able to select the appropriate HoA to 757 be used for a particular packet or flow. 759 This choice would be made at the time of a new communication flow 760 set up. Usual IPv6 mechanisms for source and destination address 761 selection, such as "Default Address Selection for IPv6" (RFC3484) 762 [8] or DNS SRV Protocol (RFC2782) [9] could be used. 764 However, in RFC3484 it is said that "If the eight rules fail to 765 choose a single address, some unspecified tie-breaker should be 766 used". Therefore more specific rules in addition to those 767 described in RFC3484 may be defined for HoA selection. 769 o CoA Selection 771 When multiple CoAs are available, the MN and its communicating 772 peers (HA and CNs) must be able to select the appropriate CoA to 773 be used for a particular packet or flow. The MN may use its 774 internal policies to (i) distribute its flow, and (ii) distribute 775 policies on distant nodes to allow them to select the preferred 776 CoA. Solutions like draft-soliman-flow-binding [7] may be used. 778 Another related aspect of path selection is the concern of ingress 779 filtering. This is covered below in Section 6.1.5. 781 6.1.4. Rehoming 783 Re-homing takes place after an outage has been detected or an 784 alternative path has been identified (see previous issues 785 Section 6.1.1, Section 6.1.2 and Section 6.1.3), therefrom diverting 786 existing sessions from one path to another. New transport sessions 787 would have to be established over the alternate path if no mechanism 788 is provided to redirect flow transparently at layers above layer 3. 789 The need for re-homing or flow redirection is explained in Appendix A 791 The different mechanisms that can be used to provide re-homing can be 792 split into three categories, depending on the part of the path that 793 needs to be changed. 795 The first category is the CoA changes : it influences the path 796 between the MN and its HA, and the path between the MN and its CN in 797 RO mode. This may hold in case (n, n). 799 The second category is when the HoA changes (: it influences the 800 entire path. As the HoA is the address shown to the higher layer 801 (above layer 3), an additional mechanism is needed to manage this 802 change. Solution with a shim layer (e.g., Shim6 [REF shim6 TO BE 803 ADDED]), or solution at the transport layer such as SCTP [REF SCTP TO 804 BE ADDED] may be useful. 806 The third category is when the HA address changes. In this case, the 807 bidirectional tunnel between the MN and its HA as to be switched to 808 the new address of the HA. This can be managed transparently by 809 MIPv6 if the HoA doesn't change at the same time. Otherwise, 810 sessions continuity is not ensured, as explained in the above 811 paragraph. 813 6.1.5. Ingress Filtering 815 Ingress filtering mechanisms [10][11] may drop the outgoing packets 816 when multiple bi-directional tunnels end up at different HAs. This 817 could particularly occur if different prefixes are handled by 818 different HAs. If a packet with a source address configured from a 819 specific prefix is tunneled to a HA that does not handle that 820 specific prefix, the packet may be discarded either by the HA or by a 821 border router in the home network. The problem of ingress filtering 822 however, is two-fold. It can occur in the access network as well as 823 the home network. 825 Suppose MN selects the interface (which would determine the CoA) and 826 the home network (which would determine the HoA): the chosen CoA may 827 not be registered with the chosen HoA. For instance, consider 828 Figure 2 below. In the access network, the MN must use CoA=PA.MN 829 when it sends packets through AR-A and it must use CoA=PB.MN when it 830 sends a packet through AR-B. In the home network, it must use 831 HoA=P1.MN when it tunnels the packet to home agent HA-1, and it must 832 use HoA=P2.MN when it tunnels the packet to home agent HA-2. To 833 avoid ingress filtering, the choice is thus limited to a of valid 834 (HoA,CoA) pairs. This issue is related to Section 6.1.3 greatly 835 limits the way MN can benefit from its multihoming configuration 836 (particularly in case of the HA failure since flows cannot be 837 diverted to the other HA). 839 Prefix: PA +------+ +----------+ +------+ 840 HoA: P1.MN /-----| AR-A |----| |----| HA-1 | 841 CoA: PA.MN / +------+ | | +------+ 842 +----+ | | Prefix: P1 843 | MN | | Internet | 844 +----+ | | Prefix: P2 845 HoA: P2.MN \ +------+ | | +------+ 846 CoA: PB.MN \-----| AR-B |----| |----| HA-2 | 847 Prefix: PB +------+ +----------+ +------+ 849 Figure 2: MN connected to Multiple Access/Home Networks 851 Should the MN be able to bind both CoAs PA.MN and PB.MN 852 simultaneously to HoAs P1.MN and P2.MN respectively (see 853 Section 6.2.1), it would be able to choose the (HoA,CoA) pair based 854 on the access network it wishes to use for outgoing packets. It is, 855 nonetheless, still limited to transmit all packets to a specific HA 856 for the selected (HoA,CoA) pair, i.e. ingress filtering at the home 857 network remains unsolved). 859 Ingress filtering in the home network concerns only the (n,n) case 860 since the choice of the HoA and CoA is limited to a single (HoA, CoA) 861 pair in other cases. In (n,n), the MN may be connected to multiple 862 access networks or multiple home networks each practicing ingress 863 filtering. To overcome this, mechanisms such as those provided by 864 Shim6 (see RFC3582 [12] and [13]) may be used. 866 6.2. MIPv6-specific Issues 868 6.2.1. Binding Multiple CoAs to a given HoA 870 In the (1,n) cases, multiple CoAs would be available to the MN. In 871 order to use them simultaneously, the MN must be able to bind and 872 register multiple CoAs for a single HoA with both the HA and the CNs. 873 The MIPv6 specification is currently lacking such ability. 875 Although in the (n,n) cases, MIPv6 allows MN to have multiple 876 (HoA,CoA) pairs, the upper layer's choice of using a particular HoA 877 would mean that the MN is forced to use the corresponding CoA. This 878 constrains the MN from choosing the best (in terms of cost, bandwidth 879 etc) access link for a particular flow, since CoA is normally bound 880 to a particular interface. If the MN can register all available CoAs 881 with each HoA, this would completely decouple the HoA from the 882 interface, and allow the MN to fully exploit its multihoming 883 capabilities. 885 To counter this issue, a solution like [14] may be used. 887 6.2.2. Simultaneous Location in Home and Foreign Networks 889 Rule 4 of RFC3484 (section 5) specifies that a HoA should be 890 preferred to a CoA. While this rule allows the host to choose which 891 address to use, it does not allow the MN to benefit from being 892 multihomed in a situation where it may have one of its interfaces 893 directly connected to a home link. That is, addresses from other 894 interfaces cannot be registered as CoAs for the HoA associated to the 895 home link the mobile node is connected to. As a result, flows cannot 896 be redirected transparently from one CoA to another and MIPv6 897 features can only recover the failure of the HoA. 899 In the special case of (1,*) where one of the interface is connected 900 to the home link, none of the other addresses can be used to achieve 901 multihoming goals with the HA. 903 6.2.3. HA Synchronization 905 In the (n,*) cases, HoAs may be obtained from different HAs. If any 906 failure is affecting ongoing sessions on a given HoA (HA has failed 907 or is overloaded), there is currently no failover allowing existing 908 sessions to be shifted from one HA to another tough certain level of 909 co-ordination between HAs on registered bindings would be useful. 910 This co-ordination could further be extened to all (*,*) cases where 911 distinct HAs would be co-ordinated to register CoAs for the same HoA. 912 HA synchronization mechanisms such as these described in [15] and 913 [16] could be used. 915 6.3. Considerations for MIPv6 Implementation 917 In addition to the issues described in Section 6.1 and Section 6.2, 918 there are other concerns implementers should take into consideration 919 so that their MIPv6 implementations are more "friendly" to 920 multihoming, particularly the use of multiple interfaces. These 921 implementation-related considerations are described in the sub- 922 sections below. 924 6.3.1. Using one HoA as a CoA 926 In (n,*) cases, the MN has multiple HoAs. A HoA may be seen as a CoA 927 from the perspective of another home link of the same MN. 929 As an example, a MN has two HoAs (HoA1 and HoA2) on two distinct home 930 links. MN is connected to these two home links via two interfaces. 931 MN looses its connectivity on its first interface and HoA1 is not 932 reachable. It may then want to register HoA2 as a CoA for HoA1 in 933 order to keep receiving packets intended to HoA1, via the second 934 interface. 936 According to the definition of a CoA, the current MIPv6 specification 937 does not prohibit to register a HoA as the CoA from the perspective 938 of another HoA. 940 In RFC3775 section 6.1.7 it is written: "Similarly, the Binding 941 Update MUST be silently discarded if the care-of address appears as a 942 home address in an existing Binding Cache entry, with its current 943 location creating a circular reference back to the home address 944 specified in the Binding Update (possibly through additional 945 entries)." 947 In order to benefit from any multihoming configuration, a MN must be 948 able to register whatever address it owns with any of its HoA, as 949 long as the above statement is observed. 951 6.3.2. Binding a new CoA to the Right HoA 953 In the (n,*) cases, the MN has multiple HoAs. When the MN moves and 954 configures a new CoA, the newly obtained CoA must be bound to a 955 specific HoA. The current MIPv6 specification doesn't provide a 956 decision mechanism to determine to which HoA this newly acquired CoA 957 should be bound to. 959 With no such mechanism, the MN may be confused and may bind this CoA 960 to a possibly wrong HoA. The result might be to bind the CoA to the 961 same HoA the previous CoA was bound to or to another one, depending 962 on the implementation. It would indeed be better to specify the 963 behavior so that all implementations are compliant. 965 6.3.3. Binding HoA to interface 967 In (n,*) cases, MIPv6 does not provide any information on how HoAs 968 should be bound to a device, and particularly there is no mechanism 969 to bind HoAs to interfaces. 971 This may be troublesome, for example, when we consider a MN 972 configured with two HoAs and equipped with three interfaces. When 973 the MN is connected to a home link via one interface, it will need to 974 bind the corresponding HoA to this interface, even if the HoA was 975 initially assigned to another one. 977 HoA1 HoA2 979 CoA1 CoA2 CoA3 980 Iface1 Iface2 Iface3 982 Figure 3: Illustration of the case (2,3) 984 HoA must always be assigned to an activated interface and if the MN 985 is connected to its home link, the corresponding HoA must be used on 986 this interface. In some cases, the HoA then would have to be re- 987 assigned to another interface in case of connection loss or 988 attachment to the home link. 990 6.4. Summary 992 The table below summarizes the cases where each issue applies (TO BE 993 CHECKED AND COMPLETED) 995 +=====================================================+ 996 | # of HoAs: | 1 | 1 | n | n | n | 997 | # of CoAs: | 1 | n | 0 | 1 | n | 998 +=====================================================+ 999 | General IPv6 Issues | 1000 +---------------------------------+---+---+---+---+---+ 1001 | Failure detection |o | o | ? | o | o | 1002 +---------------------------------+---+---+---+---+---+ 1003 | Path Exploration | | | | | | 1004 +---------------------------------+---+---+---+---+---+ 1005 | Path Selection | | o | ? | o | o | 1006 +---------------------------------+---+---+---+---+---+ 1007 | Flow redirection | o | o | ? | o | o | 1008 +---------------------------------+---+---+---+---+---+ 1009 | Ingress Filtering | | | ? | o | o | 1010 +---------------------------------+---+---+---+---+---+ 1011 | MIPv6-Specific Issues | 1012 +---------------------------------+---+---+---+---+---+ 1013 | Binding Multiple CoAs to a | | o | ? | o | o | 1014 | given HoA | | | | | | 1015 +---------------------------------+---+---+---+---+---+ 1016 | Simultaneous location in home | | o | ? | o | o | 1017 | and foreign networks | | | ? | | | 1018 +---------------------------------+---+---+---+---+---+ 1019 | HA Synchronization | | | | | | 1020 +---------------------------------+---+---+---+---+---+ 1021 | Implementation-Related Concerns | 1022 +---------------------------------+---+---+---+---+---+ 1023 | Using one HoA as a CoA | | | ? | o | o | 1024 +---------------------------------+---+---+---+---+---+ 1025 | Binding a new CoA to the | | | ? | o | o | 1026 | right HoA | | | | | | 1027 +---------------------------------+---+---+---+---+---+ 1028 | Binding HoA to interface(s) | o | o | ? | o | o | 1029 +=====================================================+ 1031 Figure 4: Summary of Issues and Categorization 1033 7. Conclusion 1035 In this document, we have demonstrated issues arising for multihomed 1036 mobile nodes operating Mobile IPv6. We have seen that mechanisms are 1037 needed: 1039 o to redirect flows from a failed path to a new path, 1041 o to decide which path should better be taken when multiple paths 1042 are available, 1044 o to register multiple Care-of Addresses 1046 o to exchange policies between the Mobile Router and the Home Agent 1048 Even if Mobile IPv6 can be used as a mechanism to manage multihomed 1049 mobile nodes, triggers of flow redirection between interfaces/ 1050 addresses are not adapted to the multihoming status of the node. 1051 Also, we have shown that in some configurations Mobile IPv6 is 1052 ambiguous in the definitions of CoA/HoA and in the mappings between 1053 HoAs, CoAs and network interfaces. Finally, we have also raised 1054 issues not directly related to Mobile IPv6, but solutions for these 1055 issues are needed for mobile nodes to fully take advantage of their 1056 multihomed configuration. 1058 8. IANA Considerations 1060 This is an informational document and as such does not require any 1061 IANA action. 1063 9. Security Considerations 1065 This is an informational document where the multihoming 1066 configurations under the operation of Mobile IPv6 are analyzed. 1067 Security considerations of these multihoming configurations, should 1068 they be different from those that concern Mobile IPv6, must be 1069 considered by forthcoming solutions. 1071 10. Contributors 1073 The following people have contributed ideas, text and comments to 1074 earlier versions of this document: Eun Kyoung Paik from Seoul 1075 National University, South Korea and Thomas Noel from Universite 1076 Louis Pasteur, Strasbourg, France. 1078 11. Acknowledgments 1080 The authors would like to thank all the people who have sent comments 1081 so far, particularly Tobias Kufner, Marcelo Bagnulo, Romain Kuntz and 1082 Henrik Levkowetz for their in-depth comments and raising new issues. 1084 12. References 1086 12.1. Normative References 1088 [1] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in 1089 IPv6", RFC 3775, June 2004. 1091 [2] Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to 1092 Protect Mobile IPv6 Signaling Between Mobile Nodes and Home 1093 Agents", RFC 3776, June 2004. 1095 [3] Ernst, T., Montavont, N., Wakikawa, R., Ng, C., and K. 1096 Kuladinithi, "Motivations and Scenarios for Using Multiple 1097 Interfaces and Global Addresses", 1098 draft-ietf-monami6-multihoming-motivation-scenario-01 (work in 1099 progress), October 2006. 1101 [4] Manner, J. and M. Kojo, "Mobility Related Terminology", 1102 RFC 3753, June 2004. 1104 12.2. Informative References 1106 [5] Choi, JH. and G. Daley, "Goals of Detecting Network Attachment 1107 in IPv6", RFC 4135, August 2005. 1109 [6] Krishnan, S., Montavont, N., Yegin, A., Veerepalli, S., and A. 1110 Yegin, "Link-layer Event Notifications for Detecting Network 1111 Attachments", draft-ietf-dna-link-information-06 (work in 1112 progress), February 2007. 1114 [7] Soliman, H., Montavont, N., Fikouras, N., and K. Kuladinithi, 1115 "Flow Bindings in Mobile IPv6", 1116 draft-soliman-monami6-flow-binding-04 (work in progress), 1117 February 2007. 1119 [8] Draves, R., "Default Address Selection for Internet Protocol 1120 version 6 (IPv6)", RFC 3484, February 2003. 1122 [9] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 1123 specifying the location of services (DNS SRV)", RFC 2782, 1124 February 2000. 1126 [10] Ferguson, P. and D. Senie, "Network Ingress Filtering: 1127 Defeating Denial of Service Attacks which employ IP Source 1128 Address Spoofing", BCP 38, RFC 2827, May 2000. 1130 [11] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 1131 Networks", BCP 84, RFC 3704, March 2004. 1133 [12] Abley, J., Black, B., and V. Gill, "Goals for IPv6 Site- 1134 Multihoming Architectures", RFC 3582, August 2003. 1136 [13] Nordmark, E. and M. Bagnulo, "Level 3 multihoming shim 1137 protocol", draft-ietf-shim6-proto-08 (work in progress), 1138 May 2007. 1140 [14] Wakikawa, R., Ernst, T., Nagami, K., and V. Devarapalli, 1141 "Multiple Care-of Addresses Registration", 1142 draft-ietf-monami6-multiplecoa-02 (work in progress), 1143 March 2007. 1145 [15] Wakikawa, R., Devarapalli, V., and P. Thubert, "Inter Home 1146 Agents Protocol (HAHA)", draft-wakikawa-mip6-nemo-haha-01 (work 1147 in progress), February 2004. 1149 [16] Koh, B., Ng, C., and J. Hirano, "Dynamic Inter Home Agent 1150 Protocol", draft-koh-mip6-nemo-dhap-00 (work in progress), 1151 July 2004. 1153 Appendix A. Why a MN may want to redirect flows 1155 When a MN is multihomed, an addresses selection mechanism is needed 1156 to distribute flows over interfaces. As policies may change over 1157 time, as well as the available addresses/interfaces, flow redirection 1158 mechanisms are needed. While the selection policy is out of scope of 1159 this document, the following reasons may trigger the MN to redirect 1160 flow from one address to another: 1162 o Failure detection: the path between the MN and its CN(s) is 1163 broken. The failure can occur at different places onto this path; 1164 The failure can be local on the MN, where the interface used on 1165 the MN is disconnected from the network (e.g., a wireless 1166 interface which comes out of range from its point of attachment). 1167 Alternatively, the failure can be on the path between the MN and 1168 one of its HA. Yet another alternative is that the failure can be 1169 on the path between the HA and the CN. If route optimization is 1170 used, it can also be a failure between the MN and its CN(s). 1172 o New address: a new address on the MN may become available, e.g. 1173 when the MN connects to the network with a new interface. The MN 1174 may decide that this new interface is most suitable for its 1175 current flows that are using another interface. 1177 o 1179 o Uninterrupted horizontal handover in mobility: If the MN is 1180 mobile, it may have to change its point of attachment. When a MN 1181 performs a horizontal handover, the handover latency (the time 1182 during which the MN can not send nor receive packets) can be long 1183 and the flows exchanged on the interface can be interrupted. If 1184 the MN wants to minimize such perturbation, it can redirect some 1185 or all the flows on another available interface. This redirection 1186 can be done prior to the handover if L2 triggering is considered 1187 [6] . 1189 o Change in the network capabilities: the MN can observe a 1190 degradation of service on one of its interface, or conversely an 1191 improvement of capacity on an interface. The MN may then decide 1192 to redirect some or all flows on another interface that it 1193 considers most suitable for the target flows. 1195 o Initiation of a new flow: a new flow is initiated between the MN 1196 and a CN. According to internal policies, the MN may want to 1197 redirect this flow on a most suitable interface. 1199 Authors' Addresses 1201 Nicolas Montavont 1202 Ecole Nationale Superieure des telecommunications de Bretagne 1203 2, rue de la chataigneraie 1204 Cesson Sevigne 35576 1205 France 1207 Phone: (+33) 2 99 12 70 23 1208 Email: nicolas.montavont@enst-bretagne.fr 1209 URI: http://www-r2.u-strasbg.fr/~montavont/ 1211 Ryuji Wakikawa 1212 Keio University 1213 Department of Environmental Information, Keio University. 1214 5322 Endo 1215 Fujisawa, Kanagawa 252-8520 1216 Japan 1218 Phone: +81-466-49-1100 1219 Fax: +81-466-49-1395 1220 Email: ryuji@sfc.wide.ad.jp 1221 URI: http://www.wakikawa.org/ 1223 Thierry Ernst 1224 INRIA 1225 INRIA Rocquencourt 1226 Domaine de Voluceau B.P. 105 1227 Le Chesnay, 78153 1228 France 1230 Phone: +33-1-39-63-59-30 1231 Fax: +33-1-39-63-54-91 1232 Email: thierry.ernst@inria.fr 1233 URI: http://www.nautilus6.org/~thierry 1234 Chan-Wah Ng 1235 Panasonic Singapore Laboratories Pte Ltd 1236 Blk 1022 Tai Seng Ave #06-3530 1237 Tai Seng Industrial Estate 1238 Singapore 534415 1239 SG 1241 Phone: +65 65505420 1242 Email: chanwah.ng@sg.panasonic.com 1244 Koojana Kuladinithi 1245 University of Bremen 1246 ComNets-ikom,University of Bremen. 1247 Otto-Hahn-Allee NW 1 1248 Bremen, Bremen 28359 1249 Germany 1251 Phone: +49-421-218-8264 1252 Fax: +49-421-218-3601 1253 Email: koo@comnets.uni-bremen.de 1254 URI: http://www.comnets.uni-bremen.de/~koo/ 1256 Full Copyright Statement 1258 Copyright (C) The IETF Trust (2007). 1260 This document is subject to the rights, licenses and restrictions 1261 contained in BCP 78, and except as set forth therein, the authors 1262 retain all their rights. 1264 This document and the information contained herein are provided on an 1265 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1266 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1267 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1268 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1269 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1270 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1272 Intellectual Property 1274 The IETF takes no position regarding the validity or scope of any 1275 Intellectual Property Rights or other rights that might be claimed to 1276 pertain to the implementation or use of the technology described in 1277 this document or the extent to which any license under such rights 1278 might or might not be available; nor does it represent that it has 1279 made any independent effort to identify any such rights. Information 1280 on the procedures with respect to rights in RFC documents can be 1281 found in BCP 78 and BCP 79. 1283 Copies of IPR disclosures made to the IETF Secretariat and any 1284 assurances of licenses to be made available, or the result of an 1285 attempt made to obtain a general license or permission for the use of 1286 such proprietary rights by implementers or users of this 1287 specification can be obtained from the IETF on-line IPR repository at 1288 http://www.ietf.org/ipr. 1290 The IETF invites any interested party to bring to its attention any 1291 copyrights, patents or patent applications, or other proprietary 1292 rights that may cover technology that may be required to implement 1293 this standard. Please address the information to the IETF at 1294 ietf-ipr@ietf.org. 1296 Acknowledgment 1298 Funding for the RFC Editor function is provided by the IETF 1299 Administrative Support Activity (IASA).