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

Versions: 00 01 02 03 04

Internet Engineering Task Force                             Alain Durand
INTERNET-DRAFT                                           SUN Microsystem
July 20, 2001                                                Johan Ihren
Expires Jan. 21, 2002                                      Autonomica AB

               NGtrans IPv6 DNS operational requirements and roadmap


                          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
   The list of Internet-Draft Shadow Directories can be accessed at


   This document describes IPv6 DNS operational requirements and
   roadmap. It is the result of discussion from members of the NGtrans,
   DNSops and DNSext working groups.

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

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 foreseen 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 some 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.  With growing
   IPv6-only areas it will become increasingly cumbersome for such
   installations to maintain their DNS data on remote systems that are
   not available over local transport.

3. Issues with the standard resolution process

   The caching resolver that tries to lookup an name starts out at the
   root, and follows referrals until it is referred to a nameserver that
   is authoritative for the name.  If somewhere down the chain of
   referrals it is referred to a nameserver that is only accessible over
   a type of transport that is unavailable, a traditional nameserver is
   unable to finish the task.

   When the Internet moves from IPv4 to a mixture of IPv4 and IPv6 it is
   only a matter of time until this starts to happen and the complete
   DNS hierarchy starts to fragment into a graph where authoritative
   nameservers for certain nodes are only accessible over a certain
   transport. What is feared is that a node using only a particular
   version of IP, querying information about another node using the same
   version of IP can not do it because, somewhere in the chain of
   servers accessed during the resolution process, one or more of them
   will only be accessible with the other version of IP.

   A key requirement is that this will not happen and mechanisms must be
   in place to bridge the two worlds.  However, it should be noted that,
   even though bridging has to be bi-directional, there is not strictly
   necessary to use the same technique both ways, although from a design
   perspective it would be preferrable. That is, it is perfectly
   acceptable to build two different mechanisms, one to enable IPv4 only
   hosts to query IPv6 only DNS servers and one for IPv6 only hosts to
   query IPv4 only DNS servers.

   Also, 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

   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 focus on possible
   architectures to enable those caching resolver to meet the above

   On the same idea, forwarding resolver will not be discussed here.

4. Architectures

4.1 Architecture number 1:
    Sent all queries with RD bit off only over IPv4

   This would force all IPv6 DNS resolvers to 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.

4.2 Architecture number 2:
    Keep all zone data on IPv4 name servers

   This basically mandates an IPv6/IPv4 DNS general forwarder.

   In this architecture, all IPv6 DNS resolver are configure as
   forwarder and send 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.

   Furthermore, either some sort of dynamic forwarder location mechanism
   would be needed or significant maintenance issues would arise over
   time with statically configured forwarders.

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

4.3 Architecture number 3:
    Complete IPv4/IPv6 DNS solution

   This architecture require all zones to be accessible via IPv4 and
   IPv6. Note that, for each zone, there may be different physical
   servers answering queries made either with IPv4 or IPv6.

   Although desirable, this architecture is not implementable overnight.
   However, it can be a desirable long term 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.

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

   There are serious concerns about both scalability of these fallback
   forwarders and mechanisms to locate them.

4.5 Architecture number 5:
    A lookup-proxy between transports

   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

   By using any kind of forwarder, half the information (the "where to
   send it" part) is thrown away and the referral process is restarted
   from the root since the forwarder is recursive.  What is suggested is
   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.

   The exact details of such a protocol and how the tuple is sent are
   beyond the scope of this document and should be discussed in the
   DNSext working group. Note that this can be done without changing the
   format of the actual DNS queries.

   The more zones will be accessible via dual-stack transport, the less
   this fall-back or lookup-proxy mechanisms 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

4.6 Recommended architecture

   Architecture 1 is not acceptable, architecture 2 does not scale
   beyond early deployment, architecture 3 is only a long term

   Therefore there is a need to implement either architecture 4 and/or 5
   before large scale IPv6 DNS deployment takes place. For lack of a
   better solution the rest of this document focus on steps needed to
   deploy IPv6 DNS capabilities based upon architecture 4+5.

5. Roadmap for DNS service in a mixed environment IPv4/IPv6

5.1 Bridging system

   Per paragraph 3, a bridging system must be in place prior to large
   scale deployment IPv6 DNS deployment. Note that fallback resolvers
   are easy to implement to bootstrap early deployment and can be
   replace later by more scalable proxy-lookup systems.

5.2 Root name service accessible via IPv6

   The first DNS query a caching resolver will send is directed to a
   root name server. This, if the configuration of the bridging system
   is derived automatically from the DNS itself, there is a strong
   requirement to make root name service available over IPv6 transport.
   If the configuration is derived any other way or is done manually,
   there is a possibility to operate the system without an IPv6
   accessible root in certain cases.  However, as this document does not
   want to preclude any particular implementation of the bridging
   systems at this point, it is highly recommended that at some IPv6
   enable root name server be in place as early as possible.  It is an
   important step to show that IPv6 DNS deployment is possible.

5.3 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. Again, although not strictly necessary
   from a technical perspective, it is important to make sure that some
   TLD servers are accessible from the beginning via IPv6 so at least
   some label strings are resolvable with IPv6 transport without
   resorting to any fall-back mechanism.

   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.

5.3 IPv6 glue at TLD registries.

   It is necessary for domains delegated from a TLD to be able to
   specify an IPv6 name server address to the TLD registry. This is not
   so much a technical issue as it is a question of management and

5.4 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 should in the future be moved
   to ip6.arpa. So, as in 5.2 and 5.3, although not strictly speaking a
   technical requirement, it is important to have at least one server
   for int/ip6.int and arpa/ip6.arpa accessible via IPv6.

   Having both zones, ip6.int and ip6.arpa, reachable via IPv6 as early
   as possible will simplify any transition from one to the other.

6. AAAA vs A6

   This question will not be discussed here.

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

8 Editor address

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

   Johan Ihren
   Autonomica AB
   Bellmansgatan 30
   SE-118 47 Stockholm, Sweden

9. References

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