Relay-Supplied DHCP Options
updates
- rfc-3315 — Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
Extracted elements (20)
DHCPv6 clients cannot receive options directly from relay agents because relay agents are required to deliver the server's payload unmodified. The RSOO indirection mechanism — relay sends options to the server, server forwards them to client — was chosen to work within this constraint while enabling relay-agent-specific information delivery.
The RSOO mechanism is intentionally not a general-purpose store for client configuration in relay agents; it targets specific use cases where only the relay agent has information needed by the client, such as the ERP Local Domain Name (RFC 6440).
The server preference for the innermost RSOO value (relay agent closest to the client) as the default conflict-resolution rule reflects the principle that the relay agent with the most direct knowledge of the client's network attachment is most authoritative for client-facing options.
This document updates RFC 3315 (DHCPv6) by explicitly codifying the previously implicit requirement that relay agents MUST NOT modify the content of encapsulation payloads as they are relayed back toward clients.
By default, the DHCP server MUST choose the innermost value — the value supplied by the relay agent closest to the DHCP client — when conflicting RSOO options are present from multiply-nested relay messages.
DHCP server implementations SHOULD have an administrator-configurable list of RSOO-enabled options so that new RSOO-enabled options do not require software updates.
DHCP servers implementing this specification MUST examine each option contained in an RSOO to verify it is RSOO-enabled and MUST silently discard any option in an RSOO that is not RSOO-enabled.
If the server receives an RSOO, it SHOULD add options from the RSOO for which it has no internal candidate to the list of options to send to the client, and SHOULD discard any RSOO options for which it already has one or more candidates.
Relay agents MAY include an RSOO in the option payload of a Relay-Forward message being sent toward a DHCP server.
Relay agents MUST NOT send non-RSOO-enabled options in the Relay-Supplied Options option.
Relay agents that implement the RSOO and are configured to disable forwarding of Relay-Forward messages containing RSOOs MUST silently discard any such message, and MUST examine all Relay-Forward encapsulations, not just the outer encapsulation.
The RSOO MUST NOT contain any option that is not specifically called out as an RSOO-enabled option. Specifications defining RSOO-enabled options MUST reference this specification and MUST state the option is RSOO-enabled. No DHCP option specified prior to this document is RSOO-enabled.
When multiply-nested Relay-Forward messages contain conflicting values for options in their respective RSOOs, the DHCP server MUST choose no more than one of these options to forward to the client and MUST NOT forward more than one of these options.
When relaying the payload of Relay-Reply messages toward clients, relay agents MUST NOT modify the payload. This makes explicit an implicit requirement from RFC 3315.
The Relay-Supplied Options option (RSOO) is a new DHCPv6 option that relay agents include in Relay-Forward messages to supply options the DHCPv6 server can then pass to the client. It encapsulates one or more DHCPv6 options that the relay agent wishes the server to forward to the client.
IANA assigned option code 66 (OPTION_RSOO) in the DHCPv6 Option Codes registry for the Relay-Supplied Options option.
IANA created a new registry titled 'Options Permitted in the Relay-Supplied Options Option' listing DHCPv6 option codes that may appear in the RSOO. Options may only be added after IETF Review, with careful security analysis of allowing relay agents to supply values for each candidate option.
A malicious node acting as a relay agent on the untrusted side of a network boundary can supply an RSOO containing RSOO-enabled options that override the same options provided by a trusted relay agent on the network side. Network administrators in such environments are advised to configure trusted relay agents to drop Relay-Forward messages containing the RSOO.
Dropping RSOO-containing messages is only effective if the DHCP server's response to the client is authenticated per RFC 3315 Section 21 or a similar mechanism; without authentication, a malicious node can modify the server's response in transit and the client cannot detect it.
The RSOO is encoded with a 16-bit OPTION_RSOO code field (value 66), a 16-bit option-length field indicating the total length of the encapsulated options, followed by one or more DHCPv6 options.