Re: [Mcast-wifi] [pim] Volunteers needed for work on progressing IGMP/MLD on the standards track

Linus Lüssing <linus.luessing@c0d3.blue> Thu, 13 December 2018 14:32 UTC

Return-Path: <linus.luessing@c0d3.blue>
X-Original-To: mcast-wifi@ietfa.amsl.com
Delivered-To: mcast-wifi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D892F130DF0; Thu, 13 Dec 2018 06:32:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4
X-Spam-Level:
X-Spam-Status: No, score=-4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=c0d3.blue
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i0RJW9gcHhPa; Thu, 13 Dec 2018 06:32:37 -0800 (PST)
Received: from mail.aperture-lab.de (mail.aperture-lab.de [IPv6:2a01:4f8:171:314c::100:a1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0AED112DDA3; Thu, 13 Dec 2018 06:32:36 -0800 (PST)
Date: Thu, 13 Dec 2018 15:32:29 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=c0d3.blue; s=2018; t=1544711554; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=mvRoBh63WB5zwAN0xu8S0j+cRf5ScQcDpc5LdUPEzIo=; b=cohL3A3ueUcierQuZPRT8Qa3izn67LguOQBPVUiKRNCiUnlObG8v9zJ6abAavdpbVEhpHJ Dkj28nn/mTJtnqE2+470wnaGsJZ2fPaEGI8PIm0k5+51ObZk/W2M76DSuJv//erGYJvXm6 cyNDLfZRpQdrZ6fdzoXu1JUnSl7VoBefPoncxv9kvnagb7m0Qh8iJ8FMzQZsqq1+ZE8XEL w14PmqR1KcMerJ1drJtWZ3l8JlsdagWm1bfcd+wsVjvWJXJc83wbU6GflV9443RYi02FW6 +EGrWkbQc4ASn9S+lI8SdmfmFJBkPy0lH3IVF3D549jG28BkBSjhzhjIcMpKIg==
From: Linus Lüssing <linus.luessing@c0d3.blue>
To: Stig Venaas <stig@venaas.com>
Cc: pim@ietf.org, mcast-wifi@ietf.org
Message-ID: <20181213143229.GA1713@otheros>
References: <CAHANBt+AJLxCpzWgF_x0UQAp_1BWMewPjkN_u51xzMPP8WA2oA@mail.gmail.com> <20181212071343.GC9328@otheros>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <20181212071343.GC9328@otheros>
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=c0d3.blue; s=2018; t=1544711554; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=mvRoBh63WB5zwAN0xu8S0j+cRf5ScQcDpc5LdUPEzIo=; b=JeS8zOFuSnbAN2Vsrnu3w7QqmRB/2mUZ3lc6NkuxWMOwNXiWT1rsB0U9NZxN6vlw7HLQuX 5+X0gEE8pb99yQjIxLYwzBSmzpK74kf7tmbeb2wqYwsERorOogWABb+j1OrXFTRhCZRgWW FRcGW0ltxp1j0+3tyPv7QJNoBzos4HdwA16K33co2DjuV18Xl4gfBQIfeTL5+VyxHkBMH2 ZICaB68fKdXnXudU4BCl+wj/yvILyMmiS54zVTj70z4VWHcEOhbIrUwrexa+lczj6xtDIB Y3UmpDqLcqm38OSuxsqE0/iDnYdtSJGKoMLPltSUDEvzFYp7a7fAHnrLxuTsLg==
ARC-Seal: i=1; s=2018; d=c0d3.blue; t=1544711554; a=rsa-sha256; cv=none; b=j6vWLI7s00Ib8No7L+9jACvyUwMjqyv2XFH9TiC+2379RMi881zlAgQkHB/tKZ/Zd5eYLu unuTkj9cb9rt8nevYwtAUa/A4fTaJdXIPOJE+el93l0iUtC8X80rWtQ+S8U1N3sq5kC7Ou 5arrR81qX0NAcEHuN2rzAoByE5UQka5btRDPjbizkcdWSpo+0Ntb7HrrQFj8fDERjSXnY9 YbosTOQzY9whGCuyUUXGxc6B0Gin7A7V1tG0INQo8mRtFTMVTxkwRIeG/t5YX2PxqYzZHv TQgKUchZAHN0UHUYm1R4fcXEtQZtnxwXDLTDE1ZLyEOpcn0ttBJenmloL+Boww==
ARC-Authentication-Results: i=1; ORIGINATING; auth=pass smtp.auth=linus.luessing@c0d3.blue smtp.mailfrom=linus.luessing@c0d3.blue
Authentication-Results: ORIGINATING; auth=pass smtp.auth=linus.luessing@c0d3.blue smtp.mailfrom=linus.luessing@c0d3.blue
Archived-At: <https://mailarchive.ietf.org/arch/msg/mcast-wifi/nlhJ16nWxPzdI3ZEVn5oTehDriU>
Subject: Re: [Mcast-wifi] [pim] Volunteers needed for work on progressing IGMP/MLD on the standards track
X-BeenThere: mcast-wifi@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discussions related to issues with multicast in 802.11 Wi-Fi networks & solutions/optimizations targeted at resolving these issues." <mcast-wifi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mcast-wifi>, <mailto:mcast-wifi-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mcast-wifi/>
List-Post: <mailto:mcast-wifi@ietf.org>
List-Help: <mailto:mcast-wifi-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mcast-wifi>, <mailto:mcast-wifi-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 13 Dec 2018 14:32:48 -0000

And a five more inconveniences that came to my mind:


# IGMP Query 0.0.0.0 source address

As snooping switches have an interest in learning about multicast
listeneres, they often implement the querier protocol. However,
they might not implement DHCP for instance, leaving them with no
assigned IPv4 address to use for IGMP queries.

In that case, such snooping switches will usually use the 0.0.0.0
source address.

The issue with that however is that according to IGMP they would
always win the querier election as it is the lowest address
possible.

This is undesirable due to the following two reasons: For one
thing a snooping switch might not always be in a favorable
position topology wise. A real multicast router for instance is
probably in a better spot but would always loose the election. For
another, when multiple such snooping switches use the 0.0.0.0
address then this creates quite some turbulences: The selected
querier will change frequently.

If I remember correctly, there was some debate on the Linux bridge
mailinglist in the past regarding how to treat an IGMP query with
a zero-source address.

For reports, there is a nice section regarding the source address
(RFC3376, section 4.2.13. "IP Source Addresses for Reports").
However there is no equivilant for that for queries.

Ideally, 0.0.0.0 would be excluded and ignored from the querier
election mechanism, I think.


# MLD Query :: source address

RFC4541, section 3 ("IPv6 considerations") says:

"[...] the switch should use the null IP source address (::) when
sending said queries"

While RFC3810, section 5.1.14 ("Source Addresses for Queries") says:

"All MLDv2 Queries MUST be sent with a valid IPv6 link-local
 source address. If a node (router or host) receives a Query
 message with the IPv6 Source Address set to the unspecified address (::), or
 any other address that is not a valid IPv6 link-local address,
 it MUST silently discard the message and SHOULD log a warning."

Currently, the Linux bridge for instance adhears to the latter, ignoring
all MLD queries with a :: source address.


# Query type for Querier Election

RFC3376, 6.6.2. Querier Election:

"When a router receives a query with a lower IP address, it sets the
 Other-Querier-Present timer to Other Querier Present Interval and ceases
 to send queries on the network if it was the previously elected
 querier."

The "receives a query" should probably be a "receives a general
query". Similarly for MLDv2 (RFC3810, section 7.6.2).

At least that's what the Linux bridge currently does. It only
processes general queries for the querier election and for
multicast router port additions.


# IPv6 link-local multicast to multicast routers

Currently it seems slightly unclear whether data with an IPv6
link-local destination needs to be forwarded to multicast routers.

Ideally, this would not be necessary as link-local multicast by
definition will not be routed. This would potentially save quite
some traffic as in a large broadcast domain there are quite a few
such messages for IPv6 Neighbor Discovery, for instance.

However, this is probably, unfortunately not do-able right now.
At least when  there are IGMPv1/2 / MLDv1 hosts present. Due to
the report suppression link-local multicast will need to be
forwarded to the selected querier / some common host which
received all reports, to avoid snooping switches introducing
multicast packet loss.

RFC4541 does not seem to make any special recommendations
regarding IPv6 link-local multicast.

.o(One thought that crossed my mind was, whether it might make sense
to add a flag to Multicast Router Advertisements which if set
explicitly indicates that the according router is not interested
link-local multicast.)


# Querier => Multicast Router implication?

Ideally, RFC4286 ("Multicast Router Discovery") would become the
sole source to detect multicast routers. And RFC4541 would not
(need to) recommend to add queriers to the multicast router list
anymore. Especially as snooping switches often implement IGMP/MLD
querying, too, this is a little inconvenient.

However, since RFC4286 is neither mandatory nor widely
implemented and the report suppression issue still present this
too is probably, unfortunately more a wish-list item for the
distant future.


Regards, Linus