Mext Working Group D. Oulai
Internet-Draft S. Krishnan
Intended status: Informational Ericsson
Expires: September 4, 2009 H. Soliman
Elevate Technologies
March 3, 2009
Problem Statement for Route Optimization in dual stack environments
draft-oulai-mext-dsmip-v4ro-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 September 4, 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.
Oulai, et al. Expires September 4, 2009 [Page 1]
Internet-Draft Problem Statement for DSMIPv6 RO March 2009
Abstract
Dual Stack MIPv6 (DSMIP) is a MIPv6 extension to support IPv4
mobility for mobile hosts. While route optimization is well defined
for IPv6 traffic, this features is not defined for IPv4. This
document looks at the different scenarios where IPv4 route
optimization is desirable and highlights some problems.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions used in this document . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. MIPv6 Route Optimization . . . . . . . . . . . . . . . . . . . 6
5. The Problem . . . . . . . . . . . . . . . . . . . . . . . . . 7
6. Problem space and scenarios . . . . . . . . . . . . . . . . . 8
6.1. Mobile and correspondent nodes communicate using IPv4 . . 8
6.2. Mobile and correspondent nodes communicate using IPv6 . . 8
7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
8. Normative References . . . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
Oulai, et al. Expires September 4, 2009 [Page 2]
Internet-Draft Problem Statement for DSMIPv6 RO March 2009
1. Introduction
Dual Stack MIPv6 (DSMIP) is a MIPv6 extension to support IPv4 traffic
for mobile nodes [I-D.ietf-mext-nemo-v4traversal]. DSMIP introduces
two new address options: the IPv4 Home Address option and the IPv4
CareOf Address option. With those options, a mobile node (MN) can
send and receive v4 traffic although all the mobility signaling is
MIPv6 based. Therefore, there is no need to have a MIPv4 stack on
the mobile node.
Route optimisation (RO) is a process that allows an MN to communicate
directly with a correspondent node (CN) without transiting by the
home agent. There are several benefits for RO such as shorter path
delay, reduced bandwidth consumption and reduced load on the HA.
MIPv6 RO is done using the return routability procedure (RRP). RRP's
main goal is to assure the CN that the MN is reachable through the
home address (HoA) and the care-of address (CoA) and to configure
security keys for the binding. This mechanism does not consider IPv4
addresses. However, it is anticipated that IPv4 and IPv6 will
coexist for a long time and lots of work is being done for IPv4-IPv6
coexistence. Therefore, having RO enabled will enhance DSMIP as a
strong alternative for IPv4-IPv6 coexistence.
This document briefly describes current MIPv6 RO process and
scenarios where IPv4 RO would be desirable. Then specific problems
related to IPv4 RO and use cases are discussed.
Oulai, et al. Expires September 4, 2009 [Page 3]
Internet-Draft Problem Statement for DSMIPv6 RO March 2009
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].
Oulai, et al. Expires September 4, 2009 [Page 4]
Internet-Draft Problem Statement for DSMIPv6 RO March 2009
3. Terminology
All the general mobility-related terms used in this document are to
be interpreted as defined in the Mobile IPv6 [RFC3775] and DSMIP
[I-D.ietf-mext-nemo-v4traversal] base specifications.
Oulai, et al. Expires September 4, 2009 [Page 5]
Internet-Draft Problem Statement for DSMIPv6 RO March 2009
4. MIPv6 Route Optimization
MIPv6 defines a route optimisation procedure where an MN can send a
binding update (BU) directly to the CN in order to use a direct path
[RFC3775]. Before sending the BU, the MN has to perform the RRP in
order to prove to the CN that it owns both the HoA and the CoA. To
perform RRP, the MN sends a HoTI message to the CN through the HA.
The source address of the HoTI is the HoA. Simultaneously, the MN
sends a CoTI message to the CN with its CoA as a source address. The
CN responds to these two messages and includes a Home keygen Token in
the HoT message and a CareOf keygen token in the CoT message. If the
MN received those two messages then it is reachable via the HoA and
CoA. Next step for the MN is to combine both tokens to get a binding
management key (Kbm), which is used to authenticate the BU. The CN
will then be able to verify that the Kbm was formed using both
tokens.
Some optimizations have been proposed for RO. [RFC4449] proposed to
precompute several binding management keys to speed up the binding
update process but this requires the MN and the CN to be in the same
administrative domain.[RFC4866] introduced an enhanced fast RO
process, which requires cryptographically generated addresses.
Oulai, et al. Expires September 4, 2009 [Page 6]
Internet-Draft Problem Statement for DSMIPv6 RO March 2009
5. The Problem
The DSMIPv6 specification allows a dual stack mobile node to
communicate with a correspondent node under two fundamental
scenarios: a) using IPv4, by assigning an IPv4 home address to the
mobile node and b) while the mobile node is located in an IPv4-only
foreign link. In both scenarios the mobile node may be located in an
IPv4 network that assigns private addresses and is therefore
separated by a NAT from the rest of the Internet. In DSMIPv6, the
mobile node can communicate with a correspondent node in the above
scenarios by routing traffic through the home agent, which ,manages
mobility for the IPv4 and IPv6 home addresses by binding them to
either an IPv4 or an IPv6 care-of address. However, DSMIPv6 does not
allow mobile nodes and correspondent nodes to optimise communication
between them and bypassing the home agent.
Route optimisation cannot be achieved using the current DSMIPv6
specification. Route optimisation is not achievable when the mobile
node is communicating to an IPv4-only correspondent node. However,
if the correspondent node is IPv6-enabled, route optimisation can be
achieved by extending DSMIPv6 and the current RRP in MIPv6.
Hence, the problem discussed in this draft is the lack of route
optimisation support in DSMIPv6. The following section discusses the
scenarios that illustrate this problem. A solution for the route
optimisation problem for dual stack nodes should address the
scenarios in the following section.
Oulai, et al. Expires September 4, 2009 [Page 7]
Internet-Draft Problem Statement for DSMIPv6 RO March 2009
6. Problem space and scenarios
In this section we present different scenarios that need to be
addressed in order to provide a complete route optimisation solution
for dual stack mobile nodes. In all scenarios we assume that both
the mobile node and correspondent node are dual stacked with both
stacks enabled.
The scenarios in this section discuss the options for encapsulating
the application payload between the mobile and correspondent nodes.
The capability of the access network will essentially force the need
for tunnelling or allow the communication without the use of
tunnelling.
6.1. Mobile and correspondent nodes communicate using IPv4
In this scenario, the mobile and correspondent node's traffic used
IPv4 only. This might be due to the fact that either node is located
in an IPv4-only environment, or because their applications can only
use IPv4 addresses. In this scenario, the mobile node needs to
optimise the route for the IPv4 communication using Mobile IPv6
signalling. Essentially, the mobile node needs to optimise the route
for its IPv4 home address. This scenario assumes that the
correspondent node's IPv6 stack is enabled, even if it is not
assigned a global IPv6 address.
It should be noted that in this scenario the mobile node can be
located behind a NAT. However, it is assumed that the correspondent
node is reachable with a public IPv4 address. Also, note that this
scenario is somewhat orthogonal to the access network's capability.
That is, the access networks may provide IPv4-only, IPv6-only or dual
stack access. In all cases, the nodes encapsulate the application
payload in IPv4; although, the access capability would require a
solution to tunnel such traffic according to the IP version supported
by the access network.
6.2. Mobile and correspondent nodes communicate using IPv6
Unlike the scenario above, in this scenario, the mobile and
correspondent nodes communicate using IPv6. Hence, the mobile node
is using its IPv6 home address and needs to optimise the route using
MIPv6 signalling.
Note that this scenario is again orthogonal to the access capability,
which will affect how the IPv6 traffic will be routed (or tunnelled)
between the mobile node and correspondent node. That is, if both
access networks support IPv6, traffic will be routed natively and
standard MIPv6 will be used to optimise the route. However, if
Oulai, et al. Expires September 4, 2009 [Page 8]
Internet-Draft Problem Statement for DSMIPv6 RO March 2009
either access network supports IPv4 only, then the solution will need
to overcome this issue through tunnelling.
Oulai, et al. Expires September 4, 2009 [Page 9]
Internet-Draft Problem Statement for DSMIPv6 RO March 2009
7. Security Considerations
This document does not introduce any security vulnerabilities.
Solutions for the problems presented in this document need to endure
that they are as secure as the current RRP in [RFC3775].
Oulai, et al. Expires September 4, 2009 [Page 10]
Internet-Draft Problem Statement for DSMIPv6 RO March 2009
8. Normative References
[I-D.ietf-mext-nemo-v4traversal]
Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and
Routers", draft-ietf-mext-nemo-v4traversal-09 (work in
progress), February 2009.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004.
[RFC4449] Perkins, C., "Securing Mobile IPv6 Route Optimization
Using a Static Shared Key", RFC 4449, June 2006.
[RFC4866] Arkko, J., Vogt, C., and W. Haddad, "Enhanced Route
Optimization for Mobile IPv6", RFC 4866, May 2007.
Oulai, et al. Expires September 4, 2009 [Page 11]
Internet-Draft Problem Statement for DSMIPv6 RO March 2009
Authors' Addresses
Desire Oulai
Ericsson
8400 Blvd Decarie
Town of Mount Royal, Quebec
Canada
Email: desire.oulai@ericsson.com
Suresh Krishnan
Ericsson
8400 Blvd Decarie
Town of Mount Royal, Quebec
Canada
Email: Suresh.Krishnan@ericsson.com
Hesham Soliman
Elevate Technologies
Email: hesham@elevatemobile.com
Oulai, et al. Expires September 4, 2009 [Page 12]