Client Link-Layer Address Option in DHCPv6
draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-05

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: RFC Editor <rfc-editor@rfc-editor.org>,
    dhc mailing list <dhcwg@ietf.org>,
    dhc chair <dhc-chairs@tools.ietf.org>
Subject: Protocol Action: 'Client Link-layer Address Option in DHCPv6' to Proposed Standard (draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-05.txt)

The IESG has approved the following document:
- 'Client Link-layer Address Option in DHCPv6'
  (draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-05.txt) as Proposed
Standard

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

The IESG contact persons are Ralph Droms and Brian Haberman.

A URL of this Internet Draft is:
http://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt/

Ballot Text

Technical Summary: 

   This document specifies the format and mechanism that is to be used
   for encoding client link-layer address in DHCPv6 Relay-Forward
   messages by defining a new DHCPv6 Client Link-layer Address option.

Working Group Summary: 

   This document was proposed in the working group about a year ago as
   an extension for DHCPv6 clients.  There was concern that it would
   turn into something that would replace DUID and create
   interoperability problems, so the working group developed a rough
   consensus that we should implement this as a relay option instead,
   since this would prevent it being misused to replace DUID.

   Those who disagreed with the consensus, because they would have
   preferred a DHCP client option, went along with this because this
   solution satisfied their actual use case.  They were encouraged to
   try pursuing the client option in the future if they felt it was
   still needed.  This was seen as an acceptable compromise by all the
   dissenters.

Document Quality: 

   I'm not aware of any existing implementations.  This is something
   that a number of enterprise folks have requested, and we expect to
   see implementation in relay agents targeted to those markets.  I
   think everyone who's reviewed the document is mentioned in the
   acknowledgements section.


Personnel: 

   Ted Lemon is the document shepherd.  Ralph Droms is the responsible
   AD.

RFC Editor Note