MONAMI6 Working Group N. Montavont Internet-Draft GET/ENST-B Intended status: Informational R. Wakikawa Expires: May 22, 2008 Keio University T. Ernst INRIA C. Ng Panasonic Singapore Labs K. Kuladinithi University of Bremen November 19, 2007 Analysis of Multihoming in Mobile IPv6 draft-ietf-monami6-mipv6-analysis-04 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on May 22, 2008. Copyright Notice Copyright (C) The IETF Trust (2007). Montavont, et al. Expires May 22, 2008 [Page 1] Internet-Draft Analysis of Multihoming in MIPv6 November 2007 Abstract Mobile IPv6 as specified in RFC 3775 allows a mobile node to maintain its IPv6 communications while moving between subnets. This document investigates configurations where a mobile node running Mobile IPv6 is multihomed. The use of multiple addresses is foreseen to provide ubiquitous, permanent and fault-tolerant access to the Internet, particularly on mobile nodes which are more prone to failure or sudden lack of connectivity. However, Mobile IPv6 currently lacks support for such multihomed nodes. The purpose of this document is to detail all the issues arising through the operation of Mobile IPv6 on multihomed mobile nodes. Montavont, et al. Expires May 22, 2008 [Page 2] Internet-Draft Analysis of Multihoming in MIPv6 November 2007 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 3. Goals and Node Capabilities . . . . . . . . . . . . . . . . . 9 4. Taxonomy . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 5. Multihoming Configurations . . . . . . . . . . . . . . . . . . 13 5.1. (1,1): 1 HoA, 1 CoA . . . . . . . . . . . . . . . . . . . 13 5.2. (n,1): n HoAs, 1 CoA . . . . . . . . . . . . . . . . . . . 14 5.3. (1,n): 1 HoA, n CoAs . . . . . . . . . . . . . . . . . . . 16 5.4. (n,n): n HoAs, n CoAs . . . . . . . . . . . . . . . . . . 17 5.5. (n,0): n HoAs, no CoAs . . . . . . . . . . . . . . . . . . 18 6. Multihoming Issues . . . . . . . . . . . . . . . . . . . . . . 19 6.1. General IPv6-related Issues . . . . . . . . . . . . . . . 19 6.1.1. Failure Detection . . . . . . . . . . . . . . . . . . 19 6.1.2. Path Exploration . . . . . . . . . . . . . . . . . . . 19 6.1.3. Path Selection . . . . . . . . . . . . . . . . . . . . 20 6.1.4. Rehoming . . . . . . . . . . . . . . . . . . . . . . . 21 6.1.5. Ingress Filtering . . . . . . . . . . . . . . . . . . 22 6.2. MIPv6-specific Issues . . . . . . . . . . . . . . . . . . 23 6.2.1. Binding Multiple CoAs to a given HoA . . . . . . . . . 23 6.2.2. Simultaneous Location in Home and Foreign Networks . . 24 6.2.3. HA Synchronization . . . . . . . . . . . . . . . . . . 24 6.3. Considerations for MIPv6 Implementation . . . . . . . . . 24 6.3.1. Using one HoA as a CoA . . . . . . . . . . . . . . . . 25 6.3.2. Binding a new CoA to the Right HoA . . . . . . . . . . 25 6.3.3. Binding HoA to interface . . . . . . . . . . . . . . . 25 6.4. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 26 7. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 28 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 9. Security Considerations . . . . . . . . . . . . . . . . . . . 30 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 31 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 32 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33 12.1. Normative References . . . . . . . . . . . . . . . . . . . 33 12.2. Informative References . . . . . . . . . . . . . . . . . . 33 Montavont, et al. Expires May 22, 2008 [Page 3] Internet-Draft Analysis of Multihoming in MIPv6 November 2007 Appendix A. Why a MN may want to redirect flows . . . . . . . . . 35 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36 Intellectual Property and Copyright Statements . . . . . . . . . . 38 Montavont, et al. Expires May 22, 2008 [Page 4] Internet-Draft Analysis of Multihoming in MIPv6 November 2007 1. Introduction The emergence of performant wireless technologies has favored node mobility within the Internet. Nowadays, and even more tomorrow, nodes are highly mobile and can change their point of attachment to the Internet at any time, even during active network connections. As such, Mobile IPv6 (RFC 3775 [1] and RFC 3776 [2]) allows mobile nodes to maintain sessions open while changing their point of attachment to the Internet. Besides - as explained in [3] - ubiquitous, permanent, fault-tolerant and heterogeneous access to the Internet is required . For doing so, mobile nodes which are prone to failure or sudden lack of connectivity shall be equipped with multiple interfaces. They may also be connected to multihomed networks. In such a situation, mobile nodes would be allocated multiple addresses and are said to be multihomed. These addresses would be assigned to a single interface or to multiple interfaces. However, the current specification of Mobile IPv6 lacks support for using multiple addresses simultaneously. Individual solutions have been proposed to extend Mobile IPv6 in such a way but all issues have not been addressed and not even discussed in some document. This study aims at fulfilling this gap and has two thus goals. The first goal is to determine the capabilities required for providing ubiquitous, permanent, fault-tolerant and heterogeneous access to the Internet to multihomed mobile nodes operating Mobile IPv6. The second goal is to define the issues arising when we attempt to fulfill these requirements. The definition of solutions addressing these issues is out of scope of this document. To understand the foundation of this study, the reader shall read the companion document [3] which outlines the motivations, the goals and the benefits of multihoming for both fixed and mobile nodes (i.e. generic IPv6 nodes). Real-life scenarios as illustrated in that document are the base motivations for the present study. The reader shall also understand the operation of the Mobile IPv6 protocol (RFC3775 [1]). The document is organized as follows: in Section 2, we introduce the terminology related to multihoming and used in this document. In Section 3 we recall and refine the design goals behind multihoming and we discuss what are the required capabilities on the mobile nodes to fully meet these design goals. Then we propose in Section 4 a taxonomy to classify the different cases where mobile nodes are multihomed. Thereafter the taxonomy is used in Section 5 to describe Montavont, et al. Expires May 22, 2008 [Page 5] Internet-Draft Analysis of Multihoming in MIPv6 November 2007 a number of multihomed configurations specific to Mobile IPv6. For each case, we show the resulting addressing configuration (number of Home Addresses, and the number of Care-of Addresses). Each configuration is illustrated with example diagrams and the means to meet the requirements are outlined. Finally we discuss in Section 6 all issues related to a multihomed mobile node and we identify what is missing in order to reach the goals outlined in [3]. These issues are classified into IPv6 issues, Mobile IPv6-specific issues, and advices to implementers. Montavont, et al. Expires May 22, 2008 [Page 6] Internet-Draft Analysis of Multihoming in MIPv6 November 2007 2. Terminology The terms used in the present document are defined in RFC3753 [4], RFC3775 [1] and [3]. In this document we are using the following terms and abbreviations: o MIPv6 The Mobile IPv6 protocol specified in RFC3775 [1] o MN a Mobile Node operating MIPv6 o HA a Mobile IPv6 Home Agent o HoA a Mobile IPv6 Home Address o CoA a Mobile IPv6 Care-of Address o Multihomed MN In the companion document [3], a node is said to be multihomed when it has multiple IPv6 addresses, either because multiple prefixes are advertised on the link(s) the node is attached to, or because the node has multiple interfaces (see the entire definition). For a mobile node operating MIPv6, this may translate into the following definition: A MN is said multihomed when it has either i) multiple addresses which are used as source addresses or ii) multiple tunnels to transmit packets, or both. A MN may have multiple tunnels in the following cases: * When it has multiple HoAs, that is if multiple prefixes are available on the home link or if it has multiple interfaces named on (presumably) distinct home links. * When it has multiple CoAs, that is if multiple prefixes are available on the foreign link or if it has multiple interfaces Montavont, et al. Expires May 22, 2008 [Page 7] Internet-Draft Analysis of Multihoming in MIPv6 November 2007 attached to (presumably) distinct foreign links. * When the HA has multiple addresses. o A valid address An address that is topologically correct (it is configured from the prefix available on the link the interface is attached to) and routable. o Simultaneously using multiple addresses A MN is using multiple addresses simultaneously when an incoming packet with the destination address set to any of these addresses reaches the MN, or when any of these addresses can be used by the MN as the source address of outcoming packets. o Simultaneously using multiple interfaces A MN is using multiple interfaces simultaneously when it can transmit IP packets over any of these interfaces. o BT Mode MIPv6 Bidirectional tunnel between MN and HA. o RO Mode MIPv6 Route optimization between MN and CN. Montavont, et al. Expires May 22, 2008 [Page 8] Internet-Draft Analysis of Multihoming in MIPv6 November 2007 3. Goals and Node Capabilities In this section, we determine what are the capabilities required on the mobile nodes in order to benefit from multihoming configurations, as indicated in [3] where a number of goals/benefits are listed: ubiquitous access, flow redirection, reliability, load sharing, inteface switching, preference settings, and aggregate bandwidth. These do somwhat overlap, i.e., they are not totally independent. Reaching one of them may imply reaching another one as well. For this reason, the following non-overlapping goals could be extracted: 1. Reliability 2. Load Sharing 3. Flow Distribution From now on, this document will focus on these three non-overlapping goals, as in this section to determine capabilities. We will determine later in Section 5 which capabilities are already fulfilled by Mobile IPv6 and what issues still remain. Basically, Internet connectivity is guaranteed for a MN as long as at least one path is maintained between the MN and the fixed Internet. This path can be divided into two portions: the path between the MN and its HA(s) and the path between the HA(s) and the CN. If RO is in place between the MN and a CN, an additional path between the MN and the CN must be guaranteed. In some cases, it may be necessary to divert packets from a (perhaps failed) path to an alternative (perhaps newly established) path (e.g. for matters of reliability, preferences), or to split traffic between multiple paths (e.g. for load sharing, flow distribution). The use of an alternative path must be transparent at layers above layer 3 if broken sessions and the establishment of new transport sessions has to be avoided. In order to meet some of the goals (particularly flow distribution and load sharing), multiple paths must be maintained simultaneously between the MN and its CN. This translates into the following capabilities: 1. A mechanism should be available to quickly activate a backup interface and redirect traffic when an interface fails (e.g., loss of connection). 2. A mechanism should be available to quickly redirect flows from one address to another when it is needed. Some of the triggers of flow redirection are given in Appendix A. Montavont, et al. Expires May 22, 2008 [Page 9] Internet-Draft Analysis of Multihoming in MIPv6 November 2007 3. A MN allocated with multiple valid addresses must be able to use them simultaneously. 4. A MN equipped with multiple interfaces (attached to distinct foreign links or distinct home links, or a combination of both) must be able to use them simultaneoulsy. 5. A MN should be able to distribute its traffic load among its valid global addresses. 6. If multiple HAs are available to manage bindings for a given HoA, the MN should be able to use them simultaneously or to switch between them. One has to consider whether these goals can be achieved with transparency or without transparency. Transparency is achieved when switching between interfaces does not cause the disruption of on- going sessions. To be achieved with transparency, a necessary (may or may not be sufficient) condition is for the end-point addresses at the transport/application layer to remain unchanged. This is in view of the large amount of Internet traffic currently carried by TCP, which unlike SCTP, cannot handle multiple end-point address pairs. Each of the aforementioned goals can be achieved independently. We define here which of the above capabilities are needed for each goal: 1. Reliability: 1, 2, 3, 6 2. Load Sharing: 3, 6 3. Flow Distribution: 2, 3, 4, 5, 6 Montavont, et al. Expires May 22, 2008 [Page 10] Internet-Draft Analysis of Multihoming in MIPv6 November 2007 4. Taxonomy In order to examine the issues preventing a MN to meet the requirements listed in Section 3 we use in the present document the following taxonomy (x,y) where: o x = number of Home Addresses (HoAs) o y = number of Care-of Addresses (CoAs) A value of '1' implies there is a single instance of the parameter, whereas a value of 'n' indicates that there are multiple instances of the parameter. A value of '0' implies that there is no instance of this parameter. A value '*' indicates that the number can be '0', '1' or 'n'. An illustration of this taxonomy is given in Figure 1. Mobile Node HoA1 HoA2 ... HoAn --> Permanent Address (x) | | | +-----+--------+ | | | | | | | CoA1 +--CoA2 +---CoA3 ... CoAn --> Temporary Address (y) | | | | Link1 Link2 Link3 ... Linkn --> IPv6 Link (n/a *) | | | | +-----+----+ | | | | | IF1 IF2 ... IFn --> Physical layer CoA1, CoA2, CoA3 are bound to HoA1 on IF1 and IF2 CoA3 is bound to HoA2 on IF2 * n/a because the number of IPv6 links is equal to number of CoAs (y) Figure 1: Illustration of the Taxonomy As the taxonomy suggests, the fact that a mobile node has several HoAs is independent from it having multiple interfaces. Having multiple interfaces does not imply that it has multiple HoAs and vice-versa. Similarly, the number of CoAs is independent from the number of HoAs and the number of interfaces. While a node would probably have at least one CoA per interface, multiple prefixes available on a link may lead the node to configure several CoAs on that link. Montavont, et al. Expires May 22, 2008 [Page 11] Internet-Draft Analysis of Multihoming in MIPv6 November 2007 The proposed taxonomy has two parameters because each of them has an influence on either the mobile node behavior / management, or the potential benefits the mobile node may obtain from such a configuration. The configurations denoted by these parameters will have an impact on how multihoming is supported. Depending on the number of HoAs and CoAs, different policies will be needed, such as "which CoA has to be mapped to which HoA", "must all the CoAs be mapped with all the HoAs", etc. Montavont, et al. Expires May 22, 2008 [Page 12] Internet-Draft Analysis of Multihoming in MIPv6 November 2007 5. Multihoming Configurations In this section, we detail all the possible multihoming configurations. We briefly discuss the current situation with MIPv6 and we point to issues that will be further detailed in Section 6.1, Section 6.2 and Section 6.3. As it is demonstrated below, we notice that: o When the mobile nodes is equipped with multiple interfaces, reliability, load sharing and flow distribution can be achieved in all (*,*) cases. o When a single interface is available, none of the goals can be achieved in the (1,1) case (the MN is not multihomed). In all the other cases, only reliability and load sharing can be achieved. 5.1. (1,1): 1 HoA, 1 CoA A MN in this configuration with only a single network interface is not multihomed. This configuration is the common case of a MN away from its home link: the node has one HoA and one CoA which is configured on the foreign link. None of the multihoming goals are achievable. A MN in the same configuration but with several interfaces is multihomed and lead to a special situation where the MN is connected to both its home link and a foreign link. In order to use both interfaces simultaneously, the HoA would be directly used on the interface connected to the home link, and a CoA configured on the other interface connected to a foreign link. There cannot be more than two active interfaces in the (1,1) case, otherwise the MN would either have (A) multiple interfaces on the home link, or (B) multiple interfaces on foreign links. For (A), there would be multiple HoAs. For (B) there would be multiple CoAs. These are indeed cases (n,*) (see Section 5.2 , Section 5.4 and Section 5.5) and (*,n) (see Section 5.3 and Section 5.4), respectively. Current situation with MIPv6 (when the node has multiple interfaces): o Reliability Reliability is achievable, but in a limited manner. The MN has two valid addresses, but is unable to use both addresses simultaneously: it cannot register the CoA configured on the foreign network with its HA and receive packets from the HA via a tunnel to the CoA at the same time it receives packet on the HoA from the home link. In addition, if the MN looses its connection Montavont, et al. Expires May 22, 2008 [Page 13] Internet-Draft Analysis of Multihoming in MIPv6 November 2007 established using the CoA on the foreign link, flows must be re- initiated with another address (either the HoA, or a new CoA obtained on another foreign link). Fault recovery is thus only possible without transparency, and MIPv6 features can only recover the failure of the HoA. This issue is detailed in Section 6.2.2. However, it might be possible for the MN to register the CoA with selected CNs (i.e. route optimization). In this case, the MN can enjoy a better reliability for communications sessions opened with these CNs. When the CoA fails, the MN can either bind a new CoA, or remove the binding and directly get the packets to its HoA. Reliability could also be achieved through bi-casting since the MN has two addresses and should be able to request any CN to duplicate traffic to both of them. However, MIPv6 does not allow the MN to request bi-casting on the CN (see Section 6.2.2). o Load Sharing, Flow Distribution The MN is able to use both interfaces at the same time, according to some preference settings on its side to decide which one to use for which application. Therefore load sharing and flow distribution can be achieved when sessions are initiated by the MN. When a CN initiates a session with the MN, it would choose the destination address depending on the available information about the MN (e.g., DNS request). Presently there is no mechanism allowing the MN to indicate on which interface (i.e., address) a CN may reach it. If only one address is known by the distant node, load sharing and flow distribution cannot be achieved. See in Section 6.1.3 where such path selection issues are discussed. 5.2. (n,1): n HoAs, 1 CoA A MN in this configuration is multihomed since it has several HoAs. This case may happen when a node gets access to the Internet through different HAs (possibly distinct operators), each offering a Mobile IPv6 service to the node. That way, the node would have a HoA per HA. Alternatively, a single home network may be multihomed to the Internet, leading to the advertisement of multiple prefixes on the home link. The MN would thus have multiple HoAs on a single home link. In either cases, the node would configure a single CoA on the visited IPv6 subnet, and bind that single CoA to all its HoAs. If the MN has multiple interfaces, only one interface is connected to a foreign network. The other interfaces are connected to their home links, or are inactive. Montavont, et al. Expires May 22, 2008 [Page 14] Internet-Draft Analysis of Multihoming in MIPv6 November 2007 Current situation with MIPv6: o Reliability If the HA fails, the session using the fail HA must be restarted since MIPv6 does not provide any mechanism to hand-over transparently from a HA to another one. Fault tolerance cannot be achieved in this case, since established communications cannot be preserved. See the corresponding discussion in Section 6.1.4 and Section 6.2.3. If one of the HoA of the mobile node fails, it means either that the corresponding HA has failed (which is the case discussed above), or the HoA is no longer routed to the HA. In that latter case, sessions using that HoA would be temrinated, since the HoA cannot be changed transparently. The CoA may change when the MN has multiple interfaces and is disconnected from its home link (e.g. failure of the interface, or movement). In such a situation, MIPv6 allows transparent redirection of flows using the old CoA (i.e. the session was initiated using the HoA) to another CoA. For sessions directly opened via the CoA, the loss of the address implies a re- initiation of the session. Reliability through bi-casting could also be achieved by registering two addresses with a single HoA. However MIPv6 does not provide any mechanism to associate more than one CoA with one HoA. Moreover, in this particular case, one HoA should be used as a CoA bound to the other HoA. (see in Section 6.2.1 and Section 6.3.1). In conclusion, reliability can only be achieved in some cases, when flows are initiated via a HoA. o Load Sharing In Bidirectional Tunnel (BT) mode, load sharing only affects the path between the CN and the HA(s), and not the path between the MN and the HA(s), as long as the CoA does not change. In RO mode, the path between the MN and the CN does not change if the CoA does not change. As an entry in the binding cache is identified by a HoA, the MN can register the same CoA with all HoAs, on any distant node. A mechanism would then be needed for the MN to select which HoA should be used when a new communication flow is initiated. A similar mechanism is needed on the CN side if it knows that multiple HoAs are assigned to the same MN. With such mechanisms, it would be possible to use multiple HoAs at the same time, and load sharing could be performed. However, it can be noted that load sharing on the path between the CN and the HA Montavont, et al. Expires May 22, 2008 [Page 15] Internet-Draft Analysis of Multihoming in MIPv6 November 2007 might not be the most bandwidth contraint part of the overall path from the CN to the MN. Thus load sharing might not bring important benefits. See in Section 6.1.3 where such path selection issues are discussed. It is also possible that the MN register one HoA as a CoA for another HoA (see in Section 6.3.1). o Flow Distribution This is achievable when the MN is attached to one foreign link via one of its interfaces and to the home link(s) via its other interface(s). In this case, the MN can spread flows over its interfaces. Note that if a CN initiates a communication, the interface that it will use on the MN would depend on which MN's address is advertised to the CN. 5.3. (1,n): 1 HoA, n CoAs A MN in this configuration is multihomed since it has several CoAs. It may occur when the MN has multiple interfaces connected to different links, or when the only interface is connected to a link where multiple IPv6 prefixes are advertised (i.e. the visited network is multihomed). Note that one of the interfaces of the MN may be connected to its home link. Current situation with MIPv6: o Reliability Reliability support is limited to recover from a failed CoA. Fault recovery is achieved in MIPv6 by associating an alternate CoA to replace the failed one. However, efficient mechanisms are needed to determine that a CoA has failed (see Section 6.1.1), to check reachability (Section 6.1.2), to determine which CoA should be used instead (Section 6.1.3) and to redirect flows to the new CoA (Section 6.1.4). o Load Sharing and Flow Distribution This configuration allows to share the load and to set preferences among different paths between the HA and the MN when BT mode is used, and between the CN and the MN when RO mode is used. In order to achieve load sharing and flow distribution under this scenario, the MN would need to register several CoAs with its unique HoA. However, the present specification of MIPv6 only allows the MN to register a single CoA per HoA. This is discussed in Section 6.2.1. When a single HoA is bounded to several CoAs at the same time, the MN or HA/CN must be able to select the appropriate CoA. This selection could be done based on user/ Montavont, et al. Expires May 22, 2008 [Page 16] Internet-Draft Analysis of Multihoming in MIPv6 November 2007 application preferences (see Section 6.1.3). 5.4. (n,n): n HoAs, n CoAs A MN in this configuration is multihomed since it has multiple addresses. This case can be viewed as a combination of the two cases described above: the MN has several HoAs, e.g. given by different operators (similar to case (n,1) in Section 5.2) and several CoAs, e.g. because the node is receiving multiple IPv6 prefixes (similar to case (1,n) in Section 5.3). As an example, we can consider a node with three interfaces, two of them connected to their home link (two different HoAs) and the last one connected to a visited link where two IPv6 prefixes are available. Current situation with MIPv6: o Reliability If one CoA becomes unreachable (similar to (1,n)), the MN can redirect flows to another CoA by associating any of the other available CoAs to the corresponding HoA. If the MN can not use one of its HoA anymore (similar to (n,1)), the MN will have to re- initiate all flows which were using the corresponding HoA. Redirection between the addresses available for the MN will be different depending on this HoA / CoA binding policies. o Load Sharing and Flow Distribution MIPv6 allows the MN to register only one CoA per HoA (see Section 6.2.1), but it can register the same or different CoAs with multiple HoAs. If the MN chooses to bind the same CoA to all its HoAs, we fall in the (n,1) case. In this case, load sharing can only be performed if route optimization is not used, on the CN-HA path, as a different HoA may be used per CN. If the MN chooses to bind a different CoA for each HoA, load sharing will be done along the whole path across the MN and its CNs. Preference settings may define which CoA (eventually several if bi-casting is used) should be bound to which HoA (see Section 6.1.3). In a very specific situation, one of the routable address of the MN (i.e., which can be directly used without tunneling to reach the MN) can be one of its HoA. This HoA would then be viewed as a CoA bound to another HoA (similar to (n,1)). MIPv6 does not prevent this behavior, which allows to set a certain preference on addresses usage. See Section 6.3.1 for the corresponding issue. Montavont, et al. Expires May 22, 2008 [Page 17] Internet-Draft Analysis of Multihoming in MIPv6 November 2007 5.5. (n,0): n HoAs, no CoAs This case happens when all the interfaces are connected to their respective home links. This situation is quite similar to a multihomed fixed node. The node would no longer be in the (n,0) configuration when one or more of the interfaces are attached to foreign links. The mobile node may wish to use one or more HoAs to serve as the CoA of another HoA (see Section 6.3.1). In such situations, this scenario is reduced to a (1,1) or (1,n) configuration as described in Section 5.1 and Section 5.3, respectively. Current situation with MIPv6 o Reliability If the MN is disconnected from one of its interfaces, the MN should be able to register another valid HoA as a CoA bound to its failed HoA (see issue Section 6.3.1). o Load Sharing, Flow Distribution This can be achieved when the MN is initiating the communication flow, as it can choose which HoA should be used. Depending on how CN can discover HoAs of the MN, these goals might also be achieved when the CN is initiating the communication flow. See previous scenario and discussions in Section 6.1.3 about the path selection. If the flows binding on interfaces preferences change over time, the MN should be able to redirect one flow from one interface to another. However, MIPv6 only allows to redirect all flows from one interface to another, assuming one HoA is registered as CoA (see issue Section 6.3.1). If the MN policies indicate to redirect only one flow, a supplementary mechanism would be needed. Montavont, et al. Expires May 22, 2008 [Page 18] Internet-Draft Analysis of Multihoming in MIPv6 November 2007 6. Multihoming Issues Existing protocols may not have the goals expressed in Section 3. For doing so, the issues discussed in this section must be addressed, and solved preferably by dynamic mechanisms. Note that some issues are pertaining to MIPv6 solely, whereas other issues are not at all related to MIPv6. However, such non MIPv6 issues must be solved in order to meet the goals outlined in Section 3. In this section, we describe some of these issues in two main headings: general IPv6-related issues (Section 6.1), and issues that are specific to MIPv6 (Section 6.2). Other concerns related to implementations of MIPv6 are described in Section 6.3. Issues and their area of application are summarized in Section 6.4 6.1. General IPv6-related Issues 6.1.1. Failure Detection It is expected for faults to occur more readily at the edge of the network (i.e. the mobile nodes), due to the use of wireless connections. Efficient fault detection mechanisms are necessary to recover in timely fashion. A failure in the path between two nodes can be located at many different places: the media of one of the node is broken (i.e., loss of connectivity), the path between the MN and the HA is broken, the home link is disconnected from the Internet, etc. The failure protection domain greatly varies. In some configurations, the protection domain is limited to a portion of the path. So far, MIPv6 only relies on the ability or the inability to receive Router Advertisements within a stipulated period to detect the availability or loss of media (local failure). [6] is addressing such concerns through the use of layer 2 triggers [7]. Movement detection might be extended to include other triggers such as the loss of connectivity on one interface. Additional mechanisms would be needed to detect a failure in the path between a MN and its CN(s), as well as between the MN and its HA(s), between the MN and CN(s), or between the HA and CN(s). 6.1.2. Path Exploration When the MN needs to re-home a communication to an alternative path, a path exploration may take place. The path exploration is a step that occurs after the failure detection, and before the path selection. It consists of identifying a set of paths that are known to provide bidirectional connectivity between the MN and its HA, and Montavont, et al. Expires May 22, 2008 [Page 19] Internet-Draft Analysis of Multihoming in MIPv6 November 2007 optionally between the MN and its CN. It may be noted that the step of path exploration may be avoided by selecting a new path, and trying to re-home the communications on this new path. If the re- homing fails, a new path is selected until there is no alternate path, or the re-homing signaling succeed. Path exploration requires some signaling between pairs of address to check reachability. An additional protocol may be needed to perform this task. In (1, *), the path exploration consists in checking reachability between each CoA and each HA address. If RO mode is used, the MN may also insure reachability between its CNs address(es) and each CoA. In (n, *), the path exploration consists in checking reachability between the HoA that is used with the session that must be re-homed and each CoA (and optionnally with the CN address(es)). In addition, the session may need to be re-homed to a different HoA. In this case, each path between a pair (HoA, CoA) must to be validated. In all these cases the path between the HA and the CN is not checked. A specific mechanism may be defined to check reachability between a HA and a CN. 6.1.3. Path Selection When there exists multiple paths from and to the MN, the MN ends up choosing a source address, and possibly the interface that should be used. A CN that wants to establish a communication with such a MN may end up by choosing a destination address for this MN. o Interface selection When the node has multiple available interfaces, the simultaneous or selective use of several interfaces would allow a mobile node to spread flows between its different interfaces. Each interface could be used differently according to some user and applications policies and preferences that would define which flow would be mapped to which interface and/or which flow should not be used over a given interface. How such preferences would be set on the MN is out of scope of MIPv6 and might be implementation specific. On the other hand, if the MN wishes to influence how preferences are set on distant nodes (Correspondent Node or Home Agent), mechanisms such as those proposed in draft-soliman-flow-binding [8] could be used. Montavont, et al. Expires May 22, 2008 [Page 20] Internet-Draft Analysis of Multihoming in MIPv6 November 2007 o HoA Selection When multiple HoAs are available, the MN and its communicating peers (HA and CNs) must be able to select the appropriate HoA to be used for a particular packet or flow. This choice would be made at the time of a new communication flow set up. Usual IPv6 mechanisms for source and destination address selection, such as "Default Address Selection for IPv6" (RFC3484) [9] or DNS SRV Protocol (RFC2782) [10] could be used. However, in RFC3484 it is said that "If the eight rules fail to choose a single address, some unspecified tie-breaker should be used". Therefore more specific rules in addition to those described in RFC3484 may be defined for HoA selection. o CoA Selection When multiple CoAs are available, the MN and its communicating peers (HA and CNs) must be able to select the appropriate CoA to be used for a particular packet or flow. The MN may use its internal policies to (i) distribute its flow, and (ii) distribute policies on distant nodes to allow them to select the preferred CoA. Solutions like [8], [11], [12], or [13] may be used. Another related aspect of path selection is the concern of ingress filtering. This is covered below in Section 6.1.5. 6.1.4. Rehoming Re-homing takes place after an outage has been detected or an alternative path has been identified (see previous issues Section 6.1.1, Section 6.1.2 and Section 6.1.3), therefrom diverting existing sessions from one path to another. New transport sessions would have to be established over the alternate path if no mechanism is provided to redirect flow transparently at layers above layer 3. The need for re-homing or flow redirection is explained in Appendix A The different mechanisms that can be used to provide re-homing can be split into three categories, depending on the part of the path that needs to be changed. The first category is the CoA changes : it influences the path between the MN and its HA, and the path between the MN and its CN in RO mode. This may hold in case (n, n). The second category is when the HoA changes (: it influences the entire path. As the HoA is the address shown to the higher layer Montavont, et al. Expires May 22, 2008 [Page 21] Internet-Draft Analysis of Multihoming in MIPv6 November 2007 (above layer 3), an additional mechanism is needed to manage this change. Solution with a shim layer (e.g., Shim6 [14]), or solution at the transport layer such as SCTP [5] may be useful. The third category is when the HA address changes. In this case, the bidirectional tunnel between the MN and its HA as to be switched to the new address of the HA. This can be managed transparently by MIPv6 if the HoA doesn't change at the same time. Otherwise, sessions continuity is not ensured, as explained in the above paragraph. 6.1.5. Ingress Filtering Ingress filtering mechanisms [15][16] may drop the outgoing packets when multiple bi-directional tunnels end up at different HAs. This could particularly occur if different prefixes are handled by different HAs. If a packet with a source address configured from a specific prefix is tunneled to a HA that does not handle that specific prefix, the packet may be discarded either by the HA or by a border router in the home network. The problem of ingress filtering however, is two-fold. It can occur in the access network as well as the home network. Suppose MN selects the interface (which would determine the CoA) and the home network (which would determine the HoA): the chosen CoA may not be registered with the chosen HoA. For instance, consider Figure 2 below. In the access network, the MN must use CoA=PA.MN when it sends packets through AR-A and it must use CoA=PB.MN when it sends a packet through AR-B. In the home network, it must use HoA=P1.MN when it tunnels the packet to home agent HA-1, and it must use HoA=P2.MN when it tunnels the packet to home agent HA-2. To avoid ingress filtering, the choice is thus limited to a of valid (HoA,CoA) pairs. This issue is related to Section 6.1.3 greatly limits the way MN can benefit from its multihoming configuration (particularly in case of the HA failure since flows cannot be diverted to the other HA). Prefix: PA +------+ +----------+ +------+ HoA: P1.MN /-----| AR-A |----| |----| HA-1 | CoA: PA.MN / +------+ | | +------+ +----+ | | Prefix: P1 | MN | | Internet | +----+ | | Prefix: P2 HoA: P2.MN \ +------+ | | +------+ CoA: PB.MN \-----| AR-B |----| |----| HA-2 | Prefix: PB +------+ +----------+ +------+ Figure 2: MN connected to Multiple Access/Home Networks Montavont, et al. Expires May 22, 2008 [Page 22] Internet-Draft Analysis of Multihoming in MIPv6 November 2007 Should the MN be able to bind both CoAs PA.MN and PB.MN simultaneously to HoAs P1.MN and P2.MN respectively (see Section 6.2.1), it would be able to choose the (HoA,CoA) pair based on the access network it wishes to use for outgoing packets. It is, nonetheless, still limited to transmit all packets to a specific HA for the selected (HoA,CoA) pair, i.e. ingress filtering at the home network remains unsolved). Ingress filtering in the home network concerns only the (n,n) case since the choice of the HoA and CoA is limited to a single (HoA, CoA) pair in other cases. In (n,n), the MN may be connected to multiple access networks or multiple home networks each practicing ingress filtering. To overcome this, mechanisms such as those provided by Shim6 (see RFC3582 [17] and [14]) may be used. 6.2. MIPv6-specific Issues 6.2.1. Binding Multiple CoAs to a given HoA In the (1,n) cases, multiple CoAs would be available to the MN. In order to use them simultaneously, the MN must be able to bind and register multiple CoAs for a single HoA with both the HA and the CNs. The MIPv6 specification is currently lacking such ability. Although in the (n,n) cases, MIPv6 allows MN to have multiple (HoA,CoA) pairs, the upper layer's choice of using a particular HoA would mean that the MN is forced to use the corresponding CoA. This constrains the MN from choosing the best (in terms of cost, bandwidth etc) access link for a particular flow, since CoA is normally bound to a particular interface. If the MN can register all available CoAs with each HoA, this would completely decouple the HoA from the interface, and allow the MN to fully exploit its multihoming capabilities. To counter this issue, a solution like [18] may be used. However, with simultaneous binding support, there exists a possibility that a malicious MN can successfully bind a number of victims' addresses as valid CoAs for the MN with its HA. This is because CoAs specified by the MN in BU messages are not verified by HA (since MIPv6 assumes an existing trust relationship between the MN and its HA). Once these addresses have been bound, the malicious MN can perform a re- direction attack by instructing the HA to tunnel packets to the victims' addresses. Although such threats exist in MIPv6, MIPv6 only allows a MN to have a single CoA binding per HoA at a given time. Once the malicious MN has bound a victim's address to the HoA using MIPv6, the malicious MN can no longer use the HoA for communications (such as to initiate a Montavont, et al. Expires May 22, 2008 [Page 23] Internet-Draft Analysis of Multihoming in MIPv6 November 2007 large file download). With simultaneous multiple CoA bindings, the malicious MN could bind a valid CoA in addition to multiple victims' addresses. This valid CoA could then be used by the malicious MN to set up flow filtering rules at HA, thereby controlling and/or launching new re-direction attacks. In view of such risk, it is advisable for HA to employ some form of CoAs verification before using the CoAs as a valid routing path to MN. 6.2.2. Simultaneous Location in Home and Foreign Networks Rule 4 of RFC3484 (section 5) specifies that a HoA should be preferred to a CoA. While this rule allows the host to choose which address to use, it does not allow the MN to benefit from being multihomed in a situation where it may have one of its interfaces directly connected to a home link. That is, addresses from other interfaces cannot be registered as CoAs for the HoA associated to the home link the mobile node is connected to. As a result, flows cannot be redirected transparently from one CoA to another and MIPv6 features can only recover the failure of the HoA. In the case of (1,*) where one of the interface is connected to the home link, none of the other addresses can be used to achieve multihoming goals with the HA. 6.2.3. HA Synchronization In the (n,*) cases, HoAs may be obtained from different HAs. If any failure is affecting ongoing sessions on a given HoA (HA has failed or is overloaded), there is currently no failover allowing existing sessions to be shifted from one HA to another, though certain level of co-ordination between HAs on registered bindings would be useful. This co-ordination could further be extened to all (*,*) cases where distinct HAs would be co-ordinated to register CoAs for the same HoA. HA synchronization mechanisms such as these described in [19] and [20] could be used. 6.3. Considerations for MIPv6 Implementation In addition to the issues described in Section 6.1 and Section 6.2, there are other concerns implementers should take into consideration so that their MIPv6 implementations are more "friendly" to multihoming, particularly the use of multiple interfaces. These implementation-related considerations are described in the sub- sections below. Montavont, et al. Expires May 22, 2008 [Page 24] Internet-Draft Analysis of Multihoming in MIPv6 November 2007 6.3.1. Using one HoA as a CoA In (n,*) cases, the MN has multiple HoAs. A HoA may be seen as a CoA from the perspective of another home link of the same MN. As an example, a MN has two HoAs (HoA1 and HoA2) on two distinct home links. MN is connected to these two home links via two interfaces. MN looses its connectivity on its first interface and HoA1 is not reachable. It may then want to register HoA2 as a CoA for HoA1 in order to keep receiving packets intended to HoA1, via the second interface. According to the definition of a CoA, the current MIPv6 specification does not prohibit to register a HoA as the CoA from the perspective of another HoA. In RFC3775 section 6.1.7 it is written: "Similarly, the Binding Update MUST be silently discarded if the care-of address appears as a home address in an existing Binding Cache entry, with its current location creating a circular reference back to the home address specified in the Binding Update (possibly through additional entries)." In order to benefit from any multihoming configuration, a MN must be able to register whatever address it owns with any of its HoA, as long as the above statement is observed. 6.3.2. Binding a new CoA to the Right HoA In the (n,*) cases, the MN has multiple HoAs. When the MN moves and configures a new CoA, the newly obtained CoA must be bound to a specific HoA. The current MIPv6 specification doesn't provide a decision mechanism to determine to which HoA this newly acquired CoA should be bound to. With no such mechanism, the MN may be confused and may bind this CoA to a possibly wrong HoA. The result might be to bind the CoA to the same HoA the previous CoA was bound to or to another one, depending on the implementation. It would indeed be better to specify the behavior so that all implementations are compliant. 6.3.3. Binding HoA to interface In (n,*) cases, MIPv6 does not provide any information on how HoAs should be bound to a device, and particularly there is no mechanism to bind HoAs to interfaces. This may be troublesome, for example, when we consider a MN Montavont, et al. Expires May 22, 2008 [Page 25] Internet-Draft Analysis of Multihoming in MIPv6 November 2007 configured with two HoAs and equipped with three interfaces. When the MN is connected to a home link via one interface, it will need to bind the corresponding HoA to this interface, even if the HoA was initially assigned to another one. HoA1 HoA2 CoA1 CoA2 CoA3 Iface1 Iface2 Iface3 Figure 3: Illustration of the case (2,3) HoA must always be assigned to an activated interface and if the MN is connected to its home link, the corresponding HoA must be used on this interface. In some cases, the HoA then would have to be re- assigned to another interface in case of connection loss or attachment to the home link. 6.4. Summary The table below summarizes the cases where each issue applies (TO BE CHECKED AND COMPLETED) Montavont, et al. Expires May 22, 2008 [Page 26] Internet-Draft Analysis of Multihoming in MIPv6 November 2007 +=====================================================+ | # of HoAs: | 1 | 1 | n | n | n | | # of CoAs: | 1 | n | 0 | 1 | n | +=====================================================+ | General IPv6 Issues | +---------------------------------+---+---+---+---+---+ | Failure detection |o | o | ? | o | o | +---------------------------------+---+---+---+---+---+ | Path Exploration | | | | | | +---------------------------------+---+---+---+---+---+ | Path Selection | | o | ? | o | o | +---------------------------------+---+---+---+---+---+ | Flow redirection | o | o | ? | o | o | +---------------------------------+---+---+---+---+---+ | Ingress Filtering | | | ? | o | o | +---------------------------------+---+---+---+---+---+ | MIPv6-Specific Issues | +---------------------------------+---+---+---+---+---+ | Binding Multiple CoAs to a | | o | ? | o | o | | given HoA | | | | | | +---------------------------------+---+---+---+---+---+ | Simultaneous location in home | | o | ? | o | o | | and foreign networks | | | ? | | | +---------------------------------+---+---+---+---+---+ | HA Synchronization | | | | | | +---------------------------------+---+---+---+---+---+ | Implementation-Related Concerns | +---------------------------------+---+---+---+---+---+ | Using one HoA as a CoA | | | ? | o | o | +---------------------------------+---+---+---+---+---+ | Binding a new CoA to the | | | ? | o | o | | right HoA | | | | | | +---------------------------------+---+---+---+---+---+ | Binding HoA to interface(s) | o | o | ? | o | o | +=====================================================+ Figure 4: Summary of Issues and Categorization Montavont, et al. Expires May 22, 2008 [Page 27] Internet-Draft Analysis of Multihoming in MIPv6 November 2007 7. Conclusion In this document, we have demonstrated issues arising for multihomed mobile nodes operating Mobile IPv6. We have seen that mechanisms are needed: o to redirect flows from a failed path to a new path, o to decide which path should better be taken when multiple paths are available, o to register multiple Care-of Addresses o to exchange policies between the Mobile Router and the Home Agent Even if Mobile IPv6 can be used as a mechanism to manage multihomed mobile nodes, triggers of flow redirection between interfaces/ addresses are not adapted to the multihoming status of the node. Also, we have shown that in some configurations Mobile IPv6 is ambiguous in the definitions of CoA/HoA and in the mappings between HoAs, CoAs and network interfaces. Finally, we have also raised issues not directly related to Mobile IPv6, but solutions for these issues are needed for mobile nodes to fully take advantage of their multihomed configuration. Montavont, et al. Expires May 22, 2008 [Page 28] Internet-Draft Analysis of Multihoming in MIPv6 November 2007 8. IANA Considerations This is an informational document and as such does not require any IANA action. Montavont, et al. Expires May 22, 2008 [Page 29] Internet-Draft Analysis of Multihoming in MIPv6 November 2007 9. Security Considerations This is an informational document where the multihoming configurations under the operation of Mobile IPv6 are analyzed. Security considerations of these multihoming configurations, should they be different from those that concern Mobile IPv6, must be considered by forthcoming solutions. For instance, Section 6.2.1 described a potential threat that should be considered when developing a proposed solution for multiple CoA regsitrations Montavont, et al. Expires May 22, 2008 [Page 30] Internet-Draft Analysis of Multihoming in MIPv6 November 2007 10. Contributors The following people have contributed ideas, text and comments to earlier versions of this document: Eun Kyoung Paik from Seoul National University, South Korea and Thomas Noel from Universite Louis Pasteur, Strasbourg, France. Montavont, et al. Expires May 22, 2008 [Page 31] Internet-Draft Analysis of Multihoming in MIPv6 November 2007 11. Acknowledgments The authors would like to thank all the people who have sent comments so far, particularly Tobias Kufner, Marcelo Bagnulo, Romain Kuntz and Henrik Levkowetz for their in-depth comments and raising new issues. Montavont, et al. Expires May 22, 2008 [Page 32] Internet-Draft Analysis of Multihoming in MIPv6 November 2007 12. References 12.1. Normative References [1] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [2] Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to Protect Mobile IPv6 Signaling Between Mobile Nodes and Home Agents", RFC 3776, June 2004. [3] Ernst, T., Montavont, N., Wakikawa, R., Ng, C., and K. Kuladinithi, "Motivations and Scenarios for Using Multiple Interfaces and Global Addresses", draft-ietf-monami6-multihoming-motivation-scenario-01 (work in progress), October 2006. [4] Manner, J. and M. Kojo, "Mobility Related Terminology", RFC 3753, June 2004. [5] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V. Paxson, "Stream Control Transmission Protocol", RFC 2960, October 2000. 12.2. Informative References [6] Choi, JH. and G. Daley, "Goals of Detecting Network Attachment in IPv6", RFC 4135, August 2005. [7] Krishnan, S., Montavont, N., Yegin, A., Veerepalli, S., and A. Yegin, "Link-layer Event Notifications for Detecting Network Attachments", draft-ietf-dna-link-information-06 (work in progress), February 2007. [8] Soliman, H., Montavont, N., Fikouras, N., and K. Kuladinithi, "Flow Bindings in Mobile IPv6", draft-soliman-monami6-flow-binding-04 (work in progress), February 2007. [9] Draves, R., "Default Address Selection for Internet Protocol version 6 (IPv6)", RFC 3484, February 2003. [10] Gukbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000. [11] Larsson, C., "A Filter Rule Mechanism for Multi-access Mobile Montavont, et al. Expires May 22, 2008 [Page 33] Internet-Draft Analysis of Multihoming in MIPv6 November 2007 IPv6", draft-larsson-monami6-filter-rules-02 (work in progress), March 2007. [12] Kauppinen, T., "Filter Interface Identifier Binding in Mobile IPv6", draft-kauppinen-monami6-binding-filter-rule-00 (work in progress), October 2006. [13] Mitsuya, K., "A Policy Data Set for Flow Distribution", draft-mitsuya-monami6-flow-distribution-policy-04 (work in progress), August 2007. [14] Nordmark, E. and M. Bagnulo, "Level 3 multihoming shim protocol", draft-ietf-shim6-proto-08 (work in progress), May 2007. [15] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, May 2000. [16] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, March 2004. [17] Abley, J., Black, B., and V. Gill, "Goals for IPv6 Site- Multihoming Architectures", RFC 3582, August 2003. [18] Wakikawa, R., Ernst, T., Nagami, K., and V. Devarapalli, "Multiple Care-of Addresses Registration", draft-ietf-monami6-multiplecoa-02 (work in progress), March 2007. [19] Wakikawa, R., Devarapalli, V., and P. Thubert, "Inter Home Agents Protocol (HAHA)", draft-wakikawa-mip6-nemo-haha-01 (work in progress), February 2004. [20] Koh, B., Ng, C., and J. Hirano, "Dynamic Inter Home Agent Protocol", draft-koh-mip6-nemo-dhap-00 (work in progress), July 2004. Montavont, et al. Expires May 22, 2008 [Page 34] Internet-Draft Analysis of Multihoming in MIPv6 November 2007 Appendix A. Why a MN may want to redirect flows When a MN is multihomed, an addresses selection mechanism is needed to distribute flows over interfaces. As policies may change over time, as well as the available addresses/interfaces, flow redirection mechanisms are needed. While the selection policy is out of scope of this document, the following reasons may trigger the MN to redirect flow from one address to another: o Failure detection: the path between the MN and its CN(s) is broken. The failure can occur at different places onto this path; The failure can be local on the MN, where the interface used on the MN is disconnected from the network (e.g., a wireless interface which comes out of range from its point of attachment). Alternatively, the failure can be on the path between the MN and one of its HA. Yet another alternative is that the failure can be on the path between the HA and the CN. If route optimization is used, it can also be a failure between the MN and its CN(s). o New address: a new address on the MN may become available, e.g. when the MN connects to the network with a new interface. The MN may decide that this new interface is most suitable for its current flows that are using another interface. o o Uninterrupted horizontal handover in mobility: If the MN is mobile, it may have to change its point of attachment. When a MN performs a horizontal handover, the handover latency (the time during which the MN can not send nor receive packets) can be long and the flows exchanged on the interface can be interrupted. If the MN wants to minimize such perturbation, it can redirect some or all the flows on another available interface. This redirection can be done prior to the handover if L2 triggering is considered [7] . o Change in the network capabilities: the MN can observe a degradation of service on one of its interface, or conversely an improvement of capacity on an interface. The MN may then decide to redirect some or all flows on another interface that it considers most suitable for the target flows. o Initiation of a new flow: a new flow is initiated between the MN and a CN. According to internal policies, the MN may want to redirect this flow on a most suitable interface. Montavont, et al. Expires May 22, 2008 [Page 35] Internet-Draft Analysis of Multihoming in MIPv6 November 2007 Authors' Addresses Nicolas Montavont Ecole Nationale Superieure des telecommunications de Bretagne 2, rue de la chataigneraie Cesson Sevigne 35576 France Phone: (+33) 2 99 12 70 23 Email: nicolas.montavont@enst-bretagne.fr URI: http://www-r2.u-strasbg.fr/~montavont/ Ryuji Wakikawa Keio University Department of Environmental Information, Keio University. 5322 Endo Fujisawa, Kanagawa 252-8520 Japan Phone: +81-466-49-1100 Fax: +81-466-49-1395 Email: ryuji@sfc.wide.ad.jp URI: http://www.wakikawa.org/ Thierry Ernst INRIA INRIA Rocquencourt Domaine de Voluceau B.P. 105 Le Chesnay, 78153 France Phone: +33-1-39-63-59-30 Fax: +33-1-39-63-54-91 Email: thierry.ernst@inria.fr URI: http://www.nautilus6.org/~thierry Montavont, et al. Expires May 22, 2008 [Page 36] Internet-Draft Analysis of Multihoming in MIPv6 November 2007 Chan-Wah Ng Panasonic Singapore Laboratories Pte Ltd Blk 1022 Tai Seng Ave #06-3530 Tai Seng Industrial Estate Singapore 534415 SG Phone: +65 65505420 Email: chanwah.ng@sg.panasonic.com Koojana Kuladinithi University of Bremen ComNets-ikom,University of Bremen. Otto-Hahn-Allee NW 1 Bremen, Bremen 28359 Germany Phone: +49-421-218-8264 Fax: +49-421-218-3601 Email: koo@comnets.uni-bremen.de URI: http://www.comnets.uni-bremen.de/~koo/ Montavont, et al. Expires May 22, 2008 [Page 37] Internet-Draft Analysis of Multihoming in MIPv6 November 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Montavont, et al. Expires May 22, 2008 [Page 38]