Re: Modified IPv6 to unmodified IPv4

[Brian E Carpenter <brian.e.carpenter@gmail.com>]

On 2007-10-19 21:05, Iljitsch van Beijnum wrote:
> 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). 

That doesn't cover us for the day when we have true IPv6-only apps
with no reptilian memory of IPv4. I think I'd rather avoid the
application having any knowledge of IPv4 at all. If we're going to
do this horrible thing, let's do it 100%. (As Iljitsch knows, I'm
playing with some thoughts on this, but they aren't quite ready for
public ridicule yet.)

    Brian

> 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.