PF import FAQ [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/netinetin4_cksum.c]

[Max Laier]

Hi,

to answer some of the questions and concerns raised in the discussion here 
(and in private mail to me):

Q: Does that mean ipfw(6)/ipfilter will be removed?
A: Not if I have to decide, which I have not ... luckyly.

Q: Why for haven's sake do we include another firewall?
A: Because we can! Fact is, that addition of pf does not mess any existing 
   code. It is encapsulated inside the pfil(9) api and could be maintained 
   as third-party code in the ports-tree. Still, it is my belief that the 
   addition of pf to the base system has benefits: Possible to build it in 
   the kernel (which is somewhat comforting for a firewall), it will be 
   catched by tinderbox builds (i.e. track changes in the kernel api) and 
   so forth. It boils down to: It's just more convenient for both user and 
   developer!

Q: Are there plans to unify the firewalls/create *the* firewall?
A: No. It seems there are plans to glue ipfw with it's IPv6 part (see 
   Luigi's msg on this thread before), but there will not be one unified 
   kernel firewall thing doing all of ipfw/ipf/pf/... in near future.
   Keep in mind that every firewall has it's own (dis)advantages, some in 
   implementation which can be lifted, some in design and that it is the 
   differentses between them that make them especially useful for a
   certain job. Choice is the key here.

Q: Will ALTQ and/or CARP come as well?
A: Both is on my list, but not with a high priority or ready-made plans. 
   It is ture that pf gains a lot from coupling with ALTQ and CARP rounds 
   that up even more, still I like to take one step at a time and the 
   current step is pf. If you are curious about ALTQ check out the altq 
   project at rofug: http://www.rofug.ro/projects/freebsd-altq/

Q: Will there be a NO_PF knob?
A: Definitely! The build infrastructure will not be too different from
   what ipf does now.

Q: What are the technical arguments for pf again?
A: Activ development! State of the art feature list, steadily increasing. 
   High performance stateful inspection, stateful (in-kernel) NAT/redirect 
   and load-balancing, DoS prevention (synproxy, per-rule/-state limits), 
   flexible "high-level" syntax, structured rulesets with anchors, dynamic 
   address tables w/ O(1)-lookups, highly customizable logging with full 
   payload, mature IPv6 support and many many more ...
   Futur version will bring failover, with keeping states and other 
   enterprise level solutions.

-- 
Best regards,				| mlaier at freebsd.org
Max Laier				| ICQ #67774661
http://pf4freebsd.love2party.net/	| mlaier at EFnet