24

I understand the original reasoning behind having 65,535 ports per IP address: this is the highest number that can be represented by a 16-bit, or 2-byte, number, and it wasn't conceivable that computers would ever be able to spare more than that for something as trivial as ports, or something like that. Ports may in fact need more than 1 bit each, as each port can be open, blocked, "stealthed", or others, but for some reason people always say ports operate with a 16-bit number. If I have any part of this wrong, by all means tell me.

However, in a world where most computers are 32-bit, and have more than enough memory/space to spare for a couple more ports, why do we still have this many ports? We are in the process of moving to HTML5, HTTP2.0, IPv6, and other definitely different versions, so why not the same with ports? Many of these allow much more than 16 bits; in fact, IPv6 allows 16 bytes! I understand that many of these are years or even decades away, but why all the chatter on these upgrades, and not even a peep about more ports (that I, an amateur, have heard of)?

The only 2 reasons I can see for keeping 65,535 ports are letting big businesses keep their old legacy systems, which is hardly a good reason, and the rise of embedded systems, many of them tiny, with miniscule amounts of space, memory, etc., coming onto the Internet soon, many as part of the Internet of Things. With these embedded systems, perhaps we could let them have fewer ports, and when a big desktop computer tries to connect to one, it could be told to be gentle, as the baby embedded system can only use ~65,000 ports.

On the other hand, I can think of a few good reasons to have more ports, most having to do with NAT and other systems where more than 1 private IP address has to communicate with the rest of the Internet using the same public IP address, like the rise of VM's on the same computer, all using the same IP address. Technically, each VM IP address has 65,535 ports, but in reality they all use the host's ports. In cases like this, these systems could run out of ports fairly quickly. Another specific case is carrier-grade NAT, where one public IP address is translated into several private IP addresses, and at least one of these private addresses gets translated into another set of even more private addresses. Again, each private IP address technically has its own set of 65,535 ports, but this is an illusion, as when the data get out to the public Internet, they are using the public IP's ports. I'm not sure we necessarily need NAT, per se, but we will need something like it to conserve addresses even with the massive amounts IPv6 will give us. When we have cases like these, can we even afford not to have more than 65,535 ports?

So, why do we still have only 65,535 ports, and are there any plans to allow more?

P.S. I know there are technically 65,536 ports per IP address, but port 0 is not usually used for anything.

trysis
  • 385
  • 1
  • 4
  • 10
  • I think you need to ask IANA these questions they control the resources. I think you need to read the [TCP/IP guide](http://www.tcpipguide.com/free/index.htm) too as some of your understanding seems flawed. – user9517 May 02 '14 at 06:45
  • 1
    Yeah, I figured. I tried to say as much as I understood, but as you can see, I don't understand everything. – trysis May 02 '14 at 17:03
  • 8
    What is off-topic about this question? Just wondering. – trysis May 02 '14 at 17:11
  • 1
    I also gave up asking questions in these sites. Everything seems to be off-topic these days... – Nuno Jan 18 '17 at 22:40
  • IPv6 makes the limitation of ports moot by offering a computer a /64 of addresses to use. – J.Money Sep 17 '19 at 21:49

1 Answers1

34

The port is a part of the layer 4 protocol in use - TCP or UDP, for the most part; it's not related to the memory addressing of the actual computers, so don't get confused by the 32 or 64 bit memory addressing of modern operating systems.

The headers of these layer 4 protocols have specifically defined structures, for which exactly 16 bits are used for the source and destination ports. Without compatibility-breaking changes to the layer 4 protocols that the entire internet depends on, the number of ports cannot be changed. Even the newer SCTP has the 16 bit constraint on ports.

Keep in mind that these protocols identify traffic based not just on the receiving port, but also the receiving IP and the sending port and IP; you're limited to 65535 listening TCP ports (but you don't have that many), and you're limited to 65535 connections to a specific service on a specific remote system (lower in practice, see ephemeral ports), so it's uncommon to run into the limit on these protocols unless you have a system creating a whole lot of connections to a specific remote system.

Shane Madden
  • 112,982
  • 12
  • 174
  • 248
  • 4
    It always comes down to backwards-compatibility, doesn't it? Why can we change to IPv6, which allows so many more IP addresses it's ridiculous, but we can't have a couple more ports? That's my main annoyance. – trysis May 02 '14 at 17:07
  • 4
    @trysis Right - moving from IPv4 to IPv6 is a good comparison to what it'd take to move to a version of TCP and a version of UDP with more bits in the header for the port. And if you haven't noticed, it's been a slow and painful process to even get worldwide IPv6 deployment to where it is now (with a 1-2% of worldwide traffic using it). For IPv4, there was a compelling need to move - address exhaustion. Running out of port space on these protocols, on the other hand, is not a common problem, so there's no compelling need to make the massive changes that would be needed to make it happen. – Shane Madden May 02 '14 at 17:53
  • Oh, that makes more sense. Thanks. Maybe someday we will feel the need, but I suppose you're right in that that need isn't there now. – trysis May 02 '14 at 18:15
  • I would hope that if we ever go through all that trouble, we can come up with something better than integer-based port addressing. Something like UUID-based ports would be awesome. Or actual namespaces would be even more descriptive and eliminate the potential for conflicts between applications. Imagine setting a port forward for the "com.windows.local.yourdomain.server001" namespace or something like that. – njbair Jun 03 '16 at 14:48
  • so if two PCs together make 65,535 connections or similar to a coupel of PCs outside the NAT, none of the other PCs would be able to access itnernet. Am I correct? – Denis Jun 03 '16 at 15:23
  • @Qwertylicious Not quite - it's just that no other PCs behind the NAT would be able to access the PCs that the swarm of connections was made to. Connections are uniquely identified by source port, source ip, dest port, and dest ip, so the limits just apply to additional connections to those same servers (or in the small network scenario far more likely, when your router just doesn't have much memory allocated for tracking all those connections and just starts dropping them from the NAT table after there's a few hundred thousand connections total). – Shane Madden Jun 07 '16 at 03:08
  • in theory you can keep it 16 bits but add another layer between the ip layer and transport layer for a special extended mode where some of the data section is reserved for 4 or 8 byte addressing. sadly this requires new systems that would support such mechanism, or less securely, all applications on the machine must agree to forward any packets they receive with a special flag based on the newer addresssing scheme. Im sure this is an easier problem than that faced by transitioning from 16 bit to 32 bit addressing while keeping compatibility. – Dmitry May 04 '18 at 03:44