On Feb 21, 12:55pm, jonathan@dsg.stanford.edu (jonathan@dsg.stanford.edu) wrote:
-- Subject: Re: IPSEC in GENERIC

| 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.)

Thanks, that is what I am doing.

| 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) {

Yes, this is what rui is working on (merging inpcb/in6pcb).

| 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.

We all agree, so this change should not be controversial.

christos