RFC 8415
Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
Pages: 154
Proposed Standard
→ Errata
Obsoletes: 3315 3633 3736 4242 7083 7283 7550
Proposed Standard
→ Errata
Obsoletes: 3315 3633 3736 4242 7083 7283 7550
Part 6 of 14 – Pages 50 to 61
18. DHCP Configuration Exchanges
A client initiates a message exchange with a server or servers to acquire or update configuration information of interest. A client has many reasons to initiate the configuration exchange. Some of the more common ones are: 1. as part of the operating system configuration/bootstrap process, 2. when requested to do so by the application layer (through an operating-system-specific API), 3. when a Router Advertisement indicates that DHCPv6 is available for address configuration (see Section 4.2 of [RFC4861]), 4. as required to extend the lifetime of address(es) and/or delegated prefix(es), using Renew and Rebind messages, or 5. upon the receipt of a Reconfigure message, when requested to do so by a server.
The client is responsible for creating IAs and requesting that a server assign addresses and/or delegated prefixes to the IAs. The client first creates the IAs and assigns IAIDs to them. The client then transmits a Solicit message containing the IA options describing the IAs. The client MUST NOT be using any of the addresses or delegated prefixes for which it tries to obtain the bindings by sending the Solicit message. In particular, if the client had some valid bindings and has chosen to start the server discovery process to obtain the same bindings from a different server, the client MUST stop using the addresses and delegated prefixes for the bindings that it had obtained from the previous server (see Section 18.2.7 for more details on what "stop using" means in this context) and that it is now trying to obtain from a new server. A DHCP client that does not need to have a DHCP server assign IP addresses or delegated prefixes to it can obtain configuration information such as a list of available DNS servers [RFC3646] or NTP servers [RFC5908] through a single message and reply exchange with a DHCP server. To obtain configuration information, the client first sends an Information-request message (see Section 18.2.6) to the All_DHCP_Relay_Agents_and_Servers multicast address. Servers respond with a Reply message containing the configuration information for the client (see Section 18.3.6). To request the assignment of one or more addresses or delegated prefixes, a client first locates a DHCP server and then requests the assignment of addresses/prefixes and other configuration information from the server. The client does this by sending the Solicit message (see Section 18.2.1) to the All_DHCP_Relay_Agents_and_Servers multicast address and collecting Advertise messages from the servers that respond to the client's message; the client then selects a server from which it wants to obtain configuration information. This process is referred to as server discovery. When the client has selected the server, it sends a Request message to that server as described in Section 18.2.2. A client willing to perform the Solicit/Reply message exchange described in Section 18.2.1 includes a Rapid Commit option (see Section 21.14) in its Solicit message. Servers that can assign addresses or delegated prefixes to the IAs respond to the client with an Advertise message or Reply message if the client included a Rapid Commit option and the server is configured to accept it. If the server responds with an Advertise message, the client initiates a configuration exchange as described in Section 18.2.2.
A server may initiate a message exchange with a client by sending a Reconfigure message to cause the client to send a Renew, Rebind, or Information-request message to refresh its configuration information as soon as the Reconfigure message is received by the client. Figure 9 shows a timeline diagram of the messages exchanged between a client and two servers for the typical lifecycle of one or more leases. This starts with the four-message Solicit/Advertise/ Request/Reply exchange to obtain the lease(s), followed by a two-message Renew/Reply exchange to extend the lifetime on the lease(s), and then ends with a two-message Release/Reply exchange to end the client's use of the lease(s). Server Server (not selected) Client (selected) v v v | | | | Begins initialization | | | | start of | _____________/|\_____________ | 4-message |/ Solicit | Solicit \| exchange | | | Determines | Determines configuration | configuration | | | |\ | ____________/| | \________ | /Advertise | | Advertise\ |/ | | \ | | | Collects Advertises | | \ | | | Selects configuration | | | | | _____________/|\_____________ | |/ Request | Request \| | | | | | Commits configuration | | | end of | | _____________/| 4-message | |/ Reply | exchange | | | | Initialization complete | | | | . . . . . . | T1 (renewal) timer expires | | | |
2-message | _____________/|\_____________ | exchange |/ Renew | Renew \| | | | | | Commits extended lease(s) | | | | | _____________/| | |/ Reply | . . . . . . | | | | Graceful shutdown | | | | 2-message | _____________/|\_____________ | exchange |/ Release | Release \| | | | | | Discards lease(s) | | | | | _____________/| | |/ Reply | | | | v v v Figure 9: Timeline Diagram of the Messages Exchanged between a Client and Two Servers for the Typical Lifecycle of One or More Leases18.1. A Single Exchange for Multiple IA Options
This document assumes that a client SHOULD use a single transaction for all of the IA options required on an interface; this simplifies the client implementation and reduces the potential number of transactions required (for the background on this design choice, refer to Section 4 of [RFC7550]). To facilitate a client's use of a single transaction for all IA options, servers MUST return the same T1/T2 values for all IA options in a Reply (see Sections 18.3.2, 18.3.4, and 18.3.5) so that the client will generate a single transaction when renewing or rebinding its leases. However, because some servers may not yet conform to this requirement, a client MUST be prepared to select appropriate T1/T2 times as described in Section 18.2.4.18.2. Client Behavior
A client uses the Solicit message to discover DHCP servers configured to assign leases or return other configuration parameters on the link to which the client is attached. A client uses Request, Renew, Rebind, Release, and Decline messages during the normal lifecycle of addresses and delegated prefixes.
When a client detects that it may have moved to a new link, it uses Confirm if it only has addresses and Rebind if it has delegated prefixes (and addresses). It uses Information-request messages when it needs configuration information but no addresses and no prefixes. When a client requests multiple IA option types or multiple instances of the same IA types in a Solicit, Request, Renew, or Rebind, it is possible that the available server(s) may only be configured to offer a subset of them. When possible, the client SHOULD use the best configuration available and continue to request the additional IAs in subsequent messages. This allows the client to maintain a single session and state machine. In practice, especially in the case of handling IA_NA and IA_PD requests [RFC7084], this situation should be rare or a result of a temporary operational error. Thus, it is more likely that the client will get all configuration if it continues, in each subsequent configuration exchange, to request all the configuration information it is programmed to try to obtain, including any stateful configuration options for which no results were returned in previous message exchanges. Upon receipt of a Reconfigure message from the server, a client responds with a Renew, Rebind, or Information-request message as indicated by the Reconfigure Message option (see Section 21.19). The client SHOULD be suspicious of the Reconfigure message (they may be faked), and it MUST NOT abandon any resources it might have already obtained. The client SHOULD treat the Reconfigure message as if the T1 timer had expired. The client will expect the server to send IAs and/or other configuration information to the client in a Reply message. If the client has a source address of sufficient scope that can be used by the server as a return address and the client has received a Server Unicast option (see Section 21.12) from the server, the client SHOULD unicast any Request, Renew, Release, and Decline messages to the server. Use of unicast may avoid delays due to the relaying of messages by relay agents, as well as avoid overhead on servers due to the delivery of client messages to multiple servers. However, requiring the client to relay all DHCP messages through a relay agent enables the inclusion of relay agent options in all messages sent by the client. The server should enable the use of unicast only when relay agent options will not be used.
18.2.1. Creation and Transmission of Solicit Messages
The client sets the "msg-type" field to SOLICIT. The client generates a transaction ID and inserts this value in the "transaction-id" field. The client MUST include a Client Identifier option (see Section 21.2) to identify itself to the server. The client includes IA options for any IAs to which it wants the server to assign leases. The client MUST include an Elapsed Time option (see Section 21.9) to indicate how long the client has been trying to complete the current DHCP message exchange. The client uses IA_NA options (see Section 21.4) to request the assignment of non-temporary addresses, IA_TA options (see Section 21.5) to request the assignment of temporary addresses, and IA_PD options (see Section 21.21) to request prefix delegation. IA_NA, IA_TA, or IA_PD options, or a combination of all, can be included in DHCP messages. In addition, multiple instances of any IA option type can be included. The client MAY include addresses in IA Address options (see Section 21.6) encapsulated within IA_NA and IA_TA options as hints to the server about the addresses for which the client has a preference. The client MAY include values in IA Prefix options (see Section 21.22) encapsulated within IA_PD options as hints for the delegated prefix and/or prefix length for which the client has a preference. See Section 18.2.4 for more on prefix-length hints. The client MUST include an Option Request option (ORO) (see Section 21.7) to request the SOL_MAX_RT option (see Section 21.24) and any other options the client is interested in receiving. The client MAY additionally include instances of those options that are identified in the Option Request option, with data values as hints to the server about parameter values the client would like to have returned. The client includes a Reconfigure Accept option (see Section 21.20) if the client is willing to accept Reconfigure messages from the server. The client MUST NOT include any other options in the Solicit message, except as specifically allowed in the definition of individual options.
The first Solicit message from the client on the interface SHOULD be delayed by a random amount of time between 0 and SOL_MAX_DELAY. This random delay helps desynchronize clients that start a DHCP session at the same time, such as after recovery from a power failure or after a router outage after seeing that DHCP is available in Router Advertisement messages (see Section 4.2 of [RFC4861]). The client transmits the message according to Section 15, using the following parameters: IRT SOL_TIMEOUT MRT SOL_MAX_RT MRC 0 MRD 0 A client that wishes to use the Rapid Commit two-message exchange includes a Rapid Commit option (see Section 21.14) in its Solicit message. The client may receive a number of different replies from different servers. The client will make note of any valid Advertise messages that it receives. The client will discard any Reply messages that do not contain the Rapid Commit option. Upon receipt of a valid Reply with the Rapid Commit option, the client processes the message as described in Section 18.2.10. At the end of the first RT period, if no suitable Reply messages are received but the client has valid Advertise messages, then the client processes the Advertise as described in Section 18.2.9. If the client subsequently receives a valid Reply message that includes a Rapid Commit option, it does one of the following: - processes the Reply message as described in Section 18.2.10 and discards any Reply messages received in response to the Request message - processes any Reply messages received in response to the Request message and discards the Reply message that includes the Rapid Commit option If the client is waiting for an Advertise message, the mechanism described in Section 15 is modified as follows for use in the transmission of Solicit messages. The message exchange is not terminated by the receipt of an Advertise before the first RT has elapsed. Rather, the client collects valid Advertise messages until
the first RT has elapsed. Also, the first RT MUST be selected to be strictly greater than IRT by choosing RAND to be strictly greater than 0. A client MUST collect valid Advertise messages for the first RT seconds, unless it receives a valid Advertise message with a preference value of 255. The preference value is carried in the Preference option (see Section 21.8). Any valid Advertise that does not include a Preference option is considered to have a preference value of 0. If the client receives a valid Advertise message that includes a Preference option with a preference value of 255, the client immediately begins a client-initiated message exchange (as described in Section 18.2.2) by sending a Request message to the server from which the Advertise message was received. If the client receives a valid Advertise message that does not include a Preference option with a preference value of 255, the client continues to wait until the first RT elapses. If the first RT elapses and the client has received a valid Advertise message, the client SHOULD continue with a client-initiated message exchange by sending a Request message. If the client does not receive any valid Advertise messages before the first RT has elapsed, it then applies the retransmission mechanism described in Section 15. The client terminates the retransmission process as soon as it receives any valid Advertise message, and the client acts on the received Advertise message without waiting for any additional Advertise messages. A DHCP client SHOULD choose MRC and MRD values of 0. If the DHCP client is configured with either MRC or MRD set to a value other than 0, it MUST stop trying to configure the interface if the message exchange fails. After the DHCP client stops trying to configure the interface, it SHOULD restart the reconfiguration process after some external event, such as user input, system restart, or when the client is attached to a new link.18.2.2. Creation and Transmission of Request Messages
The client uses a Request message to populate IAs with leases and obtain other configuration information. The client includes one or more IA options in the Request message. The server then returns leases and other information about the IAs to the client in IA options in a Reply message. The client sets the "msg-type" field to REQUEST. The client generates a transaction ID and inserts this value in the "transaction-id" field.
The client MUST include the identifier of the destination server in a Server Identifier option (see Section 21.3). The client MUST include a Client Identifier option (see Section 21.2) to identify itself to the server. The client adds any other appropriate options, including one or more IA options. The client MUST include an Elapsed Time option (see Section 21.9) to indicate how long the client has been trying to complete the current DHCP message exchange. The client MUST include an Option Request option (see Section 21.7) to request the SOL_MAX_RT option (see Section 21.24) and any other options the client is interested in receiving. The client MAY additionally include instances of those options that are identified in the Option Request option, with data values as hints to the server about parameter values the client would like to have returned. The client includes a Reconfigure Accept option (see Section 21.20) if the client is willing to accept Reconfigure messages from the server. The client transmits the message according to Section 15, using the following parameters: IRT REQ_TIMEOUT MRT REQ_MAX_RT MRC REQ_MAX_RC MRD 0 If the message exchange fails, the client takes an action based on the client's local policy. Examples of actions the client might take include the following: - Select another server from a list of servers known to the client -- for example, servers that responded with an Advertise message. - Initiate the server discovery process described in Section 18. - Terminate the configuration process and report failure.
18.2.3. Creation and Transmission of Confirm Messages
The client uses a Confirm message when it has only addresses (no delegated prefixes) assigned by a DHCP server to determine if it is still connected to the same link when the client detects a change in network information as described in Section 18.2.12. The client sets the "msg-type" field to CONFIRM. The client generates a transaction ID and inserts this value in the "transaction-id" field. The client MUST include a Client Identifier option (see Section 21.2) to identify itself to the server. The client MUST include an Elapsed Time option (see Section 21.9) to indicate how long the client has been trying to complete the current DHCP message exchange. The client includes IA options for all of the IAs assigned to the interface for which the Confirm message is being sent. The IA options include all of the addresses the client currently has associated with those IAs. The client SHOULD set the T1 and T2 fields in any IA_NA options (see Section 21.4) and the preferred-lifetime and valid-lifetime fields in the IA Address options (see Section 21.6) to 0, as the server will ignore these fields. The first Confirm message from the client on the interface MUST be delayed by a random amount of time between 0 and CNF_MAX_DELAY. The client transmits the message according to Section 15, using the following parameters: IRT CNF_TIMEOUT MRT CNF_MAX_RT MRC 0 MRD CNF_MAX_RD If the client receives no responses before the message transmission process terminates, as described in Section 15, the client SHOULD continue to use any leases, using the last known lifetimes for those leases, and SHOULD continue to use any other previously obtained configuration parameters.
18.2.4. Creation and Transmission of Renew Messages
To extend the preferred and valid lifetimes for the leases assigned to the IAs and obtain new addresses or delegated prefixes for IAs, the client sends a Renew message to the server from which the leases were obtained; the Renew message includes IA options for the IAs whose lease lifetimes are to be extended. The client includes IA Address options (see Section 21.6) within IA_NA (see Section 21.4) and IA_TA (see Section 21.5) options for the addresses assigned to the IAs. The client includes IA Prefix options (see Section 21.22) within IA_PD options (see Section 21.21) for the delegated prefixes assigned to the IAs. The server controls the time at which the client should contact the server to extend the lifetimes on assigned leases through the T1 and T2 values assigned to an IA. However, as the client SHOULD renew/rebind all IAs from the server at the same time, the client MUST select T1 and T2 times from all IA options that will guarantee that the client initiates transmissions of Renew/Rebind messages not later than at the T1/T2 times associated with any of the client's bindings (earliest T1/T2). At time T1, the client initiates a Renew/Reply message exchange to extend the lifetimes on any leases in the IA. A client MUST also initiate a Renew/Reply message exchange before time T1 if the client's link-local address used in previous interactions with the server is no longer valid and it is willing to receive Reconfigure messages. If T1 or T2 had been set to 0 by the server (for an IA_NA or IA_PD) or there are no T1 or T2 times (for an IA_TA) in a previous Reply, the client may, at its discretion, send a Renew or Rebind message, respectively. The client MUST follow the rules defined in Section 14.2. The client sets the "msg-type" field to RENEW. The client generates a transaction ID and inserts this value in the "transaction-id" field. The client MUST include a Server Identifier option (see Section 21.3) in the Renew message, identifying the server with which the client most recently communicated. The client MUST include a Client Identifier option (see Section 21.2) to identify itself to the server. The client adds any appropriate options, including one or more IA options.
The client MUST include an Elapsed Time option (see Section 21.9) to indicate how long the client has been trying to complete the current DHCP message exchange. For IAs to which leases have been assigned, the client includes a corresponding IA option containing an IA Address option for each address assigned to the IA and an IA Prefix option for each prefix assigned to the IA. The client MUST NOT include addresses and prefixes in any IA option that the client did not obtain from the server or that are no longer valid (that have a valid lifetime of 0). The client MAY include an IA option for each binding it desires but has been unable to obtain. In this case, if the client includes the IA_PD option to request prefix delegation, the client MAY include the IA Prefix option encapsulated within the IA_PD option, with the "IPv6-prefix" field set to 0 and the "prefix-length" field set to the desired length of the prefix to be delegated. The server MAY use this value as a hint for the prefix length. The client SHOULD NOT include an IA Prefix option with the "IPv6-prefix" field set to 0 unless it is supplying a hint for the prefix length. The client includes an Option Request option (see Section 21.7) to request the SOL_MAX_RT option (see Section 21.24) and any other options the client is interested in receiving. The client MAY include options with data values as hints to the server about parameter values the client would like to have returned. The client transmits the message according to Section 15, using the following parameters: IRT REN_TIMEOUT MRT REN_MAX_RT MRC 0 MRD Remaining time until earliest T2 The message exchange is terminated when the earliest time T2 is reached. While the client is responding to a Reconfigure, the client ignores and discards any additional Reconfigure messages it may receive. The message exchange is terminated when the earliest time T2 is reached, at which point the client begins the Rebind message exchange (see Section 18.2.5).
(next page on part 7)