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

[hoerdt@xxxxxxxxxxxxxxxxxxxxx]

David,

Thanks for your comprehensive explanation.

I completely understand that the multicast socket model defined
earlier with IGMPv2/MLDv1 was only affecting interfaces on 
a machine, and that packets were delivered according to the
sockets binding only, but with IGMPv3/MLDv2, the packets are delivered
to sockets according to their binding *and* the filter that they
setup in the application right ?

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

So, the key issue here is what is the default filter present on a socket
after being created. If I follow you correctly, the current 
implementation, to be compatible with previous IGMP/MLD interface 
service and applications assume EXCLUDE{} for all groups showing 
up on the socket, but it is not possible to setup the opposite 
filter and the socket (INCLUDE{} for all groups), why ? 

According to RFC3678, I could use the full state API to setup
the socket filter to INADDR_ANY as a group argument, an empty
source list, and INCLUDE mode isn't it ?

Thanks,

Mickael



On Fri, Mar 17, 2006 at 11:42:07AM -0800, David Stevens wrote:
> Hugo Santos <hsantos@xxxxxxxx> wrote on 03/17/2006 11:00:09 AM:
> 
> > David,
> > 
> >    I'm sorry if my line of thought is wrong, but, considering that in
> >  Hoerdt's example, the S1 socket didn't join the group, shouldn't it's
> >  multicast filter implicitly be INCLUDE {} for all groups? Is the socket
> >  filter only considered for MLDv2 Reports and not for packet delivery?
> 
>         Well, no. I mean, you're assuming that the join has something to
> do with what packets are delivered to the socket the join was done on
> first, and then wondering why joins aren't per-socket. :-)
>         A join of a group on a machine was never defined to affect just
> one socket, and has never had anything to do with what socket you did
> the join on. You can join every group (for the whole machine) on a
> socket that you never do any I/O on. The socket doesn't even have to
> be the same protocol as the sockets you're doing I/O on! For example,
> you can join all groups the machine needs on a raw ICMP socket, and
> do all the I/O for those groups on UDP sockets.
> 
>         I understand that this confuses a lot of people, but it isn't
> a reasonable argument to assume one model first, and then consider it
> a bug that the code follows a different model. :-)
>         The RFC, the original socket implementation, and all others
> after, use the model that packet delivery to a socket is determined
> by the address & port binding (i.e., the bind() call). Delivery to
> the machine is determined by unicast, broadcast and multicast
> addresses associated with the interfaces. Multicast joins don't
> change that at all-- they follow the same model as unicast and
> broadcast did before IP multicasting existed.
> 
>         You could make the same case that you should be able to bind()
> to a unicast address not on the local machine and then receive any
> packets on that network for that non-local unicast address. That's
> an alternative, and reasonable model, but it isn't how sockets were
> defined. Maybe you want to define a new API that aren't sockets. :-)
> 
>         But whether you agree with the way it was originally designed
> or not, it isn't something new and changing the behavior to fit a
> different model on Linux only simply would break existing applications
> for Linux that use the existing model, and make anything using that
> on other OSes no longer portable to Linux.
> 
>                                                         +-DLS
> 
>