(usagi-users 03633) Re: IPv6 multicast socket specific binding bug

[email protected] wrote on 03/18/2006 08:24:53 AM:

> I completely understand that the multicast socket model defined
> earlier with IGMPv2/MLDv1 was only affecting interfaces on 

        Well, really, it doesn't have anything to do with IGMP, but
if it did, it would be IGMPv1. :-) These protocols are for
external (multicast router) consumption, but the sockets API for
multicasting, including the "per-interface, not per-socket" part
of it, doesn't require multicast routing or any advertising (for
link-local IP multicasts).

        I think it's just a different, not a better model, and I
think it's 15 years too late from a practical standpoint to
change it. You can propose library functions, or perhaps different
socket options, that do what you want. Even a generalized socket
filter, that matches for unicast packets as well, would be a
potentially handy thing and would allow selections of this sort
more easily at a higher level in the stack. But I don't think
you can reasonably change the semantics of existing system calls
and socket options.
 
> For example, suppose that I have two sockets S1 ans S2 on where
> I have asked the respective following filters for the same group G :
> INCLUDE{a,b,c} and INCLUDE{d,e,f}. Packets arriving on the interface
> machine will be delivered to the sockets according to the 
> filters installed no ? It would be troubling for me to receive packets
> coming from source e on socket S1, and not compliant to RFC3376

        I don't know why you'd say it isn't compliant. It is explicit
that an ordinary, filterless join has an "{EXCLUDE, {}}" filter and
"{INCLUDE, {}}" is equivalent to a leave-group, in the protocols.
        So, in your example, if you apply a full-state {INCLUDE, {}},
that will leave the group _on_this_socket_. What you are (still)
disagreeing with, it appears to me, is the original behavior that
a socket not in the group will receive packets for that group if
the binding allows it. Just as in the unicast case, all you have
to do is change the bind() to specify more precisely what packets
you want to receive. Since I think you want {INCLUDE, {}} not
explicitly for each group, but even when no filtering has been
used on that group, changing per-socket filters to use {INCLUDE,{}}
is a back-door way of breaking existing applications that aren't
using multicast filters at all. I don't think that's a good idea.
        I think it would be a good idea to have a similar, generalized
filtering capability that works with unicast packets. That sort of
thing would make writing INADDR_ANY-bound programs that want source
or destination restrictions without having to do it all in the
application easier. And it would also allow you to write library
functions that do the "exclusive multicast membership" semantics
you want easily.

                                                        +-DLS