Yes there are multiple ways that ipv4 can be translated into the ipv6 range. That's not what I'm suggesting here. I'm suggesting the existing ipv4 assignments to natively work in ipv6.
That would only work, at best, in 1 direction. If Alice has IPv6 and Bob has IPv4, Alice can send Bob a packet to either 1.2.3.4 or ::01:02:03:04, but if Alice's IPv6 number isn't in the IPv4 range (ex: ::10:11:12:13:14), then her IPv6 number won't have a corresponding IPv4 number that she can put in the IPv4 IP header (because the IPv4 header only allocates enough bytes to exactly fit 1 IPv4 header in the from field and 1 IPv4 header in the to field).
This means she'll have to either send an IPv6 header or an IPv4 header with a false or blank IPv4 from address. If she sends an IPv6 packet, Bob's IPv4 network stack won't be able to understand it and drop the packet. If she sends an IPv4 packet with a blank or false IPv4 from address, Bob will receive the packet, but won't be able to send a response.
What I'm suggesting is both Alice and Bob speaking ipv6. ipv4 is only used for handing out assignments to ipv6 users. If most dual stack networks use the same assignments for ipv6 and ipv4, and ipv6 routing tables are directly copied from ipv4 routing tables, then Bob can talk to Alice if their ISPs support ipv6. It's a simple upgrade instead of having to get totally separate assignments.
What I indicated in my comment above is that I dont know which of the many existing ways to embed the v4 range into the v6 address space you are talking about. Can you please tell me so that we can discuss it?
Generally, if it's not being routed right now on the public internet, and just used inside networks for migration purposes, it's not as useful for the "my Minecraft server has this IP" use case.
