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

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