Date:        Mon, 20 May 2002 09:28:21 +1000 (EST)
    From:        Darren Reed <darrenr@reed.wattle.id.au>
    Message-ID:  <200205192328.JAA19724@avalon.reed.wattle.id.au>

  | This comment got me thinking.  What is the point of ping being able to
  | 'get there' if (for example) ssh can't ?

It helps work out what the problem actually is.

  | If a ttl of 255 is good enough for ping, why not change net.inet.ip.ttl
  | to 255 as well ?

Then if the path should be 16 hops, but is looping, instead of looping around
16 more hops, it will loop around 240 more hops instead.   For ping, which
is mostly only run by people looking for problems, that's not a huge issue.
It wouldn't be for ssh either.   But if all the world's web traffic started
looping so much more whenever there's a route flap somewhere and the route
to some destination or other loops for a while, then the part of the
internet caught up in the loop will suffer much more if people are using
unreasonably long TTL's.

Also, while it really doesn't matter much any more, the correctness of
TCP depends upon packets being killed - most of the TCP systems around
assume that the TTL isn't going to be set more than 120 or so, that's
implicit in their choice of the holddown timer.  (This doesn't matter much
as in practice there are no hops with a delay anything like a second).

  | The more I think about it, the more sense it makes to tune traceroute to
  | net.inet.ip.ttl because when "ssh cvs.netbsd.org" doesn't work, 9 times
  | out of 10 you are going to see what traceroute does and for traceroute to
  | return meaningful results, it should be using the same ttl as ssh, right?

No.   Much better for traceroute to tell you that it can reach the
destination in 47 hops, then you look at net.inet.ip.ttl and discover it
set to 45, and say "ah".   That's why we have a tunable variable, it can
be fixed easily when needed.   Note that if you're out near the edge of the
net (eg: in Australia...) you probably need a bigger default TTL than those
nearer the centre.   [I had reports years ago that munnari wasn't answering
DNS queries fome some place in Europe - that was a network diameter problem,
which required increasing the TTL used by munnari's named .. .munnari wasn't
NetBSD at the time, this actually meant recompilations...]

kre

ps: by all means make the default TTL for traceroute bigger, though I'm
not sure I'd go all the way to 255 (the -m option is always there for
those cases where the TTL runs out and the destination hasn't yet been
reached, and there's not been any loop either).