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

[Toerless Eckert <[e-mail]>]

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