Received: by 2002:a05:6a10:6006:0:0:0:0 with SMTP id w6csp1510406pxa; Fri, 28 Aug 2020 14:55:24 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxjGCIdUNMrHWmKfw1ax2E+MARW5H/PoUKrzDBjlvUBRNWgS+hdZBUxup/KVK8ww0Oyu2co X-Received: by 2002:a50:e846:: with SMTP id k6mr799702edn.27.1598651724333; Fri, 28 Aug 2020 14:55:24 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1598651724; cv=none; d=google.com; s=arc-20160816; b=xes7DDmQHJJXB3HycOLpjZLf4Fl+UqYFrCdmEw/2I87Fa2CqrkTNbens5CKTJDmTlQ fQG3LxCW493eh32lrD8IHzFSKpiPQ5WsfnojmOt4DtyMwx2uGXq1up08yFtdqsf8CmB0 cT51SRj41jDM8Z+yW4pXJWBcc9bvyO6Zxiu4WqfoZcr8Qq4r9a1c95TZ7y822JRWkVnT knvXyX+WARm37VVx7CEUMWLddNGEzz05No6OFr1H+Mk4PKZGelWeKzdiK1fYyAs94OlE IIzaD2p0oSfd43kGEUWB29AUA0UgtxDGUZ/2bwrA96L3kG02974XQ+2DE15wk37oCffy If0w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date :dkim-signature; bh=BGIFgHhnj4ZZ+ZwmJ+azPNOf9dZgEALfNMtI3CFWx/o=; b=BVjYMGMsMP4t/QMsdzIVUs/CbQA+Q20lNeaJevddxkeZo6dpuyt21fNPZ124PTSgna aQNrlrHPFV/zIofHFOSicCM1VydbCyTPMdrulRZ2LgRvzNU0nsTA4ExFK2+UL/ViYfeB mwCJrbSV9aPu8pWsRhncbogzJAO1TMsKErfzsbkJi/TPgXVa9iM0jhRalznhugWnFmx8 Ez5h42n/duOWw75J+XXOzhIuMLfvPRxoaGS3kjINEnM40MdSYMYFc6I8gwQkZil26Bkx l5TZadIL3Vr2SudMTPZ8N/cGov7tA5yruIuQgMQQSMBtEdjflcBvzdde/OTNAZuDHvet WRuQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@networkplumber-org.20150623.gappssmtp.com header.s=20150623 header.b=iZovJBNh; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id p16si250355edm.382.2020.08.28.14.55.01; Fri, 28 Aug 2020 14:55:24 -0700 (PDT) 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; Authentication-Results: mx.google.com; dkim=pass header.i=@networkplumber-org.20150623.gappssmtp.com header.s=20150623 header.b=iZovJBNh; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726771AbgH1VwR (ORCPT + 99 others); Fri, 28 Aug 2020 17:52:17 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40124 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726338AbgH1VwM (ORCPT ); Fri, 28 Aug 2020 17:52:12 -0400 Received: from mail-pg1-x544.google.com (mail-pg1-x544.google.com [IPv6:2607:f8b0:4864:20::544]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id AB11DC061264 for ; Fri, 28 Aug 2020 14:52:12 -0700 (PDT) Received: by mail-pg1-x544.google.com with SMTP id p37so1064874pgl.3 for ; Fri, 28 Aug 2020 14:52:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=BGIFgHhnj4ZZ+ZwmJ+azPNOf9dZgEALfNMtI3CFWx/o=; b=iZovJBNhkq0B0uvt1ArnlCzdGbse3STj2vz7fm/5VWNq+S1otd+TvNXZEUISe40n4r 3tyV7aZKRDpcO8Xj0Mrnb0RFV5xmg0I8ORIUjCNCrvsgPb0d8Bun/VjtpPNSc/dfVpKT uS0YwSrtAIaaZAeAitIxGI7YsF/TOi0NkB/2zD/YiJYxK4wMVhVW0mHTLZyrIXJPpESq y06pufjnDraLjjx8YNwTEqj440DVB6lkZF+ldjBz/N+O4Pc4nEPAthTnNQEdzYhkK/W3 qIkdIyU503gGOvgOhAL7fG7yiYDGHx8m7RtnSdb1qBuDmi3Q35PlKpNHYR+hXjomtOgO +BDA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=BGIFgHhnj4ZZ+ZwmJ+azPNOf9dZgEALfNMtI3CFWx/o=; b=prh9vY3ZN7Q2Sr4wP8blqLVXX+kMIDpNLYyTkJTD0LRnPmNh3nQTpP9cxhNCY3U314 uk0uX8a3ROsc9YDkd8Z4Hg1K6xizHS8X0DaHgjtyFmltpVKwU92bi5A5mqQD9wtAlEbo MTWEtW2BbJooMrYF3iHf8mVr5fyOcCQCUhC0dsvRdwg65znylKdl2sh4iU/z9iAGWc9Z HXD6nfuF3i16HEa52vJU03YKoRq0+5cKw5olsAhQZksuYsyRrefbCjUIaDQEfQCTPE6a 2AsKagXMCQM5fEcb9f5ph+A81AanaBL6y74psdvHpc6lXvLAeHsA8xBnRlhpXKc/NO7s 15jQ== X-Gm-Message-State: AOAM532DeU8Xj9+2VxDSVUFYebLZMJC4AfrBYoHymrPVq1434xjgexYY TxuCW0lQ1tggUuvOSOnHA+Lhqg== X-Received: by 2002:a62:5214:: with SMTP id g20mr821890pfb.168.1598651532034; Fri, 28 Aug 2020 14:52:12 -0700 (PDT) Received: from hermes.lan (204-195-22-127.wavecable.com. [204.195.22.127]) by smtp.gmail.com with ESMTPSA id r199sm400334pfc.98.2020.08.28.14.52.11 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 28 Aug 2020 14:52:11 -0700 (PDT) Date: Fri, 28 Aug 2020 14:52:03 -0700 From: Stephen Hemminger To: Bart Groeneveld Cc: linux-kernel@vger.kernel.org, "David S . Miller" , Jakub Kicinski , Jonathan Corbet , Alexey Kuznetsov , Hideaki YOSHIFUJI , netdev@vger.kernel.org, linux-doc@vger.kernel.org Subject: Re: [PATCH v3] net: Use standardized (IANA) local port range Message-ID: <20200828145203.65395ad8@hermes.lan> In-Reply-To: <20200828204447.32838-1-avi@bartavi.nl> References: <20200828203959.32010-1-avi@bartavi.nl> <20200828204447.32838-1-avi@bartavi.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 28 Aug 2020 22:44:47 +0200 Bart Groeneveld wrote: > IANA specifies User ports as 1024-49151, > and Private ports (local/ephemeral/dynamic/w/e) as 49152-65535 [1]. > > This means Linux uses 32768-49151 'illegally'. > This is not just a matter of following specifications: > IANA actually assigns numbers in this range [1]. > > I understand that Linux uses 61000-65535 for masquarading/NAT [2], > so I left the high value at 60999. > This means the high value still does not follow the specification, > but it also doesn't conflict with it. > > This change will effectively halve the available ephemeral ports, > increasing the risk of port exhaustion. But: > a) I don't think that warrants ignoring standards. > Consider for example setting up a (corporate) firewall blocking > all unknown external services. > It will only allow outgoing trafiic at port 80,443 and 49152-65535. > A Linux computer behind such a firewall will not be able to connect > to *any* external service *half of the time*. > Of course, the firewall can be adjusted to also allow 32768-49151, > but that allows computers to use some services against the policy. > b) It is only an issue with more than 11848 *outgoing* connections. > I think that is a niche case (I know, citation needed, but still). > If someone finds themselves in such a niche case, > they can still modify ip_local_port_range. > > This patch keeps the low and high value at different parity, > as to optimize port assignment [3]. > > [1]: https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.txt > [2]: https://marc.info/?l=linux-kernel&m=117900026927289 > [3]: See for example commit 1580ab63fc9a03593072cc5656167a75c4f1d173 ("tcp/dccp: better use of ephemeral ports in connect()") > > Signed-off-by: Bart Groeneveld Changing the default range impacts existing users. Since Linux has been doing this for so long, I don't think just because a standards body decided to reserve some space is sufficient justification to do this.