>> 	and to share bpf code between kernel and userland.
>> 	(which is rather important, however, is not done so at this moment)
>Is there a person who is responsible for bringing in tcpdump/libpcap ?

	i'm not sure about it, but i feel part of responsibility.

>> 	just to make sure, please do not nuke cases where data is not on
>> 	first mbuf.  near-future IPv6 change (options PULLDOWN_TEST)
>> 	will choke.
>Hmmm ?  Why would this effect BPF calls ?  They're done from the drivers,
>not IPV6 ?  But this change sounds like it might affect IP Filter ?

	sorry, it is bpf and tcpdump that chokes on IPv6 packett.

	to make IPv6 processing easy, we at this moment set MINCLSIZE to MHLEN,
	effectively making drivers to pack packets like this:
	- single header mbuf (MHLEN) if len <= MHLEN
	- single cluster mbuf (MCLBYTES), or multiple cluster mbufs otherwise

	new code will behave just like traditional 4.4BSDdoes, so packets will
	be packed like this:
	- single header mbuf (MHLEN) if len <= MHLEN
	- header mbuf + normal mbuf (MHLEN + MLEN) if len <= MHLEN + MLEN
	- single cluster mbuf (MCLBYTES), or multiple cluster mbufs otherwise
	with the new code, upper-layer headers on a IPv6 packet would exceed
	the first mbuf easily.  if bpf code looks at first mbuf only, we will
	fail to catch IPv6 packet by bpf.

itojun