RADIUS Option for the DHCPv6 Relay Agent
Draft of message to be sent after approval:
From: The IESG <firstname.lastname@example.org> To: IETF-Announce <email@example.com> Cc: RFC Editor <firstname.lastname@example.org>, dhc mailing list <email@example.com>, dhc chair <firstname.lastname@example.org> Subject: Protocol Action: 'RADIUS Option for DHCPv6 Relay Agent' to Proposed Standard (draft-ietf-dhc-dhcpv6-radius-opt-14.txt) The IESG has approved the following document: - 'RADIUS Option for DHCPv6 Relay Agent' (draft-ietf-dhc-dhcpv6-radius-opt-14.txt) as Proposed Standard This document is the product of the Dynamic Host Configuration Working Group. The IESG contact persons are Ted Lemon and Brian Haberman. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-radius-opt/
Technical Summary: This document defines RADIUS DHCPv6 option that is similar to its DHCPv4 counter-part that was defined in RFC4014. The DHCPv6 RADIUS option provides a mechanism to exchange authorization and identification information between the DHCPv6 relay agent and the DHCPv6 server. This mechanism is meant for the centralized DHCPv6 server to select the right configuration for the requesting DHCPv6 client based on the authorization information received from the RADIUS server, which is not co-located with the DHCPv6 server. The Network Access Server (NAS) acts as DHCPv6 relay agent and RADIUS client simultaneously in this document. Working Group Summary: This document was called draft-yeh-dhc-dhcpv6-authorization-opt prior to its adoption. There was unanimous support for it (9 people in favor of adoption and none against), so this document was adopted in May 2012. There was quite high interest in this work - 55 posts since its adoption. There was never any opposition for this work. Document Quality: I'm not aware of any existing implementations, but the level of support from both DHCP vendors (Nominum, Weird Solutions, Cisco, ISC), hardware vendors (Huawei, Cisco) and operators (Orange, Telecom Italia) suggests that this will be implemented and deployed shortly after option code is assigned by IANA. There was no single lead reviewer and many people contributed to the draft (55 posts about it to DHC list, 41 posts to RADEXT during its WG life). This document went through rapid updates (10 revisions 10 months), because its lead author - Leaf Yeh - was eager to address any comments as soon as they appeared. Personnel: Who is the Document Shepherd? Who is the Responsible Area Director? Tomek Mrugalski is the document shepherd. Ted Lemon is the responsible AD.