Thanks, Bob, for writing a draft doc on DNS Discovery requirements. We need something concrete to center this discussion.
So, here are some discussion points around the draft doc... Is a server-less solution the best solution for DNS Discovery? ============================================================== The requirements statement starts off with the same premise as the DNS Discovery team: "server-less" (as the term is defined in the doc) operation is a design requirement. The DNS Discovery team report stated "It is a further requirement that the above information be obtained without using a DHCP server." The issue with the DNS Design Team analysis and the recommended DNS discovery mechanism is not "is this the best server-less solution"; rather, the issue is "is this best server-less solution the best solution" or "do we need this best server-less solution". Bob's requirements will give us another answer to "is this the best server-less solution" and won't answer the question of whether the server-less solution is needed. So, we should either: * throw out the requirement for a server-less solution and find the best solution; or, * do an apriori analysis to confirm that a server-less solution is fundamentally required; or, * have and end-game analysis of "best server-less" solution vs. server-ful solution and decide if we need both Do we need a server-less solution for every IPv6 configuration problem? ================================================ I read an unstated assumption in the first sentence, "IPv6 provides two approaches to basic IPv6 configuration." that server-less and server-ful configuration are two mutually exclusive, stovepipe approaches, where both alternatives must be provided for each component of basic configuration. I believe we've shown that server-less configuration for IPv6 addresses is useful and a solved problem. It may be the only required solution - I can suppose situations in which address assignment might require constraint and control, but we don't have any deployment experience that proves such a requirement. But a solution to server-less configuration of IPv6 addresses does not imply that a solution to server-less configuration of routing information, DNS resolution and other basic configuration is a good idea or even possible. I think we should be careful to consider each type of configuration separately to make sure we're generating useable solutions to real problems. Server-less DNS Discovery or server-less DNS resolution? ======================================================== Just to be careful - the basic requirement in Bob's draft requirements is "to provide a server-less mechanism to enable a host to learn the address of an DNS server." This is a more stringent requirement than to provide a server-less mechanism to perform DNS resolution. I would say that the most recent "Stateless DNS Discovery" mechanism <draft-ietf-ipv6-dns-discovery-04.txt> does *not* meet the requirement laid out in Bob's requirements statement. A host using the Level 1 compliance mechanism defined in <draft-ietf-ipv6-dns-discovery-04.txt> does not find the address of an arbitrary DNS server. Rather, the host can do DNS resolution in a site that has specifically configured its network routing and DNS infrastructure to support DNS resolution through the well-known DNS server addresses. Scope of required information for DNS Discovery ================================================ Others have pointed out the a device using DNSSEC may need NTP. The requirements should be expanded to read something like "learn the address of a DNS server and any other servers required for use of DNS". At 04:23 PM 4/17/2002 -0700, you wrote: >I took a cut at a requirements statement for IPv6 DNS Discovery. Comments >are appreciated. > >Thanks, >Bob > >---------------------- > >IPv6 DNS Discovery Requirements Statement > >IPv6 provides two approaches to basic IPv6 configuration. One is >server-less and is defined in IPv6 Neighbor Discover [RFC2461] and the >IPv6 Stateless Address Autoconfiguration [RFC2462]. The other is server >oriented and is defined in DHCPv6 [dhcpv6 id]. IPv6 Neighbor Discovery >includes flags to direct an IPv6 host to use either approach. > >In order for an IPv6 host to communicate on the Internet it needs an IPv6 >address, IPv6 prefix for the link it is attached, default router address, >and a DNS server address. This information allows the host to use basic >internet services like the web, email, file transfer, etc. > >The server-less approach currently provides mechanisms for the IPv6 host >to learn an address, IPv6 prefix for the link, and default router address, >but does not provide any mechanism for the IPv6 host to learn any DNS >information. Without any DNS information the IPv6 host can not use basic >internet services with out some other kind of configuration (except by the >user typing in literal IPv6 addresses). Requiring users to enter literal >IPv6 addresses in difficult in IPv6 given the size of the addresses. > >The basic requirement for IPv6 DNS Discovery is to provide a server-less >mechanism to enable a host to learn the address of an DNS server. This >will complete the IPv6 server-less configuration mechanisms. > >For this requirement, Server-less is defined to mean the DNS information >is learned with out any dependence on resources other than are needed >(i.e., links, interfaces, routers, and DNS server) to communicate with the >DNS server. > >IPv6 DNS Discovery should work inside of a single site where the DNS >servers are in the site and between sites where the DNS servers and hosts >are located in different sites (e.g., small home office where DNS servers >are in the ISP's network). > >It is also desirable to learn other related DNS information such as >default DNS for the IPv6 host, search path, LLMNR enabled flag, etc. in a >server-less manner. > >Desirable aspects of a solution the meets these requirements include: > > - Minimal changes to existing implementations > - A solution that could be standardized in a short amount of time. > - Minimal use of bandwidth > > >References > >[DHCPv6] J. Bound, et. al., Dynamic Host Configuration Protocol for IPv6 > (DHCPv6), Internet Draft, <draft-ietf-dhc-dhcpv6-23.txt>, > February 2002. > >[RFC2461] T. Narten, et. al., Neighbor Discovery for IP Version 6 (IPv6), > RFC2461, December 1998. > >[RFC2462] S. Thomson, et. al., IPv6 Stateless Address Autoconfiguration, > RFC2462, December 1998. > > > > > >-------------------------------------------------------------------- >IETF IPng Working Group Mailing List >IPng Home Page: http://playground.sun.com/ipng >FTP archive: ftp://playground.sun.com/pub/ipng >Direct all administrative requests to [EMAIL PROTECTED] >-------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED] --------------------------------------------------------------------
