From: David Laight <David.Laight@ACULAB.COM>
To: 'Bart Groeneveld' <avi@bartavi.nl>,
Patches internal <patches.internal@link.bartavi.nl>
Cc: "David S . Miller" <davem@davemloft.net>,
Jakub Kicinski <kuba@kernel.org>,
Jonathan Corbet <corbet@lwn.net>,
Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>,
Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
"linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: RE: [PATCH v2] net: Use standardized (IANA) local port range
Date: Sat, 29 Aug 2020 13:37:01 +0000 [thread overview]
Message-ID: <30c8e904e2114204a4381034e7ee06c7@AcuMS.aculab.com> (raw)
In-Reply-To: <20200828203959.32010-1-avi@bartavi.nl>
From: Bart Groeneveld
> Sent: 28 August 2020 21:40
>
> 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].
Linux is using the 'historic' values.
IANA shouldn't really have 'grabbed' half the port number space.
Really the 'problem' of TCP port numbers identifying the service
as well as the connection should have been addresses by some other
means (eg using port 1023 and a TCP option to select the serivce).
Changing the default base from 32k to 48k will break some existing
systems if/when a kernel upgrade is installed.
You are also changing the numbers for UDP.
Anyone doing a lot of RTP (which typically requires 2 adjacent
UDP ports) is already constrained by the availability or ports.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
prev parent reply other threads:[~2020-08-29 13:37 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20200821142533.45694-1-avi@bartavi.nl>
2020-08-28 20:39 ` Bart Groeneveld
2020-08-28 20:44 ` [PATCH v3] " Bart Groeneveld
2020-08-28 21:52 ` Stephen Hemminger
2020-08-28 23:14 ` David Miller
2020-08-31 8:07 ` Eric Dumazet
2020-08-29 10:37 ` Michal Kubecek
2020-08-29 13:37 ` David Laight [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=30c8e904e2114204a4381034e7ee06c7@AcuMS.aculab.com \
--to=david.laight@aculab.com \
--cc=avi@bartavi.nl \
--cc=corbet@lwn.net \
--cc=davem@davemloft.net \
--cc=kuba@kernel.org \
--cc=kuznet@ms2.inr.ac.ru \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=patches.internal@link.bartavi.nl \
--cc=yoshfuji@linux-ipv6.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®