Boeing Research & Technology

P.O. Box 3707 Seattle WA 98124 USA fltemplin@acm.org

I-D Internet-Draft RFC6939 specifies a method for DHCPv6 relay agents to insert a Client Link Layer Address Option (CLLAO) in a DHCPv6 Relay-Forward message. In some cases, however, the DHCPv6 client may need to insert a CLLAO in its message on its own behalf even though it is on the same link as the DHCPv6 server. This document discusses client-inserted CLLAOs.

specifies a method for DHCPv6 relays to insert a Client Link-Layer Address Option (CLLAO) in Relay-Forward messages. This provides a means for a first-hop relay to inform the DHCPv6 server of the link-layer address of the DHCPv6 client on the client<->relay link. However, on some links it may be necessary for the client to include a CLLAO even though it is on the same link as the server. Asymmetric Extended Route Optimization (AERO) is an example of a "DHCPv6-over-(foo)" link layer where the client and server are always on the same link but it may be difficult or impossible for the DHCPv6 server process to determine the client's link-layer address through normal socket API operations. Additionally, it may be difficult or impossible for the client to determine its own link-layer address (as seen by the server) since the address may be altered by a link-layer switching element on the path. In that case, if the client inserts a CLLAO option the server's (foo) driver can use the option to convey the client's link-layer address to the DHCPv6 server process, and then from the DHCPv6 server process back to the client in the DHCPv6 reply. The following section specifies the protocol for client-inserted CLLAOs.

When a DHCPv6 client is on the same link as the server, and a supplementary client link-layer address discovery method is necessary, the client inserts a CLLAO option in its DHCPv6 messages and writes any link-layer-specific values in the non-mutable portions of the "link-layer address" field as specified by the relevant "DHCPv6-over-(foo) document. When a DHCPv6 server is on the same link as the client, and the client includes a CLLAO option in a DHCPv6 message, the server's (foo) driver writes the client's observed link-layer address in the mutable portions of the "link-layer address" field of the option and delivers the message to the DHCPv6 server process. The server then processes the CLLAO option locally as necessary and returns the CLLAO option in its DHCPv6 replies. When a DHCPv6 relay on the same link as a client forwards the client's DHCPv6 messages, and the server requires a means for discovering the client's link-layer address, the relay follows the specifications in . A DHCPv6 server MUST ignore a CLLAO option supplied by the client if it is not on the same link as the client. A DHCPv6 client SHOULD NOT include a CLLAO option if it is not on the same link as the server.

This document introduces no IANA considerations.

The CLLAO suppled by the client may contain both a non-mutable portion and a mutable portion that is rewritten by the server's (foo) driver. When DHCPv6 authentication and/or DHCPv6 Security are used, the client and server MUST first write the value '0' in any mutable fields of the CLLAO in the client's DHCPv6 message before performing security transformations. When the server returns the CLLAO to the client in a DHCPv6 reply, however, it performs security transformations with the actual client link-layer address in the mutable fields rather than writing the value '0'. This means that the mutable portions of the client's link-layer address could be rewritten by a link-layer switching element on the path from the client to the server and not detected by the DHCPv6 security mechanism. However, such a condition would only be a matter of concern on unmanaged/unsecured links where the link-layer switching elements themselves present a man-in-the-middle attack threat. For this reason, IP security MUST be used when this mechanism is employed over unmanaged/unsecured links.