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

[Phil Karn <[e-mail]>]

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