Personal G. Tsirtsis
A. O'Neill
BT
Internet Draft S. Corson
Document: draft-tsirtsis-v4-over-mipv6-00.txt Ansible Systems
Category: Informational August 2000
Expires: February 2001
IPv4 over Mobile IPv6 for Dual Stack nodes
draft-tsirtsis-v4-over-mipv6-00.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 [1].
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.
Abstract
In this document we show how IPv4 based communications can be
supported by a dual stack mobile node that only supports Mobile IPv6
(MIPv6). The aim is to use MIPv6 for mobility services while the
Mobile can still use its dual stack capabilities for IPv4
communications without the need for translation.
1. Introduction
Mobile IP (MIP) is capable of offering mobile services to terminals.
Faced with IPv4 address shortage and other shortcomings of Mobile
IPv4, a lot of work is now focused on the more functional Mobile
IPv6. This, however, creates a number of problems for migration and
interoperability, potentially forcing IPv6 Only deployment and
consequently, heavy use of either Tunneling or Protocol Translation
[SIIT], [NAT-PT].
[SOL] combines [DSTM] and [SIIT] to allow IPv6 only nodes to
communicate with IPv4 only nodes and provides some support for
Mobile Nodes in the same domain.
<Tsirtsis, O'Neill, Corson> 1
<IPv4 over MIPv6> <August> <2000>
In this document we present mechanisms to be used for support of
IPv4 based communication with a dual stack mobile node (IPv4v6) that
only supports Mobile IPv6 (MIPv6), rather than both MIPv4 and MIPv6.
The aim is to use MIPv6 for mobility services whilst allowing the
Mobile to use its dual stack capabilities for legacy IPv4
communications without requiring translation or MIPv4 deployment.
2. Dual Stack Mobile Node
Imagine a Dual Stack Mobile Node (MN) that only supports MIPv6 and
not MIPv4. While stationary and at home the MN does not use its
MIPv6 capabilities and thus, looks like a regular Dual Stack node.
In an environment like that, one of the most appealing
interoperability mechanisms proposed by the NGTRANS WG is called
[DSTM].
DSTM allows a dual stack node to use DHCPv6 to configure on demand
its IPv4 stack. This offers high utilization of IPv4 address space
and no requirements for IPv4 support in the domain. Additionally,
while the Node has an IPv4 address, it can communicate with IPv4
only nodes without the use of Protocol Translators and/or Address
Translators.
DSTM has been mainly designed for stationary dual stack nodes. We
will now examine how a MN can take advantage of DSTM in a mobile
environment. It is clear that if the MN is not moving, DSTM can be
directly applicable i.e.: the MN can use DHCPv6 over MIPv6 to
communicate with the DSTM server in the home network and request an
IPv4 address. The problem is that while MIPv6 can "move" the
mobile's IPv6 stack between access points in the network, it is not
obvious how it can move the IPv4 stack of the same MN.
3. Tunneling IPv4 in IPv6
[DSTM] assumes that IPv4 routing is not available in the DSTM
domain. The Dynamic Tunneling Interface (DTI)_is defined as an
interface that encapsulates IPv4 packets into IPv6 packets. The
Tunnel End Point (TEP) is also defined as the destination of the
IPv6 packet containing an IPv4 packet. Providing the MN node knows
were the TEP in the domain it happens to be in, it can use MIPv6 to
send an encapsulated IPv4 packet to the IPv4 CN.
So, lets see how a Dual Stack MN would use DSTM and MIPv6 to
initiate an IPv4 based communication. The examples below are
borrowed from [DSTM] and modified for our purpose. Similar notation
is also used:
MN will designate an IPv6 host with a dual stack, MN6 will be the
IPv6 address of this host and MN4 its IPv4 address.
TEP will designate the Dual Stack Tunnel End Point of the network.
CN will designate an IPv4-only host and CN4 its address.
<Tsirtsis, O'Neill, Corson> 2
<IPv4 over MIPv6> <August> <2000>
==> means an IPv6 packet
--> an IPv4 packet
++> a tunneled IPv4 packet that is encapsulated in an IPv6 packet
..> a DNS query or response. The path taken by this packet
does not matter in the examples. "a" means the DNS name of a
host
DNS DHCPv6
MN6 TEP CN4
| | |
|. . .> Z | | - MN6 asks DNS for an A6 for "CN4"
|<. . .error | | - the DNS answers with an error
|. . .> Z | | - MN6 asks for the A RR for "CN4"
|<. . . Z4 | | - the answer is CN4
| | |
| | |
| | | - MN6 needs an IPv4 address.
|=================> | - MN6 requests from the local DHCPv6
| | | server an IPv4 address
|<================= | - The DHCPv6 server replies to the MN
| | | providing temporarily an IPv4
| | | address and the TEP address.
|+++++++++++>| | - The MN sends the IPv6 packet to the
| | | TEP using its Home Address
| |----------->| - The TEP sends the packet to CN4
MN6 essentially uses its MIPv6 CCoA in the foreign domain to request
an IPv4 address (and the local TEP) from the local DHCPv6 server. It
then uses MIPv6 to communicate with the local TEP and encapsulate
IPv4 packets destined to external IPv4 only nodes. Even if MN6 moves
to a new Access Router in this domain, a BU to the TEP will allow
the IPv6 tunnel and the IPv4 packets it encapsulates to be
maintained.
Note that like [SOL] the level of IPv6 connectivity offered by the
above combination is very similar to MIPv4 without route
optimization since the IPv4 address used is in fact a dynamically
allocated IPv4 Home Address. Also like [SOL], MIPv6 Route
optimization is of course used for the path between the MN and the
TEP in that domain.
It might also be possible for the MN to use the Home DHCPv6 server
when in a foreign domain e.g: if the foreign domain does not support
DHCPv6. This would require DHCPv6 request to be sent through the
Home Agent of the MN. The reply would then include an IPv4 address
and a TEP address from the home domain. Data would have to be sent
from the MN to the HA to the TEP and eventually to the CN.
Note that no new protocol or change to any protocol is implied in
this draft. We just show how MIPv6 can be combined with DSTM to give
<Tsirtsis, O'Neill, Corson> 3
<IPv4 over MIPv6> <August> <2000>
basic IPv4 based communication capability to a Dual Stack MN which
only supports MIPv6.
4. Comparison with [SOL]
The main advantage of this approach is that no translation is used
for IPv4 communications. [SOL] uses translation for IPv4
communications.
The main disadvantage of this approach is that all IPv4
communications will have to go over one or more TEP boxes that are
single points of failure) for the IPv4 sessions they support. In
[SOL] this problem is minimized due to the stateless nature of
[SIIT].
Finally, care needs to be taken so that the CCoA the MN uses to
request an IPv4 address from the DHCPv6 server, does not expire
before the DHCPv6 server manages to allocate the IPv4 address.
Movement and thus deprecation of the CCoA can be handled as long as
packets to this CCoA still reach the MN. [MIPv6] provides mechanisms
to allow that.
In this draft we do not consider incoming sessions (from IPv4 only
nodes outside the IPv6 domain). This is because the [DSTM]
specification does not support that functionality but only as a
future work item. If and when such mechanisms are developed, they
are likely to apply in this draft too.
5. Security Considerations
The same as those define in [MIPv6] and [DSTM]
6. References
[SOL] H. Soliman, E. Nordmark, "Extensions to SIIT and DSTM for
enhanced routing of inbound packets", <draft-soliman-siit-dstm-
00.txt>, July 2000, Work in Progress
[MIPV6] D. Johnson and C. Perkins, "Mobility Support in IPv6",
<draft-ietf-mobileip-ipv6-12.txt>, Work in progress.
[SIIT] E. Nordmark, "Stateless IP/ICMP Translation Algorithm",
RFC2765, February 2000.
[NAT-PT] G. Tsirtsis, P. Shrisuresh, "Network Address Translation -
Protocol Translation (NAT-PT)", RFC2766, February 2000
<Tsirtsis, O'Neill, Corson> 4
<IPv4 over MIPv6> <August> <2000>
7. Acknowledgments
This draft is based on [SOL] and offers an alternative to it.
Author's Addresses
George Tsirtsis
BT
Phone: +44-20-88260073
Email: george.tsirtsis@bt.com
Alan O'Neill
BT
Phone: +44-20-88260073
Email: alan.w.oneill@bt.com
M. Scott Corson
University of Maryland
Ansible Systems
(+1) 301-405-6630
corson@isr.umd.edu
Copyright Notice
Placeholder for ISOC copyright.