How would this have worked in practice, in a way that the NAT464/NAT64 schemes that most mobile operators use haven’t? Would IANA have dedicated some blocks of IPv4 to be used for IPv4-compatible IPv6 addresses on the public internet?
Time has to pass for all users to switch to v6. DNS6 and DHCP6 are in-place upgrades to the existing ones, not alternatives, so now they support longer fields. Once that's done, Google.com can say hey actually we're 142.251.214.110.1 now, and probably my ISP also gives me x.x.x.x.1.1 and leases x.x.x.x.2.2 to someone else.
You can also do all the above without the 4:: prefix. The point of that was to keep the possibility of offering all-new routes under the other v6 /8s, but that has its own friction.
IPv4-mapped IPv6 addresses (prefix ::ffff:0:0/96)
Network stacks do allow this today.
If you don’t want the local machine to have a routable IPV4 address at all (which is a common practice on mobile networks), you can do something similar with a different prefix (usually 64:ff9b::/96) called NAT46. In this case the local machine’s network stack exclusively emits IPv6 packets, and the upstream router/network detects the prefix and performs stateful NAT using its own IPv4 address(es), just like NAT44. Depending on the use-case, the local machine doesn’t even have to understand what you’re doing at all. Instead you just have the local network’s DNS server return fake AAAA records with the corresponding 64:ff9b::x.x.x.x addresses when some particular domain doesn’t have native IPv6 support.
The closest was 6to4. rfc6343 goes into why that got deprecated. You'd either have "router 6to4" which required additional setup for more parties, or "relay 6to4" which introduced nasty failure modes. Also don't think 6to4 was meant to support cases like 2002:1.2.3.4.5 down the road.
It does not address the network level identity and reachability. There is no default, globally routable mapping where owning a ipv4 automatically gives you an equivalent identity in ipv6 that others can reach without translation infrastructure. The transition mechanisms are not uniform or canonical, and that increases complexity.
6to4 was an attempt at that kind of embedding and I do not think it succeeded?
The original specification of ipv6 did not directly address a translation mechanism? It seemed to rely on, well, everyone will go dual stack and we will shut down the old ipv4 stack. I think it should have addressed that in the beginning and provided the one canonical way of doing it, perhaps with guides on timelines to get the ISP and backbone providers to get on board.
Traffic to 2002:70.94.201.31/48 is tunnelled via 70.94.201.31 with-in an IPv4 packet (encapsulation):
None of this stuff works perfectly, but it’s powering almost every mobile internet connection in the world so I don’t understand what is missing.
ipv6 was standardized in 1995 6to4 was standardized in 2001
6to4 is not used in any meaningful way today.
What was missing was ipv6 should have had 6to4 (but better) in it, in 1995.
Now, I could go on about what is wrong with 6to4, but every new topic is just another surface area for ipv6 proponents to launch another question (I sometimes suspect in bad faith).
Anyone with an IPv4 automatically got a 'free' IPv6 allocation:
> For any 32-bit global IPv4 address that is assigned to a host, a 48-bit 6to4 IPv6 prefix can be constructed for use by that host (and if applicable the network behind it) by appending the IPv4 address to 2002::/16.
> For example, the global IPv4 address 192.0.2.4 has the corresponding 6to4 prefix 2002:c000:0204::/48. This gives a prefix length of 48 bits, which leaves room for a 16-bit subnet field and 64 bit host addresses within the subnets.
* https://en.wikipedia.org/wiki/6to4
"Connection of IPv6 Domains via IPv4 Clouds", etc:
We have it already with a translator box. It's called NAT64 and almost every cellular ISP in the whole wide world uses it.