Subject: RE: TTL=255 on xmit, no check on receipt please

From: Stuart Cheshire <[email-masked]>
Date: Fri, 27 Dec 2002 15:40:01 -0800

>I don't think so. I really believe that all this is a trade off.
>If what you want is a properly architected link local "zeroconf"
>service, then you should use IPv6. If you insist on IPv4, it must
>be for compatibility with existing implementations etc.

Christian, the reason that IPv4 link-local is useful is because it is 
relatively easy to add to an existing IPv4 stack, whereas adding IPv6 is 
more work. Do you disagree with this? Microsoft shipped IPv4 link-local 
in Windows 98 four years ago, and not IPv6. There must have been a reason 
for that.

>If you consider interoperability, the TTL 255 requirement for IPv4
>addresses is not very productive. There is a wide body of deployed
>implementations that use the auto-configured IPv4 address and set
>the initial TTL to a value other than 255, which means that
>implementations will not in practice require a check to the value
>255 for a very long time. So you will be left with a "set 255,
>don't check" implementation, which means that you won't get any
>protection, and also means that if your packet is somehow
>swallowed by a mis-configured router, it will travel all the way
>to the Internet core.

I quote from Dave Thaler <[email-masked]>, in the
arguments he gave which convinced the working group to adopt TTL=255:

>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.

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

---

From: Robert Elz <[email-masked]>
Date: Sun, 29 Dec 2002 01:06:25 +1100

Date:        Fri, 27 Dec 2002 15:40:01 -0800
    From:        Stuart Cheshire <[email-masked]>
    Message-ID:  <[email-masked]>

  | I quote from Dave Thaler <[email-masked]>, in the
  | arguments he gave which convinced the working group to adopt TTL=255:
  | 
  | >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.

Upon reflection though it has been shown that neither of those is
correct or relevant.

A node for which the spec would apply (one which is implementing LL
addresses) is never going to send one to a router, so you're never
going to discover holes in router configurations this way (note this
is completely different from the case where the argument was first put
relating to multicast).   Similarly, you'll never detect offenders this
way.

The only packets with LL addresses in them that will get sent to routers
are packets from implementations that have never heard of LL addresses,
and believe these things are just regular IP addresses.   Obviously, the
LL spec isn't going to influence them, one way or the other, so what it
says the TTL should be set to is irrelevant there.

The only point of the TTL=255 stuff here, is so you could check it and
reject packets that have come from outside (the way that v6 ND does).
But as has also been shown here before, that's completely meaningless
here, there's simply no point doing that.

TTL==1 has the (very minor) benefit that Christian mentioned, where
no attempt will be made in a badly misconfigured net to send packets into
the internet, but the chances of this actually happening (so many things
have to be broken at once for it to ever matter) are so small that this
isn't worth it either.

All mention of special TTL values should simply be stricken from the
docs, they gain absolutely nothing.   Allow implementations to set
whatever they believe is sane (which may often be 1, with a config knob
to allow other values so a net can communicate with implementations that
assume 255 & actually check it - but this is an implementation matter).

kre