Now consider that IPv4 + NAT + NAT traversal is essentially a crap version of IPv4+ that uses UDP port numbers to achieve an unstable, unreliable 16 bit extensi

Now consider that IPv4 + NAT + NAT traversal is essentially a crap version of IPv4+ that uses UDP port numbers to achieve an unstable, unreliable 16 bit extension to the IPv4 address space. Of course because these port numbers are ephemeral and unreliable all P2P code must be full of complex logic to constantly check for dead paths, remap ports, deal with different kinds of NAT, etc. I happen to think DJB was right. If we could rewind history to, say, 1998 and implement an address space extension to IPv4 that was less of a severe change than IPv6 that probably would have been the better way forward. Personally I would have implemented IP64, using the existing IPv4 space as the most significant 32 bits of a 64 bit address space. The advantage here is that an IP remains something that can fit in a typical 64-bit CPU register and remains short enough that it's type-able and at least a little bit memorable. 64 bits would be plenty to address every device on Earth. There are some nice things about having a larger address space but most of them are minor compared with the address shortage problem. IPv6 gives you enough space for reliable stateless auto configuration, but in practice that's going out of favor since it turns out you need DHCP (DHCPv6) for other reasons besides just assigning addresses.