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

From: Stuart Cheshire <[email-masked]>
Date: Wed, 24 Aug 2005 22:37:42 -0700

>The IESG has received a request from the DNS Extensions WG to consider 
>the following document:
>
>- 'Linklocal Multicast Name Resolution (LLMNR) '
>   <draft-ietf-dnsext-mdns-42.txt> as a Proposed Standard
>
>The IESG plans to make a decision in the next few weeks, and solicits
>final comments on this action.  Please send any comments to the
>[email-masked] or [email-masked] mailing lists by 2005-08-24.

My question about this document is one I've asked before in private;
it's time now that it was asked publicly.

What is this document for? No one has implemented this LLMNR protocol. No 
one has any plans to implement this protocol. No company plans to ship 
products using this protocol. Even Microsoft has not even hinted at plans 
to use LLMNR in Longhorn/Vista. All of Microsoft's hype in this area 
centers on a naming protocol they call Peer Name Resolution Protocol 
(PNRP). Noah Horton, Program Manager in charge of PNRP, says, "PNRP is in 
Windows Vista Beta 1. It is there and it is beautiful."

<http://blogs.msdn.com/noahh/archive/2005/08/11/450535.aspx>

I see no similar gossip surrounding LLMNR in Vista. In fact, a Google 
search for "LLMNR Windows Vista" finds just twelve hits. A typical burst 
of line noise finds more Google hits than that. Eleven of those hits are 
accidental -- copies of the IANA port number list. I found only one hit 
that looked like a plausible relevant match, but when I followed the link 
it was an article that begins:

>Say "howdy" to Bonjour 
>Apple's zero-config scheme leaves Microsoft and UPnP in the dust

<http://www.infoworld.com/article/05/06/03/23TCtigerSB_1.html>

So, what's LLMNR for, if no one actually wants to implement it?

I have my guess, but it's best explained by a brief bit of history:

Back in 1997 I attended a presentation at Stanford about SLP. I was 
stunned by all the really obvious flaws it had. I wrote up a critique of 
SLP and suggested that Apple should just implement the tried-and-true 
AppleTalk Name Binding Protocol (NBP) running over IP Multicast. Partly 
as a result of that and other similar things, Apple later hired me.

At an IETF social I discussed this idea of NBP/IP with Bill Woodcock. He 
said that the IETF would reject any attempt to mix an AppleTalk protocol 
with IP, but... if I could work out how to do the same thing using DNS 
packets, then that would be much more acceptable to the IETF community. 
It took me a little while, but I worked out how to encode the necessary 
semantics in terms of standard DNS records and queries.

I proposed this idea, and was told I needed a working group. So, the 
Zeroconf working group was created.

I proposed the idea again, and was told that it wasn't the charter of the 
Zeroconf working group; I'd have to take it to DNSEXT.

I proposed the idea to DNSEXT and was told (and I quote):

    Multicast DNS... stupid idea.
    Zero Configuration... stupid idea.
    You all stupid people. You go away now please.

(To be fair to the speaker, he was not a native English speaker. My 
attempt to say the same in Japanese would have been much less eloquent. 
And at least he was honest about his position on the subject.)

So, the DNSEXT working group had made itself clear. They thought 
Multicast DNS and DNS Service Discovery were stupid ideas, and would play 
no part in doing anything that would help or encourage or facilitate 
their creation.

So, I did go away. I designed the protocol, documented it in Internet 
Drafts, solicited feedback, implemented the protocol, and shipped it in a 
wide range of products. It's in Mac OS X 10.2, 10.3, and 10.4. It's in 
Bonjour for Windows. It's in Apple's AirPort base stations, and it's what 
lets them effortlessly share printers and stream music to your stereo. It 
runs on Linux, Solaris, FreeBSD, and pretty much every other Unix 
platform. Some Linux distributions already ship with it included. In 
addition to Apple's own Open Source implementation, there are several 
other competing Open Source implementations under various different 
licenses. There are implementations in Java and Python and C#. It's in 
your TiVos, your Axis network cameras, and Roku SoundBridges. It's in 
pretty much any recent network printer made by HP, Canon, Brother, Xerox, 
Lexmark, Epson (and probably other vendors I'm forgetting right now). It 
was in the printers being used in the IETF terminal room at IETF 63 in 
Paris, and if you work in any reasonably large organization that's bought 
a network printer in the last year or two then it's probably running on 
your network right now. If you only have Windows machines, then you're 
not out of luck -- you can discover those printers using Bonjour for 
Windows:

<http://www.apple.com/bonjour/>.

It is, though I say it myself, a huge success.

What is DNSEXT's response to this? Well, it was clear that the original 
plan, ignoring mDNS and hoping it would die on its own, had failed. What 
they needed was an IETF antibody. A decoy. A honey pot. Something to go 
out and compete against mDNS in the marketplace of ideas. Something that 
would have the appearance of being the "official" successor to mDNS, a 
siren to lure potential implementers onto the rocks.

Now, I can already hear a certain minority saying, "You've convinced me. 
LLMNR should be published as an IETF Standard. Apple's heresy must be 
stopped at any cost."

The question for the wider IETF community is whether that's what the IETF 
wants to do. Is the role of the IETF to foster interoperability, or to 
sabotage it? Are Internet Standard RFCs supposed to be useful things to 
be implemented, or are they supposed to be traps to ensnare the 
uninformed?

It reminds me of OSI. We had a perfectly good networking protocol -- 
TCP/IP -- so ISO decided they needed to make their own 
similar-but-not-quite-the-same protocol to compete with it, just for the 
sake of not wanting to adopt something invented elsewhere. ISO thought 
that because they were an "official standards body", whereas TCP/IP was 
just something that a bunch of guys had made that happened to work, that 
ISO could, by legislative fiat, oust the successful incumbent protocol. 
How many man-years of work were wasted by that abortive effort? Did OSI 
emerge from that debacle looking good, or looking bad?

In fact, this comparison to OSI is overly generous. OSI was implemented 
and actually worked. It was just unnecessary. The problem with LLMNR is 
that it is deliberately limited to prevent it from being used for service 
discovery, which, you may recall, was the whole motivation for beginning 
this work in the first place. LLMNR is presented as being the "official" 
sanctioned successor to mDNS, as if it were somehow equivalent in 
functionality but better designed, while in fact it is so 
self-contradictory and nonsensical that it actually does nothing useful 
at all.

Time and time again LLMNR has come up for last call. Each time I read it, 
and point out the fatal flaws and contradictions (that would have been 
painfully obvious to anyone had they actually tried to implement it). A 
few changes get made, and the document comes back around again. Piece by 
piece I'm designing a protocol for my competitors, so they can use it to 
compete with my own!

If the proponents of LLMNR are sincerely supporting it because they 
believe it offers useful functionality (and I like to believe that's the 
case), then lets see some actual implementations.

Whatever happened to "rough consensus and RUNNING CODE?"

Once we have some actual implementations to try out, then we can compare 
them with mDNS and see what might be necessary (on both sides) to make 
them interoperate usefully. I'm quite happy for LLMNR to be a compatible 
subset of mDNS. What's silly is for LLMNR to be gratuitously incompatible 
for the sake of being incompatible. Bernard Aboba has an FAQ Web site 
where he writes:

<http://www.drizzle.com/~aboba/DNSEXT/llmnrfaq.html>

> Apple's mDNS protocol differs from LLMNR (and DNS) in more than
> half a dozen ways.

He then goes on to list a bunch of similarities like "Apple's mDNS does 
not share the DNS cache", and finishes with:

> Apple mDNS and LLMNR use different ports, as well as different
> multicast addresses, and because of the many protocol
> differences, do not interoperate.

Isn't that circular logic? They use different ports and multicast 
addresses because they're incompatible, but the main reason they're 
incompatible is because they use different ports and multicast addresses? 
Surely that particular incompatibility could be remedied easily, merely 
by NOT choosing to use a different port and multicast address?

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

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Peter Dambier <[email-masked]>
Date: Thu, 25 Aug 2005 12:41:39 +0200

>>[email-masked] or [email-masked] mailing lists by 2005-08-24.

I really would appreciate do think IESG should postpone or reject.

This protocoll is untested!

Its implementation could result in a loss of lives!

There is no reference implementation.

>>Apple's mDNS protocol differs from LLMNR (and DNS) in more than

1. It is emplemented.

2. Mostly everybody does use it.

3. mDNS did not result in the loss of lives.

>>differences, do not interoperate.

Consider:

RFC 1149 - Standard for the transmission of IP datagrams on avian carriers

Everybody thinks of implementing RFC 1149 on birds only or at least on
living beeings with feathers.

How about insects? How about bats?

Here in Germany we have accidently closed the entrance to a tunnel used by
bats. To save their lives we opened a new entrance into that tunnel.

The bats did not know. Millions lost their lives crashing into the debries
from the old entrance.

Moving wellknown ports and addresses is like randomly opening and closing
tunnel.

In my honest oppinion this draft does violate RFC 1149 and it knowingly
riscs the loss of lives ...

Forget about bats and bees now. Think of existing programmes and appliances.
Do you want to kill them?

Kind regards,
Peter and Karin Dambier

-- 
Peter and Karin Dambier
Public-Root
Graeffstrasse 14
D-64646 Heppenheim
+49-6252-671788 (Telekom)
+49-179-108-3978 (O2 Genion)
+49-6252-750308 (VoIP: sipgate.de)
+1-360-448-1275 (VoIP: freeworldialup.com)
mail: [email-masked]
http://iason.site.voila.fr
http://www.kokoom.com/iason

---

From: Margaret Wasserman <[email-masked]>
Date: Thu, 25 Aug 2005 10:09:35 -0400

Hi Peter,

At 12:41 PM +0200 8/25/05, Peter Dambier wrote:
>Stuart Cheshire wrote:
>>>The IESG has received a request from the DNS Extensions WG to 
>>>consider the following document:
>>>

The IETF does not define reference implementations.  This document 
has been submitted for Proposed Standard (PS) publication, and there 
are no specific implementation requirements for publication at the PS 
level, which is the first level of the IETF standards track.  Two 
interoperable implementations are required for advancement to Draft 
Standard.

However, I have been told (although I cannot personally verify this) 
that the LLMNR protocol has been implemented in Microsoft WinCE 5.0, 
and that statement is supported by the release notes that can be 
found at:

http://download.microsoft.com/download/0/8/0/08000f6b-974b-4384-90d0-26440d9ecbcf/relnotes.rtf

>>>differences, do not interoperate.

The DNSEXT WG understands that LLMNR is not identical to the Apple 
mDNS protocol and that it will not interoperate with it.  In fact, 
the reason that LLMNR runs on a different port is that it is known to 
be different.

>Do you want to kill them?

I do not understand how defining a new, different service on a new 
port will kill anything.  There is nothing about the existence LLMNR 
that would prevent hosts from running Apple's proprietary mDNS 
protocol on the existing Apple mDNS port.

I don't think that you have raised any issues here that have not 
already been discussed in the DNSEXT WG.  If you do have specific 
technical objections to the LLMNR protocol, could you re-state them a 
bit more clearly so that I can understand what they are?

Thank you,
Margaret

---

From: Keith Moore <[email-masked]>
Date: Thu, 25 Aug 2005 17:22:17 -0400

> to use LLMNR in Longhorn/Vista. 

I don't see anything in RFC 2026 criteria that hinges on whether
Microsoft intends to implement a protocol.

Local name lookup is useful, but trying to overload DNS names to serve
two different purposes, without breaking apps and/or making DNS appear
to be inconsistent, is fairly difficult.  There's an inherent conflict
between wanting local name lookup to be transparent to apps
(perhaps even by changing the semantics of existing and well-established
APIs to do local lookup in addition to DNS lookup), and having the two
lookup services produce inconsistent results (thus confusing apps that
quite reasonably expect that they should be consistent).  If you try
to make the two kinds of names look different you risk breaking apps
that expect everything to look like a DNS name.  And if you overload
DNS syntax then you subject DNS servers to bogus queries.  

The primary reason IETF exists is to try to sort out those kinds of
conflict in an open, neutral setting. 

For whatever reason, you chose to ship code without waiting for IETF to
finish its deliberations on how to resolve those conflicts. Maybe you
were right to do so.  I wish I could say that IETF always produces
superior results, but we all know that it desn't always succeed.  And
yet, by doing so you were essentially disregarding others' legitimate
concerns about the problems associated with your approach, and/or
unilaterally deciding, on behalf of not only your customers but
everyone who might be affected by deployment of your protocol, that you
are in a better position to know what is good for them than everyone
else who participated in IETF.

Now you are arguing  that people who attempted to consider a wide range
of input, and to do a responsible job of engineering a DNS-compatible
name lookup solution should abandon the results of their efforts in
favor of your ad hoc solution, merely because you were irresponsible
enough to ship it in product before the issues were widely understood
and the conflicts resolved in an open forum.

Well, maybe you're right, and maybe mDNS is better than LLMNR.  Or
maybe mDNS is only slightly worse, and not enough worse to make it
worth the confusion that standardizing LLMNR will create.  But you're
not going to convince anybody of that with your current line of
argument.

IMHO, if you can't provide a thorough analysis indicating that mDNS
works better than LLMNR,  that mDNS resolves those conflicts in a
superior way to LLMNR, and that your solution will do less harm to
applications and DNS consistency than LLMNR, and that mDNS conforms to
2026 criteria, you don't have much of a gripe, and you certainly don't
have justification for saying that LLMNR should be abandoned.

You ask about running code.  Running code is useful.  A single
impelmentation serves as a proof of concept.  Multiple implementations
derived from a single spec and tested against each other serve as a
clarity check on the specification.  But mere existence of running code
is not a reliable indicator of sound design.  In the ARPAnet days, when
there were only a few dozen hosts, a few interoperability tests were
generally enough to give a reliable indication of full-scale behavior.
In an Internet with a billion hosts, producing an implementation is
just a baby step.  These days, there's no substitute for thorough
analysis of the effect of a protocol based on a large number of use
cases.  So mDNS's running code and deployment do not trump LLMNR, and a
comparison of mDNS and LLMNR implementations would not yield much
useful data unless one were grossly more inefficient than the other.

As for this Last Call - I think there are two questions that should be
asked:

1. does LLMNR meet 2026 criteria?  no known technical omissions,
conflicts resolved, etc. 

2. is LLMNR enough better than mDNS to make it worth approving it as a
standard even though mDNS exists and has some limited deployment?   If
the answer to #1 is yes, then I suspect the answer to #2 is also yes,
but an explanation is needed.

Furthermore, if there is rough consensus, supported by analysis, that
mDNS is harmful, then we ought to consider saying that.  But we
shouldn't make this statement critical path for getting LLMNR out the
door.

Keith

---

From: Peter Dambier <[email-masked]>
Date: Fri, 26 Aug 2005 00:32:12 +0200

> Microsoft intends to implement a protocol.

I have seen windows boxes use it. They left traces on our root servers
and they cried when we hit them treating ".local" like "localhost"

It was windows users who complained not Macintoshes.

> DNS syntax then you subject DNS servers to bogus queries.  

Bogus queries do sabotage our root servers. They make 90% of our traffic.
That is what "root-servers.net" say. I have seen traffic reduced on
"a.public-root.net" by some 25% when we showed them a dummy for ".local".

> else who participated in IETF.

They are restricted to their local LANs. I have never seen them in the
wide, wild internet.

> useful data unless one were grossly more inefficient than the other.

I'd say 25% of traffic on root servers is grossly inefficient and it does
violate a couple of RFCs.

> shouldn't make this statement critical path for getting LLMNR out the

Regards,
Peter and Karin