[RFC PATCH 0/8] l2tp: introduce L2TPv3 support

[RFC PATCH 0/8] l2tp: introduce L2TPv3 support

[James Chapman]

This patch series implements L2TPv3. It replaces the existing pppol2tp
driver with a number of separate drivers, namely:-

l2tp_core    - L2TP driver core. Always required.
l2tp_ppp     - L2TP PPP
l2tp_eth     - L2TPv3 ethernet pseudowire
l2tp_ip      - L2TPv3 IP encapsulation
l2tp_netlink - L2TPv3 netlink API

The combination of l2tp_core and l2tp_ppp provides
backwards-compatible L2TPv2 pppol2tp functionality.

Except for Patch 6, these patches are not yet ready for the mainline
so don't have my signed-off-by sig. Recently added pppol2tp features
such as namespace support are still to be merged in. I am posting the
patches early to get some feedback before I spend too long
testing. The code is working in basic test setups.

The implementation is as I described in a previous posting to netdev,
archived at http://marc.info/?l=linux-netdev&m=120845482320143&w=4.

The patches are:-

1. Move the existing L2TPv2 pppol2tp driver from drivers/net into a
   new directory, net/l2tp.

2. Split the pppol2tp driver into separate L2TP and PPP parts. This
   is required for L2TPv3 since L2TPv3 can carry protocols other than
   PPP.

3. Add L2TPv3 core protocol support.

4. Update PPP-over-L2TP driver to work over L2TPv3.

5. Add L2TPv3 IP encapsulation (no UDP) support. This creates a new
   L2TPIP socket family. Userspace uses an L2TPIP socket instead of a
   UDP socket when IP encapsulation is required.

6. Small change to genetlink core to export genl_lock/genl_unlock.

7. Add userspace API for L2TPv3 using netlink. Userspace must manage
   L2TPv3 kernel tunnel/session configuration using netlink. The
   previous pppol2tp driver was managed using [gs]etsockopt(), which
   is retained for backwards compatibility. Netlink is used for L2TPv3
   because it is more flexible and the L2TPv3 kernel interface is
   quite complex.

8. Add ethernet pseudowire support. Each ethernet pseudowire has a
   net_device which may be managed by userspace tools.

--
James Chapman
Katalix Systems Ltd
http://www.katalix.com
Catalysts for your Embedded Linux software development 

Re: [RFC PATCH 0/8] l2tp: introduce L2TPv3 support

[Herbert Xu]

James Chapman <jchapman@katalix.com> wrote:
> This patch series implements L2TPv3. It replaces the existing pppol2tp
> driver with a number of separate drivers, namely:-
> 
> l2tp_core    - L2TP driver core. Always required.
> l2tp_ppp     - L2TP PPP
> l2tp_eth     - L2TPv3 ethernet pseudowire
> l2tp_ip      - L2TPv3 IP encapsulation
> l2tp_netlink - L2TPv3 netlink API

Have you thought by using the rtnl_link_ops interface instead
of your own netlink API?

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [RFC PATCH 0/8] l2tp: introduce L2TPv3 support

[James Chapman]

Herbert Xu wrote:
> James Chapman <jchapman@katalix.com> wrote:
>> This patch series implements L2TPv3. It replaces the existing pppol2tp
>> driver with a number of separate drivers, namely:-
>>
>> l2tp_core    - L2TP driver core. Always required.
>> l2tp_ppp     - L2TP PPP
>> l2tp_eth     - L2TPv3 ethernet pseudowire
>> l2tp_ip      - L2TPv3 IP encapsulation
>> l2tp_netlink - L2TPv3 netlink API
> 
> Have you thought by using the rtnl_link_ops interface instead
> of your own netlink API?

I did, yes. I decided against it only because I didn't want to cause
confusion with what I perhaps wrongly perceive as an API for managing
net devices. In the L2TPv3 case, there might not be a netdev directly
associated with a newlink API call, for example. I've no problem with
switching the code to use it if it is preferred.

-- 
James Chapman
Katalix Systems Ltd
http://www.katalix.com
Catalysts for your Embedded Linux software development

Re: [RFC PATCH 0/8] l2tp: introduce L2TPv3 support

[Patrick McHardy]

James Chapman wrote:
> Herbert Xu wrote:
>> James Chapman <jchapman@katalix.com> wrote:
>>> This patch series implements L2TPv3. It replaces the existing pppol2tp
>>> driver with a number of separate drivers, namely:-
>>>
>>> l2tp_core    - L2TP driver core. Always required.
>>> l2tp_ppp     - L2TP PPP
>>> l2tp_eth     - L2TPv3 ethernet pseudowire
>>> l2tp_ip      - L2TPv3 IP encapsulation
>>> l2tp_netlink - L2TPv3 netlink API
>> Have you thought by using the rtnl_link_ops interface instead
>> of your own netlink API?
> 
> I did, yes. I decided against it only because I didn't want to cause
> confusion with what I perhaps wrongly perceive as an API for managing
> net devices. In the L2TPv3 case, there might not be a netdev directly
> associated with a newlink API call, for example. I've no problem with
> switching the code to use it if it is preferred.

 From a quick look, it seems you're (also) managing sessions, for
which rtnl_link might not be the best choice. Could you give a
short overview of the operations you need to be able to perform?

Re: [RFC PATCH 0/8] l2tp: introduce L2TPv3 support

[Herbert Xu]

James Chapman <jchapman@katalix.com> wrote:
> 
> I did, yes. I decided against it only because I didn't want to cause
> confusion with what I perhaps wrongly perceive as an API for managing
> net devices. In the L2TPv3 case, there might not be a netdev directly
> associated with a newlink API call, for example. I've no problem with
> switching the code to use it if it is preferred.

Fair enough, just making sure that it was considered at least :)
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [RFC PATCH 0/8] l2tp: introduce L2TPv3 support

[James Chapman]

Patrick McHardy wrote:
> James Chapman wrote:
>> Herbert Xu wrote:
>>> James Chapman <jchapman@katalix.com> wrote:
>>>> This patch series implements L2TPv3. It replaces the existing pppol2tp
>>>> driver with a number of separate drivers, namely:-
>>>>
>>>> l2tp_core    - L2TP driver core. Always required.
>>>> l2tp_ppp     - L2TP PPP
>>>> l2tp_eth     - L2TPv3 ethernet pseudowire
>>>> l2tp_ip      - L2TPv3 IP encapsulation
>>>> l2tp_netlink - L2TPv3 netlink API
>>> Have you thought by using the rtnl_link_ops interface instead
>>> of your own netlink API?
>>
>> I did, yes. I decided against it only because I didn't want to cause
>> confusion with what I perhaps wrongly perceive as an API for managing
>> net devices. In the L2TPv3 case, there might not be a netdev directly
>> associated with a newlink API call, for example. I've no problem with
>> switching the code to use it if it is preferred.
> 
> From a quick look, it seems you're (also) managing sessions, for
> which rtnl_link might not be the best choice. Could you give a
> short overview of the operations you need to be able to perform?

Sure.

Userspace needs to create, delete, modify and query L2TP tunnel and
session contexts in the kernel. Tunnels are associated with a tunnel
socket (UDP or L2TPIP) and can carry multiple sessions. Session contexts
differ according to type; they are associated with a pppol2tp socket and
implicit ppp netdev in the case of PPP pseudowires, or an ethernet
netdev in the case of ethernet pseudowires. Other pseudowires may be
added in the future for ATM, Frame Relay etc.

In the existing L2TPv2 driver, only PPP is supported by L2TPv2 so the
management of session contexts is done through [gs]etsockopt and ioctl
on the pppol2tp socket. Since in L2TPv3, there might not be a socket for
a session (i.e. in the case of ethernet), we need a new API to manage
the tunnel and session contexts in the kernel.

The extra L2TPv3 configuration parameters of tunnels also required a
more extensive API for creating tunnel contexts. In L2TPv2, tunnel
contexts were automatically created when the first session on that
tunnel was created. In L2TPv3, this isn't possible because the tunnel
creation parameters aren't known by the session. Therefore, the API was
changed to require that userspace create an L2TPv3 tunnel context in the
kernel separately, before creating sessions on it.

Is that enough detail?

-- 
James Chapman
Katalix Systems Ltd
http://www.katalix.com
Catalysts for your Embedded Linux software development

Re: [RFC PATCH 0/8] l2tp: introduce L2TPv3 support

[Patrick McHardy]

James Chapman wrote:
> Patrick McHardy wrote:
>> James Chapman wrote:
>>> Herbert Xu wrote:
>>>> James Chapman <jchapman@katalix.com> wrote:
>>>>> This patch series implements L2TPv3. It replaces the existing pppol2tp
>>>>> driver with a number of separate drivers, namely:-
>>>>>
>>>>> l2tp_core    - L2TP driver core. Always required.
>>>>> l2tp_ppp     - L2TP PPP
>>>>> l2tp_eth     - L2TPv3 ethernet pseudowire
>>>>> l2tp_ip      - L2TPv3 IP encapsulation
>>>>> l2tp_netlink - L2TPv3 netlink API
>>>> Have you thought by using the rtnl_link_ops interface instead
>>>> of your own netlink API?
>>> I did, yes. I decided against it only because I didn't want to cause
>>> confusion with what I perhaps wrongly perceive as an API for managing
>>> net devices. In the L2TPv3 case, there might not be a netdev directly
>>> associated with a newlink API call, for example. I've no problem with
>>> switching the code to use it if it is preferred.
>> From a quick look, it seems you're (also) managing sessions, for
>> which rtnl_link might not be the best choice. Could you give a
>> short overview of the operations you need to be able to perform?
> 
> Sure.
> 
> Userspace needs to create, delete, modify and query L2TP tunnel and
> session contexts in the kernel. Tunnels are associated with a tunnel
> socket (UDP or L2TPIP) and can carry multiple sessions. Session contexts
> differ according to type; they are associated with a pppol2tp socket and
> implicit ppp netdev in the case of PPP pseudowires, or an ethernet
> netdev in the case of ethernet pseudowires. Other pseudowires may be
> added in the future for ATM, Frame Relay etc.

rtnl_link really doesn't seem to be the best fit for this. It
*could* be used for PPP device management, but since a userspace
daemon is required anyways, it wouldn't be much of a benefit.

> In the existing L2TPv2 driver, only PPP is supported by L2TPv2 so the
> management of session contexts is done through [gs]etsockopt and ioctl
> on the pppol2tp socket. Since in L2TPv3, there might not be a socket for
> a session (i.e. in the case of ethernet), we need a new API to manage
> the tunnel and session contexts in the kernel.
> 
> The extra L2TPv3 configuration parameters of tunnels also required a
> more extensive API for creating tunnel contexts. In L2TPv2, tunnel
> contexts were automatically created when the first session on that
> tunnel was created. In L2TPv3, this isn't possible because the tunnel
> creation parameters aren't known by the session. Therefore, the API was
> changed to require that userspace create an L2TPv3 tunnel context in the
> kernel separately, before creating sessions on it.
> 
> Is that enough detail?

Yes, thanks a lot.