INTERNET DRAFT C. Huitema Microsoft September 11, 2002 R. Austein Expires March 11, 2002 Bourgeois Dilettante S. Satapati Cisco Systems, Inc. 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, through five stages of development: no infrastructure upgrade, gateway upgrade, ISP upgrade, IPv6 only host, IPv6 only ISP. 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. Huitema et al. [Page 1] INTERNET DRAFT Unmanaged Networks Transition Tools September 11, 2002 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 the connectivity 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. 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 Huitema et al. [Page 2] INTERNET DRAFT Unmanaged Networks Transition Tools September 11, 2002 infrastructure" for peer-to-peer applications. 2.1.2 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. 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. 2.1.3 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 Huitema et al. [Page 3] INTERNET DRAFT Unmanaged Networks Transition Tools September 11, 2002 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 the third phase. 2.1.4 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. 2.1.5 Explicit prefix delegation Discussion of [PREFIXDHCPV6]. 2.1.6 SIIT Stateless IP/ICMP Translation Algorithm (SIIT) is a generic translation mechanism between IPv4 and IPv6. The main characteristics of DSTM are as follow: 1) The translation system maintains a pool of IPv4 addresses; 2) The system provides translation for a set of "client" IPv6 nodes, which use set of IPv6 addresses; 3) The IPv4 addresses in the pool are statically or dynamically paired with the IPv6 address of a "client" node; 4) The IPv4 addresses outside the pool are presented to clients by combining a 96 bit IPv6 prefix, specific to the system, with the 32 bit IPv4 address. A SIIT system will receive the IPv6 packets whose destination address starts with its 96 bit prefix. Translation from IPv6 is performed by mapping the destination address to the IPv4 address represented in its least significant 32 bits, and by mapping the source IPv6 address to one of the addresses in the pool, using a static mapping if one already existed, or using a dynamic mapping Huitema et al. [Page 4] INTERNET DRAFT Unmanaged Networks Transition Tools September 11, 2002 otherwise. The SIIT mechanism is a good match to the requirement for communication between local IPv4 and IPv6 nodes in an unmanaged network: the gateway can easily obtain a 96 bit IPv6 prefix, and it can use a pool of IPv4 addresses from the RFC 1918 address space. SIIT should however be complemented by a mechanism that allocate a static or quasi static IPv4 address mapping to the local IPv6 only hosts. The SIIT mechanism may not be a good match for the other translation requirement expressed in the scoping document, i.e. provide access for IPv6 only hosts to IPv4 servers: SIIT requires a pool of IPv4 addresses that is larger than the "working set" of IPv6 addresses using the system, but in most unmanaged networks, the gateway can manage only one IPv4 addresses. This probably mandates some form of port translation in addition to protocol translation, which is outside the scope of SIIT. SIIT may or may not be a good solution for the "Internet base" translation services required in case D, depending on the size of the required "working set" and the size of the pool of addresses available to the SIIT system. 2.1.7 NAT-PT The "Network Address Translation - Protocol Translation" [NAT-PT] combines the use of [SIIT] with the use of application layer gateways (ALG), to replace notation of IPv4 or IPv6 addresses in protocol packets by their appropriate IPv6 or IPv4 value. In particular, the specification discusses a DNS ALG that would enable the NAT-PT system to reply with a "translated" record, e.g. a AAAA record contained the IPv6-mapped IPv4 address of an IPv4 only host, or a A record containing the IPv4 address statically assigned to an IPv6 only host. (Text from Suresh - there are some disagreements) NAT-PT, combined with SIIT, is a good fit for Phase 4 (or whatever this phase will be renumbered/re-lettered), using which IPv6 only nodes can interact with IPv4 nodes and vice-versa. There are some issues with DNS-ALG portion of NAT-PT [DNS-ALG-ISSUES], that have been pointed out by the community. A variant of DNS-ALG [HALLIN-DNS- ALG] could be used to overcome these problems. The only issue that remains unaddressed with NAT-PT DNS-ALG is that it breaks DNS-SEC. NAT-PT without the DNS-ALG, but with a DNS proxy, would be a good fit for deployments that mandate DNS-SEC. -- There is some disagreement that this is the only issue -- 2.1.8 NAT64 Huitema et al. [Page 5] INTERNET DRAFT Unmanaged Networks Transition Tools September 11, 2002 -- Not clear that we should actually have a section on NAT64 -- 2.1.9 TRT An IPv6-to-IPv4 Transport Relay Translator [TRT] may be used instead of a NAT to provide access to IPv4 only servers for IPv6 hosts. (extract from an e-mail by Rob Austein) TRT (RFC 3142) has many of the same characteristics as NAT-PT, so the situations in which one can use one tend to be the situations in which one can use the other. Basically, NAT-PT is a simpler way to handling the simple protocols (roughly: applications that don't require an ALG), while TRT is better at handling the complicated protocols. Most single-connection TCP based protocols work through NAT-PT, as do most simple "connection-like" UDP based protocols (eg, TFTP); whether NAT-PT is "better" than TRT depends on what one is trying to accomplish and how much setup work one is willing to do. TRT is -much- better for a protocol like FTP, let alone an abomination like H.323. More precisely, TRT is much better for handling the control connections of such protocols; the data streams of such protocols tend to be just normal packet streams that can also be handled (perhaps more easily) via NAT-PT. (Not true for SIP & H.323; the signaling exchange need to be aware of the addresses used end-to-end. -CH.) I suspect that the winning combination is probably an integrated package that uses both of these mechanisms on top of the same support mechanisms (address translation table, dynamic packet filtering rule support (if any), etc). 2.1.10 DSTM The "Dual Stack Transition Mechanism" [DSTM] is targeted to help the interoperation of IPv6 newly deployed networks with existing IPv4 networks. The DSTM service manages a pool of IPv4 addresses that are leased to dual-stack hosts using DHCPv6; the dual-stack hosts transmit IPv4 packets to IPv4 only hosts by tunneling them over IPv6 to the DSTM server, which then relays them using IPv4; in the opposite direction, the DSTM server receives IPv4 packets directed to the addresses in the pool, and tunnels them to the IPv6 destination to which the IPv4 address has been leased. For the hosts, the advantage of DSTM over NAT-PT is transparency: the content of the IPv4 packet is not affected by any translation; it is possible to use encryption, including IP security. The cost is Huitema et al. [Page 6] INTERNET DRAFT Unmanaged Networks Transition Tools September 11, 2002 the need to maintain a dual stack: the tunneling mechanism effectively provides the host with an IPv4 interface, that supplements the existing IPv6 interface. As such, DSTM is not a solution for IPv6 only hosts. For the network operator, DSTM is an alternative to running a "dual stack" infrastructure: all the internal routers operate strictly on IPv6 packets. This advantage is however marginal to inexistent for unmanaged networks, which typically do not include internal routers; there is no obvious advantage to allocating IPv4 addresses through DHCPv6 rather than DHCPv4. DSTM may have a role to play in the transition of large network, or in that of ISP networks, but its role in the transition of unmanaged networks is thus marginal at best: it does not support IPv6 only hosts, and it does not provide an operational advantage in the unmanaged network. 2.2 Recommendation of connectivity mechanisms 3 Meeting the naming requirements This section is even more preliminary than the previous one. 3.1 Existing naming services 3.1.1 DHCPv6 -- discussion of [DNSDHCPV6] -- 3.1.2 Reserved address -- discussion of [DNSANYCAST] -- 3.1.3 MDNS -- discussion of [MDNS] -- 3.1.4 Node identification -- discussion of [NODEINFO] -- 3.1.5 Dynamic DNS 3.1.6 Reverse lookup wildcard In a wildcard scenario, the reverse lookup requests are routed to a DNS server provided by the ISP, and are served there by an automatic process. For example, if the ISP "example.net" has delegated the prefix 1234:5678:9ABC::/48 to the subscriber "foo", an wildcard Huitema et al. [Page 7] INTERNET DRAFT Unmanaged Networks Transition Tools September 11, 2002 service would respond to reverse lookup for the address 1234:5678:9ABC::1 by providing a pointer to either "1234-5678-9ABC- 0-0-0-0-1.example.net", or "1234-5678-9ABC-0-0-0-0- 1.foo.example.net" - i.e. with or without an identification of the client's account in the pointed name. Privacy advocates will probably insist that ISP do not include client identification in such pointers, as this would negate all benefits of privacy addresses. 3.1.7 DNS delegation In a delegation scenario, the ISP will delegate a domain name to the gateway, e.g. "foo.example.net". The gateway could then publish DNS names for the internal hosts, e.g. "host-1.foo.example.net". If the ISP also delegates management of the "reverse lookup" prefix, "C.B.A.9.8.7.6.5.4.3.2.1.ip6.arpa" in our example, the gateway could also manage reverse lookup records for the unmanaged network. This will require the same dynamic DNS procedures that are required in any case for local name resolution; it will also require a cautious handling of privacy addresses to avoid inadvertent information disclosure. 3.2 Recommendation of naming services 4 Meeting the security requirements 4.1 Existing mechanisms 4.1.1 Privacy addresses 4.1.2 Local scope addresses 4.1.3 IP security 4.1.4 Host based firewalls 4.1.5 Gateway based firewall 4.2 Recommendation of security mechanisms 5 Security Considerations Section 4 of this memo discusses the available security mechanisms for managing the deployment of IPv6. 6 IANA Considerations This memo does not include any request to IANA. 7 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 Huitema et al. [Page 8] INTERNET DRAFT Unmanaged Networks Transition Tools September 11, 2002 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 "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. 8 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. Huitema et al. [Page 9] INTERNET DRAFT Unmanaged Networks Transition Tools September 11, 2002 9 Acknowledgements This fractional and preliminary memo has benefited from comments of Ronald van der Pol, Margaret Wasserman and Tony Hain. 10 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. [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. Huitema et al. [Page 10] INTERNET DRAFT Unmanaged Networks Transition Tools September 11, 2002 [MDNS] Multicast DNS. Work in progress. [NODEINFO] IPv6 Node Information Queries. Work in progress. 11 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 USA EMail: satapati@cisco.com Huitema et al. [Page 11] INTERNET DRAFT Unmanaged Networks Transition Tools September 11, 2002 Table of Contents: 1 Introduction .................................................... 1 2 Meeting the connectivity requirements ........................... 2 2.1 Evaluation of connectivity mechanisms ......................... 2 2.1.1 TEREDO ...................................................... 2 2.1.2 6to4 ........................................................ 3 2.1.3 Tunnel broker ............................................... 3 2.1.4 RA proxy .................................................... 4 2.1.5 Explicit prefix delegation .................................. 4 2.1.6 SIIT ........................................................ 4 2.1.7 NAT-PT ...................................................... 5 2.1.8 NAT64 ....................................................... 5 2.1.9 TRT ......................................................... 6 2.1.10 DSTM ....................................................... 6 2.2 Recommendation of connectivity mechanisms ..................... 7 3 Meeting the naming requirements ................................. 7 3.1 Existing naming services ...................................... 7 3.1.1 DHCPv6 ...................................................... 7 3.1.2 Reserved address ............................................ 7 3.1.3 MDNS ........................................................ 7 3.1.4 Node identification ......................................... 7 3.1.5 Dynamic DNS ................................................. 7 3.1.6 Reverse lookup wildcard ..................................... 7 3.1.7 DNS delegation .............................................. 8 3.2 Recommendation of naming services ............................. 8 4 Meeting the security requirements ............................... 8 4.1 Existing mechanisms ........................................... 8 4.1.1 Privacy addresses ........................................... 8 4.1.2 Local scope addresses ....................................... 8 4.1.3 IP security ................................................. 8 4.1.4 Host based firewalls ........................................ 8 4.1.5 Gateway based firewall ...................................... 8 4.2 Recommendation of security mechanisms ......................... 8 5 Security Considerations ......................................... 8 6 IANA Considerations ............................................. 8 7 Copyright ....................................................... 8 8 Intellectual Property ........................................... 9 9 Acknowledgements ................................................ 10 10 References ..................................................... 10 11 Authors' Addresses ............................................. 11 Huitema et al. [Page 12]