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

From: Arun Thulasi <[email-masked]>
Date: Thu, 12 May 2005 14:46:10 -0700

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.

Thanks,
Arun T

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

---

From: Stig Venaas <[email-masked]>
Date: Fri, 13 May 2005 19:53:56 +0200

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

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.

Stig

---

From: Hoerdt Mickael <[email-masked]>
Date: Fri, 13 May 2005 20:27:21 +0200

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

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

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.

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
Arun Thulasi wrote:

> Hello All,
>
> This is a request to review and comment on the internet draft
> available at
> 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.
>