Re: Comments on the NAT66 draft

[Tim Chown <[e-mail]>]

On Mon, Nov 10, 2008 at 11:16:29AM +0100, Gunter Van de Velde (gvandeve) wrote:
> 
> Also, each enterprise customer I speak to of reasonable size does not
> want to be tied with the address space of the service provider. The cost
> of moving in addition to the downtime due to network transition is on
> top of their minds when they are speaking on v6. 
> 
> RFC4864 does provide alternatives for NAT in some cases, however there
> are gaps. As Brian mentioned in an earlier response, these GAPS could be
> solved in different ways, and while NAT66 may be one of them, there
> could be other solutions out there not being investigated. My prefered
> way of moving fwd is to first understand the actual problem that needs
> to be solved (problem space), then understand the solution space. Now,
> it seems the other way around, which makes little sense.

I think that's a very good point Gunter, but no matter how deep and thorough
the analysis of scenarios and proposals of solutions from the IETF that 
remove the technical need for NAT66, there's still a huge install base of 
users and sites that use IPv4 NAT today, and no doubt that some of those 
will want IPv6 NAT.  While many end users don't use NAT by choice, many -
perhaps larger - sites do.

If the IETF doesn't define IPv6 NAT, vendors will build solutions to meet
demand, and we'll probably end up with a variety of subtley different NATs 
like we do today for IPv4.

So I think there is a use in defining NAT66; it should buy some predictability
in the behaviour of 'NAT' for IPv6 networks.   But the uncomfortable fact is
that the only way that can be done is by the IETF implictly 'approving' IPv6
NAT, by defining it in an RFC.  

We will certainly see NAT for IPv4-IPv6 interoperability for a significant
time to come, so NAT isn't going away.   I think it is similarly important 
that NAT46 or NAT64 is defined in a way that maximises robust and predictable
behaviour (as much as that is possible).

Whether you call IPv6 NAT something else, be it SAM, NAM, or whatever, it'll 
still walk and quack like a duck, but at least just one variety of duck.

While I'm surprising myself by suggesting that defining NAT66 has value,
I think it is still important that we continue to show how applications and
networks are simpler to build, deploy and support without any form of IPv6 
NAT in use.   We should promote scenarios where IPv6 NAT is not required
where IPv4 NAT is used today, like SOHO networks.  Hopefully then the 
carrot is there for those users/developers/sites/ISPs that want to take 
advantage of that.   

-- 
Tim