> > Actually, as a spec of IGMPv2/v3, router alert option is mandatory
> > even in a report message. This means it should be set or check not
> > only by a router, but by a host.
> 
> It should definitely be set by both router and host.  But a host is not
> a router, so there is no need for the host to process a Router Alert,
> and no need for the host to demand that the option be set.

IGMPv2/v3 docs mention Router Alert is not only for a router.
In fact, rfc2236 says;
	All IGMP messages described in this document are sent with IP
	TTL 1, and contain the IP Router Alert option [RFC 2113] in
	their IP header.
Also an I-D of v3 spec explicitly says;
	Hosts SHOULD Ignore v3 Queries without the Router-Alert
	option.
Actually, handling Report message between v2 and v3 is completely
different, so v3's I-D doesn't mention about v3 Report with RA. But
it is not a meaning that RA only should be care by a router.
So, if we restrictly talk about IGMPv2/v3 spec, you are not correct.
If you are just talking you disagree the spec, let's talk about ideal
way for us.

> > So, IMO, it's good to modify kernel to implement IGMP with RA.
> > In addition, set/getsockopt implementation is necessary to handle this
> > option, in order to make routing daemon, like pimd, know that kernel
> > would set/check RA. After set/getsockopt implementation for RA is
> > done, routing daemon with using this set/getsockopt can handle whether
> > it should set/check by daemon itself.
> > 
> > The problem is - actually, it's not a problem, it's a spec, though -
> > when kernel modification strictly follows IGMP's specs, every IGMP
> > packet with no RA is ignored.  ...
> 
> This may be in the spec, but it is a bad idea.  When implementing a
> protocol, any protocol, it is best to be as conservative as possible
> when creating packets (adhere to the spec as closely as you can) but 
> be as LIBERAL as possible (ignore the little things that can't make
> any difference).

Okay.
So, we should have a selection mechanism for IGMP to be restricted by
spec or not?

> It doesn't make any sense to check that the RA option is present, nor
> to ignore packets where it isn't present.  The whole purpose of the
> RA option is to make certain that the router processes the packet.  If

Yes, at this point, you might be true.

> you have processed the packet enough to notice that the RA isn't
> there, then you've gotten past the point where RA would have made a
> difference (ie, you've already noticed that the packet exists).  So
> discarding the packet at that point does nothing useful.

Hmm. I cannot say you are correct here.

> Besides, although I haven't read the IGMP v2/v3 specs in the last 
> couple of weeks, I don't think there's anything in there that actually
> says that the receiving router has to discard packets without the RA
> being set.

So, please read these specs.:)
And please send your comments to the authors if you disagree.

> > ...  So if someone who doesn't implement RA
> > sends IGMPv2/v3 message, then strictly modified node, which may be a
> > host or may be a router, cannot communicate the sender.
> > So, as my ideal way:), sysctl implementation to able or disable strict
> > RA check is also a good idea.

Again, this is my propose, though, I like having;
       kernel part (in an igmp.c) to set/check RA
       set/getsockopt() to set/check RA by daemon
       sysctl() to turn on/off RA check by kernel(?)
If you don't want to strictly follow these specs, then you use above
sysctl() to not check RA.
(But remember after we have these implementations, each multicast
routing daemon should be modified...)
Isn't it good for you?

> PS  This E-mail represents my personal views, and in no way does it
> represent the view of my employer!

I see.:)
--
Hitoshi Asaeda