Subject: RE: summary/conclusion of discussion on mdns-00

From: Erik Guttman <[email-masked]>
Date: Fri, 25 May 2001 17:14:42 +0200 (MEST)

> I don't think that the "magic address" idea is that bad. It doesn't have to
> be "magic" though. Why can't it be the actual mDNS multicast address (e.g.
> 239.255.255.251)? 

Actually, the mDNS address would be the link-local IPv4 multicast
address 224.0.0.251. <http://www.iana.org/assignments/multicast-addresses>

The admin local scope address you mention is for the mdns protocol,
as specified by Bill Woodcock and Bill Manning.  The drafts have since
expired.  

A problem with the 'magic number' proposal - if used in conjunction with 
admin multicast scopes - is that the magic numbers depend on which scope 
is used.  The mdns address is a 'relative assignment.' [RFC 2365]  The 
mDNS address is '4 down from the top of the range,' for Local Scope 
(239.255.255.0/24) it is 239.255.255.251.  For Organization Local Scope
(239.192.0.0/14) it would be 239.192.33.251.

Erik

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

---

From: "Eric A. Hall" <[email-masked]>
Date: Fri, 25 May 2001 09:50:06 -0700

> A[nother] problem with the 'magic number' proposal [...]

Can the draft get away with just recommending the use of "a local
configuration setting" without specifically overloading anything?

In that case, an mDNS-aware resolver could just an entry in resolv.conf
something like:

   mDNS <optional mcast addr>

where the multicast address can be locally predefined if scope control is
an issue for that site. Systems that supported the protocol would use it,
systems that didn't support it would ignore the "local configuration
setting". This approach doesn't overload any existing functionality,
doesn't break anything, and still allows for configuration management.

I'm not advocating that we define attribute:value pairs for resolv.conf or
the windows registry or anything, just that we say "uses a local
configuration setting", which can include an in-memory flag, a resolv.conf
entry, or any other form of local configuratin.

We can still go and define DHCP options for enabling/disabling this
setting of course.

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

---

From: Robert Elz <[email-masked]>
Date: Sat, 26 May 2001 16:00:45 +0700

Date:        Fri, 25 May 2001 09:50:06 -0700
    From:        "Eric A. Hall" <[email-masked]>
    Message-ID:  <[email-masked]>

  | Can the draft get away with just recommending the use of "a local
  | configuration setting" without specifically overloading anything?

Good enough for me ... though I'd prefer that it say that if DNS back
end resolvers have been configured for the node that this switch
default to "off" (no MDNS) and that if none have, it default to "on".

Ie: (or maybe I mean eg) if there's a classic resolv.conf (from DHCP or
elsewhere) then no mDNS unless the option exists and enables it (which
it wouldn't currently).  On the other hand, if there's no resolv.conf, or
no "nameserver" lines in it, then mDNS just happens.

kre