Subject: Re: Where did this TTL=255 idea come from?

From: Stuart Cheshire <[email-masked]>
Date: Fri, 29 Nov 2002 11:28:39 -0800

>I find it entirely inappropriate that you have been attempting to force
>the WG to conform to a specification that has serious technical flaws,
>and dismmissing significant technical objections out-of-hand, in order
>to protect your employer from the risk that it exposed itself to by
>shipping code that implemented a preliminary version of the spec.
>I think that's a serious conflict of interest for a WG chair.

Keith, I wish you would try to remember from one day to the next which 
side of the argument you are on. Right now it seems that every comment 
you send is simply disagreeing with whatever the previous person said, as 
if you just want to keep fueling the fire and keep this four-year debate 
going on into its fifth, sixth and seventh years.

Please remember that the current topic of discussion was initiated by 
Thomas Narten saying:

>The IETF traditionally takes a dim view of having specs encourage behavior 
>that is non-backwards compatable, unless there is compelling benefit.

The question before us is whether the working group wants to modify its 
specification to accomodate *Microsoft*, not Apple.

Apple has always been willing to update its software to comply with 
Working Group consensus, and has done so in the past, and as far as I 
know will continue to do so in the future.

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

---

From: Keith Moore <[email-masked]>
Date: Fri, 29 Nov 2002 15:05:01 -0500

> side of the argument you are on. 

I'm trying to understand and argue for what seems best for the Internet 
as a whole.   Which side are *you* on?

> >that is non-backwards compatable, unless there is compelling benefit.

Yes, but that has to be understood with a context.  The IETF also has 
a long tradition of trying to produce a desirable end-state even 
when it means compromising backward compatibility.  And the IETF 
traditionally places more value on backward compatibility with standards
than on backward compatibility with pre-standardization practice.
 
> specification to accomodate *Microsoft*, not Apple.

No, that's your interpretation of the question.  There are proposals
on the table which would accomodate neither, but are arguably technically
superior.  Are you attempting to avoid the question of whether Apple 
should be compelled to change its code also?

> know will continue to do so in the future.

Actually I hope that Apple would update its software to follow the 
standards as published, rather than merely the consensus of the 
working group.  They are not necessarily the same thing. 

Keith

---

From: Thomas Narten <[email-masked]>
Date: Fri, 29 Nov 2002 16:20:34 -0500

Stuart,

> specification to accomodate *Microsoft*, not Apple.

Casting this discussion as an Apple vs. Microsoft discussion is most
unhelpful, and is exactly the type of thing that will get this group
nowhere. Especially, since your note implies that Apple is doing right
and Microsoft is doing wrong. Please think *very* hard about how your
words might be interpreted by others.

All, can we please stop this sort of name calling and focus on the
technical issues?

> know will continue to do so in the future.

Good. Then lets figure out what the best thing to do is and update the
spec (if needed). Vendors can figure out themselves what they will do
with their implementations.

I'm personally extremely frustrated by this thread because there is a
lot of heat and not much light. There are technical issues to consider
that the WG should evaluate and weight. But a lot of postings so far
seem to focus on one issue (while ignoring others) and then conclude
that the "obvious" outcome is X. There are at least three issues to
consider here, and they need to be considered *together* as they all
must be weighed relative to each other.

The way I understand the issues:

Enforcing the 255-on-receipt check is non-backwards
compatable. Indeed, it occurred to me today that its non-backwards
compatable with nodes that don't even implement LL
addressing. Consider a node A, on the same link with B. A has a global
address, B has a LL address. If A attempts to communicate with B, but
B notices that the dest address is LL, and then checks for a TTL of
255 (following the recommendation in the current ID), communication
will likely fail. So here we have a case where two nodes with valid
addresses can't communicate for non-obvious reasons. Neither
implementation is violating a Standard. Note the A has not implemented
LL at all, so it can't be violating any LL standard.

Is this not a potential interoperability problem that we shouldn't
knowingly encourage?

However, now that Apple does this check, setting the TTL to anything
other than 255 is also problematic.

That might argue for setting it to 255 (and explaining in the document
why), but also saying SHOULD NOT or MUST NOT do the check on receipt
since we know it also causes problems with existing implementations
that don't set the TTL this way.  (Note we could say that the test
might be changed in a future standard once the deployed base is
upgraded/junked, but it is too early to say that today if one wants to
avoid interoperability problems today).

But setting the TTL to 255 (rather than 1) also will lead to more LL
packets going off link then if the TTL is set to 1. Sure, hosts aren't
*supposed* to forward them to routers, but some leakage will
inevitably happen as a result of misconfigurations, and other things
that are "not supposed to happen". This may cause operational
problems. How much? Hard to say. Depends on how many (and which)
routers do filtering.  I don't believe we need 100% compliance here in
order to get enough filtering in practice to keep LL traffic from
leaking in horrible ways. For a home site, for example, does it care
if its LL traffic goes off link? Probably not. What it cares about is
that it doesn't go across the DSL link to its ISP (or that packets
from the ISP come in with LL addresses). But that is something the ISP
probably cares about enough to ensure that filters are fairly likely
to get put at that boundary. Etc.

So, could we please have a discussion of the overall pros and cons of
these (or any other relevant) issues, so that the WG understands the
list of issues that need to be weighed and balanced?

Note: I'm personally not that concerned *which* approach the WG
adopts. However, I really want (and need) to be able to defend the
WG's decision when people tell me that the spec is broken because it
codifies known interoperability problems into a standard.

Thomas

---

From: "John C. Welch" <[email-masked]>
Date: Fri, 29 Nov 2002 16:53:21 -0500

> working group.  They are not necessarily the same thing.

If they were to do that, then there would be no way to test anything, since
there is no standard, and we'd all be sitting on our hands for another
decade or so dreaming of easily configured IP settings.

john

-- 
John C. Welch
Consultant III
Administrative Computing
(617) 253 - 1368 work
(508) 579 - 7380 cell
bynkii2          AIM