Re: [PATCH v3] net: Use standardized (IANA) local port range
From: Eric Dumazet <hidden>
Date: 2020-08-31 08:07:34
Also in:
lkml, netdev
On 8/28/20 2:52 PM, Stephen Hemminger wrote:
On Fri, 28 Aug 2020 22:44:47 +0200 Bart Groeneveld [off-list ref] wrote:quoted
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 <redacted>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.
Agreed. There is a sysctl, allowing admins/distros to opt-in to whatever IANA values of the days if they really want. We have already many issues caused by ephemeral range being too small. For instance I often have to debug issues caused by some distros changing sysctl_tcp_rfc1337 to 1, hurting some real applications.