Network Working Group                                 Alain Durand
INTERNET-DRAFT                              SUN Microsystems, inc.
August 21,
October 25, 2002                          Jun-ichiro itojun Hagino
Expires February April 2002                         IIJ Research Laboratory
                                                       Dave Thaler

                Well known site local unicast addresses for
               to communicate with recursive DNS resolver
                 <draft-ietf-ipv6-dns-discovery-06.txt> servers

                          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-

   Internet Drafts are 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 a "work in progress".

   To view the list Internet-Draft Shadow Directories, see


   This documents specifies a method for 3 well known addresses to configure stub
   resolvers on IPv6 nodes to find a enable them to communicate with recursive
   DNS resolver server with minimum configuration in the network and without
   running a discovery protocol on the end nodes.  This method is to may be
   used in last
   resort, when no other information about the addresses of recursive DNS
   servers is available.  Implementation of stub resolvers using this as
   default configuration must provide a way to override this.

Copyright notice

   Copyright (C) The Internet Society (2002).  All Rights Reserved.

1. Introduction

   RFC 2462 [ADDRCONF] provides a way to autoconfigure nodes with one or
   more IPv6 address and default routes.

   However, for a node to be fully operational on a network, many other
   parameters are needed, such as the address of a name server that
   offer recursive service (a.k.a. recursive DNS resolver, server), mail relays,
   web proxies, etc.  Except for name resolution, all the other services
   are usually described using names, not addresses, such as or  For obvious bootstrapping
   reasons, a node needs to be configured with the IP address (and not
   the name) of a recursive DNS resolver. server.  As IPv6 addresses look much
   more complex than IPv4 ones, there is some incentive to make this
   configuration as automatic and simple as possible.

   Although it would be desirable to have all configuration parameters
   configured/discovered automatically, it is common practice in IPv4
   today to ask the user to do manual configuration for some of them by
   entering server names in a configuration form. So, a solution that
   will allow for automatic configuration of the recursive DNS resolver server is
   seen as an important step forward in the autoconfiguration story.

   The intended usage scenario for this proposal is a home or enterprise
   network where IPv6 nodes are plugged/unplugged with minimum
   management and use local resources available on the network to
   autoconfigure. This proposal is also usefull useful in cellular networks
   where all moble mobile devices are included within the same site.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in [KEYWORDS].

2. Pre-configuration Well known addresses vs discovery

   Some of the discussions in the past around DNS server discovery have
   been trying to characterize the solution space into stateless versus
   stateful or server-oriented server oriented versus severless.  It is not absolutely
   clear how much state if any needs to be kept to perform DNS server
   discovery, and, although the semantic differences between a router
   and a server are well understood from a conceptual perspective, the
   current implementations tend to blur the picture.  In another attempt
   to characterize different approaches, one can look at how much
   intelligence a client needs to have in order to use the service.

   One avenue is to ask the IPv6 node to participate in a discovery
   protocol, such as SLP or DHCP, learn the address of the server and
   send packets to this server. Another one is to pre-configure (hard-
   code) a local scope address on configure the IPv6
   node with well known addresses and let it send packets
   directly to this address, with the underlying assumption that the local routing system will
   forward them packets to the right place.  This document explores this
   later avenue of pre-configuration configuration using well known addresses that does
   not require participation of the end node in the DNS resolver any discovery mechanism.

3. Reserved prefix and addresses

   The mechanism described here is is:
      - intended for ongoing use and not not just for bootstrapping
      - intended to be used as populate a last resort, in stub resolver's list of available
      recursive servers only if that list is otherwise unpopulated
      - providing reliability through redundancy using three unicast

3.1 Stub resolver configuration

   This memo reserved three well known IPv6 site local addresses.

   In the absence of any other information about the addresses of
   recursive DNS resolvers.  If
   other servers, IPv6 stub-resolvers MAY use any of those three
   IPv6 addresses in their list of candidate recursive DNS servers.

3.2 Recursive DNS servers configuration mechanisms are available, they should

   Within sites, one or more recursive DNS server SHOULD be tried

   Note configured
   with any of those three addresses. It is RECOMMENDED that large sites
   deploy 3 recursive DNS servers, one for each reserved address. Small
   site could use only one recursive DNS server and assign the 3
   addresses to it.

3.3 Rationale for the choice of three addresses

   Three was chosen based on common practice in many places in the
   industry.  While it's true that if the first one fails, that it's
   unlikely the second one will succeed (due to there really being no
   DNS server at all), using multiple addresses is important so that
   when ones do exist, the host can fail over to a second server more
   quickly than routing converges. Three servers is a compromise between
   extra reliability and increased complexity (maintaining additional
   servers, having multiple entries in the routing system, additional
   delays before the stub resolver returns an error,...).

   Another reason to have multiple addresses is to avoid the need to use
   of anycast addresses to achieve reliability through redundancy. On
   top of the classic problems (TCP sessions, ICMP messages,...) using
   an anycast address would hide the real locations of the recursive DNS
   servers to implementors:

   Implementing the stub resolver, prohibiting it to keep track of which
   servers are performing correctly. For this particular matter, using
   well known addresses is no different than configuring the stub
   resolver with regular addresses taken from the local site.

3.4 Implementation considerations

   Stub resolver implementation MAY be configured by default using those
   addresses. However, implementing only the mechanism described in this
   memo may end up causing some interoperability problems when operating
   in networks where no recursive DNS resolver server is configured with any of
   the well known addresses.  Thus, it is recommended to stub resolvers MUST implement also other
   mechanisms for overriding this default, for example: manual
   configuration, L2 mechanisms and/or DHCPv6.

3. Reserved prefix and addresses

   The basic idea of this proposal is to reserve three well known IPv6
   site local addresses for DNS resolvers and then have the routing
   system forward the DNS request to them.

   IPv6 stub-resolvers implementing this proposal are pre-configured
   with those three IPv6 addresses as DNS resolver.

   Local DNS resolvers should be configured with one of those three
   addresses to enable clients to switch from one to the other if one

4. Routing

   A solution to enable clients the stub resolvers to reach the recursive DNS resolvers
   servers is to inject host routes in the local routing system.
   Examples of methods for injecting host routes and a brief discussion
   of their fate sharing properties are presented here:

      a) Manual injection of routes by a router on the same subnet.
      If the node running the recursive DNS resolver server goes down, the router
      may or may not be notified and keep announcing the route.

      b) Running a routing protocol on the same node running the DNS
      If the process running the recursive DNS resolver server dies, the routing
      protocol may or may not be notified and keep annoucing announcing the route.

      c) Running a routing protocol within the same process running the
      recursive DNS resolver. server.
      If the recursive DNS resolver server and the routing protocol run in
      separated threads, similar concerns as above are true.

      d) Having Developing an "announcement" protocol that the recursive DNS resolver
      server could use to advertize the host route to the nearby router.
      Details of such a protocols protocol are out of scope of this document, but
      something similar to [MLD] is possible. However, the three first
      mechanisms should cover most cases.

   An alternate solution is to configure a link with the well known
   prefix and position the three recursive DNS resolvers servers on that link.
   The advantage of this method is that host routes are not necessary ,
   the well known prefix is advertized advertised to the routing system by the
   routers on the link. However, in the event of a problem on the
   physical link, all resolvers will become unreachable.

   IANA considerations for this prefix are covered in Section 6.


5. Site local versus global scope considerations

   The rationales for having a site local prefix are:

      -a) Using a site local prefix will ensure that the traffic to the
      recursive DNS resolver servers stays local to the site. This will prevent
      the DNS requests from accidentally leaking out of the site.
      However, the local resolver can implement a policy to forward DNS
      resolution of non-local addresses to an external DNS resolver.

      -b) Reverse DNS resolution of site local addresses is only
      meaningful within the site. Thus, making sure that such queries
      are first sent to a recursive DNS resolver server located within the site
      perimeter increase their likelyhood likelihood of success.


6. Examples of use

   This section presents example scenarios showing how the mechanism
   described in this memo can co-exist with other techniques, namely
   manual configuration and DHCPv6 discovery.


   Note: those examples are just there to illustrate some usage
   scenarios and in no way do they suggest any recommended practices.

6.1 Simple case, general purpose recursive DNS resolver server

   This example shows the case of an enterprise or a cellular network that manages a full flavor general purpose one recursive
   DNS resolver server and a large number of nodes running DNS stub resolvers.
   The recursive DNS resolver server is performing (and caching) all the recursive queries on behalf of
   recursive queries on behalf of the stub resolvers.  The recursive DNS
   server is configured with an IPv6 address taken from the prefix
   delegated to the
   stub resolvers.  Those site and with the 3 well known addresses defined in
   this memo.  The stub resolvers are either manually configured with the "real"
   IPv6 address of the resolver recursive DNS server or with one (or several) of the well known site
   local unicast addresses defined in this memo.


            |                                          |
            |                  ---------------------   |
            |                  |manually configured|  |
            |                  |DNS stub resolver  |   |
            |                  |configured with the|   |
            |                  |"real" address of  |   |
            |                  |the recursive DNS  |   |
            |                  |server             |   |
            |                  ---------------------   |
            |  ----------  -----------          |                  |
            |  |recursive|          |                  |
            |  |DNS     |<-----------      |<----------                  |
            |  |resolver|<-----------  |server   |<----------------            |
            |  ----------  -----------                |            |
            |                  ---------------------                  ----------------------  |
            |                  |DNS stub resolver   |  |
            |                  |configured with 3   |  |
            |                  |well known addresses|  |
            |                  ----------------------  |
            |                                          |

            (The recursive DNS server is configured to listen both on
            its IPv6 address and on the well known address)

6.2 Three recursive DNS servers

   This is a similar example as above, except that three recursive DNS
   resolvers are configured instead of just one.

            |                                          |
            |                  ---------------------   |
            |                  |DNS stub resolver  |   |
            |                  |configured with the|   |
            |                  |"real" address of  |   |
            |                  |the recursive DNS  |   |
            |                  |server             |   |
            |                  ---------------------   |
            |                       |                  |
            |  -----------          |                  |
            |  |recursive|          |                  |
            |  |DNS      |<---------|                  |
            |  |server 1 |<---------|------            |
            |  -----------          |     |            |
            |                       |     |            |
            |  -----------          |     |            |
            |  |recursive|          |     |            |
            |  |DNS      |<---------|     |            |
            |  |server 2 |<---------|-----|            |
            |  -----------          |     |            |
            |                       |     |            |
            |  -----------          |     |            |
            |  |recursive|          |     |            |
            |  |DNS      |<----------     |            |
            |  |server 3 |<---------------|            |
            |  -----------                |            |
            |                  ----------------------  |
            |                  |DNS stub resolver   |  |
            |                  |configured with 3   |  |
            |                  |well known addresses|  |
            |                  ----------------------  |
            |                                          |

            (The recursive DNS resolver server is configured to listen both on
            its IPv6 address and on the well known address)


6.3 DNS forwarder

   A drawback of the choice of site local scope for the reserved
   addresses for recursive DNS resolver server is that, in the case of a
   home/small office network connected to an ISP, DNS traffic cannot be
   sent directly to the ISP recursive DNS resolver server without having the ISP
   and all its customers share the same definition of site.

   In this scenario, the home/small office network is connected to the
   ISP router (PE) via an edge router (CPE).

                                           /            |
            --------           --------------           -----      /             |
            |ISP PE|           |customer CPE|           |CPE|     /    Customer  |
            |      |===========|   |====<     site      |
            |      |           |   |     \              |
            --------           --------------           -----      \             |
                                           \            |

   The customer router CPE could be configured on its internal interface
   with one of the reserved site local addresses and listen for DNS
   queries. It would be configured to use one (or several) of the well
   known site local unicast addresses within the ISP's site to send its
   own queries to.  It would act as a DNS forwarder, forwarding queries
   received on its internal interface to the ISP's recursive DNS resolver. server.

                                                  /            |
        ----------           --------------      /             |
        |ISP     |           |customer           |         CPE|     /    Customer  |
        |DNS     |===========|         DNS|====<     site      |
        |server  |    <------|---forwarder|-----\----          |
        ----------           --------------      \             |
                                                  \            |

       In this configuration, the CPE is acting as a multi-sited router.


6.4 DNS forwarder with DHCPv6 interactions

   In this variant scenario, DHCPv6 is be used between the PE and CPE to
   do prefix delegation [DELEG] and recursive DNS resolver server discovery.

                                                    /            |
            --------           --------------      /             |
            |ISP   |           |customer CPE|     /    Customer  |
            |DHCPv6|===========|      DHCPv6|====<     site      |
            |server|    <------|------client|     \              |
            --------           --------------      \             |
                                                    \            |

   This example will show how DHCPv6 and well known site local unicast
   addresses cooperate to enable the internal nodes to access DNS.

   The customer router CPE is configured on its internal interface with
   one of the reserved site local addresses and listen for DNS queries.
   It would act as a DNS forwarder, as in 5.2,  forwarding those queries
   to the recursive DNS resolver server pointed out by the ISP in the DHCPv6

                                                  /            |
        ----------           --------------      /             |
        |ISP     |           |customer CPE|     /    Customer  |
        |DNS     |===========|         DNS|====<     site      |
        |resolver|    <------|---forwarder|-----\----          |
        ----------           --------------      \             |
                                                  \            |

   The same CPE router could also implement a local DHCPv6 server and
   advertizes itself as DNS forwarder.

                                                    /            |
            --------           --------------      /   Customer  |
            |ISP PE|           |customer CPE|     /    site      |
            |      |===========|DHCPv6      |====<               |
            |      |           |server------|-----\--->          |
            --------           --------------      \             |
                                                    \            |

   Within the site:

      a) DHCPv6 aware clients use DHCPv6 to obtain the address of the
      DNS forwarder...

                                                  /            |
        ----------           --------------      /   Customer  |
        |ISP     |           |customer CPE|     /    site      |
        |DNS     |===========|         DNS|====<               |
        |resolver|    <------|---forwarder|-----\----DHCPv6    |
        ----------           --------------      \   client    |
                                                  \            |
          (The address of the DNS forwarder is aquired acquired via DHCPv6.)

      b) other nodes simply send their DNS request to the reserved site
      local addresses.

                                                  /            |
        ----------           --------------      /   customer  |
        |ISP     |           |customer CPE|     /    site      |
        |DNS     |===========|         DNS|====<               |
        |resolver|    <------|---forwarder|-----\----non DHCPv6|
        ----------           --------------      \   node      |
                                                  \            |
          (Internal nodes use the reserved site local unicast address.)

   A variant of this scenario is the CPE can decide to pass the global
   address of the ISP recursive DNS resolver server in the DHCPv6 exchange with
   the internal nodes.


7. IANA considerations

   The site local prefix fec0:0000:0000:ffff::/64 is to be reserved out
   of the site local fec0::/10 prefix.

   The unicast addresses fec0:000:0000:ffff::1, fec0:000:0000:ffff::2
   and fec0:000:0000:ffff::3 are to be reserved for recursive DNS resolver server

   All other addresses within the fec0:0000:0000:ffff::/64 are reserved
   for future use and are expected to be assigned only with IESG


8.  Security Considerations

   Ensuring that queries reach a legitimate DNS server relies on the
   security of the IPv6 routing infrastructure.  The issues here are the
   same as those for protecting basic IPv6 connectivity.

   IPsec/IKE can be used as the well-known well known addresses are used as unicast

   The payload can be protected using standard DNS security techniques.
   If the client can preconfigure a well known private or public key
   then TSIG [TSIG] can be used with the same packets presented for the
   query.  If this is not the case, then TSIG keys will have to be
   negotiated using [TKEY].  After the client has the proper key then
   the query can be performed.

   The use of site local addresses instead of global addresses will
   ensure the DNS queries issued by host using this mechanism will not
   leak out of the site.


9.  References

        Bradner, S., "Key words for use in RFCs to Indicate
        Requirement Levels", BCP 14, RFC 2119, March 1997.

        Thomson, S., and T. Narten, "IPv6 Stateless Address
        Autoconfiguration", RFC 2462, December 1998.

        Deering, S., Fenner, W., Haberman, B.,
        "Multicast Listener Discovery (MLD) for IPv6",
        RFC2710, October 1999.

        Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington,
        "Secret Key Transaction Authentication for DNS (TSIG)",
        RFC2845, May 2000.

        D. Eastlake, "Secret Key Establishment for DNS (TKEY RR)",
        RFC2930, September 2000.

        Bound, J., Carney, M., Perkins, C., Lemon, T., Volz, B. and
        Droms, R. (ed.), "Dynamic host Configuration Protocol for IPv6
        (DHCPv6)", draft-ietf-dhc-dhcpv6-23 draft-ietf-dhc-dhcpv6-27 (work in progress),
        Februray 2002.

        Troan, O., Droms, R., "IPv6 Prefix Options for DHCPv6",
        draft-troan-dhcpv6-opt-prefix-delegation-01.txt (work in progress),
        February 2002.


10.  Authors' Addresses

   Alain Durand
   SUN microsystems, inc.
   901 San Antonio rd
   17 Network Circle, UMPK 17-202
   Palo Alto,
   Menlo Park, CA 94303, USA. 94025

   Jun-ichiro itojun HAGINO
   Research Laboratory, Internet Initiative Japan Inc.
   Takebashi Yasuda Bldg.,
   3-13 Kanda Nishiki-cho,
   Chiyoda-ku, Tokyo 101-0054, JAPAN

   Dave Thaler
   One Microsoft Way
   Redmond, CA 98052, USA


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