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

bind 9.3结合mysql数据库

 
   When the CPE is a host, the RA option for RDNSS can be used to 
   allow the CPE to get RDNSS information as well as /64 prefix 
   information for stateless address autoconfiguration at the same 
   time when the host is attached to a new subnet [8].  Because an 
   IPv6 host must receive at least one RA message for stateless 
   address autoconfiguration and router configuration, the host could 
   receive RDNSS configuration information in that RA without the 
   overhead of an additional message exchange. 
    
   When the CPE is a router, the CPE may accept the RDNSS information 
   from the RA on the interface connected to the ISP, and copy that 
   information into the RAs advertised in the customer network. 
    
   This approach is more valuable in the mobile host scenario, in 
   which the host must receive at least an RA message for detecting a 
   new network, than in other scenarios generally although 
   administrator should configure RDNSS information on the routers.  
   Secure ND [14] can provide extended security when using RA message.
    
5.1.2 DHCPv6 Option Approach 
    
   DHCPv6 can be used for RDNSS configuration through the use of the 
   DNS option, and can provide other configuration information in the 
   same message with RDNSS configuration [5]-[7].  DHCPv6 DNS option 
   is already in place for DHCPv6 as RFC 3646 [7] and moreover DHCPv6-
   lite or stateless DHCP [6] is nowhere as complex as a full DHCPv6 
   implementation.  DHCP is a client-server model protocol, so ISP can
   handle user identification on its network intentionally, and also 
   authenticated DHCP [15] can be used for secure message exchange. 
    
   The expected model for deployment of IPv6 service by ISPs is to 
   assign a prefix to each customer, which will be used by the 
   customer gateway to assign a /64 prefix to each network in the 
   customer's network.  Prefix delegation with DHCP (DHCPv6 PD) has 
   already been adopted by ISPs for automating the assignment of the 
   customer prefix to the customer gateway [17].  DNS configuration 
   can be carried in the same DHCPv6 message exchange used for DHCPv6 
   to efficiently provide that information, along with any other 
   configuration information needed by the customer gateway or 
   customer network.  This service model can be useful to Home or SOHO
   subscribers.  The Home or SOHO gateway, which is a customer gateway
   for ISP, can then pass that RDNSS configuration information to the 
   hosts in the customer network through DHCP. 
    
5.1.3 Well-known Addresses Approach 
    
   Well-known anycast addresses approach is also a feasible and simple
   mechanism for ISP [9].  The use of well-known anycast addresses 
 
 
Jeong, et al.             Expires - January 2005             [Page 13] 
 
Internet-Draft     IPv6 Host Configuration of DNS Server     July 2004 
 
 
   avoids some of the security risks in rogue messages sent through an
   external protocol like RA or DHCPv6.  The configuration of hosts 
   for the use of well-known anycast addresses requires no protocol or
   manual configuration, but the configuration of routing for the 
   anycast addresses requires intervention on the part of the network
   administrator.  Also, the number of special addresses would be 
   equal to the number of RDNSSes that could be made available to 
   subscribers. 
    
5.2 Enterprise Network 
    
   Enterprise network is defined as a network that has multiple 
   internal links, one or more router connections, to one or more 
   Providers and is actively managed by a network operations entity 
   [16].  An enterprise network can get network prefixes from ISP by 
   either manual configuration or prefix delegation [17].  In most 
   cases, because an enterprise network manages its own DNS domains, 
   it operates its own DNS servers for the domains.  These DNS servers
   within enterprise network process recursive DNS name resolution 
   requests of IPv6 hosts as RDNSS.  RDNSS configuration in enterprise
   network can be performed like in Section 4, in which three 
   approaches can be used together. 
    
   IPv6 host can decide which approach is or may be used in its subnet
   with O flag in RA message [8].  As the first option in Section 4, 
   well-known anycast addresses can be used as a last resort when 
   RDNSS information can not be obtained through either RA option or 
   DHCP option.  This case needs IPv6 hosts to preconfigure the well-
   known anycast addresses in their DNS configuration files. 
    
   When the enterprise prefers well-known anycast approach to the 
   others, IPv6 hosts should preconfigure the well-known anycast 
   addresses like in the first option. 
    
   The last option, a more convenient and transparent way, does not 
   need IPv6 hosts to preconfigure the well-known anycast addresses 
   because the addresses are delivered to IPv6 hosts through either RA
   option or DHCPv6 option as if they were unicast addresses.  This 
   way is most recommended for the sake of user's convenience. 
    
5.3 3GPP Network 
    
   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).  Higher level description of the 3GPP 
   architecture can be found in [18], and transition to IPv6 in 3GPP 
   networks is analyzed in [19] and [20]. 
    
 
 
Jeong, et al.             Expires - January 2005             [Page 14] 
 
Internet-Draft     IPv6 Host Configuration of DNS Server     July 2004 
 
 
   In 3GPP architecture, there is a dedicated link between the UE and 
   the GGSN called the Packet Data Protocol (PDP) Context.  This link 
   is created through the PDP Context activation procedure [21].  
   There is a separate PDP context type for IPv4 and IPv6 traffic.  If
   a 3GPP UE user is communicating using IPv6 (having an active IPv6 
   PDP context), it can not be assumed that (s)he has simultaneously 
   active IPv4 PDP context, and DNS queries could be done using IPv4. 
   A 3GPP UE can thus be an IPv6 node, and it needs to somehow 
   discover the address of the RDNSS.  Before IP-based services (e.g.,
   web browsing or e-mail) can be used, the IPv6 (and IPv4) RDNSS 
   addresses need to be discovered in the 3GPP UE. 
    
   Section 5.3.1 briefly summarizes currently available mechanisms in 
   3GPP networks and recommendations.  5.3.2 analyzes the Router  
   Advertisement based solution, 5.3.3 analyzes the Stateless DHCPv6 
   mechanism, and 5.3.4 analyzes the Well-known addresses approach.  
   Section 5.3.5 finally summarizes the recommendations. 
    
5.3.1 Currently Available Mechanisms and Recommendations 
    
   3GPP has defined a mechanism, in which RDNSS addresses can be  
   received in the PDP context activation (a control plane mechanism).
   That is called the Protocol Configuration Options Information  
   Element (PCO-IE) mechanism [22].  The RDNSS addresses can also be 
   received over the air (using text messages), or typed in manually 
   in the UE.  Note that the two last mechanisms are not very well  
   scalable.  The UE user most probably does not want to type IPv6 
   RDNSS addresses manually in his/her UE.  The use of well-known 
   addresses is briefly discussed in section 5.3.4. 
    
   It is seen that the mechanisms above most probably are not  
   sufficient for the 3GPP environment.  IPv6 is intended to operate 
   in a zero-configuration manner, no matter what the underlying 
   network infrastructure is.  Typically, the RDNSS address is needed 
   to make an IPv6 node operational - and the DNS configuration should
   be as simple as the address autoconfiguration mechanism.  It must 
   also be noted that there will be additional IP interfaces in some 
   near future 3GPP UEs, e.g., Wireless LAN (WLAN), and 3GPP-specific 
   DNS configuration mechanisms (such as PCO-IE [22]) do not work for 
   those IP interfaces.  In other words, a good IPv6 DNS configuration
   mechanism should also work in a multi-access network environment. 
    
   From 3GPP point of view, the best IPv6 DNS configuration solution 
   is feasible for a very large number of IPv6-capable UEs (can be 
   even hundreds of millions in one operator's network), is automatic 
   and thus requires no user action.  It is suggested to standardize a
   lightweight, stateless mechanism that works in all network  
   environments.  The solution could then be used for 3GPP, 3GPP2, 
 
 
Jeong, et al.             Expires - January 2005             [Page 15] 
 
Internet-Draft     IPv6 Host Configuration of DNS Server     July 2004 
 
 
   WLAN and other access network technologies.  A light, stateless 
   IPv6 DNS configuration mechanism is thus not only needed in 3GPP 
   networks, but also 3GPP networks and UEs would certainly benefit 
   from the new mechanism. 
    
5.3.2 RA Extension 
    
   Router Advertisement extension [8] is a lightweight IPv6 DNS  
   configuration mechanism that requires minor changes in 3GPP UE IPv6
   stack and Gateway GPRS Support Node (GGSN, the default router in  
   the 3GPP architecture) IPv6 stack.  This solution can be specified 
   in the IETF (no action needed in the 3GPP) and taken in use in 3GPP 
   UEs and GGSNs. 
    
   In this solution, an IPv6-capable UE configures DNS information  
   via RA message sent by its default router (GGSN), i.e., RDNSS 
   option for recursive DNS server is included in the RA message.  
   This solution is easily scalable for a very large number of UEs.  
   The operator can configure the RDNSS addresses in the GGSN as a 
   part of normal GGSN configuration.  The IPv6 RDNSS address is 
   received in the Router Advertisement, and an extra Round Trip Time
   (RTT) for asking RDNSS addresses can be avoided. 
    
   If thinking about cons, this mechanism still requires 
   standardization effort in the IETF, and the end nodes and routers 
   need to support this mechanism.  The equipment software update 
   should, however, be pretty straightforward, and new IPv6 equipment 
   could support RA extension already from the beginning. 
    
5.3.3 Stateless DHCPv6 
    
   DHCPv6-based solution needs the implementation of Stateless DHCP  
   [6] and DHCPv6 DNS options [7] in the UE, and a DHCPv6 server in  
   the operator's network.  A possible configuration is such that the
   GGSN works as a DHCP relay. 
    
   Pros for Stateless DHCPv6-based solution are 
   1) Stateless DHCPv6 is a standardized mechanism. 
    
   2) DHCPv6 can be used for receiving other configuration information
   than RDNSS addresses, e.g., SIP server addresses. 
    
   3) DHCPv6 works in different network environments. 
    
   4) When DHCPv6 service is deployed through a single, centralized 
   server, the RDNSS configuration information can be updated by the 
   network administrator at a single source. 
    
 
 
Jeong, et al.             Expires - January 2005             [Page 16] 
 
Internet-Draft     IPv6 Host Configuration of DNS Server     July 2004 
 
 
   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 already, and it is one box more to be maintained. 
    
   2) DHCPv6 is not necessarily needed for 3GPP UE IPv6 addressing 
   (3GPP Stateless Address Autoconfiguration is typically used), and 
   not automatically implemented in 3GPP IPv6 UEs. 
    
   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 
   router operating system, scalability and reliability is comparable 
   with other DNS configuration approaches. 
    
   4) It is sub-optimal to utilize the radio resources in 3GPP 
   networks for DHCPv6 messages if there is a simpler alternative 
   available. 
    
      a) Use of Stateless DHCPv6 adds one round trip delay to the case
      in which the UE can start transmitting data right after the 
      Router Advertisement. 
    
   5) If the DNS information (suddenly) changes, Stateless DHCPv6 can 
   not automatically update the UE, see [23]. 
    
5.3.4 Well-known Addresses 
    
   Using well-known addresses is also a feasible and a light mechanism
   for 3GPP UEs.  Those well-known addresses can be preconfigured in  
   the UE software and the operator makes the corresponding  
   configuration on the network side.  So this is a very easy 
   mechanism for the UE, but requires some configuration work in the 
   network.  When using well-known addresses, UE forwards queries to 
   any of the preconfigured addresses.  In the current proposal [9], 
   IPv6 anycast addresses are suggested. 
    
   Note: IPv6 DNS configuration proposal based on the use of well-
   known site-local addresses developed at the IPv6 Working Group was
   seen as a feasible mechanism for 3GPP UEs, but opposition by some 
   people in the IETF and finally deprecating IPv6 site-local 
   addresses made it impossible to standardize it.  Note that this 
   mechanism is implemented in some existing operating systems today 
   (also in some 3GPP UEs) as a last resort of IPv6 DNS configuration.
    
5.3.5 Recommendations  
    
 
 
Jeong, et al.             Expires - January 2005             [Page 17] 
 
Internet-Draft     IPv6 Host Configuration of DNS Server     July 2004 
 
 
   It is suggested that a lightweight, stateless DNS configuration 
   mechanism is specified as soon as possible.  From 3GPP UE's and 
   networks' point of view, Router Advertisement based mechanism looks
   most promising.  The sooner a light, stateless mechanism is 
   specified, the sooner we can get rid of using well-known site-local
   addresses for IPv6 DNS configuration. 
    
5.4 Unmanaged Network 
    
   There are 4 deployment scenarios of interest in unmanaged networks 
   [24]: 
    
   1) A gateway which does not provide IPv6 at all; 
    
   2) A dual-stack gateway connected to a dual-stack ISP; 
    
   3) A dual-stack gateway connected to an IPv4-only ISP; and 
    
   4) A gateway connected to an IPv6-only ISP. 
    
5.4.1 Case A: Gateway does not provide IPv6 at all 
    
   In this case, the gateway does not provide IPv6; the ISP may or may
   not provide IPv6.  Automatic or Configured tunnels are the 
   recommended transition mechanisms for this scenario. 
    
   The case where dual-stack hosts behind an NAT, that need access to 
   an IPv6 RDNSS, can not be entirely ruled out.  The DNS 
   configuration mechanism has to work over the tunnel, and the 
   underlying tunneling mechanism could be implementing NAT traversal.
   The tunnel server assumes the role of a relay (both for DHCP and 
   Well-known anycast addresses approaches). 
    
   RA-based mechanism is relatively straightforward in its operation, 
   assuming the tunnel server is also the IPv6 router emitting RAs. 
   Well-known anycast addresses approach seems also simple in 
   operation across the tunnel, but the deployment model using Well-
   known anycast addresses in a tunneled environment is unclear or not 
   well understood. 
    
5.4.2 Case B: A dual-stack gateway connected to a dual-stack ISP 
    
   This is similar to a typical IPv4 home user scenario, where DNS 
   configuration parameters are obtained using DHCP.  Except that 
   Stateless DHCPv6 is used, as opposed to the IPv4 scenario where the
   DHCP server is stateful (maintains the state for clients). 
    

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