What happens to the ttl field of an ip datagram every time it reaches a router?

To ensure IP packets have a limited lifetime on the network all IP packets have an 8 bit Time to Live (IPv4) or Hop Limit (IPv6) header field and value which specifies the maximum number of layer three hops (typically routers) that can be traversed on the path to their destination. Each time the packet arrives at a layer three network device (a hop) the value is reduced by one before it is routed onward. When the value eventually reaches one the packet is discarded by the device that receives it (as the value will be reduced to zero). Whilst this won’t prevent network issues caused by a routing loop or similar, it reduces their impact and may help avoid router failures. As it is an 8 bit field, the maximum possible value is 255 (11111111 in binary).

In the unexpected event that a router receives an IPv6 packet with a Hop Limit of zero and that packet is not destined for the router itself, it is discarded as you’d expect. If a router (or any IPv6 host) receives an IPv6 packet with a Hop Limit of zero or one and the host is the destination of that packet (it won’t be routed onwards), the packet is accepted. The IPv4 RFC is far less explicit and simply states that if this field is zero the ‘datagram’ must be destroyed.

The IPv4 RFC states that TTL is measured in seconds but acknowledges this is an imperfect measure. There is no way of knowing how long any particular host will take to process a packet and most will do so in far less than a second. In any case, based on this logic, in theory the maximum time a packet can exist in the network is 4.25 minutes (255 seconds). Hence, the TTL is described as a “self destruct time limit”.

Here’s what the Time to Live and Hop Limit field look like in a standard IPv4 and IPv6 header respectively:

When discarding a packet with a TTL or Hop Limit of one or zero the router in question may (it’s not mandatory) send an ICMP error message to the source as follows:

• IPv4: type 11: ‘Time Exceeded’, code 0: ‘time to live exceeded in transit’

• IPv6: type 3: ‘Time Exceeded’, code 0: ‘Hop limit exceeded in transit’

ICMP messages are frequently blocked or rate limited at various points in a network for perceived security benefits and if that occurs, the source will retransmit the discarded packet(s) a number of times. If the cause of the TTL expiring is a routing loop, this will likely exacerbate the problem. Even if the ICMP message does arrive, there is no easy way for the host to handle the error and take an appropriate course of action. Most likely it will retransmit more quicky than if it had not (no waiting for an acknowledgement first, it knows the packet has not arrived). A routing loop simply can’t be addressed at this level.

The IPv4 Time to Live field and functionality is described in the Internet Protocol RFC 791: //tools.ietf.org/html/rfc791. ICMPv4 is specified in RFC 792: //tools.ietf.org/html/rfc792 and extended in RFC 4884 //tools.ietf.org/html/rfc4884.

The IPv6 Hop Limit field and functionality is described in the Internet Protocol, Version 6 (IPv6) Specification, RFC 8200: //tools.ietf.org/html/rfc8200. ICMPv6 is specified in RFC 4443: //tools.ietf.org/html/rfc4443 and extended in RFC 4884 //tools.ietf.org/html/rfc4884.

Default TTL and Hop Limit Values

Default TTL and Hop Limit values vary between different operating systems, here are the defaults for a few:

• Linux kernel 2.4 (circa 2001): 255 for TCP, UDP and ICMP
• Linux kernel 4.10 (2015): 64 for TCP, UDP and ICMP
• Windows XP (2001): 128 for TCP, UDP and ICMP
• Windows 10 (2015): 128 for TCP, UDP and ICMP
• Windows Server 2008: 128 for TCP, UDP and ICMP
• Windows Server 2019 (2018): 128 for TCP, UDP and ICMP
• MacOS (2001): 64 for TCP, UDP and ICMP

As you can see, the TTL or Hop Limit seen in packets from a host could, in part, be used to identify the operating system in use on that host.

Traceroute

The Linux traceroute and Windows tracert tools (and others) rely upon the TTL or Hop Limit field for their operation. These tools send packets to the destination using an ever increasing TTL, starting with a value of one. On receipt of a packet with a TTL of one, the first hop router (likely the default gateway for the source host) will decrement the TTL by one resulting in a value of zero. This will cause the router to discard the packet and send an ICMP Time Exceeded error message to the source (hopefully).

Packets are then sent with a TTL of two and so on until the packets eventually make it to the destination host. The ICMP error messages and the source addresses of the hosts that sent them reveal which routers are used along the path to deliver packets to the destination. The traceroute tool then presents this information to the user in a logical way. These tools also do a reverse DNS lookup on the source IP address of the ICMP messages they receive to help the user in identifying the devices involved. Most tools use UDP and a destination port from the 33434 to 33534 range for the probe packets by default, with alternative ICMP (Echo Request) or TCP (SYN) options that can be specified if desired. Windows uses ICMP Echo Request packets. For each TTL value used three packets are usually sent by default.

As mentioned earlier ICMP blocking or rate limiting in the network, or even on the sending host may interfere with traceroute’s operation, this issue is exacerbated further by Window’s use of ICMP probes.

Path splitting technologies such as Equal Cost Multi-Path (ECMP) routing may mean the results of two or more consecutive traceroutes will differ. You may even see multiple hosts displayed for a single hop as typically three probes are sent per TTL value. Here’s an example:

7 peer8-et-0-0-4.telehouse.ukcore.bt.net (109.159.252.158) 29.640 ms peer8-et-0-1-4.telehouse.ukcore.bt.net (109.159.252.106) 27.807 ms peer7-et-4-1-1.telehouse.ukcore.bt.net (194.72.16.134) 36.241 ms<br>8 195.99.126.135 (195.99.126.135) 32.526 ms 109.159.253.3 (109.159.253.3) 35.746 ms 109.159.253.235 (109.159.253.235) 38.440 ms

As Jedadiah Casey noted in this blog here at Packet Pushers: “When performing a traceroute from Cisco devices, which send three probes to each hop by default, the second probe in the final hop usually times out. This is due to the default ICMP rate limiting of Cisco IOS. The error messages returned from the intermediate routers are “TTL Exceeded”, whereas the message returned by the ultimate destination is “Destination Unreachable”.”

As Andrea Barberio kindly pointed out in the comments, there are traceroute tools capable of dealing with ECMP, such as Dublin Traceroute and Paris Traceroute.

Ping

The ping tool should not be used directly to confirm your host’s TTL or Hop Limit. The tool’s output displays the TTL or Hop Limit of the incoming IP packets used to deliver the ICMP Echo Response messages, not the the value used when sending the ICMP Echo Requests.

You could of course use tcpdump in conjunction with ping and observe the TTL or Hop Limit of the outbound requests. A command and filter expression like this would work for IPv4:

sudo tcpdump -vvnni any 'icmp[icmptype] == 8'

And this for IPv6:

sudo tcpdump -vvnni any 'icmp[icmptype] == 128'

Changing the TTL On Popular Operating Systems

Linux – IPv4

You can display the current setting like so:

sysctl net.ipv4.ip_default_ttl<br>​<br>net.ipv4.ip_default_ttl = 64

To temporarily change the value to 128 until the next reboot:

sysctl -w net.ipv4.ip_default_ttl=128

To permanently change the value to 128 even if the host is rebooted you have a number of options:

• Edit the /etc/sysctl.conf file
• Create a new file with a .conf extension in the /etc/sysctl.d/ directory
• Edit an existing file in the /etc/sysctl.d/ directory

Whichever route you choose, add this to the file, save and exit:

net.ipv4.ip_default_ttl = 128

Then reload the kernel parameters using the following command along with the name of the file you added the parameter to:

sysctl -p /etc/sysctl.conf

Alternatively, you can reboot the host.

Linux – IPv6

You can display the current default setting for all interfaces (that have not been individually modified) like so:

sysctl net.ipv6.conf.all.hop_limit<br>​<br>net.ipv6.conf.all.hop_limit = 64

To display the current setting for a specific interface (which may have been configured with a non-default value) like so:

sysctl net.ipv6.conf.wlp3s0.hop_limit<br>​<br>net.ipv6.conf.all.hop_limit = 64

To temporarily or permanently adjust the Hop Limit, follow the instructions in the prior IPv4 section using the parameter name(s) detailed in this one instead.

Linux – Other Methods

The TTL and Hop Limit can also be adjusted using the ip route command and with IP Tables.

Windows – IPv4

Display the current value using an Administrative command prompt like so:

C:\WINDOWS\system32&gt;netsh int ipv4 show global<br>Querying active state...<br>​<br>General Global Parameters<br>---------------------------------------------<br>Default Hop Limit &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; : 128 hops<br>...

Set the value immediately and permanently like so:

netsh int ipv4 set global defaultcurhoplimit=64

Windows – IPv6

Display the current value using an Administrative command prompt like so:

C:\WINDOWS\system32&gt;netsh int ipv6 show global<br>Querying active state...<br>​<br>General Global Parameters<br>---------------------------------------------<br>Default Hop Limit &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; : 128 hops

Set the value immediately and permanently like so:

netsh int ipv6 set global defaultcurhoplimit=64

Windows – IPv4 Registry Method

You can also create this registry setting to set the IPv4 TTL only:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters<br>Name: DefaultTTL<br>Type: REG_DWORD<br>Base: Decimal<br>Valid Range: 1-255

Note that a reboot is required.

More on Traceroute

If you’d like to take a closer practical look at how the Linux traceroute tool operates, read on.

A Default UDP Traceroute

We’ll start with a look at the packets generated by a standard traceroute to privacy supporting search site StartPage. First up, let’s run tcpdump and use a filter expression so we only see outbound UDP DNS requests, outbound UDP probes and inbound ICMP Time Exceeded messages:alreadyWe’ll start with a look at the packets generated by a standard traceroute to privacy supporting search site StartPage. First up, let’s run tcpdump and use a filter expression so we only see outbound UDP DNS requests, outbound UDP probes and inbound ICMP Time Exceeded messages:

sudo tcpdump -Knnvvi any '(udp and dst port 53) or (udp and dst portrange 33434-33534) or icmp[icmptype] == 11'

Now let’s run the traceroute:

First we’ll see the IPv4 and IPv6 DNS queries for the startpage.com domain name (requests are being sent to the local systemd-resolve local resolver running on the loopback address 127.0.0.53):

IP (tos 0x0, ttl 64, id 11363, offset 0, flags [DF], proto UDP (17), length 59)<br> &nbsp; &nbsp;127.0.0.1.38232 &gt; 127.0.0.53.53: 26663+ A? startpage.com. (31)<br>​<br>IP (tos 0x0, ttl 64, id 7648, offset 0, flags [DF], proto UDP (17), length 107)<br> &nbsp; &nbsp;127.0.0.53.53 &gt; 127.0.0.1.38232: 26663 q: A? startpage.com. 3/0/0 startpage.com. A 37.0.87.23, startpage.com. A 37.0.87.7, startpage.com. A 145.131.132.94 (79)

Then we’ll see the probe packets (I’ve shown the first packet from the first five sets of three probes):

IP (tos 0x0, ttl 1, id 59291, offset 0, flags [none], proto UDP (17), length 60)<br> &nbsp; &nbsp;10.0.2.160.55220 &gt; 37.0.87.23.33434: UDP, length 32<br>​<br>IP (tos 0x0, ttl 2, id 59294, offset 0, flags [none], proto UDP (17), length 60)<br> &nbsp; &nbsp;10.0.2.160.55236 &gt; 37.0.87.23.33437: UDP, length 32<br>​<br>IP (tos 0x0, ttl 3, id 59297, offset 0, flags [none], proto UDP (17), length 60)<br> &nbsp; &nbsp;10.0.2.160.50889 &gt; 37.0.87.23.33440: UDP, length 32<br>​<br>IP (tos 0x0, ttl 4, id 59300, offset 0, flags [none], proto UDP (17), length 60)<br> &nbsp; &nbsp;10.0.2.160.36143 &gt; 37.0.87.23.33443: UDP, length 32<br>​<br>IP (tos 0x0, ttl 5, id 59303, offset 0, flags [none], proto UDP (17), length 60)<br> &nbsp; &nbsp;10.0.2.160.36325 &gt; 37.0.87.23.33446: UDP, length 32

And here’s what the ICMP error related to the first probe shown above looks like:

IP (tos 0xc0, ttl 64, id 38014, offset 0, flags [none], proto ICMP (1), length 88)<br> &nbsp; &nbsp;10.0.2.1 &gt; 10.0.2.160: ICMP time exceeded in-transit, length 68<br> IP (tos 0x0, ttl 1, id 59291, offset 0, flags [none], proto UDP (17), length 60)<br> &nbsp; &nbsp;10.0.2.160.55220 &gt; 37.0.87.23.33434: UDP, length 32

You’ll note the details of the packet that caused the error message to be sent are included and the TTL shown is 1.

Here’s the reverse DNS query for the host that sent the Time Exceeded message:

IP (tos 0x0, ttl 64, id 54011, offset 0, flags [DF], proto UDP (17), length 71)<br> &nbsp; &nbsp;127.0.0.1.44927 &gt; 127.0.0.53.53: 65236+ PTR? 160.2.0.10.in-addr.arpa. (43)

An ICMP Traceroute

Now let’s see how things look using ICMP Echo Response messages instead (a different source host is used). Here’s the modified tcpdump command and filter expression:Feel free to skip this section, it’s not required for the examNow let’s see how things look using ICMP Echo Response messages instead (a different source host is used). Here’s the modified tcpdump command and filter expression:

sudo tcpdump -Knnvvi any '(udp and dst port 53) or icmp[icmptype]=8 or icmp[icmptype] == 11'

And the traceroute command:

traceroute --icmp startpage.com

Here’s some of the ICMP probes:

IP (tos 0x0, ttl 1, id 14423, offset 0, flags [none], proto ICMP (1), length 60)<br> &nbsp; &nbsp;10.11.12.176 &gt; 37.0.87.51: ICMP echo request, id 8761, seq 1, length 40<br>​<br>IP (tos 0x0, ttl 2, id 14426, offset 0, flags [none], proto ICMP (1), length 60)<br> &nbsp; &nbsp;10.11.12.176 &gt; 37.0.87.51: ICMP echo request, id 8761, seq 4, length 40<br>​<br>IP (tos 0x0, ttl 3, id 14429, offset 0, flags [none], proto ICMP (1), length 60)<br> &nbsp; &nbsp;10.11.12.176 &gt; 37.0.87.51: ICMP echo request, id 8761, seq 7, length 40

And an ICMP Time Exceeded message, with details of the outbound ICMP probe message:

19:04:49.973098 IP (tos 0xc0, ttl 64, id 29383, offset 0, flags [none], proto ICMP (1), length 88)<br> &nbsp; &nbsp;10.11.12.254 &gt; 10.11.12.176: ICMP time exceeded in-transit, length 68<br> IP (tos 0x0, ttl 1, id 14423, offset 0, flags [none], proto ICMP (1), length 60)<br> &nbsp; &nbsp;10.11.12.176 &gt; 37.0.87.51: ICMP echo request, id 8761, seq 1, length 40

A TCP Traceroute

Now let’s see how things look using TCP SYNs and port 80 instead (a different source host is used). Here’s the modified tcpdump command and filter expression:

sudo tcpdump -Knnvvi any '(udp and dst port 53) or tcp dst port 80 or icmp[icmptype] == 11'

And the traceroute command:

sudo traceroute --tcp --port 80 startpage.com

Here’s some of the TCP SYN probes:

IP (tos 0x0, ttl 1, id 51513, offset 0, flags [none], proto TCP (6), length 52)<br> &nbsp; &nbsp;10.101.210.201.39955 &gt; 216.58.198.174.80: Flags [SEW], seq 1839786269, win 5240, options [mss 1310,nop,nop,sackOK,nop,wscale 2], length 0<br>​<br>IP (tos 0x0, ttl 2, id 51516, offset 0, flags [none], proto TCP (6), length 52)<br> &nbsp; &nbsp;10.101.210.201.36083 &gt; 216.58.198.174.80: Flags [SEW], seq 143600272, win 5240, options [mss 1310,nop,nop,sackOK,nop,wscale 2], length 0<br>​<br>IP (tos 0x0, ttl 3, id 51519, offset 0, flags [none], proto TCP (6), length 52)<br> &nbsp; &nbsp;10.101.210.201.57301 &gt; 216.58.198.174.80: Flags [SEW], seq 1968846450, win 5240, options [mss 1310,nop,nop,sackOK,nop,wscale 2], length 0

I ran this traceroute while connected to a public WiFi network and didn’t get any ICMP Time Exceeded messages at all but I think you know what they look like by now.

The traceroute tool also tidies up after itself by sending RSTs using the same source ports used to send the SYN packets. This ensures any stateful devices that might have created connection table entries based on the SYN packets remove them quickly. You’ll note that the RST packets have reverted to using the host’s default TTL, whch is 55 in this case.

IP (tos 0x0, ttl 55, id 0, offset 0, flags [DF], proto TCP (6), length 40)<br> &nbsp; &nbsp;10.101.210.201.39955 &gt; 216.58.198.174.80: Flags [R], seq 1839786270, win 0, length 0<br>​<br>IP (tos 0x0, ttl 55, id 0, offset 0, flags [DF], proto TCP (6), length 40)<br> &nbsp; &nbsp;10.101.210.201.36083 &gt; 216.58.198.174.80: Flags [R], seq 143600273, win 0, length 0<br>​<br>IP (tos 0x0, ttl 55, id 0, offset 0, flags [DF], proto TCP (6), length 40)<br> &nbsp; &nbsp;10.101.210.201.57301 &gt; 216.58.198.174.80: Flags [R], seq 1968846451, win 0, length 0

There’s More

You can use the TTL or Hop Limit to determine if a middlebox, proxy, DPI or IPS device is getting involved in a flow. If the TTL or Hop Limit of packets arriving at a server are very different to the value set by the client sending them, taking into account the likely number of hops, chances are something has been placed between the client and server. This is most likely by design and valuable information if you are having issues with malformed client requests or data which could be caused by whatever the device is.

You can also use the TTL or Hop Limit to determine the likely source of connection resets and confirm whether the destination is sending them or something else is interfering. If you know the far end is 10 hops away and runs Linux (default TTL of 64) and the TTL of the reset packets is 60, something doesn’t add up.

You can use a very low TTL or Hop Limit value as a crude but effective form of security. For example, a host in a data centre or AWS VPC may have no need to communicate with anything more than 10 hops (or less) away. You can set the TTL or Hop Limit value accordingly and ensure communication with any host outside of that ‘radius’ will fail. This protects against many data exfiltration methods, command and control and remote access exploits and more. An outbound proxy can be used to allow access to permitted sites on the internet for the purposes of software updates for example. An inbound full proxy used ‘in front’ of the server may void some of this protection.