Internet DRAFT - draft-ietf-ngtrans-interaction

draft-ietf-ngtrans-interaction



INTERNET-DRAFT                                     A. Baudot
June 2002                                          France Telecom R&D
Expires December, 2002                             G. Egeland
                                                   Telenor
                                                   C. Hahn 
                                                   Deutsche Telekom
                                                   P. Kyheroinen 
                                                   Elisa Communications
                                                   A. Zehl   
                                                   Deutsche Telekom
                                                   







Interaction of transition mechanisms

<draft-ietf-ngtrans-interaction-01.txt>



Status of this Memo

This document is an Internet-Draft and is in full conformance with all provisions 
of Section 10 of RFC2026 except that the right to produce derivative works is not 
granted.

This document is an Internet-Draft and is NOT offered in accordance with Section 10 
of RFC2026, and the author does not provide the IETF with any rights other than to 
publish as an Internet-Draft

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.


Abstract

This document discusses the interaction of transition mechanisms that can be 
involved during the transition phase where both IPv4 and IPv6 will be concurrently 
used. On one hand, several transition mechanisms have been defined to solve 
particular transition issues. On the other hand, one can face multiple transition 
issues and may have to use several transition mechanisms.  
Since an applicability scope is attached to each transition mechanism, specifying 
where the mechanism applies, i.e. host, domain or global, this memo aims at 
identifying cases where multiple transition mechanisms may be involved within the 
same scope, and what the interaction effects among them can be.


Table of Contents

0.      Applicability statement                        2
1.      Introduction                                   2
2.      Conventions used in this document              3
3.      Definition of the transition phases            3
4.      Classification of transition mechanisms        3
5.      Interaction matrix                             5
5.1.    Interaction within the host scope              5
5.1.1.  BIS and BIA study case                         5
5.2.    Interaction within the domain scope            6
5.2.1.  DTSM and NAT-PT study case                     6
5.2.2.  DSTM and ISATAP study case                     7
5.2.3.  ISATAP and NAT-PT study case                   8
5.3.    Interaction within the global scope            8
5.3.1.  Tunnel Broker and Configured Tunnel study case 8
5.3.2.  6to4 and Tunnel Broker study case              9
5.3.3.  6to4 and Configured Tunneling study case       10
5.4.    Inter-scope interaction                        10
5.4.1.  ISATAP and 6to4 study case                     10
6.      Security Considerations                        11
7.      References                                     11
8.      Authors' Addresses                             12


0. Applicability statement

This document discusses interaction of transition tools that apply within a same scope, i.e. local, site or global. Thus, there is no direct relationship between the study cases analysed herein, and the transition scenario identified by ngtrans working group. Any transition tool may participate to any transition scenario, and so, the same interaction issue may be faced within different transition scenarios.
Hence, this document can be a companion document to all scenario documents that are to be written, and can also discuss other possible cases that may not be addressed within transition scenarios. Such a document may ensure that interaction issues are addressed with the same sharpness over the different transition scenarios.


1. Introduction

The document [TRANSITION] provides an overview of most of the transition mechanisms 
defined within the IETF ngtrans working group. Each transition mechanism aims at 
solving a particular transition issue, and an applicability scope specifies where 
the tool applies: host, domain or global. During transition phase, one can face 
multiple transition issues, and then more than one transition mechanism must be 
deployed within a same scope.

The goal of this document is to focus on the interaction effects between transition 
mechanisms that can be mutually involved. It does not intend to provide any 
guidelines or rules on the way different transition mechanisms should be used. It 
intends to point out, if any, potential interaction effects, one can face using 
several transition mechanisms.

Section 3 defines different transition phases and clarifies where this memo applies.

Section 4 provides a classification of the transition mechanisms as a reminder

Section 5 details the interaction matrix, and discusses interaction effects.

2. Conventions used in this document

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", 
"SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this document are to be 
interpreted as described in RFC-2119 [ ].


3. Definition of the transition phases

The transition phase, where both IPv4 and IPv6 will be concurrently used, is 
commonly understood as period of time that can last years or even decades. One can 
imagine that this early phase will look like a large IPv4 ocean with a few 
interconnected IPv6 islands, while a later phase could look like a large IPv6 ocean 
with a few remaining IPv4 islands. This document will only discuss interaction of 
transition mechanisms during the early phase.


4. Classification of transition mechanisms

As reminder, the mechanisms sorted by scope, according to [TRANSITION] are listed 
below:

Host scope:

-	Dual Stack: a dual stack node has both an IPv4 and an IPv6 stack 
available, and is then enabled to directly communicate with both IPv4 or 
IPv6 node. A dual stack node may not have connectivity to both IPv4 and 
IPv6 networks.

-	Bump-In-the-Stack [BIS] can be viewed as an integrated NAT-PT, enabling 
IPv4-only application to communicate with IPv6 only hosts. A host running 
BIS acts as an IPv6 only host, while some of their applications are still 
running on an IPv4 stack.

-	Bump-in-the-API [BIA] can be compared to BIS, but acts at the API level 
where the translation occurs. It enables IPv4-only application to 
communicate with IPv6 only hosts.

Domain scope:

-	SOCKS [RFC3089] mechanism is based on the use of SOCKS protocol, and 
enables communication between IPv4 and IPv6 "socksified" nodes.

-	SIIT [RFC2765] describes the method of translating an IPv4 header to an 
IPv6 one, and vice versa. Since SIIT is a stateless method, it must be 
applied to every packet. 

-	NAT-PT [RFC2766] translates communications between IPv4-only and IPv6-only 
host. NAT-PT integrates a dedicated DNS application layer gateway. The 
translation process is based on SIIT method, and a state and/or a context 
of each communication is kept during the session lifetime.

-	TRT [RFC3142] enables IPv6-only hosts to exchange traffic with IPv4-only 
hosts by translating {TCP/UDP}/IPv6 to {TCP/UDP}/IPv4 and vice versa. TRT 
acts at the transport layer.

-	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".

-	ISATAP [ISATAP] is an Intra-Site Automatic Tunneling addressing protocol 
that connects IPv6 hosts and routers within IPv4 sites. ISATAP is treating 
the site's IPv4 infrastructure as a non-broadcasting multiple access link 
layer and tunnels the IPv6 payload in an IPv4 packet.

-	Dual stack transition mechanism [DSTM] enables a full IPv4 end-to-end 
communication between dual stack nodes within an IPv6-only network to an 
IPv4-only host. DSTM is based on tunneling, using dynamic tunnel 
interface combined with temporary IPv4 address allocation provided by 
another way such as DHCPv6 or RPCv6

-	Teredo [TEREDO] is a service that enables nodes located behind one or 
several IPv4 NATs to obtain IPv6 connectivity by tunneling packets over 
UDP.

Global scope:

-	Configured tunnel: typically this stands for manually configured tunnel where 
information about configuration is learned "manually".
 
-	Automatic tunnel: automatic tunnels are based on the use of IPv4-compatible 
addresses from which tunnels end-point IPv4 addresses are derived.

-	Tunnel broker [BROKER] is mainly aimed at allowing rapid connectivity to a 
native IPv6 to an isolated dual stack host within the legacy Internet. 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, and returns it along with its DNS name and client 
configuration information.


-	6to4 [6to4] method enables IPv6 sites to automatically connect to other IPv6 
sites over the legacy IPv4 Internet infrastructure without specific 
configuration. 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.

-	BGP tunnel [BGP-TUNNEL] explains how to interconnect IPv6 islands over an 
IPv4 cloud, including the exchange of IPv6 reachability information using 
BGP. It uses a trivial tunneling mechanism without an explicit tunnel.
  

5. Interaction matrix

There are currently up to 16 different transition mechanisms defined today, so that 
a full interaction matrix would result in more or less 512 cases of possible 
combinations of two mechanisms.

In order to reduce this large amount of cases, and to optimize the cases to study, 
this documents makes the assumption that interaction between transition mechanisms 
may only occur if they apply to the same scope and/or if they are deployed at the 
same location. It is assumed that there is no interaction between mechanisms of 
different scopes, unless they are located at the same place.

Since the host scope is composed of 3 mechanisms, the domain scope is composed of 8 
mechanisms, and the global scope is composed of 5 mechanisms, the number of 
possible cases is greatly reduced. Nevertheless, this document discusses the cases 
listed below:
-	Host scope: BIS and BIA.
-	Domain scope: DSTM and NAT-PT, DSTM and ISATAP.
-	Global scope: 6to4 and Tunnel Broker, Tunnel Broker and configured tunnel.
-	Domain/Global scope: ISATAP and 6to4.

5.1. Interaction within the host scope

This section discusses interaction of two different mechanisms within the host 
scope, and focuses on the points listed below: 
-	Impact of concurrent DNS use
-	Concurrent use of both mechanisms by the same application
-	Simultaneous use of both mechanisms by two different applications

5.1.1. BIS and BIA study case

BIS and BIA enable IPv4-only applications to communicate with IPv6-only hosts. They 
are based on the principal of packet interception and translation. BIS is acting at 
the IP layer, while BIA is acting at the API layer. Translation decision is taken 
when the destination name resolution results in an IPv6-only end-point. Then the 
mechanism changes the DNS answer from "AAAA" record to "A" record, and translation 
is silently started so that the IPv4-only application will run as usual. 

 Concurrent DNS use

Both mechanism triggers are based on the name resolution trick, and are competing. 
The result may be implementation dependent, but it is rather obvious that one of 
the mechanisms will be predominant over the other one.

Concurrent use of both mechanisms by the same host

Because of the same scope of both transition mechanisms, only one mechanism per 
host is needed. The use of both mechanisms at the same time on the same host will 
cause confusing results because of possible double interception in the same data 
flow. 

Simultaneous use of both mechanisms by two different hosts

BIA uses the existing dual stack mechanism and a common IPv6 address to communicate 
with other hosts via IPv6. BIS adds the IPv6 functionality to the IPv4 stack and 
also uses common IPv6 addresses for communication with other IPv6 hosts. 
Communication between BIS and BIA hosts will take place as it normally would occur 
between two dual stack hosts therefore no specific issues can be raised here.

5.2. Interaction within the domain scope

This section discusses interaction of two different mechanisms within the domain 
scope, and focuses on the points listed below:
-	Impact of concurrent DNS use
-	Concurrent use of both mechanisms by the same host or router
-	Simultaneous use of both mechanism by two different hosts or routers

5.2.1. DTSM and NAT-PT study case

NAT-PT and DSTM achieve nearly the same goal, enabling communication between a host 
connected to an IPv6-only network and IPv4-only host within the legacy Internet, 
but in a different manner. NAT-PT assumes that one host is IPv6-only, while DSTM 
needs a dual-stack host. NAT-PT is based on address and protocol translation, while 
DSTM enables end-to-end IPv4 communication.
In a transition scenario, one can easily imagine both mechanisms being needed, for 
example because some applications may not be ported to IPv6, while some host are 
IPv6-only.

Concurrent DNS use

For both mechanisms, DNS use is crucial: 

-	NAT-PT needs DNS-ALG intervention for both inbound and outbound sessions. For 
an outbound session to an IPv4-only host, the DNS-ALG will translate an 
"AAAA" query to an "A" query, and the "A" response to an "AAAA" response. 
The IPv4-only host will then be seen as an IPv6 host through the NAT-PT 
gateway. In addition, NAT-PT requires that all DNS requests must pass 
through the DNS-ALG to operate properly. The consequence of this behavior is 
that a host within the IPv6 domain will never receive any DNS response 
including an "A" record.

-	A DSTM client encapsulates IPv4 into IPv6 packets for end-to-end 
communication with an IPv4-only host. The decision of tunneling packets is 
taken when a unique "A" record is received as name resolution of the 
destination host. Temporary IPv4 address allocation is processed, and the 
communication is then initiated.

It is obvious that within an IPv6 domain behind a NAT-PT box, a global domain 
configuration results in directing all DNS queries and responses through a DNS-ALG, 
and then, DSTM mechanism will never be trigged and used.

Concurrent use of both mechanisms by the same host

Because of the DNS behavior described in the section above, some extra mechanisms 
are required to switch a DNS query through a DNS-ALG to use NAT-PT, or through 
another way to use DSTM. 
A single default and global configuration of an IPv6 domain behind a NAT-PT box may 
result in the exclusive use of NAT-PT.

Simultaneous use of both mechanisms by two different hosts

Because of the DNS behavior described in the above section, a specific domain 
configuration is needed, in order to enable the DNS traffic either to go through a 
DNS-ALG for NAT-PT use, or to go through another gateway for DSTM use. 
This can be achieved, for example, by using a dedicated DNS server for dual-stack 
DSTM hosts and a dedicated DNS server for IPv6-only hosts that will use NAT-PT.

5.2.2. DSTM and ISATAP study case

DSTM aims at providing direct IPv4 connectivity to a dual stack host connected to 
an IPv6-only network. ISATAP aims at providing IPv6 connectivity to a dual stack 
host connected to an IPv4-only network. Since the principles are opposite, neither 
a host running ISATAP will use DSTM mechanism, nor a DSTM host will run ISATAP. 
However, one can deploy, for example, ISATAP on part of its legacy IPv4 domain, 
while deploying DSTM on some IPv6-only parts of its infrastructure. 
This study case has then to focus on the border of the domain where both TEP 
(Tunnel End Point) and ISATAP routers can be located.

Concurrent DNS use

Neither ISATAP, nor DSTM mechanism has any specific behavior related to DNS that is 
used as normal. DSTM uses name resolution results as a trigger for a temporary IPv4 
address allocation through another protocol (e.g. DHCPv6 or RPCv6).
Both mechanisms use DNS as normal and independently so that no particular issue can 
be raised.

Concurrent use of both mechanisms by the same host

Because of the opposite goals and network environment, one host can only run one 
mechanism, so that concurrent use of both mechanism will never occur, and no issue 
can be raised.

Simultaneous use of both mechanisms by two different hosts

DSTM and ISATAP tunnel packets the opposite way: respectively IPv4-in-IPv6 and 
IPv6-in-IPv4. Both mechanisms can operate independently, even within the same 
router, and no particular interaction issue can be raised. 

5.2.3. ISATAP and NAT-PT study case

ISATAP [ISATAP] is an Intra-Site Automatic Tunneling addressing protocol that 
connects IPv6 hosts and routers within IPv4 sites. NAT-PT enables communication 
between an IPv6 and an IPv4 host.

Concurrent DNS use

ISATAP both have a specific IPv6 addresses and normal domain names. A dual stack 
ISATAP host will have a routable IPv4 address which can be used to connect to other 
IPv4 hosts. For the ISATAP host to be able to communicate with IPv4-onlyhosts 
within a site using its IPv6 address, the DNS requests must pass through a NAT-PT 
router with a DNS-ALG. When an IPV4 host tries to connect to an ISATAP host, it 
will use the ISATAP host's IPv4 address if the ISATAP has an ""and an "AAAAA" 
record defined in the DNS. If the DNS requests from the IPv4 hosts are configured 
to go through a DNS-ALG, the connection between the two hosts will go through the 
NAT-PT router. With such a configuration the IPv4 host will have problems 
communicating with other IPv4-only hosts, since they have no AAAA record. Using 
several DNS servers and letting the ISATAP hosts belong to a separate sub domain, 
communicating with the primary DNS through a NAT-PT box, will, however, solve this.

Concurrent use of both mechanisms by the same host or router

The two mechanisms operate separately and can both be implemented in the same 
router, i.e. ISATAP router and NAT-PT. 

Simultaneous use of both mechanisms by two different hosts

As described above, an ISATAP host can communicate with other IPv4 hosts through a 
NAT-PT box. IPv4 hosts will also be able to connect to an IPv6 ISATAP host with 
proper configuration of DNS.


5.3. Interaction within the global scope

This section discusses interaction of two different mechanisms within the global 
scope, and a particular focus is put on:
-	Impact of concurrent DNS use
-	Concurrent use of both mechanisms by the same host or router
-	Simultaneous use of both mechanisms by two different hosts or routers
-	
5.3.1. Tunnel Broker and Configured Tunnel study case

Configured tunnels are used to connect IPv6 islands across an IPv4 infrastructure 
encapsulating IPv6 packets into IPv4 ones.
The Tunnel broker mechanism is a way to automate tunnel configuration through a 
user interface in order to get IPv6 connectivity over an existing IPv4 
infrastructure. All configuration steps needed to establish a tunnel are done on 
one side by the tunnel server, which configures one side of the tunnel endpoint by 
request. On the other side, the tunnel set-up is done by automatically generated 
scripts that are downloaded and executed on the user PC.
Since the basic tunneling mechanism is used in both cases, it is assumed that no 
particular issue can be raised.

Concurrent DNS use

There is no direct impact of the DNS on the functionality of both mechanisms. 
The Tunnel Broker mechanism may use Dynamic DNS Update protocol to create, update 
and delete user defined DNS records for the lifetime of the requested tunnel. Once 
created the end user could be reached using his name. A host sitting behind a 
configured tunnel can easily resolve the IPv6 address of the corresponding host by 
querying the DNS. On the other side a host connected by a tunnel, provided by the 
tunnel broker, can use the DNS without restrictions to resolve a given name.

Concurrent use of both mechanisms by the same host

Due to the equality of both mechanisms the mutual impact between them is the same 
as between two or more configured tunnels or tunnels created by a tunnel broker 	  
script. No restrictions could be seen here except for the restrictions applicable 
by the IPv4/IPv6 stack.

Simultaneous use of both mechanisms by two different hosts

As described above no particular issue can be raised.

5.3.2. 6to4 and Tunnel Broker study case

6to4 [6to4] enables automatic tunneling between sites over an IPv4 infrastructure, 
and provides IPv6 connectivity. In addition, 6to4 provides a globally unique IPv6 
prefix for a site.
Tunnel Broker (TB) provides IPv6 connectivity to an isolated host or site within an 
IPv4-only network, and allocates an IPv6 global address to a host or an IPv6 prefix 
to a site.
Today 6to4 and Tunnel Broker are significantly deployed over the 6bone, and are 
running independently without any noticeable interaction issues. 
However, let's consider the following case: a Tunnel Broker allocating 6to4 
addresses or 6to4 prefixes. 
Allocating a 6to4 prefix to a Tunnel brokered site is somewhat confusing: A 6to4 
mechanism can be directly deployed, because, the site owns anyway at least an IPv4 
global address. Since its technical motivation is unclear, this case has been left 
aside for further study.
Allocating 6to4 addresses may be a way of providing IPv6 connectivity without 
owning any native IPv6 address space. This case is studied below.

Concurrent DNS use

6to4 mechanism has no impact on DNS, and Tunnel Broker manages 6to4 addresses as 
normal IPv6 addresses.
No particular issues related to DNS can be raised.

Concurrent use of both mechanisms by the same host

The Tunnel Brokered host can reach all 6to4 hosts using IPv6 and all IPv6 hosts 
behind 6to4 relay routers. It can still use IPv4 to reach IPv4 hosts.

Simultaneous use of both mechanisms by two different hosts

6to4 hosts and other IPv6 hosts, that have connection to 6to4 sites via a 6to4 
relay router, can reach the Tunnel Brokered host through the established tunnel 
using the 6to4 address of the dual stacked host.

5.3.3. 6to4 and Configured Tunneling study case

One can easily imagine the case of a border router running 6to4 and having 
configured tunnels giving IPv6 connectivity to some other IPv6 only sites. 

Concurrent DNS use

Since, neither 6to4 mechanism, nor configured tunnel have any impact on DNS, no 
particular issue can be raised.

Concurrent use of both mechanisms by the same host or router

6to4 mechanism is solicited for communications with other external 6to4 hosts, 
while configured tunnel are used for communications with hosts belonging to other 
IPv6 sites. Within a given border router, both mechanisms can run independently, 
and no particular interaction issues can be raised.

Simultaneous use of both mechanisms by two different hosts or routers

As described above no particular issue can be raised.

5.4. Inter-scope interaction

5.4.1.  ISATAP and 6to4 study case
 
ISATAP [ISATAP] is an Intra-Site Automatic Tunneling addressing protocol that 
connects IPv6 hosts and routers within IPv4 sites. ISATAP treats the site's IPv4 
infrastructure as a non-broadcasting multiple access link layer and tunnels the 
IPv6 payload in an IPv4 packet. ISATAP provides a 64-bit interface identifier field 
with an embedded IPv4 address that is used for tunneling between other ISATAP 
hosts/routers within a site.
6to4 [6to4] enables automatic tunneling between sites over an IPv4 infrastructure. 
By using a globally routable IPv4 address, 6to4 provides a globally unique IPv6
prefix for a site.
In this case, ISATAP and 6to4 are combined to provide IPv6 connectivity to a host, 
which is connected to an internal IPv4 infrastructure as well as to an external 
IPv4 infrastructure.

Concurrent DNS use

6to4 and ISATAP both have specific IPv6 addresses and normal domain names. 
Communication with a DNS server will take place as normal.

Concurrent use of both mechanisms by the same host or router

A router that implements both ISATAP and 6to4 will be able to communicate with both 
ISATAP hosts within the site and other 6to4 sites. The two mechanisms use IPv6-in-
IPv4 encapsulation, but operate independently of each other since an ISATAP router 
tunnels packets to a host while a 6to4 router tunnels traffic to other 6to4 sites.


Simultaneous use of both mechanisms by two different hosts or routers

An ISATAP host communicates with other IPv6 hosts either directly or via an ISATAP 
router. A host using a 6to4 address will communicate with other 6to4 sites via its 
6to4 router and with other IPv6 hosts via a 6to4 gateway. If a valid IPv6 route 
between the ISATAP router and the 6to4 gateway exists, communication between the 
connected hosts takes place as normal.

6. Security Considerations

Section explains briefly that security considerations are out of the scope of the 
document, and that almost every single transition mechanism includes a section 
dedicated to its own security.


7. References

[TRANSITION]	W. Bielmont, A. Durand, D. Finkerson, A. Hazeltine, M. Kaat, T. 
Larder, R. van der Pol, Y. Sekiya, H. Steeman, G.Tsirtsis, An 
overview of the introduction of Ipv6 transition in the Internet,  
draft-ietf-ngtrans-introduction-to-Ipv6-transition-07.txt, July 
2001, (work in progress).

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

[DSTM]         J. Bound, L. Toutain, O. Medina, F. Dupont,H. Affifi, A. Durand, 
"Dual Stack Transition Mechanism (DSTM)", draft-ietf-ngtrans-dstm-
06.txt, January 2002, work in progress.

[BIA]		S. Lee, M. Shin, Y. Kim, E. Nordmark, A. Durand, "Dual stack host 
using BUMP-in-the-API",draft-ietf-ngtrans-bia-02.txt, January 2002, 
work in progress.

[BGP-TUNNEL]	J. De Clercq, G. Gastaud, Y Nguyen, D. Ooms, S. Prevost, F. Le 
Faucheur, "Connecting IPv6 Islands across IPv4 Clouds with BGP", 
draft-ietf-ngtrans-bgp-tunnel-04.txt, January 2002, work in 
progress.

[ISATAP]	F. Templin, T. Gleeson, M. Talwar, D. Thaler, "Intra-Site Automatic 
Tunnel Addressing Protocol (ISATAP)", draft-ietf-ngtrans-isatap-
03.txt, January 2002, work in progress.

[TEREDO]	C. Huitema, "Teredo : Tunneling IPv6 over UDP through NATs", 
February 2002, 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.

[RFC3053]       A. Durand, P. Fasano, I. Guardini, D. Lento, "IPv6
               Tunnel Broker", RFC3053, January 2001

[RFC3089]	H. Kitamura, "A SOCKS-based IPv6/IPv4 gateway mechanism", RFC3089, 
April 2001.
 
[RFC3142]      J. Hagino, K. Yamamoto, "An IPv6-to-IPv4 transport
               relay translator", RFC3142, June 2001.


8. Authors' Addresses

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

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

   Christian Hahn
   Deutsche Telekom
   T-Nova Berkom
   Goslarer Ufer 35
   10589 Berlin
   Germany
   E-mail: HahnC@t-systems.com

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

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


Full Copyright Statement

"Copyright (C) The Internet Society (<2002>). All Rights Reserved.

This document and translations of it may be copied and furnished to others, and 
derivative works that comment on or otherwise explain it or assist its 
implementation may be prepared, copied, published and distributed, in whole or in 
part, without restriction of any kind, provided that the above copyright notice and 
this paragraph are included on all such copies and derivative works. However, this 
document itself may not be modified in any way, such as by removing the copyright 
notice or references to the Internet Society or other Internet organizations, 
except as needed for the purpose of developing Internet standards in which case the 
procedures for copyrights defined in the Internet Standards process must be 
followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by the 
Internet Society or its successors or assigns.

This document and the information contained herein is provided on an "AS IS" basis 
and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL 
WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE 
USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.





Internet Draft            Interaction of transition mechanisms	June 2002



	Expires December 2002 	[Page 14]