In message <20060222050832.GA12831@panix.com>,
Thor Lancelot Simon writes:

>On Tue, Feb 21, 2006 at 09:08:43PM -0500, Christos Zoulas wrote:
>> On Feb 21,  3:50pm, thorpej@shagadelic.org (Jason Thorpe) wrote:
>> -- Subject: Re: IPSEC in GENERIC
>> 
>> Here's a patch to provide a fast path for both IPSEC and FAST_IPSEC.
>> The IPSEC code works fine. The FAST_IPSEC prints errors, but the code
>> has been rotting; i.e. it does not even compile with other IPSEC options
>> such as IPSEC_NAT_T.
>
>That's an unfair characterization; the author of the IPSEC_NAT_T code
>chose to implement it only for the KAME stack.  

Yes, exactly.  But christos' way of putting that seems awfully easy to
read as an attack on FAST_IPSEC. I can't tell if it was meant that way
or not. If blame is being apportioned over IPSEC_NAT_T (and that's
what the above looks like), I'd point at least *some* at the
implementor who chose to do IPSEC_NAT_T only for KAME IPSEC.


>None of the other IPSEC_X
>or IPSEC_Y options are relevant to the FAST_IPSEC stack at all 

I originally wondered if Christos is under the misapperhension
that IPSEC_NAT_T, IPSEC_ESP, et al. are "options" for both (KAME) IPSEc and
FAST_IPSEC?

>and it is
>well documented that you can't have both in your kernel.
>
>There are many users of the FAST_IPSEC code, including a number of
>machines run by The NetBSD Foundation itself.


Yes, but from that, I conclude those machines don't use or require
IPv6 with IPsec?  I seem to recall rumoure problems with FAST_IPSEC
and strict-alignment machines.

Aside from NAT_T (mentioned above) and the well-known lack of IPv6 IPsec
support (due to absense of IPv6-fans willing to acutally do the work),
what's FAST_IPSEC missing?