I've been reading the iptables man-page (light bedtime reading) and i came across the 'TTL' target, but it warns:

Setting or incrementing the TTL field can potentially be very dangerous


Don't ever set or increment the value on packets that leave your local network!

I can see how perhaps decrementing or setting the TTL lower could cause packets to be dropped before reaching the destination, but what effect could incrementing have?


The TTL get decremented when it pass through a router. This makes sure that if the packet is traveling around in circles it will eventually die.

The TTL field of an IP v4 packet is an 8-bit field (255 decimal). So setting it high at the start it isn't a big deal since it can't actually be that large in a well-formed packet (Although, some things might accept malformed IP packets).

However, if something increments it, and the incrementation step is part of the loop, the packet could keep going in circles without ever reaching zero. Over time (could be very short, or a gradual leak), packets could build up in the system containing that loop causing it to overload.

| improve this answer | |

The TTL on packets keeps routing sane, basically. If a packet were to have a very large TTL and was caught in a circular route for some reason, it could cause a ton of traffic (called a "packet storm") and interfere with normal operations. Too low TTL would result in loss of connectivity as you'd lose the packet before it reached the destination.

| improve this answer | |

There's one point which the answers appear to have missed but which would be purely academic (because of how many hops seem to be required on the internet): if a packet would normally fail to reach it's destination because of an expiring TTL, then increasing it would allow the packet to reach it's destination but would not affect packets being returned and they would expire before reaching your network.

UPDATE: According to this page on Wikipedia:

In theory, under IPv4, time to live is measured in seconds, although every host that passes the datagram must reduce the TTL by at least one unit. In practice, the TTL field is reduced by one on every hop. To reflect this practice, the field is renamed hop limit in IPv6.

UPDATE 2: As someone updated my post and referenced Wikipedia, I thought it might be best to reference the RFC itself - http://www.ietf.org/rfc/rfc791.txt - Just search for TTL in there and it does quite a good job of explaining it:

This field indicates the maximum time the datagram is allowed to remain in the internet system... every module that processes a datagram must decrease the TTL by at least one even if it process the datagram in less than a second
| improve this answer | |
  • 2
    However - if you incremented packets which originated on your network to the value they would have had if they had originated on your router, then the return packets will reach your router (and then you can increment them when sending it onward to the client in the local network) – Random832 May 22 '13 at 19:22
  • I do like the novel view on the approach and you get my upvote for that. However that TTL was originally intended to be decremented once for every second the packet spent in the network as well as for every hop. That historical definition is largely ignored nowadays - however it can never be assumed that the path between two nodes is symmetrical - or even the same from one packet transmission to another. – PP. May 23 '13 at 9:32
  • True. You can get some very odd results using tracert sometimes if packet x takes a different route from packet y! Also thanks for the information about it tracking time too, I didn't know that (although if packets aren't timestamped that could only be decremented if a router held onto it couldn't it?) – Matthew Steeples May 23 '13 at 11:56
  • @PP. Do you have a reference for the claim that the TTL was originally supposed to be decremented once per second? Without high-precision synchronized clocks, which certainly weren't commonplace in Internet's early days (let alone that a lot of hosts only handled local time), I don't see how that could be reliably done. – a CVn May 23 '13 at 14:57
  • 3
    @MichaelKjörling It is defined as such in RFC 791, which defines IPv4. – Michael Hampton May 23 '13 at 17:32

I know just one program, that could use a higher TTL value, and that is traceroute. As the name says, it traces the route to a destination host by modifying the TTL value. The standard max hops is 20, but you can increase that.

| improve this answer | |
  • 2
    (Most implementations of) traceroute also rely on ICMP Time Exceeded messages to tell whether a packet has reached its destination or not. As an aside, Time Exceeded messages is one reason why outright blocking of ICMP is a very bad idea. – a CVn May 23 '13 at 14:55

Each router that handles a packet decrements the TTL value, until the packet reaches its destination, or TTL reaches zero, and dies.

As others have said, increasing TTL could result in packets which never die, if there is a negative cycle. Generally, if a TTL value is not large enough, the logic to try a larger TTL should probably be handled by the end-to-end clients.

If you are sure that a router is not in a cycle (tree-like topology), you could in theory safely increase the TTL value. Having said that, allowing more hops than is standard could make congestion more likely in the external network. If you have a long chain of routers between the internal and external network, as long as there is no cycle, a larger TTL value might help. Having said that, it could be quite easy for somebody to add an edge to the network and create a cycle, so starting with a larger TTL value where the packet originated in the first place is much safer.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.