Subject: Sense of the WG: mDNS configuration?

From: Bernard Aboba <[email-masked]>
Date: Sat, 18 Aug 2001 17:16:29 -0700 (PDT)

At IETF 51, we had a discussion relating to configuration of mDNS. A
number of alternatives were discussed, including:

      Domain Searchlist (draft-aboba-dhc-domsearch-05.txt)
      mDNS enable (draft-guttman-dhc-mdns-enable-01.txt)
      Name Service Searchlist (RFC 2937)

Note that each of these alternative approaches allows for local
configuration, in addition to control via a DHCP option.  

This is a request for a "sense of the WG" on which alternative should be
pursued. Please post your opinion to the list, along with a few words on
why you think your choice makes sense. 

to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.

---

From: Jun-ichiro itojun Hagino <[email-masked]>
Date: Sun, 19 Aug 2001 11:06:57 +0900

>why you think your choice makes sense. 

	i vote for domain searchlist.  there are environments without DHCP
	server, like IPv6 stateless address autoconf
	(RFC2937 and guttman-dhc-mbdns-enable both assumes that a DHCP
	server is there).

itojun

---

From: "Eric A. Hall" <[email-masked]>
Date: Sat, 18 Aug 2001 22:50:58 -0500

> server, like IPv6 stateless address autoconf

I vote for anything other than searchlist overloads.

Forced to choose, I would vote for local configuration option, with the
ability to use DHCP as a modification of the local configuration option
getting a strong positive.

[can we please stop calling it multicast DNS, since it isn't?]

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

---

From: Bernard Aboba <[email-masked]>
Date: Sat, 18 Aug 2001 23:51:44 -0700 (PDT)

> 	(RFC2937 and guttman-dhc-mbdns-enable both assumes that a DHCP

Currently the DNS server addresses and the domain searchlist can be
statelessly discovered in IPv6, but the other candidates cannot be,
thereby creating a DHCPv6 dependency, which is a show-stopper.

Would your opinion change if the other candidates (mDNS enable, name
service searchlist) could be statelessly discovered?

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Sun, 19 Aug 2001 14:16:18 +0900

>>>>> On Sun, 19 Aug 2001 11:06:57 +0900, 
>>>>> Jun-ichiro itojun Hagino <[email-masked]> said:

> 	(RFC2937 and guttman-dhc-mbdns-enable both assumes that a DHCP

I agree with itojun for the same reason.  At least we should have a
method of configuration without stateful servers.

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]

---

From: Robert Elz <[email-masked]>
Date: Sun, 19 Aug 2001 15:11:41 +0700

Date:        Sat, 18 Aug 2001 17:16:29 -0700 (PDT)
    From:        Bernard Aboba <[email-masked]>
    Message-ID:  <[email-masked]>

  |       Domain Searchlist (draft-aboba-dhc-domsearch-05.txt)
  |       mDNS enable (draft-guttman-dhc-mdns-enable-01.txt)
  |       Name Service Searchlist (RFC 2937)

Either of the latter two - the mdns-enable option is basically just
a special case of 2937, in a sense - but as I read 2937, it would need
another DNS option defined anyway, so its option number can be used in
the 2937 option (there's no current dhcp option giving the addresses
of the servers for mDNS .. for obvious reasons).

That is, adapting 2937 is probably more work than it is worth, so mdns-enable
is probably the better choice.

dhc-domsearch (with the magic string) is just wrong - overloads an option
with a totally irrelevant meaning.

And for itojun - none of these assume the existence of a dhcp server,
merely that if it does exist, then it can be used to configure nodes.

dhc-domsearch is basically setting the search line of resolv.conf and
the other two, the hosts line of nsswitch.conf (from a NetBSD perspective,
which I'm sure you understand).   When there's no dhcp server, those can
be configured manually (or simply default to whatever the OS vendor
decides is best - perhaps based upon an IETF recommendation).

kre

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 21 Aug 2001 10:57:19 -0700 (PDT)

> This strikes me somewhat as comparing apples to oranges. The three
> choices above do not do the same thing, so if the goal is to pick one,
> I would back up and ask: Can we get some agreement on what problem
> needs to be solved? I suspect that a choice of one approach over the
> other reflects at least partially disagreement on what the actual
> problem is that folks think is being addressed.
> 

Good point. My understanding was that configuration is attempting to
provide the following information:

a. Whether mDNS is to be used at all. 
b. If it is to be used, the order in which it is used relative to other 
   alternatives (e.g. unicast DNS first, then mDNS)
c. For the future, it would be useful to be able to control the scope
   used in mDNS (e.g. linklocal vs. wider scope). This isn't something
   we care about now, but the configuration choice we make shouldn't
   preclude this down the road. 

It is also desirable that configuration be possible in the following
scenarios:

  * IPv6 stateless auto-configuration (e.g. no DHCPv6 server)
  * IPv6 stateful configuration  (e.g. DHCPv6)
  * IPv4 w/DHCPv4
  * IPv4 or IPv6 with local configuration

---

From: Thomas Narten <[email-masked]>
Date: Tue, 21 Aug 2001 13:39:25 -0400

Thomas

---

From: Robert Elz <[email-masked]>
Date: Wed, 22 Aug 2001 14:40:31 +0700

Date:        Tue, 21 Aug 2001 13:39:25 -0400
    From:        Thomas Narten <[email-masked]>
    Message-ID:  <[email-masked]>

  | >       Domain Searchlist (draft-aboba-dhc-domsearch-05.txt)
  | >       mDNS enable (draft-guttman-dhc-mdns-enable-01.txt)
  | >       Name Service Searchlist (RFC 2937)

  | This strikes me somewhat as comparing apples to oranges.

I don't think so.

  | The three choices above do not do the same thing,

Not in general, but for the issue here, they're being bent (to greater
or lesser degrees) into answering the same question.  The issue is which
of those we should use to get the answer.

  | so if the goal is to pick one,
  | I would back up and ask: Can we get some agreement on what problem
  | needs to be solved?

Bernard replied to that already - but I don't think there was ever any
real question over what the issue was (why the above question was asked).

  | I suspect that a choice of one approach over the
  | other reflects at least partially disagreement on what the actual
  | problem is that folks think is being addressed.

I doubt it.   I think it is more along the lines of what else comes for
free when one of the choices is adopted, and what else gets lost when one
of the choices is adopted, and the relative priorities people place on
those.

kre

---

From: Aidan Williams <[email-masked]>
Date: Sat, 25 Aug 2001 11:59:44 +1000

>    preclude this down the road.

An observation: none of this configuration relates to the DNS
namespace(s) themselves, just to the way they are looked up.

Therefore, I am not in favour of overloading the DNS search list so
that an entry of .local.arpa. means "use multicast" for DNS requests.
Keeping the above configuration information away from the DNS
searchlist is a good idea.

So far, I haven't seen a clear description of the characteristics of
the .local.arpa. namespace itself.  Most discussion of it seems to be
related to turning off/on multicast lookups.

I see the namespace like this:

  - The .local.arpa. suffix is *not* globally unique.
    (a nice clear definition of this somewhere would be a good thing)

  - The .local.arpa. namespace is analogous to link-local, site-local
    or rfc1928 addressing.

  - The .local.arpa. namespace is useful independently of whether
    multicast lookups are used.  Is there a good reason to preclude
    unicast lookup in this namespace?

A standard configured DNS server could use these local names
(one could imagine entries like pop3, smtp, etc in there).

It could be a sensible default place to put non-global scoped address
mappings.

Zeroconf networks (which may not have a global DNS suffix) can use
this suffix too.

regards
	aidan
____
:wq!

---

From: Aidan Williams <[email-masked]>
Date: Sat, 25 Aug 2001 12:37:23 +1000

> is probably the better choice.

I agree that RFC2937 is the right concept, but I don't understand why
it is a great deal of work to extend.

Extending RFC2937 has the advantage that mDNS can be slotted in between
whatever name lookup services are defined by it (e.g. NIS+, NetBIOS, ..).
What would you do if you got *both* and mdns-enable option, and an
RFC2937 option?

I can think of two options for extending 2937:

  1. add an RFC2937 option for mDNS, and use a seperate DHCP option
     to define the scopes.

     Doesn't seem to buy much else other than "getting with the existing
     program".  Allows mDNS to be slotted in with the other zoo of
     name services.

  2. add RFC2937 options for each mDNS scope to be checked.

     My initial thought was that this was a dumb idea because
     there might be a profusion of the same option, but with
     every random scope.  However, there are probably only
     two relevant multicast scopes: link-local and site-local.

     This would basically incorporate the mdns-enable work into
     the RFC2937 framework.

> with a totally irrelevant meaning.

I whole-heartedly agree.

> When there's no dhcp server, those can

In the absence of configuration information, a sensible default
is to try mdns.  There isn't much else you can do (other than fail).

For IPv6, it seems that just about all DHCP options can be re-specified
as "stateless" router advert options, or new ICMP messages.
What would prevent this one going the same way?

regards
	aidan
____
:wq!

---

From: Bernard Aboba <[email-masked]>
Date: Sat, 25 Aug 2001 11:26:57 -0700 (PDT)

> What would prevent this one going the same way?

Nothing prevents this. I might even argue that in "Inform mode" (e.g. where
no address is being requested), DHCPv6 already enables "stateless" response
by routers, so there is no new work required. But I am sure that there are
many who don't agree with me ;)