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

[Luigi Rizzo]

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.

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