NETLMM Working Group A. Muhanna Internet-Draft Nortel Intended status: Standards Track S. Krishnan Expires: August 21, 2008 Ericsson K. Leung Cisco B. Patil Nokia Siemens Networks February 18, 2008 Proxy MIPv6 support for transient registrations draft-muhanna-netlmm-pmipv6-support-transient-coa-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 August 21, 2008. Copyright Notice Copyright (C) The IETF Trust (2008). 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. This document specify an enhancement to enable Proxy Muhanna, et al. Expires August 21, 2008 [Page 1] Internet-Draft PMIPv6 Transient Registration February 2008 MIPv6 protocol to support a transient proxy care-of address registration. This process allows the target mobile access gateway to request the local mobility anchor which host the mobile node binding cache entry to register a transient proxy care-of address and the direction of the associated traffic to enable the LMA to receive uplink traffic from two different proxy care-of addresses at the same time during the mobile node inter-MAG active handoff. Table of Contents 1. Conventions used in this document . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Transient Care of Address Registration Procedure . . . . . . . 4 4. LMA Operation with transient binding cache entries . . . . . . 4 5. Removal of transient binding cache entries . . . . . . . . . . 4 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 9. Normative References . . . . . . . . . . . . . . . . . . . . . 5 10. Informative References . . . . . . . . . . . . . . . . . . . . 6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 Intellectual Property and Copyright Statements . . . . . . . . . . 8 Muhanna, et al. Expires August 21, 2008 [Page 2] Internet-Draft PMIPv6 Transient Registration February 2008 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 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. In the case of mobile node active handoff between two different MAGs, the target MAG usually sends a proxy BU message to the mobile node local mobility anchor to update the mobile node BCE with a new care-of address. As soon as the LMA receives and successfully process the proxy BU from the target MAG, LMA updates the mobile node BCE with the new care of address and starts sending the mobile node downlink traffic to the new care of address hosted at the target MAG and forward all of the mobile node uplink reverse IP traffic to the internet as long as it comes from the new care of address. However, during active handoff scenario, some of the mobile node uplink traffic may be still in transient through the previous MAG. Currently, the LMA forwards a mobile node reverse uplink traffic to the internet as long as the following two conditions are met: o The mobile node has an active BCE with its current care of address. o The uplink traffic is received from the care of address saved in the mobile node BCE. This document defines a mechanism which allows Proxy MIPv6 to support a transient care-of address registration which enables the mobile access gateway to register an address as a transient proxy care-of address for a short period of time during inter-MAG active handoff. This new transient registration will enable the LMA to receive uplink traffic for the same MN from two different MAGs at the same time. As soon as inter-MAG handoff is complete, the mobile node BCE will be updated to reflect the latest mobile node care of address and the Muhanna, et al. Expires August 21, 2008 [Page 3] Internet-Draft PMIPv6 Transient Registration February 2008 transient pCoA will be removed from the binding cache. 3. Transient Care of Address Registration Procedure When the target MAG sends a PBU for the new MN that attaches it sets a new value (6: Handoff with transient uplink) in the Handoff Indicator field in the PBU. When the LMA receives this PBU, it creates a new BCE entry with a new bit called the "Transient bit". The LMA responds with a PBA message containing the same handoff indicator value. If the LMA is not capable of performing transient registrations it can ignore the transient registration and instead process the message as if it contained the HI value of 3 (Handoff between mobile access gateways for the same interface). 4. LMA Operation with transient binding cache entries When an uplink packet is received from the MN through the target MAG, the LMA MUST verify if the source address of the packet (i.e. the pCoA of the target MAG) matches the transient pCoA. If the address matches, the LMA MUST consider the packet to be valid and MUST forward the packet appropriately based on the contents of the decapsulated packet. The LMA SHOULD NOT use the transient binding cache entries for sending out downlink traffic to the MN through the target MAG. 5. Removal of transient binding cache entries The transient binding cache entry, which was created by the procedure described in this document, needs to be short lived. i.e. for the duration of the handover. After the handover completes, this entry needs to either be removed or promoted to a full blown binding cache entry. There are three ways by which this can happen 1. The target MAG sends a new PBU with HI value 3 (Handoff between mobile access gateways for the same interface): The transient binding cache entry is converted into a full blown binding cache entry and the BCE for the old MAG is removed 2. The old MAG sends a deregistraion PBU: The transient binding cache entry is converted into a full blown binding cache entry and the BCE for the old MAG is removed 3. A configurable timer expires: The transient binding cache entry is converted into a full blown binding cache entry and the BCE for the old MAG is removed Muhanna, et al. Expires August 21, 2008 [Page 4] Internet-Draft PMIPv6 Transient Registration February 2008 Alternately, if none of these happen, the transient binding cache entry can simply be removed after a configurable timer expires. 6. IANA Considerations This document does not require any IANA interaction. 7. 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 a mechanism to allow a mobile node to be transitionally multihomed at two care of addresses during an inter-MAG active handoff using the same security requirements as per [PMIPv6-Base]. 8. Acknowledgements The ideas presented in the document came out of a discussion during IETF70 at Vancouver in December 2007. The following people were involved in the discussion (listed by last name) Kuntal Chowdhury, Vijay Devarapalli, Sri Gundavelli, Lalit Kotecha, Suresh Krishnan, Kent Leung and Ahmad Muhanna. 9. 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. Muhanna, et al. Expires August 21, 2008 [Page 5] Internet-Draft PMIPv6 Transient Registration February 2008 10. 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 Suresh Krishnan Ericsson 8400 Decarie Blvd. Town of Mount Royal, QC Canada Phone: +1 (514) 345-7900 x42871 Email: suresh.krishnan@ericsson.com Kent Leung Cisco 170 West Tasman Drive San Jose, CA 95134 USA Email: kleung@cisco.com Muhanna, et al. Expires August 21, 2008 [Page 6] Internet-Draft PMIPv6 Transient Registration February 2008 Basavaraj Patil Nokia Siemens Networks 6000 Connection Drive Irving, TX 75039 USA Email: basavaraj.patil@nsn.com Muhanna, et al. Expires August 21, 2008 [Page 7] Internet-Draft PMIPv6 Transient Registration February 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). 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, et al. Expires August 21, 2008 [Page 8]