cvs commit: src/sys/contrib/pf/net if_pflog.c if_pflog.hif_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

[Andre Oppermann]

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.

Full double ACK!

-- 
Andre

> 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.
> 
> cheers
> luigi
> 
> > eventually phased out after a few releases. With the exception of dummynet,
> > this should be fairly straightforward.
> >
> > If you're worried about the size of the base system, there are plenty
> > of other rarely-used features that could be removed to "make room" for pf.
> >
> >
> > Tim