IETF MIP6 Working Group N. Montavont Internet-Draft LSIIT - ULP Expires: April 25, 2005 R. Wakikawa Keio University T. Ernst WIDE at Keio University T. Noel LSIIT - ULP C. Ng Panasonic Singapore Labs October 25, 2004 Analysis of Multihoming in Mobile IPv6 draft-montavont-mobileip-multihoming-pb-statement-02.txt Status of this Memo This document is an Internet-Draft and is subject to all provisions of section 3 of RFC 3667. 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 become aware will be disclosed, in accordance with RFC 3668. 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 April 25, 2005. Copyright Notice Copyright (C) The Internet Society (2004). Abstract Montavont, et al. Expires April 25, 2005 [Page 1] Internet-Draft Analysis of Multihoming in Mobile IPv6 October 2004 The use of multiple interface is foreseen to provide ubiquitous, permanent and fault-tolerant access to the Internet, particularly on mobile hosts which are more subject to failure or sudden lacks of connectivity. However, Mobile IPv6 currently lack support for such multihomed nodes. Individual solutions have been proposed to extend Mobile IPv6 but all issues have not been addressed in a single document. The purpose of the present document is thus to fill this gap and to contribute to raise the discussion in order to make sure that forthcoming solutions will address all the issues. In this document, we propose a taxonomy to classify the situations where a mobile node could be multihomed. This taxonomy is then used to highlight the issues preventing mobile nodes operating Mobile IPv6 to be multihomed. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Taxonomy . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1 Taxonomy definition . . . . . . . . . . . . . . . . . . . 4 2.2 Taxonomy explanation . . . . . . . . . . . . . . . . . . . 5 3. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.1 x=1: only onr interface on the host . . . . . . . . . . . 7 3.2 x=n: The host has several interfaces . . . . . . . . . . . 7 4. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 9 4.1 Issues Related to Mobile IPv6 . . . . . . . . . . . . . . 9 4.2 Issues Not Related to Mobile IPv6 . . . . . . . . . . . . 9 4.3 Issues Related to a Host Connected to Home Link . . . . . 10 4.4 Redirection transparency . . . . . . . . . . . . . . . . . 10 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 13 Intellectual Property and Copyright Statements . . . . . . . . 15 Montavont, et al. Expires April 25, 2005 [Page 2] Internet-Draft Analysis of Multihoming in Mobile IPv6 October 2004 1. Introduction Mobile IPv6 [1],[2] is designed to allow a mobile node to maintain its IPv6 communications while moving between IPv6 subnets. However, the current specification does not give hints nor requirements to deal with mobile nodes with multiple points of attachement, i.e. a multihomed mobile node. The purpose of the present document is to fill this gap. This document has two goals. The first goal is to define a taxonomy which helps to represent the different situations where a mobile host is multihomed. For each case, we show the configuration a multihomed host may have (number of interfaces, number of Home Addresses or number of Care-of Addresses). We also give a concrete illustration for each scenario. The second goal of this document is to define the requirements needed to manage multihomed hosts. Different issues will be raised in order to provide full support of multihomed hosts in Mobile IPv6. The potentially needed solutions to support new features will be described in a separate document. The reader is assumed to have read our 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 of the present study. The terms used in this memo are the same as the ones used in Mobile IPv6 [1]. The document is organized as follows: in the first section, we propose a taxonomy to classify the different cases where mobile hosts are multihomed. Then this taxonomy is used to describe the multihoming scenarios specific to Mobile IPv6. In the next section, an analysis of each case is given in order to select the most interesting scenarios highlighted in the previous section. The last section summarizes the different features needed in Mobile IPv6 to reach the goals defined in [3]. Montavont, et al. Expires April 25, 2005 [Page 3] Internet-Draft Analysis of Multihoming in Mobile IPv6 October 2004 2. Taxonomy 2.1 Taxonomy definition 0 As detailed in [3], multihoming can provide a number of benefits: ubiquitous access, redundancy/fault recovery, load sharing, load balancing, bicasting and preferences settings. In that document, the multihoming study is split into two main axes: either the node has only one interface (and several IPv6 addresses) or the node has several interfaces. In this memo, we follow the same guidelines, but we conduct this study from the pespective of mobile nodes operating Mobile IPv6 specifically. However, two more parameters are necessary to study the feasability of each goal: the multihoming management will be different according to the number of Home Addresses and the number of Care-of Addresses the mobile node has. We thus propose the following taxonomy: o x = number of active interfaces o y = number of Home Addresses (HoAs) o z = 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. An illustration of this taxonomy is given in Figure 1. Montavont, et al. Expires April 25, 2005 [Page 4] Internet-Draft Analysis of Multihoming in Mobile IPv6 October 2004 Mobile Node HoA1 HoA2 ... HoAn --> Mobile IP layer (x) | | | +-----+--------+ | | | | | | | CoA1 +--CoA2 +---CoA3 ... CoAn --> IP layer (y) | | | | Link1 Link2 Link3 ... Linkn --> IPv6 Link (n/a *) | | | | +-----+----+ | | | | | IF1 IF2 ... IFn --> Physical layer (z) (z = the number of active interfaces) HoA1 ::= {CoA1, 2, 3} [IF1 and IF2] HoA2 ::= {CoA3} [IF2] Mobile Node(x = 2, y = 3, z = 2) * because number of IPv6 link is equal to the number of CoAs, equal to y Figure 1: Illustration of the chosen taxonomy The variable y indicates the number of HoAs allocated to a host. A host may have multiple HoAs (x=n) when either: o The host has only one home link, and all its HoAs are based on the same IPv6 prefix (e.g. the host may have multiple interfaces). o The host has only one home link, and multiple HoAs with distinct prefixes because there are several IPv6 prefixes advertised on the home link. o The host has several home links, and thus has at least two HoAs with different IPv6 prefixes. As the taxonomy suggests, the fact that the mobile node has several HoAs is independent from the fact that the mobile node has multiple interfaces. The fact that the mobile node has multiple interfaces does not imply that it has multiple HoAs and vice-versa. 2.2 Taxonomy explanation We propose a taxonomy with three 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 configuration. According to the number of interfaces, a mobile node Montavont, et al. Expires April 25, 2005 [Page 5] Internet-Draft Analysis of Multihoming in Mobile IPv6 October 2004 can indeed expect different benefits. If several interfaces are available, they can for instance be used simultaneouly to save bandwidth. If only one interface is available at a time but the node is still multihomed, multiple source / destination addresses or multiple HAs may be used according to the type of traffic. This feature could also allow load balancing. The number of HoAs and CoAs help to consider all scenarios of multihomed nodes. These parameters will have an impact on the way multihoming is supported. According to the number of HoAs and CoAs, different policies will be needed, such as which CoA have to be mapped with which HoA, do all the CoAs need to be mapped with all the HoAs, etc. Montavont, et al. Expires April 25, 2005 [Page 6] Internet-Draft Analysis of Multihoming in Mobile IPv6 October 2004 3. Scenarios This section is split into two parts according to the number of interfaces on the mobile node. This distinction is made to help the reader to better understand the different cases, but also because the benefits for the mobile node will be different according to this parameter. 3.1 x=1: only onr interface on the host 1. One HoA, one CoA (1,1,1) The host is not multihomed. The host has only one interface, with one HoA and is currently away from its home link (one CoA on the foreign link). 2. Several HoAs, one CoA (1,n,1) The host is multihomed, since it has several HoAs. This case may happen when a host is getting access to Internet through different ISPs and each offers a Mobile IPv6 service to the host. That way, the host will have a HoA per ISP. Once the host is connected to a visited IPv6 subnet, it gets one CoA. This CoA may be registered with all the Home Agents provided by the ISPs, in order to remain simulteneously reachable through all its HoAs. 3. One HoA, several CoAs (1,1,n) The host is multihomed since it has several CoAs. This case may occur when the interface of the host is connected to a link where multiple IPv6 prefixes are advertised. 4. Several HoAs, several CoAs (1,n,n) The host is multihomed, since it has multiple addresses. This case can be viewed as a combination of the two cases described above: the host has several HoAs (e.g. given by different ISPs) and several CoAs (e.g. because the host is receiving multiple IPv6 prefixes). 3.2 x=n: The host has several interfaces 1. One HoA, one CoA (n,1,1) The host is multihomed: this is a special case of a host with two interfaces connected to different IPv6 subnets; one of the subnet is the home network of the host and allows the host to directly Montavont, et al. Expires April 25, 2005 [Page 7] Internet-Draft Analysis of Multihoming in Mobile IPv6 October 2004 use its HoA (without the MIPv6 mechanisms). The host can build a temporarily IPv6 address on its other interface but it cannot register the temporary address with its Home Agent because the host is using its HoA. If the host decides to update its location, it will not be able to use its HoA on the interface connected to its home link. 2. One HoA, several CoAs (n,1,n) The host is multihomed: the host has several addresses to choose from. For example, consider a host with several interfaces, each connected to an IPv6 network (the same or not). In this example, at least one global IPv6 address is configured on each interface. The host has only one home link, and only one Home Agent. 3. Several HoA, one CoA (n,n,1) The host is multihomed. This case extends the case (n,1,1) when the host has several HoAs, for example from multiple ISPs. The CoA can be associated with each HoA. 4. Several HoAs, several CoAs (n,n,n) The host is multihomed. Many scenarios may lead to this case. For example, consider a host 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 advertised. Montavont, et al. Expires April 25, 2005 [Page 8] Internet-Draft Analysis of Multihoming in Mobile IPv6 October 2004 4. Open Issues In this section we highlight open issues which have to be taken into account to handle a multihomed host using Mobile IPv6 and we list the requirements for a Mobile IPv6 node to benefit from its multihomed configuration in an optimized fashion. To meet some of these requirements, specific procedures in the Mobile IPv6 specification will be required. It's not the purpose of this document to provide solutions to meet these requirements but we give some hints. Solutions to meet these requirements shall be defined in a separate document. 4.1 Issues Related to Mobile IPv6 1. In the (*,n,*) cases when the mobile host obtains a new CoA, it's not clear to which HoA the new CoA would be bound to. There is thus a need to define a relationship between HoAs and CoAs. For example, does the mobile node needs to register each new CoA with each HoA. 2. In the (*,1,n) cases, several CoAs may be simultaneously used by a mobile node. In this case, the host must be able to register all CoAs with a single HoA on a distant node (Correspondent Node or Home Agent). Also, the MN needs a mechanism to select the primary CoA to be bound to the HA. Other mechansims may be needed to define policies to use several CoAs simultaneously, according to the CN and/or the flow. The issues related to the multiple CoAs usage are "how to manage multiple CoAs bound to a single HoA" and "how to identify an entry in the Binding Cache". Solutions like [4] may be used. 3. In case (*,n,*) cases, a HoA may be seen as a CoA from the perspective of another home link of a mobile node. For example, let us assume a mobile node with three interfaces, where each interface has a home address (HoA1, HoA2 and HoA3 repectively) determined from three different home links. If we consider that the mobile node is connected to two of its home links via two interfaces, and looses its network connection via the third interface, it may want to register its two other HoAs (i.e. HoA1 and HoA2) as a CoA for HoA3. Thus the definition of a HoA address may need to be extended in the context of multiple different HoAs. 4.2 Issues Not Related to Mobile IPv6 1. In the (n,*,*) cases, the solution should bring support to allow a mobile host to simultaneously use several interfaces, Montavont, et al. Expires April 25, 2005 [Page 9] Internet-Draft Analysis of Multihoming in Mobile IPv6 October 2004 regardless the number of HoAs and CoAs the mobile node may have and regardless the network topology the mobile node is connected to. The simultaneous use of several interfaces would allow a mobile node to spread its different flows between its interfaces. 2. In the (*,n,*) case, a mechanism should be defined to detail how to bind multiple HoAs to a host. 3. In the (n,*,*) cases, a mechanism is needed to redirect flows from one interface to another: this functionality would allow a mobile node to pursue all communication flows that were initiated via the old interface via another interface. MIPv6 can be used to perform redirection between interfaces, as specified in [5]. 4. In the (n,1,1) case, the node may want to use each interface differently according to some 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. In order to optimize the global connectivity of a multihomed host, a specific support may allow a multihomed hosts to set filters on flows on distant nodes (Correspondent Node or Home Agent), such as mechanisms proposed by [6], [7] and [8]. 4.3 Issues Related to a Host Connected to Home Link In the (n,*,*) cases listed in Section 3, the host may have one of its interfaces directly connected to a home link. This may have an impact on the multihoming management. For example, if we consider the case (n,n,n) with a host having three interfaces, three HoAs and two CoAs (connected to two visited IPv6 subnets), the CoAs cannot be registered with the Home Agent serving the host on the home link it is connected to. Otherwise, the case (n,n,n) can translate into either case (n,n,1) or (n,n,0) according to the way the host is connected to the Internet. Case (n,n,1) only happens when the host is connected to a visited link with only one interface and obtain only one CoA. Other interfaces are connected to the home link(s). In the case (n,n,0), i.e. several interfaces, several HoAs, and no CoA, all interfaces of the host are connected to their respective home links. 4.4 Redirection transparency When considering the goals/benefits defined in [3], one has to consider whether these goals can be achieved with transparency or without transparency. Transparency is achieved when switching Montavont, et al. Expires April 25, 2005 [Page 10] Internet-Draft Analysis of Multihoming in Mobile IPv6 October 2004 between interfaces does not cause the disruption of on-going sessions. In order to achieve transparency, a necessary (may or may not be sufficient) condition is for the end-point addresses to remain unchanged. This is in-view of the large amount of Internet traffic today are carried by TCP, which unlike SCTP, cannot handle multiple end-point address pairs. Montavont, et al. Expires April 25, 2005 [Page 11] Internet-Draft Analysis of Multihoming in Mobile IPv6 October 2004 5. Acknowledgments The authors would like to than all the people who have sent comments so far, particularly Tobias Kufner for raising a new issues. 6 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. and E-K. Paik, "Goals and Benefits of Multihoming", draft-ernst-generic-goals-and-benefits-00 (work in progress), July 2004. [4] Wakikawa, R., "Multiple Care-of Addresses Registration", draft-wakikawa-mobileip-multiplecoa-03 (work in progress), July 2004. [5] Montavont, N., Noel, T. and M. Kassi-Lahlou, "MIPv6 for Multiple Interfaces", draft-montavont-mobileip-mmi-02 (work in progress), October 2003. [6] Soliman, H., Malki, K. and C. Castelluccia, "Per-flow movement in MIPv6", draft-soliman-mobileip-flow-move-02 (work in progress), July 2002. [7] Montavont, N. and T. Noel, "Home Agent Filtering for Mobile IPv6", draft-montavont-mobileip-ha-filtering-v6-00 (work in progress), January 2004. [8] Kuladinithi, K., "Filters for Mobile IPv6 Bindings (NOMADv6)", draft-nomadv6-mobileip-filters-02 (work in progress), June 2004. [9] Manner, J. and M. Kojo, "Mobility Related Terminology", RFC 3753, June 2004. [10] Ernst, T. and H. Lach, "Network Mobility Support Terminology", draft-ietf-nemo-terminology-02 (work in progress), October 2004. [11] Stemm, M. and R. Katz, "Vertical Handoffs in Wireless Overlay Montavont, et al. Expires April 25, 2005 [Page 12] Internet-Draft Analysis of Multihoming in Mobile IPv6 October 2004 Networks", Journal Mobile Networks and Applications, vol. 3, number 4, pages 335-350, 1998. Authors' Addresses Nicolas Montavont LSIIT - Univerity Louis Pasteur Pole API, bureau C444 Boulevard Sebastien Brant Illkirch 67400 FRANCE Phone: (33) 3 90 24 45 87 EMail: montavont@dpt-info.u-strasbg.fr URI: http://www-r2.u-strasbg.fr/~montavont/ Ryuji Wakikawa Keio University Jun Murai Lab., 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.mobileip.jp/ Thierry Ernst WIDE at Keio University Jun Murai Lab., Keio University. K-square Town Campus, 1488-8 Ogura, Saiwa-Ku Kawasaki, Kanagawa 212-0054 Japan Phone: +81-44-580-1600 Fax: +81-44-580-1437 EMail: ernst@sfc.wide.ad.jp URI: http://www.sfc.wide.ad.jp/~ernst/ Montavont, et al. Expires April 25, 2005 [Page 13] Internet-Draft Analysis of Multihoming in Mobile IPv6 October 2004 Thomas Noel LSIIT - Univerity Louis Pasteur Pole API, bureau C444 Boulevard Sebastien Brant Illkirch 67400 FRANCE Phone: (33) 3 90 24 45 92 EMail: noel@dpt-info.u-strasbg.fr URI: http://www-r2.u-strasbg.fr/~noel/ 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: cwng@psl.com.sg Montavont, et al. Expires April 25, 2005 [Page 14] Internet-Draft Analysis of Multihoming in Mobile IPv6 October 2004 Intellectual Property Statement 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. Disclaimer of Validity 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 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. Copyright Statement Copyright (C) The Internet Society (2004). 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Montavont, et al. Expires April 25, 2005 [Page 15]