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

[Brian Haberman <[e-mail]>]

Hey Dino!
      We have a slim window to get something into 3376bis *if* we can 
clearly articulate that it is a clarification (the IESG approved 3376bis 
last week).

So, section 7.2.1 says:

The Host Compatibility Mode variable is based on whether an older 
version General query was heard in the last Older Version Querier 
Present Timeout seconds.

AND

If a host receives a query which causes its Querier Present timers to be 
updated and correspondingly its compatibility mode, it should switch 
compatibility modes immediately.

I think a simple approach is to change the first sentence to use a MUST 
for changing mode based on a General query. So, something like:

The Host Compatibility Mode variable value MUST only be updated based on 
whether an older version General query was heard...

Thoughts?

Brian

On 8/15/24 2:41 PM, Dino Farinacci wrote:
> Brian, this is a protocol design bug if this behavior was intended. Otherwise the RFC needs updating for clarity.
> 
> In either case, the RFC text MUST BE fixed.
> 
> Dino
> 
>> On Aug 14, 2024, at 9:41 PM, Phil Karn <[e-mail]> wrote:
>>
>> I understand that part. My point was that Linux appears to reset the interface compatibility mode timer for IGMPv2 in response to a *group specific* membership query. My reading of the RFC is that this should be done only for *general* membership queries (no specific group). Even worse, MacOS stops responding entirely to IGMPv3 queries.
>>
>> As things stand now, if you have an iPhone on your LAN, IGMPv3 is unusable for everybody.. If you have a MacOS system on your LAN and the querier is IGMPv3, multicast will be broken for you. Permanently. Is that the intent of the RFC?
>>
>> if you see a group-specific query and you’re a member of that group (otherwise you probably wouldn’t see the query!) you should answer with the version used for that query, but reset the compatibility mode timer to IGMPv2 only if the next *general* query uses IGMPv2.
>>
>>> On Aug 14, 2024, at 13:35, Brian Haberman <[e-mail]> wrote:
>>>
>>> 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]
>>> _______________________________________________
>>> pim mailing list -- [e-mail]
>>> To unsubscribe send an email to [e-mail]
>>
>> _______________________________________________
>> pim mailing list -- [e-mail]
>> To unsubscribe send an email to [e-mail]
>