Captive-Portal Identification Using DHCP or Router Advertisements (RAs)
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> Subject: Protocol Action: 'Captive-Portal Identification in DHCP / RA' to Proposed Standard (draft-wkumari-dhc-capport-16.txt) The IESG has approved the following document: - 'Captive-Portal Identification in DHCP / RA' (draft-wkumari-dhc-capport-16.txt) as Proposed Standard This document has been reviewed in the IETF but is not the product of an IETF Working Group. The IESG contact person is Joel Jaeggli. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-wkumari-dhc-capport/
Technical Summary This document describes a DHCP option and an RA extension to inform nodes that they are behind some sort of captive portal device, and that they will need to authenticate to get Internet Access. Working Group Summary This document was reviewed by the DHC working group, but was not adopted there because the work is not in charter. Because it defines new DHCP options, it's not really in charter for 6man either. Taken forward as an AD sponsored it has had abundant review. been the inspiration for a BOF and generally received positive attention. Document Quality Dan Lüdtke has done an implementation of the router side of the RA option. We are aware of no RA listener implementations nor DHCP client implementations. Because this document defines DHCP options, any generally-configurable DHCP server or client can readily be configured to support this new option, typically without recompilation. The option question for this document is whether captive portal manufacturers and, more importantly, DHCP client implementors and RA listener implementors will see the extension as valuable and make use of it. The reason for advancing it at this stage rather than waiting for widespread adoption is that until a standard format is defined, the extension serves no useful purpose and cannot be deployed. By documenting this extension, we hope to provide an opportunity for improvement in the way captive portals are operated. Personnel Ted Lemon is the document shepherd. Joel Jaeggli is the responsible AD.