Why Are There Only 65,535 Ports, and Will We Ever Have More? [closed]

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.

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.