Re: kern/44843: IPSEC in kernel make IPPROTO_ESP and IPPROTO_AH unusable

[matthew sporleder <msporleder%gmail.com@localhost>]

The following reply was made to PR kern/44843; it has been noted by GNATS.

From: matthew sporleder <msporleder%gmail.com@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: Paul Koning <paul_koning%dell.com@localhost>, 
kern-bug-people%netbsd.org@localhost, 
        gnats-admin%netbsd.org@localhost, netbsd-bugs%netbsd.org@localhost
Subject: Re: kern/44843: IPSEC in kernel make IPPROTO_ESP and IPPROTO_AH 
unusable
Date: Fri, 8 Apr 2011 13:50:03 -0400

 > =A0IPSec uses those two protocols; if you tell NetBSD to implement them i=
 n =3D
 > =A0the kernel, why would you expect to be able to access them from =3D
 > =A0userland?
 >
 
 To force this choice at kernel-compile time is pretty extreme, in my opinio=
 n.
 
 My sample program works on other operating systems.  I don't know
 about their kernels as much as I do netbsd's, but I know I can install
 racoon on linux without needing a new kernel.  OpenBSD has options
 IPSEC in GENERIC and doesn't seem to have a problem.
 
 Is there another example of where enabling an option in the kernel
 disables a userland component in such a way?  options INET certainly
 doesn't exclude my ability to run a web server.
 
 I didn't see any mention in the options or ipsec man pages mentioning
 this impact.