TL;DR: As long as the two communicating endpoints are happy and there's
not an overly restrictive firewall in the way, then it doesn't matter
what ports are used.
On 8/6/25 8:38 PM, Grant Edwards wrote:
According to IANA (and before that ICANN and USC/ISI) port numbers from
1024 to 49151 are registerd ports, and are to be used for specific
protocols.
I don't disagree with the accuracy of that statement. However I do
Disagree with the implications.
Dynamic or ephemeral ports are supposed to be in the range 49152-65535.
No. That's the port range that's reserved for them.
Nothing about any of the reservations makes the port exclusive for what
it's reserved for.
Remember, IP addresses and protocol ports are *locally* *significant*
/on/ /both/ /ends/ of a connection.
Nothing other than the endpoints should care what ports are used. Sure,
some overzealous firewall configurations impose their will on the
traffic that flows through them.
I can easily use any pair of ports that I want to between two systems.
The only real restriction is that the two systems must agree and be
willing to use the same ports for the connection.
What's more is that most servers don't care what port(s) clients are
using as long as they talk to the port that the server daemon is
listening on. Meaning that servers only care about the destination IP
and port of the inbound connection.
So I can have my client connect from any non-conflicting port on my
client's IP address to the port the service is running on at the
server's IP address.
This means that three of the four pieces of the tuple are known and the
fourth is up to the client application and / or the client system's kernel.
- client IP - known
- server IP - known
- client port - unknown
- server port - known
I can limit my system to 49152-65535 or I can allow it to use
1024-65535. There are even ways to cause the client traffic to appear
to be from port 1-65535.
Aside: I don't remember what it is, but I feel like port 65535 has some
sort of problem in some niche situation, so I'd actually stop at 65534.
So roughly, I can use ports ~49152-65535 or ports 1-65535 and have four
times the range of ports.
This does work perfectly fine.
I've done this for years.
There has NEVER been a conflict between my client system and the server
that I'm talking to.
I can even have my client talk from TCP port 443 to TCP port 80 on the
server. It doesn't matter.
Only the two communicating endpoints care. -- And overly zealous
firewall configurations.
Linux defaults to 32768-60999 for ephemeral ports. That clearly
overlaps with a _lot_ of assigned/registered port numbers in the
range 32786-49151.
Yes. So what? It doesn't matter. It obviously works and hasn't been a
problem.
That seems just plain wrong.
It's against the documentation. But it works perfectly fine.
What am I missing?
A different world view? -- I mean that as the view of communicating
devices, not who's name is penciled in next to a port.
It's simple enough to change the ephemeral range so it doesn't overlap
with registered port numbers,
Yes.
and it looks like I'm going to need to do that to avoid possible
collisions
I would ask why. But you hint at some additional complications.
in a project I'm working on.
Please elaborate.
I still bet that it won't be a problem. (See draggons below.)
The question is why do I have to do that?
You don't.
The standards are pretty clear.
Many RFCs are clear on things. SMTP RFCs strongly suggest that I should
always accept every single piece of email that comes into my server.
Yet for my own policy reasons I reject a LOT of email.
The standard is for interoperability. If you're interoperable with
things while not following the standard to the letter, cool.
Why does Linux default to being broken like that?
It's not broken.
It's been working just fine for years.
Here be dragons.
If your application is listening to port 12345 on 192.0.2.1, I can still
send traffic from 192.0.2.1:12345 to 198.51.100.1:23456.
There is no conflict between the two sockets below:
192.0.2.1:12345 - 0.0.0.0:0
192.0.2.1:12345 - 198.51.100.1:23456
The tuples (almost always) need to be unique. The tuple is client IP &
port and server IP & port.
This example re-use of port 12345 technically works. However it's
probably not the best idea to do because it may confuse humans. It
won't confuse the TCP/IP stack. But we have some conventions in place
to make things easier for humans.
To recap, as long as the two communicating endpoints are happy and
there's not an overly restrictive firewall in the way, then it doesn't
matter what ports are used.
--
Grant. . . .
