Lightweight DHCPv6 Relay Agent
updates
- rfc-3315 — Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
Extracted elements (27)
Options contained in DHCPv6 messages MUST NOT be validated by the LDRA. This design decision delegates option validity checking to the DHCP server, allowing new options to be introduced without requiring any changes to the LDRA.
The LDRA sets link-address to the Unspecified Address (::) because it resides on the same link as the client and has no IP routing capability, making the concept of a meaningful link-address inapplicable. Servers must be updated to ignore zero link-address fields for address selection.
The LDRA was introduced to allow Relay Agent Information (including Interface-ID) to be inserted by access nodes (DSLAMs, Ethernet switches) that perform only Layer 2 bridging and have no IPv6 control or routing capability. This fills the gap where a DHCPv6 server would otherwise be unaware of how a client is attached to the network.
RFC 6221 updates RFC 3315 Section 11 to require that DHCP servers conforming to this specification MUST, for address selection purposes, ignore any link-address field whose value is zero, including nested Relay-Forward link-address fields.
The LDRA message format is intentionally unchanged from RFC 3315 to maintain interoperability with existing DHCP relays and servers. The LDRA implements the same Relay-Forward and Relay-Reply message types as a standard DHCPv6 Relay Agent.
A Relay-Reply message is valid for the LDRA only if: the Interface-ID option is present and corresponds to a valid interface; the peer-address and destination IP address are identical and link-local when no IP address is configured on the LDRA; and the link-address is Unspecified when no IP address is configured.
DHCP servers MUST ignore any link-address field whose value is the Unspecified Address (::) for the purposes of address selection, treating the client as if the message were not relayed.
Every LDRA Relay-Forward message MUST include both the Relay-Message option (encapsulating the original client message) and the Interface-ID option. These are the mandatory DHCP options for the LDRA.
If a Relay-Message option would exceed the MTU of the outgoing interface, it MUST be discarded and an error condition SHOULD be logged.
If the client-received message is already a Relay-Forward, the LDRA MUST set the hop-count field in the newly created Relay-Forward to the received hop-count value incremented by 1, as specified in RFC 3315.
In Relay-Forward messages created by the LDRA, the link-address parameter MUST be set to the Unspecified Address (::), the peer-address MUST be set per Section 6.1, and the Interface-ID option MUST be included.
On receipt of a DHCP message on a client-facing interface, the LDRA MUST discard messages of types ADVERTISE (2), REPLY (7), RECONFIGURE (10), and RELAY-REPL (13), as these are server-to-client messages that should not arrive on client-facing interfaces.
The DHCPv6 server MUST include the Interface-ID option in Relay-Reply messages so that the LDRA can determine the correct client-facing interface for forwarding the decapsulated message.
The Interface-ID SHOULD be considered an opaque value by servers (servers SHOULD NOT parse it), the LDRA SHOULD use the same Interface-ID value for a given interface, and this value SHOULD be retained across restarts to ensure reliable use in server parameter assignment policies.
The LDRA MUST copy the IP destination and link-layer destination addresses from the client-originated message into the Relay-Forward message, and MUST copy the IP source address into the peer-address field and the link-layer source address into the link-layer source address.
The LDRA MUST have each of its interfaces configured as either client-facing or network-facing, and MUST intercept all UDP traffic to All_DHCP_Relay_Agents_and_Servers (ff02::1:2) on port 547 arriving on client-facing interfaces.
The LDRA MUST implement a trusted/untrusted configuration for all client-facing interfaces (SHOULD be configurable per interface). On untrusted interfaces, the LDRA MUST discard any RELAY-FORW (12) message received from the client.
The LDRA MUST intercept all IP traffic on the network-facing interface with a link-local scoped source address, link-local scoped destination address, UDP protocol, and destination port 547, and MUST only forward Relay-Reply messages; all other DHCP message types MUST be silently discarded.
The LDRA MUST prevent the original client message from being forwarded on the network-facing interface; it must encapsulate the message into a Relay-Forward message instead.
When forwarding a Relay-Reply to the client, the LDRA MUST copy the link-layer and IP source address from the Relay-Reply message into the outgoing IP/UDP packet forwarded to the client.
When the LDRA receives a Relay-Reply message with an Interface-ID option present and link-address unspecified, the LDRA MUST relay the decapsulated message to the client on the interface identified in the Interface-ID option.
The Relay-Forward message is used by the LDRA to forward client messages toward the server. It carries three key parameters: link-address (always set to the Unspecified Address by an LDRA), peer-address (copied from the client's IP source address), and the Interface-ID option identifying the client-facing interface.
The Relay-Reply message is constructed by the DHCPv6 server and must include an Interface-ID option so the LDRA can identify which client-facing interface to forward the decapsulated message on.
The hop-count-based determination of LDRA trustworthiness can be easily defeated by a rogue relay agent on the network-facing interface of the LDRA, since an attacker on that segment can inject arbitrary relay messages. All DHCPv6 relay agent security issues from RFC 3315 Section 23 apply to the LDRA.
The LDRA SHOULD implement rate-limiting on client-originated traffic to prevent excessive process utilization. Traffic is easily identified since the LDRA only listens for DHCPv6 traffic to All_DHCPv6_Servers_and_Relay_Agents on UDP port 547; excess messages may be silently discarded.
The LDRA operates on a per-interface client-facing/network-facing distinction: on client-facing interfaces it intercepts DHCP client messages and wraps them in Relay-Forward; on the network-facing interface it intercepts Relay-Reply messages and decapsulates them for forwarding to clients. Messages of unexpected type are silently dropped in each direction.
The LDRA uses the Relay-Forward message format from RFC 3315 unchanged, with fields: msg-type (RELAY-FORW), hop-count, link-address (set to :: by LDRA), peer-address (client's link-local address), followed by options including mandatory Interface-ID and Relay-Message options.