The DHCPv4 Relay Agent Identifier Sub-Option
Extracted elements (15)
Administrators may use UUIDs (RFC 4122) or provisioning-system role assignments to achieve Relay-ID uniqueness. DHCP servers with configurable duplicate-ID event notification can help detect unintended duplication; network management systems can also collect all relay agent Relay-IDs and alert on conflicts.
In industrial (factory-floor) Ethernet networks, client location is more useful than client identity. Combining a relay-unique port/slot value with a network-element-unique Relay-ID allows DHCP servers to use connection-based identifiers without manual address configuration.
Relay agents may be unable to add the Relay Agent Information option to all message types (e.g., IP-unicast RENEW messages). Deployments must either accept server-side persistence of the last-seen relay identifier or use the Server Identifier Override sub-option (RFC 5107) to permit insertion into all relayed messages.
The Relay-ID sub-option is administratively configurable so that when a relay device is replaced due to failure or upgrade, the new device can continue providing the same relay identifier as the old device, preserving server-to-relay associations for lease bindings.
The Relay-ID sub-option is carried within the DHCPv4 Relay Agent Information option (RFC 3046). DHCP servers that recognize the Relay Agent Information option echo it back in replies, enabling end-to-end Relay-ID visibility.
A relay agent SHOULD use a single identifier value consistently, and the identifier SHOULD be committed to stable storage unless the relay device can regenerate the value upon reboot.
A Relay-ID configured in a relay agent MUST be unique within its administrative domain. Duplicate Relay-IDs may cause resource allocation problems as the DHCP server attempts to allocate the same resource to devices behind different relay agents.
Relay agents SHOULD make their relay identifiers visible to their administrators via their user interface, a log entry, a MIB field, or some other mechanism, to aid in ensuring uniqueness.
The authentication sub-option for the DHCP Relay Agent Information option (RFC 4030) SHOULD be deployed as a defense against forged Relay Agent Information options, though it is not a requirement for supporting the Relay-ID sub-option.
An administrative domain in this document consists of all DHCP servers and relay agents that communicate with each other; the Relay-ID must be unique within this scope, not globally.
The Relay Agent Identifier (Relay-ID) sub-option is a new sub-option for the DHCPv4 Relay Agent Information option (RFC 3046) that carries a sequence of octets uniquely identifying the relay agent within its administrative domain. The value is normally administratively configured in the relay agent.
IANA assigned sub-option code 12 to the Relay Agent Identifier Sub-Option in the 'DHCP Relay Agent Sub-Option Codes' registry (bootp-dhcp-parameters).
Forged Relay Agent Information options, including forged Relay-IDs, are a threat. A perimeter defense blocking these options from untrusted sources combined with the RFC 4030 authentication sub-option mitigates this risk and also helps avoid duplication of relay identifiers by malicious entities.
In factory-floor deployments, an incorrect Relay-ID could cause devices to be misconfigured in ways that produce incorrect results, cause physical damage, or create hazardous conditions for workers. Administrators must use dependable techniques (e.g., hardware tokens physically attached to the installation location) to prevent misconfiguration in such environments.
The Relay-ID sub-option uses sub-option code 12 (SUBOPT_RELAY_ID), followed by a 1-octet length field (excluding the sub-option ID and length fields, minimum length one), followed by the variable-length identifier octets.