The Dynamic Host Configuration Protocol (DHCP) has become one of today’s most widely deployed internet technologies. Its range of application stretches from the public service provider to private large enterprises, up to our own homes: millions of hosts and applications on the Internet dependent on it in order to function. Through what we could define as an evolutionary path the DHCP framework has reached far beyond its original purpose, which is, as its name states, to dynamically deliver configuration parameters to hosts. DHCP has, in fact, become a powerful tool for advanced uses such as user service provisioning, upper-layer application automatic setup or enforcement of user identity and access control by network administrators.

This article, channelizing the experience matured by the authors in the field, explores the evolution of the DHCP framework with, in particular, emphasis on how DHCP can be used as an effective and scalable tool for access control in multi-access environments (such as Ethernet, Wi-Fi or Fiber-to-the-Home broadband networks). Throughout the article we will evaluate some of DHCP advanced applications and provide, what we believe to be, useful guidelines for approaching both design and operation tasks related to large scale DHCP-based deployments.

DHCP, in its original framework, provides a mechanism for delivering configuration parameters to hosts. A DHCP environment is built on a client-server model, where DHCP clients act as supplicants and DHCP servers administer and assign Internet Protocol (IP) addresses and/or configuration parameters. The environment consists of a standardized messaging protocol, running on top of the (connection-less) User Datagram Protocol (UDP) layer. Messages are encapsulated (in the case of IPv4) using destination port 67 for contacting DHCP servers and 68 for contacting DHCP clients. The acting devices implement a simple state-machine mechanism based on a small number of states and use timers to trigger specific actions and state transitions.

The next picture provides a simple representation of the interaction between client and server in the simplest DHCP deployment scenario, with client and server attached to the same segment (layer 2 broadcast domain, e.g Ethernet VLAN).

Through the rest of this paper we will, instead, move the focus to advanced applications of DHCP based on the manipulation of DHCP option number 82. Please note that, within this article, only the case of IPv4 will be considered. Although similar on most aspects, the specifications of DHCP mechanisms for IPv6 (DHCPv6 RFC 3315 and related) define slightly different mechanisms and therefore, for the sake of readability, will not be considered in this article.

DHCP and the flexibility of its “options” language (RFC 2132)

One of the most significant characteristics of DHCP, the one contributing the most to its evolutionary course and popularity, is its extensible vocabulary of attributes, the so called DHCP options. In the years a flexible framework for manipulating and customizing DHCP options has been defined by the Internet Engineering Task Force (IETF). Several Request for Comments (RFC’s) have been released, some of them extremely well received by the community, such as the introduction of “Vendor Extensions” options (RFC 2132) and the definition of DHCP option 82 (Relay Agent Information option, RFC 3046). The latter, in particular, has become a keystone of many and extremely diversified network environments. Its recognition within the industry has stimulated further protocol evolution, with several vendor proprietary enhancements as well as additional recommendations from the IETF opening new ground for further application.

Before moving on to the specific definition and uses of DHCP option 82, let’s quickly get a snapshot of the generic concept of DHCP option, which is defined by RFC 2132. DHCP uses the basic message format already defined for the Bootstrap Protocol (BOOTP, RFC 951) and offers a customizable vocabulary of attributes and extensions, formatted as Type-Length-Value (TLV) tuples, individually called options and globally administered by IANA. The use of options is, as the name itself implies, dependent on the environment (client and server requirements and capabilities) and is highly customizable. Hosts willing to gather configuration must specify which parameters they require as a list of requested options on their request messages (such list is an option itself, option number 55). Servers will (eventually) honour such requests replying with offers including the value of the requested options.

As defined in RFCs 2131 and 2132, any DHCP message, after listing the mandatory addressing parameters (client hardware address, IP addressing etc.) must also include an option-field portion, delimited by the Hex code 0x63825363 (called also “magic cookie”). Option 53 (“DHCP message type”), for instance, is an option used to sub-define the message type (discover, offer, ack, nack, inform etc.) and it is mandatory to the option-field (and therefore to any DHCP message). All other options (as you would expect) are optional. In any case the options-field portion must always be terminated by using the “end” option (0xff).

Here a typical example of DHCP packet with the most common options being set:

In practice all DHCP real-world deployments, even the simplest ones, make use of at least some of the options defined in RFC 2132 for requesting and providing configuration parameters (i.e. option 3 default gateway address, option 6 for the Domain Name System (DNS) server to be used, option 54 reporting the DHCP server contact address, etc.). Specific environment may require use of very specific options, while even a freely customizable option is available if IANA predefined options come short: the so called option 43, which can be defined, formatted and implemented as needed by administrators (eventually a TLV list of sub-fields itself, if many parameters need to be inserted) in order to exchange custom specific parameters.

Now that the DHCP framework has been briefly recalled, let’s focus on the use and applications of the so called DHCP option 82, an option which is tightly bound to the Relay Agent functionality and has a unique (and powerful) peculiarity among all other options: it is invisible to clients and it is scoped for use only to the operator’s network infrastructure (on servers and nodes such as routers, BRAS, DSLAMs, switches, etc.).

DHCP Relay Agent Information option (RFC 3046)

As in most of the cases, whenever hosts initiate a DHCP client they do it because they do not have a valid unicast IP address yet (as they are willing to get access to network environment they are moving in), the DHCP protocol utilizes IP broadcast as the basic transport media for communication towards servers. Anyway, as the use of broadcast limits the applicability of the protocol solely to the Local Area Network (LAN), RFC 2131 extended the communication scope by including, if required, the role of an intermediate DHCP Relay Agents host, with the specific ability to intercept (broadcast) DHCP messages and “relay” them to known servers across a standard IP unicast network. Using the giaddr mandatory field (which is a standard field and not an option in the DHCP message) the Relay Agent specifies its IP location for the server to be able to send replies.

The next picture shows a DHCP packet with the option82 inserted by the DHCP Relay Agent:

In this situation the function of the Relay Agent Information option, or just DHCP option 82, becomes critical: it is through this field that the Relay Agent and the Server can “communicate” specific information to each other. As well described by RFC 3046, which introduced the option, the use and manipulation of such field addresses the needs for access and identity control by network administrators in any Media Access Control (MAC) multi-access environments based on DHCP.

In practice DHCP option 82 is a network-generated “identification tag”. It is applied by network elements (under the control of the service administrator) to any DHCP client-generated message upon entering the controlled environment. Network devices, if explicitly set to do so, populate the option with, according to RFC 3046, a combination of topological and identity information. DHCP servers can utilize the value(s) inserted in the option to identify the location of entrance and eventually (if a relation can be assumed between topological information and ens users) the identity of user requesting DHCP support. DHCP servers are consequently able to determine which action should be taken for granting (limiting or blocking) access to the user.

The manipulation of DHCP option 82 relies upon an implicit (or if required explicit) “trust” relationship between servers and relay agents (or even additional network elements, as we will see once considering DHCP snooping) and is an option which must not be set by the end-user DHCP clients (otherwise causing the request to be dropped and signaled as an anomaly).

DHCP option 82 original format

As a farsighted decision, RFC 3046 adopted a flexible structure for the option. The value (Agent Information) field consists itself of a sequence of TLV (Sub-Option Type/Length/Value) tuples. In the recommendation two sub-options have been initially specified, although the extensible syntax has allowed in time more sub-options to be added, as needed.

The first sub-option introduced by RFC 3046, called Agent Circuit ID, has mainly a topological purpose. It should be use for providing information about the device / port / circuit entity at which the DHCP client packet entered the network. The second sub-option, called Agent Remote ID, is meant to identify the user and is normally left to operator administration (i.e. pre-provisioned by the operator on the access device user facing port, for instance as an operator order-number, service-number or as a user name).

Note: As mentioned the Remote ID is normally left by vendor implementations to operator administration. Anyway this is not a mandatory requirement of RFC 3046 and some implementations, still compliant to RFC 3046, cause restrictions in the possibilities of customizing the sub-option. In order to overcome vendor-dependent deadlocks, the IETF has defined in RFC 3993 an additional sub-option, called Subscriber-ID, with the only purpose of being an operator fully configurable parameter. As the use of the Subscriber-ID is conceptually identical to the use of the Remote-ID sub-option, the Subscriber-ID should be considered semantically a synonym of the Remote-ID and therefore it will not be described further in this paper.

DHCP option 82 mode of operation as of RFC 3046

According to RFC 3046 the “tagging” of option 82 in the DHCP client message may be a task performed by the DHCP relay agent itself or by some “trusted” device (for example a downstream bridge), in proximity (or better upon) the network entry point. As we will see when discussing processing of the option on OSI layer 2 devices, this degree of freedom has, at the same time, become reason for adaptability to real world needs (and therefore a critical contribution to the DHCP success) as well as reason for ambiguity in the DHCP standardization process.

In some specific situations (i.e. broadband based on Asynchronous Transfer Mode, ATM, access) the relay agent is the one node required to add the option 82 tag (and to relay the message, setting the giaddr field). In many other situations (i.e. in any Ethernet-based access network) a downstream “trusted” device, such as an access switch, a Digital Subscriber Line Access Multiplexer (DSLAM), a Data Over Cable Service Interface Specification (DOCSIS) station, or other functionally equivalent access device, is in a better position for marking the DHCP message entrance point and is required to set the option 82 value. In this case the OSI layer 2 device leaves the giaddr field intact (as the 0.0.0.0 value) and the relay agent, explicitly set to trust the downstream network device, is only in charge of relaying the messages, modifying the giaddr field without touching the existing option 82 value. In this perspective tagging the Relay Agent Information option and performing the Relay Agent functionality are logically separated operations.

The following provides a schematic representation of this mode of operation, with the tagging of option 82 and the relay functionalities performed by separate devices.