6

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.

dbush
  • 205,898
  • 23
  • 218
  • 273
John Zwinck
  • 239,568
  • 38
  • 324
  • 436

1 Answers1

8

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).

nbro
  • 15,395
  • 32
  • 113
  • 196
dbush
  • 205,898
  • 23
  • 218
  • 273
  • 3
    I can't agree about "as low as possible" for multicast TTL. Thing is: multicasts are not broadcasts, so if nobody subscribed to it here there is no a packet issued then. Same time, it may be suitable to let the multicast group being accessible through multiple network segments to reach interested subscribers. Again: multicasts are not broadcasts (despite the fact they're both UDP-driven). – Yury Schkatula Mar 26 '18 at 13:33
  • In my experience it would be highly unusual to send unicast and multicast UDP using the same socket. Anyone who wants separate TTL for multicast could create a separate socket for it. I understand that IP_MULTICAST_TTL affects multicast packets, but at the end of the day the IP header is the same for multicast and unicast, so what's the point? Maybe the point is that implementors wanted to have different default values for multicast (1) vs unicast (64)...though it's not obvious that this was a good idea (see the questions from people who didn't know the multicast default TTL was 1). – John Zwinck Mar 26 '18 at 13:44
  • @JohnZwinck An example of where you would want to do both is in a NAK based reliable multicast transmission. A receiver of multicast transmissions running as a daemon can either send NAKs only to the sender via unicast or it can multicast them to the entire group, and that behavior can be configured on a per-session basis. – dbush Mar 26 '18 at 13:55
  • @YurySchkatula Though unlikely, it is possible that routers can have static multicast routes in place that would allow forwarding of multicast even without an explicit subscription. Granted, multicast is generally not allowed on the public Internet, but on the off chance you use a particular multicast address that is, restricting the TTL safeguards against that. – dbush Mar 26 '18 at 13:58
  • @JohnZwinck And yes, both options do set the same field in the IP header, but having two separate options allows socket implementations to dictate when and how that happens. – dbush Mar 26 '18 at 14:00