>>-It only works in collaboration with the ppp-radius plugin. agreed, radius, adds another overhead and requirement from the client which, if it can be avoided is better.
RDBMS? I don't know, not too sure I ever heard of it. DHCP? well documented , used and understood by many sysadmins, therefore is my prefered choice as well. -----Original Message----- From: Norbert Wegener [mailto:[EMAIL PROTECTED]] Sent: 16 January 2003 09:52 To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: Assignment of IPs to LAC's ..... .... > 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. I also think that 2b is the way to go. Even for those who have a working radius it is not simple to use radius for the purpose of administrating ippools. What I understand from David's postings in case of using radius for this job: -You need a modified radius and you need a special configuration for this. -It only works in collaboration with the ppp-radius plugin. To me it seems, using the dhcp-radius plugin is the more "generic" way to go. > 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? As we use l2tp over ipsec on the same machine, the question might be answered, before l2tp comes into business. At least in our scenario every user has its own X.509 certificate for ipsec. When someone wants to esablish a second ipsec tunnel with a certificate which has been used to establish a still existing tunnel, the first ipsec connection will be shut down and a l2tp tunnnel using this connection will at least stop working. In a situation like this it seems to me, one does not have to deal with all problems discussed here. I hope I'm right :-) Norbert > 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 > -- Norbert Wegener Phone:(49)2012661379 Fax:(49)2012661377 SBS Essen,Germany Mail: [EMAIL PROTECTED] Mailfax:(49)2018165521379 CA Cert: http://w4.siemens.de/de2/flash/digital_id/digital_id.html
