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

Versions: 00 01

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]


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