NETLMM Working Group M. Sahasrabudhe Internet-Draft Nokia Siemens Networks Intended status: Best Current V. Devarapalli Practice Azaire Networks Expires: August 18, 2008 February 15, 2008 Proxy Mobile IPv6 and Mobile IPv4 interworking draft-meghana-netlmm-pmipv6-mipv4-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 18, 2008. Copyright Notice Copyright (C) The IETF Trust (2008). Abstract The Proxy Mobile IPv6 protocol provides mobility management for an IPv4-only mobile nodes. It provides network-based mobility management and session continuity for the IPv4 mobile node as long as the mobile node is attached to the Proxy Mobile IPv6 domain. The mobile node that attaches to the Proxy Mobile IPv6 domain, may also implement Mobile IPv4. When a Mobile IPv4-capable mobile node attaches to a Proxy Mobile IPv6 domain, there are some interactions Sahasrabudhe & Devarapalli Expires August 18, 2008 [Page 1] Internet-Draft PMIPv6 and MIPv4 interworking February 2008 between Proxy Mobile IPv6 and Mobile IPv4 that need to be studied. This document looks at a particular scenario where the mobile node transitions between using Proxy Mobile IPv6 and Mobile IPv4. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Transitioning between Proxy Mobile IPv6 and Mobile IPv4 . . . 3 3.1. Booting up in the PMIPv6 domain . . . . . . . . . . . . . 4 3.2. Handover from PMIPv6 domain to non-PMIPv6 domain . . . . . 6 3.3. Handover in to the PMIPv6 domain . . . . . . . . . . . . . 8 4. Security Considerations . . . . . . . . . . . . . . . . . . . 10 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 7.1. Normative References . . . . . . . . . . . . . . . . . . . 11 7.2. Informative References . . . . . . . . . . . . . . . . . . 11 Appendix A. Application of PMIPv6 - MIPv4 interactions to LTE-HRPD handovers . . . . . . . . . . . . . . . . . 12 A.1. LTE to HRPD Handover . . . . . . . . . . . . . . . . . . . 13 A.2. HRPD to LTE Handover . . . . . . . . . . . . . . . . . . . 13 A.3. Serving-GW Relocation . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 Intellectual Property and Copyright Statements . . . . . . . . . . 15 Sahasrabudhe & Devarapalli Expires August 18, 2008 [Page 2] Internet-Draft PMIPv6 and MIPv4 interworking February 2008 1. Introduction The Proxy Mobile IPv6 protocol [3] is a network-based mobility management protocol that provides mobility management for both IPv4 and IPv6 mobile nodes as long as they are attached to the same Proxy Mobile IPv6 domain. These mobile nodes that attach to the Proxy Mobile IPv6 domain may also implement host-based mobility management protocols like Mobile IPv6 [5] or Mobile IPv4 [2]. The interactions between Proxy Mobile IPv6 and Mobile IPv6 are described in [6]. This document captures a scenario related to interactions between Proxy Mobile IPv6 and Mobile IPv4. The scenario of particular interest in this document is where the MIPv4 Home Agent and the Proxy Mobile IPv6 Local Mobility Anchor functionality are co-located on the same network node. The mobile node performs handovers between the Proxy Mobile IPv6 domain and the Mobile IPv4 foreign link. The Proxy Mobile IPv6 domain may also appear as the home link for the mobile node with respect to Mobile IPv4. This document describes this scenario in more detail. 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. Transitioning between Proxy Mobile IPv6 and Mobile IPv4 The following describes a scenario where the mobile node moves between access network(s) that are part of the Proxy Mobile IPv6 domain and an access network that is outside the Proxy Mobile IPv6 domain. The mobile node implements the Mobile IPv4 mobile node functionality as described in [2]. The Mobile IPv4 home agent function and the Proxy Mobile IPv6 LMA function are co-located on the same network node. In this scenario, the mobile node uses Proxy Mobile IPv6 as long as it is in the Proxy Mobile IPv6 domain. Since the mobile node is an IPv4 node, the MAG obtains an IPv4 address from the LMA using the Proxy Binding Update and Proxy Binding Acknowledgement exchange as described in [4]. The MAG then assigns the IPv4 address to the mobile node. The mobile node may also use DHCP to configure the IPv4 address as described in [4]. The mobile node has the Mobile IPv4 stack active at the same time, but as long as it is attached to the same Proxy Mobile IPv6 domain, Sahasrabudhe & Devarapalli Expires August 18, 2008 [Page 3] Internet-Draft PMIPv6 and MIPv4 interworking February 2008 it will appear as if it is attached to the home link. If the mobile node 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 IPv4 address acquired earlier in the Proxy Mobile IPv6 domain as the Mobile IPv4 home address and performs a Mobile IPv4 registration. The Mobile IPv4 registration is performed with the same home agent that was earlier a local mobility anchor in the Proxy Mobile IPv6 domain. If the foreign link supports the foreign agent functionality, the mobile node does not configure a co- located care-of address. The home agent supporting the mobile node based on host-based mobility management, is also configured to function as a local mobility anchor for supporting local mobility management. The IPv4 address configured by the mobile node in the Proxy Mobile IPv6 domain is the same as the MIPv4 home address when the mobile node is attached to a foreign link. This is illustrated in Figure 1. +------+ |HA/LMA|-----------------------+ +------+ | //\\ | +-------//--\\--------+ | ( // \\ PMIPv6 ) | ( // \\domain ) +--------------+ +----//--------\\-----+ ( Non-PMIPv6 ) // \\ ( domain ) // \\ +--------------+ // \\ | +----+ +----+ +----+ |MAG1| |MAG2| | AR | +----+ +----+ +----+ | | | [MN] MN obtains Mobile IPv4 HoA from HA MIPv4 HoA = PMIPv6 IPv4 MN-HoA Figure 1: Transitioning between PMIPv6 and MIPv4 3.1. Booting up in the PMIPv6 domain According to Section 2 of RFC 3344 [2], the mobile node should receive an Agent Advertisement from its home agent to detect that it is attached to the home link. The Agent Advertisement from a home agent is distinguishable by the presence of the 'H' bit in the advertisement. Sahasrabudhe & Devarapalli Expires August 18, 2008 [Page 4] Internet-Draft PMIPv6 and MIPv4 interworking February 2008 In the scenario presented in Section 3, the mobile node is attached to the home link when it is in the Proxy Mobile IPv6 domain. When the mobile node boots up in the Proxy Mobile IPv6 domain, it first authenticates itself to the Mobile Access Gateway (MAG) and sets up a point-to-point link with the MAG. The current Proxy Mobile IPv6 specification only supports point-to-point links between the mobile node and the MAG. As soon as the point-to-point link is up, the mobile node should send an agent solicitation to check if it is attached to the home link. When the MAG sees the agent solicitation from the mobile node, it identifies that the mobile node has the Mobile IPv4 client active. The MAG then sends an Agent Advertisement on behalf of the Home Agent function co-located with the LMA function. The 'Router Address' field in the Agent Advertisement is set to the IPv4 address of the co-located MIPv4 Home Agent and PMIPv6 LMA functions. When the mobile node receives the Agent Advertisement with the 'H' flag set, it discovers that it is attached to the MIPv4 home link. The mobile node extracts the address from the 'Router Address' field in the Agent Advertisement and stores it as the MIPv4 home agent address. Figure 2 shows the sequence of steps by which the mobile node discovers that it is attached to the home link. Sahasrabudhe & Devarapalli Expires August 18, 2008 [Page 5] Internet-Draft PMIPv6 and MIPv4 interworking February 2008 MN MAG AR/FA LMA/HA | | | | | 1. Attach to MAG | | | |<=================>| | | | | | 2.Proxy BU | | |------------------------------->| | | | | IPv4 MN-HoA | | | 3.Proxy BAck | allocation | |<-------------------------------| | | | | | | |4. PMIPv6 tunnel| | |================================| | |================================| | | | | | 5. IP Addr assign | | | |<=================>| | | | (L2 mechanism or | | | | using DHCP) | | | | | | | | 6. HA Advert | | | |<------------------| | | | | | | |9. MN at | | | | home | | | Figure 2: Booting Up in the PMIPv6 domain 3.2. Handover from PMIPv6 domain to non-PMIPv6 domain When the mobile node moves to an access network that is outside the Proxy Mobile IPv6 domain, it starts Mobile IPv4 operation. The mobile node performs movement detection as specified in [2]. If there is a foreign agent on the access network, it starts using the foreign agent. If there is no foreign agent on the access network, the mobile node configures a care-of address from the access network. Once the mobile node configures a care-of address from the access network, it sends a registration request to the home agent. It uses the home agent address obtained via the Home Agent Advertisement it received while attached to the home link in the Proxy Mobile IPv6 domain. The mobile MAY include the IPv4 address configured when attached to the Proxy Mobile IPv6 domain as the home address in the registration request. The mobile node MAY also set the home address to 0.0.0.0 in the registration request as specified in [2]. When the home agent receives the registration request for the mobile node, it processes the registration request and creates a Mobile IPv4 Sahasrabudhe & Devarapalli Expires August 18, 2008 [Page 6] Internet-Draft PMIPv6 and MIPv4 interworking February 2008 binding cache entry for the mobile node. If there is a Proxy Mobile IPv6 binding cache entry for the mobile node, that entry is deleted. If the registration request had a valid home address, the home agent creates a binding cache entry for the home address. If the registration request had the home address field set to 0.0.0.0, the home agent allocates the PMIPv6 IPv4 MN-HoA previously assigned to the mobile node as the Mobile IPv4 home address. The home agent then sends a registration reply to the mobile node as specified in [2]. Figure 3 shows the sequence of steps involved in the handover from a Proxy Mobile IPv6 domain to an access router or a foreign agent outside the Proxy Mobile IPv6 domain. Sahasrabudhe & Devarapalli Expires August 18, 2008 [Page 7] Internet-Draft PMIPv6 and MIPv4 interworking February 2008 MN MAG AR/FA LMA/HA | | | | | 1. MN attached to | PMIPv6 tunnel | | PMIPv6 domain |================================| |<=================>|================================| | | | | |2. MN | | | | moves | | | | | | | | 3. Attach to AR/FA | | |<=================================>| | | | | | | 4. FA Agent Advert| | | |<----------------------------------| | | | | | | 5. Registration | | | | Request (HoA = 0.0.0.0) | | |---------------------------------->| | | | | | | | |6. Registration | | | | Request | | | |--------------->| | | | |IPv4 MN-HoA | | | |allocated as | | | |MIPv4 HoA | | |7. Registration | | | | Reply (HoA) | | | |<---------------| | | | | | 8. Registration Reply (HoA) | | |<----------------------------------| | | | | | | | |9. MIPv4 tunnel | | | |================| | | |================| | | | | The MIPv4 tunnel would be between the MN and the LMA/HA in the co-located CoA mode. Figure 3: Handover from PMIPv6 domain to non-PMIPv6 domain 3.3. Handover in to the PMIPv6 domain When the mobile node moves in to an access network that is part of the Proxy Mobile IPv6 domain, it is again attached to its home link. It detects that it is attached to the home link when it receives a home agent advertisement advertising the home link. Sahasrabudhe & Devarapalli Expires August 18, 2008 [Page 8] Internet-Draft PMIPv6 and MIPv4 interworking February 2008 When the mobile node moves into the Proxy Mobile IPv6 domain, the LMA receives a Proxy Binding Update from the MAG. The LMA that is co- located with the Mobile IPv4 home agent functions responds with an IPv4 address that is the same as the Mobile IPv4 home address. The LMA also deletes the Mobile IPv4 binding cache entry for the mobile node and creates a proxy binding cache entry for the mobile node. The LMA then sends a Proxy Binding Acknowledgement message to the MAG with the assigned IPv4 address. The MAG after processing the Proxy Binding Acknowledgement, sends a Home Agent advertisement message to the mobile node. When the mobile node detects that it is attached to the home link, it sends a registration request to the home agent with lifetime set to zero to delete the binding cache entry. If the home agent receives a de-registration message (registration request with lifetime set to zero), when there is a proxy binding cache entry for the mobile node, it MUST NOT delete the proxy binding cache entry. Instead it MUST respond to the mobile node with a registration reply acknowledging the de-registration. Figure 4 shows the sequence of steps involved in the handover from an access link outside the Proxy Mobile IPv6 domain in to the Proxy Mobile IPv6 domain. Sahasrabudhe & Devarapalli Expires August 18, 2008 [Page 9] Internet-Draft PMIPv6 and MIPv4 interworking February 2008 MN MAG AR/FA LMA/HA | | | | | | | MIPv4 tunnel | | 1. MN attached to AR/FA |================| |<=================================>|================| | | | | |2. MN | | | | moves | | | | | | | | 3. Attach to MAG | | | |<=================>| | | | | | | | | | 4.Proxy BU | | |------------------------------->| | | | | MIPv4 HoA | | | | allocated as | | | 5.Proxy BAck | IPv4 MN-HoA | |<-------------------------------| | | | | | | |6. PMIPv6 tunnel| | |================================| | |================================| | | | | | 7. IP Addr assign | | | |<=================>| | | | (L2 mechanism or | | | | using DHCP) | | | | | | | | 8. HA Advert | | | |<------------------| | | | | | | |9. MN at | | | | home | | | Figure 4: Handover in to the PMIPv6 domain 4. Security Considerations In the scenario described in Section 3, the mobile node transitions between using Proxy Mobile IPv6 and Mobile IPv4. The binding cache entry for the mobile node may be modified both by the MAGs in the PMIPv6 domain and the mobile node. In Mobile IPv4, the binding cache entry created by the mobile node can only be modified by the mobile node. This document requires that the MIPv4 home agent that also implements the PMIPv6 LMA functionality should allow both the mobile node and the authorized MAGs to modify the binding cache entry for Sahasrabudhe & Devarapalli Expires August 18, 2008 [Page 10] Internet-Draft PMIPv6 and MIPv4 interworking February 2008 the mobile node. 5. IANA Considerations This document requires no action from IANA. 6. Acknowledgments The authors would like to thank Lalit Kotecha for interesting discussions on this topic. 7. References 7.1. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August 2002. [3] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", draft-ietf-netlmm-proxymip6-10 (work in progress), February 2008. [4] Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy Mobile IPv6", draft-ietf-netlmm-pmip6-ipv4-support-02 (work in progress), November 2007. 7.2. Informative References [5] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [6] Giaretta, G., "Interactions between PMIPv6 and MIPv6: scenarios and related issues", draft-giaretta-netlmm-mip-interactions-02 (work in progress), November 2007. [7] 3rd Generation Partnership Project, "3GPP Technical Specification 23.402 V8.0.0: Technical Specification Group Services and System Aspects; Architecture enhancements for non- 3GPP accesses (Release 8)", December 2007. Sahasrabudhe & Devarapalli Expires August 18, 2008 [Page 11] Internet-Draft PMIPv6 and MIPv4 interworking February 2008 Appendix A. Application of PMIPv6 - MIPv4 interactions to LTE-HRPD handovers The 3GPP specification TS 23.402 [7] specifies handovers between 3GPP LTE access and 3GPP2 HPRD access. This section describes how the inter-working mechanism specified in Section 3 can be applied to handovers between LTE and HRPD access networks. The interworking between Mobile IPv4 and Proxy Mobile IPv6 is especially of interest for the LTE-HRPD inter-system handover. The HRPD network already has the Mobile IPv4 protocol implemented and deployed. The LTE network will have the Proxy Mobile IPv6 protocol deployed to support mobility management for the mobile node. For handsets that are dual mode (support both LTE and HRPD technologies) there is no common mobility protocol. Mobility management for the mobile node can be supported though for these nodes by having an interworking solution between Mobile IPv4 and Proxy Mobile IPv6. This solution should work for nodes that may not implement IPv6 and should work with minimal changes to legacy nodes on the HRPD network, for example, the PDSN. The solution described in this document introduces the concept of making the mobile node appear to be on the Home link with respect to the Mobile IPv4 protocol when it is attached to the LTE network and is in the PMIPv6 domain. When the Mobile Node is in the HRPD network, Mobile IPv4 Foreign Agent care-of address mode is used. The solution requires the Proxy Mobile IPv6 LMA functionality and the Mobile IPv4 home agent functionality to be co-located which will most likely reside on the PDN-GW in the LTE network. When the mobile node first attaches to the LTE network, during authentication the MN profile will indicate that this is a dual mode MN that has subscription on both the LTE and HRPD networks. The profile can additionally indicate that the Mobile Node is an IPv4 only node. When the MAG on the Serving-GW sends the Proxy Binding Update (PBU) message to the LMA, it requests for a dynamic IPv4 Home Address allocation for the MN. It does so by setting the IPv4 Home Address field to all zeros in the IPv4 Home Address option. The LMA that can reside on the PDN-GW assigns an IPv4 HoA to the mobile node and returns this address in the Proxy Binding Acknowledgement message to the MAG. Once the PMIPv6 tunnel between the MAG and the LMA is set up, the S-GW sends out a Home Agent Advertisement message for the mobile node with the home agent address set to the PDN-GW address. This indicates to the mobile node that it is attached to the home link. Sahasrabudhe & Devarapalli Expires August 18, 2008 [Page 12] Internet-Draft PMIPv6 and MIPv4 interworking February 2008 A.1. LTE to HRPD Handover In the LTE to HRPD handover, the PDSN downloads the mobile node profile during access authentication. The profile would indicate that the mobile node is a dual mode device that can connect to the LTE as well as HRPD network. The profile may also indicate to the PDSN that it should use a certain PDN-GW as the Mobile IPv4 home agent for the mobile node. The PDSN sends a Foreign Agent Advertisement message. This Agent advertisement prompts the MN to send a Mobile IPv4 Registration request message. The home address field in the message is set to 0.0.0.0. The PDSN forwards the registration request to the PDN-GW. The PDN-GW acting as the Mobile IPv4 home agent returns the same address that was assigned as Proxy Mobile IPv6 IPv4 MN-HoA as the Mobile IPv4 home address. The home address is returned to the PDSN in a Mobile IPv4 Registration Reply message. The Foreign Agent function on the PDSN forwards the Registration Reply message to the mobile node indicating the Mobile IPv4 home address to use. The mobile node can now roam on the HRPD network using the Mobile IPv4 protocol and the MIPv4 home address using the FA address on the PDSN as the care-of address. A.2. HRPD to LTE Handover When a HRPD to LTE handover is performed, the access authentication phase supplies the mobile node's profile to the MME. This indicates to the MME that the MN is a dual mode handset that is capable of interworking. Once the bearer establishment between mobile node and the Serving-GW is done, the Serving-GW will send a Proxy Binding to the PDN-GW to perform a PMIPv6 registration. The Serving-GW will request for an IPv4 address for the MN in the Proxy Binding Update message. The PDN GW responds with a Proxy Binding Acknowledgement including the IPv4 MN-HoA information. This creates a PMIPv6 tunnel between the MAG on the Serving-GW and the LMA on the PDN-GW. The Serving-GW then sends a Home Agent advertisement on behalf of the PDN-GW to make it appear to the mobile node that it is attached to the home link. A.3. Serving-GW Relocation When the mobile node moves from one Serving-GW to another in the Proxy Mobile IPv6 domain, it is assigned the same IPv4 address. As long as the mobile node attaches to MAGs inside the Proxy Mobile IPv6 Sahasrabudhe & Devarapalli Expires August 18, 2008 [Page 13] Internet-Draft PMIPv6 and MIPv4 interworking February 2008 domain, mobility management is done using Proxy Mobile IPv6. The mobile node configures the same IPv4 MN-HoA across the Proxy Mobile IPv6 domain. The Serving-GWs that the mobile node attaches to send a Home Agent advertisement to the mobile node to make it appear that it is still attached to the home link. Authors' Addresses Meghana Sahasrabudhe Nokia Siemens Networks 313 Fairchild Drive Mountain View, CA 94043 USA Email: meghana.sahasrabudhe@nsn.com Vijay Devarapalli Azaire Networks 3121 Jay Street Santa Clara, CA 95054 USA Email: vijay.devarapalli@azairenet.com Sahasrabudhe & Devarapalli Expires August 18, 2008 [Page 14] Internet-Draft PMIPv6 and MIPv4 interworking 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). Sahasrabudhe & Devarapalli Expires August 18, 2008 [Page 15]