Sender source address selection improvements

[neirbowj]

I have recently started looking more closely at IPv6 multicast. This uncovered a quirk of the way mcjoin does sender source address selection that manifests itself on FreeBSD. That got me thinking about several more general improvements, and I'm hoping to get some feedback on whether I'm thinking about this in a way that aligns with the community.

The quirk is that FreeBSD and Linux return results from getifaddrs(3) in a different order. On Linux, the link-local address (LLA) is last. On FreeBSD it's first. mcjoin selects the source address by iterating over the list for the outbound interface (guessed from default route or specified with the -i option) and stopping on the first one that has the UP, RUNNING, and MULTICAST flags all set. On FreeBSD that results in always sending from the LLA when the group is IPv6.

A quick fix would be to add a check to ifinfo to skip LLAs, either entirely or at least when the destination is not also of Link-Local scope or smaller.

My next thought was to wonder why mcjoin needs to handle source address selection at all? If an application does not call bind(2) on a socket intended to initiate communications, doesn't the OS already select a suitable source address informed by things like the unicast routing table, interface configuration, and system-level preferences? As a testing tool, I think I want the default behavior to be the least opinionated and to have some ability to override system defaults through the application.

While I was tinkering with this, it also dawned on me that mcjoin ignores the source specification from the command line when in sender mode. It seems natural to want to select the source address in sender mode as one of the ways to override system defaults, and reusing the established argument syntax has several benefits over creating a new option to bind sockets: parsing and validation would be simpler than having to detect and reject SOURCE,GROUP in sender mode; and it would be nice to be able to source different groups from different addresses.

My current thinking goes something like this. In sender mode...

• The -i IFACE option is not needed and can be ignored or rejected.

• When SOURCE is not specified (GROUP only or GROUP:PORT), the
  call to bind(2) is skipped, and the OS gets to selects the source
  address for the group.

• When SOURCE is specified (SOURCE,GROUP or SOURCE,GROUP:PORT),
  the socket for that group is bound to the specified source. While
  little to no validation is needed at the application layer, errors
  from the OS should be reported. If the operator selects a source
  address that results in unexpected behavior (e.g. no output on the
  wire), I would consider that a useful test result.

• The current application layer logic for source address selection
  could be retained and enabled with a new command line switch.

If these sound like good ideas, I could probably hack together some patches sufficient for basic validation. I have easy access to several different platforms for testing: FreeBSD 14.3; Rocky Linux 8, 9, and 10; and Ubuntu 24.04.

[neirbowj]

The -i IFACE option is not needed and can be ignored or rejected.

It looks like this may be incorrect on platforms where the IP_MULTICAST_IF sockopt wants the ifindex.