One document matched: draft-wu-netext-pmipv6-ipv4-ro-ps-00.txt
Network Working Group Q.Wu
Internet Draft Huawei
Intended status: Standard Track May 21, 2009
Expires: November 2009
Problem Statement of IPv4 Support for PMIPv6 Localized Routing
draft-wu-netext-pmipv6-ipv4-ro-ps-00.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 November 21, 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 November 21, 2009 [Page 1]
Internet-Draft PS of IPv4 Support for PMIPv6 local routing May 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 introduces 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......................................6
5. References...................................................6
5.1. Normative References....................................6
5.2. Informative References..................................7
6. Acknowledgments..............................................7
Wu Expires November 21, 2009 [Page 2]
Internet-Draft PS of IPv4 Support for PMIPv6 local routing May 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. However, the
IPv4 support for the scenarios and problems of routing optimization
for PMIP6 [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 describes these scenarios and its relevant problems during
setting up an optimized routing path.
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 general processing or
operation that makes end-to-end user traffic between the MN and
the CN go through an optimized routing path in a single PMIPv6
domain.
o Routing Optimization Path (ROP): referred as that the end-to-end
direct path between both the MN and the CN attached MAG(s) without
involving both the MN and the CN registered LMA(s) where the user
traffic is transported.
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): referred as ROP setting up and
ROS maintaining by the involved network entities.
Wu Expires November 21, 2009 [Page 3]
Internet-Draft PS of IPv4 Support for PMIPv6 local routing May 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 of this architecture.
- LMA1 and LMA2 which MN and CN are respectively registering to may
be the same LMA or different LMA in a single PMIPv6 domain.
- With IPv4 user traffic support, MN and CN both are IPv4-only
enabled node or dual stack node.
- 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 November 21, 2009 [Page 4]
Internet-Draft PS of IPv4 Support for PMIPv6 local routing May 2009
Case 1: both MN and CN are IPv4 enabled nodes
In this case, the end-to-end user traffic between MN and CN belongs
to the IPv4 application. MN and CN may be attached to the same or
different MAG. Furthermore, MN and CN attached MAGs communicate with
the LMAs using IPv4 or IPv6 transport.
Case 2: 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.
Case 3: 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.
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
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 both MN and CN are located in the
different MAG respectively and the MAG supports different transport
(e.g., IPv4 over IPv6 transport, IPv6 over IPv4 transport), In such
cases, there are 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
Wu Expires November 21, 2009 [Page 5]
Internet-Draft PS of IPv4 Support for PMIPv6 local routing May 2009
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]. However, when the traffic destined
for the CNs with same HoA does not pass through the LMA and go
directly to the path between the MAGs, the MAG attached by the CN can
not identify the right CN and forward the user traffic to the right
CN.
o P4: IP Protocol Version Switch
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 is sent directly to the corresponding MAG, the dual stack
MAG needs to switch the transport from IPv6 version to the IPv4
version ,i.e., 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 or DHCPv4
server 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
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.
Wu Expires November 21, 2009 [Page 6]
Internet-Draft PS of IPv4 Support for PMIPv6 local routing May 2009
[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.
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 November 21, 2009 [Page 7]
Internet-Draft PS of IPv4 Support for PMIPv6 local routing May 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
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 November 21, 2009 [Page 8]
| PAFTECH AB 2003-2026 | 2026-04-23 21:19:19 |