[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits]

Versions: 00 01 02 03 04

Internet Engineering Task Force                             Alain Durand
INTERNET-DRAFT                                           SUN Microsystem
July 13, 2001                                                   (editor)
Expires Jan. 14, 2002



                  NGtrans IPv6 DNS operational requirements

                    draft-ietf-ngtrans-dns-ops-req-00.txt



                       Status of this memo


   This memo provides information to the Internet community.   It
   does  no  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 describes IPv6 DNS operational needs.  It is the
   result of discussion from members of the NGtrans wg.



1. IPv6 transition: Dual-stack vs IPv6 only nodes vs IPv6-mostly nodes


   Transition  to  IPv6  can  happen  following   two   different
   strategies:


   1.1. Incremental deployment on existing network.

   This needs to be done without disturbing IPv4  service.   This
   strategy  relies  heavily on dual-stack nodes and tunnels.  It
   is foresee that this scenario is likely to happen in corporate
   networks.


   1.2. Large scale deployment of new infrastructure

   This scenario envision large  to  very  large  networks  where
   public IPv4 address space is not available and private address
   is not practical.  Nodes in this scenario will very likely  be
   IPv6-only  or  IPv6-mostly  (getting  an  IPv4 address only on
   demand). This scenario is likely to happen in the  wireless/3G
   world.


   So the requirements discussed in this memo are not targeted at
   transitioning the DNS from IPv4 only to IPv6 only, but more at
   the transition to a mixed environment, where some systems will
   be  IPv4 only, some will be IPv6 only and others will be dual-
   stacked.



2. Rationale why DNS servers needs to be accessible via IPv6


   When IPv6-only and IPv6-mostly devices send DNS  queries,  per
   configuration/implementation  they  have  little choice but to
   use IPv6 transport. For example, it may be too expensive,  too
   slow or just not possible to get an IPv4 address for just that
   purpose.



3. Architecture


   A key point in the architecture required is to make sure not to
   partition the Internet from a DNS perspective. In an ideal world,
   provisions should be made that any system, regardless of its IP version,
   could get information about any other system, even if some of the
   queried DNS zone can only be accessible only using one
   particular version of IP.

   This requirements is stronger for new IPv6  systems  than  for
   existing  IPv4  systems. That is, it may be acceptable for old
   IPv4 systems to fail to discover information  about  some  new
   IPv6  systems,  however, any new IPv6 system should be able to
   get DNS information about any IPv4 system. Also, it should  be
   strongly encourage that new IPv4 system should be able to also
   query information about IPv6 systems.


3.1 IPv6 stub-resolver

   IPv4 and IPv6 stub resolvers are expected to send DNS  queries
   with  The  RD  (Recursion  Desire) bit ON to a DNS server that
   will act as caching resolver. The rest of the discussion  will
   not consider the stub-resolver case.


3.2 Architecture number 1:

   All IPv6 DNS resolver send all DNS queries using IPv4.

   This architecture  impose  a  dual-stack  model  for  all  DNS
   resolvers   and  will  not  scale.  It  will  not  be  further
   considered.


3.2 Architecture number 2: IPv6/IPv4 DNS general forwarder

   In this architecture, all IPv6 DNS resolver are  configure  to
   forward  all their DNS queries over IPv6 with the RD bit ON to
   a small number of dual-stack DNS servers which will accept  to
   relay their queries over IPv4 or IPv6 on their behalf.

   Such relays may decide to use caching techniques  to  speed-up
   request.  It  is  perceived  that an enormous amount of memory
   Would be needed to do so. Also, if negative  caching  is  also
   used,  great  care  is  needed in the choice of the TTL of the
   records in the negative cache.

   This solution has obvious scaling problems  and  can  only  be
   used   in  the  beginning  of  the  transition  to  the  mixed
   environment.


3.3 Architecture number 3:

   Pure IPv6 DNS solution

   In this architecture, all DNS queries  originating  from  IPv6
   resolvers  are  made  over  IPv6. This will require not only a
   root DNS server accessible via IPv6, but  also  a  DNS  server
   accessible via IPv6 for all possible DNS zone in the Internet.
   This solution would result  today  on  the  partition  of  the
   Internet  into  at  least  two  separated  world  from  a  DNS
   perspective, and is not acceptable as is.  However, in a  long
   term  perspective,  having  all zones accessible via both IPv4
   and IPv6 will be a desireable goal.  One way to make  progress
   toward  that direction is to ensure that, each time a new zone
   is delegated, both IPv4 and  IPv6  glue  are  provided.  There
   would  then  be  an opportunity for some people to offer dual-
   stack DNS secondary hosting.


3.4 Architecture number 4:

   Last resort, fallback forwarder

   This architecture is a mix  of  the  two  previous  ones.  The
   lookup  of name starts out by following the referrals from the
   root down until either the answer is found  or  following  the
   referral  requires  a  transport  (IPv4  or  IPv6) that is not
   available. When this happens the query  is  "forwarded"  to  a
   dual stack forwarder as a last resort.

   Without changing anything in the DNS protocols, this will
   impose the fall back DNS forwarder to accept recursive queries
   and redo the complete query by following the hint chain again from
   the root. Good caching techniques may help to reduce the load
   on the forwarder.

   Should the recursive  fall-back  forwarder  not  be  a  viable
   solution  because  of scalability or other reasons, which seem
   likely, then a more complicated design will  be  necessary.  A
   new  protocol that forwards both the query and the destination
   nameserver to a non-recursive "lookup-proxy"  is  needed.  The
   lookup-proxy  forwards  the  query directly to the destination
   nameserver, thereby achieving much better scalability.

   The more zones will be accessible  via  dual-stack  transport,
   the  less  this  fall-back mechanism will be used. And, as the
   top level zones in a label string are always the first  to  be
   queried,  there  is a big incentive to get them accessible via
   IPv6 as soon as possible.


3.5 Recommended architecture

   Architecture 1 is not  acceptable,  architecture  2  does  not
   scale  beyond  early deployment, architecture 3 is only a long
   term goal, so there is a  need  to  implement  architecture  4
   before  large  scale  deployment takes place. The rest of this
   document focus on steps needed to implement it.



4. Needs for a root name server accessible via IPv6


   The first DNS query an IPv6-only  or  IPv6-mostly  DNS  server
   will do is for a root name server, thus there is a need for at
   least  one  well  known,  well  maintained,  root  DNS  server
   accessible via IPv6.



5. Needs for TLDs servers accessible via IPv6


   Having the capability to query a root name server  using  IPv6
   is  just  the first step. The next one is to query a TLD for a
   NS record pointing to a domain name. Thus, to make  sure  that
   at  least  some label strings are resolvable with IPv6 without
   using the fall-back mechanism, some TLD  servers  need  to  be
   accessible  via  IPv6  from  the beginning.  Note that this is
   already the case for .jp and .cc.  Also note that  great  care
   should be taken when adding IPv6 glue in the TLD delegation by
   the root.



6. Needs for IPv6 NS delegations under TLDs


   Domains under TLDs are usually under the control of  customers
   who  can  manage their own zone. However, they need to be able
   to specify an IPv6 address to their registrars for their  name
   server (NS) delegation.



7. Needs for reverse path DNS servers


   Reverse DNS queries should also be supported in IPv6, for the same reasons
   as direct queries.

   Today's resolvers do reverse nibbles queries under the ip6.int tree.
   This may in the future be moved to ip6.arpa. So there is a need for at least one
   server for int/ip6.int and arpa/ip6.arpa to be accessible via IPv6
   Having both ip6.int and ip6.arpa reachable via IPv6 as early as possible
   will simplify any transition from one to the other.



8. AAAA vs A6


   This question will not be discussed here.



9. Security considerations


   Fall-back DNS, especially in the non-recursive solution, could
   be misused to create denial of service attacks on external DNS
   servers.  Some provision should be made in the design of those
   forwarder to deal with this issue.



10. Editor address


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



11. References


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/