Is there anything preventing modifying linux's tcp stack to have over 65,535 ports?

Question

I was reading this and started to wonder of there was anything preventing me from just modifying a copy of the linux tcp stack to support more than a 16-bit header to allow for more ports. Would this be possible, and if so, would anything on layer 1-3 prevent transmission of modified packets containing a 32-bit tcp header?

Answer 1

Would this be possible,

Technically yes, but you could only communicate with peers that also have been modified in the exact same way. So the amount of simultaneous connections you can make wouldn't be increased, it would be effectively reduced to the 2-3 other hosts who also thought this would be a good idea.

There's no help from the fact that you're using "99% TCP" – as long as it's not 100% TCP, hosts still won't automatically know how to speak it, so it's the same as deploying a whole new protocol (like IL or SCTP), and it's a similar story to past attempts of "extending" IPv4 by increasing the 32-bit address fields to avoid having to deploy IPv6.

(But note that the number of TCP ports available is per IP address, not globally per host – if you have two IP addresses, you can use the same port number for two different sockets, so it's easier to just add a second IPv6 address. And in theory it should be "per address-pair," so even if you run out of local ports when connecting to server A, you should still be able to use the same local ports for connections to server B...)

would anything on layer 1-3 prevent transmission of modified packets containing a 32-bit tcp header?

In theory, nothing should. As long as you choose a custom IP protocol number for your modified-TCP, it should travel across the Internet without problems. (Residential ISPs or locked-down enterprise networks might be a little more picky, but overall blocking of non-TCP/UDP packets over the public Internet is not really common, and there already exist many of those – such as GRE, ESP, HIP, SCTP...)

(Some L2 and L3 features (LACP and ECMP correspondingly) actually look at higher-layer headers, but they don't outright fail when they see an unknown L4 protocol – at most I think they might perform worse that they could have. Similarly, your layer-1 interface – the Ethernet card – will often have hardware TCP checksum and segmentation offloading which won't work with modified-TCP, but that's again only a performance loss and not something critical.)

In practice, though, firewalls might give you a really bad headache. Both the stateful firewalls with NAT in your home router (or various cloud providers) and stateless filters in enterprise routers (which can literally have the TCP header layout baked into the hardware).

It's one of the reasons why SCTP never really caught on despite having several desirable features that TCP lacks, and why QUIC was designed to rely on UDP as its multiplexing layer rather than becoming its own IP-level protocol with its own port fields.

For example, if you make an outbound connection using modified-TCP, the stateful firewall in your home router might not be able to correctly allow packets back in – it has to recognize the L4 protocol to keep track of its ports (or IDs or SPIs or equivalent) – and more importantly, if you do this on IPv4, the NAT functionality won't be able to translate the packets correctly (address translation requires the TCP checksum to be updated).

A common situation with using existing non-TCP/UDP protocols e.g. IPIP or GRE from behind a NAT is that the NAT only remembers one internal device per protocol (due to not having access to port numbers), so if multiple hosts try to use IPIP tunnels across the same gateway, its NAT state may either stick to whatever host spoke first (preventing all other hosts from using the protocol until the state expires) or may keep resetting to whatever host spoke last (thus inbound packets meant for host A would get delivered to host B, etc).

Even rarely used protocols which are standard and do have traditional ports (such as SCTP or DCCP) already suffer from these problems when cheap gateways don't include the necessary modules in their NAT/firewall (due to resource constraints).

---

And if you try to avoid these problems by reusing the existing TCP protocol number for your modified-TCP, it'll make things much worse instead – firewalls will misinterpret your 32-bit port field as the original pair of 16-bit fields, etc.

Rather than modify the basic header, a better way might be to stay with standard TCP and use TCP options to carry the additional 16+16 bits – which still wouldn't help with hosts or gateways that do not recognize those options, but at least you'd be doing it in a way that currently deployed systems already expect. (Multipath-TCP is being somewhat successfully deployed this way.)

However, many of these problems would remain even if you used TCP options for the additional port bits. For example, existing NAT systems would still only look at the low 16 bits of the port number, causing confusion if e.g. ports 80 and 65616 are used at the same time.