In message <20060221034924.5214F56534@rebar.astron.com>,
Christos Zoulas writes:

>On Feb 20,  7:35pm, jonathan@Pescadero.dsg.stanford.edu (Jonathan Stone) wrote
>:
>-- Subject: Re: IPSEC in GENERIC

[...]

>I see the summary of this thread as:
>
>1. The reason we don't turn IPSEC on by default is performance.
>2. There is FAST_IPSEC but it does not do IPV6.
>3. The KAME code is too complicated/messy and hard to separate.
>4. In order to do have the best of both worlds is to compile IPSEC
>   in and determine if we need to take the IPSEC complex path only
>   if the number of SPD's > 0 (which was proposed by you this round).
>
>Now can you (or someone else) step up and see if doing (4) is feasible?

Someone else I think, since I have approximately zero in the old
KAME IPsec code.  I can say that I beleive the approach I suggested is
workable, for locally-terminated traffic. I don't recall making any
measure of forwarding rates myself, which is the case Thor brought up.

As I tried to say earlier: right now I'm more interested in turning
off IPv6 on the machines I have with GENERIC kernels, so that those
machines don't automagically start using IPv6 for local-subnet
communication behind my back.  That, I care about, whereas IPsec in
GENERIC I don't much care for.


In all honesty, in the local marketplace, I hear an awful lot of need
for "Cisco VPNs", "SSL VPNs", pptp, and almost no demand for IPsec.
The instructions I saw (Hubert's, I think, from Feb 2004?), for
configuring "Cisco VPN"s access say that one must first disable IPSEC
if it's configured, then add tun.  These days, tun is on in most 3.0
GENERIC configs.

So, in all sincerity and thinking of just my local neck of the woods,
and assuming Hubert's caveat about IPSEC is still accurate, I'd tend
to think NetBSD might get more utility from excluding IPsec and
keeping tun, than from adding IPsec.  Then again, maybe things are
very different where you are, or where Michael is.

Worth considering both ways, though.


>christos