Triggering DHCPv6 Reconfiguration from Relay Agents
Extracted elements (25)
Reconfigure-Reply was introduced to provide explicit server acknowledgment rather than having the relay monitor Reconfigure messages implicitly. The implicit approach can fail when the server accepts the request but delays generating Reconfigure messages due to rate-limiting, or when the request partially fails for some clients.
The default server behavior is to reject Reconfigure-Request messages (rather than accept) because allowing an untrusted relay to trigger Reconfigure messages poses a security risk. An administrator must explicitly enable this feature on the server.
The Link Address Option is required in Reconfigure-Request (rather than relying on the relay's peer address) so the server can correctly identify the client's link, consistent with how link identification works during normal relay-forward operations per RFC 3315 Section 20.1.1.
The relay agent MUST use a link-address value in the Link Address Option equivalent to the value used when relaying messages from the client to the server. To defend against poor implementations, the relay SHOULD use the exact same value previously sent to the server.
Clients and servers MUST silently discard any received Reconfigure-Reply messages. The relay MUST silently discard Reconfigure-Reply messages where the transaction-id does not match, the Server Identifier Option is absent, or the Status Code Option is absent.
Clients MUST silently discard any received Reconfigure-Request messages.
If the Reconfigure-Request is successfully validated, the server MUST return a 'Success' Status Code and MUST include a list of all Client Identifier Options for clients to which Reconfigure messages will not be sent. 'Success' is returned even if no Reconfigure messages will be sent to any client.
Intermediate relay agents MUST be configurable to accept or reject Reconfigure-Request messages from other relay agents. The default behavior when no explicit configuration is present is to accept Reconfigure-Request messages.
Servers MUST discard any received Reconfigure-Request messages that lack a Client Identifier Option, lack a Link Address Option, or include a Server Identifier Option whose contents do not match the server's identifier.
The relay agent MUST include one or more Client Identifier Options and a Link Address Option in the Reconfigure-Request so the DHCPv6 server can identify the affected client(s) and the link on which they are located.
The relay MUST rate-limit Reconfigure-Request messages sent to the server and MUST be configured with required rate-limit parameters. The maximum Reconfigure-Request packet size SHOULD be configurable and the default value MUST be 1280 octets.
The relay SHOULD use Reconfigure-Reply, not an observed Reconfigure message encapsulated in Relay-Reply, to determine whether the Reconfigure-Request was successfully handled by the server.
The server MUST be configurable to accept or reject Reconfigure-Request messages. The default behavior when no indication is explicitly configured is to reject Reconfigure-Request messages.
The server MUST include a Status Code Option in the Reconfigure-Reply indicating whether the request was successfully processed, failed, or partially failed. UnspecFail MUST be returned for malformed requests, NotAllowed if the server is not configured to allow Reconfigure-Request, and NotConfigured if the server has no record of the link.
The server MUST rate-limit Reconfigure messages triggered by Reconfigure-Request messages and MUST be configured with required rate-limit parameters.
When several affected clients exceed the maximum message size, the relay MUST generate multiple Reconfigure-Request messages to carry all Client Identifier Options. The relay MUST NOT add clients to the list in retransmissions but MAY remove them.
Reconfigure-Request retransmission follows RFC 3315 Section 14 with parameters: IRT=1 second, MRT=10 seconds, MRC=5, MRD=0 (no maximum duration).
The problem scenario motivating this RFC involves an RSOO (Relay-Supplied Options option, RFC 6422) carrying configuration data (e.g., DS-Lite tunnel name) that can change via a RADIUS CoA message to the NAS/relay agent, but the DHCPv6 server has no means to detect such a change and cannot issue a Reconfigure message without this new mechanism.
Two new DHCPv6 message types are defined: RECONFIGURE-REQUEST (type code 18) and RECONFIGURE-REPLY (type code 19). Both use the same message format as defined in Section 6 of RFC 3315.
IANA assigned two new DHCPv6 Message types (RECONFIGURE-REQUEST and RECONFIGURE-REPLY) and one new DHCPv6 Option Code (OPTION_LINK_ADDRESS, value 80) in the DHCPv6 parameters registry.
Because Reconfigure-Request can trigger DHCPv6 Reconfigure messages (which can control the timing of DHCPv6 renewal), the server MUST have a mechanism for determining that the relay agent is a trusted entity. DHCPv6 servers and relay agents MUST implement relay message authentication as described in Section 21.1 of RFC 3315.
In networks where the security of machines with access to the data path is not under the control of the server administrator, IPsec (RFC 4301) is necessary to prevent spoofing of Reconfigure-Request messages. DHCPv6 servers MUST silently discard Reconfigure-Request messages originating from unknown relay agents.
Relay agents SHOULD implement appropriate means to prevent using Reconfigure-Request messages as a denial-of-service attack on the DHCPv6 servers. DHCPv6 servers MAY be configured to reject relayed Reconfigure-Request messages or restrict relay chaining.
Upon receiving a Reconfigure-Reply, the relay transitions based on the status code: NotAllowed, NotConfigured, or Success triggers termination of the request; UnspecFail triggers a corrected retransmission. With multiple servers, the request is deemed successful for a client if at least one Reconfigure-Reply does not include that client's Client Identifier Option.
The Link Address Option (OPTION_LINK_ADDRESS, code 80) carries a 16-octet IPv6 address used by the server to identify the link on which the client is located. The option-len field is fixed at 16.