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

Versions: 00 01 02 03

IPNG Working Group                                     Dave Thaler
INTERNET-DRAFT                                           Microsoft
Expires January 2002                      Jun-ichiro itojun Hagino
                                           IIJ Research Laboratory
                                                     July 10, 2001

                   IPv6 Stateless DNS Discovery

                       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 document specifies the steps a host takes in deciding how to
autoconfigure information (other than the host's name itself)
required for name resolution in IP version 6. The
autoconfiguration process includes determining whether such
information should be obtained through the stateless mechanism,
the stateful mechanism, or both.  This document defines the
process for acquiring a list of DNS server addresses, a domain

Expires April 2001                                        [Page 1]

Draft                 Stateless DNS Discovery        November 2001

search path, and the domain name of the host via a stateless
mechanism.  The details of autoconfiguration using the stateful
protocol are specified elsewhere.

Copyright Notice

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

Expires April 2001                                        [Page 2]

Draft                 Stateless DNS Discovery        November 2001

1.  Introduction

RFC 2462 [ADDRCONF] specifies "OtherConfigFlag" as a per-interface
variable, which is set from the value of the "O" ("Other stateful
configuration") flag in Router Advertisements received.  When
OtherConfigFlag is set on an interface, information related to
name resolution is obtained using the stateful autoconfiguration
mechanism.  However, when OtherConfigFlag is not set, it does not
describe how to obtain such information.  This is the purpose of
this document.

(NOTE: Should we specify whether each parameter below is per-host
or per-interface?  A possible argument for "no" is that it may not
be the same on different platforms today.)

For a host to effectively resolve names of other hosts, and
potentially allow resolution of its name to be performed, the
following parameters are typically required:

 o One or more addresses of Domain Name Service (DNS) [RFC1034,
   RFC1035] servers.  The function of name-to-address resolution
   (or vice versa) in IP is performed by DNS, which requires that
   at least one DNS Server be known and reachable by a device
   desiring to perform name resolution.

 o Domain name of the host itself.

 o Search path.  It is currently common practice for the search
   path to be computed by a device based on its domain name.
   However, a DHCP option [DOMSEARCH] has been proposed, and so
   search path configuration is likely to be a requirement in
A design team recommendation [DDDT] contains an analysis of the
requirements and solution space, which was used as the basis for
this document.

2.  Overview

A well-known site-local IPv6 anycast address is assigned to all
DNS servers in the site, and host routes are propagated in the
site's routing tables.

A host initially sends a specific DNS query using UDP to this
anycast address, and the reply for this specific query contains

Expires April 2001                                        [Page 3]

Draft                 Stateless DNS Discovery        November 2001

any parameters the host should use.

(Note: There has been some discussion of what DNS record type
should be used.  [DDDT] recommended the use of SRV records, and a
proposal using SRV records was presented at the interim Working
Group meeting in Seattle.  However, since information other than
servers must be included, and encoding multiple types of
information was done through creative interpretation of the SRV
field descriptions, there was some pushback against the use of SRV
records.  Other options include TXT records, and defining a new
record type.  This version (-02) of this document will describe
the use of TXT records, but a future version may change to define
a new record type instead, depending on feedback received from the
WG.  The goal is still to encode all information in a single
response, so that only 1 message exchange is required.)

3.  DNS Server Configuration

Name resolution information can be encoded in TXT records as
follows.  The DNS server list is expressed with a string of the
form "dnsservers=<address>[,<address>]*" where the attributevalue
is a comma-separated list of one or more addresses (either IPv4 or
IPv6) in string literal format suitable for passing to

The domain name to use is expressed with a string of the form
"domainname=<domain>" where the attributevalue is the domain name
the client should use.

The domain suffix search path is expressed with a string of the
form "searchpath=<domain>[,<domain>]*" where the attributevalue is
a comma-separated list of domain suffixes.

Name resolution information can be expressed as defaults for the
entire site, as well as per-subnet overrides if desired.  To
express site defaults, the record owner used is a wildcard, namely
*._dnsinfo.local.arpa.  The format of per-subnet overrides is
described in the next section.

(NOTE: Is local.arpa the right well-known domain to use?  We may
need to define a separate one.)

Each of the attributes described herein are optional, and any
combination may be used, except that only one record per

Expires April 2001                                        [Page 4]

Draft                 Stateless DNS Discovery        November 2001

attributename should be present per owner (site or subnet) string.

*._dnsinfo.local.arpa   IN   TXT   "dnsservers=fec0:0:1::1,fec0:0:2::2"
*._dnsinfo.local.arpa   IN   TXT   "domainname=example.com"
*._dnsinfo.local.arpa   IN   TXT   "searchpath=foo.example.com,

                  Table 1: Example configuration

The DNS server must also be assigned the well-known site-local
anycast address, and a host route must be injected into the site's
routing infrastructure.  Route injection can be done via any of
several methods, including:

a) Run the server on a router, and configure it to inject the host

b) Run a routing protocol on the server, and configure it to
   inject the host route.  Note that this requires that the server
   and its router(s) must run the same routing protocol, at least
   for communication between the router(s) and the server(s) on
   the link.  However, a server does not need to participate fully
   in the routing protocol, it only needs to be able to inject

c) Run multiple servers on the same link(s), and configure their
   local router(s) to inject host routes for the anycast address
   into the site's routing infrastructure.  Running multiple
   servers on the same link provides robustness to the failure of
   a server, while routing provides robustness to the loss of
   routers and other links.  There may still be some failures,
   however, such as a unidirectional failure of the router's
   interface, which are not handled by this option.

d)  Modify the routers on the link to periodically solicit (using
    Neighbor Discovery) the anycast address, and inject the host
    route based on whether a reply is received.

e)  Use a host-to-router protocol for communicating anycast group
    joins to routers.  There is now work in progress [HOST-
    ANYCAST] in this regard.

Expires April 2001                                        [Page 5]

Draft                 Stateless DNS Discovery        November 2001

4.  Host Behavior

When an interface comes up, and a host determines that the
OtherConfigFlag on the interface is off, then it takes the
following actions.

The host constructs a DNS query for TXT records for
"<subnet>._dnsinfo.local.arpa.", where <subnet> is constructed
from an onlink prefix as follows:

1) Determine the onlink prefix to use.  Any onlink site-local
   prefix is used, if present.  Otherwise, any onlink global
   prefix is used.  If no other onlink prefixes are present (e.g.,
   if no routers are present), the link-local prefix is used as a
   last resort.

2) Convert the subnet prefix to a string by taking the lower case
   string literal representation, with no zero compression, and
   replacing all colons with underscores.  Table 2 below shows
   some examples.  This notation is used so that it uses only one
   token, is unique per prefix, and is human readable.

Prefix                     String
-----------------          --------------------------------------
fec0:0:0:1::/64            fec0_0000_0000_0001._dnsinfo.local.arpa
3ffe:ffff:0:1234::/64      3ffe_ffff_0000_1234._dnsinfo.local.arpa
fe80::/64                  fe80_0000_0000_0000._dnsinfo.local.arpa

                     Table 2: Example queries

Once the query is formed, the host sends out the query using UDP
to the well-known anycast address.  If no response is received
after DNS_RETRANS_TIMER seconds, the query is repeated, up to a
maximum of MAX_DNS_QUERIES total messages.

(TODO: Compare to DHCP.  Does DHCP retry eventually, if no server
was initially found?)

Since the query is sent to an anycast address, the reply will
necessarily come from a different address.  The host must not
discard the reply simply because the source address is different.
A more detailed discussion of this issue can be found in

Expires April 2001                                        [Page 6]

Draft                 Stateless DNS Discovery        November 2001

Upon receiving a response, the host parses the TXT records and
acts on the information as follows.

If a dnsservers attribute is present, the list of server addresses
is extracted from the value.  If no such attribute is present (or
if no reply is received), an implementation-specific default list
is used.  For example:

o    an implementation MAY use an empty list (effectively
     disabling name resolution),

o    a host MAY use a DNS server list containing only the anycast
     address, subject to the limitations discussed in the next

o    a host MAY use mDNS [MDNS] only, or

o    a host MAY use some combination of the above.
In general, the list obtained is used in the same way as if the
list had been obtained (or failed to be obtained) via DHCP.

If a domainname attribute is present, the domain name is extracted
from the value.  The domain name (or lack thereof) is used in the
same way as if the list had been obtained (or failed to be
obtained) via DHCP.

If the searchpath attribute is present, the search path is
extracted from the value.  If not present, the host uses the
search path it would use if no path had been obtained if DHCP were
in use.

4.1.  Alternative Host Behavior

A host MAY choose to skip TXT queries and use the anycast address
for sending normal DNS queries, if the following limitations are

o    The host cannot obtain the domain name for the host itself,
     nor a domain search path.

o    Queries that undergo IPv6 fragmentation may not be handled
     well, as fragments may reach different servers.  Therefore,
     queries SHOULD fit into the IPv6 minimum link MTU.

Expires April 2001                                        [Page 7]

Draft                 Stateless DNS Discovery        November 2001

o    When a response comes back with the TC (truncated) bit set,
     the host cannot issue TCP fallback queries due to the
     limitations with TCP and anycast.

The rule on allowing replies that come from a source different
from the query destination still applies.

5.  Protocol Constants

DNS_RETRANS_TIMER       3 seconds

MAX_DNS_QUERIES         3 transmissions

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

(NOTE: need to verify the text below makes sense.)

Since anycast is used, IPsec/IKE cannot be used.  However, the
payload can be protected as follows.  If the client can
preconfigure a well known private or public key then TSIG [TSIG]
or DNSSEC [DNSSEC] can be used with the same packets presented for
the query.  If this is not the case, then either TSIG keys will
have to be negotiated using [TKEY] or a Diffie-Hellman Key
[DIFFSEC] exchange will have to take place using DNSSEC.  After
the client has the proper key then the query can be performed.

7.  IANA Considerations

The IANA should assign a single site-local IPv6 address to be used
as an anycast address assigned to DNS servers.

8.  Acknowledgements

The IPv6 DNS Discovery Design Team [DDDT] provided recommendations
that formed the basis of this specification.  The IPv6 Working
Group provided valuable feedback on the mechanism.  Aaron Schader
provided helpful comments on this draft.

Expires April 2001                                        [Page 8]

Draft                 Stateless DNS Discovery        November 2001

9.  References

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

     Hagino, Jun-ichiro itojun, and K. Ettikan, "An analysis of
     IPv6 anycast", draft-ietf-ipngwg-ipv6-anycast-
     analysis-00.txt, Work in progress, July 2001.

     Thaler, D., Editor, "Analysis of DNS Server Discovery
     Mechanisms for IPv6", draft-ietf-ipngwg-dns-discovery-

     D. Eastlake, "Storage of Diffie-Hellman Keys in the Domain
     Name System (DNS)", RFC 2539, March 1999.

     D. Eastlake, "Domain Name System Security Extensions", RFC
     2535, March 1999.

     B. Aboba, "DHCP Domain Search Option", draft-aboba-dhc-
     domsearch-01.txt, December 2000.

     Haberman, B., and D. Thaler, "Host-based Anycast using MLD",
     draft-haberman-ipngwg-host-anycast-00.txt, February 2001.

     Esibov, L., Aboba, B., and D. Thaler, draft-ietf-dnsext-
     mdns-03.txt, July 2001.

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

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

Expires April 2001                                        [Page 9]

Draft                 Stateless DNS Discovery        November 2001

10.  Full Copyright Statement

Copyright (C) The Internet Society (2001).  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

Expires April 2001                                       [Page 10]

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