[pim] Re: IGMP v3 update - clarification about which router queries cause version fallback
Dino Farinacci <farinacci@gmail.com> Thu, 15 August 2024 19:39 UTC
Return-Path: <farinacci@gmail.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 110DDC165518 for <pim@ietfa.amsl.com>; Thu, 15 Aug 2024 12:39:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.108
X-Spam-Level:
X-Spam-Status: No, score=-2.108 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 nmAJPHOYT2nH for <pim@ietfa.amsl.com>; Thu, 15 Aug 2024 12:39:57 -0700 (PDT)
Received: from mail-pl1-x62d.google.com (mail-pl1-x62d.google.com [IPv6:2607:f8b0:4864:20::62d]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FD74C169506 for <pim@ietf.org>; Thu, 15 Aug 2024 12:39:57 -0700 (PDT)
Received: by mail-pl1-x62d.google.com with SMTP id d9443c01a7336-20202df1c2fso2459225ad.1 for <pim@ietf.org>; Thu, 15 Aug 2024 12:39:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1723750797; x=1724355597; darn=ietf.org; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=bOmswWQZEXwQDZo9CuMSpxOmxSAL8zHeeSTBRuCI9og=; b=DV0jwh/OhYunQXMo+bFrvP+FZ+lP1bke33744cP2cZPZMm5fWohrh4j5235NXMebo0 A/KynPtMYGTjCE4/i0AH8FGVEqznbZac14l+/PZZyrtqx0okZ7JzxAgP/G7dJdR2l5jj TaFcGSHxbZFzBze55shyhNUSMtYtfU25F9XhBBIN9Tdynd+FwhHVFKC8bldclD36b2Ov VIdPFMltsS4MbbaagKlc36keus+m0lfewvHtAO0jpT+g30ig3oqWykzitjw8NV0JSB+5 /3DlkqwvMOc5T5ggvSnqksaxswAJynr/YWn6bzmUzgVWLw6LbXCxVedQMRNBAaWS4Xsc B5Ng==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1723750797; x=1724355597; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=bOmswWQZEXwQDZo9CuMSpxOmxSAL8zHeeSTBRuCI9og=; b=Zcc8KQ0W7CrRgkMvm9fBmmzPDpW6ZRG3kBUt+W4O7ZalEhaHfYy2QXks1eDfcQMJxn c+XJkbkJ6pGoZbTwpGTf02ZrLs/gkTfUQMHgLOPd0ZaY82YO23z8o5U5uuj94keX6ctp uaCd3KiawRCHv8PQCe6Uj5hW/wBtTF86CtzTfxya+9YtM8q2N0uLr9U/H+1nxNexA7gG l9su6QmMJvxZ5wQk0GMC7YSHXVol4Isry+QppW1Dr0/eM2kPbnK5pOOWMk2j4HiiR2mS EiuCm8KnqploMs/hyOFvBG78fndXypa6agMcH+YQMlShYeB4B7K8MeVmO0yIyxir4v8L 39hg==
X-Forwarded-Encrypted: i=1; AJvYcCXPVotVKMx+1oOAKOvdY1VK2wbwPp/q4sOpXxBXpOfbjdeOeTVICUmjPhSzDYlMgmpfEn/R0G8R7NmusSw=
X-Gm-Message-State: AOJu0YzetFWXW7m2E2KdBwIVS+LNaGkNUGiByWKgITKGd/obq8Hg0IDi R0iY8XzZc6+ZP9qQnxrrXt/8HxKIaSaqeDLxkxZh0uM6j6TMK7hX
X-Google-Smtp-Source: AGHT+IGJbkQEkt0qhqzn5sF2zc7lHpA0uHpyr7T0PaMO9NMI91lOzqTjJz9/tV+8CsVp6VFav8gj/Q==
X-Received: by 2002:a17:903:35c4:b0:201:eb46:1be5 with SMTP id d9443c01a7336-20206162588mr4670265ad.3.1723750796707; Thu, 15 Aug 2024 12:39:56 -0700 (PDT)
Received: from smtpclient.apple (c-24-5-184-219.hsd1.ca.comcast.net. [24.5.184.219]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-201f038dfa0sm13505685ad.197.2024.08.15.12.39.56 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 15 Aug 2024 12:39:56 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.600.62\))
From: Dino Farinacci <farinacci@gmail.com>
In-Reply-To: <3aae3037-7f75-4e1b-9d44-f664e752a7a2@innovationslab.net>
Date: Thu, 15 Aug 2024 12:39:45 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <92E30006-1EFE-4060-A00D-DAB766BEEEED@gmail.com>
References: <9a4ab4e0-a5aa-4c9b-bf02-01fd070858a8@ka9q.net> <13f97817-2506-4ace-a44d-a7f8a8525c96@innovationslab.net> <D2183B0A-209E-40A6-AC3F-553D122AAF01@ka9q.net> <C61FF107-AD97-471E-AA2E-B6B570FC4E71@gmail.com> <3aae3037-7f75-4e1b-9d44-f664e752a7a2@innovationslab.net>
To: Brian Haberman <brian@innovationslab.net>
X-Mailer: Apple Mail (2.3774.600.62)
Message-ID-Hash: 5AFVAHGQMAHBGKIWWOE34234IQZK2BDY
X-Message-ID-Hash: 5AFVAHGQMAHBGKIWWOE34234IQZK2BDY
X-MailFrom: farinacci@gmail.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-pim.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: Phil Karn <karn@ka9q.net>, pim@ietf.org
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [pim] Re: IGMP v3 update - clarification about which router queries cause version fallback
List-Id: Protocol Independent Multicast <pim.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/pim/quIInR7n3sYRIHjkR2YJ_qQaSME>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pim>
List-Help: <mailto:pim-request@ietf.org?subject=help>
List-Owner: <mailto:pim-owner@ietf.org>
List-Post: <mailto:pim@ietf.org>
List-Subscribe: <mailto:pim-join@ietf.org>
List-Unsubscribe: <mailto:pim-leave@ietf.org>
> Hey Dino! Hi! > We have a slim window to get something into 3376bis *if* we can clearly articulate that it is a clarification (the IESG approved 3376bis last week). Well if its a bug, you DO NOT let the process stop you. Its important to fix. Taking a network down due to this issue is a showstopper bug. Now, Phil, you got to get Apple to fix this. Stuart Cheshire may be able to help. > So, section 7.2.1 says: > > The Host Compatibility Mode variable is based on whether an older version General query was heard in the last Older Version Querier Present Timeout seconds. I wouldn't say "older" actually. If you "hear any different version than you did last time", then the new query version is what runs on the LAN. Because if IGMPv3 leaves the LAN, the LAN should operate in IGMPv2. > AND > > If a host receives a query which causes its Querier Present timers to be updated and correspondingly its compatibility mode, it should switch compatibility modes immediately. Right. > I think a simple approach is to change the first sentence to use a MUST for changing mode based on a General query. So, something like: > > The Host Compatibility Mode variable value MUST only be updated based on whether an older version General query was heard... Agree: The Host Compatibility Mode variable value MUST only be updated based on whether a different version General query was heard, from the last one received, ... Dino > > Thoughts? > > Brian > > On 8/15/24 2:41 PM, Dino Farinacci wrote: >> Brian, this is a protocol design bug if this behavior was intended. Otherwise the RFC needs updating for clarity. >> In either case, the RFC text MUST BE fixed. >> Dino >>> On Aug 14, 2024, at 9:41 PM, Phil Karn <karn@ka9q.net> wrote: >>> >>> I understand that part. My point was that Linux appears to reset the interface compatibility mode timer for IGMPv2 in response to a *group specific* membership query. My reading of the RFC is that this should be done only for *general* membership queries (no specific group). Even worse, MacOS stops responding entirely to IGMPv3 queries. >>> >>> As things stand now, if you have an iPhone on your LAN, IGMPv3 is unusable for everybody.. If you have a MacOS system on your LAN and the querier is IGMPv3, multicast will be broken for you. Permanently. Is that the intent of the RFC? >>> >>> if you see a group-specific query and you’re a member of that group (otherwise you probably wouldn’t see the query!) you should answer with the version used for that query, but reset the compatibility mode timer to IGMPv2 only if the next *general* query uses IGMPv2. >>> >>>> On Aug 14, 2024, at 13:35, Brian Haberman <brian@innovationslab.net> wrote: >>>> >>>> Hi Phi, >>>> 3376 and 3376bis are pretty clear on this from my perspective. Section 7.2.1 says: >>>> >>>> In order to be compatible with older version routers, IGMPv3 hosts MUST operate in version 1 and version 2 compatibility modes. IGMPv3 hosts MUST keep state per local interface regarding the compatibility mode of each attached network. A host's compatibility mode is determined from the Host Compatibility Mode variable which can be in one of three states: IGMPv1, IGMPv2 or IGMPv3. This variable is kept per interface and is dependent on the version of General Queries heard on that interface as well as the Older Version Querier Present timers for the interface. >>>> >>>> Regards, >>>> Brian >>>> >>>> On 7/30/24 12:54 AM, Phil Karn wrote: >>>>> Hi. I'm been trying to figure out why Linux on my network keeps falling back to IGMPv2, and I've found out why. I may need a clarification to RFC3376. >>>>> At first, all works fine. My snooping switch issues an IGMPv3 general membership query and my Linux system answers with IGMPv3 membership messages. Great. >>>>> Then my Linux system sees a IGMPv2 group-specific query for 224.0.0.251 (the multicast DNS group). Since I'm running avahi-daemon (the mDNS service daemon) this elicits an outgoing IGMPv2 membership report for 224.0.0.251. Then subsequent IGMPv3 general membership queries elicits IGMPv2 (not v3) membership reports for all my other multicast group memberships. >>>>> I believe this is a bug in Linux, but I want to make sure RFC3376 says what I think it says. >>>>> RFC3376 says an IGMPv2 general query should change the interface version to IGMPv2 and start the IGMPv2 querier-present timer, after which the interface reverts to v3 if enough time goes by without another IGMPv2 general query. But it does not explicitly say that ONLY a IGMPv2 GENERAL query should do this -- that a group-specific IGMPv2 query should NOT cause the interface to drop into IGMPv2 mode even if we're a member of that group. >>>>> The problem is that buggy Apple devices frequently and gratuitously join and leave 224.0.0.251, and these devices don't speak IGMPv3. Whenever one leaves, the querier correctly issues a group-specific query to see if any other members are left -- and this group-specific query knocks Linux back to IGMPv2. Since these Apple devices gratuitously join and leave more rapidly than the IGMPv2-querier-present timer expires, the situation persists. IGMPv3 becomes unusable on my network. >>>>> So is it the intent of RFC3376 that ONLY a *general* IGMPv2/v1 query should trigger the version fallback logic, or should a group-specific IGMPv2 query do the same? >>>>> To summarize: >>>>> 1. RFC 3376 is arguably vague about exactly which membership queries should invoke a version fallback. All IGMPv2/v1 queries, or only general ones? >>>>> 2. Linux interprets any IGMPv2 membership query - not just a general query - as triggering a fallback. Right now I don't know if this is correct behavior or an honest misunderstanding of a vague specification. >>>>> 3. Apple really should get with the program and implement IGMPv3. It's only what, 22 years old? >>>>> 4. Apple really should get with the program and stop explicitly joining a very popular link-local multicast address (224.0.0.251) that every host is supposed to be an implicit member of anyway. >>>>> 5. Apple really should get with the program and stop gratuitously leaving and re-joining said link-local multicast group. >>>>> But I'm only asking this list to address point #1. Should group-specific IGMPv2 membership queries trigger a version fallback until the IGMPv2 Querier Present timer expires? Or should only general queries do so? >>>>> --Phil >>>>> _______________________________________________ >>>>> pim mailing list -- pim@ietf.org >>>>> To unsubscribe send an email to pim-leave@ietf.org >>>> _______________________________________________ >>>> pim mailing list -- pim@ietf.org >>>> To unsubscribe send an email to pim-leave@ietf.org >>> >>> _______________________________________________ >>> pim mailing list -- pim@ietf.org >>> To unsubscribe send an email to pim-leave@ietf.org
- [pim] IGMP v3 update - clarification about which … Phil Karn
- [pim] Re: IGMP v3 update - clarification about wh… Brian Haberman
- [pim] Re: IGMP v3 update - clarification about wh… Phil Karn
- [pim] Re: IGMP v3 update - clarification about wh… Brian Haberman
- [pim] Re: IGMP v3 update - clarification about wh… Dino Farinacci
- [pim] Re: IGMP v3 update - clarification about wh… Brian Haberman
- [pim] Re: IGMP v3 update - clarification about wh… Dino Farinacci
- [pim] Re: IGMP v3 update - clarification about wh… Brian Haberman
- [pim] Re: IGMP v3 update - clarification about wh… Phil Karn
- [pim] Re: IGMP v3 update - clarification about wh… Brian Haberman
- [pim] Re: IGMP v3 update - clarification about wh… Dino Farinacci
- [pim] Re: IGMP v3 update - clarification about wh… Phil Karn
- [pim] Re: IGMP v3 update - clarification about wh… Phil Karn
- [pim] Re: IGMP v3 update - clarification about wh… Gyan Mishra
- [pim] Re: IGMP v3 update - clarification about wh… Brian Haberman
- [pim] Re: IGMP v3 update - clarification about wh… Brian Haberman
- [pim] Re: IGMP v3 update - clarification about wh… Brian Haberman
- [pim] Re: IGMP v3 update - clarification about wh… Brian Haberman
- [pim] Re: IGMP v3 update - clarification about wh… Gyan Mishra