draft-ietf-dnsop-ipv6-dns-configuration-06.txt

非常好的dns解析软件

   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]

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]

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]

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]

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]

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]

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]

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