Internet DRAFT - draft-engelstad-ngtrans-mipv4-over-mipv6
draft-engelstad-ngtrans-mipv4-over-mipv6
INTERNET DRAFT P. Engelstad
Telenor R&D
Expires February 9. 2002 August 9. 2001
Transitional Integration of Mobile IPv4 and Mobile IPv6.
<draft-engelstad-ngtrans-mipv4-over-mipv6-01.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 dual stack mobile node can be reached and
communicate by means of both IPv4 and IPv6, even in situations where
the mobile node is in reach of only either IPv4 or IPv6 networks. A
Dual Stack Mobility Agent accommodates mobility and translates
between IPv4 and IPv6 traffic. It may operate as a mobility agent in
its own right or as a module that relays traffic between existing
single stack Mobile IPv4 and Mobile IPv6 home agents.
1. Introduction
When a dual stack mobile node roams IPv4 and IPv6 networks, it may
Engelstad [Page 1]
INTERNET DRAFT Dual Stack Mobile IP
use a Dual Stack Mobility Agent to accommodate IPv4 connectivity and
mobility, even while in reach of only IPv6 networks.
The problem of maintaining IPv4 communication while roaming IPv6
access networks has also been addressed by [SIIT-DSTM] and [NGTRANS-
MOVING]. The former of these proposals, however, do not offer
transparent IPv4 mobility, because incoming traffic destined for a
mobile node's IPv4 home address will not reach it. The latter is only
restricted to DSTM ([DSTM]) and requires changes to the Mobile IPv4
and Mobile IPv6 protocols, although transition mechanisms will be
used (hopefully) for only a limited period of time.
The Dual Stack Mobility Agent that is defined in this draft, on the
other hand, provides full transparent layer3 mobility and IPv4
connectivity while roaming IPv6 access networks, without requiring
any changes to existing protocols.
A mobile node uses an IPv4 home address (or care-of-address) with a
network prefix that assures that the Dual Stack Mobility Agent can
receive it. The agent keeps a binding between the IPv4 home address
and an IPv6 address that can be used to reach the mobile nodes in the
IPv6 domain. It receives un-tunneled IPv4 packets destined for a
mobile node's IPv4 home address (or tunneled IPv4-in-IPv4 packets
destined for the mobile node's IPv4 care-of-address). The Dual Stack
Mobility Agent tunnels the (inner) IPv4 packets to the IPv6 address
in the binding.
The mobile node can set the address bindings in the Dual Stack
Mobility Agent dynamically and on the fly. To register a binding with
the agent, it uses nearly the same registration messages and
registration procedures as for Mobile IPv4. The mobile node adds an
"IPv6 Address Extension", which is specified in section 5 of this
draft, to the Mobile IPv4 Registration Request.
The Dual Stack Mobility Agent can either relay traffic between
existing single stack home agents, or it can operate as a mobility
agent in its own right.
The Dual Stack Mobility Agent, like any other mobility agent, shows
its strength during the initial stage of communication: It offers
transparent connectivity to fixed IPv4 and IPv6 home addresses - just
like Mobile IP does. However, it also introduces additional overhead,
as well as potential bottlenecks and single points of failure (like
also Mobile IP does). Thus, it might be favorable to perform Route
Optimizations during the initial stages of the communication session.
The communication may be "handed over" to another transition
mechanism - preferably one that is stateless and efficient.
Engelstad [Page 2]
INTERNET DRAFT Dual Stack Mobile IP
The Dual Stack Mobility Agent modularizes the integration of Mobile
IPv4 and Mobile IPv6. One may plug it into or take it out of a
Mobile-IP-enabled network without influencing the functionality of
existing mobility agents. It may also shield the single stack Mobile
IP agents from all knowledge of dual stack functionality and of
existing transition mechanisms. All such functionality is located in
the Dual Stack Mobility Agent without adding additional requirements
to existing IPv4 or IPv6 mobility agents.
Note that this draft focuses on how to ensure IPv4 connectivity when
the mobile node is attached to only IPv6 networks. Maintaining IPv6
connectivity while only in reach of IPv4 networks, on the other hand,
is not yet treated. This requires that the Dual Stack Mobility Agent
perform IPv6-to-IPv4 address mapping, which may be embedded into this
draft at a later stage.
Table of Content
1. Introduction .............................................. 1
2. Terminology ............................................... 3
3. Overview .................................................. 4
3.1. DSFA located in the home domain ......................... 4
3.2. DSHA located in the home domain ......................... 6
3.3. DSFA located in the visited domain ...................... 7
4. Dual Stack Mobility Agent Functionality ................... 7
4.1. Address Translation List (ATL)........................... 8
4.2. DSMA Packet Forwarding .................................. 9
4.3. ATL Registrations ....................................... 9
4.4. DSMA Backward tunneling ................................. 10
4.5. DSMA Reverse tunneling .................................. 12
4.6. DSMA Discovery .......................................... 12
4.7. DSMA Capability Discovery ............................... 13
5. New message extensions .................................... 13
6. Correspondent Node Functionality .......................... 14
7. Mobile Node Functionality ................................. 14
8. Security Issues ........................................... 15
9. IANA considerations ....................................... 15
References ..................................................... 16
Author's address ............................................... 16
APPENDICES:
A. DSFA Functionality ........................................ 17
A.1. DSFA Registration ....................................... 17
A.2. DSFA Packet Forwarding .................................. 18
B. DSHA Functionality ........................................ 19
B.1. DSHA Registration ....................................... 19
B.2. DSHA Packet Forwarding .................................. 20
Engelstad [Page 3]
INTERNET DRAFT Dual Stack Mobile IP
2. Terminology
This draft uses the same terminology as introduced in [MIPv4] and
[MIPv6]. In addition the following terms are defined:
Dual Stack Mobility Agent (DSMA):
A dual stack node with a conceptual Address Translation List (ATL)
that is able to map IPv4 addresses to IPv6 addresses. DSMA receives
IPv4 packets from an IPv4 correspondent node or IPv4-in-IPv4 packets
from the Mobile IPv4 home agent of a mobile node. DSMA tunnels the
packets to the IPv6 address that the mobile node has registered in
the Address Translation List. ("Transition Agent" was chosen as an
alternative name for DSMA in the first version of this draft.)
Dual Stack Home Agent (DSHA):
A Dual Stack Mobility Agent that acts as the IPv4 home agent of the
mobile node. It receives un-tunneled IPv4 packets destined the IPv4
home address of the mobile node. DSHA tunnels the packets to the IPv6
(home or care-of-) address that the mobile node has registered with
DSHA.
Dual Stack Foreign Agent (DSFA):
A Dual Stack Mobility Agent that acts as an IPv4 foreign agent of the
mobile node. It receives IPv4-in-IPv4 packets tunneled to the IPv4
care-of-address that DSFA has provided the mobile node with. DSFA
decapsulates the packet and tunnels the inner packet to the IPv6
(home or care-of-) address that the mobile node has registered with
DSFA.
Address Translation List (ATL): A conceptual data structure that
contains bindings between IPv4 and IPv6 addresses.
The following acronyms are used in this draft:
DSMA Dual Stack Mobility Agent.
DSHA Dual Stack Home Agent
DSFA Dual Stack Foreign Agent
ATL Address Translation List.
MIPv4 Mobile IPv4 ([MIPv4]).
MIPv6 Mobile IPv6 ([MIPv6]).
HAv4 IPv4 Home Agent ([MIPv4]).
HAv6 IPv6 Home Agent ([MIPv6]).
CNv4 MIPv4 Correspondent Node (Communicates by IPv4.)
CNv6 MIPv6 Correspondent Node (Communicates by IPv6.)
MN Mobile Node (Dual stack node, implements MIPv4 and MIPv6).
Engelstad [Page 4]
INTERNET DRAFT Dual Stack Mobile IP
3. Overview
3.1. DSFA located in the home domain
The Dual Stack Mobility Agent (DSMA) may be situated in the home
domain of a mobile node (MN). In that case the MN probably has been
configured with the knowledge of the DSMA; it knows its IP addresses
and capabilities, and there are mobility/binding security
associations established between MN and DSMA.
A DSMA located in MN's home domain may - from IPv4's point of view -
serve as MN's foreign agent, i.e. it operates as a Dual Stack Foreign
Agent (DSFA). MN has already a single stack Mobile IPv4 home agent
(HAv4) located in the home domain and wants to use DSFA as a means to
reach MN even in situations where MN is in reach of only IPv6
networks. MN binds its IPv4 home address to its IPv6 address, and
registers the IPv4 care-of-address that is associated with DSFA's
IPv4 interface with HAv4. HAv4 tunnels the packet to DSFA, which
decapsulates it and tunnels the inner IPv4 packet towards MN's IPv6
stack.
MN may register either its IPv6 home address or its IPv6 care-of-
address with DSFA. In the former case, MN may use an existing Mobile
IPv6 home agent (HAv6) to ensure connectivity and mobility while away
from its IPv6 home network. In the latter case, the IPv4 packets are
tunneled directly to MN's IPv6 care-of-address.
Mobile IPv4 (MIPv4) is run on top of Mobile IPv6 (MIPv6), so to
speak. How this is envisioned to work, is shown in figure 1 below.
+------------------------+
| IPv4 Internet |
| |
| +----+ | +----+
| |HAv4| <----- | <-|CNv4|
| +----+ | +----+
+-----------------+ | |
| | V |
| | +----+ |
| IPv6 +---------+DSFA+---------+
MN |(Visited network)| +----+ |
+---------+ | | (a) / | (b) |
|MIPv4 <- | | | / V |
+-------|-+ | | / +----+ | + - -+
|MIPv6 <--|<- | <---------- | <----- |HAv6| <- - - | <-|CNv6|
+---------+ | | +----+ | +- - +
+---------------- + |
Engelstad [Page 5]
INTERNET DRAFT Dual Stack Mobile IP
| IPv6 Internet |
+------------------------+
Figure 1. DSFA: A Dual Stack Mobility Agent that operates as a
foreign agent. Incoming traffic from CNv4 is forwarded towards MN.
(a): Traffic is sent directly to MN's IPv6 care-of-address.
(b): Traffic is sent via MN's IPv6 home agent.
(IPv6 communication with CNv6 is simultaneously maintained.)
3.2. DSHA located in the home domain
MN may also use a DSMA located in its home domain as an IPv4 home
agent, i.e. DSMA operates as a Dual Stack Home Agent (DSHA). In that
case DSHA receives IPv4 packets destined for MN's IPv4 home address
directly from CNv4. It tunnels the packets to the IPv6 (home or care-
of-) address that MN has registered with DSHA.
How this is envisioned to work, is shown in figure 2 below.
+------------------------+
| IPv4 Internet |
| | +----+
+-----------------+ |---------- | <-|CNv4|
| | V | +----+
| | +----+ |
| IPv6 +---------+DSHA+---------+
MN |(Visited network)| +----+ |
+---------+ | | (a) / | (b) |
|MIPv4 <- | | | / V |
+-------|-+ | | / +----+ | + - -+
|MIPv6 <--|<- | <---------- | <----- |HAv6| <- - - | <-|CNv6|
+---------+ | | +----+ | +- - +
+---------------- + |
| IPv6 Internet |
+------------------------+
Figure 2. DSHA: A Dual Stack Mobility Agent that operates as an
IPv4 home agent. Incoming traffic from CNv4 is forwarded towards
MN.
(a): Traffic is sent directly to MN's IPv6 care-of-address.
(b): Traffic is sent via MN's IPv6 home agent.
(IPv6 communication with CNv6 is simultaneously maintained.)
Many MNs do not need a permanent IPv4 address, because they need not
be permanently reachable for incoming IPv4 traffic initiated by other
Engelstad [Page 6]
INTERNET DRAFT Dual Stack Mobile IP
nodes on the Internet. Due to the scarcity of IPv4 addresses it is
desirable to let these MNs acquire IPv4 addresses dynamically. Thus,
if MN has no fixed IPv4 home address, but is configured with a
security association with the DSHA, it may use home address discovery
[HADDR-DISC] to get an IPv4 home address assigned by DSHA for the
limited period of time that it is needed.
3.3. DSFA located in the visited domain
MN may also use a DSFA in the visited domain, to play the role as a
MIPv4 foreign agent. The mechanisms that MN uses to discover DSMAs in
visited domains are beyond the scope of this draft.
How a DSMA can serve as a foreign agent in the visited domain is
shown in figure 3 below.
+------------------------+
| IPv4 Internet |
+-----------------+ |
| IPv6 | |
MN |(Visited network)| |
+---------+ | | |
|MIPv4 <- | | | |
+-------|-+ | +--+--+ +----+ | +----+
|MIPv6 <--|<- | <--------- |DSFA | <---- |HAv4| <---- | <-|CNv4|
+---------+ | +--+--+ +----+ | +----+
+---------------- + |
| |
+------------------------+
Figure 3. The mobile node uses the Dual Stack Mobility Agent as a
foreign agent. Traffic from CNv4 is forwarded towards MN.
While some other transition mechanisms (e.g. DSTM) tend to allocate a
separate IPv4 address to each user that wants to have traffic relayed
through the border node, DSFA allows all visiting MNs to share the
same IPv4 care-of-address. It is the MN's IPv4 home address in the
incoming decapsulated IPv4 packet (i.e. in the inner IPv4 header)
that determines the corresponding IPv6 care-of-address of the
visiting MN.
4. Dual Stack Mobility Agent functionality
DSMA is a dual stack router that is located on the border between an
Engelstad [Page 7]
INTERNET DRAFT Dual Stack Mobile IP
IPv4 domain and an IPv6 domain.
Seen from the IPv4 side, DSMA behaves like a MIPv4 Mobility Agent. If
it plays the role as a Foreign Agent, it receives IPv4-in-IPv4 packet
that are tunneled from the Mobile IPv4 home agent, destined for the
IPv4 care-of-address that DSMA has provided MN with. DSMA
decapsulates the packet and tunnels the inner IPv4 packet to the IPv6
address that MN has registered with it. If it plays the role as a
MIPv4 Home Agent it receives (un-tunneled) IPv4 packets directly from
the IPv4 correspondent node (CNv4), which it tunnels to the IPv6
address that MN has registered with it
DSMA's main conceptual data structure is the Address Translation List
(ATL), which binds an IPv4 address to an IPv6 address and stores
other control information associated with the binding. DSMA uses the
bindings to tunnel the IPv4 packets to the IPv6 address that MN has
registered in the ATL.
From the IPv6 side, DSMA is perceived as any other IPv6 Correspondent
Node (CNv6) that behaves according to the MIPv6 specification
([MIPv6]). Thus, when for example a HAv6 receives IPv4-in-IPv6
packets, it is only concerned with the encapsulating IPv6 header. The
packets are tunneled to MN's IPv6 stack in line with the
specifications in [MIPv6].
Like any other CNv6, DSMA has a MIPv6 binding cache associated with
its IPv6 interface, and it may receive MIPv6 binding updates on this
interface, too. Thus, packets may be route optimized and forwarded
directly to MN, circumventing the IPv6 address that MN has registered
in ATL. The MIPv6 binding cache can naturally be implemented as part
of the ATL.
4.1. The Address Translation List (ATL)
The Address Translation List (ATL) is comparable with a Mobile IPv4
binding cache. It binds an IPv4 address to an IPv6 address and stores
other control information associated with the binding including
flags, lifetime and binding types. The binding type determines how
the IPv4 packets shall be forwarded towards the IPv6 address that MN
has registered in ATL.
An entry in ATL includes:
- MN's registered IPv4 address
- MN's registered IPv6 address
- Binding type (indicating how IPv4 packets shall be forwarded to
the registered IPv6 address)
- Identification field from MIPv4 registration
Engelstad [Page 8]
INTERNET DRAFT Dual Stack Mobile IP
- Remaining lifetime of current or pending registration
- A bit that indicates if DSMA serves as a home agent or foreign
agent for MN
- Other flags (S,D,T,G,M, etc.)
DSFAs should also include:
- Home agent address
- UDP source port (for pending registrations)
- Requested registration lifetime (for pending registrations)
4.2. DSMA Packet Forwarding
Both DSFA and DSHA use the ATL to forward the IPv4 packets to MN.
(DSFA, however, must decapsulate the incoming IPv4-in-IPv4 packets
first, while DSHA receives un-tunneled packets directly from CNv4.)
The binding type mandates how IPv4 packets that DSMA receives will be
forwarded towards MN. For example:
- If the binding is of Binding Type 1 (section 5), the IPv4 packet
is encapsulated in an IPv6 header and forwarded towards MN.
Other binding types may be defined at a later stage.
After the ATL lookup, DSMA checks the IPv6 address registered in the
ATL with the MIPv6 binding cache:
- 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 ATL 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 ATL, and no IPv6 Routing Header needs to be used.
(DSMA may be configured with filters to prevent routing loops and
infinitely nested tunnels.)
4.3. ATL Registrations
If MN wants to configure the IPv4-to-IPv6 address binding in DSMA's
ATL on the fly, there are two different scenarios to consider:
1) MN has already a MIPv4 home agent and wants to use DSMA as a DSFA,
Engelstad [Page 9]
INTERNET DRAFT Dual Stack Mobile IP
i.e. as a foreign agent that receives IPv4-in-IPv4 packets.
2) MN wants to use DSMA as a DSHA, i.e. as an IPv4 home agent that
receives IPv4 packets directly from CNv4.
In both cases MN may use MIPv4 registration messages [MIPv4] with the
"IPv6 Address Extension" defined in section 5. The extension
contains the IPv6 delivery address that DSMA is requested to bind to
MN's IPv4 address. MN may use backward tunneling (section 4.4) to
tunnel the requests over IPv6 to DSMA's IPv6 interface.
4.3.1 Case 1: DSFA Registration
If MN registers with DSFA (case 1 above) it adds the "IPv6 Address
Extension" (section 5) as a non-authenticating Mobile-Foreign
extension. DSFA examines the extension and acts as a MIPv4 foreign
agent:
- If the registration request cannot be accepted it sends a
negative Registration Reply back to MN (tunneled over IPv6).
- If it can accept the request, it notes the relevant information
in a pending registration record, chops off the Mobile-Foreign
Extensions and relays the remaining standard MIPv4 Registration
Request to HAv4.
This registration procedure is treated in more detail in appendix A
of this draft. Unless otherwise stated in this document, the
registration procedure is as specified in [MIPv4].
4.3.2 Case 2: DSHA Registration
If MN registers with DSHA (case 2 above) it adds the "IPv6 Address
Extension" (section 5) as a non-authenticating Mobile-Home
extension. DSHA examines the extension and acts as a MIPv4 home
agent:
- If the registration request cannot be accepted it sends a
negative Registration Reply back to MN (tunneled over IPv6).
- If it can accept the request, it sends a positive Registration
Reply back to MN (tunneled over IPv6).
This registration procedure is treated in more detail in appendix B
of this draft. Unless otherwise stated in this document, the
registration procedure is as specified in [MIPv4].
Engelstad [Page 10]
INTERNET DRAFT Dual Stack Mobile IP
4.4. Backward Tunneling
MN may use any appropriate transition mechanism ([NGTRANS-MECH]) to
get reverse (outgoing) IPv4 traffic onto the IPv4 Internet. If no
such mechanisms are available, MN may tunnel the IPv4 packets back to
DSMA over the IPv6 domain. DSMA decapsulates the packet and sends the
packet into the IPv4 domain. We refer to this as "backward
tunneling".
All DSMAs must support backward tunneling. This ensures that a MN is
able to send IPv4 packets into the IPv4 domain even in situations
where it is only directly attached to IPv6 networks (- assuming that
the visited IPv6 network and the DSMA are interconnected by an IPv6
internet).
How backward tunneling is envisioned to work, is shown in figure 4
below.
+------------------------+
| IPv4 Internet |
| | +----+
+-----------------+ >---------> | <-|CNv4|
| | | | +----+
| | +----+ |
| IPv6 +---------+DSMA+---------+
MN |(Visited network)| +----+ |
+---------+ | | ^ |
|MIPv4 >- | | | | |
+-------|-+ | | | |
|MIPv6 >--|-> | ----------> | --------->| |
+---------+ | | |
+---------------- + |
| IPv6 Internet |
+------------------------+
Figure 4. Backward tunneling of outgoing IPv4 traffic from MN. MN
uses DSMA to reach a CNv4.
If the inner packet is not destined for DSMA itself, DSMA should
check that it has registered a binding for the IPv4 and IPv6 source
addresses of the tunneled packet. DSMA must take into account that
MN's actual IPv4 home address may be placed in the IPv6 Home Address
Option instead of in the IPv6 source address as explained in [MIPv6].
DSMA may also let IPv4 multicast addresses pass as IPv4 source
addresses. DSMA may require AH authentication.
When MN sends MIPv4 registration messages to DSMA in order to update
Engelstad [Page 11]
INTERNET DRAFT Dual Stack Mobile IP
a binding in ATL, it may tunnel the messages over IPv6. After
decapsulation, DSMA will push the registration message in the inner
IPv4 packet up the protocol stack in the same way that it will do
with un-tunneled registration messages.
Normally the destination address of the IPv4 header in the
registration request is DSMA's own IPv4 agent address, and the source
address is MN's IPv4 home address. However, when MN tunnels the
registration message to DSMA, it may use the "All-mobility-Agent"
Multicast Address as the IPv4 destination address. MN may use the
unspecified 0.0.0.0-address as a source address in tunneled requests
if MN performs home address discovery [HADDR-DISC] and has not yet
received its IPv4 home address.
Note that the IPv6 headers of any of the backward-tunneled packets
may contain MIPv6 Binding Updates that may update entries in the
MIPv6 binding cache of DSMA.
(One may consider DSMA as an IPv4 mobility agent that uses the entire
IPv6 Internet as its L2 link, and delivers IPv4 packets to MNs over
this link. In this model backward tunneling corresponds to using DSMA
as MN's default router.)
4.5. DSMA Reverse Tunneling
Reverse Tunneling [REVERSE-TUN] lets packets be tunneled back to the
IPv4 home agent, which decapsulates the packet and sends the inner
IPv4 packet onto the Internet.
For a DSHA, Reverse Tunneling is the same as backward tunneling
(above).
If MN requests Reverse Tunneling from an DSFA, on the other hand,
backward tunneled packets that have been decapsulated are re-tunneled
back to the home agent, instead of being sent onto the IPv4 Internet
from DSFA's own IPv4 interface.
DSMAs should support reverse tunneling.
4.6. DSMA Discovery
DSMA discovery is for further study.
DSMAs may for example broadcast some special MIP Agent Advertisements
on home networks, and other places DSMAs may be discovered by other
mechanisms such as DHCP. Dual Stack Transition Mechanism [DSTM]
Engelstad [Page 12]
INTERNET DRAFT Dual Stack Mobile IP
includes an example of such an address acquisition method.
Many MNs, however, will probably not need to discover the DSMA. They
have been configured with a list of one or more DSMAs; it knows their
IPv6 addresses and maybe also their capabilities.
4.7. DSMA Capability Discovery
If MN knows the IPv6 agent address of a DSMA but not its IPv4 agent
address, it may tunnel a MIPv4 Registration Request to DSMA with the
Home Agent Address field containing the "All-Mobility-Agent"
multicast address. DSMAs must respond to such a request by tunneling
back to MN a negative Registration Reply (code 133) that contains the
agent address.
If MN knows the IPv6 and IPv4 agent addresses of a DSMA but not its
capabilities or care-of-address(es), it may tunnel an Agent
Solicitation containing an "IPv6 Address Extension" (section 5) to
DSMA. DSMA responds by tunneling a MIPv4 Agent Advertisement
containing an "IPv6 Address Extension" (section 5) back to MN. (The
details of this are for further study.)
If MN has a network address identifier (NAI), knows the IPv6 and IPv4
addresses of a DSMA that may serve as a home agent (DSHA), and has
Mobile-Home Security Association with this DSMA, it may use the
mechanism described inn [HADDR-DISC] to discover its own home
address.
In the remaining of this draft we assume that MN knows DSMA's IP
addresses and its capabilities. MN may have been configured with a
specific DSMA or acquired the information by other means.
5. New message extensions
MIPv4 registration requests that are directed at DSMA in order to set
an IPv4-to-IPv6 binding MUST include the "IPv6 Address Extension"
defined in this document. It has the following format:
IPv6 Address Extension:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Binding Type | (reserved) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 address |
Engelstad [Page 13]
INTERNET DRAFT Dual Stack Mobile IP
+ +
| |
+ +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: TBD. The extension type must be given a number between 0 and
127 to ensure that a recipient that does not understand the extension
silently discards the registration message.
Length: 20
Binding Type: Indicates how DSMA shall forward IPV4 packets towards
MN's IPv6 address. The first bit from the left denotes binding type
1, the second bit from the left denotes binding type 2 and so forth:
- Binding Type 0: Unspecified.
- Binding Type 1: IPv4 packets are delivered by means of standard
IPv4-in-IPv6 encapsulation.
IPv6 address: The IPv6 (home or care-of-) address that MN wants to
bind to its IPv4 address in DSMA's ATL.
If DSMA is requested to act as a home agent (DSHA), the extension is
added as a mobile-home non-authentication extension, and the IPv4
home agent address in the Registration Request is DSMA's own agent
address.
If the registration message requests the DSMA to act as a foreign
agent (DSFA), the extension is added as a mobile-foreign non-
authentication extension, and the IPv4 home agent address in the
Registration Request is not DSMA's own agent address.
TBD: New registration reply codes (if necessary).
6. Correspondent Node Functionality
Correspondent nodes are unaffected by the scheme specified in this
draft, although they may be affected by the requirements in [MIPv4]
and [MIPv6].
7. Mobile Node Functionality
Engelstad [Page 14]
INTERNET DRAFT Dual Stack Mobile IP
IPv4 and IPv6 communication can be maintained independently: IPv4-in-
IPv6 packets destined for MN are decapsulated and the inner IPv4 is
handed over to the IPv4 protocol stack, while pure IPv6 and MIPv6
traffic, on the other hand, is handed to the IPv6 protocol stack.
Therefore, the MIPv4 module can chose between MIPv4-over-MIPv6 and
pure MIPv4 connectivity, depending on the IP-version(s) run on the
network(s) in reach.
MIPv6 works more or less transparently to MIPv4. When running
MIPv4-over-MIPv6, for example, the MIPv6 tunnel is perceived as a
fixed connection from MIPv4's point of view. The MIPv4 module does
not need to worry about agent detection, acquisition of IPv4 care-of-
addresses, FA registrations, HA registrations, binding updates and so
forth. Mobility is entirely handled by MIPv6.
Note that the details of how MIPv4 and MIPv6 is integrated inside MN,
and how it works in conjunction here, is beyond the scope of this
draft. The idea of an address-mapper, which was outlined in [ADDRESS-
MAPPER], might be applicable.
8. Security Issues
Our scheme implements the same security mechanisms that Mobile IP
does.
The IPv6 part of a DSMA, for example, should share a security
association with MN or HAv6, like a CNv6 in [MIPv6]. The IPv4 side of
DSMA should share a security association with MN or HAv4, like a FA
in [MIPv4].
Often it will be as easy to distribute a "mobility security
association" or "binding security association" between MN and DSMA,
as it is between MN and its home agents. This makes binding updates
and registrations directed at DSMA easy to implement without any
Public Key Infrastructure (PKI) in place.
The schemes outlined in this draft are based on extensive use of
tunneling. Secure tunneling, including requirements for IPsec AH for
reverse tunneling, may be addressed in subsequent versions of the
document.
9. IANA Considerations
TBD
Engelstad [Page 15]
INTERNET DRAFT Dual Stack Mobile IP
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.
[NGTRANS-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.
[SIIT-DSTM] 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.
[NGTRANS-MECH] W. Biemolt et. al., "An overview of the introduction
of IPv6 in the Internet", July 2001, Work in Progress.
[REVERSE-TUN] G. Montenegro (ed.), "Reverse Tunneling for Mobile IP,
revised", IETF RFC 3024, January 2001.
[DSTM] J. Bound et.al, "Dual Stack Transition Mechanism (DSTM)",
<draft-ietf-ngtrans-dstm-04.txt>, July 2001, Work in Progress.
[ADDRESS-MAPPER] S. Tsao, J. Liu and W. Boehm, " Mobility Support
for IPv4 and IPv6 Interconnected Networks based on Dual-Stack Model
", <draft-tsao-mobileip-dualstack-model-02.txt>, March 2001, Work in
Progress.
[6to4] B. Carpenter and K. Moore, "Connection of IPv6 Domains via
IPv4 Clouds", IETF RFC 3056, February 2001
[HADDR-DISC] P. Calhoun and C.E. Perkins, "Mobile IP Network Access
Identifier Extension for IPv4", IETF RFC 2794, January 2000.
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
Engelstad [Page 16]
INTERNET DRAFT Dual Stack Mobile IP
NGTRANS WG's mailing list on ngtrans@sunroof.eng.sun.com, if you have
comments or opinions regarding this draft. Your comments are welcome!
APPENDIX:
A. DSFA Functionality
A.1. DSFA Registration
MN may use MIPv4 registration messages [MIPv4] with extensions
defined in this draft to configure on the fly the IPv4-to-IPv6
address binding in DSFA's ATL.
Unless otherwise stated in this document, the registration procedure
is as specified in [MIPv4].
Upon reception of the request DSFA acts as follows:
- It will note that it is requested to act as a foreign agent (i.e. a
DSFA).
- DSFA performs the Mobile-Foreign Authentication.
- It processes the "IPv6 Address Extension" and other non-
authentication Mobile-Foreign extensions.
- DSFA prepares to bind MN's IPv4 home address (in the home address
field of the registration request) to MN's IPv6 address (in the IPv6
address extension). I.e. it notes down all relevant information from
the request message in a pending registration record. (No actual
changes are done in the ATL before it receives a successful
registration reply from HAv4.)
- It chops off the "IPv6 Address Extension" and other Mobile-Foreign
extensions and forwards the remaining Mobile-Home part of the
registration request to MN's HAv4.
If DSFA receives a successful registration reply from HAv4, it will
use the noted information to update the ATL. The registration reply
is forwarded back to MN, using the forwarding mechanism that the
binding in ATL mandates.
All other fields in the registration request have the same values and
meaning as in MIPv4. However, the scheme in this draft may add
further requirements.
The MIPv4 registration request takes the following form:
Type: 1 (Registration Request)
S: MN can set the bit freely as it concerns only home agent behavior.
Engelstad [Page 17]
INTERNET DRAFT Dual Stack Mobile IP
DSFA will ignore the value of this bit.
B: MN can set the bit freely as it concerns only home agent behavior.
DSFA will ignore the value of this bit.
D: Not set. This ensures that broadcast and multicast packets (if
requested by MN) will be encapsulated in an IPv4 header carrying MN's
IPv4 home address before they are tunneled to DSFA. Otherwise, DSFA
would not have a chance to know where to send these packets.
M: Only set if MN knows that DSFA supports Minimal encapsulation.
Alternatively, DSFA will always accept the mandatory IP-in-IP
encapsulation.
G: Only set if MN knows that DSFA supports GRE encapsulation.
Alternatively, DSFA will always accept the mandatory IP-in-IP
encapsulation.
r: Value and meaning determined by [MIPv4].
T: Set if MN requests Reverse Tunneling, i.e. backward tunneled
packets from MN are re-tunneled back to home agent. If un-set, on the
other hand, backward-tunneled packets are injected directly into the
IPv4 domain at DSFA.
x: Value and meaning determined by [MIPv4].
Lifetime: Registration lifetime in seconds in line with [MIPv4].
Home Address: The IPv4 home address that the mobile node registers in
the ATL.
Home Agent: The IPv4 address of the mobile node's home agent. (This
must not be an address of DSFA's own interfaces.)
Care-of Address: The IPv4 care-of-address that DSFA provides MN with.
Identification: A 64-bit number that is used in line with [MIPv4].
Extensions: The registration request must include the "IPv6 Address
Extension" that is defined in section 5. The extension is added as a
Mobile-Foreign non-Authentication Extension ([MIPv4]). It contains
the IPv6 (home or care-of-) address that MN wants to register in ATL.
It also contains a binding type, which mandates how IPv4 packets must
be tunneled to reach the IPv6 address.
MN may tunnel the request over DSFA's IPv6 interface.
The registration reply from HAv6 has the same format as in [MIPv4]
and is processed in line with [MIPv4]. DSFA relays tunnels the reply
to MN. (TBD: Should the also reply from DSFA to MN contain the IPv6
Address Extension?)
A.2. DSFA Packet Forwarding
If DSFA receives an IPv4-in-IPv4 packet that is destined for DSFA's
IPv4 care-of-address(es), it should decapsulate the packet. DSFA uses
the destination address of the inner IPv4 packet and the bindings in
the address translation list (ATL) to forward the packet. If ATL
Engelstad [Page 18]
INTERNET DRAFT Dual Stack Mobile IP
contains a valid binding for that IPv4 destination address, and the
entry shows that this DSMA is registered to serve as a DSFA for MN,
information in the ATL entry determines how the packet shall be
forwarded. (Normally the IPv4 packet will be tunneled to the IPv6
address specified in the binding.)
Note that DSFA may be able to intercept different IPV4 encapsulation
formats including Minimal Encapsulation and GRE Encapsulation in
addition to the mandatory IP in IP encapsulation. In this draft we
use IPv4-in-IPv4 as a generic term for all the encapsulation formats
received by DSFA, unless explicitly stated.
Tunneled packets that cannot be forwarded should be silently
discarded.
B. DSHA Functionality
B.1. DSHA Registration
MNs may use MIPv4 registration messages [MIPv4] with the "IPv6
Address Extension" defined in this draft to configure on the fly the
IPv4-to-IPv6 address binding in DSHA's ATL.
Upon reception of the registration request, DSHA acts as follows:
- It will note that it is requested to act as an IPv4 home agent
(i.e. a DSHA).
- DSHA performs Mobile-Home Authentication.
- It processes the "IPv6 Address Extension" and other non-
authentication Mobile-Foreign extensions.
- If the home address field is zero, DSHA dynamically allocates an
IPv4 home address to MN, in line with [HADDR-DISC].
- If the request is accepted, DSHA binds MN's IPv4 home address to
MN's IPv6 address (in the IPv6 Address Extension). It adds an entry
in the address translation list.
- DSHA generates a MIPv4 registration reply, in line with [MIPv4].
- It encapsulates the registration reply in an IPv6 header according
to the ATL binding, and tunnels the reply to MN.
Unless otherwise stated in this document, the registration procedure
is as specified in [MIPv4].
The MIPv4 registration request takes the following form:
Type: 1 (Registration Request)
S: May be set if MN knows DSHA supports Simultaneous Bindings.
Engelstad [Page 19]
INTERNET DRAFT Dual Stack Mobile IP
B: May be set if MN knows that DSHA supports forwarding of
broadcasted diagrams.
D: May only be set if MN is capable of accepting broadcast and
multicast packets (if requested by MN) that are tunneled to MN's IPv6
address (without first have been encapsulated by an IPv4 packet that
carries MN's IPv4 home address).
M: Not set.
G: Not set.
r: Value and meaning determined by [MIPv4].
T: Should be set. Ignored by DSHA, because it must support backward
tunneling anyway. (Backward and reverse tunneling are the same as far
as DSHAs are concerned).
x: Value and meaning determined by [MIPv4].
Lifetime: Registration lifetime in seconds in line with [MIPv4].
Home Address: MN's IPv4 home address if DSHA has already allocated
this address to MN. Otherwise, it may be set to zero to ask DSHA to
allocate an IPv4 home address, which it will add to the home address
field of the registration reply. The IPv4 address is IPv4 address
that is registered in ATL.
Home Agent: The IPv4 address of DSHA.
Care-of Address: Set to zero. The IPv6 care-of-address is found in
the "IPv6 Address Extension" (below).
Identification: A 64-bit number that is used in line with [MIPv4].
Extensions: The registration request must include the "IPv6 Address
Extension" that is defined in section 5. The extension contains the
IPv6 (home or care-of-) address that MN wants to register in ATL. The
extension is added as a mobile-home non-authentication extension.
The registration reply from DSHA has the same format as in [MIPv4]
and is tunneled to MN. (TBD: Should the reply from DSHA to MN contain
the IPv6 Address Extension?)
B.2. DSHA Packet Forwarding
A DSMA that serves as a home agent (DSHA) must examine the IPv4
destination address of all arriving packets to check if it is equal
to the home address of any of the MNs that are registered with it.
Information in the ATL entry determines how the packet shall be
forwarded on behalf of a MN. (Normally the IPv4 packet will be
tunneled to the IPv6 address specified in the binding.)
If DSHA is not a virtual network ([MIPv4]), MN may request forwarding
of broadcast packets. If DSHA is a multicast router, MN may request
forwarding of multicast packets. If the D bit is set DSHA will tunnel
broadcast and multicast packets directly to MN's IPv6 delivery
address. Otherwise, DSMA first encapsulates broadcast and multicast
Engelstad [Page 20]
INTERNET DRAFT Dual Stack Mobile IP
packets, using in an IPv4 header that carries MN's IPv4 home address,
before they are tunneled over IPv6 to MN.
Engelstad [Page 21]
