Subject: Re: LLMNR is done

From: Stuart Cheshire <[email-masked]>
Date: Mon, 26 Jan 2004 20:04:36 -0800

>On  August 29, 2003 Olaf Kolkman posted the following message to the
>DNSEXT WG mailing list summarizing the situation:
>
>http://ops.ietf.org/lists/namedroppers/namedroppers.2003/msg01620.html
>
>In this message, he made the request that *all* changes required
>to achieve interoperability be provided.  No answer was received.

Unfortunately, *everything* seems subject to intense debate, even what 
the list of things to debate is. Before embarking on that debate, I asked 
if the working group had any interest in working for interoperability 
with the installed base. No answer was received.

>Known differences between Rendezvous and LLMNR

I think there are some misperceptions here; I should correct them.

>a. Rendezvous uses multicast responses.  LLMNR uses unicast.

Rendezvous uses both unicast and multicast responses, depending on what 
is most efficient. If only one client is likely to want a particular 
response, then unicast is used. If multiple clients are likely to want 
the response, then multicast is used.

>b. Rendezvous allows proxying; LLMNR does not.

Sleep proxy servers for power management are an important part of meeting 
Energy Star and Blue Angel energy consumption requirements. As the limits 
get tighter and tighter each year, it is going to become increasingly 
hard to sell products that don't have this kind of intelligent power 
management.

>c. Rendezvous uses the header bits differently, including AA, TC, RD,
>RA, AD, CD

Can you elaborate? I'm not aware of any substantive differences.

>d. Rendezvous and LLMNR uses different retransmission strategies and
>timers.

Surely these are trivial differences that could be easily agreed.

>e. Rendezvous uses ".local" extension, LLMNR does not.

This is a red herring. The dot-local debate exists at a layer above 
Rendezvous/LLMNR. Apple (and others) use dot-local to trigger an explicit 
multicast query; other names may be looked up according via unicast or 
multicast depending on situation, just as with LLMNR.

>f. Rendezvous requires TTL=255; LLMNR uses TTL=1.

The TTL check is, as you know, to guarantee that packets really 
originated on the local link (*especially* unicast replies). I'm told 
that in the latest Windows XP Service Pack lots of services have been 
locked down the local link by default for "security", so I would have 
thought that having the ability to do the same for LLMNR would have met 
with Microsoft's approval in the current climate. Note that setting the 
TTL to 255 allows the receiver to check the TTL; it doesn't *require* the 
receiver to check if it doesn't want to.

>g. LLMNR supports unicast queries; Rendezvous does not.

Incorrect. Rendezvous supports unicast queries as well as multicast, and 
always has.

>h. LLMNR and Rendezvous use different multicast addresses and ports.

This is the ultimate red herring. They only use different multicast 
addresses and ports because of perceived differences (a)-(g).

So, as I have said before, the only real show-stopping incompatibility I 
see is the decision on the TTL.

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: [email-masked] (Jun-ichiro itojun Hagino)
Date: Tue, 27 Jan 2004 18:53:58 +0900 (JST)

> with the installed base. No answer was received.

	i guess i missed your message - yes, i'd love to see Rendezvous
	and LLMNR be interoperate (or converge into a single protocol).

itojun

---

From: Brad Hards <[email-masked]>
Date: Tue, 27 Jan 2004 21:06:51 +1100

> with the installed base. No answer was received.
I have interest in interoperability with MacOS and Windows boxes. Unix 
variants in embedded applications, and Unix variant boxes as clients in mixed 
environments require it.

> the response, then multicast is used.
I don't see this as a fundamental issue. Worst case is we require both 
multicast and unicast responses, but agreement on which is better in some 
common cases shouldn't be that hard.

> hard to sell products that don't have this kind of intelligent power
Again, not fundamental. Add proxying as a MAY, and explain to implementers the 
tradeoff.

> Can you elaborate? I'm not aware of any substantive differences.
Pass for now.

> Surely these are trivial differences that could be easily agreed.
Without looking at the detail, I'd have to agree.

> multicast depending on situation, just as with LLMNR.
I see .local as a useful scoping approach. Easy to explain to part-time 
sysadmins too.

> receiver to check if it doesn't want to.
This has been done a time or two (perhaps more). There is no obviously best 
way. In this case, we might as well choose the path of least gratuitous 
breakage.
 
> Incorrect. Rendezvous supports unicast queries as well as multicast, and
We probably should support both. 

> addresses and ports because of perceived differences (a)-(g).
I see it as "self fulfilling requirement". Either we agree a compatible 
protocol, or we support running both on different mc addresses and ports 
(optionally with a shared cache).

Brad

---

From: Ted Lemon <[email-masked]>
Date: Tue, 27 Jan 2004 09:45:21 -0600

I don't have anything substantive to add except that I would really, 
really like to see Rendezvous be able to interoperate with LLMNR.   I 
use Rendezvous a _lot_, it makes a big difference in the usability of 
my network, and the one big remaining hole right now is that it doesn't 
work with Windows.   :'(

I think that resolving the TTL issue in favor of the way Rendezvous 
does it is a good solution - there are pros and cons to both ways of 
doing TTL, and in fact it was as a result of debate about this issue 
with regard to LLMNR that Rendezvous switched to this scheme 
originally.

I've weighed in on this several times in the past - the only reason 
I've stopped saying anything about it is because I've given up hope in 
the process - it's seemed recently that there was no interest at all in 
making LLMNR and Rendezvous interoperate.   It sounds like this is not 
actually the case, and that a lot of other folks have been silent as 
well, perhaps for the same reason.   :'/

---

From: Paul Vixie <[email-masked]>
Date: Tue, 27 Jan 2004 17:38:38 +0000

> the process - it's seemed recently that there was no interest at all
> in making LLMNR and Rendezvous interoperate.  It sounds like this is
> not actually the case, and that a lot of other folks have been silent
> as well, perhaps for the same reason.  :'/

i think aboba's assessment may be accurate, which is that these are
different protocols with different applicability statements.  if that's
true then simply advancing both of them, each with an applicability
statement that makes clear why it exists and what its purpose and scope
is, is a reasonable approach.

for example, i saw a demo where a mac found a desktop printer without
either one of them having an ip address, and a mac found an mp3 jukebox
without either one of them having an ip address.  the chooser/browser
widget just came up and showed what it found.  is this sufficiently
different from llmnr's target and purpose that we can reasonably say
that both protocols can be advanced, and both will be in the field, and
they are not competing approaches to the same problem space?

---

From: Alain Durand <[email-masked]>
Date: Tue, 27 Jan 2004 10:31:51 -0800

I really have a hard time with the idea that LLMNR & Rendez-vous address 
different needs.
There is so much overlap that, in a normal worl, convergence would be 
the most sensible avenue.
If we, as a collection of vocal individuals, cannot put ego aside and 
can't converge, please, at least,
let's make those two interoperable.

    - Alain.

---

From: Paul Vixie <[email-masked]>
Date: Tue, 27 Jan 2004 18:49:16 +0000

> I really have a hard time with the idea that LLMNR & Rendez-vous address

nevertheless i think the llmnr authors might in fact intend it for
a different use, in which case we could expect to see microsoft and
apple each implement both rendezvous and llmnr, which would lead to...

> the most sensible avenue.

...convergence.  in which case, as long as ietf advances them in tandem,
and with well written applicability statements to motivate implementors
to put both of them in (where appropriate), then...

> can't converge, please, at least, let's make those two interoperable.

...we will have done the job we agreed to do when attending ietf functions.

if on the other hand alain (quoted above) is correct and these protocols
address identical needs or significantly overlapping needs, then it would
be irresponsible of us to advance both drafts, or to advance only one.

---

From: Ralph Droms <[email-masked]>
Date: Tue, 27 Jan 2004 14:18:01 -0500

Paul - can you explain what you mean by "without either one of them having
an ip address".  If I take that statement literally, I wonder why the IETF
would be interested in a protocol that doesn't use IP?

- Ralph

---

From: Paul Vixie <[email-masked]>
Date: Tue, 27 Jan 2004 19:26:08 +0000

> would be interested in a protocol that doesn't use IP?

i misspoke.  there was no dhcp server, no dhs server, no server of any kind.
of course there were ip addresses, but they were self assigned and invisible
to the user.

to get a non-rendezvous laptop to see a non-rendezvous desktop printer, i'd
have had to set, or at least know, one or both ip addresses.  and there would
not have been a way to get it to show up in the chooser/browser tool.

what this really comes down to is applicability.  yesterday here, aboba said
that rendezvous and llmnr were different protocols intended for different
uses.  if the community agrees, then both docs should be advanced, with clear
applicability statements.  if the community doesn't agree, then a new/merged
specification should be developed and advanced, with a notation that apple's
existing protocol is to enjoy no special advantage, regardless of the size
of their installed base.

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 28 Jan 2004 06:17:58 +0900

Paul;

> is, is a reasonable approach.

As both of them are designed for closed home network with
dumb administration (which means it is crazy to make TTL
of multicast larger than 1, even more crazy than that of
DHCPv6) and neither of them are useful for hosts connected
to the public internet, we, Internet ETF, should not mind
so much how they evolve or ruin, as long as it is made
clear that they are not useful to the Internet and should
not be used on hosts connected to the Internet.

							Masataka Ohta

---

From: "Al Costanzo" <[email-masked]>
Date: Tue, 27 Jan 2004 17:43:39 -0500

Are you speaking about an old protocol (non-routable) that does not need IP
because it just finds MAC addresses on small nets? (kinda sorta like one of
the options HP has/had for thier network printers?)

-Al

---

From: Robert Elz <[email-masked]>
Date: Tue, 27 Jan 2004 14:47:28 +0700

Date:        Mon, 26 Jan 2004 20:04:36 -0800
    From:        Stuart Cheshire <[email-masked]>
    Message-ID:  <[email-masked]>

  | So, as I have said before, the only real show-stopping incompatibility I 
  | see is the decision on the TTL.

Perhaps a possible compromise.   (In other contexts I have argued against
any TTL rules at all - that wasn't in the context of a particular
application, I see no problem with telling applications what TTL is
appropriate for them to use).

As I understand it, the argument for TTL=1 is that it restricts packets
to the local net, they won't accidentally go further than that.

The argument for TTL=255 is that it allows hosts to verify that packets
originated from the local net, and didn't come from off net.

The verification (it seems to me) is only really important for answers.
That is, it is entirely reasonable for a host to care whether the answer
it received came from a local responder, and not someone-off net doing
bad (or just stupid) things.

On the other hand, someone being asked a query should not care too much
where the query came from - if it is doing things sensibly, it will only
be sending its answer to its local net anyway, if the query came from
further away, no reply will be received - so by verifying the query came
from the local net, all that really can be achieved is to save a little
work (perhaps a useful gain, but hardly a requirement).

Packets going off net when they serve no useful purpose is a minor annoyance
when they're unicast, but it is something that really wants to be avoided
with multicast.   So, I think setting TTL==1 on multicast packets is
definitely right.   Even for multicast replies, that's likely the best
thing to do.

For unicast packets, I'd think TTL==255 is OK - unicast LLMR packets are likely
to be replies, where verifying that the packet came from the local net is
more important.   Preventing unicast packets "escaping" is a pretty meaningless
thing to do (or even hope to do) - if LL addresses are involved, they won't
escape anyway, otherwise an occasional packet may go somewhere it isn't
wanted - I don't see that as an important enough issue to argue about.

kre

---

From: Andras Salamon <[email-masked]>
Date: Wed, 28 Jan 2004 10:03:26 +0200

> originated from the local net, and didn't come from off net.

How about requiring queries to use TTL=255, to ensure only members of
the local network can generate queries, and requiring answers to use
TTL=1, which stops responses leaving the local network?  This would stop
denial of service attacks caused by injection of queries into the local
network, and would damp any DoS attempts originated on the local network
before they left.  It also strongly ties the protocol to local networks,
satisfying at least one member of the working group.

Of course, this would have the side effect of breaking both LLMNR and
Rendezvous.

-- Andras Salamon                   [email-masked]

---

From: Jakob Schlyter <[email-masked]>
Date: Wed, 28 Jan 2004 11:40:53 +0100 (CET)

> see is the decision on the TTL.

I'd like to second this and I really hope the chairs will allow the WG to
work this out before advancing the docs.

rendezvous has been proven to work well in the real world (i.e. outside
the ietf) and I cannot see why not to follow the path it has taken. if we,
as the WG, cannot resolve this issue, we have failed.

	jakob

---

From: John Schnizlein <[email-masked]>
Date: Wed, 28 Jan 2004 06:33:30 -0500

It is worth noting that this 11th hour attempt to reverse the TTL=1
decision in this WG is much like the 11th hour (after the chair
announced ROUGH consensus) change in the Zero-Conf WG. There also,
the old history of earlier consideration of TTL=1 was presented
as justification for the reversal to support TTL=255. The change
of the meaning of this field in the IP header is unnecessary and
risky. That it hasn't caused trouble yet is insufficient justification.

In the Zero-Conf WG, my concern that the reversal made its
specification at odds with the consensus reached in DNS-ext was
ignored. Returning to the original rough consensus in Zero-Conf
would restore compatibility between these WGs.

Why all this new reference to Rendezvous? Note that it was not
mentioned in the Zero-Conf charter at all. Zero-Conf progressed
as if independent of a single vendor's implementation until near
the end.

John

At 10:45 AM 1/27/2004, Ted Lemon wrote:
>I don't have anything substantive to add except that I would really, really like to see Rendezvous be able to interoperate with LLMNR.   I use Rendezvous a _lot_, it makes a big difference in the usability of my network, and the one big remaining hole right now is that it doesn't work with Windows.   :'(
>
>I think that resolving the TTL issue in favor of the way Rendezvous does it is a good solution - there are pros and cons to both ways of doing TTL, and in fact it was as a result of debate about this issue with regard to LLMNR that Rendezvous switched to this scheme originally.
>
>I've weighed in on this several times in the past - the only reason I've stopped saying anything about it is because I've given up hope in the process - it's seemed recently that there was no interest at all in making LLMNR and Rendezvous interoperate.   It sounds like this is not actually the case, and that a lot of other folks have been silent as well, perhaps for the same reason.   :'/

At 11:04 PM 1/26/2004, Stuart Cheshire wrote:
>...
>...

---

From: Ted Lemon <[email-masked]>
Date: Wed, 28 Jan 2004 09:27:24 -0600

On Jan 28, 2004, at 5:33 AM, John Schnizlein wrote:
> announced ROUGH consensus) change in the Zero-Conf WG.

John, this isn't an 11th-hour attempt.   We've been arguing about this 
for several years now, without reaching consensus.   If you had the 
impression that there was consensus, it's only because the people who 
do not participate in the "consensus" have been quiet for a while 
because we have little hope that saying anything will be productive.

> There also,

Yes, you and several other people have repeatedly made this assertion.

So because of this, we will have two non-interoperating protocols that 
do the same thing.   That's a real world problem that can be 
demonstrated on networks today.   How do I know?   Because it's already 
caused trouble for me personally and for people for whom I provide 
network support - people who are not John Schnizlein or Ted Lemon and 
cannot debug these problems without our help.   This interoperability 
problem is a direct result of what appears to be a completely 
theoretical argument.

> as if independent of a single vendor's implementation until near

Rendezvous happened, as far as I can tell, because the Zeroconf working 
group failed.   By which I mean that although there was strong 
agreement among proponents of zeroconf about what to do, there was 
strong resistance to the idea of the IETF pushing any kind of zeroconf, 
and this prevented the working group from succeeding.   We have some 
drafts in/near last call now, but it's a Pyrrhic victory - I'd rather 
implement Rendezvous than zeroconf.