Create releng/7.2 from stable/7 in preparation for 7.2-RELEASE.

[FreeBSD/releng/7.2.git] / contrib / bind9 / doc / draft / draft-ietf-dnsop-ipv6-dns-configuration-06.txt

DNS Operations WG                                          J. Jeong, Ed.
Internet-Draft                              ETRI/University of Minnesota
Expires: November 6, 2005                                    May 5, 2005


      IPv6 Host Configuration of DNS Server Information Approaches
             draft-ietf-dnsop-ipv6-dns-configuration-06.txt

Status of this Memo

   This document is an Internet-Draft and is subject to all provisions
   of Section 3 of RFC 3667.  By submitting this Internet-Draft, each
   author represents that any applicable patent or other IPR claims of
   which he or she is aware have been or will be disclosed, and any of
   which he or she become aware will be disclosed, in accordance with
   RFC 3668.

   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.

   This Internet-Draft will expire on November 6, 2005.

Copyright Notice

   Copyright (C) The Internet Society (2005).

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, such as ISP,
   Enterprise, 3GPP, and Unmanaged networks, considering multi-solution
   resolution.  Therefore, this document will give the audience a



Jeong                   Expires November 6, 2005                [Page 1]
\f
Internet-Draft    IPv6 Host Configuration of DNS Server         May 2005


   guideline for IPv6 host DNS configuration.


















































Jeong                   Expires November 6, 2005                [Page 2]
\f
Internet-Draft    IPv6 Host Configuration of DNS Server         May 2005


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  5
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  6
   3.  IPv6 DNS Configuration Approaches  . . . . . . . . . . . . . .  7
     3.1   RA Option  . . . . . . . . . . . . . . . . . . . . . . . .  7
       3.1.1   Advantages . . . . . . . . . . . . . . . . . . . . . .  8
       3.1.2   Disadvantages  . . . . . . . . . . . . . . . . . . . .  8
       3.1.3   Observations . . . . . . . . . . . . . . . . . . . . .  9
     3.2   DHCPv6 Option  . . . . . . . . . . . . . . . . . . . . . .  9
       3.2.1   Advantages . . . . . . . . . . . . . . . . . . . . . . 11
       3.2.2   Disadvantages  . . . . . . . . . . . . . . . . . . . . 12
       3.2.3   Observations . . . . . . . . . . . . . . . . . . . . . 12
     3.3   Well-known Anycast Addresses . . . . . . . . . . . . . . . 12
       3.3.1   Advantages . . . . . . . . . . . . . . . . . . . . . . 13
       3.3.2   Disadvantages  . . . . . . . . . . . . . . . . . . . . 14
       3.3.3   Observations . . . . . . . . . . . . . . . . . . . . . 14
   4.  Interworking among IPv6 DNS Configuration Approaches . . . . . 15
   5.  Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 16
     5.1   ISP Network  . . . . . . . . . . . . . . . . . . . . . . . 16
       5.1.1   RA Option Approach . . . . . . . . . . . . . . . . . . 16
       5.1.2   DHCPv6 Option Approach . . . . . . . . . . . . . . . . 17
       5.1.3   Well-known Anycast Addresses Approach  . . . . . . . . 17
     5.2   Enterprise Network . . . . . . . . . . . . . . . . . . . . 17
     5.3   3GPP Network . . . . . . . . . . . . . . . . . . . . . . . 18
       5.3.1   Currently Available Mechanisms and Recommendations . . 19
       5.3.2   RA Extension . . . . . . . . . . . . . . . . . . . . . 19
       5.3.3   Stateless DHCPv6 . . . . . . . . . . . . . . . . . . . 20
       5.3.4   Well-known Addresses . . . . . . . . . . . . . . . . . 21
       5.3.5   Recommendations  . . . . . . . . . . . . . . . . . . . 21
     5.4   Unmanaged Network  . . . . . . . . . . . . . . . . . . . . 22
       5.4.1   Case A: Gateway does not provide IPv6 at all . . . . . 22
       5.4.2   Case B: A dual-stack gateway connected to a
               dual-stack ISP . . . . . . . . . . . . . . . . . . . . 22
       5.4.3   Case C: A dual-stack gateway connected to an
               IPv4-only ISP  . . . . . . . . . . . . . . . . . . . . 22
       5.4.4   Case D: A gateway connected to an IPv6-only ISP  . . . 23
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 24
     6.1   RA Option  . . . . . . . . . . . . . . . . . . . . . . . . 25
     6.2   DHCPv6 Option  . . . . . . . . . . . . . . . . . . . . . . 25
     6.3   Well-known Anycast Addresses . . . . . . . . . . . . . . . 25
   7.  Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 26
   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 29
     9.1   Normative References . . . . . . . . . . . . . . . . . . . 29
     9.2   Informative References . . . . . . . . . . . . . . . . . . 29
       Author's Address . . . . . . . . . . . . . . . . . . . . . . . 31
   A.  Link-layer Multicast Acknowledgements for RA Option  . . . . . 32



Jeong                   Expires November 6, 2005                [Page 3]
\f
Internet-Draft    IPv6 Host Configuration of DNS Server         May 2005


       Intellectual Property and Copyright Statements . . . . . . . . 33


















































Jeong                   Expires November 6, 2005                [Page 4]
\f
Internet-Draft    IPv6 Host Configuration of DNS Server         May 2005


1.  Introduction

   Neighbor Discovery (ND) for IP Version 6 and IPv6 Stateless Address
   Autoconfiguration provide the ways to configure either fixed or
   mobile nodes with one or more IPv6 addresses, default routes and some
   other parameters [3][4].  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 [8], (b) DHCPv6
   option [5]-[7], and (c) Well-known anycast addresses for recursive
   DNS servers [9].  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 does
   not make any recommendation on a particular one or on a combination
   of particular ones.  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.


























Jeong                   Expires November 6, 2005                [Page 5]
\f
Internet-Draft    IPv6 Host Configuration of DNS Server         May 2005


2.  Terminology

   This document uses the terminology described in [3]-[9].  In
   addition, a new term is defined below:

   o  Recursive DNS Server (RDNSS): A Recursive DNS Server is a name
      server that offers the recursive service of DNS name resolution.












































Jeong                   Expires November 6, 2005                [Page 6]
\f
Internet-Draft    IPv6 Host Configuration of DNS Server         May 2005


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 is to define a new ND option called the RDNSS option
   that contains a recursive DNS server address.  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) [8].

   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 other ways, such as automatic
   configuration through a DHCPv6 client running on the router.  When
   advertising more than one RDNSS option, an RA message includes as
   many RDNSS options as RDNSSes.

   Through the ND protocol and RDNSS option along with a prefix
   information option, an IPv6 host can perform its network
   configuration of its IPv6 address and RDNSS simultaneously [3][4].
   The RA option for RDNSS can be used on any network that supports the
   use of ND.

   However, it is worth noting that some link layers, such as Wireless
   LANs (e.g., IEEE 802.11 a/b/g), do not support reliable multicast,
   which means that they cannot guarantee the timely delivery of RA
   messages [25]-[28].  This is discussed in Appendix A.

   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
   [8].  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; this can be
   used for the load balancing of RDNSSes [8].



Jeong                   Expires November 6, 2005                [Page 7]
\f
Internet-Draft    IPv6 Host Configuration of DNS Server         May 2005


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 [3][4], 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), etc.  RFC 2461
       [3] 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 of 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 support
       broadcast reliably (e.g., Ethernet LANs) but not necessarily on
       other links (e.g., Wireless LANs): Refer to Appendix A.  Also,
       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 of the
       information needed to use most Internet applications, such as the
       web in a single packet.  This not only saves bandwidth where this
       is an issue, but also minimizes the delay needed to learn the
       RDNSS information.

   5.  The RA approach could be used as a model for other 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 operating system.
       Therefore, if ND supports the configuration of some additional
       services, such as DNS servers, ND should be extended in the



Jeong                   Expires November 6, 2005                [Page 8]
\f
Internet-Draft    IPv6 Host Configuration of DNS Server         May 2005


       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 the 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 it uses a minimum of
   bandwidth.  The environments like this include the homes, public
   cellular networks, and enterprise environments where no per host
   configuration is needed, but exclude public WLAN hot spots.

   DHCPv6 is preferable where it is being used for address configuration
   and if there is a need for host specific configuration [5]-[7].  The
   environments like this are most likely to be the enterprise
   environments where the local administration chooses to have per host
   configuration control.

Note

   The observation section is based on what the proponents of each
   approach think makes a good overall solution.

3.2  DHCPv6 Option

   DHCPv6 [5] includes the "DNS Recursive Name Server" option, through
   which a host can obtain a list of IP addresses of recursive DNS



Jeong                   Expires November 6, 2005                [Page 9]
\f
Internet-Draft    IPv6 Host Configuration of DNS Server         May 2005


   servers [7].  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 [6].

   Stateless DHCPv6 can be deployed either 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 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 - clients 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.  Using
   this mechanism, it is currently possible to propagate new
   configuration information to DHCPv6 clients as this information
   changes.

   The DHC Working Group is currently studying an additional mechanism
   through which configuration information, including the list of
   RDNSSes, can be updated.  The lifetime option for DHCPv6 [10] 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.



Jeong                   Expires November 6, 2005               [Page 10]
\f
Internet-Draft    IPv6 Host Configuration of DNS Server         May 2005


   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.  So configuring
       DHCPv6 servers allows the network administrator to configure
       RDNSSes along with the addresses of other network services, as
       well as location-specific information like 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 as well as with other
       configuration information.  This capability is important in some
       network deployments such as service provider networks or WiFi hot
       spots.

   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.




Jeong                   Expires November 6, 2005               [Page 11]
\f
Internet-Draft    IPv6 Host Configuration of DNS Server         May 2005


3.2.2  Disadvantages

   The DHCPv6 option for RDNSS has a few disadvantages.  These include:

   1.  Update currently requires message from server (however, see
       [10]).

   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.  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, on a cell phone network, where bandwidth is at a premium and
   extremely low latency is desired.  The final DNS configuration draft
   should be written 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 [11].  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 peers 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



Jeong                   Expires November 6, 2005               [Page 12]
\f
Internet-Draft    IPv6 Host Configuration of DNS Server         May 2005


   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 at IPv6 Working Group in the past [9].
   It should be noted that "anycast" in this memo is simpler than that
   of RFC 1546 [11] and RFC 3513 [12] 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, say, as factory default.  Thus, there is no
   transport mechanism and no packet format [9].

   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 just 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,

   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 the approach needs to configure DNS servers
   as a router, but nothing else.  Considering that DNS servers do need
   configuration, the amount of overall configuration effort is
   proportional to the number of the DNS servers and scales linearly.
   It should be noted that, in the simplest case where a subscriber to
   an ISP does not have any DNS server, the subscriber naturally



Jeong                   Expires November 6, 2005               [Page 13]
\f
Internet-Draft    IPv6 Host Configuration of DNS Server         May 2005


   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

   Well-known anycast addresses approach requires that DNS servers (or
   routers near it 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).

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 having different anycast addresses than multiple servers
   sharing the same anycast address because the former approach allows
   stale servers to still generate routes to their anycast addresses.
   Thus, in a routing domain (or domains sharing DNS servers), there
   will be only one server having an anycast address unless the domain
   is so large that load distribution is necessary.

   Small ISPs will operate one RDNSS at each anycast address which 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 [11]
   and RFC 3513 [12] 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 [3] and RFC 3513 [12].  As a result, ND-related
   instability disappears.  Thus, anycast in well-known anycast
   addresses approach can and should use the anycast address as a source
   unicast (according to RFC 3513 [12]) address of packets of UDP and
   TCP responses.  With TCP, if a route flips and packets to an anycast
   address are routed to a new server, it is expected that the flip is
   detected by ICMP or sequence number inconsistency and the TCP
   connection is reset and retried.




Jeong                   Expires November 6, 2005               [Page 14]
\f
Internet-Draft    IPv6 Host Configuration of DNS Server         May 2005


4.  Interworking among IPv6 DNS Configuration Approaches

   Three approaches can work together for IPv6 host configuration of
   RDNSS.  This section shows a consideration on how these approaches
   can interwork each other.

   For ordering between RA and DHCP approaches, the O (Other stateful
   configuration) flag in RA message can be used [8][32].  If no RDNSS
   option is included, an IPv6 host may perform DNS configuration
   through DHCPv6 [5]-[7] regardless of whether the O flag is set or
   not.

   The well-known anycast addresses approach fully interworks with the
   other approaches.  That is, the other approaches can remove the
   configuration effort on servers by using the well-known addresses as
   the default configuration.  Moreover, the clients preconfigured with
   the well-known anycast addresses can be further configured to use
   other approaches to override the well-known addresses, if the
   configuration information from other approaches is available.
   Otherwise, all the clients need to have the well-known anycast
   addresses preconfigured.  In order to use the anycast approach along
   with two other approaches, there are three choices as follows:

   1.  The first choice is that well-known addresses are used as last
       resort, when an IPv6 host cannot get RDNSS information through RA
       and DHCP.  The well-known anycast addresses have to be
       preconfigured in all of IPv6 hosts' resolver configuration files.

   2.  The second is that an IPv6 host can configure well-known
       addresses as the most preferable in its configuration file even
       though either an RA option or DHCP option is available.

   3.  The last is that the well-known anycast addresses can be set in
       RA or DHCP configuration to reduce the configuration effort of
       users.  According to either the RA or DHCP mechanism, the well-
       known addresses can be obtained by an IPv6 host.  Because this
       approach is the most convenient for users, the last option is
       recommended.


Note

   This section does not necessarily mean this document suggests
   adopting all these three approaches and making them interwork in the
   way described here.  In fact, some approaches may even not be adopted
   at all as a result of further discussion.





Jeong                   Expires November 6, 2005               [Page 15]
\f
Internet-Draft    IPv6 Host Configuration of DNS Server         May 2005


5.  Deployment Scenarios

   Regarding the DNS configuration on the IPv6 host, several mechanisms
   are being considered at the DNSOP Working Group such as RA option,
   DHCPv6 option and well-known preconfigured anycast addresses as of
   today, and this document is a final result from the long thread.  In
   this section, we suggest four applicable scenarios of three
   approaches for IPv6 DNS configuration.

Note

   In the applicable scenarios, authors do not implicitly push any
   specific approaches into the restricted environments.  No enforcement
   is in each scenario and all mentioned scenarios are probable.  The
   main objective of this work is to provide a useful guideline for IPv6
   DNS configuration.

5.1  ISP Network

   A characteristic of ISP network is that multiple Customer Premises
   Equipment (CPE) devices are connected to IPv6 PE (Provider Edge)
   routers and each PE connects multiple CPE devices to the backbone
   network infrastructure [13].  The CPEs may be hosts or routers.

   In the case where the CPE is a router, there is a customer network
   that is connected to the ISP backbone through the CPE.  Typically,
   each customer network gets a different IPv6 prefix from an IPv6 PE
   router, but the same RDNSS configuration will be distributed.

   This section discusses how the different approaches to distributing
   DNS information are compared in an ISP network.

5.1.1  RA Option Approach

   When the CPE is a host, the RA option for RDNSS can be used to allow
   the CPE to get RDNSS information as well as /64 prefix information
   for stateless address autoconfiguration at the same time when the
   host is attached to a new subnet [8].  Because an IPv6 host must
   receive at least one RA message for stateless address
   autoconfiguration and router configuration, the host could receive
   RDNSS configuration information in that RA without the overhead of an
   additional message exchange.

   When the CPE is a router, the CPE may accept the RDNSS information
   from the RA on the interface connected to the ISP, and copy that
   information into the RAs advertised in the customer network.

   This approach is more valuable in the mobile host scenario, in which



Jeong                   Expires November 6, 2005               [Page 16]
\f
Internet-Draft    IPv6 Host Configuration of DNS Server         May 2005


   the host must receive at least an RA message for detecting a new
   network, than in other scenarios generally although administrator
   should configure RDNSS information on the routers.  Secure ND [14]
   can provide extended security when using RA messages.

5.1.2  DHCPv6 Option Approach

   DHCPv6 can be used for RDNSS configuration through the use of the DNS
   option, and can provide other configuration information in the same
   message with RDNSS configuration [5]-[7].  The DHCPv6 DNS option is
   already in place for DHCPv6 as RFC 3646 [7] and DHCPv6-lite or
   stateless DHCP [6] is nowhere as complex as a full DHCPv6
   implementation.  DHCP is a client-server model protocol, so ISPs can
   handle user identification on its network intentionally, and also
   authenticated DHCP [15] can be used for secure message exchange.

   The expected model for deployment of IPv6 service by ISPs is to
   assign a prefix to each customer, which will be used by the customer
   gateway to assign a /64 prefix to each network in the customer's
   network.  Prefix delegation with DHCP (DHCPv6 PD) has already been
   adopted by ISPs for automating the assignment of the customer prefix
   to the customer gateway [17].  DNS configuration can be carried in
   the same DHCPv6 message exchange used for DHCPv6 to efficiently
   provide that information, along with any other configuration
   information needed by the customer gateway or customer network.  This
   service model can be useful to Home or SOHO subscribers.  The Home or
   SOHO gateway, which is a customer gateway for ISP, can then pass that
   RDNSS configuration information to the hosts in the customer network
   through DHCP.

5.1.3  Well-known Anycast Addresses Approach

   The well-known anycast addresses approach is also a feasible and
   simple mechanism for ISP [9].  The use of well-known anycast
   addresses avoids some of the security risks in rogue messages sent
   through an external protocol like RA or DHCPv6.  The configuration of
   hosts for the use of well-known anycast addresses requires no
   protocol or manual configuration, but the configuration of routing
   for the anycast addresses requires intervention on the part of the
   network administrator.  Also, the number of special addresses would
   be equal to the number of RDNSSes that could be made available to
   subscribers.

5.2  Enterprise Network

   Enterprise network is defined as a network that has multiple internal
   links, one or more router connections, to one or more Providers and
   is actively managed by a network operations entity [16].  An



Jeong                   Expires November 6, 2005               [Page 17]
\f
Internet-Draft    IPv6 Host Configuration of DNS Server         May 2005


   enterprise network can get network prefixes from an ISP by either
   manual configuration or prefix delegation [17].  In most cases,
   because an enterprise network manages its own DNS domains, it
   operates its own DNS servers for the domains.  These DNS servers
   within enterprise network process recursive DNS name resolution
   requests from IPv6 hosts as RDNSSes.  The RDNSS configuration in the
   enterprise network can be performed like in Section 4, in which three
   approaches can be used together as follows:

   1.  An IPv6 host can decide which approach is or may be used in its
       subnet with the O flag in RA message [8][32].  As the first
       choice in Section 4, well-known anycast addresses can be used as
       a last resort when RDNSS information cannot be obtained through
       either an RA option or DHCP option.  This case needs IPv6 hosts
       to preconfigure the well-known anycast addresses in their DNS
       configuration files.

   2.  When the enterprise prefers the well-known anycast approach to
       others, IPv6 hosts should preconfigure the well-known anycast
       addresses like in the first choice.

   3.  The last choice, a more convenient and transparent way, does not
       need IPv6 hosts to preconfigure the well-known anycast addresses
       because the addresses are delivered to IPv6 hosts via either the
       RA option or DHCPv6 option as if they were unicast addresses.
       This way is most recommended for the sake of user's convenience.


5.3  3GPP Network

   The IPv6 DNS configuration is a missing part of IPv6
   autoconfiguration and an important part of the basic IPv6
   functionality in the 3GPP User Equipment (UE).  The higher level
   description of the 3GPP architecture can be found in [18], and
   transition to IPv6 in 3GPP networks is analyzed in [19] and [20].

   In the 3GPP architecture, there is a dedicated link between the UE
   and the GGSN called the Packet Data Protocol (PDP) Context.  This
   link is created through the PDP Context activation procedure [21].
   There is a separate PDP context type for IPv4 and IPv6 traffic.  If a
   3GPP UE user is communicating using IPv6 (having an active IPv6 PDP
   context), it cannot be assumed that (s)he has simultaneously an
   active IPv4 PDP context, and DNS queries could be done using IPv4.  A
   3GPP UE can thus be an IPv6 node, and it needs to somehow discover
   the address of the RDNSS.  Before IP-based services (e.g., web
   browsing or e-mail) can be used, the IPv6 (and IPv4) RDNSS addresses
   need to be discovered in the 3GPP UE.




Jeong                   Expires November 6, 2005               [Page 18]
\f
Internet-Draft    IPv6 Host Configuration of DNS Server         May 2005


   Section 5.3.1 briefly summarizes currently available mechanisms in
   3GPP networks and recommendations. 5.3.2 analyzes the Router
   Advertisement based solution, 5.3.3 analyzes the Stateless DHCPv6
   mechanism, and 5.3.4 analyzes the Well-known addresses approach.
   Section 5.3.5 finally summarizes the recommendations.

5.3.1  Currently Available Mechanisms and Recommendations

   3GPP has defined a mechanism, in which RDNSS addresses can be
   received in the PDP context activation (a control plane mechanism).
   That is called the Protocol Configuration Options Information Element
   (PCO-IE) mechanism [22].  The RDNSS addresses can also be received
   over the air (using text messages), or typed in manually in the UE.
   Note that the two last mechanisms are not very well scalable.  The UE
   user most probably does not want to type IPv6 RDNSS addresses
   manually in his/her UE.  The use of well-known addresses is briefly
   discussed in section 5.3.4.

   It is seen that the mechanisms above most probably are not sufficient
   for the 3GPP environment.  IPv6 is intended to operate in a zero-
   configuration manner, no matter what the underlying network
   infrastructure is.  Typically, the RDNSS address is needed to make an
   IPv6 node operational - and the DNS configuration should be as simple
   as the address autoconfiguration mechanism.  It must also be noted
   that there will be additional IP interfaces in some near future 3GPP
   UEs, e.g., WLAN, and 3GPP-specific DNS configuration mechanisms (such
   as PCO-IE [22]) do not work for those IP interfaces.  In other words,
   a good IPv6 DNS configuration mechanism should also work in a multi-
   access network environment.

   From a 3GPP point of view, the best IPv6 DNS configuration solution
   is feasible for a very large number of IPv6-capable UEs (can be even
   hundreds of millions in one operator's network), is automatic and
   thus requires no user action.  It is suggested to standardize a
   lightweight, stateless mechanism that works in all network
   environments.  The solution could then be used for 3GPP, 3GPP2, WLAN
   and other access network technologies.  A light, stateless IPv6 DNS
   configuration mechanism is thus not only needed in 3GPP networks, but
   also 3GPP networks and UEs would certainly benefit from the new
   mechanism.

5.3.2  RA Extension

   Router Advertisement extension [8] is a lightweight IPv6 DNS
   configuration mechanism that requires minor changes in the 3GPP UE
   IPv6 stack and Gateway GPRS Support Node (GGSN, the default router in
   the 3GPP architecture) IPv6 stack.  This solution can be specified in
   the IETF (no action needed in the 3GPP) and taken in use in 3GPP UEs



Jeong                   Expires November 6, 2005               [Page 19]
\f
Internet-Draft    IPv6 Host Configuration of DNS Server         May 2005


   and GGSNs

   In this solution, an IPv6-capable UE configures DNS information via
   RA message sent by its default router (GGSN), i.e., RDNSS option for
   recursive DNS server is included in the RA message.  This solution is
   easily scalable for a very large number of UEs.  The operator can
   configure the RDNSS addresses in the GGSN as a part of normal GGSN
   configuration.  The IPv6 RDNSS address is received in the Router
   Advertisement, and an extra Round Trip Time (RTT) for asking RDNSS
   addresses can be avoided.

   If thinking about the cons, this mechanism still requires
   standardization effort in the IETF, and the end nodes and routers
   need to support this mechanism.  The equipment software update
   should, however, be pretty straightforward, and new IPv6 equipment
   could support RA extension already from the beginning.

5.3.3  Stateless DHCPv6

   DHCPv6-based solution needs the implementation of Stateless DHCP [6]
   and DHCPv6 DNS options [7] in the UE, and a DHCPv6 server in the
   operator's network.  A possible configuration is such that the GGSN
   works as a DHCP relay.

   Pros for Stateless DHCPv6-based solution are

   1.  Stateless DHCPv6 is a standardized mechanism.

   2.  DHCPv6 can be used for receiving other configuration information
       than RDNSS addresses, e.g., SIP server addresses.

   3.  DHCPv6 works in different network environments.

   4.  When DHCPv6 service is deployed through a single, centralized
       server, the RDNSS configuration information can be updated by the
       network administrator at a single source.

   Some issues with DHCPv6 in 3GPP networks are listed below:

   1.  DHCPv6 requires an additional server in the network unless the
       (Stateless) DHCPv6 functionality is integrated into a router
       already existing, and that means one box more to be maintained.

   2.  DHCPv6 is not necessarily needed for 3GPP UE IPv6 addressing
       (3GPP Stateless Address Autoconfiguration is typically used), and
       not automatically implemented in 3GPP IPv6 UEs.





Jeong                   Expires November 6, 2005               [Page 20]
\f
Internet-Draft    IPv6 Host Configuration of DNS Server         May 2005


   3.  Scalability and reliability of DHCPv6 in very large 3GPP networks
       (with tens or hundreds of millions of UEs) may be an issue, at
       least the redundancy needs to be taken care of.  However, if the
       DHCPv6 service is integrated into the network elements, such as a
       router operating system, scalability and reliability is
       comparable with other DNS configuration approaches.

   4.  It is sub-optimal to utilize the radio resources in 3GPP networks
       for DHCPv6 messages if there is a simpler alternative available.

       *  The use of Stateless DHCPv6 adds one round trip delay to the
          case in which the UE can start transmitting data right after
          the Router Advertisement.

   5.  If the DNS information (suddenly) changes, Stateless DHCPv6 can
       not automatically update the UE, see [23].


5.3.4  Well-known Addresses

   Using well-known addresses is also a feasible and a light mechanism
   for 3GPP UEs.  Those well-known addresses can be preconfigured in the
   UE software and the operator makes the corresponding configuration on
   the network side.  So this is a very easy mechanism for the UE, but
   requires some configuration work in the network.  When using well-
   known addresses, UE forwards queries to any of the preconfigured
   addresses.  In the current proposal [9], IPv6 anycast addresses are
   suggested.

Note

   The IPv6 DNS configuration proposal based on the use of well-known
   site-local addresses developed at the IPv6 Working Group was seen as
   a feasible mechanism for 3GPP UEs, but opposition by some people in
   the IETF and finally deprecating IPv6 site-local addresses made it
   impossible to standardize it.  Note that this mechanism is
   implemented in some existing operating systems today (also in some
   3GPP UEs) as a last resort of IPv6 DNS configuration.

5.3.5  Recommendations

   It is suggested that a lightweight, stateless DNS configuration
   mechanism is specified as soon as possible.  From a 3GPP UE and
   network point of view, the Router Advertisement based mechanism looks
   most promising.  The sooner a light, stateless mechanism is
   specified, the sooner we can get rid of using well-known site-local
   addresses for IPv6 DNS configuration.




Jeong                   Expires November 6, 2005               [Page 21]
\f
Internet-Draft    IPv6 Host Configuration of DNS Server         May 2005


5.4  Unmanaged Network

   There are 4 deployment scenarios of interest in unmanaged networks
   [24]:

   1.  A gateway which does not provide IPv6 at all;

   2.  A dual-stack gateway connected to a dual-stack ISP;

   3.  A dual-stack gateway connected to an IPv4-only ISP; and

   4.  A gateway connected to an IPv6-only ISP.


5.4.1  Case A: Gateway does not provide IPv6 at all

   In this case, the gateway does not provide IPv6; the ISP may or may
   not provide IPv6.  Automatic or Configured tunnels are the
   recommended transition mechanisms for this scenario.

   The case where dual-stack hosts behind an NAT, that need access to an
   IPv6 RDNSS, cannot be entirely ruled out.  The DNS configuration
   mechanism has to work over the tunnel, and the underlying tunneling
   mechanism could be implementing NAT traversal.  The tunnel server
   assumes the role of a relay (both for DHCP and Well-known anycast
   addresses approaches).

   RA-based mechanism is relatively straightforward in its operation,
   assuming the tunnel server is also the IPv6 router emitting RAs.
   Well-known anycast addresses approach seems also simple in operation
   across the tunnel, but the deployment model using Well-known anycast
   addresses in a tunneled environment is unclear or not well
   understood.

5.4.2  Case B: A dual-stack gateway connected to a dual-stack ISP

   This is similar to a typical IPv4 home user scenario, where DNS
   configuration parameters are obtained using DHCP.  Except that
   Stateless DHCPv6 is used, as opposed to the IPv4 scenario where the
   DHCP server is stateful (maintains the state for clients).

5.4.3  Case C: A dual-stack gateway connected to an IPv4-only ISP

   This is similar to Case B. If a gateway provides IPv6 connectivity by
   managing tunnels, then it is also supposed to provide access to an
   RDNSS.  Like this, the tunnel for IPv6 connectivity originates from
   the dual-stack gateway instead of the host.




Jeong                   Expires November 6, 2005               [Page 22]
\f
Internet-Draft    IPv6 Host Configuration of DNS Server         May 2005


5.4.4  Case D: A gateway connected to an IPv6-only ISP

   This is similar to Case B.
















































Jeong                   Expires November 6, 2005               [Page 23]
\f
Internet-Draft    IPv6 Host Configuration of DNS Server         May 2005


6.  Security Considerations

   As security requirements depend solely on applications and are
   different application by application, there can be no generic
   requirement defined at IP or application layer for DNS.

   However, it should be noted that cryptographic security requires
   configured secret information that full autoconfiguration and
   cryptographic security are mutually exclusive.  People insisting on
   secure full autoconfiguration will get false security, false
   autoconfiguration or both.

   In some deployment scenarios [19], where cryptographic security is
   required for applications, the secret information for the
   cryptographic security is preconfigured through which application
   specific configuration data, including those for DNS, can be securely
   configured.  It should be noted that if applications requiring
   cryptographic security depend on DNS, the applications also require
   cryptographic security to DNS.  Therefore, the full autoconfiguration
   of DNS is not acceptable.

   However, with full autoconfiguration, weaker but still reasonable
   security is being widely accepted and will continue to be acceptable.
   That is, with full autoconfiguration, which means there is no
   cryptographic security for the autoconfiguration, it is already
   assumed that the local environment is secure enough that the
   information from the local autoconfiguration server has acceptable
   security even without cryptographic security.  Thus, the
   communication between the local DNS client and local DNS server has
   acceptable security.

   In autoconfiguring recursive servers, DNSSEC may be overkill, because
   DNSSEC [29] needs the configuration and reconfiguration of clients at
   root key roll-over [30][31].  Even if additional keys for secure key
   roll-over are added at the initial configuration, they are as
   vulnerable as the original keys to some forms of attacks, such as
   social hacking.  Another problem of using DNSSEC and
   autoconfiguration together is that DNSSEC requires secure time, which
   means secure communication with autoconfigured time servers, which
   requires configured secret information.  Therefore, in order that the
   autoconfiguration may be secure, it requires configured secret
   information.

   If DNSSEC [29] is used and the signatures are verified on the client
   host, the misconfiguration of a DNS server may be simply denial of
   service.  Also, if local routing environment is not reliable, clients
   may be directed to a false resolver with the same IP address as the
   true one.



Jeong                   Expires November 6, 2005               [Page 24]
\f
Internet-Draft    IPv6 Host Configuration of DNS Server         May 2005


6.1  RA Option

   The security of RA option for RDNSS is the same as the ND protocol
   security [3][8].  The RA option does not add any new vulnerability.

   It should be noted that the vulnerability of ND is not worse and is a
   subset of the attacks that any node attached to a LAN can do
   independently of ND.  A malicious node on a LAN can promiscuously
   receive packets for any router's MAC address and send packets with
   the router's MAC address as the source MAC address in the L2 header.
   As a result, the L2 switches send packets addressed to the router to
   the malicious node.  Also, this attack can send redirects that tell
   the hosts to send their traffic somewhere else.  The malicious node
   can send unsolicited RA or NA replies, answer RS or NS requests, etc.
   All of this can be done independently of implementing ND.  Therefore,
   the RA option for RDNSS does not add to the vulnerability.

   Security issues regarding the ND protocol were discussed at IETF SEND
   (Securing Neighbor Discovery) Working Group and RFC 3971 for the ND
   security has been published [14].

6.2  DHCPv6 Option

   The DNS Recursive Name Server option may be used by an intruder DHCP
   server to cause DHCP clients to send DNS queries to an intruder DNS
   recursive name server [7].  The results of these misdirected DNS
   queries may be used to spoof DNS names.

   To avoid attacks through the DNS Recursive Name Server option, the
   DHCP client SHOULD require DHCP authentication (see section
   "Authentication of DHCP messages" in RFC 3315 [5]) before installing
   a list of DNS recursive name servers obtained through authenticated
   DHCP.

6.3  Well-known Anycast Addresses

   Well-known anycast addresses does not require configuration security
   since there is no protocol [9].

   The DNS server with the preconfigured addresses are still reasonably
   reliable, if local environment is reasonably secure, that is, there
   is no active attackers receiving queries to the anycast addresses of
   the servers and reply to them.








Jeong                   Expires November 6, 2005               [Page 25]
\f
Internet-Draft    IPv6 Host Configuration of DNS Server         May 2005


7.  Contributors

   Ralph Droms
   Cisco Systems, Inc.
   1414 Massachusetts Ave.
   Boxboro, MA  01719
   US

   Phone: +1 978 936 1674
   Email: rdroms@cisco.com


   Robert M. Hinden
   Nokia
   313 Fairchild Drive
   Mountain View, CA  94043
   US

   Phone: +1 650 625 2004
   Email: bob.hinden@nokia.com


   Ted Lemon
   Nominum, Inc.
   950 Charter Street
   Redwood City, CA  94043
   US

   Email: Ted.Lemon@nominum.com


   Masataka Ohta
   Tokyo Institute of Technology
   2-12-1, O-okayama, Meguro-ku
   Tokyo  152-8552
   Japan

   Phone: +81 3 5734 3299
   Fax:   +81 3 5734 3299
   Email: mohta@necom830.hpcl.titech.ac.jp


   Soohong Daniel Park
   Mobile Platform Laboratory, SAMSUNG Electronics
   416 Maetan-3dong, Yeongtong-Gu
   Suwon, Gyeonggi-Do  443-742
   Korea




Jeong                   Expires November 6, 2005               [Page 26]
\f
Internet-Draft    IPv6 Host Configuration of DNS Server         May 2005


   Phone: +82 31 200 4508
   Email: soohong.park@samsung.com


   Suresh Satapati
   Cisco Systems, Inc.
   San Jose, CA  95134
   US

   Email: satapati@cisco.com


   Juha Wiljakka
   Nokia
   Visiokatu 3
   FIN-33720, TAMPERE
   Finland

   Phone: +358 7180 48372
   Email: juha.wiljakka@nokia.com































Jeong                   Expires November 6, 2005               [Page 27]
\f
Internet-Draft    IPv6 Host Configuration of DNS Server         May 2005


8.  Acknowledgements

   This draft has greatly benefited from inputs by David Meyer, Rob
   Austein, Tatuya Jinmei, Pekka Savola, Tim Chown, Luc Beloeil,
   Christian Huitema, Thomas Narten, Pascal Thubert, and Greg Daley.
   Also, Tony Bonanno proofread this draft.  The authors appreciate
   their contribution.












































Jeong                   Expires November 6, 2005               [Page 28]
\f
Internet-Draft    IPv6 Host Configuration of DNS Server         May 2005


9.  References

9.1  Normative References

   [1]  Bradner, S., "IETF Rights in Contributions", RFC 3667,
        February 2004.

   [2]  Bradner, S., "Intellectual Property Rights in IETF Technology",
        RFC 3668, February 2004.

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

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

   [5]  Droms, R., Ed., "Dynamic Host Configuration Protocol for IPv6
        (DHCPv6)", RFC 3315, July 2003.

   [6]  Droms, R., "Stateless Dynamic Host Configuration Protocol (DHCP)
        Service for IPv6", RFC 3736, April 2004.

   [7]  Droms, R., Ed., "DNS Configuration options for Dynamic Host
        Configuration Protocol for IPv6 (DHCPv6)", RFC 3646,
        December 2003.

9.2  Informative References

   [8]   Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, "IPv6 DNS
         Discovery based on Router Advertisement",
         draft-jeong-dnsop-ipv6-dns-discovery-04.txt (Work in Progress),
         February 2005.

   [9]   Ohta, M., "Preconfigured DNS Server Addresses",
         draft-ohta-preconfigured-dns-01.txt (Work in Progress),
         February 2004.

   [10]  Venaas, S., Chown, T., and B. Volz, "Information Refresh Time
         Option for DHCPv6", draft-ietf-dhc-lifetime-03.txt (Work in
         Progress), January 2005.

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

   [12]  Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6)
         Addressing Architecture", RFC 3513, April 2003.

   [13]  Lind, M., Ed., "Scenarios and Analysis for Introduction IPv6



Jeong                   Expires November 6, 2005               [Page 29]
\f
Internet-Draft    IPv6 Host Configuration of DNS Server         May 2005


         into ISP Networks", RFC 4029, March 2005.

   [14]  Arkko, J., Ed., "SEcure Neighbor Discovery (SEND)", RFC 3971,
         March 2005.

   [15]  Droms, R. and W. Arbaugh, "Authentication for DHCP Messages",
         RFC 3118, June 2001.

   [16]  Bound, J., Ed., "IPv6 Enterprise Network Scenarios",
         draft-ietf-v6ops-ent-scenarios-05.txt (Work in Progress),
         July 2004.

   [17]  Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host
         Configuration Protocol (DHCP) version 6", RFC 3633,
         December 2003.

   [18]  Wasserman, M., Ed., "Recommendations for IPv6 in 3GPP
         Standards", RFC 3314, September 2002.

   [19]  Soininen, J., Ed., "Transition Scenarios for 3GPP Networks",
         RFC 3574, August 2003.

   [20]  Wiljakka, J., Ed., "Analysis on IPv6 Transition in 3GPP
         Networks", draft-ietf-v6ops-3gpp-analysis-11.txt (Work in
         Progress), October 2004.

   [21]  3GPP TS 23.060 V5.4.0, "General Packet Radio Service (GPRS);
         Service description; Stage 2 (Release 5)", December 2002.

   [22]  3GPP TS 24.008 V5.8.0, "Mobile radio interface Layer 3
         specification; Core network protocols; Stage 3 (Release 5)",
         June 2003.

   [23]  Chown, T., Venaas, S., and A. Vijayabhaskar, "Renumbering
         Requirements for Stateless DHCPv6",
         draft-ietf-dhc-stateless-dhcpv6-renumbering-02.txt (Work in
         Progress), October 2004.

   [24]  Huitema, C., Ed., "Unmanaged Networks IPv6 Transition
         Scenarios", RFC 3750, April 2004.

   [25]  ANSI/IEEE Std 802.11, "Part 11: Wireless LAN Medium Access
         Control (MAC) and Physical Layer (PHY) Specifications",
         March 1999.

   [26]  IEEE Std 802.11a, "Part 11: Wireless LAN Medium Access Control
         (MAC) and Physical Layer (PHY) specifications: High-speed
         Physical Layer in the 5 GHZ Band", September 1999.



Jeong                   Expires November 6, 2005               [Page 30]
\f
Internet-Draft    IPv6 Host Configuration of DNS Server         May 2005


   [27]  IEEE Std 802.11b, "Part 11: Wireless LAN Medium Access Control
         (MAC) and Physical Layer (PHY) specifications: Higher-Speed
         Physical Layer Extension in the 2.4 GHz Band", September 1999.

   [28]  IEEE P802.11g/D8.2, "Part 11: Wireless LAN Medium Access
         Control (MAC) and Physical Layer (PHY) specifications: Further
         Higher Data Rate Extension in the 2.4 GHz Band", April 2003.

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

   [30]  Kolkman, O. and R. Gieben, "DNSSEC Operational Practices",
         draft-ietf-dnsop-dnssec-operational-practices-03.txt (Work in
         Progress), December 2004.

   [31]  Guette, G. and O. Courtay, "Requirements for Automated Key
         Rollover in DNSSEC",
         draft-ietf-dnsop-key-rollover-requirements-02.txt (Work in
         Progress), January 2005.

   [32]  Park, S., Madanapalli, S., and T. Jinmei, "Considerations on M
         and O Flags of IPv6 Router Advertisement",
         draft-ietf-ipv6-ra-mo-flags-01.txt (Work in Progress),
         March 2005.


Author's Address

   Jaehoon Paul Jeong (editor)
   ETRI/Department of Computer Science and Engineering
   University of Minnesota
   117 Pleasant Street SE
   Minneapolis, MN  55455
   US

   Phone: +1 651 587 7774
   Fax:   +1 612 625 2002
   Email: jjeong@cs.umn.edu
   URI:   http://www.cs.umn.edu/~jjeong/












Jeong                   Expires November 6, 2005               [Page 31]
\f
Internet-Draft    IPv6 Host Configuration of DNS Server         May 2005


Appendix A.  Link-layer Multicast Acknowledgements for RA Option

   One benefit of an RA option [8] is to be able to multicast the
   advertisements, reducing the need for duplicated unicast
   communications.

   However, some link-layers may not support this as well as others.
   Consider, for example, WLAN networks where multicast is unreliable.
   The unreliability problem is caused by lack of ACK for multicast,
   especially on the path from the Access Point (AP) to the Station
   (STA), which is specific to CSMA/CA of WLAN, such as IEEE 802.11
   a/b/g [25]-[28].  That is, a multicast packet is unacknowledged on
   the path from the AP to the STA, but acknowledged in the reverse
   direction from the STA to the AP [25].  For example, when a router is
   placed at wired network connected to an AP, a host may sometimes not
   receive RA message advertised through the AP.  Therefore, the RA
   option solution might not work well on a congested medium that uses
   unreliable multicast for RA.

   The fact that this problem has not been addressed in Neighbor
   Discovery [3] indicates that the extra link-layer acknowledgements
   have not been considered a serious problem till now.

   A possible mitigation technique could be to map all-nodes link- local
   multicast address to the link-layer broadcast address, and to rely on
   the ND retransmissions for message delivery in order to achieve more
   reliability.
























Jeong                   Expires November 6, 2005               [Page 32]
\f
Internet-Draft    IPv6 Host Configuration of DNS Server         May 2005


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM 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.


Copyright Statement

   Copyright (C) The Internet Society (2005).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.




Jeong                   Expires November 6, 2005               [Page 33]
\f