Specifying IP Address Assignment from a DHCP Server

IP addresses can be assigned from a back-end DHCP server, rather than from a standard IP address pool. DHCP address pools function like internal address pools—Framed-IP-Address can be allocated from any address pool, either internal or DHCP.

DHCP address pools are defined in the dhcp.ini file and initialization files with the extension .dhc.

In addition, each DHCP address pool must be enabled by adding a placeholder IP address pool in the Web GUI. This placeholder pool should have the same name as the DHCP pool, and should have an empty list of address ranges. The placeholder pool allows the DHCP pool to appear in lists presented by the Web GUI, so it can be selected into an attribute.

When an IP address must be assigned from a DHCP pool during an Access-Request, DHCP DISCOVER and REQUEST messages are issued to trigger the allocation of an address. When an accounting Stop ends the session, DHCP RELEASE is issued to the server that allocated the address. Upon receipt of an accounting INTERIM request, a DHCP REQUEST message is issued to the server that allocated the address, attempting to extend the lease. If the server is specified as a broadcast address, DHCP failover occurs if the primary DHCP server go down.

DHCP leases can be acquired, extended, and released by different servers. The server that acquires the lease adds all the information for extending and releasing the lease to the Class attribute.

Flexible configuration features allow RADIUS attributes to be mapped to DHCP options. Therefore, information from a RADIUS request can be provided to the DHCP server, and information returned from the DHCP server can be returned to the network access server.

During authentication, if an address is assigned from a pool, the pool name must refer to either a DHCP pool or an internal pool. If the pool name is not found, the request is rejected.

Address Allocation

Address Allocation

During address allocation, a DISCOVER message is issued. If an OFFER is received from a DHCP server and the offered lease time meets the minimum lease time requirements, the server issues a REQUEST message. If an ACK message is received, the allocated address is returned in the Access-Accept.

In addition to the options required for normal DHCP operation, additional options in the DHCP DISCOVER and REQUEST messages are constructed based on the attributes in the RADIUS request and the literal values specified in the [Request] section for the pool. A Parameter Request List option is also constructed, listing all return options required for populating the RADIUS response, as specified in the [Reply] section for the pool.

If an address is assigned by means of DHCP, the DH= field is added to the Class attribute. This field includes:

• The unique client identifier for this lease.

• The address of the DHCP server.

• The lease time.

The unique client identifier for each user session is placed in the client hardware address field of the DHCP request as well as in the Client ID option. This information is used by the DHCP server to associate IP addresses with clients.

Address Renewal

Address Renewal

If an INTERIM accounting message whose Class attribute includes both the IP= and the DH= fields is received, a REQUEST message is unicast to the DHCP server that allocated the address in an attempt to renew the lease. It requests the same lease time as was granted for the original request. If the server is specified as a broadcast address, DHCP failover occurs if the primary DHCP server go down.

Address Release

Address Release

If an accounting Stop message whose Class attribute includes both the IP= and the DH= fields is received, a RELEASE message is unicast to the DHCP server that allocated the address.

An address to the DHCP server is also released when a session is deleted from its session database for reasons other than receiving an accounting Stop. For example, phantom session expiration or administrative deletion of a session result in the release of the temporary DHCP address.

DHCP Option Mapping

DHCP Option Mapping

Options in a DHCP DISCOVER or REQUEST message can automatically be constructed based on attributes in the RADIUS request as well as pre-configured literal values. Also, options returned by the DHCP server in an OFFER message can be transmitted back to the network access server in RADIUS attributes.

The following applies to the mapping between RADIUS attributes and DHCP options:

• Both standard and vendor-specific DHCP options are supported. (Vendor-specific DHCP options must use standard encapsulation rules, as described in RFC 2132.)

• Format conversions between RADIUS attributes and a DHCP option are performed. For example, a DHCP option containing an IP address is formatted into dotted notation when returned in a RADIUS string attribute.

• A single RADIUS request attribute can set more than one DHCP option in a request, and a single DHCP option can set more than one RADIUS response attribute.

• A single DHCP option containing multiple values can be mapped to multiple instances of a single RADIUS attribute.

  For example, a RADIUS attribute called IP-Router could appear multiple times in an Access-Accept. DHCP’s Router option returns a list of IP addresses of routers. This single DHCP option can be configured to return multiple instances of the RADIUS IP-Router attribute -- one for each router address in the list.

• A single DHCP option containing multiple values can be mapped to multiple RADIUS attributes.

  For example, two RADIUS attributes exist, Primary-DNS-Server and Secondary-DNS-Server. DHCP’s DNS Server option returns a list of IP addresses of DNS servers. This single DHCP option can be configured to set the first DNS server address in Primary-DNS-Server and the second in Secondary-DNS-Server.

• Only attributes appropriate to the dictionary are returned.

  Therefore, if network access servers from different vendors use different RADIUS attributes for the same information, each RADIUS attribute that might be required can be mapped to the same DHCP option. The correct attribute is returned to the network access server.

Using Multiple Servers

Using Multiple Servers

As the information required to renew or release a DHCP-assigned address is contained in the Class attribute, it is feasible to set up multiple servers, all utilizing a common DHCP server for address allocation. The network access server can issue requests to any of the servers, and addresses are assigned and released correctly even if different servers handle authentication and accounting requests for the same session.

This architecture requires that each server must be configured to be stateless—that is, the current sessions database must be turned off in the radius.ini file, as follows:

For a standalone server, current sessions processing makes sense only when authentication and all accounting transactions are directed to the same server. If current sessions processing is not disabled, the current sessions database will be incorrect and always grows. For example, DHCP addresses are prematurely released when phantoms expire.