Hi all,
Thanks Bob for initiating requirements draft.
IMHO "stateless address autoconfiguration" is actually a huge improvement propose by IPv6. In the same way, I think that a "server less" DNS server discovery should be a great service .
Anyway, I wonder if we should introduce to distinct requirements:
1- to provide a server less mechanism to enable a host to resolve any Domain Name
2- to provide a server less mechanism to enable a host to discover DNS server IPv6 address (so as "to learn other related DNS information" as stated Bob).
I think that those two mechanisms are actually distinct, and that each solution to those requirements will perhaps not be addressed by the same mechanism.
1- I think my first requirement is compliant with Level 1 of <draft-ietf-ipv6-dns-discovery-04.txt>. In that case, the host does not really want to know the IP address of the local DNS servers.
2- no solution has already be accepted, is that requirement really relevant ?
-> Does anycast enough mature ? unfortunately I've seen no answer to that.
-> ICMPv6 options could be enough ? But could be if an issue any other services discovery would like to use such a mechanism in the future, to modify the RA means an update of all existing devices ;+((
-> I thought it was a question for SLP but SLP seems needing for User Agents which is not compliant with other Bob's requirements (User Agent would be a kind of server... ?).
-> other solutions DDDT proposed in <draft-ipnwg-dns-discovery-analysis-00.txt> ?...
My 2%
Luc
-----Message d'origine-----
De : Ralph Droms [mailto:[EMAIL PROTECTED]]
Envoye : lundi 22 avril 2002 17:43
A : [EMAIL PROTECTED]
Objet : Re: Proposed IPv6 DNS Discovery Requirements
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]
--------------------------------------------------------------------
