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

Versions: 00

IPNG Working Group                       DNS Discovery Design Team
INTERNET-DRAFT                                 Dave Thaler, Editor
Expires September 2001                               July 12, 2001





       Analysis of DNS Server Discovery Mechanisms for IPv6
        <draft-ietf-ipngwg-dns-discovery-analysis-00.txt>





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

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

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.



Copyright Notice

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


Abstract





Expires January 2002                                      [Page 1]


Draft                       DDDT Report               January 2002


There are any number of ways that IPv6 hosts can discover
information required to enable name resolution, in the absence of
a DHCP server.  This document discusses the issues and provides a
taxonomy of possible solutions, and evaluates them against various
design criteria.  Finally, it provides recommendations as input to
the standards process.


1.  Introduction

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

There is also underway, known as Multicast DNS (mDNS) [MDNS], on
resolving names on the link in the absence of a DNS Server.  In a
managed environment with DNS Servers, mDNS is typically disabled
(via the domain search path).  As a result, it is required that a
device be able to discover whether DNS Servers are available and
discover its search path.  Thus, the mechanisms analyzed in this
report do not conflict with, but actually support the mDNS work.

In the absence of a DHCP server, the current IPv6 protocol suite
does not yet provide a mechanism to discover DNS servers or search
paths.  To solve this problem, a design team was chartered by the
IPNG Working Group to investigate possible solutions and provide a
recommendation as input to the working group.

This document summarizes the approaches investigated, and provides
an analysis of each, and describes its recommendations.  The
design team participants are listed in the Authors' Addresses
section below.


2.  Requirements

For a device to effectively resolve names, and potentially allow
resolution of its name to be performed, the following information
is required:

 o One or more addresses of DNS servers.  If a list is obtained, a
   client need only rediscover DNS servers if all addresses in the
   list are unreachable.  However, if a list is obtained from a
   single point, such as one of the DNS servers, then a





Expires January 2002                                      [Page 2]


Draft                       DDDT Report               January 2002


   requirement exists that the list of servers be up-to-date and
   easily maintainable.

 o Domain name

 o Search path.  It is currently common practice, for the search
   path to be computed by a device based on its domain name
   obtained.  However, a DHCP option [DOMSEARCH] is being proposed
   in the DHC WG, and so search path configuration is likely to be
   a requirement in general.

It is a further requirement that the above information be obtained
without using a DHCP server.

Automatic configuration of DNS servers, if no DNS servers exist
within the IPv6 site, is not a requirement.  However, it is
expected that there may be devices on site boundaries which will
want to relay messages containing the above types of DNS
information across site boundaries.  One such likely scenario
would be a home gateway device, where a home is its own site,
wanting to allow devices in the home to discover and use an
external DNS server, provided by an ISP.


3.  Criteria for Evaluation

Each mechanism can be evaluated against a number of criteria:

Scalability
   Is the mechanism scalable to a huge number of devices within a
   site?

Security
   Does the mechanism support authentication?  What pre-
   configuration is assumed?

Time to Deploy
   Can the mechanism be deployed immediately?  What devices need
   to have software updated to deploy the mechanism?  What devices
   need to have additional configuration done with existing
   software?

Business Motivation
   Do the parties required to implement any new code have a
   business motivation to do so, in preference to other options?





Expires January 2002                                      [Page 3]


Draft                       DDDT Report               January 2002


   Do the parties required to deploy any new devices or software
   have a business motivation to do so, in preference to other
   options?

Standardization
   Does the mechanism require anything new to be standardized?  If
   so, is the standardization within the realm of another Working
   Group?

Fate Sharing
   If deployed, does the mechanism introduce dependencies on other
   devices, protocols, or processes that would not normally be
   required to perform name resolution?

Convergence Time
   Upon the failure of a DNS server, router, or link, how long
   does it take for the mechanism to converge?

Scenarios
   Does the mechanism work in all scenarios?  Scenarios of note
   include:

   o  Isolated link with a DNS server but no routers

   o  Site with routers, but no multicast routing enabled

   o  Hosts connected over an NBMA link


4.  Taxonomy

Mechanisms can be categorized by their choice of transport
mechanism (e.g., are the messages multicast or unicast?), and by
their choice of packet format.

Sections 5 and 6 cover these two axes, and describe the set of
mechanisms evaluated.


5.  Transport Mechanisms

5.1.  Anycast for DNS server discovery only

This method is based on the use of a well-known site-scoped
anycast address which is used during DNS server discovery only.





Expires January 2002                                      [Page 4]


Draft                       DDDT Report               January 2002


We assume that IANA defines a well-known site-scoped anycast
address, which can be assigned one or more servers.  For optimal
fate-sharing, we assume that these servers are DNS servers.  The
aim is to provide a mechanism that allows DNS servers assigned the
well-known anycast address to be reachable within a site.

The proposal is based on a two-step discovery process.  First, a
device sends, using a connection-less protocol, a server-discovery
message with the anycast address as a destination address.  The
message will eventually reach a topologically closest server with
the anycast address.  The server will send a reply with a unicast
address as the source address, containing a list of unicast
addresses of valid DNS servers, plus the domain name and search
path.  Thereafter, all communication for name resolution is done
using one of the unicast addresses in the list obtained.  Only if
all addresses in the list are unreachable does the device need to
repeat the discovery process.

Obviously, this requires that all IPv6 devices requiring DNS
server discovery in the absence of a DHCP server must implement
this mechanism.


There are three immediate deployment options:

a) Run the servers on routers, and configure them to inject host
   routes for the anycast address into the site's routing
   infrastructure.

b) Run a routing protocol on the servers, and configure them to
   inject host routes for the anycast address into the site's
   routing infrastructure.  Note that this requires that a 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.  Note that, however, a server does not need to
   participate fully in the routing protocol, it only needs to be
   able to inject routes.  For example, RIPng [RIPNG], configured
   for outbound advertisements only, would be sufficient.

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,





Expires January 2002                                      [Page 5]


Draft                       DDDT Report               January 2002


   however, such as a unidirectional failure of the router's
   interface, which are not handled by this option.

If new code can be added to the router, a fourth option is also
possible:

d)  Using Neighbor Discovery to track whether servers are present.
    In this case a router will be configured to solicit certain
    Site-scoped anycast addresses when booting. This can also be
    done periodically.  Upon receiving a reply, the router will
    have the true address of the server in its Neighbor Cache and
    can inject a host route into the system for this Site-scoped
    anycast address.  A variant of this option, which would not
    require configuring the routers with the addresses to solicit,
    would be to combine it with running a routing protocol on the
    servers.  The router could then solicit whatever addresses
    were advertised in host routes, and take advantage of neighbor
    unreachability detection to quickly expire host routes.

    Routers should have this feature and allow configuration to
    enable or disable it. Also the Site-scoped addresses can be
    configurable when enabling this feature. This is to ensure
    that network administrators can add new Site-scoped addresses
    without the need for new software.  On some links, it may be
    required to not allow hosts to announce these services.  Hence
    soliciting anycast addresses should not be enabled on those
    links.

    It should be noted that this option does not require any
    protocol changes to ND, as it relies on the allocation of
    Well-known site-scoped anycast addresses to the hosts.


For a longer-term solution, a mechanism for communicating anycast
group joins to routers is desired.  It is expected that this would
be done as an extension to the Multicast Listener Discovery [MLD]
protocol, and the sockets API for joining multicast groups.  There
is now work in progress [HOST-ANYCAST] in this regard.

More details on generic anycast issues are available in [ITOJUN-
ANYCAST].









Expires January 2002                                      [Page 6]


Draft                       DDDT Report               January 2002


5.1.1.  Evaluation

Scalability
   The use of anycast can scale up to an arbitrarily large number
   of devices within the site, since to perform DNS server
   discovery, devices will only contact their closest server.  As
   a result, scalability can be achieved by adding more servers as
   the number of devices increases.  Since all traffic is unicast
   traffic, no extra bandwidth is consumed on links other than
   those between a device and its closest server.

   A large number of servers can also be supported easily, if
   desired, since only a single server is contacted to obtain a
   list of DNS servers, and the list obtained need not contain all
   DNS servers in the site.


Security
   The use of anycast is vulnerable to the same attacks as
   unicast.  This mechanism can best be authenticated by having
   the content signed via a content-specific mechanism.

   It may be possible to use IPsec to authenticate the discovery
   messages, but IKE cannot be used for anycast transmission, as
   RFC 2373 does not allow an anycast address to be used as the
   source address of packets.  As a result, barring future
   research and development of other key distribution protocols,
   using IPsec instead of a content-specific mechanism would
   require manual keying.

   In addition to securing discovery messages, it is also
   necessary to secure the mechanism used to communicate anycast
   joins from DNS servers to routers.  Without such
   authentication, the possibility would exist for a rogue server
   to redirect traffic to itself, and away from valid servers.

   In option (a), this is easy since the server is on the same
   machine as the router.  Likewise, in option (c), joins are done
   by manual configuration which is easily securable.  Option (b),
   however, requires utilizing authentication mechanisms available
   with current routing protocols (e.g., MD5 with RIPng [RIPMD5]).

   In option (d), only Neighbor Discovery messages need to be
   secured.  However, authenticating Neighbor Discovery messages
   is needed regardless of the option chosen, even if only to





Expires January 2002                                      [Page 7]


Draft                       DDDT Report               January 2002


   secure discovery by devices on the same link.


Time to Deploy
   Anycast discovery can be deployed as soon as clients are
   available, using any of the immediate-term options listed
   above, alone or in any combination, at the choice of each site
   administrator, without any need to coordinate with others.

   For immediate option (a), one must update one or more routers
   to run a server, if none already do.

   For immediate option (b), one must update one or more DNS
   servers to run an IPv6 routing protocol which can talk to its
   local router(s).

   For immediate option (c), one must ensure that multiple servers
   are deployed on the same link(s).  One then configures its
   local routers with a static host route for the anycast address.

   To deploy option (d), routers on servers' links need to be able
   to inject routes based on responses received from ND
   solicitations.  This would require SW upgrades for those
   existing routers.

   In all four options, one must finally configure the servers
   with the well-known anycast address.  No configuration is
   needed on other routers or devices, so configuration is
   confined to a small number of devices.  It is expected that at
   least one of the above options will be acceptable to IPv6 site
   administrators for the immediate future.


Business Motivation
   The primary business motivation is that it can be deployed
   immediately with a minimum of effort and cost, compared to
   other options.  As time progresses, the incentive to upgrade to
   either option (d) or a dynamic joining protocol is that the
   site would not be limited to the three basic options.


Standardization
   For immediate deployment, including option (d), nothing new is
   required.  For a longer-term optimal solution, an anycast-
   joining protocol is required.  It is expected that this would





Expires January 2002                                      [Page 8]


Draft                       DDDT Report               January 2002


   be done within the IPv6 Working Group as an extension to MLD.


Fate Sharing
   This mechanism exhibits good fate sharing properties.  No
   additional dependencies on any other devices, protocols, or
   processes exist, beyond those that are already required for
   performing actual name resolution using DNS (i.e., unicast
   reachability).


Convergence Time
   When a router or link fails, the convergence time is the
   convergence time of the unicast routing protocol in the site,
   if the server is off-link, or the convergence time of Neighbor
   Discovery if the server is on-link.  When a server fails, this
   is also the convergence time of DNS server discovery, but not
   for name resolution.  Since unicast is used for actual name
   resolution, a host with a list of DNS servers may converge
   faster to another DNS server it previously discovered, when a
   DNS server fails.


Scenarios
   This mechanism should work in all scenarios discussed.
   Specifically, it will work in the absence of routers and in the
   absence of multicast-capable media and routing protocols.


5.2.  Anycast for name resolution

Assign a well-known site-scoped anycast address to DNS servers.
Use anycast destination address on DNS queries.  Anycast packet
will eventually reach the topologically a closest DNS server.  DNS
server will send a reply.

While the other mechanisms evaluated try to obtain unicast IPv6
addresses of DNS servers, this approach uses anycast as the actual
name resolution transport.

Acquiring the domain name and search path must still be done as in
section 5.1 above, however.








Expires January 2002                                      [Page 9]


Draft                       DDDT Report               January 2002


5.2.1.  Configuration

Define a well-known site-scoped anycast address, and write it down
on a document.  Let us assume that it is fec0::9999 for now.

Configure clients to send DNS queries to the address.  The
configuration does not need to be modified even if the machine
moves from a site to another, as the anycast address is well-
known.

Configure DNS servers (server-1, server-2 to server-N) with the
anycast address, and make them reply the query to fec0::9999.
Make sure that packets with the anycast destination address get
routed to DNS servers.  (see a section below on this topic)

5.2.2.  Actual use

(1)  When a DNS name resolution is necessary for a client, the
     client would transmit a DNS query (usually UDP) toward
     fec0::9999.

     client -> fec0::9999    DNS query

(2)  The DNS query will reach one of the DNS servers (suppose it
     was "server-X").  The server will resolve the name by making
     a recursive query.  The server will send a reply to the
     client.  If we follow the RFC 2373 restriction that an
     anycast address cannot be used as a source address, we need
     to use server-X's unicast address as the source.  In this
     case, DNS clients should not check the source address of DNS
     replies.  Some existing implementations do this to check if
     the packet was really from the server queried.  The check is
     rather weak, however, as it is easy to spoof the source
     address.  Instead, DNSSEC should be used here.

     server-X -> client  DNS reply

5.2.3.  Evaluation

Note that there are multiple ways to handle anycast routing in a
site.  Some of them require us to inject a /128 route into the
routing system, some of them does not.

Scalability
   The scalability of the proposal is exactly the same as the





Expires January 2002                                     [Page 10]


Draft                       DDDT Report               January 2002


   scalability implication in anycast routing.  Note that, as the
   proposal uses a site-scoped anycast address, we need to scale
   up to a single site - we do not need to scale up to the whole
   Internet.

   Regarding to the site network size, the approach should have no
   problem, except the possible delay imposed by extra hops
   between DNS clients and servers.

   Regarding to the impact from the number of possible DNS servers
   to the site routing system, there should be no problem.  Even
   if we are to inject a /128 route to the site routing system, we
   will have a single extra routing entry on site routers.  As we
   share a single site-scoped anycast address among the DNS
   servers, we just need to carry a single /128 route in the site
   routing system.

   Regarding to the load balancing among DNS servers, it depends
   on (1) the network topology in the site, (2) where the DNS
   servers are located, (3) where the DNS clients are located, and
   (4) the anycast routing mechanism we use.  If we need to
   implement a perfect load balancing among DNS servers (equal
   load onto each DNS servers), we should just put DNS servers
   onto a single IPv6 subnet.  Neighbor discovery for anycast
   address should take care of it.  Refer to [ND], section 7.2.7.

   There is no impact against the worldwide routing system.


Security
   The security issues with this mechanism are the same as those
   discussed in section 5.1.

Time to Deploy
   The proposal is based on standardized mechanisms, including
   anycast, routing protocols (like RIPng) and DNS lookup over
   IPv6.  This is just a matter of configuration to deploy this
   proposal.

   There are widely-deployed implementations that support anycast
   address assignment.  There are many IPv6 routing protocol
   implementations.

   As for DNS lookup over IPv6, there are servers (including ISC
   BIND9) and clients (including BIND9, NetBSD, OpenBSD, FreeBSD,





Expires January 2002                                     [Page 11]


Draft                       DDDT Report               January 2002


   and Linux) that support it.

   The use of TCP with anycast needs more study (spec-wise), so
   DNS query/reply over IPv6 TCP may need some time to deploy.

   Regarding to the sanity checks made by DNS client
   implementation, BIND-based implementation has a configurable
   option to turn off the source address validation on the DNS
   reply packet.

   To deploy this proposal, there is no requirement to run
   additional servers.

Business Motivation
   If there are operating system implementations without anycast
   support, we apparently cannot use the operating system
   implementation as a DNS server.  If there are commercial
   operating systems that do not support anycast, they now have a
   good motivation to support it.

Standardization
   As the proposal uses DNS as the content format, it is safe to
   say that the content is standardized well.

   We already have couple of standardized IPv6 routing protocols.
   So even if we are to use routing protocol to inject a /128
   route for the DNS server anycast address, there should be no
   problem.

   For full discussions on anycast routing, refer to [ADDRARCH]
   and [ITOJUN-ANYCAST].

Fate Sharing
   As DNS queries use site-scoped anycast address as the
   destination, DNS query/reply relies upon anycast routing
   mechanism.  There is no circular dependency between anycast
   routing and DNS lookups.

Convergence Time
   There are couple of possible configurations for anycast packet
   delivery.

   If we run anycast DNS servers on routers, the convergence time
   will be the same as the router failure recovery time.  When a
   router with DNS server dies, we need to wait until another





Expires January 2002                                     [Page 12]


Draft                       DDDT Report               January 2002


   router to take it over.

   If we inject /128 routes onto the site routing system for
   anycast packet delivery, the convergence time will depend on
   the routing information propagation time of the site routing
   system.

   As to partial failure (like DNS server daemon died but the
   operating system is alive), there are many failure modes to
   mention and there are many implementation dependencies.
   Implementers may need to diagnose partial failure modes in
   detail.

Scenarios
   This mechanism should work in all scenarios discussed.


5.3.  Link-scoped multicast with router-only responses

This transport approach is modeled after IPv6 Neighbor Discovery
[ND] transport mechanisms.  It could be part of [ND] or another
protocol using a similar transport mechanism.

This approach has two modes.  The first is routers periodically
advertise DNS information (e.g., DNS server addresses, default
domain, and search path) to all nodes on a link by sending an
advertisement to the all nodes link-scope multicast address (i.e.,
FF02::1 ).

The second mode is that nodes needing DNS information can send a
solicitation to the all routers link-scope multicast address
(e.g., FF02::2) requesting DNS information.  Routers with the DNS
information will respond with an advertisement with the requested
DNS information.  This advertisement will be sent to the unicast
address of the node sending the solicitation.


5.3.1.  Evaluation

Scalability
   This transport approach has excellent scalability.  It scales
   as well as ND and DNS does currently.  All of the multicast
   traffic is local to the link. The periodic advertisement rates
   can be tuned to environment including turn it off completely
   and relying on the solicitation/advertisement mode.





Expires January 2002                                     [Page 13]


Draft                       DDDT Report               January 2002


   ND transport mechanisms work on a variety of link (e.g.,
   multicast capable, point-to-point, shared media, etc.).  It
   will well suited for both wired and wireless links.


Security
   Mechanisms that are being developed to authenticate ND can be
   applied to this approach as well.  The only preconfiguration is
   done in routers where the DNS information is held.

   No new security issues are raised.  All of the traffic is link-
   scoped.  Any attacks require link access and if successful only
   affect nodes on the individual link.


Time to Deploy
   This approach requires implementation in nodes wishing to learn
   DNS information and in routers to provide the information.  The
   router will need to be configured with the DNS information
   needed in the advertisements.

   If done as an extension to ND, it will be a small amount of
   work to extend the ND implementation to add the additional
   functionality.  If done in a new protocol it would be more
   difficult to create the new protocol.

   It should be possible to deploy it quickly once the details are
   scoped out and the implementations are developed.  There is no
   new network wide services such as multicast or anycast that
   need to be deployed.  There are no dependencies with other
   protocols.


Business Motivation
   This approach is a simple extension to existing protocols in
   existing products and there should be ample motivation to add
   it to existing products.  No complex dependencies are created.
   No new network transport mechanisms (e.g., anycast) are
   required.  No network operators have to deploy any new
   transport mechanisms (e.g., multicast and/or anycast).


Standardization
   A single document would have to be written to describe an
   extension to ND or a new protocol.  This would have to become





Expires January 2002                                     [Page 14]


Draft                       DDDT Report               January 2002


   an IETF standard.  This is within the scope of the IPng working
   group.  No other IETF working groups would need to be involved.


Fate Sharing
   The only fate sharing issue raised is that it ties the
   discovery of DNS information with the operation of routers on a
   link.  This is very similar to the common practice with IPv4 of
   using Bootp relays in routers to communicate with DHCP servers,
   so in practical terms the issue is very small.

   No changes are made to DNS servers or way nodes communicate
   with DNS servers.


Convergence Time
   Convergence time is similar to current IPv4 DNS operation using
   DHCP for DNS discovery. No new convergence issues are created.
   If one of a set of DNS servers is unavailable (e.g., down,
   isolated, etc.), then normal DNS recover mechanisms will select
   an alternative DNS servers.

   If one of a set of routers is unavailable, other routers on the
   link will continue providing the DNS information.

   If the last DNS server is unavailable, then it is down.  If the
   last router is unavailable, then new nodes will not be able to
   learn DNS information or reach any DNS server through the
   router.


Scenarios
   This mechanism works over a broad range of scenarios.  It
   should work as well on links that are high performance (e.g.,
   LANs) and low performance (e.g., wireless).

   However, this mechanism relies on routers and does not support
   DNS servers on isolated links.  Other local DNS server
   discovery mechanisms (e.g., multicast DNS) would be needed.
   This approach is believed to be compatible with multicast DNS
   approach being developed in the IETF.

   It can be used in either a periodic multicast advertisement, or
   a solicitation/advertisement mode.






Expires January 2002                                     [Page 15]


Draft                       DDDT Report               January 2002


5.4.  Link-scoped multicast (with router assist)

In this approach, devices send a request to a (new) well-known
link-scoped multicast address.  DNS servers and routers both
listen to this multicast address.  If any DNS servers exist on the
list, they can respond directly to the host.

In addition, routers are responsible for using some other
mechanism to obtain the DNS server list (e.g., one of the other
mechanisms evaluated in this document).  Routers with the DNS
information will respond with an advertisement with the requested
DNS information.


5.4.1.  Evaluation

Scalability
   This mechanism scales fine on each individual link.  The
   scalability across the site depends on the scalability of the
   inter-router mechanism used.


Security
   The use of multicast is vulnerable to the same attacks as
   unicast.  This mechanism can best be authenticated by having
   the content signed via a content-specific mechanism.

   It may be possible to use IPsec to authenticate the discovery
   messages, but IKE cannot be used for multicast transmission.
   As a result, barring future research and development of other
   key distribution protocols, using IPsec instead of a content-
   specific mechanism would require manual keying.

   In contrast to the anycast approaches, it is not strictly
   necessary to secure the mechanism used to communicate multicast
   joins from DNS servers to routers, since a rogue server cannot
   redirect traffic to itself that would otherwise reach a valid
   server.


Time to Deploy
   This approach can be deployed by devices immediately, as link-
   scoped multicast is already ubiquitous.  However, the time to
   deploy router assist to discover off-link servers depends on
   the inter-router mechanism chosen.





Expires January 2002                                     [Page 16]


Draft                       DDDT Report               January 2002


Business Motivation
   No strong business case for choosing this mechanism over the
   others evaluated is known.


Standardization
   Nothing new is required, beyond whatever is required for the
   content mechanism and the inter-router mechanism.


Fate Sharing
   Good fate sharing is preserved in this partial mechanism, as no
   additional dependencies on other devices or protocols is
   introduced, beyond whatever is required for the inter-router
   mechanism.


Convergence Time
   The convergence time depends on the convergence time of the
   inter-router mechanism used.


Scenarios
   This mechanism works on an isolated link, and can work in the
   absence of multicast routing (provided a non-multicast inter-
   router mechanism is used).

   However, it does not support the NBMA link scenario.


5.5.  Site-scoped multicast

Site-scoped multicast could be used to discover all DNS servers
within a site.  This would be analogous to the way multicast is
currently used by IPv6 hosts to discover their neighboring
routers, but over the span of a site rather than just a single
link.

There are several possible ways for site-scoped multicast to be
used for DNS (or any other) server discovery.  The clients could
send multicast query packets to a well-known, site-local, "all-
site-DNS-servers" multicast address, to which all DNS servers
would listen and respond.  Alternatively, the servers themselves
could send periodic multicast advertisement packets to a well-
known, site-local, "all-site-DNS-clients" multicast address, to





Expires January 2002                                     [Page 17]


Draft                       DDDT Report               January 2002


which all clients would listen in order to discover the presence
and address(es) of all of the site's DNS servers.  Probably the
best approach, from the point of view of responsiveness, scaling,
and traffic volume is to use both of those techniques in
combination, exactly as they are used for router discovery, as
follows:


o  Two well-known, site-local scoped, multicast addresses are
   assigned by IANA, one for all-site-DNS-routers and one for all-
   site-DNS-clients.


o  When a DNS server starts up, it multicasts a small number (say,
   3) of advertisement messages to the all-site-DNS-clients
   address at short (sub-second) intervals, and then continues to
   retransmit the advertisement messages but at much larger
   intervals (30 seconds or more).  It also sends a unicast
   response to any (unicast or multicast) DNS discovery query
   message it receives.


o  When a client starts up (or when the first attempt to perform a
   DNS look-up occurs), if the client has not yet heard any
   advertisements from DNS servers, it multicast up to a small
   number (say, 3) of query messages to the all-site-DNS-servers
   address at short (sub-second) intervals, stopping as soon as it
   receives a response from a DNS server or it reaches the small
   retransmission limit.  From that point on, the client does not
   send any multicast queries, but rather relies on passively
   discovering additional DNS servers (and DNS servers that fail
   and subsequently recover) by listening on the the all-site-DNS-
   clients address for advertisements.

The response and advertisement messages would ideally contain only
the address of the sending DNS (rather than a list of multiple DNS
servers, which which would impose an undesirable requirement for
configuration of, or a coordinating protocol among, the servers).
That one address could be found either in the Source Address field
of the IPv6 header or in the content of the message.  Clients
would build their lists of candidate DNS servers by taking the
union of the responses/advertisements received.

To avoid the need for additional packet exchanges, the response
and advertisement messages should also carry the other information





Expires January 2002                                     [Page 18]


Draft                       DDDT Report               January 2002


required by the client, i.e., the domain name and default domain
search list to be used by clients within the site.  [Open issue:
what ought a client to when not all DNS serves are advertising the
same information?]


5.5.1.  Evaluation

Scalability
   The recommended technique, above, imposes a steady-state
   traffic load on a site of one multicast packet per DNS server,
   every (30 second or greater) advertisement transmission
   interval.   Because almost all nodes would be expected to
   listen to those multicasts, they would effectively be site-wide
   broadcast messages.  However, note that the retransmission
   interval can safely be made quite large to minimize the
   overhead of those message, since the technique does not rely on
   a small interval for its responsiveness; rather, the periodic
   multicast advertisements serve the role of ensuring long-term
   consistency and recovering from rare failures (e.g., loss of
   three packets in a row, or site partitioning).

   In addition to the overhead of the periodic advertisements,
   there is also the small (maximum 3 packet) burst load of
   queries/ responses/advertisements that occur whenever a client
   or DNS server starts up.  Note that these costs are comparable
   to those incurred by the anycast techniques described in other
   sections.  They can also be further reduced by a more
   sophisticated design, in which queries and/or responses are
   delayed for small, randomized time intervals in order to do
   "suppression" of identical queries or responses that occur very
   close together, e.g., when a site comes up after a site-wide
   power-failure.

   Using this technique requires that all, or almost all, nodes
   within a site send multicast packets at some point or another.
   A multicast routing implementation that instantiated state for
   every active multicast source node would have a state cost on
   the order of the number of nodes in the site.  It may be
   preferable to use a multicast routing protocol that
   instantiates state only for each active multicast source
   *subnet* (which is sufficient to support shortest-path
   multicast delivery), or for each multicast destination address
   (so-called "shared-tree" multicast, which does not try to
   achieve shortest-path delivery, which is not important for this





Expires January 2002                                     [Page 19]


Draft                       DDDT Report               January 2002


   particular application).


Security
   The security evaluation for all types of multicast is discussed
   in section 5.4.1.


Time to Deploy
   It is expected that most sites will not have site-wide
   multicast deployed in the near-term future.  As a result, it
   may be some time before a site-scoped multicast solution could
   be deployed.


Business Motivation
   Given the perceived extra cost of managing a multicast-enabled
   infrastructure, when other solutions relying only on unicast
   routing exist, it is expected that no strong business case for
   choosing site-scoped multicast exists.


Standardization
   Protocols needed for multicast connectivity are already on the
   standards track, or in progress.


Fate Sharing
   This mechanism places an extra dependency on the correct
   functioning of the multicast routing system.  There are no
   dependencies on any extra devices, however, beyond those that
   are already required for name resolution.


Convergence Time
   When a router or link fails, the convergence time is the
   convergence time of the multicast routing protocol in the site.
   When a server fails, this is also the convergence time of DNS
   server discovery, but not for name resolution.  Since unicast
   is used for actual name resolution, a host with a list of DNS
   servers may converge faster to another DNS server it previously
   discovered, when a DNS server fails.








Expires January 2002                                     [Page 20]


Draft                       DDDT Report               January 2002


Scenarios
   This mechanism works on an isolated link with a DNS server but
   no routers.

   However, it does not work in a site with no multicast routing
   enabled, or among hosts connected over an NBMA link.


5.6.  Hybrid

It is possible to combine the above approaches in some situations.
For example, the option for link-scoped multicast with router
assist requires one of the other options to form a complete
solution.

It is also possible for one of the above mechanisms to be the
default, but allow use of one of the other mechanisms based on
local manual configuration, or on configuration obtained
information obtained from say Router Advertisements.  Of course,
if routers can distribute the address to use for discovery, then a
router which does not have multicast routing enabled must not
distribute a site-scoped multicast address.

The disadvantage with router overrides is that devices must be
prepared to handle multiple mechanisms, increasing the complexity
of the implementations.


6.  Message Content Mechanisms

6.1.  DHCP

In this mechanism, the messages sent to DNS servers are DHCP-
format messages, and the DNS servers send DHCP messages in
response.

The domain name can be obtained by having the DNS server include a
Domain Name option in the response.  A DHCP option to obtain a
domain search path [DOMSEARCH] is currently being discussed in the
DHC WG.  Without this option, the search path behavior would be no
different from the behavior today, where the search path is simply
computed based on the domain name obtained.  A list of DNS servers
would also require a new DHCP option, which is already required if
DHCP for IPv6 is to be implemented.






Expires January 2002                                     [Page 21]


Draft                       DDDT Report               January 2002


6.1.1.  Evaluation

Scalability
   Only one round trip of messages is required, and there is no
   need to run any additional servers.  In other respects, this
   mechanism has the same scalability properties as the underlying
   transport mechanism chosen.


Security
   A means of securing DHCP content that does not rely on IPsec
   has been proposed in the DHC Working Group [DHCPAUTH].


Time to Deploy
   This would require time to implement a DHCP parser in DNS
   servers.  In addition, DHCP for IPv6 is still being defined by
   the DHC Working Group.


Business Motivation
   Devices wanting to resolve names probably already have to
   implement a DHCP parser and be able to obtain DNS-related
   configuration information using DHCP messages.  As a result, it
   is expected that little extra work would be required by stack
   implementers beyond implementing DHCPv6.


Standardization
   The DHCP for IPv6 content format is still being defined by the
   DHC Working Group.


Fate Sharing
   Good fate sharing would require that DNS servers also implement
   a DHCP parser.  Otherwise, it is necessary to run a DHCP
   service on the DNS servers which simply responds to requests
   for DNS information.  In such a configuration, an additional
   dependency on the DHCP service would be introduced by this
   mechanism.


Convergence Time
   This mechanism has the same convergence time as the underlying
   transport mechanism chosen.





Expires January 2002                                     [Page 22]


Draft                       DDDT Report               January 2002


Scenarios
   This mechanism works in the same scenarios as the underlying
   transport mechanism chosen.


6.2.  DNS

DNS itself can be used, as long as the transport mechanism ensures
that discovery messages reach DNS servers, to obtain the DNS
server list, default domain name, and domain search path.

DNS has many record types that could be used.  For example, SOA
and NS records contain relevant information.  However, the name
resolution configuration information which an administrator
desires that a host should use may not match the usual
configuration of the DNS server (e.g., might use a different
domain name).  Hence, using information encoded in separate
records is more flexible.  It is also desirable that an
administrator can give different configuration information to
hosts in different subnets, since this capability exists when a
DHCP server is present.

There are many ways to accomplish the above.  On the query side,
the subnet prefix can be encoded in the hostname part of the
query.  On the response side, the server list, domain name, and
search path can be encoded in the response, potentially using SRV
records [SRV] with a special encoding, or using TXT records [TXT],
or even defining a new record type.



6.2.1.  Evaluation

Scalability
   The mechanism has one round trip to the DNS server and the
   security overhead.  Using Secret Keys, if possible, will
   produce no more packets, but some processing on the DNS server
   to match the clients secret key using [TSIG].  Using Diffie-
   Hellman with [DNSSEC], if many clients attempt this at the same
   time will put extreme processing demands on the DNS server.
   But it is doubtful that one or a few DNS Servers will handle
   1000's of clients.  See Security Evaluation below.

Security
   If the client can preconfigure a well known private or public





Expires January 2002                                     [Page 23]


Draft                       DDDT Report               January 2002


   key then TSIG or 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.

Time to Deploy
   This mechanism can be deployed now.  If the address provided to
   the Client is an Anycast address then resolver implementations
   would have to not use the present mechanisms to verify the
   source address of a QUERY response is equivalent to the
   destination address of the QUERY to the DNS Server.  Likewise
   for Multicast DNS.

Business Motivation
   All DNS suppliers are now implementing TSIG and DNSSEC.  The
   biggest business motivation for this mechanism is that it
   requires the least new code of any of the mechanisms evaluated,
   and provides the greatest robustness since there are no
   dependencies on other protocols or services.

Standardization
   If SRV or TXT records are used, there is no standardization
   required other than the specific mechanism document in the IPv6
   Working Group.  If a new record type is required, the DNSEXT
   Working Group would be involved.

Fate Sharing
   There are no dependencies on other than the normal DNS
   processes implemented today, nor are there any new dependencies
   created from these content messages.

Convergence Time
   There is no degradation in convergence time with this content
   set of messages, other than awaiting for a failed network to
   respond again or a DNS Server(s) to come back up after reboot.
   Once the resolver has done the DNS queries the knowledge from
   the server on most implementations becomes stateful and stored
   to non-volatile storage.  In the case of embedded systems with
   no non-volatile storage the DNS Server address would have to be
   relearned.

Scenarios
   This mechanism should work in all scenarios discussed.





Expires January 2002                                     [Page 24]


Draft                       DDDT Report               January 2002


6.3.  Node Information Query

ICMPv6 node information query [NODEINFO] provides a way to query
IPv6 addresses assigned to a machine.  This could be used to query
IPv6 unicast address for a DNS server, from a DNS server IPv6
anycast/multicast address.

To get a local domain name and search path, new query types
(QTypes) would need to be defined for these information types.

6.3.1.  Evaluation

Scalability
   As ICMPv6 node information query will be handled by the DNS
   server node itself, there is no need for running an additional
   server.  This mechanism has the same scalability properties as
   the underlying transport mechanism chosen.


Security
   IPsec is the only way to prevent malicious packets.  It depends
   on the actual transport protocol used with ICMPv6 node
   information query, if IPsec is usable or not.  For example, it
   is rather hard to use IPsec with anycast/multicast, so IPsec
   may not work well if we use anycast/multicast.


Time to Deploy
   While there exist some implementations of node information
   queries, implementation is not ubiquitous.


Business Motivation
   There does not seem to be any strong business motivation for
   implementing a node information query parser, in preference to
   other options.


Standardization
   The ICMPv6 node information query has not made it to RFC status
   yet, but is owned by the IPv6 Working Group.


Fate Sharing
   Depends on how we combine this with other mechanisms, and





Expires January 2002                                     [Page 25]


Draft                       DDDT Report               January 2002


   transport protocols.


Convergence Time
   Depends on how we combine this with other mechanisms, and
   transport protocols.


Scenarios
   This mechanism should work in all scenarios in which the
   transport mechanism works.


6.4.  RA Extensions

The basic approach is to define a new ND option that would contain
the DNS information.  Existing ND transport mechanisms (i.e.,
advertisements and solicitations) mechanisms would be used.  This
would work in the same way that nodes learn about routers and
prefixes, etc.

A ND new option would be defined that routers could send in router
advertisements.


This approach has two modes of operation.  The first is routers
periodically send the DNS Configuration Option in their periodic
router advertisements.

The second mode is that nodes needing DNS information can send a
solicitation to the routers on the link requesting the DNS
Configuration options.

This approach has an issue that the DNS information needs to be
configured in the routers doing the advertisements.  There are
several approaches to this:


a) Many routers may already have most of this information
   configured.  Routers also function as hosts and may have DNS
   server addresses, default domain, and list of domains to search
   in their configuration file.  For example, Cisco IOS [IOS] has
   the following commands:







Expires January 2002                                     [Page 26]


Draft                       DDDT Report               January 2002


   ip domain-name name
      Define a default domain name that the Cisco IOS software
      will use to complete unqualified host names.


   ip domain-list name
      Define a list of default domain names to complete
      unqualified host names.


   ip name-server server-addr1 [server-addr2...server-addr6]
      Specify one or more hosts that supply name information.

   At least in the case of Cisco routers, and probably most
   others, no additional work is needed to add the DNS information
   to the routers.


b) The next approach, that is consistent with current router
   management practice, is to configure the router manually with
   the DNS information that they would advertise w/ IPv6 ND.  This
   could be done by CLI commands as shown above and/or by other
   mechanisms normally used to configure routers (e.g., web
   interfaces, proprietary tools, etc.)

   The work to implement this is minor and part of implementation
   the feature in the router.  No new management/distribution
   protocols.


c) The next approach, also consistent with current router
   management practice, is that the router configuration files are
   created centrally and remotely installed on the router.  This
   is done today with a mix to special tools, text editors, pearl
   scripts, vendor management systems, etc.  It is very common
   practice to create files of CLI commands and push them to the
   routers.  No new management and/or distribution protocols are
   required.


d) Create or extend an SNMP MIB (do we have an ND MIB?) that
   contains this information and use existing management tools to
   set the information in the router.  Also common practice and no
   new management/distribution protocols.  A MIB is required and
   extensions to management tools to support the new variables.





Expires January 2002                                     [Page 27]


Draft                       DDDT Report               January 2002


e) Extend Router Renumbering (RR) to contain this information and
   use it to advertise it to the routers.  This is mostly
   consistent with what RR does and allows control reasonable fine
   grained control of to allow different information per router or
   even per interface.

Without changing the intended usage of Router Advertisements, the
natural transport mechanism used would be Link-scoped multicast
with router-only response.


6.4.1.  Evaluation

Scalability
   This mechanism has excellent scalability properties.  It scales
   as well as ND and DNS does currently.  All of the multicast
   traffic is local to the link. The periodic advertisement rates
   can be tuned to environment including turn it off completely
   and relying on the solicitation/advertisement mode.


Security
   ND does not currently have authentication mechanisms built in,
   but there is ongoing work to investigate using AH with ND.
   This approach would use what ever solution is selected for ND
   authentication.


Time to Deploy
   This approach requires implementation in nodes wishing to learn
   DNS information and in routers to provide the information.  The
   router will need to be configured with the DNS information
   needed in the advertisements.

   It is a relatively minor amount of work to add a new option to
   an existing router and/or node implementations of ND.  It
   should be possible to deploy it quickly once the details are
   scoped out and the implementations are developed.  There is no
   new network wide services such as multicast or anycast that
   need to be deployed.  There are no dependencies with other
   protocols.


Business Motivation
   The business motivation is very good.  The implementation,





Expires January 2002                                     [Page 28]


Draft                       DDDT Report               January 2002


   documentation, and support cost are minor and very much in line
   with existing ND features.  There are no new protocols and/or
   transports to deploy, document, and support.

   Devices wanting to discover DNS servers already have to have an
   RA parser in them.  It is expected that implementors would find
   it easier to extend an existing parser than to add a new
   parser.


Standardization
   This mechanism would require a new RA option format to be
   standardized.  This would be done by the IPv6 Working Group.


Fate Sharing
   The only fate sharing issue raised is that it ties the
   discovery of DNS information with the operation of routers on a
   link.  This is very similar to the common practice with IPv4 of
   using Bootp relays in routers to communicate with DHCP servers,
   so in practical terms the issue is very small.

   No changes are made to DNS servers or way nodes communicate
   with DNS servers.


Convergence Time
   Convergence time is similar to current IPv4 DNS operation using
   DHCP for DNS discovery. No new convergence issues are created.
   If one of a set of DNS servers is unavailable (e.g., down,
   isolated, etc.), then normal DNS recover mechanisms will select
   an alternative DNS servers.

   If one of a set of routers is unavailable, other routers on the
   link will continue providing the DNS information.

   If the last DNS server is unavailable, then it is down.  If the
   last router is unavailable, then new nodes will not be able to
   learn DNS information or reach any DNS server through the
   router.


Scenarios
   This mechanism works over a broad range of scenarios.  It
   should work as well on links that are high performance (e.g.,





Expires January 2002                                     [Page 29]


Draft                       DDDT Report               January 2002


   LANs) and low performance (e.g., wireless).

   However, this mechanism relies on routers and does not support
   DNS servers on isolated links.  Other local DNS server
   discovery mechanisms (e.g., multicast DNS) would be needed.
   This approach is believed to be compatible with multicast DNS
   approach being developed in the IETF.

   It can be used in either a periodic multicast advertisement, or
   a solicitation/advertisement mode.


6.5.  SLP

The Service Location Protocol [RFC 2608] provides a general
framework for service discovery.  Services are modeled on the
basis of their type, location, and a set of attributes.

Clients use SLP to request services on the basis of the attributes
required and retrieve both the location and attributes of all
services fulfilling the request.  In the case of DNS server
discovery, a DNS client could discover the location, domain name
and search path to use, all in one message round trip
(SrvRqst/SrvRply) if the Attribute List Extension is used, or two
round trips (SrvRqst/SrvRply, AttrRqst/AttrRply) if the Attribute
List extension is not supported.

Without changing the basic SLPv2 protocol, the natural transport
mechanism used would be Site-scoped multicast.


6.5.1.  Evaluation

Scalability

   This mechanism has the same scalability properties as the
   underlying transport mechanism chosen.


Security
   SLPv2 provides its own security so that those who obtain
   service location and attribute information can verify the
   signature over it.  These digital signatures are calculated
   using keys which are distributed by some external mechanism
   (SLPv2 does not provide mechanisms for cryptographic key





Expires January 2002                                     [Page 30]


Draft                       DDDT Report               January 2002


   distribution).


Time to Deploy
   SLPv2 for IPv6 is not yet a proposed standard.  It will shortly
   enter IETF last call.

   There are no IPv6 SLPv2 implementations yet.  SLPv2 over IPv4
   has been implemented by many vendors and is used for a variety
   of purposes.


Business Motivation
   Rather than each protocol supplying its own service discovery
   protocol, SLP can provide a general purpose mechanism which
   will minimize the software required and allow for common
   operational considerations and management.


Standardization
   SLPv2 is a Proposed Standard.  SLPv2 over IPv6 and the
   Attribute List Extension are both about to enter IETF last call
   before being advanced to Proposed Standard.


Fate Sharing
   SLP would require an additional protocol to be used to
   configure DNS resolvers - namely, a SLP user agent library.
   DNS servers would need to be advertised using a SLP service
   agent - this functionality could be provided by a library
   invoked by a DNS server, or by an additional service running on
   the DNS server host (although this is more complicated and less
   assured of not advertising the DNS server when it is in fact
   not available).


Convergence Time
   If no directory agents are deployed, convergence time is on the
   order of milliseconds:  the only way that a DNS resolver could
   discover a DNS server which was not available would be if the
   DNS server failed after answering that it was available.

   If directory agents are available, convergence depends on the
   soft state registration lifetime - which could be of any
   granularity on the order of seconds - but typically is on the





Expires January 2002                                     [Page 31]


Draft                       DDDT Report               January 2002


   order of minutes.  During this interval it is possible for a
   client to discover a service which has gone off line since the
   service location has been cached by a directory agent
   temporarily.


Scenarios

   o  Isolated link with a DNS server but no routers

      SLP requests multicast on the link would enable DNS clients
      to directly discover DNS servers, domain name and search
      path.

      The DNS clients and servers would have to make use of a SLP
      library to accomplish this.  Another alternative is a
      service advertising process co-resident on the DNS server
      host which advertises the DNS server on its behalf.  In this
      case, no modification of the DNS server would be necessary.


   o  Site with routers, but no multicast routing enabled

      Routers use SLP to discover DNS servers on attached links.
      The routers can then use other mechanisms to distribute the
      location of the DNS servers (add an anycast routing entry
      for each DNS server, send extensions to routing
      advertisements, etc.)

      DNS clients could use link-scoped multicast SLP discovery,
      and routers could answer these requests on behalf of DNS
      servers.  The problem with this approach is that it does not
      specify the way in which DNS server locations are propagated
      between routers.

      Thus, SLP can be used as a mechanism to provide dynamic and
      decentralized service discovery for the system, but only
      between the routers and the DNS servers.  The mechanism
      between the routers to propagate DNS service locations would
      have to be satisfied by some additional protocol (such as
      OSPF extensions).

      In summary, a link-scoped multicast with router-assist
      transport mechanism would be needed in this scenario.






Expires January 2002                                     [Page 32]


Draft                       DDDT Report               January 2002


   o  NBMA Link

      This scenario could not be supported without changing the
      SLP protocol to work with anycast addresses.  However, it is
      not expected that this is a very important scenario.


6.6.  Something New

Any number of other mechanisms (e.g., HTTP, SNMP, etc.)  could
also be extended, but it is expected that any other mechanism
would take at least as long to deploy, and have no significant
advantage over the other mechanisms evaluated above.


7.  Recommendations

Based on team discussion, and WG consensus at IETF 49, the
recommendation for transport mechanism is to use site-scoped
anycast.  That is, IANA should allocate a well-known site-local
anycast address for DNS servers.

No specific recommendation is made regarding using anycast for
discovery-only or for actual name resolution.  However, we observe
that choice can be made by individual sites as follows.  Nodes
will use the anycast address to discover DNS-specific information
such as the domain name, search path, and DNS server list.  If the
DNS server list contains just the anycast address itself, the
anycast address will also be used for name resolution.

Based on subsequent team discussion, the recommendation to the WG
regarding the content mechanism is to use DNS.  That is, the
recommendation is that the WG should define the details of how the
DNS server list, domain name, and search path, can be encoded in
DNS records.  The team's initial recommendation is that the IPv6
WG investigate whether SRV records are sufficient, and if not,
then either TXT records or a new record type should be used.  It
is believed that the information should and can be encoded in a
single response message.

Finally, it is recommended that the "Other stateful configuration"
flag in the Router Advertisement be used to control whether to use
DHCP or this mechanism.  That is, the analysis and recommendations
in this document apply only to links where the "Other stateful
configuration" flag is zero.





Expires January 2002                                     [Page 33]


Draft                       DDDT Report               January 2002


8.  Appendix A: Summary Grid

Figure 1 summarizes information on transport mechanisms:

                 |Any(Disc)|Any(Res)|LnkM(Rtr)|LnkM(Gen)|SiteM
-----------------+---------+--------+---------+---------+---------
SW upgrades      |-/S/SR   |-/S/SR  |R        |R        |UR
-----------------+---------+--------+---------+---------+---------
Reconfig changes |S        |-       |R        |S        |-
-----------------+---------+--------+---------+---------+---------
New dependencies |-        |-       |router,  |linkmcast|multicast
                 |         |        |linkmcast|         |routing,
                 |         |        |         |         |linkmcast
-----------------+---------+--------+---------+---------+---------
Convergence time |fast     |per-rtg |fast     |fast     |fast
-----------------+---------+--------+---------+---------+---------
Can use IKE      |no       |no      |no       |no       |no
-----------------+---------+--------+---------+---------+---------
Standards work   |-/ipngwg |-/ipngwg|ipngwg   |ipngwg   |-
-----------------+---------+--------+---------+---------+---------
Deployable "now" |yes      |yes     |no       |no       |no
-----------------+---------+--------+---------+---------+---------

              Figure 1: Transport Mechanism Summary

Key:
 / separates multiple deployment options
 - = No devices
 S = All DNS servers
SR = All routers with directly-connected DNS servers
UR = All routers which don't have multicast routing implemented
 R = All routers

SW upgrades = what boxes, other than devices wanting to discover
DNS servers, require software upgrades?

Reconfig changes = what boxes need to be reconfigured when the set
of DNS servers changes?

New dependencies = what new dependencies are added?

Convergence Time = how long does it take to contact a new DNS
server when a server/link/router fails?  "Fast" = a device can
immediately use an alternate server if reachable.  "Per-rtg" =
Device must wait until routing converges for the unreachable





Expires January 2002                                     [Page 34]


Draft                       DDDT Report               January 2002


address.

Can use IKE = can IKE be used for key negotiation?

Standards work = what WGs would be required to standardize new
items?

Deployable "now" = could a new client using this mechanism be
deployed immediately, without requiring implementation of new code
for routers or servers?

Figure 2 summarizes information on content mechanisms:

                  |DHCP      |DNS      |NIQ      |RA       |SLP
------------------+----------+---------+---------+---------+---------
Round trips used  |1         |1        |1        |1        |1
------------------+----------+---------+---------+---------+---------
Has own signatures|yes       |yes      |-        |no       |yes
------------------+----------+---------+---------+---------+---------
Has own key dist  |-         |yes      |-        |-        |-
------------------+----------+---------+---------+---------+---------
Standards work    |dhc       |dnsext?  |ipngwg   |ipngwg   |svrloc
------------------+----------+---------+---------+---------+---------
Need addl parser  |in servers|-        |yes      |-        |yes
------------------+----------+---------+---------+---------+---------
Generalizable     |yes       |yes      |yes      |-        |yes
------------------+----------+---------+---------+---------+---------
Deployable "now"  |no        |yes      |no       |no       |no
------------------+----------+---------+---------+---------+---------

               Figure 2: Content Mechanism Summary

Round trips used = How many round trips are required?

Has own signatures? = Does the content have its own signature
facility?  (a "no" means it relies on IPsec)

Standards work = what WGs would be required to standardize new
items?

Need addl parser = besides any parsers that a device must already
implement to perform basic name resolution, does the mechanism
introduce a requirement for another parser?

Generalizable = can the mechanism be generalized to allow





Expires January 2002                                     [Page 35]


Draft                       DDDT Report               January 2002


discovery of other types of information or services?

Deployable "now" = could a new client using this mechanism be
deployed immediately, without requiring implementation of new code
for routers or servers?













































Expires January 2002                                     [Page 36]


Draft                       DDDT Report               January 2002


9.  Authors' Addresses

     Bernard Aboba
     Microsoft
     One Microsoft Way
     Redmond, WA 98052, USA
     Email: aboba@internaut.com

     Jim Bound
     Compaq Computer Corporation
     110 Spitbrook Road ZK3-3/U14
     Nashua, NH 03062-2698
     Email: bound@zk3.dec.com

     Steve Deering
     Cisco Systems, Inc.
     170 West Tasman Drive
     San Jose, CA 95134-1706, USA
     Email: deering@cisco.com

     Erik Guttman
     Sun Microsystems
     Bahnstr. 2
     74915 Waibstadt, Germany
     Email: erik.guttman@sun.com

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

     Robert M. Hinden
     Nokia
     313 Fairchild Drive
     Mountain View, CA 94043, USA
     Email: hinden@iprg.nokia.com

     Tatuya JINMEI
     Research and Development Center, Toshiba Corporation
     1 Komukai Toshiba-cho, Kawasaki-chi
     Kanagawa 212-8582
     Japan
     Email: jinmei@isl.rdc.toshiba.co.jp





Expires January 2002                                     [Page 37]


Draft                       DDDT Report               January 2002


     Atsushi Onoe
     Internet Systems Laboratory, IN Laboratories, Sony Corporation
     6-7-35 Kitashinagawa, Shinagawa-ku, Tokyo 141-0001
     Japan
     Email: onoe@sm.sony.co.jp

     Hesham Soliman
     Ericsson Australia
     61 Rigall St., Broadmeadows
     Melbourne, Victoria 3047
     Australia
     Email: Hesham.Soliman@ericsson.com.au

     David Thaler
     Microsoft
     One Microsoft Way
     Redmond, WA 98052, USA
     Email: dthaler@microsoft.com


10.  References

[ANYCAST]
     Partridge, C., Mendez, T., and W. Milliken, "Host Anycasting
     Service", RFC 1546, November 1993.

[ADDRARCH]
     Hinden, R., and S. Deering, "IP Version 6 Addressing
     Architecture", RFC 2373, July 1998.

[DHCPAUTH]
     Droms, R., and W. Arbaugh, "Authentication for DHCP
     Messages", draft-ietf-dhc-authentication-16.txt, January
     2001.

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

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

[DOMSEARCH]
     B. Aboba, "DHCP Domain Search Option", draft-aboba-dhc-





Expires January 2002                                     [Page 38]


Draft                       DDDT Report               January 2002


     domsearch-01.txt, December 2000.

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

[IOS]
     Cisco IOS Release 12.0 Configuration Guides,
     http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/12cgcr/cbkixol.htm

[ITOJUN-ANYCAST]
     Jun-ichiro Hagino and K. Ettikan, "An analysis of IPv6
     anycast", draft-itojun-ipv6-anycast-analysis-02.txt, February
     2001.

[MDNS]
     Esibov, L., Aboba, B., and D. Thaler, "Multicast DNS", draft-
     ietf-dnsext-mdns-00.txt, November 2000.

[ND] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery
     for IP Version 6 (IPv6)", RFC 2461, December 1998.

[NODEINFO]
     Matt Crawford, "IPv6 Node Information Queries", draft-ietf-
     ipngwg-icmp-name-lookups-07.txt, August 2000.

[RFC1034]
     P. Mockapetris, "Domain Names - Concepts and Facilities", STD
     13, RFC 1034, November 1987.

[RFC1035]
     P. Mockapetris, "Domain Names - Implementation and
     Specifications", STD 13, RFC 1035, November 1987.

[RIPMD5]
     Baker, F., and R. Atkinson, "RIP-2 MD5 Authentication", RFC
     2082, January 1997.

[RIPNG]
     Malkin, G., and R. Minnear, "RIPng for IPv6", RFC 2080,
     January 1997.

[SLPv2]
     Guttman, E., Perkins, C., Veizades, J., and M. Day, "Service
     Location Protocol, Version 2", RFC 2608, June 1999.





Expires January 2002                                     [Page 39]


Draft                       DDDT Report               January 2002


[SRV]
     Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
     specifying the location of services (DNS SRV)", RFC 2782,
     February 2000.

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

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

[TXT]
     R. Rosenbaum, "Using the Domain Name System To Store
     Arbitrary String Attributes", RFC 1464, May 1993.

































Expires January 2002                                     [Page 40]


Draft                       DDDT Report               January 2002


11.  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 Standards
process must be followed, or as required to translate it into
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 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR
PURPOSE."






















Expires January 2002                                     [Page 41]


Draft                       DDDT Report               January 2002



Table of Contents


1 Introduction ..............................................    2
2 Requirements ..............................................    2
3 Criteria for Evaluation ...................................    3
4 Taxonomy ..................................................    4
5 Transport Mechanisms ......................................    4
5.1 Anycast for DNS server discovery only ...................    4
5.1.1 Evaluation ............................................    7
5.2 Anycast for name resolution .............................    9
5.2.1 Configuration .........................................   10
5.2.2 Actual use ............................................   10
5.2.3 Evaluation ............................................   10
5.3 Link-scoped multicast with router-only responses ........   13
5.3.1 Evaluation ............................................   13
5.4 Link-scoped multicast (with router assist) ..............   16
5.4.1 Evaluation ............................................   16
5.5 Site-scoped multicast ...................................   17
5.5.1 Evaluation ............................................   19
5.6 Hybrid ..................................................   21
6 Message Content Mechanisms ................................   21
6.1 DHCP ....................................................   21
6.1.1 Evaluation ............................................   22
6.2 DNS .....................................................   23
6.2.1 Evaluation ............................................   23
6.3 Node Information Query ..................................   25
6.3.1 Evaluation ............................................   25
6.4 RA Extensions ...........................................   26
6.4.1 Evaluation ............................................   28
6.5 SLP .....................................................   30
6.5.1 Evaluation ............................................   30
6.6 Something New ...........................................   33
7 Recommendations ...........................................   33
8 Appendix A: Summary Grid ..................................   34
9 Authors' Addresses ........................................   37
10 References ...............................................   38
11 Full Copyright Statement .................................   41











Expires January 2002                                     [Page 42]


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