Link-Layer Address Assignment Mechanism for DHCPv6
draft-ietf-dhc-mac-assign-09

Approval announcement
Draft of message to be sent after approval:

Announcement

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: Ian Farrer <ianfarrer@gmx.com>, Tomek Mrugalski <tomasz.mrugalski@gmail.com>, dhcwg@ietf.org, draft-ietf-dhc-mac-assign@ietf.org, dhc-chairs@ietf.org, rfc-editor@rfc-editor.org, evyncke@cisco.com, The IESG <iesg@ietf.org>, ianfarrer@gmx.com
Subject: Protocol Action: 'Link-Layer Addresses Assignment Mechanism for DHCPv6' to Proposed Standard (draft-ietf-dhc-mac-assign-09.txt)

The IESG has approved the following document:
- 'Link-Layer Addresses Assignment Mechanism for DHCPv6'
  (draft-ietf-dhc-mac-assign-09.txt) as Proposed Standard

This document is the product of the Dynamic Host Configuration Working Group.

The IESG contact persons are Erik Kline and Éric Vyncke.

A URL of this Internet Draft is:
https://datatracker.ietf.org/doc/draft-ietf-dhc-mac-assign/

Ballot Text

Technical Summary

This document extends the DHCPv6 protocol to include the leasing of link-layer addresses. It defines both a direct client mode, whereby a client requests a LL addresses, or block of addresses, intended for configuration on its own interface(s). Proxy client mode allows a block of addresses to be requested by a client (e.g. a hypervisor), which will then be used for configuring end-devices. One application for this function are large scale VM deployments, where the likelihood of a MAC address collision is not acceptable (due to the birthday paradox). Two new DHCPv6 options are defined for this purpose.

Working Group Summary

This document has been progressed through the DHC workgroup. There is consensus in the WG for the publication of this document. No points or controversy have been raised during the authoring or review process.

Document Quality

There are no existing implementations of the specification. One of the authors (C. Bernandos) stated that he is involved in an EU project which may implement. 

IETF Last Call had only one feedback from IoT directorate.

Personnel

Ian Farrer is the Document Shepherd.
Éric Vyncke is the Area Director

IANA Note

The IANA considerations section requests the assignment of new DHCPv6 option codes for the two new DHCPv6 options that are defined in the document's body text. The data that is provided contains the necessary parameters for the option code assignment, including the "Client ORO" and "singleton option" values as described in section 24. of RFC8415.

No registries requiring Expert Review are defined.

RFC Editor Note

RFC Editor Note

For RFC editor, please make a cluster of ietf-dhc-slap-quadrant and this document and try to get two consecutive RFC numbers, this draft-ietf-dhc-mac-assign should have the lower RFC number;

Thank you

-éric