Two questions about handling many connections

Why not increase the port number space to 32 bits when other incompatible changes are made to UDP and TCP? This would help many things -- port exhaustion on busy servers, and more space for NAT routers to use, better "authentication" for DNS lookups.

Also, if I understand correctly, this proposal will add some features of Transactional TCP plus syncookies to standard TCP. But just like syncookies, this doesn't seem to solve the problem with a large set of distributed attacking hosts -- because of three underlying assumptions:

1) That the attacking hosts are forging IPs and are therefore unable to reply to anything sent by the server with the proper "authentication" (sequence number, keyed hash, etc.).

2) That a single client would not be able to complete a huge number of connections without running out of memory itself, so it has to send SYNs and ignore any responses.

3) That a client can only complete connections that it initiated.

But aren't all of those assumptions wrong in many common situations today?

With botnets, attackers may have access to tens of thousands of different hosts with real IP addresses. And couldn't attackers deploy something like "reverse syncookies" where they encode the connection information allowing them to force the server to hold the state and making their code stateless. And almost all ingress/egress filtering is done with large blocks of IPs, which means a single compromised host can use entire subnets or even netblocks of IPs, at least if they are in the same broadcast domain.

So I guess I'm saying the problem is the asymmetric nature of the system -- there are just lots more potential clients than you have servers and I'm not sure if there is any way to prevent them from overwhelming you if a significant fraction are being used maliciously.