INTERNET DRAFT C. Huitema <draft-huitema-ngtrans-unmaneval-01.txt> Microsoft November 1, 2002 R. Austein Expires May 1, 2002 Bourgeois Dilettante S. Satapati Cisco Systems, Inc. Ronald van der Pol NLnet Labs Evaluation of Transition Mechanisms for Unmanaged Networks Status of this memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. This document is 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 In a companion paper we defined the "unmanaged networks" scope, which typically correspond to home networks or small office networks, and the requirements for IPv6 transition mechanism in that scope. We start from this analysis and evaluate here the suitability of mechanisms defined in the NGTRANS working group. 1 Introduction In a companion paper [UNMANREQ] we defined the "unmanaged networks" scope, which typically correspond to home networks or small office networks, and the requirements for IPv6 transition mechanism in that scope. We start from this analysis and evaluate here the suitability of mechanisms defined in the NGTRANS working group. The requirements for unmanaged networks are expressed by analyzing four classes of application: local, client, peer to peer, and servers, and considering four cases of deployment. These are: A) Gateway does not provide IPv6 Huitema et al. [Page 1] INTERNET DRAFT Unmanaged Networks Transition Tools November 1, 2002 B) ISP and gateway are dual stack C) Gateway is IPv6 capable, dual stack, ISP is not D) ISP is IPv6 only This document analyses the issues involved in the transition from IPv4 to IPv6. One of the most important issues is that of naming and addressing. During the transition phase from IPv4 to IPv6 there will be IPv4 only, dual stack or IPv6 only nodes that want to communicate to other IPv4 only, dual stack or IPv6 only nodes. When both nodes do not speak the same version of IP, some translation will be needed. The issues involved are described in the next chapters. This analysis outlines two types of requirement: connectivity requirements, i.e. how to ensure that nodes can exchange IP packets, and naming requirements, i.e. how to ensure that nodes can resolve each-other's names. Note that draft-00 is essentially a pro-forma place holder. Many of the discussion sections are incomplete. We expect that the content will evolve significantly during and after the interim meeting of the NGTRANS/V6OPS WG. 2 Meeting case A requirements Different connectivity requirements appear at different stages of the IPv6 deployment: - In case A, isolated hosts located behind a NAT need to acquire some form of connectivity. - In case B, an IPv6 capable gateway must be able to obtain IPv6 connectivity and an IPv6 prefix from an IPv6 capable ISP. The network may include IPv4 only hosts, IPv6 only hosts, and dual stack hosts. Various mechanisms are needed to let IPv4 hosts and IPv6 hosts interoperate. - In case C, an upgraded gateway must be able to provide IPv6 connectivity to the unmanaged network independently of the local ISP. Otherwise, the application requirements are the same as in case B. - In case D, the ISP only provide IPv6 services; an IPv4 only host must be able to interact through the gateway and the IPv6 only ISP with IPv4 only servers on the Internet. In this section, we first evaluate how mechanisms already defined or being worked on in the IETF meet these requirements. We then consider the "remaining holes" and recommend specific developments. 2.1 Evaluation of connectivity mechanisms The following evaluation is fractional and preliminary, and does not necessarily reflect consensus of all the authors. Huitema et al. [Page 2] INTERNET DRAFT Unmanaged Networks Transition Tools November 1, 2002 2.1.1 TEREDO TEREDO is a mechanism designed to provide IPv6 connectivity to hosts behind NATs. Hosts use servers to find out a "mapped" IPv4 address and UDP port; they build an IPv6 address that includes the IPv4 address of their preferred server, and their own mapped IPv4 address and mapped port. A mechanism of bubbles, relayed by the servers, is used for establishing contacts between Teredo nodes, or for discovering the appropriate Teredo relay serving an IPv6 peer; the actual IPv6 packets are carried in UDP packets exchanged directly between the nodes, or exchanged through the relay serving an IPv6 peer. Teredo appears to be a good fit for providing IPv6 connectivity to hosts behind NAT, in case A of IPv6 deployment. The service is designed for minimizing the cost of deploying the server, which matches the requirement of minimizing the cost of the "supporting infrastructure" for peer-to-peer applications. 3 Meeting case B requirements In case B, we assume that the gateway and the ISP are both dual stack. The hosts on the local network may be IPv4 only, dual stack, or IPv6 only. The main requirements are: 3.1 Prefix delegation The gateway must be able to acquire an IPv6 prefix, delegated by the ISP. The possible mechanisms are RA proxy and explicit prefix delegation. 3.1.1 RA proxy The implicit delegation mechanism assumes that the gateway is connected to the ISP by a point-to-point link. Examples of such point to point links are various types of configured tunnels and serial links, for example using PPP. The principle of RA proxy is simple: the gateway issues a "router solicitation" message on the serial link, receives a "router advertisement", learns a network prefix from the advertisement, and advertises the same prefix on the unmanaged network. The implicit delegation mechanism cannot work if the provider's router advertises the same prefix to multiple gateways, as is the case if gateways are connected to routers through a shared media. In this situation, an explicit delegation mechanism is required; this type of mechanism is currently being studied. 3.1.2 Explicit prefix delegation Discussion of [PREFIXDHCPV6]. Huitema et al. [Page 3] INTERNET DRAFT Unmanaged Networks Transition Tools November 1, 2002 3.2 Communication between IPv4-only and IPv6-only hosts During the transition phase from IPv4 to IPv6 there will be IPv4- only, dual stack or IPv6-only nodes that want to communicate to other IPv4-only, dual stack or IPv6-only nodes. When both nodes do not speak the same version of IP, some translation will be needed. The table below shows the preferred situation with respect to nodes A and B wanting to communicating with each other. ======================================================== | + A | | | | | + | IPv4 only | dual stack | IPv6 only | | B + | | | | ======================================================== | H | | | | IPv4 H IPv4 | IPv4 | t(IPv6)->IPv4 | | only H address | address | address | | H | | | -------------------------------------------------------- | H | | | | dual H IPv4 | IPv4 or IPv6 | IPv6 | | stack H address | address | address | | H | | | -------------------------------------------------------- | H | | | | IPv6 H t(IPv4)->IPv6 | IPv6 | IPv6 | | only H address | address | address | | H | | | ======================================================== t(IPv6)->IPv4 means that some translation is involved which produces some IPv4 address for an IPv6 only host. t(IPv4)->IPv6 means that some translation is involved which produces some IPv6 address for an IPv4 only host. 3.2.1 The problem with address translation An obvious candidate for enabling communication between IPv4-only and IPv6-only hosts is "network address translation, protocol translation" [NAT-PT]. The NAT-PT mechanisms has two components, address translation and address discovery: address translation is the processing of IP packets by a NAT; address discovery is the mechanism by which an IPv4-only or IPv6-only host discovers the "translated address" at which packets for their correspondent should be addressed. The NAT-PT specification proposes to solve address discovery by using a DNS ALG, as specified in section 4 of [NAT-PT]. This section makes an important assumption: it assumes that the NAT- PT acts as a bridge between two networks, one IPv6-only and the other IPv6-only. As a result, the DNS-ALG will translate a DNS Huitema et al. [Page 4] INTERNET DRAFT Unmanaged Networks Transition Tools November 1, 2002 request for a AAAA record coming from the IPv6 host into a request for an A record, and vice versa. The problem is that address translation does not know if the traffic originates from an IPv4 only/IPv6 only node or from a dual stack node. When a dual stack node A wants to communicate with an IPv4 only host B, the dual stack host A gets either the IPv4 address of B (preferred) or an IPv6 address which is some kind of translation of the IPv4 address of B. This latter situation is not wanted, because it means unnecessary translation between IPv4 and IPv6. This is shown in the table below. ============================================================ | + A | | | | | + | IPv4 only | dual stack | IPv6 only | | B + | | | | ============================================================ | | | | | | IPv4 | IPv4 | IPv4 | t(IPv6)->IPv4 | | only | address | address | address | | | | | | ------------------------------------------------------------ | |XXXXXXXXXXXXXXXXX| |XXXXXXXXXXXXXXXXX| | dual | IPv4 address or | IPv4 or IPv6 | IPv6 address or | | stack | t(IPv4)->IPv6 | address | t(IPv6)->IPv4 | | |XXXXXXXXXXXXXXXXX| |XXXXXXXXXXXXXXXXX| ------------------------------------------------------------ | | | | | | IPv6 | t(IPv4)->IPv6 | IPv6 | IPv6 | | only | address | address | address | | | | | | ============================================================ The boxes with XXX-es are the cases where address translation could result in unwanted translation. 3.2.2 Possible solutions There are at least two solutions to the problems described above: avoid the DNS ALG, or avoid using the results of the DNS ALG when they are not needed. IPv6-only hosts can avoid the need for a DNS ALG if they can process IPv4 addresses locally. In this hypothesis, the IPv6-only node that wished to communicate with a correspondent will first request the AAAA records associated with the correspondent's name; if there are no such records, the IPv6-only node will request the A records of the correspondent, and construct as many IPv6 addresses by combining a specific address prefix with each IPv4 addresses. The same mechanism can be used when the IPv4 address is learned by other channels than the DNS, e.g. as a literal address in a URL. Dual stack hosts can avoid using unnecessary translation if they can Huitema et al. [Page 5] INTERNET DRAFT Unmanaged Networks Transition Tools November 1, 2002 recognize translated addresses, and then use address selection rules to give priority to non-translated addresses. Translated addresses can be either IPv6 addresses obtained by combining an IPv4 address with a specific address prefix, or IPv4 addresses allocated by the NAT-PT as a representation of an IPv6 address. The dual stack host can recognize translated IPv6 addresses if the know the value of the specific address prefix used by the NAT-PT; they can recognize the translated IPv4 addresses if the know the address range from which the NAT-PT picks them. The 1st mechanism will allow IPv6 only hosts to direct requests for IPv4 hosts to the NAT, possibly using a "bump in the API" mechanism. If we assume that this mechanism exists, then there is never a need for a NAT to intercept requests for AAAA records: the IPv6 only node will issue requests for A records if need be. The second mechanism allows a NAT to map IPv6 addresses to IPv4 while reducing the risk of confusion: with proper address selection rules, a dual stack host will never use these mapped addresses instead of the regular IPv6 addresses. Both solutions requires that the IPv6 host be aware of the specific IPv6 address prefix used by the NAT-PT, and thus require either that this 96 bit prefix be set to a conventional well known value, or that the value chosen by the NAT-PT be provisioned in each IPv6 client. Dual stack host will also need to recognize the IPv4 address range used by the NAT-PT. 3.3 Resolution of local names to IPv6 addresses To be developed. Compare dynamic DNS update and multicast name resolution. Study solution for reverse lookup. Consider the case of privacy addresses. 4 Meeting case C requirements Case C is very similar to case B, the difference being that the ISP is not dual stack. The gateway must thus use some form of tunneling mechanism to obtain IPv6 connectivity, and an address prefix. 4.1 Tunneling mechanisms 4.1.1 6to4 The [6TO4] technology allows routers to derive a global scope IPv6 prefix from a global IPv4 address. This technology is a very good fit for the second phase of the transition, as it can be programmed in the "upgraded gateway", and can provide value to the gateway users without requiring explicit support from the ISP. This technology has however a clear limitation: it requires that the gateway obtains at least one global IPv4 address from the local ISP. Huitema et al. [Page 6] INTERNET DRAFT Unmanaged Networks Transition Tools November 1, 2002 Another potential limitation of the technology is the reliance on publicly accessible "6to4 relay routers" that accept packets from 6to4 routers and relay them to the "regular" IPv6 Internet. These relays all listen to the same IPv4 anycast address [RFC3056], which enables gateways to start operating as 6to4 routers without requiring any explicit configuration. As the deployment of IPv6 progresses, a growing fraction of the traffic originating from 6to4 routers will have to be carried through these relays, potentially leading to severe congestion of the relays. There are three possible ways to alleviate this congestion. First, one can hope that many actors will deploy 6to4 relay routers, in order to facilitate the deployment of IPv6; congestion would be alleviated by the provision of a large number of gateways. Second, one could develop some "route optimization" process, so that the traffic would flow through a "shortcut path" rather than through the 6to4 relays; the relays would then avoid congestion by carrying only a small fraction of the traffic. Third, if neither the first nor the second solution materialize, some gateways may enter into contractual agreements with relay service providers; in this case, the 6to4 technology would become merely a variant of the configured tunnel technologies. 4.1.2 Tunnel broker Configured tunnels require a contractual agreement with an IPv6 provider, which comes in addition to the existing agreement with the IPv4 provider; different technologies have different domains of application: - Many tunnel technologies use a global IPv4 address to identify the "client end" of the tunnel, thus inheriting the same "global IPv4 address" requirement as 6TO4; - A variant of the [TEREDO] technology could be used to establish tunnels over UDP when the client cannot use a global IPv4 address; this variant is however not standardized. - Practical deployment of tunnel technologies requires the introduction of accounting/billing functions; the existing tunnel broker specification, [TUNNELS], does not describe how these functions should be implemented. The practical conclusion is that "upgraded gateways" will probably support the 6TO4 technology, and will have an optional configuration option for "configured tunnels". Configured tunnels are in practice an intermediate solution between the "automatic configuration" provided by 6to4, and the "ISP support" that characterize case B. 5 Meeting the case D requirements To be developed. Huitema et al. [Page 7] INTERNET DRAFT Unmanaged Networks Transition Tools November 1, 2002 6 Provisional recommendations This draft is still a draft, but we can already list a set of recommendations for the V6OPS working group: - To meet case A requirements, we need to develop and standardize the Teredo technology. - To meet case B prefix delegation requirements, we need a standardized IPv6 prefix delegation mechanism - To meet case B connectivity requirements, we need to revisit the NAT-PT specification, in order to clarify the use of the DNS-ALG. We also need to either reserve specific IPv4 and IPv6 address prefixes for use by NAT-PT, or define a way to provision IPv6 hosts with the IPv4 and IPv6 prefixes used by the local NAT-PT. - To meet case C connectivity requirement, we need to continue standardization of the 6to4 mechanism. 7 IANA Considerations This memo does not include any request to IANA. 8 Copyright The following copyright notice is copied from RFC 2026 [Bradner, 1996], Section 10.4, and describes the applicable copyright for this document. Copyright (C) The Internet Society July 12, 2001. 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 in 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 assignees. This document and the information contained herein is provided on an Huitema et al. [Page 8] INTERNET DRAFT Unmanaged Networks Transition Tools November 1, 2002 "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. 9 Intellectual Property The following notice is copied from RFC 2026 [Bradner, 1996], Section 10.4, and describes the position of the IETF concerning intellectual property claims made against this document. The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use other technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. 10 Acknowledgements This fractional and preliminary memo has benefited from comments of Ronald van der Pol, Margaret Wasserman and Tony Hain. 11 References [UNMANREQ] Unmanaged Networks Transition Scope. Work in progress. [IPV6] S. Deering, R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [NEIGHBOR] T. Narten, E. Nordmark, W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998. [STATELESS] T. Narten, S. Thomson, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998. [6TO4] B. Carpenter, K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", RFC 3056, February 2001. Huitema et al. [Page 9] INTERNET DRAFT Unmanaged Networks Transition Tools November 1, 2002 [6TO4ANYCAST] C. Huitema, "An Anycast Prefix for 6to4 Relay Routers", RFC 3068, June 2001. [TEREDO] Teredo: Tunneling IPv6 over UDP through NATs. Work in progress. [TUNNELS] A. Durand, P. Fasano, I. Guardini. IPv6 Tunnel Broker. RFC 3053, January 2001 [PREFIXDHCPV6] IPv6 Prefix Options for DHCPv6. Work in progress. [SIIT] E. Nordmark, Stateless IP/ICMP Translation Algorithm (SIIT). RFC 2765, February 2000. [NAT-PT] G. Tsirtsis, P. Srisuresh, Network Address Translation - Protocol Translation (NAT-PT). RFC 2766, February 2000. [DNS-ALG-ISSUES] Issues with NAT-PT DNS ALG in RFC2766. Work in progress. [HALLIN-DNS-ALG] NAT-PT DNS ALG solutions. Work in progress. [TRT] J. Hagino, K. Yamamoto. An IPv6-to-IPv4 Transport Relay Translator, RFC 3142, June 2001. [DSTM] Dual Stack Transition Mechanism (DSTM). Work in progress. [DNSDHCPV6] DNS Configuration options for DHCPv6. Work in progress. [DNSANYCAST] Well known site local unicast addresses for DNS resolver. Work in progress. [MDNS] Multicast DNS. Work in progress. [NODEINFO] IPv6 Node Information Queries. Work in progress. 12 Authors' Addresses Christian Huitema Microsoft Corporation One Microsoft Way Redmond, WA 98052-6399 Email: huitema@microsoft.com Rob Austein Email: sra@hactrn.net Suresh Satapati Cisco Systems, Inc. San Jose, CA 95134 Huitema et al. [Page 10]
INTERNET DRAFT Unmanaged Networks Transition Tools November 1, 2002 USA EMail: satapati@cisco.com Ronald van der Pol Email: Ronald.vanderPol@rvdp.org Huitema et al. [Page 11]
INTERNET DRAFT Unmanaged Networks Transition Tools November 1, 2002 Table of Contents: 1 Introduction .................................................... 1 2 Meeting case A requirements ..................................... 2 2.1 Evaluation of connectivity mechanisms ......................... 2 2.1.1 TEREDO ...................................................... 3 3 Meeting case B requirements ..................................... 3 3.1 Prefix delegation ............................................. 3 3.1.1 RA proxy .................................................... 3 3.1.2 Explicit prefix delegation .................................. 3 3.2 Communication between IPv4-only and IPv6-only hosts ........... 4 3.2.1 The problem with address translation ........................ 4 3.2.2 Possible solutions .......................................... 5 3.3 Resolution of local names to IPv6 addresses ................... 6 4 Meeting case C requirements ..................................... 6 4.1 Tunneling mechanisms .......................................... 6 4.1.1 6to4 ........................................................ 6 4.1.2 Tunnel broker ............................................... 7 5 Meeting the case D requirements ................................. 7 6 Provisional recommendations ..................................... 8 7 IANA Considerations ............................................. 8 8 Copyright ....................................................... 8 9 Intellectual Property ........................................... 9 10 Acknowledgements ............................................... 9 11 References ..................................................... 9 12 Authors' Addresses ............................................. 10 Huitema et al. [Page 12]