Subject: Re: traceroute max ttl uplift
To: Wolfgang Rupprecht <wolfgang@wsrcc.com>
From: Robert Elz <kre@munnari.OZ.AU>
List: tech-net
Date: 05/20/2002 18:21:06
    Date:        Sun, 19 May 2002 12:32:08 -0700
    From:        Wolfgang Rupprecht <wolfgang@wsrcc.com>
    Message-ID:  <15591.64952.526061.727317@capsicum.wsrcc.com>

  | The examples in the source were from the days when it was unusual for
  | routers to do the TTL decrementing for ICMP messages correctly.
  | Traceroute was the tool that caused folks to fix these bugs.

No, not quite - they were from the days when it happened (though
wasn't really common) for hosts to reply to packets (especially
when sending ICMP errors) using the TTL that was in the packet when it
arrived.   That is, if a packet arrived with a TTL of 1 (typical
traceroute packet) the reply (ICMP port unreachable) would be sent
with a TTL of 1.   Needless to say, that rarely reached the sender.
Sender assumes dropped packet, tries again, TTL increased by 1,
this time the reply starts with TTL of 2.

Eventually the sender has the TTL set to twice the hop count, the
reply is originated with a TTL of exactly the hop count, and the packet
makes it back to the source - arriving with a TTL of 1.   For that
reason, traceroute tests for reply packets arriving with a TTL of 1
and flags them.

  | I can't recall a single case within the last few years where I did a
  | traceroute and saw a "hole" of 5 or more hops.

no, those ancient broken hosts all seem to have gone now.   But I'd bet
there's still at least one out there somewhere...

kre