>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 >iesg@ietf.org or ietf@ietf.org 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 PROTECTED]> * Wizard Without Portfolio, Apple Computer, Inc. * www.stuartcheshire.org _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
