Handling Unknown DHCPv6 Messages
obsoleted by
- rfc-8415 — Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
updates
- rfc-3315 — Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
Extracted elements (14)
If a future message type is defined that is sent unsolicited to relay agents, non-conforming relays will forward it to DHCP servers instead. Since DHCP servers do not respond to unknown messages, this is unlikely to create significant load, making a relay identification strategy probably unnecessary.
Most future DHCPv6 messages are expected not to communicate directly with relay agents, though relay agents may still need to relay them. This justifies the blanket forward-unknown-to-server rule without requiring relay agents to understand new message semantics.
RFC 3315 did not specify behavior for unknown message types, leading to relay agents inappropriately dropping messages and DHCP agents inappropriately processing them. This document fills that gap by providing explicit normative behavior for all three agent roles.
The sole purpose of requiring relay agents to forward unknown messages is to ensure that when legitimate new DHCPv6 messages are defined in the future, relay agents manufactured prior to those definitions will by default succeed in relaying such messages, maintaining forward compatibility.
Relay agents are administratively permitted to be configured to drop messages based on message type for security reasons (e.g., in a firewall), and nothing in this update should be construed to prevent such configuration.
This document updates RFC 3315 by explicitly defining relay agent, client, and server behavior when receiving unknown DHCPv6 message types. Implementations not updated to conform to this specification may behave incorrectly when encountering unknown messages.
A DHCPv6 client or server MUST silently discard any received DHCPv6 message with an unknown message type.
If a relay agent receives a Relay-reply message, it MUST process the message as defined in Section 20.2 of RFC 3315 regardless of the type of message encapsulated in the Relay Message option.
If a relay agent receives messages other than Relay-forward and Relay-reply and does not recognize the message type, it MUST forward them toward the server as described in Section 20.1.1 of RFC 3315.
A message is valid for constructing a new Relay-forward message if: (a) it is a Relay-forward message, (b) the relay agent recognizes the message type and is not the intended target, or (c) the relay agent does not recognize the message type. This extends Section 20.1 of RFC 3315.
Relay agents forward messages in two directions: Relay-reply messages are sent toward the client (to the destination address specified in the message), while Relay-forward and all other message types (including unknown types) are sent toward the server via the default forwarding path.
Because relay agents forward all unknown DHCPv6 message types, a malicious attacker can interfere with the relaying function by constructing fake DHCPv6 messages with arbitrary type codes. This is analogous to existing attacks using known type codes in DHCPv4 and DHCPv6.
Clients and servers that have not been updated to implement silent discard of unknown messages may become newly vulnerable to relay-agent-mediated attacks as a result of relay agents now forwarding unknown messages. Authors recommend updating all three agent types to the new specification.
In most deployment scenarios, attacking clients directly is easier than through a relay agent, and attacks using unknown message types are already possible on the local wire. At sites where only servers and relay agents can be upgraded, the incremental benefit of doing so likely exceeds the risk from vulnerable clients.