idnits 2.17.1 draft-ietf-monami6-mipv6-analysis-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 22. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1189. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1200. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1207. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1213. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** 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 856: '... 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 (February 26, 2007) is 6262 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '14' is defined on line 1070, but no explicit reference was found in the text ** 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 -- Possible downref: Normative reference to a draft: ref. '2' ** Downref: Normative reference to an Informational RFC: RFC 3753 (ref. '3') == Outdated reference: A later version (-05) exists of draft-soliman-monami6-flow-binding-00 -- Possible downref: Normative reference to a draft: ref. '4' ** Obsolete normative reference: RFC 3484 (ref. '5') (Obsoleted by RFC 6724) ** Downref: Normative reference to an Informational RFC: RFC 3582 (ref. '9') == Outdated reference: A later version (-12) exists of draft-ietf-shim6-proto-07 ** Downref: Normative reference to an Informational draft: draft-ietf-dna-goals (ref. '11') == Outdated reference: A later version (-06) exists of draft-ietf-dna-link-information-05 ** Downref: Normative reference to an Informational draft: draft-ietf-dna-link-information (ref. '12') == Outdated reference: A later version (-14) exists of draft-ietf-monami6-multiplecoa-00 Summary: 12 errors (**), 0 flaws (~~), 8 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IETF MONAMI6 Working Group N. Montavont 3 Internet-Draft GET/ENST-B 4 Expires: August 30, 2007 R. Wakikawa 5 Keio University 6 T. Ernst 7 INRIA 8 C. Ng 9 Panasonic Singapore Labs 10 K. Kuladinithi 11 University of Bremen 12 February 26, 2007 14 Analysis of Multihoming in Mobile IPv6 15 draft-ietf-monami6-mipv6-analysis-02.txt 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 August 30, 2007. 42 Copyright Notice 44 Copyright (C) The IETF Trust (2007). 46 Abstract 48 Mobile IPv6 as specified in RFC3775 [1] allows a mobile node to 49 maintain its IPv6 communications while moving between subnets. This 50 document investigates configurations where a mobile node running 51 Mobile IPv6 is multihomed. The use of multiple addresses is foreseen 52 to provide ubiquitous, permanent and fault-tolerant access to the 53 Internet, particularly on mobile nodes which are more prone to 54 failure or sudden lack of connectivity. However, Mobile IPv6 55 currently lacks support for such multihomed nodes. The purpose of 56 this document is to detail all the issues arising through the 57 operation of Mobile IPv6 on multihomed mobile nodes. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 65 3. Nodes capabilities . . . . . . . . . . . . . . . . . . . . . . 8 67 4. Taxonomy . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 69 5. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 12 70 5.1. (H1,C1): 1 HoA, 1 CoA . . . . . . . . . . . . . . . . . . 12 71 5.2. (Hn,C1): n HoAs, 1 CoA . . . . . . . . . . . . . . . . . . 13 72 5.3. (H1,Cn): 1 HoA, n CoAs . . . . . . . . . . . . . . . . . . 15 73 5.4. (Hn,Cn): n HoAs, n CoAs . . . . . . . . . . . . . . . . . 16 74 5.5. (Hn,C0): n HoAs, no CoAs . . . . . . . . . . . . . . . . . 17 76 6. Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 77 6.1. General IPv6-related Issues . . . . . . . . . . . . . . . 19 78 6.1.1. Path Selection . . . . . . . . . . . . . . . . . . . . 19 79 6.1.2. Ingress Filtering . . . . . . . . . . . . . . . . . . 20 80 6.1.3. Failure detection . . . . . . . . . . . . . . . . . . 21 81 6.2. MIPv6-specific Issues . . . . . . . . . . . . . . . . . . 21 82 6.2.1. Binding Multiple CoAs to a given HoA . . . . . . . . . 21 83 6.2.2. Simultaneous Location in Home and Foreign Networks . . 22 84 6.3. Considerations for MIPv6 Implementation . . . . . . . . . 22 85 6.3.1. Using one HoA as a CoA . . . . . . . . . . . . . . . . 22 86 6.3.2. Binding a new CoA to the Right HoA . . . . . . . . . . 23 87 6.3.3. Binding HoA to interface . . . . . . . . . . . . . . . 23 88 6.3.4. Flow redirection . . . . . . . . . . . . . . . . . . . 24 89 6.4. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 24 91 7. TODO List . . . . . . . . . . . . . . . . . . . . . . . . . . 26 92 8. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 27 94 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 28 96 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 29 98 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30 100 Appendix A. Why a MN may want to redirect flows . . . . . . . . . 32 102 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33 103 Intellectual Property and Copyright Statements . . . . . . . . . . 35 105 1. Introduction 107 The emergence of performant wireless technologies has favored node 108 mobility within the Internet. Nowadays, and even more tomorrow, 109 nodes are highly mobile and they can change their point of attachment 110 to the Internet at any time, even during active network connections. 111 Mobile IPv6 as specified in RFC3775 [1] allows mobile nodes to 112 maintain their communication while changing their point of attachment 113 to the Internet. 115 Besides, mobile nodes can be connected to multihomed networks or they 116 may have multiple interfaces to benefit from heterogeneous 117 technologies. The use of multiple addresses (allocated to either a 118 single interface or multiple interfaces) is foreseen to provide 119 ubiquitous, permanent and fault-tolerant access to the Internet, 120 particularly on mobile nodes which are prone to failure or sudden 121 lack of connectivity. However, the current specification of Mobile 122 IPv6 lacks support for mobile nodes with multiple addresses used 123 simultaneously, i.e. multihomed mobile nodes. These addresses would 124 be assigned to a single interface or to multiple interfaces, which 125 poses a number of issues. 127 This document has two goals. The first goal is to define the 128 requirements from the point of view of multihomed mobile nodes 129 operating Mobile IPv6. The second goal is to define the issues 130 arising when we attempt to fulfill these requirements. The 131 definition of the potentially needed solutions is out of scope of 132 this document. These should be defined in a separate document. 134 In order to reach the goals of this document, we define a taxonomy 135 which is used to describe the different situations where a mobile 136 node is multihomed. For each case, we show the configuration a 137 multihomed node may have (the number of Home Addresses, and the 138 number of Care-of Addresses). We also illustrate each scenario with 139 example diagrams. 141 To understand the foundation of this document, the reader should read 142 the companion document 143 draft-ietf-monami6-multihoming-motivation-scenario [2] which outlines 144 the motivations, the goals and the benefits of multihoming for both 145 fixed and mobile nodes (i.e. generic IPv6 nodes). Real-life 146 scenarios as illustrated in that document are the base motivations of 147 the present study. The reader should also understand the operation 148 of the Mobile IPv6 protocol (RFC3775 [1]). 150 The document is organized as follows: in Section 2, we introduce the 151 terminology related to multihoming and used in this document. In 152 Section 3, we discuss what is required on the mobile nodes to fully 153 benefit from a multihomed configuration. Then we propose in 154 Section 4 a taxonomy to classify the different cases where mobile 155 nodes are multihomed. Thereafter the taxonomy is used in Section 5 156 to describe a number of multihomed configuration specific to Mobile 157 IPv6. Finally we discuss in Section 6 and Section 6.3 all issues 158 related to a multihomed mobile node and we identify what is missing 159 in order to reach the goals outlined in 160 draft-ietf-monami6-multihoming-motivation-scenario [2]. These issues 161 are classified into IPv6 issues, Mobile IPv6-specific issues, and 162 advices to implementers. 164 2. Terminology 166 The terms used in the present document are defined in RFC3753 [3], 167 RFC3775 [1] and draft-ietf-monami6-multihoming-motivation-scenario 168 [2]. 170 In this draft we are using the following terms and abbreviations: 172 o MIPv6 174 The Mobile IPv6 protocol specified in RFC3775 [1] 176 o MN 178 a Mobile Node using MIPv6 180 o HA 182 a Mobile IPv6 Home Agent 184 o HoA 186 a Mobile IPv6 Home Address 188 o CoA 190 a Mobile IPv6 Care-of Address 192 o Multihomed MN 194 In the companion document [2], a node is said to be multihomed 195 when it has multiple IPv6 addresses, either because multiple 196 prefixes are advertised on the link(s) the node is attached to, or 197 because the node has multiple interfaces (see the entire 198 definition). For a mobile node operating MIPv6, this may 199 translate into the following definition: 201 A MN (as defined above) is said multihomed when it has either i) 202 multiple addresses which are used as source addresses or ii) 203 multiple tunnels to transmit packets, or both. A MN may have 204 multiple HoAs/CoAs in the following cases: 206 * A MN would have multiple HoAs if multiple prefixes are 207 available on the home link or if it has multiple interfaces 208 named on (presumably) distinct home links. 210 * A MN would have multiple CoAs if multiple prefixes are 211 available on the foreign link or if it has multiple interfaces 212 attached to (presumably) distinct foreign links. 214 o A valid address 216 An address that is topologically correct (it is configured from 217 the prefix available on the link the interface is attached to) and 218 routable. 220 o Simultaneously using multiple addresses 222 A MN is simultaneously using multiple addresses at the same time 223 when an incoming packet with the destination address set to any of 224 these addresses reaches the MN, or when any of these addresses can 225 be used by the MN to set the source address of outcoming packets. 227 o Simultaneously using multiple interfaces 229 A MN is simultaneously using multiple interfaces when it can 230 exchange IP packets over any of these interfaces. 232 3. Nodes capabilities 234 Generic goals and benefits of multihoming are discussed in 235 draft-ietf-monami6-multihoming-motivation-scenario [2]. These goals 236 are ubiquitous access, flow redirection, reliability, load sharing, 237 inteface switching, preference settings, and aggregate bandwidth. 238 These generic goals overlap, i.e., they are not totally independent. 239 Reaching one of them may imply to reach another goal as well. For 240 this reason, the following non-overlapping goals may be extracted 241 from these generic goals: 243 1. Reliability 245 2. Load Sharing 247 3. Interface switching/Flow Distribution 249 In this section, after determining a set of capabilities that allows 250 a MN to achieve these design goals, we explicitly indicate which 251 capability is needed to reach which goal. We will determine later in 252 the document (in Section 5) which capabilities are already fulfilled 253 by Mobile IPv6 and what issues remain. 255 Basically, Internet connectivity is guaranteed for a MN as long as at 256 least one path is maintained between the MN and the fixed Internet. 257 This path can be divided into two portions: the path between the MN 258 to its HA(s) and the path between the HA(s) and the CN. If RO is in 259 place between the MN and a CN, an additional path between the MN and 260 the CN must be guaranteed. In some cases, it may be necessary to 261 divert packets from a (perhaps failed) path to an alternative 262 (perhaps newly established) path (e.g. for matters of reliability, 263 preferences), or to split traffic between multiple paths (e.g. for 264 load sharing, interface switching). The use of an alternative path 265 must be transparent at layers above layer 3 if broken sessions and 266 the establishment of new transport sessions has to be avoided. 268 In order to meet some of the goals (particularly interface switching 269 and load sharing), multiple paths must be maintained simultaneously 270 between the mobile node and its CN. 272 This translates into the following capabilities: 274 1. A MN equipped with multiple global addresses must be able to use 275 them simultaneously 277 2. A MN equipped with multiple interfaces must be able to attach 278 distinct interfaces to distinct access networks (distinct foreign 279 links or distinct home links, or a combination of both). 281 3. A MN should be able to share its traffic load among its valid 282 global addresses 284 4. A mechanism should be available to quickly activate a backup 285 interface and redirect traffic when an interface fails (e.g., 286 loss of connection). 288 5. A mechanism should be available to quickly redirect flow from one 289 address to another when it is needed. Some of the triggers of 290 flow redirection are given in Appendix A. 292 6. If multiple HAs are available to manage bindings for a given HoA, 293 the MN should be able to use them simultaneously. 295 One has to consider whether these goals can be achieved with 296 transparency or without transparency. Transparency is achieved when 297 switching between interfaces does not cause the disruption of on- 298 going sessions. To be achieved with transparency, a necessary (may 299 or may not be sufficient) condition is for the end-point addresses at 300 the transport/application layer to remain unchanged. This is in view 301 of the large amount of Internet traffic currently carried by TCP, 302 which unlike SCTP, cannot handle multiple end-point address pairs. 304 Each of the aforementioned goals can be achieved independently. We 305 define here what of the above capabilities are needed for each goal: 307 1. Reliability: 2, 4, 5, 6 309 2. Load Sharing: 1, 6 311 3. Interface switching/Flow Distribution: 1, 2, 3, 5 313 4. Taxonomy 315 In order to examine the issues preventing a MIPv6 mobile node to meet 316 the requirements listed in Section 3 we use in the present document 317 the following taxonomy (Hx,Cy) where: 319 o x = number of Home Addresses (HoAs) 321 o y = number of Care-of Addresses (CoAs) 323 A value of '1' implies there is a single instance of the parameter, 324 whereas a value of 'n' indicates that there are multiple instances of 325 the parameter. A value '*' indicates that the number can be '1' or 326 'n'. 328 An illustration of this taxonomy is given in Figure 1. 330 Mobile Node 332 HoA1 HoA2 ... HoAn --> Permanent Address (Hx) 333 | | | 334 +-----+--------+ | | 335 | | | | | 336 CoA1 +--CoA2 +---CoA3 ... CoAn --> Temporary Address (Cy) 337 | | | | 338 Link1 Link2 Link3 ... Linkn --> IPv6 Link (n/a *) 339 | | | | 340 +-----+----+ | | 341 | | | 342 IF1 IF2 ... IFn --> Physical layer 344 CoA1, CoA2, CoA3 are bound to HoA1 on IF1 and IF2 345 CoA3 is bound to HoA2 on IF2 347 * because number of IPv6 links is equal to the number of CoAs, y 349 Figure 1: Illustration of the Taxonomy 351 As the taxonomy suggests, the fact that a mobile node has several 352 HoAs is independent from the fact that this mobile node has multiple 353 interfaces. The fact that a mobile node has multiple interfaces does 354 not imply that it has multiple HoAs and vice-versa. Similarly, the 355 number of CoAs is independent from the number of HoAs and the number 356 of interfaces. While a node would probably have at least one CoA per 357 interface, multiple prefixes available on a link may lead the node to 358 configure several CoAs on that link. 360 The proposed taxonomy has two parameters because each of them has an 361 influence on either the mobile node behavior / management, or the 362 potential benefits the mobile node may obtain from such a 363 configuration. 365 The configurations denoted by these parameters will have an impact on 366 the way multihoming is supported. Depending on the number of HoAs 367 and CoAs, different policies will be needed, such as "which CoA has 368 to be mapped to which HoA", "must all the CoAs be mapped with all the 369 HoAs", etc. 371 5. Scenarios 373 In this section, we detail the reachable multihoming goals under each 374 type of configuration. For each configuration, we give a basic 375 explanation and we list which of the goals outlined in Section 3 are 376 achievable provided that supporting mechanisms are either already 377 existing or could be added. Other goals are not achievable due to 378 the inherent configuration of the node. Then, we briefly discuss the 379 current situation with MIPv6 and we point to issues discussed later 380 in this document in Section 6.1, Section 6.2 and Section 6.3. 382 5.1. (H1,C1): 1 HoA, 1 CoA 384 A mobile node in this configuration with a single network interface 385 is not multihomed. This scenario is the common case of a MN running 386 Mobile IPv6 and away from its home link: the node has one HoA and one 387 CoA which is configured on the foreign link. None of the multihoming 388 goals are achievable. 390 When the node in the same configuration has several interfaces, it 391 may lead to a special situation where a node is connected to both its 392 home link and a foreign link. The MN is multihomed since it would be 393 able to use both interfaces. The Home Address might be directly used 394 on the interface which is connected to the home link, and a Care-of 395 Address is configured on the other interface which is connected to a 396 foreign link. There cannot be more than two active interfaces, 397 otherwise the mobile node would either have (A) multiple interfaces 398 on the home link, or (B) multiple interfaces on foreign links. For 399 (A), there would be multiple HoAs. For (B) there would be multiple 400 CoAs. These two cases would fall in another scenario, either (Hn,C*) 401 (see Section 5.2, Section 5.4 and Section 5.5) or (H*,Cn) (see 402 Section 5.3 and Section 5.4). 404 Achievable goals (when the node has a single interface): Reliability, 405 Load Sharing. 407 Achievable goals (when the node has multiple interfaces): 408 Reliability, Load Sharing, Interface switching 410 Current situation with MIPv6 (when the node has multiple interfaces): 412 o Reliability 414 These goals are achievable, but in a limited manner. The MN can 415 build a CoA on the interface connected to the foreign network, but 416 it cannot register the CoA with its HA and receive packets from 417 the HA via tunnel to the CoA at the same time it receives packet 418 on the HoA from the Home Link. As a result, without binding 419 separately to CNs (i.e. route optimization), the MN is not able to 420 use both addresses simultaneously. In addition, in case of 421 failure, the MN cannot redirect flows from one valid address to 422 another. If the MN looses its connection established using the 423 address on the foreign link, all flows must be re-initiated with 424 another address (either the HoA, or a new address obtained on 425 another foreign link). Fault recovery is thus only possible 426 without transparency, and the MIPv6 features can only recover the 427 failure of the Home Address. This issue is detailed in 428 Section 6.2.2. 430 It might be possible for MN to register the CoA with selected CNs 431 (i.e. route optimization). In this case, the MN can enjoy 432 benefits of increased reliability for communications sessions 433 opened with these CNs. When the CoA fails, the MN can either bind 434 a new CoA, or remove the binding and directly get the packets to 435 its HoA. 437 Reliability could be achieved through bi-casting since the MN has 438 two addresses and should be able to request any CN to duplicate 439 traffic to both of them. However, MIPv6 does not allow the MN to 440 request bi casting on the CN (see Section 6.2.2). 442 o Load Sharing, Interface Switching 444 The MN is able to use both interfaces at the same time, according 445 to some preference settings on its side to decide which one to use 446 for which application. Therefore load sharing and interface 447 switching can be achieved when sessions are initiated by the MN. 448 When a CN initiates a session with the MN, it would choose the 449 destination address depending on the available information about 450 the MN (e.g., DNS request). Presently there is no mechanism 451 allowing the MN to indicate on which interface (i.e., address) a 452 CN may reach it. If only one address is known by the distant 453 node, load sharing and interface switching cannot be achieved. 454 See in Section 6.1.1 where such path selection issues are 455 discussed. 457 5.2. (Hn,C1): n HoAs, 1 CoA 459 The MN is multihomed, since it has several HoAs. This case may 460 happen when a node is getting access to the Internet through 461 different HAs (possibly distinct operators) and each offers a Mobile 462 IPv6 service to the node. That way, the node will have a HoA per HA. 463 Alternatively, a single home network may be multihomed to the 464 Internet, leading to having multiple prefixes on the home link. Thus 465 the MN would have multiple HoAs for a single home link. In either 466 case, the node would need to configure a single CoA on the visited 467 IPv6 subnet, and bind that single CoA to all the HoAs it owns. If 468 the MN has multiple interfaces, only one interface is connected to a 469 foreign network. The other interfaces are connected to their home 470 links, or are inactive. 472 Achievable goals: Reliability, Load Sharing, Interface switching (if 473 the MN has more than one interface) 475 Current situation with MIPv6: 477 o Reliability 479 In case a HoA fails, (a failure could happen in the home network 480 of the MN, e.g. when one HA of the MN is disconnected from the 481 network), the session using the HoA must be restarted since MIPv6 482 does not provide any mechanism to hand-over transparently from a 483 fail HoA to another one. Currently, fault tolerance cannot be 484 achieved in this case, since established communications cannot be 485 preserved. See the corresponding discussion in Section 6.3.4. 487 The CoA may change when the MN has multiple interfaces and is 488 disconnected from its home link (e.g. failure of the interface, or 489 movement). In such a situation, MIPv6 allows to transparently 490 redirect flows using the old CoA as a temporarily address (i.e. 491 the HoA was used as the main address) to another CoA. For 492 sessions directly opened via the CoA, the loss of the address 493 implies a re-initiation of the session. 495 In conclusion, fault recovery can only be done in some cases, when 496 flows were initiated via a HoA. 498 Achieving reliability through bi-casting could be achieved in this 499 scenario by registering two addresses with a single HoA. However 500 MIPv6 does not provide any mechanism to associate more than one 501 CoA with one HoA. Moreover, in this particular case, one HoA 502 should be taken as a CoA regarding the other HoA. (see discussions 503 in Section 6.2.1 and Section 6.3.1). 505 o Load Sharing 507 In Bidirectional Tunnel (BT) mode, load sharing only affects the 508 path between the CN and the HA(s), and not the path between the MN 509 and the HA(s), as long as the CoA does not change. In RO mode, 510 the path between the MN and the CN does not change if the CoA does 511 not change. As an entry in the binding cache is identified by a 512 HoA, the MN can register the same CoA with all HoAs, on any 513 distant node. A mechanism would then be needed for the MN to 514 select which HoA should be used when a new communication flow is 515 initiated. A similar mechanism is needed on the CN side if it 516 knows that multiple HoAs are assigned to the same MN. With such 517 mechanisms, it would be possible to use multiple HoAs at the same 518 time, and load sharing could be performed. However, it can be 519 noted that load sharing on the path between the CN and the MN's HA 520 might not be the most bandwidth contraint part of the overall path 521 from the CN to the MN. Thus this load sharing might not show 522 important enhancements. See in Section 6.1.1 where such path 523 selection issues are discussed. It is also possible that the MN 524 register one HoA as a CoA for another HoA (see discussions in 525 Section 6.3.1). 527 o Interface Switching 529 Interface switching is achievable when the MN has several 530 interfaces. In this case, the MN is attached to one foreign link 531 via one of its interfaces, and it is attached to home link(s) with 532 its other interface(s). In this case, the MN can spread flows 533 over its interfaces. Note that if a CN initiates a communication, 534 the interface that it will use on the MN would depend on the 535 information it has about this MN. 537 5.3. (H1,Cn): 1 HoA, n CoAs 539 The MN is multihomed since it has several CoAs. This case may for 540 instance occur when the interface of the node is connected to a link 541 where multiple IPv6 prefixes are available. One possible reason for 542 this is that the visited network is multihomed and because of that, 543 multiple prefixes are available in it, one per provider. Another 544 possible configuration is a MN with several interfaces connected to 545 different links. Note that one of the interfaces of the MN may be 546 connected to its home link. 548 Achievable goals: Reliability, Load Sharing, Interface switching (if 549 the MN is equipped with several interfaces) 551 Current situation with MIPv6: 553 o Reliability 555 Fault recovery will be limited to the case where one of the CoAs 556 become unreachable for a particular peer. For instance, a CoA may 557 become unreachable because the ISP which provides the IPv6 prefix 558 fails. Fault recovery in MIPv6 is achieved by associating an 559 alternate CoA to replace the failed one. However, efficient 560 mechanisms are needed to determine that a CoA has failed (see 561 Section 6.1.3) and to determine which CoA should be used instead 562 (see below). 564 o Load Sharing and Interface Switching 566 This configuration allows to share the load and set preferences 567 among different paths between the HA and the MN when BT mode is 568 used, and between the CN and the MN when RO mode is used. In 569 order to achieve load sharing and interface switching under this 570 scenario, the MN would need to register several CoAs with its 571 unique HoA. However, the present specification of MIPv6 only 572 allows the MN to register a single CoA per HoA. This is discussed 573 in Section 6.2.1. When a single HoA is bounded to several CoAs at 574 the same time, the MN or HA/CN must be able to select the 575 appropriate CoA. This selection could be done based on user/ 576 application preferences (see Section 6.1.1). 578 5.4. (Hn,Cn): n HoAs, n CoAs 580 The MN is multihomed since it has multiple addresses. This case can 581 be viewed as a combination of the two cases described above: the MN 582 has several HoAs (e.g. given by different operators) and several CoAs 583 (e.g. because the node is receiving multiple IPv6 prefixes). As an 584 example, we can consider a node with three interfaces, two of them 585 connected to their home link (two different HoAs) and the last one 586 connected to a visited link where two IPv6 prefixes are available. 588 Achievable goals: reliability, load sharing and interface switching 590 Current situation with MIPv6: 592 o Reliability 594 If one CoA becomes unreachable (similar to scenario (H1,Cn) in 595 Section 5.3), the MN can redirect flows to another CoA by 596 associating any other available CoAs to the corresponding HoA. If 597 the MN can not use one of its HoA anymore (similar to scenario 598 (Hn,C1) in Section 5.2), the MN will have to re-initiate all flows 599 which were using the corresponding HoA. Redirection between the 600 addresses available for the MN will be different depending on this 601 HoA / CoA binding policies. 603 o Load Sharing, Interface Switching 605 Currently, the MN can register only one CoA per HoA (see 606 Section 6.2.1), but it can register the same or different CoAs 607 with multiple HoAs. If the MN chooses to bind the same CoA to all 608 its HoAs, we fall in the (Hn,C1) case. In this case, load sharing 609 can only be performed if route optimization is not used, on the 610 CN-HA path, as a different HoA may be used per CN. If the MN 611 chooses to bind a different CoA for each HoA, load sharing will be 612 done along the whole path across the MN and its CNs. Preference 613 settings may define which CoA (eventually several if bi-casting is 614 used) should be bound to which HoA (see Section 6.1.1). 616 In a very specific situation, one of the routable address of the 617 MN (i.e., which can be directly used without tunneling to reach 618 the MN) can be one of its HoA. In this case, this HoA can be 619 viewed as a CoA to bind with another HoA. Thus the MN may be able 620 to register one HoA as CoA regarding another HoA (see 621 Section 6.3.1). MIPv6 does not prevent this behavior, which allow 622 to set a certain preference on addresses usage. 624 5.5. (Hn,C0): n HoAs, no CoAs 626 This case happens when all the interfaces are connected to their 627 respective home links. This situation is quite similar to a non- 628 mobile node which is multihomed. The node would no longer be in the 629 (Hn,C0) configuration when one or more of the interfaces are attached 630 to foreign links. 632 The mobile node may wish to use one or more HoAs to serve as the CoA 633 of another HoA (see Section 6.3.1). In such situations, this 634 scenario is reduced to a (H1,C1) or (H1,Cn) configuration as 635 described in Section 5.1 or Section 5.3. 637 Achievable goals: Reliability, Load Sharing, interface switching 639 Current situation with MIPv6 641 o Reliability 643 If the MN is disconnected from one of its interfaces, the MN 644 should be able to register another valid HoA to its failed HoA 645 (see issue Section 6.3.1). 647 o Load Sharing, Interface Switching 649 This can be achieved when the MN is initiating the communication 650 flow, as it can choose which HoA should be used. Depending on how 651 CN can discover HoAs of the MN, these goals might also be achieved 652 when the CN is initiating the communication flow. See previous 653 scenario and discussions in Section 6.1.1 about the path 654 selection. If the flows binding on interfaces preferences change 655 over time, the MN should be able to redirect one flow from one 656 interface to another. However, MIPv6 only allows to redirect all 657 flows from one interface to another, assuming one HoA is 658 registered as CoA (see issue Section 6.3.1). If the MN policies 659 indicate to redirect only one flow, a supplementary mechanism 660 would be needed. 662 6. Issues 664 Existing protocols may not be able to handle the requirements 665 expressed in Section 3. For doing so, the issues discussed in this 666 section must be addressed, and solved preferably by dynamic 667 mechanisms. Note that some issues are pertaining to MIPv6 solely, 668 whereas other issues are not at all related to MIPv6. However, such 669 non MIPv6 issues must be solved in order to meet the requirements 670 outlined in Section 3. 672 In this section, we describe some of these issues in two main 673 headings: general IPv6-related issues, and issues that are specific 674 to MIPv6. Other concerns related to implementations of MIPv6 are 675 described in Section 6.3. Issues and their area of application are 676 summarized in Section 6.4 678 6.1. General IPv6-related Issues 680 6.1.1. Path Selection 682 When there exists multiple paths from and to the MN, the MN ends up 683 choosing a source address, and possibly the interface that should be 684 used. A CN that wants to establish a communication with such a MN 685 may end up by choosing a destination address for this MN. 687 o Interface selection 689 When the node has multiple available interfaces, the simultaneous 690 or selective use of several interfaces would allow a mobile node 691 to spread flows between its different interfaces. 693 Each interface could be used differently according to some user 694 and applications policies and preferences that would define which 695 flow would be mapped to which interface and/or which flow should 696 not be used over a given interface. How such preferences would be 697 set on the MN is out of scope of MIPv6 and might be implementation 698 specific. On the other hand, if the MN wishes to influence how 699 preferences are set on distant nodes (Correspondent Node or Home 700 Agent), mechanisms such as those proposed in 701 draft-soliman-flow-binding [4] could be used. 703 o HoA Selection 705 When multiple HoAs are available, the MN and its communicating 706 peers (HA and CNs) must be able to select the appropriate HoA to 707 be used for a particular packet or flow. 709 This choice would be made at the time of a new communication flow 710 set up. Usual IPv6 mechanisms for source and destination address 711 selection, such as "Default Address Selection for IPv6" (RFC3484) 712 [5] or DNS SRV Protocol (RFC2782) [6] could be used. 714 However, in RFC3484 it is said that "If the eight rules fail to 715 choose a single address, some unspecified tie-breaker should be 716 used". Therefore more specific rules in addition to those 717 described in RFC3484 may be defined for HoA selection. 719 o CoA Selection 721 When multiple CoAs are available, the MN and its communicating 722 peers (HA and CNs) must be able to select the appropriate CoA to 723 be used for a particular packet or flow. The MN may use its 724 internal policies to (i) distribute its flow, and (ii) distribute 725 policies on distant nodes to allow them to select the preferred 726 CoA. Solutions like draft-soliman-flow-binding [4] may be used. 728 Another related aspect of path selection is the concern of ingress 729 filtering. This is covered below in Section 6.1.2. 731 6.1.2. Ingress Filtering 733 In the (H*,Cn) case, a MN may be connected to multiple access 734 networks or multiple home networks each practicing ingress filtering 735 (such as those specified in RFC3704 [7] and RFC2827 [8]). Thus, to 736 avoid ingress filtering, the selection of path would be limited by 737 the choice of address used. This is related to Section 6.1.1. The 738 problem of ingress filtering however, is two-fold. It can occur at 739 the access network, as well as the home network. 741 For instance, consider Figure 2 below. In the access network, when 742 the MN sends a packet through AR-A, it must use CoA=PA.MN; and when 743 MN sends a packet through AR-B, it must use CoA=PB.MN. In the home 744 network, when the MN tunnels the packet to home agent HA-1, it must 745 use HoA=P1.MN; and when MN tunnels the packet to home agent HA-2, it 746 must use HoA=P2.MN. This greatly limits the way MN can benefit from 747 its multihoming configuration. 749 As an illustration, suppose MN is choosing the interface (which would 750 determine the CoA used) and the home network to use (which would 751 determine the HoA used), it might be possible that the chosen CoA is 752 not registered with the chosen HoA. 754 Prefix: PA +------+ +----------+ +------+ 755 HoA: P1.MN /-----| AR-A |----| |----| HA-1 | 756 CoA: PA.MN / +------+ | | +------+ 757 +----+ | | Prefix: P1 758 | MN | | Internet | 759 +----+ | | Prefix: P2 760 HoA: P2.MN \ +------+ | | +------+ 761 CoA: PB.MN \-----| AR-B |----| |----| HA-2 | 762 Prefix: PB +------+ +----------+ +------+ 764 Figure 2: MN connected to Multiple Access/Home Networks 766 It must be noted that should the MN have a way of binding both CoAs 767 PA.MN and PB.MN simultaneously to each of HoAs P1.MN and P2.MN (see 768 Section 6.2.1), then it can choose the CoA to use based on the access 769 network it wishes to use for outgoing packets. This solves the first 770 part of the problem: ingress filtering at the access network. It is, 771 nonetheless, still limited to using only a specific home agent for 772 the home-address used (i.e. the second problem of ingress filtering 773 at the home network remains unsolved). For this, mechanism such as 774 those provided by Shim6 (see RFC3582 [9] and draft-ietf-shim6-proto 775 [10]) may be used. 777 6.1.3. Failure detection 779 Currently, IPv6 has not clearly defined mechanism for failure 780 detection. A failure in the path between two nodes can be located at 781 many different places: the media of one of the node is broken (i.e., 782 loss of connectivity), the path between the MN and the HA is broken, 783 the home link is disconnected from the Internet, etc. By now, MIPv6 784 only relies on the ability or the inability to receive Router 785 Advertisements within a stipulated period to detect the availability 786 or loss of media (local failure). Current effort [11] in the DNA 787 Working Group aims to address this, such as through the use of layer 788 2 triggers [12]. Movement detection might be extended to include 789 other triggers such as the loss of connectivity on one interface. 790 Further mechanisms would be needed to detect a failure in the path 791 between a MN and its CN(s), as well as between the MN and its HA(s), 792 between the MN and CN(s), or between the HA and CN(s). 794 6.2. MIPv6-specific Issues 796 6.2.1. Binding Multiple CoAs to a given HoA 798 In the (H1,Cn) cases, multiple CoAs would be available to the MN. In 799 order to use them simultaneously, the MN must be able to bind and 800 register multiple CoAs for a single HoA with both the HA and the CNs. 801 The MIPv6 specification is currently lacking such ability. 803 Although in the (Hn,Cn) cases, MIPv6 allows MN to have multiple HoA 804 and CoA pairs, the upper layer's choice of using a particular HoA 805 would mean that the MN is forced to use the corresponding CoA. This 806 constrains the MN from choosing the best (in terms of cost, bandwidth 807 etc) access link for a particular flow, since CoA is normally bound 808 to a particular interface. If the MN can register all available CoAs 809 with each HoA, this would completely decouple the HoA from the 810 interface, and allow the MN to fully exploit its multihoming 811 capabilities. 813 To counter this issue, solutions like draft-ietf-mcoa [13] may be 814 used. 816 6.2.2. Simultaneous Location in Home and Foreign Networks 818 Rule 4 of RFC3484 specifies that a HoA will always be preferred to a 819 CoA. While this rule allows the host to choose which address to use, 820 it does not allow the MN to benefit from being multihomed in some 821 cases. When a MN is multihomed, it may have one of its interfaces 822 directly connected to a home link. This may have an impact on the 823 way multihoming is managed, since addresses from other interfaces 824 cannot be registered as CoAs for the HoA associated to the home link 825 the mobile node is connected on. 827 In the special case of (H1,C*) where one of the interface is 828 connected to the home link, none of the other addresses can be used 829 to achieve multihoming goals with the HA. 831 6.3. Considerations for MIPv6 Implementation 833 In addition to the issues described in Section 6.1 and Section 6.2, 834 there are other concerns implementers should take into consideration 835 so that their MIPv6 implementations are more "friendly" to the use of 836 multiple interfaces. These implementation-related considerations are 837 described in the sub-sections below. 839 6.3.1. Using one HoA as a CoA 841 In (Hn,C*) cases, the MN has multiple HoAs. A HoA may be seen as a 842 CoA from the perspective of another home link of the same MN. 844 As an example, a MN has two HoAs (HoA1 and HoA2) on two distinct home 845 links. MN is connected to these two home links via two interfaces. 846 If the MN looses its connectivity on its first interface, HoA1 is not 847 reachable. It may then want to register HoA2 as a CoA for HoA1 in 848 order to keep receiving packets intended to HoA1, via the second 849 interface. 851 According to the definition of a CoA, the current MIPv6 specification 852 does not prohibit a HoA to be a CoA from the perspective of another 853 HoA. 855 In RFC3775 section 6.1.7 it is written: " Similarly, the Binding 856 Update MUST be silently discarded if the care-of address appears as a 857 home address in an existing Binding Cache entry, with its current 858 location creating a circular reference back to the home address 859 specified in the Binding Update (possibly through additional 860 entries)." 862 In order to benefit from any multihoming configuration, a MN must be 863 able to register whatever address it owns with any of its HoA, as 864 long as the above statement is observed. 866 6.3.2. Binding a new CoA to the Right HoA 868 In the (Hn,C*) cases, the MN has multiple HoAs. When the MN moves 869 and configures a new CoA, the newly obtained CoA must be bound to a 870 specific HoA. The current MIPv6 specification doesn't provide a 871 decision mechanism to determine to which HoA this newly acquired CoA 872 should be bound to. 874 The result might be to bind the CoA to the same HoA the previous CoA 875 was bound to or to another one, depending on the implementation. It 876 would indeed be better to specify the behavior so that all 877 implementations are compliant. 879 6.3.3. Binding HoA to interface 881 In (Hn,C*) cases, MIPv6 does not provide any information on how HoAs 882 should be bound on a device, and particularly there is no mechanism 883 to bind HoAs to interfaces. 885 This may be troublesome, for example, when we consider a MN 886 configured with two HoAs and equipped with three interfaces. When 887 the MN is connected to a home link via one interface, it will need to 888 bind the corresponding HoA to this interface, even if the HoA was 889 initially assigned to another one. 891 HoA1 HoA2 893 CoA1 CoA2 CoA3 894 Iface1 Iface2 Iface3 896 Figure 3: Illustration of the case (H2,C3) 898 HoA must always be assigned to an activated interface and if the MN 899 is connected to its home link, the corresponding HoA must be used on 900 this interface. In some cases, the HoA then would have to be re- 901 assigned to another interface in case of connection loss or 902 attachment to the home link. 904 6.3.4. Flow redirection 906 Internet connectivity is guaranteed for a MN as long as at least one 907 path is maintained between the MN and its CN. When the current path 908 fails, an alternative path must be found to substitute the failed 909 one. The redirection from the old path to the new path may result in 910 broken sessions. In this case, new transport sessions would have to 911 be established over the alternate path if no mechanism is provided to 912 redirect flow transparently at layers above layer 3. The need for 913 flow redirection is given in Appendix A. 915 The different mechanisms that can be used to provide flow redirection 916 can be split into two categories, depending on the part of the path 917 that needs to be changed. The first category is when a CoA changes 918 (i.e., the used CoA become invalid or new preferences indicate that 919 the used CoA is no more the CoA to use): if one of the MN's CoA needs 920 to be changed, it influences the path between the MN and its HA, and 921 the path between the MN and its CN in RO mode. If the MN has 922 multiple interfaces and one fails, established sessions on the failed 923 interface would break if no support mechanism is used to redirect 924 flows from the failed interface to another. 926 The second category is when the HoA changes (i.e. the currently used 927 HoA is not valid anymore, e.g., because IPv6 renumbering on the home 928 link): if one of the MN's HoA needs to be changed, it influences the 929 path between the CN and the HoA. In (Hn,C*) cases, the MN has 930 multiple HoAs. If one fails, established sessions on the failed HoA 931 would break if no support mechanism is used to redirect flows from a 932 failed HoA to another, unless the transport session has multihoming 933 capabilities, such as SCTP, to allow dynamic changing of addresses 934 used. 936 6.4. Summary 938 THIS TABLE IS A WORK IN PROGRESS (so all boxes may not have been 939 filled appropriately). For now, please comment on the need for the 940 table rather than the content) 941 +=====================================================+ 942 | # of HoAs: | 1 | 1 | n | n | n | 943 | # of CoAs: | 1 | n | 0 | 1 | n | 944 +=====================================================+ 945 | General IPv6 Issues | 946 +---------------------------------+---+---+---+---+---+ 947 | Path Selection | | o | ? | o | o | 948 +---------------------------------+---+---+---+---+---+ 949 | Ingress Filtering | | | ? | o | o | 950 +---------------------------------+---+---+---+---+---+ 951 | Failure detection |o | o | ? | o | o | 952 +---------------------------------+---+---+---+---+---+ 953 | MIPv6-Specific Issues | 954 +---------------------------------+---+---+---+---+---+ 955 | Binding Multiple CoAs to a | | o | ? | o | o | 956 | given HoA | | | | | | 957 +---------------------------------+---+---+---+---+---+ 958 | Simultaneous location in home | | o | ? | o | o | 959 | and foreign networks | | | ? | | | 960 +---------------------------------+---+---+---+---+---+ 961 | Implementation-Related Concerns | 962 +---------------------------------+---+---+---+---+---+ 963 | Using one HoA as a CoA | | | ? | o | o | 964 +---------------------------------+---+---+---+---+---+ 965 | Binding a new CoA to the | | | ? | o | o | 966 | right HoA | | | | | | 967 +---------------------------------+---+---+---+---+---+ 968 | Binding HoA to interface(s) | o | o | ? | o | o | 969 +---------------------------------+---+---+---+---+---+ 970 | Flow redirection | o | o | ? | o | o | 971 +=====================================================+ 973 Figure 4: Summary of Issues and Categorization 975 7. TODO List 977 Study security concerns 979 Possibly discuss the possibility to use HoA on both home link and 980 foreign link as in case (H1,C1): 982 Mention about relation with Shim6. 984 Reword all the text about the "returning home case" throughout the 985 entire draft 987 Consider the multiple HA addresses throughout the entire draft. 989 8. Conclusion 991 In this document, we have raised issues related to multihoming. We 992 have seen that mechanisms are needed to redirect flow from a failed 993 path to a new path, and mechanisms to decide which path should better 994 be taken when multiple paths are available. This raises a number of 995 issues. 997 Even if MIPv6 can be used as a mechanism to manage multihomed MN, 998 triggers of flows redirection between interfaces/addresses are not 999 adapted to the multihoming status of the node. Also, we have shown 1000 that in some scenarios MIPv6 is ambiguous in the definitions of CoA/ 1001 HoA and in the mappings between HoAs, CoAs and network interfaces. 1002 Finally, we have also raised issues not directly related to MIPv6, 1003 but solutions for these issues are needed for mobile nodes to fully 1004 enjoy the benefits of being multihomed. 1006 9. Contributors 1008 The following people have contributed ideas, text and comments to 1009 earlier versions of this document: Eun Kyoung Paik from Seoul 1010 National University, South Korea and Thomas Noel from Universite 1011 Louis Pasteur, Strasbourg, France. 1013 10. Acknowledgments 1015 The authors would like to thank all the people who have sent comments 1016 so far, particularly Tobias Kufner, Marcelo Bagnulo, Romain Kuntz and 1017 Henrik Levkowetz for their in-depth comments and raising new issues. 1019 11. References 1021 [1] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in 1022 IPv6", RFC 3775, June 2004. 1024 [2] Ernst, T., Montavont, N., Wakikawa, R., Ng, C., and K. 1025 Kuladinithi, "Motivations and Scenarios for Using Multiple 1026 Interfaces and Global Addresses", 1027 draft-ietf-monami6-multihoming-motivation-scenario-01 (work in 1028 progress), October 2006. 1030 [3] Manner, J. and M. Kojo, "Mobility Related Terminology", 1031 RFC 3753, June 2004. 1033 [4] Soliman, H., "Flow Bindings in Mobile IPv6", 1034 draft-soliman-monami6-flow-binding-00 (work in progress), 1035 March 2006. 1037 [5] Draves, R., "Default Address Selection for Internet Protocol 1038 version 6 (IPv6)", RFC 3484, February 2003. 1040 [6] Gukbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 1041 specifying the location of services (DNS SRV)", RFC 2782, 1042 February 2000. 1044 [7] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 1045 Networks", BCP 84, RFC 3704, March 2004. 1047 [8] Ferguson, P. and D. Senie, "Network Ingress Filtering: 1048 Defeating Denial of Service Attacks which employ IP Source 1049 Address Spoofing", BCP 38, RFC 2827, May 2000. 1051 [9] Abley, J., Black, B., and V. Gill, "Goals for IPv6 Site- 1052 Multihoming Architectures", RFC 3582, August 2003. 1054 [10] Nordmark, E. and M. Bagnulo, "Level 3 multihoming shim 1055 protocol", draft-ietf-shim6-proto-07 (work in progress), 1056 November 2006. 1058 [11] Choi, J., "Goals of Detecting Network Attachment in IPv6", 1059 draft-ietf-dna-goals-04 (work in progress), December 2004. 1061 [12] Krishnan, S., Montavont, N., Yegin, A., Veerepalli, S., and A. 1062 Yegin, "Link-layer Event Notifications for Detecting Network 1063 Attachments", draft-ietf-dna-link-information-05 (work in 1064 progress), November 2006. 1066 [13] Wakikawa, R., "Multiple Care-of Addresses Registration", 1067 draft-ietf-monami6-multiplecoa-00 (work in progress), 1068 June 2006. 1070 [14] Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to 1071 Protect Mobile IPv6 Signaling Between Mobile Nodes and Home 1072 Agents", RFC 3776, June 2004. 1074 Appendix A. Why a MN may want to redirect flows 1076 When a MN is multihomed, an addresses selection mechanism is needed 1077 to distribute flows over interfaces. As policies may change over 1078 time, as well as the available addresses/interfaces, flow redirection 1079 mechanisms are needed. While the selection policy is out of scope of 1080 this document, the following reasons may trigger the MN to redirect 1081 flow from one address to another: 1083 o Failure detection: the path between the MN and its CN(s) is 1084 broken. The failure can occur at different places onto this path; 1085 The failure can be local on the MN, where the interface used on 1086 the MN is disconnected from the network (e.g., a wireless 1087 interface which comes out of range from its point of attachment). 1088 Alternatively, the failure can be on the path between the MN and 1089 one of its HA. Yet another alternative is that the failure can be 1090 on the path between the HA and the CN. If route optimization is 1091 used, it can also be a failure between the MN and its CN(s). 1093 o New address: a new address on the MN comes available. This can be 1094 the case when the MN connects to the network with a new interface. 1095 The MN may decide that this new interface is most suitable for its 1096 current flows that are using another interface. 1098 o Uninterrupted horizontal handover in mobility: If the MN is 1099 mobile, it may have to change its point of attachment. When a MN 1100 performs a horizontal handover, the handover latency (the time 1101 during which the MN can not send nor receive packets) can be long 1102 and the flows exchanged on the interface can be interrupted. If 1103 the MN wants to minimize such perturbation, it can redirect some 1104 or all the flows on another available interface. This redirection 1105 can be done prior to the handover if L2 triggering is considered 1106 [12] . 1108 o Change in the network capabilities: the MN can observe a 1109 degradation of service on one of its interface, or conversely an 1110 improvement of capacity on an interface. The MN may then decide 1111 to redirect some or all flows on another interface that it 1112 considers most suitable for the target flows. 1114 o Initiation of a new flow: a new flow is initiated between the MN 1115 and a CN. According to internal policies, the MN may want to 1116 redirect this flow on a most suitable interface. 1118 Authors' Addresses 1120 Nicolas Montavont 1121 Ecole Nationale Superieure des telecommunications de Bretagne 1122 2, rue de la chataigneraie 1123 Cesson Sevigne 35576 1124 France 1126 Phone: (+33) 2 99 12 70 23 1127 Email: nicolas.montavont@enst-bretagne.fr 1128 URI: http://www-r2.u-strasbg.fr/~montavont/ 1130 Ryuji Wakikawa 1131 Keio University 1132 Department of Environmental Information, Keio University. 1133 5322 Endo 1134 Fujisawa, Kanagawa 252-8520 1135 Japan 1137 Phone: +81-466-49-1100 1138 Fax: +81-466-49-1395 1139 Email: ryuji@sfc.wide.ad.jp 1140 URI: http://www.wakikawa.org/ 1142 Thierry Ernst 1143 INRIA 1144 INRIA Rocquencourt 1145 Domaine de Voluceau B.P. 105 1146 Le Chesnay, 78153 1147 France 1149 Phone: +33-1-39-63-59-30 1150 Fax: +33-1-39-63-54-91 1151 Email: thierry.ernst@inria.fr 1152 URI: http://www.nautilus6.org/~thierry 1153 Chan-Wah Ng 1154 Panasonic Singapore Laboratories Pte Ltd 1155 Blk 1022 Tai Seng Ave #06-3530 1156 Tai Seng Industrial Estate 1157 Singapore 534415 1158 SG 1160 Phone: +65 65505420 1161 Email: chanwah.ng@sg.panasonic.com 1163 Koojana Kuladinithi 1164 University of Bremen 1165 ComNets-ikom,University of Bremen. 1166 Otto-Hahn-Allee NW 1 1167 Bremen, Bremen 28359 1168 Germany 1170 Phone: +49-421-218-8264 1171 Fax: +49-421-218-3601 1172 Email: koo@comnets.uni-bremen.de 1173 URI: http://www.comnets.uni-bremen.de/~koo/ 1175 Full Copyright Statement 1177 Copyright (C) The IETF Trust (2007). 1179 This document is subject to the rights, licenses and restrictions 1180 contained in BCP 78, and except as set forth therein, the authors 1181 retain all their rights. 1183 This document and the information contained herein are provided on an 1184 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1185 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1186 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1187 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1188 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1189 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1191 Intellectual Property 1193 The IETF takes no position regarding the validity or scope of any 1194 Intellectual Property Rights or other rights that might be claimed to 1195 pertain to the implementation or use of the technology described in 1196 this document or the extent to which any license under such rights 1197 might or might not be available; nor does it represent that it has 1198 made any independent effort to identify any such rights. Information 1199 on the procedures with respect to rights in RFC documents can be 1200 found in BCP 78 and BCP 79. 1202 Copies of IPR disclosures made to the IETF Secretariat and any 1203 assurances of licenses to be made available, or the result of an 1204 attempt made to obtain a general license or permission for the use of 1205 such proprietary rights by implementers or users of this 1206 specification can be obtained from the IETF on-line IPR repository at 1207 http://www.ietf.org/ipr. 1209 The IETF invites any interested party to bring to its attention any 1210 copyrights, patents or patent applications, or other proprietary 1211 rights that may cover technology that may be required to implement 1212 this standard. Please address the information to the IETF at 1213 ietf-ipr@ietf.org. 1215 Acknowledgment 1217 Funding for the RFC Editor function is provided by the IETF 1218 Administrative Support Activity (IASA).