Subject: Re: Reminder that we are supporting two parallel IPsec implementations
To: Jonathan Stone <jonathan@DSG.Stanford.EDU>
From: None <firstname.lastname@example.org>
Date: 09/12/2003 07:33:45
>A gentle reminder that we currently have two independnet IPsec stacks
>in the tree: the original KAME code, and a port of Sam Leffler's fast-ipsec
>(which is in turn a careful re-tuning of Angelos Keromytis' OpenBSD work).
>Fast-ipsec has been carefully implemented to preserve the existing
>KAME PF_KEY api. The assumption in committing fast-ipsec was that we
>would preserve the PF_KEY api until fast-ipsec has working v6 support,
>at which point I assume we cut over to fast-ipsec).
>(I beleive I stated here that, all along, an eventual goal for
>fast-ipsec is to make its impact on non-IPsec traffic negligible (at
>least when no SPD rules are present) so that we can confgure it on
>by. default. That implicitly less means the IP portion of the KAME
>stack has, at best, second-best status.)
>Anyway ... if we go down that route, then during the transition
>period, changes to the PF_KEY API have to be synchronized across both
>IPsec implementations. Ad-hoc changes to the PF_KEY api (or abi) in
>one will likely break the other.
>Can we agree to not do that?
i don't understand why sys/netipsec has to have another PF_KEY
implementation. could you tell me why?