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

From: Tim Chown <[email-masked]>
Date: Mon, 17 Mar 2003 06:06:20 +0000

On Sun, Mar 16, 2003 at 10:10:39PM +0100, Johan Ihren wrote:
> That you're not interested in configuring ntp, foo and bar is fine.
> But that is in no way an argument for a multitude of discovery
> mechanisms. I still think that *one* generic discovery mechanism is
> very much better than several.
> 
> Much better that you just configure your client not to import the
> stuff you don't care about than inventing more mechanisms to support
> every form of granularity that people can invent.
> 
> Let's keep it simple. 

Hi Johan,

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

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.

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

Tim
--------------------------------------------------------------------
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-masked]
--------------------------------------------------------------------

---

From: Masataka Ohta <[email-masked]>
Date: Mon, 17 Mar 2003 18:41:09 +0859 ()

Tim;

> I think that, 
> piece" in the stateless autoconfiguration puzzle.

No, not at all.

> I have no objection to it 

The issue is merely that "stateless" approach is hopeless only to cause
a lot of problems when its application is seriously considered.

It is a problem of IPng group to remove "stateless" approach from IPv6
specification.

							Masataka Ohta

---

From: Tim Chown <[email-masked]>
Date: Tue, 18 Mar 2003 02:46:24 +0000

> It is a problem of IPng group to remove "stateless" approach from IPv6

Oh, nothing radical then...

---

From: Tim Chown <[email-masked]>
Date: Tue, 18 Mar 2003 21:38:15 +0000

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