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

Question

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?

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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.

Answer 5

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.