https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193246
--- Comment #11 from Craig Rodrigues <rodr...@freebsd.org> ---
-------- Forwarded Message --------
Subject: Re: [Bug 193246] Bug in IPv6 multicast join(), uncovered by
Jenkins
Date: Fri, 05 Sep 2014 03:05:14 +0100
From: Bruce Simpson <b...@fastmail.net>
To: bugzilla-nore...@freebsd.org
On 04/09/2014 19:16, bugzilla-nore...@freebsd.org wrote:
> I think what this means is that in_mcast6.c is very much tied to doing MLDv6
> (or whatever the v6 equivalent of IGMP is), but for these groups, you need to
> be somehow calling into in_mcast.c to do IGMP instead. However, I'm not sure
> at what level in_mcast6.c needs to call into in_mcast.c myself. I do think
> Bruce is your best bet for someone to ask.
>
Unfortunately I'm fully booked. But yes, that is a good summary.
If Craig (or someone else) is willing to volunteer to support v4-mapped
addresses: one approach would be to extend in6_mship{} to include them.
Pushing state down to IGMP will need to be added as a special case. To
keep it simple, assume that only the legacy any-source multicast (ASM)
model will be supported, i.e. listeners will not specify source filters.
Looking at the JDK source, it appears they used to handle the v4/v6
swizzle themselves because of limitations in Linux 2.4/2.6.
In other words, we do not support RFC 3493 Sec 3.7 for multicast groups
at the moment. A more appropriate errno value to return is EPROTONOOPT.
[Interestingly, Sec 5.2 discusses IPv6 multicast options, but does not
contain any reference to IPv4 at all.]
There now follows a late-night writeup of the rationale behind this code
-- and this is as concise as I can make it, I'm afraid.
in[6]_mcast.c is split into a top half (i.e. per-socket state) and a
bottom half (i.e. stack-wide state, and the IGMPv1/2/3 and MLDv1/2 wire
protocols). IPv6 mcast options are processed separately from IPv4.
Both implement a transaction scheme to protect global membership state
(in the bottom half) from failures at the granularity of a single socket
(or PCB) in the top half.
Why all the complexity? Well, this is to support source-specific
multicast (SSM, aka "inclusive mode"). To cut a long story short: as the
size of an internetwork increases, it gets more difficult for routers to
track the state of multicast listeners, unless they are aware of where
the traffic originates from. The book "Interdomain Multicast Routing" by
Brian M. Edwards discusses this in lurid detail.
So, SSM was introduced to support inter-domain multicast. In this model,
joining a multicast group is no longer a simple matter of registering
for a channel -- you must also specify the sources you are interested
in. However, the majority of multicast applications are built on the
older model: i.e. they do not cross more than one IP network hop, and do
not specify sources ("any-source multicast", aka ASM).
The network stack must be able to cope with both of these uses. It does
so by representing the legacy ASM scheme as "exclusive mode". The RFC
3678 APIs also have the advantage that the application can block
unwanted senders, even if ASM is in use. [The main API it specifies,
setsourcefilter(), does not explicitly mandate v4-mapped support.]
So, in the bottom half of mcast, each group has a shared RB-tree of
listener state. This is created from the set union of the filter state
on each subscribed socket.
If there are no filters for a particular group, i.e. all of the
sockets/PCBs in the system are in "exclusive" mode and have no filters,
then of course the RB-tree for that group will be empty. Otherwise, if
there is a mix of "exclusive" and "inclusive" mode listeners, the tree
will need to be recomputed.
The shared tree is then used to fill out the IGMP/MLD messages sent to
on-link routers to request group subscription. It is also used to filter
input traffic from within the relevant transports (e.g. UDP, raw
sockets). Previously, this filtering required that the network layer
take a socket-layer lock.
In closing: this isn't just a simple matter of adding a few defines. The
v6 code will need to check that a v4-mapped group was passed, and make
sure to perform the transaction pushdown to IGMP.
--
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
