On Oct 1, 12:24pm, Peter Postma wrote:
}
} I'm pleased to announce a new port of the OpenBSD 3.5 packet filter (PF)
} to NetBSD 2.0. Unfortunately not a complete port, ALTQ is missing, dynamic
} addresses aren't supported and some small parts aren't ported/supported yet.

     I'm somewhat behind on my e-mail and haven't been following this
thread, but I've beem meaning to comment on this for a long time.  I
believe that one of the things that OpenBSD has done is to smash ALTQ
into PF including going so far as to use a combined configuration
file.  I think this is a very bad idea.  By the same token, I think IPF
has some problems as well due to the fact that its rules specify
interfaces.

     I think what we really need to do is to seperate packet
classificaton from operation ala Cisco IOS.  We're getting more and
more things that need packet classification.  Filtering, IPNAT, IPSec
(there are two implementations of this), and QOS are just a start.
There could be more things in the future such as policy routing (there
already is some of this in IPF with its fastroute option), and
selection of "interesting" traffic to automatically bring up a PPP
link.  Given that there are so many uses for packet classification and
at least two classification engines, I think it is a grave mistake to
have packet classification tied into operations on packets.

     The way things are done in Cisco IOS is that you define an "ACL"
then you apply that ACL to some operation (i.e. filtering packets going
in or out of an interface, limiting SNMP connections, route filtering,
selecting "interesting" traffic to bring up a dynamic link, etc.).
Unfortunately, the seperation isn't totally clean, since things like
"keep state" need to see the traffic travelling in both directions.
However, I think this is the way we should be heading.

}-- End of excerpt from Peter Postma