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

Versions: 00                                                            
Internet Engineering Task Force                             Alain Durand
INTERNET-DRAFT                                          SUN Microsystems
January 9, 2002
Expires July 10, 2002

                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 DNS over IPv6 transport have brought a better
   understanding on the impact of tools like NAT-PT (RFC2766).  Several
   problems have been identified around the DNS ALG functionality.

1. Issues related to NAT-PT DNS ALG for outgoing connections

1.1 AAAA answers for A queries

   Within an IPv6 NAT-PT domain, an application asking for an A record
   could be returned a translated AAAA record.

   RFC2766 section  4.2:

     "...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."

   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 a 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 AAAA record. Although this may not be a problem
   for simple IPv6 only applications, it may be a concern for applications
   that 'walk through' the DNS structure and may pas information to peers.

   This is in contradiction to the spirit of RFC2826 [RFC2826], "IAB
   Technical Comment on the Unique DNS Root" that says: "The property of
   uniqueness allows a symbol to be used unambiguously in any context,
   allowing the symbol to be passed on, referred to, and reused, while
   still preserving the meaning of the original use."

   => NAT-PT DNS ALG could break any application that passes records
   returned by the DNS to peers. In particular, this can add complexity
   to the operation of the DNS itself: zone transfer, operation in a
   mixed v4/v6 transport,...

   Second, the application has no way of knowing that the returned AAAA
   address is actually not a real IPv6 one, but a IPv4 translated one.
   It may be led to believe that it's a real one and think "It's IPv6,
   so it has End to End IP connectivity, thus there will be no NAT in
   the middle and I can use any IPv6 specific options"

   => Applications behind a NAT-PT DNS ALG may think they use IPv6 when
   they are actually using IPv6 + NAT-PT + IPv4.

1.2. Source Address Selection/Destination address ordering

   The translated AAAA record points to an IPv6 address that belongs to
   the site IPv6 prefix.

   Let's assume that an IPv6 node X within a NAT-PT domain wants to
   communicate with a dual-stack host Y on the public Internet. That
   host Y has published both IPv4 (A) and IPv6 (AAAA) addresses in the
   DNS.  When X will query A and AAAA for Y, it will be returned 2 AAAA.
   One will be the actual IPv6 address of Y and the other one the
   "translated" IPv4 address.  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 communication between a node within the NAT-PT domain and a
   external dual stack host will select the translated path over the
   native IPv6 path.

1.3. NAT-PT & IPv6 default router

   NAT-PT ALG makes the assumption that the DNS traffic goes through the
   NAT-PT box.

   This is OK is 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.

   => For NAT-PT to work correctly with DNS-ALG, it requires that the
   NAT-PT box be the only default IPv6 router of the NAT-PT domain.
   This works fine for small networks but raises some scalibity issues
   when applied to large networks or for networks with multiple exit

1.4. DNS-sec

   Section 7.5 of RFC2766 says that NAT-PT is not deployable with DNS-
   sec.  It would work if all the DNS resolution were done over IPv6,
   but in a mixed environment as described in draf-ietf-ngtrans-dns-
   ops-req-03.txt, this will be a problem.

   => DNS-sec is not deployable within a NAT-PT doamin with DNS-ALG.  If
   NAT-PT is widely deployed, it would become be a serious obstacle to
   the large scale deployment of DNS-SEC.

2. Issue is related to NAT-PT DNS ALG for incoming connections.

2.1. Incoming address pool exhaustion.

   Section 4.1 proposes to allocate an IPv4 address from the external
   pool each time a DNS lookup is perform from the outside for a
   internal name.  RFC2766 recognize this is a potential problem and
   says:  "address mappings for incoming sessions should time out to
   minimise the effect of denial of service attacks."

   => Even with short time out, it is very easy for an attacker to
   create a DoS attack just by repetitively querying the DNS for all
   known internal domain names.  As the minimum DNS timeouts are usually
   in seconds, such DOS would be much more devastating as simple
   flooding as it only requires very limited bandwith to be effective.

3. Security considerations

   Section 1.4 and 2.1 discuss the potential security impact of RFC2766.

4 Authors addresses

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

5. References

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

   [RFC2826] IAB,
             "IAB Technical Comment on the Unique DNS Root",
             RFC 2826, May 2000