Re: Comments on the NAT66 draft

[james woodyatt <jhw@apple.com>]

On Nov 10, 2008, at 07:26, EricLKlein@softhome.net wrote:
> [...] Now people are trying to revive the patch known as NAT into v6  
> when it is still not clear why they are needed beyond "that is how  
> we always did it" solutions.  If RFC 3879 and RFC 4864 are not  
> detailed enough as to why local only addresses are not part of v6  
> lets do a proper need and gap analysis and then design a solution to  
> what is really needed.

As I have periodically tried to remind everyone, there is a usage  
scenario for NAT in IPv4 that is not addressed by RFC 3879 or RFC  
4864, and it remains in my view the one compelling reason for  
specifying how NAT66 should work.  That scenario is the one where  
stateful packet filtering for application flows is transparently  
inserted on paths into and out from enterprise networks using an  
address translation to redirect flows at border routers to the  
application-filtering middleboxes.

You can imagine doing that without address translation, i.e. with  
tunnels and redirects, but that raises practical issues with path MTU,  
and it just moves the address translation from the insertion point to  
the application helper.  You've still got the translation and the  
potential for transparency loss that comes with it.  It's important to  
remember that people deploying systems like this tend to view end-to- 
end integrity as a bug rather than a feature, and the introduction of  
potential for transparency loss is the whole point of the exercise.   
If doing it with NAT66 instead of tunnels and redirects makes  
practical sense to enterprise network operators, and I think it does,  
then I assure you... that's how it will be done.

As much as I would like to believe that enterprises will stop feeling  
the need to deploy this kind of nonsense, I'm very skeptical that IETF  
will be able to change their minds.  If we're going to have  
middleboxes that intercept and process IPv6 application flows, then I  
don't see how NAT66 or something like it can be avoided.

That said, I'm not impressed by the arguments put forward by the  
opponents of RFC 4864 local network protection who, in my view, are  
greatly exaggerating the seriousness of the network renumbering  
problem.   My response to that concern is that any organization too  
small to win a PI allocation and too poor to bear the almost  
negligible expense of renumbering an IPv6 network [much smaller than  
renumbering an IPv4 network] is an organization with more serious  
problems than its difficulty in changing its Internet service  
provider.  I don't see why such organizations should have much  
standing here, and I think we should ignore them while we have more  
important problems to solve, e.g. IPv4-IPv6 coexistence matters.


--
james woodyatt <jhw@apple.com>
member of technical staff, communications engineering