I don't think its even that hard to create an extension at this point. Partially because we are mostly there already. Call the extension "NAT tagging" and add

I don't think its even that hard to create an extension at this point. Partially because we are mostly there already. Call the extension "NAT tagging" and add a 24-bit NAT "tag" which reflects the bottom 24 bits of the 10.x space. Every machine with a private ipv4 appends this as its source tag, and it becomes the responsibility of NAT tagging aware NATs to notice the NAT tag on inbound packets and route them appropriately. Client machines which are themselves aware make sure to preserve the source tag when sending packets back to the NAT'ed machine. The tag of every existing public ipv4 is 0.0.0. The only tricky part at this point is encoding all these extra bits in a way which is ignored by existing ipv4 stacks. Although, figure out how to check for it in a handshake of some form (easier with stateful protocols like TCP) and it could hide outside of the IP header itself. Non compliant endpoints continue to suffer the existing port forwarding/etc issues that exist with current NAT's while updated machines can directly address each other. The various hacks (already in use) to the HTTP hostname fields also solve the problem for tag unaware machines addressing public https servers. This gives every existing IPv4 address 24 bits of additionally public routable addressing without having to upgrade a single core router/etc.