Section 3.53. <AuthBy DYNADDRESS>

3.53. <AuthBy DYNADDRESS>

<AuthBy DYNADDRESS> is used to dynamically allocate IP address information in conjunction with <AddressAllocator xxxxxx> clauses. It is implemented in AuthDYNADDRESS.pm. At present, there are three Address Allocation engines provided:

AddressAllocator SQL can allocate IPv4 addresses and IPv6 prefixes out of an SQL database. For more information, see Section 3.114. <AddressAllocator SQL>.
AddressAllocator DHCP can allocate addresses from a DHCP server. For more information, see Section 3.115. <AddressAllocator DHCP>.
AddressAllocator DHCPv6 can allocate addresses and prefixes from a DHCPv6 server. For more information, see Section 3.116. <AddressAllocator DHCPv6>.

IP address and prefix allocation is usually the responsibility of your NAS, and most organisations have allocation done by their NASs. There are sometimes special requirements that mean allocation must be done by a central authority, and <AuthBy DYNADDRESS> allows you to make your RADIUS server the address allocator.

When using <AuthBy DYNADDRESS>, the usual arrangement is to make <AuthBy DYNADDRESS> the last AuthBy clause in a <Handler>. Some previous AuthBy clauses are responsible for authenticating the password of the user. Only if the authentication succeeds is

<AuthBy
                  DYNADDRESS>

run and an address allocated.

It is common practice to maintain multiple IP address pools, with each pool used for a different class of users, perhaps with different access controls. The features of <AuthBy DYNADDRESS> allow you to control which pools to allocate from, and also how to translate the allocated information into RADIUS reply attributes.

See goodies/addressallocator* in the Radiator distribution for configuration samples for different allocation engines.

<AuthBy DYNADDRESS> understands also the same parameters as <AuthBy xxxxxx>. For more information, see Section 3.32. <AuthBy xxxxxx>.

3.53.1. AddressAllocator

This is the Identifier of an <AddressAllocator xxxxxx>. It specifies which Address Allocation engine will be used to allocate the addresses. It must match the Identifier parameter of an <AddressAllocator xxxxxx> clause. Special formatting characters are permitted. The named AddressAllocator will be used to allocate and deallocate addresses of all users authenticated through this AuthBy.

<AddressAllocator SQL>
      Identifier SQLAllocator
      DBSource ....
      .....
</AddressAllocator>
<Handler>
      AuthByPolicy ContinueWhileAccept
      # This does the authentication
      <AuthBy FILE>
            Filename xxxxxx
      </AuthBy>
      # If authentication succeeds, this allocates an
      # address, using the AddressAllocator above
      <AuthBy DYNADDRESS>
            AddressAllocator SQLAllocator
      </AuthBy>
</Handler>

Note

This parameter used to be called Allocator. This word is still supported but deprecated. Support will be removed some time in the future.

3.53.2. PoolHint

This optional parameter specifies how the pool hint is derived. A pool hint is generally used by an AddressAllocator to determine which pool to allocate an address from. The value of the pool hint will therefore depend on what type of Address Allocator you are using, and usually which pools are available.

The default PoolHint (and the most common requirement) is ‘%{Reply:PoolHint}’, which means the pool hint is an attribute called ‘PoolHint’ in the current reply. Presumably the PoolHint will have been set in the reply by some previous AuthBy clause. This is easy to do for example in an AuthBy FILE, by adding the pool hint attribute to the users file:

user1       Password=x
            PoolHint=pool1

user2       Password=y
            PoolHint=pool2

The PoolHint attribute will then be used by the Address Allocator to indicate which pool to allocate from. The exact way the pool hint is used depends on the type of Address Allocator you are using, so refer to the documentation for the Address Allocator.

Tip

If the pool hint resolves to an empty string, a DEBUG message will be issued, no address will be allocated, but the request will be ACCEPTED. This allows you to arrange for only some users to get an address allocated (and the NAS will allocate addresses for the others).

3.53.3. MapAttribute

This optional parameter allows you to specify how the results of the address allocation are to be placed in the reply.

If the yiaddr attribute (usually Framed-IP-Address) is already set in the reply, then AuthBy DYNADDRESS will not allocate an address, and will just ACCEPT the request. This means that if a user record has a fixed IP address in it, then AuthBy DYNADDRESS will not allocate an address for that user.

The above also applies to IPv6 iaaddr and iaprefix. However, if there is additional configuration information, such as DNS server addresses, the allocator may still make a query to fetch this information. For example, DHCPv6 allocator can send a stateless Information-request.

Each MapAttribute specifies the name of the allocation variable, and the name of the RADIUS attribute in which to place it (if it is not set already). The following allocation variables are normally available for IPv4 allocation. Some AddressAllocator clauses may not provide all of these or may also make others available.

yiaddr, usually the allocated IP address in dotted quad format (e.g. 1.2.3.4)
subnetmask, usually the IP Subnet Mask in dotted quad format (e.g. 255.255.255.255)
dnsserver, usually the address of the DNS server to use in dotted quad format (e.g. 1.2.3.4) Only one DNS server address is currently permitted and supported for IPv4

The default behaviour is to place the allocated IPv4 address in Framed-IP-Address, and the IPv4 subnetmask in Framed-IP-Netmask. This is equivalent to:

MapAttribute yiaddr, Framed-IP-Address
MapAttribute subnetmask, Framed-IP-Netmask

There are no default MapAttribute parameters for IPv6 information. For DHCPv6 allocator, the name of the allocation variables must be the case insensitive name of the desired DHCPv6 option. For example, the following requests and maps OPTION_IAADDR and OPTION_DNS_SERVERS. Multiple DNS servers are mapped to multiple instances of DNS-Server-IPv6-Address

MapAttribute iaaddr, Framed-IPv6-Address
MapAttribute dns_servers, DNS-Server-IPv6-Address

For more information about the details of the available allocation variables, see Section 3.116. <AddressAllocator DHCPv6> and Section 3.114. <AddressAllocator SQL>.

3.53.5. RunWhenMissing

This optional flag parameter controls if confirm and deallocate operations are run even if the address, as defined by MapAttribute yiaddr, is missing from the accounting requests that have Acct-Status-Type set to Start, Alive or Stop. The default value is enabled and confirm, and deallocate are always run.

# If Framed-IP-Address is missing from the request do nothing
MapAttribute yiaddr, Framed-IP-Address
RunIfMissing false

Tip

When IPv4 and IPv6 allocators are chained, yiaddr is typically not set for one of the allocators. In this case, set RunWhenMissing to off.