IETF MIP6 Working Group N. Montavont Internet-Draft LSIIT - ULP Expires: July 11, 2005 R. Wakikawa Keio University T. Ernst WIDE at Keio University T. Noel LSIIT - ULP C. Ng Panasonic Singapore Labs January 10, 2005 Analysis of Multihoming in Mobile IPv6 draft-montavont-mobileip-multihoming-pb-statement-03.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 July 11, 2005. Copyright Notice Copyright (C) The Internet Society (2005). Abstract Montavont, et al. Expires July 11, 2005 [Page 1]
Internet-Draft Analysis of Multihoming in Mobile IPv6 January 2005 The use of multiple interfaces is foreseen to provide ubiquitous, permanent and fault-tolerant access to the Internet, particularly on mobile nodes which are more subject to failure or sudden lacks of connectivity. However, Mobile IPv6 currently lacks 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 up this gap and 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. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Taxonomy . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 6 5. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 7 6. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 9 6.1 Deciding which HoA a new CoA should be bound to . . . . . 9 6.2 Binding Multiple CoAs to a HoA . . . . . . . . . . . . . . 10 6.3 Using one HoA as a CoA . . . . . . . . . . . . . . . . . . 10 6.4 Using multiple interfaces simultanouely . . . . . . . . . 10 6.5 Relationship between interfaces and HoAs . . . . . . . . . 10 6.6 Flow redirection . . . . . . . . . . . . . . . . . . . . . 11 6.7 Flows filtering . . . . . . . . . . . . . . . . . . . . . 11 6.8 Multiple HoAs . . . . . . . . . . . . . . . . . . . . . . 12 7. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 12 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 12 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 14 Intellectual Property and Copyright Statements . . . . . . . . 16 Montavont, et al. Expires July 11, 2005 [Page 2]
Internet-Draft Analysis of Multihoming in Mobile IPv6 January 2005 1. Introduction 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 lacks of connectivity. 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 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. Individual solutions have been proposed to extend Mobile IPv6 for multihomed mobile nodes, but all issues have not been addressed in a single document. The purpose of the present document is thus to fill up this gap by listing such issues, raising the discussion at the IETF, and placing some requirements in order to propose comprehensive solutions in forthcoming standards. This document has two goals. The first goal of this document is to define the requirements from the point of view of multihomed mobile nodes operating Mobile IPv6. The second goal of this document is to define the issues araising when we attempt to fullfil these requirements. The definition of the potentially needed solutions is out of scope of the analysis document. These should be defined in a separate document once the IETF community agrees on which issues should be solved. 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 (number of interfaces, number of Home Addresses or number of Care-of Addresses). We also illustrate each scenario. To understand the foundation of this document, the reader must 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 reader must also understand the operation of the Mobile IPv6 protocol ([1]). The document is organized as follows: in the first section, we introduce terminology related to multihoming. Then we propose a taxonomy to classify the different cases where mobile nodes are multihomed. We then present requirements for multihomed MN. Thereafter the taxonomy is used to describe the multihoming scenarios specific to Mobile IPv6. Finaly we list all open issues related to a Montavont, et al. Expires July 11, 2005 [Page 3]
Internet-Draft Analysis of Multihoming in Mobile IPv6 January 2005 multihomed MN and identify what is missing to reach goals fixed in [3]. 2. Terminology The terms used in the present document are defined in [4], [1] and [3]. From now on we will use the abbreviations MIP6 for Mobile IPv6 and MN for a "Mobile Node operating MIP6". In [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 MIP6, this may translate into the MN having multiple HoAs and/or multiple CoAs: o A MN would have multiple HoAs if multiple prefixes are advertised on the home link or if it has multiple interfaces named on (presumably) distinct home links. o A MN would have multiple CoAs if multiple prefixes are advertised on the foreign link or if it has multiple interfaces attached to (presumably) distinct foreign links. A valid address is an address topologically correct (it is named after the prefix advertised on the link the interface is attached to) and routable. A MN is said to be "simultaneously using multiple addresses" if the MN has the ability to use any of the said multiple addresses at the same time. This implies that the MN is able to receive packets with destination address field equals to any of the said multiple addresses, and the MN is able to choose any of the said multiple addresses as the source address of the packets it is sending. A MN is said to be "simultaneously using multiple interfaces" if there is at least one valid address named for each of the said multiple interfaces, and that the MN is able to simultaneously use these addresses. 3. Taxonomy In order to aid the discussion of the benefits of multihoming as listed in [3] from the perspective of a mobile node, we will use the following taxonomy in this document: Montavont, et al. Expires July 11, 2005 [Page 4]
Internet-Draft Analysis of Multihoming in Mobile IPv6 January 2005 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. Mobile Node HoA1 HoA2 ... HoAn --> Mobile IP layer (y) | | | +-----+--------+ | | | | | | | CoA1 +--CoA2 +---CoA3 ... CoAn --> IP layer (z) | | | | Link1 Link2 Link3 ... Linkn --> IPv6 Link (n/a *) | | | | +-----+----+ | | | | | IF1 IF2 ... IFn --> Physical layer (x) HoA1 ::= {CoA1, 2, 3} [IF1 and IF2] HoA2 ::= {CoA3} [IF2] Mobile Node(x = 2, y = 2, z = 3) * because number of IPv6 link is equal to the number of CoAs, equal to y Figure 1: Illustration of the Taxonomy The variable y indicates the number of HoAs allocated to a node. A node may have multiple HoAs (y=n) when either: o The node has only one home link, and all its HoAs are based on the same IPv6 prefix (e.g. the node may have multiple interfaces). o The node has only one home link, and multiple HoAs with distinct prefixes because there are several IPv6 prefixes advertised on the home link. o The node 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 Montavont, et al. Expires July 11, 2005 [Page 5]
Internet-Draft Analysis of Multihoming in Mobile IPv6 January 2005 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. 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 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. 4. Requirements To achieve the benefits of multihoming as described in [3], some requirements on the MN might have to be fulfilled. These include: o The MN must have a valid address on each link an interface is attached to. o The MN must have either multiple interfaces with at least a single valid IP address on each interface, or a single interface with more than one valid address. o A MN equipped with multiple interface must be able to use multiple interfaces simultaneously. o A MN quipped with multiple interfaces must be able to attach distinct interfaces to different access networks (distinct foreign links or distinct home links, or a combination of both) o If several interfaces are activated and configured with valid addresses, the MN should be able to share its traffic load among these interfaces. o If an interface is used as backup and the primary interface failed (loss of connection), a mechanism should be available to quickly activate the backup interface and redirect traffic. Montavont, et al. Expires July 11, 2005 [Page 6]
Internet-Draft Analysis of Multihoming in Mobile IPv6 January 2005 o The MN must be able to use multiple Home Agents simultaneously if they are available o 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 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. We will next analyse issues arising from current Mobile IPv6 Specifications when trying to fulfill these requirements. 5. 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. 1. (1,1,1): 1 iface, 1 HoA, 1 CoA The node is not multihomed. The node has only one interface, with one HoA and is currently away from its home link (one CoA on the foreign link). Achievable benefits: none. 2. (1,n,1): 1 iface, several HoAs, 1 CoA The node is multihomed, since it has several HoAs. This case may happen when a node is getting access to Internet through different ISPs and each offers a Mobile IPv6 service to the node. That way, the node will have a HoA per ISP. Once the node 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. Achievable benefits: fault recovery, load sharing, preference settings. 3. (1,1,n): 1 iface, 1 HoA, several CoAs The node is multihomed since it has several CoAs. This case may Montavont, et al. Expires July 11, 2005 [Page 7]
Internet-Draft Analysis of Multihoming in Mobile IPv6 January 2005 occur when the interface of the node is connected to a link where multiple IPv6 prefixes are advertised. Achievable benefits: fault recovery, load sharing, bicasting, preference settings. 4. (1,n,n): 1 iface, several HoAs, several CoAs The node is multihomed, since it has multiple addresses. This case can be viewed as a combination of the two cases described above: the node has several HoAs (e.g. given by different ISPs) and several CoAs (e.g. because the node is receiving multiple IPv6 prefixes). Achievable benefits: fault recovery, load sharing, bicasting, preferences settings. 5. (n,1,1): n ifaces, 1 HoA, 1 CoA The node is multihomed: this is a special case of a node with two interfaces connected to different IPv6 subnets; one of the subnet is the home network of the node and allows the node to directly use its HoA (without the MIPv6 mechanisms). The node can build a temporarily IPv6 address on its other interface but it cannot register the temporary address with its Home Agent because the node is using its HoA. If the node decides to update its location, it will not be able to use its HoA on the interface connected to its home link. Achievable benefits: ubiquitous access, fault recovery, load sharing, load balancing, preference settings 6. (n,1,n): n ifaces, 1 HoA, several CoAs The node is multihomed: the node has several addresses to choose from. For example, consider a node 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 node has only one home link, and only one Home Agent. Achievable benefits: ubiquitous access, fault recovery, load sharing, load balancing, bicasting, preference settings 7. (n,n,1): n ifaces, several HoA, one CoA The node is multihomed. This case extends the case (n,1,1) when the node has several HoAs, for example from multiple ISPs. The CoA can be associated with each HoA. Montavont, et al. Expires July 11, 2005 [Page 8]
Achievable benefits: ubiquitous access, fault recovery, load sharing, load balancing, bicasting, preference settings 8. (n,n,n): n ifaces, several HoAs, several CoAs The node is multihomed. Many scenarios may lead to this case. For example, 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 advertised. Achievable benefits: ubiquitous access, fault recovery, load sharing, load balancing, bicasting, preference settings 6. Problem Statement Internet connectivity is guaranteed for a MN as long as at least one path is maintained between the MN and the fixed Internet. When an alternative path must be found to substitute a failed one, the loss of the previous path may result in broken sessions. New transport sessions would have to be established over the alternate path if no mechanism is provided to make this change transparent at layers above layer 3. In order to meet other expected benefits of multihoming, multiple paths may be maintained simulateneously (e.g. for load balancing, load sharing) or not (e.g. for redundancy) between the mobile node and the home network(s). 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 fault recovery, preferences) or to split traffic between multiple paths (e.g. for load sharing, load balacing) Existing protocols may not be able to handle such cases. 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 MIP6 solely, whereas other issues are not at all related to MIP6. However, such non MIP6 issues must be solved in order to reach all the goals of multihoming. 6.1 Deciding which HoA a new CoA should be bound to In the (*,n,*) cases, the MN has multiple HoAs. When the MN moves and configure a new CoA, the newly obtained CoA must be bound to a specific HoA. The current MIP6 specification doesn't provide a mechanism to determine to which HoA this newly acquirred CoA should be bound to. With no such mechanism, the MN may be confused and may bind this CoA Montavont, et al. Expires July 11, 2005 [Page 9]
Internet-Draft Analysis of Multihoming in Mobile IPv6 January 2005 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.2 Binding Multiple CoAs to a HoA In the (*,1,n) cases, multiple CoAs would be available on the MN. However, the current MIP6 specification doesn't allow to register multiple CoAs for a single HoA. 6.3 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 disctinct 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. According to the definition of a CoA, the current MIP6 specification prohibits to register another HoA as a CoA. In order to counter this, a MN must be able to register whatever address it owns with any of its HoA. A mechanism is needed to determine how to decide which HoA will be chosen and the definition of a HoA and CoA might be extended. 6.4 Using multiple interfaces simultanouely In (n,*,*) cases, the MN has multiple interfaces. The simultaneous use of several interfaces would allow a mobile node to spread its different flows between its interfaces. MIP6 does not presently allow the MN to register and use several interfaces simultaneously, regardless the number of HoAs and CoAs the mobile node may have and regardless the network topology the mobile node is connected to. 6.5 Relationship between interfaces and HoAs In (*,n,*) cases, MIPv6 does not define any relation between HoAs and interfaces, and particularly there is no mechanism to bind HoAs to interfaces. For example, consider a MN equipped with two HoAs and 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. Montavont, et al. Expires July 11, 2005 [Page 10]
Internet-Draft Analysis of Multihoming in Mobile IPv6 January 2005 HoA1 HoA2 CoA 1 CoA2 CoA3 Iface1 Iface2 Iface3 Figure 2: Illustration of the case (3,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.6 Flow redirection In the (n,*,*) cases, the MN has multiple interfaces. If one interface fails, established sessions on the failed interface would break if no support mechanism is used to redirect flows from the failed interface to another. MIP6 allows a MN to move transparently from one access link to another access link when the same interface is used, i.e. in cases (1,*,*). However, in cases (n,*,*), MIP6 doesn't provide a mechanism to transmit traffic established over one interface to another interface. Movement detection might be extended to include other triggers such as the loss of connectivity on one interface. Moreover, the chosen mechanism must work whatever the previous bindings the MN has registered. The redirection between interfaces can be performed transparently to the MNs if mechanisms such as specified in [5] are brought to the MN. 6.7 Flows filtering In the (n,*,*) case, the node has multiple interfaces. If each interface may be used 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 node, a specific mechanims may allow a multihomed node to set filters on flows on distant nodes (Correspondent Node or Home Agent), such as mechanisms proposed by [6], [7] and [8]. Montavont, et al. Expires July 11, 2005 [Page 11]
Internet-Draft Analysis of Multihoming in Mobile IPv6 January 2005 6.8 Multiple HoAs In the (n,*,*) cases listed in Section 5, the node 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 node 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 node 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 node is connected to the Internet. Case (n,n,1) only happens when the node 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 node are connected to their respective home links. 7. Conclusion In this document, we have raised issues related to multihoming. Even if MIPv6 can be used as 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 ambigous in the CoA / HoA definition and in the mapping between HoAs, CoAs and CoAs. Finaly, we have also raised issues not directly related to MIPv6, but which are needed to achieve benefits described in [3]. 8. Contributors The following people have contributed ideas, text and comments to this draft: Koojana Kuladinithi, Eun Kyoung Paik. 9. Acknowledgments The authors would like to than all the people who have sent comments so far, particularly Tobias Kufner for raising new issues. 10 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 Montavont, et al. Expires July 11, 2005 [Page 12]
Internet-Draft Analysis of Multihoming in Mobile IPv6 January 2005 Agents", RFC 3776, June 2004. [3] Ernst, T., "Goals and Benefits of Multihoming", draft-multihoming-generic-goals-and-benefits-00 (work in progress), February 2004. [4] Manner, J. and M. Kojo, "Mobility Related Terminology", RFC 3753, June 2004. [5] Montavont, N., Noel, T. and M. Kassi-Lahlou, "MIPv6 for Multiple Interfaces", draft-montavont-mobileip-mmi-00 (work in progress), July 2002. [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] Ernst, T. and H. Lach, "Network Mobility Support Terminology", draft-ietf-nemo-terminology-02 (work in progress), October 2004. [10] Wakikawa, R., "Multiple Care-of Addresses Registration", draft-wakikawa-mobileip-multiplecoa-03 (work in progress), July 2004. [11] Stemm, M. and R. Katz, "Vertical Handoffs in Wireless Overlay Networks", Journal Mobile Networks and Applications, vol. 3, number 4, pages 335-350, 1998. Montavont, et al. Expires July 11, 2005 [Page 13]
Internet-Draft Analysis of Multihoming in Mobile IPv6 January 2005 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 July 11, 2005 [Page 14]
Internet-Draft Analysis of Multihoming in Mobile IPv6 January 2005 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 July 11, 2005 [Page 15]
Internet-Draft Analysis of Multihoming in Mobile IPv6 January 2005 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 (2005). 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 July 11, 2005 [Page 16]