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

[email protected] wrote on 03/20/2006 01:33:51 PM:

> the spec, in RFC 3376, section 3.2 you can read, with two 
> sockets having called :
> 
> IPMulticastListen ( s1, i, m, INCLUDE, {a, b, c} )
> IPMulticastListen ( s2, i, m, INCLUDE, {b, c, d} )
> 
> "after a multicast packet has been accepted from an interface by the
> IP layer, its subsequent delivery to the application or process
> listening on a particular socket depends on the multicast
> reception state of that socket [and possibly also on other
> conditions, such as what transport-layer port the socket is bound
> to].  So, in the above example, if a packet arrives on interface
> i, destined to multicast address m, with source address a, it will be 
> delivered on socket s1 but not on socket s2.

        As you probably know already, Linux does this in the literal
case.

> ...
> The previous service interface [RFC1112] described no filtering 
> based upon multicast join state; rather, a join on a socket simply 
caused the 
> host to join a group on the given interface, and packets
> destined for that group could be delivered to all sockets
> whether they had joined or not.
> "
        Glad to see that quote, since I've been using more indirect
references for years prior to this RFC to explain why it isn't broken. :-)

> Maybe i'm misinterpreting this text, but according to it, you can setup
> explicit filter on multicast trafic per socket.

        Yes, and you can on Linux as well. The special-case
exception is {INCLUDE, {}}, which is defined to be the same
as a "leave", so it frees the membership at the socket
layer and does not maintain filter (or group membership)
state. Even adding that as an explicit way to exclude a
group isn't an unreasonable change to existing code,
though it would only exclude groups explicitly enumerated.
 
> So now coming back to what I think that could be useful :
> 
> The implicit filter set on a socket at it's creation state (even
> if it doesn't require any memory in the kernel) is "Accept
> all group, and all sources that is,rely on the binding state" which
> could be translated to a call to the equivalent logical function 
> defined in RFC3678 :
> 
> int setipv4sourcefilter(int s, struct in_addr interface,
>                         INADDR_ANY, MCAST_EXCLUDE,
>                    0, NULL);
> 
> I know that you cannot do that witht the current kernel (using
> MCAST_FILTER setsockopt you'll get a EINVAL) but as a (*,EXLUDE,{}) 
> state implicitely exist on a socket, i was just wondering 

        RFC3678 refers to the 3rd argument as "the group". So, I
take it your suggestion is to allow wild-carding in the glibc
function, which would then require kernel support for it. That
is not allowed in the draft kernel interface I implemented, or
as far as I can see, in the wrappers defined by RFC3678. It's
EINVAL because INADDR_ANY isn't a multicast address. :-)
        This literal call is unnecessary, because the default for
all joined groups is in fact {EXCLUDE, {}}, but I think you're
suggesting to extend it for the purpose of allowing a non-group-
specific per-socket default filter. That's a reasonable thing to
do, but as a spec-extension, it is still not portable to/from other
OSes. If you're going to do that, why not add full filtering
for all sockets, unicast and multicast, source, destination and
possibly other packet attributes? :-) But maybe not so cumbersome
as pcap...

> if it would be costly or not to implement an explicit state of 
> (*,INCLUDE,{}), using MCAST_FILTER ?

        I think this is doable, but doing it violates the interface
specification (by extending it to "work" in an error case). It's
less intrusive than what I thought you were suggesting before,
but I'm still not sure it's a good idea. Doing this through a
new filtering mechanism that isn't bound by POSIX, or having
POSIX explicitly extend it (even including unicasts!) is better
than breaking portability.

                                                        +-DLS