INTERNET-DRAFT Jim Bound
NGTRANS Working Group Hewlett Packard
Expires December 2002
Dual Stack Transition Mechanism (DSTM) Overview
<draft-ietf-ngtrans-dstm-overview-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.
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.
To view the entire list of current Internet-Drafts, please check the
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or
ftp.isi.edu (US West Coast).
Distribution of this memo is unlimited.
Bound Expires December 2002 [Page 1]
INTERNET-DRAFT draft-ietf-ngtrans-dstm-overview-00.txt June 2002
Abstract
The initial deployment of IPv6 will require a tightly coupled use of
IPv4 addresses to support the interoperation of IPv6 and IPv4 within
an IPv6-only Network. Nodes will still need to communicate with IPv4
nodes that do not have a dual IP layer supporting both IPv4 and IPv6.
The Dual Stack Transition Mechanism (DSTM) is based on the use of
IPv4-over-IPv6 tunnels to carry IPv4 traffic within an IPv6-only
network and provides a method to allocate a temporary IPv4 Address to
IPv6/IPv4 nodes. DSTM is also a way to avoid the use of Network
Address Translation for early adopter IPv6 deployment.
Table of Contents:
1. Introduction .......................................... 3
2. DSTM Overview and Assumptions ......................... 4
3. DSTM Deployment Example ............................... 5
4.1 DSTM Client/Server Example ........................... 6
5. Implementation State and Other IETF work using DSTM .... 7
6. Applicability Statement ............................... 8
7. Security Considerations ............................... 9
Acknowledgments .......................................... 9
References ............................................... 9
Authors' Address ......................................... 9
Bound Expires December 2002 [Page 2]
INTERNET-DRAFT draft-ietf-ngtrans-dstm-overview-00.txt June 2002
1. Introduction
The initial deployment of IPv6 will require a tightly coupled use of
IPv4 addresses to support the interoperation of IPv6 and IPv4 within
an IPv6-only Network. Nodes will still need to communicate with IPv4
nodes that do not have a dual IP layer supporting both IPv4 and IPv6.
The Dual Stack Transition Mechanism (DSTM) is based on the use of
IPv4-over-IPv6 tunnels to carry IPv4 traffic within an IPv6-only
network and provides a method to allocate a temporary IPv4 Address to
IPv6/IPv4 nodes. DSTM is also a way to avoid the use of Network
Address Translation for early adopter IPv6 deployment.
DSTM is targeted to help the interoperation of IPv6 newly deployed
networks with existing IPv4 networks. Since the IPv4 globally
routable address space available is becoming a scarce resource, it is
assumed that users will deploy IPv6 to reduce the need and
reliability on IPv4 within a portion of their networks. Under this
premise, supporting native IPv4 and native IPv6 simultaneously
largely increases the complexity of network administration (address
plan, routing infrastructure). It is proposed, in this case, to
configure the network only for IPv6. In this specific scenario,
DHCPv4 can not be directly used to assign IPv4 addresses to IPv6
nodes, since no IPv4 connectivity is maintained in the network.
When DSTM is deployed in a network, an IPv4 address is allocated to a
dual stack node if the connection can not be established using IPv6.
This allows either IPv6 nodes to communicate with IPv4-only nodes, or
IPv4-only applications to run on an IPv6 node without modification.
This allocation mechanism is coupled with the ability to perform
IPv4-over-IPv6 (4over6) tunnelling, hiding IPv4 packets inside the
native IPv6 domain. This simplifies network management: only the IPv6
routing plan is managed inside the network.
The DSTM architecture is composed of an address server (DSTM server),
a gateway and a number of nodes (DSTM nodes). The address server is
in charge of IPv4 address allocation to client nodes. This
allocation is very simple since there is no localization purpose in
this address. The DSTM server has just to guarantee the uniqueness of
the IPv4 address for a period of time. The gateway, or Tunnel End
Point (TEP), can be seen as a border router between the IPv6-only
domain and an IPv4 Internet or Intranet. This node performs
encapsulation/decapsulation of packets to assure bi-directional
forwarding between both networks. Finally, in order to assure IPv4
connectivity, nodes in the IPv6-only domain should be able to
dynamically configure their IPv4 stack (by asking the server for a
temporary address) and must be capable to establish 4over6 tunnels
towards a Tunnel End Point. The exact details on how DSTM nodes
communicate with the DSTM Server is out of the scope of this overview
and will be described in other documents.
Bound Expires December 2002 [Page 3]
INTERNET-DRAFT draft-ietf-ngtrans-dstm-overview-00.txt June 2002
2. DSTM Overview and Assumptions
DSTM as discussed in the introduction is a method that uses existing
protocols. DSTM does not specify a protocol. However, DSTM defines
client, server and TEP behaviour and the properties of the temporary
addresses allocation mechanisms.
The motivation for DSTM is to provide IPv6 nodes a means to acquire
an IPv4 address, for communications with IPv4-only nodes or IPv4
applications.
The core assumption within this mechanism is that it is totally
transparent to applications, which can continue to work with IPv4
addresses. It is also transparent to the network which carries only
IPv6 packets. It is the authors' viewpoint that the user in this
case, has deployed IPv6 to support end to end computing, without
translation. This aspect is fundamental during a transition process
to guarantee that every existing application will continue to work
(e.g. IPsec, H.323), with embeded IPv4 addresses in the payload of a
packet.
The DSTM model and assumptions are as follows:
- The DSTM domain is within an Intranet not on the Internet.
- IPv6 nodes do not maintain IPv4 addresses except on a temporary basis,
to communicate with IPv4-only and IPv4 Applications.
- The temporary IPv4 address allocation is done by the DSTM server,
different protocols such as DHCPv6 or RPCv6 can be used to assign the
IPv4 address.
- The DSTM domain for the IPv6 nodes will keep IPv4 routing
tables to a minimum and use IPv6 routing, hence, reducing
the network management required for IPv4 during transition.
- Once IPv6 nodes have obtained IPv4 addresses Dynamic Tunneling is
used to encapsulate the IPv4 packet within IPv6 and then forward
that packet to an IPv6 TEP, where the packet will be decapulated and
forwarded using IPv4. The IPv4 allocation mechanism may also
provide the TEP IPv6 address.
- Existing IPv4 applications or nodes do not have to be modified to
communicate with DSTM.
- Implementation defined software will have to exist to support DSTM:
o Ability within a DSTM Server implementation to maintain
configuration information about TEPs for encapsulating IPv4
packets between IPv6 nodes that can forward IPv4 packets to an
Bound Expires December 2002 [Page 4]
INTERNET-DRAFT draft-ietf-ngtrans-dstm-overview-00.txt June 2002
IPv4 routing realm, and to maintain a pool of IPv4
Addresses.
o An IPv6 node MUST support the dynamic tunneling
mechanisms in this specification to encapsulate IPv4 packets
within IPv6 on an IPv6 node. In addition
a DSTM client SHOULD be present on the node for IPv4
Mapped Addresses and TEPs management.
o DSTM Border Routers MAY recall or be able to cache
the association of IPv6 and IPv4 addresses of nodes during
the forwarding process.
A schematic overview of DSTM is as follows:
-----------------------------------------------
| IPv4 Internet or Intranet
DSTM Domain Intranet | IPv4 Applications
| Domain
_____________________ |
| | |
| DSTM Server | |
|_____________________| |
^ |
| |
__________________ | _|_______
| | | | |
| IPv6/IPv4 Node | | | DSTM |
|------------------| | | Border |
| DSTM client | | | Router |
| |<------- | IPv6 |
|------------------| | & |
| DTI/Route |<-------------------->| IPv4 |
------------------- ---------
|
----------------------------------------------
For an IPv6 node to participate in DSTM it MUST have a dual IP layer,
supporting both an IPv4 and an IPv6 stack. DSTM is not a solution
for IPv6 ONLY nodes.
3. DSTM Deployment Example
In the example below, the following notation will be used:
X will designate an IPv6 node with a dual stack, X6 will be the IPv6
address of this node and X4 the IPv4 address
Bound Expires December 2002 [Page 5]
INTERNET-DRAFT draft-ietf-ngtrans-dstm-overview-00.txt June 2002
Y will designate a DSTM border router at the boundary between an
IPv6 DSTM domain and an IPv4-only domain.
Z will designate an IPv4-only node and Z4 its address.
==> means an IPv6 packet
--> means an IPv4 packet
++> means a tunneled IPv4 packet is encapsulated in an IPv6 packet
..> means a DNS query or response. The path taken by this
packet does not matter in the examples
"a" means the DNS name of a node
4.1 DSTM Client/Server Example
This example describes the case where an application (either compiled
for the IPv6 or IPv4 API) running on an IPv6 node (X6) wants to
establish a session with an IPv4 application on an IPv4-only node
(Z4).
The IPv4 routing table of node X is configured to send IPv4 packets
to the DTI interface.
Bound Expires December 2002 [Page 6]
INTERNET-DRAFT draft-ietf-ngtrans-dstm-overview-00.txt June 2002
DSTM
Server DNS
X6 Y6/Y4 Z4
| | |
|. . . . . . . .> Z | - X6 asks the DNS for the A RR for "Z"
|<. . . . . . . . Z4 | - the answer is Z4
| | |
| | | - The application sends its first IPv4
| | | packet which arrives to the DTI
| | | interface.
| | | (If the application is compiled for IPv6
| | | this can be done through an IPv4-mapped
| | | address).
| | |
| | | - X6 needs an IPv4 address (first use)
|====> | | - X6 queries the DSTM server for an
| | | IPv4 address
|<==== | | - The DSTM server locates the client
| | | and provides a temporary IPv4
| | | global address and the IPv6 TEP address.
|+++++++++++>| | - The DTI sends the IPv6 packet to the
| | | TEP.
| |----------->| - Y sends the packet to the destination Z4
| | | - Y caches the association between
| |<-----------| - Z4 answers.
| | |
|<+++++++++++| | - Y uses the mapping between X4 and X6
| | | to tunnel the packet to the destination
| | |
When Z responds the packet returns back through Y. Y having cached
the association between the IPv4 and the IPv6 address of X, is able
to send the packet encapsulating the IPv4 packet within IPv6 back to
X.
5. Implementation State and Other IETF work using DSTM
DSTM is being used as a transition architecture and methodology for
early and long term deployment. Implementations of DSTM exist on Linux
and BSDi, and using RPCv6, DHCPv6, and manual configuration to provide
the DSTM IPv4 Addresses to clients. DSTM can be used by Mobile and
Stationary Clients or for Servers and Gateways providing other
transition mechanisms for VPNs, Mobility between IPv4 and IPv6, and DNS
Records to locate IPv6 nodes. DSTM can also be used to support 6to4 and
Teredo as adjuncts to those transition mechanisms.
Bound Expires December 2002 [Page 7]
INTERNET-DRAFT draft-ietf-ngtrans-dstm-overview-00.txt June 2002
DSTM's implementation pilots exist and it is also achieving defacto
implementation status within the early IPv6 adopter networks to avoid
translation of IPv6.
Other relevant IETF works in progress for DSTM can be viewed as follows:
Dual Stack Transition Mechanism (DSTM)
draft-ietf-ngtrans-dstm-07.txt
DSTM IPv4 over IPv6 tunnel profile for Tunnel Setup Protocol(TSP)
draft-blanchet-ngtrans-tsp-dstm-profile-00
Dual Stack deployment using DSTM and neighbour discovery
draft-bereski-ngtrans-nd-dstm-01.txt
DSTM Options for DHCP
draft-ietf-dhc-dhcpv6-opt-dstm-01.txt
DSTM Ports Option for DHCPv6
draft-ietf-dhc-dhcpv6-opt-dstm-ports-00.txt
Dual Stack Transition Mechanism (DSTM) Extensions
draft-ietf-ngtrans-dstmext1-aiih-00.txt
Extensions to SIIT and DSTM for enhanced routing of inbound packets
draft-ietf-ngtrans-siit-dstm-01.txt
DSTM in a VPN Scenario
draft-richier-dstm-vpn-00.txt
Using a Single IPv4 Global Address in DSTM
draft-shin-dstm-single-ipv4-00.txt
6. Applicability Statement
DSTM is applicable for use from within a DSTM Domain in which hosts
need to communicate with IPv4-only hosts or through IPv4-only
applications on a user Intranet or over the Internet.
The motivation of DSTM is to allow dual IP layer nodes to communicate
using global IPv4 addresses across an Intranet or Internet, where
global addresses are required. However, the mechanisms used in DSTM
can also be deployed using private IPv4 addresses to permit the
Intranet use of DSTM where users require temporary access to IPv4
services within their Intranet.
In DSTM, a mechanism is needed to perform the address allocation
process. This can be decoupled in two functions: the management of
the IPv4 address pool and the communication protocol between server
and clients. A number of mechanisms, like DHCPv6, can perform these
functions. The choice of the method to be used is out of scope and
will be described in other documents.
The exact capacities of the 4over6 tunnelling interface required by
DSTM is implementation defined. Optionally, it is allowed that DSTM
Bound Expires December 2002 [Page 8]
INTERNET-DRAFT draft-ietf-ngtrans-dstm-overview-00.txt June 2002
nodes configure manually (in a static manner) the tunnel to the TEP;
but the recommendation is not to do this. The dynamic configuration
of 4over6 interfaces as a result of the address allocation process is
the right way to execute DSTM on an IPv6 Network.
DSTM also assumes that all packets returning from an IPv4 node to a
DSTM node are routed through the originating DSTM TEP who maintains
the association of the node's IPv4/IPv6 addresses. At this time it
is beyond the scope of this proposal to permit IPv4 packets destined
to a DSTM node to be forwarded through a non-originating DSTM TEP.
A line for future work on DSTM may include the support of multiple
TEPs for returning IPv4 packets and the discovery of DSTM nodes using
IPv4 DNS queries.
7. Security Considerations
The DSTM mechanism can use all of the defined security specifications
for each functional part of its operation. For DNS, the DNS Security
Extensions/Update can be used. Concerning address allocation,
when connections are initiated by the DSTM nodes, the risk of Denial
of Service attacks (DOS) based on address pool exaustion is limited
since DSTM is used in an Intranet environement. In this scenario, If
DHCPv6 is deployed, the DHCPv6 Authentication Message can be used too.
Also, since the TEPs are inside an Intranet, they can not be
used as an open relay. Finally, for IPv4 communications on DSTM
nodes, once the node has an IPv4 address, IPsec can be used since
DSTM does not break secure end-to-end communications at any point.
Acknowledgments
TBD
References
TBD
Authors' Address
Jim Bound
Hewlett Packard
110 Spitbrook Road
Nashua, NH 003062
Phone: +603.884.00
Email: Jim.Bound@hp.com
USA
Bound Expires December 2002 [Page 9]
