[Search] [pdf|bibtex] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 08                                    
INTERNET-DRAFT                                                 Jim Bound
NGTRANS Working Group                                             Compaq
Obsoletes draft-ietf-ngtrans-dstm-06.txt                 Laurent Toutain
Expires August 2002                                       Octavio Medina
                                                          Francis Dupont
                                                           ENST Bretagne
                                                            Hossam Afifi
                                                            Alain Durand
                                                        Sun Microsystems

                 Dual Stack Transition Mechanism (DSTM)


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,Toutain,Medina and al.  Expires August 2002               [Page 1]

INTERNET-DRAFT       draft-ietf-ngtrans-dstm-07.txt        February 2002


   During the initial deployment of IPv6, hosts in native IPv6 networks
   will need to maintain connectivity with hosts and/or applications who
   can only be reached through IPv4. The Dual Stack Transition Mechanism
   (DSTM) provides a method to assure this connectivity based on the use
   of IPv4-over-IPv6 tunnels and the temporal allocation of a global
   IPv4 address to hosts requiring such communication. This document
   defines the processes and architecture required for this transition

Table of Contents:

      1. Introduction  ..........................................  3
      2. Terminology   ..........................................  4
      2.1 IPv6 DSTM Terminology  ................................  4
      2.2 Specification Language  ...............................  5
      3. DSTM Overview and Assumptions ..........................  5
      4. DSTM Node Requirements  ................................  7
      4.1 Configuration of the IPv4 stack  ......................  7
      4.2 IPv4 packet forwarding  ...............................  8
      4.3 DSTM processing of IPv4 packets  ......................  8
      4.4 IPv6 packet construction  .............................  8
      5. DSTM Server Requirements  ..............................  9
      6. Applicability Statement  ............................... 10
      7. Security Considerations  ............................... 10
      Acknowledgments  .......................................... 11
      Normative References   .................................... 12
      Informative References  ................................... 12
      Authors' Address  ......................................... 12

Bound,Toutain,Medina and al.  Expires August 2002               [Page 2]

INTERNET-DRAFT       draft-ietf-ngtrans-dstm-07.txt        February 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 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[7] 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 connexion 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 proposal
   and will be described in other documents.

Bound,Toutain,Medina and al.  Expires August 2002               [Page 3]

INTERNET-DRAFT       draft-ietf-ngtrans-dstm-07.txt        February 2002

   This specification begins by the definition of the terminology
   (section 2).  Section 3 provides a technical overview of the DSTM
   methodology as a transition mechanism.  In section 4, the
   requirements for DSTM nodes is presented. Section 5 describes the
   DSTM server requirements. Finally, section 6 provides the DSTM
   Applicability Statement.

2. Terminology

2.1 IPv6 DSTM Terminology

      DSTM Domain             The network areas on an Intranet where IPv6 nodes
                              use DSTM to assure IPv4 communication. An IPv4
                              address allocation server may be deployed inside the
                              domain to manage an IPv4 address pool. IPv4 routing
                              access may not be maintained within a DSTM domain.

      DSTM Server             A process in charge of managing the IPv4 address
                              space that will be allocated to DSTM Nodes.

      Tunnel End Point (TEP)  Destination of IPv6 flows containing IPv4 packets.
                              It assures the forwarding function between the DSTM
                              domain and a given IPv4 network.

      4over6 Tunnelling       Encapsulation of IPv4 packets over IPv6. Used for
                              carrying IPv4 flows from one node to another in a
                              DSTM Domain.

      DSTM Client             A process on a DSTM Node who manages
                              the temporary IPv4 address allocated by the
                              DSTM Server.

      DSTM Node               A node that implements both IPv4 and IPv6 stacks,
                              4over6 tunnelling and is a DSTM client. A DSTM node
                              generates only IPv6 packets on the network.

      IPv6 Protocol Terms:    See [1]

      IPv6 Transition Terms:  See [6]

      DHCPv6 Terms:           See [2]

Bound,Toutain,Medina and al.  Expires August 2002               [Page 4]

INTERNET-DRAFT       draft-ietf-ngtrans-dstm-07.txt        February 2002

2.2 Specification Language

      In this document, several words are used to signify the requirements
      of the specification, in accordance with RFC 2119 [4]. These words
      are often capitalized.

         MUST          This word, or the adjective "required", means that
                       the definition is an absolute requirement of the

         MUST NOT      This phrase means that the definition is an absolute
                       prohibition of the specification.

         SHOULD        This word, or the adjective "recommended", means
                       that there may exist valid reasons in particular
                       circumstances to ignore this item, but the full
                       implications must be understood and carefully
                       weighed before choosing a different course.
                       Unexpected results may result otherwise.

         MAY           This word, or the adjective "optional", means that
                       this item is one of an allowed set of alternatives.
                       An implementation which does not include this option
                       MUST be prepared to interoperate with another
                       implementation which does include the option.

         silently discard
                       The implementation discards the packet without
                       further processing, and without indicating an error
                       to the sender. The implementation SHOULD provide
                       the capability of logging the error, including the
                       contents of the discarded packet, and SHOULD record
                       the event in a statistics counter.

3. DSTM Overview and Assumptions

   DSTM, as discussed in the introduction, is a method that uses
   existing protocols.  This document does not specify a new protocol.
   However, DSTM defines node, server and TEP behaviours as well as the
   properties of the temporary addresses allocation mechanism.

   The motivation for DSTM is to provide IPv6 hosts a means to acquire
   an IPv4 address, for communications with IPv4-only hosts or through
   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, where only IPv6

Bound,Toutain,Medina and al.  Expires August 2002               [Page 5]

INTERNET-DRAFT       draft-ietf-ngtrans-dstm-07.txt        February 2002

   packets are carried. 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), despite the presence of IPv4 addresses in the
   payload of a packet.

   The following assumptions describe the model used by DSTM:

     - A DSTM domain is within an Intranet not on the Internet.

     - IPv6 nodes do not maintain an IPv4 address except on a temporary basis,
       to communicate with IPv4-only nodes and/or IPv4 applications.

     - The temporary IPv4 address allocation is performed by the DSTM server.
       Different protocols (DHCPv6 being the logical choice) can be used
       for the allocation process. Native IPv6 communication between server and
       client is one restriction in this matter.

     - As an extension to the address allocation process, the DSTM server may also
       provide a range of port numbers to be used by the client. This would allow
       the use of the same IPv4 address by several DSTM nodes at the same time,
       reducing the size of the required IPv4 address pool.

     - Inside a DSTM domain, IPv4 routing tables are kept to a minimum on
       behalf of IPv6 routing, hence, reducing the network management required
       for IPv4 during transition.

     - Once an IPv6 node has obtained an IPv4 address (and maybe a port range),
       4over6 tunnelling is used to forward packets from the node to a DSTM TEP,
       where the packet is decapsulated and forwarded using IPv4. As part of the
       address allocation process, the DSTM server SHOULD provide the client with
       the IPv6 address of the TEP to be used.

     - Existing IPv4 applications do not need to be modified to run on DSTM nodes.

     - A DSTM Node can communicate with any IPv4-only host, as long as the
       destination address is reachable from the TEP used by the node.

Bound,Toutain,Medina and al.  Expires August 2002               [Page 6]

INTERNET-DRAFT       draft-ietf-ngtrans-dstm-07.txt        February 2002

   A schematic overview of DSTM is as follows:

           DSTM Domain (Intranet)                |    IPv4 Internet or Intranet
                                                 |        IPv4 Applications
                  +---------------------+        |             Domain
                  |     DSTM Server     |        |
                  +---------------------+        |
                                ^  ^             |
                                |  |             |
     +----DSTM Node----+        |                |
     |                 |        |  |           +--------+
     | IPv6/IPv4 Node  |        |   - - - - - >| DSTM   |
     |                 |        |              | TEP    |
     |-----------------|        |              |        |
     |   DSTM client   |<-------+              | IPv6   |-------------->
     |-----------------|                       |   &    |     IPv4
     |  4over6 iface   |<=====================>|  IPv4  |
     +-----------------+     IPv4 over IPv6    +--------+
                                 tunnel          |
                IPv6-only Network                |

   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.

4. DSTM Node Requirements.

4.1 Configuration of the IPv4 stack

   As long as communications can take place in native IPv6, no IPv4
   address is given to the DSTM node. The host can detect the need of an
   IPv4 address by different methods: when a query to the DNS resolver
   results in an IPv4 destination address, when an application opens an
   IPv4 socket, or when an IPv4 packet is sent to the kernel and no
   interface is ready to forward that packet.

   When the first IPv4 packet needs to be sent, the DSTM client MUST
   contact the DSTM server. This document does not specify any
   particular mechanism for DSTM client/server communication. Following
   this message exchange, the client obtains from the server a temporary
   IPv4 address as well as the IPv6 address of a TEP. If allowed by the
   implementation, the server MAY also provide the port range to be
   used. This information is used to configure the 4over6 interface. It
   is at this point that the IPv4 stack is configured.

Bound,Toutain,Medina and al.  Expires August 2002               [Page 7]

INTERNET-DRAFT       draft-ietf-ngtrans-dstm-07.txt        February 2002

4.2 IPv4 packet forwarding

   In the absence of an IPv4 routing infrastructure, a DSTM node can not
   directly send IPv4 packets on the network. It has to encapsulate them
   into IPv6 packets and send them to a Tunnel End Point (which can be
   seen as a particular DSTM node) that will decapsulate the packet and
   forward them into the IPv4 network.

   On a DSTM node, this encapsulation is done by a 4over6 interface.
   All IPv4 traffic can be directed to that interface by an IPv4 routing
   table entry. The exact details of the 4over6 interface and the
   associated routing table entries are implementation dependant.

4.3 DSTM processing of IPv4 packets

   When a DSTM Node needs to send an IPv4 packet, it is sent to the
   4over6 interface. If the 4over6 interface is not configured (it does
   not have an IPv4 address), the process SHOULD be blocked and the DSTM
   Server SHOULD be contacted to get a temporary address. Once an
   address is allocated, it is used as the IPv4 source address for all
   the packets leaving the interface.  The other fields of the IPv4
   packet are normally filled.

4.4 IPv6 packet construction

   When the 4over6 interface encapsulates an IPv4 packet into an IPv6
   packet, it has to determine the IPv6 destination address. Usually,
   this will be the address of a TEP. At the node, the address of the
   TEP can be either statically configured or dynamically acquired when
   the DSTM node obtains an IPv4 address from the DSTM Server.

   The IPv6 address of the TEP SHOULD be provided by the DSTM server
   when the DSTM node receives a temporary IPv4 address (section 5).
   However, a DSTM node MAY manually configure the TEP during early
   deployment of DSTM. This will not scale and is not recommended as a
   long term transition solution.

   The next header type for encapsulation of IPv4 is 4 (as for IPv4
   tunnelling over IPv4). When a tunnelled packet arrives to the IPv6
   destination, the IPv6 header is removed and the packet is processed
   by the IPv4 layer.  The IPv4 packet will then be forwarded by the TEP
   using the IPv4 infrastructure.  The TEP SHOULD cache the association
   between the IPv4 and IPv6 source addresses.

   The IPv6 source address of an encapsulated packet SHOULD be the IPv6
   address of the physical interface on which the IPv6 packet will be

Bound,Toutain,Medina and al.  Expires August 2002               [Page 8]

INTERNET-DRAFT       draft-ietf-ngtrans-dstm-07.txt        February 2002

5. DSTM Server Requirements

   The DSTM server is in charge of the temporary IPv4 address
   allocation. 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. To
   reduce the need of IPv4 addresses, some implementations MAY include a
   port range as part of the allocation process. This would allow the
   use of the same IPv4 address by several nodes simultaneously.

   The DTSM server MUST memorize the mapping between the IPv6 address of
   the node requesting an address and the allocated IPv4 address. The
   IPv4 address is allocated by the server for a fixed amount of time.
   This duration MUST be included in the response. If the client needs
   the IPv4 address for a longer period of time, the client MUST renew
   the lease.

   Routing in the IPv4 realm MUST ensure that the pool of IPv4 global
   addresses managed by a DSTM server is routed to one or more TEPs in
   the DSTM domain. When allocating an address to a DSTM Node, the
   server message SHOULD include the IPv6 address of the TEP in charge
   of the allocated address. Additionally, the DSTM Server MAY be in
   charge of configuring the IPv4/IPv6 mapping table at the TEP, if it
   can not be constructed dynamically or dynamic construction is
   disabled for security reasons.

   The communication between the DSTM client and the server MUST be in
   IPv6.  Describing the different methods that can be used to assure
   such communication is out of scope and will be described in other

   The DSTM server MAY allocate a temporary IPv4 address without a
   request from he client.

   The DSTM server SHOULD be able to authenticate the DSTM client.

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.

Bound,Toutain,Medina and al.  Expires August 2002               [Page 9]

INTERNET-DRAFT       draft-ietf-ngtrans-dstm-07.txt        February 2002

   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
   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 [9, 10]. 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
   [2]. Also, since the TEPs are inside an intranet, they can not be
   used as an open relays.  Finally, for IPv4 communications on DSTM
   nodes, once the node has an IPv4 address, IPsec [3] can be used since
   DSTM does not break secure end-to-end communications at any point.

   Changes from draft 03 to draft 04

      1.  Changed DHCPv6 options and processing to comply with

   Changes from draft 02 to draft 03

      1.  Working Group Edits

   Changes from draft 01 to draft 02

Bound,Toutain,Medina and al.  Expires August 2002              [Page 10]

INTERNET-DRAFT       draft-ietf-ngtrans-dstm-07.txt        February 2002

      1.  Added futher clarifications to DSTM components.

      2.  Added client/server details for DHCPv6 ngtrans extension.

      3.  Removed optional scenarios to simplify this mechanism.

      4.  Removed AIIH concepts and changed to be DSTM components.

      5.  Add Applicability Statement

      6.  Added acknowledgment section and new coauthors Francis Dupont
          and Alain Durand.

   Changes from draft 00 to draft 01

      1.  Added text explaining why the draft does not use DHCPv4 to assign
          IPv4 compatible addresses to the "Introduction".

      2.  Defined what is mandatory and what is optional and added relative
          text in various places to clarify this change.  And added RFC
          2119 adjectives to the spec where appropriate.

      3.  Scenario 1 where IPv6 node wants to communicate with IPv4
          node is mandatory.

      4.  Scenarios 2 and 3 are now optional where an IPv6 node is
          assigned an IPv4 compatible address because an external
          IPv4 node is attempting communications with the IPv6 node.

      5.  For scenario 1 DHCPv6 is only needed for DSTM and not the
          tightly coupled paradigm of a co-existent DHCPv6 and
          DNS server.  Also added mandatory and optional to the
          DSTM AIIH/NODE/ROUTER Diagram.

      6.  Made Static Tunnel Endpoints mandatory and Dynamic Tunnel
          End Points optional.

      7.  Fixed DHCPv6 Reconfigure statements to take into account
          changes to the Reconfigure message in the DHCPv6 working
          group, to support AIIH processing.


   The authors would like to acknowledge the implementation
   contributions by Stephane Atheo at ENST Bretagne who has implemented
   a DSTM prototype on FreeBSD and input to this specification.  We
   would also like to thank the NGTRANS Working Group for their input.

Bound,Toutain,Medina and al.  Expires August 2002              [Page 11]

INTERNET-DRAFT       draft-ietf-ngtrans-dstm-07.txt        February 2002

Normative References

      [1]  S. Deering and R. Hinden.  Internet Protocol, Version 6 (IPv6)
           Architecture", RFC 2460, December 1998.

      [3]  IPSEC -
           S. Kent, R. Atkinson. Security Architecture for the Internet
           Protocol.  RFC 2401, November 1998.
           S. Kent, R. Atkinson. IP Authentication Header.
           RFC 2402, November 1998.
           S. Kent, R. Atkinson.  IP Encapsulating Security Payload
           RFC 2406, November 1998.

      [4]  S. Bradner.  Key words for use in RFCs to indicate Requirement
           Levels.  RFC 2119, March 1997.

      [5]  A. Conta and S. Deering.  Generic Packet Tunneling in IPv6.
           RFC 2473, December 1998.

      [6]  R. Gilligan and E. Nordmark.  Transition Mechanisms for IPv6
           Hosts and Routers.  RFC 2893, August 2000.

      [7]  R. Droms.  Dynamic Host Configuration Protocol.
           RFC 2131, March 1997.

      [8]  Thomson, Narten.  IPv6 Stateless Address Configuration.
           RFC 2462, December 1998.

      [9]  Hinden, Deering.  IP Version 6 Addressing Architecture.
           RFC 2373, July 1998.

Informative References

      [2]  J. Bound, M. Carney, C. Perkins, and R. Droms.  Dynamic Host
           Configuration Protocol for IPv6.  draft-ietf-dhc-dhcpv6-16.txt
           October 2001 (work in progress).

Authors' Address

       Jim Bound
       Compaq Computer Corporation
       110 Spitbrook Road
       Nashua, NH 003062, USA.
       Email: Jim.Bound@compaq.com

Bound,Toutain,Medina and al.  Expires August 2002              [Page 12]

INTERNET-DRAFT       draft-ietf-ngtrans-dstm-07.txt        February 2002

       Laurent Toutain
       ENST Bretagne
       BP 78
       35512 Cesson Sevigne Cedex, FR.
       Phone : +33 2 99 12 70 26
       Email : Laurent.Toutain@enst-bretagne.fr

       Octavio Medina
       ENST Bretagne
       BP 78
       35512 Cesson Sevigne Cedex, FR.
       Phone : +33 2 99 12 70 23
       Email : Octavio.Medina@enst-bretagne.fr

       Francis Dupont
       ENST Bretagne
       BP 78
       35 512 Cesson Sevigne Cedex, FR.
       Phone : +33 2 99 12 70 33
       Email : Francis.Dupont@enst-bretagne.fr

       Hossam Afifi
       91011  Evry, FR.
       Phone : +33 1 60 76 40 40
       Email : Hossam.Afifi@int-evry.fr

       Alain Durand
       Sun Microsystems
       901 San Antonio Road
       UMPK 17-202
       Palo Alto, CA 94303-4900, USA.
       Email: Alain.Durand@sun.com

Bound,Toutain,Medina and al.  Expires August 2002              [Page 13]