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

[hoerdt@xxxxxxxxxxxxxxxxxxxxx]

Hi,

See inline,

On Mon, Mar 20, 2006 at 12:20:50PM -0800, David Stevens wrote:
> hoerdt@xxxxxxxxxxxxxxxxxxxxx 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.

No, that's not what i want. I also think that this implicit INCLUDE{}
filter at socket creation is not a good idea for the same reason you
mentionned. The example I mentionned was in fact inspired from 
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.
...
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.
"
Maybe i'm misinterpreting this text, but according to it, you can setup
explicit filter on multicast trafic per socket. 

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 
if it would be costly or not to implement an explicit state of 
(*,INCLUDE,{}), using MCAST_FILTER ?

Thanks,

Mickael

>         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
> 
> 
>