<AddressAllocator SQL> works in conjunction
               with 
<AuthBy DYNADDRESS> (see 
Section 3.53. <AuthBy DYNADDRESS>) to
               allocate IPv4 addresses and IPv6 prefixes from an SQL database. During
               deallocation, the address is marked as unused. Addresses that remain in
               use for more than 
DefaultLeasePeriod seconds are
               automatically reclaimed (this protects against lost Accounting Stop
               requests).
<AddressAllocator SQL> supports all the
               common SQL configuration parameters. For more information about the SQL
               configuration parameters, see 
Section 3.8. SQL configuration.
The default FindQuery fetches the oldest unused address from the
               RADPOOL table. Change the allocation strategy by customising the SQL
               queries.
            Starting from Radiator 4.14, you can define UpdateQuery to refresh
               address TIME_STAMP and EXPIRY when accounting Alive requests are received.
               This keeps the addresses from being automatically reclaimed while they are
               periodically updated by Alive requests.
            The table definition of a sample RADPOOL table for a range of SQL
               databases can be found in the goodies/*.sql files in
               the Radiator distribution.
            <AddressAllocator SQL> uses the PoolHint to
               determine which pool to use. It uses the pool hint in the SQL select
               statement that is used to find an available address. It does an exact
               match on the POOL column of the RADPOOL table.
            When an address is allocated for a user, it is ‘leased’ to the user for
               a fixed period. It is available exclusively for that user until either
               they terminate their session (when an Accounting Stop is received) or
               until the lease expires. The purpose of this is to protect against ‘lost’
               Accounting Stops such as might occur with poor network connectivity, or a
               crashed NAS. However it also means that you should set the lease period to
               be longer than the longest legitimate session time, otherwise users may
               find their addresses being reallocated to another user.
            Since Radiator 4.14 you can use shorter lease period if accounting
               Alive messages are used and UpdateQuery is
               configured.
            Starting with Radiator 4.18, you can use asynchronous SQL queries with
               some database servers. See 
AsynchronousSQL
               and 
goodies/addressallocator.sql for the details.
The default lease period is 1 day, and you can control this with
               DefaultLeasePeriod. Every
               LeaseReclaimInterval seconds, expired leases are
               reclaimed and made available for allocation again.
            Acct-Status-Type values Accounting-On and Accounting-Off are by default
               accepted and replied to with no other action. You can configure
               AddressAllocator SQL with DeallocateByNASQuery to, for example, release
               all leases for the NAS when Accounting-On or Accounting-Off is
               received.
            <AddressAllocator SQL> makes the following
               allocation variables available for replies. These names can be used in
               MapAttribute in <AuthBy DYNADDRESS>.
            
               - yiaddr, the allocated IPv4 address or IPv6 prefix
                  from the YIADDR column of the RADPOOL table
- subnetmask, the IPv4 subnet mask or IPv6 mask
                  length from the SUBNETMASK column of the RADPOOL table
- dnsserver, the DNS server address from the
                  DNSSERVER column of the RADPOOL table
<AddressAllocator SQL> can also optionally
               populate the RADPOOL table at startup, by defining
               <AddressPool xxxxxx> clauses inside the
               <AddressAllocator SQL> clause.