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

[Brian Haberman <[e-mail]>]

I haven't heard any concerns with the below edits. I will make them in 
my working version and submit it for Gunter's review early next week.

Thanks!
Brian

On 8/16/24 8:18 PM, Phil Karn wrote:
> That's good too. It's just that really explicit language makes it easier 
> to convince the code maintainers that they have to fix something.
> 
> Phil
> 
> On 8/16/24 10:49, Brian Haberman wrote:
>> Hi Phil,
>>      From a language perspective, I think that is simply a repetition 
>> of the same rule since there are only two types of query messages. If 
>> you think the MUST NOT approach makes it more explicit, I would suggest:
>>
>> 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. The Host Compatibility mode variable value 
>> MUST NOT be changed by an older version of a group-specific query.
>>
>> Regards,
>> Brian
>>
>> On 8/16/24 1:42 PM, Phil Karn wrote:
>>> Why not make it more explicit?
>>>
>>> The Host Compatibility Mode variable value MUST only be updated based 
>>> on whether an older  General query was heard in the last Older 
>>> Version Querier Present Timeout seconds. The Host Compatibility mode 
>>> variable value MUST NOT be changed by an older version of a 
>>> group-specific query.
>>>
>>> On 8/16/24 06:40, Brian Haberman wrote:
>>>> So, I don't think we should drop "older" from the sentence. The 
>>>> paragraph immediately before that sentence says that Host 
>>>> Compatibility Mode changes based on receiving an even older version 
>>>> query or expiration of the timers.
>>>>
>>>> Paragraph 3 of 7.2.1:
>>>> The Host Compatibility Mode of an interface changes whenever an 
>>>> older version query (than the current compatibility mode) is heard 
>>>> or when certain timer conditions occur. When the IGMPv1 Querier 
>>>> Present timer expires, a host switches to Host Compatibility mode of 
>>>> IGMPv2 if it has a running IGMPv2 Querier Present timer. If it does 
>>>> not have a running IGMPv2 Querier Present timer then it switches to 
>>>> Host Compatibility of IGMPv3. When the IGMPv2 Querier Present timer 
>>>> expires, a host switches to Host Compatibility mode of IGMPv3.
>>>>
>>>> To me, that means the proposed edit is to make the following change 
>>>> in section 7.2.1
>>>>
>>>> OLD:
>>>> 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.
>>>>
>>>> NEW:
>>>> The Host Compatibility Mode variable value MUST only be updated 
>>>> based on whether an older  General query was heard in the last Older 
>>>> Version Querier Present Timeout seconds.
>>>>
>>>> Thoughts?
>>>>
>>>> Brian
>>>>
>>>> On 8/15/24 3:39 PM, Dino Farinacci wrote:
>>>>>> Hey Dino!
>>>>>
>>>>> Hi!
>>>>>
>>>>>>      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).
>>>>>
>>>>> Well if its a bug, you DO NOT let the process stop you. Its 
>>>>> important to fix. Taking a network down due to this issue is a 
>>>>> showstopper bug.
>>>>>
>>>>> Now, Phil, you got to get Apple to fix this. Stuart Cheshire may be 
>>>>> able to help.
>>>>>
>>>>>> 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.
>>>>>
>>>>> I wouldn't say "older" actually. If you "hear any different version 
>>>>> than you did last time", then the new query version is what runs on 
>>>>> the LAN. Because if IGMPv3 leaves the LAN, the LAN should operate 
>>>>> in IGMPv2.
>>>>>
>>>>>> 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.
>>>>>
>>>>> Right.
>>>>>
>>>>>> 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...
>>>>>
>>>>> Agree:
>>>>>
>>>>> The Host Compatibility Mode variable value MUST only be updated 
>>>>> based on whether a different version General query was heard, from 
>>>>> the last one received, ...
>>>>>
>>>>> Dino
>>>>>
>>>>>>
>>>>>> 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]
>>>>>