[pim] Re: IGMP v3 update - clarification about which router queries cause version fallback

Brian Haberman <brian@innovationslab.net> Fri, 16 August 2024 13:41 UTC

Return-Path: <brian@innovationslab.net>
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 668D7C14F682 for <pim@ietfa.amsl.com>; Fri, 16 Aug 2024 06:41:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.908
X-Spam-Level:
X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=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=innovationslab-net.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 ARQQhX2JCXn6 for <pim@ietfa.amsl.com>; Fri, 16 Aug 2024 06:41:00 -0700 (PDT)
Received: from mail-qv1-xf35.google.com (mail-qv1-xf35.google.com [IPv6:2607:f8b0:4864:20::f35]) (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 BB7F5C14F617 for <pim@ietf.org>; Fri, 16 Aug 2024 06:40:55 -0700 (PDT)
Received: by mail-qv1-xf35.google.com with SMTP id 6a1803df08f44-6bf75ed0e0eso8760176d6.1 for <pim@ietf.org>; Fri, 16 Aug 2024 06:40:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=innovationslab-net.20230601.gappssmtp.com; s=20230601; t=1723815654; x=1724420454; darn=ietf.org; h=in-reply-to:autocrypt:from:content-language:references:cc:to :subject:user-agent:mime-version:date:message-id:from:to:cc:subject :date:message-id:reply-to; bh=HlhggTY69T3EsKNKjaP7rT4NoXt4cB+QwS8GuTwXUzE=; b=DF1U6T36TB4Wd9EoxXnRt7NAMmcZcQ4nIyW3Y1YeKcJuFG2hfHp0qGADGJSsFtzq7+ u1JUWr/ro9rHG8Zn0blPr2HDCT0HdV1D/5H8t3gRnLEkAMzA88bLLtMZq1DVBYgvu1qX +KmPTAIR9YpyQ2ggrALoJ0lG49dwVpALyBtnLPgMiAWs62HWY6He9sjF9JhX/NyH9ART KLbLmcOMqU8qFnLVCCVkX+E6fDxWS+1JlN9AuzjDd1Trds9tHVIXORbog3otbkbsZXPa GJ72E1OSKGIDszgzimMI2YE6A68B7qjtPUfvZ0Jfq58Dpjni4JHopcX8iJBjIFMXn4kV 82Bg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1723815654; x=1724420454; h=in-reply-to:autocrypt:from:content-language:references:cc:to :subject:user-agent:mime-version:date:message-id:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=HlhggTY69T3EsKNKjaP7rT4NoXt4cB+QwS8GuTwXUzE=; b=e06ILHmjHLRVVppBN9cHOgW7mpb4QKCEoaJ79claug1z/u5WMmkZFMA7I+x2XAULka Z4h3zoPV9xcIK2fDIWhy4x9E7yplEbPkboty4Yrh6+67ALjTOlNiCI2Xvtk42LbH4LNT gwX/V2HSRhKaCxLD6IRgXyaoYdyX0zwSXm3TY5ete7LVt51PgwcwzDZT9tNCa8WSpxoC JmC7BqxjpWGR0TaS8qtn1WApPn/2sUP4aOg2BVLWQeLdVqVoke/EQVGKuI3/4lmqiVVi smbSPAsUee5vUTLplR9Lvin9HlSe+iE/g8+iIg/di9VT3GzK6NIE9jdevRlImvLrsN5c G1zA==
X-Forwarded-Encrypted: i=1; AJvYcCWw+vb2dnAS0AvwbPeQiGGMu8NAtDoYb7TZ01dDWVzxm8Bt1+dgD6WevzhSI+fNdDxHbnJzLXUoxSokujM=
X-Gm-Message-State: AOJu0YxHZDRgmG55e0lU8P4eM+vGvk3/qePVmgh7jZAsEUF9uYuor4Yp 4Wd4JD6RD7rbK1u8Pa6fT4YMXO1UVMpTZfPKLIJPVwaBwC3IiLWUtjFRzsEreHu7pZHKkIOCePL W
X-Google-Smtp-Source: AGHT+IFj0fmu4U1AxEpAkTAfxtNXu7Y8zNYy7qCRpUz5ZL6u7o9VBo7BH6YB0coxCqwkV0emH9TrTw==
X-Received: by 2002:a05:6214:2dc2:b0:6b5:ec9e:a80e with SMTP id 6a1803df08f44-6bf7ce41e16mr31447796d6.44.1723815654451; Fri, 16 Aug 2024 06:40:54 -0700 (PDT)
Received: from [192.168.1.23] ([172.59.112.90]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-6bf6fdde105sm17645006d6.9.2024.08.16.06.40.53 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 16 Aug 2024 06:40:54 -0700 (PDT)
Message-ID: <3db33494-b756-46b4-937d-bab213642207@innovationslab.net>
Date: Fri, 16 Aug 2024 09:40:52 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
To: Dino Farinacci <farinacci@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> <92E30006-1EFE-4060-A00D-DAB766BEEEED@gmail.com>
Content-Language: en-US
From: Brian Haberman <brian@innovationslab.net>
Autocrypt: addr=brian@innovationslab.net; keydata= xsFNBGFCWtIBEAC2FIgMIrH27l4L1Uu+vxCBakOv0Y1nxsu61+aulA78two2kCl7OCF+myP8 KQHEFMoZSn+ZvR+QDFyhsHe7qDK0CVf1K3n97PptXG5kvbnDJdwVJV0w9zYC17/VDgGAKLqj 0iNDVc9mYg/zCYdPn616UAj7hNpFgc9f982gLokyR/xbMNvtOwOpToysK+7Oc25oOam0xuUx CHcE4BfzJHO2VmUgWHeTvxervtIeMcn5PUlQ4XhzYH88mLlI1Uno7W5Dfx8FjXLNNAq4aNBM 6QND2LRekYi75pSTFXNpYIZvmgVT/VB6SHpsyJ3Hkio4YqGkPiqCEcB6U1lArT2FmXnzsTOt 6ydx6ONClxtcOmoEWrES+8tU+knaCEo1/XOrWtivTFMzn3Mahf726XxQBG55FkhqQ/Mir70e mTtpm8MDf+Qj4o5OsSF01l0MMxwOPiB57pz+XuUoWvLEjLgnb83eY0/YpBJdYESL3zZ3zMBo zA65cUozqSGHwQnlE1ACRDKhsReSYmiPJR5o3pWvNf5z+1M3tyn4qpuPxFFA1X8tEstpoC9t QoX8oextRj9BXlJCcCOwSVbCN8buO7aJMN3PIwSewjYvNLMxLrMph/8jNAHIaZnIt3CRHAq6 RsEAv8VQBWruIyNyyX0N8upnOpvriqx1eI2yS/B/Z2D8fQoFewARAQABzSlCcmlhbiBIYWJl cm1hbiA8YnJpYW5AaW5ub3ZhdGlvbnNsYWIubmV0PsLBlAQTAQgAPhYhBKm74/fFK6tXux1c k5E020tPLWqqBQJhQlrSAhsDBQkHhh8tBQsJCAcCBhUKCQgLAgQWAgMBAh4BAheAAAoJEJE0 20tPLWqq9fAP/1BO1H3SxphcXPbIsuJ+LoBCoKhrIftwGrLZzyiHYyLSFJ/HWLH2Kv79XJP4 6GkpTCk3VfJp6LEjw9FItwXUn0BEf0LyEy1L7w81YXPq+e4kwTPaQI8CgnbpSS9HBkcUj2r9 bwCjf+QZMqfgbz4d2MkVdVrIM2XPLYQND+Xtu1tyTTnrvFndLQFkDdqHAM9HqoikoNqWqz5j JPaxpJfxqmWr86vNThI7sD0rgMX5TWj7Flngzv2G9/uGEz4rHOIwK6KKiXNKk79kTqjUCQ9j tXl8BC2LQj8xsnWeGISTMR3xbiBPeTX94686O6KcLl7QIVKVS+nqs2l2j2gaXo1AjhBXO7gP GFN+rZzPOUZnPQUek3FeQoZCkfC/ljWBPooCpBe2euv5uZ4NbfKHAr9nmmhg4Uh1IceMxMQ/ /kB2wXTbuoprWLkK02r/y9LyGI5zLqLNl0NG17erJ0NCke76xYJkKBYezgBj1pZmYQDC1Sox fKlsaFCWkBrcKuGWc49qbEtWVM8h/mw+0w5pFyKX733xa6A+S8TOPYng/qFYgauotV9unjjt b7Npn7XyYzypk7QqKo4zipBqpHKeQ96Y/FKXSHPuTVj7dGK3Dn4b0q9Dgti7ogCc8F3tJcZI E0R8Q+4TRcQ192dLvyyTrv4h9BY6q5aB56Z6dsn11TAx7YCAzsFNBGFCWtIBEACqN6OFHSNq jiPy8s05QTC2fCqi0G5CcbRFXcqmHDEKdwqHk5VuOEL8CcWKNzOEMCt6EJvNL4ivfeHs1e7f rfm08+0Da0xAFiab92B9lOTLfv/NkKZ3jakQs06rtSzX7tYDbnmDeX206Uqff1mDjsiXHoAJ fdW7CjNLdWp42B3fkSjUR8mUgeNPqO4Jhgd7d3tTN2ov7M0rS7kUoE6Gd01LmNoPUQ024g8G ecMXVBldgg78aKmehs5pSWLmoBfczymGmNT/++9B6btmy7ruU+febVXRaQJY7aqpkTL7oy4H 3LMRSy/0BXHm1WgO7201Aj7PuaXM424hAhzmAJhO5AvlT9PuS9eSaIP0sqgP7ZTX7UezVj1H Tv5VJtgHI1fiNfhd/KFqDQDGaKdlM0iysyPanSCscjsWqAG0Od2TPdSuURqvgt8suBZrAAfK d55Ovguy+8uCi047sQxShUonw7TxGl3FMAe04PBIOgMCB/uys4yDUjYrawrlNigvx60Nec+T ExE+qszoO57If3/rG78J2ntGjog+yTDNffkbzljcy3YDe3k/r+T2FKOcWxJTlwSWAs1aVLZ7 DWx73lpYrSNJxiU7PrPihfS/Doy3VfmfF/RbH/xmkuPvsyrVfd16pEEtHGi5hBk2KQyjVqi1 IWwXV9ZVOQFBE9nJ7i6A7Aw3EwARAQABwsF8BBgBCAAmFiEEqbvj98Urq1e7HVyTkTTbS08t aqoFAmFCWtICGwwFCQeGHy0ACgkQkTTbS08taqrpIBAAjc6GdUjCyVsZLYwV8bMM4loltFrx z/mroCIFW4PZ0u4zENaloQbHuhDx7Ii6mR9jRiVNbXP4XvuyhjlUO+pt6hGrPbzsmV9vGvN0 2nkGYmSpxQNEzHQf/CJyLhPWY5qTJlDEr4zHbloG2KRPQ6dv9mdRIyAwDxNDSq2tVlrJC+b4 hG9vYp9msCZspqVDRTzvRTZQoWAvGJUaUgZd/FLPTfFePAmX+enXkUKl332i82xNU/nTix73 WajK7WhWC2GugrEbi42fJgUKRtYWhY36QyxucB1VWUacn7iKt/eLfPrCVVsHP2j4vqjlL/HJ 38TvbqfI4WbXyXF630U7IOlMT8//vpo3Y8hjWw0p5dm22fyPcjfnqxDdDefKCJpN215JgvDi Ww42J+VDTsd+5FJYCSUqg3jXmJl1z6FewF5hjuUGf/VdKCrhFocfh1b8VFgne2M1vyNcPoS8 23lJOMpcVAmzFhmVl5y/az/kgPJzbQggSByv3pZZUlJttLKf9BSGwmKcoGEgNo8p/DUyMkQV kVCJdmnamJzYEa/s3XRasTZhoWzNSjIEfeJaLd8dVXTzByMzgYuj/raFP1UF33GQ8W+zr23b VLVc8pEjMQlWeRGfJRyvG4ZOYpFk0c7jw8LpERCd/1SGHL3RQ3CwOqouQgKV+0BjMbY6A6Vj CuWio7k=
In-Reply-To: <92E30006-1EFE-4060-A00D-DAB766BEEEED@gmail.com>
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="------------7Df0MJ9iilmEjc7HRKfWB49e"
Message-ID-Hash: CSX42WPUXB5QNI46ZMWI6PZH5RXQ3QD2
X-Message-ID-Hash: CSX42WPUXB5QNI46ZMWI6PZH5RXQ3QD2
X-MailFrom: brian@innovationslab.net
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/5e3BrAXUWHgPK6ZIxhCFpl9s0Xo>
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>

So, I don't think we should drop "older" from the sentence. The 
paragraph immediately before that sentence says that Host Compatibility 
Mode changes based on receiving an even older version query or 
expiration of the timers.

Paragraph 3 of 7.2.1:
The Host Compatibility Mode of an interface changes whenever an older 
version query (than the current compatibility mode) is heard or when 
certain timer conditions occur. When the IGMPv1 Querier Present timer 
expires, a host switches to Host Compatibility mode of IGMPv2 if it has 
a running IGMPv2 Querier Present timer. If it does not have a running 
IGMPv2 Querier Present timer then it switches to Host Compatibility of 
IGMPv3. When the IGMPv2 Querier Present timer expires, a host switches 
to Host Compatibility mode of IGMPv3.

To me, that means the proposed edit is to make the following change in 
section 7.2.1

OLD:
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.

NEW:
The Host Compatibility Mode variable value MUST only be updated based on 
whether an older  General query was heard in the last Older Version 
Querier Present Timeout seconds.

Thoughts?

Brian

On 8/15/24 3:39 PM, Dino Farinacci wrote:
>> 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
>