Subject: Re: LLMNR is done

From: [email-masked] (Jun-ichiro itojun Hagino)
Date: Tue, 27 Jan 2004 18:53:58 +0900 (JST)

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

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

itojun

--
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: 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.

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

> >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.
Again, not fundamental. Add proxying as a MAY, and explain to implementers the 
tradeoff.

> >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.
Pass for now.

> >d. Rendezvous and LLMNR uses different retransmission strategies and
> >timers.
>
> Surely these are trivial differences that could be easily agreed.
Without looking at the detail, I'd have to agree.

> >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.
I see .local as a useful scoping approach. Easy to explain to part-time 
sysadmins too.

> >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.
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.
 
> >g. LLMNR supports unicast queries; Rendezvous does not.
>
> Incorrect. Rendezvous supports unicast queries as well as multicast, and
> always has.
We probably should support both. 

> >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).
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: 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)

On Mon, 26 Jan 2004, Stuart Cheshire wrote:

> So, as I have said before, the only real show-stopping incompatibility I
> 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:
>...
>...