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

bind 9.3结合mysql数据库

DNS Operations WG                                                     
Internet-Draft                                         J. Jeong (ed.) 
                                                                 ETRI 
                                                                      
Expires: January 2005                                    18 July 2004 
    
    
      IPv6 Host Configuration of DNS Server Information Approaches 
             draft-ietf-dnsop-ipv6-dns-configuration-02.txt 
    
    
Status of this Memo 
    
   By submitting this Internet-Draft, I certify that any applicable 
   patent or other IPR claims of which I am aware have been disclosed,
   and any of which we become aware will be disclosed, in accordance 
   with RFC3668. 
    
   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 January 17, 2005. 
    
Copyright Notice 
    
   Copyright (C) The Internet Society (2004). All Rights Reserved. 
    
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 four deployment scenarios considering multi-solution 
   resolution.  Therefore, this document will give the audience a 

 
 
Jeong, et al.             Expires - January 2005              [Page 1] 
 
Internet-Draft     IPv6 Host Configuration of DNS Server     July 2004 
 
 
   guideline of IPv6 DNS configuration to select approaches suitable 
   for their host DNS configuration. 
    
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...........................................9
          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..................................12
          5.1.2 DHCPv6 Option Approach..............................13
          5.1.3 Well-known Addresses Approach.......................13
      5.2 Enterprise Network........................................14
      5.3 3GPP Network..............................................14
          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.....................................17
      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.........................................18
          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
   7. Acknowledgements..............................................19
   8. Normative References..........................................20
   9. Informative References........................................20
   10. Authors' Addresses...........................................21
   Intellectual Property Statement..................................23
   Full Copyright Statement.........................................23
   Acknowledgement..................................................24
 
 
Jeong, et al.             Expires - January 2005              [Page 2] 
 
Internet-Draft     IPv6 Host Configuration of DNS Server     July 2004 
 
 
    
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 [3][4].  To support 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 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 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 approaches suitable for IPv6 host configuration of recursive 
   DNS server. 
    
2. Terminology 
    
   This document uses the terminology described in [3]-[9].  In 
   addition, a new term is defined below: 
    
   Recursive DNS Server (RDNSS)    A Recursive DNS Server is a name 
                                   server that offers the recursive 
                                   service of DNS name resolution. 
    
3. IPv6 DNS Configuration Approaches 
    
   In this section, the operational attributes of three solutions are 
   described in detail. 
     
3.1 RA Option 
    
   RA approach is to define a new ND option called 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, 
   etc.  An IPv6 host can configure the IPv6 addresses of one or more 
 
 
Jeong, et al.             Expires - January 2005              [Page 3] 
 
Internet-Draft     IPv6 Host Configuration of DNS Server     July 2004 
 
 
   RDNSSes via RA message periodically sent by 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 address can be 
   performed manually by operator or other ways, such as automatic 
   configuration through DHCPv6 client running on the router.  When 
   advertising more than one RDNSS options, an RA message includes as 
   many RDNSS options as RDNSSes.  Through ND protocol and RDNSS 
   option along with 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, RA approach performs
   poorly in some wireless environments where RA message is used for 
   IPv6 address autoconfiguration, such as WLAN networks. 
    
   The RA approach is useful in some non-WLAN mobile environments 
   where the addresses of the RDNSSes are changing because the RA 
   option includes a lifetime field.  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, lifetime would seem to make matters a bit more 
   complex.  Instead of just writing 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 RDNSS option, allows 
   IPv6 hosts to select primary RDNSS among several RDNSSes; this can 
   be used for load balancing of RDNSSes [8]. 
    
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 multi-
   point (i.e., Ethernet LANs), etc.  RFC2461 [3] states, however, 
   that there may be some link type on which ND is not possible; on 
   such a link, some other mechanism will be needed for DNS 
   configuration. 
    
   3) All of the information a host needs to run basic Internet  
   applications such as email, the web, ftp, etc., can be performed 
 
 
Jeong, et al.             Expires - January 2005              [Page 4] 
 
Internet-Draft     IPv6 Host Configuration of DNS Server     July 2004 
 
 
   with the addition of this option to ND and address auto-
   configuration.  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).  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, 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 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 that are common to all clients on a subnet would be easy 
   to define.  This includes things like NTP servers, SIP servers, etc.
    
3.1.2 Disadvantages 
    
   1) ND is mostly implemented in kernel part of operating system.  
   Therefore, if ND supports the configuration of some additional 
   services, such as DNS, NTP and SIP servers, ND should be extended 
   in kernel part.  DHCPv6, however, has more flexibility for 
   extension of service discovery because it is an application layer 
   protocol. 
    
   2) The current ND framework should be modified due to the 
   synchronization between another ND cache for RDNSSes in kernel 
   space and DNS configuration file in user space.  Because it is 
   unacceptable to write and rewrite 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 necessary 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 
   by RA option. 
    
3.1.3 Observations 
    

 
 
Jeong, et al.             Expires - January 2005              [Page 5] 
 
Internet-Draft     IPv6 Host Configuration of DNS Server     July 2004 
 
 
   The proposed RDNSS RA option along with IPv6 ND and Auto-
   configuration 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 environments where hosts use RAs to 
   autoconfigure their addresses and all 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.  Environments like this include 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].  Environments like this are most likely 
   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 
   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 
 
 
Jeong, et al.             Expires - January 2005              [Page 6] 
 
Internet-Draft     IPv6 Host Configuration of DNS Server     July 2004