On Feb 22, 12:22pm, jonathan@Pescadero.dsg.stanford.edu (Jonathan Stone) wrote:
-- Subject: Re: IPSEC in GENERIC

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

I was under that misapprehension until I tried to compile, failed and
then read the code.

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

IPSEC_ESP? I don't know.

christos