lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Message-Id: <20190121062628.2710-1-linus.luessing@c0d3.blue> Date: Mon, 21 Jan 2019 07:26:24 +0100 From: Linus Lüssing <linus.luessing@...3.blue> To: netdev@...r.kernel.org Cc: Roopa Prabhu <roopa@...ulusnetworks.com>, Nikolay Aleksandrov <nikolay@...ulusnetworks.com>, Alexey Kuznetsov <kuznet@....inr.ac.ru>, Hideaki YOSHIFUJI <yoshfuji@...ux-ipv6.org>, "David S . Miller" <davem@...emloft.net>, bridge@...ts.linux-foundation.org, linux-kernel@...r.kernel.org Subject: [PATCH net-next v2 0/4] bridge: implement Multicast Router Discovery (RFC4286) Hi, This patchset adds initial Multicast Router Discovery support to the Linux bridge (RFC4286). With MRD it is possible to detect multicast routers and mark bridge ports and forward multicast packets to such routers accordingly. So far, multicast routers are detected via IGMP/MLD queries and PIM messages in the Linux bridge. As there is only one active, selected querier at a time RFC4541 ("Considerations for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Snooping Switches") section 2.1.1.a) recommends snooping Multicast Router Advertisements as provided by MRD (RFC4286). The first two patches are refactoring some existing code which is reused for parsing the Multicast Router Advertisements later in the fourth patch. The third patch lets the bridge join the all-snoopers multicast address to be able to reliably receive the Multicast Router Advertisements. What is not implemented yet from RFC4286 yet: * Sending Multicast Router Solicitations: -> RFC4286: "[...] may be sent when [...] an interface is (re-)initialized [or] MRD is enabled" * Snooping Multicast Router Terminations: -> currently this only relies on our own timeouts * Adjusting timeouts with the values provided in the announcements Regards, Linus --- Changes in v2: * rebased to current net-next/master (no conflicts/changes)
Powered by blists - more mailing lists