In some email I received from Chris G Demetriou, they wrote:
[...being busy and just getting back to reading this...]
> To do packet filtering via hacks to bpf, you'd have to rearrange
> things so the input path looks like:
> 
>   le0 input -> bpf_{,m}tap -(if not blocked)-> ether_input
> 	       |         ^
> 	       |         \-----------------+<-- post-blocker filters -\
> 	       |                           ^       		      |
> 	       |       	       	       (if blocked)		      |
> 	       |                           ^    		      |
> 	       \--> pre-blocker filters -> blocker -(if not blocked) -/
> 
> with a similar flow of control on the output side.

I have avoided filtering packets at such a low level for a couple of
reasons:

	(a) the various protocol sanity checks haven't been performed so we
	    may be wasting CPU on filtering a bad packet (and even come to
	    an incorrect answer);

	(b) by introducing delays in the ethernet driver where the taps to
	    bpf are already, adding an IP (only) filter introduces delays to
	    other protocols (such as ethertalk) which may be in use.

[...]
> One objection that i have to a packet filtering mechanism that's not
> tightly integrated with BPF is that it's much harder (or perhaps even
> impossible) to get access to packets on _both sides_ of the filter...

Well, not for IP...

Whilst bpf makes it possible to filter on protocols other than IP, I've
yet to see anyone desire to filter on anything else.  This allows the IP
filter to be tailor made, rather than needing to use something like BPF
and add on extras.

darren