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

非常好的dns解析软件

   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.





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


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

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

   The 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

   It is suggested that a lightweight, stateless DNS configuration
   mechanism is specified as soon as possible.  From a 3GPP UE and
   network point of view, the 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.




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


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, cannot 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).

5.4.3  Case C: A dual-stack gateway connected to an IPv4-only ISP

   This is similar to Case B. If a gateway provides IPv6 connectivity by
   managing tunnels, then it is also supposed to provide access to an
   RDNSS.  Like this, the tunnel for IPv6 connectivity originates from
   the dual-stack gateway instead of the host.




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


5.4.4  Case D: A gateway connected to an IPv6-only ISP

   This is similar to Case B.
















































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


6.  Security Considerations

   As security requirements depend solely on applications and are
   different application by application, there can be no generic
   requirement defined at IP or application layer for DNS.

   However, it should be noted that cryptographic security requires
   configured secret information that full autoconfiguration and
   cryptographic security are mutually exclusive.  People insisting on
   secure full autoconfiguration will get false security, false
   autoconfiguration or both.

   In some deployment scenarios [19], where cryptographic security is
   required for applications, the secret information for the
   cryptographic security is preconfigured through which application
   specific configuration data, including those for DNS, can be securely
   configured.  It should be noted that if applications requiring
   cryptographic security depend on DNS, the applications also require
   cryptographic security to DNS.  Therefore, the full autoconfiguration
   of DNS is not acceptable.

   However, with full autoconfiguration, weaker but still reasonable
   security is being widely accepted and will continue to be acceptable.
   That is, with full autoconfiguration, which means there is no
   cryptographic security for the autoconfiguration, it is already
   assumed that the local environment is secure enough that the
   information from the local autoconfiguration server has acceptable
   security even without cryptographic security.  Thus, the
   communication between the local DNS client and local DNS server has
   acceptable security.

   In autoconfiguring recursive servers, DNSSEC may be overkill, because
   DNSSEC [29] needs the configuration and reconfiguration of clients at
   root key roll-over [30][31].  Even if additional keys for secure key
   roll-over are added at the initial configuration, they are as
   vulnerable as the original keys to some forms of attacks, such as
   social hacking.  Another problem of using DNSSEC and
   autoconfiguration together is that DNSSEC requires secure time, which
   means secure communication with autoconfigured time servers, which
   requires configured secret information.  Therefore, in order that the
   autoconfiguration may be secure, it requires configured secret
   information.

   If DNSSEC [29] is used and the signatures are verified on the client
   host, the misconfiguration of a DNS server may be simply denial of
   service.  Also, if local routing environment is not reliable, clients
   may be directed to a false resolver with the same IP address as the
   true one.



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


6.1  RA Option

   The security of RA option for RDNSS is the same as the ND protocol
   security [3][8].  The RA option does not add any new vulnerability.

   It should be noted that the vulnerability of ND is not worse and is a
   subset of the attacks that any node attached to a LAN can do
   independently of ND.  A malicious node on a LAN can promiscuously
   receive packets for any router's MAC address and send packets with
   the router's MAC address as the source MAC address in the L2 header.
   As a result, the L2 switches send packets addressed to the router to
   the malicious node.  Also, this attack can send redirects that tell
   the hosts to send their traffic somewhere else.  The malicious node
   can send unsolicited RA or NA replies, answer RS or NS requests, etc.
   All of this can be done independently of implementing ND.  Therefore,
   the RA option for RDNSS does not add to the vulnerability.

   Security issues regarding the ND protocol were discussed at IETF SEND
   (Securing Neighbor Discovery) Working Group and RFC 3971 for the ND
   security has been published [14].

6.2  DHCPv6 Option

   The DNS Recursive Name Server option may be used by an intruder DHCP
   server to cause DHCP clients to send DNS queries to an intruder DNS
   recursive name server [7].  The results of these misdirected DNS
   queries may be used to spoof DNS names.

   To avoid attacks through the DNS Recursive Name Server option, the
   DHCP client SHOULD require DHCP authentication (see section
   "Authentication of DHCP messages" in RFC 3315 [5]) before installing
   a list of DNS recursive name servers obtained through authenticated
   DHCP.

6.3  Well-known Anycast Addresses

   Well-known anycast addresses does not require configuration security
   since there is no protocol [9].

   The DNS server with the preconfigured addresses are still reasonably
   reliable, if local environment is reasonably secure, that is, there
   is no active attackers receiving queries to the anycast addresses of
   the servers and reply to them.








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


7.  Contributors

   Ralph Droms
   Cisco Systems, Inc.
   1414 Massachusetts Ave.
   Boxboro, MA  01719
   US

   Phone: [phone]
   Email: [e-mail]


   Robert M. Hinden
   Nokia
   313 Fairchild Drive
   Mountain View, CA  94043
   US

   Phone: [phone]
   Email: [e-mail]


   Ted Lemon
   Nominum, Inc.
   950 Charter Street
   Redwood City, CA  94043
   US

   Email: [e-mail]


   Masataka Ohta
   Tokyo Institute of Technology
   2-12-1, O-okayama, Meguro-ku
   Tokyo  152-8552
   Japan

   Phone: [phone]
   Fax:   [phone]
   Email: [e-mail]


   Soohong Daniel Park
   Mobile Platform Laboratory, SAMSUNG Electronics
   416 Maetan-3dong, Yeongtong-Gu
   Suwon, Gyeonggi-Do  443-742
   Korea




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


   Phone: [phone]
   Email: [e-mail]


   Suresh Satapati
   Cisco Systems, Inc.
   San Jose, CA  95134
   US

   Email: [e-mail]


   Juha Wiljakka
   Nokia
   Visiokatu 3
   FIN-33720, TAMPERE
   Finland

   Phone: [phone]
   Email: [e-mail]