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

[Hitoshi Asaeda <[e-mail]>]

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