NETFILTER_XT_TARGET_NOTRACK

NETFILTER_XT_TARGET_NOTRACK

[Jean Delvare]

Hi all,

I have a concern / question / suggestion regarding
NETFILTER_XT_TARGET_NOTRACK.

Currently, NETFILTER_XT_TARGET_NOTRACK merely selects
NETFILTER_XT_TARGET_CT, and does nothing else. This means that selecting
or not selecting NETFILTER_XT_TARGET_NOTRACK makes no difference, as
long as NETFILTER_XT_TARGET_CT itself is set.

I seem to understand that NETFILTER_XT_TARGET_NOTRACK was reintroduced
in kernel 3.8 to help migration to NETFILTER_XT_TARGET_CT. I understand
the logic, but this was 7 kernel versions / over 2 years ago. Wouldn't
it be the right time to finally remove NETFILTER_XT_TARGET_NOTRACK?

Alternatively, I find it curious that the compatibility code is
unconditionally built into xt_CT even when NETFILTER_XT_TARGET_NOTRACK
is not selected. Is it an overlook, or is it by design? I think it would
make sense to only build that compatibility code when
NETFILTER_XT_TARGET_NOTRACK is selected. In that case it would make
sense to keep NETFILTER_XT_TARGET_NOTRACK.

Thanks,
-- 
Jean Delvare
SUSE L3 Support

Re: NETFILTER_XT_TARGET_NOTRACK

[Pablo Neira Ayuso]

On Thu, Apr 10, 2014 at 02:05:11PM +0200, Jean Delvare wrote:
> Hi all,
> 
> I have a concern / question / suggestion regarding
> NETFILTER_XT_TARGET_NOTRACK.
> 
> Currently, NETFILTER_XT_TARGET_NOTRACK merely selects
> NETFILTER_XT_TARGET_CT, and does nothing else. This means that selecting
> or not selecting NETFILTER_XT_TARGET_NOTRACK makes no difference, as
> long as NETFILTER_XT_TARGET_CT itself is set.
> 
> I seem to understand that NETFILTER_XT_TARGET_NOTRACK was reintroduced
> in kernel 3.8 to help migration to NETFILTER_XT_TARGET_CT. I understand
> the logic, but this was 7 kernel versions / over 2 years ago. Wouldn't
> it be the right time to finally remove NETFILTER_XT_TARGET_NOTRACK?
>
> Alternatively, I find it curious that the compatibility code is
> unconditionally built into xt_CT even when NETFILTER_XT_TARGET_NOTRACK
> is not selected. Is it an overlook, or is it by design? I think it would
> make sense to only build that compatibility code when
> NETFILTER_XT_TARGET_NOTRACK is selected. In that case it would make
> sense to keep NETFILTER_XT_TARGET_NOTRACK.

Recent iptables versions use the alias infrastructure so NOTRACK is
mapped to CT internally. We can probably wait a bit more before we get
rid of that old compat code. Frankly, the NOTRACK part is quite little
code actually and very simple, so we don't get much from removing it
but problems (as we may break compatibility for old iptables userspace
binary versions with no aliasing infrastructure).