[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: CPE equipments and stateful filters



[ Added BEHAVE working group. ]

On Jul 27, 2007, at 19:44, Fred Baker wrote:
[...] Alain's comment in the plenary Thursday evening that James  
document and my comments on this list advocate NAT are, in the best  
possible case, incorrect - nobody is talking about NAT in IPv6,  
although I do believe that there will be places that network  
operators choose to use that class of capability. In the worst  
case, it constitutes a deliberate misstatement calculated to cause  
confusion and troll for a flame war in this venue. I choose to  
believe the former, although I ask myself the question. [...]
I wasn't present for the plenary, so I don't know what M. Durand  
said, but let me clarify my position, which I believe is best  
characterized as a "warning that we have not quite succeeded in  
making NAT obsolete" with IPv6.
The need to implement what I am now calling "application transparency  
helpers," which function like ALG modules in an IPv4/NAT firewall,  
but which only help control transport filtering state in response to  
application protocol content without actually coordinating any UNSAF  
function like an ALG does, is a vector by which NAT implementations  
may worm their way back into the IPv6 architecture.
I'm currently looking at source code in OpenBSD PF that appears  
designed to use IPv6-NAT to redirect application flows to userland  
proxies for exactly this purpose.  IPv6 support for an FTP  
"transparency helper" is on my list of things I expect to need, and  
using an IPv6 NAT to redirect FTP control flows in and out of my  
existing IPv4 FTP proxy looks like the obvious shortest path to  
working code.  (Similar things will need to be done with all the  
other major application protocols.)
If IPv6 NAT were truly obsolete, this wouldn't be the case, but it  
is.  Hence, my warning.
Coming away from IETF 69 in Chicago, I'm now convinced that IETF will  
not be revisiting its consensus that the public IPv6 internet is  
intended to be clients behind multiple layers of firewalls  
communicating mainly through mediation services in data centers.  I'm  
certain my employers will have no trouble adapting to this reality.
I'm no longer certain that IPv6 will ever be a suitable replacement  
for IPv4/NAT in residential settings, but I see reasons to be hopeful  
that all is not lost on that account.

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