Subject: ZEROCONF and multicast name resolution

From: Erik Guttman <[email-masked]>
Date: Wed, 24 Jul 2002 11:44:56 +0200 (MEST)

Folks,

The appropriate place to discuss these matters is on the DNSEXT WG
mailing list.  I am cross posting this message to the ZEROCONF WG
list only in order to end the thread which we do not have the 
charter to resolve and redirect discussion to the forum which does.

Keith Moore and various interlocutors have been discussing
multicast name resolution on the ZEROCONF WG mailing list.
I will not summarize that discussion, but I believe the below
captures most of the major points.  If I fail to do justice
to your particular concerns, please expand.

Multicast-Based Name Resolution
-------------------------------

Multicast-based name resolution has been a goal of the ZEROCONF
WG since it was chartered.  The work item, to create a standards
track protocol, has been taken on by the DNSEXT WG.

This effort has been troubled, again because of disagreements
about the functional requirements, but also because of unease
from many involved in DNS standardization at the IETF.  The
requirements expressed in ZEROCONF WG documents were either
not clear, or they were not meet with agreement in the DNSEXT WG.

I believe the goals for multicast name resolution arise from
the following observations.

 - Peer to peer naming protocols exist today, and have for a
   long time (NetBIOS and AppleTalk).  

 - It is possible to use these protocols to resolve names without 
   the use of DNS.  

 - NetBIOS and AppleTalk names can be *the same* as host names in
   the DNS.

 - Some hosts *ALREADY* use alternative naming mechanisms to resolve
   names when DNS is not available (NIS, NetBIOS, AppleTalk, others).
   As has been brought out on the list, this is common practice and in
   no way incorrect with respect to the resolver APIs.

 - There is no IETF standard way to provide this function, over IP.
 
 - It is desirable to retire NetBIOS and AppleTalk for many reasons
   but without a functionally equivalent IETF standard solution, this 
   is not possible.

The ZEROCONF WG has attempted to articulate the requirements for
an IETF standard to allow this name to address (and reverse) 
resolution in environments without DNS support.

There are numerous areas where we run into differences of opinion.

 - What does it mean for hosts to respond to fully qualified 
   domain names which DNS would normally respond to?  Should 
   multicast name resolution use the same namespace as DNS? 

   Some have held that we need a special 'local' namespace,
   while others believe that a host should be able to respond
   to requests for its 'own' name.

 - What we really want is applications that continue to 
   function even when DNS fails or is not present:  http://foo
   will succeed if there is a host which can respond to a
   name resolution request for 'foo' using the non-DNS multicast
   name resoultion protocol.  

   Some seem to hold this is not an appropriate objective.

 - Should multicast name resolution be possible whether even when
   DNS *is* available?  This would prevent 'local' name resolution 
   from ever failing and ensure it always returns consistent
   information.

   Many have asserted that DNS has to be used, exclusively,
   for domain name resolution if it is available as this is the 
   current and expected behavior.

That these issues have not been clearly resolved has left
work on LLMNR (draft-ietf-dnsext-mdns-10.txt) in an uncertain state.  

Let's try to resolve the issues and can come up with a solution which 
will serve the many users of local, unadministered networks.

Thanks and regards,

Erik

---

From: Erik Guttman <[email-masked]>
Date: Wed, 24 Jul 2002 16:17:53 +0200 (MEST)

> work on LLMNR (draft-ietf-dnsext-mdns-10.txt) in an uncertain state.  

Oops.  I have not been to the past two IETF meetings and 
have been relying on the mailing list to stay informed.  

I gather it was decided at the Yokohama DNSEXT meeting to 
take the next revision of the mdns draft to WG last call.
So the doc isn't in an 'uncertain state' after all, except
maybe now after my untimely comments :-/

Erik

---

From: Keith Moore <[email-masked]>
Date: Wed, 24 Jul 2002 14:05:18 -0400

Erik,

thanks for the summary; to me it seems a reasonable reflection of the 
recent zeroconf discussion.  I'll go look at the namedroppers archive 
and see if I can glean what that group has said about this.

my concerns can briefly be summarized as follows:

- in general, changing existing APIs will break applications.  one way 
  to do this is to change an existing name lookup function in such
  a way that the names no longer have the same semantics as before,
  or it treats names as valid that were formally invalid, or 
  by introducing new error conditions that need to be distinguished
  from the old ones.  such changes seem a likely result of changing
  an existing name lookup API to also handle name lookup in an ad hoc 
  network.

- local names can be useful, but they should be easily distinguished
  from fully qualified dns names, both by humans and by applications.  

  the de facto standard way to do this is to omit dots from local names.  
  if that convention is also adopted for ad hoc networks then fewer 
  applications will break.

- if you provide another way to look up DNS names (as opposed to local
  names), it needs to have results that are consistent with DNS.
  just as one example, it needs to never return "no such name" or
  "no records" when in fact it cannot tell whether the name exists
  or whether there are any such records.  this is somewhat difficult 
  to do in a disconnected network.

- a name lookup protocol that works on an ad hoc network is useful.
  but expecting a name lookup protocol to also be usable for service
  discovery creates some conflicts that are not easily resolved.