Subject: Re: [LL29] Link-local sources should specify TTL=1

From: Stuart Cheshire <[email-masked]>
Date: Wed, 12 Mar 2003 23:19:21 -0800

Erik Guttman wrote:

>TTL SHOULD be 1.  If an application explicitely sets the TTL to
>some other value, this should be used.  (No mention of processing
>on the basis of the TTL of received packets is made.)
>
>The reasons for my preference of this alternative are (focussing
>on new arguments, not yet presented on the list):
>
>   - Applications have the ability to set this value and interpret
>     it for received packets.  Since this is available today using
>     standard interfaces, requiring the TTL to be set to 255 would
>     potentially *break* existing applications.  Hypocrates said
>     "Do no harm."  (This is a reason to reject [LL3])

I think "potentially" is a weak argument here.

Mac OS 9 and X have both set the TTL to 255 for years, and I've never 
heard of any application having a problem.

>   - The suggestion in LL3 that 'eventually' filtering on the basis
>     of received packets having a TTL=255 cannot be carried out today
>     because of the prevelance of hosts which do not do this.  Those
>     hosts which do this filtering are problematic for this reason.
>     There is no provision for when 'eventually' will occur.  Thus,
>     the provision complicates the protocol specification but adds
>     no immediate value.  (These are reasons to reject [LL3]).

I wholeheartedly agree that if the document specifies what the TTL should 
be, but no one is checking the TTL, then there's a risk that 
implementations will get it wrong, which diminishes the value of 
specifying what it should be in the first place.

It is for exactly this reason that the Rendezvous Conformance Test, which 
vendors have to pass to license the Apple Rendezvous logo for their 
products, checks that the device both sets the IP TTL to 255, and also 
checks whether the device ignores packets sent with a TTL other than 255. 
A partial list of vendors with Rendezvous products can be seen at
<http://www.apple.com/macosx/jaguar/rendezvous.html>.

>   - There are scenarios in which a host can have a routable address
>     and receive packets from an on-link host with a link-local address.
>     This host can then forward the location (in a reference, referral,
>     URI, etc) off-link.  It is then possible for the off-link host to
>     use this link-local address as a destination address.  If the TTL
>     for this is set to 255, the packet will be forwarded along the
>     default path (probably), unless routers have been explicitely
>     configured to not forward packets in the 169.254/16 prefix.  Since
>     many such routers exist and will continue to exist, this means that
>     LL traffic with a TTL != 1 will escape off-link.  (This is a reason
>     to reject [LL3] and [LL21]).

This argument does not hold water.

Does this hypothetical "off-link host" implement IPv4LL or not?

If yes, then it will never send an LL packet to a router for forwarding.

If no, then changing this spec to require TTL=1 is pointless because the 
"off-link host" doesn't implement this spec.

I'm sorry to have to say this, but the arguments supporting TTL=1 are 
notable for their quantity rather than their quality. Many people have 
spoken in support of TTL=1, but none of the arguments given hold up under 
scrutiny. I fear that we risk declaring consensus here based on the 
volume of arguments offered, despite the fact that when prodded with a 
little scrutiny, those arguments are discovered to have the durability of 
soap bubbles.

>   - A packet sent with a TTL=255, link-local source address to a
>     non-link-local multicast address will be forwarded by a router
>     which supports multicast routing and does not know to decline to
>     forward packets with a 169.254/16 source address prefix.  This
>     will result in (given the nature of dense-mode multicast routing
>     protocols) a flood of link-local source addressed packets to *all
>     links* in the network, at least for the first such packet trans-
>     mitted.  (This is a very good reason to reject LL3 and LL21.)

Given that Mac OS and Windows have been sending packets with TTL >> 1 for 
five years, how many documented instances of this problem have been 
reported?

For this problem to happen, you need a network with multicast routing 
enabled. Sad to say, but such networks are rare, even today. In addition, 
you need the DHCP server on that network to fail. You need some 
application that's sending to a non-link-local multicast destination. 
Finally, you need IP routers that don't know they're not supposed to 
forward LL packets. When this confluence of events occurs together, what 
happens? Does the sky fall? No, all that happens is that, until the DHCP 
server is fixed, some packets go out with source addresses such that the 
receivers can't reply to them. Does this destroy any hardware? Does this 
melt down the network? Does this impede the ability of users to use the 
network? No. Those are packets that would have gone out anyway -- albeit 
with a different source address -- so that traffic would have existed on 
the network anyway.

If we'd published this spec five years ago, then by now there would be a 
chance that multicast-capable routers would know not to forward packets 
with LL source addresses. I submit that the sooner we publish a spec, the 
sooner router vendors will start shipping products that don't forward LL 
packets.

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

---

From: Robert Elz <[email-masked]>
Date: Thu, 13 Mar 2003 21:18:07 +0700

Date:        Wed, 12 Mar 2003 23:19:21 -0800
    From:        Stuart Cheshire <[email-masked]>
    Message-ID:  <[email-masked]>

  | I'm sorry to have to say this, but the arguments supporting TTL=1 are 
  | notable for their quantity rather than their quality. Many people have 
  | spoken in support of TTL=1, but none of the arguments given hold up under 
  | scrutiny.

I agree with that.

But the arguments for TTL=255 are just as lame.

The problem is that neither side is willing to admit that their
arguments really have no merit, each believes they do, regardless
of how many counter-arguments the other side make.

At various stages in the early parts of this discussion (for me anyway,
last year) I was swayed towards the TTL=255 case (seemed to be reasonable
enough) and then to the TTL=1 case (sounded convincing).   Upon scrutiny,
neither made much sense.

That's why I proposed LL21 - that we just drop mention of TTLs.

If some application that uses LL addresses (rendezvous can be one for
example) wants to specify that the TTL must be N, then let it do so.
What's more, that specification would work whether LL addresses are being
used by the protocol, or whether some other addresses are.  If the
protocol finds it useful to know for sure that packets originated on the
local link (and so wants to test TTL==255) then surely that should work
regardless of what addresses happen to be being used.

On the other hand, if a protocol wants to ensure that its packets remain
on the local link, then it can specify TTL=1 as a requirement, which, once
again, works regardless of the addresses (LL or others).

Specifying a particular TTL for all uses of one particular address type
would prevent at least one of the above from working.   There's no meaningful
benefit to be obtained by a general specification, so let's just drop it.

Support LL21

kre

---

From: Ralph Droms <[email-masked]>
Date: Thu, 13 Mar 2003 09:26:30 -0500

Given a lack of convincing arguments about the advantage of using the
TTL field for specific advantage in IPv4LL, I strongly believe we
should retain its current definition as a TTL value.

Still calling it "TTL" while using it as "source not on link" doesn't
change the fact the IPv4LL would be making a fundamental change to
the definition of the IP header for use when an IPv4LL address header
happens to contain an IPv4LL address.

- Ralph

---

From: "John C. Welch" <[email-masked]>
Date: Thu, 13 Mar 2003 09:57:19 -0500

> benefit to be obtained by a general specification, so let's just drop it.

And you now have to test the TTL usage for *every single vendor* to use
products from different vendors to make sure that the TTL handling is
compatible. Which of course means that a v4LL 'standard' is now as much of
an oxymoron as jumbo shrimp.

Now, if you're a major network vendor, the ability to comply with a standard
and lock your customers into your? stuff and out of anyone else's stuff is
brilliant. Someone else compatible? Not for long, just 'adjust' your TTL
handling until their stuff doesn't work with yours, then tell your customers
that they have to remove their stuff, buy more of your stuff and life will
be perfect again.

I thought we had left the IBM of the 60s and 70s behind long ago.

john

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