Client Link-Layer Address Option in DHCPv6
Draft of message to be sent after approval:
From: The IESG <email@example.com> To: IETF-Announce <firstname.lastname@example.org> Cc: RFC Editor <email@example.com>, dhc mailing list <firstname.lastname@example.org>, dhc chair <email@example.com> 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/
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.