doc: Add RFC documents

1 files changed, 1459 insertions, 0 deletions

diff --git a/doc/rfc/rfc4339.txt b/doc/rfc/rfc4339.txt
new file mode 100644
index 0000000..a6f29d9
--- /dev/null
+++ b/doc/rfc/rfc4339.txt
@@ -0,0 +1,1459 @@
+
+
+
+
+
+
+Network Working Group                                      J. Jeong, Ed.
+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.
+
+
+
+
+
+
+
+
+
+
+Jeong                        Informational                      [Page 1]
+
+RFC 4339         IPv6 Host Configuration of DNS Server     February 2006
+
+
+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
+
+
+
+
+Jeong                        Informational                      [Page 2]
+
+RFC 4339         IPv6 Host Configuration of DNS Server     February 2006
+
+
+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).
+
+
+
+Jeong                        Informational                      [Page 3]
+
+RFC 4339         IPv6 Host Configuration of DNS Server     February 2006
+
+
+   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
+
+
+
+Jeong                        Informational                      [Page 4]
+
+RFC 4339         IPv6 Host Configuration of DNS Server     February 2006
+
+
+       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
+
+
+
+Jeong                        Informational                      [Page 5]
+
+RFC 4339         IPv6 Host Configuration of DNS Server     February 2006
+
+
+   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.
+
+
+
+Jeong                        Informational                      [Page 6]
+
+RFC 4339         IPv6 Host Configuration of DNS Server     February 2006
+
+
+   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.
+
+
+
+
+
+
+
+Jeong                        Informational                      [Page 7]
+
+RFC 4339         IPv6 Host Configuration of DNS Server     February 2006
+
+
+   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.
+
+
+
+
+
+
+
+
+
+
+
+
+Jeong                        Informational                      [Page 8]
+
+RFC 4339         IPv6 Host Configuration of DNS Server     February 2006
+
+
+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
+
+
+
+Jeong                        Informational                      [Page 9]
+
+RFC 4339         IPv6 Host Configuration of DNS Server     February 2006
+
+
+   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.
+
+
+
+Jeong                        Informational                     [Page 10]
+
+RFC 4339         IPv6 Host Configuration of DNS Server     February 2006
+
+
+   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
+   instability disappears.  Thus, in the well-known anycast addresses
+   approach, anycast can and should use the anycast address as a source
+   unicast (according to RFC 3513 [10]) 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 that the TCP
+   connection is reset and retried.
+
+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.
+
+   For ordering between RA and DHCP approaches, the O (Other stateful
+   configuration) flag in the RA message can be used [6][28].  If no
+   RDNSS option is included, an IPv6 host may perform DNS configuration
+   through DHCPv6 [3]-[5] 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
+
+
+
+Jeong                        Informational                     [Page 11]
+
+RFC 4339         IPv6 Host Configuration of DNS Server     February 2006
+
+
+   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 that this document
+   suggests adopting all of these three approaches and making them
+   interwork in the way described here.  In fact, as a result of further
+   discussion some approaches may not even be adopted at all.
+
+5.  Deployment Scenarios
+
+   Regarding the DNS configuration on the IPv6 host, several mechanisms
+   are being considered by 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 an ISP network is that multiple Customer Premises
+   Equipment (CPE) devices are connected to IPv6 PE (Provider Edge)
+   routers and that each PE connects multiple CPE devices to the
+   backbone network infrastructure [11].  The CPEs may be hosts or
+   routers.
+
+
+
+Jeong                        Informational                     [Page 12]
+
+RFC 4339         IPv6 Host Configuration of DNS Server     February 2006
+
+
+   If 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 and /64 prefix information for
+   stateless address autoconfiguration at the same time when the host is
+   attached to a new subnet [6].  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 the 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
+   the host must receive at least an RA message for detecting a new
+   network, than in other scenarios generally, although the
+   administrator should configure RDNSS information on the routers.
+   Secure ND [12] can provide extended security when RA messages are
+   used.
+
+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 [3]-[5].  The DHCPv6 DNS option is
+   already in place for DHCPv6, as RFC 3646 [5] and DHCPv6-lite or
+   stateless DHCP [4] is not nearly as complex as a full DHCPv6
+   implementation.  DHCP is a client-server model protocol, so ISPs can
+   handle user identification on its network intentionally; also,
+   authenticated DHCP [13] 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 [15].  DNS configuration can be carried in
+   the same DHCPv6 message exchange used for DHCPv6 to provide that
+
+
+
+Jeong                        Informational                     [Page 13]
+
+RFC 4339         IPv6 Host Configuration of DNS Server     February 2006
+
+
+   information efficiently, 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 [7].  The use of well-known anycast
+   addresses avoids some of the security risks in rogue messages sent
+   through an external protocol such as 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
+
+   An 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
+   [14].  An enterprise network can get network prefixes from an ISP by
+   either manual configuration or prefix delegation [15].  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 networks process recursive DNS name resolution
+   requests from IPv6 hosts as RDNSSes.  The RDNSS configuration in the
+   enterprise network can be performed as it is 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 [6][28].  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 a 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 as it is 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
+
+
+
+Jeong                        Informational                     [Page 14]
+
+RFC 4339         IPv6 Host Configuration of DNS Server     February 2006
+
+
+       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 the 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 [16], and
+   transition to IPv6 in 3GPP networks is analyzed in [17] and [18].
+
+   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 [19].
+   There is a separate PDP context type for IPv4 and IPv6 traffic.  If a
+   3GPP UE user is communicating by using IPv6 (i.e., by having an
+   active IPv6 PDP context), it cannot be assumed that the user
+   simultaneously has an active IPv4 PDP context, and DNS queries could
+   be done using IPv4.  A 3GPP UE can thus be an IPv6 node, and somehow
+   it needs to 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.
+
+   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 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 [20].  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
+   the user's 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
+
+
+
+Jeong                        Informational                     [Page 15]
+
+RFC 4339         IPv6 Host Configuration of DNS Server     February 2006
+
+
+   as the address autoconfiguration mechanism.  Note that there will be
+   additional IP interfaces in some near-future 3GPP UEs; e.g., 3GPP-
+   specific DNS configuration mechanisms (such as PCO-IE [20]) 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 (even
+   hundreds of millions in one operator's network), is automatic, and
+   thus requires no user action.  It is suggested that a lightweight,
+   stateless mechanism be standardized for use in all network
+   environments.  The solution could then be used for 3GPP, 3GPP2, and
+   other access network technologies.  Thus, not only is a light,
+   stateless IPv6 DNS configuration mechanism 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 [6] 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 is needed in the 3GPP) and taken in use in 3GPP
+   UEs and GGSNs.
+
+   In this solution, an IPv6-capable UE configures DNS information via
+   an RA message sent by its default router (GGSN); i.e., the RDNSS
+   option for a 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.
+
+   When one considers 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
+
+   A DHCPv6-based solution needs the implementation of Stateless DHCP
+   [4] and DHCPv6 DNS options [5] 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.
+
+
+
+Jeong                        Informational                     [Page 16]
+
+RFC 4339         IPv6 Host Configuration of DNS Server     February 2006
+
+
+   The pros of a stateless DHCPv6-based solution are:
+
+   1.  Stateless DHCPv6 is a standardized mechanism.
+
+   2.  DHCPv6 can be used for receiving configuration information other
+       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 an existing
+       router.  This means that there might be one additional server to
+       be maintained.
+
+   2.  DHCPv6 is not necessarily needed for 3GPP UE IPv6 addressing
+       (3GPP Stateless Address Autoconfiguration is typically used) and
+       is not automatically implemented in 3GPP IPv6 UEs.
+
+   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 is
+       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
+       cannot automatically update the UE; see [21].
+
+5.3.4.  Well-known Addresses
+
+   Using well-known addresses is also a feasible and light mechanism for
+   3GPP UEs.  Those well-known addresses can be preconfigured in the UE
+   software and the operator can make the corresponding configuration on
+   the network side.  Thus, this is a very easy mechanism for the UE,
+
+
+
+Jeong                        Informational                     [Page 17]
+
+RFC 4339         IPv6 Host Configuration of DNS Server     February 2006
+
+
+   but it 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 [7], IPv6 anycast addresses are
+   suggested.
+
+   Note: An IPv6 DNS configuration proposal, based on the use of well-
+   known site-local addresses, was developed by the IPv6 Working Group;
+   it was seen as a feasible mechanism for 3GPP UEs, although no IETF
+   consensus was reached on this proposal.  In the end, the deprecation
+   of IPv6 site-local addresses made it impossible to standardize a
+   mechanism that uses site-local addresses as well-known addresses.
+   However, as of this writing, this mechanism is implemented in some
+   operating systems and 3GPP UEs as a last resort of IPv6 DNS
+   configuration.
+
+5.3.5.  Recommendations
+
+   It is suggested that a lightweight, stateless DNS configuration
+   mechanism be 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 stop using well-known site-local
+   addresses for IPv6 DNS configuration.
+
+5.4.  Unmanaged Network
+
+   There are four deployment scenarios of interest in unmanaged networks
+   [22]:
+
+   1.  A gateway that 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 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 implement NAT traversal.  The tunnel server assumes the role of
+   a relay (for both DHCP and well-known anycast addresses approaches).
+
+
+
+Jeong                        Informational                     [Page 18]
+
+RFC 4339         IPv6 Host Configuration of DNS Server     February 2006
+
+
+   The RA-based mechanism is relatively straightforward in its
+   operation, assuming the tunnel server is also the IPv6 router
+   emitting RAs.  The well-known anycast addresses approach also seems
+   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.  The exception is
+   that Stateless DHCPv6 is used, as opposed to the IPv4 scenario, where
+   the DHCP server is stateful (it 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 from the host.
+
+5.4.4.  Case D: A Gateway Connected to an IPv6-only ISP
+
+   This is similar to Case B.
+
+6.  Security Considerations
+
+   As security requirements depend solely on applications and differ
+   from application to application, there can be no generic requirement
+   defined at the IP or application layer for DNS.
+
+   However, note that cryptographic security requires configured secret
+   information and 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 [17], 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.  Note 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.
+
+
+
+Jeong                        Informational                     [Page 19]
+
+RFC 4339         IPv6 Host Configuration of DNS Server     February 2006
+
+
+   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 [23]-[25] needs the configuration and reconfiguration of
+   clients at root key roll-over [26][27].  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 attack, 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, configured secret information is
+   required.
+
+   If DNSSEC [23]-[25] is used and the signatures are verified on the
+   client host, the misconfiguration of a DNS server may simply be
+   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.
+
+6.1.  RA Option
+
+   The security of RA option for RDNSS is the same as the ND protocol
+   security [1][6].  The RA option does not add any new vulnerability.
+
+   Note 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 by the IETF
+   SEND (Securing Neighbor Discovery) Working Group, and RFC 3971 for
+   the ND security has been published [12].
+
+
+
+
+
+Jeong                        Informational                     [Page 20]
+
+RFC 4339         IPv6 Host Configuration of DNS Server     February 2006
+
+
+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 [5].  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 "Authentication
+   of DHCP messages" in RFC 3315 [3][13]) before installing a list of
+   DNS recursive name servers obtained through authenticated DHCP.
+
+6.3.  Well-known Anycast Addresses
+
+   The well-known anycast addresses approach is not a protocol, thus
+   there is no need to secure the protocol itself.
+
+   However, denial of service attacks on the DNS resolver system might
+   be easier to achieve as the anycast addresses used are by definition
+   well known.
+
+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
+
+
+
+
+
+
+
+
+
+
+Jeong                        Informational                     [Page 21]
+
+RFC 4339         IPv6 Host Configuration of DNS Server     February 2006
+
+
+   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
+
+   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                        Informational                     [Page 22]
+
+RFC 4339         IPv6 Host Configuration of DNS Server     February 2006
+
+
+8.  Acknowledgements
+
+   This document 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 document.  The authors appreciate
+   their contribution.
+
+9.  References
+
+9.1.  Normative References
+
+   [1]  Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery
+        for IP Version 6 (IPv6)", RFC 2461, December 1998.
+
+   [2]  Thomson, S. and T. Narten, "IPv6 Stateless Address
+        Autoconfiguration", RFC 2462, December 1998.
+
+   [3]  Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M.
+        Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)",
+        RFC 3315, July 2003.
+
+   [4]  Droms, R., "Stateless Dynamic Host Configuration Protocol (DHCP)
+        Service for IPv6", RFC 3736, April 2004.
+
+   [5]  Droms, R., "DNS Configuration options for Dynamic Host
+        Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, December
+        2003.
+
+9.2.  Informative References
+
+   [6]  Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, "IPv6
+        Router Advertisement Option for DNS Configuration", Work in
+        Progress, September 2005.
+
+   [7]  Ohta, M., "Preconfigured DNS Server Addresses", Work in
+        Progress, February 2004.
+
+   [8]  Venaas, S., Chown, T., and B. Volz, "Information Refresh Time
+        Option for Dynamic Host Configuration Protocol for IPv6
+        (DHCPv6)", RFC 4242, November 2005.
+
+   [9]  Partridge, C., Mendez, T., and W. Milliken, "Host Anycasting
+        Service", RFC 1546, November 1993.
+
+   [10] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6)
+        Addressing Architecture", RFC 3513, April 2003.
+
+
+
+
+Jeong                        Informational                     [Page 23]
+
+RFC 4339         IPv6 Host Configuration of DNS Server     February 2006
+
+
+   [11] Lind, M., Ksinant, V., Park, S., Baudot, A., and P. Savola,
+        "Scenarios and Analysis for Introducing IPv6 into ISP Networks",
+        RFC 4029, March 2005.
+
+   [12] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
+        Neighbor Discovery (SEND)", RFC 3971, March 2005.
+
+   [13] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages",
+        RFC 3118, June 2001.
+
+   [14] Bound, J., "IPv6 Enterprise Network Scenarios", RFC 4057, June
+        2005.
+
+   [15] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host
+        Configuration Protocol (DHCP) version 6", RFC 3633, December
+        2003.
+
+   [16] Wasserman, M., "Recommendations for IPv6 in Third Generation
+        Partnership Project (3GPP) Standards", RFC 3314, September 2002.
+
+   [17] Soininen, J., "Transition Scenarios for 3GPP Networks", RFC
+        3574, August 2003.
+
+   [18] Wiljakka, J., "Analysis on IPv6 Transition in Third Generation
+        Partnership Project (3GPP) Networks", RFC 4215, October 2005.
+
+   [19] 3GPP TS 23.060 V5.4.0, "General Packet Radio Service (GPRS);
+        Service description; Stage 2 (Release 5)", December 2002.
+
+   [20] 3GPP TS 24.008 V5.8.0, "Mobile radio interface Layer 3
+        specification; Core network protocols; Stage 3 (Release 5)",
+        June 2003.
+
+   [21] Chown, T., Venaas, S., and A. Vijayabhaskar, "Renumbering
+        Requirements for Stateless Dynamic Host Configuration Protocol
+        for IPv6 (DHCPv6)", RFC 4076, May 2005.
+
+   [22] Huitema, C., Austein, R., Satapati, S., and R. van der Pol,
+        "Unmanaged Networks IPv6 Transition Scenarios", RFC 3750, April
+        2004.
+
+   [23] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
+        "DNS Security Introduction and Requirements", RFC 4033, March
+        2005.
+
+   [24] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
+        "Resource Records for the DNS Security Extensions", RFC 4034,
+        March 2005.
+
+
+
+Jeong                        Informational                     [Page 24]
+
+RFC 4339         IPv6 Host Configuration of DNS Server     February 2006
+
+
+   [25] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
+        "Protocol Modifications for the DNS Security Extensions", RFC
+        4035, March 2005.
+
+   [26] Kolkman, O. and R. Gieben, "DNSSEC Operational Practices", Work
+        in Progress, October 2005.
+
+   [27] Guette, G. and O. Courtay, "Requirements for Automated Key
+        Rollover in DNSSEC", Work in Progress, January 2005.
+
+   [28] Park, S., Madanapalli, S., and T. Jinmei, "Considerations on M
+        and O Flags of IPv6 Router Advertisement", 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                        Informational                     [Page 25]
+
+RFC 4339         IPv6 Host Configuration of DNS Server     February 2006
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2006).
+
+   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.
+
+   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.
+
+Intellectual Property
+
+   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.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is provided by the IETF
+   Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Jeong                        Informational                     [Page 26]
+