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]
