Thank you, Theo, for the history and clarification. It's always good to hear stories like this.
I'm building a IPv6 lab and I was trying to figure out fact from fiction. On Wed, Feb 24, 2016, at 11:58 AM, Theo de Raadt wrote: > > I've been reading about IPv6 and the KAME project. > > > > I read that OpenBSD integrated just IPv6 code rather than both (having > > developed their own IPSec stack). > > > > The information that I'm reading is from 2004. Does anyone who if this > > is still true? > > KAME had a v6 stack that included ipsec. On the other hand, some of > their routing logic was highly immature and incomplete, and would have > mirrored code that was already in the BSD kernel. > > In OpenBSD land, an IPSEC stack was already far in development, by > angelos; > it was a packet defer architecture that could work with hardware crypto > engines, and used the standard routing table for policy decision logic. > > There is a third part to the story. Craig Metz bad adapted the routing > logic in the kernel to make it v6 ready. itojun recognized merging of > these codebases as a good direction forward. > > So itojun, cmetz and angelos came up with a plan to merge the right > parts together and started it, then a bit later over a week the job > was completed at the first openbsd hackathon in my house, Jun 4 - 6, > 1999. (Oddly, I now believe it was longer than 3 days, but it is hard > to remember 17 years back). > > We believe that day was the first time ipv6 worked in a full official > operating system, and same with ipsec, and same with ipsec over ipv6 > (i recall that being a lot more flaky, but it was early days). Other > ipv6 work by other teams had just been "testbeds", not fully targetted > towards complete integration and shipping. > > Off in FreeBSD land, a bit later, they were connected to different > members of the KAME team, and instead opted to integrate KAME v6 + > ipsec as-is. About 10 years later, they saw the light and integrated > angelos's ipsec stack as well as an option, probably because it the > crypto offload / cpu crypto instruction awareness (which is largely > due the ability of the forwarding path to defer packet crypto job in a > staged forwarding path, which I convinced angelos to build in support > of how hardware engines would work). A few years ago they finished > that switchover. > > that help?
