One document matched: draft-thubert-nemo-ipv4-traversal-00.txt
Network Working Group P. Thubert
Internet-Draft M. Molteni
Expires: August 2, 2003 P. Wetterwald
Cisco Systems
February 2003
IPv4 traversal for MIPv6 based Mobile Routers
draft-thubert-nemo-ipv4-traversal-00
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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 August 2, 2003.
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract
Since IPv6 connectivity is not yet broadly available, there is a need
in NEMO for a simple technology that allows a MIPv6 based Mobile
Router to roam over IPv4 networks.
The Doors Protocol proposed in this memo allows an arbitrary Mobile
Node to roam even within private IPv4 address spaces, across both
Network and Port Address Translations, in order to cope with existing
of deployments of technologies such as GPRS.
Thubert, et al. Expires August 2, 2003 [Page 1]
Internet-Draft Doors February 2003
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology and concepts . . . . . . . . . . . . . . . . . . 3
2.1 Doors Handle . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2 Other definitions . . . . . . . . . . . . . . . . . . . . . 5
3. Basic MIPv6 Doors support . . . . . . . . . . . . . . . . . 5
3.1 Known Restrictions . . . . . . . . . . . . . . . . . . . . . 7
3.2 Operation for a MIPv6 Mobile Node roaming over IPv4 . . . . 7
3.2.1 Sending packets over the Doors tunnel . . . . . . . . . . . 8
3.2.2 Receiving packets over the Doors tunnel . . . . . . . . . . 9
3.3 Operation for the Home Agent of a MIPv6 MN roaming over IPv4 9
3.3.1 Receiving packets over the Doors tunnel . . . . . . . . . . 9
3.3.2 Sending packets over the Doors tunnel . . . . . . . . . . . 11
4. Distributed configurations . . . . . . . . . . . . . . . . . 12
4.1 Hierarchical MIP . . . . . . . . . . . . . . . . . . . . . . 12
4.2 Reverse Routing Header . . . . . . . . . . . . . . . . . . . 12
5. IANA considerations . . . . . . . . . . . . . . . . . . . . 16
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16
References . . . . . . . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 17
Full Copyright Statement . . . . . . . . . . . . . . . . . . 18
Thubert, et al. Expires August 2, 2003 [Page 2]
Internet-Draft Doors February 2003
1. Introduction
This document assumes that the reader is familiar with Mobile IPv6
defined in [1], with the concept of Mobile Router (MR) and with the
Nemo terminology defined in [2], as well as IPv4 Network Address
Translation (NAT) and Port Address Translation (PAT).
During the transition phase from IPv4 to IPv6, hot spots that
actually provide IPv6 connectivity will be scarce and Mobile Routers
should support an alternate roaming technology over IPv4.
There is an existing panel of solutions from the NGTRANS WG (ISATAP,
6to4, TEREDO), but these solutions fail to traverse simply every type
of NAT and PAT, such as present today in GPRS deployments.
There is a real value in combining MIPv6 and IPv4 traversal
technologies. MIP brings a MN-HA tunnel and a binding cache into the
picture, as well as a keep alive procedure. The MIP cache can be
used to store the PAT/NAT states, while the Binding flow can be tuned
to keep the PAT/NAT active. As a result, it is possible for a IPv6
Mobile Router to traverse PAT/NAT with no protocol overhead or
additional states in the network.
The Doors Protocol developed in this draft is aimed at the Nemo
problem space. In particular, only the MN-HA tunnel is considered
(as opposed to any MN-CN tunnel). Also, some restrictions apply that
may be circumvented by additional work.
2. Terminology and concepts
2.1 Doors Handle
Existing technologies such as 6to4 use synthetized IPv6 addresses to
build automatic tunnels. In such technologies, the result is still a
valid Global IPv6 address, that can be used as Source or Destination
address in IPv6 packets, and points on one of the machine's
interfaces.
Here, we synthetize a 128-bits tag, named Doors Handle. The Doors
Handle is not a valid Global IPv6 Address, and can not generally be
used as a Source or Destination IPv6 address.
The Doors Handle should not be used for upper layer checksums,
either: the tag only is meant to be used as an IPv6 address in the
header of a packet that is encapsulated inside a IPv4 (UDP) tunnel.
In fact, the Doors Handle points on that IPv4 (UDP) tunnel, as
opposed to an interface on a machine, and is meant to be used only as
a CareOf by MIPv6 Nodes roaming over a IPv4 network.
Thubert, et al. Expires August 2, 2003 [Page 3]
Internet-Draft Doors February 2003
The Doors Handle has the following format:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Direction := (InDoors | OutDoors) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MN UDP Port | well-known Doors Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MN IPv4 address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Door IPv4 address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Doors Handle
Direction
The 32-bits protocol ID indicates that the Doors protocol is being
used to synthetize this address. At this time, There are 2 IDs
defined:
0x12345678: InDoors
0x12343210: OutDoors
MN UDP Port
16-bits UDP Source port, chosen dynamically by the Mobile Node.
Doors Port
16-bits UDP Destination port. A well known value DOORSPORT to be
assigned by IANA. For interoperability testing, DOORSPORT of 434
(MIPv4 Port) is used in the meantime.
MN IPv4 Address
32-bits private IPv4 address that the MN acquires dynamically
while roaming, using DHCP or IPCP, or that is statically
configured.
Door IPv4 Address
32-bits public IPv4 address of the door, that the MN learns
dynamically while roaming, using DHCP or IPCP extension (TBD), or
that is statically configured.
Thubert, et al. Expires August 2, 2003 [Page 4]
Internet-Draft Doors February 2003
2.2 Other definitions
DoG
The Doors Gateway (DoG) is the function that terminates the Doors
Tunnel on both Home and Mobile ends. The DoG performs IPv4/UDP
automatic tunneling and a IPv6 level Network Address Translation.
DooR
A Doors Router (DooR) is a router that implements the Doors
Gateway. The Home Door is connected to the Home Network via IPv6.
Mobile Routers implementing the Doors Protocol are Mobile DooRs.
Doors Tunnel
The Doors Tunnel is an IPv4/UDP automatic tunnel that encapsulates
a Mobile IPv6 tunnel. The Tunnel has two Directions, InDoors and
OutDoors.
InDoors
A packet going InDoors flows between the Mobile Node and the DoG.
An InDoors packet is characterized by a Source IPv6 address that
is an InDoors Handle. An InDoors Handle is generated by the
Mobile Node, with the Direction field set to InDoors.
OutDoors
A packet going OutDoors flows between DoG and the Mobile Node. An
OutDoors packet is characterized by a Destination IPv6 address
that is an OutDoors Handle. An OutDoors Handle is generated by
the DoG, based on an InDoors Handle, after the IPv4 Address
Translation, with the Direction field set to OutDoors.
3. Basic MIPv6 Doors support
The Basic MIPv6 Doors support collocates a DoG function with the Home
Agent. A roaming Mobile Node generates an InDoors Handle and uses it
as CareOf to Bind over a Doors Tunnel to its Home Agent. All packets
are sent over the MN-HA tunnel, with no Route Optimization.
When sending a packet with a Source IPv6 address that is an InDoors
Handle, the Mobile Node automatically tunnels the packet over the
associated Doors tunnel. In turn, when sending a packet with a
Destination IPv6 address that is an OutDoors Handle, a HA
automatically tunnels the packet over the associated Doors tunnel.
Thubert, et al. Expires August 2, 2003 [Page 5]
Internet-Draft Doors February 2003
+-----------------+
| Correspondent | ^
+-----------------+ |
| |
+++++++++++ |
+ + |
+ IPv6 + | IPv6 Connectivity
+ + |
++++++++++++ |
| |
+-----------------+ |
| Home Agent | |
| DoG | ^
+-----------------+ . |
| |
+++++++++++ . |
+ IPv4 + |
+ Public + . |
+ Network + | Doors
++++++++++++ . | Tunnel
| |
+-----------------+ . |
| PAT / NAT | |
+-----------------+ . |
| |
+++++++++++ . |
+ IPv4 + |
+ Private + . |
+ Network + |
++++++++++++ . |
| |
+-----------------+ . |
| DoG | v
| Mobile Router | |
+-----------------+ |
| |
+++++++++++ |
+ IPv6 + |
+ Mobile + |
+ Network + |
++++++++++++ |
| |
+-----------------+ |
| MNN | v
+-----------------+
Basic Doors Model
Thubert, et al. Expires August 2, 2003 [Page 6]
Internet-Draft Doors February 2003
3.1 Known Restrictions
Since the CareOf is NATed on the way, it will cause problems to
Authentication Header and upper layer checksum computations, so
terminating a connection with the CareOf will not generally work.
The HA may have to save the original source IPv6 address in the
packets on order to perform signature and checksum validations.
Also, since the Doors Handle is not a valid IPv6 address, the packet
can not be forwarded after UDP decapsulation, so in basic MIPv6 mode,
the UDP tunnel MUST be terminated by the Home Agent.
Most of these limitations can be circumvented, but this is not
covered in this version of this draft, in order to keep it simple.
Yet, binding flows and MN-HA tunneling purposes, the Nemo
requirements can be fulfilled by the procedures described hereafter.
3.2 Operation for a MIPv6 Mobile Node roaming over IPv4
A MN roaming generates its InDoors Handle as follows:
+-------------+-------+-------+--------------+--------------+
| | | | | |
| InDoors | xxxx | DOORS | MN private @ |Door public @ |
| | | | | |
+-------------+-------+-------+--------------+--------------+
InDoors Handle
Direction: InDoors
MN UDP port: A value chosen dynamically by the Mobile Node. It
may be a signature used for verification purposes.
Doors Port: DOORSPORT
MN IPv4 address: the private IPv4 CoA acquired by the mobile
router on his roaming interface by any mechanism (configuration,
DHCP, IPCP, ...)
Door IPv4 address: An IPv4 address of the Home Agent.
The Mobile Node may recompute a new port periodically, build a new
CareOf and rebind.
The Mobile Node MUST be tuned to send Binding Updates often enough to
make sure that the NAT/PAT states are kept alive. As a result, there
is no additional control traffic for that purpose.
Thubert, et al. Expires August 2, 2003 [Page 7]
Internet-Draft Doors February 2003
3.2.1 Sending packets over the Doors tunnel
According to non-optimized MIPv6 and basic Nemo principles, the
Mobile Node, and in particular if it is a Nemo Mobile Router, uses
the MN-HA tunnel for all communications with the Infrastructure,
sourcing packets with the CareOf and using the Home Address Option to
pass the address that is actually used as Source for upper layer
purposes.
When sending or forwarding a IPv6 packet with a Source address that
is a Door Number with a InDoors Handle, a Mobile Node MUST
encapsulate the packet into a IPv4/UDP tunnel using the following
settings:
<-- outer IPv4 header -> <-UDP ports-> <in.IPv6 header->
+----+--------+--------+ +-----+-----+ +----+----+-----+ +-----+-------
| | | | | | | | | | | |
|oNAF| oSRCV4 |oDESTV4 | |SPort|DPort| |iNAF|iSRC|iDEST| | Payload
| | | | | | | | | | | |
+----+--------+--------+ +-----+-----+ +----+----+-----+ +-----+-------
InDoors Packet
NAF represents the Non-Address Fields of a IP header
Sport is the UDP Source port, set to the MN UDP port from the
Handle
DPort is the UDP Destination Port, set to the Doors Port from the
Handle
SRCV4 is the Source IPv4 address, set to the MN IPv4 address from
the Handle
DESTV4 is the Destination IPv4 address, set to the Door IPv4
address from the Handle.
SRC is the IPv6 Source Address, set to CoA == InDoors Handle
DEST is the Home Agent Address
The Payload may be Home Address Dest Option and a Mobility Header
or a IPv6 packet from a Node in the Mobile Network
This causes packets in the MN-HA tunnel to be automatically
reencapsulated into an IPv4/UDP tunnel to the HA IPv4 address, as
long as the CareOf Address is a Doors Handle.
Thubert, et al. Expires August 2, 2003 [Page 8]
Internet-Draft Doors February 2003
3.2.2 Receiving packets over the Doors tunnel
The process of terminating the Doors tunnel on the MN side is:
Decapsulating the IPv6 packet from the IPv4/UDP encapsulation
Recomposing the original IPv6 address as known on the MR side.
When receiving a packet over UDP with Source Port equal to DOORSPORT,
a Mobile Node checks whether there's an inner IPv6 packet with a
Destination IPv6 address that is actually a Doors Handle.
If so, and if the Direction of the Handle is OutDoors, the MN
restores its InDoors Handle by:
Overwriting the Direction to InDoors
Overwriting the MN IPv4 address field with the IPv4 Destination
address from the received packet
Overwriting the MN UDP port field with the UDP Destination port
from the received packet
If the generated Doors Handle does not match its CareOf, the node
drops the packet.
Then, the node decapsulates the UDP tunnel and receives the resulting
IPv6 packet. The result is either yet an other level of
decapsulation, or, in the case of a RH type 2, a forwarding to the
next hop in the RH, that should be the node's home address.
This causes the MN-HA tunnel to be automatically decapsulated from an
IPv4/UDP tunnel as long as the Doors Handle is the CareOf.
3.3 Operation for the Home Agent of a MIPv6 MN roaming over IPv4
For basic MIPv6 Doors support, Home Agent runs the DoG, and the
OutDoors Handle is stored as CareOf in the Binding Cache.
3.3.1 Receiving packets over the Doors tunnel
The process of terminating the Doors Tunnel on the HA side is:
Decapsulating the IPv6 packet from the IPv4/UDP encapsulation
Translating the original source IPv6 address into an OutDoors
Handle.
Thubert, et al. Expires August 2, 2003 [Page 9]
Internet-Draft Doors February 2003
When receiving a packet over UDP with Source Port equal to DOORSPORT,
the DoG function in a HA checks whether there's an inner IPv6 packet
with a Source IPv6 address that is actually a Doors Handle.
If so, and if the Direction is InDoors, DoG translates the Handle by:
Overwriting the Direction to OutDoors
Overwriting the MN IPv4 address field with the IPv4 Source Address
from the received packet
Overwriting the MN UDP port field with the UDP Source port from
the received packet
As a result, the layout of the OutDoors Handle is as follows:
+-------------+-------+-------+--------------+--------------+
| | | | | |
| OutDoors | yyyy | DOORS | MN public @ |Door public @ |
| | | | | |
+-------------+-------+-------+--------------+--------------+
OutDoors Handle
Direction: OutDoors
MN UDP port: May have been PATed
Doors Port: DOORSPORT
MN IPv4 address: the public IPv4 address of the MN if NATed
Door IPv4 address: An IPv4 address of the Home Agent.
At that time of translating the Handle, the DoG knows both the
InDoors and OutDoors tags. It may save the InDoors Handle for AH
computation and upper layer checksums, should there be a need for it.
Then, the DoG decapsulates the UDP tunnel and receives the resulting
IPv6 packet. As the HA is collocated with the DoG, the packet is
received and the OutDoors Handle is used as CareOf and stored in the
binding cache.
So the transition between IPv4 and IPv6 roaming is smooth, handled by
the DoG function, transparently to the HA support.
Thubert, et al. Expires August 2, 2003 [Page 10]
Internet-Draft Doors February 2003
3.3.2 Sending packets over the Doors tunnel
When the HA forwards packets to a Mobile Node that is not at home, it
encapsulates them over the MN-HA tunnel. The Destination IPv6
address is the translated CareOf Address of the MN, that is the
OutDoors Handle of that MN if it is roaming over IPv4 using the Doors
Protocol.
When sending or forwarding a IPv6 packet with a Destination address
that is an OutDoors Handle, the DoG function in the Home Agent MUST
encapsulate the packet into a IPv4/UDP tunnel using the following
settings:
<-- outer IPv4 header -> <-UDP ports-> <in.IPv6 header->
+----+--------+--------+ +-----+-----+ +----+----+-----+ +-----+-------
| | | | | | | | | | | |
|oNAF| oSRCV4 |oDESTV4 | |SPort|DPort| |iNAF|iSRC|iDEST| | Payload
| | | | | | | | | | | |
+----+--------+--------+ +-----+-----+ +----+----+-----+ +-----+-------
InDoors Packet
NAF represents the Non-Address Fields of a IP header
Sport is the UDP Source port, set to the Doors Port from the
Handle
DPort is the UDP Destination Port, set to the MN UDP port from the
Handle
SRCV4 is the Source IPv4 address, set to the Door IPv4 address
from the Handle.
DESTV4 is the Destination IPv4 address, set to the MN IPv4 address
from the Handle
SRC is the Home Agent Address
DEST is the IPv6 Source Address, set to the mapped CoA == OutDoors
Handle
The Payload may start with a Routing Header of type 2, or be a
IPv6 packet from a Node in the Mobile Network
When applied to Nemo, between a Mobile Router and its Home Agent, the
Doors protocol maintains a single state in the PAT/NAT for all the
communications of all the Mobile Network Nodes.
Thubert, et al. Expires August 2, 2003 [Page 11]
Internet-Draft Doors February 2003
4. Distributed configurations
With the basic MIPv6 Doors support, the Home DooR is necessarily
collocated with the Home Agent. This is fine for a small, collapsed
configuration (A single HA/Door), but more of a problem for a larger,
distributed configuration. Further improvements, described
hereafter, allow for a distribution of that functionality.
4.1 Hierarchical MIP
A Mobility Anchor Point (MAP), as defined in [4] can be used to
terminate the Doors tunnel on behalf of the Home Agent. This permits
a distributed configuration with no dependencies of between the
number of MAPs and the number of HAs.
A new IPv4 region is defined, and several MAP/Doors can be deployed
to handle that region. They keep a state for the Mobile Nodes that
use their service for Regional mobility, but advertise their own
Global IPv6 address to the Home Agent, which uses it as the MN
CareOf.
As a result, the HA is transparent when a IPv4 traversal occurs.
4.2 Reverse Routing Header
The RRH, as defined in [3] provides an alternate technique to
distribute the Doors Gateways for roaming Mobile Routers. In this
case, a number of Mobile Routers, called Stray DoGs are deployed on
the Home Network side of the IPv4 Network, and configured to be "not
at home" - even though they do not move-, and to be Home DooRs.
Since they are not at home, the Stray DoGs perform the procedure
defined in [3] for a roaming Mobile Router, when forwarding a packet
decapsulated by the DoG:
They swap the Source address with their own (Global IPv6) CareOf
Address, adding the original Source (the OutDoors Handle) to the RRH.
As a result, the Home Agent is again transparent to the fact that
IPv4 traversal occurred.
The whole IPv4 network is now considered as the Mobile Network of the
Doors gateways. As a result, the Mobile Router roaming over IPv4 is
considered at a depth of one, attached to its selected Doors Gateway.
Other MRs may be attached to that roaming MR in a nested Nemo
Fashion. Each one maintains a tunnel to its home Agent, while all of
these tunnels share the same IPv4/UDP end points.
Thubert, et al. Expires August 2, 2003 [Page 12]
Internet-Draft Doors February 2003
+-----------------+
| Correspondent | ^
+-----------------+ |
| | IPv6 Connectivity
+++++++++++ |
+-----+ + + |
| HA1 |--+ IPv6 + | ^
+-----+ + + | |
++++++++++++ | |
| | |
+-----------------+ | |
| Door | | ^ |
+-----------------+ | |
| . | | MR1's
+++++++++++ | | tunnel
+ IPv4 + . | | Home
+ Public + | |
+ Network + . | Doors |
++++++++++++ | Tunnel |
| . | (a single |
+-----------------+ | one for |
| PAT / NAT | . | all the |
+-----------------+ | nested |
| . | Nemo) |
+++++++++++ | |
+ IPv4 + . | |
+ Private + | |
+ Network + . | |
++++++?+++++ | |
| . | |
+-----------------+ | |
| Mobile Router 1 | v v
+-----------------+ | ^
| | |
====?=============?========== | | Nested
MR5 MR2 | | Mobile
| | | | Network
=========== ===?===== | |
MR3 | |
| | |
==|=========?== | |
LFN1 MR4 | |
| | |
=============== v V
Doors with RRH
Thubert, et al. Expires August 2, 2003 [Page 13]
Internet-Draft Doors February 2003
With RRH, the InDoors packets are formatted as follows:
<-- outer IPv4 header -> <-UDP ports-> <in.IPv6 header-> <-RRH->
+----+--------+--------+ +-----+-----+ +----+----+-----+ +------+-------
| | | | | | | | | | | | ... |
|oNAF| oSRCV4 |oDESTV4 | | SP | DP | |iNAF|iSRC|iDEST| | CoAx | Payload
| | | | | | | | | | | | HoAx |
+----+--------+--------+ +-----+-----+ +----+----+-----+ +------+-------
InDoors Packet with RRH support
NAF represents the Non-Address Fields of a IP header
Sport is the UDP Source port, set to the MN UDP port from the
Handle
DPort is the UDP Destination Port, set to the Doors Port from the
Handle
SRCV4 is the Source IPv4 address, set to the MN IPv4 address from
the Handle
DESTV4 is the Destination IPv4 address, set to the Door IPv4
address from the Handle.
SRC is the IPv6 Source Address, set to CoA == InDoors Handle
DEST is the Home Agent Address
RRH contains the Source Routed path to the First MR down the
nested Nemo, that is the real tunnel endpoint
The Payload may start with a Home Address Destination Option and a
Mobility Header or a IPv6 packet from a Node in the Mobile Network
The packets on the return path are sent by the Home Agent to the
Stray DoG that originated the inbound packets.
The encapsulating headers contains a Routing Header of type 2 derived
from the RRH. Conforming the RH type 2 processing, the Stray DoG
needs to forward the packet to the first entry in the Routing Header,
which happens to be a OutDoors Handle.
When sending or forwarding a IPv6 packet with a Destination address
that is an OutDoors Handle, the Stray DoG MUST encapsulate the packet
into a IPv4/UDP tunnel using the following settings:
Thubert, et al. Expires August 2, 2003 [Page 14]
Internet-Draft Doors February 2003
<-- outer IPv4 header -> <-UDP ports-> <in.IPv6 header-> <-RH2->
+----+--------+--------+ +-----+-----+ +----+----+-----+ +------+-------
| | | | | | | | | | | | ... |
|oNAF| oSRCV4 |oDESTV4 | |SPort|DPort| |iNAF|iSRC|iDEST| | CoAx | Payload
| | | | | | | | | | | | HoAx |
+----+--------+--------+ +-----+-----+ +----+----+-----+ +------+-------
OutDoors Packet with RRH support
NAF represents the Non-Address Fields of a IP header
Sport is the UDP Source port, set to the Doors Port from the
Handle
DPort is the UDP Destination Port, set to the MN UDP port from the
Handle
SRCV4 is the Source IPv4 address, set to the Door IPv4 address
from the Handle.
DESTV4 is the Destination IPv4 address, set to the MN IPv4 address
from the Handle
SRC is the Home Agent Address
DEST is the IPv6 Source Address, set to the mapped CoA == OutDoors
Handle
The Routing Header type 2 contains the Source Routed path to the
First MR down the nested Nemo, that is the real tunnel endpoint
The Payload is a IPv6 packet to a Node in a Mobile Network behind
the Mobile Router HoAx
This solution presents a number of advantages:
This solution does not keep states in the gateways. The NATed
addresses are stored and maintained in the Home Agent binding
cache, as long as they are needed, by the Mobile IPv6 protocol.
The MR may swap its Doors Gateway whenever it needs, since this
will seen as yet an other roaming. In particular, the -optionally
local, private- address of a local Doors Gateway may be available
in a DHCP or an IPCP extension.
There is only one entry in the NAT/PAT gateway for a full Nested
Nemo configuration. This limits the size of the tables that the
NAT gateway has to maintain.
Thubert, et al. Expires August 2, 2003 [Page 15]
Internet-Draft Doors February 2003
5. IANA considerations
A port number value is required for DOORSPORT. Note that this
requirement could be alleviated by a common configuration on both
sides, but this makes the deployment a bit more complex.
The values for InDoors and OutDoors also have to be standardized.
0x12345678 and 0x12343210 are given for interoperability testing in
the meantime.
6. Acknowledgements
The authors wish to thank: Ole Troan, Vincent Ribiere, Massimo
Lucchina, Daniel Shell, Ravi Samprathi, and the coffee machine for
their various contributions.
References
[1] Perkins, C., Johnson, D. and J. Arkko, "Mobility Support in
IPv6", draft-ietf-mobileip-ipv6-20 (work in progress), January
2003.
[2] Ernst, T. and H. Lach, "Network Mobility Support Terminology",
draft-ernst-monet-terminology-01 (work in progress), July 2002.
[3] Thubert, P. and M. Molteni, "IPv6 Reverse Routing Header and its
application to Mobile Networks", draft-thubert-nemo-reverse-
routing-header-01 (work in progress), October 2002.
[4] Castelluccia, C., Malki, K., Soliman, H. and L. Bellier,
"Hierarchical Mobile IPv6 mobility management (HMIPv6)", draft-
ietf-mobileip-hmipv6-07 (work in progress), October 2002.
[5] Petrescu, A., "Issues in Designing Mobile IPv6 Network Mobility
with the MR-HA Bidirectional Tunnel (MRHA)", draft-petrescu-
nemo-mrha-01 (work in progress), November 2002.
[6] Sarikaya, B., "Architectural Requirements for Base Network
Mobility Using Bidirectional Tunneling", draft-sarikaya-nemo-
archreqs-00 (work in progress), November 2002.
[7] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[8] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
Specification", RFC 2460, December 1998.
Thubert, et al. Expires August 2, 2003 [Page 16]
Internet-Draft Doors February 2003
Authors' Addresses
Pascal Thubert
Cisco Systems Technology Center
Village d'Entreprises Green Side
400, Avenue Roumanille
Biot - Sophia Antipolis 06410
FRANCE
EMail: pthubert@cisco.com
Marco Molteni
Cisco Systems Technology Center
Village d'Entreprises Green Side
400, Avenue Roumanille
Biot - Sophia Antipolis 06410
FRANCE
EMail: mmolteni@cisco.com
Patrick Wetterwald
Cisco Systems Technology Center
Village d'Entreprises Green Side
400, Avenue Roumanille
Biot - Sophia Antipolis 06410
FRANCE
EMail: pwetterw@cisco.com
Thubert, et al. Expires August 2, 2003 [Page 17]
Internet-Draft Doors February 2003
Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Thubert, et al. Expires August 2, 2003 [Page 18]
| PAFTECH AB 2003-2026 | 2026-04-21 19:10:23 |