Network Working Group P. Hallin Internet-Draft Telia Research AB Expires: December 16, 2002 June 17, 2002 NAT-PT DNS ALG solutions draft-hallin-natpt-dns-alg-solutions-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 December 16, 2002. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract There is an ongoing discussion about the impact of IPv4 to IPv6 transition mechanisms such as NAT-PT (RFC2766). [NAT-PT-ISSUES] identifies several problems around the DNS ALG functionality in NAT- PT. This document proposes possible solutions to some of the problems illustrated in [NAT-PT-ISSUES] and to additional issues with the DNS ALG functionality in NAT-PT. Hallin Expires December 16, 2002 [Page 1] Internet-Draft NAT-PT DNS ALG solutions June 2002 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Solutions to some of the problems described in [NAT-PT-ISSUES] 3 2.1 AAAA answers for A queries . . . . . . . . . . . . . . . . . . 3 2.2 Source Address Selection/Destination ordering . . . . . . . . 3 2.3 NAT-PT & IPv6 default router . . . . . . . . . . . . . . . . . 5 2.4 IPv4 Address assignment for incoming connections (IPv4 to IPv6) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Solutions to additional problems with the NAT-PT DNS ALG . . . 6 3.1 Reverse queries from IPv6 to IPv4 . . . . . . . . . . . . . . 6 3.2 Truncated DNS messages . . . . . . . . . . . . . . . . . . . . 8 4. Security Considerations . . . . . . . . . . . . . . . . . . . 8 References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 9 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 10 Hallin Expires December 16, 2002 [Page 2] Internet-Draft NAT-PT DNS ALG solutions June 2002 1. Introduction NAT-PT is an IPv6 to IPv4 transition mechanism that enables IPv6-only clients to use IPv4 services. NAT-PT works by combining protocol translation with [NAT]. Due to the long address format of IPv6 it is believed that IPv6 users will use DNS a lot. To enable DNS traffic through a NAT-PT a special Application Level Gateway (ALG) is provided. The DNS-ALG within a NAT-PT will be a very important component. IETF has recognized some problems with the DNS-ALG described in [NAT-PT]. The issues discussed include that packets will be translated even when it is not necessary and that all IPv6 traffic has to go through the NAT-PT, whether or not it is translated. Protocol translation is a potential bottleneck and it is important to limit its use. This document will describe possible solutions to some of these problems as well as to other issues with the DNS ALG functionality in NAT-PT. 2. Solutions to some of the problems described in [NAT-PT-ISSUES] 2.1 AAAA answers for A queries [NAT-PT-ISSUES] points out that it is not specified in [NAT-PT] how a DNS ALG should treat answers to A queries from internal hosts. NAT-PT should only be used by IPv6-only nodes. These nodes should not use IPv4 DNS (A) and if an A query from an internal node is intercepted by the NAT-PT, it should be refused. Dual-stack nodes use both IPv4 and IPv6 DNS, but since they are able to communicate using native IPv4 with IPv4-only hosts they have no use of a NAT-PT. Thus, they should not communicate with IPv4-only nodes through a NAT- PT. --------------------------------------------------------------------- => NAT-PT should only be used by IPv6-only nodes. These nodes should not use IPv4 DNS (A), thus the NAT-PT should refuse any A queries made by internal nodes. --------------------------------------------------------------------- 2.2 Source Address Selection/Destination ordering [NAT-PT-ISSUES] illustrates that the communication between a node within the NAT-PT domain and an external dual-stack host, will select the translated path over the native IPv6 path. Let's assume that an IPv6-only node X within a NAT-PT domain wants to communicate with a dual-stack host Y on the public Internet. The host Y has published both IPv4 (A) and IPv6 (AAAA) addresses in the Hallin Expires December 16, 2002 [Page 3] Internet-Draft NAT-PT DNS ALG solutions June 2002 DNS. X will query IPv6 (AAAA) for Y. The NAT-PT will intercept the IPv6 DNS query. In the NAT-PT standard it is specified that the DNS- ALG should forward the intercepted IPv6 queries in an unchanged version together with a translated IPv4 DNS query (A) to the DNS server. The DNS server will return both an IPv4 and an IPv6 DNS reply to the NAT-PT. The idea is that the IPv4 DNS reply will have an empty answer section if the destination host is IPv6 and that the IPv6 DNS reply will have an empty answer section if the destination host is IPv4. Both DNS replies are forwarded to the requesting IPv6 client. The IPv6 DNS reply will be forwarded in unchanged form and the IPv4 DNS reply will be translated to an IPv6 DNS reply. The requesting client will receive two IPv6 DNS replies, one empty and one containing the IPv6 address of the destination host. Depending on if the destination host is IPv4 or IPv6, the address will either be a native IPv6 or a translated IPv4 address. This works fine when communicating with IPv6-only or IPv4-only hosts. Problems occur when the destination host is dual-stack IPv4/IPv6 such as the host Y. The client will then receive two IPv6 DNS replies with answer sections containing addresses. As the prefix associated to the translated address belongs to same site as X's IPv6 address, when X will use source address selection/destination address ordering it will result to longest prefix match and will choose the "translated" address over the native one. The result is that protocol translation will be used even if native IPv6 communication is possible. An alternate approach is for the DNS ALG to send the IPv6 DNS query in unchanged form, but ignore to send the translated IPv4 DNS query. The returning IPv6 DNS reply is analysed. If the answer section of the IPv6 DNS reply contains addresses, it is forwarded in unchanged form to the IPv6-only client. A special case is if the IPv6 DNS reply contains the name error flag, in this case the domain name does not exist and the IPv6 DNS reply can be forwarded to the IPv6 only client in unchanged form. If the answer section of the IPv6 DNS reply does not contain any addresses and the name error flag is not set, it is probable that the destination host is IPv4 and protocol translation is required. The DNS reply is then converted to an IPv4 DNS request and returned to the DNS server. The returning IPv4 DNS reply will be translated to IPv6 and forwarded to the IPv6-only client. The negative effect of this method is increased DNS latency when communicating with IPv4- only hosts. This is because the empty IPv6 DNS message has to arrive to the NAT-PT before the IPv4 (a) request can be sent. Hallin Expires December 16, 2002 [Page 4] Internet-Draft NAT-PT DNS ALG solutions June 2002 IPv6-only client NAT-PT IPv4 DNS server | AAAA query | | |------------->--------------|AAAA query (unchanged form) | | |-------------->-------------| | | | | | AAAA reply | | |--------------<-------------| | | | |AAAA reply (unchanged form) | | |-------------<--------------| | | | | Figure 1: Case one, the destination host is IPv6 enabled IPv6-only client NAT-PT IPv4 DNS server | AAAA query | | |------------->--------------|AAAA query (unchanged form) | | |-------------->-------------| | | | | | AAAA reply | | |--------------<-------------| | | | | | A query | | |-------------->-------------| | | | | | A reply | | |--------------<-------------| | AAAA reply | | |--------------<-------------| | Figure 2: Case two, the destination host is IPv4-only --------------------------------------------------------------------- => This solution ensures that communication between nodes within the NAT-PT domain always use native IPv6 communication when possible. The price is added DNS latency. --------------------------------------------------------------------- 2.3 NAT-PT & IPv6 default router The NAT-PT DNS ALG makes the assumption that the DNS traffic goes through the NAT-PT box. [NAT-PT-ISSUES] describes that this is ok when DNS resolution is done over IPv4. However, if it is done over IPv6, there is no reason why the DNS traffic will still go through the NAT-PT box unless the NAT-PT box is also the default IPv6 router of the site. The conclusion is that NAT-PT has to be the only Hallin Expires December 16, 2002 [Page 5] Internet-Draft NAT-PT DNS ALG solutions June 2002 default IPv6 router in the NAT-PT domain to work correctly with DNS- ALG. This implicates that all IPv6 traffic has to go through the NAT-PT, whether or not it is translated. This raises scalability issues in larger networks. In a network with both IPv6-only and dual-stack hosts, this would require dual-stack hosts to be connected to a NAT- PT. This would not make any sense, since dual-stack hosts have no need for the services a NAT-PT provides. However, a more scalable approach is that IPv6-only clients connected to the NAT-PT, do all IPv6 DNS resolution over translated IPv4. The IPv6-only clients set NAT-PT_PREFIX:ipv4_dns as their DNS server, where NAT-PT_PREFIX is the NAT-PT prefix in the NAT-PT domain and ipv4_dns is a DNS server in the IPv4 domain. All DNS messages will then be routed through the NAT-PT. Dual-stack nodes will continue to use their ordinary DNS server. Their DNS traffic will not be routed through the NAT-PT. Thus, dual-stack nodes have no contact with the NAT-PT in the network. The NAT-PT is not required to be the default IPv6 router of the site. Only traffic in need of translation will be routed through the NAT-PT. This set up works provided that the IPv4 DNS server supports IPv6 DNS. --------------------------------------------------------------------- => It is not necessary for the NAT-PT to be the only default router in the IPv6 domain. The only traffic that has to go through the NAT- PT is the one that needs to be translated. --------------------------------------------------------------------- 2.4 IPv4 Address assignment for incoming connections (IPv4 to IPv6) IPv4 Address assignment for incoming connections (IPv4 to IPv6) works the same way as described in [NAT-PT]. If a network administrator is cautious about denial of service attacks, it is possible to ignore to configure the forwarding to the IPv6 DNS server. IPv6 nodes with static bindings can still be reached from IPv4 by registering them in the IPv4 DNS server. Another method is to enable IPv6 on IPv4 nodes wanting to communicate with IPv6-only nodes. 3. Solutions to additional problems with the NAT-PT DNS ALG 3.1 Reverse queries from IPv6 to IPv4 The DNS-ALG described in [NAT-PT] does not support reverse queries from IPv6 to IPv4. Reverse querying is an important feature to support. For example, some applications uses reverse queries to check if the result of a name lookup is correct. By using the minor extension to [NAT-PT] presented below reverse querying from IPv6 to Hallin Expires December 16, 2002 [Page 6] Internet-Draft NAT-PT DNS ALG solutions June 2002 IPv4 is enabled. If the IPv6 address in the IPv6 reverse query starts with the NAT-PT prefix, the DNS-ALG understands that this is a reverse query for an IPv4 node. The IPv4 address is extracted by removing the NAT-PT prefix. The translation works by replacing the string "IP6.INT" with "IN-ADDR.ARPA" and replacing the IPv6 address with the extracted IPv4 address (in reverse order). Reverse queries concerning IPv6 addresses that don't start with the NAT-PT prefix is forwarded to the DNS server in unchanged form. This enables correct reverse lookup of both native IPv6 and translated IPv4 addresses. Hallin Expires December 16, 2002 [Page 7] Internet-Draft NAT-PT DNS ALG solutions June 2002 --------------------------------------------------------------------- => It is possible to support IPv6 to IPv4 reverse querying with minor additions to [NAT-PT]. --------------------------------------------------------------------- 3.2 Truncated DNS messages When the DNS-ALG described in [NAT-PT] translates DNS replies from IPv4 to IPv6, it replaces the included IPv4 addresses with IPv6 addresses. An IPv4 address is 4 bytes long, while an IPv6 address is 16 bytes long. The result is that the translated message will be longer than the original message. DNS messages are usually sent using UDP. When transferring DNS messages over UDP, 512 bytes is the maximum DNS message length. The obvious approach when implementing a DNS ALG is to truncate translated DNS messages that exceed the maximum message length. However, some applications have problems with truncated DNS messages. Another possible solution is to remove resource records in the additional section of the DNS message and avoid truncation. --------------------------------------------------------------------- => By removing resource records in the additional section, problems with truncated DNS messages are avoided while essentially providing the same information in the DNS message. --------------------------------------------------------------------- 4. Security Considerations The security issues identified in [NAT-PT-ISSUES] are still unsolved. References [NAT-PT] Tsirtsis and Srisuresh, "Network Address Translation - Protocol Translation (NAT-PT)", RFC 2766, February 2000. [NAT-PT-ISSUES] Durand, "Issues with NAT-PT DNS ALG in RFC2766", January 2002. [NAT] Egevang and Francis, "The IP Network Address Translator (NAT)", RFC 1631, May 1994. Hallin Expires December 16, 2002 [Page 8] Internet-Draft NAT-PT DNS ALG solutions June 2002 Author's Address Per Hallin Telia Research AB SE-123 42 Farsta Sweden Phone: +46 8 713 81 08 EMail: Per.A.Hallin@telia.se Hallin Expires December 16, 2002 [Page 9] Internet-Draft NAT-PT DNS ALG solutions June 2002 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 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 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. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Hallin Expires December 16, 2002 [Page 10]