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

[Brian Haberman <[e-mail]>]

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