Re: [pim] [MBONED] IGMPv3 backward compatibility issue killing SSM (was: Re: pim wglc for 3228bis, 3376bis and 3810bis)
Stig Venaas <stig@venaas.com> Wed, 20 December 2023 19:23 UTC
Return-Path: <stig@venaas.com>
X-Original-To: pim@ietfa.amsl.com
Delivered-To: pim@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1C60C14CE4D for <pim@ietfa.amsl.com>; Wed, 20 Dec 2023 11:23:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.905
X-Spam-Level:
X-Spam-Status: No, score=-6.905 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=venaas-com.20230601.gappssmtp.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xZZZLfyLssvp for <pim@ietfa.amsl.com>; Wed, 20 Dec 2023 11:23:38 -0800 (PST)
Received: from mail-ed1-x52b.google.com (mail-ed1-x52b.google.com [IPv6:2a00:1450:4864:20::52b]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29DACC14F61A for <pim@ietf.org>; Wed, 20 Dec 2023 11:23:38 -0800 (PST)
Received: by mail-ed1-x52b.google.com with SMTP id 4fb4d7f45d1cf-55114c073b8so23638a12.1 for <pim@ietf.org>; Wed, 20 Dec 2023 11:23:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=venaas-com.20230601.gappssmtp.com; s=20230601; t=1703100216; x=1703705016; darn=ietf.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=7yxeWIwHHXdbCmVddLKJcGAffqXs3dNV30w2jQwYc/A=; b=WmsidtYrwNmpcyx86EGABfVJzbe2gqXVEJ4PYTHzTGz0gD6ug69CwgcNgq19pgybvO AZAq4sLiMo/izC6Nq6+fnSqfISoK6O9xqWXAeW0UN94KGxnIhtEq/exq2yBzfrmeXORY vtvQM7/AbFbUheTXn1Ttc40tZw59q767fusFQ/8wnaNt+5BlAZof3tbA9thC9k2l44/l bo53j1L6Nuci/ChFjFvmK1M+crv0KRQ8oizCg2le+Zxm5qzozXbslX0CQEubuVKpvAU4 6U1fYwujK2VeUite/vBVvPl0uXFmuZlVTZCwwFZLggVGiCkVxsdxal2xDJ1bLUVZbM/x 8C7A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1703100216; x=1703705016; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=7yxeWIwHHXdbCmVddLKJcGAffqXs3dNV30w2jQwYc/A=; b=Gnu4NJ2EUiwPXUl0v/7cCH1iB445Pe9w6rHYLD2K2GnAOerMJTsS5nAvgKvDfbIVdL o3RPVka+MCNCHKYtUH0ECF+7CA37KYghoLpKGICHpW3byPQTO7U/cwcccMU5Dcl1BMQU NYyBg7WPG+Wtv1++eIUlX8IoCZfiUEMyIstcX5OJZ/iB1sa3w+AX1lwzs4an42AcDi/w jGqbxSk3MDwnQKQlBrHUe3+pc6+FhoTwZUnoBv0GXC5Jhkj6GEeBqfVBRcKsZbAFNFbP UlfVXdmZV9rWRQv2mie7kZtT4bnptUpsSvK93oLVIHcuJ8vMzE1PW6MjKAc7dUdRXEGW swoQ==
X-Gm-Message-State: AOJu0YygFDCIxA5sIWd2aeUMctYMUOYVWeTqKEGFKauSWAC0v2258tzX uPicKR+UeUMwhiSu4qSsMoFP2jTNYYirFbLzkwODyA==
X-Google-Smtp-Source: AGHT+IGZGRquK1kB45kbCQFenvmbBYbFxqF3BuriLU1UIchcFbI59zjKiDDIeq9Ct67M4oGBxrspN1N/gzOBJtGXLno=
X-Received: by 2002:a17:907:918a:b0:a23:573e:a80 with SMTP id bp10-20020a170907918a00b00a23573e0a80mr1823159ejb.230.1703100216059; Wed, 20 Dec 2023 11:23:36 -0800 (PST)
MIME-Version: 1.0
References: <CAHANBtKf03ukXH4sgwN0WVdkaVXnbRYdAGBDmQK56YXrS-z6yA@mail.gmail.com> <CAHANBtKdfS0cPceqv8_R+ToeGOBdUksH7gArKqegqSt_Q0Sf0Q@mail.gmail.com> <ZXtzwBljE45Og27f@faui48e.informatik.uni-erlangen.de> <D07DCE90-5B42-4C8F-AD3C-8E9064D9A284@ieee.org> <ZYMWrJydaQ2GiOd8@faui48e.informatik.uni-erlangen.de>
In-Reply-To: <ZYMWrJydaQ2GiOd8@faui48e.informatik.uni-erlangen.de>
From: Stig Venaas <stig@venaas.com>
Date: Wed, 20 Dec 2023 11:23:25 -0800
Message-ID: <CAHANBtJYkxxDjH5+O-eFFEFT3s9W1Cds2mw+9744unzPyc1YHw@mail.gmail.com>
To: Toerless Eckert <tte@cs.fau.de>
Cc: Hitoshi Asaeda <asaeda@ieee.org>, zzhang@juniper.net, brian@innovationslab.net, n.leymann@telekom.de, pim@ietf.org, mboned@ietf.org, fenner@fenron.com
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/pim/DIiwu3UKNhx0Q1nNcZPY7qnuPuU>
Subject: Re: [pim] [MBONED] IGMPv3 backward compatibility issue killing SSM (was: Re: pim wglc for 3228bis, 3376bis and 3810bis)
X-BeenThere: pim@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Protocol Independent Multicast <pim.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pim>, <mailto:pim-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pim/>
List-Post: <mailto:pim@ietf.org>
List-Help: <mailto:pim-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pim>, <mailto:pim-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 20 Dec 2023 19:23:42 -0000
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. 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. 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. It's not like the host or application can fall back to ASM. Regards, Stig On Wed, Dec 20, 2023 at 8:30 AM Toerless Eckert <tte@cs.fau.de> 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 <tte@cs.fau.de> 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 <stig@venaas.com> 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 > > > MBONED@ietf.org > > > https://www.ietf.org/mailman/listinfo/mboned > > > > -- > --- > tte@cs.fau.de
- [pim] pim wglc for 3228bis, 3376bis and 3810bis Stig Venaas
- Re: [pim] pim wglc for 3228bis, 3376bis and 3810b… Stig Venaas
- Re: [pim] pim wglc for 3228bis, 3376bis and 3810b… Jeffrey (Zhaohui) Zhang
- Re: [pim] pim wglc for 3228bis, 3376bis and 3810b… Toerless Eckert
- Re: [pim] [MBONED] IGMPv3 backward compatibility … Hitoshi Asaeda
- Re: [pim] IGMPv3 backward compatibility issue kil… Holland, Jake
- Re: [pim] WGLC feedback for draft-ietf-pim-3376bi… Toerless Eckert
- Re: [pim] IGMPv3 backward compatibility issue kil… Toerless Eckert
- Re: [pim] [MBONED] IGMPv3 backward compatibility … Toerless Eckert
- Re: [pim] [MBONED] IGMPv3 backward compatibility … Toerless Eckert
- [pim] WGLC feedback for draft-ietf-pim-3376bis (w… Toerless Eckert
- Re: [pim] [MBONED] IGMPv3 backward compatibility … Stig Venaas
- [pim] IGMPv3 backward compatibility issue killing… Toerless Eckert
- Re: [pim] [MBONED] IGMPv3 backward compatibility … Leonard Giuliano
- Re: [pim] pim wglc for 3228bis, 3376bis and 3810b… Brian Haberman
- Re: [pim] pim wglc for 3228bis, 3376bis and 3810b… Stig Venaas
- Re: [pim] WGLC feedback for draft-ietf-pim-3376bi… Toerless Eckert
- Re: [pim] WGLC feedback for draft-ietf-pim-3376bis Brian Haberman
- Re: [pim] [MBONED] IGMPv3 backward compatibility … Stig Venaas
- Re: [pim] [MBONED] IGMPv3 backward compatibility … Dave Katz
- Re: [pim] [MBONED] IGMPv3 backward compatibility … Hitoshi Asaeda
- Re: [pim] [MBONED] IGMPv3 backward compatibility … Dave Katz
- Re: [pim] IGMPv3 backward compatibility issue kil… N.Leymann
- Re: [pim] [MBONED] IGMPv3 backward compatibility … Brian Haberman
- Re: [pim] [MBONED] IGMPv3 backward compatibility … Stig Venaas
- Re: [pim] [MBONED] IGMPv3 backward compatibility … Brian Haberman
- Re: [pim] [MBONED] IGMPv3 backward compatibility … Hitoshi Asaeda
- Re: [pim] [MBONED] IGMPv3 backward compatibility … Stig Venaas
- Re: [pim] [MBONED] IGMPv3 backward compatibility … Hitoshi Asaeda
- Re: [pim] [MBONED] IGMPv3 backward compatibility … Brian Haberman
- Re: [pim] [MBONED] IGMPv3 backward compatibility … N.Leymann
- Re: [pim] [MBONED] IGMPv3 backward compatibility … Stig Venaas
- Re: [pim] [MBONED] IGMPv3 backward compatibility … Brian Haberman
- Re: [pim] [MBONED] IGMPv3 backward compatibility … Leonard Giuliano
- Re: [pim] [MBONED] IGMPv3 backward compatibility … Stig Venaas
- Re: [pim] [MBONED] IGMPv3 backward compatibility … Stig Venaas
- Re: [pim] [MBONED] IGMPv3 backward compatibility … Hitoshi Asaeda
- Re: [pim] [MBONED] IGMPv3 backward compatibility … Brian Haberman
- Re: [pim] [MBONED] IGMPv3 backward compatibility … Stig Venaas
- Re: [pim] [MBONED] IGMPv3 backward compatibility … Brian Haberman
- Re: [pim] [MBONED] IGMPv3 backward compatibility … Stig Venaas
- Re: [pim] [MBONED] IGMPv3 backward compatibility … Hitoshi Asaeda
- Re: [pim] [MBONED] IGMPv3 backward compatibility … N.Leymann
- Re: [pim] [MBONED] IGMPv3 backward compatibility … Leonard Giuliano
- Re: [pim] [MBONED] IGMPv3 backward compatibility … Hitoshi Asaeda