cvs commit: src/sys/contrib/pf/net if_pflog.c if_pflog.h if_pfsync.c if_pfsync.h pf.c pf_ioctl.c pf_norm.c pf_osfp.c pf_table.c pfvar.h src/sys/contrib/pf/netinet in4_cksum.c

[Sam Leffler]

On Feb 26, 2004, at 1:50 AM, Luigi Rizzo wrote:

> for what matters, i have posted to -net patches some time ago to extend
> ipfw2 to deal with ipv6 packets (thus effectively replacing ipfw6).
> No feedback in 6 weeks, to me this looks like lack of interest.
>
>> problem of having too many firewalls. What I'd like to see is ipfw,
>> ipfilter and ip6fw implemented in terms of the pf kernel code, then
>
> what is the motivation for that ? Features ?
>
> To me there is no clear winner.
>
> Honestly, i believe that the microcode-based approach of ipfw2 is
> a lot simpler to maintain and extend than the one used in pf
> (which resembles a lot the original ipfw), and dropping it would
> be a step backward.
> ipfw2 has some instructions (e.g. the 'address set') that greatly
> simplify the writing of rulesets.
>
> A definite plus in 'pf' is the in-kernel nat support, but that
> could be ported to ipfw2 with approx the same effort needed to port
> dummynet to pf.
>
> So, I'd say the ideal firewall would have the ipfw2 microcode-based
> rules and dummynet, and pf's NAT. I don't care what we call it, the
> point is that some work is needed in both cases.

I agree with Luigi about much of this.  I'm happy to see pf brought 
into the tree because it's actively being developed and folks look to 
be using it (it looks to me like it's going to become the most often 
used filtering package for folks with *bsd systems).  However I think 
the "microcode-based" architecture used by ipfw2 and the BSD/OS ipfw 
code are a better design.  I also worry that pf is bloating as people 
leverage it to do many things only semi-related to packet filtering.

	Sam