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.