Network Working Group | F. Templin, Ed. |
Internet-Draft | Boeing Research & Technology |
Intended status: Informational | January 21, 2015 |
Expires: July 25, 2015 |
Client-Inserted Client Link-Layer Address Options in DHCPv6
draft-templin-client-cllao-00.txt
RFC6939 presents 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.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 25, 2015.
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
[RFC6939] specifies a method for DHCPv6 relays[RFC3315] 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 server to receive a CLLAO even when it is on the same link as the client. In that case, the client itself must insert the CLLAO.
Asymmetric Extended Route Optimization (AERO) [I-D.templin-aerolink] is an example of a link where it may be difficult or impossible for the DHCPv6 server to determine the DHCPv6 client's link-layer address through normal socket API operations. In that case, if the client inserts a CLLAO option the server can discover the client's link-layer address by examining the option fields of the DHCPv6 message instead of the message headers. The following section specifies the protocol for client-inserted CLLAOs.
When a DHCPv6 client is on the same link as the server, and the server requires a means for discovering the client's link-layer address, the client inserts a CLLAO option [RFC6939] in its DHCPv6 messages and writes the link-layer address of the sending interface in the "link-layer address" field.
When a DHCPv6 server is on the same link as the client, and the client includes a CLLAO option in its DHCPv6 messages, the server 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 [RFC6939].
A DHCPv6 client MUST NOT include a CLLAO option if it is not on the same link as the server.
This document introduces no IANA considerations.
When DHCPv6 authentication [RFC3315] and/or DHCPv6 Security [I-D.ietf-dhc-sedhcpv6] are used, the DHCPv6 client/server MUST NOT include the CLLAO option in security signature calculations. This means that the link-layer address in the CLLAO could be rewritten by a link-layer switching element on the path from the client to the server and not detected by the security mechanism. However, such a condition would only be possible on unsecured links where link-layer switching elements present a man-in-the-middle attack threat.
[RFC3315] | Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003. |
[RFC6939] | Halwasia, G., Bhandari, S. and W. Dec, "Client Link-Layer Address Option in DHCPv6", RFC 6939, May 2013. |
[I-D.ietf-dhc-sedhcpv6] | Jiang, S., Shen, S., Zhang, D. and T. Jinmei, "Secure DHCPv6", Internet-Draft draft-ietf-dhc-sedhcpv6-05, December 2014. |
[I-D.templin-aerolink] | Templin, F., "Transmission of IP Packets over AERO Links", Internet-Draft draft-templin-aerolink-50, December 2014. |