Re: [GSoC] L2TP pseudo device

[Darren Reed <darrenr%netbsd.org@localhost>]

Jordan Gordeev wrote:
> 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.

ok but you are aware of NetBSD already supporting pppoe, aren't you?


> 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.

ok

>    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.

ok

>    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.

ok

>    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.

I disagree. This should be another type of socket.
But I can also see it being desirable to have both packet types on the 
one socket so that ordering is preserved.

You may wish to think about different socket types or protocol types for 
a given address family of a socket with there being a "wildcard" to let 
you receive all.


> 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.

What are your thoughts on the latter point?
How would you design a mechanism to implement that without making it 
specific to this project?

Darren