Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard

Rob Austein <sra@isc.org> Fri, 26 August 2005 19:37 UTC

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8k0a-0003uY-OK; Fri, 26 Aug 2005 15:37:00 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8k0Y-0003uO-BQ for ietf@megatron.ietf.org; Fri, 26 Aug 2005 15:36:58 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10477 for <ietf@ietf.org>; Fri, 26 Aug 2005 15:36:56 -0400 (EDT)
Received: from cyteen.hactrn.net ([66.92.66.68]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8k1I-0001k2-MN for ietf@ietf.org; Fri, 26 Aug 2005 15:37:47 -0400
Received: from thrintun.hactrn.net (thrintun.hactrn.net [IPv6:2002:425c:4242:0:250:daff:fe82:1c39]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "thrintun.hactrn.net", Issuer "Grunchweather Associates" (verified OK)) by cyteen.hactrn.net (Postfix) with ESMTP id 07910243 for <ietf@ietf.org>; Fri, 26 Aug 2005 15:36:38 -0400 (EDT)
Received: from thrintun.hactrn.net (localhost [IPv6:::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 019D341AB; Fri, 26 Aug 2005 15:36:36 -0400 (EDT)
Date: Fri, 26 Aug 2005 15:36:36 -0400
From: Rob Austein <sra@isc.org>
To: ietf@ietf.org
In-Reply-To: <d9c8c54a66573745ab93d9d345afece7@karoshi.com>
References: <200508260153.j7Q1rBPj000783@relay4.apple.com> <20050826072055.GA15833@nic.fr> <87ll2pkquy.fsf@windlord.stanford.edu> <430EFCFF.1010203@zurich.ibm.com> <17167.14936.141345.6653@chiark.greenend.org.uk> <87pss0ioqx.fsf@windlord.stanford.edu> <d9c8c54a66573745ab93d9d345afece7@karoshi.com>
User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <20050826193636.019D341AB@thrintun.hactrn.net>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5
Subject: Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

At Fri, 26 Aug 2005 11:28:44 -0700, Bill Manning wrote:
> 
> 	then there was the debate over if this was DNS or something else...
> 	Stewart & I took the stance, yes it was/is.

Yep, this was the original sticking point.  In particular, there were
folks (myself among them) who felt strongly that:

1) Whatever this thing was, it should not run on the same port as
   normal DNS; and

2) Whatever this thing was, cached answers from it should not be
   mingled with cached answers from normal DNS.

The usage model for this multicast thing is very different from normal
DNS (every node for itself vs hierarchical, totally different models
for what constitutes authoritative data, totally different security
models, etc).  To me, this is enough to make it a different protocol
that happens to reuse some DNS data formats.

Unfortunately, even getting agreement on that much (that it was a
different protocol) was hard, in part because some participants
believed this whole thing should be as simple as putting a multicast
address into their /etc/resolv.conf files.  Sigh.  By the time we
achieved rough consensus that DNS and this other thing were different
protocols to be run on different ports with separate caches,
discussion had already become fairly polarized.

I happen to think that both mDNS and LLMNR crippled themselves by
attempting to wedge a totally different protocol into a DNS-like
framework (a lot of the DNS semantics make no sense in this different
usage model, so the developers of these protocols had to figure out
what to do for all the cases where the packet format expressed
something that had no analogue in the new protocol), but that's what
the proponants chose to do.  Their call, and hey, I could be wrong.

What I did care about was preventing leaks between normal DNS and this
other stuff.  Unless something changed since the last time I checked,
both mDNS and LLMNR use different ports and different caches from
normal DNS, so I have no problem with either one on this score.

Subsequent parallel development of LLMNR and mDNS was just weird, and
I mostly stayed out of it because my main concerns had already been
addressed.  There have been several attempts to reconcile the two
protocols, but in the end neither camp seems willing to budge.  The
differences between the two protocols have been discussed, several
times, in mind-numbing detail, all of which is available in the
namedroppers archives and the LLMNR issue tracker for anybody with the
intestinal fortitude to wade through it.

So, like Stuart, I find this mess sad and disturbing, but, unlike
Stuart, I don't see major harm (either way) with LLMNR.  It would have
been nice to have one protocol, but the people involved couldn't
settle their differences.  That happens sometimes.  Vendors who think
LLMNR is a better idea than mDNS are going to implement it anyway,
whether the IETF blesses it or not.  If the network effect (economic
sense) is going to make mDNS win no matter what happens with LLMNR, it
won't matter whether the IETF has blessed LLMNR or not.

So the only thing I see left for the IETF to decide is whether we're
going to continue arguing about this for another N years.

Let's not.

--Rob

["Little-Endians are Little-Endians and Big-Endians are Big-Endians
  and never the twain shall meet.

 "We would like to see some Gulliver standing up between the two
  islands, forcing a unified communication regime on all of us.  I do
  hope that my way will be chosen, but I believe that, after all,
  which way is chosen does not make too much difference.  It is more
  important to agree upon an order than which order is agreed upon.

 "How about tossing a coin?"

  --Danny Cohen, IEN 137, "On Holy Wars and a Plea for Peace"]

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf