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

From: Aidan Williams <[email-masked]>
Date: Mon, 02 Dec 2002 12:58:23 +1100

Thomas Narten wrote:
 > The way I understand the issues:
 >
 > Enforcing the 255-on-receipt check is non-backwards
 > compatable. Indeed, it occurred to me today that its non-backwards
 > compatable with nodes that don't even implement LL
 > addressing. Consider a node A, on the same link with B. A has a global
 > address, B has a LL address. If A attempts to communicate with B, but
 > B notices that the dest address is LL, and then checks for a TTL of
 > 255 (following the recommendation in the current ID), communication
 > will likely fail. So here we have a case where two nodes with valid
 > addresses can't communicate for non-obvious reasons. Neither
 > implementation is violating a Standard. Note the A has not implemented
 > LL at all, so it can't be violating any LL standard.
 >

The same thing occurred to me today, however I applied it to the
"TTL=1 stops leakage" case.  Non-LL-aware nodes responding to LL
source addresses will set their TTL to whatever the OS default is.
If they further use their default route (as they are likely to do),
the packets get delivered to a router.
TTL=1 doesn't save us at this point.

Also, the responses going to a default router won't return to the
initiating LL node, so communication is likely to be broken regardless
of what the TTL is set to.

I think we have to assume that non-LL-aware nodes responding to LL
source addresses will use their default route and will set a TTL on
those packets other than 1 or 255.

 > Is this not a potential interoperability problem that we shouldn't
 > knowingly encourage?

Assuming that we want to support LL communication with nodes that are
not LL-aware.

At the moment I don't think it is worth the effort to interoperate
with non-LL-aware nodes.

(
  The text in Section 1.7 and 2.6 seems to imply that the nodes mixing
  LL and non-LL addresses are to some extent aware of the address
  differences and can make a decision about when to ARP directly for
  the destination (ie ARP for LL when I am non-LL-only, and ARP for
  non-LL when I am LL-only).

  Nodes behaving like this are to some extent LL-aware.
)

 > However, now that Apple does this check, setting the TTL to anything
 > other than 255 is also problematic.
 >
 > That might argue for setting it to 255 (and explaining in the document
 > why), but also saying SHOULD NOT or MUST NOT do the check on receipt
 > since we know it also causes problems with existing implementations
 > that don't set the TTL this way.  (Note we could say that the test
 > might be changed in a future standard once the deployed base is
 > upgraded/junked, but it is too early to say that today if one wants to
 > avoid interoperability problems today).
 >

Not checking TTL=255 on receipt is a statement that assurances about
non-forwarding are no longer important.  If that is the case, I'm fine
with setting TTL=255 and not checking as a way of minimising problems.

It would be nice to hear from Dave Thaler on this.  I believe he
proposed the TTL=255 change, and he might have some comments regarding
the importance of interoperability with Windows systems that don't
currently behave this way.

 > But setting the TTL to 255 (rather than 1) also will lead to more LL
 > packets going off link then if the TTL is set to 1. Sure, hosts aren't
 > *supposed* to forward them to routers, but some leakage will
 > inevitably happen as a result of misconfigurations, and other things
 > that are "not supposed to happen". This may cause operational
 > problems. How much? Hard to say. Depends on how many (and which)
 > routers do filtering.  I don't believe we need 100% compliance here in
 > order to get enough filtering in practice to keep LL traffic from
 > leaking in horrible ways. For a home site, for example, does it care
 > if its LL traffic goes off link? Probably not. What it cares about is
 > that it doesn't go across the DSL link to its ISP (or that packets
 > from the ISP come in with LL addresses). But that is something the ISP
 > probably cares about enough to ensure that filters are fairly likely
 > to get put at that boundary. Etc.
 >

I argued above that TTL=1 makes no difference for non-LL-aware nodes.
They'll do whatever they do today and packets will leak with TTL=64
(or whatever) and follow the default route up to an ISP filter.

LL-aware nodes sending LL requests (or LL responses) to a default
router (ie leaking) will fail to communicate since the router will
either forward along the default route, or will drop the packets.
Implementation bugs causing leakage are therefore very likely to cause
outright communication failure.  Hence I believe we're unlikely to see
leakage from LL-aware nodes (it causes communication failure).

So, I don't find the TTL=1 leakage argument compelling.  Setting the
TTL=1 has a certain aesthetic appeal because it fits with my
conception of link-local.

We should certainly not *prevent* applications using LL communication
and wanting assurances about packet forwarding from setting TTL=255
and checking.

regards
	aidan
____
:wq!