INTERNET-DRAFT A. Baudot February 2002 France Telecom R&D Expires August, 2002 G. Egeland Telenor C. Hahn Deutsche Telekom P. Kyheroinen Elisa Communications A. Zehl Deutsche Telekom Interaction of transition mechanisms 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 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 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 Feb 2002 Expires August 2002 [Page 14] Expires August 2002 [Page 1]