Access to the IPv4 net for IPv6-only systems, was: Re: WG Action: Conclusion of IP Version 6 (ipv6)

Sun Sep 30 18:59:42 UTC 2007

On 28-sep-2007, at 23:38, Alain Durand wrote:

> On 10/21/07 5:13 PM, "Iljitsch van Beijnum" <iljitsch at muada.com>  
> wrote:

(sorry about posting from the future, shouldn't mail while  
experimenting)

>> I think an approach where you have a regular IPv4 NAT and then tunnel
>> the RFC 1918 addresses over an IPv6-only network would work better
>> than NAT-PT.

> The issue here is that the translation would have to occur at the  
> box that
> is decapsulating the packet, as the mapping private-v4 to v4 would  
> have to
> be indexed by some kind of tunnel ID that identifies the customer.

Well, if you do both NAT and tunneling, then you need to keep state  
for both. That's not free, but is it a big issue?

> If you translate v4 to v6 at the home gateway, you have a global v6  
> address
> to identify that customer and you can do the reverse translation  
> (back to
> v4) pretty much anywhere you want in the service provider network.

So what I say is:

<v4 world> - <NAT> - <tunnel over v6> - <process NATed v4>

And what you say is:

<v4 world> - <NAT> - <translate to v6> - <forward over native v6> -  
<translate to v4> - <process NATed v4>

Your model has more steps, and it's also more complicated. If you  
know you're going to go back to v4 anyway, it makes more sense to  
keep the IPv4 header around and tunnel rather than translate. This  
doesn't affect the IPv6 processing, because all IPv6 header fields  
can be the same regardless.