Client Link-Layer Address Option in DHCPv6
Extracted elements (16)
DHCPv4 provides the client link-layer address directly in the message header (htype/chaddr fields), but DHCPv6 only mandates a DUID with no simple mechanism to extract a link-layer address. This gap complicates correlation of DHCPv4 and DHCPv6 bindings for the same dual-stack client in service provider deployments.
Placing the client link-layer address in DHCPv6 Relay-Forward messages (rather than in client messages) was chosen so that the option is populated by the first-hop relay agent, which has direct link-layer visibility, without requiring any changes to DHCPv6 client implementations.
RFC 4361 described a mechanism for using the same DUID in DHCPv4 and DHCPv6 to correlate clients, but it requires modification of existing DHCPv4 clients and has not seen broad industry adoption. A relay-agent-carried option was chosen as a simpler, server/relay-only solution requiring no client changes.
The mechanism is unnecessary when the DHCPv6 server is directly connected to the same network link as the client, because the server can obtain the link-layer address from the link-layer header of the DHCPv6 message directly.
There is no requirement that a DHCPv6 server return the Client Link-Layer Address option and its data in any downstream (server-to-client) DHCP message; the option is strictly for relay-to-server communication.
DHCPv6 clients MUST NOT send the Client Link-Layer Address option, and MUST ignore it if received. The option is only exchanged between relay agents and servers.
DHCPv6 relay agents MAY include the link-layer source address of the received DHCPv6 message in the Client Link-Layer Address option in relayed Relay-Forward messages, but only for messages originating from clients (e.g., Solicit, Request) — not for Relay-Forward or Advertise messages.
If a DHCPv6 server receives a Client Link-Layer Address option in any encapsulated message that is not a Relay-Forward DHCP message, the server MUST silently ignore that option.
If configured to store or use a client link-layer address, a DHCPv6 server SHOULD look for the Client Link-Layer Address option in the Relay-Forward message of the relay agent closest to the client.
The link-layer type field in the Client Link-Layer Address option MUST be a valid hardware type assigned by IANA, as described in RFC 826.
The DHCPv6 Client Link-Layer Address option (OPTION_CLIENT_LINKLAYER_ADDR, code 79) carries the client's link-layer address type (16-bit IANA hardware type) and variable-length link-layer address in DHCPv6 Relay-Forward messages. Option-length is 2 plus the length of the link-layer address.
IANA assigned option code 79 to OPTION_CLIENT_LINKLAYER_ADDR in the 'DHCP Option Codes' registry for DHCPv6 parameters.
A rogue DHCPv6 relay agent or a DHCPv6 client posing as a relay agent can insert an incorrect Client Link-Layer Address option, enabling a DHCPv6 client to masquerade as a DHCPv4 client with the same link-layer address. This could allow DNS spoofing attacks, e.g., installing a fraudulent AAAA record under the same name as a legitimate DHCPv4 client's A record.
DHCP server administrators are strongly advised to configure DHCP servers using this option to communicate with relay agents via IPsec (as described in RFC 3315, Section 21.1) to prevent relay agent masquerade attacks.
In deployments where the physical network operator and the connectivity provider are administratively separate, the Client Link-Layer Address option may reveal client identity information to a party that would not otherwise have it. IPsec is strongly recommended to provide confidentiality for relay-agent-to-server messages, especially over open networks.
OPTION_CLIENT_LINKLAYER_ADDR encoding: 2-octet option-code (79), 2-octet option-length (2 + link-layer address length), 16-bit link-layer type (IANA hardware type per RFC 826), followed by the variable-length link-layer address.