Network Working Group R. van der Pol Internet-Draft NLnet Labs Expires: July 28, 2003 S. Satapati S. Sivakumar Cisco Systems, Inc. January 27, 2003 Issues when translating between IPv4 and IPv6 draft-vanderpol-v6ops-translation-issues-00 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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. This Internet-Draft will expire on July 28, 2003. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract During the transition from IPv4 to IPv6 both protocols will be used simultaneously. Most nodes will support both protocols and will be able to communicate via both IPv4 and IPv6 transport. Problems arise when a node only supports IPv4 and it wants to communicate with a node that only supports IPv6. Translation between the two IP protocols might be needed in some cases. This memo discusses the problems involved in translation between IPv4 and IPv6. van der Pol, et al. Expires July 28, 2003 [Page 1] Internet-Draft Translation issues January 2003 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Why is translation between IPv4 and IPv6 needed? . . . . . . 3 4. The basic elements of protocol translation . . . . . . . . . 4 5. The problems with translation between IPv4 and IPv6 . . . . 4 5.1 The problems with address translation . . . . . . . . . . . 4 5.2 The problems with address discovery . . . . . . . . . . . . 5 5.2.1 The problem of getting unwanted translated addresses . . . . 6 5.2.2 The problem of getting AAAA answers for A queries . . . . . 7 5.3 Scaling problems with NAT in large setups . . . . . . . . . 8 6. IPv4 NAT or NAT-PT? . . . . . . . . . . . . . . . . . . . . 8 7. When is translation between IPv4 and IPv6 needed? . . . . . 8 8. Security Considerations . . . . . . . . . . . . . . . . . . 8 References . . . . . . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 9 A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 Intellectual Property and Copyright Statements . . . . . . . 11 van der Pol, et al. Expires July 28, 2003 [Page 2] Internet-Draft Translation issues January 2003 1. Introduction During the transition from IPv4 to IPv6 both protocols will be used simultaneously. Most nodes will be able to communicate via both IPv4 and IPv6 transport (dual stack nodes). When communicating to a node that supports only one of the protocols, they choose that protocol. When communication via both protocols is possible, they usually default to IPv6. Problems arise when one node only supports IPv4 (IPv4-only) and the node it wants to communicate with only supports IPv6 (IPv6-only). In some cases the nodes can still communicate by using a proxy that supports both IPv4 and IPv6, e.g. by using an HTTP proxy for web traffic. If no such proxies are available and the nodes must communicate, translation between IPv4 and IPv6 could be used as a last resort. This memo discusses the problems involved with translation between IPv4 and IPv6. 2. Terminology o IPv4-only node - A node that has an IPv4 stack and no IPv6 stack. o IPv6-only node - A node that has an IPv6 stack and no IPv4 stack. o dual stack node - A node that has both an IPv4 and an IPv6 stack. It may be connected to an IPv4 network, to an IPv6 network or to both. o NAT - Network Address Translation. Usually, the translation between a private (RFC1918) IPv4 address and a globally routable IPv4 address and vice versa. o NAT-PT - Network Address Translation, Protocol Translation. The translation between IPv4 addresses and semantically equivalent IPv6 address and vice versa. o ALG - Application Level Gateway. A translator that knows how to translate the payload of traffic of a particular application when the payload contains IP addresses. Each application needs its own specific ALG. o DNS-ALG - An Application Level Gateway for DNS. 3. Why is translation between IPv4 and IPv6 needed? If one node only supports IPv4 and the other node only supports IPv6, no direct communication is possible. Fortunately, most nodes will be dual stack, which means they support both IP versions. However, nodes that are not upgraded yet support only IPv4. Problems arise van der Pol, et al. Expires July 28, 2003 [Page 3] Internet-Draft Translation issues January 2003 when IPv6-only devices are introduced in the internet. Those devices can not communicate with IPv4-only nodes. When introducing such devices several questions should be asked. o Is communication with IPv4-only devices needed or is it acceptable to support communication with dual stack and other IPv6-only nodes only. o Is it possible to use dual stack proxies? E.g., IPv6-only appliances that offer web services can be reached via IPv4 transport by using dual stack HTTP proxies. It should also be noted that IPv6-only nodes do not require translation to function. E.g., they can use DNS or email services when these services are setup with dual stakc in mind. These issues are explained in [5] and [4]. For DNS resolving they can use a dual stack caching forwarder. For outgoing email they can use a dual stack mail drop. For incoming email they can use POP or IMAP via IPv6 transport to fetch their email from a central email server that receives email via IPv4 and IPv6 transport. 4. The basic elements of protocol translation An obvious candidate for enabling communication between IPv4-only and IPv6-only nodes is NAT-PT [2]. The NAT-PT mechanism has two components, address and protocol translation as described in SIIT [1] and address discovery. Address and protocol translation is the processing of IP packets by a NAT; address discovery is the mechanism by which an IPv4-only or an IPv6-only node discovers the "translated address" to which packets should be sent. The NAT-PT specification proposes to solve address discovery by using a DNS-ALG, as specified in section 4 of NAT-PT [2]. 5. The problems with translation between IPv4 and IPv6 Translation between IPv4 and IPv6 has many different problems. Some of these problems are summarized in the next sections. Section Section 5.1 summarizes the problems of NAT. Section Section 5.2 describes the problems with address discovery. Section Section 5.3 describes the scaling problems in large NAT setups. 5.1 The problems with address translation Translation between IPv4 and IPv6 has all the problems of classic NAT as described in RFC 2993 [3]. o It breaks applications that have IP addresses in the payload. NAT only translates addresses in the IP headers, not in the payload. van der Pol, et al. Expires July 28, 2003 [Page 4] Internet-Draft Translation issues January 2003 ALGs must be used to translate addresses in the payloads. However, each application needs its own specific ALG. Therefore, it is hard to introduce new applications that need to use addresses in the payload of there packets. o It breaks security protocols like IPsec and DNSEC. The IPSec AH header contains a hash of the IP header. If the IP header is modified by the translator, the authencity of the packet is lost. DNS-ALG cannot translate DNSSEC packets because it does not know the private key of the signature(s). o It breaks IP multicast. Protocols like PIM, SDR, RTP, etc. have IP addresses in their payloads. NAT boxes need ALGs for all of these. Few if any NAT boxes support all the ALGs needed. o It is a bottleneck and a single point of failure, because the NAT box needs to build state and therefore all the traffic must pass the NAT box. 5.2 The problems with address discovery 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 version of IP address with respect to nodes A and B wanting to communicate with each other. van der Pol, et al. Expires July 28, 2003 [Page 5] Internet-Draft Translation issues January 2003 ======================================================== | + 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. 5.2.1 The problem of getting unwanted translated addresses This section makes an important assumption: it assumes that the NAT-PT acts as a bridge between two networks, one IPv4-only and the other IPv6-only. As a result, the DNS-ALG will translate a DNS request for a AAAA record coming from the IPv6 node 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 node B, the dual stack node 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. van der Pol, et al. Expires July 28, 2003 [Page 6] Internet-Draft Translation issues January 2003 ============================================================ | + 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. 5.2.2 The problem of getting AAAA answers for A queries Within an IPv6 NAT-PT domain, an application asking for an A record could be returned a translated AAAA record. RFC2766 [2] section 4.2: "...the DNS-ALG on the NAT-PT device forwards the original AAAA/A6 query to the external DNS system unchanged, as well as an A query for the same node. If an AAAA/A6 record exists for the destination, this will be returned to NAT-PT which will forward it, also unchanged, to the originating host. If there is an A record for Node-C the reply also returns to the NAT-PT. The DNS-ALG then, translates the reply adding the appropriate PREFIX and forwards it to the originating device with any IPv6 addresses that might have learned." RFC2766 is not clear on how a DNS-ALG should treat answers to A queries made by nodes within the NAT-PT domain. As a matter of fact, one could fear that a careless DNS-ALG would also intercept them and translate them into a AAAA form. In other words, nodes asking for an A record could be returned a AAAA record. Although this may not be a problem for simple IPv6-only applications, it may be a concern for van der Pol, et al. Expires July 28, 2003 [Page 7] Internet-Draft Translation issues January 2003 applications that 'walk through' the DNS structure and may pass information to peers. 5.3 Scaling problems with NAT in large setups In large networks NAT-PT and/or DNS-ALG boxes can become a serious single point of failure, a bottleneck and a Denial Of Service (DOS) target. It may be necessary to spread the NAT-PT and/or DNS-ALG among several boxes. However, this is a very complicated operation. The NAT-PT and/or DNS-ALG boxes need to build state about address mappings. The setup must be carefully chosen, so that packets that need to be translated are routed through the box that has the proper state. 6. IPv4 NAT or NAT-PT? Nodes on an IPv6-only network that want to communicate with IPv4-only nodes do not necessarily need to use NAT-PT. If the nodes are dual stack, they can use IPv4-in-IPv6 tunneling through the IPv6-only network. In cases where there are only private IPv4 (RFC1918) addresses available, it still makes sense to use IPv4-in-IPv6 tunneling combined with classical IPv4 NAT, because there is extensive deployment experience with IPv4 NAT, but little experience with NAT-PT. 7. When is translation between IPv4 and IPv6 needed? Some argue that IPv6-only devices will show up on a large scale soon because of new appliances that do not have enough memory to support both IPv4 and IPv6. Others argue that the cost of a dual or hybrid stack is not much more than that of an IPv6-only stack. Others think translation is only needed in the final phase of the transition from IPv4 to IPv6. Eventually, almost all nodes will be IPv6 enabled and only a few legacy systems are still IPv4-only. When communicating with those legacy systems, translation might be needed. 8. Security Considerations As described in section Section 5.1 NAT-PT breaks security protocols like IPsec and DNSSEC. Because all traffic needs to go through the NAT boxes, these boxes can become a target for a DOS attack. Some argue that an advantage of NAT is that there is no traffic possible to an inside address/port until the NAT box has built state for that address/port combination. That is only partially true. As soon as the inside address/port has sent a packet outside, the NAT box has state for that address/port combination and that address/port van der Pol, et al. Expires July 28, 2003 [Page 8] Internet-Draft Translation issues January 2003 combination is globally reachable. For security reasons, it is much better to have a more controlled security meachanism. A host inside a NAT-PT network when trying to traverse through the NAT box gets an global address. However, this host can send packets with different spoofed source addresses which will make the NAT box exhaust its address pool. In this case, no other legitimate hosts can communicate to the other side of the translator, because the translator has no more addresses to give. This can be a serious problem in large NAT-PT networks. References [1] Nordmark, E., "Stateless IP/ICMP Translation Algorithm (SIIT)", RFC 2765, February 2000. [2] Tsirtsis, G. and P. Srisuresh, "Network Address Translation - Protocol Translation (NAT-PT)", RFC 2766, February 2000. [3] Hain, T., "Architectural Implications of NAT", RFC 2993, November 2000. [4] Nakamura, M. and J. Hagino, "SMTP operational experience in mixed IPv4/IPv6 environements", draft-ietf-ngtrans-ipv6-smtp-requirement-06 (work in progress), July 2002. [5] Durand, A., "IPv6 DNS transition issues", draft-durand-ngtrans-dns-issues-00 (work in progress), June 2002. Authors' Addresses Ronald van der Pol NLnet Labs Kruislaan 419 Amsterdam 1098 VA NL EMail: Ronald.vanderPol@nlnetlabs.nl van der Pol, et al. Expires July 28, 2003 [Page 9] Internet-Draft Translation issues January 2003 Suresh Satapati Cisco Systems, Inc. 170 West Tasman Dr. San Jose CA 95134 US EMail: satapati@cisco.com Senthil Sivakumar Cisco Systems, Inc. 170 West Tasman Dr. San Jose CA 95134 US EMail: ssenthil@cisco.com Appendix A. Acknowledgements The authors gratefully acknowledge the contributions of: Rob Austein, Christian Huitema, and, Daniel Soohong. van der Pol, et al. Expires July 28, 2003 [Page 10] Internet-Draft Translation issues January 2003 Intellectual Property Statement 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 of the 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 implementors 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. Full Copyright Statement Copyright (C) The Internet Society (2003). 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 "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 van der Pol, et al. Expires July 28, 2003 [Page 11] Internet-Draft Translation issues January 2003 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. van der Pol, et al. Expires July 28, 2003 [Page 12]