Subject: Link-local TTL

From: RJ Atkinson <[email-masked]>
Date: Wed, 27 Nov 2002 07:32:40 -0500

1) This TTL check thing is an operational consideration, NOT a security 
consideration.
2) The best technical approach is probably actually this one, which I 
typo'd
	earlier this week, but maybe got right this morning:

	A)	Receivers MUST drop incoming link-local packets where (TTL != 1).
	B)	Senders MUST set (TTL = 1) on all outbound link-local packets.

Rationale:
	- This is fully backwards-compatible with the deployed systems.
	- This prevents a link-local from being forwarded off-link,
		even if the router is misconfigured or unaware of link-local 
addressing.
	- This prevents a receiver from accepting (most) bogus link-local 
packets.

Ran
[email-masked]

---

From: Joshua Graessley <[email-masked]>
Date: Wed, 27 Nov 2002 11:32:24 -0800

On Wednesday, November 27, 2002, at 04:32 AM, RJ Atkinson wrote:

>
> 1) This TTL check thing is an operational consideration, NOT a 
> security consideration.

Actually, this will break compatibility with current shipping Macs. 
Macs implement the check for TTL = 255 upon reception of packets with 
an IPv4 link-local address and will silently discard any packets where 
the TTL is not 255.

> 	- This prevents a receiver from accepting (most) bogus link-local 

This does nothing to prevent the receiver from accepting bogus 
link-local packets. The receiver is relying on routers not forwarding 
packets.

-josh

---

From: Keith Moore <[email-masked]>
Date: Wed, 27 Nov 2002 15:18:25 -0500

> an IPv4 link-local address and will silently discard any packets where

that's what you get for shipping product before the standard was approved.

---

From: "John C. Welch" <[email-masked]>
Date: Wed, 27 Nov 2002 16:06:52 -0500

> that's what you get for shipping product before the standard was approved.

Well, if you wait for the standards to get around to getting their act
together and make a bloody decision, then you don't change anything, nothing
new gets done, and computing progress stands still.

Maybe if the standards bodies spent less time arguing minor points, and more
time getting work done, then this wouldn't be an issue. In the commercial
world, (read, the people who spend most of the money on new technology),
there is nothing more agonizing that making the decision to delay needed
technology purchases because you *hope* that a standard that is due out in a
given *year* will actually be out that year. People need to get work done,
and they'll happily ignore standards to get work done.

not to pick on any company here, but face it, any company delaying a
Zeroconf implementation for the standards bodies to get around to agreeing
on something is foolish.

john

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

---

From: Joshua Graessley <[email-masked]>
Date: Wed, 27 Nov 2002 13:14:47 -0800

> that's what you get for shipping product before the standard was 

My point is that compatibility with currently deployed devices should 
not be used as a reason to change the spec to require that the TTL be 
set to 255.

I thought we already went through this debate some time ago and decided 
that TTL 255 was the most desirable solution. Is there a reason we're 
rehashing this yet again? The original question that started this 
thread was one about whether the TTL 255 check would break currently 
deployed products. We've been shipping Macs for a while now with the 
check in and we haven't had any reports of problems with 
interoperability with other link-local devices.

-josh

---

From: Keith Moore <[email-masked]>
Date: Wed, 27 Nov 2002 16:40:46 -0500

> not be used as a reason to change the spec to require that the TTL be

similarly it should not be used as a reason to not change the spec to 
require that TTL be set to 1.
 
> rehashing this yet again? 

yes, IESG review.  this is a normal part of the process.

Keith