Re: nf_conntrack & NAT

[Harald Welte <laforge@netfilter.org>]

[-- Attachment #1: Type: text/plain, Size: 1418 bytes --]

On Wed, Dec 07, 2005 at 08:00:39AM +0100, Patrick Schaaf wrote:
> For example, I use ipset bitmaps to determine, at conntrack-NEW-time,
> whether some connection should be REDIRECTed, or not. This decision,
> once made, should stay stable for the same connection, even if the
> ipset bitmap is modified wrt to another new connection between the
> same partners.

Patrick, whatever kind of special-case applications you might have, I
honestly don't care at this point.

The fundamental issue at this time is to get nf_conntrack
feature-complete with what ip_conntrack offers.  This allows us to get
rid of ip_conntrack and therby remove lots of duplicate code that was
only meant as an intermediate solution.

The other fundamental issue is that we don't want to extend the current
full-blown ip_nat/iptable_nat code to offer the same functionality for
IPv6.

So that's why nf_conntrack based stateful nat will be restricted to
IPv4.

If we later need something different for IPv6, then let's do that at
this later point.

-- 
- Harald Welte <laforge@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

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]