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

Versions: 00 01                                                         
Network Working Group                                            M. Endo
Internet-Draft                                                 H. Miyata
Intended status: Informational                   Yokogawa Electric Corp.
Expires: April 4, 2009                                   October 1, 2008


                     Translator Friendly DNS Proxy
                    draft-endo-v6ops-dnsproxy-01.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   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 April 4, 2009.


















Endo & Miyata             Expires April 4, 2009                 [Page 1]


Internet-Draft        Translator Friendly DNS Proxy         October 2008


Abstract

   This document describes the DNS Proxy that is separated from NAT-PT
   [RFC2766].  NAT-PT was designed to work with DNS Application Level
   Gateway.  However [RFC4966] pointed out DNS related issues, and
   [RFC2766] was changed to historical state.  This document attempts to
   DNS Proxy specification, removing dependency on NAT-PT as well as
   resolving problems pointed in [RFC4966].


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  5
     2.1.  Application Level Gateway (ALG)  . . . . . . . . . . . . .  5
     2.2.  Dummy Prefix . . . . . . . . . . . . . . . . . . . . . . .  5
     2.3.  Requirements Language  . . . . . . . . . . . . . . . . . .  5
   3.  Conceptual Model . . . . . . . . . . . . . . . . . . . . . . .  6
     3.1.  Dummy Prefix List  . . . . . . . . . . . . . . . . . . . .  7
     3.2.  IPv4 Address Pool  . . . . . . . . . . . . . . . . . . . .  7
     3.3.  Address Mapping Table  . . . . . . . . . . . . . . . . . .  7
     3.4.  RR Translation Engine  . . . . . . . . . . . . . . . . . .  8
     3.5.  Translator Dispatcher  . . . . . . . . . . . . . . . . . .  9
     3.6.  Translator Interface . . . . . . . . . . . . . . . . . . .  9
   4.  Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
     4.1.  Translator Independency  . . . . . . . . . . . . . . . . . 11
     4.2.  Transport Independency . . . . . . . . . . . . . . . . . . 11
     4.3.  Translation Mode . . . . . . . . . . . . . . . . . . . . . 11
     4.4.  Load Balancing of Translator . . . . . . . . . . . . . . . 11
     4.5.  Dynamic Address Mapping Functionality  . . . . . . . . . . 11
     4.6.  Host Implementation  . . . . . . . . . . . . . . . . . . . 11
     4.7.  Solution for RFC4966 . . . . . . . . . . . . . . . . . . . 12
       4.7.1.  3.1 Network Topology Constraints Implied by NAT-PT . . 12
       4.7.2.  3.2 scalability and single point of failure  . . . . . 12
       4.7.3.  4.1 Address Selection Issues when Communicating
               with Dual-Stack End-Hosts  . . . . . . . . . . . . . . 12
       4.7.4.  "4.3 Inappropriate Translation of Response to A
               Queries" . . . . . . . . . . . . . . . . . . . . . . . 13
   5.  RR Translation Behavior  . . . . . . . . . . . . . . . . . . . 14
     5.1.  AAAA query processing  . . . . . . . . . . . . . . . . . . 14
     5.2.  DNS server has AAAA resource records . . . . . . . . . . . 14
     5.3.  DNS server has only A resource records . . . . . . . . . . 14
     5.4.  A query processing . . . . . . . . . . . . . . . . . . . . 16
       5.4.1.  DNS server has A resource records  . . . . . . . . . . 16
       5.4.2.  DNS server has only AAAA resource records  . . . . . . 16
     5.5.  Translation Mode . . . . . . . . . . . . . . . . . . . . . 17
     5.6.  PTR query (Optional) . . . . . . . . . . . . . . . . . . . 18
       5.6.1.  IP6.ARPA domain  . . . . . . . . . . . . . . . . . . . 18



Endo & Miyata             Expires April 4, 2009                 [Page 2]


Internet-Draft        Translator Friendly DNS Proxy         October 2008


       5.6.2.  IN-ADDR.ARPA domain  . . . . . . . . . . . . . . . . . 19
     5.7.  Other Resource Record Types  . . . . . . . . . . . . . . . 19
   6.  Limitation . . . . . . . . . . . . . . . . . . . . . . . . . . 20
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 21
     7.1.  DNSSEC . . . . . . . . . . . . . . . . . . . . . . . . . . 21
       7.1.1.  The EDNS Original Resource Record option . . . . . . . 21
       7.1.2.  Usage of the ORR option  . . . . . . . . . . . . . . . 22
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 24
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 25
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 25
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 25
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26
   Intellectual Property and Copyright Statements . . . . . . . . . . 27






































Endo & Miyata             Expires April 4, 2009                 [Page 3]


Internet-Draft        Translator Friendly DNS Proxy         October 2008


1.  Introduction

   Many IPv4-to-IPv6 translation technologies are proposed.  The address
   mapping technology is one of the most important technologies to use
   IPv4-to-IPv6 translation technologies.  Some IPv4-to-IPv6 translation
   technologies select a DNS Proxy as the address mapping technology.

   NAT-PT [RFC2766], one of IPv4-to-IPv6 translation technologies, was
   designed.  However NAT-PT had some issues that [RFC4966] describes.
   So, it was changed to historical state by [RFC4966].

   Because DNS Proxy is located in NAT-PT, DNS Proxy related issues that
   [RFC4966] describes happened.  In other words, if DNS Proxy is
   independent from NAT-PT, some issues will be solved.

   This document proposes the DNS Proxy that is separated from NAT-PT.
   Proposed DNS Proxy isn't implemented in the host, but it co-exists
   with NAT-PT.  There are some approaches that DNS Proxy is implemented
   in hosts.  But, it is too hard to adopt DNS Proxy function, because
   many IPv6 and IPv4 hosts are already deployed.  And it requires
   functionality discovering translators.

   Proposed DNS Proxy requires a relationship with translators to map
   addresses dynamically.  This document assumes a design to work with
   translators, which have an interface to collaborate with Application
   Level Gateways or Proxies.

   The purpose of this document is to attempt a translator friendly DNS
   Proxy and to clear requirements for DNS Proxy.






















Endo & Miyata             Expires April 4, 2009                 [Page 4]


Internet-Draft        Translator Friendly DNS Proxy         October 2008


2.  Terminology

   The majority of terms used in this document are borrowed almost as is
   from [SNATPT].  The following lists terms specific to this document.

2.1.  Application Level Gateway (ALG)

   Application Level Gateway (ALG) is an application specific agent that
   allows an IPv6 node to communicate with an IPv4 node and vice versa.
   Some applications carry network addresses in payloads.  The
   translator such as NAT-PT is application unaware and doesn't snoop
   the payload.  ALG could work in conjunction with NAT-PT to provide
   support for many such applications.

2.2.  Dummy Prefix

   The IPv6 Prefix to map IPv4 address to IPv6 address.  And a length of
   the prefix is 96 bit.  In this document, Dummy Prefix is represented
   as PREFIX or PREFIX::/96 when IPv6 address or prefix is described.
   The prefix PREFIX::/96 is advertised in an IPv6 network by the NAT-PT
   gateway, and packets addressed to this PREFIX will be routed to the
   NAT-PT gateway.  This PREFIX is configured for each NAT-PT gateway,
   and DNS Proxy will use it during translating from A RR to AAAA RR.

2.3.  Requirements Language

   The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
   SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this
   document, are to be interpreted as described in [RFC2119].






















Endo & Miyata             Expires April 4, 2009                 [Page 5]


Internet-Draft        Translator Friendly DNS Proxy         October 2008


3.  Conceptual Model

   This section describes the conceptual model for proposed DNS Proxy.
   Fig.3.1 shows a block diagram of proposed DNS Proxy.  DNS Proxy has
   important components "Dummy Prefix List", "IPv4 Address Pool" and
   "Address Mapping Table".  "Dummy Prefix List" and "IPv4 Address Pool"
   store addresses for mapping addresses.  "Address Mapping Table" has
   entries of mapped addresses.

   This document shows just an example.  An implementation is not
   required to have them in the exact from described here, so long as
   its external behavior is consistent with that described in this
   document.


   +----------------------------------------------+
   | DNS Proxy                                    |
   |                      +-------------------+   |
   |           +--------->| Dummy Prefix List |   |
   |           |          +-------------------+   |
   |           |                                  |
   |           |          +-------------------+   |
   |           | +------->| IPv4 Address Pool |   |
   |           | |        +-------------------+   |
   |           | |                                |
   |   +------------+                             |  +------------+
   |   | Translator |<------------------------------>| Translator |
   |   | Dispatcher |                             |  | Interface  |
   |   +------------+                             |  +------------+
   |        ^    |                                |
   |        |    |    +-----------------------+   |
   |        |    +--->| Address Mapping Table |   |
   |        |         +-----------------------+   |
   |        |                                     |
   |        |                                     |
   |   +--------------------------------------+   |
   |   |         RR Translation Engine        |   |
   |   +--------------------------------------+   |
   |        ^ |                                   |
   +--------|-|-----------------------------------+
   +--------|-|-----------------------------------+
   |        | |     TCP/UDP Stack                 |
   +--------|-|-----------------------------------+
            | v
        DNS Messages

   Fig. 3.1 DNS Proxy Conceptual Model




Endo & Miyata             Expires April 4, 2009                 [Page 6]


Internet-Draft        Translator Friendly DNS Proxy         October 2008


3.1.  Dummy Prefix List

   Dummy Prefix List has dummy prefixes that are assigned to each
   translator.  DNS Proxy selects a prefix from it, and DNS Proxy maps
   an IPv4 address to an IPv6 address with selected prefix.

   The entry of this list MUST have following information.


         IPv6 Prefix:
           The IPv6 prefix assigned to one translator.  This prefix is
           used to map an IPv4 address to an IPv6 address.


3.2.  IPv4 Address Pool

   IPv4 Address Pool stores IPv4 addresses that are assigned to each
   translator.  DNS Proxy selects an IPv4 address from it, and DNS Proxy
   maps an IPv6 address to selected IPv4 address.

   The entry of this pool MUST have following information.


         IPv4 Address:
           This IPv4 address is used to map to an IPv6 address.

         Address Status:
           This information indicates a status of this IPv4 address.
           The status has two condition "Un-Mapped" and "Mapped".  If
           Un-mapped status, DNS Proxy can select this entry to map.
           Otherwise DNS Proxy cannot do it.

           Un-mapped:
             This IPv4 address is not mapped.
           Mapped:
             This IPv4 address is already mapped.


3.3.  Address Mapping Table

   Address Mapping Table has mapped addresses.  When DNS Proxy maps an
   IPv5 address to an IPv6 address, DNS Proxy adds a new entry to
   Address Mapping Table.  When DNS Proxy maps an IPv6 address to an
   IPv4 address, a new entry is not added because a mapped IPv6 address
   is globally unique.






Endo & Miyata             Expires April 4, 2009                 [Page 7]


Internet-Draft        Translator Friendly DNS Proxy         October 2008


   The entry of this table MUST have following information.


         IPv4 Address:
           This IPv4 address is used to map to an IPv6 address.

         IPv6 Address:
           IPv6 address that is mapped to above IPv4 address.

         Expire Time:
           Lifetime for this entry.  If it is expired, this entry will
           be released.  Then an IPv4 address included in this entry
           will be re-used.


3.4.  RR Translation Engine

   Functionalities of RR Translation Engine are forwarding DNS messages
   and translating DNS messages.

   Target types of resource records that RR Translation Engine can
   translate are A, AAAA and PTR resource record.  Regarding A6 resource
   record type, because [RFC3363] changed to experimental status,
   translating A6 resource record isn't needed.  Regarding PTR resource
   record type, RR Translation Engine only translates "IN-ADDR.ARPA" and
   "IP6.ARPA" domain.  In other resource record types or other domains
   of PTR record case, RR Translation Engine SHOULD just forward DNS
   messages to DNS server or clients.

   In translating resource records, RR Translation Engine sends DNS
   query to DNS server sequentially and sends only one DNS response to
   client.  This behavior is already described by [RFC4966] section 4.1.

   By default, DNS Proxy forwards unchanged DNS query to DNS server.
   Then if DNS server responds with no answer, DNS Proxy translates a
   query type and re-send DNS query to DNS server.  Although DNS Proxy
   responds with real IPv6 addresses, client that are attached to an
   IPv6 network which has no global IPv6 connectivity cannot
   communicate.  To support this case, RR Translation Engine SHOULD
   translate a query type when DNS Proxy forwards a first DNS query, and
   a behavior of RR Translation Engine SHOULD be configurable.

   When RR Translation Engine decides to need to translate a resource
   record, it will make a request to Translator Dispatcher for mapping
   addresses.  Translator Dispatcher selects the Dummy Prefix or IPv4
   address.  In case that translating from A to AAAA records, RR
   Translation Engine creates AAAA records with IPv6 address that is
   combined Translator Dispatcher selected Dummy Prefix and received A



Endo & Miyata             Expires April 4, 2009                 [Page 8]


Internet-Draft        Translator Friendly DNS Proxy         October 2008


   record.  In case that translating from AAAA to A records, RR
   Translation Engine creates A record with IPv4 address that Translator
   Dispatcher selected.

   Especially in translating from AAAA to A records, RR Translation
   Engine must change TTL value for translated records to shorter.
   Because IPv4 address will be re-used, it avoids caching records in
   clients.

   The DNS Proxy described by [RFC2766] is stateless DNS Proxy.
   According to [RFC4966] section 4.43, such a DNS Proxy can translate
   DNS response messages that need not be translated.  So, proposed DNS
   Proxy MUST be stateful DNS Proxy.  If RR Translation Engine received
   only DNS response message, RR Translation Engine MUST discard it.

   The behavior of DNS Proxy MUST NOT depend on transport or network
   protocol.  DNS Proxy MUST decide own behavior according to the
   received DNS query.

3.5.  Translator Dispatcher

   Translator Dispatcher manages Address Mapping Table.  With depend on
   the request from RR Translation Engine, Translator Dispatcher selects
   an address from Dummy Prefix List or IPv4 Address Mapping Pool and
   maps selected address.

   To map an IPv4 address to an IPv6 address, Translator Dispatcher
   searches Address Mapping Table.  If the table has entry that includes
   an IPv6 address which is mapped an IPv4 address, Translator
   Dispatcher answers the IPv4 address that the entry has.  Otherwise
   Translator Dispatcher selects an IPv4 address from IPv4 Address Pool,
   maps selected IPv4 address and creates a new entry.  If a new entry
   was created, Translator Dispatcher must inform a new mapping to a
   translator through Translator Interface.  By doing that, dynamically
   address mapping is possible.

   To map an IPv6 address to an IPv4 address, Translator Dispatcher
   selects a dummy prefix from Dummy Prefix List.  Selected dummy prefix
   and an IPv4 address are combined.  A translator like a [SNATPT] or
   TRT ([RFC3142]) can treat a packet destinated to dummy prefix as
   packet that is translate.  So, informing a new mapping to a
   translator is not needed.

3.6.  Translator Interface

   The communication between DNS Proxies and translators is done through
   this interface.  In this document, dynamic address mapping uses the
   interface.



Endo & Miyata             Expires April 4, 2009                 [Page 9]


Internet-Draft        Translator Friendly DNS Proxy         October 2008


   The detail is TBD.


















































Endo & Miyata             Expires April 4, 2009                [Page 10]


Internet-Draft        Translator Friendly DNS Proxy         October 2008


4.  Benefits

4.1.  Translator Independency

   Proposed DNS Proxy does not depend on translators.  So, this DNS
   Proxy can cooperate with not only [SNATPT] but also other translation
   technologies.

4.2.  Transport Independency

   The behavior of Proposed DNS Proxy does not depend on a transport or
   network protocol.  Because the resolver of some client implementation
   can only support IPv4, in transition period, DNS Proxy must support
   such kind of clients.  Because of transport independency, proposed
   DNS Proxy can be attached to any topology.  And one more benefit is
   that the implementation will be simple.

4.3.  Translation Mode

   By translating query type at forwarding DNS query, DNS Proxy can
   control type of addresses that is returned to clients.  For example,
   if DNS Proxy is attached to IPv6 only network, which has no IPv6
   global connectivity, by DNS Proxy translate AAAA query type received
   from client to A query type forcibly, client can receive mapped IPv6
   address.  Because proposed DNS Proxy can change behavior of
   translating DNS query, proposed DNS Proxy can support various
   network.

4.4.  Load Balancing of Translator

   Translator Dispatcher selects an address arbitrary from Dummy Prefix
   List or IPv4 Address Pool to map an address.  Addresses that are
   included in Dummy Prefix List or IPv4 Address Pool are assigned to
   translators.  In other words, selecting an address means selecting a
   translator.  So, proposed DNS Proxy can support load balancing for
   translators.

4.5.  Dynamic Address Mapping Functionality

   Proposed DNS Proxy can map an IPv4 address to an IPv6 address
   dynamically.  It is very useful functionality for from IPv4 to IPv6
   communication.

4.6.  Host Implementation

   This document requires no changes to host implementation.





Endo & Miyata             Expires April 4, 2009                [Page 11]


Internet-Draft        Translator Friendly DNS Proxy         October 2008


4.7.  Solution for RFC4966

   Proposed DNS Proxy will be solutions following problems described by
   [RFC4966].

4.7.1.  3.1 Network Topology Constraints Implied by NAT-PT

   Because proposed DNS Proxy is separated from NAT-PT, the problem that
   [RFC4966] describes will not happen.

4.7.2.  3.2 scalability and single point of failure

   Because proposed DNS Proxy is separated from NAT-PT, the problem that
   [RFC4966] describes will not happen.  But redundancy mechanism for
   DNS Proxy is needed.

4.7.3.  4.1 Address Selection Issues when Communicating with Dual-Stack
        End-Hosts

   RFC4966 says

      If the query relates to a dual-stack host, the query will return
      both the native IPv6 address(es) and the translated IPv4
      address(es) in AAAA RRs.  Without additional information, the IPv6
      host address selection may pick a translated IPv4 address instead
      of selecting the more appropriate native IPv6 address.  Under some
      circumstances, the address selection algorithms [RFC3484] will
      always prefer the translated address over the native IPv6 address;
      this is obviously undesirable.

   Proposed DNS Proxy does not reply both the real IPv6 addresses and
   the translated IPv4 addresses in one DNS response.  So the problem
   will not happen.

   RFC4966 also says

   o  The DNS client may timeout the query if it doesn't receive a
      response in time.  This is more likely than for queries not
      passing through a DNS ALG because the NAT-PT may have to make two
      separate, sequential queries of which the client is not aware.  It
      may be possible to reduce the response time by sending the two
      queries in parallel and ignoring the result of the A query if the
      AAAA returns one or more addresses.  However, it is still
      necessary to delay after receiving the first response to determine
      if a second is coming, which may still trigger the DNS client
      timeout.

   The timeout may happen.  However, actually, almost DNS resolutions



Endo & Miyata             Expires April 4, 2009                [Page 12]


Internet-Draft        Translator Friendly DNS Proxy         October 2008


   are not timeout.  Furthermore, adopting DNS cache to DNS Proxy can
   reduce the timeout.

4.7.4.  "4.3 Inappropriate Translation of Response to A Queries"

   Because proposed DNS Proxy is stateful DNS Proxy, the problem will
   not happen.












































Endo & Miyata             Expires April 4, 2009                [Page 13]


Internet-Draft        Translator Friendly DNS Proxy         October 2008


5.  RR Translation Behavior

   Proposed DNS Proxy does not intercept any DNS messages.  So, to use
   this DNS Proxy, this DNS Proxy MUST be specified as DNS resolver in
   client systems.  Because proposed DNS Proxy is separated from the
   transport layer, there is no difference of processing a DNS AAAA
   query between from IPv6 network and from IPv4 network.

5.1.  AAAA query processing

   This section describes a behavior when DNS Proxy received AAAA query.
   There is assumption that DNS server to which DNS Proxy forwards DNS
   queries was pre-configured in DNS Proxy.

5.2.  DNS server has AAAA resource records

   This behavior is same as DNS Cache servers.  If DNS server has native
   resource records which clients requested, DNS Proxy should just
   forward DNS messages.

   There are host X and client in the IPv6 network.  The IPv6 address of
   host X is registered in DNS server.  If client want to communicate
   with host X, the client will send AAAA query to DNS Proxy.  DNS Proxy
   will receive AAAA query from the client, then DNS Proxy will forward
   the query to DNS server without changing.  DNS server will respond
   IPv6 address of X to DNS Proxy.  The DNS response message that DNS
   Proxy received has IPv6 address for X, and then DNS Proxy will sends
   DNS response message to the client.


   Client                     DNS Proxy                   DNS Server
     |         AAAA query         |                            |
     |------------->--------------|  AAAA query (unchanged)    |
     |                            |-------------->-------------|
     |                            |                            |
     |                            |         AAAA reply         |
     |   AAAA reply (unchanged)   |--------------<-------------|
     |--------------<-------------|                            |
     |                            |                            |

5.3.  DNS server has only A resource records

   This is a basic behavior of proposed DNS Proxy.  If DNS Proxy decides
   that DNS server does not have resource records which clients
   requested, DNS Proxy will translate DNS messages.

   There is IPv4 only host Z and IPv6 client.  The IPv4 address of host
   Z is registered in DNS server.  If client want to communicate with



Endo & Miyata             Expires April 4, 2009                [Page 14]


Internet-Draft        Translator Friendly DNS Proxy         October 2008


   host Z using IPv6, the client will send AAAA query to DNS Proxy.  DNS
   Proxy will receive AAAA query from the client, then DNS Proxy will
   forward the query to DNS server without changing.  Because DNS server
   does not have IPv6 address for host Z, DNS server will send DNS
   response with no address.  When DNS Proxy received DNS response
   without addresses, DNS Proxy will translate DNS query type to A
   record, and send translated DNS query(A) to DNS server.  DNS server
   will respond IPv4 address of Z to DNS Proxy.  The DNS response
   message that DNS Proxy received has IPv4 address for Z, and then DNS
   Proxy will translate IPv4 address that is contained DNS response
   message to IPv6 address.  After translation, DNS Proxy will send
   translated DNS response message to the client.

   Regarding address mapping, DNS Proxy selects the prefix from Dummy
   Prefix List, and appends IPv4 address that is included in DNS
   response message to last 32 bit of selected prefix.  The information
   of address mapping does not needed to inform to translators, because
   translators can treat packets that destinated to Dummy Prefix as
   packets that will be translated.


   Client                     DNS Proxy                   DNS Server
     |         AAAA query         |                            |
     |------------->--------------|  AAAA query (unchanged)    |
     |                            |-------------->-------------|
     |                            |                            |
     |                            |         AAAA reply         |
     |                            |--------------<-------------|
     |                            |                            |
     |                            |  A query (translated)      |
     |                            |-------------->-------------|
     |                            |                            |
     |                            |          A reply           |
     |                            |--------------<-------------|
     |   translated AAAA reply    |                            |
     |--------------<-------------|                            |
     |                            |                            |

   NOTE:

      The above described behavior is initially introduced by Jun-ichiro
      itojun HAGINO and Kazu Yamamoto at 47th IETF in 2000.  And while
      being improved and extended the idea is widely deployed with not
      only with TRT [RFC3142] but also NAT-PT [RFC2766] like
      implementation introduced as [SNATPT].






Endo & Miyata             Expires April 4, 2009                [Page 15]


Internet-Draft        Translator Friendly DNS Proxy         October 2008


5.4.  A query processing

   This section describes a behavior when DNS Proxy received A query.
   The process of A query is similar process of AAAA query.

5.4.1.  DNS server has A resource records

   This behavior is same as that section 5.x.y described.  The
   difference is a record type of DNS query requested.

   There are host X and client in the IPv4 network.  The IPv4 address of
   host X is registered in DNS server.  If client want to communicate
   with host X, the client will send A query to DNS Proxy.  DNS Proxy
   will receive A query from the client, and then DNS Proxy will forward
   the query to DNS server without changing.  DNS server will respond
   IPv4 address of X to DNS Proxy.  The DNS response message that DNS
   Proxy received has IPv4 address for X, and then DNS Proxy will sends
   DNS response message to the client.


   Client                     DNS Proxy                   DNS Server
     |            A query         |                            |
     |------------->--------------|     A query (unchanged)    |
     |                            |-------------->-------------|
     |                            |                            |
     |                            |            A reply         |
     |                            |--------------<-------------|
     |      A reply (unchanged)   |                            |
     |--------------<-------------|                            |
     |                            |                            |

5.4.2.  DNS server has only AAAA resource records

   This is a basic behavior of proposed DNS Proxy.  If DNS Proxy decides
   that DNS server does not have resource records which clients
   requested, DNS Proxy will translate DNS messages.

   There is IPv6 host Z and IPv4 client.  The IPv6 address of host Z is
   registered in DNS server.  If client want to communicate with host Z
   using IPv4, the client will send A query to DNS Proxy.  DNS Proxy
   will receive A query from the client, and then DNS Proxy will forward
   the query to DNS server without changing.  Because DNS server does
   not have IPv4 address for host Z, DNS server will send DNS response
   with no address.  When DNS Proxy received DNS response without
   addresses, DNS Proxy will translate DNS query type to AAAA record,
   and send translated DNS query (AAAA) to DNS server.  DNS server will
   respond IPv6 address of Z to DNS Proxy.  The DNS response message
   that DNS Proxy received has IPv6 address for Z, and then DNS Proxy



Endo & Miyata             Expires April 4, 2009                [Page 16]


Internet-Draft        Translator Friendly DNS Proxy         October 2008


   will translate IPv6 address that is contained DNS response message to
   IPv4 address.  After translation, DNS Proxy will send translated DNS
   response message to the client.

   Regarding mapping addresses, DNS Proxy selects the IPv4 from IPv4
   Address Pool, and maps IPv4 address to an IPv6 address that is
   included in DNS response message.  After mapping addresses, DNS Proxy
   MUST inform pair of address to translator.  After exchanging DNS
   messages, the client will send packets to the IPv4 address that DNS
   Proxy mapped.  In that time, if translator does not known the mapping
   information, any packets that the client sent will not be translated
   by a translator.


   Client                     DNS Proxy                   DNS Server
     |            A query         |                            |
     |------------->--------------|     A query (unchanged)    |
     |                            |-------------->-------------|
     |                            |                            |
     |                            |            A reply         |
     |                            |--------------<-------------|
     |                            |                            |
     |                            |  AAAA query (translated)   |
     |                            |-------------->-------------|
     |                            |                            |
     |                            |       AAAA reply           |
     |                            |--------------<-------------|
     |     translated A reply     |                            |
     |--------------<-------------|                            |
     |                            |                            |

5.5.  Translation Mode

   By default, proposed DNS Proxy SHOULD just forward DNS query that DNS
   Proxy received first time in the DNS session.  It avoids exhaustion
   of memory and address/port pool resources on the translators and the
   DNS Proxy.  For example, there is an IPv6 network that does not have
   any global connectivity.  In such case, if the client received native
   IPv6 address from DNS Proxy, the client cannot communicate.  To solve
   them, the translation mode of DNS Proxy SHOULD be configurable.  If a
   configuration is that DNS Proxy have priority to return mapped
   address, DNS Proxy will translate DNS AAAA query that the client sent
   to DNS A query, and forward DNS server.








Endo & Miyata             Expires April 4, 2009                [Page 17]


Internet-Draft        Translator Friendly DNS Proxy         October 2008


   Client                     DNS Proxy                   DNS Server
     |         AAAA query         |                            |
     |------------->--------------|  A query (translated)      |
     |                            |-------------->-------------|
     |                            |                            |
     |                            |          A reply           |
     |                            |--------------<-------------|
     |   translated AAAA reply    |                            |
     |--------------<-------------|                            |
     |                            |                            |

5.6.  PTR query (Optional)

   The translation for PTR resource records is not mandate
   functionality.  But, it is useful feature for network operations.
   Domains that Proposed DNS Proxy supports are IP6.ARPA and IN-
   ADDR.ARPA domains.  If DNS Proxy receive PTR query that has other
   domain, DNS Proxy SHOULD forward it without changing.

5.6.1.  IP6.ARPA domain

   When DNS Proxy received PTR query for IP6.ARPA domain, DNS Proxy will
   search own Dummy Prefix List.  If the prefix included in IP6.ARPA
   domain is not exist in Dummy Prefix List, DNS Proxy will just forward
   the query to DNS server.  If exist, DNS Proxy will translate QNAME
   field to IN-ADDR.ARPA domain, and send translated query to DNS
   server.  When DNS Proxy received DNS response that DNS server
   responded, DNS Proxy would restore QNAME field to IP6.ARPA domain,
   and send DNS response to the client.


   Client                     DNS Proxy                   DNS Server
     |[translated IPv6].IP6.ARPA  |                            |
     |         PTR query          |                            |
     |------------->--------------| <IPv4>.IN-ADDR.ARPA        |
     |                            |   PTR query (translated)   |
     |                            |-------------->-------------|
     |                            |                            |
     |                            | <IPv4>.IN-ADDR.ARPA PTR    |
     |                            |       Z.example.com reply  |
     |                            |--------------<-------------|
     |[translated IPv6].IP6.ARPA  |                            |
     |   PTR Z.example.com reply  |                            |
     |--------------<-------------|                            |
     |                            |                            |






Endo & Miyata             Expires April 4, 2009                [Page 18]


Internet-Draft        Translator Friendly DNS Proxy         October 2008


5.6.2.  IN-ADDR.ARPA domain

   When DNS Proxy received PTR query for IN-ADDR.ARPA domain, DNS Proxy
   will search own Address Mapping Table.  If the IPv4 address included
   in IN-ADDR.ARPA domain is not exist in Address Mapping Table, DNS
   Proxy will just forward the query to DNS server.  If exist, DNS Proxy
   will translate QNAME field to IP6.ARPA domain for IPv6 address that
   entry of Address Mapping Table has, and send translated query to DNS
   server.  When DNS Proxy received DNS response that DNS server
   responded, DNS Proxy would restore QNAME field to IN-ADDR.ARPA
   domain, and send DNS response to the client.


   Client                     DNS Proxy                   DNS Server
     |[mapped IPv4].IN-ADDR.ARPA  |                            |
     |         PTR query          |                            |
     |------------->--------------| <IPv6>.IP6.ARPA            |
     |                            |   PTR query (translated)   |
     |                            |-------------->-------------|
     |                            |                            |
     |                            | <IPv6>.IP6.ARPA PTR        |
     |                            |       Y.example.com reply  |
     |                            |--------------<-------------|
     |[mapped IPv4].IN-ADDR.ARPA  |                            |
     |   PTR Y.example.com reply  |                            |
     |--------------<-------------|                            |
     |                            |                            |

5.7.  Other Resource Record Types

   If DNS Proxy received queries for resource record types that this
   document does not described, DNS Proxy SHOULD forward queries to DNS
   server.


















Endo & Miyata             Expires April 4, 2009                [Page 19]


Internet-Draft        Translator Friendly DNS Proxy         October 2008


6.  Limitation

   There are some limitations when DNS Proxy maps an IPv4 address to an
   IPv6 address dynamically.

   When DNS Proxy will map an IPv4 address dynamically, DNS Proxy MUST
   inform the pair of addresses.  And timing of releasing the mapping
   should be concerned.  Because DNS Proxy only manages DNS exchange,
   DNS Proxy cannot care about communications.  It is require exchanging
   information of sessions that translators operate.  The detail of
   relationship between DNS Proxy and translator is out of scope of this
   document.

   Another limitation is TTL of resource record.  DNS Proxy SHOULD
   change the TTL value for translated resource records to shorter.
   IPv4 addresses that contained in IPv4 Address Pool will re-used,
   because address space of IPv4 is less than IPv6's one.  So it avoids
   to cache translated record in clients.

































Endo & Miyata             Expires April 4, 2009                [Page 20]


Internet-Draft        Translator Friendly DNS Proxy         October 2008


7.  Security Considerations

7.1.  DNSSEC

   This DNS Proxy translates resource records, so that nodes
   implementing DNSSEC may ignore the translated records.  Due to avoid
   this issue, there are two solutions.  One is that the DNS Proxy
   behaves like a secure DNS server.  The DNS proxy, which behaves like
   a secure DNS server, is same as a Man-in-the-Middle model.  It
   requires a verifying method for the DNS Proxy.  Another one is that
   clients, which initiate a DNS communication, validate responses by
   themselves.  This solution requires modification for DNSSEC
   implementation of clients.  In this document proposes the 2nd
   solution.  We need more discussion about this issue, because other
   drafts like a [NAT64] propose alternative solutions.

7.1.1.  The EDNS Original Resource Record option

   EDNS [RFC2671] defines a mechanism to add option to the DNS [RFC1035]
   protocol.  This secsion defines the Original Resource Record (ORR)
   option that indicate the answer section includes translated RRs.

   The format of the ORR option is:


       0   1   2   3   4   5   6   7   8   9  10  11  12  13  14  15
     +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
     |                          OPTION-CODE                          |
     +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
     |                         OPTION-LENGTH                         |
     +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
     |                                                               |
     /                          OPTION-DATA                          /
     |                                                               |
     +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

   The fields are defined as follows:

   o  OPTION-CODE: (Assigned by IANA.)

   o  OPTION-LENGTH: Size (in octets) of OPTIONS-DATA.

   o  OPTION-DATA: This field includes the original resource record
      which the DNS Proxy would translate from.







Endo & Miyata             Expires April 4, 2009                [Page 21]


Internet-Draft        Translator Friendly DNS Proxy         October 2008


7.1.2.  Usage of the ORR option

   The ORR option can carries original RRs.  So that the client can
   verify RRs at receiving first response from the DNS Proxy, if the
   response has translated RR in its answer secDNS tion.  This section
   describes the usage of ORR option.


   Client                     DNS Proxy                   DNS Server
     |         AAAA query         |                            |
     |------------->--------------|  AAAA query (unchanged)    |
     |                            |-------------->-------------|
     |                            |                            |
     |                            |         AAAA reply         |
     |                            |--------------<-------------|
     |                            |                            |
     |                            |  A query (translated)      |
     |                            |-------------->-------------|
     |                            |                            |
     |                            |  A reply (authorized)      |
     |                            |--------------<-------------|
     |   translated AAAA reply    |                            |
     |   and
     |   authorized A reply (ORR) |                            |
     |--------------<-------------|                            |
     |                            |                            |

   1.  A client send an AAAA query to the DNS Proxy.

   2.  The DNS Proxy received above query and forwards it to a DNS
       server.

   3.  A DNS server replies with no answer.

   4.  The DNS Proxy sends a query, which is translated to an A query by
       the DNS Proxy.

   5.  A DNS server sends an A response, which has an authenticated
       answer.

   6.  The DNS Proxy receives an authenticated response.  The DNS Proxy
       MUST keep SIG RR and adopt ORR option with RR, which is included
       in an authenticated response.  And The DNS Proxy translates RR
       from A to AAAA.

   7.  When the client receives a response which has ORR option, the
       client decide that the response has translated RRs.  Then, the
       client verifies answer section using RR, which was included in



Endo & Miyata             Expires April 4, 2009                [Page 22]


Internet-Draft        Translator Friendly DNS Proxy         October 2008


       ORR option.


















































Endo & Miyata             Expires April 4, 2009                [Page 23]


Internet-Draft        Translator Friendly DNS Proxy         October 2008


8.  IANA Considerations

   The option type Original Resource Record option, as defined in
   section 7 is new EDNS option.  A code number for new EDNS option
   should be assigned by IANA.














































Endo & Miyata             Expires April 4, 2009                [Page 24]


Internet-Draft        Translator Friendly DNS Proxy         October 2008


9.  References

9.1.  Normative References

   [RFC2119]  Bradner, S. and E. Davies, "Key words for use in RFCs to
              Indicate Requirement Levels", RFC 2119, BCP 14,
              March 1997.

   [RFC3142]  Hagino, J. and K. Yamamoto, "An IPv6-to-IPv4 Transpot
              Relay Translator", RFC 3142, June 2001.

   [RFC3363]  Bush, R., Durand, A., Fink, B., Gudmundsson, O., and T.
              Hain, "Representing Internet Protocol version 6 (IPv6)
              Addresses in the Domain Name System (DNS)", RFC 3363,
              August 2002.

   [RFC4966]  Aoun, C. and E. Davies, "Reasons to Move the Network
              Address Translator - Protocol Translator (NAT-PT) to
              Historic Status", RFC 4966, July 2007.

   [SNATPT]   Miyata, H. and M. Endo, "Simplified Network Address
              Translation - Protocol Translation", Work in
              Progress draft-miyata-v6ops-snatpt-01, September 2008.

9.2.  Informative References

   [NAT64]    Bagnulo, M. and P. Matthews, "NAT64/DNS64: Network Address
              and Protocol Translation from IPv6 Clients to IPv4
              Servers", Work in Progress draft-bagnulo-behave-nat64-01,
              September 2008.

   [RFC1035]  Mockapetris, P., "DOMAIN NAMES - IMPLEMENTATION AND
              SPECIFICATION", RFC 1035, November 1987.

   [RFC2671]  Vixie, P., "Extension Mechanisms for DNS (EDNS0)",
              RFC 2671, August 1999.

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











Endo & Miyata             Expires April 4, 2009                [Page 25]


Internet-Draft        Translator Friendly DNS Proxy         October 2008


Authors' Addresses

   Masahito Endo
   Yokogawa Electric Corporation
   2-9-32 Nakacho
   Musashino-shi, Tokyo  180-8750
   JAPAN

   Email: masahito.endou@jp.yokogawa.com


   Hiroshi Miyata
   Yokogawa Electric Corporation
   2-9-32 Nakacho
   Musashino-shi, Tokyo  180-8750
   JAPAN

   Email: h.miyata@jp.yokogawa.com

































Endo & Miyata             Expires April 4, 2009                [Page 26]


Internet-Draft        Translator Friendly DNS Proxy         October 2008


Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.


Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.











Endo & Miyata             Expires April 4, 2009                [Page 27]