In some email I received from Robert Elz, sie wrote:
[...]
>   | 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.

Well...hmmm...what serves most of the world's web pages ?
Answer that and then look below at the short list I drew up.

> 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).

Well, some points of reference:
Solaris (2.5.1+), HP-UX (11+) both ship with a default TTL of 255;
Windows 2000 has a default ttl of 128;
Linux has used 255 since at least 2.2.

> 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).

I'm tending towards using 64 in traceroute and maybe bump the kernel to 128.

Darren