[pim] Re: IGMP v3 update - clarification about which router queries cause version fallback

[Brian Haberman <[e-mail]>]

Hi Phi,
      3376 and 3376bis are pretty clear on this from my perspective. 
Section 7.2.1 says:

In order to be compatible with older version routers, IGMPv3 hosts MUST 
operate in version 1 and version 2 compatibility modes. IGMPv3 hosts 
MUST keep state per local interface regarding the compatibility mode of 
each attached network. A host's compatibility mode is determined from 
the Host Compatibility Mode variable which can be in one of three 
states: IGMPv1, IGMPv2 or IGMPv3. This variable is kept per interface 
and is dependent on the version of General Queries heard on that 
interface as well as the Older Version Querier Present timers for the 
interface.

Regards,
Brian

On 7/30/24 12:54 AM, Phil Karn wrote:
> Hi. I'm been trying to figure out why Linux on my network keeps falling 
> back to IGMPv2, and I've found out why. I may need a clarification to 
> RFC3376.
> 
> At first, all works fine. My snooping switch issues an IGMPv3 general 
> membership query and my Linux system answers with IGMPv3 membership 
> messages. Great.
> 
> Then my Linux system sees a IGMPv2 group-specific query for 224.0.0.251 
> (the multicast DNS group). Since I'm running avahi-daemon (the mDNS 
> service daemon) this elicits an outgoing IGMPv2 membership report for 
> 224.0.0.251. Then subsequent IGMPv3 general membership queries elicits 
> IGMPv2 (not v3) membership reports for all my other multicast group 
> memberships.
> 
> I believe this is a bug in Linux, but I want to make sure RFC3376 says 
> what I think it says.
> 
> RFC3376 says an IGMPv2 general query should change the interface version 
> to IGMPv2 and start the IGMPv2 querier-present timer, after which the 
> interface reverts to v3 if enough time goes by without another IGMPv2 
> general query. But it does not explicitly say that ONLY a IGMPv2 GENERAL 
> query should do this -- that a group-specific IGMPv2 query should NOT 
> cause the interface to drop into IGMPv2 mode even if we're a member of 
> that group.
> 
> The problem is that buggy Apple devices frequently and gratuitously join 
> and leave 224.0.0.251, and these devices don't speak IGMPv3. Whenever 
> one leaves, the querier correctly issues a group-specific query to see 
> if any other members are left -- and this group-specific query knocks 
> Linux back to IGMPv2. Since these Apple devices gratuitously join and 
> leave more rapidly than the IGMPv2-querier-present timer expires, the 
> situation persists. IGMPv3 becomes unusable on my network.
> 
> So is it the intent of RFC3376 that ONLY a *general* IGMPv2/v1 query 
> should trigger the version fallback logic, or should a group-specific 
> IGMPv2 query do the same?
> 
> To summarize:
> 
> 1. RFC 3376 is arguably vague about exactly which membership queries 
> should invoke a version fallback. All IGMPv2/v1 queries, or only general 
> ones?
> 
> 2. Linux interprets any IGMPv2 membership query - not just a general 
> query - as triggering a fallback. Right now I don't know if this is 
> correct behavior or an honest misunderstanding of a vague specification.
> 
> 3. Apple really should get with the program and implement IGMPv3. It's 
> only what, 22 years old?
> 
> 4. Apple really should get with the program and stop explicitly joining 
> a very popular link-local multicast address (224.0.0.251) that every 
> host is supposed to be an implicit member of anyway.
> 
> 5. Apple really should get with the program and stop gratuitously 
> leaving and re-joining said link-local multicast group.
> 
> But I'm only asking this list to address point #1. Should group-specific 
> IGMPv2 membership queries trigger a version fallback until the IGMPv2 
> Querier Present timer expires? Or should only general queries do so?
> 
> --Phil
> 
> 
> _______________________________________________
> pim mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]