Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
From:   Paul Davey <paul.davey@alliedtelesis.co.nz>
To:     "David S. Miller" <davem@davemloft.net>
Cc:     netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
        Paul Davey <paul.davey@alliedtelesis.co.nz>
Subject: [PATCH net-next 0/2] Allow more than 255 IPv4 multicast interfaces
Date:   Wed,  2 Sep 2020 15:22:20 +1200
Message-Id: <20200902032222.25109-1-paul.davey@alliedtelesis.co.nz>
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

Currently it is not possible to use more than 255 multicast interfaces
for IPv4 due to the format of the igmpmsg header which only has 8 bits
available for the VIF ID.  There is enough space for the full VIF ID in
the Netlink cache notifications, however the value is currently taken
directly from the igmpmsg header and has thus already been truncated.

Using the full VIF ID in the Netlink notifications allows use of more
than 255 IPv4 multicast interfaces if the user space routing daemon
uses the Netlink notifications instead of the igmpmsg cache reports.

However doing this reveals a deficiency in the Netlink cache report
notifications, they lack any means for differentiating cache reports
relating to different multicast routing tables.  This is easily
resolved by adding the multicast route table ID to the cache reports.

Paul Davey (2):
  ipmr: Add route table ID to netlink cache reports
  ipmr: Use full VIF ID in netlink cache reports

 include/uapi/linux/mroute.h |  1 +
 net/ipv4/ipmr.c             | 12 +++++++-----
 2 files changed, 8 insertions(+), 5 deletions(-)

--=20
2.28.0