Very good read.

I'm appalled that 256KiB of state is needed (the flawed implementation being replaced required only 10KiB).

Considering how contrived the randomization scheme is, I wonder if changing the paradigm to something simpler could produce a better scheme. The whole counters-indexed-by-adversary construction is fishy.

A native thought, but nevertheless: why not just read the next port number out of a cryptographic PRNG seeded at boot time?

There is an extra condition for the new port, it must not have been used recently, because attempting a new connection with a port used previously might hit a previous connection on the server that has not been deleted yet and it is still in the TIME-WAIT state.

The obvious and correct solution is to keep a list with the recently used ports, with an expiration time after a connection has been closed, and to reject any new random port that can be found in that list.

RFC 6056 claims that the obvious solution is inefficient, so it is better to increment some previously used port, to get a new distinct port.

Judging from the large overhead that is needed for fixing the "efficient" solution, I believe that it would have been better to just implement the right solution, which is likely to need less state.