[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: The argument for writing a general purpose NAT for IPv6
On Apr 18, 2007, at 07:03, Wesley Eddy wrote:
On Wed, Apr 18, 2007 at 10:20:08AM +0200, Brian E Carpenter wrote:
I am confused.
If the issue is stateful packet filters the solution is
to be able to configure them off for specified hosts. I can't
see why transport proxies are needed (as far as you describe them,
they exist *because* the IPv4 box is a NAT, not because it
contains stateful filters).
The transport proxies don't exist just because the IPv4 box is a
NAT. They would need to be there even if the box implemented IPv4
stateful packet inspection/filtering without NAT. Let me outline the
logical flow:
1) SPI -> ALG
2) ALG -> transport proxies
3) transport proxies -> NAT
therefore
4) SPI -> NAT
We will never need NAT for translating between global and private
IPv6 address realms. That's not at issue. However, we *do* need NAT
for transparently redirecting IPv6 flows into transport proxies to
implement application layer gateways to permit stateful packet
inspection filters to keep from breaking Internet applications.
I think I agree. It looks like James is saying that *in his code*,
implementing IPv6-NAT is the easiest way to re-use existing upper-
layer
packet inspection code in order to poke holes in the firewall. I
don't
think that this in any way applies to implementations in general.
This is true to a point. Unfortunately, there isn't anything
particularly special about my implementation. If you looked at the
source code, you'd see it's very similar to other implementations
widely deployed on the Internet today.
It's also true that some applications, e.g. RealPlayer comes to mind,
are just not easily handled without using transport-layer transparent
proxies. I've implemented ALG's for that using both methods, i.e.
network-layer packet inspection and transport-layer proxy, and 1) the
difference in engineering costs to maintain them is stark, plus 2)
the transport-layer proxy is more functional because it doesn't break
when headers are split across multiple TCP segments, as sometimes
happens.
I believe he's only said that this seems like the path of least
resistance in his code, but I don't think he's said that it would be
impossible to re-use his packet inspection code through some other
means
without implementing IPv6-NAT, but I may have missed something.
Not impossible, but many will find it prohibitively expensive and
difficult.
What I hope the V6OPS group will take away from this discussion is
the awareness that, if my engineering management is thinking that
implementing IPv6-NAT is worth doing to make application layer
gateways function properly, then others may too. If there is a goal
to make IPv6-NAT an unnecessary tool and a waste of resources to
develop, then that goal is *not* being met.
--
j h woodyatt <jhw@apple.com>