Network Working Group Q.Wu Internet Draft Huawei J.Korhonen Nokia Siemens Network Intended status: Informational June 23, 2009 Expires: December 2009 Problem Statement of IPv4 Support for PMIPv6 Localized Routing draft-wu-netext-pmipv6-ipv4-ro-ps-01.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and 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 December 23, 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 and restrictions with respect to this document. Wu Expires December 23, 2009 [Page 1] Internet-Draft PS of IPv4 Support for PMIPv6 local routing June 2009 Abstract [ID-PMIP6-RO-PS] describes the problem space of localized routing which allows end-to-end user traffic forwarding between MN and CN directly without involving Local Mobility Anchor (LMA) in a single Proxy Mobile IPv6 [RFC5213] domain. However, localized routing with IPv4 support which allows IPv4 transport between MAG and LMA and/or IPv4 enabled user traffic between MN and CN is not considered. This document details the scenarios and problem statement for localized routing with IPv4 support. Table of Contents 1. Introduction.................................................3 2. Conventions used in this document............................3 3. Scenarios and Problem Statement..............................4 4. Security Considerations......................................7 5. References...................................................7 5.1. Normative References....................................7 5.2. Informative References..................................8 6. Acknowledgments..............................................8 Wu Expires December 23, 2009 [Page 2] Internet-Draft PS of IPv4 Support for PMIPv6 local routing June 2009 1. Introduction In Proxy Mobile IPv6 [RFC5213], Local Mobility Anchor (LMA) is responsible for forwarding the user traffic from the correspondent node to the current location of registered mobile nodes. To reduce latency and backhaul load, optimized routing path without involving LMA in path is expected. [ID-PMIP6-RO-PS] has outlined some possible problems during setting up an optimized routing path between MN and CN which requires that MN and CN are connected to same PMIP domain. However, the scenarios and problems for the IPv4 support of PMIP6 localized routing [ID-PMIP6-IPv4] are not specified. As [ID-PMIP6-IPv4] described, PMIPv6 with IPv4 support contains two basic features: IPv4 transport support and IPv4 HoA support. This document details these scenarios and describes its relevant problems during setting up an optimized routing path. In these IPv4 support localized routing scenarios, it allows a MN and a CN subscription belong to different operators. 2. Conventions used in this document 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 [RFC2119]. This document uses the terminology of [RFC5213]. The following terms are used in the context of this problem statement: o Routing Optimization (RO): referred as the functionality that makes end-to-end user traffic between the MN and the CN go through an optimized routing path in the same PMIPv6 domain. o Routing Optimization Path (ROP): the direct MAG-to-MAG path for a user traffic between the MAG the MN is attached to and the MAG the CN is attached to. o Routing Optimization States (ROS): referred as RO information that is generally stored in the corresponding LMA(s) and MAG(s). Such information includes RO policies and tunnel ID of ROP, etc. o Routing Optimization Control (ROC): the ROP setting up and the ROS management done by the PMIPv6 network entities participating to the RO. Wu Expires December 23, 2009 [Page 3] Internet-Draft PS of IPv4 Support for PMIPv6 local routing June 2009 3. Scenarios and Problem Statement Fig.1 shows a generic IPv4 support architecture. In this architecture, the end-to-end user traffic routing is allowed between MN and CN (CN1, CN2 or CN3). To make the description simple, we have the following general assumptions to this architecture. - LMA1 and LMA2 which MN and CN are respectively anchored to may be the same LMA or different LMA in the same PMIPv6 domain. - With IPv4 user traffic support, MN and CN both are IPv4-only enabled nodes or dual stack nodes. - With IPv4 transport support, we assume IPv4 network is deployed between LMA1 and MAG1. However, the transport network between LMA2 and MAG2, MAG1 and MAG2 is not limited to IPv4 network. +---------+ ============|LMA1/LMA2|============ // +---------+ \\ || || +-----+ || | NAT | +-----------+ +--+-----+--+ | IPv4/IPv6 | | IPv4 | | Network | | Network | +-----------+ +-----------+ || || || || +-----------+ || +------+ |IPv4/IPv6 +---+ +------+ | MAG1 |===================|NAT|=====| MAG2 | +------+ | Network +---+ +------+ | | +-----------+ | | +-----+ +-----+ +-----+ +-----+ | | | | +----+ +-----+ +-----+ +-----+ | MN | | CN1 | | CN2 | | CN3 | +----+ +-----+ +-----+ +-----+ {IPv4-MN-HoA1} {IPv4-CN1-HoA2} {IPv4-CN2-HoA3} {IPv6-CN3-HoA4} {IPv6-MN-HoA1} {IPv6-CN2-HoA3} Fig.1 IPv4 support architecture Based on the assumption mentioned above, we have the following three use cases on IPv4 support for PMIPv6 localized routing. Wu Expires December 23, 2009 [Page 4] Internet-Draft PS of IPv4 Support for PMIPv6 local routing June 2009 Case 1: Both MN and CN attached MAGs are using IPv4 transport In this case, the PMIPv6 signaling between MAGs and LMAs for MN and CN is carried over IPv4 network. The end-to-end user traffic between MN and CN can be IPv4 or IPv6 application. With IPv4 transport support, the NAT may exist between MAG1 and MAG2 or between the LMA1 and LMA2. Case 2: MN and CN attached MAGs are using IPv4 transport and IPv6 transport respectively In this case, the PMIPv6 signaling between MAG1 and LMA1 for MN is carried over IPv4 network while the PMIP6 signaling between MAG2 and LMA2 for CN is carried over IPv6 network. The end-to-end user traffic between MN and CN can be IPv4 or IPv6 application. With the IPv4 transport support, the NAT may exist between MAG1 and MAG2 or between the LMA1 and LMA2. Case 3: Both MN and CN are IPv4 enabled nodes In this case, MN is using IPv4 address to communicate with CN through the direct path between the MN and CN's MAGs located in the same PMIP6 domain. The end-to-end user traffic between MN and CN belongs to the IPv4 application. Furthermore, MN and CN may be attached to the same or different MAGs. MN and CN attached MAGs communicate with the LMAs using IPv6 transport. Case 4: Roaming user MN and non-roaming user CN subscription belong to different Operators In this case, Roaming user MN moves to the visited network owned by the operator using IPv4 transport where no-roaming CN is located. MN and CN are under the same PMIP6 domain. However, MN and CN subscription belong to the different operators. Case 5: Both MN and CN are "roaming" and using visited network LMAs In this case, both MN and CN moves to the same visited network owned by the operator using IPv4 transport. MN and CN are roaming users and both using visited network LMAs. However MN and CN subscription belong to the different operators. On the basis of the above use cases, we have several problems of IPv4 Support for PMIPv6 localized routing to be considered below. o P1: NAT Detection Wu Expires December 23, 2009 [Page 5] Internet-Draft PS of IPv4 Support for PMIPv6 local routing June 2009 For IPv4 transport support, when the IPv4 network is deployed between both MAG(s) in an optimized routing path, NAT [RFC3022] device may be located. In general, [ID-DSMIP6] for detecting the on-path NAT device may be applicable for ROP setup. However, if there existing NAT between the MAGs associated with the MN and CN and the MAG is not aware of it, the NAT may automatically drop the user traffic between the MN and CN and prevent setting up localized routing path. o P2: Encapsulation Mode Negotiation There may be some situations where MN communicates with CN using the direct path between the MAGs to which both MN and CN attached and such MAGs support different tunnel encapsulation or transport (e.g., IPv4 over IPv6 transport, IPv6 over IPv4 transport, IPv6 over IPv4 UDP). In such cases, there may be various encapsulation modes existed between MAG1 and MAG2 for choice. Therefore, it is expected to negotiate and determine the appropriate encapsulation mode for end- to-end user traffic routing between MN and CN during ROC processing. o P3: IPv4 address space overlapping There may be some situations where mobile nodes from different operators may be assigned the same IPv4 HoA from overlapping private address space. In PMIPv6 domain, the MAG and the LMA can distinguish each mobile node flow based on the GRE key encapsulated within the tunneled packet [ID-PMIP-GREKEY], even though two mobile nodes are assigned the same IPv4 HoA. However, when the traffic destined for the CNs with same HoA does not pass through the tunnel between the MAG and the LMA and go directly to the path between the MAGs associated with MN and CN, the MAG attached by the CN can not identify the right CN based on the overlapped IPv4 HoA in the destination field of the incoming packet, therefore can not forward the user traffic to the right CN. o P4: IP Protocol Version Transition Wu Expires December 23, 2009 [Page 6] Internet-Draft PS of IPv4 Support for PMIPv6 local routing June 2009 There may be some situations where the IPv4 network is deployed between both MAG(s) in an optimized routing path and the IPv6 network is deployed between the MAG and the LMA, in such cases, once the local routing is allowed between both MAG(s) and the traffic from the MN or CN does not pass through the LMA and is sent directly to the corresponding MAG, the dual stack MAG needs to transit from the IPv6 transport version to the IPv4 transport version ,e.g., change the destination address of the packet from IPv6-Proxy-CoA to IPv4-Proxy- CoA. This change should be considered during ROC processing. o P5: ROS Maintaining For IPv4 support, the ROS should include the additional source/ destination IPv4 address or the transport IPv4 address (e.g. IPv4- Proxy-CoA), etc. Further more, RO policy (e.g. whether per-MN based RO is enabled or disabled) may be downloaded from AAA as an attribute of ROS and maintained locally in the ROS. 4. Security Considerations The scenarios and problems specified in this document can use the security association between the LMA and the MAG to create security association between MAGs associated with the MN and CN in the communication. 5. References 5.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022, January 2001. [ID-PMIP6-RO-PS] Liebsch, M., "PMIPv6 Localized Routing Problem Statement", draft-liebsch-netext-pmip6-ro-ps-00, February 2009. Wu Expires December 23, 2009 [Page 7] Internet-Draft PS of IPv4 Support for PMIPv6 local routing June 2009 5.2. Informative References [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [ID-PMIP6-IPv4] Wakikawa, R. and S.Gundavelli, "IPv4 Support for Proxy Mobile IPv6", draft-ietf-netlmm-pmip6-ipv4-support-12 (work in progress), April 2009. [ID-PMIP-GREKEY] Muhanna, A., Khalil, M., S.Gundavelli and K. Leung, "GRE Key Option for Proxy Mobile IPv6", draft-ietf-netlmm- grekey-option-09, May 2009 6. Acknowledgments Many thanks to NetExt members for their comments. Wu Expires December 23, 2009 [Page 8] Internet-Draft PS of IPv4 Support for PMIPv6 local routing June 2009 Authors' Addresses Qin Wu Huawei Technologies Co.,Ltd. Floor 10, HuiHong Mansion, No.91 BaiXia Rd. Nanjing, Jiangsu, 210001 P.R.China Email: sunseawq@huawei.com Jouni Korhonen Nokia Siemens Network Linnoitustie 6 Espoo FI-02600 Finland Email: jouni.nospam@gmail.com Yungui Wang Huawei Technologies Co.,Ltd. Floor 10, HuiHong Mansion, No.91 BaiXia Rd. Nanjing, Jiangsu, 210001 P.R.China Email: w52006@huawei.com Wu Expires December 23, 2009 [Page 9]