Subject: Set the IPv4 TTL to 1?

From: Stuart Cheshire <[email-masked]>
Date: Wed, 9 Feb 2005 10:41:09 -0800

>Put the text back.   Deleting this was a decision the working
>group could have made when the document was under discussion, but
>there is no longer a working group to approve any change like this
>(and I kind of doubt it would have been approved anyway).

The working group did consider whether "Link-local sources should specify 
TTL=1", and the proposal was rejected 
<http://www.drizzle.com/~aboba/ZEROCONF/ll29.html>. I'm not sure how it 
found its way into the document.

If this is the only area of disagreement, then I'll compromise so we can 
move forward and publish the RFC, but reluctantly, because it's terrible 
terrible advice to have in the document. For the record, I should state 
why I think this:

* I already see far too many consumer devices that don't work beyond the 
local link, by design or by accident, and this advice risks encouraging 
more such devices.

* Is this "advice" actually part of the formal specification or not?
It doesn't say, "MUST", "SHOULD" or "MAY". Is an implementer required or 
expected to follow it, or not?

* One of the goals of IPv4LL was that it should be as much like normal IP 
as possible, so as to minimize any additional burden on application 
writers. This "advice" looks like it places an additional burden on 
application writers.

* You say that application code should only set the TTL when "sending 
from an IPv4 Link-Local address"? If you've ever tried it, you'll know 
that on a multi-homed host, determining in advance what address you're 
going to be sending from is very difficult from user-level code. Most 
application code that opens connections or sends UDP packets simply 
specifies the DNS name or destination address, and lets the kernel pick 
the interface and source address. Most application code that accepts 
connections simply binds to INADDR_ANY and lets the kernel handle the job 
of making sure the right source address is used when sending back the TCP 
ACKs.

* This "advice" creates gratuitous incompatibility with existing deployed 
devices that followed the instructions in earlier drafts to check that 
the TTL on received packets is 255.

With all that said, if this is the only point of disagreement, then I 
will accept it and we should publish the RFC.

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

---

From: Robert Elz <[email-masked]>
Date: Thu, 10 Feb 2005 04:30:40 +0700

Date:        Wed, 9 Feb 2005 10:41:09 -0800
    From:        Stuart Cheshire <[email-masked]>
    Message-ID:  <[email-masked]>

  | The working group did consider whether "Link-local sources should specify 
  | TTL=1", and the proposal was rejected 
  | <http://www.drizzle.com/~aboba/ZEROCONF/ll29.html>. I'm not sure how it 
  | found its way into the document.

Yes, there was a big argument about this, which, if for no other reason
is justification for not changing anything this late in this area of the
doc.

  | * Is this "advice" actually part of the formal specification or not?
  | It doesn't say, "MUST", "SHOULD" or "MAY". Is an implementer required or 
  | expected to follow it, or not?

No, it is just a suggestion (or that's how I read it).

  | * You say that application code should only set the TTL when "sending 
  | from an IPv4 Link-Local address"? If you've ever tried it, you'll know 
  | that on a multi-homed host, determining in advance what address you're 
  | going to be sending from is very difficult from user-level code.

Determining what will be picked for you is difficult.   Determining
what should be used is trivial.   If the application wants to send
from an LL address, and an LL address is available, forcing its use
is simple - as would be setting a TTL of 1 in that case.

That said, I doubt many applications will bother, I certainly don't
expect server applications to bother - but if an application writer
feels the need to consider which TTL should be set, when LL addresses are
in use, setting 1 is a reasonable choice (compat with followers of old
versions of the spec notwithstanding).   [Aside: do you really expect
application writers to ever even look in this spec?]

  | With all that said, if this is the only point of disagreement, then I 
  | will accept it and we should publish the RFC.

I think that is probably best.

kre

ps If/when this ever advances to DS, if implementations aren't documented
to be following this advice, then the proper procedure is to remove it.