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

[Gyan Mishra <[e-mail]>]

Phil

I have seen this exact behavior and it’s very annoying that a single IGMPv2
host sending a query can drop the entire LAN from IGMPv3 to IGMPv2.

The workaround was to find the device and shut it down or upgrade it to
support IGMPv3.

This issue happens every time an older non standard devices placed on LAN
which can bring down LAN to V2 unfortunately.

We also had an issue where we had L2 switches on a LAN that had management
interface with PIM enabled however was missing IGMP v3 setting and that was
bringing LAN down to v2.  We had PIM as standard on all interfaces however
we should have had exception for L2 switches but we didn’t and that wreaked
havoc on every LAN with L2 switch that has PIM enabled was reverting the
LAN to V2.  What a nightmare that was to fix and troubleshoot.


If we do a bis or update to the spec I think there is a lot that can be
cleaned up.

Kind Regards

Gyan
On Fri, Aug 16, 2024 at 8:27 PM Phil Karn <[e-mail]> 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]
>
> _______________________________________________
> pim mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>