In the list archives, I've noticed there are many mentions of possible ways to assign IP addresses to the LACs under rp-l2tp. I've written something which addresses the issue, but it's far from an ideal method. More on that later.
There were mentions of adding ip pool handling to rp-l2tp's LNS. There were also mentions of why that's a bad idea for the sake of purity, the sake of simplicity, for separation of layers, etc. Another option given was adding the same ability to pppd, possibly through the RADIUS or DHCP plugins. I didn't find any decent documentation on any of that. I wasn't about to get into the innards of pppd itself, either. So better plugin docs for pppd might be helpful. Also, pppd's man page mentions setting up options per port, and I didn't try seeing if this means per pty just like per tty. Someone mentioned tying a full-blown RDBMS into the system to manage pools. That seemed like overkill to several people. It does to me too. The solution (or at least workaround) I came up with focused on a few things. First, rp-l2tp probably shouldn't be doing this directly. Second, I didn't want to modify pppd in any way for which I didn't have good documentation. Third, I didn't want to write a huge piping daemon or depend on huge system like MySQL. SQLite may have been a decent option, but that's still kind of overkill. Fourth, it had to be simple enough to develop and debug quickly. It also had to be simple enuogh to explain to someone else quickly if someone else comes into the department. Simplicity couldn't be limited to implementation of the solution itself, but also how it interacts with rp-l2tp and pppd. Letting their documentation cover most of the process is a big plus. What I came up with is a wrapper around pppd. The pppd-path configuration option sets rp-l2tp to call the wrapper as if it were pppd. The lns-pppd-opts option sends all the needed pppd options except the IP addresses to the wrapper. The wrapper then sends its own arguments plus the local and remote IP addresses to pppd. When pppd is done with the connection, the ip-down hook calls a program which deallocates the IP address the pppd wrapper assigned (using the fact that the hook programs get the IP address passed to them by pppd). All the state about which addresses are available and which are assigned is kept on disk. All I have left to write is a reaper program which times out expired leases. Right now, the whole thing is prototyped out in Perl, but for my company's uses, I doubt I'll have to rewrite it for scalability concerns. Before anyone goes adding pool management functionality to rp-l2tp, perhaps they should try this kind of solution. Chris
