On 28-sep-2007, at 23:38, Alain Durand wrote:
On 10/21/07 5:13 PM, "Iljitsch van Beijnum" <[EMAIL PROTECTED]>
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.
