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

bind 9.3结合mysql数据库

 
 
   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 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. 
    
   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. 
    
 
 
Jeong, et al.             Expires - January 2005              [Page 7] 
 
Internet-Draft     IPv6 Host Configuration of DNS Server     July 2004 
 
 
   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 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. 
    
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 message, 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. 
    

 
 
Jeong, et al.             Expires - January 2005              [Page 8] 
 
Internet-Draft     IPv6 Host Configuration of DNS Server     July 2004 
 
 
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 
    
   First of all, the well-known anycast addresses approach is much 
   different from that discussed in IPv6 Working Group in the past. 
    
   The approach with well-known anycast addresses is to set 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).  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. 
    
   It should be noted that "anycast" in this memo is simpler than that
   of RFC1546 [11] and RFC3513 [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, 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 to have multiple RDNSSes sharing an anycast 
   address on a single link. 
    
3.3.1 Advantages 
    

 
 
Jeong, et al.             Expires - January 2005              [Page 9] 
 
Internet-Draft     IPv6 Host Configuration of DNS Server     July 2004 
 
 
   The basic advantage of the well-known addresses approach is that it
   uses no transport mechanism.  Thus, 
   1) There is no delay to get response and no further delay by packet
   losses. 
    
   2) The approach can be combined with any other configuration 
   mechanisms including but not limited to factory default 
   configuration, RA-based approach and DHCP based approach. 
    
   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 access DNS servers of the ISP even though the subscriber 
   and the ISP do nothing and there is no protocol to exchange DNS 
   server information between the subscriber and the ISP. 
    
3.3.2 Disadvantages 
    
   Well-known anycast addresses approach requires that DNS servers (or
   routers near it as a proxy) act as routers to advertise their 
   anycast addresses to the routing system, which requires some 
   configuration (see the last paragraph of the previous section on 
   the scalability of the effort). 
    
3.3.3 Observations 
    
   If other approaches are used in addition, the well-known anycast 
   addresses should also be set in RA or DHCP configuration files to 
   reduce configuration effort of users.
    
   Redundancy by multiple RDNSSes is better provided by multiple 
   servers having different anycast addresses than multiple servers 
   sharing same anycast address because the former approach allows 
   stale servers to still generate routes to their anycast addresses. 
   Thus, in a routing domain (or domains sharing DNS servers), there 
   will be only one server having an anycast address unless the domain
   is so large that load distribution is necessary. 
    
   Small ISPs will operate one RDNSS at each anycast address which is 
   shared by all the subscribers.  Large ISPs may operate multiple 
   RDNSSes at each anycast address to distribute and reduce load, 
   where boundary between RDNSSes may be fixed (redundancy is still 
   provided by multiple addresses) or change dynamically.  DNS packets
 
 
Jeong, et al.             Expires - January 2005             [Page 10] 
 
Internet-Draft     IPv6 Host Configuration of DNS Server     July 2004 
 
 
   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 RFC1546 [11]
   and RFC3513 [12] where it is assumed to be administratively 
   prohibited to have multiple servers on a single link sharing an 
   anycast address, anycast in this memo should be implemented as 
   UNICAST of RFC2461 [3] and RFC3513 [12].  As a result, ND-related 
   instability disappears.  Thus, anycast in well-known anycast 
   addresses approach can and should use the anycast address as a 
   source unicast (according to RFC3513 [12]) address of packets of 
   UDP and TCP responses.  With TCP, if route flips and packets to an 
   anycast address are routed to a new server, it is expected that the
   flip is detected by ICMP or sequence number inconsistency and the 
   TCP connection is reset and retried.
    
4. Interworking among IPv6 DNS Configuration Approaches 
    
   Three approaches can work together for IPv6 host configuration of 
   RDNSS.  This section shows a consideration on how these approaches 
   can interwork each other. 
    
   For ordering between RA and DHCP approaches, O (Other stateful 
   configuration) flag in RA message can be used [8].  If no RDNSS 
   option is included, an IPv6 Host may perform DNS configuration 
   through DHCPv6 [5]-[7] regardless of whether the O flag is set or 
   not. 
    
   The well-known anycast addresses approach fully interworks with the
   other approaches.  That is, the other approaches can remove 
   configuration effort on servers by using the well-known addresses 
   as the default configuration.  Moreover, clients preconfigured with
   well-known anycast addresses can be further configured to use other
   approaches to override the well-known addresses, if configuration 
   information from other approaches are available.  That is, all the 
   clients should have the well-known anycast addresses preconfigured,
   in the case where there are no other mechanisms available.  In 
   order to fly anycast approach with the other solutions, there are 
   three options. 
    
   The first option is that well-known addresses are used as last 
   resort, when an IPv6 host can not get RDNSS information through RA 
   and DHCP.  The well-known anycast addresses have to be pre-
   configured in IPv6 hosts' resolver configuration files. 
    


 
 
Jeong, et al.             Expires - January 2005             [Page 11] 
 
Internet-Draft     IPv6 Host Configuration of DNS Server     July 2004 
 
 
   The second is that an IPv6 host can configure well-known addresses 
   as the most preferable in its configuration file even though either
   RA option or DHCP option is available. 
    
   The last is that the well-known anycast addresses can be set in RA 
   or DHCP configuration to reduce configuration effort of users.  
   According to either RA or DHCP mechanism, the well-known addresses 
   can be obtained by IPv6 host.  Because this approach is the most 
   convenient for users, the last option is recommended. 
 
   Note: this section does not necessarily mean this document suggests
   adopting all these three approaches and making them interwork in 
   the way described here.  In fact, some approaches may even not be 
   adopted at all as a result of further discussion. 
    
5. Deployment Scenarios 
    
   Regarding DNS configuration on the IPv6 host, several mechanisms 
   have being considered at the DNSOP Working Group such as RA option,
   DHCPv6 option and well-known preconfigured anycast addresses as of 
   today, and this document is a final result from the long thread.  
   In this section, we suggest four applicable scenarios of three 
   approaches for IPv6 DNS configuration. 
    
   Note: in the applicable scenarios, authors do not implicitly push 
   any specific approaches into the restricted environments.  No 
   enforcement is in each scenario and all mentioned scenarios are 
   probable.  The main objective of this work is to provide a useful 
   guideline of IPv6 DNS configuration. 
    
5.1 ISP Network 
    
   A characteristic of ISP network is that multiple Customer Premises 
   Equipment (CPE) devices are connected to IPv6 PE (Provider Edge) 
   routers and each PE connects multiple CPE devices to the backbone 
   network infrastructure [13].  The CPEs may be hosts or routers. 
    
   In the case where the CPE is a router, there is a customer network 
   that is connected to the ISP backbone through the CPE.  Typically, 
   each customer network gets a different IPv6 prefix from an IPv6 PE 
   router, but the same RDNSS configuration will be distributed. 
    
   This section discusses how the different approaches to distributing
   DNS information are compared in an ISP network. 
    
5.1.1 RA Option Approach 
    

 
 
Jeong, et al.             Expires - January 2005             [Page 12] 
 
Internet-Draft     IPv6 Host Configuration of DNS Server     July 2004