Subject: Re: Comments sought: draft-arunt-ipv6-multicast-filtering-rules-00.txt

From: Arun Thulasi <[email-masked]>
Date: Sun, 05 Jun 2005 23:17:06 -0700

Hello Stig,

Bear with me for the delayed reply. Do look inline for my reply to your 
comments and suggestions.

>On Thu, May 12, 2005 at 02:46:10PM -0700, Arun Thulasi wrote:
>  
>
>>Hello All,
>>
>>This is a request to review and comment on the internet draft available 
>>at 
>>http://www.ietf.org/internet-drafts/draft-arunt-ipv6-multicast-filtering-rules-00.txt
>>
>>The draft is written to explain a set of behaviors in IPv6 multicasting 
>>scenarios. Since the behavior seemed to vary on different 
>>implementations, this draft specifies both the behaviors and puts forth 
>>one of them as preferred.
>>
>>Do look into the draft and offer your comments.
>>    
>>
>
>The behaviour described in 5.2 pretty much matches what I would expect.
>However, you don't say anything about SSM or the RFC 3678 source filering
>API.
>
>  
>
I did a run through of the ssm and allied drafts. The behavior that we 
have suggested in the draft is independent of SSM. By this I suggest 
that if the user wants to implement SSM, it would have to involve some 
kind of filtering. Since SSM requires a (S,G) format where there has to 
be exactly one source and multiple receivers (as specified in the 
document), it is different from the default behavior what we propose in 
our draft which applies for ordinary multicasting scenarios.

However, it would be a better idea to include something on SSM support 
in the document (the least is to mention that SSM is not part of the 
scenario and atmost explain what differentiates this solution from the 
SSM scenario) since this document talks about multicast filtering rules 
in IPv6. If the general consensus is that, i can work on including that.

>I would like to see the stack doing filtering if necessary, so that when
>a host joins specific sources (include mode) other packets reaching the
>host from other sources would not be delivered to the application. And
>also when in exclude mode, excluding specific sources, the stack should
>filter in my opinion.
>
>  
>
Yes. This is indeed SSM specific (when you want to exclude sources etc). 
One way to include SSM in the draft is to talk about all this in the 
filtering scenario, still suggesting that this is optional and not 
default behavior.

>In my opinion, the filtering should at least be done so that an
>application doesn't receive from unwanted sources on the socket where
>the filter is applied. If the same application or another, creates
>another socket and binds to the right port and wildcard address or the
>group address, then I think the best might be to deliver the packets.
>
>  
>
I think this is what we present in the draft. If another application 
binds to the right port and wild card address, it would still be 
delivered the packet.

In my opinion, i guess it could be a good idea to talk about SSM in the 
draft, in the filtering behavior section. I can even work on a separate 
section that talks about Multicast Filtering in SSM based scenarios.

Do let me know what you suggest.

Thanks,
Arun T

>Stig

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Arun Thulasi <[email-masked]>
Date: Sun, 05 Jun 2005 23:17:31 -0700

Hello Hoerdt,

Do bear with me for the delayed reply. Do find my reply to you inline.

>Hi Arun,
>
>Thanks for this work, I think it can be very useful for multicast
>application writers. Here are my comments :
>
>Section 3:
>
>You say that the current behavior is implementation specific, could you
>give some references/samples ? My experience is that the multicast
>socket/setsockopt behavior
>is quite standard among implementations even is sometime functions
>arguments are changing...
>
>  
>
I ran some tests on a few implementations. I did see them behaving 
differently while receving multicast packets destined to certain 
addresses. We had actually formed the idea of a draft specifying the 
rules for multicast filtering only after noticing that.

>Section 4:
>
>I guess that you want to say "Multicast socket" instead of multicast
>client in this section.
>Reducing multicast applications to Client and Server with a destination
>and source port is quite dangerous here I think. That's of course the
>way how current simple multicast applications are working today but
>keeping the idea more general, multicast applications may contains
>several sockets corresponding to several protocols and joining several
>groups.
>
>Also, you use the words host/node/client independantly, I understand
>them as "sockets".
>
>  
>
Agreed. However, i would prefer to have the word "applications" in the 
text, but still add "sockets" to differentiate between the two entities 
and putting the forth the point of them being some sort of a interface 
handle. Do let me know of your suggestions of how else we can 
differentiate between these two entities.

>Section 5:
>
>I dont think that I agree with this section, why should every
>applications should listens to
>some special multicast adresses ? I think my disagreement is a
>consequence of the socket/Application/client definition.
>
>  
>
RFC1112 talks how the all-host group is a special case and always starts 
as an Idle Member and never transitions to another state. I reckon this 
would suggest that the address should be ON all the time.

I would be working on including new filtering rules when SSM is present 
on the machine. Do let me know if you would require the draft to address 
any more issues.

Cheers,
Arun T

>Section 6:
>
>The behaviour is what I would expect from a system. Please note that the
>information present in this section is redundant with RFC3678.
>
>Cheers,
>
>Hoerdt Mickaël
>  
>