[99635] in North American Network Operators' Group
Re: Access to the IPv4 net for IPv6-only systems, was: Re: WG Action: Conclusion of IP Version 6 (ipv6)
daemon@ATHENA.MIT.EDU (Iljitsch van Beijnum)
Mon Oct 1 04:27:23 2007
In-Reply-To: <C322ECA2.33F3%alain_durand@cable.comcast.com>
Cc: Jari Arkko <jari.arkko@piuha.net>, Randy Bush <randy@psg.com>,
<nanog@nanog.org>
From: Iljitsch van Beijnum <iljitsch@muada.com>
Date: Sun, 30 Sep 2007 20:59:42 +0200
To: Alain Durand <alain_durand@cable.comcast.com>
Errors-To: owner-nanog@merit.edu
On 28-sep-2007, at 23:38, Alain Durand wrote:
> On 10/21/07 5:13 PM, "Iljitsch van Beijnum" <iljitsch@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.
