[Search] [pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00                                                            
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

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
   The list of Internet-Draft Shadow Directories can be accessed at


   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

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

   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

   For example, if the well known prefix is ::FFFE:0:0/96, then an IPv6
   only application willing to send a packet to will simply send
   it to the IPv6 address ::FFFE:

   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

   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

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

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

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

6. Security considerations

   Section 3. discusses the potential security impact of RFC2766 on

7. Authors addresses

   Alain Durand
   SUN Microsystems, Inc
   901 San Antonio Road
   Palo Alto, CA 94303-4900
   Mail: Alain.Durand@sun.com

8. References

   [NAT-PT] Tsirtsis, G., Srisuresh, P.,
            "Network Address Translation - Protocol Translation (NAT-PT)",
            RFC 2766, February 2000