NETLMM Working Group V. Devarapalli Internet-Draft N. Kant Intended status: Standards Track H. Lim Expires: May 14, 2008 Azaire Networks November 11, 2007 Multiple Interface Support with Proxy Mobile IPv6 draft-devarapalli-netlmm-multihoming-00.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 May 14, 2008. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract Proxy Mobile IPv6 enables network-based mobility for a regular IPv6 mobile node with no mobility management protocol. It makes it appear to the mobile node that its IP address does not change as the mobile node moves across the Proxy Mobile IPv6 domain. There have been some issues identified with supporting a host with multiple interfaces attaching to the Proxy Mobile IPv6 domain. This document describes and analyzes some of the scenarios associated with this. Devarapalli, et al. Expires May 14, 2008 [Page 1] Internet-Draft PMIPv6 Multihoming November 2007 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Multiple Interface Scenarios . . . . . . . . . . . . . . . . . 3 3.1. Unique Prefix per Interface . . . . . . . . . . . . . . . 3 3.1.1. Inter-Access Technology Handovers . . . . . . . . . . 5 3.1.2. Mobile node with three or more interfaces . . . . . . 6 3.2. Unique Address per Interface . . . . . . . . . . . . . . . 7 3.3. Shared Address across Interfaces . . . . . . . . . . . . . 8 4. Security Considerations . . . . . . . . . . . . . . . . . . . 9 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 6.1. Normative References . . . . . . . . . . . . . . . . . . . 9 6.2. Informative References . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 Intellectual Property and Copyright Statements . . . . . . . . . . 11 Devarapalli, et al. Expires May 14, 2008 [Page 2] Internet-Draft PMIPv6 Multihoming November 2007 1. Introduction Proxy Mobile IPv6 [2] provides network-based mobility for a regular IPv6 mobile node with no mobility management protocol. It is quite straight forward to provide mobility for a mobile node with one interface. There have been some issues identified with supporting a host with multiple interfaces attaching to the Proxy Mobile IPv6 domain. The multiple interfaces could be of the same or different access technology types. The mobile node may handoff sessions from one interface to another. The mobile node may be a regular IPv6 host which cannot handle the same prefix across two different interfaces. Some mobile nodes have multi-homing support in the sense that they can connect to the same subnet via two interfaces. This document analyzes three different scenarios with respect to a mobile node with multiple interfaces attaching to a PMIPv6 domain. o Assigning a unique prefix per interface of the mobile node. o Assigning the same prefix across interfaces but a unique address per interface. o Shared one address across interfaces. In all three scenarios the mobile node is able to use the multiple interfaces simultaneously to send and receive packets. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [1]. 3. Multiple Interface Scenarios Three different scenarios are considered in this document. The following sections describe and analyze the three scenarios. 3.1. Unique Prefix per Interface In this scenario, each interface on the mobile node is assigned a unique prefix. The LMA maintains multiple binding cache entries, one entry per interface on the mobile node. The binding cache entries may contain the Layer 2 interface identifier and the access technology type of the corresponding interface on the mobile node. The LMA also maintains two separate routes for prefix1 and prefix2. Devarapalli, et al. Expires May 14, 2008 [Page 3] Internet-Draft PMIPv6 Multihoming November 2007 LMA Binding Cache +----+ ----------------- |LMA | MN:if1 [prefix1] --> MAG1 +----+ MN:if2 [prefix2] --> MAG2 //\\ +---------//--\\-------------+ ( // \\ ) PMIPv6 domain ( // \\ ) +------//--------\\----------+ // \\ // \\ +----+ +----+ |MAG1| |MAG2| +----+ +----+ | | | | | if1 if2 | +------[MN]------+ Figure 1: Unique Prefix per Interface The mobile node is able to use both interfaces simultaneously for sending and receiving packets. Since the LMA maintains separate route entries for prefix1 and prefix2, it encapsulates and forwards the packets via the appropriate MAG. When the mobile node moves and attaches to another MAG in the same Proxy Mobile IPv6 domain, session continuity is maintained by assigning the same prefix to the interface. If the mobile node moves and attaches to MAG3 with if1, the MAG3 sends a Proxy BU message to the LMA with the access technology type and interface identifier of if1. The LMA checks if there is an existing binding cache entry for the mobile node for if1. If there is an existing binding cache entry, the LMA assigns the same prefix previously assigned and responds to MAG3. If there is no L2 interface identifier that MAG3 could identify for if1 and did not include the interface identifier in the proxy BU, then the LMA does not know if this is a handover for if1 or if the mobile node is attaching via a new interface to MAG3. The LMA's decision is then based on what the Handover Indication field in the Access Technology Type option is set to. If MAG3 knows that the mobile node was attached to another MAG in the same PMIPv6 domain using if1, then it must indicate to the LMA that it is a handover. This would ensure that the mobile node sees the same prefix for if1. Otherwise the mobile node ends up with a new prefix for if1. Devarapalli, et al. Expires May 14, 2008 [Page 4] Internet-Draft PMIPv6 Multihoming November 2007 The Proxy Mobile IPv6 specification [2] does not specify any mechanism for MAG3 to figure out if the mobile node is performing a handover for if1 or if it is attaching to the Proxy Mobile IPv6 domain for the first time via if1. One option is for MAG3 to obtain this information via context transfer from MAG1. This solution requires a context transfer interface between MAG1 and MAG3. Another option is for MAG3 to be told by the AAA infrastructure as part of access authentication that the mobile node was previously attached to the Proxy Mobile IPv6 domain via if1. However, this solution may not work in case the AAA infrastructure does not store interface related information or if the AAA infrastructure is not being used. One solution that may work in most cases is for the mobile node to indicate to MAG3 that it already has sessions on top of the prefix assigned to if1 and it is performing a handover. The mobile node conveys this information as part of Layer 2 setup. When MAG3 gets this information, it sets the Handover Indication field in the Access Technology Type option to indicate a handover for if1. 3.1.1. Inter-Access Technology Handovers This section considers a handover scenario where the mobile node performs a handover between interfaces that belong to different access technologies. The mobile node is initially attached to the PMIPv6 domain via MAG1 using if1 as show in Figure 2. LMA Binding Cache +----+ ----------------- |LMA | MN:if1 [prefix1] --> MAG1 +----+ //\\ +---------//--\\-------------+ ( // \\ ) PMIPv6 domain ( // \\ ) +------//--------\\----------+ // \\ // \\ +----+ +----+ |MAG1| |MAG2| +----+ +----+ | | | if1 if2 +------[MN]------ Figure 2: Mobile Node attached via if1 Devarapalli, et al. Expires May 14, 2008 [Page 5] Internet-Draft PMIPv6 Multihoming November 2007 The mobile node moves and attaches to the same PMIPv6 domain via MAG2 using if2. The mobile node may not have connectivity on if1 anymore. The LMA assigns the same prefix for if2 and updates its binding cache entry. This is illustrated in Figure 3. LMA Binding Cache +----+ ----------------- |LMA | MN:if2 [prefix1] --> MAG2 +----+ //\\ +---------//--\\-------------+ ( // \\ ) PMIPv6 domain ( // \\ ) +------//--------\\----------+ // \\ // \\ +----+ +----+ |MAG1| |MAG2| +----+ +----+ | | if1 if2 | ------[MN]------+ Figure 3: Mobile Node Performs Handover to if2 For the above inter-access technology handover to work, the LMA must know that this is a handover involving two different interfaces of the mobile node. The Interface Identifier option if present in the proxy BU from MAG2 will have a different identifier from what is stored in the binding cache entry on the LMA. The Proxy BU from MAG2 must have the Handover Indication field in the Access Technology Type option set to "2" or "3" to indicate that it is a handover. See Section 3.1 for a detailed description of how MAG2 determines when to indicate in the Proxy BU that it is a handover. The mobile node must also be able to move the prefix from if1 to if2 during the handover for the inter-access technology handover to work. A regular IPv6 mobile node, with no multi-homing support, may get confused if it sees the same prefix over two different interfaces. 3.1.2. Mobile node with three or more interfaces This section considers a handover scenario for a mobile node with three or more interfaces and performing a handover from if1 to if3 while staying connected over if2. It is assumed that the mobile node is attached to MAG1 using if1, MAG2 using if2 and MAG3 using if3. In Devarapalli, et al. Expires May 14, 2008 [Page 6] Internet-Draft PMIPv6 Multihoming November 2007 this scenario, even if MAG3 knows that it is a handover, it does not which two interfaces are involved in the handover. The AAA infrastructure does not help here since the AAA does not know which interface is being handed off to which one. The only possible solution here is for the mobile node to tell MAG3 more information about if1 or the home network prefix assigned to if1 or information about MAG1. MAG3 may indicate in the proxy BU information about if1 or the prefix assigned to if1 in the proxy BU sent to the LMA. The LMA uses this information to assign the prefix that was assigned to if1 to if3 also. In case the mobile node provides information about MAG1, then MAG3 can contact MAG1 over a context transfer interface and obtain more information about if1 or the home network prefix assigned to if1. In all cases, MAG3 indicates that it is a handover in the proxy BU. 3.2. Unique Address per Interface In this scenario, the mobile node is assigned the same prefix across multiple interfaces, but with a unique address per interface. The LMA maintains separate binding cache entries per address of the mobile node. The LMA may also maintain a single binding cache entry, but must have separate host route entries per address assigned to the mobile node. This scenario illustrated in Figure 4 creates a multi- homing scenario where the mobile node has connectivity via two interfaces to the same subnet. LMA Binding Cache +----+ ----------------- |LMA | MN:if1 [addr1] --> MAG1 +----+ MN:if2 [addr2] --> MAG2 //\\ +---------//--\\-------------+ ( // \\ ) PMIPv6 domain ( // \\ ) +------//--------\\----------+ // \\ // \\ +----+ +----+ |MAG1| |MAG2| +----+ +----+ | | | | | if1 if2 | +------[MN]------+ Figure 4: Unique Address per Interface Devarapalli, et al. Expires May 14, 2008 [Page 7] Internet-Draft PMIPv6 Multihoming November 2007 The mobile node is able to use both interfaces simultaneously for sending and receiving packets. Since the LMA maintains separate host route entries for addr1 and addr2, it encapsulates and forwards the packets via the appropriate MAG. This scenario however creates a multi-link subnet since the same prefix is advertised over two different point-to-point links. Neighbor discovery is not run across the two point-to-point links even though the same prefix is used across the links. Please refer to [4] for more information on issues regarding multi-link subnets. 3.3. Shared Address across Interfaces In this scenario, the mobile node is assigned the same address across multiple interfaces. This scenario enables a mobile node to use different links, but make only one IP address visible to the applications. The mobile node can send and receive packets for one particular application flow over if1 and for another application flow over if2. This scenario also enables a mobile node to combine two low bandwidth links into a high bandwidth link. Figure 5 illustrates this scenario. LMA State +----+ --------- |LMA | MN:if1 [addr1, flow1] --> MAG1 +----+ MN:if2 [addr2, flow2] --> MAG2 //\\ +---------//--\\-------------+ ( // \\ ) PMIPv6 domain ( // \\ ) +------//--------\\----------+ // \\ // \\ +----+ +----+ |MAG1| |MAG2| +----+ +----+ | | | | | if1 if2 | +------[MN]------+ Figure 5: Shared Address across Interfaces The LMA maintains only one binding cache entry per mobile node in this scenario. However, the LMA maintains flow filters that indicate routing to a particular MAG. For example, lets assume that the mobile node has two separate flows, flow1 and flow2 and wants to run Devarapalli, et al. Expires May 14, 2008 [Page 8] Internet-Draft PMIPv6 Multihoming November 2007 flow1 over if1 and flow2 over if2. When the LMA receives a packet for the mobile node, it checks the flow filters stored in the binding cache entry. If the packets match filter1, the LMA knows that the packets must be tunneled to MAG1. For this scenario to work, the mobile node must be able to indicate to the attached MAG which flows are being bound to a particular MAG. The MAG, in turn must include the flow information in the proxy BU sent to the LMA. The LMA processes this Proxy BU and creates a filter based on the flow information. The flow filters may be stored in the binding cache entry for the mobile node. See [3] for more information on carrying flow filters in the proxy binding update. More description TBD. 4. Security Considerations This document mainly analyzes some of the scenarios arising out of a mobile node with multiple interfaces attaching to a Proxy Mobile IPv6 domain. It does not introduce any new security concerns on top of what is described in the Security Considerations section of [2]. 5. IANA Considerations This document does not request any assignments from IANA. 6. References 6.1. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", draft-ietf-netlmm-proxymip6-05 (work in progress), September 2007. [3] Soliman, H., "Flow Bindings in Mobile IPv6 and Nemo Basic Support", draft-soliman-monami6-flow-binding-04 (work in progress), March 2007. 6.2. Informative References [4] Thaler, D., "Multilink Subnet Issues", draft-iab-multilink-subnet-issues-03 (work in progress), Devarapalli, et al. Expires May 14, 2008 [Page 9] Internet-Draft PMIPv6 Multihoming November 2007 January 2007. Authors' Addresses Vijay Devarapalli Azaire Networks 4800 Great America Pkwy Santa Clara, CA 95054 USA Email: vijay.devarapalli@azairenet.com Nishi Kant Azaire Networks 4800 Great America Pkwy Santa Clara, CA 95054 USA Email: nishi.kant@azairenet.com Heeseon Lim Azaire Networks 4800 Great America Pkwy Santa Clara, CA 95054 USA Email: heeseon.lim@azairenet.com Devarapalli, et al. Expires May 14, 2008 [Page 10] Internet-Draft PMIPv6 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). Devarapalli, et al. Expires May 14, 2008 [Page 11]