Re: dns discovery for agenda? [Re: chairs and charter]

[Tim Chown <tjc@ecs.soton.ac.uk>]

On Tue, Mar 18, 2003 at 05:40:02AM +0100, Johan Ihren wrote:
> 
> Someone has to implement these things, burn code into proms and ship
> products. That process is not simplified by having several alternate
> mechanisms available. From an implementation point of view it would be
> much preferable to have just one and be done with it. And if you only
> have one, it had better be somewhat more generic than RA.

Hi Johan,

I think we're talking about two mechanisms, not "several", one geared
to stateful environments (which is fine, and of course necessary), the 
other to stateless environments.   

The RA method for stateless (for which a draft was proposed last year,
though I think it expired) is the only stateless method on (or near :)
to the table now, but the question is more general: do we want to mandate
a DHCPv6 server to be present to have DNS functionality in statelessly
configuring IPv6 nodes?

> With all due respect, I think this is short sighted. Today you almost
> cannot buy a DSL router for home use that doesn't have an integrated
> DHCP server, among all kinds of other strange stuff. To make a future
> equivalents of such devices also talk DHCPv6 is clearly possible.

Sure.  But that's then still a lot of DHCP code for just DNS discovery
(if DNS discovery is all that is required of the DHCPv6 server, and the
node doesn't need other DHCPv6 options).

Also, often the home DSL router can perform the resolver function.  This
throws up a possibility for such home devices for the RA message having an
option to say "use me for DNS", which would be simpler, but only apply
to a subset of cases.

> The more interesting issue that I think we should focus on is *how do
> you configure* the device to make correct announcements of where the
> recursive nameservice is located. And if we stay with the DSL-
> whatever-in-a-home example it seems rather clear that that
> configuration issue is exactly the same regardless of whether the
> stuff is sent out piggybacked as an RA option or via DHCPv6.

Agreed.   The "use me" option above would circumvent that need (for that
specific case), but I accept it's still extra code.
 
> But in the particular case of *discovery* mechanisms I still think
> that this is a mistake that needs to be rectified. 

I appreciate people may be concerend of creeping featurism, but I think
it's a fairly clear minimum requirement for a node to have basic stateless 
autoconf and DNS config (ref. Jim's comment to the list on DNS "MUST").
Maybe others don't see such a scenario being common.
 
Maybe a node will also want other DHCPv6 options, like preferred prefix,
time, NIS, whatever, but these are beyond the basic need for connectivity
and name resolution.

> And the reason is that discovery is part of "bootstrapping" a device
> to become a first class member of the network. "Software upgrades"
> take place after bootstrapping so mucking with discovery will always
> be extremely expensive for installed devices. Not to mention that when
> the device and the infrastructure don't share the same view on
> discovery things will break in ugly ways.

Appreciated.

If dnsop doesn't want to consider this item, so be it, but it has, as I
understand it, been punted from the IPv6 Charter to dnsop (rightly :) so
I feel it's worth pressing the question at this point.  

Tim
#----------------------------------------------------------------------
# To unsubscribe, send a message to <dnsop-request@cafax.se>.