"Unprivileged ports" is just a case in point for everything you would need privileges to do, from binding arbitrary ports to adding arbitrary addresses and running local servers on them, etc, etc, etc. The point is: turning "complicated" network features that require privilege into simple unprivileged socket code.
Right, per my other thread below, my understanding was the "privileged" ports were mainly ones that were allowed for off machine communication by standard policy/convention long time ago. As such, using higher number ports should be just as easy in the code as using lower ports, outside of the discovery that was implied by following the other conventions. But, introducing new network addresses seems to have already side stepped the discovery affordances?
I'll offer the same caveat here, btw, I am not trying to torpedo the idea of trying this. I'm genuinely curious why you would need to do this. Not necessarily why you would want to.
We did it because we run WireGuard gateways to the public cloud we operate, and our CLI wants to talk to things on customer networks (like remote Docker server instances to build new versions of apps). Our options were:
* Do user-mode WireGuard (and thus TCP/IP) and talk "natively" to the infrastructure deployed on our platform.
* Write case-by-case application gateways for each of those pieces of infrastructure tunneled somehow through HTTP.
