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]