As suggested by the user kwaio, the default (or a common) TTL value to use when generating ICMP echo-request and echo-reply packets is 64.
In my case, the first routers along my selected path responded with an echo-reply message with TTL=255 (at the source), while the last ones with TTL=64.
It appears instead that ICMP time-exceeded messages were created in all cases with a TTL of 255.
After some digging, I found out that different vendors and different OS's adopt different initial TTLs for different protocols: binbert.com/blog/2009/12/default-time-to-live-ttl-values
An interesting implication of this is that you can take identify the manifacturer of a given router by letting a packet expire on it and by sending it a ping. More details here:
TTL-based Fingerprinting and MPLS and the full article: "Network Fingerprinting: TTL-Based Router Signatures".
Hi I'm late but in the event you're still curious...
The quote from R Steenbergen's NANOG slide is correct. The behaviour is defined in Section 4.3.2.4 of RFC1812, which states:
the IP source address in an ICMP message originated by the router MUST
be one of the IP addresses associated with the physical interface over
which the ICMP message is transmitted
Depending on one's Traceroute implementation, the response to a trace may be an ICMP Destination Unreachable (i.e. Unix-implemented traceroute) or an ICMP Time Exceeded (Windows-initiated traceroute). I believe this is covered in Steenbergen's presentation. Since neither of these sections make any provision for specifying source address of the ICMP response, we assume that Section 4.3.2.4 holds for these specific response types.
Picture this scenario and assume the following:
- Assume all links between circles (routers) are equal-cost layer-3 links (in
particular, that the link between R1 and R2 is not a
LAG/EtherChannel/etc)
- Routing within example network is such that packets go from Sender S to Receiver R over the lower path, and
return via the higher path, in the directions indicated
The Traceroute under modern day implementations would look like this:
traceroute to R
1 A 0.329 ms A 0.425 ms A 0.471 ms
2 C 0.349 ms C 0.435 ms C 0.473 ms
3 F 0.359 ms G 0.445 ms F 0.481 ms
4 R 0.369 ms R 0.455 ms R 0.491 ms
And the trace if routers were coded to the spec would look like this:
traceroute to R
1 B 0.329 ms B 0.425 ms B 0.471 ms
2 D 0.349 ms E 0.435 ms D 0.481 ms
3 H 0.369 ms H 0.445 ms H 0.491 ms
4 R 0.389 ms R 0.455 ms R 0.496 ms
So in a more colloquial sense, modern implementations tell us how we reached a particular host. The original specification would tell us how we left a router, but would not tell us how we got there.
Note that we might think this would cause Ping to break, but the specification covers that case explicitly:
The IP source address in an ICMP Echo Reply MUST be the same as the
specific-destination address of the corresponding ICMP Echo Request
message.
In other words, for Ping, the ICMP Echo Reply source address shouldn't be an address associated with the egress interface as specified by Section 4.3.2.4, but should instead use a source address derived from the destination address of the original ICMP Echo Request.
Best Answer
We can't be sure, it can change.
Each packet can have a different path, there is no guarantee here, it is a tool to help debugging, and not always a perfect truth.
A packet can also take one path there, but a completely different path back.
So what traceroute does tell you is at which router the packet "failed" with each step of increased TTL. To try and verify you run the trace multiple times (some implementations might already do this for you)
There could also be specific rules in place, which makes different types of packets take different paths. For example a trace might work perfectly fine, while TCP and/or UDP ports are blocked somewhere.