19. DHCP Server-Initiated Configuration Exchange
- DHCP Server-Initiated Configuration Exchange
A server initiates a configuration exchange to cause DHCP clients to obtain new addresses and other configuration information. For example, an administrator may use a server-initiated configuration exchange when links in the DHCP domain are to be renumbered. Other
examples include changes in the location of directory servers, addition of new services such as printing, and availability of new software.
19.1. Server Behavior
A server sends a Reconfigure message to cause a client to initiate immediately a Renew/Reply or Information-request/Reply message exchange with the server.
19.1.1. Creation and Transmission of Reconfigure Messages
The server sets the "msg-type" field to RECONFIGURE. The server sets the transaction-id field to 0. The server includes a Server Identifier option containing its DUID and a Client Identifier option containing the client's DUID in the Reconfigure message.
The server MAY include an Option Request option to inform the client of what information has been changed or new information that has been added. In particular, the server specifies the IA option in the Option Request option if the server wants the client to obtain new address information. If the server identifies the IA option in the Option Request option, the server MUST include an IA option that contains no other sub-options to identify each IA that is to be reconfigured on the client.
Because of the risk of denial of service attacks against DHCP clients, the use of a security mechanism is mandated in Reconfigure messages. The server MUST use DHCP authentication in the Reconfigure message.
The server MUST include a Reconfigure Message option (defined in section 22.19) to select whether the client responds with a Renew message or an Information-Request message.
The server MUST NOT include any other options in the Reconfigure except as specifically allowed in the definition of individual options.
A server sends each Reconfigure message to a single DHCP client, using an IPv6 unicast address of sufficient scope belonging to the DHCP client. If the server does not have an address to which it can send the Reconfigure message directly to the client, the server uses a Relay-reply message (as described in section 20.3) to send the Reconfigure message to a relay agent that will relay the message to the client. The server may obtain the address of the client (and the
appropriate relay agent, if required) through the information the server has about clients that have been in contact with the server, or through some external agent.
To reconfigure more than one client, the server unicasts a separate message to each client. The server may initiate the reconfiguration of multiple clients concurrently; for example, a server may send a Reconfigure message to additional clients while previous reconfiguration message exchanges are still in progress.
The Reconfigure message causes the client to initiate a Renew/Reply or Information-request/Reply message exchange with the server. The server interprets the receipt of a Renew or Information-request message (whichever was specified in the original Reconfigure message) from the client as satisfying the Reconfigure message request.
19.1.2. Time Out and Retransmission of Reconfigure Messages
If the server does not receive a Renew or Information-request message from the client in REC_TIMEOUT milliseconds, the server retransmits the Reconfigure message, doubles the REC_TIMEOUT value and waits again. The server continues this process until REC_MAX_RC unsuccessful attempts have been made, at which point the server SHOULD abort the reconfigure process for that client.
Default and initial values for REC_TIMEOUT and REC_MAX_RC are documented in section 5.5.
19.2. Receipt of Renew Messages
The server generates and sends a Reply message to the client as described in sections 18.2.3 and 18.2.8, including options for configuration parameters.
The server MAY include options containing the IAs and new values for other configuration parameters in the Reply message, even if those IAs and parameters were not requested in the Renew message from the client.
19.3. Receipt of Information-request Messages
The server generates and sends a Reply message to the client as described in sections 18.2.5 and 18.2.8, including options for configuration parameters.
The server MAY include options containing new values for other configuration parameters in the Reply message, even if those parameters were not requested in the Information-request message from the client.
19.4. Client Behavior
A client receives Reconfigure messages sent to the UDP port 546 on interfaces for which it has acquired configuration information through DHCP. These messages may be sent at any time. Since the results of a reconfiguration event may affect application layer programs, the client SHOULD log these events, and MAY notify these programs of the change through an implementation-specific interface.
19.4.1. Receipt of Reconfigure Messages
Upon receipt of a valid Reconfigure message, the client responds with either a Renew message or an Information-request message as indicated by the Reconfigure Message option (as defined in section 22.19). The client ignores the transaction-id field in the received Reconfigure message. While the transaction is in progress, the client silently discards any Reconfigure messages it receives.
DISCUSSION:
The Reconfigure message acts as a trigger that signals the client
to complete a successful message exchange. Once the client has
received a Reconfigure, the client proceeds with the message
exchange (retransmitting the Renew or Information-request message
if necessary); the client ignores any additional Reconfigure
messages until the exchange is complete. Subsequent Reconfigure
messages cause the client to initiate a new exchange.
How does this mechanism work in the face of duplicated or
retransmitted Reconfigure messages? Duplicate messages will be
ignored because the client will begin the exchange after the
receipt of the first Reconfigure. Retransmitted messages will
either trigger the exchange (if the first Reconfigure was not
received by the client) or will be ignored. The server can
discontinue retransmission of Reconfigure messages to the client
once the server receives the Renew or Information-request message
from the client.
It might be possible for a duplicate or retransmitted Reconfigure
to be sufficiently delayed (and delivered out of order) to arrive
at the client after the exchange (initiated by the original
Reconfigure) has been completed. In this case, the client would
initiate a redundant exchange. The likelihood of delayed and out
of order delivery is small enough to be ignored. The consequence
of the redundant exchange is inefficiency rather than incorrect
operation.
19.4.2. Creation and Transmission of Renew Messages
When responding to a Reconfigure, the client creates and sends the Renew message in exactly the same manner as outlined in section 18.1.3, with the exception that the client copies the Option Request option and any IA options from the Reconfigure message into the Renew message.
19.4.3. Creation and Transmission of Information-request Messages
When responding to a Reconfigure, the client creates and sends the Information-request message in exactly the same manner as outlined in section 18.1.5, with the exception that the client includes a Server Identifier option with the identifier from the Reconfigure message to which the client is responding.
19.4.4. Time Out and Retransmission of Renew or Information-request Messages
The client uses the same variables and retransmission algorithm as it does with Renew or Information-request messages generated as part of a client-initiated configuration exchange. See sections 18.1.3 and 18.1.5 for details. If the client does not receive a response from the server by the end of the retransmission process, the client ignores and discards the Reconfigure message.
19.4.5. Receipt of Reply Messages
Upon the receipt of a valid Reply message, the client processes the options and sets (or resets) configuration parameters appropriately. The client records and updates the lifetimes for any addresses specified in IAs in the Reply message.