Proposal: Merge RFC3678 multicast APIs

[Bruce M Simpson]

Hi,

I propose that we merge the RFC3678 advanced multicast APIs. Doing so 
gets us closer to IGMPv3 and SSM. I would greatly appreciate suggestions 
about how to deal with the include header issue below.

I have already started merging the basic definitions into p4 branch 
bms_netdev.

Background:
 * RFC3678 specifies user and kernel APIs for any-source and 
specific-source multicast for IPv4, IPv6, and protocol-independent use.
  * this includes struct ip_mreq_source and friends
  * SIOCSIPMSFILTER and SIOCGMSFILTER are historical and may be ignored.

Impact:
 * It requires that struct sockaddr_storage is visible to <netinet/in.h>.
  * This change breaks the following files in the kernel:
in4_cksum.c inet_ntoa.c ip_ecn.c in6_cksum.c in_cksum.c slcompress.c
  ...which do not include <sys/socket.h> where this structure is defined.

Benefit:
 * We get the SSM API. We don't support IGMPv3 or SSM yet, but this is 
part of the work.
 * Better to do this now and incrementally; the IGMPv3 implementations 
out there for FreeBSD have been published as patch sets which are now 
bitrotting.
 * This lets us eliminate the ugly RFC1724 hack from the IPv4 stack, 
which is used to
   specify an outgoing IPv4 multicast interface by passing a 24-bit 
interface index
   in the host portion of a 0.0.0.0/8 address.
  * This behaviour is not portable; Microsoft Windows Vista uses the 
full 32-bit wide interface index space in both its IPv4 and IPv6 stack. 
No snickering from the gallery please -- Dave Thaler has done excellent 
work bringing the MS stack closer to IETF standards.
  * routed uses this; it can be patched to not do so; the RFC3678 API 
for this is to use the generic MCAST_JOIN_GROUP socket option which 
accepts an interface index as an argument in struct group_req.
  * Linux defines a struct ip_mreqn as a workaround for applications 
using the pre RFC3678
    API. Inside the kernel it maps IFA to IFP when handling 
IP_ADD_MEMBERSHIP, thus avoiding
    the 0.0.0.0/8 hack.

See ip(4) in HEAD for the polite rendering of my rant about doing IGMP 
correctly and its  implications for addressing in the IPv4 stack (short: 
you need an IP address for it to work properly, and source address 
selection, or IPv6, is looking like a really good idea in a 
wireless/manet/mobile/ad-hoc world).

Regards,
BMS