skip to content

In IPv4, who sets the TTL of an ICMP echo reply, and what can the received TTL tell you about the responder and path?

level: middleimportance: should knowfreq 26%

answer

  1. the reply is newly originated
  2. not copied from the request
  3. common starting values
  4. start minus observed equals hops
  5. return path only

basics

~20 s

The responder sets an echo reply's TTL from its own starting value; RFC 1812 forbids routers copying it from the request. Likely start minus received TTL estimates return-path hops, but the start is a guess and the forward path stays invisible.

solid answer

~40 s

An echo reply is a new datagram the responder originates, so its TTL starts at the responder's own initial value: RFC 1812 §4.3.2.2 says a router MUST initialise it and must not take it from the triggering packet, and a host uses its configured default per RFC 1122. Each router on the way back decrements it, so the received TTL is that start minus the return-path hop count. Initial values are implementation defaults (Linux uses 64; 128 and 255 are also common), so guessing the nearest one gives a rough hop count and a weak OS hint. It only describes the return path, which can differ from the forward one, and a middlebox answering on the host's behalf sets its own TTL. A sudden change in reply TTL signals a return-path change.

go deeper

for a junior

Recall that the reply is a fresh datagram whose TTL the responder sets, and that routers reduce it by one per hop on the way back.

for a middle

Explain the start-minus-observed hop estimate, why the start is an implementation default rather than a protocol value, and why only the return path is measured.

for a senior

Use reply TTL changes as a route-change signal, and spot when a middlebox or duplicate address is answering because the implied starting value does not fit the host.

for a principal

Decide how much an estate's monitoring should rely on TTL-derived path signals given asymmetric routing and configurable defaults, versus dedicated path measurement.

## The reply is a new datagram An ICMP echo reply is not the request turned around in flight. The responder **originates a new IP datagram**: RFC 792 describes swapping the addresses and changing the type, and every IP field the responder does not copy, including the **Time to Live** (`TTL`, an 8-bit field in the IPv4 header), is the responder's to set. - RFC 1812 §4.3.2.2 is explicit for routers: when originating an ICMP message the router **MUST initialize the TTL**, and the TTL for ICMP responses must **not** be taken from the packet that triggered the response. - Hosts follow their general rule for every datagram they send, RFC 1122 §3.2.1.7: the IP layer sets a TTL (never zero), and when a fixed value is used it MUST be configurable. So the TTL in a received reply is: **the responder's initial TTL, minus one for every router on the path back to you.** ## Where the starting values come from The specifications do not fix the starting value. RFC 1122 says it should be large enough for the Internet's diameter, and RFC 1812 observes that "64 is a common value". Operating systems pick their own defaults as an implementation choice — Linux, for example, starts at 64 — and other systems commonly start at 128 or 255. Administrators can change all of them. ## Reading a received TTL The usual inference runs like this: 1. Take the TTL you observed, say `57`. 2. Assume the responder started at the nearest common value at or above it — here `64`. 3. Subtract: `64 − 57 = 7` routers on the **return** path. | Observed TTL | Likely start | Implied return-path hops | |---|---|---| | 57 | 64 | 7 | | 116 | 128 | 12 | | 243 | 255 | 12 | This is a **heuristic**, not a measurement, and each step can fail: - **The start value is a guess.** A host configured to start at 100 that is 36 hops away would be misread. - **It measures the return path only.** Routing on the Internet is often asymmetric; the reply can come back through different routers than the request went out on, so the number says nothing reliable about the forward path. - **The responder may not be the host.** A middlebox answering echo on a server's behalf — an implementation feature of some load balancers and firewalls — sets its own TTL, so the value describes the middlebox. - **Tunnels hide hops.** A tunnel that does not decrement the inner TTL makes several physical routers count as one. ## What changes in the TTL tell you Watching the reply TTL over many probes is more useful than one value: - A **stable** TTL across replies means the return path length is stable. - A **step change** (from `57` to `53`, say) means the return path changed — a route change or failover somewhere upstream. - **Alternating** values can mean replies are being spread across return paths of different lengths, or that more than one device is answering for the address. The starting value also serves as a weak **operating-system fingerprint**: a reply arriving just under 128 suggests one family of systems, just under 64 another. It is unreliable for the same reason the hop count is — defaults are configurable. ## What the TTL does not tell you - The TTL of the **request** when it reached the target is not reported back; the reply carries a fresh TTL, so the forward hop count is invisible to an echo exchange. Mapping the forward path is a separate technique built on deliberately small TTLs and the time-exceeded messages routers send. - The TTL is not a time: although RFC 791 defined it in seconds, routers decrement it by one per hop, so it says nothing about latency. - IPv6 has the same mechanism under the name **Hop Limit** (RFC 8200), with the same caveats for ICMPv6 echo replies.

  • Replies from one address alternate between TTL 57 and TTL 121. What explanations fit?
    Values that far apart suggest different starting TTLs, near 64 and near 128, rather than one responder on paths of different lengths. The likeliest causes are two different devices answering for the address, such as a duplicate IP assignment or a middlebox answering some probes while the host answers others, or replies arriving through different responders behind an anycast or load-balanced address.
  • Why can't an echo reply tell you how many hops the request travelled?
    The request's remaining TTL is consumed at the target and never written into the reply; the responder starts the reply with a fresh TTL of its own. Because Internet routing is often asymmetric, the return hop count is not a proxy for the forward one either. Learning the forward path needs a different technique based on sending probes with small TTLs and reading the time-exceeded messages routers return.

saying these in an interview costs you the question

  • The echo reply's TTL is copied from the request's remaining TTL.
  • A reply TTL of 64 is required by the IP specification.
  • Reply TTL gives the exact forward-path hop count to the host.
  • The TTL in a reply measures latency in seconds.