Date: Thu, 26 Feb 2004 21:11:14 -0800 From: Sam Leffler <sam@errno.com> To: Luigi Rizzo <rizzo@icir.org> Cc: Tim Robbins <tjr@FreeBSD.org> Subject: Re: 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 Message-ID: <5D79345A-68E3-11D8-AE91-000A95AD0668@errno.com> In-Reply-To: <20040226015016.B23674@xorpc.icir.org> References: <200402260234.i1Q2YDx1014240@repoman.freebsd.org> <20040226060126.GA70201@troutmask.apl.washington.edu> <20040226080517.GA29763@cat.robbins.dropbear.id.au> <20040226015016.B23674@xorpc.icir.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5D79345A-68E3-11D8-AE91-000A95AD0668>