* todo/serverside-ip-pools: new file describing how to implemented

  server-side IP pools
* todo/radius.conf.sample2: removed, we have a radius.conf don't we

diff --git a/todo/radius.conf.sample2 b/todo/radius.conf.sample2
deleted file mode 100644 (file)
index b25469a..0000000
--- a/todo/radius.conf.sample2
+++ /dev/null
@@ -1,45 +0,0 @@
-
-confdir:               /etc/raddb
-authlog:               /var/log/radius.log
-acctlog:               /var/log/radacct/%s/detail
-radwtmp:               /var/log/radwtmp
-radutmp:               /var/log/radutmp
-pidfile:               /var/run/radiusd.pid
-checkrad:              /usr/local/sbin/checkrad
-
-avgroup common {
-   auth-recv-allow:    Framed-MTU
-   auth-recv-allow:    Idle-Timeout
-   auth-recv-allow:    Reply-Message
-   auth-recv-allow:    Filter-Id
-   auth-recv-allow:    Port-Limit
-   auth-recv-allow:    Session-Timeout
-   auth-recv-allow:    Idle-Timeout
-   auth-recv-allow:    Framed-Protocol
-   auth-recv-allow:    Framed-Compression
-   auth-recv-allow:    Service-Type = Login-User
-   auth-recv-allow:    Login-Service
-   auth-recv-allow:    Login-IP-Host
-}
-
-proxy domain.com {
-   authproxy:          pr1.domain.com:1645
-   acctproxy:          pr1.domain.com:1646
-   auth-send-allow:    A/V pairs
-   auth-send-deny:     ALL
-   auth-recv-allow:    Framed-Address = 192.168.1.2/26
-   auth-recv-allow:    Framed-Netmask = 255.255.255.255/26
-   auth-recv-allow:    common
-   auth-recv-deny:     ALL
-   acct-send-deny:     Caller-ID
-   acct-send-allow:    ALL
-   authlog:            /var/log/radius.pr1.log
-   acctlog:            /var/log/radacct/pr1/detail
-}
-
-nas 192.168.1.1 {
-   shortname:          cs-1.alp
-   type:               livingston
-}
-
-

diff --git a/todo/serverside-ip-pools b/todo/serverside-ip-pools
new file mode 100644 (file)
index 0000000..087c605
--- /dev/null
+++ b/todo/serverside-ip-pools
@@ -0,0 +1,84 @@
+From: miquels@cistron-office.nl (Miquel van Smoorenburg)
+Subject: Serverside IP pools design [was: Re: Questions on IP address allocation]
+Date: Tue, 13 Nov 2001 13:29:24 +0000 (UTC)
+Message-ID: <9sr77k$ofn$1@ncc1701.cistron.net>
+To: freeradius-devel@lists.cistron.nl,freeradius-users@lists.cistron.nl
+
+In article <DE6495F924D2304DA0FAD60FC1C00601150E3B@AVIANSERVER.aviancommunications.com>,
+John Padula <john_padula@aviancommunications.com> wrote:
+>I'm still looking into IP address allocation via the "+" option.
+>I wanted to check if there's any sense of a lease or expiration on the
+>IP address
+>given out.
+
+No, and that's not really neccesary either, since other than with
+DHCP you have strictly defined session start- and stop points.
+
+>I've checked the RFC and didn't see any mention of this, but
+>wanted to 
+>make sure.
+
+Because IP address allocation is completely outside the scope
+of the Radius RFC / protocol.
+
+>Coming from the DHCP world, where there's a large blob of
+>processing
+>devoted to lease negotiation, it seems strange that (a) we just give out
+>an IP 'forever'
+
+Not forever - until the end of the session.
+
+>and (b) we just keep incrementing based on nas-port-id.  There's no way
+>to define 
+>a range of IPs.
+
+That's because it really is an ugly hack.
+
+>Is there any way to establish a hook (in the 'module' model) where
+>a user could call some external function that would return an IP and
+>possibly manage that IP?
+
+It's hard but not impossible. You would have to write a routine/module
+that knows about several pools (probably defined in radius.conf)
+and keeps an on-disk database that accounts for the IP addresses
+given out. It should look at all accounting-stop messages and mark
+the IP as free at the end of a session.
+
+There is also the problem of 'lost packets'. If an accounting-stop
+packet gets lost, or if authentication fails on the NAS after you've
+send an authentication ack so that start and stop packets might
+not be sent at all, the IP address you allocated will not
+be freed - ever. So when the pool reaches a high watermark (>90%)
+then you will need to scan all sessions in the pool to see if
+they are still active, using "checkrad", until you're under the
+low watermark (<80%) again. High and low watermarks would presumably
+be defined as part of the pool definition in radius.conf
+
+Other ways to keep the pool clean is to also check all authentication
+and accounting start packets for NAS/portno combination and if
+that matches with a presumably still active pool allocation,
+kill the allocation, since the original user is gone anyway.
+And perhaps a time-limit - use a minimum "Session-Timeout = 86400"
+for all sessions with addresses from the pool and periodically
+clean up all session that are older than (86400 * 1.2) or so.
+That should also be made part of the pool definition in radius.conf
+
+ip-pool pool1 {
+       range-start     = 192.168.10.10
+       range-end       = 192.168.10.19
+       cleanup-start   = 90%
+       cleanup-end     = 80%
+       session-timeout = 86400
+       session-stale   = 90000
+       session-db      = /var/log/radius/pool1.db
+}
+
+.. or something. You get the idea.
+
+The above is a description of how you could make serverside
+IP pools possible. Now someone needs to write the code.
+
+Mike.
+-- 
+"Only two things are infinite, the universe and human stupidity,
+ and I'm not sure about the former" -- Albert Einstein.