What address is DHCPv6 solicit messages sent?

Skip to main content

This browser is no longer supported.

Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.

1.3 Overview

• Article
• 06/24/2021
• 10 minutes to read

In this article

DHCP uses the following basic steps to automatically configure a network address and configuration information on a DHCP client. The application of DHCP discussed here is an illustrative example of an IPv4 network, where the DHCP client and the DHCP server are on the same subnet and the client machine has no prior IP address configured on the network interface. DHCP can also be used by a client to obtain configuration parameters (other than the IP address) from the DHCP server. For further details, see section 3.4 of [RFC2131].

1. When the TCP/IP protocol initializes and DHCPv4 has been enabled on any of the client machine's interfaces, the DHCPv4 client sends a DHCPDISCOVER message to find the DHCPv4 servers on the network and to obtain a valid IPv4 address configuration. The DHCP client includes a Vendor Class Identifier Option that contains "vendor-class identifier" information about the host, such as the operating system version.

2. All DHCPv4 servers that receive the DHCPDISCOVER message and have been configured with valid IPv4 address configuration for the client send a DHCPOFFER message back to the DHCPv4 client. The DHCPv4 servers optionally include other configuration information for the client in the DHCPOFFER message, in case the client wants to select the specific configuration information that it desires. If configuration information is included, then based on the vendor class identifier that the client included in the message, the DHCPv4 servers also include any specific standard options or vendor-specific options appropriate to hosts running that operating system version. If no specific standard options or vendor-specific options are defined for hosts running that operating system version, the server ignores the Vendor Class Identifier Option sent by the client.

3. The DHCPv4 client selects an IPv4 address configuration to use from the DHCPOFFER messages that it receives. The DHCPv4 client then sends a DHCPREQUEST message to the selected DHCPv4 server by using the Server ID option, requesting the use of the selected configuration. The client again includes its vendor class identifier in the message.

4. The DHCPREQUEST message identifies the server that sent the offer that the DHCPv4 client selected. The DHCPv4 servers for which the Server Identifier sent by the client in the DHCPREQUEST does not match the Server ID put the offered IPv4 address back into the available pool of addresses. The selected DHCPv4 server assigns the IPv4 address configuration to the DHCPv4 client and sends a DHCPACK (acknowledgment) message to the DHCPv4 client. The DHCPv4 server includes configuration information, including any specific standard options or vendor-specific options based on the vendor class identifier sent by the client in the DHCPREQUEST message.

The DHCPv4 client computer completes the TCP/IP initialization. It then repeats the preceding steps for other interfaces, if present, for which DHCP is enabled. (See the following figure.) After this is complete, the client can use all TCP/IP services and applications for normal network communications and connectivity to other IPv4 hosts.

Figure 1: Basic DHCP process

The DHCPv4 client can decline an offer from a DHCPv4 server if it determines that the IP address included in the DHCPOFFER message sent by the server is already in use on that network. If so, the DHCPv4 client sends a DHCPDECLINE message and restarts the configuration process by sending a DHCPDISCOVER message again.

The DHCPv4 server can send a DHCPNAK message in response to the client's DHCPREQUEST message if one or more of the desired configuration options sent by the client in that message are unacceptable. In this case, the DHCPv4 client restarts the configuration process by sending a DHCPDISCOVER message again.

The DHCPv4 client can relinquish its lease on the IP address by sending a DHCPRELEASE message to the server.

In some cases, the DHCPv4 client can remember and want to reuse an IP address that was previously allocated by the DHCPv4 server to it. In this case, the client begins the initialization process by sending a DHCPREQUEST message to the server containing that network address as the "requested IP address". The DHCPv4 server sends a DHCPACK message to the client if it chooses to allow the client to continue to use that IP address. Otherwise, the DHCPv4 server sends a DHCPNAK message to the client.

For further details on the DHCP protocol overview, refer to section 3 of [RFC2131].

DHCPv6 uses the following basic steps to automatically configure a network address on a DHCPv6 client. The application of DHCPv6 discussed here is an illustrative example of an IPv6 network. The DHCPv6 client and the DHCPv6 server are on the same subnet, and the client machine has no prior IPv6 address configured on the network interface. DHCPv6 can also be used by a client to obtain configuration parameters (other than the IP address) from the DHCPv6 server. Details are as specified in [RFC3315] sections 1, 18.1.5, and 18.2.5.

1. When the TCP/IP protocol initializes and DHCPv6 has been enabled on any of the client machine's interfaces, the DHCPv6 client sends a DHCPv6 Solicit message to the All_DHCP_Relay_Agents_and_Servers multicast address specified in [RFC3315] to discover the available DHCPv6 servers. The DHCPv6 client includes a Vendor Class Option that contains information about the host, such as the operating system version.

2. All DHCPv6 servers that receive the DHCPv6 Solicit message from the client and have been configured with valid IPv6 address configuration information for the client send a DHCPv6 Advertise message in response to the DHCPv6 client. The DHCPv6 servers optionally include other configuration information for the client in the DHCPv6 Advertise message, in case the client wants to select the specific configuration information it requires. If configuration information is included, then based on the vendor class information that the client included in the message, the DHCPv6 servers also include any specific standard options or vendor-specific options appropriate to hosts running that operating system version. If no specific standard options or vendor-specific options are defined for hosts running that operating system version, the DHCPv6 servers ignore the Vendor Class Option sent by the client.

3. The DHCPv6 client selects an IPv6 address configuration to use from the DHCPv6 Advertise messages that it receives. The DHCPv6 client then sends a DHCP Request message to the selected DHCPv6 server by using the Server Identifier option, requesting the use of the selected configuration. The client again includes a Vendor Class Option in the message.

4. The DHCPv6 Request message identifies the server that sent the offer that the DHCPv6 client selected. The DHCPv6 servers for which the Server Identifier sent by the client in DHCPv6 Request does not match the Server Identifier put the offered IPv6 address back into the available pool of addresses. The selected DHCPv6 server assigns the IPv6 address configuration to the DHCPv6 client and sends a DHCPv6 Reply message with no Status Code option to the DHCPv6 client. The DHCPv6 servers include the configuration information, including any specific standard options or vendor-specific options based on the vendor class information sent by the client in the DHCPv6 Request message.

The presence of a Status Code option with any value other than Success in a DHCPv6 message from the server to the client is construed as a failure, and the DHCPv6 client then restarts the initialization process by sending the DHCPv6 Solicit message again.

The DHCPv6 client computer completes the TCP/IP initialization as described in the preceding steps. It then repeats the preceding steps for other interfaces, if present, for which DHCPv6 is enabled. (See the following figure.) After this is complete, the client can use all TCP/IP services and applications for normal network communications and connectivity to other IPv6 hosts.

Figure 2: Basic DHCPv6 process

The DHCPv6 client can decline an offer from a DHCPv6 server if it finds that the IPv6 address included in the DHCPv6 Advertise message sent by the server is already in use on that network. If so, the DHCPv6 client sends a DHCPv6 Decline message and restarts the configuration process by sending a DHCPv6 Solicit message again.

The DHCPv6 server can send a DHCPv6 Reply message with a Status Code option with a value other than Success in response to the client's DHCPv6 Request message if one or more of the desired configuration options sent by the client in that message are unacceptable. In this case, the DHCPv6 client restarts the configuration process by sending a DHCPv6 Solicit message again.

The DHCPv6 client can relinquish its lease on the IP address by sending a DHCPv6 Release message to the server.

In some cases, the DHCPv6 client can remember and want to reuse an IP address that was previously allocated by the DHCPv6 server to it. In this case, the client begins the initialization process by sending a DHCPv6 Renew or Rebind message to the server containing that network address as the "requested IP address". The DHCPv6 server sends a DHCPv6 Reply message with no Status Code option to the client if it chooses to allow the client to continue to use that IPv6 address. Otherwise, the DHCPv6 server sends a DHCP Reply message to the client with a value other than Success.

For further details of the DHCPv6 protocol overview, see section 3 of [RFC3315].

Accidental configuration of multiple DHCP servers on a network might cause misconfiguration of DHCP clients. DHCP servers can implement Rogue Detection to prevent such accidental configurations. A Rogue Aware Server periodically checks whether it is authorized.

Rogue Detection can be implemented using DHCPINFORM and/or DHCPv6 Information-request messages ([RFC3315] section 15.12). The following scenarios are valid for Rogue Detection:

Authorization of a DHCPv4 server using DHCPINFORM.

1. A Validating Server sends a broadcast DHCPINFORM message containing a designated vendor-specific option requesting other Rogue Aware Servers on the network to respond.

2. A Rogue Aware Administratively Authorized Server replies to the DHCPINFORM message by sending a DHCPACK message with the corresponding vendor-specific option with a NULL-terminated string in the option data.

3. A Rogue Authorized Server on the network replies to the DHCPINFORM message by sending a DHCPACK message containing the corresponding vendor-specific option with a NULL-terminated string in the option data.

4. Any DHCP servers that are not Rogue Aware can reply to the DHCPINFORM message by sending a DHCPACK message, which does not contain the corresponding vendor-specific option.

5. A Rogue Aware Unauthorized Server on the network will not reply to the DHCPINFORM message.

6. If a Validating Server receives a DHCPACK message from an Administratively Authorized Server, it will consider itself unauthorized.

7. If a Validating Server does not receive a DHCPACK message from an Administratively Authorized Server within a stipulated time, it retries sending the DHCPINFORM message.

8. If a Validating Server receives a DHCPACK message from a Rogue Authorized Server, or a server which is not Rogue Aware, it retries sending the DHCPINFORM message.

9. The maximum number of retries is implementation specific. After all retry attempts are exhausted, the Validating Server can consider itself authorized or continue validation using the DHCPv6 Information-request message.

Figure 3: DHCPv4 Server Authorization messages

Authorization of a DHCP server using Information-request.

1. A Validating Server sends a DHCPv6 Information-request message containing a designated vendor specific option requesting other Rogue Aware Servers on the network to respond.

2. A Rogue Aware Administratively Authorized Server replies to the DHCPv6 Information-request message by sending a DHCPv6 Reply message containing the corresponding vendor-specific option with a NULL-terminated string in the option data.

3. A Rogue Authorized Server on the network replies to the DHCPv6 Information-request message by sending a DHCPv6 Reply message containing the corresponding vendor-specific option with a NULL-terminated string in the option data.

4. Any DHCP server that is not Rogue Aware can reply to the DHCPv6 Information-request message by sending a DHCPv6 Reply message that does not contain the corresponding vendor-specific option.

5. A Rogue Aware Unauthorized Server on the network will not reply to the DHCPv6 Information-request message.

6. If a Validating Server receives a DHCPv6 Reply message from an Administratively Authorized Server, it will consider itself unauthorized.

7. If a Validating Server does not receive a DHCPv6 Reply message from an Administratively Authorized Server within a stipulated time, it retries sending the DHCPv6 Information-request message.

8. If a Validating Server receives a DHCPv6 Reply message from a Rogue Authorized Server, or a server which is not Rogue Aware, it retries sending the DHCPv6 Information-request message.

9. The maximum number of retries is implementation-specific. After all retry attempts are exhausted, the Validating Server will consider itself authorized.

Figure 4: DHCPv6 Server Authorization messages

What is DHCPv6 solicit message?

What is DHCPv6 address?

What address is used to contact a DHCPv6 server?

What are the normal DHCPv6 messages?