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

非常好的dns解析软件

   (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 the configuration effort of users.

   The redundancy by multiple RDNSSes is better provided by multiple
   servers having different anycast addresses than multiple servers
   sharing the 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
   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 [11]
   and RFC 3513 [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 RFC 2461 [3] and RFC 3513 [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 RFC 3513 [12]) 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 the TCP
   connection is reset and retried.




Jeong                   Expires November 6, 2005               [Page 14]

Internet-Draft    IPv6 Host Configuration of DNS Server         May 2005


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, the O (Other stateful
   configuration) flag in RA message can be used [8][32].  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 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
   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 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.





Jeong                   Expires November 6, 2005               [Page 15]

Internet-Draft    IPv6 Host Configuration of DNS Server         May 2005


5.  Deployment Scenarios

   Regarding the DNS configuration on the IPv6 host, several mechanisms
   are 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 for 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

   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



Jeong                   Expires November 6, 2005               [Page 16]

Internet-Draft    IPv6 Host Configuration of DNS Server         May 2005


   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 messages.

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].  The DHCPv6 DNS option is
   already in place for DHCPv6 as RFC 3646 [7] and DHCPv6-lite or
   stateless DHCP [6] is nowhere as complex as a full DHCPv6
   implementation.  DHCP is a client-server model protocol, so ISPs 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 Anycast Addresses Approach

   The well-known anycast addresses approach is also a feasible and
   simple mechanism for ISP [9].  The use of well-known anycast
   addresses 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



Jeong                   Expires November 6, 2005               [Page 17]

Internet-Draft    IPv6 Host Configuration of DNS Server         May 2005


   enterprise network can get network prefixes from an 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 from IPv6 hosts as RDNSSes.  The RDNSS configuration in the
   enterprise network can be performed like 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 [8][32].  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 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 like 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
       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 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 [18], and
   transition to IPv6 in 3GPP networks is analyzed in [19] and [20].

   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 [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 cannot be assumed that (s)he has simultaneously an
   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.




Jeong                   Expires November 6, 2005               [Page 18]

Internet-Draft    IPv6 Host Configuration of DNS Server         May 2005


   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., 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 a 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, 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 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 needed in the 3GPP) and taken in use in 3GPP UEs



Jeong                   Expires November 6, 2005               [Page 19]

Internet-Draft    IPv6 Host Configuration of DNS Server         May 2005


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

   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.

   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 a router
       already existing, and that means one box more to be maintained.