Mobopts Research Group C. Ng Internet-Draft Panasonic Singapore Labs Expires: May 15, 2008 K. Aso Matsushita Electric Industrial Co. Ltd. (Panasonic) November 12, 2007 On Mobile IPv6 Optimization and Multihoming draft-ng-mobopts-multihoming-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on May 15, 2008. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract This memo explores the possible areas of extensions to MIPv6 route optimization in the considerations of multihomed nodes. The intention is to raise awareness in the research community, leading to a possible extension to RFC 4651. Ng & Aso Expires May 15, 2008 [Page 1] Internet-Draft MIPv6 Optimization and Multihoming November 2007 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Multihomed Mobile Node . . . . . . . . . . . . . . . . . . . . 3 3. Multihomed Anchor Node . . . . . . . . . . . . . . . . . . . . 3 4. Multihomed Correspondent Node . . . . . . . . . . . . . . . . . 3 5. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 5 6. Informative Reference . . . . . . . . . . . . . . . . . . . . . 5 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . . 6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 Intellectual Property and Copyright Statements . . . . . . . . . . 8 Ng & Aso Expires May 15, 2008 [Page 2] Internet-Draft MIPv6 Optimization and Multihoming November 2007 1. Introduction RFC 4651 [1] discussed and analyzed various techniques of optimizing the Route Optimization in Mobility Support in IPv6 (Mobile IPv6, or MIPv6) [2]. One area in which RFC 4651 had not considered, which was in fact mentioned as a future research area, is the consideration of multihomed nodes. As different access technologies continues to emerge, the likelihood of a node being multihomed increases. Additionally, a node can enjoy various benefits, such as more resilience to link failures or network congestions, as documented in various literature (e.g. see [3], [4], [5]). Thus, it could be expected that in future, a substantial portion of nodes involved in Mobile IPv6 signaling will be multihomed. Narayanan et. al provided a good analysis in the interaction of between various mobility and multihoming protocols in [6] from an architectural perspective. The present memo is not meant to duplicate the work there. Instead, it is our intention to analyze if there are opportunities for optimization when multihomed node is involved in Mobile IPv6 signaling. For this purpose, this memo first consider the case where the mobile node is multihomed in Section 2, and then the case where the anchor node (i.e. home agent, mobility anchor point, etc) is multihomed in Section 3. Finaly, the case where the correspondent node is multihomed is considered in Section 4. [AUTHOR'S NOTE]: Due to time constraint, only Section 4 is completed. The remaining 2 sections will be added in subsequent versions. 2. Multihomed Mobile Node TBD 3. Multihomed Anchor Node TBD 4. Multihomed Correspondent Node There are two main possibilities why a correspondent node can be multihomed. Firstly, the correspondent node can be on a multihomed site. Secondly, the correspondent node may be using multiple Ng & Aso Expires May 15, 2008 [Page 3] Internet-Draft MIPv6 Optimization and Multihoming November 2007 interfaces. In both cases, the correspondent node would configure multiple addresses, and may use more than one address when communicating with the mobile node. Such communications may take the form of: o Single Session: with the use of multihoming-capable protocols such as Stream Control Transmission Protocol (SCTP) [7], or Site Multihoming by Intermediation (Shim6) [8], the correspondent node and mobile node may be having only a single transport session, even though multiple addresses are used. o Multiple Sessions: the correspondent node may wish to perform load balancing between its multiple addresses such that, for instance, audio streams would use one address while video stream uses another address when having a video conference session with the mobile node. In both of the forms, the packet data unit (PDU) received by the IP layer of the mobile node from the upper layers will be addressed to multiple addresses belonging to the correspondent node. In the Single Session case, the SCTP or SHIM6 protocol layer will split the traffic stream into different PDUs to be sent to different addresses of the correspondent node. In the Multiple Sessions case, the applications will open different sessions addressed to different addresses of the correspondent node. Either way, the Mobile IP layer will not be aware of the fact that all these different addresses belong to the same physical node. When route optimization is attempted, the mobile node will initiate return routability procedure with each and every of the correspondent node's addresses, oblivious to the fact that only one set of return routability procedure is needed to bind its care-of address to its home address at the correspondent node. Approaches to eliminate such redundant signalling would involve making the Mobile IP layer of the mobile node aware that the addresses all belongs to the same correspondent node. In one approach, special application programming interface (API) is provided to allow upper layers to link a set of addresses as belonging to a single entity. This will allow SCTP, Shim6 or other multihoming protocols to inform the Mobile IP layer that route optimization is enabled with all the addresses in the linked set as long as return routability procedure is successfully conducted with one of the addresses in the linked set. The disadvantage of this approach is that it relies on upper layers to utilize the newly provided API. Old, unmaintained programs would not be able to do so, resulting in redundant signalling. Another approach is for the correspondent node to inform the mobile Ng & Aso Expires May 15, 2008 [Page 4] Internet-Draft MIPv6 Optimization and Multihoming November 2007 node of all its addresses upon receiving the first signalling message from the mobile node. This may be any one of the Home Test Init, Care-of Test Init or Binding Update messages. Upon responding with the Home Test, Care-of Test or Binding Acknowledgement messages, the correspondent node may include the list of addresses it owns, so that the mobile node would know that it need not repeat the return routability procedure with these addresses. There are security threats that needs to be analyzed for the second approach. Two aspects of the threat analysis should be covered: o the threats on the mobile node This is generally the case where a malicious correspondent node sends back a list of fake addresses. The impact of this seems minimal at first glance, since the worst damage this would do is caused mobile node to wrongly assume that route optimization is established when it is in fact not. o the threats on the correspondent node This is generally the case where a malicious node initiate return routability procedure with a correspondent node, tricking it to revealing the list of addresses it owns. This does not seems to be a serious threat at first glance, since if the correspondent node does not wish its list of addresses to be known, it can always be configured to not return the list of addresses. 5. Conclusion This memo explores the use of multihoming and mobility protocols simultaneously, and investigates specifically if there are further enhancements that can be done in such situations. We had analyzed the case the correspondent node is multihomed, leaving the cases where the mobile node and mobility anchor are multihomed as future work in subsequent versions. 6. Informative Reference [1] Vogt, C. and J. Arkko, "A Taxonomy and Analysis of Enhancements to Mobile IPv6 Route Optimization", RFC 4651, February 2007. [2] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. Ng & Aso Expires May 15, 2008 [Page 5] Internet-Draft MIPv6 Optimization and Multihoming November 2007 [3] Abley, J., Black, B., and V. Gill, "Goals for IPv6 Site- Multihoming Architectures", RFC 3582, August 2003. [4] Bagnulo, M. and J. Abley, "Applicability Statement for the Level 3 Multihoming Shim Protocol (Shim6)", draft-ietf-shim6-applicability-03 (work in progress), July 2007. [5] Ernst, T., "Motivations and Scenarios for Using Multiple Interfaces and Global Addresses", draft-ietf-monami6-multihoming-motivation-scenario-02 (work in progress), July 2007. [6] Narayanan, V., Thaler, D., Bagnulo, M., and H. Soliman, "IP Mobility and Multi-homing Interactions and Architectural Considerations", draft-vidya-ip-mobility-multihoming-interactions-01 (work in progress), July 2007. [7] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V. Paxson, "Stream Control Transmission Protocol", RFC 2960, October 2000. [8] Bagnulo, M. and E. Nordmark, "Shim6: Level 3 Multihoming Shim Protocol for IPv6", draft-ietf-shim6-proto-09 (work in progress), November 2007. Appendix A. Change Log o draft-ng-mobopts-multihoming-00: * Initial version. Ng & Aso Expires May 15, 2008 [Page 6] Internet-Draft MIPv6 Optimization and Multihoming November 2007 Authors' Addresses 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 Keigo Aso Matsushita Electric Industrial Co. Ltd. (Panasonic) 5-3 Hikarino-oka Yokosuka, Kanagawa 239-0847 JP Phone: +81 46 840 5123 Email: asou.keigo@jp.panasonic.com Ng & Aso Expires May 15, 2008 [Page 7] Internet-Draft MIPv6 Optimization and Multihoming November 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Ng & Aso Expires May 15, 2008 [Page 8]