[GSoC] L2TP pseudo device

[Jordan Gordeev <jgordeev%dir.bg@localhost>]

I've been looking at the "Create a L2TP (RFC 2661) pseudo device" 
proposed Google Summer of Code idea.
I want to share some of my thoughts with you and hear your opinion.

When implementing L2TP, there are two primary desirable characteristics 
- 1) performance and 2) flexibility. It's natural to want to divide the 
implementation into two components - one userland and one in the kernel, 
where the userland component ensures flexibility and the kernel 
component ensures performance. A third desirable characteristic is 
generality - i.e. applicability to other PPP-carrying mechanisms, such 
as PPPoE.

Here's my first idea for design of an L2TP implementation:
   All network-layer protocols are handled by the kernel.
   All control protocols (LCP, other link-layer control protocols, 
NCP's like IPCP, IPV6CP, etc.) are handled by a userland program.
   The userland program uses a socket (or a character device) to send 
and receive control-protocol packets. These control-protocol packets 
will appear on the kernel/userland socket interface as PPP frames.
   The kernel component and the userland component will need to 
interact - the userland component will send commands to the kernel 
component and the kernel component will send event notifications to the 
userland component.
   I believe it's a good idea to use the same socket, that is used for 
control-protocol packets, for commands/event notifications too. A 
special "NetBSD L2TP Control Protocol" can be invented for this purpose.

Having the userland application handle all control-protocol packets has 
the disadvantage of even the simplest requests - LCP Echo-Request's - 
going from kernel to userland and back, with the overhead this incurs. 
It would be nice to have at least some parts of some control protocols 
handled in the kernel. This leads to the second design idea:
   All network-layer protocols are handled by the kernel.
   Some control-protocol packets are handled by the kernel.
   Some control-protocol packets are handled in userland.
   The division of responsibilities between the kernel and userland is 
fixed.
   The control-protocol packets handled by the kernel are those, for 
which "imagination" or access to external resources (e.g. RADIUS 
servers) is not required.

This idea can be extended to the third design idea:
   All network-layer protocols are handled by the kernel.
   Some control-protocol packets are handled by the kernel.
   Some control-protocol packets are handled in userland.
   The division of responsibilities between the kernel and userland is 
dynamic.
   The userland application can get more responsibilities, or off-load 
responsibilities to the kernel, whenever it wishes.

In my opinion, the best mix of performance and flexibility is achieved 
in the second design idea, although I like the other ideas too.
Do you like the second idea the most?
Have you got any suggestions you want to share?

Regards,
   Jordan Gordeev