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

[Brian Haberman <[e-mail]>]

That would be a re-design of the protocol, so not feasible in this go 
around.

Brian

On 8/16/24 8:27 PM, Phil Karn wrote:
> I think it means an older version of IGMP. But hey, you can never be too 
> explicit in these things. That's why we're discussing this in the first 
> place.
> 
> But if we want to start another, larger discussion on improved 
> compatibility, we can do that too. IMHO, the timers are a kludge. Simply 
> answer IGMPv2 queries with IGMPv2 responses, and IGMPv3 queries with 
> IGMPv3 responses. A single host running an old version of IGMP shouldn't 
> be able to drag its entire LAN down to its level. I mean, IGMPv3 is now 
> what, 22 years old? When I was active in the IETF, I couldn't even 
> conceive of having to worry about protocols 22+ years old. TCP/IP itself 
> wasn't that old.
> 
> Phil
> 
> On 8/16/24 13:11, Dino Farinacci wrote:
>> But does "older" mean a previous received Query, or one with an older 
>> version where 1 < 2 < 3, and 1 is older than 2 and 3,
>> and 2 is older than 3?
>>
>> If it is version based, can a LAN go from v3 to v2 when the v3 Query 
>> doesn't arrive anymore?
>>
>> Dino
>>
>>> On Aug 16, 2024, at 6:40 AM, Brian Haberman 
>>> <[e-mail]> 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]