idnits 2.17.1 draft-ietf-monami6-mipv6-analysis-00.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 1213. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1190. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1197. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1203. ** 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 860: '... 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 (February 20, 2006) is 6641 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 355 == Unused Reference: '16' is defined on line 1077, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3775 (ref. '1') (Obsoleted by RFC 6275) -- No information found for draft-ietf-monami6-multihoming-motivations-scenarios - is the name correct? -- 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 (-03) exists of draft-soliman-mobileip-flow-move-02 -- Possible downref: Normative reference to a draft: ref. '6' -- Possible downref: Normative reference to a draft: ref. '7' -- Possible downref: Normative reference to a draft: ref. '8' ** Obsolete normative reference: RFC 3484 (ref. '9') (Obsoleted by RFC 6724) ** Downref: Normative reference to an Informational draft: draft-ietf-dna-goals (ref. '12') == 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. '13') == Outdated reference: A later version (-05) exists of draft-wakikawa-mobileip-multiplecoa-04 -- Possible downref: Normative reference to a draft: ref. '14' -- Possible downref: Normative reference to a draft: ref. '15' -- Possible downref: Normative reference to a draft: ref. '16' Summary: 12 errors (**), 0 flaws (~~), 7 warnings (==), 16 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 24, 2006 R. Wakikawa 5 Keio University 6 T. Ernst 7 Keio University / WIDE 8 C. Ng 9 Panasonic Singapore Labs 10 K. Kuladinithi 11 University of Bremen 12 February 20, 2006 14 Analysis of Multihoming in Mobile IPv6 15 draft-ietf-monami6-mipv6-analysis-00.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 24, 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 interfaces, number of Home 142 Addresses or number of Care-of Addresses). We also illustrate each 143 scenario. 145 To understand the foundation of this document, the reader must read 146 our companion document [3] which outlines the motivations, the goals 147 and the benefits of multihoming for both fixed and mobile nodes (i.e. 148 generic IPv6 nodes). Real-life scenarios as illustrated in that 149 document are the base motivations of the present study. The reader 150 must also understand the operation of the Mobile IPv6 protocol ([1]). 152 The document is organized as follows: in Section 2, we introduce the 153 terminology related to multihoming and used in this document. In 154 Section 3, we discuss what is required on the mobile nodes to fully 155 benefit from a multihomed configuration. Then we propose in 156 Section 4 a taxonomy to classify the different cases where mobile 157 nodes are multihomed. Thereafter the taxonomy is used in Section 5 158 to describe a number of multihomed configuration specific to Mobile 159 IPv6. Finally we discuss in Section 6 and Section 6.3 all issues 160 related to a multihomed mobile node and we identify what is missing 161 to reach the goals outlined in [3]. These issues are classified into 162 IPv6 issues, Mobile IPv6-specific issues, and advices to 163 implementers. 165 2. Terminology 167 The terms used in the present document are defined in [4], [1] and 168 [3]. 170 In this draft we are using the following terms and abbreviations: 172 o MIPv6 174 The Mobile IPv6 protocol specified in [1] 176 o MN 178 a Mobile Node operating MIPv6 180 o HA 182 a Home Agent 184 o HoA 186 Home Address 188 o CoA 190 Care-of Address 192 o Multihomed MN 194 In [3], a node is said to be multihomed when it has multiple IPv6 195 addresses, either because multiple prefixes are advertised on the 196 link(s) the node is attached to, or because the node has multiple 197 interfaces (see the entire definition). For a mobile node 198 operating MIPv6, this may translate into the following definition: 200 A MN (as defined above) is said multihomed when it simultaneously 201 has (i) multiple HoAs; (ii) multiple CoAs; and/or (iii) or a 202 combination of at least 2 of these. A MN may have multiple HoAs/ 203 CoAs in the following cases: 205 * A MN would have multiple HoAs if multiple prefixes are 206 available on the home link or if it has multiple interfaces 207 named on (presumably) distinct home links. 209 * A MN would have multiple CoAs if multiple prefixes are 210 available on the foreign link or if it has multiple interfaces 211 attached to (presumably) distinct foreign links. 213 o A valid address 215 An address that is topologically correct (it is configured from 216 the prefix available on the link the interface is attached to) and 217 routable. 219 o Simultaneously using multiple addresses 221 This indicates a scenario where the MN has the ability to use any 222 of the said multiple addresses at the same time. This implies 223 that a packet with the destination field set to one of the said 224 multiple addresses will reach the MN, either directly from a CN to 225 the MN or through a tunnel with one of the MN's HAs. This also 226 implies that any of the said multiple addresses can be used as 227 source address above the MIPv6 layer. 229 o Simultaneously using multiple interfaces 231 This indicates a scenario when there is at least one valid address 232 named for each of the said multiple interfaces, and that the MN is 233 able to simultaneously use these addresses. 235 3. Requirements 237 The following generic goals and benefits of multihoming are discussed 238 in the companion document [3]: 240 1. Permanent and Ubiquitous Access 242 2. Reliability 244 3. Load Sharing 246 4. Load Balancing/Flow Distribution 248 5. Preference Settings 250 6. Aggregated Bandwidth 252 In this section, we are determining what is required for a mobile 253 node to achieve these design goals. We will determine later in the 254 document (in Section 5) which requirements are already fulfilled by 255 MIPv6 and what issues remain in order to meet the requirements not 256 currently fulfilled by MIPv6. 258 Basically, Internet connectivity is guaranteed for a MN as long as at 259 least one path is maintained between the MN and the fixed Internet. 260 This path can be divided into two portions: the path between the MN 261 to its HA(s) and the path between the HA(s) and the CN. If RO is in 262 place between the MN and a CN, an additional path between the MN and 263 the CN must be guaranteed. In some cases, it may be necessary to 264 divert packets from a (perhaps failed) path to an alternative 265 (perhaps newly established) path (e.g. for matters of reliability, 266 preferences), or to split traffic between multiple paths (e.g. for 267 load sharing, load balancing). The use of an alternative path must 268 be transparent at layers above layer 3 if broken sessions and the 269 establishment of new transport sessions has to be avoided. 271 In order to meet some of the goals (particularly load balancing and 272 load sharing), multiple paths must be maintained simultaneously 273 between the mobile node and its CN. 275 This can translate into the following enumeration of requirements: 277 1. A MN must have either multiple interfaces with at least a single 278 valid global IP address on each interface, or a single interface 279 with more than one valid global address, or a single interface 280 with one valid global address and multiple HoAs. 282 2. A MN equipped with multiple interfaces must be able to use them 283 simultaneously 285 3. A MN equipped with multiple interfaces must be able to attach 286 distinct interfaces to distinct access networks (distinct foreign 287 links or distinct home links, or a combination of both). 289 4. A MN should be able to share its traffic load among its 290 interfaces, when several interfaces are activated and configured 291 with valid addresses. 293 5. A mechanism should be available to quickly activate a backup 294 interface and redirect traffic when an interface fails (e.g., 295 loss of connection). 297 6. A mechanism should be available to quickly redirect flow from one 298 address to another when it is needed. Some of the triggers of 299 flow redirection are given in Appendix A. 301 7. If multiple HAs are available, the MN should be able to use 302 multiple HAs simultaneously for a given Home Address. 304 8. When multiple HoAs are available to the MN, it should be able to 305 use simultaneously distinct HAs for each HoA. 307 One has to consider whether these goals can be achieved with 308 transparency or without transparency. Transparency is achieved when 309 switching between interfaces does not cause the disruption of on- 310 going sessions. To be achieved with transparency, a necessary (may 311 or may not be sufficient) condition is for the end-point addresses to 312 remain unchanged. This is in view of the large amount of Internet 313 traffic currently carried by TCP, which unlike SCTP, cannot handle 314 multiple end-point address pairs. 316 In the future, when a Shim6 protocol [5] is designed and deployed, 317 upper layer transparency may be maintained even if end-point 318 addresses are changed. However, as Shim6 is in its early design 319 phase as of the writing of this memo, we will continue to assume that 320 an end-point address change would cause a transport layer disruption 321 throughout this document. 323 4. Taxonomy 325 In order to examine the issues preventing a MIPv6 mobile node to meet 326 the requirements listed in Section 3 we use in the present document 327 the following taxonomy (x,y) where: 329 o x = number of Home Addresses (HoAs) 331 o y = number of Care-of Addresses (CoAs) 333 A value of '1' implies there is a single instance of the parameter, 334 whereas a value of 'n' indicates that there are multiple instances of 335 the parameter. A value '*' indicates that the number can be '1' or 336 'n'. 338 An illustration of this taxonomy is given in Figure 1. 340 Mobile Node 342 HoA1 HoA2 ... HoAn --> Permanent Address (x) 343 | | | 344 +-----+--------+ | | 345 | | | | | 346 CoA1 +--CoA2 +---CoA3 ... CoAn --> Temporary Address (y) 347 | | | | 348 Link1 Link2 Link3 ... Linkn --> IPv6 Link (n/a *) 349 | | | | 350 +-----+----+ | | 351 | | | 352 IF1 IF2 ... IFn --> Physical layer 354 HoA1 ::= {CoA1, 2, 3} [IF1 and IF2] 355 HoA2 ::= {CoA3} [IF2] 356 Mobile Node(x = 2, y = 3) 358 * because number of IPv6 links is equal to the number of CoAs, y 360 Figure 1: Illustration of the Taxonomy 362 As the taxonomy suggests, the fact that a mobile node has several 363 HoAs is independent from the fact that this mobile node has multiple 364 interfaces. The fact that a mobile node has multiple interfaces does 365 not imply that it has multiple HoAs and vice-versa. Similarly, the 366 number of CoAs is independent from the number of HoAs and the number 367 of interfaces. While a node would probably have at least one CoA per 368 interface, multiple prefixes available on a link may lead the node to 369 configure several CoAs on that link. 371 The proposed taxonomy has two parameters because each of them has an 372 influence on either the mobile node behavior / management, or the 373 potential benefits the mobile node may obtain from such a 374 configuration. 376 The configurations denoted by these parameters will have an impact on 377 the way multihoming is supported. According to the number of HoAs 378 and CoAs, different policies will be needed, such as "which CoA has 379 to be mapped with which HoA", "must all the CoAs be mapped with all 380 the HoAs", etc. 382 5. Scenarios 384 In this section, we detail the reachable multihoming goals under each 385 type of configuration. For each configuration, we give a basic 386 explanation and we list which of the goals outlined in Section 3 are 387 achievable provided that supporting mechanisms are either already 388 existing or could be added. Other goals are not achievable due to 389 the inherent configuration of the node. Then, we briefly discuss the 390 current situation with MIPv6 and we point to issues discussed later 391 in this document in Section 6.1, Section 6.2 and Section 6.3. 393 5.1. (1,1): 1 HoA, 1 CoA 395 A mobile node in this configuration with a single network interface 396 is not multihomed. This scenario is the common case of a MN running 397 Mobile IPv6 and away from its home link: the node has one HoA and one 398 CoA which is configured on the foreign link. None of the multihoming 399 goals are achievable. 401 When the node in the same configuration has several interfaces, it 402 may lead to a special situation where a node is connected to both its 403 home link and a foreign link. The MN is multihomed since it would be 404 able to use both interfaces. The Home Address might be directly used 405 on the interface which is connected to the home link, and a Care-of 406 Address is configured on the other interface which is connected to a 407 foreign link. There cannot be more than two interfaces, otherwise 408 the mobile node would either have (A) multiple interfaces on the home 409 link, or (B) multiple interfaces on foreign links. For (A), there 410 would be multiple HoAs. For (B) there would be multiple CoAs. These 411 two cases would fall in another scenario, either (n,*) (see 412 Section 5.2, Section 5.4 and Section 5.5) or (*,n) (see Section 5.3 413 and Section 5.4). 415 Achievable goals (when the node has multiple interfaces): Ubiquitous 416 Access, Reliability, Load Sharing, Load Balancing, Aggregated 417 Bandwidth, Preference Settings. 419 Current situation with MIPv6 (when the node has multiple interfaces): 421 o Ubiquitous Access and Reliability 423 These goals are achievable, but in a limited manner. The MN can 424 build a CoA on the interface connected to the foreign network, but 425 it cannot register the CoA with its HA and receive packets from 426 the HA via tunnel to the CoA at the same time it receives packet 427 on the HoA from the Home Link. As a result, without binding 428 separately to CNs (i.e. route optimization), the MN is not able to 429 use both addresses simultaneously. In addition, in case of 430 failure, the MN cannot redirect flows from one valid address to 431 another. If the MN looses its connection established using the 432 address on the foreign link, all flows must be re-initiated with 433 another address (either the HoA, or a new address obtained on 434 another foreign link). Fault recovery is thus only possible 435 without transparency, and the MIPv6 features can only recover the 436 failure of the Home Address. This issue is detailed in 437 Section 6.2.2. 439 It might be possible for MN to register the CoA with selected CNs 440 (i.e. route optimization). In this case, the MN can enjoy 441 benefits of increased reliability for communications sessions 442 opened with these CNs. When the CoA fails, the MN can either bind 443 a new CoA, or remove the binding. 445 Reliability can be achieved through bicasting since the MN has two 446 addresses and should be able to request any CN to duplicate 447 traffic to both of them. However, MIPv6 does not allow the MN to 448 request bicasting on the CN (see Section 6.2.2). 450 o Preference Settings, Load Sharing, Load Balancing and Aggregated 451 Bandwidth 453 The MN is able to use both interfaces at the same time, according 454 to some preference settings on its side to decide which one to use 455 for which application. Therefore load sharing, load balancing and 456 aggregated bandwidth can be achieved when sessions are initiated 457 by the MN. When a CN initiates a session with the MN, it would 458 choose the destination address depending on the available 459 information about the MN (e.g., DNS request). Presently there is 460 no mechanism allowing the MN to indicate on which interface (i.e., 461 address) a CN may reach it. If only one address is known by the 462 distant node, load sharing, load balancing and aggregated 463 bandwidth cannot be achieved. See in Section 6.1.1 where such 464 path selection issues are discussed. 466 5.2. (n,1): n HoAs, 1 CoA 468 The MN is multihomed, since it has several HoAs. This case may 469 happen when a node is getting access to the Internet through 470 different HAs (possibly distinct operators) and each offers a Mobile 471 IPv6 service to the node. That way, the node will have a HoA per HA. 472 Alternatively, a single home network may be multihomed to the 473 Internet, leading to having multiple prefixes on the home link. Thus 474 the MN would have multiple HoAs for a single home link. Either case, 475 the node would need to configure a single CoA on the visited IPv6 476 subnet, and bind that single CoA to all the HoAs it owns. If the MN 477 has multiple interfaces, only one interface is connected to a foreign 478 network. The other interfaces are connected to their home links. 480 Achievable goals: Ubiquitous Access, Reliability, Load Sharing, Load 481 Balancing and Aggregated Bandwidth (if the MN has more than one 482 interface) and Preference Settings. 484 Current situation with MIPv6: 486 o Ubiquitous Access and Reliability 488 In case a HoA fails, (a failure could happen in the home network 489 of the MN, e.g. when one HA of the MN is disconnected from the 490 network), the session using the HoA must be restarted since MIPv6 491 does not provide any mechanism to hand-over transparently from a 492 fail HoA to another one. Currently, fault tolerance cannot be 493 achieved in this case, since established communications cannot be 494 preserved. See the corresponding discussion in Section 6.3.4. 496 The CoA may change when the MN has multiple interfaces and is 497 disconnected from its home link (e.g. failure of the interface, or 498 movement). In such a situation, MIPv6 allows to transparently 499 redirect flows using the old CoA as a temporarily address (i.e. 500 the HoA was used as the main address) to another CoA. For 501 sessions directly opened via the CoA, the loss of the address 502 implies a re-initiation of the session. 504 In conclusion, fault recovery can only be done in some cases, when 505 flows were initiated via a HoA. 507 Achieving reliability through bi-casting could be achieved in this 508 scenario by registering two addresses with a single HoA. However 509 MIPv6 does not provide any mechanism to associate more than one 510 CoA with one HoA. Moreover, in this particular case, one HoA 511 should be taken as a CoA regarding the other HoA. (see discussions 512 in Section 6.2.1 and Section 6.3.1). 514 o Preference Settings and Load Sharing 516 In Bidirectional Tunnel (BT) mode, preference settings and load 517 sharing only affect the path between the CN and the HA(s), and not 518 the path between the MN and the HA(s), as long as the CoA does not 519 change. In RO mode, the path between the MN and the CN does not 520 change if the CoA does not change. As an entry in the binding 521 cache is identified by a HoA, the MN can register the same CoA 522 with all HoAs, on any distant node. A mechanism would then be 523 needed for the MN to select which HoA should be used when a new 524 communication flow is initiated. A similar mechanism is needed on 525 the CN side if it knows that multiple HoAs are assigned to the 526 same MN. With such mechanisms, it would be possible to use 527 multiple HoAs at the same time, and load sharing could be 528 performed. See in Section 6.1.1 where such path selection issues 529 are discussed. It is also possible that the MN register one HoA 530 as a CoA for another HoA (see discussions in Section 6.3.1). 532 o Load Balancing and Aggregated Bandwidth 533 Load balancing and aggregated bandwidth are achievable when the MN 534 has several interfaces. In this case, the MN is attached to one 535 foreign link via one of its interfaces, and it is attached to home 536 link(s) with its other interface(s). In this case, the MN can 537 spread flows over its interfaces. Note that if a CN initiates a 538 communication, the interface that it will use on the MN would 539 depend on the information it has about this MN. 541 5.3. (1,n): 1 HoA, n CoAs 543 The MN is multihomed since it has several CoAs. This case may for 544 instance occur when the interface of the node is connected to a link 545 where multiple IPv6 prefixes are available. One possible reason for 546 this is that the visited network is multihomed and because of that, 547 multiple prefixes are available in it, one per provider. Note that 548 one of the interfaces of the MN may be connected to its home link. 550 Achievable goals: Reliability, Load Sharing, Preference Settings, 551 Load Balancing and Aggregated Bandwidth (if the MN is equipped with 552 several interfaces) 554 Current situation with MIPv6: 556 o Ubiquitous Access, Reliabiility 558 Fault recovery will be limited to the case where one of the CoAs 559 become unreachable for a particular peer. For instance, a CoA may 560 become unreachable because the ISP which provides the IPv6 prefix 561 fails. Fault recovery in MIPv6 is achieved by associating an 562 alternate CoA to replace the failed one. However, efficient 563 mechanisms are needed to determine that a CoA has failed (see 564 Section 6.1.3) and to determine which CoA should be used instead 565 (see below). 567 o Preference Setting, Load Sharing, Load balancing and Aggregated 568 Bandwidth 570 This configuration allows to share the load and set preferences 571 among different paths between the HA and the MN when BT mode is 572 used, and between the CN and the MN when RO mode is used. In 573 order to achieve load sharing, load balancing and aggregated 574 bandwidth under this scenario, the MN would need to register 575 several CoAs with its unique HoA. However, the present 576 specification of MIPv6 only allows the MN to register a single CoA 577 per HoA. This is discussed in Section 6.2.1. When a single HoA 578 is bounded to several CoAs at the same time, the MN or HA/CN must 579 be able to select the appropriate CoA. This selection could be 580 done based on user/application preferences (see Section 6.1.1). 582 5.4. (n,n): n HoAs, n CoAs 584 The MN is multihomed since it has multiple addresses. This case can 585 be viewed as a combination of the two cases described above: the MN 586 has several HoAs (e.g. given by different operators) and several CoAs 587 (e.g. because the node is receiving multiple IPv6 prefixes). As an 588 example, we can consider a node with three interfaces, two of them 589 connected to their home link (two different HoAs) and the last one 590 connected to a visited link where two IPv6 prefixes are available. 592 Achievable goals: ubiquitous access, reliability, load sharing, load 593 balancing and preferences settings. 595 Current situation with MIPv6: 597 o Ubiquitous Access, Reliability 599 If one CoA becomes unreachable (similar to scenario (1,n) in 600 Section 5.3), the MN can redirect flows to another CoA by 601 associating any other available CoAs to the corresponding HoA. If 602 the MN can not use one of its HoA anymore (similar to scenario 603 (n,1) in Section 5.2), the MN will have to re-initiate all flows 604 which were using the corresponding HoA. Redirection between the 605 addresses available for the MN will be different depending on this 606 HoA / CoA binding policies. 608 o Preference Settings, Load Sharing, Load Balancing and Aggregated 609 Bandwidth. 611 Currently, the MN can register only one CoA per HoA (see 612 Section 6.2.1), but it can register the same or different CoAs 613 with multiple HoAs. If the MN chooses to bind the same CoA to all 614 its HoAs, we fall in the (n,1) case. In this case, load sharing 615 can only be performed if route optimization is not used, on the 616 CN-HA path, as a different HoA may be used per CN. If the MN 617 chooses to bind a different CoA for each HoA, load sharing will be 618 done along the whole path across the MN and its CNs. Preference 619 settings may define which CoA (eventually several if bicasting is 620 used) should be bound to which HoA (see Section 6.1.1). 622 In a very specific situation, one of the routable address of the 623 MN (i.e., which can be directly used without tunneling to reach 624 the MN) can be one of its HoA. In this case, this HoA can be 625 viewed as a CoA to bind with another HoA. Thus the MN may be able 626 to register one HoA as CoA regarding another HoA (see 627 Section 6.3.1). MIPv6 does not prevent this behavior, which allow 628 to set a certain preference on addresses usage. 630 5.5. (n,0): n HoAs, no CoAs 632 This case happens when all the interfaces are connected to their 633 respective home links. This node can be considered as a fixed node 634 from a multihoming point of view. The node would no longer be in the 635 (n,0) configuration when one or more of the interfaces are attached 636 to foreign links. 638 The mobile node may wish to use one or more HoAs to serve as the CoA 639 of another HoA (see Section 6.3.1). In such situations, this 640 scenario is reduced to a (1,1) or (1,n) configuration as described in 641 Section 5.1 or Section 5.3. 643 Achievable goals: Ubiquitous Access, Reliability, Load Sharing, Load 644 Balancing, Aggregated Bandwidth, Preference Settings. 646 Current situation with MIPv6 648 o Ubiquitous Access and Reliability 650 If the MN is disconnected from one of its interfaces, the MN 651 should be able to register another valid HoA to its failed HoA 652 (see issue Section 6.3.1). 654 o Preference Settings, Load Sharing, Load Balancing and Aggregated 655 Bandwidth 657 This can be achieved when the MN is initiating the communication 658 flow, as it can choose which HoA should be used. Depending on how 659 CN can discover HoAs of the MN, these goals might also be achieved 660 when the CN is initiating the communication flow. See previous 661 scenario and discussions in Section 6.1.1 about the path 662 selection. If the flows binding on interfaces preferences change 663 over time, the MN should be able to redirect one flow from one 664 interface to another. However, MIPv6 only allows to redirect all 665 flows from one interface to another, assuming one HoA is 666 registered as CoA (see issue Section 6.3.1). If the MN policies 667 indicate to redirect only one flow, a supplementary mechanism 668 would be needed. 670 6. Issues 672 Existing protocols may not be able to handle the requirements 673 expressed in Section 3. For doing so, the issues discussed in this 674 section must be addressed, and solved preferably by dynamic 675 mechanisms. Note that some issues are pertaining to MIPv6 solely, 676 whereas other issues are not at all related to MIPv6. However, such 677 non MIPv6 issues must be solved in order to meet the requirements 678 outlined in Section 3. 680 In this section, we describe some of these issues in two main 681 headings: general IPv6-related issues, and issues that are specific 682 to MIPv6. Other concerns related to implementations of MIPv6 are 683 described in Section 6.3. Issues and their area of application are 684 summarized in Section 6.4 686 6.1. General IPv6-related Issues 688 6.1.1. Path Selection 690 When there exists multiple paths from and to the MN, the MN ends up 691 choosing a source and destination address, and possibly the interface 692 that should be used. 694 o Interface selection 696 When the node has multiple available interfaces, the simultaneous 697 or selective use of several interfaces would allow a mobile node 698 to spread flows between its different interfaces. 700 Each interface could be used differently according to some user 701 and applications policies and preferences that would define which 702 flow would be mapped to which interface and/or which flow should 703 not be used over a given interface. How such preferences would be 704 set on the MN is out of scope of MIPv6 and might be implementation 705 specific. On the other hand, if the MN wishes to influence how 706 preferences are set on distant nodes (Correspondent Node or Home 707 Agent), mechanisms such as those proposed in [6], [7] and [8] 708 could be used. 710 o HoA Selection 712 When multiple HoAs are available, the MN and its communicating 713 peers (HA and CNs) must be able to select the appropriate HoA to 714 be used for a particular packet or flow. 716 This choice would be made at the time of a new communication flow 717 set up. Usual IPv6 mechanisms for source and destination address 718 selection, such as "Default Address Selection for IPv6" [9] could 719 be used. 721 However, in RFC3484 it is said that "If the eight rules fail to 722 choose a single address, some unspecified tie-breaker should be 723 used". Therefore more specific rules in addition to those 724 described on RFC3484 may be defined for HoA selection. 726 o CoA Selection 728 When multiple CoAs are available, the MN and its communicating 729 peers (HA and CNs) must be able to select the appropriate CoA to 730 be used for a particular packet or flow. the MN must use its 731 internal policies to distribute its flow, but also to distribute 732 policies on distant nodes to allow them to select the right CoA. 733 Solutions like nomadv6 [8] or HA filtering [7] may be used. 735 Another related aspect of path selection is the concern of ingress 736 filtering. This is detailed in Section 6.1.2. 738 6.1.2. Ingress Filtering 740 In the (*,n) case, a MN may be connected to multiple access networks 741 or multiple home networks each practicing ingress filtering [10], 742 [11]. Thus, to avoid ingress filtering, the selection of path would 743 be limited by the choice of address used. This is related to 744 Section 6.1.1. The problem of ingress filtering however, is two- 745 fold. It can occur at the access network, as well as the home 746 network. 748 For instance, consider Figure 2 below. In the access network, when 749 mobile node MN sends a packet through AR-A, it must use CoA=PA.MN; 750 and when MN sends a packet through AR-B, it must use CoA=PB.MN. In 751 the home network, when MN tunnels the packet to home agent HA-1, it 752 must use HoA=P1.MN; and when MN tunnels the packet to home agent 753 HA-2, it must use HoA=P2.MN. This greatly limits the way MN can 754 benefit from its multihoming configuration. 756 As an illustration, suppose MN is choosing the interface (which would 757 determine the CoA used) and the home network to use (which would 758 determine the HoA used), it might be possible that the chosen CoA is 759 not registered with the chosen HoA. 761 Prefix: PA +------+ +----------+ +------+ 762 HoA: P1.MN /-----| AR-A |----| |----| HA-1 | 763 CoA: PA.MN / +------+ | | +------+ 764 +----+ | | Prefix: P1 765 | MN | | Internet | 766 +----+ | | Prefix: P2 767 HoA: P2.MN \ +------+ | | +------+ 768 CoA: PB.MN \-----| AR-B |----| |----| HA-2 | 769 Prefix: PB +------+ +----------+ +------+ 771 Figure 2: MN connected to Multiple Access/Home Networks 773 It must be noted that should the mobile node MN have a way of binding 774 both CoAs PA.MN and PB.MN simultaneously to each of HoAs P1.MN and 775 P2.MN (see Section 6.2.1), then it can choose the CoA to use based on 776 the access network it wishes to use for outgoing packets. This 777 solves the first part of the problem: ingress filtering at the access 778 network. It is, nonetheless, still limited to using only a specific 779 home agent for the home-address used (i.e. the second problem of 780 ingress filtering at the home network remains unsolved). 782 6.1.3. Failure detection 784 Currently, IPv6 has no clearly defined mechanism for failure 785 detection. A failure in the path between two nodes can be located at 786 many different places: the media of one of the node is broken (i.e., 787 loss of connectivity), the path between the MN and the HoA is broken, 788 the home link is disconnected from the Internet, etc. By now, MIPv6 789 only relies on the ability or the inability to receive Router 790 Advertisements within a stipulated period to detect the availibility 791 or loss of media. Current effort [12] in the DNA Working Group aims 792 to address this, such as through the use of layer 2 triggers [13]. 793 Movement detection might be extended to include other triggers such 794 as the loss of connectivity on one interface. Further mechanisms 795 would be needed to detect a failure in the path between a MN and its 796 CN(s), as well as between the MN and its HoA(s), between the MN and 797 CN(s), or between the MN and CN(s). 799 6.2. MIPv6-specific Issues 801 6.2.1. Binding Multiple CoAs to a given HoA 803 In the (1,n) cases, multiple CoAs would be available to the MN. In 804 order to use them simultaneously, the MN must be able to bind and 805 register multiple CoAs for a single HoA with both the HA and the CNs. 806 The MIPv6 specification is currently lacking such ability. 808 Although in the (n,n) cases, MIPv6 allows MN to have multiple HoA and 809 CoA pairs, the upper layer's choice of using a particular HoA would 810 mean that the MN is forced to use the corresponding CoA. This 811 constrains the MN from choosing the best (in terms of cost, bandwidth 812 etc) access link for a particular flow, since CoA is normally bound 813 to a particular interface. If the MN can register all available CoAs 814 with each HoA, this would completely decouple the HoA from the 815 interface, and allow the MN to fully exploit its multihoming 816 capabilities. 818 To counter this issue, solutions like [14] may be used. 820 6.2.2. Simultaneous Location in Home and Foreign Networks 822 Rule 4 of RFC3484 specifies that a HoA will always be preferred to a 823 CoA. While this rule allows to choose which address to use, it does 824 not allow MN to benefit from being multihomed. When a MN is 825 multihomed, it may have one of its interfaces directly connected to a 826 home link. This may have an impact on the way multihoming is 827 managed, since addresses from other interfaces cannot be registered 828 as CoAs for the HoA associated to the home link the mobile node is 829 connected on. 831 In the special case of (1,*) where one of the interface is connected 832 to the home link, none of the other addresses can be used to achieve 833 multihoming goals with the HA. 835 6.3. Considerations for MIPv6 Implementation 837 In addition to the issues described in Section 6.1 and Section 6.2, 838 there are other concerns implementers should take into consideration 839 so that their MIPv6 implementations are more "friendly" to the use of 840 multiple interfaces. These implementation-related considerations are 841 described in the sub-sections below. 843 6.3.1. Using one HoA as a CoA 845 In (n,*) cases, the MN has multiple HoAs. A HoA may be seen as a CoA 846 from the perspective of another home link of the same MN. 848 As an example, a MN has two HoAs (HoA1 and HoA2) on two distinct home 849 links. MN is connected to these two home links via two interfaces. 850 If the MN looses its connectivity on its first interface, HoA1 is not 851 reachable. It may then want to register HoA2 as a CoA for HoA1 in 852 order to keep receiving packets intended to HoA1, via the second 853 interface. 855 According to the definition of a CoA, the current MIPv6 specification 856 does not prohibit a HoA to be a CoA from the perspective of another 857 HoA. 859 In RFC3775 section 6.1.7 it is written: " Similarly, the Binding 860 Update MUST be silently discarded if the care-of address appears as a 861 home address in an existing Binding Cache entry, with its current 862 location creating a circular reference back to the home address 863 specified in the Binding Update (possibly through additional 864 entries)." 866 In order to benefit from any multihoming configuration, a MN must be 867 able to register whatever address it owns with any of its HoA, as 868 long as the above statement is verified. 870 6.3.2. Binding a new CoA to the Right HoA 872 In the (n,*) cases, the MN has multiple HoAs. When the MN moves and 873 configures a new CoA, the newly obtained CoA must be bound to a 874 specific HoA. The current MIPv6 specification doesn't provide a 875 decision mechanism to determine to which HoA this newly acquired CoA 876 should be bound to. 878 With no such mechanism, the MN may be confused and may bind this CoA 879 to a possibly wrong HoA. The result might be to bind the CoA to the 880 same HoA the previous CoA was bound to or to another one, depending 881 on the implementation. It would indeed be better to specify the 882 behavior so that all implementations are compliant. 884 6.3.3. Binding HoA to interface 886 In (n,*) cases, MIPv6 does not provide any information on how HoAs 887 should be bound on a device, and particularly there is no mechanism 888 to bind HoAs to interfaces. 890 This may be troublesome, for example, when we consider a MN 891 configured with two HoAs and equipped with three interfaces. When 892 the MN is connected to a home link via one interface, it will need to 893 bind the corresponding HoA to this interface, even if the HoA was 894 initially assigned to another one. 896 HoA1 HoA2 898 CoA1 CoA2 CoA3 899 Iface1 Iface2 Iface3 901 Figure 3: Illustration of the case (2,3) 903 HoA must always be assigned to an activated interface and if the MN 904 is connected to its home link, the corresponding HoA must be used on 905 this interface. In some cases, the HoA then would have to be re- 906 assigned to another interface in case of connection loss or 907 attachment to the home link. 909 6.3.4. Flow redirection 911 Internet connectivity is guaranteed for a MN as long as at least one 912 path is maintained between the MN and its CN. When an alternative 913 path must be found to substitute for another one, the loss of one 914 path to the Internet may result in broken sessions. In this case, 915 new transport sessions would have to be established over the 916 alternate path if no mechanism is provided to redirect flow 917 transparently at layers above layer 3. The need for flow redirection 918 is given in Appendix A. 920 The different mechanisms that can be used to provide flow redirection 921 can be split into two categories, depending on the part of the path 922 that needs to be changed. The first category is when the CoA 923 changes: if one of the MN's CoA needs to be changed, it influences 924 the path between the MN and its HA, and the path between the MN and 925 its CN in RO mode. If the MN has multiple interfaces and one fails, 926 established sessions on the failed interface would break if no 927 support mechanism is used to redirect flows from the failed interface 928 to another. 930 The second category is when the HoA changes: if one of the MN's HoA 931 needs to be changed, it influences the path between the CN and the 932 HoA. In (n,*) cases, the MN has multiple HoAs. If one fails, 933 established sessions on the failed HoA would break if no support 934 mechanism is used to redirect flows from a failed HoA to another, 935 unless the transport session has multihoming capabilities, such as 936 SCTP, to allow dynamic changing of addresses used. 938 6.4. Summary 940 THIS TABLE IS A WORK IN PROGRESS (so all boxes may not have been 941 filled appropriately). For now, please comment on the need for the 942 table rather than the content) 943 +=====================================================+ 944 | # of HoAs: | 1 | 1 | n | n | n | 945 | # of CoAs: | 1 | n | 0 | 1 | n | 946 +=====================================================+ 947 | General IPv6 Issues | 948 +---------------------------------+---+---+---+---+---+ 949 | Path Selection | | o | ? | o | o | 950 +---------------------------------+---+---+---+---+---+ 951 | Ingress Filtering | | | ? | o | o | 952 +---------------------------------+---+---+---+---+---+ 953 | Failure detection |o | o | ? | o | o | 954 +---------------------------------+---+---+---+---+---+ 955 | MIPv6-Specific Issues | 956 +---------------------------------+---+---+---+---+---+ 957 | Binding Multiple CoAs to a | | o | ? | o | o | 958 | given HoA | | | | | | 959 +---------------------------------+---+---+---+---+---+ 960 | Using one HoA as a CoA | | | ? | o | o | 961 +---------------------------------+---+---+---+---+---+ 962 | Simultaneous location in home | | o | ? | o | o | 963 | and foreign networks | | | ? | | | 964 +---------------------------------+---+---+---+---+---+ 965 | Implementation-Related Concerns | 966 +---------------------------------+---+---+---+---+---+ 967 | Binding a new CoA to the | | | ? | o | o | 968 | right HoA | | | | | | 969 +---------------------------------+---+---+---+---+---+ 970 | Binding HoA to interface(s) | o | o | ? | o | o | 971 +---------------------------------+---+---+---+---+---+ 972 | Flow redirection | o | o | ? | o | o | 973 +=====================================================+ 975 Figure 4: Summary of Issues and Categorization 977 7. TODO List 979 Study security concerns 981 Possibly discuss the possibility to use HoA on both home link and 982 foreign link as in case (1,1): 984 Mention about relation with Shim6. 986 Reword all the text about the "returning home case" throughout the 987 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, and Romain Kuntz 1017 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] Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to 1025 Protect Mobile IPv6 Signaling Between Mobile Nodes and Home 1026 Agents", RFC 3776, June 2004. 1028 [3] Ernst, T., "Motivations and Scenarios for Using Multiple 1029 Interfaces and Global Addresses", 1030 draft-ietf-monami6-multihoming-motivations-scenarios-00 (work 1031 in progress), February 2006. 1033 [4] Manner, J. and M. Kojo, "Mobility Related Terminology", 1034 RFC 3753, June 2004. 1036 [5] Bagnulo, M. and E. Nordmark, "Level 3 multihoming shim 1037 protocol", draft-ietf-shim6-proto-03 (work in progress), 1038 December 2005. 1040 [6] Soliman, H., Malki, K., and C. Castelluccia, "Per-flow movement 1041 in MIPv6", draft-soliman-mobileip-flow-move-02 (work in 1042 progress), July 2002. 1044 [7] Montavont, N. and T. Noel, "Home Agent Filtering for Mobile 1045 IPv6", draft-montavont-mobileip-ha-filtering-v6-00 (work in 1046 progress), January 2004. 1048 [8] Kuladinithi, K., "Filters for Mobile IPv6 Bindings (NOMADv6)", 1049 draft-nomadv6-mobileip-filters-03 (work in progress), 1050 October 2005. 1052 [9] Draves, R., "Default Address Selection for Internet Protocol 1053 version 6 (IPv6)", RFC 3484, February 2003. 1055 [10] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 1056 Networks", BCP 84, RFC 3704, March 2004. 1058 [11] Ferguson, P. and D. Senie, "Network Ingress Filtering: 1059 Defeating Denial of Service Attacks which employ IP Source 1060 Address Spoofing", BCP 38, RFC 2827, May 2000. 1062 [12] Choi, J., "Goals of Detecting Network Attachment in IPv6", 1063 draft-ietf-dna-goals-04 (work in progress), December 2004. 1065 [13] Yegin, A., "Link-layer Event Notifications for Detecting 1066 Network Attachments", draft-ietf-dna-link-information-03 (work 1067 in progress), October 2005. 1069 [14] Wakikawa, R., "Multiple Care-of Addresses Registration", 1070 draft-wakikawa-mobileip-multiplecoa-04 (work in progress), 1071 June 2005. 1073 [15] Yegin, A., "Link-layer Hints for Detecting Network 1074 Attachments", draft-yegin-dna-l2-hints-01 (work in progress), 1075 February 2004. 1077 [16] Montavont, N., "Mobile IPv6 for multiple interfaces (MMI)", 1078 draft-montavont-mip6-mmi-02 (work in progress), July 2005. 1080 Appendix A. Why a MN may want to redirect flows 1082 When a MN is multihomed, an addresses selection mechanism is needed 1083 to distribute flows over interfaces. As policies may change over 1084 time, as well as the available addresses/interfaces, flow redirection 1085 mechanisms are needed. While the selection policy is out of scope of 1086 this document, the following reasons may trigger the MN to redirect 1087 flow from one address to another: 1089 o Failure detection: the path between the MN and its CN(s) is 1090 broken. The failure can occur at different places onto this path; 1091 The failure can be local on the MN, where the interface used on 1092 the MN is disconnected from the network (e.g., a wireless 1093 interface which comes out of range from its point of attachment). 1094 Alternatively, the failure can be on the path between the MN and 1095 one of its HA. Yet another alternative is that the failure can be 1096 on the path between the HA and the CN. If route optimization is 1097 used, it can also be a failure between the MN and its CN(s). 1099 o New address: a new address on the MN comes available. This can be 1100 the case when the MN connects to the network with a new interface. 1101 The MN may decide that this new interface is most suitable for its 1102 current flows that are using another interface. 1104 o Uninterrupted horizontal handover in mobility: If the MN is 1105 mobile, it may have to change its point of attachment. When a MN 1106 performs a horizontal handover, the handover latency (the time 1107 during which the MN can not send nor receive packets) can be long 1108 and the flows exchanged on the interface can be interrupted. If 1109 the MN wants to minimize such perturbation, it can redirect some 1110 or all the flows on another available interface. This redirection 1111 can be done prior to the handover if L2 triggering is considered 1112 [13] [15] 1114 o Change in the network capabilities: the MN can observe a 1115 degradation of service on one of its interface, or conversely an 1116 improvement of capacity on an interface. The MN may then decide 1117 to redirect some or all flows on another interface that it 1118 considers most suitable for the target flows. 1120 o Initiation of a new flow: a new flow is initiated between the MN 1121 and a CN. According to internal policies, the MN may want to 1122 redirect this flow on a most suitable interface. 1124 Authors' Addresses 1126 Nicolas Montavont 1127 Ecole Nationale Superieure des telecommunications de Bretagne 1128 2, rue de la chataigneraie 1129 Cesson Sevigne 35576 1130 France 1132 Phone: (+33) 2 99 12 70 23 1133 Email: nicolas.montavont@enst-bretagne.fr 1134 URI: http://www-r2.u-strasbg.fr/~montavont/ 1136 Ryuji Wakikawa 1137 Keio University 1138 Department of Environmental Information, Keio University. 1139 5322 Endo 1140 Fujisawa, Kanagawa 252-8520 1141 Japan 1143 Phone: +81-466-49-1100 1144 Fax: +81-466-49-1395 1145 Email: ryuji@sfc.wide.ad.jp 1146 URI: http://www.wakikawa.net/ 1148 Thierry Ernst 1149 Keio University / WIDE 1150 Jun Murai Lab., Keio University. 1151 K-square Town Campus, 1488-8 Ogura, Saiwa-Ku 1152 Kawasaki, Kanagawa 212-0054 1153 Japan 1155 Phone: +81-44-580-1600 1156 Fax: +81-44-580-1437 1157 Email: ernst@sfc.wide.ad.jp 1158 URI: http://www.sfc.wide.ad.jp/~ernst/ 1159 Chan-Wah Ng 1160 Panasonic Singapore Laboratories Pte Ltd 1161 Blk 1022 Tai Seng Ave #06-3530 1162 Tai Seng Industrial Estate 1163 Singapore 534415 1164 SG 1166 Phone: +65 65505420 1167 Email: chanwah.ng@sg.panasonic.com 1169 Koojana Kuladinithi 1170 University of Bremen 1171 ComNets-ikom,University of Bremen. 1172 Otto-Hahn-Allee NW 1 1173 Bremen, Bremen 28359 1174 Germany 1176 Phone: +49-421-218-8264 1177 Fax: +49-421-218-3601 1178 Email: koo@comnets.uni-bremen.de 1179 URI: http://www.comnets.uni-bremen.de/~koo/ 1181 Intellectual Property Statement 1183 The IETF takes no position regarding the validity or scope of any 1184 Intellectual Property Rights or other rights that might be claimed to 1185 pertain to the implementation or use of the technology described in 1186 this document or the extent to which any license under such rights 1187 might or might not be available; nor does it represent that it has 1188 made any independent effort to identify any such rights. Information 1189 on the procedures with respect to rights in RFC documents can be 1190 found in BCP 78 and BCP 79. 1192 Copies of IPR disclosures made to the IETF Secretariat and any 1193 assurances of licenses to be made available, or the result of an 1194 attempt made to obtain a general license or permission for the use of 1195 such proprietary rights by implementers or users of this 1196 specification can be obtained from the IETF on-line IPR repository at 1197 http://www.ietf.org/ipr. 1199 The IETF invites any interested party to bring to its attention any 1200 copyrights, patents or patent applications, or other proprietary 1201 rights that may cover technology that may be required to implement 1202 this standard. Please address the information to the IETF at 1203 ietf-ipr@ietf.org. 1205 Disclaimer of Validity 1207 This document and the information contained herein are provided on an 1208 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1209 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1210 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1211 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1212 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1213 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1215 Copyright Statement 1217 Copyright (C) The Internet Society (2006). This document is subject 1218 to the rights, licenses and restrictions contained in BCP 78, and 1219 except as set forth therein, the authors retain all their rights. 1221 Acknowledgment 1223 Funding for the RFC Editor function is currently provided by the 1224 Internet Society.