NETEXT Working Group V. Devarapalli Internet-Draft WiChorus Intended status: Standards Track N. Kant Expires: September 4, 2009 H. Lim Stoke C. Vogt Ericsson March 3, 2009 Multiple Interface Support with Proxy Mobile IPv6 draft-devarapalli-netext-multi-interface-support-00.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. This document may not be modified, and derivative works of it may not be created, except to format it for publication as an RFC or to translate it into languages other than English. 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 September 4, 2009. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights Devarapalli, et al. Expires September 4, 2009 [Page 1] Internet-Draft PMIPv6 Multiple Interface Support March 2009 and restrictions with respect to this document. 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. It also describes the requirements for a handover across interfaces using Proxy Mobile IPv6. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Multiple Interface Scenarios . . . . . . . . . . . . . . . . . 4 3.1. Unique Prefix per Interface . . . . . . . . . . . . . . . 4 3.2. Unique Address per Interface . . . . . . . . . . . . . . . 5 3.3. Shared Address across Interfaces . . . . . . . . . . . . . 6 4. Handovers across Interfaces . . . . . . . . . . . . . . . . . 8 4.1. Requirements for a PMIPv6 Handover across Interfaces . . . 8 4.1.1. Removal of IP Address/Prefix from Old Interface . . . 8 4.1.2. Configuration of Same IP Address/Prefix on New Interface . . . . . . . . . . . . . . . . . . . . . . 9 4.1.3. Update of Active Socket Structures . . . . . . . . . . 9 4.2. Handover across Interfaces using a PMIPv6 virtual interface . . . . . . . . . . . . . . . . . . . . . . . . 9 4.3. Inter-Access Technology Handovers . . . . . . . . . . . . 9 4.4. Mobile node with three or more interfaces . . . . . . . . 11 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 8.1. Normative References . . . . . . . . . . . . . . . . . . . 13 8.2. Informative References . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 Devarapalli, et al. Expires September 4, 2009 [Page 2] Internet-Draft PMIPv6 Multiple Interface Support March 2009 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 are some issues identified with supporting a host with multiple interfaces attaching to the Proxy Mobile IPv6 domain. The multiple interfaces on the mobile node could be of the same or different access technology types. If the mobile node has multiple interfaces attached to the Proxy Mobile IPv6 domain, and wishes to use both interfaces simultaneously, the LMA and the MAGs in the Proxy Mobile IPv6 domain must allow this. The mobile node may also decide to handoff sessions from one interface to another. The two interfaces involved in the handover could be of the same or different access technology types. In some cases, the mobile node may be assigned the same prefix across two interfaces when both interfaces are attached to the Proxy Mobile IPv6 domain. 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 and still able to send and receive packets on both interfaces. This document analyzes three different scenarios with respect to a mobile node with multiple interfaces attaching to a Proxy Mobile IPv6 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 address across interfaces. In all three scenarios the mobile node is able to use the multiple interfaces simultaneously to send and receive packets. This document also analyzes the requirements on a IPv6 host to support a handover across interfaces when Proxy Mobile IPv6 is used in Section 4.1. 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]. Devarapalli, et al. Expires September 4, 2009 [Page 3] Internet-Draft PMIPv6 Multiple Interface Support March 2009 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. 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 Binding Update 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 Devarapalli, et al. Expires September 4, 2009 [Page 4] Internet-Draft PMIPv6 Multiple Interface Support March 2009 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 Binding Update, 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 Handoff Indicator field in the Handoff Indicator option is set to. If MAG3 knows that the mobile node was attached to another MAG in the same Proxy Mobile IPv6 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. 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 Handoff Indicator field in the Handoff Indicator option to indicate a handover for if1. Section 4 discusses handovers between interfaces using Proxy Mobile IPv6 in more detail. 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 2 creates a multi- homing scenario where the mobile node has connectivity via two interfaces to the same subnet. Devarapalli, et al. Expires September 4, 2009 [Page 5] Internet-Draft PMIPv6 Multiple Interface Support March 2009 LMA Binding Cache +----+ ----------------- |LMA | MN:if1 [addr1] --> MAG1 +----+ MN:if2 [addr2] --> MAG2 //\\ +---------//--\\-------------+ ( // \\ ) PMIPv6 domain ( // \\ ) +------//--------\\----------+ // \\ // \\ +----+ +----+ |MAG1| |MAG2| +----+ +----+ | | | | | if1 if2 | +------[MN]------+ Figure 2: Unique Address per Interface 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 [5] 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 3 illustrates this scenario. Devarapalli, et al. Expires September 4, 2009 [Page 6] Internet-Draft PMIPv6 Multiple Interface Support March 2009 LMA State +----+ --------- |LMA | MN:if1 [addr, flow1] --> MAG1 +----+ MN:if2 [addr, flow2] --> MAG2 //\\ +---------//--\\-------------+ ( // \\ ) PMIPv6 domain ( // \\ ) +------//--------\\----------+ // \\ // \\ +----+ +----+ |MAG1| |MAG2| +----+ +----+ | | | | | if1 if2 | +------[MN]------+ Figure 3: 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 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 tunnels the packets to MAG1. For this scenario to work, the mobile node must be able to indicate to the attached MAG which flow will be sent over the attachment to the MAG. It may do this by indicating the service identifier during the layer 2 attachment to the MAG. The service identifier is described in [4]. The MAG, in turn must include the flow information in the Proxy Binding Update sent to the LMA. The MAG may use the Service Selection option [4] in the Proxy Binding Update to indicate the flow information. The MAG may also construct a flow filter and convey the information in the Proxy Binding Update. See [3] for more information on carrying flow filters in the proxy binding update. The LMA processes the Proxy Binding Update from the MAG and creates a filter based on the flow information. The flow filters may be stored in the binding cache entry for the mobile node. Devarapalli, et al. Expires September 4, 2009 [Page 7] Internet-Draft PMIPv6 Multiple Interface Support March 2009 4. Handovers across Interfaces The followings describe handovers across multiple interfaces on a mobile node using Proxy Mobile IPv6. 4.1. Requirements for a PMIPv6 Handover across Interfaces Using Proxy Mobile IPv6 for handovers across interfaces requires the following at the minimum on the mobile node. o Removal of the IP address/prefix from the old interface. o Configuration of the same IP address/prefix on the new interface. o Update of active socket structures to the new interface. The following describes the requirements for a handover across interface in more detail. 4.1.1. Removal of IP Address/Prefix from Old Interface An IP address can be removed from the old interface through a tear- down of the link-layer connection, provided the IP address was auto- configured. Standard host stack implementations remove auto- configured IP addresses from interfaces that have lost link-layer connectivity. The advantage of this mechanism is that it is network- controlled and does not require special host functionality. A disadvantage of the mechanism is its coarse granularity: A link-layer connectivity tear-down leads to the removal of all IP addresses on an interface. So if an interface has multiple IP addresses, all of them are removed, yet a handover may be desired for only one of them. Link-layer connectivity tear-down is the only means by which a network can control the removal of an IP address from an old interface. Standard host stack implementations generally do not accept IP layer control messages as a trigger for IP address removal. For example, zero-lifetime advertisements for an IP address prefix in Router Advertisement messages [6] are ignored in an effort to protect against denial-of-service attacks. Alternative mechanisms to remove an IP address from the old interface therefore require new functionality on mobile nodes. The handover may be indicated by the network, such as through a zero-lifetime advertisement for an IP address prefix in Router Advertisement messages. But it is the mobile node which must correctly interpret such indication and remove the corresponding IP address. Devarapalli, et al. Expires September 4, 2009 [Page 8] Internet-Draft PMIPv6 Multiple Interface Support March 2009 4.1.2. Configuration of Same IP Address/Prefix on New Interface A successful handover across interfaces requires a mobile node to configure the new interface with the same IP address that was previously used on the old interface. The standard mechanism for autonomous address auto-configuration in IPv6, Stateless Address Autoconfiguration [7], does not support this. It derives IP addresses from the respective interface identifiers, and thus generates different IP addresses on different interfaces. Configuration of the same IP address on a new interface therefore requires either network-controlled IP address configuration through DHCPv6, L2 address assignment mechanisms or new functionality on the mobile nodes. 4.1.3. Update of Active Socket Structures Typically, sockets structures are opened based on the address assigned to an interface. As long as the address is available on one of the interfaces on the mobile node, the active sockets should not get affected. However, many implementations today include a pointer to the interface in socket structures. This makes handovers between different interfaces impossible. Handovers across interfaces may therefore require modifications to such implementations to make socket structures interface-independent. 4.2. Handover across Interfaces using a PMIPv6 virtual interface The mobile node may also implement a virtual interface that hides the multiple physical interfaces involved in the handover. The address that the mobile node configures, when it is attached to the Proxy Mobile IPv6 domain, is assigned to the virtual interface. Only the virtual interface and the address configured on the virtual interface are visible to the applications on the mobile node. If only one interface is active at a time, then the mobile node maps the virtual interface to the active physical interface. When a handover happens, the mobile node maps the virtual interface to the new active physical interface. The implementation of this virtual interface can be done in a manner similar to the Linux Port Bonding [8]. The actual implementation details are out of scope of this document. 4.3. 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. Devarapalli, et al. Expires September 4, 2009 [Page 9] Internet-Draft PMIPv6 Multiple Interface Support March 2009 The mobile node is initially attached to the Proxy Mobile IPv6 domain via MAG1 using if1 as show in Figure 4. LMA Binding Cache +----+ ----------------- |LMA | MN:if1 [prefix1] --> MAG1 +----+ //\\ +---------//--\\-------------+ ( // \\ ) PMIPv6 domain ( // \\ ) +------//--------\\----------+ // \\ // \\ +----+ +----+ |MAG1| |MAG2| +----+ +----+ | | | if1 if2 +------[MN]------ Figure 4: Mobile Node attached via if1 The mobile node moves and attaches to the same Proxy Mobile IPv6 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 5. Devarapalli, et al. Expires September 4, 2009 [Page 10] Internet-Draft PMIPv6 Multiple Interface Support March 2009 LMA Binding Cache +----+ ----------------- |LMA | MN:if2 [prefix1] --> MAG2 +----+ //\\ +---------//--\\-------------+ ( // \\ ) PMIPv6 domain ( // \\ ) +------//--------\\----------+ // \\ // \\ +----+ +----+ |MAG1| |MAG2| +----+ +----+ | | if1 if2 | ------[MN]------+ Figure 5: 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 Binding Update from MAG2 will have a different identifier from what is stored in the binding cache entry on the LMA. So this might appear to the LMA as if the mobile node is attaching via a different interface. The Proxy Binding Update from MAG2 MUST have the Handoff Indicator field in the Handoff Indicator 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 Binding Update 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. The mobile node should satisfy the requirements listed in Section 4.1 for the handover to work. 4.4. 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 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 Devarapalli, et al. Expires September 4, 2009 [Page 11] Internet-Draft PMIPv6 Multiple Interface Support March 2009 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 Binding Update information about if1 or the prefix assigned to if1 in the Proxy Binding Update 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 Binding Update. Yet another handover scenario is where the mobile is attached to MAG1 via if1 and MAG2 via if2, decides to attach to MAG2 via if3 and perform a handover from the if1 to if3. In this scenario, the mobile node must indicate to MAG2 that it is performing a handover from if1 by providing information about if1 when attaching to MAG2 using if3. MAG2 would then treat the attachment over if3 as a handover from if1 and will indicate this in this Proxy Binding Update to the LMA. The LMA would then assign the same prefix that was previously assigned for if1. MAG would further treat existing attachment over if2 separately and cause no modifications to the sessions over if2. 5. 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]. 6. IANA Considerations This document does not request any assignments from IANA. 7. Acknowledgements Many of the issues related to using Proxy Mobile IPv6 with a mobile node with multiple interfaces were discussed on the NETLMM mailing list. This document tries to capture those issues. Therefore the authors would like to thank all the folks involved in those discussions. The authors would also like to think Sri Gundavelli, Kuntal Chowdhury, Basavaraj Patil, Vidya Narayanan, and George Tsirtsis for some interesting discussions in this space. Devarapalli, et al. Expires September 4, 2009 [Page 12] Internet-Draft PMIPv6 Multiple Interface Support March 2009 8. References 8.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", RFC 5213, August 2008. [3] Soliman, H., Montavont, N., Fikouras, N., and K. Kuladinithi, "Flow Bindings in Mobile IPv6 and Nemo Basic Support", draft-ietf-mext-flow-binding-00 (work in progress), May 2008. 8.2. Informative References [4] Korhonen, J., Nilsson, U., and V. Devarapalli, "Service Selection for Mobile IPv6", RFC 5149, February 2008. [5] Thaler, D., "Multi-Link Subnet Issues", RFC 4903, June 2007. [6] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007. [7] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, September 2007. [8] "Linux Port Bonding", http://linux-ip.net/html/ether-bonding.html . Authors' Addresses Vijay Devarapalli WiChorus 3950 North First Street San Jose, CA 95134 USA Email: vijay@wichorus.com Devarapalli, et al. Expires September 4, 2009 [Page 13] Internet-Draft PMIPv6 Multiple Interface Support March 2009 Nishi Kant Stoke 5403 Betsy Ross Drive Santa Clara, CA 95054 USA Email: nishi@stoke.com Heeseon Lim Stoke 5403 Betsy Ross Drve Santa Clara, CA 95054 USA Email: hlim@stoke.com Christian Vogt Ericsson Research, NomadicLab Hirsalantie 11 02420 Jorvas Finland Email: christian.vogt@ericsson.com Devarapalli, et al. Expires September 4, 2009 [Page 14]