DHCP with IPv6

The process of successfully obtaining and allocating IP addresses in an IPv6 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 Solicit message to the DHCP Relay Agents and Servers address (FF02::1:2), requesting that a DHCP server respond with an IP address that the client can use.

The DHCP server responds with an Advertise message sent to the client's link-local 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 because the Solicit message was incorrectly formatted, the Advertise message contains a failure Status Code.

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 Solicit 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, 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, the Advertise message contains a failure Status Code.

The client responds to a valid Advertise message with a Request message, accepting and confirming the offered IP address.

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

When the client receives a valid Reply, 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 Decline 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 Decline message from the client, it deletes the binding, flags the IP address as unusable, and responds with a Reply message.

Rapid Commit

The address allocation process can be streamlined down to a single message exchange when the client and server support Rapid Commit. The client includes the Rapid Commit option in the Solicit message, indicating that it is willing to accept any address returned by the server.

When the server receives a Solicit message with the Rapid Commit option, it allocates an address, creates a binding and responds with a Reply message to the client.

Address Renewal

The client maintains two timers: Renewal Time (T1) and Rebind Time (T2). Either timer can be specified by the server in a Reply message. When T1 expires, the client sends a unicast Renew message 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 valid Reply, indicating that the lease has been renewed. The server responds with a failure Reply 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 Rebind in an attempt to rebind with the DHCP server. If a Reply 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 Renew message 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 Release to the server. When the server receives the Release message, it deletes the binding returns the address to the pool for allocation to another client, and responds with a Reply.

NOTE: The DHCP messages discussed are the only messages supported by a simulated client or server. If a client receives a failure Advertise or Reply 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 the client.

The relay agent encapsulates the original message in a Relay-Forward message and sends the message on to either a DHCP server or another relay agent.

The server decapsulates the Relay-Forward message, processes the original message from the client, and formulates the appropriate response. It then encapsulates the response in a Relay-Reply message and sends the message to the Relay Agent.

The Relay Agent decapsulates the Relay-Reply and forwards the DHCP server's response to the client.