In some email I received from Andrew Brown, sie wrote:
> >> I'd like to change the default maxttl from 30 to
> >> 64 (this matches the kernel default ttl too).  Apart from causing longer
> >> reports when packets go in circles, can anyone see a reason not to bump
> >> this up ?
> >
> >Ping has long used a TTL of 255.  Why not do something similar for
> >traceroute?  To prevent one from seeing 200+ failure lines traceroute
> >could simply stop upping the ttl whenever the past N TTL settings
> >failed.  (Eg. if the past 5-10 traceroute TTL's didn't get a reply,
> >stop incrementing the TTL and exit.)

I don't want to change the behaviour of traceroute (as this suggests),
only its defaults.  Behavioural changes like that are more likely to
have some sort of ripple effect god knows where.

> the difference between ping and traceroute is that ping starts off by
> attempting to "get there", whereas traceroute starts off by assuming
> it can't.

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

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

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?

I don't understand why we should bother to have the default ttl different
to what's in ping (or the other way around).

> there are reasons for not giving up after 5-10 "hops" that don't
> respond...see the traceroute source for examples.
> 
> otoh, another option to specify the number of drops after which
> traceroute gives up might be a neat idea.

So long as it is an option (and not a default), yes.

Darren