Modified IPv6 to unmodified IPv4

[Iljitsch van Beijnum <iljitsch@muada.com>]

Several people have said they prefer the modifications that make it  
possible for IPv6 hosts to talk to IPv4 hosts to be on the IPv6 side.  
How about this:

Obviously, we're trying to address the situation where the IPv6 host  
doesn't have a real IPv4 address all to itself. Dual stack or  
softwires will address the situation where that is the case.

So that means NAT. What if we can keep the NAT in IPv4 rather than  
IPv6? So instead of applications talking IPv6 and then having a  
gateway translate and NAT, we have the applications talk IPv4, carry  
the IPv4 over IPv6 and then NAT. The interesting part here is that if  
we integrate the NAT and the translation, we can skip the whole IPv4  
provisioning, because the NATed IPv4 address is of no importance to  
anyone except the application behind the NAT. So we simply use a well- 
known private address here. We also skip the DNS ALG and deal with A  
records directly.

In other words:

A is an IPv6 host
B is an IPv4 server
T is a translator
X is a client app on A
Y is a server app on B

So X thinks it is running on an IPv4 host which has address 10.6.6.6  
(or whatever well-known RFC 1918 address we want to use). In reality,  
A is an IPv6 host with address 2001:db8:31::1. When X wants to talk  
to Y, it looks up the relevant domain name and sees address  
64.0.0.64. So it opens a TCP connection to 64.0.0.64. A then  
generates and IPv6 packet with source 2001:db8:31::1 and destination  
<96 fixed bits>:64.0.0.64. T translates the IPv6 packet into an IPv4  
packet with source 10.6.6.6 and destination 64.0.0.64 and then  
proceeds to NAT, using 2001:db8:31::1 under the hood to demultiplex  
rather than 10.6.6.6 because 10.6.6.6 is implicitly used by ALL  
clients of T. X sees the <address of T>/64.0.0.64 packets and Y may  
or may not notice and subsequently may or may not work around the  
"IPv4 NAT" in the path.