Internet Engineering Task Force                             Alain Durand
INTERNET-DRAFT                                           SUN Microsystem
Oct 2, 2001
Expires Apr. 3, 2002



                               IPv6 DNS lookup proxy

                         draft-durand-dns-proxy-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.

   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


   This document describe a DNS lookup proxy to enable IPv6 only
   resolver to query data on IPv4 only server.



. Introduction


   As analyzed in [DNSOPreq], the operation of DNS in a mixed
   environment IPv4 and IPv6 require Some bridging to happen to enable
   an IPv6 only system to query data on an IPv4 only server and vice-
   versa. However, such bridges do not need to be symmetrical, that is,
   it is OK, for the sake of efficiency, to design two different
   systems, one for each case. This document presents a scalable
   solution to enable IPv6 only systems to query IPv4 only servers.  The
   case of an IPv4 only system querying an IPv6 only server is not
   discussed here.



. Recursive vs non recursive fallback system


   One of the approach suggested to solve the bridging problem was to
   use some kind of dual stack, general forwarder that will resolve the
   queries on behalf of the IPv6 only resolver.  An IPv6 only resolver
   could either delegate all its queries to this forwarder or only use
   it in last resort mode, when IPv4 transport is needed to reach the
   desired DNS server.

   In the first mode of operation, the general forwarder may face
   massive scaling issues.  In the second mode of operation, the
   forwarder will still have to operate in recursive mode because the
   information gathered previously by the IPv6 only resolver in its
   attempt to resolve the name will be lost. It is feared that such
   general forwarder will also face serious scaling issues once the IPv6
   traffic will increase.


   The lookup-proxy design is based upon the following observation:
   When a resolver is following a chain of referrals and cannot complete
   because it is referred to an address it lacks transport for, then it
   knows both the query and where to send it. It is just lacking
   transport. The solution presented here aims at bridging seamlessly
   the two transports by providing a new protocol that can send the
   tuple:

           {query, server}

   to a proxy, have the proxy send the query on (directly) to the
   server, collect the response and return it to the resolver.  The
   proxy will be non-recursive, and thereby much more scalable.
   Furthermore, the proxy does not (or should not) know much about DNS,
   it should only know enough to repack the query and response in IPv4
   and IPv6 packets respectively.



. Lookup proxy architecture


3.1 An IPv6 anycast prefix

   As an IPv6 address is much larger than an IPv4 address, it is
   possible to embed an IPv4 address within an IPv6 address. Proposal
   like [6to4] or [isatap] use this property to embed IPv4 tunnel
   endpoint within IPv6 addresses.

   This document suggest to use a well know, globally routable prefix P
   as an anycast DNS lookup proxy prefix. The prefix length of P MUST be
   shorter than 96 and SHOULD be small enough not to be filtered in
   common BGP announcement.

   A set of DNS lookup proxies MUST advertise this anycast prefix and
   MUST intercept any IPv6 packet whose destination address is of the
   form P::a.b.c.d (a.b.c.d represent the 32 bits of an IPv4 address)
   and UPD destination port is 53.


3.2 DNS lookup proxy behavior

   A DNS lookup proxy SHOULD check the payload to make sure it really is
   a valid DNS query and then MUST forward it in a new IPv4 packet.

   The source address of this new packet is one of the proxy IPv4
   addresses.  The destination address is taken from the 32 lowest bits
   of the destination address of the incoming IPv6 packet. The transport
   protocol MUST be set to UDP and destination port to 53. The payload
   of the new IPv4 packet MUST be directly copied from the one in the
   IPv6 packet.


3.3 Fragmentation and MTU

   Simple UDP DNS queries and answers are expected to fit within 512
   bytes, fragmentation and MTU are not an issue for them.  However,
   queries using EDNS 0 or falling back to TCP may have a larger
   payload.  For DNS connections using TCP, MTU is not an issue, as TCP
   will adapt the correct MTU in each connection on both side of the
   proxy.  Using EDNS 0, the client may specify a large packet size than
   512. As an IPv6 header is longer than an IPv4 header (with no
   options), this mechanism will not results in fragmented UDP packets.

   However, if the DNS communication results in exchanging more than one
   packet, there is a theoretical chance that different packets will go
   through different proxies, defeating the mechanism. It is expected
   that the routing system will be stable enough to prevent this case to
   happen in reality.


3.4 Mapping

   A DNS lookup proxy MUST maintain some kind of mapping between the
   incoming IPv6 query and the outgoing IPv4 packet so that when the
   answer will come back from the IPv4 DNS server, it will know where to
   sent it to in IPv6 land.

   A DNS lookup proxy MUST implement some time-outs on those mappings to
   do garbage collection.


3.5 Caching
   A DNS lookup proxy MAY implement positive and/or negative caching
   technique to improve efficiency.

   In the case of positive caching, the proxy MUST honor the TTL
   provided in the DNS answer; the proxy MAY use a smaller TTL than it
   received, but MUST NOT cache the answer beyond the period specified
   by the TTL.



3.5 rate limitation

   A DNS lookup proxy may also impose some rate limitation measure on
   packet they sent to the same address, either IPv4 or IPv6, to lower
   the impact of potential DOS attack inherent with any public proxy.



. Converting IPv4 referrals into IPv6 referrals

   When an IPv6 only resolver is following a chain of referrals and
   cannot complete because it is referred only to IPv4 addresses, it
   SHOULD automatically derived an IPv6 addresses by padding the IPv4
   addresses to the prefix P and send the DNS queries to those
   addresses.



. Scaling issues


   Using an anycast prefix P will allow to use as many proxy as
   necessary, thus this mechanism has very good scaling properties.


. Anycast issues

   IPv6 architecture requires the anycast addresses MUST NOT be used as
   source addresses. Thus, when returning the DNS answer, the proxy MUST
   replace the anycast address by one of its unicast address with the
   appropriate scope. Also, the IPv6 DNS resolver MUST not check the
   source address of packets returning from the proxy.




. Security consideration


   Any public proxy is inherently a source of DOS attack. Rate limiting
   packet emission as suggested in 3.5 is expected to lower the risks.



. Author address


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


. References

   [DNSOPreq] draft-ietf-ngtrans-dns-ops-req-02.txt


   10. Acknowledgment

   The author whishes to acknowledge the input of Johan Ihren and
   Akira Kato.