Rebind Capability in DHCPv6 Reconfigure Messages
updates
- rfc-3315 — Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
Extracted elements (18)
Rebind was chosen as the new allowed response type because a Rebind message does not include a Server Identifier option, allowing any DHCPv6 server to respond. This enables use cases such as migrating clients to a different server when the original server is being shut down, which Renew cannot support because Renew binds to a specific server.
RFC 3315 did not specify that a Reconfigure must come from the server with which the client most recently communicated, nor which server the client should identify in its Renew response. RFC 6644 clarifies that the client MUST use the same server identifier it would use after T1 expiry, resolving ambiguity for implementations.
This document updates RFC 3315 Sections 19.1.1, 19.1.2, 19.2, 19.4.1, 19.4.2, and 19.4.4, and Section 22.19 (Reconfigure Message option definition). Implementations conforming only to RFC 3315 will not recognize msg-type 6 (Rebind) in the Reconfigure Message option.
DHCPv6 clients that support Reconfigure-Rebind MUST implement the Reconfigure Key authentication protocol as described in RFC 3315 Section 21.5. Other authentication mechanisms such as Secure DHCPv6 (CGA-based) may optionally be implemented.
For retransmission of client messages triggered by a Reconfigure, the client uses the same variables and retransmission algorithm as for Renew, Rebind, or Information-request messages in client-initiated exchanges (RFC 3315 Sections 18.1.3, 18.1.4, and 18.1.5). If no response is received by end of retransmission, the Reconfigure is ignored and discarded.
If a client is currently sending Rebind messages as described in RFC 3315 Section 18.1.4, it ignores any received Reconfigure messages.
If the server does not receive a Renew, Rebind, or Information-request from the client within REC_TIMEOUT, it retransmits the Reconfigure, doubles REC_TIMEOUT, and repeats. After REC_MAX_RC unsuccessful attempts the server SHOULD abort the reconfigure process for that client.
In response to a Rebind message, the server generates and sends a Reply as described in RFC 3315 Sections 18.2.4 and 18.2.8, including options for configuration parameters. The server MAY include IAs and new parameter values even if not requested in the Rebind.
The server MUST include a Reconfigure Message option in each Reconfigure message to indicate whether the client should respond with a Renew, a Rebind, or an Information-request message.
The server MUST NOT include any options in the Reconfigure message other than those explicitly allowed by the definition of individual options.
Upon receipt of a valid Reconfigure message, the client MUST respond with a Renew, Rebind, or Information-request as indicated by the Reconfigure Message option. The client ignores the transaction-id field in the received Reconfigure.
When responding to a Reconfigure with a Rebind, the client creates and sends the Rebind exactly as specified in RFC 3315 Section 18.1.4, except it copies the Option Request option and any IA options from the Reconfigure message into the Rebind.
When sending a Renew message in response to a Reconfigure message, the client MUST include a Server Identifier option identifying the server with which the client most recently communicated.
While a reconfigure-triggered transaction is in progress, the client silently discards any subsequently received Reconfigure messages.
RFC 6644 extends the Reconfigure Message option to permit msg-type value 6 (Rebind), in addition to the RFC 3315 values 5 (Renew) and 11 (Information-request), enabling a server to direct a client to rebind to any available server.
A malicious attacker can send a faked Reconfigure message with msg-type Rebind to force the client to disconnect from its current server and relink to a rogue server by quickly responding to the client's Rebind. This attack is analogous to existing server-spoofing attacks on Solicit/Request and is mitigated by using the AUTH option (RFC 3315) or CGA-based Secure DHCPv6.
Client reconfigure-triggered state: on receipt of valid Reconfigure, client transitions to in-progress transaction state and sends Renew, Rebind, or Information-request per the msg-type field; it discards further Reconfigure messages until the transaction completes or retransmission times out, at which point it returns to idle.
The Reconfigure Message option (OPTION_RECONF_MSG, code 19) carries a single 1-octet msg-type field. Valid values are 5 (Renew), 6 (Rebind), and 11 (Information-request); option-len is always 1.