INTERNET-DRAFT                                     M. Krampell
February 2001                                      Eurescom
Expires August, 2001                               A. Gibier
                                                   British Telecom
                                                   A. Zehl 
                                                   Deutsche Telekom
                                                   P. Kyheroinen 
                                                   Elisa Communications
                                                   A. Baudot   
                                                   France Telecom
                                                   G. Egeland
                                                   Telenor
                                                   P. Nielsen
                                                   TDC Tele Denmark
                                                   J. Vieira
                                                   Portugal Telecom

                  Interaction of transition mechanisms 

          <draft-krampell-v6transition-interaction-00.txt>

   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.

   Distribution of this memo is unlimited.

Abstract

   This document discusses interaction of transition mechanisms that
   can be involved in a communication between two end-points. Various
   transition mechanisms are defined to solve single transition issues.
   They are supposed to be used once along the path of a single
   communication. During the transition phase disparate network
   architecture will introduce multiple transition mechanisms in
   different ways. It will not be possible to predict the number and
   the nature of the transition mechanisms that can be encountered
   along the path of a communication. This memo aims to identify cases
   where multiple transition mechanisms can be involved, and what can
   be the interaction effects between them. 

Krampell                                  Expires August 2001  [page 1]

Internet Draft       Interaction of transition mechanisms      Feb 2001


Table of Contents

   1. Introduction..................................................4
   2. Definition of the transition phases...........................4
   3. Classification of single transition mechanisms................4
     3.1 Connecting IPv4 sources and destinations over IPv6
         networks (v4 host to v4 host)..............................4
       3.1.1 Dual stack transition mechanism (DSTM).................5
     3.2 Connecting IPv6 source to IPv6 destinations over IPv4
         networks(v6 host to v6 host)...............................5
       3.2.1 Tunnel Broker (TB).....................................5
       3.2.2 6TO4...................................................5
       3.2.3 6OVER4.................................................5
     3.3 Communication between IPv4 source and IPv6 destination
         (v4 host to v6 host).......................................5
       3.3.1 SOCKS..................................................5
       3.3.2 Network Address and Protocol Translator (NAT-PT).......6
       3.3.3 Bump In The Stack (BIS)................................7
     3.4 Communication between IPv6 source and IPv4 destination
         (v6 host to v4 host).......................................7
       3.4.1 SOCKS..................................................7
       3.4.2 Network Address and Protocol Translator (NAT-PT).......7
       3.4.3 Bump In The Stack (BIS)................................7
   4. Transition mechanisms for the early phase.....................8
     4.1 Combining multiple transition mechanisms for a single
         connection.................................................8
     4.2 Table of combinations......................................9
     4.3 Comments on the table......................................9
       4.3.1 6to4 combined with DSTM................................9
       4.3.2 6to4 combined with SOCKS...............................9
       4.3.3 6to4 combined with NAT-PT.............................10
       4.3.4 Tunnel broker combined with DSTM......................10
       4.3.5 Tunnel Broker combined with SOCKS.....................10
       4.3.6 Tunnel Broker combined with NAT-PT....................11
       4.3.7 Tunnel Broker combined with BIS.......................11
       4.3.8 DSTM combined with 6to4...............................11
       4.3.9 DSTM combined with Tunnel Broker.. ...................12
       4.3.10 DSTM combined with SOCKS.............................12
       4.3.11 DSTM combined with BIS...............................12
       4.3.12 DSTM combined with 6over4............................12
       4.3.13 SOCKS combined with 6to4.............................13
       4.3.14 SOCKS combined with Tunnel Broker....................13
       4.3.15 SOCKS combined with BIS..............................13
       4.3.16 SOCKS combined with 6over4...........................13
       4.3.17 NAT-PT combined with 6to4............................14
       4.3.18 NAT-PT combined with Tunnel Broker...................14
       4.3.19 NAT-PT combined with DSTM............................14
       4.3.20 NAT-PT combined with SOCKS...........................15
       4.3.21 NAT-PT combined with NAT-PT..........................15
       4.3.22 NAT-PT combined with 6over4..........................16
       4.3.23 BIS combined with DSTM...............................16
       4.3.24 BIS combined with SOCKS..............................16

Krampell                                  Expires August 2001  [page 2]

Internet Draft       Interaction of transition mechanisms      Feb 2001




       4.3.25 6over4 combined with DSTM............................16
       4.3.26 6over4 combined with SOCKS...........................16
       4.3.27 6over4 combined with NAT-PT..........................17
   5. Transition mechanisms for the late phase.....................17
     5.1 Combining multiple transition mechanisms for a single
         connection................................................17
     5.2 Table of combinations.....................................18
     5.3 Comments on the table.....................................18
       5.3.1 6to4 combined with other mechanisms...................18
       5.3.2 Tunnel Broker combined with DSTM......................18
       5.3.3 Tunnel Broker combined with SOCKS.....................19
       5.3.4 Tunnel Broker combined with 6over4....................19
       5.3.5 DSTM combined with Tunnel Broker......................19
       5.3.6 DSTM combined with SOCKS..............................20
       5.3.7 DSTM combined with NAT-PT.............................20
       5.3.8 DSTM combined with BIS................................21
       5.3.9 DSTM combined with 6over4.............................21
       5.3.10 SOCKS combined with DSTM.............................21
       5.3.11 NAT-PT combined with DSTM............................21
       5.3.12 NAT-PT combined with SOCKS...........................21
       5.3.13 NAT-PT combined with NAT-PT..........................22
       5.3.14 NAT-PT combined with BIS.............................22
       5.3.15 NAT-PT combined with 6over4..........................23
       5.3.16 BIS combined with DSTM...............................23
       5.3.17 6over4 combined with DSTM............................23
   6. Combination of the results of the early and late phase.......23
     6.1 Table of combinations.....................................24 
     6.2 Comments on table.........................................24 
   7. Parallel single transition mechanism across multiple
      communications...............................................24
   8. Results from the combination of mechanisms and conclusions...25
     8.1 Observations..............................................25
     8.2 Conclusions...............................................25
  9. References....................................................26
 10. Acknowledgements..............................................27
 11. Authors' addresses............................................27















Krampell, P1009                           Expires August 2001  [page 3]

Internet Draft       Interaction of transition mechanisms      Feb 2001



1. Introduction

   This document discusses interaction of transition mechanisms that
   can be involved in a communication between two end-points. Various
   transition mechanisms are defined to solve single transition issues.
   They are supposed to be used once along the path of a single
   communication. During the transition phase separate network
   architectures will introduce multiple transition mechanisms in
   different ways.

   This memo aims to identify realistic cases where two transition
   mechanisms can be involved, and what the interaction effects between
   them will be. Two different network topologies are considered : the
   earlier transition phase involving a large IPv4 network and small
   IPv6 islands, and the latter transition phase involving a large IPv6
   network and small IPv4 islands.

   This memo does not take into account quality of service or security
   considerations. These are out of the scope of the document.

   Section 2 defines the transition phases used in the document.
   Section 3 defines and classifies the current transition mechanisms.
   Section 4 discusses the transition mechanisms interaction in the
   early transition phase. Section 5 discusses the transition
   mechanisms interaction in the later transition phase.

2. Definition of the transition phases

   Early phase		large IPv4 ocean, interconnected IPv6 clouds.
   Late phase		large IPv6 ocean, only partially connected IPv4
                        clouds.

3. Classification of single transition mechanisms

   From the end-to-end point of view there are different types of
   communication possible between two nodes.

   . IPv4 source with IPv4 destination
   . IPv6 source with IPv6 destination.
   . IPv4 source with IPv6 destination
   . IPv6 source with IPv4 destination.

   Each transition mechanism  mentioned in this document applies to one
   of the four cases above, and will be described in the following
   sections.

3.1 Connecting IPv4 sources and destinations over IPv6 networks (v4
    host to v4 host).




Krampell                                  Expires August 2001  [page 4]

Internet Draft       Interaction of transition mechanisms      Feb 2001

3.1.1 Dual stack transition mechanism (DSTM)

   Dual stack transition mechanism [DSTM] enables a full IPv4 end-to-
   end communication between a dual stack node within an IPv6-only
   network to an IPv4-only host. DSTM is based on tunnelling, using
   dynamic tunnel interface combined with temporary IPv4 address
   allocation provided by a DHCPv6 server. 

3.2 Connecting IPv6 sources to IPv6 destinations over IPv4 networks (v6
    host to v6 host)

3.2.1 Tunnel Broker (TB)

   Tunnel broker [BROKER] is mainly aimed at the isolated user or early
   IPv6 adopter allowing rapid connectivity to a native IPv6 network
   such as the 6Bone. The tunnel broker system automatically manages
   the tunnel requests from end users thus reducing the management
   overhead traditionally associated with the configuration of tunnels.
   The tunnel broker assigns an IPv6 address to the dual stack host
   which it returns along with its DNS name and client configuration
   information. The TB method is aimed more at short term periods of
   native IPv6 connectivity rather than providing long term access.

3.2.2 6TO4

   The 6to4 [6to4] method enables IPv6 sites to connect to other IPv6
   sites over the legacy IPv4 Internet infrastructure. This method
   will only be used in the early phase of transition from IPv4 to
   IPv6 networks (large IPv4 ocean with small IPv6 islands). The aim
   of this method is to allow isolated IPv6 sites (or hosts), which are
   attached to an IPv4 network which has no native Ipv6 support, to
   communicate with other IPv6 domains. The IPv6 host which uses this
   method does not require an IPv4-compatible IPv6 address, or
   configured tunnels. The presence of firewalls in IPv4 networks does
   not affect the 6to4 mechanism as long as the 6to4 router has a
   globally routable IPv4 address.

3.2.3 6OVER4

   The 6over4 [RFC2529] technique allows isolated IPv6 hosts to act
   like fully functional IPv6 hosts even without direct contact with an
   IPv6 router. 6over4 uses IPv4 multicast to create a
   "virtual Ethernet".

3.3 Communication between IPv4 source and IPv6 destination (v4 host to
    v6 host)

3.3.1 SOCKS

   SOCKSv5 provides a mechanism for a gateway named "SOCKS Server" to
   act as a relay of TCP and UDP connections between two end hosts.
   One host will be behind the SOCKS Server which is usually in a


Krampell                                  Expires August 2001  [page 5]

Internet Draft       Interaction of transition mechanisms      Feb 2001



   private network and the other host will be on the outside of that
   network. The main points for this mechanism are:

   - The host behind the SOCKS Server must use "socksified clients".
     This means that SOCKSv5 installs an additional library in that
     host, which acts as a "shim" layer between the application
     (clients) and the transport layers. The applications need no
     change, since this "shim" layer translates the socket calls
     invoked by the application to the modified socket calls used in
     the SOCKSv5 client-host to SOCKS-Server framework.
   - One restriction of the SOCKS mechanism is that connections must
     always be initiated by the internal host which is the one behind
     the SOCKS Server. SOCKSv5 is considered a one way mechanism
     although it can be configured to translate IPv4 to IPv6 or IPv6 to
     IPv4.
   - Since the SOCKS Server is a dual stack host and includes
     translation protocol procedures according to the SIIT algorithm,
     it can be configured to provide IPv4 to IPv6 translation or vice
     versa but only one of them in a particular SOCKS Server machine.
   - It is important also that security mechanisms to authenticate and
     deny/permit access to internal hosts can be used in the SOCKS
     Server.

   In this way, a small or medium sized IPv4 network can provide access
   to an IPv6 external network using a SOCKS Server in a dual stack
   machine with access to both networks. When an internal IPv4 host
   wants to establish a connection with an IPv6 external host it sends
   a request to the SOCKS Server using the FQDN (Full Qualified Domain
   Name) of the remote host. The SOCKS Server resolves that name to an
   IPv6 address and sends a fake IPv4 address to the internal host.
   So two connections are maintained: one TCP IPv4 connection between
   the internal host and the gateway (UDP would be encapsulated in
   TCP), and the other UDP or TCP IPv6 connection with the external
   IPv6 host. Applications are not aware of all these processes, since
   they make socket calls with the usual socket API and these calls are
   intercepted by the "shim" SOCKSv5 layer.

3.3.2 Network Address and Protocol Translator (NAT-PT)

   NAT-PT allows native IPv6 hosts and applications to communicate with
   native IPv4 hosts and applications, and vice versa. A NAT-PT device
   resides at the boundary between an IPv6 and an IPv4 network.
   NAT-PT provides a combination of header translation and address
   translation. Header translation is necessary to convert an IPv4
   header to IPv6 header format and vice versa. Address translation is
   needed in order for hosts of one network to be able to identify
   hosts of the other network using the native address format of the
   first network. What this means is that an IPv4 host has to be able
   to identify an IPv6 host using an IPv4 address and an IPv6 host has
   to identify an IPv4 host via an IPv6 address. NAT-PT manages this
   cross network identification.

Krampell                                  Expires August 2001  [page 6]

Internet Draft       Interaction of transition mechanisms      Feb 2001



   NAT-PT allocates an IPv4 pool address when an IPv4 host is
   communicating with an IPv6 host - the IPv4 pool address being used
   to identify the IPv6 host. NAT-PT handles the mapping of the IPv4
   pool address to the IPv6 host, during the duration of the session
   between IPv4 and IPv6 host.

   NAT-PT may optionally include a selection of Application Level
   Gateways (ALG). ALGs are necessary where an IP application has
   addresses embedded within the IP packet payload. Examples of this
   are FTP and DNS. NAT-PT normally only converts the IP addresses
   contained in the IP header. For these applications, NAT-PT must
   investigate the packet payload and convert the embedded addresses
   to the format of the destination network.


3.3.3 Bump In The Stack (BIS)

   The mechanism [RFC2767] consists in intercepting DNS requests from
   an IPv4 application and adding a AAAA record to it. If the DNS
   response indicates an IPv6 host, the IPv6 address is mapped to a
   local IPv4 address and the traffic from the IPv4 application is
   translated into IPv6 and vice versa.  This allows IPv4 hosts to
   communicate with other IPv6 hosts using existing IPv4 applications.

3.4 Communication between IPv6 source and IPv4 destination (v6 host to
    v4 host)

3.4.1 SOCKS

   Read section 3.3.1 for more information on SOCKS. This mechanism can
   be configured for communication between IPv4 source and IPv6
   destination and vice versa.

3.4.2 Network Address and Protocol Translator (NAT-PT)

   Conversely to 3.3.2 above, an IPv6 host will identify an IPv4 host
   via an IPv6 compatible IPv4 address. The IPv6 compatible IPv4
   address is composed of the IPv4 address of the IPv4 host plus a 96
   bit prefix added by NAT-PT. NAT-PT adds the prefix as a packet
   passes from the IPv4 network to the IPv6 network and removes it from
   packets passing in the opposite direction.

   NAT-PT may optionally include a selection of Application Level
   Gateways (ALG) (read section 3.3.2).

3.4.3 Bump In The Stack (BIS)

   When a BIS host receives an IPv6 datagram, the translator of the BIS
   mechanism will try to translate the IPv6 packet into an IPv4 packet.
   Since it does not know how to translate the IPv6 address, it will


Krampell                                  Expires August 2001  [page 7]

Internet Draft       Interaction of transition mechanisms      Feb 2001



   request that the mapper provides a mapping for the IPv6 destination
   and source address. The mapper will register its own IPv4 address as
   the destination IPv6 address and pick an IPv4 address out of the
   pool for the IPv6 source address. The translator can now translate
   the packet and afterwards send it to the application.

4. Transition mechanisms for the early phase

                    +----------------+
                    |                |
   +----------+     |                |     +----------+
   |   IPv6   |     |      IPv4      |     |   IPv6   |
   |  Network |-----|     Network    |-----|  Network |
   |          |     |    (Internet)  |     |          |
   +----------+     |                |     +----------+
                    |                |
                    |                |
                    +----------------+

4.1 Combining multiple transition mechanisms for a single connection

   This section describes the different cases where multiple transition
   mechanisms can be involved in the same communication between to
   end-points. It will also analyse their interaction issues related to
   name resolution and other limitations.



























Krampell                                  Expires August 2001  [page 8]

Internet Draft       Interaction of transition mechanisms      Feb 2001



4.2 Table of combinations


   Src \ Dest  6to4  Tunnel Br  DSTM  SOCKS  NAT-PT  BIS  6over4
   -------------------------------------------------------------
   6to4        x       A(1)      N/A   N/A   A(2)    A(1)   A(1)

   Tunnel Br   A(1)    x         N/A   N/A   N/A     A(2)   A(1)

   DSTM        N/A     N/A       x     A(3)  A(1)    N/A    N/A

   SOCKS       A(2)    N/A       A(1)  x     A(1)    N/A    N/A

   NAT-PT      A(2)    N/A       A(2)  N/A   x       A(1)   N/A

   BIS         A(1)    A(1)      N/A   N/A   A(1)    x      A(1)

   6over4      A(1)    A(1)      N/A   N/A   N/A     A(1)   x


   Applicable 
   A(1) = will work
   A(2) = with special limitation, see comment
   A(3) = one mechanism has a limitation
   N/A = Not applicable, because mechanisms have a different goal
   x = no interaction of transition mechanisms

4.3 Comments on the table

   The Comments on the table will contain descriptions only if the
   answer is A(2), A(3) or N/A. A(1) is obvious.

4.3.1 6to4 combined with DSTM
   
   The two mechanisms have different goals, and cannot fit together.
   6to4 aims at connecting two isolated IPv6 islands, while DSTM aims
   at allowing end-to-end IPv4 communication between a dual stack host
   located within an IPv6-only network.

4.3.2 6to4 combined with SOCKS
   
   This case is not applicable because the source is not located in the
   inner side of the SOCKS gateway, as required by the mechanism
   (see section 3.3.1).








Krampell                                  Expires August 2001  [page 9]

Internet Draft       Interaction of transition mechanisms      Feb 2001



4.3.3 6to4 combined with NAT-PT
   
                      |               |              |
   ---IPv6 cloud----->|<--IPv4 ocean->|<-IPv6 cloud->|<-IPv4 ocean--
                      |               |              |
      +----+       +----+          +----+         +-----+        +----+ 
      |IPv6|==[v6]=|6to4|===[v4]===|6to4|===[v6]==|NATPT|==[v4]==|IPv4|
      +----+       +----+          +----+         +-----+        +----+
         |                                                          |
         +-------------------(v6)-----------------(v6/v4)----(v4)---+

   ==[v4]== IPv4 network
   ==[v6]== IPv6 network
   --(v4)-- IPv4 packet
   --(v6)-- IPv6 packet
   (v6/v4)  translation

   In this scenario, if the 6to4 site is able to do DNS resolution
   through NAT-PT then it will work fine. Otherwise it will not work.

4.3.4 Tunnel Broker combined with DSTM

   This case is not applicable. The two mechanisms have different goals
   and cannot fit together. Tunnel broker aims at allowing IPv6 end-to-
   end communication between an isolated dual stack host within an IPv4
   network and an IPv6-only host, while DSTM aims at allowing IPv4 end-
   to-end communication between an isolated dual stack host within an
   IPv6 network and an IPv4 only host. Actually these two mechanisms
   apply to opposite or symmetrical cases. 

4.3.5 Tunnel Broker combined with SOCKS

   It does not work. Due to the inherent nature of SOCKS, it is not
   possible to initiate a communication from outside the socks domain.
                            
    ---IPv4 ocean--->|<-IPv6 cloud->|<--------IPv4 ocean----------
                     |              |
   +-------+      +-----+      +--------+      +-----------------+
   |IPv6/v4|==v4==|TB/S |==v6==|SOCKS GW|==v4==|IPv4 SOCKS client|
   +-------+      +-----+      +--------+      +-----------------+
       |                                                |
       +-----------(v6)---------(v6/v4)-----(v4)--------+

   ==[v4]== IPv4 network
   ==[v6]== IPv6 network
   --(v4)-- IPv4 packet
   --(v6)-- IPv6 packet
   (v6/v4)  translation




Krampell                                 Expires August 2001  [page 10]

Internet Draft       Interaction of transition mechanisms      Feb 2001



   Further, the dual stack host supported by the tunnel broker has both
   native IPv4 and IPv6 connectivity and therefore does not require any
   translation facilities. Both source and destination can communicate
   directly within the IPv4 ocean.

4.3.6 Tunnel Broker combined with NAT-PT

    ---IPv4 ocean--->|<-IPv6 cloud-->|<-----IPv4 ocean------
                     |               |
   +-------+      +-----+       +--------+      +-----------+
   |IPv6/v4|==v4==|TB/S |==v6===| NAT-PT |==v4==|IPv4 client|
   +-------+      +-----+       +--------+      +-----------+
       |                                              |
       +-----------(v6)----------(v6/v4)-----(v4)-----+

   ==[v4]== IPv4 network
   ==[v6]== IPv6 network
   --(v4)-- IPv4 packet
   --(v6)-- IPv6 packet
   (v6/v4)  translation
                            
   This case is not applicable. The dual stack host supported by the
   tunnel broker has both native IPv4 and IPv6 connectivity and
   therefore does not require any translation facilities.

4.3.7 Tunnel Broker combined with BIS

                       |
   ---IPv4 ocean------>|<-----IPv6 island------
                       |
   +-------+        +----+        +-----------+
   |IPv6/v4|==[v4]==|TB/S|==[v6]==|BIS IPv4/v6|
   +-------+        +----+        +-----------+
       |                                     |
       +-------------(v6)----------(v6/v4)-(v4)

   ==[v4]== IPv4 network
   ==[v6]== IPv6 network
   --(v4)-- IPv4 packet exchange
   --(v6)-- IPv6 packet exchange
   (v6/v4)  translation
   
   The communication will work from the BIS host to the dual stack host
   over the Tunnel Broker only, if the tunnel is already established
   between Tunnel Client and Tunnel Broker.

4.3.8 DSTM combined with 6to4
   
   This case is not applicable because the two mechanisms have
   different goals and cannot fit together. 6to4 enables IPv6 end-to-


Krampell                                 Expires August 2001  [page 11]

Internet Draft       Interaction of transition mechanisms      Feb 2001



   end communication between IPv6-only hosts within IPv6-only networks
   over an IPv4-only network, while DSTM enables IPv4 end-to-end
   communications between a dual-stack host within an IPv6-only network
   and an IPv4-only host.

4.3.9 DSTM combined with Tunnel Broker
   
   This case is not applicable because the two mechanisms have
   different goals and cannot fit together. See section 4.3.1 (Tunnel
   Broker combined with DSTM).

4.3.10 DSTM combined with SOCKS

                         |                |
   ------IPv6 cloud1---->|<--IPv4 ocean-->|<--IPv6 cloud2---
                         |                |                  
   +-------+        +--------+        +-----+        +----+
   |IPv4/v6|==[v6]==|DSTM TEP|==[v4]==|SOCKS|==[v6]==|IPv6|
   +-------+        +--------+        +-----+        +----+
       |                                                |
       +------------v4----------------(v4/v6)----v6-----+

   ==[v4]== IPv4 network
   ==[v6]== IPv6 network
   --(v4)-- IPv4 packet exchange
   --(v6)-- IPv6 packet exchange
   (v4/v6)  translation
   TEP      Tunnel End Point

   This case is applicable but due to the inherent nature of SOCKS, it
   is not possible to initiate a communication from outside the socks
   domain. The IPv6 host would be seen as an IPv4 host through
   the SOCKS mechanism, but no communication can be initiated.

4.3.11 DSTM combined with BIS

   This case is not applicable because BIS enables an IPv4 application
   to communicate with an IPv6 hosts, over an IPv6 end-to-end
   communication, while DSTM enables IPv4 end-to-end communication
   between a dual-stack host within an IPv6-only network and an
   IPv4-only host. These two mechanisms cannot fit together.

4.3.12 DSTM combined with 6over4
   
   This case is not applicable because 6over4 enables IPv6 end-to-end
   communication between IPv6-only hosts within IPv6-only networks over
   an IPv4-only network, while DSTM enables IPv4 end-to-end
   communication between a dual-stack host within an IPv6-only network
   and an IPv4-only host. These two mechanisms cannot fit together.



Krampell                                 Expires August 2001  [page 12]

Internet Draft       Interaction of transition mechanisms      Feb 2001



4.3.13 SOCKS combined with 6to4

   ---IPv4 ocean---->|<-IPv6 cloud1->|<--IPv4 ocean-->|<-IPv6 cloud2--
                     |               |                |
     +----+       +------+         +----+          +----+        +----+
     |IPv4|==[v4]=|SOCKS |===[v6]==|6to4|===[v4]===|6to4|==[v6]==|IPv6|
     +----+       +------+         +----+          +----+        +----+
        |                                                          |
        +---(v4)---(v4/v6)-----------------(v6)--------------------+

      ==[v4]== IPv4 network
      ==[v6]== IPv6 network
      --(v4)-- IPv4 packet exchange
      --(v6)-- IPv6 packet exchange
      (v4/v6)  translation

   The destination is an IPv6 host seen as an IPv4 host through the
   SOCKS box, and can only be reached through the 6to4 mechanism from
   cloud1 to cloud2. Some special DNS arrangements have to be made for
   this scenario to work. The DNS resolution must involve an DNS server
   on the IPV6 that holds the SOCKS box.

4.3.14 SOCKS combined with Tunnel Broker
   
   This case is not applicable. Tunnel Broker is a tunnel type
   mechanism that will be used in homogenous communications while
   SOCKS is a translation type one, so their combination will not
   happen in a three-cloud scenario.

4.3.15 SOCKS combined with BIS

   This case is not applicable. BIS enables IPv4 applications to
   operate over IPv6 networks so it would be necessary to use another
   Transition Mechanism in the same site to connect with the IPv4
   world-cloud.

4.3.16 SOCKS combined with 6over4

   This case is not applicable. 6over4 uses IPv4 multicast to provide
   communication between dual stack hosts and IPv6 hosts placed in IPv6
   only areas. Then it is used only when the world-cloud is IPv6 and it
   does not make sense in the early transition phase in an
   IPv6-IPv4-IPv6 scenario.









Krampell                                 Expires August 2001  [page 13]

Internet Draft       Interaction of transition mechanisms      Feb 2001



4.3.17 NAT-PT combined with 6to4

                     |               |                |
   ---IPv4 ocean---->|<-IPv6 cloud1->|<--IPv4 ocean-->|<-IPv6 cloud2---
                     |               |                |
     +----+       +------+         +----+          +----+        +----+ 
     |IPv4|==[v4]=|NAT-PT|===[v6]==|6to4|===[v4]===|6to4|==[v6]==|IPv6|
     +----+       +------+         +----+          +----+        +----+
        |                                                          |
        +---(v4)---(v4/v6)-----------------(v6)--------------------+

   ==[v4]== IPv4 network
   ==[v6]== IPv6 network
   --(v4)-- IPv4 packet exchange
   --(v6)-- IPv6 packet exchange
   (v4/v6)  translation

   The destination is an IPv6 host seen as an IPv4 host through the
   NAT-PT box, and can only be reached through the 6to4 mechanism from
   cloud1 to cloud2. Some special DNS arrangements have to be made for
   this scenario to work. The DNS resolution must involve an DNS server
   on the IPV6 that holds the NAT-PT box. The NAT-PT box must be enable
   to process inbound IPv4 session.

4.3.18 NAT-PT combined with Tunnel Broker

   This case is not applicable. The dual stack host supported by the
   tunnel broker has both native IPv4 and IPv6 connectivity and thus
   does not require any translation facilities.

4.3.19 NAT-PT combined with DSTM

                     |                |
   ---IPv6 cloud1--->|<--IPv4 ocean-->|<--IPv6 cloud2-------
                     |                |                  
   +----+        +------+        +--------+        +-------+
   |IPv6|==[v6]==|NAT-PT|==[v4]==|DSTM TEP|==[v6]==|IPv6/v4|
   +----+        +------+        +--------+        +-------+
      |                                                 |
      +----(v6)---(v6/v4)-------------(v4)--------------+

   ==[v4]== IPv4 network
   ==[v6]== IPv6 network
   --(v4)-- IPv4 packet exchange
   --(v6)-- IPv6 packet exchange
   (v6/v4)  translation
   TEP      Tunnel End Point

   The DSTM TEP must be enabled to process inbound
   IPv4 sessions, and the destination host must be seen as an IPv4
   one through the name resolution process.

Krampell                                 Expires August 2001  [page 14]

Internet Draft       Interaction of transition mechanisms      Feb 2001



4.3.20 NAT-PT combined with SOCKS

   This case is not possible.
                     |                |
   ---IPv6 cloud1--->|<--IPv4 ocean-->|<--IPv6 cloud2----
                     |                |                  
   +----+        +------+        +--------+        +----+
   |IPv6|==[v6]==|NAT-PT|==[v4]==|SOCKS GW|==[v6]==|IPv6|
   +----+        +------+        +--------+        +----+
      |                                               |
      +----(v6)---(v6/v4)---(v4)--(v4/v6)----(v6)-----+

   ==[v4]== IPv4 network
   ==[v6]== IPv6 network
   --(v4)-- IPv4 packet exchange
   --(v6)-- IPv6 packet exchange
   (v6/v4)  translation
   (v4/v6)  translation

   The source of the communication is not located to the inner side of
   the SOCKS gateway as required.

4.3.21 NAT-PT combined with NAT-PT

                      |                |
   ---IPv6 cloud1---->|<--IPv4 ocean-->|<--IPv6 cloud2----
                      |                |                  
   +----+        +--------+        +--------+        +----+
   |IPv6|==[v6]==| NAT-PT |==[v4]==| NAT-PT |==[v6]==|IPv6|
   +----+        +--------+        +--------+        +----+
      |                                                 |
      +----(v6)---(v6/v4)---(v4)----(v4/v6)----(v6)-----+

   ==[v4]== IPv4 network
   ==[v6]== IPv6 network
   --(v4)-- IPv4 packet exchange
   --(v6)-- IPv6 packet exchange
   (v6/v4)  translation
   (v4/v6)  translation

   The native IPv6 host gets connectivity to the IPv4 Internet using
   NAT-PT to translate from IPv6 to IPv4 and then with another NAT-PT,
   translating the other way round, it gains connection to another IPv6
   network.








Krampell                                 Expires August 2001  [page 15]

Internet Draft       Interaction of transition mechanisms      Feb 2001



4.3.22 NAT-PT combined with 6over4

                   |                |                |
 ---IPv4 ocean---->|<-IPv6 cloud1-->|<--IPv4 ocean-->|<-IPv6 cloud2----
                   |                |                |
   +----+       +------+        +------+         +------+        +----+ 
   |IPv4|==[v4]=|NAT-PT|==[v6]==|6over4|===[v4]==|6over4|==[v6]==|IPv6|
   +----+       +------+        +------+         +------+        +----+
      |                                                            |
      +---(v4)---(v4/v6)-------------------(v6)--------------------+

   ==[v4]== IPv4 network
   ==[v6]== IPv6 network
   --(v4)-- IPv4 packet exchange
   --(v6)-- IPv6 packet exchange
   (v4/v6)  translation

   In this scenario, if the 6over4 site is able to do DNS resolution
   through the NAT-PT, it works fine. Otherwise it doesn't work.

4.3.23 BIS combined with DSTM
   
   In this scenario the combination is not possible. This is because
   the DSTM mechanism connects a dual stack host in an IPv6 network
   with a native IPv4 host (IPv4 in IPv6 tunnelling), whereas the
   BIS mechanism is used to enable connectivity between an IPv4
   application running on an IPv6 host with an IPv6 application on an
   IPv6 host.

4.3.24 BIS combined with SOCKS

   Due to the nature of socks the communication must be initiated
   from a host within the SOCKS domain. The combination is not
   possible.

4.3.25 6over4 combined with DSTM
   
   This case is not applicable because 6over4 enables IPv6 end-to-end
   communication between IPv6-only hosts within IPv6-only networks over
   an IPv4-only network, while DSTM enables IPv4 end-to-end
   communications between a dual-stack host within an IPv6-only network
   and an IPv4-only host. These two mechanisms do not fit together.

4.3.26 6over4 combined with SOCKS
   
   This case is not applicable. 6over4 enables IPv6 end-to-end
   communication between IPv6-only hosts within IPv6-only networks over
   an IPv4-only network while the socks mechanism translates between
   IPv6 and IPv4.



Krampell                                 Expires August 2001  [page 16]

Internet Draft       Interaction of transition mechanisms      Feb 2001



   +--------+             +--------+        +------+        +------+
   | 6over4 |--[v6inv4]---| 6over4 |--[v6]--| Socks|--[V4]--| IPv4 |
   |  host  |             | Router |        |  GW  |        | host |
   +--------+             +--------+        +------+        +------+
       |                      |                 |               |
       +---------v4-----------+--------v6-------+--------v4-----+

   The 6over4 host is dualstack so it can communicate directly with the
   IPv4 host (no need to go through IPv6).
   Further due to the nature of socks the communication should be
   initiated from within the socks domain.

4.3.27 6over4 combined with NAT-PT
   
   This case is not applicable. 6over4 enables IPv6 end-to-end
   communication between IPv6-only hosts within IPv6-only networks over
   an IPv4-only network while NAT-PT translates between IPv6 and
   IPv4.

   +--------+             +--------+        +--------+        +------+
   | 6over4 |--[v6inv4]---| 6over4 |--[v6]--| NAT-PT |--[V4]--| IPv4 |
   |  host  |             | Router |        |        |        | host |
   +--------+             +--------+        +--------+        +------+
       |                      |                 |                 |
       +---------v4-----------+--------v6-------+--------v4-------+

   The 6over4 host is dualstack so it can communicate directly with the
   IPv4 host (no need to go through IPv6).

5. Transition mechanisms for the late phase

   The late phase of the transition is characterized by a large IPv6
   ocean, only partially connected IPv4 islands.

                    +----------------+
                    |                |
   +----------+     |                |     +----------+
   |   IPv4   |     |       IPv6     |     |   IPv4   |
   |  Network |-----|     Network    |-----|  Network |
   |          |     |                |     |          |
   +----------+     |                |     +----------+
                    |                |
                    |                |
                    +----------------+

5.1 Combining multiple transition mechanisms for a single connection 






Krampell                                 Expires August 2001  [page 17]

Internet Draft       Interaction of transition mechanisms      Feb 2001



5.2 Table of combinations


   Src \ Dest  6to4  Tunnel Br  DSTM  SOCKS  NAT-PT  BIS  6over4
   -------------------------------------------------------------
   6to4        x        N/A      N/A   N/A    N/A    N/A    N/A

   Tunnel Br   N/A      x        N/A   N/A    A(1)   A(1)   A(1)

   DSTM        N/A      N/A      x     N/A    N/A    N/A    N/A

   SOCKS       N/A      A(1)     N/A    x     A(1)   A(1)   A(1)

   NAT-PT      N/A      A(1)     N/A   A(3)   x      A(1)   A(2)

   BIS         N/A      A(1)     N/A   A(3)   A(1)   x      A(1)
                                     
   6over4      N/A      A(1)     N/A   A(3)   A(1)   A(1)   x

   Applicable 
   A(1) = will work
   A(2) = with special limitation, see comment
   A(3) = one mechanism has a limitation
   N/A = Not applicable, because mechanisms have a different goal
   x = no interaction of transition mechanisms


5.3 Comments on table

   The Comments on the table will contain descriptions only if the
   answer is A(2), A(3) or N/A, A(1) is obvious.


5.3.1 6to4 combined with other mechanisms
   
   The 6to4 mechanism, by definition, will only be used in the early
   transition phases to interconnect two or more IPv6 clouds through
   the existing IPv4 infrastructure, so it doesn't make sense to use it
   with any mechanism at this phase of the transition, where an unique
   IPv6 cloud (ocean) is involved.

5.3.2 Tunnel Broker combined with DSTM
    
   This case is not applicable. These two mechanism have different
   goals and does not fit together (see section 4.3.4)







Krampell                                 Expires August 2001  [page 18]

Internet Draft       Interaction of transition mechanisms      Feb 2001



5.3.3 Tunnel Broker combined with SOCKS
  
                     |              |
    ---IPv4 cloud1-->|<-IPv6 ocean->|<--------IPv4 cloud2--------
                     |              |
   +-------+      +-----+      +--------+      +-----------------+
   |IPv6/v4|==v4==|TB/S |==v6==|SOCKS GW|==v4==|IPv4 SOCKS client|
   +-------+      +-----+      +--------+      +-----------------+
       |                                                |
       +-----------(v6)---------(v6/v4)-----(v4)--------+

   ==[v4]== IPv4 network
   ==[v6]== IPv6 network
   --(v4)-- IPv4 packet
   --(v6)-- IPv6 packet
   (v6/v4)  translation

   This case is not possible due to SOCKS mechanism limitation : the
   communication is initiated from the outside of the SOCKS domain
   while the mechanism requires inbound communication.

5.3.4 Tunnel Broker combined with 6over4
   
   This combination is technical possible. It is though unlikely that
   in the later phases of transition that 6over4 will still be used.
   Any stubs of surviving IPv4 networks are likely to be used solely
   for IPv4 applications with perhaps some single host IPv6
   connectivity via tunnels (such as tunnel broker). Connectivity to a
   native IPv6 network for IPv6 application use is not likely to be a
   problem and thus continued 6over4 usage unlikely.

5.3.5 DSTM combined with Tunnel Broker
   
   This case in Non-applicable, because mechanism have different goals
   and do not fit together (see section 4.3.4).

















Krampell                                 Expires August 2001  [page 19]

Internet Draft       Interaction of transition mechanisms      Feb 2001



5.3.6 DSTM combined with SOCKS
   
                        |                |                  
   -----IPv6 ocean----->|<--IPv4 cloud-->|<--IPv6 ocean---
                        |                |                  
   +-------+        +--------+        +-----+        +----+
   |IPv4/v6|==[v6]==|DSTM TEP|==[v4]==|SOCKS|==[v6]==|IPv6|
   +-------+        +--------+        +-----+        +----+
       |                                                |
       +------------v4----------------(v4/v6)----v6-----+
   
   ==[v4]== IPv4 network
   ==[v6]== IPv6 network
   --(v4)-- IPv4 packet
   --(v6)-- IPv6 packet
   (v4/v6)  translation
   TEP      Tunnel End Point
  
   This case is not applicable, since going through DSTM and SOCKS
   mechanisms means that both source and destination are located within
   the IPv6 ocean. Both source and destination have IPv6 connectivity
   and the communication can be achieved directly within the IPv6
   ocean. Otherwise, the source of the communication is not located to
   the inner side of the SOCKS domain as required by the mechanism.

5.3.7 DSTM combined with NAT-PT
   
                         |                |
   ------IPv6 ocean----->|<--IPv4 cloud-->|<--IPv6 ocean---
                         |                |                  
   +-------+        +--------+        +------+        +----+
   |IPv4/v6|==[v6]==|DSTM TEP|==[v4]==|NAT-PT|==[v6]==|IPv6|
   +-------+        +--------+        +------+        +----+
       |                                                 |
       +------------v4----------------(v4/v6)-----v6-----+

   ==[v4]== IPv4 network
   ==[v6]== IPv6 network
   --(v4)-- IPv4 packet
   --(v6)-- IPv6 packet
   (v4/v6)  translation
   TEP      Tunnel End Point

   This case is not applicable, since going through DSTM and NAT-PT
   mechanisms means that both source and destination are located within
   the IPv6 ocean. Both source and destination have IPv6 connectivity
   and the communication can be achieved directly within the IPv6
   ocean.




Krampell                                 Expires August 2001  [page 20]

Internet Draft       Interaction of transition mechanisms      Feb 2001



5.3.8 DSTM combined with BIS
   
   This case is not applicable because BIS enables an IPv4 application
   to communicate with an IPv6 hosts, over an IPv6 end-to-end
   communication, while DSTM enables IPv4 end-to-end communications
   between a dual-stack host within an IPv6-only network and an IPv4-
   only host.

5.3.9 DSTM combined with 6over4
   
   This case is not applicable because it requires more than one
   "standalone" IPv6 island.

5.3.10 SOCKS combined with DSTM
   
   DSTM is used to permit that an IPv4 application in a dual stack host
   placed in an IPv6 network can communicate directly with an IPv4-only
   host placed in an IPv4 island and then SOCKS (or any translation
   mechanism) does not make sense. This combination only fits in the
   early phase because of the IPv6 edge network if we are only
   considering three cloud scenarios.

5.3.11 NAT-PT combined with DSTM

   This case is not applicable. The dual stack host on the IPv6
   Internet gets connectivity to an IPv4 network using the DSTM
   mechanism. Here the NAT-PT transition mechanism is not necessary
   as the dual host on the IPv6 Internet has native connection to both
   IPv6 and IPv4 network solely using the DSTM mechanism.

5.3.12 NAT-PT combined with SOCKS

                     |                |
   ---IPv4 cloud1--->|<--IPv6 ocean-->|<--IPv4 cloud2----
                     |                |                  
   +----+        +------+        +--------+        +----+
   |IPv4|==[v4]==|NAT-PT|==[v6]==|SOCKS GW|==[v4]==|IPv4|
   +----+        +------+        +--------+        +----+
      |                                               |
      +----(v4)---(v4/v6)---(v6)--(v6/v4)----(v4)-----+

   ==[v4]== IPv4 network
   ==[v6]== IPv6 network
   --(v4)-- IPv4 packet exchange
   --(v6)-- IPv6 packet exchange
   (v6/v4)  translation
   (v4/v6)  translation

   This case is actually impossible due to the SOCKS mechanism
   limitation : the source of the communication is not located
   to the inner side of the SOCKS gateway, as required.

Krampell                                 Expires August 2001  [page 21]

Internet Draft       Interaction of transition mechanisms      Feb 2001



5.3.13 NAT-PT combined with NAT-PT

                      |                |
   ---IPv4 cloud1---->|<--IPv6 ocean-->|<--IPv4 cloud2----
                      |                |                  
   +----+        +--------+        +--------+        +----+
   |IPv4|==[v4]==| NAT-PT |==[v6]==| NAT-PT |==[v4]==|IPv4|
   +----+        +--------+        +--------+        +----+
      |                                                 |
      +----(v4)---(v4/v6)---(v6)----(v6/v4)----(v4)-----+

   ==[v4]== IPv4 network
   ==[v6]== IPv6 network
   --(v4)-- IPv4 packet exchange
   --(v6)-- IPv6 packet exchange
   (v6/v4)  translation
   (v4/v6)  translation

   The IPv4 host on the IPv4 network gets connectivity to the IPv6
   Internet using NAT-PT to translate from IPv4 to IPv6 and then
   with another NAT-PT, translating the other way round, it gains
   connection to another IPv4 network.

5.3.14 NAT-PT combined with BIS

                      | 
   ---IPv4 cloud ---->|<----IPv6 ocean------
                      |                 
   +----+        +--------+        +---------+
   |IPv6|==[v4]==| NAT-PT |==[v6]==| BIS host|
   +----+        +--------+        +---------+ 
      |                                  |
      +----(v4)---(V4/v6)--- (v6)--------+

   ==[v4]== IPv4 network
   ==[v6]== IPv6 network
   --(v4)-- IPv4 packet exchange
   --(v6)-- IPv6 packet exchange
   (v6/v4)  translation

   The BIS host on the Pv6 Internet runs IPv4 applications and can
   communicate with others IPv6 hosts. Using the NAT-PT box it can
   then get access to an IPv4 network.









Krampell                                 Expires August 2001  [page 22]

Internet Draft       Interaction of transition mechanisms      Feb 2001



5.3.15 NAT-PT combined with 6over4

   ---IPv4 cloud1-->|<---IPv6 ocean--->|<----IPv4 cloud2----
   +----+        +------+        +--------+        +--------+
   |IPv4|==[v4]==|NAT-PT|==[v6]==| 6over4 |==[v4]==| 6over4 |
   +----+        +------+        | Router |        |  host  | 
      |                          +--------+        +--------+
      |                                                 |
      +---(v4)---(v4/v6)----------------(v6)------------+

   The isolated Ipv4 source gains connectivity to an Ipv6 using the
   NAT-PT box. The isolated IPv6 destination gains connectivity to an
   IPv4 network using the 6over4 mechanism. The isolated IPv6
   destination can also connect, using the 6over4 mechanism, to a
   6over4 router and therefore is accessible from the IPv6 Internet.
   Communication between source and destination is enabled. In this
   scenario for the isolated IPv6 host to gain connectivity to an IPv4
   network, this IPv4 network must support multicast. If the IPv4
   network does not support multicast then the 6over4 mechanism cannot
   be used.

5.3.16 BIS combined with DSTM
   
   In this scenario the combination is not possible. This is because
   the DSTM mechanism connects a dual stack host in an IPv6 network
   with an IPv4 host in an IPv4 network (IPv4 in IPv6 tunnelling),
   whereas the BIS mechanism is used to enable connectivity between an
   IPv4 application running on an IPv6 host with an IPv6 application on
   an IPv6 host.

5.3.17 6over4 combined with DSTM
   
   This case is not applicable because 6over4 enables IPv6 end-to-end
   communication between IPv6-only hosts within IPv6-only networks over
   an IPv4-only network, while DSTM enables IPv4 end-to-end
   communications between a dual-stack host within an IPv6-only network
   and an IPv4-only host.

6. Combination of the results of the early and late phase

   If we combine the results of the early phase and the later phase,
   using the worst case of each phase, we receive the following table.










Krampell                                 Expires August 2001  [page 23]

Internet Draft       Interaction of transition mechanisms      Feb 2001



6.1 Table of combinations

   Src \ Dest  6to4  Tunnel Br  DSTM  SOCKS  NAT-PT  BIS  6over4
   -------------------------------------------------------------
   6to4        x       N/A       N/A   N/A   N/A     N/A    N/A

   Tunnel Br   N/A     x         N/A   N/A   N/A     A(1)   A(1)

   DSTM        N/A     N/A       x     A(3)  A(1)    N/A    N/A

   SOCKS       N/A     N/A       N/A   x     N/A     N/A    A(1)

   NAT-PT      N/A     N/A       N/A   A(3)  x       A(1)   A(2)

   BIS         N/A     A(1)      N/A   A(3)  A(1)    x      A(1)

   6over4      N/A     A(1)      N/A   N/A   N/A     A(1)   x


   Applicable
   A(1) = will work
   A(2) = with special limitation, see comment
   A(3) = one mechanism has a limitation
   N/A = Not applicable, because mechanisms have a different goal
   x = no interaction of transition mechanisms

6.2 Comments on table

   The results of the combination of the tables for the early and the
   late phase reduces the number of mechanisms that will cause no
   problems during the early and late phase of the transition further.

   Basically NAT-PT and BIS that seem to have the least problems
   in interacting with each other.
   
   It can be observed, that there is not a single mechanism that will
   not have a problem, in the early phase or in the late phase.

7. Parallel single transitions mechanism across multiple communications

   This document focuses on the investigation of combining two
   transition mechanisms. More complex scenarios combining more than 2
   transition mechanisms are out of scope.
   It is suspected that more problems occur if transition mechanisms
   are cascaded.







Krampell                                 Expires August 2001  [page 24]

Internet Draft       Interaction of transition mechanisms      Feb 2001



8. Observations from the combination of mechanisms and conclusions

   The main observation is that no particular issues are related to
   combination of two transition mechanism. In both earlier and later
   phases, some pair of mechanism do not fit together, some other pair
   of mechanism fit together very well. In the other cases issues are
   not due to the combination of two mechanisms, but is due to the own
   limitations of one of the mechanism involved in the combination.

8.1 Observations

   There are several observations that can be made from the findings in
   this document.

   It is obvious that some transition mechanisms will cause problems at
   some point in time during the transition to IPv6 networks. However,
   network administrators and service providers, generally speaking,
   users of transition mechanisms, should be very aware that these
   problems exist. This can have am impact of the deployment of these
   transition mechanisms.

   Since various transition mechanism use different prerequisites it is
   possible that some transition mechanisms will cause problems in
   complex network scenarios. Again, network administrators and service
   providers, generally speaking, users of transition mechanisms,
   should be very aware that these problems exist. This can have an
   impact on the deployment of these transition mechanisms.

8.2 Conclusions

   For deployment of IPv6, it is necessary to offer technical solutions
   for various transition scenarios. None of the investigated single
   transition mechanisms can solve all the problems during the various
   phases of the transition from IPv4 to IPv6. However, the results
   from this document show that the concurrent deployment of sometimes
   complex transition mechanisms increases the complexity of a network
   in transition. 

   The authors therefore propose to focus on developing recommendations
   on how network operators should start and proceed with the
   deployment of transition mechanisms. The authors of this memo
   propose that further transition mechanisms should be required to
   describe the interaction with existing transition mechanism to
   prevent interaction problems.

   The authors of this memo observe and conclude that the current
   variety of transition mechanisms and its potential problems can
   hinder the deployment of these mechanisms in a large scale.




Krampell                                 Expires August 2001  [page 25]

Internet Draft       Interaction of transition mechanisms      Feb 2001



9. References

[6TO4]	       B. Carpenter, K. Moore, Connection of IPv6 Domains via
               IPv4 Clouds,RFC 3056, February 2001.

[AIIH]         Jim Bound, "Assignment of IPv4 Global Addresses to IPv6
               Hosts (AIIH)",
               draft-ietf-ngtrans-assgn-ipv4-addrs-01.txt (work in
               progress).

[BROKER]       A. Durand, P. Fasano, I. Guardini, D. Lento, "IPv6
               Tunnel Broker", draft-ietf-ngtrans-broker-00.txt
               (work in progress).

[DSTM]         J. Bound, L. Toutain, H. Affifi, "Dual Stack Transition
               Mechanism (DSTM)", draft-ietf-ngtrans-dstm-01.txt
               (work in progress).

[RFC1933]      R. Gilligan and E. Nordmark, "Transition Mechanisms for
               IPv6 Hosts and Routers", RFC 1933, April 1996.

[RFC2529]      B. Carpenter, C. Jung, "Transmission of IPv6 over IPv4
               Domains without Explicit Tunnels", RFC2529, March 1999.

[RFC2765]      E. Nordmark, "Stateless IP/ICMP Translator",
               RFC 2765, February 2000.

[RFC2766]      G. Tsirtsis, P. Srisuresh,
               "Network Address Translation - Protocol Translation
               (NAT-PT)", RFC 2766, February 2000.

[RFC2767]      K. Tsuchiya, H. Higuchi, Y. Atarashi, "Dual Stack Hosts
               using the Bump-in-the-Stack technique",
               RFC 2767, February 2000.

[SOCKS-EXT]    H. Kitamura, "SOCKSv5 Protocol Extensions for IPv6/IPv4
               Communication Environment",
               draft-kitamura-socks-ipv6-01.txt (work in progress).

[SOCKS-GATE]   H. Kitamura, A. Jinzaki, S. Kobayashi, "A SOCKS-based
               IPv6/IPv4 Gateway Mechanism",
               draft-ietf-ngtrans-socks-gateway-02.txt
               (work in progress).
 
[TRT]          J. Hagino, K. Yamamoto, "An IPv6-to-IPv4 transport
               relay translator",
               draft-ietf-ngtrans-tcpudp-relay-00.txt,
               (work in progress).




Krampell                                 Expires August 2001  [page 26]

Internet Draft       Interaction of transition mechanisms      Feb 2001



10. Acknowledgements

   The authors would like to thank the following  people for providing
   input to this document: David Binet, Emilio Garcia, Christian Hahn,
   Peter Hovell, Katarina Santti, Thomas Scheffler, Ingvild Sorteberg,
   Victor Marques, John King and Fraser Christie.


11. Authors' addresses

   Magnus Krampell
   EURESCOM GmbH
   Schloss-Wolfsbrunnenweg 35
   D-69118 Heidelberg
   Germany
   E-mail: krampell@eurescom.de


   Arnaud Gibier
   British Telecom
   B29/128, BT Adastral Park,
   Martlesham Heath,
   Ipswich, IP5 3RE
   United Kingdom
   Email: arnaud.gibier@bt.com


   Andre' Zehl
   Deutsche Telekom
   T-Nova Berkom
   Goslarer Ufer 35
   10589 Berlin
   Germany
   E-mail: andre.zehl@telekom.de


   Pasi Kyheröinen
   Elisa Communications
   Kutomotie 14, Helsinki
   P.O.Box 40, FIN-00061 ELISA
   Finland
   E-mail : pasi.kyheroinen@rc.elisa.fi


   Alain Baudot
   France Telecom R&D
   42, rue de  coutures - BP 6243
   14066 Caen cedex 4
   France
   E-mail : alain.baudot@francetelecom.com


Krampell                                 Expires August 2001  [page 27]

Internet Draft       Interaction of transition mechanisms      Feb 2001



   Geir Egeland
   Telenor Research and Development
   PO BOX 83
   N-2027 Kjeller
   Office: Instituttveien 23
   E-mail: geir.egeland@telenor.com


   Per Randrup Nielsen
   TDC Tele Danmark
   Sletvej 30
   8310 Tranbjerg J
   Denmark
   E-mail : prani@tdk.dk


   Jacinto Vieira
   PT-Inovação
   Rua José Ferreira Pinto Basto
   3810 Aveiro
   Portugal
   E-mail: lvieira@ptinovacao.pt































Krampell                                 Expires August 2001  [page 28]