Fundamentals of DHCPv6 Address Allocation

DUIDs of DHCPv6 Devices

Each DHCPv6 client and server has a DHCP Unique Identifier (DUID). DHCPv6 servers use DUIDs to identify clients, and DHCPv6 clients use DUIDs to identify servers. Client DUIDs are used in a local address allocation policy. The following types of DUIDs are currently defined:

• DUID Based on Link-Layer Address Plus Time (DUID-LLT): This type of DUID is generated based on the link-layer address and the time the DUID is generated.

• DUID Assigned by Vendor Based on Enterprise Number (DUID-EN): This type of DUID is generated based on a vendor's enterprise number as registered with IANA.

• DUID Based on Link-Layer Address (DUID-LL): This type of DUID is generated based on the link-layer address.

DHCPv6 Multicast Address

Similar to a DHCPv4 client, a DHCPv6 client does not need to be configured with a DHCPv6 server's IP address. Instead, the DHCPv6 client sends a Solicit message carrying a multicast destination address to locate the DHCPv6 server. If multiple DHCPv6 servers exist, a DHCPv6 client can select a server in accordance with a specified policy (for example, based on the Preference option). Two multicast addresses are defined in DHCPv6:

• All_DHCP_Relay_Agents_and_Servers (FF02::1:2)

  This multicast address is used for all servers and relay agents in a broadcast domain. It is used by a DHCPv6 client to interact with all DHCPv6 servers and relay agents.

• All_DHCP_Servers (FF05::1:3)

  This multicast address is used for all servers in a broadcast domain. When a DHCPv6 relay agent needs to forward packets to a DHCPv6 server whose unicast address is unknown, this multicast address can be used for packet forwarding.

Interaction Modes for a DHCPv6 Client and Server

DHCPv6 adopts the client/server model. A client sends an Information-request message to a server for a valid dynamic IPv6 address/prefix or other configuration information, and the server responds with a Reply message containing the corresponding configuration information according to a specified policy. In different phases, the client and server exchange different information in different modes.

• Two-message exchange to obtain configuration information

  • After a DHCPv6 client obtains an IPv6 address/prefix through stateless address autoconfiguration, it multicasts an Information-request message.

  • Upon receipt of the Information-request message, the DHCPv6 server sends the DHCPv6 client a Reply message containing the configuration information to be allocated to the client.

• Two-message exchange to obtain the IPv6 address/prefix and other configuration information

  When a DHCPv6 client accesses the network for the first time, it can obtain an IPv6 address/prefix and other configuration information through two-message exchange.

  • When a DHCPv6 client accesses the network for the first time, it multicasts a Solicit message containing the Rapid Commit option.

  • Upon receipt of the Solicit message, a DHCPv6 server selects an IPv6 address/prefix from the IPv6 address/prefix pool and assigns it to the DHCPv6 client. If the DHCPv6 server supports two-message exchange, it sends a Reply message containing the leased IPv6 address/prefix and other configuration information to the DHCPv6 client. If the DHCPv6 server does not support two-message exchange, it sends an Advertise message.

  • If the DHCPv6 client receives a Reply message, it uses the IPv6 address/prefix and other configuration information contained in the message. If the DHCPv6 client receives only an Advertise message within a specified period, it undergoes four-message exchange according to the configured policy.

    

    Two-message exchange applies to scenarios where only one DHCPv6 server exists on the network. If more than one DHCPv6 server exists, using two-message exchange may cause a waste of IPv6 addresses/prefixes.

• Four-message exchange to obtain IPv6 addresses/prefixes and other configuration information

  Similar to a DHCPv4 client, a DHCPv6 client undergoes four-message exchange to obtain IPv6 addresses/prefixes and other configuration information when it accesses the network for the first time.

  • Discovery stage

    The DHCPv6 client searches for a DHCPv6 server.

    The DHCPv6 client multicasts a Solicit message.

  • Offer stage

    The DHCPv6 server offers an IPv6 address/prefix.

    After a DHCPv6 server receives the Solicit message, it selects an unassigned IPv6 address/prefix from the IPv6 address/prefix pool and then responds to the DHCPv6 client with an Advertise message that carries the selected IPv6 address/prefix and other configuration information.

  • Selection stage

    The DHCPv6 client selects an IPv6 address/prefix.

    If multiple DHCPv6 servers send Advertise messages to the DHCPv6 client, the DHCPv6 client selects a server according to the configured policy. If the Advertise message sent by a DHCPv6 server carries the Server Unicast option and the DHCPv6 client also supports this option, the DHCPv6 client unicasts a Request message to the DHCPv6 server. Otherwise, the DHCPv6 client multicasts a Request message containing the information used to instruct the selected DHCPv6 server to offer an IPv6 address/prefix.

  • Acknowledgment stage

    The DHCPv6 server confirms the offered IPv6 address/prefix.

    After receiving the Request message, the DHCPv6 server sends the DHCPv6 client a Reply message containing the offered IPv6 address/prefix and other configuration information. The DHCPv6 client then applies the IPv6 address/prefix and other configuration information carried in the message.

    

    Except the address offered by the DHCPv6 server selected by the DHCPv6 client, the unassigned IPv6 addresses/prefixes offered by other DHCPv6 servers are available for other DHCPv6 clients.

• DHCPv6 client's extending the IPv6 address/prefix lease

  When a DHCPv6 server assigns an IPv6 address/prefix to a DHCPv6 client, the DHCPv6 server sends a message containing the preferred lifetime, valid lifetime, lease renewal time, and rebind time. Their relationship is as follows: lease renewal time < rebind time < preferred lifetime < valid lifetime.

  The preferred lifetime is used to limit the lease renewal time and rebind time. By default, the lease renewal time and rebind time account for 50% and 80%, respectively, of the preferred lifetime.

  The valid lifetime is the validity period of an IPv6 address or a prefix. After the valid lifetime expires, the DHCPv6 server reclaims the IPv6 address/prefix. If the DHCPv6 client wants to keep the IPv6 address/prefix, it must renew the lease before the valid lifetime expires.

  When the lease of the IPv6 address/prefix expires, the DHCPv6 client automatically sends a Renew message to the DHCPv6 server. If both the DHCPv6 client and server support unicast, the DHCPv6 client unicasts a Renew message. Otherwise, the DHCPv6 client multicasts a Renew message.

  After a DHCPv6 server receives the Renew message, if the contained IPv6 address/prefix is valid and the lease can be renewed, the DHCPv6 server responds with a Reply message containing the new lease of the IPv6 address/prefix. After the DHCPv6 client receives the Reply message, it renews the lease of the IPv6 address/prefix.

  If the IPv6 address/prefix is not renewed before the rebind time expires, the DHCPv6 client multicasts a Rebind message to all reachable DHCPv6 servers.

  After a DHCPv6 server receives the Rebind message, if the contained IPv6 address/prefix is valid and the lease can be renewed, the DHCPv6 server responds with a Reply message containing the new lease of the IPv6 address/prefix. After the DHCPv6 client receives the Reply message, it renews the lease of the IPv6 address/prefix.

• DHCPv6 client's check on whether its IPv6 address/prefix is still available when the link to which the DHCPv6 client is connected changes

  When the link to which the DHCPv6 client is connected changes, for example, the network cable is loosely connected, the DHCPv6 client needs to send a Confirm message to the server to check whether its IPv6 address/prefix is still available.

  If the IPv6 address needs to be validated, the DHCPv6 client multicasts a Confirm message containing the IPv6 address to be validated.

  After a DHCPv6 server receives the Confirm message, if the IPv6 address can still be used, the DHCPv6 server sets the status of the IPv6 address to Success in a Reply message and sends the Reply message to the DHCPv6 client. After receiving the Reply message, the DHCPv6 client can continue to use the IPv6 address. If the IPv6 prefix needs to be validated, the DHCPv6 client multicasts a DHCPv6 Rebind message containing the IPv6 prefix to be validated. The DHCPv6 server processes the Rebind message and replies with a Reply message. After the DHCPv6 client receives the Reply message, if the lifetime of the prefix is not 0, the DHCPv6 client continues to use the prefix and renews its lease.

• DHCPv6 client's detection of IPv6 address conflicts

  If a DHCPv6 client detects an IPv6 address conflict, it sends a message to notify the DHCPv6 server of the address conflict.

  Specifically, the DHCPv6 client sends a Decline message carrying the conflicting IPv6 address to the DHCPv6 server. The source address of the Decline message cannot be a conflicting address. If both the DHCPv6 client and server support unicast, the DHCPv6 client unicasts a Decline message. Otherwise, the DHCPv6 client multicasts a Decline message.

  Upon receipt of the Decline message, the DHCPv6 server marks the IPv6 address carried in the message as a conflicting address.

  

  If the DHCPv6 server and client are on different network segments, address conflicts cannot be detected.

• DHCPv6 client's releasing of an IPv6 address/prefix

  To release its IPv6 address/prefix, a DHCPv6 client sends the DHCPv6 server a Release message containing the IPv6 address/prefix to be released. If both the DHCPv6 client and server support unicast, the client unicasts a Release message. Otherwise, the DHCPv6 client multicasts a Release message.

  After receiving the Release message from the DHCPv6 client, the DHCPv6 server releases the IPv6 address/prefix assigned to the DHCPv6 client and responds with a Reply message.

• Lease time of an IPv6 prefix pool

  The DHCPv6 server can specify different lease times for different IPv6 prefix pools. All the prefixes in a DHCPv6 prefix pool have the same lease time.

• Renew time and rebind time of an IPv6 address pool

  In different IPv6 address pools, the proportions of the renew time and rebind time in the preferred lifetime can be set to different values. In one IPv6 address pool, the proportions of the renew time and rebind time in the preferred lifetime are fixed.

• Hot standby

  For a device equipped with two main control boards, DHCPv6 data on the master main control board is backed up to the slave one in real time. Therefore, if a master/slave switchover is performed, the associated DHCPv6 functions on the slave main control board can still work properly.