Subject: LLMNR and Rendezvous TTL disagreement, a modest proposal

From: David Brower <[email-masked]>
Date: Thu, 12 Feb 2004 13:10:16 -0800

[ Moderators note: Post by non-subscriber.  With the massive amount of
   spam, it is easy to miss and therefore delete relevant posts 
   by non-subsrcibers. Please fix your subscription addresses. ]

Not being religious, and only being a party that wishes to use things
in this space to reduce configuration, interoperability between LLMNL
and Rendezvous is important in reaching stability and critical mass.

The first contentious issue seems to be the TTL field.  There seem to
be perfectly good arguments for each position, and I am not wise
enough to say either is correct.  Is it plausible to say "both are
right" on this point?  Have the standard say senders may set the field
to either 1 or 255, and recipients should accept either value?   Both
seem just as good at detecting leaked packets.

You may stone me now.

thanks,

David Brower
Oracle Cluster Architecture

--
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: Sun, 15 Feb 2004 07:31:54 +0900

David Brower;

> right" on this point?

No.

					Masataka Ohta

---

From: Ted Lemon <[email-masked]>
Date: Sun, 15 Feb 2004 10:49:08 -0500

> seem just as good at detecting leaked packets.

The reason we can't just do this is that the standard that was agreed 
upon requires that if you get a packet with a TTL that's not 255, you 
have to drop it.   This is the standard Rendezvous adopted, because the 
WG consensus at the time was that this was the right thing to do.   
Subsequently the consensus of the WG changed, and the current consensus 
is incompatible with the old consensus.

At this point whenever this comes up, everybody clams up, with the 
exception of a swift rejoinder from the "can't change the meaning of 
TTL" crowd, and perhaps a quick (perhaps completely inaccurate!) 
explanation of the situation from me.

I do not think that there is consensus that we should change the 
meaning of TTL in LLMNR packets to be compatible with Rendezvous, but 
there also isn't consensus that we should not.   And so we all kind of 
act embarrassed when the question comes up, and I suspect that the end 
result will be a lack of interoperability, because the consensus seems 
to have been called already.   :'}

---

From: Paul Vixie <[email-masked]>
Date: Mon, 16 Feb 2004 17:03:51 +0000

> [...] The reason we can't just do this is that the standard that was
> agreed upon requires that if you get a packet with a TTL that's not
> 255, you have to drop it.  This is the standard Rendezvous adopted,
> because the WG consensus at the time was that this was the right thing
> to do.  Subsequently the consensus of the WG changed, and the current
> consensus is incompatible with the old consensus.  [...]

I think there are two topics on which consensus would be valuable and
useful but which for the moment are impossible to gauge.  Above, Ted
makes reference to the old "1 vs 255" thing.  Others here have shown
that one choice assures correct behaviour by initiators, the other by
responders, and that either choice is useful, perhaps equally so.  At
this point we could flip a coin to decide, and the consensus would
surely be, "wow we sure are glad that some kind of decision got made."

The second point on which consensus is unclear is actually much more
important, and that's "should we allow Apple to legislate standards
using the force of their installed base?"  Apparently there's some
concern that Apple is acting like a bully here.  I've also heard of
suspicions that Microsoft's big reason for pushing LLMNR is to wipe
out Apple's early lead in this market.  What we (as IETF "members")
have to decide isn't "who should win this fight?" but rather "what's
the best engineering solution?"  In other words no arguments based on
the existence of an installed base, whether for or against, should be
taken into account.  If the best solution happens to be what Apple did
then we should write it that way.  If the best solution happens to be
what Apple didn't do then we should write it THAT way.

But wait, I have a proposal.  Given the following three facts...

    (1) 1 and 255 have about equal usefulness but protect different endpoints
    (2) apple only chose as they did because of apparent consensus "back then"
    (3) consensus since then seems to have drifted back into vagueness

...that we give Apple's solution the nod based simply on operational
experience with a solution that has already been randomly chosen.

--------

But there's still the larger question of "why LLMNR?"  If the WG isn't
going to advance LLMNR while it remains incompatible with Rendezvous,
then why doesn't the WG just advance Rendezvous?  Clearly, being early
isn't always an advantage.  But does it always have to be a disadvantage?

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 17 Feb 2004 08:48:06 +0900

Paul;
 
>     (1) 1 and 255 have about equal usefulness but protect different endpoints

IETF concern is to pretect the network, to which both Apple
and Microsoft are indifferent.

						Masataka Ohta

---

From: Brad Hards <[email-masked]>
Date: Tue, 17 Feb 2004 20:09:02 +1100

On Tue, 17 Feb 2004 04:03 am, Paul Vixie wrote:
>     (1) 1 and 255 have about equal usefulness but protect different
> endpoints (2) apple only chose as they did because of apparent consensus
> "back then" (3) consensus since then seems to have drifted back into
> vagueness
>
I suggest that we make it "MUST (or SHOULD) send at 255, MAY bother to check" 
as the path to least gratuitous breakage.

Brd

---

From: Ted Lemon <[email-masked]>
Date: Mon, 16 Feb 2004 16:24:58 -0500

> experience with a solution that has already been randomly chosen.

This is what I would like to see happen.

> isn't always an advantage.  But does it always have to be a 

Well, remember that LLMNR addresses one part of what Rendezvous 
addresses - name resolution.   Also, as Bernard pointed out a couple of 
weeks ago, LLMNR and Rendezvous NR do have slightly different design 
goals (actually, he said more than slightly, but I think he was 
exaggerating :').

I think that it's worthwhile to compromise where we can, particularly 
in the 1v255 issue, and not try to standardize the whole Rendezvous 
suite as an IETF standard, because if we try to do this latter thing, I 
think we will just wind up back in the quagmire.

The root cause for Rendezvous not happening here is not that it was too 
early, but that there is strong resistance among certain participants 
in the IETF against some of what Rendezvous does.   I have tried to 
overcome this resistance, and my conclusion after having tried for some 
time is that it can't be overcome through any effort that I'm able to 
bring to bear.

---

From: Andras Salamon <[email-masked]>
Date: Thu, 19 Feb 2004 10:01:25 +0200

> as the path to least gratuitous breakage.

I support "MUST send with TTL=255, MAY reject if TTL<>255 on receipt",
possibly with a paragraph emphasizing that routers SHOULD discard such
packets if TTL<>255 (though this is perhaps broadening the ambit of the
document too far).

-- Andras Salamon                   [email-masked]