Subject: LLMNR interoperability with Rendezvous?

From: Stuart Cheshire <[email-masked]>
Date: Thu, 28 Aug 2003 11:03:35 -0700

I'm asking this question at the suggestion of Ólafur Gudmundsson.

Is there any interest in this working group in making LLMNR interoperate 
with Rendezvous?

In addition to Mac OS 9 and OS X, there's Rendezvous for Linux, Windows, 
VxWorks and other platforms. There are Rendezvous network printers, 
network scanners, headless Rendezvous file servers, consumer electronics 
home Hi-Fi equipment, home media servers, and so on.

LLMNR could interoperate with that installed base with only a few trivial 
changes, but the will to make those changes depends on whether the 
working group has any interest in interoperability.

Opinions?

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

--
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: Masataka Ohta <[email-masked]>
Date: Fri, 29 Aug 2003 18:14:12 +0859 ()

It seems to me that the question should be whether the protocol
called Rendezvous is good enough or not.

If it is not, we should keep LLMNR, which may or may not interoperate
with Rendezvous.

If it is, we should simply use it and abandon LLMNR.

						Masataka Ohta

---

From: Paul Vixie <[email-masked]>
Date: Fri, 29 Aug 2003 15:12:40 +0000

> If it is, we should simply use it and abandon LLMNR.

as a proponent of the DISCOVER opcode, i have some sympathy for the above
position.  however, rendezvous and llmnr are not merely different ways to
accomplish the same thing... they accomplish different things.  for example
when selecting a printer or file server, apple's macos/x users see the list
of available resources instantly when they bring up a "chooser" panel; this
is because the services periodically solicit themselves in some multicast
kind of way.  to do resource discovery of this kind with llmnr would mean
a short delay when the panel was being initialized, while all relevant
servers and printers heard a query and sent a reply.  i do not think that
apple would consider llmnr a successful replacement for rendezvous as long
as this feature difference existed.

i think it's clear that "architecture" did not happen with regard to dns
and multicast.  so i really do have sympathy for the above position.

---

From: Stuart Cheshire <[email-masked]>
Date: Fri, 29 Aug 2003 19:34:16 -0700

>Stuart, please provide the working group with a list with issues
>previously not discussed and a separate list of items that have been
>discussed. Please provide that list before the end of next week (Sep
>7).

The road block is the TTL incompatibility:

Rendezvous sets IP TTL=255, and checks IP TTL on reception, and discards 
packets that have lower TTLs indicating that they may originate from 
off-link attackers.

LLMNR sets IP TTL=1, and on reception discards packets that don't have IP 
TTL=1.

Aside from that difference, Rendezvous does everything that LLMNR does.
The packet formats are identical (DNS packet format).
A Rendezvous responder will respond to queries from a LLMNR querier,
and a LLMNR responder will answer queries from a Rendezvous querier,
were it not for the fact that they are both choosing to ignore and
discard each other's packets. This seems like a silly incompatibility.

Ólafur wrote:
>  the document went through numerous cycles during which issues
>  where thoroughly discussed. The issue of the TTL=1 has review
>  from the working group and that issue is not to be opened again.

So, this is the show-stopping incompatibility. We can't change 
Rendezvous's TTL handling because too many Rendezvous hardware products 
have already shipped from Apple and other companies. DNSEXT can't change 
LLMNR's TTL handling because it has been thoroughly discussed and is not 
to be opened again.

This is an impasse. Even with the best will in the world, the 
circumstances are such that it is simply not possible for either side to 
make the change to interoperate with the other.

---

From: Stuart Cheshire <[email-masked]>
Date: Fri, 29 Aug 2003 19:34:52 -0700

Randy Bush wrote:

>sure.  what changes will be needed in rendezvous?

We'd need to add the ability to respond to TCP connections (which is 
something that was always in the plans anyway; we simply haven't had any 
devices that needed it yet).

There are several things that Rendezvous does that LLMNR doesn't, but I 
was not asking the Working Group to adopt these extensions. They are 
things that Rendezvous does to accomodate the situation where more than 
one host may respond to a given query, something that has not been a 
priority for this Working Group or LLMNR.

---

From: Michael Richardson <[email-masked]>
Date: Sun, 31 Aug 2003 08:42:42 -0400

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "Stuart" == Stuart Cheshire <[email-masked]> writes:
    Stuart> The road block is the TTL incompatibility:

    Stuart> Rendezvous sets IP TTL=255, and checks IP TTL on reception, and
    Stuart> discards packets that have lower TTLs indicating that they may
    Stuart> originate from off-link attackers.

    Stuart> LLMNR sets IP TTL=1, and on reception discards packets that don't
    Stuart> have IP TTL=1.

  If I'm not mistaken, the BGP protocol originally used TTL=1, but now
recommends using TTL=255 and checking that way instead.

]      Out and about in Ottawa.    hmmm... beer.                |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another Debian/notebook using, kernel hacking, security guy");  [

---

From: Ted Lemon <[email-masked]>
Date: Sun, 31 Aug 2003 11:50:02 -0400

> recommends using TTL=255 and checking that way instead.

Hm.   I was one of the people who thought that TTL=255 wasn't such a great 
idea, all other things being equal.   However, nobody ever presented any 
strong reason why we should use one over the other - it was always a matter 
of preferences and fine distinctions.

I really don't think insisting on TTL=1 is a good idea if it means we can't 
interoperate with a lot of existing devices out there, because there isn't a 
clear advantage to it.   It winds up just being a gratuitous incompatibility.

So although the time is late, and I'm not in love with the idea of reopening 
resolved issues, I think this is worth changing.

---

From: Michael Richardson <[email-masked]>
Date: Sun, 31 Aug 2003 12:21:26 -0400

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "Ted" == Ted Lemon <[email-masked]> writes:

    Ted> Hm.  I was one of the people who thought that TTL=255 wasn't such a
    Ted> great idea, all other things being equal.  However, nobody ever
    Ted> presented any strong reason why we should use one over the other -
    Ted> it was always a matter of preferences and fine distinctions.

  TTL=1 depends upon the routers dropping at exactly the right time.
  TTL=255 is locally checkable, but requires that link-local multicast works.

  Both depend upon the router doing something correctly.
  I can't comment on what has been broken more often. I think that there
are/were many "internet-sharing" programs for windows(95) which broke TTL=1
processing. Odds are they didn't even speak multicast, so I don't know what
the major risks are.

---

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?