Network Working Group M. Bagnulo Internet-Draft UC3M Expires: January 12, 2006 E. Nordmark Sun Microsystems July 11, 2005 SHIM - MIPv6 Interaction draft-bagnulo-shim6-mip-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 January 12, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract In this note, we explore the interaction between the SHIM protocol and MIPv6 protocol, identifying potential benefits and difficulties. The analysis will consider the two modes of operation of MIPv6: the Bidirectional Tunnel (BT) mode where the communication is routed through the Home Agent and the Route Optimization (RO) mode, where the communication flows directly between the Correspondent node and the mobile node. Bagnulo & Nordmark Expires January 12, 2006 [Page 1] Internet-Draft SHIM & MIP July 2005 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Bidirectional Tunnel (BT) Mode . . . . . . . . . . . . . . . . 4 2.1 Communication between the MN and the CN . . . . . . . . . 4 3. RO mode . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Security considerations . . . . . . . . . . . . . . . . . . . 7 5. Normative References . . . . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 7 Intellectual Property and Copyright Statements . . . . . . . . 8 Bagnulo & Nordmark Expires January 12, 2006 [Page 2] Internet-Draft SHIM & MIP July 2005 1. Introduction SHIM [1] is a host-based mechanism to provide site-multihoming support. In this note, we explore the interaction between the SHIM protocol and MIPv6 protocol, identifying potential benefits and difficulties. The analysis contained in this document considers the most general case of shim and MIPv6 interaction, where the mobile node has both multiple Care-of-Addresses as well as multiple Home Addresses. The MN can have multiple addresses for any number of reasons. For example, the MN can have multiple CoAs due to the MN having multiple interfaces (connecting to different providers), or the MN visiting a link which has multiple address prefixes due to the visited site being multihomed. Also, the MN can have multiple HoAs for different reasons, including having a home link which has multiple address prefixes due to being in a multihomed site, to having multiple, independent Home Agents that each provide it with a Home Address. Without loss of generality the analysis uses a single IP address for the correspondent node. The analysis will consider the two modes of operation of MIPv6: the Bidirectional Tunnel (BT) mode where the communication is routed through the Home Agent and the Route Optimization (RO) mode, where the communication flows directly between the Correspondent Node and the Mobile Node. Bagnulo & Nordmark Expires January 12, 2006 [Page 3] Internet-Draft SHIM & MIP July 2005 2. Bidirectional Tunnel (BT) Mode 2.1 Communication between the MN and the CN In this case, we have a MN with multiple CoAs (CoA1,..., CoAj) and multiple HoAs (HoA1,..., HoAm) communicating with a Cn with address IPCN. We assume that the SHIM is layered above MIPv6. In this scenario, suppose that an application located above the SHIM layer, establishes a communication using one of the available HoAs, e.g. HoAl and the address of the CN, IPCN, as ULIDs. Because the SHIM is located above MIPv6, packets will be tunneled through the HA, i.e. packets will be encapsulated with an additional header that will contain IPHA and CoAj as addresses. At some point during the lifetime of the communication, a SHIM context is established. Such context will contain: o HoAl and IPCN as ULIDs o HoA1,..., HoAm, as locator set for the MN. (Optionally, the MN could choose not to provide the CoAs to the CN in the shim6 signaling.) o IPCN as locator set for the CN We will next consider the response in case of an outage: Suppose that an outage occurs and the communication path becomes unavailable. If there is an outage affecting the path between the CN and the MN, then the SHIM layer will detect it, and will retry with an alternative locator. When an alternative HoA is used as alternative locator, packets will be tunneled through the HA associated with the new HoA, and will be received through the CoA associated with the new HoA. In case that there is at least one HA and one CoA that are not affected by the outage, the communication will be preserved. In this case, the communication will still flow in BT mode, but it will be routed through an alternative tunnel associated with the new HoA. If an alternative CoA is used as alternative locator, then the communication will run directly between the MN and the CN in a kind of SHIM based RO mode, recovering from the outage. However, in this case, care must be taken because the alternative CoA may become unavailable after movement. Bagnulo & Nordmark Expires January 12, 2006 [Page 4] Internet-Draft SHIM & MIP July 2005 3. RO mode We assume that the SHIM is layered above MIPv6. In this case, we have a MN with multiple CoAs (CoA1,..., CoAj) and multiple HoAs (HoA1,..., HoAm) communicating with a CN with address IPCN. Suppose that a communication is established between the MN and the CN using HoAl and IPCN. In addition, through MIPv6 protocol, a Binding Cache Entry (BCE) is created in the CN associating the HoAl with one of the CoAs, CoAp. So, packets associated with the communication are flowing directly between the CN and the MN carrying CoAp and IPCN in the source and destination address fields. Later on, at some point in time, a SHIM context is established between the MN and the CN. In this case the SHIM context established contain the following information: o ULIDs: HoAl and IPCN o Locator set for MN: HoA1,...,HoAm, CoA1,..., CoAj. (Optionally, the MN could choose not to provide the CoAs to the CN in the shim6 signaling.) o IPCN as locator set for the CN We will next analyze how this configuration reacts to different failure modes: o The path between IPCN and CoAp fails. The SHIM will detect the outage and will try with alternative locators available for the ULIDs of the session. If an alternative HoA is used by the SHIM as alternative locator, when the SHIM passes the packet with an alternative HoA to the MIP layer, the MIP layer will route through the corresponding CoA available in the BCE associated with the new HoA, possibly falling back to BT mode but potentially recovering the failure. If an alternative CoA is used by the SHIM as alternative locator, the MIP layer wonOt affect the packet carrying the alternative CoA, and packets will be routed directly between the MN and the CN, in a kind of SHIM-based RO mode. o The path between the MN and the CN through the HA fails. While data traffic is not routed through the HA, HoTI/HoT packets are exchanged through the HA. If the path between the MN and the CN through the Ha fails, then HoTI/HoT exchange will fail. A few minutes later, the corresponding BCE will expire, and the communication will fallback to the BT mode through the HA. Bagnulo & Nordmark Expires January 12, 2006 [Page 5] Internet-Draft SHIM & MIP July 2005 However, because we are considering the case where the path through the HA is down, the communication will fail. At this point, the SHIM will detect the outage and use an alternative locator pair. Analogously to the previous case, the SHIM can try with an alternative CoA or an alternative HoA as alternative locators for the communication. In any case, similar considerations to the ones described above apply and the communications will be restored, whether in BT mode (alternative HoA) or in a SHIM-based RO mode (alternative CoA used). In any case, the presented setup seems to allow the preservation of the established communication through different failure modes. It should be noted, that if CoAs are included as alternative locators for the SHIM, those will be short lived locators, and they may become unavailable sooner than the HoAs. Bagnulo & Nordmark Expires January 12, 2006 [Page 6] Internet-Draft SHIM & MIP July 2005 4. Security considerations TBD 5. Normative References [1] Nordmark, E. and M. Bagnulo, "Multihoming L3 Shim Approach", draft-ietf-shim6-l3shim-00 (work in progress), October 2004. Authors' Addresses Marcelo Bagnulo Universidad Carlos III de Madrid Av. Universidad 30 Leganes, Madrid 28911 SPAIN Phone: 34 91 6249500 Email: marcelo@it.uc3m.es URI: http://www.it.uc3m.es Erik Normark Sun Microsystems, Inc. 17 Network Circle Mountain View, CA USA Phone: +1 650 786 2921 Email: erik.nordmark@sun.com Bagnulo & Nordmark Expires January 12, 2006 [Page 7] Internet-Draft SHIM & MIP July 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. Bagnulo & Nordmark Expires January 12, 2006 [Page 8]