NETLMM Working Group A. Muhanna Internet-Draft M. Khalil Intended status: Standards Track Nortel Networks Expires: May 14, 2008 November 11, 2007 Proxy MIPv6 support for Mobile Nodes with Multihoming draft-muhanna-netlmm-multihoming-support-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 is a network-based mobility protocol which provides IP mobility for a regular IPv6 mobile node without the involvement of the IPv6 host. Whenever a mobile node is attached to a PMIPv6 domain via a mobility access gateway, MAG, it appears to the mobile node as if it is attached to the same home link and thus the mobile node may think that it is not roaming away from home. An issue has been raised with respect to the base PMIPv6 protocol support of a mobile node with multiple physical interfaces. This issue has been Muhanna & Khalil Expires May 14, 2008 [Page 1] Internet-Draft PMIPv6 Support for Multihoming November 2007 referenced as PMIPv6 support for multihoming mobile node. This document describes the multihoming issue as it relates to PMIPv6 and provides an analysis to all scenarios that have been identified thus far. Table of Contents 1. Conventions used in this document . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Multihoming Scenarios . . . . . . . . . . . . . . . . . . . . 4 3.1. Multihoming with a Single Prefix Per Interface . . . . . . 4 3.1.1. Inter-MAG Context Transfer Use . . . . . . . . . . . . 6 3.1.2. Helping AAA Infrastructure Use . . . . . . . . . . . . 6 3.1.3. MN-MAG Interaction via Access Network or L2 Interface . . . . . . . . . . . . . . . . . . . . . . 7 3.2. Multihoming with Single IP Address per Interface . . . . . 7 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 7.1. Normative References . . . . . . . . . . . . . . . . . . . 9 7.2. Informative References . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 Intellectual Property and Copyright Statements . . . . . . . . . . 11 Muhanna & Khalil Expires May 14, 2008 [Page 2] Internet-Draft PMIPv6 Support for Multihoming November 2007 1. Conventions used in this document The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [1]. All the general mobility terminologies and abbreviations are to be interpreted as defined in IPv6 Mobility Support specification [RFC- 3775] and Proxy Mobile IPv6 [PMIP6-Base]. 2. Introduction Proxy Mobile IPv6 [PMIP6-Base] is a network-based mobility protocol which provides IP mobility for a regular IPv6 mobile node without the involvement of the IPv6 host. When the IPv6 host has a multiple interfaces which are connected simultaneoulsy, then the base PMIPv6 protocol may not be able to offer mobility to such a mobile node host. However, in the case that the mobile node has multiple interfaces where the mobile node does not require simultatneous binding over these multiple interfaces, then PMIPv6 base protocol should handle this case in a straight forward fashion. In other words, in case of inter-technology handoff and when the mobile node have two different interfaces to access different technologies while the mobile node have use the simultaneous binding only in the case of inter-technology handoff, PMIPv6 base protocol may handle this case quite straight forward without. However, PMIPv6 base protocol does not specify the mechanism of how the MAG acquire the needed information for enabling PMIPv6 support for multihoming as per its general case scenario. On the other hand, when the IPv6 host use multiple physical interfaces to simultaneously attach to the same PMIPv6 domain, base PMIPv6 protocol need further development to address such case and scenario. These interfaces could be of the same or different types of accesses. It is also possible that the mobile node may handoff between different interfaces of the same access type or different accesses. In the case when a mobile node is not capable of handling the same prefix across multiple interfaces, this document provides the analysis of how PMIPv6 based protocol will enable mobility for such a case. The following two scenarios have been identified and to some extent discussed on the netlmm mailing list where the mobile node is required to use all of its available interfaces simultaneously to attach to the same PMIPv6 domain. Muhanna & Khalil Expires May 14, 2008 [Page 3] Internet-Draft PMIPv6 Support for Multihoming November 2007 o Multihoming with a single prefix per interface. o Multihoming with single IP address per interface. 3. Multihoming Scenarios Two multihoming scenarios have been identified as described in the introduction section. This document provides an analysis of these scenarios as per the following sections. In all of these scenarios and in addition to the regular PMIPv6 base protocol required information, more information specific to the interface ID, access technology type, and the handoff indication is necessary in order for PMIPv6 protocol to offer IP mobility support to a mobile node with multihoming. In PMIPv6 domain, there are several means for the MAG to acquire these extra information as listed below: o Availability of Inter-MAG Context Transfer. o Use of Available AAA Infrastructure. o Direct MN-MAG Interaction via Access Network or L2 Interface. Under each of the multihoming scenarios, this analysis will provide how the MAG may be able to use each of the above resources to enable PMIPv6 multihoming support as explained and discussed in the sections below. 3.1. Multihoming with a Single Prefix Per Interface In this case, every single interface of the IPv6 mobile node is assigned a specific IPv6 prefix as shown below in Figure 1. In the case the LMA does not receive any extra information in the P-BU to inform the LMA with the interface ID, the access type, or the handoff indicator, the LMA default behavior is to assign a new IPv6 prefix for each P-BU received for the same MN-ID but from a different MAG. Muhanna & Khalil Expires May 14, 2008 [Page 4] Internet-Draft PMIPv6 Support for Multihoming November 2007 LMA Binding Cache ================= MN1-if1 [prefix1] --> MAG1 MN1-if2 [prefix2] --> MAG2 MN2-if3 [prefix3] --> MAG1 MN2-if4 [prefix4] --> MAG2 if3 +------+ +------------->| | +------+ | if1 | MAG1 |\ +=================+ | | | +------->| | \ / \ | | | | +------+ \ / IPv6/IPv4 Transport \ | L | [MN-2] [MN-1] +--+ ...... +--| M | | | if2 +------+ / \ IPv6/IPv4 Transport / | A | | +------->| | / \ / | | | if4 | MAG2 | / +=================+ | | +------------->| |/ | | +------+ +------+ |<---------------- PMIPv6 Domain ---------------->| Figure 1: PMIPv6 Multihoming Support: A single prefix per interface. In the case when the Mobile node is able to attach simultaneously to separate MAGs using different interfaces as per figure 1, LMA will assign a separate prefix per interface. LMA is able to route each prefix's traffic after encapsulation to the corresponding MAG which the MN is attached to using the proper interface. If a mobile node, e.g. MN2, attaches to adifferent MAG, e.g. MAG2 using interface if4 after it has been attached to MAG1 via if3, LMA will assign prefix4 to MN2 binding and points the binding to MAG2. When MN2 decides to move and attaches to a different MAG which belongs to the same PMIPv6 domain as per figure 1, e.g. MAG3 using interface if4, MAG3 includes if4 in the P-BU message. When the LMA receives the P-BU from MAG3, LMA is able to identify that the MN is handing off over interface if4 to MAG3 and will assign the same prefix4 to maintain session continuity. In case the interface ID is not available to MAG3, MAG3 Must be able to set the handoff indication field in the Access Technology Type option to a value which indicates active handoff. If LMA has only one binding cache entry for the same mobile node ID, then the LMA would be able to allocate the same prefix and maintain session continuity. Muhanna & Khalil Expires May 14, 2008 [Page 5] Internet-Draft PMIPv6 Support for Multihoming November 2007 3.1.1. Inter-MAG Context Transfer Use In the case inter-MAG context transfer is available to the target MAG, the target MAG must receive the interface ID which is the mobile node is handing over. In this case, both the access technology type and the handoff indication will be available to the target MAG. If the above mentioned information is available to the target MAG during the multihomed mobile node inter-MAG context transfer, the target MAG will be able to provide the interface ID, the access technology type, and be able to correctly set the handoff indication in the Access Technology Type option. When the target MAG sends a P-BU with these information, LMA will always be able to definitely identify the mobile node binding cache entry which belongs to the P-BU received from the target MAG. 3.1.2. Helping AAA Infrastructure Use The helping AAA infrastructure can be used to enable PMIPv6 support of multihoming according to the following conditions: o During Inter MAG handoff, mobile node will perform access authentication using AAA infrastructure. o If the MN is performing access authentication during an inter-MAG handoff, the MN SHOULD provide the AAA infrastructure (AAA server) with the interface ID that the mobile node is handing off from, i.e. the previous interface ID. o If the MN is performing access authentication during an inter-MAG handoff, the MN SHOULD provide the AAA infrastructure (AAA server) with the interface ID that the mobile node is handing off from, i.e. the previous interface ID and in the case that the MN is handing over to a different interface ID, the mobile node SHOULD provide the AAA infrastructure with the target interface ID. o During Access authentication, the target MAG SHOULD be able to receive the previous and the target interface ID during the mobile node access authentication or by requesting them directly from the AAA infrastructure. o In the case that the target interface ID is different than the previous interface ID, the target MAG MUST include both the target and previous interface IDs in the P-BU in order for the LMA to be able to identify the exact MN binding cache entry. Muhanna & Khalil Expires May 14, 2008 [Page 6] Internet-Draft PMIPv6 Support for Multihoming November 2007 3.1.3. MN-MAG Interaction via Access Network or L2 Interface In the case that neither inter-MAG context transfer is available nor the help of the AAA infrastructure during access authentication, a direct communication between the MN and the MAG is required in order to enable the PMIPv6 multihoming support. In this case the MN MUST be able to communicate interface and handoff information to access network during mobile node handoff. The following information need to be communicated from the MN to the MAG via access network or L2 interface signaling. o During Inter MAG handoff, the target MAG MUST be able to receive the mobile node target interface ID from the mobile node, e.g. via access network. o In the case that the target interface ID is different from the previous interface ID during Inter-MAG handoff, the MAG MUST be able to receive both the target and previous interface IDs. o The MAG should be able to receive a handoff indication and the access technology type. If all the above information are available to the MAG during the MN inter-MAG handoff, the target MAG MUST include all these information in the P-BU to aid the LMA in identifying the exact mobile node binding cache entry. In this case, LMA is able to maintain session continuity as it is necessary. 3.2. Multihoming with Single IP Address per Interface This scenario is a special case of the main scenario listed under section 3.1. In this case the LMA assign a unique IP address for each interface and maintain separate binding cache entry per interface. Eventually this scenario causes a multi-link subnet since the same prefix is advertised over multiple subnets. This scenario assumes that the mobile node would configure a unique IP address per interface in the case of static IP address configuration or the MN will req=uest the IP address via Dynamic Host Control Protocol [RFC- 3315]. Muhanna & Khalil Expires May 14, 2008 [Page 7] Internet-Draft PMIPv6 Support for Multihoming November 2007 LMA Binding Cache ================= MN1-if1 [addr1:prefix1] --> MAG1 MN1-if2 [addr2:prefix1] --> MAG2 MN2-if3 [addr3:prefix2] --> MAG1 MN2-if4 [addr4:prefix2] --> MAG2 if3 +------+ +------------->| | +------+ | if1 | MAG1 |\ +=================+ | | | +------->| | \ / \ | | | | +------+ \ / IPv6/IPv4 Transport \ | L | [MN-2] [MN-1] +--+ ...... +--| M | | | if2 +------+ / \ IPv6/IPv4 Transport / | A | | +------->| | / \ / | | | if4 | MAG2 | / +=================+ | | +------------->| |/ | | +------+ +------+ |<---------------- PMIPv6 Domain ---------------->| Figure 2: PMIPv6 Multihoming Support: A single address per interface. In this scenario it is LMA local policy to assign different prefix per mobile node or use the same prefix for assigning IP addresses for multiple mobile nodes. Figure 2 above assumes that the LMA assigns a single prefix per MN but different IP address for each interface. 4. IANA Considerations This document does not require any IANA interaction. 5. Security Considerations This document does not present any new security requirement on the top of the security requirements listed in [PMIPv6-Base}. It only present an analysis of PMIPv6 support for multihoming mobile nodes when connected to the same PMIPv6 domain. Muhanna & Khalil Expires May 14, 2008 [Page 8] Internet-Draft PMIPv6 Support for Multihoming November 2007 6. Acknowledgements The authors would like to thank their colleagues who are willing to provide comments on the content of this draft. 7. References 7.1. Normative References [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [PMIP6-Base] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", draft-ietf-netlmm-proxymip6-05 (work in progress), September 2007. [RFC-3775] Johnson, D., Perkins, C., Arkko, J., "Mobility Support in IPv6", RFC 3775, June 2004. 7.2. Informative References [RFC-2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997. [RFC-3315] Dynamic Host Configuration Protocol for IPv6 (DHCPv6). R. Droms,Ed., J. Bound, B. Volz, T. Lemon, C. Perkins, M. Carney. July 2003. Authors' Addresses Ahmad Muhanna Nortel Networks 2221 Lakeside Blvd. Richardson, TX 75082 USA Phone: +1 (972) 685-1416 Email: amuhanna@nortel.com Muhanna & Khalil Expires May 14, 2008 [Page 9] Internet-Draft PMIPv6 Support for Multihoming November 2007 Mohamed Khalil Nortel Networks 2221 Lakeside Blvd. Richardson, TX 75082 USA Phone: +1 (972) 685-0564 Email: mkhalil@nortel.com Muhanna & Khalil Expires May 14, 2008 [Page 10] Internet-Draft PMIPv6 Support for 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). Muhanna & Khalil Expires May 14, 2008 [Page 11]