Request for Comments: 4339 ETRI/University of Minnesota
Category: Informational February 2006
IPv6 Host Configuration of DNS Server Information Approaches
Status of This Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2006).
IESG Note
This document describes three different approaches for the
configuration of DNS name resolution server information in IPv6
hosts.
There is not an IETF consensus on which approach is preferred. The
analysis in this document was developed by the proponents for each
approach and does not represent an IETF consensus.
The ’RA option’ and ’Well-known anycast’ approaches described in this
document are not standardized. Consequently the analysis for these
approaches might not be completely applicable to any specific
proposal that might be proposed in the future.
Abstract
This document describes three approaches for IPv6 recursive DNS
server address configuration. It details the operational attributes
of three solutions: RA option, DHCPv6 option, and well-known anycast
addresses for recursive DNS servers. Additionally, it suggests the
deployment scenarios in four kinds of networks (ISP, enterprise,
3GPP, and unmanaged networks) considering multi-solution resolution.
Table of Contents
1. Introduction ....................................................3
2. Terminology .....................................................3
3. IPv6 DNS Configuration Approaches ...............................3
3.1. RA Option ..................................................3
3.1.1. Advantages ..........................................4
3.1.2. Disadvantages .......................................5
3.1.3. Observations ........................................5
3.2. DHCPv6 Option ..............................................6
3.2.1. Advantages ..........................................7
3.2.2. Disadvantages .......................................8
3.2.3. Observations ........................................9
3.3. Well-known Anycast Addresses ...............................9
3.3.1. Advantages .........................................10
3.3.2. Disadvantages ......................................10
3.3.3. Observations .......................................10
4. Interworking among IPv6 DNS Configuration Approaches ...........11
5. Deployment Scenarios ...........................................12
5.1. ISP Network ...............................................12
5.1.1. RA Option Approach .................................13
5.1.2. DHCPv6 Option Approach .............................13
5.1.3. Well-known Anycast Addresses Approach ..............14
5.2. Enterprise Network ........................................14
5.3. 3GPP Network ..............................................15
5.3.1. Currently Available Mechanisms and
Recommendations ....................................15
5.3.2. RA Extension .......................................16
5.3.3. Stateless DHCPv6 ...................................16
5.3.4. Well-known Addresses ...............................17
5.3.5. Recommendations ....................................18
5.4. Unmanaged Network .........................................18
5.4.1. Case A: Gateway Does Not Provide IPv6 at All .......18
5.4.2. Case B: A Dual-stack Gateway Connected to a
Dual-stack ISP .....................................19
5.4.3. Case C: A Dual-stack Gateway Connected to
an IPv4-only ISP ...................................19
5.4.4. Case D: A Gateway Connected to an IPv6-only ISP ....19
6. Security Considerations ........................................19
6.1. RA Option .................................................20
6.2. DHCPv6 Option .............................................21
6.3. Well-known Anycast Addresses ..............................21
7. Contributors ...................................................21
8. Acknowledgements ...............................................23
9. References .....................................................23
9.1. Normative References ......................................23
9.2. Informative References ....................................23
1. Introduction
Neighbor Discovery (ND) for IP Version 6 and IPv6 Stateless Address
Autoconfiguration provide ways to configure either fixed or mobile
nodes with one or more IPv6 addresses, default routes, and some other
parameters [1][2]. To support the access to additional services in
the Internet that are identified by a DNS name, such as a web server,
the configuration of at least one recursive DNS server is also needed
for DNS name resolution.
This document describes three approaches of recursive DNS server
address configuration for IPv6 host: (a) RA option [6], (b) DHCPv6
option [3]-[5], and (c) well-known anycast addresses for recursive
DNS servers [7]. Also, it suggests the applicable scenarios for four
kinds of networks: (a) ISP network, (b) enterprise network, (c) 3GPP
network, and (d) unmanaged network.
This document is just an analysis of each possible approach, and it
does not recommend a particular approach or combination of
approaches. Some approaches may even not be adopted at all as a
result of further discussion.
Therefore, the objective of this document is to help the audience
select the approaches suitable for IPv6 host configuration of
recursive DNS servers.
2. Terminology
This document uses the terminology described in [1]-[7]. In
addition, a new term is defined below:
o Recursive DNS Server (RDNSS): Server which provides a recursive
DNS resolution service.
3. IPv6 DNS Configuration Approaches
In this section, the operational attributes of the three solutions
are described in detail.
3.1. RA Option
The RA approach defines a new ND option, called the RDNSS option,
that contains a recursive DNS server address [6]. Existing ND
transport mechanisms (i.e., advertisements and solicitations) are
used. This works in the same way that nodes learn about routers and
prefixes. An IPv6 host can configure the IPv6 addresses of one or
more RDNSSes via RA message periodically sent by a router or
solicited by a Router Solicitation (RS).
This approach needs RDNSS information to be configured in the routers
doing the advertisements. The configuration of RDNSS addresses can
be performed manually by an operator or in other ways, such as
automatic configuration through a DHCPv6 client running on the
router. An RA message with one RDNSS option can include as many
RDNSS addresses as needed [6].
Through the ND protocol and RDNSS option, along with a prefix
information option, an IPv6 host can perform network configuration of
its IPv6 address and RDNSS simultaneously [1][2]. The RA option for
RDNSS can be used on any network that supports the use of ND.
The RA approach is useful in some mobile environments where the
addresses of the RDNSSes are changing because the RA option includes
a lifetime field that allows client to use RDNSSes nearer to the
client. This can be configured to a value that will require the
client to time out the entry and switch over to another RDNSS address
[6]. However, from the viewpoint of implementation, the lifetime
field would seem to make matters a bit more complex. Instead of just
writing to a DNS configuration file, such as resolv.conf for the list
of RDNSS addresses, we have to have a daemon around (or a program
that is called at the defined intervals) that keeps monitoring the
lifetime of RDNSSes all the time.
The preference value of RDNSS, included in the RDNSS option, allows
IPv6 hosts to select primary RDNSS among several RDNSSes [6]; this
can be used for the load balancing of RDNSSes.
3.1.1. Advantages
The RA option for RDNSS has a number of advantages. These include:
1. The RA option is an extension of existing ND/Autoconfig
mechanisms [1][2] and does not require a change in the base ND
protocol.
2. This approach, like ND, works well on a variety of link types,
including point-to-point links, point-to-multipoint, and
multipoint-to-multipoint (i.e., Ethernet LANs). RFC 2461 [1]
states, however, that there may be some link types on which ND is
not feasible; on such links, some other mechanisms will be needed
for DNS configuration.
3. All the information a host needs to run the basic Internet
applications (such as the email, web, ftp, etc.) can be obtained
with the addition of this option to ND and address
autoconfiguration. The use of a single mechanism is more
reliable and easier to provide than when the RDNSS information is
learned via another protocol mechanism. Debugging problems when
multiple protocol mechanisms are being used is harder and much
more complex.
4. This mechanism works over a broad range of scenarios and
leverages IPv6 ND. This works well on links that are high
performance (e.g., Ethernet LANs) and low performance (e.g.,
cellular networks). In the latter case, by combining the RDNSS
information with the other information in the RA, the host can
learn all the information needed to use most Internet
applications, such as the web, in a single packet. This not only
saves bandwidth, but also minimizes the delay needed to learn the
RDNSS information.
5. The RA approach could be used as a model for similar types of
configuration information. New RA options for other server
addresses, such as NTP server address, that are common to all
clients on a subnet would be easy to define.
3.1.2. Disadvantages
1. ND is mostly implemented in the kernel of the operating system.
Therefore, if ND supports the configuration of some additional
services, such as DNS servers, ND should be extended in the
kernel and complemented by a user-land process. DHCPv6, however,
has more flexibility for the extension of service discovery
because it is an application layer protocol.
2. The current ND framework should be modified to facilitate the
synchronization between another ND cache for RDNSSes in the
kernel space and the DNS configuration file in the user space.
Because it is unacceptable to write and rewrite to the DNS
configuration file (e.g., resolv.conf) from the kernel, another
approach is needed. One simple approach to solve this is to have
a daemon listening to what the kernel conveys, and to have the
daemon do these steps, but such a daemon is not needed with the
current ND framework.
3. It is necessary to configure RDNSS addresses at least at one
router on every link where this information needs to be
configured via the RA option.
3.1.3. Observations
The proposed RDNSS RA option, along with the IPv6 ND and
Autoconfiguration, allows a host to obtain all of the information it
needs to access basic Internet services like the web, email, ftp,
etc. This is preferable in the environments where hosts use RAs to
autoconfigure their addresses and all the hosts on the subnet share
the same router and server addresses. If the configuration
information can be obtained from a single mechanism, it is preferable
because it does not add additional delay, and because it uses a
minimum of bandwidth. Environments like this include homes, public
cellular networks, and enterprise environments where no per host
configuration is needed.
DHCPv6 is preferable where it is being used for address configuration
and if there is a need for host specific configuration [3]-[5].
Environments like this are most likely to be the enterprise
environments where the local administration chooses to have per host
configuration control.
3.2. DHCPv6 Option
DHCPv6 [3] includes the "DNS Recursive Name Server" option, through
which a host can obtain a list of IP addresses of recursive DNS
servers [5]. The DNS Recursive Name Server option carries a list of
IPv6 addresses of RDNSSes to which the host may send DNS queries.
The DNS servers are listed in the order of preference for use by the
DNS resolver on the host.
The DNS Recursive Name Server option can be carried in any DHCPv6
Reply message, in response to either a Request or an Information
request message. Thus, the DNS Recursive Name Server option can be
used either when DHCPv6 is used for address assignment, or when
DHCPv6 is used only for other configuration information as stateless
DHCPv6 [4].
Stateless DHCPv6 can be deployed either by using DHCPv6 servers
running on general-purpose computers, or on router hardware. Several
router vendors currently implement stateless DHCPv6 servers.
Deploying stateless DHCPv6 in routers has the advantage that no
special hardware is required, and it should work well for networks
where DHCPv6 is needed for very straightforward configuration of
network devices.
However, routers can also act as DHCPv6 relay agents. In this case,
the DHCPv6 server need not be on the router; it can be on a general
purpose computer. This has the potential to give the operator of the
DHCPv6 server more flexibility in how the DHCPv6 server responds to
individual clients that can easily be given different configuration
information based on their identity, or for any other reason.
Nothing precludes adding this flexibility to a router, but generally,
in current practice, DHCP servers running on general-purpose hosts
tend to have more configuration options than those that are embedded
in routers.
DHCPv6 currently provides a mechanism for reconfiguring DHCPv6
clients that use a stateful configuration assignment. To do this,
the DHCPv6 server sends a Reconfigure message to the client. The
client validates the Reconfigure message, and then contacts the
DHCPv6 server to obtain updated configuration information. By using
this mechanism, it is currently possible to propagate new
configuration information to DHCPv6 clients as this information
changes.
The DHC Working Group has standardized an additional mechanism
through which configuration information, including the list of
RDNSSes, can be updated. The lifetime option for DHCPv6 [8] assigns
a lifetime to configuration information obtained through DHCPv6. At
the expiration of the lifetime, the host contacts the DHCPv6 server
to obtain updated configuration information, including the list of
RDNSSes. This lifetime gives the network administrator another
mechanism to configure hosts with new RDNSSes by controlling the time
at which the host refreshes the list.
The DHC Working Group has also discussed the possibility of defining
an extension to DHCPv6 that would allow the use of multicast to
provide configuration information to multiple hosts with a single
DHCPv6 message. Because of the lack of deployment experience, the WG
has deferred consideration of multicast DHCPv6 configuration at this
time. Experience with DHCPv4 has not identified a requirement for
multicast message delivery, even in large service provider networks
with tens of thousands of hosts that may initiate a DHCPv4 message
exchange simultaneously.
3.2.1. Advantages
The DHCPv6 option for RDNSS has a number of advantages. These
include:
1. DHCPv6 currently provides a general mechanism for conveying
network configuration information to clients. Configuring DHCPv6
servers in this way allows the network administrator to configure
RDNSSes, the addresses of other network services, and location-
specific information, such as time zones.
2. As a consequence, when the network administrator goes to
configure DHCPv6, all the configuration information can be
managed through a single service, typically with a single user
interface and a single configuration database.
3. DHCPv6 allows for the configuration of a host with information
specific to that host, so that hosts on the same link can be
configured with different RDNSSes and with other configuration
information.
4. A mechanism exists for extending DHCPv6 to support the
transmission of additional configuration that has not yet been
anticipated.
5. Hosts that require other configuration information, such as the
addresses of SIP servers and NTP servers, are likely to need
DHCPv6 for other configuration information.
6. The specification for configuration of RDNSSes through DHCPv6 is
available as an RFC. No new protocol extensions (such as new
options) are necessary.
7. Interoperability among independent implementations has been
demonstrated.
3.2.2. Disadvantages
The DHCPv6 option for RDNSS has a few disadvantages. These include:
1. Update currently requires a message from server (however, see
[8]).
2. Because DNS information is not contained in RA messages, the host
must receive two messages from the router and must transmit at
least one message to the router. On networks where bandwidth is
at a premium, this is a disadvantage, although on most networks
it is not a practical concern.
3. There is an increased latency for initial configuration. In
addition to waiting for an RA message, the client must now
exchange packets with a DHCPv6 server. Even if it is locally
installed on a router, this will slightly extend the time
required to configure the client. For clients that are moving
rapidly from one network to another, this will be a disadvantage.
3.2.3. Observations
In the general case, on general-purpose networks, stateless DHCPv6
provides significant advantages and no significant disadvantages.
Even in the case where bandwidth is at a premium and low latency is
desired, if hosts require other configuration information in addition
to a list of RDNSSes or if hosts must be configured selectively,
those hosts will use DHCPv6 and the use of the DHCPv6 DNS recursive
name server option will be advantageous.
However, we are aware of some applications where it would be
preferable to put the RDNSS information into an RA packet; for
example, in a mobile phone network, where bandwidth is at a premium
and extremely low latency is desired. The DNS configuration based on
RA should be standardized so as to allow these special applications
to be handled using DNS information in the RA packet.
3.3. Well-known Anycast Addresses
Anycast uses the same routing system as unicast [9]. However,
administrative entities are local ones. The local entities may
accept unicast routes (including default routes) to anycast servers
from adjacent entities. The administrative entities should not
advertise their peer routes to their internal anycast servers, if
they want to prohibit external access from some peers to the servers.
If some advertisement is inevitable (such as the case with default
routes), the packets to the servers should be blocked at the boundary
of the entities. Thus, for this anycast, not only unicast routing
but also unicast ND protocols can be used as is.
First of all, the well-known anycast addresses approach is much
different from that discussed by the IPv6 Working Group in the past
[7]. Note that "anycast" in this memo is simpler than that of RFC
1546 [9] and RFC 3513 [10], where it is assumed to be prohibited to
have multiple servers on a single link sharing an anycast address.
That is, on a link, an anycast address is assumed to be unique. DNS
clients today already have redundancy by having multiple well-known
anycast addresses configured as RDNSS addresses. There is no point
in having multiple RDNSSes sharing an anycast address on a single
link.
The approach with well-known anycast addresses is to set multiple
well-known anycast addresses in clients’ resolver configuration files
from the beginning as, say, factory default. Thus, there is no
transport mechanism and no packet format [7].
An anycast address is an address shared by multiple servers (in this
case, the servers are RDNSSes). A request from a client to the
anycast address is routed to a server selected by the routing system.
However, it is a bad idea to mandate "site" boundary on anycast
addresses, because most users do not have their own servers and want
to access their ISPs across their site boundaries. Larger sites may
also depend on their ISPs or may have their own RDNSSes within "site"
boundaries.
3.3.1. Advantages
The basic advantage of the well-known addresses approach is that it
uses no transport mechanism. Thus, the following apply:
1. There is no delay to get the response and no further delay by
packet losses.
2. The approach can be combined with any other configuration
mechanisms, such as the RA-based approach and DHCP-based
approach, as well as the factory default configuration.
3. The approach works over any environment where DNS works.
Another advantage is that this approach only needs configuration of
the DNS servers as a router (or configuration of a proxy router).
Considering that DNS servers do need configuration, the amount of
overall configuration effort is proportional to the number of DNS
servers and it scales linearly. Note that, in the simplest case,
where a subscriber to an ISP does not have a DNS server, the
subscriber naturally accesses DNS servers of the ISP, even though the
subscriber and the ISP do nothing and there is no protocol to
exchange DNS server information between the subscriber and the ISP.
3.3.2. Disadvantages
The well-known anycast addresses approach requires that DNS servers
(or routers near to them as a proxy) act as routers to advertise
their anycast addresses to the routing system, which requires some
configuration (see the last paragraph of the previous section on the
scalability of the effort). In addition, routers at the boundary of
the "site" might need the configuration of route filters to prevent
providing DNS services for parties outside the "site" and the
possibility of denial of service attacks on the internal DNS
infrastructure.
3.3.3. Observations
If other approaches are used in addition, the well-known anycast
addresses should also be set in RA or DHCP configuration files to
reduce the configuration effort of users.
The redundancy by multiple RDNSSes is better provided by multiple
servers with different anycast addresses than by multiple servers
sharing the same anycast address, because the former approach allows
stale servers to generate routes to their anycast addresses. Thus,
in a routing domain (or domains sharing DNS servers), there will be
only one server with an anycast address unless the domain is so large
that load distribution is necessary.
Small ISPs will operate one RDNSS at each anycast address that is
shared by all the subscribers. Large ISPs may operate multiple
RDNSSes at each anycast address to distribute and reduce load, where
the boundary between RDNSSes may be fixed (redundancy is still
provided by multiple addresses) or change dynamically. DNS packets
with the well-known anycast addresses are not expected (though not
prohibited) to cross ISP boundaries, as ISPs are expected to be able
to take care of themselves.
Because "anycast" in this memo is simpler than that of RFC 1546 [9]
and RFC 3513 [10], where it is assumed to be administratively
prohibited to have multiple servers on a single link sharing an
anycast address, anycast in this memo should be implemented as
UNICAST of RFC 2461 [1] and RFC 3513 [10]. As a result, ND-related