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

[[e-mail]]

Hi Toerless,

Thanks for bringing this up (see inline).

> -----Ursprüngliche Nachricht-----
> Von: Toerless Eckert <[e-mail]> 
> Gesendet: Donnerstag, 14. Dezember 2023 22:30
> An: Stig Venaas <[e-mail]>; [e-mail]; [e-mail]; Leymann, Nicolai 
> <[e-mail]>; [e-mail]; [e-mail]; [e-mail]
> Betreff: IGMPv3 backward compatibility issue killing SSM (was: Re: [pim] pim wglc for 3228bis, 3376bis and 3810bis)
> 
> 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.
Yes. That was one of the major issues we encountered during our IPTV deployment. Home networks are out
of our control and unfortunately there are many devices not supporting IGMPv3. As soon as you have an
older IGMP version active in the home network this will usually cause trouble with SSM making end-to-end
SSM deployments extremely difficult. For that reason we decided to add SSM mapping at the network edges
and to run the IPTV application with ASM only. From operational perspective not the best solution (e.g. you
need a process to change the SSM mapping in case of changes in the IPTV streams).

> 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.
I think it's even against the standard which requires a fallback from IGMPv3 towards IGMPv1/IGMPv2. This was
one of the option we discussed  (to force the home gateway to stay with IGMPv3 even in the presence of other 
IGMP versions) but the outcome was that the standard requires a fallback towards IGMPv1/v2 and that
Implementing such a behavior would be against RFC3376.

> 
> 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.
I have not seen that possibility (but might be possible with some kind of ACL/filters). 

> 
> 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.
>
I think that’s a good summary of the current situation also describing the problems with e2e SSM deployments.
 
> 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.
>  
It might make sense to differentiate a bit between home networks and ISP networks. For
typical ISP/Provider equipment I agree (IGMPv3 support is widely available) but for home
network equipment I think the situation is different. Snooping is not always available and
in many cases it's (partly) implemented for IGMPv1/v2.
 
> 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.
> 
I am fine with the proposed way forward. I think every change which makes SSM e2e deployment
easier/possible is a step into the right direction.

Regards

Nic

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