Subject: Re: New mDNS configuration language

From: Stuart Cheshire <[email-masked]>
Date: Sat, 15 Sep 2001 23:27:12 -0700

I think that before we can have a meaningful discussion about how to 
configure mDNS, we need to agree on what we *mean* by "mDNS".

There are currently two different things being called "mDNS", broadly 
similar, but different in one small though important way:

1. Use of IP multicast to look up DNS RRs that have names in the global 
DNS name space, when there is no access to the global tree of 
authoritative DNS servers which manage that global name space via formal 
delegation.

2. Use of IP multicast to look up DNS RRs that have names within a 
portion of the DNS name space specially designated to have only local 
significance, akin to Net 10 IPv4 addresses, or 169.254/16 link-local 
IPv4 addresses.

Version 1 is useful in the situation when my office uplink to the rest of 
the network has failed, and I double-click an alias icon on my laptop 
computer to access the disk of my desktop machine sitting next to it. The 
alias icon contains the DNS name of the target host (chesh1.apple.com.) 
so today this would simply fail because it couldn't get to the DNS 
server. If we had multicast DNS, then perhaps it could resolve the name 
locally using multicast, and succeed. There is also a risk here that 
without DNS SEC, the client may not know whether the response is 
trustworthy.

Version 2 is useful for a home user who simply wants to name the devices 
on his or her home network, without the expense or hassle of having to 
pay some registry to "buy" some chunk of the global DNS name space within 
which he or she can allocate names. This is much like what users do today 
with AppleTalk NBP names, or Microsoft NetBIOS names.

For Version 1, an option to enable and disable it seems to make sense.
It might also make sense to have an option to conditionally enable it, 
only for responses authenticated via DNS SEC, or universally enable it, 
for all responses whether authenticated or not.

For Version 2, an option to enable and disable makes much less sense.
If the designated local name space is "local.arpa." and a user types 
"myprinter.local.arpa." into their printing client, and there is an 
mDNS-capable printer on the network willing to answer to that name, then 
what possible utility is gained by having the host software decide to 
deliberately fail? There's no DHCP option to "disable" Net 10 addresses 
-- if you don't want Net 10 addresses, then you simply don't use them. If 
you do decide to use Net 10 addresses, the last thing you need is to 
struggle with them not working because some other configuration option 
somewhere else in the system has disabled them. The same applies here. No 
one has to use names within the designated local name space if they don't 
want to. If someone *does* decide to use names within the designated 
local name space, let's not work to create strange and interesting ways 
for them to not work, to confuse and bewilder our poor end-users.

Stuart Cheshire <[email-masked]>
 * Wizard Without Portfolio, Apple Computer
 * Chairman, IETF ZEROCONF
 * www.stuartcheshire.org

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

---

From: Paul A Vixie <[email-masked]>
Date: Sun, 16 Sep 2001 08:51:41 -0700

> with AppleTalk NBP names, or Microsoft NetBIOS names.

The example which convinced me of the need for mDNS was when Woody said "what
about when two people meet in a bus terminal and want to do iRDA between Palm
devices?"  It is compellingly impossible to imagine DHCP being useful for this.

Folks, this isn't an ad-hoc hack.  mDNS fills a necessary gap in the IP stack.
If the consensus of the WG is otherwise, then the work will just go on outside
the IETF.  This could mean Palms never speak IP over their iRDA's, or it could
mean that mDNS is yet another socially unacceptable "experimental" protocol,
but there's no way that this functionality won't be present.  There's only a
way that IETF can disassociate itself from the functionality.

---

From: Bill Woodcock <[email-masked]>
Date: Sun, 16 Sep 2001 11:12:31 -0700 (PDT)

> DNS name space

In other words, substitution of multicast for unicast with the overlying
DNS protocol and method of use otherwise unchanged.  Swap at layer 3.
Other things _above layer 5_ may query or use the information differently,
if they know they can get it via multicast, but that doesn't affect layer
5.

    > significance, akin to Net 10 IPv4 addresses, or 169.254/16 link-local

I've never been able to convince myself to care one whit about this
subset.  But I guess there are folks who find it interesting, and really
relish the idea of typing ".local" a lot.  That's great for them, as long
as they don't make me do it too.

			-Bill

---

From: Masataka Ohta <[email-masked]>
Date: Mon, 17 Sep 2001 06:52:18 +0859 ()

Paul;

> devices?"  It is compellingly impossible to imagine DHCP being useful for this.

The example is called "ad-hoc networking".

The example has nothing to do with the Internet.

> Folks, this isn't an ad-hoc hack.

It is ad-hoc networking.

An examle related to the internetworking is two people meet in a bus
terminal with their Palm devices connected to the Internet through
a wireless base station at the bus terminal.

> mDNS fills a necessary gap in the IP stack.

The basic problem is that "stateless autoconfiguration" is yet
another hype of IPv6 and is impossible to archieve in an open
environment such as the Internet.

							Masataka Ohta

PS

An important question would be "when will the wireless internet service
become widely available?".

So, just FYI, I have actually started up a company to commercially offer
mobile IP service with wireless LAN this April. ;-)

	http://www.miserv.net/miserv/english/news/index.html