[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits]

Versions: 00

INTERNET-DRAFT                                                 Jim Bound
NGTRANS Working Group                                    Hewlett Packard
Expires December 2002

            Dual Stack Transition Mechanism (DSTM) Overview


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-

   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

   The list of Internet-Draft Shadow Directories can be accessed at

   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


   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

   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

   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

       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

   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

           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

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)
   DSTM IPv4 over IPv6 tunnel profile for Tunnel Setup Protocol(TSP)
   Dual Stack deployment using DSTM and neighbour discovery
   DSTM Options for DHCP
   DSTM Ports Option for DHCPv6
   Dual Stack Transition Mechanism (DSTM) Extensions
   Extensions to SIIT and DSTM for enhanced routing of inbound packets
   DSTM in a VPN Scenario
   Using a Single IPv4 Global Address in DSTM

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.





Authors' Address

       Jim Bound
       Hewlett Packard
       110 Spitbrook Road
       Nashua, NH 003062
       Phone: +603.884.00
       Email: Jim.Bound@hp.com

Bound                         Expires December 2002             [Page 9]

Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/