nf_conntrack & NAT

[Harald Welte]

On Tue, Dec 06, 2005 at 06:31:35PM +0100, Herve Eychenne wrote:
> > for stuff like redirecting traffic, all you really need is stateless
> > rewriting of the destination address.  If people want that, the entire
> > implementation fits in a single ip6tables target.  no relation to
> > nf_conntrack at all.
> 
> Stateless?  And what if you want the response (of the packets which have
> been redirected) to come back with their initial address, as if they
> had not been redirected? (if the client shouldn't know that, if this
> should be transparent to him)

then you need a static snat target that does this for all reply packets.

> This is also known as DNAT, for which the state has be stored, right?

you don't really need state unless you want to do stuff like dynamically
changing port numbers, etc.

> So, in one word: if we definitely need DNAT with IPv4 today, why
> wouldn't we need DNAT with IPv6?

stateful IPv6 NAT only over my dead body.  Do you know that NAT is the
single most destructive way that ever happened to todays internet?  That
it is the number one reason why VoIP doesn't really take off as much as
it could?  The number one reason for various non-deterministic breakage
all over the place? 

I've participated in the IETF BEHAVE group discussions, and there was
concensus that any BEHAVE compliant NAT must not do NAT for ipv6.
 
> > also, IPVS doesn't need any ip_conntrack/iptable_nat today,
> 
> I don't know IPVS implementation, but maybe the IPVS-NAT method could
> theorically share some code with the current NAT code... (they both
> seem to handle the same kind of state table, even if at least the hashing
> algorithm could probably be different, I guess)

*sigh*.  IPVS doesn't use ip_conntrack, so they won't be using
nf_conntrack.  Also, it's their project and their decision.

-- 
- Harald Welte <laforge at netfilter.org>                 http://netfilter.org/
============================================================================
  "Fragmentation is like classful addressing -- an interesting early
   architectural error that shows how much experimentation was going
   on while IP was being designed."                    -- Paul Vixie
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : /pipermail/netfilter-devel/attachments/20051207/b8864acb/attachment.pgp