This section describes the implementation of proxy DHCP server capability to provide a standards-based DHCP server which front-ends to a downstream DHCP client, DHCP relay enabled devices, and interfaces with RADIUS to authenticate the IP host and subscriber and obtains the IP configuration information for DHCP client devices.
The proxy DHCP server is located between an upstream DHCP server and downstream DHCP clients and relay agents when RADIUS is not used to provide client IP information.
Service providers can introduce DHCP into their networks without the need to change back-end subscriber management systems that are typically based around RADIUS (AAA). Service providers can support the use of DHCP servers and RADIUS AAA servers concurrently to provide IP information for subscriber IP devices (Figure: Typical DHCP deployment scenarios).
DHCP is the predominant client-to-server based protocol used to request IP addressing and necessary information to allow an IP host device to connect to the network.
By implementing DHCP, the complexity of manually configuring every IP device that requires connectivity to the network is avoided. IP devices with DHCP can dynamically request the appropriate IP information to enable network access.
DHCP defines three components that are implemented in a variety of device types:
The DHCP client allows an IP device (host) to request IP addressing information from a DHCP server to enable access to IP based networks. This is typically found in:
end user notebooks, desktops, and servers
residential gateways and CPE routers
IP phones
set-top boxes
wireless access points
The DHCP relay agent passes (relays) DHCP client messages to pre-configured DHCP servers where a DHCP server is not on the same subnet as the IP host. This feature optionally adds information into DHCP messages (Option 82) which is typically used for identifying attaching IP devices and their location as part of subscriber management. This is typically found in:
residential gateways and CPE routers
DSLAMs
edge aggregation routers
The DHCP server receives DHCP client messages and is responsible for inspecting the information within the messages and determining what IP information if any is to be provided to a DHCP client to allow network access. This is typically found in:
dedicated standalone servers
residential gateways and CPE routers
edge aggregation routers
centralized management systems
DHCP is the predominant address management protocol in the enterprise community, however in the provider market PPP has traditionally been how individual subscribers are identified, authenticated, and provided IP addressing information.
The use of DHCP in the provider market is a growing trend for managing subscriber IP addressing, as well as supporting newer devices such as IP-enabled IP phones and set-top boxes. Most subscriber management systems rely heavily on RADIUS (RFC 2865, Remote Authentication Dial In User Service (RADIUS)) as the means for identifying and authorizing individual subscribers (and devices), deciding whether they are allowed access to the network, and which policies should be put in place to control what the subscriber can do within network.
The proxy DHCP server capability enables the deployment of DHCP into a provider network, by acting as a proxy between the downstream DHCP devices and the upstream RADIUS based subscriber management system.
Interact with downstream DHCP client devices and DHCP relay agents in the path.
Interface with RADIUS to authenticate DHCP requests.
Receive all the necessary IP information to properly respond to a DHCP client.
Override the allocated IP address lease time, if necessary, for improved IP address management.
Figure: Aggregation network with DHCP to RADIUS authentication shows a typical DHCP initial bootup sequence with the addition of RADIUS authentication. The proxy DHCP server interfaces with downstream DHCP client devices and then authenticate upstream using RADIUS to a provider’s subscriber management system.
In addition to granting the authentication of DHCP hosts, the RADIUS server can include RADIUS attributes (standard and vendor-specific attributes (VSAs)) which are then used by the edge router to:
Provision objects related to a specific DHCP host such as a subscriber and SLA policy.
Provide IP addressing information to a DHCP client.
Support the features that leverage DHCP lease state.
dynamic ARP population
ARP reply agent
anti-spoofing filters
MAC pinning
Leverage host-connectivity-verify to determine the state of a downstream IP host.
This feature offers the ability for a customer to integrate DHCP to the subscriber while maintaining their existing subscriber management system typically based around RADIUS. This provides the opportunity to control shifts to an all DHCP environment or to deploy a mixed DHCP and RADIUS subscriber management system.
To maximize its applicability VSAs of legacy BRAS vendors can be accepted so that a network provider is not forced to reconfigure its RADIUS databases (or at least with minimal changes).
To receive data from the RADIUS server the following are supported:
Juniper (vendor-id 4874) attributes 4 (Primary DNS server) and 5 (Secondary DNS server).
Redback (vendor-id 2352) attributes 1 (Primary DNS) and 2 (Secondary DNS).
Juniper attributes 6 and 7 (Primary and Secondary NetBIOS nameserver).
Redback attributes 99 and 100 (Primary and Secondary NetBIOS nameserver).
The following attributes can be sent to RADIUS:
Sending authentication requests: (from the DSL Forum) (vendor-id 3561), attributes 1 (Circuit ID) and 2 (Remote ID).
DSL Forum attributes 129 and 130 (Actual Data Rate Upstream and Downstream), 131 and 132 (Minimum Data Rate Upstream and Downstream) and 144 (Access Loop Encapsulation).
The complete list of Nokia VSAs is available on a file included on the compact flash shipped with the image.