NETLMM Working Group V. Devarapalli Internet-Draft Azaire Networks Intended status: Informational S. Gundavelli Expires: October 12, 2007 Cisco Systems K. Chowdhury Starent Networks A. Muhanna Nortel Networks April 10, 2007 Proxy Mobile IPv6 and Mobile IPv6 interworking draft-devarapalli-netlmm-pmipv6-mipv6-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 October 12, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract Proxy Mobile IPv6 is a network-based local mobility management protocol developed in the IETF. Mobile IPv6 is a host-based mobility management protocol that has no restrictions in terms of Devarapalli, et al. Expires October 12, 2007 [Page 1] Internet-Draft PIPv6 and MIPv6 interworking April 2007 applicability in a domain. This document captures some of the scenarios where Proxy Mobile IPv6 and Mobile IPv6 are used together. It also describes how the two protocols can work together. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Interworking Scenarios . . . . . . . . . . . . . . . . . . . . 3 3.1. Requiring Global Mobility at home (MIPv6-CoA == MN-HoA) . . 3 3.2. Avoiding Global Mobility at home (MIPv6-HoA == MN-HoA) . . 4 3.3. Supporting both MIPv6 and PMIPv6 hosts in the same domain . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 6 7. Normative References . . . . . . . . . . . . . . . . . . . . . 6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 Intellectual Property and Copyright Statements . . . . . . . . . . 8 Devarapalli, et al. Expires October 12, 2007 [Page 2] Internet-Draft PIPv6 and MIPv6 interworking April 2007 1. Introduction The NETLMM WG has been working on a network-based mobility management protocol, Proxy Mobile IPv6 [3]. Proxy Mobile IPv6 (PMIPv6) is based on Mobile IPv6 [2] in the sense that it re-uses many concepts from the Mobile IPv6 protocol (MIPv6). Most of the Home Agent functionality as defined in Mobile IPv6 is re-used for Proxy Mobile IPv6. There are many scenarios where Proxy Mobile IPv6 and Mobile IPv6 can be used to-gether. For example, Proxy Mobile IPv6 could be used as the local mobility management protocol and Mobile IPv6 as the global mobility management protocol in a hierarchical manner. In this document we capture three scenarios where Proxy Mobile IPv6 and Mobile IPv6 interworking needs to be considered. 1. Proxy Mobile IPv6 and Mobile IPv6 are used in a hierarchical manner 2. Transitioning between Proxy Mobile IPv6 and Mobile IPv6 3. Co-existence of PMIPv6 and MIPv6 hosts in the same network 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. Interworking Scenarios 3.1. Requiring Global Mobility at home (MIPv6-CoA == MN-HoA) In this model, PMIPv6 and MIPv6 are used in a hierarchical manner where PMIPv6 is used for local mobility and MIPv6 is used for global mobility. The MN-HoA address assigned to the mobile node in the Proxy Mobile IPv6 domain is used as the care-of address for Mobile IPv6 registration. If the mobile node moves and attaches to an access network that is not part of the proxy mobile IPv6 domain, it acquires a care-of address from the access network and performs a regular Mobile IPv6 registration with its home agent. When the mobile node is outside the Proxy Mobile IPv6 domain, only Mobile IPv6 is used. When at home or away, where network-based mobility is enabled, the mobile node will use the locally obtained IPv6address (MIPv6-CoA) on the attached link and establish global mobility management for its home address (MIPv6-HoA), using host-based mobility signaling. Devarapalli, et al. Expires October 12, 2007 [Page 3] Internet-Draft PIPv6 and MIPv6 interworking April 2007 When the mobile node moves and attaches to a different MAG in the PMIPv6 domain, the mobile node and the Mobile IPv6 home agent are not aware of the movement. PMIPv6 takes care of managing the mobility between different MAGs. The mobile node's movement is restricted only to the LMA. If the mobile node movement results in attaching to a different PMIPv6 domain, then the mobile node sees a change in its care-of address and sends a binding update to its home agent. 3.2. Avoiding Global Mobility at home (MIPv6-HoA == MN-HoA) In this mode, the mobile node uses Proxy Mobile IPv6 as long as it is in the Proxy Mobile IPv6 domain. It has Mobile IPv6 stack active at the same time, but as long as it is attached to the same Proxy Mobile IPv6 domain, it will appear as if it is attached to the home link. If it attaches to an access network that is not part of the Proxy Mobile IPv6 domain, it acquires a care-of address from the access networks, treats the earlier home address in the Proxy Mobile IPv6 domain as the Mobile IPv6 home address and performs a Mobile IPv6 registration. The Mobile IPv6 registration is performed with the same home agent that was earlier a local mobility anchor in the Proxy Mobile IPv6 domain. The home agent supporting the mobile node based on host-based mobility management scheme, is also configured to function as a local mobility anchor for supporting local mobility management. When the mobile node is in its mobile IPv6 home domain, it will be able to roam in that domain using its MN-HoA and with out having to participate in any mobility related signaling. The domain is enabled for network-based mobility and the obtained home address in the proxy mobile IPv6 context (MN-HoA) is the same as its global home address (MIPv6-HoA). The mobile is not required to initiate host-based mobility and avoiding any IPv6 tunneling over the air in the home domain. When the mobile moves away from its home domain and enters another domain where network-based mobility management is enabled, the mobile node obtains an address from the new PMIPv6 domain, and uses that address as the care-of address for Mobile IPv6 registration. The earlier MN-HoA address is now treated as the MIPv6 home address (MIPv6-HoA). This is similar to the scenario described in Section 3.1. If the mobile node moves in to a domain where network based mobility is not enabled, the mobile node will configure a local address and use the local address as the care-of address for Mobile IPv6 registration. The LMA entity for the mobile node now becomes the home agent for the mobile node. Devarapalli, et al. Expires October 12, 2007 [Page 4] Internet-Draft PIPv6 and MIPv6 interworking April 2007 Note that in the scenario the same binding cache entry for the mobile node is at times modified by the mobile node and other times modified by a MAG. The home agent must ensure that only authorized MAGs in addition to the mobile node are allowed to modify the binding cache entry for the mobile node. If the mobile node moves back to the PMIPv6 domain that corresponded to its home link, it will send a de-registration binding update with zero lifetime to its home agent. But at the same, the MAG the mobile node is attached will send a proxy Binding Update to the LMA functionality co-located with the home agent. In this case, the home agent MUST send a binding acknowledgement with success status to the mobile node to indicate that it is at home, but modify the binding cache entry to reflect the fact that it is now a binding cache entry created using PMIPv6. The home agent MUST NOT delete the binding cache entry for the mobile node. The bootstrapping mechanisms used to discover the LMA, the Mobile IPv6 home agent and home address for the mobile node must be configured such that the LMA assigned for a particular mobile node can be used as a home agent and the address given to the mobile node when it is attached to the PMIPv6 domain can be used as the MIPv6 home address when the mobile node is no longer attached to the PMIPv6 domain. 3.3. Supporting both MIPv6 and PMIPv6 hosts in the same domain This scenario addresses a network where there is a combination of Mobile IPv6 hosts and IPv6 hosts that do not implement any mobility management software. The same home agent that supports hosts that have the Mobile IPv6 mobile node functionality will also act as the PMIPv6 LMA for hosts that rely on network-based mobility management. Supporting this scenario is rather straight forward and is described in the based PMIPv6 specification [3]. 4. Security Considerations Scenarios 1 and 3 described in Section 3 do not introduce any security considerations in addition to those described in [3] or [2]. In Scenario 2 described in Section 3.2, the home agent has to allow the authorized MAGs in a particular PMIPv6 domain to be able to modify the binding cache entry for a mobile node. RFC 3775 requires that only the right mobile node is allowed to modify the binding cache entry for its home address. This document requires that the a home agent that also implements the PMIPv6 LMA functionality should allow both the mobile node and the authorized MAGs to modify the Devarapalli, et al. Expires October 12, 2007 [Page 5] Internet-Draft PIPv6 and MIPv6 interworking April 2007 binding cache entry for the mobile node. 5. IANA Considerations This document requires no action from IANA. 6. Acknowledgments The authors would like to thank Gerardo Giaretta for interesting discussions on this topic. 7. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [3] Gundavelli, S., "Proxy Mobile IPv6", draft-sgundave-mip6-proxymip6-02 (work in progress), March 2007. Authors' Addresses Vijay Devarapalli Azaire Networks 3121 Jay Street Santa Clara, CA 95054 USA Email: vijay.devarapalli@azairenet.com Sri Gundavelli Cisco Systems 170 West Tasman Drive San Jose, CA 95134 USA Email: sgundave@cisco.com Devarapalli, et al. Expires October 12, 2007 [Page 6] Internet-Draft PIPv6 and MIPv6 interworking April 2007 Kuntal Chowdhury Starent Networks 30 International Place Tewksbury, MA USA Email: kchowdhury@starentnetworks.com Ahmad Muhanna Nortel Networks 2221 Lakeside Blvd. Richardson, TX 75082 USA Email: amuhanna@nortel.com Devarapalli, et al. Expires October 12, 2007 [Page 7] Internet-Draft PIPv6 and MIPv6 interworking April 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 October 12, 2007 [Page 8]