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

[Johan Ihren <johani@autonomica.se>]

Tim Chown <tjc@ecs.soton.ac.uk> writes:

Hi Tim,

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

True.

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

I'm sure I'll get flamed for this.

To my mind that is actually almost a detail. That cost in the server
end (of course it is a cost to build a DHCPv6 server instead of not
doing that) is compensated by a simpler structure in the client end
(not having to decide what protocols to implement and, even worse,
decide how to to do failover between alternatives). 

There is a cost associated with having alternatives. And that cost is
in many cases at least as high as having just one, albeit more
complex, alternative.

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

When this was on the table a number of years ago the outcome as far as
I understand was that what was needed was an IP address and a default
route. No nameservice.

Maybe some years from now the answer will again have changed and with
the wrong design choice here that will be unnecessarily difficult to
cater to.

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

I think you should add "what is my name" to the set of stuff that is
part of the basic set. Not knowing your own name has a tendency of
being a source of trouble.

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

Absolutely. I'm not arguing against fixing this. I'm just arguing
against fixing it the wrong way. And I fully admit that I don't *know*
which way is wrong here and now.

Some years ago a decision not to depend on DHCPv6 was made (as far as
I understand, I wasn't present at that time). And it didn't work out
too well, which is why we're having this discussion. My worry is that
if we again decide that DHCPv6 isn't needed because we *only* have to
fix the *special* case of name resolution then we may end up here
again and lose even more time.

Johan

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