idnits 2.17.1 draft-ietf-monami6-mipv6-analysis-01.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 on line 1201. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1178. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1185. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1191. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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 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 854: '... Update MUST be silently discarded i...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 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 (June 26, 2006) is 6513 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) -- Looks like a reference, but probably isn't: 'IF2' on line 349 ** 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-00 -- Possible downref: Normative reference to a draft: ref. '3' ** Downref: Normative reference to an Informational RFC: RFC 3753 (ref. '4') == Outdated reference: A later version (-12) exists of draft-ietf-shim6-proto-03 == Outdated reference: A later version (-05) exists of draft-soliman-monami6-flow-binding-00 -- Possible downref: Normative reference to a draft: ref. '6' ** Obsolete normative reference: RFC 3484 (ref. '7') (Obsoleted by RFC 6724) ** Downref: Normative reference to an Informational RFC: RFC 3582 (ref. '10') ** 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-03 ** 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 -- Possible downref: Normative reference to a draft: ref. '14' Summary: 13 errors (**), 0 flaws (~~), 7 warnings (==), 11 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: December 28, 2006 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 June 26, 2006 14 Analysis of Multihoming in Mobile IPv6 15 draft-ietf-monami6-mipv6-analysis-01.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 December 28, 2006. 42 Copyright Notice 44 Copyright (C) The Internet Society (2006). 46 Abstract 48 The use of multiple interfaces is foreseen to provide ubiquitous, 49 permanent and fault-tolerant access to the Internet, particularly on 50 mobile nodes which are more prone to failure or sudden lack of 51 connectivity. However, Mobile IPv6 currently lacks support for such 52 multihomed nodes. The purpose of this document is to detail all the 53 issues arising through the operation of Mobile IPv6 on multihomed 54 mobile nodes. A taxonmy is used to describe the different situations 55 where a mobile node is multihomed. Issues are explained for each 56 multihomed configuration (number of interfaces, number of Home 57 Addresses or number of Care-of Addresses), and classified into 58 general IPv6 issues, issues pertaining to the specification of Mobile 59 IPv6, and issues related to the implementation of Mobile IPv6. It is 60 not the intention of this document to imply that all issues must be 61 solved in the short term. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 69 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 8 71 4. Taxonomy . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 73 5. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 12 74 5.1. (1,1): 1 HoA, 1 CoA . . . . . . . . . . . . . . . . . . . 12 75 5.2. (n,1): n HoAs, 1 CoA . . . . . . . . . . . . . . . . . . . 13 76 5.3. (1,n): 1 HoA, n CoAs . . . . . . . . . . . . . . . . . . . 15 77 5.4. (n,n): n HoAs, n CoAs . . . . . . . . . . . . . . . . . . 16 78 5.5. (n,0): n HoAs, no CoAs . . . . . . . . . . . . . . . . . . 17 80 6. Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 81 6.1. General IPv6-related Issues . . . . . . . . . . . . . . . 18 82 6.1.1. Path Selection . . . . . . . . . . . . . . . . . . . . 18 83 6.1.2. Ingress Filtering . . . . . . . . . . . . . . . . . . 19 84 6.1.3. Failure detection . . . . . . . . . . . . . . . . . . 20 85 6.2. MIPv6-specific Issues . . . . . . . . . . . . . . . . . . 20 86 6.2.1. Binding Multiple CoAs to a given HoA . . . . . . . . . 20 87 6.2.2. Simultaneous Location in Home and Foreign Networks . . 21 88 6.3. Considerations for MIPv6 Implementation . . . . . . . . . 21 89 6.3.1. Using one HoA as a CoA . . . . . . . . . . . . . . . . 21 90 6.3.2. Binding a new CoA to the Right HoA . . . . . . . . . . 22 91 6.3.3. Binding HoA to interface . . . . . . . . . . . . . . . 22 92 6.3.4. Flow redirection . . . . . . . . . . . . . . . . . . . 23 93 6.4. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 23 95 7. TODO List . . . . . . . . . . . . . . . . . . . . . . . . . . 25 96 8. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 26 98 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 27 100 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28 102 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 104 Appendix A. Why a MN may want to redirect flows . . . . . . . . . 30 106 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31 107 Intellectual Property and Copyright Statements . . . . . . . . . . 33 109 1. Introduction 111 The use of multiple addresses (allocated to either a single interface 112 or multiple interfaces) is foreseen to provide ubiquitous, permanent 113 and fault-tolerant access to the Internet, particularly on mobile 114 nodes which are prone to failure or sudden lack of connectivity. 115 Mobile IPv6 [1],[2] is designed to allow a mobile node to maintain 116 its IPv6 communications while moving between IPv6 subnets. However, 117 the current specification of Mobile IPv6 lacks support for mobile 118 nodes with multiple addresses used simultaneously, i.e. multihomed 119 mobile nodes. These addresses would be assigned to a single 120 interface or to multiple interfaces, which poses a number of issues. 122 Individual solutions have been proposed to extend Mobile IPv6 for 123 multihomed mobile nodes, but all issues have not been addressed in a 124 single document. The purpose of the present document is thus to fill 125 up this gap by listing such issues, raising the discussion at the 126 IETF, and placing some requirements in order to propose comprehensive 127 solutions in forthcoming standards. 129 This document has two goals. The first goal of this document is to 130 define the requirements from the point of view of multihomed mobile 131 nodes operating Mobile IPv6. The second goal of this document is to 132 define the issues arising when we attempt to fulfill these 133 requirements. The definition of the potentially needed solutions is 134 out of scope of the analysis document. These should be defined in a 135 separate document once the IETF community agrees on which issues 136 should be solved. 138 In order to reach the goals of this document, we define a taxonomy 139 which is used to describe the different situations where a mobile 140 node is multihomed. For each case, we show the configuration a 141 multihomed node may have (number of Home Addresses or number of 142 Care-of Addresses). We also illustrate each scenario. 144 To understand the foundation of this document, the reader must read 145 our companion document [3] which outlines the motivations, the goals 146 and the benefits of multihoming for both fixed and mobile nodes (i.e. 147 generic IPv6 nodes). Real-life scenarios as illustrated in that 148 document are the base motivations of the present study. The reader 149 must also understand the operation of the Mobile IPv6 protocol ([1]). 151 The document is organized as follows: in Section 2, we introduce the 152 terminology related to multihoming and used in this document. In 153 Section 3, we discuss what is required on the mobile nodes to fully 154 benefit from a multihomed configuration. Then we propose in 155 Section 4 a taxonomy to classify the different cases where mobile 156 nodes are multihomed. Thereafter the taxonomy is used in Section 5 157 to describe a number of multihomed configuration specific to Mobile 158 IPv6. Finally we discuss in Section 6 and Section 6.3 all issues 159 related to a multihomed mobile node and we identify what is missing 160 to reach the goals outlined in [3]. These issues are classified into 161 IPv6 issues, Mobile IPv6-specific issues, and advices to 162 implementers. 164 2. Terminology 166 The terms used in the present document are defined in [4], [1] and 167 [3]. 169 In this draft we are using the following terms and abbreviations: 171 o MIPv6 173 The Mobile IPv6 protocol specified in [1] 175 o MN 177 a Mobile Node operating MIPv6 179 o HA 181 a Mobile IPv6 Home Agent 183 o HoA 185 a Mobile IPv6 Home Address 187 o CoA 189 a Mobile IPv6 Care-of Address 191 o Multihomed MN 193 In [3], a node is said to be multihomed when it has multiple IPv6 194 addresses, either because multiple prefixes are advertised on the 195 link(s) the node is attached to, or because the node has multiple 196 interfaces (see the entire definition). For a mobile node 197 operating MIPv6, this may translate into the following definition: 199 A MN (as defined above) is said multihomed when it has i) multiple 200 addresses which are used as source address (regardless of HoA/CoA) 201 or ii) multiple tunnels to transmit packets. A MN may have 202 multiple HoAs/CoAs in the following cases: 204 * A MN would have multiple HoAs if multiple prefixes are 205 available on the home link or if it has multiple interfaces 206 named on (presumably) distinct home links. 208 * A MN would have multiple CoAs if multiple prefixes are 209 available on the foreign link or if it has multiple interfaces 210 attached to (presumably) distinct foreign links. 212 o A valid address 214 An address that is topologically correct (it is configured from 215 the prefix available on the link the interface is attached to) and 216 routable. 218 o Simultaneously using multiple addresses 220 This indicates a scenario where the MN has the ability to use any 221 of the said multiple addresses at the same time. This implies 222 that a packet with the destination field set to one of the said 223 multiple addresses will reach the MN, either directly from a CN to 224 the MN or through a tunnel with one of the MN's HAs. This also 225 implies that any of the said multiple addresses can be used as 226 source address above the MIPv6 layer. 228 o Simultaneously using multiple interfaces 230 This indicates a scenario when there is at least one valid address 231 named for each of the said multiple interfaces, and that the MN is 232 able to simultaneously use these addresses. 234 3. Requirements 236 The following generic goals and benefits of multihoming are discussed 237 in the companion document [3]: 239 1. Permanent and Ubiquitous Access 241 2. Reliability 243 3. Load Sharing 245 4. Load Balancing/Flow Distribution 247 5. Preference Settings 249 6. Aggregated Bandwidth 251 In this section, we are determining what is required for a mobile 252 node to achieve these design goals. We will determine later in the 253 document (in Section 5) which requirements are already fulfilled by 254 MIPv6 and what issues remain in order to meet the requirements not 255 currently fulfilled by MIPv6. 257 Basically, Internet connectivity is guaranteed for a MN as long as at 258 least one path is maintained between the MN and the fixed Internet. 259 This path can be divided into two portions: the path between the MN 260 to its HA(s) and the path between the HA(s) and the CN. If RO is in 261 place between the MN and a CN, an additional path between the MN and 262 the CN must be guaranteed. In some cases, it may be necessary to 263 divert packets from a (perhaps failed) path to an alternative 264 (perhaps newly established) path (e.g. for matters of reliability, 265 preferences), or to split traffic between multiple paths (e.g. for 266 load sharing, load balancing). The use of an alternative path must 267 be transparent at layers above layer 3 if broken sessions and the 268 establishment of new transport sessions has to be avoided. 270 In order to meet some of the goals (particularly load balancing and 271 load sharing), multiple paths must be maintained simultaneously 272 between the mobile node and its CN. 274 This can translate into the following enumeration of requirements: 276 1. A MN equipped with multiple interfaces must be able to use them 277 simultaneously 279 2. A MN equipped with multiple interfaces must be able to attach 280 distinct interfaces to distinct access networks (distinct foreign 281 links or distinct home links, or a combination of both). 283 3. A MN should be able to share its traffic load among its 284 interfaces, when several interfaces are activated and configured 285 with valid addresses. 287 4. 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 5. A mechanism should be available to quickly redirect flow from one 292 address to another when it is needed. Some of the triggers of 293 flow redirection are given in Appendix A. 295 6. If multiple HAs are available, the MN should be able to use 296 multiple HAs simultaneously for a given Home Address. 298 7. When multiple HoAs are available to the MN, it should be able to 299 use simultaneously distinct HAs for each HoA. 301 One has to consider whether these goals can be achieved with 302 transparency or without transparency. Transparency is achieved when 303 switching between interfaces does not cause the disruption of on- 304 going sessions. To be achieved with transparency, a necessary (may 305 or may not be sufficient) condition is for the end-point addresses at 306 the transport/application layer to remain unchanged. This is in view 307 of the large amount of Internet traffic currently carried by TCP, 308 which unlike SCTP, cannot handle multiple end-point address pairs. 310 In the future, when a Shim6 protocol [5] is designed and deployed, 311 upper layer transparency may be maintained even if end-point 312 addresses are changed. However, as Shim6 is in its early design 313 phase as of the writing of this memo, we will continue to assume that 314 an end-point address change would cause a transport layer disruption 315 throughout this document. 317 4. Taxonomy 319 In order to examine the issues preventing a MIPv6 mobile node to meet 320 the requirements listed in Section 3 we use in the present document 321 the following taxonomy (x,y) where: 323 o x = number of Home Addresses (HoAs) 325 o y = number of Care-of Addresses (CoAs) 327 A value of '1' implies there is a single instance of the parameter, 328 whereas a value of 'n' indicates that there are multiple instances of 329 the parameter. A value '*' indicates that the number can be '1' or 330 'n'. 332 An illustration of this taxonomy is given in Figure 1. 334 Mobile Node 336 HoA1 HoA2 ... HoAn --> Permanent Address (x) 337 | | | 338 +-----+--------+ | | 339 | | | | | 340 CoA1 +--CoA2 +---CoA3 ... CoAn --> Temporary Address (y) 341 | | | | 342 Link1 Link2 Link3 ... Linkn --> IPv6 Link (n/a *) 343 | | | | 344 +-----+----+ | | 345 | | | 346 IF1 IF2 ... IFn --> Physical layer 348 HoA1 ::= {CoA1, 2, 3} [IF1 and IF2] 349 HoA2 ::= {CoA3} [IF2] 351 * because number of IPv6 links is equal to the number of CoAs, y 353 Figure 1: Illustration of the Taxonomy 355 As the taxonomy suggests, the fact that a mobile node has several 356 HoAs is independent from the fact that this mobile node has multiple 357 interfaces. The fact that a mobile node has multiple interfaces does 358 not imply that it has multiple HoAs and vice-versa. Similarly, the 359 number of CoAs is independent from the number of HoAs and the number 360 of interfaces. While a node would probably have at least one CoA per 361 interface, multiple prefixes available on a link may lead the node to 362 configure several CoAs on that link. 364 The proposed taxonomy has two parameters because each of them has an 365 influence on either the mobile node behavior / management, or the 366 potential benefits the mobile node may obtain from such a 367 configuration. 369 The configurations denoted by these parameters will have an impact on 370 the way multihoming is supported. According to the number of HoAs 371 and CoAs, different policies will be needed, such as "which CoA has 372 to be mapped with which HoA", "must all the CoAs be mapped with all 373 the HoAs", etc. 375 5. Scenarios 377 In this section, we detail the reachable multihoming goals under each 378 type of configuration. For each configuration, we give a basic 379 explanation and we list which of the goals outlined in Section 3 are 380 achievable provided that supporting mechanisms are either already 381 existing or could be added. Other goals are not achievable due to 382 the inherent configuration of the node. Then, we briefly discuss the 383 current situation with MIPv6 and we point to issues discussed later 384 in this document in Section 6.1, Section 6.2 and Section 6.3. 386 5.1. (1,1): 1 HoA, 1 CoA 388 A mobile node in this configuration with a single network interface 389 is not multihomed. This scenario is the common case of a MN running 390 Mobile IPv6 and away from its home link: the node has one HoA and one 391 CoA which is configured on the foreign link. None of the multihoming 392 goals are achievable. 394 When the node in the same configuration has several interfaces, it 395 may lead to a special situation where a node is connected to both its 396 home link and a foreign link. The MN is multihomed since it would be 397 able to use both interfaces. The Home Address might be directly used 398 on the interface which is connected to the home link, and a Care-of 399 Address is configured on the other interface which is connected to a 400 foreign link. There cannot be more than two interfaces, otherwise 401 the mobile node would either have (A) multiple interfaces on the home 402 link, or (B) multiple interfaces on foreign links. For (A), there 403 would be multiple HoAs. For (B) there would be multiple CoAs. These 404 two cases would fall in another scenario, either (n,*) (see 405 Section 5.2, Section 5.4 and Section 5.5) or (*,n) (see Section 5.3 406 and Section 5.4). 408 Achievable goals (when the node has multiple interfaces): Ubiquitous 409 Access, Reliability, Load Sharing, Load Balancing, Aggregated 410 Bandwidth, Preference Settings. 412 Current situation with MIPv6 (when the node has multiple interfaces): 414 o Ubiquitous Access and Reliability 416 These goals are achievable, but in a limited manner. The MN can 417 build a CoA on the interface connected to the foreign network, but 418 it cannot register the CoA with its HA and receive packets from 419 the HA via tunnel to the CoA at the same time it receives packet 420 on the HoA from the Home Link. As a result, without binding 421 separately to CNs (i.e. route optimization), the MN is not able to 422 use both addresses simultaneously. In addition, in case of 423 failure, the MN cannot redirect flows from one valid address to 424 another. If the MN looses its connection established using the 425 address on the foreign link, all flows must be re-initiated with 426 another address (either the HoA, or a new address obtained on 427 another foreign link). Fault recovery is thus only possible 428 without transparency, and the MIPv6 features can only recover the 429 failure of the Home Address. This issue is detailed in 430 Section 6.2.2. 432 It might be possible for MN to register the CoA with selected CNs 433 (i.e. route optimization). In this case, the MN can enjoy 434 benefits of increased reliability for communications sessions 435 opened with these CNs. When the CoA fails, the MN can either bind 436 a new CoA, or remove the binding and directly get the packets to 437 its HoA. 439 Reliability can be achieved through bicasting since the MN has two 440 addresses and should be able to request any CN to duplicate 441 traffic to both of them. However, MIPv6 does not allow the MN to 442 request bicasting on the CN (see Section 6.2.2). 444 o Preference Settings, Load Sharing, Load Balancing and Aggregated 445 Bandwidth 447 The MN is able to use both interfaces at the same time, according 448 to some preference settings on its side to decide which one to use 449 for which application. Therefore load sharing, load balancing and 450 aggregated bandwidth can be achieved when sessions are initiated 451 by the MN. When a CN initiates a session with the MN, it would 452 choose the destination address depending on the available 453 information about the MN (e.g., DNS request). Presently there is 454 no mechanism allowing the MN to indicate on which interface (i.e., 455 address) a CN may reach it. If only one address is known by the 456 distant node, load sharing, load balancing and aggregated 457 bandwidth cannot be achieved. See in Section 6.1.1 where such 458 path selection issues are discussed. 460 5.2. (n,1): n HoAs, 1 CoA 462 The MN is multihomed, since it has several HoAs. This case may 463 happen when a node is getting access to the Internet through 464 different HAs (possibly distinct operators) and each offers a Mobile 465 IPv6 service to the node. That way, the node will have a HoA per HA. 466 Alternatively, a single home network may be multihomed to the 467 Internet, leading to having multiple prefixes on the home link. Thus 468 the MN would have multiple HoAs for a single home link. Either case, 469 the node would need to configure a single CoA on the visited IPv6 470 subnet, and bind that single CoA to all the HoAs it owns. If the MN 471 has multiple interfaces, only one interface is connected to a foreign 472 network. The other interfaces are connected to their home links. 474 Achievable goals: Ubiquitous Access, Reliability, Load Sharing, Load 475 Balancing and Aggregated Bandwidth (if the MN has more than one 476 interface) and Preference Settings. 478 Current situation with MIPv6: 480 o Ubiquitous Access and Reliability 482 In case a HoA fails, (a failure could happen in the home network 483 of the MN, e.g. when one HA of the MN is disconnected from the 484 network), the session using the HoA must be restarted since MIPv6 485 does not provide any mechanism to hand-over transparently from a 486 fail HoA to another one. Currently, fault tolerance cannot be 487 achieved in this case, since established communications cannot be 488 preserved. See the corresponding discussion in Section 6.3.4. 490 The CoA may change when the MN has multiple interfaces and is 491 disconnected from its home link (e.g. failure of the interface, or 492 movement). In such a situation, MIPv6 allows to transparently 493 redirect flows using the old CoA as a temporarily address (i.e. 494 the HoA was used as the main address) to another CoA. For 495 sessions directly opened via the CoA, the loss of the address 496 implies a re-initiation of the session. 498 In conclusion, fault recovery can only be done in some cases, when 499 flows were initiated via a HoA. 501 Achieving reliability through bi-casting could be achieved in this 502 scenario by registering two addresses with a single HoA. However 503 MIPv6 does not provide any mechanism to associate more than one 504 CoA with one HoA. Moreover, in this particular case, one HoA 505 should be taken as a CoA regarding the other HoA. (see discussions 506 in Section 6.2.1 and Section 6.3.1). 508 o Preference Settings and Load Sharing 510 In Bidirectional Tunnel (BT) mode, preference settings and load 511 sharing only affect the path between the CN and the HA(s), and not 512 the path between the MN and the HA(s), as long as the CoA does not 513 change. In RO mode, the path between the MN and the CN does not 514 change if the CoA does not change. As an entry in the binding 515 cache is identified by a HoA, the MN can register the same CoA 516 with all HoAs, on any distant node. A mechanism would then be 517 needed for the MN to select which HoA should be used when a new 518 communication flow is initiated. A similar mechanism is needed on 519 the CN side if it knows that multiple HoAs are assigned to the 520 same MN. With such mechanisms, it would be possible to use 521 multiple HoAs at the same time, and load sharing could be 522 performed. See in Section 6.1.1 where such path selection issues 523 are discussed. It is also possible that the MN register one HoA 524 as a CoA for another HoA (see discussions in Section 6.3.1). 526 o Load Balancing and Aggregated Bandwidth 527 Load balancing and aggregated bandwidth are achievable when the MN 528 has several interfaces. In this case, the MN is attached to one 529 foreign link via one of its interfaces, and it is attached to home 530 link(s) with its other interface(s). In this case, the MN can 531 spread flows over its interfaces. Note that if a CN initiates a 532 communication, the interface that it will use on the MN would 533 depend on the information it has about this MN. 535 5.3. (1,n): 1 HoA, n CoAs 537 The MN is multihomed since it has several CoAs. This case may for 538 instance occur when the interface of the node is connected to a link 539 where multiple IPv6 prefixes are available. One possible reason for 540 this is that the visited network is multihomed and because of that, 541 multiple prefixes are available in it, one per provider. Note that 542 one of the interfaces of the MN may be connected to its home link. 544 Achievable goals: Reliability, Load Sharing, Preference Settings, 545 Load Balancing and Aggregated Bandwidth (if the MN is equipped with 546 several interfaces) 548 Current situation with MIPv6: 550 o Ubiquitous Access, Reliabiility 552 Fault recovery will be limited to the case where one of the CoAs 553 become unreachable for a particular peer. For instance, a CoA may 554 become unreachable because the ISP which provides the IPv6 prefix 555 fails. Fault recovery in MIPv6 is achieved by associating an 556 alternate CoA to replace the failed one. However, efficient 557 mechanisms are needed to determine that a CoA has failed (see 558 Section 6.1.3) and to determine which CoA should be used instead 559 (see below). 561 o Preference Setting, Load Sharing, Load balancing and Aggregated 562 Bandwidth 564 This configuration allows to share the load and set preferences 565 among different paths between the HA and the MN when BT mode is 566 used, and between the CN and the MN when RO mode is used. In 567 order to achieve load sharing, load balancing and aggregated 568 bandwidth under this scenario, the MN would need to register 569 several CoAs with its unique HoA. However, the present 570 specification of MIPv6 only allows the MN to register a single CoA 571 per HoA. This is discussed in Section 6.2.1. When a single HoA 572 is bounded to several CoAs at the same time, the MN or HA/CN must 573 be able to select the appropriate CoA. This selection could be 574 done based on user/application preferences (see Section 6.1.1). 576 5.4. (n,n): n HoAs, n CoAs 578 The MN is multihomed since it has multiple addresses. This case can 579 be viewed as a combination of the two cases described above: the MN 580 has several HoAs (e.g. given by different operators) and several CoAs 581 (e.g. because the node is receiving multiple IPv6 prefixes). As an 582 example, we can consider a node with three interfaces, two of them 583 connected to their home link (two different HoAs) and the last one 584 connected to a visited link where two IPv6 prefixes are available. 586 Achievable goals: ubiquitous access, reliability, load sharing, load 587 balancing and preferences settings. 589 Current situation with MIPv6: 591 o Ubiquitous Access, Reliability 593 If one CoA becomes unreachable (similar to scenario (1,n) in 594 Section 5.3), the MN can redirect flows to another CoA by 595 associating any other available CoAs to the corresponding HoA. If 596 the MN can not use one of its HoA anymore (similar to scenario 597 (n,1) in Section 5.2), the MN will have to re-initiate all flows 598 which were using the corresponding HoA. Redirection between the 599 addresses available for the MN will be different depending on this 600 HoA / CoA binding policies. 602 o Preference Settings, Load Sharing, Load Balancing and Aggregated 603 Bandwidth. 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 (n,1) 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 bicasting 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. (n,0): n HoAs, no CoAs 626 This case happens when all the interfaces are connected to their 627 respective home links. . The node would no longer be in the (n,0) 628 configuration when one or more of the interfaces are attached to 629 foreign links. 631 The mobile node may wish to use one or more HoAs to serve as the CoA 632 of another HoA (see Section 6.3.1). In such situations, this 633 scenario is reduced to a (1,1) or (1,n) configuration as described in 634 Section 5.1 or Section 5.3. 636 Achievable goals: Ubiquitous Access, Reliability, Load Sharing, Load 637 Balancing, Aggregated Bandwidth, Preference Settings. 639 Current situation with MIPv6 641 o Ubiquitous Access and 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 Preference Settings, Load Sharing, Load Balancing and Aggregated 648 Bandwidth 650 This can be achieved when the MN is initiating the communication 651 flow, as it can choose which HoA should be used. Depending on how 652 CN can discover HoAs of the MN, these goals might also be achieved 653 when the CN is initiating the communication flow. See previous 654 scenario and discussions in Section 6.1.1 about the path 655 selection. If the flows binding on interfaces preferences change 656 over time, the MN should be able to redirect one flow from one 657 interface to another. However, MIPv6 only allows to redirect all 658 flows from one interface to another, assuming one HoA is 659 registered as CoA (see issue Section 6.3.1). If the MN policies 660 indicate to redirect only one flow, a supplementary mechanism 661 would be needed. 663 6. Issues 665 Existing protocols may not be able to handle the requirements 666 expressed in Section 3. For doing so, the issues discussed in this 667 section must be addressed, and solved preferably by dynamic 668 mechanisms. Note that some issues are pertaining to MIPv6 solely, 669 whereas other issues are not at all related to MIPv6. However, such 670 non MIPv6 issues must be solved in order to meet the requirements 671 outlined in Section 3. 673 In this section, we describe some of these issues in two main 674 headings: general IPv6-related issues, and issues that are specific 675 to MIPv6. Other concerns related to implementations of MIPv6 are 676 described in Section 6.3. Issues and their area of application are 677 summarized in Section 6.4 679 6.1. General IPv6-related Issues 681 6.1.1. Path Selection 683 When there exists multiple paths from and to the MN, the MN ends up 684 choosing a source address, and possibly the interface that should be 685 used. A CN that wants to establish a communication with such a MN 686 may end up by choosing a destination address for this MN. 688 o Interface selection 690 When the node has multiple available interfaces, the simultaneous 691 or selective use of several interfaces would allow a mobile node 692 to spread flows between its different interfaces. 694 Each interface could be used differently according to some user 695 and applications policies and preferences that would define which 696 flow would be mapped to which interface and/or which flow should 697 not be used over a given interface. How such preferences would be 698 set on the MN is out of scope of MIPv6 and might be implementation 699 specific. On the other hand, if the MN wishes to influence how 700 preferences are set on distant nodes (Correspondent Node or Home 701 Agent), mechanisms such as those proposed in [6] 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" [7] could 712 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 on 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 flow binding [6] may be used. 728 Another related aspect of path selection is the concern of ingress 729 filtering. This is detailed in Section 6.1.2. 731 6.1.2. Ingress Filtering 733 In the (*,n) case, a MN may be connected to multiple access networks 734 or multiple home networks each practicing ingress filtering [8], [9]. 735 Thus, to avoid ingress filtering, the selection of path would be 736 limited by the choice of address used. This is related to 737 Section 6.1.1. The problem of ingress filtering however, is two- 738 fold. It can occur at the access network, as well as the home 739 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 [10] and [5]) may be used. 776 6.1.3. Failure detection 778 Currently, IPv6 has not clearly defined mechanism for failure 779 detection. A failure in the path between two nodes can be located at 780 many different places: the media of one of the node is broken (i.e., 781 loss of connectivity), the path between the MN and the HA is broken, 782 the home link is disconnected from the Internet, etc. By now, MIPv6 783 only relies on the ability or the inability to receive Router 784 Advertisements within a stipulated period to detect the availibility 785 or loss of media (local failure). Current effort [11] in the DNA 786 Working Group aims to address this, such as through the use of layer 787 2 triggers [12]. Movement detection might be extended to include 788 other triggers such as the loss of connectivity on one interface. 789 Further mechanisms would be needed to detect a failure in the path 790 between a MN and its CN(s), as well as between the MN and its HA(s), 791 between the MN and CN(s), or between the HA and CN(s). 793 6.2. MIPv6-specific Issues 795 6.2.1. Binding Multiple CoAs to a given HoA 797 In the (1,n) cases, multiple CoAs would be available to the MN. In 798 order to use them simultaneously, the MN must be able to bind and 799 register multiple CoAs for a single HoA with both the HA and the CNs. 800 The MIPv6 specification is currently lacking such ability. 802 Although in the (n,n) cases, MIPv6 allows MN to have multiple HoA and 803 CoA pairs, the upper layer's choice of using a particular HoA would 804 mean that the MN is forced to use the corresponding CoA. This 805 constrains the MN from choosing the best (in terms of cost, bandwidth 806 etc) access link for a particular flow, since CoA is normally bound 807 to a particular interface. If the MN can register all available CoAs 808 with each HoA, this would completely decouple the HoA from the 809 interface, and allow the MN to fully exploit its multihoming 810 capabilities. 812 To counter this issue, solutions like [13] may be used. 814 6.2.2. Simultaneous Location in Home and Foreign Networks 816 Rule 4 of RFC3484 specifies that a HoA will always be preferred to a 817 CoA. While this rule allows to choose which address to use, it does 818 not allow MN to benefit from being multihomed in some cases. When a 819 MN is multihomed, it may have one of its interfaces directly 820 connected to a home link. This may have an impact on the way 821 multihoming is managed, since addresses from other interfaces cannot 822 be registered as CoAs for the HoA associated to the home link the 823 mobile node is connected on. 825 In the special case of (1,*) where one of the interface is connected 826 to the home link, none of the other addresses can be used to achieve 827 multihoming goals with the HA. 829 6.3. Considerations for MIPv6 Implementation 831 In addition to the issues described in Section 6.1 and Section 6.2, 832 there are other concerns implementers should take into consideration 833 so that their MIPv6 implementations are more "friendly" to the use of 834 multiple interfaces. These implementation-related considerations are 835 described in the sub-sections below. 837 6.3.1. Using one HoA as a CoA 839 In (n,*) cases, the MN has multiple HoAs. A HoA may be seen as a CoA 840 from the perspective of another home link of the same MN. 842 As an example, a MN has two HoAs (HoA1 and HoA2) on two distinct home 843 links. MN is connected to these two home links via two interfaces. 844 If the MN looses its connectivity on its first interface, HoA1 is not 845 reachable. It may then want to register HoA2 as a CoA for HoA1 in 846 order to keep receiving packets intended to HoA1, via the second 847 interface. 849 According to the definition of a CoA, the current MIPv6 specification 850 does not prohibit a HoA to be a CoA from the perspective of another 851 HoA. 853 In RFC3775 section 6.1.7 it is written: " Similarly, the Binding 854 Update MUST be silently discarded if the care-of address appears as a 855 home address in an existing Binding Cache entry, with its current 856 location creating a circular reference back to the home address 857 specified in the Binding Update (possibly through additional 858 entries)." 860 In order to benefit from any multihoming configuration, a MN must be 861 able to register whatever address it owns with any of its HoA, as 862 long as the above statement is verified. 864 6.3.2. Binding a new CoA to the Right HoA 866 In the (n,*) cases, the MN has multiple HoAs. When the MN moves and 867 configures a new CoA, the newly obtained CoA must be bound to a 868 specific HoA. The current MIPv6 specification doesn't provide a 869 decision mechanism to determine to which HoA this newly acquired CoA 870 should be bound to. 872 With no such mechanism, the MN may be confused and may bind this CoA 873 to a possibly wrong HoA. The result might be to bind the CoA to the 874 same HoA the previous CoA was bound to or to another one, depending 875 on the implementation. It would indeed be better to specify the 876 behavior so that all implementations are compliant. 878 6.3.3. Binding HoA to interface 880 In (n,*) cases, MIPv6 does not provide any information on how HoAs 881 should be bound on a device, and particularly there is no mechanism 882 to bind HoAs to interfaces. 884 This may be troublesome, for example, when we consider a MN 885 configured with two HoAs and equipped with three interfaces. When 886 the MN is connected to a home link via one interface, it will need to 887 bind the corresponding HoA to this interface, even if the HoA was 888 initially assigned to another one. 890 HoA1 HoA2 892 CoA1 CoA2 CoA3 893 Iface1 Iface2 Iface3 895 Figure 3: Illustration of the case (2,3) 897 HoA must always be assigned to an activated interface and if the MN 898 is connected to its home link, the corresponding HoA must be used on 899 this interface. In some cases, the HoA then would have to be re- 900 assigned to another interface in case of connection loss or 901 attachment to the home link. 903 6.3.4. Flow redirection 905 Internet connectivity is guaranteed for a MN as long as at least one 906 path is maintained between the MN and its CN. When an alternative 907 path must be found to substitute for another one, the loss of one 908 path to the Internet may result in broken sessions. In this case, 909 new transport sessions would have to be established over the 910 alternate path if no mechanism is provided to redirect flow 911 transparently at layers above layer 3. The need for flow redirection 912 is given in Appendix A. 914 The different mechanisms that can be used to provide flow redirection 915 can be split into two categories, depending on the part of the path 916 that needs to be changed. The first category is when the CoA 917 changes: if one of the MN's CoA needs to be changed, it influences 918 the path between the MN and its HA, and the path between the MN and 919 its CN in RO mode. If the MN has multiple interfaces and one fails, 920 established sessions on the failed interface would break if no 921 support mechanism is used to redirect flows from the failed interface 922 to another. 924 The second category is when the HoA changes: if one of the MN's HoA 925 needs to be changed, it influences the path between the CN and the 926 HoA. In (n,*) cases, the MN has multiple HoAs. If one fails, 927 established sessions on the failed HoA would break if no support 928 mechanism is used to redirect flows from a failed HoA to another, 929 unless the transport session has multihoming capabilities, such as 930 SCTP, to allow dynamic changing of addresses used. 932 6.4. Summary 934 THIS TABLE IS A WORK IN PROGRESS (so all boxes may not have been 935 filled appropriately). For now, please comment on the need for the 936 table rather than the content) 937 +=====================================================+ 938 | # of HoAs: | 1 | 1 | n | n | n | 939 | # of CoAs: | 1 | n | 0 | 1 | n | 940 +=====================================================+ 941 | General IPv6 Issues | 942 +---------------------------------+---+---+---+---+---+ 943 | Path Selection | | o | ? | o | o | 944 +---------------------------------+---+---+---+---+---+ 945 | Ingress Filtering | | | ? | o | o | 946 +---------------------------------+---+---+---+---+---+ 947 | Failure detection |o | o | ? | o | o | 948 +---------------------------------+---+---+---+---+---+ 949 | MIPv6-Specific Issues | 950 +---------------------------------+---+---+---+---+---+ 951 | Binding Multiple CoAs to a | | o | ? | o | o | 952 | given HoA | | | | | | 953 +---------------------------------+---+---+---+---+---+ 954 | Simultaneous location in home | | o | ? | o | o | 955 | and foreign networks | | | ? | | | 956 +---------------------------------+---+---+---+---+---+ 957 | Implementation-Related Concerns | 958 +---------------------------------+---+---+---+---+---+ 959 | Using one HoA as a CoA | | | ? | o | o | 960 +---------------------------------+---+---+---+---+---+ 961 | Binding a new CoA to the | | | ? | o | o | 962 | right HoA | | | | | | 963 +---------------------------------+---+---+---+---+---+ 964 | Binding HoA to interface(s) | o | o | ? | o | o | 965 +---------------------------------+---+---+---+---+---+ 966 | Flow redirection | o | o | ? | o | o | 967 +=====================================================+ 969 Figure 4: Summary of Issues and Categorization 971 7. TODO List 973 Study security concerns 975 Possibly discuss the possibility to use HoA on both home link and 976 foreign link as in case (1,1): 978 Mention about relation with Shim6. 980 Reword all the text about the "returning home case" throughout the 981 entire draft 983 Consider the multiple HA addresses throughout the entire draft. 985 8. Conclusion 987 In this document, we have raised issues related to multihoming. We 988 have seen that mechanisms are needed to redirect flow from a failed 989 path to a new path, and mechanisms to decide which path should better 990 be taken when multiple paths are available. This raises a number of 991 issues. 993 Even if MIPv6 can be used as a mechanism to manage multihomed MN, 994 triggers of flows redirection between interfaces/addresses are not 995 adapted to the multihoming status of the node. Also, we have shown 996 that in some scenarios MIPv6 is ambiguous in the definitions of CoA/ 997 HoA and in the mappings between HoAs, CoAs and network interfaces. 998 Finally, we have also raised issues not directly related to MIPv6, 999 but solutions for these issues are needed for mobile nodes to fully 1000 enjoy the benefits of being multihomed. 1002 9. Contributors 1004 The following people have contributed ideas, text and comments to 1005 earlier versions of this document: Eun Kyoung Paik from Seoul 1006 National University, South Korea and Thomas Noel from Universite 1007 Louis Pasteur, Strasbourg, France. 1009 10. Acknowledgments 1011 The authors would like to thank all the people who have sent comments 1012 so far, particularly Tobias Kufner, Marcelo Bagnulo, and Romain Kuntz 1013 for their in-depth comments and raising new issues. 1015 11. References 1017 [1] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in 1018 IPv6", RFC 3775, June 2004. 1020 [2] Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to 1021 Protect Mobile IPv6 Signaling Between Mobile Nodes and Home 1022 Agents", RFC 3776, June 2004. 1024 [3] Ernst, T., "Motivations and Scenarios for Using Multiple 1025 Interfaces and Global Addresses", 1026 draft-ietf-monami6-multihoming-motivation-scenario-00 (work in 1027 progress), February 2006. 1029 [4] Manner, J. and M. Kojo, "Mobility Related Terminology", 1030 RFC 3753, June 2004. 1032 [5] Bagnulo, M. and E. Nordmark, "Level 3 multihoming shim 1033 protocol", draft-ietf-shim6-proto-03 (work in progress), 1034 December 2005. 1036 [6] Soliman, H., "Flow Bindings in Mobile IPv6", 1037 draft-soliman-monami6-flow-binding-00 (work in progress), 1038 March 2006. 1040 [7] Draves, R., "Default Address Selection for Internet Protocol 1041 version 6 (IPv6)", RFC 3484, February 2003. 1043 [8] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 1044 Networks", BCP 84, RFC 3704, March 2004. 1046 [9] Ferguson, P. and D. Senie, "Network Ingress Filtering: 1047 Defeating Denial of Service Attacks which employ IP Source 1048 Address Spoofing", BCP 38, RFC 2827, May 2000. 1050 [10] Abley, J., Black, B., and V. Gill, "Goals for IPv6 Site- 1051 Multihoming Architectures", RFC 3582, August 2003. 1053 [11] Choi, J., "Goals of Detecting Network Attachment in IPv6", 1054 draft-ietf-dna-goals-04 (work in progress), December 2004. 1056 [12] Yegin, A., "Link-layer Event Notifications for Detecting 1057 Network Attachments", draft-ietf-dna-link-information-03 (work 1058 in progress), October 2005. 1060 [13] Wakikawa, R., "Multiple Care-of Addresses Registration", 1061 draft-ietf-monami6-multiplecoa-00 (work in progress), 1062 June 2006. 1064 [14] Yegin, A., "Link-layer Hints for Detecting Network 1065 Attachments", draft-yegin-dna-l2-hints-01 (work in progress), 1066 February 2004. 1068 Appendix A. Why a MN may want to redirect flows 1070 When a MN is multihomed, an addresses selection mechanism is needed 1071 to distribute flows over interfaces. As policies may change over 1072 time, as well as the available addresses/interfaces, flow redirection 1073 mechanisms are needed. While the selection policy is out of scope of 1074 this document, the following reasons may trigger the MN to redirect 1075 flow from one address to another: 1077 o Failure detection: the path between the MN and its CN(s) is 1078 broken. The failure can occur at different places onto this path; 1079 The failure can be local on the MN, where the interface used on 1080 the MN is disconnected from the network (e.g., a wireless 1081 interface which comes out of range from its point of attachment). 1082 Alternatively, the failure can be on the path between the MN and 1083 one of its HA. Yet another alternative is that the failure can be 1084 on the path between the HA and the CN. If route optimization is 1085 used, it can also be a failure between the MN and its CN(s). 1087 o New address: a new address on the MN comes available. This can be 1088 the case when the MN connects to the network with a new interface. 1089 The MN may decide that this new interface is most suitable for its 1090 current flows that are using another interface. 1092 o Uninterrupted horizontal handover in mobility: If the MN is 1093 mobile, it may have to change its point of attachment. When a MN 1094 performs a horizontal handover, the handover latency (the time 1095 during which the MN can not send nor receive packets) can be long 1096 and the flows exchanged on the interface can be interrupted. If 1097 the MN wants to minimize such perturbation, it can redirect some 1098 or all the flows on another available interface. This redirection 1099 can be done prior to the handover if L2 triggering is considered 1100 [12] [14] 1102 o Change in the network capabilities: the MN can observe a 1103 degradation of service on one of its interface, or conversely an 1104 improvement of capacity on an interface. The MN may then decide 1105 to redirect some or all flows on another interface that it 1106 considers most suitable for the target flows. 1108 o Initiation of a new flow: a new flow is initiated between the MN 1109 and a CN. According to internal policies, the MN may want to 1110 redirect this flow on a most suitable interface. 1112 Authors' Addresses 1114 Nicolas Montavont 1115 Ecole Nationale Superieure des telecommunications de Bretagne 1116 2, rue de la chataigneraie 1117 Cesson Sevigne 35576 1118 France 1120 Phone: (+33) 2 99 12 70 23 1121 Email: nicolas.montavont@enst-bretagne.fr 1122 URI: http://www-r2.u-strasbg.fr/~montavont/ 1124 Ryuji Wakikawa 1125 Keio University 1126 Department of Environmental Information, Keio University. 1127 5322 Endo 1128 Fujisawa, Kanagawa 252-8520 1129 Japan 1131 Phone: +81-466-49-1100 1132 Fax: +81-466-49-1395 1133 Email: ryuji@sfc.wide.ad.jp 1134 URI: http://www.wakikawa.org/ 1136 Thierry Ernst 1137 INRIA 1138 INRIA Rocquencourt 1139 Domaine de Voluceau B.P. 105 1140 Le Chesnay, 78153 1141 France 1143 Phone: +33-1-39-63-59-30 1144 Fax: +33-1-39-63-54-91 1145 Email: thierry.ernst@inria.fr 1146 URI: http://www.nautilus6.org/~thierry 1147 Chan-Wah Ng 1148 Panasonic Singapore Laboratories Pte Ltd 1149 Blk 1022 Tai Seng Ave #06-3530 1150 Tai Seng Industrial Estate 1151 Singapore 534415 1152 SG 1154 Phone: +65 65505420 1155 Email: chanwah.ng@sg.panasonic.com 1157 Koojana Kuladinithi 1158 University of Bremen 1159 ComNets-ikom,University of Bremen. 1160 Otto-Hahn-Allee NW 1 1161 Bremen, Bremen 28359 1162 Germany 1164 Phone: +49-421-218-8264 1165 Fax: +49-421-218-3601 1166 Email: koo@comnets.uni-bremen.de 1167 URI: http://www.comnets.uni-bremen.de/~koo/ 1169 Intellectual Property Statement 1171 The IETF takes no position regarding the validity or scope of any 1172 Intellectual Property Rights or other rights that might be claimed to 1173 pertain to the implementation or use of the technology described in 1174 this document or the extent to which any license under such rights 1175 might or might not be available; nor does it represent that it has 1176 made any independent effort to identify any such rights. Information 1177 on the procedures with respect to rights in RFC documents can be 1178 found in BCP 78 and BCP 79. 1180 Copies of IPR disclosures made to the IETF Secretariat and any 1181 assurances of licenses to be made available, or the result of an 1182 attempt made to obtain a general license or permission for the use of 1183 such proprietary rights by implementers or users of this 1184 specification can be obtained from the IETF on-line IPR repository at 1185 http://www.ietf.org/ipr. 1187 The IETF invites any interested party to bring to its attention any 1188 copyrights, patents or patent applications, or other proprietary 1189 rights that may cover technology that may be required to implement 1190 this standard. Please address the information to the IETF at 1191 ietf-ipr@ietf.org. 1193 Disclaimer of Validity 1195 This document and the information contained herein are provided on an 1196 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1197 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1198 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1199 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1200 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1201 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1203 Copyright Statement 1205 Copyright (C) The Internet Society (2006). This document is subject 1206 to the rights, licenses and restrictions contained in BCP 78, and 1207 except as set forth therein, the authors retain all their rights. 1209 Acknowledgment 1211 Funding for the RFC Editor function is currently provided by the 1212 Internet Society.