DHCP with IPv4

The process of successfully obtaining and allocating IP addresses in an IPv4 test network is described below. The message exchanges in a test could take place between a simulated client and a DHCP server, a simulated client and a simulated server, or a client and a simulated server. When there are differences between the behavior of a simulated device and a "real" device, the simulated device is referred to as a node.

Learn more about DHCP support

Address Allocation

A client node broadcasts a DHCPDISCOVER message, requesting that a DHCP server respond with an IP address that the client can use. The nodes can include a requested lease time, a Parameter Request List, and a User Class option.

A DHCP server responds with a DHCPOFFER message sent to the client's MAC address. The message contains a potential IP address for the client and a lease time acceptable to the server. The message may contain additional configuration information if a Parameter Request List was included in the client's request. The server reserves the address while it waits for a confirmation from the client.

If the server is unable to allocate an address, either because the requested address pool is empty or does not exist, or if the discover message is incorrectly formatted, the server responds with a DHCPNAK.

A DHCP server node will only respond to clients that unicast requests to the node's IP address, and it only responds with IP address configuration information. If the discover message contains a Parameter Request List, a requested lease time, or a requested IP address, they are ignored. If the server node is only provisioned with one address pool, it will allocate an address from the pool regardless of the information in the request. If the server node is provisioned with more than one address pool, it uses the following methods to determine from which pool an address will be allocated:

If the User Class option is present, the node compares the User Class values to the Pool Identifier for each pool until a match is found. If the pool contains an available address, it is reserved for the client; otherwise, the node searches for another match. If none of the requested pools contain an available address, the Allocate Fails Pool Empty counter is incremented. If a matching Pool Identifier is never found, the node will not allocate an address and the Allocate Fails Pool Not Found counter is incremented.
If the User Class option is not present but the giaddr field contains an IP address, indicating that the request was forwarded by a relay agent, the address is compared to the Alternate Pool Identifier for each pool. A match is found if the address falls within the zone specified by the Alternate Pool Identifier. If the pool does not contain an available address, the Allocate Fails Pool Empty counter is incremented. If a matching pool is not found, the node will not allocate an address and the Allocate Fails Pool Not Found counter is incremented.
If the User Class option is not present and the giaddr field does not contain an address, the node selects a pool according to the Pool Selection Cycle Method defined. If an address is not available, the Allocate Fails Pool Empty counter is incremented.

If the server node is unable to allocate an address, no response is sent to the client.

The client responds to an offer with a DHCPREQUEST message, accepting and confirming the offered IP address.

When the server receives a valid confirmation from the client, it creates a binding associating the client with the allocated address for the agreed upon lease time. It then sends a DHCPACK to the client, completing the transaction. If the confirmation contains invalid identifiers or is incorrectly formatted, the server responds with a DHCPNAK and does not create the binding. If the server node receives an invalid confirmation, it increments the appropriate error counter and responds with a DHCPNAK.

When the client receives the acknowledgement, it is free to use the allocated address as its IP address. A client may attempt to discover whether the address is used by another host in the network. If it is, the client sends a DHCPDECLINE message to the server, rejecting the offered address. Client nodes assume that the address is valid and do not send decline messages.

If the server receives a DHCPDECLINE message from a client, it deletes the binding and flags the IP address as unusable.

Address Renewal

The client maintains two timers: Renewal Time (T1) and Rebind Time (T2). Either timer can be specified by the server in a DHCPACK message. When T1 expires, the client sends a unicast DHCPREQUEST to the server that allocated the address, requesting that the lease timer be reset.

The server searches its bindings for a matching client identifier and if a binding is found, it resets the lease time and responds with a DHCPACK, indicating that the lease has been renewed. The server responds with a DHCPNAK if it receives a request that contains a client identifier that does not match a binding on the server, or if the request message is incorrectly formatted or contains other invalid identifiers. In this case, a server node increments the appropriate error counter.

If the client does not receive a response from the server by the time T2 expires, the client broadcasts a DHCPREQUEST in an attempt to rebind with a DHCP server. If a DHCPACK is not received before the lease expires, the client ceases IP operations for the remainder of the test. Client node measurements record renewal and rebind transactions as well as any errors encountered during the processes. The server node will respond to a unicast renewal request but will not respond to a broadcast rebind request.

Address Release

When the client leaves the network due to a mobility event or session deactivation, it sends a DHCPRELEASE to the server. When the server receives the release message, it deletes the binding and returns the address to the pool for allocation to another client.

NOTE: The DHCP messages discussed are the only messages supported by a simulated client or server. If a client receives a DHCPNAK from a server, it will record the event but will not take any further action such as broadcasting a new discover message. All other DHCP message types are ignored.

Testing with a Relay Agent

When the DHCP server is in a different subnet than the client, the client's broadcast discover message will not reach the server. In this case a relay agent, a SUT or another host in the test network, intercepts all DHCP messages sent by clients. The relay agent forwards the messages to the server's IP address, provisioning the giaddr field with its own IP address.

The server sends responses to the client to the relay agent, which then forwards them on to the client.