Internet DRAFT - draft-templin-client-cllao
draft-templin-client-cllao
Network Working Group F. Templin, Ed.
Internet-Draft Boeing Research & Technology
Intended status: Informational January 22, 2015
Expires: July 26, 2015
Client-Inserted Client Link-Layer Address Options in DHCPv6
draft-templin-client-cllao-01.txt
Abstract
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.
Status of This Memo
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 26, 2015.
Copyright Notice
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
Templin Expires July 26, 2015 [Page 1]
Internet-Draft Client CLLAO January 2015
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Client-Inserted CLLAOs . . . . . . . . . . . . . . . . . . . 2
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3
4. Security Considerations . . . . . . . . . . . . . . . . . . . 3
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 4
6.1. Normative References . . . . . . . . . . . . . . . . . . 4
6.2. Informative References . . . . . . . . . . . . . . . . . 4
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 4
1. Introduction
[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 client to include a CLLAO even though it is on the same link as
the server.
Asymmetric Extended Route Optimization (AERO) [I-D.templin-aerolink]
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.
2. 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 [RFC6939] 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.
Templin Expires July 26, 2015 [Page 2]
Internet-Draft Client CLLAO January 2015
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 [RFC6939].
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.
3. IANA Considerations
This document introduces no IANA considerations.
4. Security 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 [RFC3315] and/or DHCPv6 Security
[I-D.ietf-dhc-sedhcpv6] 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.
Templin Expires July 26, 2015 [Page 3]
Internet-Draft Client CLLAO January 2015
5. Acknowledgements
6. References
6.1. Normative References
[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.
6.2. Informative References
[I-D.ietf-dhc-sedhcpv6]
Jiang, S., Shen, S., Zhang, D., and T. Jinmei, "Secure
DHCPv6", draft-ietf-dhc-sedhcpv6-05 (work in progress),
December 2014.
[I-D.templin-aerolink]
Templin, F., "Transmission of IP Packets over AERO Links",
draft-templin-aerolink-50 (work in progress), December
2014.
Author's Address
Fred L. Templin (editor)
Boeing Research & Technology
P.O. Box 3707
Seattle, WA 98124
USA
Email: fltemplin@acm.org
Templin Expires July 26, 2015 [Page 4]
