IETF MONAMI6 Working Group N. Montavont Internet-Draft GET/ENST-B Expires: August 30, 2007 R. Wakikawa Keio University T. Ernst INRIA C. Ng Panasonic Singapore Labs K. Kuladinithi University of Bremen February 26, 2007 Analysis of Multihoming in Mobile IPv6 draft-ietf-monami6-mipv6-analysis-02.txt 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 August 30, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Montavont, et al. Expires August 30, 2007 [Page 1] Internet-Draft Analysis of Multihoming in MIPv6 February 2007 Abstract Mobile IPv6 as specified in RFC3775 [1] 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Nodes capabilities . . . . . . . . . . . . . . . . . . . . . . 8 4. Taxonomy . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 5. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 12 5.1. (H1,C1): 1 HoA, 1 CoA . . . . . . . . . . . . . . . . . . 12 5.2. (Hn,C1): n HoAs, 1 CoA . . . . . . . . . . . . . . . . . . 13 5.3. (H1,Cn): 1 HoA, n CoAs . . . . . . . . . . . . . . . . . . 15 5.4. (Hn,Cn): n HoAs, n CoAs . . . . . . . . . . . . . . . . . 16 5.5. (Hn,C0): n HoAs, no CoAs . . . . . . . . . . . . . . . . . 17 6. Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 6.1. General IPv6-related Issues . . . . . . . . . . . . . . . 19 6.1.1. Path Selection . . . . . . . . . . . . . . . . . . . . 19 6.1.2. Ingress Filtering . . . . . . . . . . . . . . . . . . 20 6.1.3. Failure detection . . . . . . . . . . . . . . . . . . 21 6.2. MIPv6-specific Issues . . . . . . . . . . . . . . . . . . 21 6.2.1. Binding Multiple CoAs to a given HoA . . . . . . . . . 21 6.2.2. Simultaneous Location in Home and Foreign Networks . . 22 6.3. Considerations for MIPv6 Implementation . . . . . . . . . 22 6.3.1. Using one HoA as a CoA . . . . . . . . . . . . . . . . 22 6.3.2. Binding a new CoA to the Right HoA . . . . . . . . . . 23 6.3.3. Binding HoA to interface . . . . . . . . . . . . . . . 23 6.3.4. Flow redirection . . . . . . . . . . . . . . . . . . . 24 6.4. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 24 7. TODO List . . . . . . . . . . . . . . . . . . . . . . . . . . 26 Montavont, et al. Expires August 30, 2007 [Page 2] Internet-Draft Analysis of Multihoming in MIPv6 February 2007 8. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 27 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 28 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 29 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30 Appendix A. Why a MN may want to redirect flows . . . . . . . . . 32 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33 Intellectual Property and Copyright Statements . . . . . . . . . . 35 Montavont, et al. Expires August 30, 2007 [Page 3] Internet-Draft Analysis of Multihoming in MIPv6 February 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 they can change their point of attachment to the Internet at any time, even during active network connections. Mobile IPv6 as specified in RFC3775 [1] allows mobile nodes to maintain their communication while changing their point of attachment to the Internet. Besides, mobile nodes can be connected to multihomed networks or they may have multiple interfaces to benefit from heterogeneous technologies. The use of multiple addresses (allocated to either a single interface or multiple interfaces) is foreseen to provide ubiquitous, permanent and fault-tolerant access to the Internet, particularly on mobile nodes which are prone to failure or sudden lack of connectivity. However, the current specification of Mobile IPv6 lacks support for mobile nodes with multiple addresses used simultaneously, i.e. multihomed mobile nodes. These addresses would be assigned to a single interface or to multiple interfaces, which poses a number of issues. This document has two goals. The first goal is to define the requirements from the point of view of 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 the potentially needed solutions is out of scope of this document. These should be defined in a separate document. In order to reach the goals of this document, we define a taxonomy which is used to describe the different situations where a mobile node is multihomed. For each case, we show the configuration a multihomed node may have (the number of Home Addresses, and the number of Care-of Addresses). We also illustrate each scenario with example diagrams. To understand the foundation of this document, the reader should read the companion document draft-ietf-monami6-multihoming-motivation-scenario [2] 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 of the present study. The reader should 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 discuss what is required on the mobile nodes to fully Montavont, et al. Expires August 30, 2007 [Page 4] Internet-Draft Analysis of Multihoming in MIPv6 February 2007 benefit from a multihomed configuration. 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 a number of multihomed configuration specific to Mobile IPv6. Finally we discuss in Section 6 and Section 6.3 all issues related to a multihomed mobile node and we identify what is missing in order to reach the goals outlined in draft-ietf-monami6-multihoming-motivation-scenario [2]. These issues are classified into IPv6 issues, Mobile IPv6-specific issues, and advices to implementers. Montavont, et al. Expires August 30, 2007 [Page 5] Internet-Draft Analysis of Multihoming in MIPv6 February 2007 2. Terminology The terms used in the present document are defined in RFC3753 [3], RFC3775 [1] and draft-ietf-monami6-multihoming-motivation-scenario [2]. In this draft we are using the following terms and abbreviations: o MIPv6 The Mobile IPv6 protocol specified in RFC3775 [1] o MN a Mobile Node using 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 [2], 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 (as defined above) 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 HoAs/CoAs in the following cases: * A MN would have multiple HoAs if multiple prefixes are available on the home link or if it has multiple interfaces named on (presumably) distinct home links. * A MN would have multiple CoAs if multiple prefixes are available on the foreign link or if it has multiple interfaces Montavont, et al. Expires August 30, 2007 [Page 6] Internet-Draft Analysis of Multihoming in MIPv6 February 2007 attached to (presumably) distinct foreign links. 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 simultaneously using multiple addresses at the same time 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 to set the source address of outcoming packets. o Simultaneously using multiple interfaces A MN is simultaneously using multiple interfaces when it can exchange IP packets over any of these interfaces. Montavont, et al. Expires August 30, 2007 [Page 7] Internet-Draft Analysis of Multihoming in MIPv6 February 2007 3. Nodes capabilities Generic goals and benefits of multihoming are discussed in draft-ietf-monami6-multihoming-motivation-scenario [2]. These goals are ubiquitous access, flow redirection, reliability, load sharing, inteface switching, preference settings, and aggregate bandwidth. These generic goals overlap, i.e., they are not totally independent. Reaching one of them may imply to reach another goal as well. For this reason, the following non-overlapping goals may be extracted from these generic goals: 1. Reliability 2. Load Sharing 3. Interface switching/Flow Distribution In this section, after determining a set of capabilities that allows a MN to achieve these design goals, we explicitly indicate which capability is needed to reach which goal. We will determine later in the document (in Section 5) which capabilities are already fulfilled by Mobile IPv6 and what issues 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 to 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, interface switching). 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 interface switching and load sharing), multiple paths must be maintained simultaneously between the mobile node and its CN. This translates into the following capabilities: 1. A MN equipped with multiple global addresses must be able to use them simultaneously 2. A MN equipped with multiple interfaces must be able to attach distinct interfaces to distinct access networks (distinct foreign links or distinct home links, or a combination of both). Montavont, et al. Expires August 30, 2007 [Page 8] Internet-Draft Analysis of Multihoming in MIPv6 February 2007 3. A MN should be able to share its traffic load among its valid global addresses 4. A mechanism should be available to quickly activate a backup interface and redirect traffic when an interface fails (e.g., loss of connection). 5. A mechanism should be available to quickly redirect flow from one address to another when it is needed. Some of the triggers of flow redirection are given in Appendix A. 6. If multiple HAs are available to manage bindings for a given HoA, the MN should be able to use them simultaneously. 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 what of the above capabilities are needed for each goal: 1. Reliability: 2, 4, 5, 6 2. Load Sharing: 1, 6 3. Interface switching/Flow Distribution: 1, 2, 3, 5 Montavont, et al. Expires August 30, 2007 [Page 9] Internet-Draft Analysis of Multihoming in MIPv6 February 2007 4. Taxonomy In order to examine the issues preventing a MIPv6 mobile node to meet the requirements listed in Section 3 we use in the present document the following taxonomy (Hx,Cy) 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 '*' indicates that the number can be '1' or 'n'. An illustration of this taxonomy is given in Figure 1. Mobile Node HoA1 HoA2 ... HoAn --> Permanent Address (Hx) | | | +-----+--------+ | | | | | | | CoA1 +--CoA2 +---CoA3 ... CoAn --> Temporary Address (Cy) | | | | 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 * because number of IPv6 links is equal to the 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 the fact that this mobile node has multiple interfaces. The fact that a mobile node has 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. The proposed taxonomy has two parameters because each of them has an Montavont, et al. Expires August 30, 2007 [Page 10] Internet-Draft Analysis of Multihoming in MIPv6 February 2007 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 the way 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 August 30, 2007 [Page 11] Internet-Draft Analysis of Multihoming in MIPv6 February 2007 5. Scenarios In this section, we detail the reachable multihoming goals under each type of configuration. For each configuration, we give a basic explanation and we list which of the goals outlined in Section 3 are achievable provided that supporting mechanisms are either already existing or could be added. Other goals are not achievable due to the inherent configuration of the node. Then, we briefly discuss the current situation with MIPv6 and we point to issues discussed later in this document in Section 6.1, Section 6.2 and Section 6.3. 5.1. (H1,C1): 1 HoA, 1 CoA A mobile node in this configuration with a single network interface is not multihomed. This scenario is the common case of a MN running Mobile IPv6 and 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. When the node in the same configuration has several interfaces, it may lead to a special situation where a node is connected to both its home link and a foreign link. The MN is multihomed since it would be able to use both interfaces. The Home Address might be directly used on the interface which is connected to the home link, and a Care-of Address is configured on the other interface which is connected to a foreign link. There cannot be more than two active interfaces, otherwise the mobile node 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 two cases would fall in another scenario, either (Hn,C*) (see Section 5.2, Section 5.4 and Section 5.5) or (H*,Cn) (see Section 5.3 and Section 5.4). Achievable goals (when the node has a single interface): Reliability, Load Sharing. Achievable goals (when the node has multiple interfaces): Reliability, Load Sharing, Interface switching Current situation with MIPv6 (when the node has multiple interfaces): o Reliability These goals are achievable, but in a limited manner. The MN can build a CoA on the interface connected to the foreign network, but it cannot register the CoA with its HA and receive packets from the HA via tunnel to the CoA at the same time it receives packet on the HoA from the Home Link. As a result, without binding Montavont, et al. Expires August 30, 2007 [Page 12] Internet-Draft Analysis of Multihoming in MIPv6 February 2007 separately to CNs (i.e. route optimization), the MN is not able to use both addresses simultaneously. In addition, in case of failure, the MN cannot redirect flows from one valid address to another. If the MN looses its connection established using the address on the foreign link, all flows must be re-initiated with another address (either the HoA, or a new address obtained on another foreign link). Fault recovery is thus only possible without transparency, and the MIPv6 features can only recover the failure of the Home Address. This issue is detailed in Section 6.2.2. It might be possible for MN to register the CoA with selected CNs (i.e. route optimization). In this case, the MN can enjoy benefits of increased 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 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, Interface Switching 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 interface switching 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 interface switching cannot be achieved. See in Section 6.1.1 where such path selection issues are discussed. 5.2. (Hn,C1): n HoAs, 1 CoA The MN is multihomed, since it has several HoAs. This case may happen when a node is getting access to the Internet through different HAs (possibly distinct operators) and each offers a Mobile IPv6 service to the node. That way, the node will have a HoA per HA. Alternatively, a single home network may be multihomed to the Internet, leading to having multiple prefixes on the home link. Thus the MN would have multiple HoAs for a single home link. In either case, the node would need to configure a single CoA on the visited Montavont, et al. Expires August 30, 2007 [Page 13] Internet-Draft Analysis of Multihoming in MIPv6 February 2007 IPv6 subnet, and bind that single CoA to all the HoAs it owns. 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. Achievable goals: Reliability, Load Sharing, Interface switching (if the MN has more than one interface) Current situation with MIPv6: o Reliability In case a HoA fails, (a failure could happen in the home network of the MN, e.g. when one HA of the MN is disconnected from the network), the session using the HoA must be restarted since MIPv6 does not provide any mechanism to hand-over transparently from a fail HoA to another one. Currently, fault tolerance cannot be achieved in this case, since established communications cannot be preserved. See the corresponding discussion in Section 6.3.4. 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 to transparently redirect flows using the old CoA as a temporarily address (i.e. the HoA was used as the main address) to another CoA. For sessions directly opened via the CoA, the loss of the address implies a re-initiation of the session. In conclusion, fault recovery can only be done in some cases, when flows were initiated via a HoA. Achieving reliability through bi-casting could be achieved in this scenario 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 taken as a CoA regarding the other HoA. (see discussions in Section 6.2.1 and Section 6.3.1). 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 Montavont, et al. Expires August 30, 2007 [Page 14] Internet-Draft Analysis of Multihoming in MIPv6 February 2007 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 MN's HA might not be the most bandwidth contraint part of the overall path from the CN to the MN. Thus this load sharing might not show important enhancements. See in Section 6.1.1 where such path selection issues are discussed. It is also possible that the MN register one HoA as a CoA for another HoA (see discussions in Section 6.3.1). o Interface Switching Interface switching is achievable when the MN has several interfaces. In this case, the MN is attached to one foreign link via one of its interfaces, and it is attached to home link(s) with 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 the information it has about this MN. 5.3. (H1,Cn): 1 HoA, n CoAs The MN is multihomed since it has several CoAs. This case may for instance occur when the interface of the node is connected to a link where multiple IPv6 prefixes are available. One possible reason for this is that the visited network is multihomed and because of that, multiple prefixes are available in it, one per provider. Another possible configuration is a MN with several interfaces connected to different links. Note that one of the interfaces of the MN may be connected to its home link. Achievable goals: Reliability, Load Sharing, Interface switching (if the MN is equipped with several interfaces) Current situation with MIPv6: o Reliability Fault recovery will be limited to the case where one of the CoAs become unreachable for a particular peer. For instance, a CoA may become unreachable because the ISP which provides the IPv6 prefix fails. Fault recovery in MIPv6 is achieved 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.3) and to determine which CoA should be used instead (see below). Montavont, et al. Expires August 30, 2007 [Page 15] Internet-Draft Analysis of Multihoming in MIPv6 February 2007 o Load Sharing and Interface Switching This configuration allows to share the load and 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 interface switching 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/ application preferences (see Section 6.1.1). 5.4. (Hn,Cn): n HoAs, n CoAs The MN 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) and several CoAs (e.g. because the node is receiving multiple IPv6 prefixes). 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. Achievable goals: reliability, load sharing and interface switching Current situation with MIPv6: o Reliability If one CoA becomes unreachable (similar to scenario (H1,Cn) in Section 5.3), the MN can redirect flows to another CoA by associating any other available CoAs to the corresponding HoA. If the MN can not use one of its HoA anymore (similar to scenario (Hn,C1) in Section 5.2), 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, Interface Switching Currently, the MN can 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 (Hn,C1) 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 Montavont, et al. Expires August 30, 2007 [Page 16] Internet-Draft Analysis of Multihoming in MIPv6 February 2007 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.1). 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. In this case, this HoA can be viewed as a CoA to bind with another HoA. Thus the MN may be able to register one HoA as CoA regarding another HoA (see Section 6.3.1). MIPv6 does not prevent this behavior, which allow to set a certain preference on addresses usage. 5.5. (Hn,C0): 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 non- mobile node which is multihomed. The node would no longer be in the (Hn,C0) 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 (H1,C1) or (H1,Cn) configuration as described in Section 5.1 or Section 5.3. Achievable goals: Reliability, Load Sharing, interface switching 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 to its failed HoA (see issue Section 6.3.1). o Load Sharing, Interface Switching 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.1 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 Montavont, et al. Expires August 30, 2007 [Page 17] Internet-Draft Analysis of Multihoming in MIPv6 February 2007 would be needed. Montavont, et al. Expires August 30, 2007 [Page 18] Internet-Draft Analysis of Multihoming in MIPv6 February 2007 6. Issues Existing protocols may not be able to handle the requirements 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 requirements outlined in Section 3. In this section, we describe some of these issues in two main headings: general IPv6-related issues, and issues that are specific to MIPv6. 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. 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 [4] could be used. 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 Montavont, et al. Expires August 30, 2007 [Page 19] Internet-Draft Analysis of Multihoming in MIPv6 February 2007 set up. Usual IPv6 mechanisms for source and destination address selection, such as "Default Address Selection for IPv6" (RFC3484) [5] or DNS SRV Protocol (RFC2782) [6] 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 draft-soliman-flow-binding [4] may be used. Another related aspect of path selection is the concern of ingress filtering. This is covered below in Section 6.1.2. 6.1.2. Ingress Filtering In the (H*,Cn) case, a MN may be connected to multiple access networks or multiple home networks each practicing ingress filtering (such as those specified in RFC3704 [7] and RFC2827 [8]). Thus, to avoid ingress filtering, the selection of path would be limited by the choice of address used. This is related to Section 6.1.1. The problem of ingress filtering however, is two-fold. It can occur at the access network, as well as the home network. For instance, consider Figure 2 below. In the access network, when the MN sends a packet through AR-A, it must use CoA=PA.MN; and when MN sends a packet through AR-B, it must use CoA=PB.MN. In the home network, when the MN tunnels the packet to home agent HA-1, it must use HoA=P1.MN; and when MN tunnels the packet to home agent HA-2, it must use HoA=P2.MN. This greatly limits the way MN can benefit from its multihoming configuration. As an illustration, suppose MN is choosing the interface (which would determine the CoA used) and the home network to use (which would determine the HoA used), it might be possible that the chosen CoA is not registered with the chosen HoA. Montavont, et al. Expires August 30, 2007 [Page 20] Internet-Draft Analysis of Multihoming in MIPv6 February 2007 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 It must be noted that should the MN have a way of binding both CoAs PA.MN and PB.MN simultaneously to each of HoAs P1.MN and P2.MN (see Section 6.2.1), then it can choose the CoA to use based on the access network it wishes to use for outgoing packets. This solves the first part of the problem: ingress filtering at the access network. It is, nonetheless, still limited to using only a specific home agent for the home-address used (i.e. the second problem of ingress filtering at the home network remains unsolved). For this, mechanism such as those provided by Shim6 (see RFC3582 [9] and draft-ietf-shim6-proto [10]) may be used. 6.1.3. Failure detection Currently, IPv6 has not clearly defined mechanism for failure detection. 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. By now, 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). Current effort [11] in the DNA Working Group aims to address this, such as through the use of layer 2 triggers [12]. Movement detection might be extended to include other triggers such as the loss of connectivity on one interface. Further 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.2. MIPv6-specific Issues 6.2.1. Binding Multiple CoAs to a given HoA In the (H1,Cn) 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. Montavont, et al. Expires August 30, 2007 [Page 21] Internet-Draft Analysis of Multihoming in MIPv6 February 2007 Although in the (Hn,Cn) cases, MIPv6 allows MN to have multiple HoA and 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, solutions like draft-ietf-mcoa [13] may be used. 6.2.2. Simultaneous Location in Home and Foreign Networks Rule 4 of RFC3484 specifies that a HoA will always 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 some cases. When a MN is multihomed, it may have one of its interfaces directly connected to a home link. This may have an impact on the way multihoming is managed, since addresses from other interfaces cannot be registered as CoAs for the HoA associated to the home link the mobile node is connected on. In the special case of (H1,C*) 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.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 the use of multiple interfaces. These implementation-related considerations are described in the sub-sections below. 6.3.1. Using one HoA as a CoA In (Hn,C*) 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. If the MN looses its connectivity on its first interface, 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. Montavont, et al. Expires August 30, 2007 [Page 22] Internet-Draft Analysis of Multihoming in MIPv6 February 2007 According to the definition of a CoA, the current MIPv6 specification does not prohibit a HoA to be a 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 (Hn,C*) 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. 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 (Hn,C*) cases, MIPv6 does not provide any information on how HoAs should be bound on a device, and particularly there is no mechanism to bind HoAs to interfaces. This may be troublesome, for example, when we consider a MN 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 (H2,C3) HoA must always be assigned to an activated interface and if the MN Montavont, et al. Expires August 30, 2007 [Page 23] Internet-Draft Analysis of Multihoming in MIPv6 February 2007 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.3.4. Flow redirection Internet connectivity is guaranteed for a MN as long as at least one path is maintained between the MN and its CN. When the current path fails, an alternative path must be found to substitute the failed one. The redirection from the old path to the new path may result in broken sessions. In this case, 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 flow redirection is given in Appendix A. The different mechanisms that can be used to provide flow redirection can be split into two categories, depending on the part of the path that needs to be changed. The first category is when a CoA changes (i.e., the used CoA become invalid or new preferences indicate that the used CoA is no more the CoA to use): if one of the MN's CoA needs to be changed, it influences the path between the MN and its HA, and the path between the MN and its CN in RO mode. If the MN has multiple interfaces and one fails, established sessions on the failed interface would break if no support mechanism is used to redirect flows from the failed interface to another. The second category is when the HoA changes (i.e. the currently used HoA is not valid anymore, e.g., because IPv6 renumbering on the home link): if one of the MN's HoA needs to be changed, it influences the path between the CN and the HoA. In (Hn,C*) cases, the MN has multiple HoAs. If one fails, established sessions on the failed HoA would break if no support mechanism is used to redirect flows from a failed HoA to another, unless the transport session has multihoming capabilities, such as SCTP, to allow dynamic changing of addresses used. 6.4. Summary THIS TABLE IS A WORK IN PROGRESS (so all boxes may not have been filled appropriately). For now, please comment on the need for the table rather than the content) Montavont, et al. Expires August 30, 2007 [Page 24] Internet-Draft Analysis of Multihoming in MIPv6 February 2007 +=====================================================+ | # of HoAs: | 1 | 1 | n | n | n | | # of CoAs: | 1 | n | 0 | 1 | n | +=====================================================+ | General IPv6 Issues | +---------------------------------+---+---+---+---+---+ | Path Selection | | o | ? | o | o | +---------------------------------+---+---+---+---+---+ | Ingress Filtering | | | ? | o | o | +---------------------------------+---+---+---+---+---+ | Failure detection |o | o | ? | 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 | | | ? | | | +---------------------------------+---+---+---+---+---+ | 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 | +---------------------------------+---+---+---+---+---+ | Flow redirection | o | o | ? | o | o | +=====================================================+ Figure 4: Summary of Issues and Categorization Montavont, et al. Expires August 30, 2007 [Page 25] Internet-Draft Analysis of Multihoming in MIPv6 February 2007 7. TODO List Study security concerns Possibly discuss the possibility to use HoA on both home link and foreign link as in case (H1,C1): Mention about relation with Shim6. Reword all the text about the "returning home case" throughout the entire draft Consider the multiple HA addresses throughout the entire draft. Montavont, et al. Expires August 30, 2007 [Page 26] Internet-Draft Analysis of Multihoming in MIPv6 February 2007 8. Conclusion In this document, we have raised issues related to multihoming. We have seen that mechanisms are needed to redirect flow from a failed path to a new path, and mechanisms to decide which path should better be taken when multiple paths are available. This raises a number of issues. Even if MIPv6 can be used as a mechanism to manage multihomed MN, triggers of flows redirection between interfaces/addresses are not adapted to the multihoming status of the node. Also, we have shown that in some scenarios MIPv6 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 MIPv6, but solutions for these issues are needed for mobile nodes to fully enjoy the benefits of being multihomed. Montavont, et al. Expires August 30, 2007 [Page 27] Internet-Draft Analysis of Multihoming in MIPv6 February 2007 9. 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 August 30, 2007 [Page 28] Internet-Draft Analysis of Multihoming in MIPv6 February 2007 10. 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 August 30, 2007 [Page 29] Internet-Draft Analysis of Multihoming in MIPv6 February 2007 11. References [1] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [2] 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. [3] Manner, J. and M. Kojo, "Mobility Related Terminology", RFC 3753, June 2004. [4] Soliman, H., "Flow Bindings in Mobile IPv6", draft-soliman-monami6-flow-binding-00 (work in progress), March 2006. [5] Draves, R., "Default Address Selection for Internet Protocol version 6 (IPv6)", RFC 3484, February 2003. [6] Gukbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000. [7] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, March 2004. [8] 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. [9] Abley, J., Black, B., and V. Gill, "Goals for IPv6 Site- Multihoming Architectures", RFC 3582, August 2003. [10] Nordmark, E. and M. Bagnulo, "Level 3 multihoming shim protocol", draft-ietf-shim6-proto-07 (work in progress), November 2006. [11] Choi, J., "Goals of Detecting Network Attachment in IPv6", draft-ietf-dna-goals-04 (work in progress), December 2004. [12] Krishnan, S., Montavont, N., Yegin, A., Veerepalli, S., and A. Yegin, "Link-layer Event Notifications for Detecting Network Attachments", draft-ietf-dna-link-information-05 (work in progress), November 2006. [13] Wakikawa, R., "Multiple Care-of Addresses Registration", Montavont, et al. Expires August 30, 2007 [Page 30] Internet-Draft Analysis of Multihoming in MIPv6 February 2007 draft-ietf-monami6-multiplecoa-00 (work in progress), June 2006. [14] Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to Protect Mobile IPv6 Signaling Between Mobile Nodes and Home Agents", RFC 3776, June 2004. Montavont, et al. Expires August 30, 2007 [Page 31] Internet-Draft Analysis of Multihoming in MIPv6 February 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 comes available. This can be the case 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 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 [12] . 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 August 30, 2007 [Page 32] Internet-Draft Analysis of Multihoming in MIPv6 February 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 August 30, 2007 [Page 33] Internet-Draft Analysis of Multihoming in MIPv6 February 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 August 30, 2007 [Page 34] Internet-Draft Analysis of Multihoming in MIPv6 February 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 August 30, 2007 [Page 35]