>With my changes (untested so far) you don't call into the ipsec
>code unless there are SPD's active. So I think that you get the
>benefit of not being penalized of having IPSEC compiled into the
>kernel if you are not using it. 

hi Christos,

What I was trying to say last time boils down to:

I think it's best to put the test for "no IPsec active, therefore none
needed" directly into ip_input() and ip6_input().

I'm not sure about forwarding, I'd have to look.  If dimming memory
serves, the API from ipsec[46]_in_reject() *always* returns a non-NULL
policy, so what you'd want is to check for only the default policy
existing, and if so, skip all the ipsec*_in_reject goop completely.

That way, you might be able to still set the M_FASTFORWARD label in
the packet tag. (Which, reading ahead, turns out to be probably what
Thor wants.)

OTOH, once we start on that route, if it were up to me, I'd define a
tiny API with inline functions to test for "no IPsec or default-only
IPsec in effect".

That way FAST_IPSEC and ex-KAME IPsec could use the same API for the
test, and thus hopefully share one block of code. (The inline
functions isolate any differences in global-variable names, expected
values for "no IPsec active", etc).

I once intended to unify the ifdefs for IPsec in much the way
FreeBSD has done, so that what's now two sets of tests would (almost)
all become:

	#if defined(IPSEC) || defined(FAST_IPSEC)
		... code which calls common API into whichever IPsec
		was configured at config-time
	#endif

that approach becomes much more feasible, now that we have a sane,
unified struct in_pcbhdr.  All the pointer-chasing from pcb to socket,
and then (three functions later) back again, in all those

	switch (so->so_proto->pr_domain->dom_family) {
   
fragmets, to discriminate IPv4 PCBs from IPv6 6to4(?)[*] PCBs, really
should go away, and (now that pcbhdr lets us disambiguate IPv6 traffic
from IPv4), we should go back to passing PCBs around, instead of
passing sockets, and following pointers as in the line I quote above.

I'd welcome constructive comments on that idea.

[*] That is, the code with the somewhat-cryptic comment:

 * NOTE: IPv6 mapped adddress concern is implemented here.

which is, I beleive, what broke last time I tried this particular code
reorg.