Subject: Re: LLMNR interoperability with Rendezvous?

From: Bernard Aboba <[email-masked]>
Date: Sun, 31 Aug 2003 21:57:38 -0700 (PDT)

Olaf Kolkman wrote:

"Going back to our proposal, you are providing us 2 lists. We now have 1
item and we would like to make sure:

- Is this 1 item the complete list of issues previously discussed and
  that need to be reviewed?

- Is the list of 'new items' an empty list?

We proposed the process so that the working group can make an informed
decision, based on the amount of things that need to be revisited, if
we need to go back and re-argue the issue.

No hidden surprises further down the road ;-) ?

--Olaf Kolkman
  DNSEXT Co-Chair

Just off the top of my head, it would appear to me that the following
additional interoperability issues also exist:

a. LLMNR responders are not authoritative for names within the ".local"
domain. Won't this create problems in responding to queries by Rendezvous
senders? Does the reverse problem also exist? (will Rendezvous responders
respond to queries for domains outside of .local?)

b. Multicasting. LLMNR sends unicast responses as well as queries.  There
was mention in Issue 44 that the unicasting of queries created an
interoperability problem.  What about the unicasting of responses?

c. Lack of support for DNS-SD.  LLMNR senders and responders typically
won't support DNS-SD.  This implies that they won't respond to TXT RR
queries with appropriately formatted responses. Won't this cause problems
as well?

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Stuart Cheshire <[email-masked]>
Date: Sat, 6 Sep 2003 09:35:09 -0700

>Going back to our proposal, you providing us 2 lists. We now have 1 item 
>and we like to make sure:
>

I am not aware of any other show-stopping incompatibility between Apple 
Rendezvous and LLMNR, but I do not have an implementation of LLMNR to 
test with.

Perhaps one of the LLMNR implementers could test their code against OS X 
and report whether it works?

One area that I think is currently weakest in LLMNR, is the issue of 
"unqualified names". The dilemma is that from one point of view, all DNS 
names are fully qualified, and from another, almost none of them are:

* All names are fully qualified: When you actually try write the code, 
you find that all names in DNS packets are fully qualified. This is 
something that is not neccessarily apparent to someone whose only 
interaction with DNS until now has been on the user-interface side -- 
i.e. writing zone files for BIND, but not writing the code that puts that 
data in packets. Zone files can have unqualified names and often do. DNS 
packets cannot.

* Almost all names are *not* fully qualified: On the user-interface side, 
almost no one puts the trailing dot at the end of names. Not in email 
addresses, not in URLs, not in command-line programs like telnet, ssh, 
ftp, etc. Even if you, as a user, are diligent and put the trailing dot, 
almost all "A HREF" links on web page do not, so the resolver library on 
your computer is constantly being bombarded with unqualified names.

This leads LLMNR to the following dilemma: Under the current rules, 
almost *every* name entered by a user or encountered in a URL is a 
legitimate candidate for LLMNR resolution. The only names that are *not* 
candidates for LLMNR resolution are the ones *received* as replies to 
LLMNR queries for CNAME, PTR, SRV, etc. This seems backwards. The only 
thing LLMNR doesn't work with is itself!

>No hidden surprises further down the road ;-) ?

The base idea in Apple Rendezvous and LLMNR is the same -- send 
DNS-format queries via multicast. Building on that base, Apple Rendezvous 
adds a bunch of capabilities. There is a spectrum of compatibility here, 
from "working" (which is what I believe we have now, aside from the TTL 
issue) to "working well", to "full feature parity". I am quite confident 
that the more ambitious features of Apple Rendezvous will be considered 
far too novel to be accepted by this working group. Others will fall 
somewhere in the middle of the spectrum. Implementing all of the optional 
parts is not necessary for interoperability. Using TCP as an analogy, a 
good example of what I'm talking about is things like slow start, fast 
retransmit, fast recovery, etc. A device that doesn't implement these 
things may not work as well as a device that does, but it still 
interoperates with a device that does.

To be clear, I have no intention of trying to sell this WG on the idea of 
adopting every last one of the esoteric features of Apple Rendezvous, 
such as:

* Efficiently handling the case where a query may elicit responses from a 
hundred or more different peers.

* Known-answer suppression -- when a query is retransmitted, the ability 
to avoid the same hundred hosts answering over and over again.

* Allowing multiple questions in a single packet, so that a batch of ten 
questions may be sent as a single packet instead of ten separate 
multicasts. The semantics of this at the receiver treats the query packet 
exactly as if it were the same as ten separate query packets each 
containing just a single question.

* Name-space management -- informing users when two machines are trying 
to use the same name, and assisting the user in the process of picking a 
new one.

* Tie-breaking when multiple machines are powered on simultaneously.

* Support of sleep proxy server for power management.

* The option to request responses by multicast or unicast, at the 
requester's discretion. Multicast responses may seem to increase the 
traffic load because every host sees the response as well as the query, 
but in fact experimental measurement shows that it does the opposite. 
Multicast responses allow other machines to suppress their own queries, 
because they know that if there is an answer to the query, they will see 
it, and correspondingly, if they don't see an answer to the query, that 
means there isn't one, because if there was, they would have seen it. If 
I see you do a query and I don't see any answer, then I don't need to 
repeat the same query myself -- there's no reason to believe that my 
attempt to elicit a response is any more likely to be successful than 
yours. So, when responses are multicast, everyone pays the cost of 
receiving the response, but then they save by *not* having to pay the 
cost of receiving all the multicast queries which are then subsequently 
suppressed. In summary, instead of ten multicast queries and ten unicast 
responses on the network, you get one multicast query and one multicast 
response. This is a net win.

* And so on...

None of this is secret. All of this (as of June) is described in
<http://www.ietf.org/internet-drafts/draft-cheshire-dnsext-multicastdns-02.
txt> In addition, all of the source code is open. Anyone can check out 
the source code from the Apple CVS server and see every change, every 
branch, every tag, every checkin comment, exactly the same as the 
engineers inside the company.
<http://developer.apple.com/darwin/projects/rendezvous/>
The code is a little ahead of draft-02 right now, but we'll be updating 
the draft to catch up as soon as we get some time after OS X 10.3 ships.

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

---

From: Stuart Cheshire <[email-masked]>
Date: Fri, 19 Sep 2003 19:04:01 -0700

>This entire episode, including the reversal of the rough consensus
>favoring TTL=1 for link-local traffic in the ZeroConf WG, brings to mind 
>the freshman engineering example in which a column is removed from a 
>room for aesthetic reasons, rendering the entire building weak.
>Please do not mess with the foundation without compelling reasons!

John, you have this completely backwards.

Up to draft-ietf-dnsext-mdns-17.txt, it said:

>In composing an LLMNR response, the responder MUST set the Hop Limit
>field in the IPv6 header and the TTL field in IPv4 header of the LLMNR
>response to 255.  The sender MUST verify that the Hop Limit field in
>IPv6 header and TTL field in IPv4 header of each response to the LLMNR
>query is set to 255.  If it is not, then sender MUST ignore the
>response.

It was only a couple of months ago, after Apple and other companies had 
been shipping products for over a year, that DNSEXT decided to reverse 
its consensus.

You may remember that I was one of the people who argued for TTL=1 in the 
first place, but I was swayed by the working group consensus, so we 
shipped with TTL=255, and then the working group changed its mind back 
again.