>       from IPv6 support point of view, PF is much better than IPFilter.
>	IPFilter passses around pointer to the head of the packet, without
>	passing around length, therefore is more vulnerable to programming
>	mistakes (it might have been okay when IPFilter was IPv4-only, but
>	with IPv6 you have different header length for each packet).
>	PF always pass around struct mbuf *, therefore length is always
>	passed around.  also, with PF internal structures are protocol-
>	independent (well, only for IPv4/v6) so it is easier to provide
>	the same set of functionalities to IPv4 and IPv6.

While it might look like it, it does more than just that.  If you cared
to look at what is "current" IPFilter code, you'd see that the interface
has changed throughout the code and even become "normalised" in a manner
that almost suggests a real design (it hasn't been so I won't claim it.)

This sounds like one of those comments from the openbsd "experts" on
IPFilter code that managed to reimplement many of the problems/bugs I
had worked around.

Where do you suppose they got all the ideas for pf from, anyway ?

Try RTFS for IPFilter some day and closely, not just from the top
of a 100 storey building.

FWIW, the only reason there isn't NAT for IPv6 in IPFilter is the
lack of native 128bit types.  Why is that a problem for IPFilter and
NAT ?  Because unlike pf, the NAT in IPFilter is capable of doing
more than just N:1 NAT, and in many different ways, that use maths on
native 32bit types (ie IPv4 addresses), which simply isn't easily
done for IPv6 (yet).  I have no intention of making IPv6 NAT available
in a manner that makes it any less capable than what is available for
IPv4 when I do.