Subject: Summary of alternatives

From: Stuart Cheshire <[email-masked]>
Date: Wed, 27 Nov 2002 17:09:17 -0800

There are four practical alternatives for the Working Group to choose 
between:

1. Always check TTL=255
2. Always check TTL=1
3. Don't check TTL at all
4. Have an optional (user configured) check for TTL=255

The three metrics to examine are:

(Mac) Always compatible with existing Macs
(Win) Always compatible with existing Windows boxes
(Orig) Always able to determine if packet originated on the local link

The scores:
                              (Mac) (Win) (Orig)
1. Always check TTL=255         +     -     +
2. Always check TTL=1           -     -     -
3. Don't check TTL at all       +     +     -
4. User configured TTL=255      +     -     -

Option 1 works with Macs. Option 1 tells you the origin of the packet. 
Option 1 works with Windows, but only after you've changed the registry 
key as described in Appendix A.3. (This registry change doesn't have to 
be done manually by the user -- we're recommending to printer vendors 
that their printer driver software should automatically make the registry 
change so that Windows will automatically work properly with their 
Zeroconf printers.)

Option 2 works with nothing today. It tells you nothing about the origin 
of the packet. It may limit forwarding of the packet, but this is a moot 
point because compliant hosts don't send LL packets to routers for 
forwarding anyway.

Option 3 works with today's Macs and Windows boxes, but doesn't tell you 
the origin on the packet.

Option 4 lets the user configure whether they want their printer to guard 
against off-link packets, or whether they want their printer to be 
compatible with the old version of Windows they are using. If the user 
configures it to check, it might not work with old Windows boxes, 
generating expensive support calls, so it fails the "Always works with 
Windows" test. If the user configures it to not check, then it might 
accept off-link packets, so it fails the "Always able to determine if 
packet originated on the local link" test. I have only one further 
comment to make on this topic: Which part of "Zero" and "Configuration" 
did you not understand? If we have to configure something to make it all 
work properly, lets configure the Registry key on last-year's Windows 
boxes to make them work better, not force the customer who buys next 
year's Zeroconf devices to understand and change some configuration 
setting to make them work worse.

Of the four, options 1 and 3 get two points each.

Option 1 has the benefit that receivers know the origin of the packet.

Option 3 has the benefit that it saves Microsoft the hassle of having to 
change its software.

My vote goes for option 1, because it gives the bigger long-term benefit.

Some people have suggested a policy where we require senders to set the 
TTL to 255, but not check the TTL on reception, and then in future, after 
Windows has been updated, we update the specification to require the 
check too. This simply doesn't work. The fact is that there is no 
incentive for vendors to set the TTL correctly if no one is checking. The 
longer time goes on, the more non-conformant devices there will be, and 
it will become impossible to enforce the check later. We have to decide 
now.

In the interest of maintaining a good signal-to-noise ratio, I ask 
everyone to send a BRIEF email saying BRIEFLY which of the four options 
they support (or optionally, an email describing some new option I 
haven't thought of).

Happy Thanksgiving.

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

---

From: Keith Moore <[email-masked]>
Date: Wed, 27 Nov 2002 21:21:57 -0500

> 4. Have an optional (user configured) check for TTL=255

Seems incomplete.  I find several alternatives worth considering:

1. set TTL=255 on transmit, check TTL==255 on receipt
2. set TTL=1 on transmit, check TTL==1 on receipt
3a. set TTL=255 on transmit, don't check on receipt
3b. set TTL=1 on transmit, don't check on receipt
4a. set TTL=255 on transmit, optionally check TTL==255 on receipt
4b. set TTL=1 on transmit, optionally check TTL==1 on receipt

There appear to be other options for receipt checking - in particular,
checking to see if TTL is one of 2 or 3 discrete values on receipt.

Setting TTL=1 on transmit has the desirable property that routers will
automagically filter traffic going outside the local link.  This 
makes it unlikely that LL packets will consume bandwidth from adjacent 
networks and also unlikely that apps using LL will be confused by
traffic from adjacent networks.

Checking TTL==1 || TTL==255 || TTL==128  would allow receivers to 
accept LL packets from both legacy Windows and legacy MacOS 
implementations.  You could do away with the TTL check entirely,
but there's probably some value in doing a minimal TTL check (just like
it is useful to check for packets with a broadcast source address)
as long as you don't trust it to block all outside traffic.

So this pair of constraints provides the greatest assurance that 
a) conforming implementations don't emit packets into adjacent networks,
   and
b) conforming implementations can interoperate equally well with 
   legacy implementations from different vendors

Deliberately generated packets with inappropriate TTLs, and leaked LL 
packets from legacy implementations could confuse apps. So it would be 
necessary for hosts and apps using LL to behave gracefully when receiving LL 
packets that could not be replied to.   Ordinary measures for thwarting
SYN attacks should suffice for TCP.

Of course apps should not assume that LL packets are trustworthy or have 
any authorization associated with them by virtue of their being LL packets, 
regardless of what the TTL value is. 

Keith