Internet Engineering Task Force Alain Durand
INTERNET-DRAFT SUN Microsystems
January 29, 2003
Expires July 30, 2003
Issues with NAT-PT DNS ALG in RFC2766
<draft-durand-v6ops-natpt-dns-alg-issues-00.txt>
Status of this memo
This memo provides information to the Internet community. It does
not specify an Internet standard of any kind. This memo is in full
conformance with all provisions of Section 10 of RFC2026 [RFC2026].
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
Recent discussions on the need to translate or not between IPv4 and
IPv6 have brought a better understanding on the impact of tools like
NAT-PT [NAT-PT]. Several problems have been identified around the
DNS ALG functionality. An alternative solution that does not require
this DNS ALG for connections initiated by the IPv6 side has been
proposed. This memo aims at analyzing the pros and cons of both
solutions in that case. Connections initiated by the IPv4 side would
always require the help of a DNS-ALG and thus are not covered by this
memo.
1. Introduction: non DNS ALG solution
Note: This section does not provide a complete description of a non
DNS ALG solution for NAT-PT, but provide a quick overview of such a
solution to understand better the discussions of the next sections.
For outgoing connections, DNS-ALG is there in NAT-PT only to provide
a local prefix for the address mapping. If a well known prefix were
defined, there would be no need for DNS ALG. However, for incoming
connection, there is no other way than relying on a DNS ALG.
For outgoing connections, the consequences of this change would be
that end-nodes willing to use the translator would now have the
responsibility to do so, it would not happen automatically, and such
IPv6-only end nodes would have to be specifically programmed to do
so.
The way this is envision to work is that an IPv6 application running
on an IPv6 only node and willing to send a packet to an IPv4 address
will simply create an IPv6 destination address made by appending the
well-known prefix with the IPv4 address and send this one on the
wire.
For example, if the well known prefix is ::FFFE:0:0/96, then an IPv6
only application willing to send a packet to 1.2.3.4 will simply send
it to the IPv6 address ::FFFE:1.2.3.4.
IPv6->IPv4 translators would advertise that well-known prefix or
shorter version of it, to their local routing system (IGP).
Note: it is not expected that this prefix would be advertised outside
of the IGPs in the Internet default free zone. Thus, it could be
deployed within an enterprise or by an ISP for its residential
customers. It is neither expected nor really desirable to see this
prefix advertised in BGP peerings.
2. Issues around address selection in outgoing connections.
RFC2766 section 4.2 says:
"...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."
2.1 IPv6 node behind NAT-PT with DNS-ALG to dual stack node
Let's take the case of a node X behind a NAT-PT box trying to
communicate with a dual stack node Y outside of the NAT-PT domain for
which both A and AAAA addresses are published in the DNS. X will
issue a AAAA query for Y. The DNS contains a AAAA record for Y, this
AAAA record will be returned (unchanged) to X. The DNS contains also
a A record for Y, so the DNS-ALG, according to RFC2766, will create a
AAAA record to map it. So X will be returned 2 AAAA records, the
regular one and a translated one.
Later, RFC2766 says:
"NOTE: The prefix PREFIX::/96 is advertised in the stub domain by
the NAT-PT, and packets addressed to this PREFIX will be routed to
the NAT-PT. The pre-configured PREFIX only needs to be routable
within the IPv6 stub domain and as such it can be any routable
prefix that the network administrator chooses."
In practice, this means that PREFIX is taken out of X site /48
prefix.
So when X will initiate the connection to Y, it will apply the
address selection rules on the two IPv6 addresses returned by the
DNS. All things being equal, address selection will do a longest
prefix match, and as the translated IPv6 address of Y is in the same
prefix as X, this one will have precedence over the 'regular' IPv6
address of Y. As a consequence, X will choose a translated path to Y
when it could have chosen a direct native IPv6 path.
One possible way to avoid this issue is to require the DNS ALG to not
return the translated AAAA if a regular AAAA record actually exist.
There are some performance/time-out issues associated to this.
2.2 IPv6 node behind NAT-PT without DNS-ALG to dual stack node
Without DNS-ALG, node X will only receive the normal AAAA record for
Y and use IPv6 for its connection. Thus, with the well known prefix,
the problems described in section 2.1 do not exist.
2.3 Dual stack node behind NAT-PT with DNS-ALG to IPv4 node
RFC2766 clearly states that it is only applicable for IPv6-only
devices, but in practice, it is very difficult to know if nodes
behind a NAT-PT domain will be dual-stack or not. Most probably,
there will be a mixture of IPv4-only nodes, IPv6-only nodes and dual
stack nodes. Let's look at the case where a dual-stack node X behind
a NAT-PT + DNS-ALG box wants to communicate to an IPv4 only node Y
outside of the translator. Let's also make the hypothesis that X IPv4
address is a global one. This could be the case of an enterprise
network who is using IPv4 global address internally but, as those
IPv4 global addresses are a scarce resource, it has decided not to
allocate IPv4 global addresses to a new generation of devices. On
this network, there would be a mix of non-upgraded IPv4-only hosts,
dual-stack nodes and new generation IPv6-only devices.
When node X wants to initiate a communication with node Y, it will
typically issue DNS queries for AAAA and A records for Y. Y being
IPv4 only, only an A record exists in the DNS.
RFC2766 is not clear on how a DNS-ALG should treat answers to A
queries made by internal nodes. 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 a A record could
be returned a translated AAAA record instead.
Also, when X will ask for a AAAA (X is dual stack, so it would ask
for both), it would be returned a translated AAAA. So in any case, a
translated AAAA record will be returned to X. Nodes are usually
configure to prefer IPv6 over IPv4 when both are available, the
communication between X and Y will then takes place using the
translated path when the native IPv4 path would have worked.
A first approach to solve this problem is to make sure in the DNS-ALG
that if an A query is originating from inside, it would not be
translated. But, as the text above shows, this is good but not
enough. One step further would be for the DNS-ALG to recognize the
fact that X is asking for both A and AAAA, then infer that it should
be a query coming from a dual-stack host and not try to generate the
translated AAAA answer.
Another approach would be to make sure that only the IPv6-only device
will use the DNS-ALG, as recommended by RFC2766. This can be tricky
in practice and would require to isolate the IPv6-only device in one
part of the network.
2.4 Dual stack node behind NAT-PT without DNS-ALG to IPv4 node
Without DNS-ALG node X will only receive the normal A record for Y
and use IPv4 for its connection. Thus, with the well known prefix,
the problems described in section 2.3 do not exist.
3. Issues around DNS-sec
3.1 DNS-sec deployment with NAT-PR and DNS-ALG
Section 7.5 of RFC2766 says that NAT-PT is not deployable with DNS-
sec. Actually there is a way to make it work, which is to mandate
that each node behind the NAT-PT box use 'AD is secure' and trust the
local recursive DNS resolver to verify the DNS signatures. This
effectively prevents node from performing their own verification and
impose a trust model that may or may not be acceptable.
--------------------------------------------------------------------
=> DNS-sec is only deployable within a NAT-PT domain with DNS-ALG if
nodes are willing to delegate signature verifications to the local
recursive DNS server. This is changing the basic trust model provided
by DNSsec where end-nodes can (if they want to) perform themselves
the signature verifications.
--------------------------------------------------------------------
3.2 DNS-sec deployment with NAT-PT without DNS-ALG
In the absence of DNS-ALG, the DNS records are not modified and nodes
can, if they want, do the signature verifications themselves.
4. Scaling
4.1 Scaling NAT-PT with DNS-ALG
The way to scale NAT-PT with a DNS-ALG is for the DNS-ALG to allocate
different prefixes for different translators. The DNS-ALG could do
that in a round-robin way, used a pre-defined list or any kind of
hashing function. This would allow the DNS-ALG to monitor the
traffic and perform dynamic adjustments. This can be seen as dynamic
scaling.
4.2 Scaling NAT-PT without DNS-ALG
Without a DNS-ALG, the routing system perform the scaling of the
system. Each NAT-PT box can advertise only the subset of the IPv4
space it intend to cover. The maximum granularity one can achieve is
one box per IPv4 address destination. This can be seen as static
scaling.
5. Robustness
5.2 Robustness of NAT-PT with DNS-ALG
The DNS-ALG needs to actively monitor the NAT-PT boxes, to detect the
potential failure of one of them and remove it from the list of valid
translators. In practice, this means that the prefix associated to
that translator will not be used anymore by the DNS-ALG to respond to
DNS queries. For this to work, the DNS-ALG must set the TTL of the
DNS answer to zero and user applications are expected to respect that
TTL, i.e. not cache the name to address mapping, even for a short
time. With this system, new connections started after new name to
address resolution request intercepted by the DNS-ALG will work,
existing connections would hang and new connections that are using
the obsolete mapping would fail.
Note: this last point is important in this discussion. For example,
web browser that have to load different URLs pointing to the 'same'
place (e.g. many pictures on the same page) may be tempted to cache
the name to address resolution mapping even though the TTL is set to
zero.
5.3 Robustness of NAT-PT without DNS-ALG
Without the DNS ALG, the routing system can also provide robustness
to the system. NAT-PT boxes can be configured to announce the same
prefix, the routing system could either forward the traffic to the
nearest translator or perform some kind of load balancing between the
various boxes. If one of them dies, it stops announcing its prefix,
thus disappear automatically from the routing tables. new connections
will be redirected transparently to a new translator, but existing
connections would hang.
Instabilities in the routing system may end up sending packets
belonging to the same flow to different NAT-PT boxes. As NAT-PT is
stateful, this would end-up in broken connections. However, the IGP
announcing the routes to the NAT-PT boxes are usually rather stable,
so this may not be as big a problem as it first seems to be. Long
term connections would statistically be more affected than short term
connections.
6. Security considerations
Section 3. discusses the potential security impact of RFC2766 on
DNSsec.
7. Authors addresses
Alain Durand
SUN Microsystems, Inc
901 San Antonio Road
UMPK17-202
Palo Alto, CA 94303-4900
USA
Mail: Alain.Durand@sun.com
8. References
[NAT-PT] Tsirtsis, G., Srisuresh, P.,
"Network Address Translation - Protocol Translation (NAT-PT)",
RFC 2766, February 2000