Subject: Re: WG Action - 1 week last call [LL3] TTL=244 on send, check on receive? (fwd)

From: Erik Guttman <[email-masked]>
Date: Thu, 27 Feb 2003 15:38:03 +0100 (CET)

---------- Forwarded message ----------
Date: Thu, 27 Feb 2003 21:30:28 +0700
From: Robert Elz <[email-masked]>
To: Erik Guttman <[email-masked]>
Subject: Re: WG Action - 1 week last call [LL3] TTL=244 on send, check on receive? 

Reject LL3, (accept LL21 in its place...)

LL3 as it stands changes nothing, leaving the TTL==255 on send,
and expecting that hosts will (sometime in the future) check it
on receive - which is what the doc already implies (it says that
hosts MAY check on receive - but no-one sane would do that when
there are known implementations that don't send 255).

There's no good reason for using 255 (even assuming it is being
checked - if it isn't, its absurd).   The absolute most that this
gains is to allow a host to drop a packet if it has passed through
a (broken) router (just how that could even happen, however broken
the router, is left to the imagination, of which lots is required).
If the packet isn't dropped, the host attempts to reply, and that
fails, which is not exactly a huge loss to anyone (given that in
practice this isn't going to happen anyway).

The alternative that has been suggested is TTL==1 instead.   That's
so routers won't forward packets.   But any host that knows to set
TTL==1 will also know not to send the packet to a router, so that
turns out to be a null benefit as well.

This all boils down to there being no reason that makes any sense
to specify anything at all about TTLs (though it might be prudent
to note, if it is in fact true - I am relying on my memory of remarks
made on the list, that some implementations actually check that
packets have TTL==255 - which might suggest to implementors in the
short term that using 255 would be safest, without actually requiring it).

kre