Internet DRAFT - draft-engelstad-ngtrans-6to4-v4v6-mobility
draft-engelstad-ngtrans-6to4-v4v6-mobility
INTERNET DRAFT P. Engelstad
Telenor R&D
Expires February 2002 August 14. 2001
IPv4 over 6to4 and 6to4 mobility.
<draft-engelstad-ngtrans-6to4-v4v6-mobility-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.
This document is an Internet-Draft. 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 document is an individual submission for the NGTRANS Working
Group of the Internet Engineering Task Force (IETF). Comments should
be submitted to the ngtrans@sunroof.eng.sun.com mailing list.
Abstract
This draft outlines how a 6to4-enabled host can be provided with
transparent IPv4 and IPv6 connectivity and mobility no matter if the
host is located in a 6to4 network or is roaming an IPv4-only network.
1. Introduction
6to4, which is specified in [6to4], is one of the most powerful
transition mechanisms we have today. It is designed to let IPv6 hosts
in one 6to4-enabled IPv6 domain ("6to4-domain") communicate with
other IPv6 hosts in other 6to4 domains. The IPv6 packets are tunneled
Engelstad [Page 1]
INTERNET DRAFT 6to4 v4v6 mobility
by a 6to4-router over the IPv4 Internet to the 6to4 designated
6to4-router that is located on the border of the 6to4 domain where
the recipient is located. The IPv4 address of the designated router
is encoded into the prefix of the IPv6 address ("6to4 address").
Section 3 of this draft shows how a dual stack host can be reachable
for incoming IPv4 traffic from anywhere on the IPv4 Internet and how
it can send outgoing IPv4 traffic back to the IPv4 Internet, although
it is located in a 6to4 domain.
One definitely does not want to route such IPv4 communication inside
the IPv6 domain based on the IPv4 addresses of the nodes in the
domain: We do not want to import the well-known IPv4 routing table
size problem into the IPv6 domain.
Instead, we let IPv4 traffic be relayed by a home agent located in
the IPv4 domain. This will solve this routing problem for the limited
time of transitioning from IPv4 to IPv6. It is assumed that the
obvious negative sides of this approach (e.g. single points of
failure, non-optimal routing etc.) can be tolerated for the same
limited period of time.
All incoming traffic is relayed through a Dual Stack Mobility Agent
([DS-MIP]) that is enhanced with 6to4 capabilities. It takes
advantage of the 6to4 infrastructure that already is in place and
reaches the dual stack host by means of appropriate encapsulation.
Section 4 demonstrates how a dual stack mobile node can get full,
transparent, layer-3 mobility for both IPv4 traffic and IPv6 traffic
by combining the mechanism in section 3 together with Mobile IPv6
(MIPv6). This mobility is offered no matter if the dual stack mobile
node roams IPv4-only networks or 6to4 networks. [MOB-REQS] treats
this problem in more detail.
2. Terminology
TBD
3. IPv4 communication over 6to4 by means of a Dual Stack Home Agent
The dual stack host uses a Dual Stack Mobility Agent (DSMA),
specified in [DS-MIP], to accommodate IPv4 communication with any
correspondent node on the IPv4 Internet. DSMA is located somewhere on
the IPv4 Internet while the dual stack host is located in some 6to4
Engelstad [Page 2]
INTERNET DRAFT 6to4 v4v6 mobility
domain.
To make this draft simple, we assume that the DSMA operates as an
IPv4 home agent for the dual stack host, i.e. it receives un-tunneled
IPv4 packets destined for a dual stack host's IPv4 home address that
are sent from any correspondent IPv4 node on the IPv4 Internet. (How
DSMA can operate as an IPv4 foreign agent is shown in [DS-MIP].)
3.1. IPv4-to-IPv6 bindings in the Address Translation List
DSMA have an Address Translation List (ATL), which keeps a permanent
fixed binding between the IPv4 home address and the IPv6 6to4 address
of a dual stack host. The binding is used to reach the dual stack
host in the 6to4 domain.
(If the dual stack host implements Mobile IPv4 (MIPv4) it may
register this binding dynamically and on the fly, using the MIPv4
registration mechanisms specified in [DS-MIP]. This may be required
if the dual stack host does not have a permanent IPv4 address with
DSMA and has to do IPv4 home address discovery as outlined in [DS-
MIP]. Otherwise, the dual stack host is not required to implement
MIPv4.)
DSMA implements also a binding cache that contains IPv6 address
mappings. It is updated by means of regular MIPv6 binding updates, as
specified in [MIPv6].
3.2. Packet forwarding
DSMA uses the Address Translation List to forward IPv4 packets to the
dual stack hosts, as explained in [DS-MIP]. The entry in the Address
Translation List includes a binding between an IPv4 address and an
IPv6 address and a binding type that indicates how the IPv4 packet
shall be forwarded to the IPv6 address in the binding. This draft is
concerned with the "6to4-binding type" ([DS-MIP]),
The "6to4-binding type" mandates that when DSMA receives an IPv4
packet destined for the IPv4 home address of the host, it
encapsulates the IPv4 packet in an IPv6 header using the 6to4 address
found in the Address Translation List for that IPv4 home address.
After the Address Translation List lookup, DSMA checks the IPv6
address registered in the Address Translation List with the MIPv6
binding cache:
Engelstad [Page 3]
INTERNET DRAFT 6to4 v4v6 mobility
- If DSMA has an entry for the registered IPv6 address in the
cache, DSMA will use the IPv6 care-of-address from the binding
cache as the destination address, while the IPv6 address
registered in the Address Translation List is put in the IPv6
Routing Header of the packet. This mechanism is explained in
[MIPv6] and [IPv6].
- If DSMA has no binding cache entry for the IPv6 address, on the
other hand, the destination address is the IPv6 address registered
in the Address Translation List, and no IPv6 Routing Header is
needed.
Finally, when forwarding the resulting IPv6 packet, DSMA acts like
any other 6to4 router: It encapsulates the 6to4 packet into the
corresponding IPv4 header (i.e. the IPv4 destination address is
derived from the 6to4 destination address).
The resulting IPv4-in-IPv6-in-IPv4 packet is forwarded over the IPv4
Internet to the designated 6to4 router, which decapsulates it and
forwards the resulting IPv4-in-IPv6 packet to the dual stack host.
The host decapsulates the packet and hands the remaining IPv4 packet
over to the IPv4 protocol stack.
The architecture for incoming communication is illustrated below.
+------------------------+
| IPv4 Internet |
| |
| +------------+ | +----+
| |6to4-enabled| <-- | <-|CNv4|
| | DSMA | | +----+
| +------------+ |
| | |
| V |
| +------------+ |
| | 6to4 | |
+-----+ designated +-----+
| | router | |
| +------------+ |
| | |
| V |
| +----+ |
| |host| |
| +----+ |
| |
| 6to4 enabled IPv6 |
| Network |
Engelstad [Page 4]
INTERNET DRAFT 6to4 v4v6 mobility
+------------------------+
Figure 1. The figure illustrates how incoming IPv4 traffic can be
run over a 6to4-enabled DSMA to reach a dual stack host in a 6to4
network. This figure illustrates the case where DSMA operates as
the MIPv4 home agent of the dual stack host.
3.4. Backward Tunneling
The dual stack host may use any appropriate transition mechanism to
get reverse (outgoing) IPv4 traffic back onto the IPv4 Internet from
the 6to4 domain where it is located.
However, if no such mechanisms are available, it may tunnel the IPv4
packets back to DSMA over the 6to4 domain and the IPv4 Internet. It
encapsulates the IPv4 packet in an IPv6 header. The dual stack host
forms a 6to4 address from DSMA's IPv4 agent address and uses this as
the destination address of the IPv6 header. The lower 80 bits are set
to an appropriate value - it depends on ongoing work in the NGTRANS
working group. The packet will be encapsulated by a 6to4 router and
forwarded over the IPv4 Internet to DSMA.
The DSMA must be able to receive and recognize such packets. It
decapsulates the packet and sends the packet into the IPv4 domain. We
refer to this as "backward tunneling".
If the inner IPv4 packet is not destined for DSMA itself, DSMA should
check that DSMA has registered a binding for the IPv4 and IPv6 source
addresses of the two inner IPv4 and IPv6 headers. If the packet
passes the security check, DSMA chops off the outer IPv4 and IPv6
headers, and the inner IPv4 packet is injected into the IPv4 domain.
3.5. Route optimization
When the dual stack host moves to a new 6to4 address, it sends a
binding update to DSMA. It may use the same mechanism as for backward
tunneling, but the inner IPv4 datagram is naturally not necessary.
The binding update will change the binding cache, and ensure that the
incoming IPv4 packets are forwarded to the new 6to4 address.
3.6. Location of 6to4-enabled DSMA
Note that neither forward tunneling nor backward tunneling requires
Engelstad [Page 5]
INTERNET DRAFT 6to4 v4v6 mobility
that DSMA have an IPv6 interface, although it must be capable of
intercepting IPv6 headers and binding updates. Packets are received
and sent on the IPv4 interface. Thus, our scheme allows DSMA to be
located anywhere on the IPv4 Internet. (The IPv6 address of the
internal IPv6 interface is the 6to4 address that is formed from the
IPv4 agent address.)
3.7. A dual stack host that roams an IPv4-only network
When a mobile dual stack host roams an IPv4-only network, it may
still use the scheme described in this draft, although it does not
implement Mobile IPv4:
- It acquires an IPv4 care-of-address by some means that are outside
the scope of this draft.
- It forms a 6to4 care-of-address from the IPv4 care-of-address.
- It sends a binding update that ensures that DSMA will forward
incoming IPv4 packets to its IPv4 care-of-address.
- The dual stack host decapsulates the IPv4-in-IPv6-in-IPv4 packets
destined for itself.
MIPv4 is naturally more efficient. Nevertheless, this scheme provides
connectivity in cases where the mobile node does not implement MIPv4.
4. 6to4 Mobility
As this section is concerned with mobility we will denote the dual
stack host as the "mobile node".
The mobile node can get full, transparent, layer-3 mobility for both
IPv4 traffic and IPv6 traffic by combining the mechanism outlined
above with Mobile IPv6 (MIPv6). This mobility is offered no matter if
the dual stack mobile node roams IPv4-only networks or 6to4 networks.
There are 4 cases to consider:
1) The mobile node wants IPv4 connectivity and roams a 6to4
network. This case was covered in section 3.1 through 3.6.
2) The mobile node wants IPv4 connectivity and roams an IPv4-only
network. This case was covered in section 3.7.
3) The mobile node wants IPv6 connectivity and roams 6to4
networks. The mobile node simply gets the traffic forwarded by the
MIPv6 home agent.
Engelstad [Page 6]
INTERNET DRAFT 6to4 v4v6 mobility
4) The mobile node wants IPv6 connectivity and roams IPv4-only
networks. The solution to this is outlined below.
Scenario 4 requires no protocols and no new changes to 6to4 or MIPv6.
[DUALSTACK-MOVING], on the other hand, which uses a similar mechanism
to solve the same problem, requires changes to the MIPv6 protocol:
They require that traditional MIPv4 and MIPv6 home agents are dual
stack and announce their IPv4 addresses in MIPv6 agent
advertisements.
We argue that it is better to keep existing mobility protocols
unchanged, and let the transition-mobility problem be handled
entirely by DSMA. DSMA does not require any changes to MIPv4 or
MIPv6, although its own specification is based on code re-use from
the existing MIPv4 specification.
The remainder of section 4 shows how a dual stack mobile node can
communicate by means of 6to4 and MIPv6, even while connected to
IPv4-only networks.
4.1. Assumptions
We assume that the mobile node implements Mobile IPv6 (MIPv6) and
that the MIPv6 home agent has an IPv6 6to4 address (i.e. 6to4 is
implemented in the home domain). The mobile node may acquire the 6to4
address of the home agent through regular MIPv6 agent advertisements.
We also assume that the dual stack mobile node is able to encapsulate
and decapsulate outgoing and incoming packets: While connected to
IPv4-only networks, the mobile node operates as its own designated
6to4 router.
4.2. Registration of 6to4 address with Mobile IPv6 home agent
The dual stack mobile node registers as follows:
- When the mobile node connects to the IPv4-only network, it
acquires an IPv4 care-of-address by some method that is outside
the scope of this document.
- The mobile node forms an IPv6 6to4 address from its IPv4 care-
of-address. This 6to4 address is used as the mobile nodes IPv6
care-of-address.
- The mobile node constructs a MIPv6 binding update with this IPv6
Engelstad [Page 7]
INTERNET DRAFT 6to4 v4v6 mobility
care-of-address.
- The mobile node tunnels (IPv6-in-IPv4) the IPv6 binding update
to the MIPv6 home agent. The IPv4 destination address of the outer
header is extracted from the IPv6 6to4 address that is the agent
address of the MIPv6 home agent. Thus, the binding update will be
tunneled to the designated router in the home domain.
- The designated router decapsulates the packet and sends it to
the MIPv6 home agent. The mobile IPv6 home agent does not need to
have any knowledge of the fact that the mobile node is not
directly connected to a 6to4 domain.
4.3. Outgoing traffic to the 6to4 correspondent node
In order to send outgoing traffic to the 6to4 correspondent node, the
mobile node inspects the 6to4 address of the correspondent node. It
extracts the IPv4 address of the designated router of the
correspondent node from the correspondent node's 6to4 address. The
mobile node tunnels (IPv6-in-IPv4) all packets to the designated
router of the correspondent node.
4.4. Incoming traffic before route optimization
The MIPv6 home agent will receive the incoming traffic from the
correspondent node. It encapsulates the packets in a new IPv6 header
that carries the 6to4 destination address of the mobile node.
A 6to4 router in the 6to4 domain of the home agent will receive the
packet, inspect the 6to4 destination address, and tunnel the packet
over the IPv4 Internet to the mobile nodes IPv4 care-of-address, in
line with the 6to4 specification.
The mobile node must decapsulate the incoming IPv6-in-IPv6-in-IPv4
packet.
4.5. Incoming traffic after route optimization
The mobile node performs route optimization by sending a MIPv6
binding update to the correspondent node. The correspondent node will
thereafter send the packets directly to the new 6to4 address
according to the MIPv6 specification. A 6to4 router in the domain
where the correspondent node is located will receive the packet, and
tunnel it over IPv4 directly to the mobile node.
Engelstad [Page 8]
INTERNET DRAFT 6to4 v4v6 mobility
5. Security Considerations
The scheme presented in this document relies on the same security
mechanisms that Mobile IPv4, Mobile IPv6 and 6to4 use. To our
knowledge, it does not introduce new security exposures beyond these
protocols.
References
[MIPv4] C.E. Perkins, "IP Mobility Support", IETF RFC 2002, October
1996.
[MIPv6] D.B. Johnson and C.E. Perkins, "Mobility Support in IPv6",
<draft-ietf-mobileip-ipv6-11.txt>, March 2000, Work in Progress.
[DUALSTACK-MOVING] s. Tsao, G. Tsirtsis, and W. Boehm, "Moving in a
Dual Stack Internet", <draft-ietf-ngtrans-moving-00.txt>, July 2001,
Work in Progress..br
[6to4] B. Carpenter and K. Moore, "Connection of IPv6 Domains via
IPv4 Clouds", IETF RFC 3056, February 2001.
[DS-MIP] P. Engelstad, "Transitional Integration of Mobile IPv4 and
Mobile IPv6", <draft-engelstad-ngtrans-mipv4-over-mipv6-01.txt>,
August 2001, Work in Progress.
[MOV-REQS] P. Engelstad, "Requirements to mobility while
transitioning from IPv4 to IPv6", <draft-engelstad-ngtrans-mobility-
requirements-00.txt>, August 2001, Work in Progress.
Author's address
Paal E. Engelstad
Telenor R&D, Palo Alto
399 Sherman Ave. Suite #12
Palo Alto, CA 94306, USA
Tel.: + 1-650- 714 7537
e-mail: paal@telenorisv.com
Feel free to contact me directly on this e-mail address, or through
NGTRANS WG's mailing list on ngtrans@sunroof.eng.sun.com, if you have
comments or opinions regarding this draft. Your comments are welcome!
Engelstad [Page 9]
