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

From: Erik Guttman <[email-masked]>
Date: Wed, 05 Mar 2003 10:47:41 +0100

[WG chair hat off]
I accept LL29 with Christian's modifications:

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])

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

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

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

Erik

---

From: Robert Elz <[email-masked]>
Date: Wed, 05 Mar 2003 18:03:34 +0700

Date:        Wed, 05 Mar 2003 10:47:41 +0100
    From:        Erik Guttman <[email-masked]>
    Message-ID:  <[email-masked]>

  |      Hypocrates said "Do no harm."  (This is a reason to reject [LL3])

I don't think we're doing medicine here, but I agree with the reasoning
that came before "Hypocrates said".

  |    - The suggestion in LL3 that 'eventually' filtering on the basis

And this.

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

[etc].   That's true, but your scenario for how it would affect
anything doesn't make much sense.   This can happen, but from
conforming hosts, it isn't going to happen often.   As Stuart said
in a message several days ago, if this was a real problem, we'd
have noticed it already - hosts doing LL with a TTL > 1 (much > 1)
have been around for years, and yet we're not being deluged by
complaints about escaping packets (the complaints about hosts getting
LL addresses at all, which the WG has been willing to write off as
irrelevant (see LL2), dawrf the complaints about escaped LL packets).

But in any case ...
  |      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]).

The "This is a reason" doesn't follow in this case.   You have demonstrated
a scenario that can happen, rarely, but not demonstrated any reason why
we should care if it does.

  |    - 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 might happen, but will also be very rare.   Remember that multicast
is forwarded using reverse path forwarding.   There has to be a route to
the source address of the packet for the multicast to be forwarded.
Unless the router is doing LL addressing (either knowing about the magic
of LL, or explicitly configured to have LL addresses on a link) then it
cannot have a route to the LL prefix - we have already agreed (or certainly
will) that the LL prefix must not be included in routing protocols.

If the router is LL aware, then it won't forward the packet anyway.  If it
isn't, but has been configured with an LL address range for some reason,
it might - but if it was configured that way, without also having filtering
configured to block LL packets, then we have a badly configured router
that should be fixed.   To actually do any real harm, we'd need lots of
similarly badly configured routers, all connected to each other, with a
particularly bizarre set of routes installed.   This is not likely enough
to bother considering.   Hence...

  |     (This is a very good reason to reject LL3 and LL21.)

No, it isn't.

To reject LL21 you'd really have to show some particular advantage to be
gained by all LL traffic by setting a particular TTL value.

The only two attempts to do that fail to achieve any detectable benefits.

We have both camps here, the TTL=1 and the TTL=255 camps, each demolishing
the other's claimed benefits, but neither is willing to accept that their
own case is similarly being demolished by the others.   Neither is
making any real positive arguments that hold up in favour of their proposed
solution.

kre