Although Ben and I are both working on L2TP projects, I think we're
targetting two totally different usage scenarios.
Time for some ASCII art...
1. ISP scenario
+----+
---+ D |
---| S | +--------+ +-------+
---| L |======| LAC |==============| LNS |
---| A | | | | |
---| M | +--------+ +-------+
---| |
---| |
---| |
+----+
thousands PPPoA each PPP session
of PPP or tunneled thru
clients PPPoE L2TP session to LNS
2. VPN scenario
+---+ +------+
|LAC+----------------------------------| |
+---+ | |
+---+ | |
|LAC+----------------------------------| LNS |
+---+ | |
+---+ | |
|LAC+----------------------------------| |
+---+ | |
+------+
PPP client Terminates
in each LAC. multiple tunnels
Typically 1
session per tunnel
Ben is addressing the ISP case, where client PPP sessions are
terminated only temporarily at the LAC while it authenticates the PPP
users to decide how to tunnel them. Each PPP session is then tunneled
straight through the LAC via an L2TP session (inside an L2TP tunnel)
to the LNS. Scalability is important here, which Ben has addressed.
I'm addressing the VPN case, where multiple clients (M$ L2TP/IPSEC
or rp-l2tp/openl2tp clients) connect to an enterprise VPN server.
Current solutions involve userspace pty hacks in the datapath,
shunting data in and out of pppd ttys. The proposed driver moves the
datapath into the kernel where it should be. The driver integrates
with existing PPP and IPSEC kernel subsystems and will handle
hundreds of sessions today.
The biggest difference in our approaches is that Martijn and I use a
PPPoL2TP socket per session bound through a plain AF_INET UDP tunnel
socket while Ben uses a new AF_L2TP tunnel socket and no separate
socket per session. Both have their merits.
If I can put the case for our driver, Linux really needs a good VPN
solution. I know of two companies that run their offices with Linux
servers yet they both retain a Microsoft server _only_ to provide VPN
access to off-site workers. Including this driver in the kernel will
enable us to build binary packages for OpenL2TP and perhaps other L2TP
solutions like rp-l2tp would be updated to use it too. Being able to
handle hundreds (not thousands) of sessions is more than adequate
in this case.
Where do we go from here then? Perhaps both approaches are equally
valid and could even co-exist in the Linux kernel distribution?
/james
Quoting Benjamin LaHaise <bcrl@xxxxxxxxx>:
> > - Architecture seems to be using char devices for communication with
> > the kernel and all the PPP datapath is handled by custom virtual
> > net_devices; the generic PPP kernel code isn't used as far as I can
> > tell. Unfortunately it is very old (linux-2.0 era I think) but Ben
> > has probably updated it.
>
> I've updated it. The current build is at http://www.kvack.org/~bcrl/babylon/
> and is 1.6-pre3-bcrl8.
[snip]
|