So, After all the discussion, it seems we're still divided as to how to assign IPs to LACs.
There are some decisions to be made. The first: 1a) Let rp-l2tp get the IP (somehow) and pass it along to pppd when it invokes pppd. 1b) Let pppd get the IP itself (somehow) and implement this as a plugin to pppd. My understanding is that we're in agreement that #2 is the way to go. ip_choose_hook in pppd makes this doable as a plugin to pppd. The code developed at Netservers.co.uk looks to be an excellent starting point. Then, the second decision: 2a) Use RADIUS to assign the IP address. 2b) Use DHCP to assign the IP address. 2c) Use an RDBMS to store the relevant state needed for IP pool allocation. Chris and Ben at Netservers.co.uk, as well as I, think 2b is the way to go. David has voiced that he thinks 2a is the way to go. Someone else suggested using a RDBMS to manage IP pool assignment, but I think this is much more heavyweight than necessary for this application. The problem that needs to be solved in both 2a and 2b scenarios is what happens if the same user connects multiple times but they're supposed to be assigned a static IP? Chris and Ben want the behavior to be "first connection gets the static IP, the rest get a dynamic IP" from what I understand. They also want to be able to possibly define a seperate private range of IPs to allocate from for a specific username, so again, we need to handle a one-to-many allocation from username to IPs. I'm not clear on how this might be solved from RADIUS -- perhaps David can speak to a specific implementation of a solution. My guess as to how to solve this for DHCP follows: 1) Client sends out DHCPREQUEST using 'client identifier' using the username. 2) Server sends back DHCPACK with assigned address. 3) Client checks to see if address is in use (using ARP or ICMP Echo). If it is unused, it uses the assigned IP address. Otherwise, the client DHCPDECLINE's the DHCPACK. Then, it issues a new DHCPREQUEST with a new 'client identifier' that is pseudo-unique to get a different IP address. This flow scenario doesn't cover all the possible use cases that Chris and Ben have laid out, but I think on closer inspection, some of them may be mutually exclusive. I'd like to hear more from everyone about actual use scenarios that MUST be supported, and see if we can't come up with appropriate control flows that will support them all. Before I commit my limited time towards working on an implementation of a solution, I'd like to get all of our minds together to just think things through. If folks are available, I'm on irc.freenode.net on the #l2tp channel ... we can try to carry on a conversation in realtime, otherwise, via this mailing list. -- Dossy -- Dossy Shiobara mail: [EMAIL PROTECTED] Panoptic Computer Network web: http://www.panoptic.com/ "He realized the fastest way to change is to laugh at your own folly -- then you can let go and quickly move on." (p. 70)
