>At present, the PFIL_HOOK code is somewhat confined to the ipv4 protocol.

	netinet/{ip_fil.c,fil.c} is very IPv4 dependent.  Have you decided
	to tackle it?

>In discussions with phone, we tossed around some ideas for being able to
>setup filters based on this protocol and that protocol (of most interest
>at present is IPv4/IPv6).  Passing flags and values to do this and that
>would solve the problem, but perhaps not in the best fashion possible.
>
>In the end, the idea of having each protocol have its own input/output
>filtering lists seemed to be the best.  This would be implemented by
>adding a new pfil struct to both struct protosw and struct ip6protosw
>which contained private list heads for at least both input and output.
>This sets up the possibility of using pfil in other protocols (non-inet
>or things like udp, etc).

	I believe using bpfilter (for packet capturing specification) is
	extensible and looks nice.  Userland configuration program would
	compile a BPF expression into BPF bytecode, and passes it down to
	the kernel as filtering expression.  BSDI4 is doing this.
	I would like to explore this direction but have no time for this yet...

>Once the method for extending to IPv6 is decided on, the problem of where
>to add filtering hooks needs to be addressed.  Having spent some time
>looking at it, I think the correct hooks need to be added at about line
>292 of ip6_input.c (after the version check, but prior to any scope checks).

	I believe the above location is fine.  in KAME code we have ip6fw
	(IPv6 filtering code based on FreeBSD IPv4 ipfw code) hook there.

>Once this gets finalised, can we get the pfil changes put back into the
>KAME mainline (with #ifdef PFIL_HOOK, of course) ? :-)

	Of course that is possible.

itojun