I strongly disagree with a number of the 'requirements' you've proposed. 1. it is not possible in general for a host to determine it's proper DNS configuration from information provided by the network, because the DNS search path that the host wants to use may not be the one that the local network specifies. even trusting the local network's DNS servers to serve as the interface to other DNS zones is a stretch. it's fine if hosts want to do this, not fine to insist that they do this.
hosts MUST therefore be able to specify their own DNS configuration which overrides that specified by the local network environment, and this seems to contradict your 'requirements' #10 and #12. 2. re 'requirement' #12: it's absolutely unacceptable for IETF to dictate that a network administrator can 'control' what DNS servers a host can use - this is fundamentally a host issue and not a network issue; it's outside of the scope of what a network should be able to dictate to a host. again, the fact that a host is currently connected to a certain location in the network should not be taken as evidence that the context in which that host operates (dns servers, search path, default domain) should have anything to do with that network location. 3. 'requirements' #7,8 are premature at best and probably a fantasy. it's highly unlikely that DNS discovery can be implemented without some new protocol definition and implementation, even if you use similar packet formats and port # to those that exist now you are certainly going to need to change client and server code - and that is a protocol change. so I think at the very least these are poorly worded. more importantly, this decision is best made after alternatives have been considered - not as an a priori 'requirement' that presumes the solution. 4. I'm not at all sure what it means to 'authenticate the reliability' of a server, so I think this needs to be reworded. 5. note #7: there's no such thing as a 'standards-track Internet Draft' 6. requirement #11 and your note about #11 seem to be mutually exclusive - you can't use site-local addresses when the host and server are at different sites. of course, it's fine to use site-local addresses between hosts and servers at the same site. > IPv6 DNS Configuration Requirements > ------------------------------------ > > 1. Host receives IPv6 address(es) of DNS server(s) available to the > host for DNS resolution > 1.a. The list of servers includes only currently available > servers > 1.b. The host can obtain the addresses of new servers as needed > 2. Hosts obtain DNS configuration with no manual configuration > 3. The addresses of a particular server are provided to hosts with no > manual configuration of that server > 4. Hosts obtain DNS configuration using only those resources required > for DNS resolution > 5. Hosts obtain DNS configuration without the manual configuration of > any external service > 6. Hosts can (if desired) authenticate the reliability of servers > 7. Definition of DNS configuration requires no additional > protocol definition > 8. Implementation of DNS configuration requires no additional protocol > implementation > 9. Time to initial deployment is minimal > 10. Hosts have one way to perform DNS configuration > 11. DNS configuration operates when host and DNS servers are in same > site or in different sites > 12. A network administrator can control what servers a host uses > 13. Host is configured with domain and domain search list > > Notes: > ------ > 2. (and 3.) Hosts and DNS servers operate as "plug-and-play" or > "zeroconf" > 7. "additional protocol definition" means protocols not currently a > standard or defined in a standards-track Internet Draft > 8. "no additional protocol implementation" means hosts and servers > are not required to include code for protocols that they wouldn't > otherwise implement > 10. Hosts shouldn't need to try several different DNS Configuration > protocols to find which one is available on a link > 11. Hosts and DNS servers can exchange datagrams using site-local > addresses > -------------------------------------------------------------------- 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] --------------------------------------------------------------------
