# How is 8 bits sufficient for the TTL in an IP header?

The TTL (Time to Live) is an 8-bit field in the IPv4 header. It can take any value from 0 to 255. If this means that the packet can take a maximum of 255 hops (routers) on its way to its destination, then the packet will be discarded.

How is it possible for me to send packets across continents?

• Same reason why most `traceroute` tools give up after merely 30 hops – the "diameter of the internet" is not nearly as big as you think. Commented Feb 22, 2018 at 13:02
• Think of it like putting your data on planes to travel. For local hops you charter a light aircraft. For big international hops, you get on the nearest 777 or A380 and make a big hop. Instead of an international flight though, Data travels from Europe to the US (or elsewhere) on one of these: en.wikipedia.org/wiki/Transatlantic_communications_cable Commented Feb 22, 2018 at 17:10
• The "six degrees of separation" theory might also interest you.
– Pam
Commented Feb 22, 2018 at 19:22
• I seriously encourage you to consider Pam's suggestion. It turns out that in naturally occurring systems (unplanned systems) like people making friends, nodes being added to the internet, companies doing business etc. that the majority of connections don't require many hops. For human interactions that number rarely exceed 6. Take oracleofbacon.org for example, which calculates the connection of actor Kevin Bacon with other actors. The distance between Bacon and Telugu actor Ravi Teja is only 3 movies. The 60s Malay actress Saloma also has only 3 movies between her and Kevin Bacon Commented Feb 23, 2018 at 3:46
• Did any answer help you? if so, you should accept the answer so that the question doesn't keep popping up forever, looking for an answer. Alternatively, you could post and accept your own answer. Commented Dec 31, 2020 at 4:20

Even when sending packets across continents, a TTL of 255 is more than enough - there simply aren't more routers involved.

Running a quick test (from Germany) shows 17 hops to the US and 18 to Japan. Usually, you don't get above 30 or so. This is due to the hierarchical structure of the Internet - you hit your ISP's backbone with just 2-5 hops, another 2-3 hops take you to the next provider etc.

The effect is somewhat similar to the situation found in the small-world experiments.

Note that TTL counts layer-3 hops only. The much more frequently used layer-2 hops across switches have no impact on the TTL - there's no such concept in Ethernet or similar protocols.

Additionally, encapsulating a packet for tunnel transport 'freezes' the TTL while in the tunnel - regardless of how many hops the outer packet takes (it's got its own TTL), the whole tunnel only counts as one or two hops for the inner packet.

A small addition to the other answers to be more complete: although many routers seem to send out packets with a TTL of 255 (for the packets they produce themselves of course, not those they forward!), most operating systems send out packets with much lower initial TTL values:

• Windows uses 128 (since Windows NT 4),
• MacOS X and Linux both use 64

Some systems used to send lower values (e.g. Windows 95 had a default TTL of 32), those values were raised to prevent problems with possibly longer routes... but those systems were definitely able to reach almost any host on the Internet back then. And —although I don't have any proof of this— I'd say that the required number of hops decreased since, because more and more long-distance fibers are installed to carry the traffic.

Also don't forget that the number of hops and the geographical distance don't correlate. Oceans are generally crossed with a single hop (optical repeaters along submarine fibers don't touch the packets, only routers do decrease the TTL). Just did a traceroute from Switzerland to New Zealand: hop #7 is at less than 50 km from where I am, #9 is in California, and #10 is in New Zealand... the intercontinental transit part is generally only a few hops in a route, the rest is mostly reaching an international carrier, and arriving to the destination from it.

8 bit is more than enough. because of ISP peering you can reach destination by travelling through less than 5 or 6 ISPs, and because of backbone network architecture, the packet will transfer only through 3 or 4 router maximum in one ISP.

if you increase the TTL, for un-routed destinations, the packet will be travelling in network until TTL become 0 - which will be consuming bandwidth unnecessarily.

• For un-routed destinations, isn't it common practice to install a reject route to prevent this? Commented Feb 22, 2018 at 16:05
• The problem is not un-routed destinations, the problem is destinations where due to misconfiguration or transient effects there is a routing loop. Commented Feb 22, 2018 at 19:53

A note from the history department: the units of the TTL are seconds, with the permitted time budget decreasing by a second for every router hop.

From the Internet Protocol RFC 791:

The time is measured in units of seconds, but since 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, the TTL must be thought of only as an upper bound on the time a datagram may exist. The intention is to cause undeliverable datagrams to be discarded, and to bound the maximum datagram lifetime.

Multi-second packets were not unusual: a minimal permitted IP datagram of 68 octets takes over 2 seconds at 300 baud. Nevertheless, I've never seen a router which decremented by more than 1 for multi-second packets.

The world is faster these days.

How is it possible for me to send packets across continents?

It's possible because the internet is not built as some huge mesh of local links. Instead the major transit providers have long distance links that (from the IP stack's perspective) go straight from one major city to another.

For example, I just ran a trace from a server I run in the UK to a sever in an approximately antipodal location. Assuming the reverse DNS is correct (not 100% certain, but it's usually close enough), the trace looks like.

• Three hops in the data center where my server resides in Northern england
• One hop from the hosting providers parent company in London
• One hop that doesn't respond to the trace. I suspect this is a hurricane electric router in London.
• One hop from Hurricane Electric (a major international transit provider) in New york.
• Three hops from Hurricane Electric in San Jose California.
• One hop from vocus.network (who appear to be a major AU/NZ provider) where the name implies it's in Los Angeles California, but the latency implies otherwise. Perhaps it's an interface of a router in NZ that is facing the US.
• Three hops from vocus.network in Auckland
• Three hops from what I presume is the provider serving the server.
• The destination server.

So we get to a server on literally the other side of the world in only 18 hops. The structure is fairly typical, a few hops in each city as it jumps around the different routers the provider has there or jumps from one provider to another. Then a big jump to another major city that may be thousands of miles away.