Subject: New mDNS configuration language

From: Bernard Aboba <[email-masked]>
Date: Thu, 13 Sep 2001 09:23:21 -0700 (PDT)

I would like to propose the following text on mDNS configuration be added
to the next version of the draft, and that previous text relating to use
of the domain searchlist for configuration be removed. Comments welcome. 

3.1.  mDNS configuration

Multicast DNS usage can be configured manually or automatically.  Where
no manual or automatic configuration is provided, multicast DNS is
enabled by default.

For IPv6, the stateless DNS discovery mechanisms described in [19] can
be used to discover whether multicast DNS is enabled or disabled.

Where DHCPv4 or DHCPv6 is implemented, DHCP options can be used to
configure multicast DNS. The mDNS enable DHCP option, described in [6],
can be used to explicitly enable or disable use of multicast DNS. The
Name Service Search option, described in RFC 2937 [3], can be used to
determine where multicast DNS is used within the name service search
order. DHCP option codes are used as RFC 2937 codes signifying name
services within the search order. As a result, to specify multicast DNS
usage within the name service search order, the option code assigned to
the mDNS enable option is used.

If a host is configured via automatic configuration mechanisms, either
stateful or stateless, and multicast DNS is not explicitly enabled, then
multicast DNS MUST NOT be used, ensuring that upgraded hosts do not
change their default behavior.  This implies that the host will neither
listen on the DNS LINKLOCAL multicast address, nor will it send queries
to that address.  For a DNS server, automatic configuration mechanisms,
either stateful or stateless, MUST NOT  enable multicast DNS.

Esibov, Aboba & Thaler       Standards Track                   [Page 17]

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

---

From: Robert Elz <[email-masked]>
Date: Fri, 14 Sep 2001 09:28:27 +0700

Date:        Thu, 13 Sep 2001 09:23:21 -0700 (PDT)
    From:        Bernard Aboba <[email-masked]>
    Message-ID:  <[email-masked]>

  | I would like to propose the following text on mDNS configuration be added
  | to the next version of the draft, and that previous text relating to use
  | of the domain searchlist for configuration be removed. Comments welcome. 

In general, this looks fine to me.   But there is one issue that isn't
clear (I suspect the problem is just wording) ...

  | Multicast DNS usage can be configured manually or automatically.  Where
  | no manual or automatic configuration is provided, multicast DNS is
  | enabled by default.

If multicast DNS exists, then there ought be (regardless of what other
mechanisms exist) a manual way of configuring it.   So I can't see a case
where "no manual configuration is provided" - maybe you mean "where no
manual or automatic configuration has been performed" ?   That is, what
matters is whether the switch has been set, rather than whether the switch
exists?

  | If a host is configured via automatic configuration mechanisms, either
  | stateful or stateless, and multicast DNS is not explicitly enabled, then
  | multicast DNS MUST NOT be used,

Does "is configured" there mean "multicast DNS has been configured" or
the host has been configured in any way at all?   Some people consider
deciding how many discs to buy as "configuring the host" ...   Does IPv6
auto-configuration of a link local address (which every IPv6 node will do)
count as "configured by automatic means" ?   An IPv6 host on a net with
no other nodes at all can get that far - so can two nodes on an isolated
net.   I suspect the wording needs a little tightening.

kre

---

From: Aidan Williams <[email-masked]>
Date: Fri, 14 Sep 2001 11:03:23 +1000

> of the domain searchlist for configuration be removed. Comments welcome.

As I have said before, I am in favour of removing the domain
searchlist approach for mDNS configuration.

> no manual or automatic configuration is provided, multicast DNS is

"Configured manually or automatically" could be tighter.
Don't we really mean that mDNS shouldn't be turned on if there is
a "configuration protocol" in operation (e.g. DHCP, stateless autoconfig)

"MAY be enabled by default", or "MUST be enabled by default".
I would prefer MAY be enabled by default.

Suggested text:
  Multicast DNS operation may be configured via DHCP, stateless DNS
  discovery or some other configuration protocol.  Where no configuration
  protocol is in operation, multicast DNS MAY be enabled by default.

> the mDNS enable option is used.

As it happens, I just submitted an I-D intended to update rfc2937.
It describes an alternate way of doing this, without a new DHCP
option.  This draft should make its way through the system, but
for now I've put a copy up on the following URL:

  http://internet.motlabs.com/~aidan/draft-williams-dhc-rfc2937bis-00.txt

I was under the (possibly wrong) assumption that DHCP options were
in reasonably short supply, and because mDNS doesn't require IP
address configuration we probably didn't need one.

The relevant text to mDNS enablement in draft-...-rfc2937bis:

   6.1.  Enabling/Disabling mDNS

      The presence of the mDNS name service search option in the search
      list enables the use of multicast DNS on a host.  A host using
      DHCP SHOULD NOT enable multicast DNS unless the mDNS name service
      is listed in the Name Service Search Option list.

      An alternative approach is to have a seperate DHCP option to
      enable/disable mDNS.  If mDNS is to be used with multicast scopes
      larger than link-local, it is reasonable to be able to specify the
      order in which different scopes are consulted.  For example using
      a search path of mdns-link-local, netbios, mdns-site-local, isp-
      dns.

This text probably belongs somewhere other than an rfc2937bis draft,
and is slightly out of order..

rfc2937bis advantages/disadvantages
  - support additional mdns multicast scopes cleanly
  - presence of mDNS scope number in the DHCP name service search
    list option disables/enables mDNS for that interface, using
    that multicast scope
  - enabling mdns in a DHCP-configured environment is tied to
    implementation of name service search option in the host,
    which is probably larger/harder to implement than the
    mdns-enable approach.

new DHCP option (mdns-enable) + search path
  - supporting multiple scopes isn't clean.  I think it is
    reasonable to support multiple scopes, but others may disagree.
  - consumes a dhcp option, and as currently specified makes an
    additional search-list-like option
  - easier to implement..
  - need to update rfc2937 anyway because of text like this:
      "we rely on the existence of previously-defined DHCP options
       that specify the IP address(es) of servers which provide
       name services whose order we wish to express."
    mdns-enable doesn't specify an IP address (currently at least).

> either stateful or stateless, MUST NOT  enable multicast DNS.

Is this a global disable on the host, or a per-interface enable/disable?
My opinion is that it should be per-interface.

regards
	aidan
____
:wq!

Communications and Networks Lab         [email-masked]
Motorola Australian Research Centre          phone: +61 2 9666 0649
Locked Bag 5028, Botany NSW 1455              phax: +61 2 9666 0501
Australia                            http://cnlab.arc.corp.mot.com/

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 13 Sep 2001 20:22:19 -0700 (PDT)

> matters is whether the switch has been set, rather than whether the switch

Yes, "where no manual or automatic configuration has been performed" was
the intent. So if you don't have a DHCP server or stateless autoconfig 
then mDNS will be enabled. 

> the host has been configured in any way at all?   

If the host is configured via DHCP or stateless autoconfig, and the
administrator does not configure mDNS, the assumption is that it will not
be used. The goal is for hosts to exhibit their present behavior (no
mDNS) within configured environments, unless the administrator explicitly
enables it. 

> Does IPv6 auto-configuration of a link local address (which every IPv6
> node will do) count as "configured by automatic means" ?  

No, but implementation of router advertisement and DNS discovery would. 

> I suspect the wording needs a little tightening.

Suggestions welcome.

---

From: Aidan Williams <[email-masked]>
Date: Fri, 14 Sep 2001 15:15:18 +1000

Bernard Aboba wrote:
> RFC 2937 only talks about configuring the order in which naming protocols
> are used. The document states that interpretation of the option is
> "implementation dependent", so that it is not clear that the name search
> list is to be used for enabling/disabling naming protocols.
> 

I agree that the current spec is not compelling on this point.
I'm suggesting a change to the RFC 2937 behaviour, possibly
specifically for mDNS.

A host can ignore part or all of a name service search list, but the
absence or presence of a particular name service type in a supplied
search list surely suggests whether it should be used or not.

> mDNS enable/disable option can support multiple scopes, no?
> 

Yes, but not in this way:
  mdns-link-local, netbios, mdns-site-local, isp-dns

I view mdns-enable as an additional search-list proposal, to a large
extent overlapping rfc2937, and without the ability to interleave
different mdns multicast scopes with other name services (as above).

Maybe the real problem is that nobody wants to (or has) implemented
the host support for rfc2937 as is.

> Careful. RFC 2937 does not state that the name service search list is to
> be interpreted this way.
> 

See above.

> Yes, the changes required to implement this option are considerably
> greater than to support the mDNS enable/disable option.
> 

Assuming that the rfc2937 searchlist was not already implemented.

> RFC 2937 appears to require assignment of a DHCP option code as a
> prerequisite.
> 

Yes, and that is why I'm suggesting an update to it.  The draft I
wrote does not require a new DHCP option code to be defined, at the
expense of a new IANA number space for the searchlist.

regards
	aidan
____
:wq!

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 13 Sep 2001 22:18:01 -0700 (PDT)

>   mdns-link-local, netbios, mdns-site-local, isp-dns

Yes, RFC 2937 can provide the *order* in which the services are used.

> different mdns multicast scopes with other name services (as above).

Not sure I agree with that. mdns-enable doesn't overlap with RFC 2937,
since that document isn't clear about enable/disable semantics. 

> the host support for rfc2937 as is.

Is that true? No implementations at all?

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 13 Sep 2001 20:32:45 -0700 (PDT)

>     reasonable to support multiple scopes, but others may disagree.

mDNS enable option can support multiple scopes, too.

>   - easier to implement..

Yes. 

> My opinion is that it should be per-interface.

I think that is correct.

---

From: Aidan Williams <[email-masked]>
Date: Fri, 14 Sep 2001 16:15:33 +1000

> Yes, RFC 2937 can provide the *order* in which the services are used.

The current mdns enable draft has this diagram:

  2.0 DHCP Enable mDNS Option Format

       Code   Len  Scope
      +-----+-----+-----+-----+
      | TBD |  n  | Scp | ...
      +-----+-----+-----+-----+

The DHCP option number is TBD.  Support is there for additional
multicast scopes should they be specified.

RFC 2937 would then use the option number TBD in the search list.

But this option number identifies *all* of the mDNS scopes which
may be consulted (presumably they are queried one after another).
Thus different mDNS scopes cannot be interleaved with other name
services, as in the example I gave above.

I think this is useful functionality, others may disagree.

> since that document isn't clear about enable/disable semantics.

I would argue that the lack of clarity in rfc2937 about enable/disable
is a problem with the specification.  Enable/disable seems to be
implied by specifying a list of name services, but the text avoids
the issue.

> Is that true? No implementations at all?

I haven't come across it in real life, but I'm not sure.  I was posing
the question to get some idea for the following reason:

If rfc2937 is little supported, then using it to enable mDNS is going
to be a large hill to climb -- even if it seems like a sensible
approach.

regards
	aidan
____
:wq!

---

From: Robert Elz <[email-masked]>
Date: Fri, 14 Sep 2001 14:03:34 +0700

Date:        Thu, 13 Sep 2001 20:22:19 -0700 (PDT)
    From:        Bernard Aboba <[email-masked]>
    Message-ID:  <[email-masked]>

  | Yes, "where no manual or automatic configuration has been performed" was
  | the intent. So if you don't have a DHCP server or stateless autoconfig 
  | then mDNS will be enabled.

Yes, that's what I thought, so change that wording (to "has been performed").

  | If the host is configured via DHCP or stateless autoconfig, and the
  | administrator does not configure mDNS, the assumption is that it will not
  | be used.

Yes, that's what I thought - the point was that "configured" is a very
broad term, and can apply to almost anything.

  | No, but implementation of router advertisement and DNS discovery would. 

Not implementation, surely, only actually receiving a router advertisement.

  | > I suspect the wording needs a little tightening.
  | Suggestions welcome. 

For this one, perhaps

	If a host has been configured via any automatic configuration
	mechanism which is able to supply DNS configuration information,
	then multicast DNS MUST NOT be used unless it has been explicitly
	enabled, whether via that mechanism or any other.  This ensures that
	upgraded hosts do not change their default behaviour, without
	requiring the source of the configuration information to be
	simultaneously updated.  This implies....

kre

---

From: Aidan Williams <[email-masked]>
Date: Fri, 14 Sep 2001 17:10:46 +1000

> Is that true? No implementations at all?

Most freebie unixes would use one of these two:
  - The ISC dhcp client appears not to, looking at the source.
  - pump appears not to, looking at the source.

Ironically, the Solaris startup files I have examined edit
/etc/nsswitch.conf on the basis of whether there was a DNS
server IP address returned in the DHCP response, so I
conclude it is not supported.

Not sure about windows, but I'm sure someone knows.. ;)

regards
	aidan
____
:wq!