Why are IP_TTL and IP_MULTICAST_TTL separate socket options?

Question

When sending UDP multicast you can use IP_MULTICAST_TTL to set the TTL. But otherwise you would use IP_TTL. Why are these two different options in the eyes of setsockopt() and getsockopt()? Is there any situation in which setting them separately makes sense?

It seems to me they ultimately set the same value in the IP header.

Answer 1

These options actually function differently.

Setting IP_MULTICAST_TTL only affects outgoing multicast datagrams, not unicast datagrams. In contrast, setting the IP_TTL option (at least on Linux) only affects outgoing unicast datagrams. This allows you to use one TTL for multicast and one TTL for unicast.

There are similar flags for IPv6, namely IPV6_MULTICAST_HOPS and IPV6_UNICAST_HOPS.

It's good practice to set the TTL for multicast packets as low as possible. This prevents them from potentially being broadcast out much more widely than needed and flooding network segments. This isn't really an issue for unicast datagrams since they're only destined for a single machine.

So, if you plan on sending both multicast and unicast datagrams from the same socket, it may make sense to use this.

This behavior was confirmed on CentOS 7.2 (kernel 3.10) and Ubuntu 16.04 (kernel 4.4).