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

[Johan Ihren <johani@autonomica.se>]

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

Tim,

> I agree with the keep it simple princple in general, but in this
> case I'm not convincved.  DNS is a special case, as Pekka explained.
> I think that, for example, advertising DNS by RA's in IPv6 offers a
> veru useful "missing piece" in the stateless autoconfiguration
> puzzle.  To require the presence of DHCPv6 for DNS discovery in IPv6
> seems wrong.  I have no objection to it as *a* method, but in the

I think your statement of "as *a* method" perfectly summarizes the
reason for my objection to having multiple discovery mechanisms.

Keeping the door open to multiple mechanisms to discover the same
thing is just plain wrong. Sorry.

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.

> scenario of my home network I'd be quite happy to run without
> statelessly configuring clients needing to use DHCP to get the DNS
> info.

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.

"Wait", you say, "that router is the device that sends out the
RA". Sure it is. And it can also do DHCPv6.

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.

> I think many people accept that the well-known site-local method
> will die because of the issues with site-locals, thus leaving only
> DHCPv6 unless something like RA piggybacks is defined for the
> stateless scenario.

I agree.

> It would be interesting to review discovery methods in different
> protocols (including transition protocols), as a variety of methods
> are already used including well-known (site-local) addresses,
> link-local multicast, well-known names, DHCPv6, SLP, anycast, etc.
> The more we have, the more that needs to be supported (which in
> itself becomes an argument to keep the stateless picture simpler by
> not requiring DHCPv6 presence).

It is always more difficult to throw things away than to add new
stuff. This is a universal problem and usually it leads to overly
complex collections of not fully orthogonal pieces. Such is life, and
that's another reason for software upgrades.

But in the particular case of *discovery* mechanisms I still think
that this is a mistake that needs to be rectified. 

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.

Regards,

Johan Ihrén
Autonomica

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