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]