One real problem is the friendliness of the numbers allocation. IPv6 had one job: make more addresses available while keeping the addresses easy to manipulate,

One real problem is the friendliness of the numbers allocation. IPv6 had one job: make more addresses available while keeping the addresses easy to manipulate, and it failed at that. "Well-known" NAT64 prefix: 64:ff9b:: Everything is so confusing in numbering and addressing: http://www.gestioip.net/cgi-bin/subnet_calculator.cgi?ip=0064:ff9b:0000:0000:0000:0000:18.52.86.120&BM=96&ip_version=v6 http://www.gestioip.net/cgi-bin/subnet_calculator.cgi?ip=006... = If problem was allocation, we could have added one number in front: 123.114.123.130.200 Now for backward compatibility: If your device, operating system and application are compatible with IPv6, congratulations, you receive 123.114.123.130.200 and talk natively in IPv6. Otherwise, if you are on an IPv4 device, you receive only a portion of the IP address but from a fake IP starting with 250.x.x.x inetnum: 250.0.0.0 - 250.255.255.255 organisation: Future use status: RESERVED Technically, in the IP packets, we would have added "IPv6 address", and called the current field "Legacy/backward-compatibility IPv4 address". For example, your local home/ISP router can send a truncated version of the IP address: 250.123.130.200 and then it's the responsibility of this translation router to remember the routes at least for some time (and there is always possibility to hardcode routes if needed). = A bit like Stateful NAT64 or "SIIT-DC: Stateless IP/ICMP Translation for IPv6 Data Center Environments" or "464XLAT: Combination of Stateful and Stateless Translation" But now, with all these millions of standards it's such a productivity loss for any tech working in networking. Similarly when switching CPUs over from 32 bits to 64 bits, the idea was to change the size of words stored in memory, not change the size of words and change the alphabet in use.