From patchwork Wed Apr 24 01:19:13 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: =?utf-8?q?Linus_L=C3=BCssing?= X-Patchwork-Id: 17889 Return-Path: X-Original-To: patchwork@open-mesh.org Delivered-To: patchwork@open-mesh.org Received: from open-mesh.org (localhost [IPv6:::1]) by open-mesh.org (Postfix) with ESMTP id E40228108D; Wed, 24 Apr 2019 03:19:27 +0200 (CEST) Authentication-Results: open-mesh.org; dkim=fail reason="key not found in DNS" (0-bit key; unprotected) header.d=c0d3.blue header.i=@c0d3.blue header.b="azH+4wpk"; dkim-atps=neutral Received-SPF: None (mailfrom) identity=mailfrom; client-ip=138.201.29.205; helo=mail.aperture-lab.de; envelope-from=linus.luessing@c0d3.blue; receiver= Received: from mail.aperture-lab.de (mail.aperture-lab.de [138.201.29.205]) by open-mesh.org (Postfix) with ESMTPS id AC3E28098C for ; Wed, 24 Apr 2019 03:19:25 +0200 (CEST) From: =?utf-8?q?Linus_L=C3=BCssing?= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=c0d3.blue; s=2018; t=1556068764; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding:in-reply-to: references; bh=2TuN8vMd5rTo2hcsA8/67laJjZlx3ms7tfGwbGfC+bQ=; b=azH+4wpkzkSfknRoaG5VhN5T9SKqbLwaMCvgekgxTwZ397cNHlPuKa1RGc9A2QvpofMgXc c3SeIx0iNRtTXLIPeLragH9XDgtntqkpXDCJmys64czugSZNNJGjYPaxyuVbgiEItd1tnj G+FaP9pDBogSTaelDMGkxTju3q4Tly0y2BzX92HFxhrO6rkM0pN49129ebQQgl3Dy57TWa a0Jt0Sb9L7qk3adewIIJnFIrrCmLq6n/1Lrfs2FxyqjoGebYI/Q5Cc71uw4HvQfyVqf69e qjQK+TUP1SIC8l99GlZM/ITCRIYP0ML0dRIiZvYBxpZUtdtZg3CfQLzp+No+CA== To: b.a.t.m.a.n@lists.open-mesh.org Date: Wed, 24 Apr 2019 03:19:13 +0200 Message-Id: <20190424011919.9821-1-linus.luessing@c0d3.blue> MIME-Version: 1.0 ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=c0d3.blue; s=2018; t=1556068764; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding:in-reply-to: references; bh=2TuN8vMd5rTo2hcsA8/67laJjZlx3ms7tfGwbGfC+bQ=; b=URKchin10c7v7Qx39uV3bAJsSqfum1AjzRYcnK/+FxASdGDF4y/0x9jTQUiQxMj+pYWDwc 3qAC7Eg+dToo7BI3+2QS/lJnPrCgZZoo1eMcfOzgQikk04A/ZPLahHoX4VIq7+l4voXXIq jMTwzetWvDIkrvhf2HqWzhTEVUS1k29dhAsS9wnmH8ZOgFocMACyGM8+OeyMJzoFBf6lOy 5+jGPUZScTeLny/KlzxpIIbZ07rHYh17x9DMW0K9QAHt1lob0KjEEFkIZV0/CP4Tbh9oN7 MXJfVgPxT1rdmmr5Gt8ULBwZ4vN0z5WPGhvk4zJUuh7ZdrTxcrq330Brd9iQPg== ARC-Seal: i=1; s=2018; d=c0d3.blue; t=1556068764; a=rsa-sha256; cv=none; b=mXB879VynnqT/8KJbEJAgVYE1qgIIoEDj1aMrqUA1yO1enrqsdF2+luYVDW36CuVo3EUL7 iB+W+0Zy/tD5Yf9qZ7aHj6uNg+zzQ5yE6VNPsc27qiPE8wrY64IMsA7tbxqeJLtCb1DhVB 7zH9vN0F0UpYTvZ3Ha0lxSQ8kVAbKK+UgL/VmBK5szJ5stj/9s5XURhxMozjuMNtoDEPMp K3NfJ19UbJsgzu3vNkJ7/unyC9070WsfcAyWPdjSao+cWmIwsBxK0vsFyEuRKw+uzAJNu2 6MARod4POv6fk5o+BBQvnz4uRpP5pjyqXFJViruT/TyC3uvgJGI721T0RT41uQ== 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 Subject: [B.A.T.M.A.N.] [PATCH 0/6] batman-adv: Add routeable multicast optimizations X-BeenThere: b.a.t.m.a.n@lists.open-mesh.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: The list for a Better Approach To Mobile Ad-hoc Networking List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: The list for a Better Approach To Mobile Ad-hoc Networking Errors-To: b.a.t.m.a.n-bounces@lists.open-mesh.org Sender: "B.A.T.M.A.N" The following patchset fills the next gaps in the multicast address rules page by adding support for group-aware optimizations for multicast addresses of scope greater than link-local. So far, only link-local addresses were optimized as packets with routeable addresses not only need to be forwarded to local multicast listeners but also multicast routers. "Handling rules depending on multicast address:" [0] Before: * Ipv4, link-local: supported without bridges * IPv6, link-local: supported * IPv4, routeable: support planned. * IPv6, routeable: support planned. After: * Ipv4, link-local: supported without bridges * IPv6, link-local: supported * IPv4, routeable: supported without bridges. * IPv6, routeable: supported. The first patch is a fix for the maint branch addressing tickets #369 and #370. Then patches 2 to 4 are basically some cleanups and restructuring of the current code. Patch 5 adds the detection of multicast routers and announces that via two new flags in its multicast TVLV. TVLV receivers will memorize this and fill lists similar to how we already do for the WANT_ALL_IPV4/IPV6 flags. Currently the detection for bridged-in IPv6 multicast routers is not quite what the RFC for multicast router discovery suggests. But once the MRD implementation in the Linux bridge has matured a bit, I'm going to swap this simplified approach with tapping into the bridge once more, asking the bridge for the presence of multicast routers on the link. (This will then also add support for "IPv4, routeable, with bridges") Finally, patch 6 implements the changes to the forwarding plane, utilizing the new information we have gathered with patch 5. Regards, Linus [0]: https://www.open-mesh.org/projects/batman-adv/wiki/Multicast-optimizations-tech#Handling-rules-depending-on-multicast-address