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

From: Erik Guttman <[email-masked]>
Date: Fri, 11 Apr 2003 14:54:09 +0200 (CEST)

LL29:   Link-local sources should specify TTL=1

Decision: Accept
Action:   Change the first two paragraphs of section 2.7 to read

     Any host sending an IPv4 packet with a source and/or destination
     address in the 169.254/16 prefix SHOULD set the TTL in the IP
     header to 1 by default. This includes multicast and broadcast
     packets with a source address in the 169.254/16 prefix.  An
     application may set the TTL to any value, using established
     interfaces for this purpose, overriding the default.

     This suggested behavior enables the normal behavior of Internet
     routers to preclude leaking traffic that is supposed to be 
     confined to a single link out into the Internet when the local 
     link has an attachment to the Internet that it did not discover. 
     Setting TTL to 1 precludes mistaken forwarding of link-local 
     traffic even when proxy-ARP is used on a link.

Notes:    This proposal is consistent with current practice and
          interpretation of TTL. (Ralph Droms)

          This proposal prevents leakage of datagrams from the local
          link in several plausible scenarios.

          This proposal explicitely allows setting of TTL for apps.

          This proposal was supported by most of the WG participants.
         
Erik Guttman
Zeroconf WG chair

---

From: Joshua Graessley <[email-masked]>
Date: Fri, 11 Apr 2003 11:01:42 -0700

The last paragraph of section A.2 regarding Mac OS X 10.2's should be 
changed.

Mac OS X 10.2 sets the TTL on all outgoing packets with a source or 
destination IPv4LL address to 255. Mac OS X 10.2 discards all incoming 
packets with a source or destination IPv4LL address if the TTL is not 
255, making any implementation of this standard incompatible with Mac 
OS X 10.2.

-josh

---

From: Joshua Graessley <[email-masked]>
Date: Fri, 11 Apr 2003 12:06:41 -0700

I apologize for not responding earlier. I had given up on this working 
group for a while.

I recognize that the issue is closed, but I believe there is a 
technical reason that this issue should be reopened. The new proposal 
breaks existing implementations. While this isn't necessarily a 
problem, it's a bit ironic since one of the reasons the document was 
changed was the fear of breaking compatibility.

A while ago, the draft was set TTL 255, check TTL 255. It was noted 
that the TTL 255 check would cause compatibility problems so it was 
dropped from the draft.

It was later noted that since the TTL 255 check can not be performed 
for the foreseeable future, setting the TTL to 255 was silly, so the 
draft was changed to say the TTL should be set to 1.

Set TTL 255 and not check doesn't break anything.
Set TTL 255 and check breaks some implementations, though we've never 
received a report of problems.
Set TTL 1 breaks some implementations.

If you're really serious about not breaking any implementations, it 
seems the right thing to do is set the TTL to 255. If you don't care 
about compatibility, then why is setting the TTL to 1 an better than 
255?

If I'm too late, let me know and I won't argue further.

-josh