Proposal: Merge RFC3678 multicast APIs

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
_______________________________________________
freebsd-net@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscribe@xxxxxxxxxxx"

Relevant Pages

  • Re: SSM Multicast availablity
    ... SSM obviously needs a different API to the previous ... multicast, with the obvious addition of the source list. ... Does it support SSM? ...
    (microsoft.public.win32.programmer.networks)
  • Re: IPv4 mapped address considered harmful
    ... > When userland application on top of AF_INET6 API sees peers with IPv4 ... > to basic API behavior) or IPv6. ... > o Assume that the victim node is an IPv4/v6 dual stack node. ...
    (Bugtraq)