Re: Time to let go of ipfilter

[Sascha Wildner <saw@xxxxxxxxx>]

y=ZG@mail.gmail.com>
In-Reply-To: <AANLkTik=S5O1DA78ObwEJ-paiUTdV5vEUM7LOym1y=ZG@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Lines: 26
NNTP-Posting-Host: 87.78.98.243
X-Trace: 1295699533 crater_reader.dragonflybsd.org 886 87.78.98.243
Xref: crater_reader.dragonflybsd.org dragonfly.kernel:14843

On 1/22/2011 10:04, Edward O'Callaghan wrote:
> I agree, however I have no doubt it will be added soon since this is
> also a limitation for NetBSD usage of NPF as well.. more my point, +1
> to EOL'ing older solutions that are no longer maintained or scalable.
> One of the things that I myself consider a 'feature' of Dragonfly is
> less old junk running in kernel space (both important on a security
> and stability stand point) and a less bulky userland.

Nothing is bulkier because of ipf or any other non-pf filter, since you 
will get it only if you specified it in your config, and it isn't the 
default.

We really shouldn't argue from some simplifying black and white "new == 
good, old == bad" standpoint here.

Apparently Joris has his reasons to use ipf and we have to see if pf (or 
ipfw2) cuts it for his setup. Likewise, others are still using ipfw2 for 
one technical reason or the other. See what Matt pointed out, for one, 
and I've also heard that it's faster (from other people).

I'm not saying we must keep ipf (and I'd rather say not), but the 
decision whether to keep it or nuke it should not be made based upon its 
age (at least as long as it works, which apparently it does), but rather 
upon whether pf is suitable for these scenarios instead.

S.