Client Link-Layer Address Option (CLLAO) Updates
draft-templin-dhc-cllao-updates-00.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 as informational material for the DHCPv6 server. The server in turn is not required to echo the CLLAO back in its replies. In some cases, however, the DHCPv6 client may be interested to receive the CLLAO, e.g., to determine if there are L2 devices (e.g., L2 proxies) that rewrite the link-layer address. This document discusses updates to RFC6939 to allow the server to echo the CLLAO back to the client.

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 September 4, 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 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

• 1. Introduction
• 2. CLLAOs in Relay-Supplied DHCP Options
• 3. IANA Considerations
• 4. Security Considerations
• 5. Acknowledgements
• 6. References
• 6.1. Normative References
• 6.2. Informative References
• Author's Address

1. Introduction

[RFC6939] specifies a method for DHCPv6 relays[RFC3315] to insert a Client Link-Layer Address Option (CLLAO) in a Relay-Forward message. This provides a means for a first-hop relay to inform the server of the client's link-layer address on the client<->relay link. However, on some links it may be necessary for the client to determine whether there is an L2 device on the path to the relay that rewrites the link-layer address.

Asymmetric Extended Route Optimization (AERO) [I-D.templin-aerolink] is an example of a "DHCPv6-over-(foo)" link layer where the client's link-layer address may be altered by an L2 device on the path. In that case, if the relay inserts a CLLAO and requests the server to include the CLLAO in its replies to the client, the client will receive the information it needs. This can be accomplished through the application of Relay-Supplied DHCP Options per [RFC6422] as described in the following section.

2. CLLAOs in Relay-Supplied DHCP Options

When a DHCPv6 relay forwards a DHCPv6 client's messages, it may determine that the client requires its own link-layer address to be echoed back in the server's reply. This determination could be through, e.g., administrative configuration, an unspecified indication from the client, etc.

When a relay determines that the client requires its link-layer address to be echoed back in the server's reply, the relay includes a CLLAO in a Relay-Supplied Options option (RSOO) in the Relay-Forward message as described in [RFC6422].

When the server receives the Relay-Forward message with the RSOO, it includes the encapsulated CLLAO in the list of options to return to the client.

When the client receives the server's reply including the CLLAO, it can optionally ignore the option as specified in [RFC6939], or parse the option to determine if the link-layer address was altered by an L2 switching element on the path to the relay. This latter behavior therefore updates [RFC6939].

3. IANA Considerations

Per Section 8 of [RFC6422], IANA is instructed to add CLLAO as a permitted option in the "Options Permitted in the Relay-Supplied Options Option" registry.

4. Security Considerations

DHCPv6 authentication [RFC3315] and/or DHCPv6 Security [I-D.ietf-dhc-sedhcpv6] SHOULD be used on unmanaged/unsecured links where the link-layer switching elements themselves present a man-in-the-middle attack threat.

5. Acknowledgements

The proposal was widely discussed on the DHC mailing list, where valuable insights were gained. Those mailing list participants are acknowledged for their insights.

Tomek Mrugalski and Bernie Volz provided helpful administrative guidance.

6. References

6.1. Normative References

6.2. Informative References

Author's Address