Subject: Re: Link-local TTL

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

RJ Atkinson wrote:
>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 is backwards.

Checking for TTL=1 would be fully INCOMPATIBLE with every current 
deployed system.

Mac OS 9 and X sets TTL=255.

Windows by default sets TTL=128 (but this can be changed).

If there's any argument based on compatibility with deployed systems, it 
has be be a choice between checking TTL=128 (for compatibility with 
existing Windows machines where the default hasn't been changed) or 
TTL=255 (for compatibility with existing Macs).

I don't think we should make decisions based on compatibility with 
deployed systems, but if we do, checking for TTL=128 or checking for 
TTL=255 are the two available choices.

>	- This prevents a link-local from being forwarded off-link,
>		even if the router is misconfigured or unaware of link-local 
>addressing.

This is not necessary -- compliant hosts never send packets to a router 
for forwarding anyway. (Having the document try to prescribe the 
TTL-setting behaviour of non-compliant hosts is self-contradictory 
nonsense.)

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