Re: [pim] [MBONED] IGMPv3 backward compatibility issue killing SSM (was: Re: pim wglc for 3228bis, 3376bis and 3810bis)

[Stig Venaas <[e-mail]>]

Hi Toerless

Please see my comments inline.

On Thu, Dec 21, 2023 at 2:49 AM Toerless Eckert <[e-mail]> wrote:
>
> On Wed, Dec 20, 2023 at 11:23:25AM -0800, Stig Venaas wrote:
> > Hi Toerless and others
> >
> > I don't think we can mandate not falling back, like Jake wrote, it
> > would not be good if all implementations that are compliant with
> > current IGMPv3/MLDv2 are not compliant with the new version.
>
> But you did get the point in my last reply to Jake that we could make
> those requirements only against "SSM aware" IGMP router side implementations.
>
> That "SSM aware" is new in 3376bis, so it does not affect existing
> implementation. Only if existing implementations would want to claim to
> be SSM aware would they have to raise to a higher bar than what
> their existin implementation may provide for.

In 3376bis, SSM aware is defined as:

   This document uses SSM-aware to refer to systems that support Source-
   Specific Multicast (SSM) as defined in [RFC4607].

Hence, implementations that claim to support 4607 (many
implementations do today), would have to support any SSM aware
requirements. What you're suggesting would work if we have some new
term that is optional. I still think not falling back should be
RECOMMENDED or a SHOULD, and it might be best to have a knob to
control it.

> > I would say that we RECOMMEND that routers have a knob for controlling
> > whether to fall back to v2 for SSM ranges when older querier is
> > detected, and perhaps also RECOMMEND that the default is not to fall
> > back for the SSM ranges.
>
> See above. I think we are safer to make the requirement only for
> "SSM aware" IGMP router side implementtions. And then i think we can
> have a default MUST.

See above, if you claim support for 4607, then you are SSM aware.

> > I see nothing good with falling back really, the older querier would
> > not understand the reports, but I don't know if it causes any harm.
>
> ?? The harm of falling back is of course that SSM stops to work when
> this happens.

Sorry, that was poorly worded. What I meant is that I see no benefit
in falling back for the SSM range. ASM would not work for that range
anyway, at least from pim perspective you would not have an RP for
instance since it is in the SSM range.
But even if not falling back, there is a problem if the DR happens to
be one of the lower version routers.

Stig

> With the text i proposed, we would likely manage to overcome this:
> - Router does not fall back to IGMPv2 queries
> - Host with SSM apps running does also not fall back to IGMPv2/v1
>   (ignores IGMPv1/v2 queries).
>
> So an IGMPv2/v2 only querier shows up on the LAN, IGMPv3 with SSM
> on router/host continues to operate by just ignoring those v1/v2 queries
>
> But of course, automatic fallback makes sense for IGMP snooping switches
> that run an IGMP querier. They're meant to work without config in
> the presence of any router(s). But they could be sold as "SSM aware",
> in which case they'd also not falll-back, - aka: the choice of
> default behavior of snooping switch would depend on where they're
> being sold into.
>
> CHeers
>     Toerless
> >
> > Regards,
> > Stig
> >
> > On Wed, Dec 20, 2023 at 8:30 AM Toerless Eckert <[e-mail]> wrote:
> > >
> > > Thanks for the proposal, Hitoshi
> > >
> > > I am still trying to find a use-case where configuring fallback would actually
> > > be useful... Any example from your side ?
> > >
> > > I've been trying to wrap my head around the use-cases:
> > >
> > > a) candidate IGMP querier because one is an SSM aware IP multicast router
> > > b) candidate IGMP querier because one is an IP multicast router (without intent to do SSM)
> > > c) candidate IGMP querier because one is an IGMP snooping switch
> > >
> > > I think in case a) you do not want any fallback to igmpv2, and you want to get alerts
> > > when some other device introduces igmpv2/igmp1 queries.
> > >
> > > I think in b) you may run into the issue of someone wnting to connect IGMPv2-omly
> > > snooping switches. But in that case you most likely need to explicitly configure
> > > IGMPv2 router behavior because such switches area not guaranteed to force the
> > > router back into IGMPv2 router mode.
> > >
> > > In case c), i thnk the switch may even want to have automatic fallback on by default
> > > (aka: going beyond what you said). Because unlike a) and b), the switch most likely
> > > wants to be able to operate without any config.
> > >
> > > Cheers
> > >     Toerless
> > >
> > > On Fri, Dec 15, 2023 at 03:48:19PM +0900, Hitoshi Asaeda wrote:
> > > > Hi Toerless,
> > > >
> > > > IGMPv3/MLDv2 backward compatibilities are the known issues.
> > > > I mentioned them more than two decades.
> > > > (https://mailarchive.ietf.org/arch/msg/magma/6DOmd2mscjnv1l1Hflq1D7mE7UM/)
> > > >
> > > > Lightweight IGMPv3/MLDv2 (RFC 5790) hence mentioned as follows;
> > > >    In the presence of older version group members, LW-IGMPv3 hosts may
> > > >    allow its Report message to be suppressed by either an IGMPv1 or
> > > >    IGMPv2 membership report.  However, because the transmission of
> > > >    IGMPv1 or v2 packets reduces the capability of the LW-IGMPv3 system,
> > > >    as a potential protection mechanism, the choice to enable or disable
> > > >    the use of backward compatibility may be configurable.
> > > >
> > > > We (IGMPv3/MLDv2 DS design team, I remember you were also the one:) discussed the backward compatibility problem and decided to mention such configuration operation in the bis drafts.
> > > > But, well, I understand the statements (1837-1841) may contradict. Two MUST are orthogonal.
> > > >
> > > > IMO, keeping this backward compatibility mode is Ok, but we should have a mechanism to disable this automatic mode by operation. And disabling the automatic mode should be the default. Therefore,
> > > >
> > > > >  This revision of IGMPv3 version 3 removes automatic fallback to IGMP version 2 and version 1
> > > > >  routers on the same network as specified in [RFC3376]. Instead,
> > > > >  such older version router behavior MUST be explicitly configured.
> > > >
> > > > I don't think we need to remove the automatic mode. Keep as is but should be disabled by default.
> > > >
> > > > >  IGMPv3 routers MUST have a configuration option, disabled by default, to operate
> > > > >  as an IGMPv2 router. When enabled, all procedures of [RFC2236] apply. Configuring this
> > > > >  option is necessary in the presence of non-IGMPv3 capable IGMP snooping switches or
> > > > >  PIM routers. These are rare but may still be depoyed.
> > > >
> > > > The default should be IGMPv3 only mode. It can be changed to automatic by configuration.
> > > >
> > > > >  When operating in IGMP version 3, routers MUST ignore version 1 and version 2 queries.
> > > > >  In version 3, the presence of those older version queries constitutes a misconfiguration
> > > > >  or attack, and these messages SHOULD result in logging of an error (rate-limited).
> > > >
> > > > I agree.
> > > >
> > > > > - And in an appropriate part of the host behavior:
> > > > >
> > > > >  IGMP version 3 hosts MUST have a configuration option, disabled by default, to ignore
> > > > >  IGMP version 1 and version 2 queries. This option SHOULD be auto-enabled when the host
> > > > >  is running SSM receiver applications, and hence depends on IGMP version 3 to operate in the
> > > > >  network.
> > > >
> > > >
> > > > Agree.
> > > >
> > > > For your another question regarding the implementation having the configuration option, my very old kernel implementations (see following links) support static configuration to stop backward compatibility mode and change IGMPv3/MLDv2 only mode on host sides by sysctl command;
> > > > IGMPv3 kernel: https://web.sfc.wide.ad.jp/~asaeda/igmpv3/index.html
> > > > MLDv2 kernel: https://web.sfc.wide.ad.jp/~asaeda/mldv2/index.html
> > > > LW-IGMPv3 kernel: https://web.sfc.wide.ad.jp/~asaeda/LW-IGMPv3/index.html
> > > > See README on each link for more detail.
> > > >
> > > > These IGMPv3/MLDv2 kernel implementations were imported into KAME, so some BSD-based kernel may have the similar option, but I'm not sure.
> > > >
> > > > Regards,
> > > >
> > > > Hitoshi
> > > >
> > > >
> > > > > On Dec 15, 2023, at 6:29, Toerless Eckert <[e-mail]> wrote:
> > > > >
> > > > > Dear pim/mboned:
> > > > >
> > > > > I am in WGLC review for rfc3376bis, but i am stumbling across the one IMHO elephant in the room,
> > > > > and i thought i should start a separate discussion thread here, and also Cc: mboned, because not
> > > > > all ops folks may want to follow pim, but this elephant is i think the main reason why SSM has
> > > > > gotten a bad rap in deployments - and we should take the opportunity to fix it in rfc3376bis.
> > > > >
> > > > > The elephant IMHO is that rfc3376bis is so far not including changes to IGMPv3 behaviors
> > > > > about backeward compatibility with v1/v2 routers on the LAN, and exactly this behavior is
> > > > > killing SSM in deployment because any such router when it becomes querier will kill SSM
> > > > > ... because hosts will revert to v1/v2 and not report their SSM (S,G) memberships.
> > > > >
> > > > > RFC3376 (and currently rfc3376bis too) writes (line numbers from idnits):
> > > > >
> > > > > 1837       *  If any older versions of IGMP are present on routers, the querier
> > > > > 1838          MUST use the lowest version of IGMP present on the network.  This
> > > > > 1839          must be administratively assured; routers that desire to be
> > > > > 1840          compatible with IGMPv1 and IGMPv2 MUST have a configuration option
> > > > > 1841          to act in IGMPv1 or IGMPv2 compatibility modes.
> > > > >
> > > > > The second sentence is either english that i do not understand, or it is in contradiction to
> > > > > the first sentence. If there is a configuration option to enable/disable router compatibility
> > > > > with IGMPv1/IGMPv2, and i disable this configuration option on my router, then i would
> > > > > be in contradiction to the first sentence, wouldn't i ?
> > > > >
> > > > > I am also not aware of implementations that do have a configuration option that
> > > > > would allow to disable IGMPv1/IGMPv2 backward compatibility - when running IGMPv3.
> > > > >
> > > > > In many router operating systems there is a config "ip igmp version [1|2|3]",
> > > > > but when it is configured for version 3 (which by now should be the default in all
> > > > > router OSs), then the backward compatibility will be active, falling back to IGMPv1/v2
> > > > > when an appropriate lower general query is received. Maybe this is what implementors
> > > > > thought of when reading 1837-1841, but i would be surprised if thats what was meant.
> > > > >
> > > > > If there are routers that have config options to disable this backward compatibility with
> > > > > older routers, i would love to learn about it.
> > > > >
> > > > > So, my argument is:
> > > > >
> > > > > The 1837-1841 functionality of RFC3376 was intended to also allow disabling of IGMPv2/IGMPv3
> > > > > router backward compatibility (and one can argue whether or not it was meant to be enabled
> > > > > by default). However, this is a feature that was not implemented. Instead, widely deployed
> > > > > implementations only implemented automatic fallback - and that turned out to be a non-desirable
> > > > > operational behavior of RFC3376. Instead, when users actually did want to have IGMPv2
> > > > > behavior on their network, they explicitly configured IGMPv2 router behavior. But did not
> > > > > want to rely on automatic fallback. And given how there is in current widely deployed router
> > > > > implementations no way to disable automatic fallback, this is the core reason for SSM to
> > > > > be highly inreliable, especially in IPTV contexts.
> > > > >
> > > > > Hence we should have the freedom to change this now to what would make IGMPv3 behave better,
> > > > > especially for SSM:
> > > > >
> > > > > - Remove above text from rfc3376 and other text referring to older router queries (1673-1675).
> > > > >
> > > > > - Replace with something like:
> > > > >
> > > > >  This revision of IGMPv3 version 3 removes automatic fallback to IGMP version 2 and version 1
> > > > >  routers on the same network as specified in [RFC3376]. Instead,
> > > > >  such older version router behavior MUST be explicitly configured.
> > > > >
> > > > >  IGMPv3 routers MUST have a configuration option, disabled by default, to operate
> > > > >  as an IGMPv2 router. When enabled, all procedures of [RFC2236] apply. Configuring this
> > > > >  option is necessary in the presence of non-IGMPv3 capable IGMP snooping switches or
> > > > >  PIM routers. These are rare but may still be depoyed.
> > > > >
> > > > >  When operating in IGMP version 3, routers MUST ignore version 1 and version 2 queries.
> > > > >  In version 3, the presence of those older version queries constitutes a misconfiguration
> > > > >  or attack, and these messages SHOULD result in logging of an error (rate-limited).
> > > > >
> > > > > - And in an appropriate part of the host behavior:
> > > > >
> > > > >  IGMP version 3 hosts MUST have a configuration option, disabled by default, to ignore
> > > > >  IGMP version 1 and version 2 queries. This option SHOULD be auto-enabled when the host
> > > > >  is running SSM receiver applications, and hence depends on IGMP version 3 to operate in the
> > > > >  network.
> > > > >
> > > > > This is about as much as i think we can do if we still want to go full standard with rfc3376bis.
> > > > > I can think of no operational deployment where the introduction of devices with existing
> > > > > older RFC compatibility would cause interoperability issues. At worst the new router would
> > > > > need to be explicitly configured for IGMPv2, which in my experience most routers deployed
> > > > > into IGMPv3 environments are done anyhow.
> > > > >
> > > > > Comments welcome. Would love to see positive replies in which case i will be happy to  explicitly
> > > > > sugest the text changes for this elephant issue to the draft.
> > > > >
> > > > > Cheers
> > > > >    Toerless
> > > > >
> > > > > On Wed, Dec 13, 2023 at 01:08:13PM -0800, Stig Venaas wrote:
> > > > >> Hi again
> > > > >>
> > > > >> Hoping we can get some more responses here.
> > > > >>
> > > > >> I've reviewed it myself, but would be great to have more people
> > > > >> reviewing the updates.
> > > > >>
> > > > >> WGLC ends in 2 days (the 15th).
> > > > >>
> > > > >> Thanks,
> > > > >> Stig
> > > > >>
> > > > >> On Tue, Nov 28, 2023 at 2:59 PM Stig Venaas <[e-mail]> wrote:
> > > > >>>
> > > > >>> Dear working group
> > > > >>>
> > > > >>> We have been working on progressing these core documents to Internet Standard.
> > > > >>>
> > > > >>> The documents are
> > > > >>>
> > > > >>> IANA Considerations for Internet Group Management Protocols
> > > > >>> https://datatracker.ietf.org/doc/draft-ietf-pim-3228bis/
> > > > >>>
> > > > >>> Internet Group Management Protocol, Version 3
> > > > >>> https://datatracker.ietf.org/doc/draft-ietf-pim-3376bis/
> > > > >>>
> > > > >>> Multicast Listener Discovery Version 2 (MLDv2) for IPv6
> > > > >>> https://datatracker.ietf.org/doc/draft-ietf-pim-3810bis/
> > > > >>>
> > > > >>> As these are important documents, I am hoping we will get some people
> > > > >>> to review these drafts and give us feedback. We did not get any
> > > > >>> responses to the previous wglc for these documents.
> > > > >>>
> > > > >>> Please respond by December 15th 2023 whether you believe these
> > > > >>> documents are ready for publication, and any comments or concerns you
> > > > >>> may have. Any input is helpful.
> > > > >>>
> > > > >>> Regards,
> > > > >>> Stig
> > > > >
> > > > > _______________________________________________
> > > > > MBONED mailing list
> > > > > [e-mail]
> > > > > https://www.ietf.org/mailman/listinfo/mboned
> > > >
> > >
> > > --
> > > ---
> > > [e-mail]
> >
>
> --
> ---
> [e-mail]