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

Stuart Cheshire <> Thu, 25 August 2005 05:37 UTC

Received: from localhost.localdomain ([] by with esmtp (Exim 4.32) id 1E8AR5-0001g7-FV; Thu, 25 Aug 2005 01:37:59 -0400
Received: from ([] by with esmtp (Exim 4.32) id 1E8AR0-0001ft-0E; Thu, 25 Aug 2005 01:37:55 -0400
Received: from (ietf-mx []) by (8.9.1a/8.9.1a) with ESMTP id BAA16617; Thu, 25 Aug 2005 01:37:52 -0400 (EDT)
Received: from ([]) by with esmtp (Exim 4.43) id 1E8ARR-0006hK-VK; Thu, 25 Aug 2005 01:38:22 -0400
Received: from ( []) by (8.12.11/8.12.11) with ESMTP id j7P5bhKZ003873; Wed, 24 Aug 2005 22:37:43 -0700 (PDT)
Received: from ( by (Content Technologies SMTPRS 4.3.17) with ESMTP id <>; Wed, 24 Aug 2005 22:37:43 -0700
Received: from [] ( []) by (8.12.11/8.12.11) with SMTP id j7P5bgdU015864; Wed, 24 Aug 2005 22:37:43 -0700 (PDT)
Message-Id: <>
Date: Wed, 24 Aug 2005 22:37:42 -0700
x-mailer: Claris Emailer 2.0v3, January 22, 1998
From: Stuart Cheshire <>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-transfer-encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0e9ebc0cbd700a87c0637ad0e2c91610
Content-Transfer-Encoding: quoted-printable
Subject: Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>

>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
> or 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."


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


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 


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 

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:


> 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 <>
 * Wizard Without Portfolio, Apple Computer, Inc.

Ietf mailing list