From patchwork Mon Sep 9 22:37:18 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Dave Taht X-Patchwork-Id: 1159950 X-Patchwork-Delegate: davem@davemloft.net Return-Path: X-Original-To: patchwork-incoming-netdev@ozlabs.org Delivered-To: patchwork-incoming-netdev@ozlabs.org Authentication-Results: ozlabs.org; spf=none (mailfrom) smtp.mailfrom=vger.kernel.org (client-ip=209.132.180.67; helo=vger.kernel.org; envelope-from=netdev-owner@vger.kernel.org; receiver=) Authentication-Results: ozlabs.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b="kiWJZZw2"; dkim-atps=neutral Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 46S32Q0YtCz9s4Y for ; Tue, 10 Sep 2019 08:37:34 +1000 (AEST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2389212AbfIIWhd (ORCPT ); Mon, 9 Sep 2019 18:37:33 -0400 Received: from mail-pg1-f196.google.com ([209.85.215.196]:43058 "EHLO mail-pg1-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726940AbfIIWhc (ORCPT ); Mon, 9 Sep 2019 18:37:32 -0400 Received: by mail-pg1-f196.google.com with SMTP id u72so8643928pgb.10 for ; Mon, 09 Sep 2019 15:37:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:in-reply-to:references; bh=o+0aLYFxsxsbeiG9ciU0Wjlqzy207eMb7ufdO3OkQes=; b=kiWJZZw2x/gNNOTQur4Y7wrM8IO2N2eRZ5mBTaXyw8qpzlKNSAHHbPAmPH8ZqQt2v4 3pgPsW1y28p/f9yh94uCbnoLUkSRKUFLXamTMH/kcltpqEcWp9Cozl14uBwBtTfc0r+5 xvvCP5sQMh2MPRQTAOSyT/N0UO+32wu37kMHZI+S6eENnaSYW1QjJVWm/oeVO1plYxef F+9R3rU26w1vS0ot0Lgqpljk9mGZliLpXtztkzav+DuqMf/Nb3g3As6740qyzs5PXyrQ uvL9/mcup69+OkD2kJpZIqg2glY8b6mx40+b5vLvrSsCf3Hur8iPWTCKPuRVCZU8faDQ o2MA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references; bh=o+0aLYFxsxsbeiG9ciU0Wjlqzy207eMb7ufdO3OkQes=; b=k3vJXLlessLnAL2VUE2nx0XAS3V3fr42I3h94rSqVJTkuOf2Z8HoEZECztVuz+dpkd RfDZKf1oj1s9a1QmKKfeYJCv9YFrlf5VsTyhuWXXEU3GxOg08DCrKBx0YdkRc6za4Krg 0WfRmCu2SUUmBIk+dU4owVwXBEKDdVx7ycb0Ik1ZaR/iJ4wpJWPO7kYdAk9nvNDdjvc6 Xj27NW6j3B5Wo24gGdU9Vt3g2gSwaYc2snn2xDfFL4rVrx8HPwsadRG0C9zuqso65aOC H+vLKX/wdscak51ztqTfoMXlVXg+LclCn8IYTA8RLVQkdhDVi3GvFfF0epmIaw2hqOKT 0Tyw== X-Gm-Message-State: APjAAAVnCY/6MKuqh/FAbi4P53tP8rkElkggkcHilnnJyYctME27EmjT fhCszht30jAfYvHVZ9Ikz0vSzYmofQWo1w== X-Google-Smtp-Source: APXvYqxZCZjI+IwQssgjNC3uYm/wXVGpVDm6uiMqHDL2opKplT0X6dkk+6wlwXaOpxDryWpc8MJUFw== X-Received: by 2002:a65:50c5:: with SMTP id s5mr24199395pgp.368.1568068648999; Mon, 09 Sep 2019 15:37:28 -0700 (PDT) Received: from dancer.lab.teklibre.com ([2603:3024:1536:86f0:eea8:6bff:fefe:9a2]) by smtp.gmail.com with ESMTPSA id q204sm16186732pfq.176.2019.09.09.15.37.27 (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 09 Sep 2019 15:37:27 -0700 (PDT) From: Dave Taht To: netdev@vger.kernel.org Cc: Dave Taht Subject: [RFC PATCH net-next 1/2] Allow 225/8-231/8 as unicast Date: Mon, 9 Sep 2019 15:37:18 -0700 Message-Id: <1568068639-6511-2-git-send-email-dave.taht@gmail.com> X-Mailer: git-send-email 2.7.4 In-Reply-To: <1568068639-6511-1-git-send-email-dave.taht@gmail.com> References: <1568068639-6511-1-git-send-email-dave.taht@gmail.com> Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org This patch converts the long "reserved for future use" multicast address space, 225/8-231/8 - 120m addresses - for use as unicast addresses instead. In a comprehensive survey of all the open source code on the planet we found no users of this range. We found some official and unofficial usage of addresses in 224/8 and in 239/8 - both spaces at well under 50% allocation in the first place, so we anticipate no additional growth for any reason, into the 225-231 spaces. There will be some short term incompatabilities induced. The principal flaw of converting this space to unicast involves a non-uniext box, sending a packet to the formerly multicast address, and the reply coming back from that "formerly multicast" address as unicast. The return packet will be dropped because the source of the reply is unicast (L2) with what the non-uniext box considers to be multicast (L3). and, like all multicast packets sent anywhere, the attempt will still flood all ports on the local switch. A tcp attempt fails immediately due to the inherent IN_MULTICAST check in the existing kernel. Some stacks (not linux) MAY do more of the wrong thing here. As for userspace exposure... We were only able to find 89 packages in fedora that used the IN_MULTICAST macro. Currently the plan is not to kill IN_MULTICAST, (as doing it right requires access to the big endian macros) but retire its usages in the kernel (already done) and then the very few programs that use it userspace. All the routing daemons we've inspected and modified don't use IN_MULTICAST. The patches to them are trivial. New users of multicast, seem to always pick something out of the 224/8 or 239/8 ranges, which are untouched by this patch. Additional potential problems include: * hardware offloads that explicitly check for multicast * binary firmware that explicitly checks for multicast * a tiny cpu hit Whether or not these problems are worth addressing to regain 120m useful unicast addresses in the next decade is up for debate. --- include/linux/in.h | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/include/linux/in.h b/include/linux/in.h index 1873ef642605..8665842a3589 100644 --- a/include/linux/in.h +++ b/include/linux/in.h @@ -42,7 +42,10 @@ static inline bool ipv4_is_loopback(__be32 addr) static inline bool ipv4_is_multicast(__be32 addr) { - return (addr & htonl(0xf0000000)) == htonl(0xe0000000); + if((addr & htonl(0xf0000000)) == htonl(0xe0000000)) + return !((htonl(addr) >= 0xe1000000) && + (htonl(addr) < 0xe8000000)); + return 0; } static inline bool ipv4_is_local_multicast(__be32 addr) From patchwork Mon Sep 9 22:37:19 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Dave Taht X-Patchwork-Id: 1159949 X-Patchwork-Delegate: davem@davemloft.net Return-Path: X-Original-To: patchwork-incoming-netdev@ozlabs.org Delivered-To: patchwork-incoming-netdev@ozlabs.org Authentication-Results: ozlabs.org; spf=none (mailfrom) smtp.mailfrom=vger.kernel.org (client-ip=209.132.180.67; helo=vger.kernel.org; envelope-from=netdev-owner@vger.kernel.org; receiver=) Authentication-Results: ozlabs.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b="HdygJsEl"; dkim-atps=neutral Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 46S32N1yMsz9s4Y for ; Tue, 10 Sep 2019 08:37:32 +1000 (AEST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2389181AbfIIWhb (ORCPT ); Mon, 9 Sep 2019 18:37:31 -0400 Received: from mail-pl1-f196.google.com ([209.85.214.196]:46814 "EHLO mail-pl1-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726940AbfIIWha (ORCPT ); Mon, 9 Sep 2019 18:37:30 -0400 Received: by mail-pl1-f196.google.com with SMTP id t1so7352393plq.13 for ; Mon, 09 Sep 2019 15:37:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:in-reply-to:references; bh=d0LILC2633SYh9WSYFBaNtUUAlCaSBgRoHMGDUTrk2s=; b=HdygJsEl2rvlxaz3ulE9FkJhGUH1T73kyvxeoCtNvb5Bp8GPQh2glEX9i6MyZADG5S tF4O7zfckACxKhh28jtpYCl5P17T4qL6Kvc07qY3QJ5rBzVhtWZIDAR8GBNNrRU71hsp AVuNbqDIJ+3lh3PGlGZJjZnzxWPh4ePEVMzwIHndLYvepjnomY0IS+wWhb+JqOIfuDHX f+XatZfMr7TgTpw8MRYqAqAT8A+dLv2GXwyHtheekkgsf+9nhsO92xSwA7jKzbRsixnJ Zw+twdHfWkhB6NqZMh7OthLnSRw65O8MizDRdlr7/oU2fhHU0dlb9YqLNd5LKln5/S4+ /t4w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references; bh=d0LILC2633SYh9WSYFBaNtUUAlCaSBgRoHMGDUTrk2s=; b=Kzke+CC2qQ21rc5EZG65LHNkkdW7ss7pDuY4Gb509oRRQWzJU8UULNMtRfTOLbw3HI JoWN2McCARyF3VkwujT8Lidi49dSQRjYW/AFar7qx+ND11o/GH6daG4i5//I5NDTBwz+ IJw0wWB9bt9R2nzpW5BP28U7o82KgQCXsQ+LAPYPOEgmADpamQv25fHts9D4GAlqnBTg sE1N+mglw/5Jd91WOKwuNlexkl72OuTmCuYL/7/F5y09e9yXLMmJh6xYcSPysTaBPekv M82wSShInnrw+rAyWSnUSk+HDElHfsXEGe6Rt32UIzp/T/o53oHCJzBmvmJ9sw6Dgm+m ogog== X-Gm-Message-State: APjAAAU6LRhpRQZudqDD8+ao7WADuSdgl3Ufvhpn+aSlbKmoTPIhcxH8 exIS6GrCLGMbNxtAWJ6gP+0YBAcjaOGAyw== X-Google-Smtp-Source: APXvYqzo3UNQWd8D1mS+WhlMlKX2SUKVoD8lvqjv2sGgHzLqvFD50g/CGSYCZlMn8ZP0O8xCAqVgMw== X-Received: by 2002:a17:902:166:: with SMTP id 93mr27601987plb.320.1568068650005; Mon, 09 Sep 2019 15:37:30 -0700 (PDT) Received: from dancer.lab.teklibre.com ([2603:3024:1536:86f0:eea8:6bff:fefe:9a2]) by smtp.gmail.com with ESMTPSA id q204sm16186732pfq.176.2019.09.09.15.37.29 (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 09 Sep 2019 15:37:29 -0700 (PDT) From: Dave Taht To: netdev@vger.kernel.org Cc: Dave Taht Subject: [RFC PATCH net-next 2/2] Reduce localhost to 127.0.0.0/16 Date: Mon, 9 Sep 2019 15:37:19 -0700 Message-Id: <1568068639-6511-3-git-send-email-dave.taht@gmail.com> X-Mailer: git-send-email 2.7.4 In-Reply-To: <1568068639-6511-1-git-send-email-dave.taht@gmail.com> References: <1568068639-6511-1-git-send-email-dave.taht@gmail.com> Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org The 127 concept of "localhost" was basically a straight port over from original ARPANET behavior. At the time it was envisioned that many services would exist in the mainframe that would need to be individually addressable, and long predated alternative approaches such as tipc, etc. This reduces 127.0.0.0/8 to a /16, and opens up 127.1.0.0 and above for use as real, unicast addresses either on the wire or internal to containers, virtual machines, vpns, etc. The only major uses of 127 to date have been (of course) 127.0.0.1 and 127.0.1.1 (for dns), and various adhoc uses for things like anti-spam daemons. Linux also has a non-standard treatment of the entire 127 address space - anything sent to any address there "just works". This patch preserves that behavior for 127.0.0.0/16 only. Other uses, such as ntp's 127.127 "handle" for it, doesn't actually touch the stack. We've seen 127.x used for chassis access and a few other explicit uses in the field, but very little. There is some small hope that we can preserve the original intent of "localhost" in an age of stacked vms and containers, where instead of using rfc1918 nat at each level, we can route, instead. --- include/linux/in.h | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/include/linux/in.h b/include/linux/in.h index 8665842a3589..6e4f37e5bf51 100644 --- a/include/linux/in.h +++ b/include/linux/in.h @@ -37,7 +37,9 @@ static inline int proto_ports_offset(int proto) static inline bool ipv4_is_loopback(__be32 addr) { - return (addr & htonl(0xff000000)) == htonl(0x7f000000); + if((addr & htonl(0xff000000)) == htonl(0x7f000000)) + return( addr & htonl(0x00ff0000)) == 0; + return 0; } static inline bool ipv4_is_multicast(__be32 addr)