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

From: Stuart Cheshire <[email-masked]>
Date: Wed, 27 Nov 2002 16:20:28 -0800

Several people have privately accused Apple (or me personally) of trying 
to force "Apple's way" of doing things on Microsoft (and the rest of the 
world). Several people have asserted that instead of being willing to 
update Apple's software, Apple is trying to force the group concensus to 
comply with the software that Apple has already shipped.

Just for the record, let me set things straight. We're in the current 
mess because Apple's DID update its software to comply with the Zeroconf 
group concensus.

I originally advocated TTL=1.

On 4th April 2001, Dave Thaler <[email-masked]> send the email 
below, arguing why the TTL should be 255. I read his arguments and was 
swayed by them. As a result, the draft was updated to include the current 
text about setting and checking TTL, and Apple immediately shipped a 
software update to set the TTL correctly.

Now, a year and a half later, we're having these discussions about 
interoperability because Apple did acceed to a suggestion received from a 
Microsoft employee, and Apple did update its software to comply, and 
Microsoft didn't.

I still agree with the arguments made by Van Jacobson and Dave Thaler,
and I still think the correct technical decision is to set and check
TTL=255.

>Subject:     RE: IPv4 linklocal security
>Date:        4 Apr 2001 7:18 pm
>From:        Dave Thaler, [email-masked]
>To:          Stuart Cheshire, [email-masked]
>CC:          [email-masked]
>
>However, the discussion of TTL=1 vs TTL=255 basically repeats a
>discussion that occurred in the MBoneD WG at IETF 38 (Memphis).
>The meeting notes don't say much, but are at
>http://www.ietf.org/proceedings/97apr/97apr-final/xrtftr65.htm
>
>The essence of the discussion is that Ross Finlayson gave a presentation
>in which he asked what the best TTL was, for each multicast scope.  He
>suggested publishing a list of recommended TTLs for each scope.
>Van Jacobson and I both argued that TTL=255 should always be used, so
>the meeting minutes skip to the conclusion which was "The final 
>recommendation was to abolish the use of TTL as a boundary mechanism",
>and as a result no list of TTLs per scope were published (and any
>old lists on web pages were removed).
>
>One of the arguments that Van and I made was that using TTL=255
>provides two things: 
>1) an incentive for ISPs to do the right thing
>by configuring routers to fix "holes" in scopes (in the zeroconf
>context this translates to not forwarding 169.254/16), or even
>better, an incentive for router vendors to do this automatically, and
>2) (less importantly) a way to easily detect offenders.
>
>In contrast TTL=1 provides no incentive for ISPs/router vendors to 
>do the right thing.
>
>Whether this argument is strong enough to use TTL=255 in the
>Zeroconf scenarios is up to this WG to decide, but it was
>good enough for the MBoneD WG in 1997.
>
>The two rules at the top of this email are orthogonal to the 
>TTL decision.  Even with the two rules on address checking,
>I'd still prefer TTL=255.
>
>-Dave

---

From: Keith Moore <[email-masked]>
Date: Wed, 27 Nov 2002 20:43:49 -0500

> mess because Apple's DID update its software to comply with the Zeroconf

The WG consensus is only one step, and only one requirement.
Technical soundness is also a requirement, independent of WG
consensus.  Also, WG consensus is not sufficient to determine
technical soundness.  Community-wide review also plays a part.  
So does IESG review.  All of this is documented in RFC 2026.

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

---

From: "John C. Welch" <[email-masked]>
Date: Wed, 27 Nov 2002 20:58:46 -0500

> I think that's a serious conflict of interest for a WG chair.

By that standard, every WG chair using any computer system at all is
conflicted. We all have preferences, and will attempt, even unconsciously,
to make sure, "our side" comes out ahead. To avoid any possible conflict,
the WG chair would have to not be a computer user at any level.

This of course, would be ridiculous. At least if Stuart's biased, we know
where, how, and why. This insistence that the commercial industry be ignored
or even chastised for having anything to do with standards is unrealistic,
and antithetical to getting the standards used.

It is psychologically impossible for a human being to be objective about
anything, so let's not apply an impossible standard to Stuart.

john

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

---

From: Thomas Narten <[email-masked]>
Date: Thu, 28 Nov 2002 14:45:49 -0500

> So does IESG review.  All of this is documented in RFC 2026.

yep.

> I think that's a serious conflict of interest for a WG chair.

Let's please keep the vendor bashing off this list. The work we need
to do is hard enough as it is. Let's also not make assumptions about
other people's motives. As we all know (and some of us know this more
than others), implementing from an ID is risky, as things for which
their may well have been concensus at one point in time later get
removed or outright reversed. In this case one vendor implemented
something in an ID assuming that it would end up in the final
spec. Other vendors may have chosen not to implement that feature yet,
for among other reasons, knowing that it is better to wait for the
final standard before doing the implementation, just to be sure. There
are pros and cons to both approaches, and I don't think you can say
one is right and the other wrong.

What this WG needs to decide is what it wants to do _NOW_ based on the
reality that exists _today_. That reality includes understanding what
current vendors are doing and what is deployed and trying to come up
with a recommendation that makes the best engineering trade off based
on a number of different considerations. What is currently deployed is
one such consideration.  But it is not the only one.

Thomas

---

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

> one such consideration.  But it is not the only one.

I guess I would still say that the end state is more important than
the transition state, so what exists _today_ isn't as important
as what will exist _tomorrow_.   But I freely admit that dealing with
transition issues is often crucial to success of a protocol. 

Keith