Network Working Group P. Hallin
Internet-Draft Telia Research AB
Expires: January 22, 2003 S. Satapati
Cisco Systems, Inc.
July 24, 2002
NAT-PT DNS ALG solutions
draft-hallin-natpt-dns-alg-solutions-01
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 January 22, 2003.
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 & Satapati Expires January 22, 2003 [Page 1]
Internet-Draft NAT-PT DNS ALG solutions July 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 . . . . . . . . . . . . . . . . . 7
2.4 IPv4 Address assignment for incoming connections (IPv4 to
IPv6) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3. Solutions to additional problems with the NAT-PT DNS ALG . . . 8
3.1 Reverse queries from IPv6 to IPv4 . . . . . . . . . . . . . . 8
3.2 Truncated DNS messages . . . . . . . . . . . . . . . . . . . . 8
3.3 DSTM cannot work with NAT-PT DNS-ALG . . . . . . . . . . . . . 9
4. Security Considerations . . . . . . . . . . . . . . . . . . . 9
References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 10
Full Copyright Statement . . . . . . . . . . . . . . . . . . . 11
Hallin & Satapati Expires January 22, 2003 [Page 2]
Internet-Draft NAT-PT DNS ALG solutions July 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. Some problems have been
recognized 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.
This problem arises due to stateless nature of DNS ALG. If DNS-ALG
had kept information about the (A) query, then incoming (A) reply
could be mapped to that query using previously stored information. A
DNS query contains {queryid, type}, which could be matched against
{replyid, type} in the DNS response. Additionally, the tuple
{srcaddr, dstaddr, sport, dport, proto} will be used for integrity
check. Once a DNS reply is received and processed, the associate
state will be removed by DNS ALG.
---------------------------------------------------------------------
=> NAT-PT DNS-ALG will match DNS replies with queries using the
minimal state stored when a DNS query, sent by IPv6-only nodes,
traversed NAT-PT. This will ensure that a host sending (A) query
will always recieve (A) reply, but not (AAAA) reply.
---------------------------------------------------------------------
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
Hallin & Satapati Expires January 22, 2003 [Page 3]
Internet-Draft NAT-PT DNS ALG solutions July 2002
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
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 sent 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 & Satapati Expires January 22, 2003 [Page 4]
Internet-Draft NAT-PT DNS ALG solutions July 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 |
| |--------------<-------------|
| translated AAAA reply | |
|--------------<-------------| |
Figure 2: Case two, the destination host is IPv4-only
A second alternative is to send both AAAA and A (translated AAAA)
queries simultaneously. The returning replies are analyzed. If the
answer section does not contain any address, DNS-ALG will silently
discard this reply. If the answer section contains an IPv6 address,
AAAA reply should be forwarded unchanged. If the first returned
reply is an IPv4 address, DNS-ALG will hold this for N time units,
after which the A reply will be translated to AAAA and forwarded.
Within the time interval of N units, if a AAAA answer is returned,
AAAA reply will be sent and (A) will be discarded. The exact value
of N is implementation dependant and is usually short enough not to
cause a DNS timeout at the IPv6-only client.
Hallin & Satapati Expires January 22, 2003 [Page 5]
Internet-Draft NAT-PT DNS ALG solutions July 2002
IPv6-only client NAT-PT IPv4 DNS server
| AAAA query | |
|------------->--------------|AAAA query (unchanged form) |
| |-------------->-------------|
| | |
| | A query |
| |-------------->-------------|
| | |
| | AAAA reply |
| |--------------<-------------|
|AAAA reply (unchanged form) | |
|-------------<--------------| |
| | |
| | A reply |
| (discard)---------<-------------|
Figure 3: Case one, the destination host is IPv6 enabled
IPv6-only client NAT-PT IPv4 DNS server
| AAAA query | |
|------------->--------------|AAAA query (unchanged form) |
| |-------------->-------------|
| | |
| | A query |
| |-------------->-------------|
| | |
| | A reply |
| (hold)------------<-------------|
| | |
| | AAAA reply |
| |--------------<-------------|
| translated AAAA reply | |
|--------------<-------------| |
| | |
| (discard A) |
Figure 4: 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.
---------------------------------------------------------------------
Hallin & Satapati Expires January 22, 2003 [Page 6]
Internet-Draft NAT-PT DNS ALG solutions July 2002
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
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 (The exception is when NAT-PT
is used in conjunction with DSTM).
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.
An alternate approach is that IPv6-only nodes will define a DNS
search list, where the IPv6 DNS server, reachable locally, is defined
first, and NAT-PT_PREFIX:ipv4_dns appears next in that order. IPv6-
only nodes that want to resolve AAAA (IPv6) names do not have to send
DNS queries through NAT-PT.
---------------------------------------------------------------------
=> 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
Hallin & Satapati Expires January 22, 2003 [Page 7]
Internet-Draft NAT-PT DNS ALG solutions July 2002
cautious about denial of service attacks, it is possible not to
configure 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
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 DNS-ALG will check for address binding to see if a
mapping exists between the IPv6 address in PTR query and an IPv4
address. If there is a mapping the PTR query will be translated to
IPv4. The translation works by replacing the string "IP6.INT" with
"IN-ADDR.ARPA" and replacing the IPv6 address with the bound 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.
---------------------------------------------------------------------
=> 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
Hallin & Satapati Expires January 22, 2003 [Page 8]
Internet-Draft NAT-PT DNS ALG solutions July 2002
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.
---------------------------------------------------------------------
3.3 DSTM cannot work with NAT-PT DNS-ALG
[INTERACTION] points out that DSTM mechanism will never be triggered
and used, because a host within the IPv6 domain will never receive a
DNS response that contains an "A" record.
Section 2.1 presents the same problem. Clearly, the proposed
solution will enable DSTM to work with NAT-PT DNS-ALG.
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.
[INTERACTION] Baudot, Egeland, Hahn, Kyheroinen and Zehl,
"Interaction of transition mechanisms", June 2002.
Hallin & Satapati Expires January 22, 2003 [Page 9]
Internet-Draft NAT-PT DNS ALG solutions July 2002
Authors' Addresses
Per Hallin
Telia Research AB
SE-123 42 Farsta
Sweden
Phone: +46 8 713 81 08
EMail: Per.A.Hallin@telia.se
Suresh Satapati
Cisco Systems, Inc.
San Jose, CA 95134
USA
EMail: satapati@cisco.com
Hallin & Satapati Expires January 22, 2003 [Page 10]
Internet-Draft NAT-PT DNS ALG solutions July 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 & Satapati Expires January 22, 2003 [Page 11]