Captive-Portal Identification in DHCP and Router Advertisements (RAs), September 2020
- File formats:
- Also available: XML file for editing
- PROPOSED STANDARD
- RFC 7710
- RFC 3679
- W. Kumari
- capport (art)
Cite this RFC: TXT | XML | BibTeX
Discuss this RFC: Send questions or comments to the mailing list firstname.lastname@example.org
Other actions: View Errata | Submit Errata | Find IPR Disclosures from the IETF | View History of RFC 8910
In many environments offering short-term or temporary Internet access (such as coffee shops), it is common to start new connections in a captive portal mode. This highly restricts what the user can do until the user has satisfied the captive portal conditions.
This document describes a DHCPv4 and DHCPv6 option and a Router Advertisement (RA) option to inform clients that they are behind some sort of captive portal enforcement device, and that they will need to satisfy the Captive Portal conditions to get Internet access. It is not a full solution to address all of the issues that clients may have with captive portals; it is designed to be one component of a standardized approach for hosts to interact with such portals. While this document defines how the network operator may convey the captive portal API endpoint to hosts, the specific methods of satisfying and interacting with the captive portal are out of scope of this document.
This document replaces RFC 7710, which used DHCP code point 160. Due to a conflict, this document specifies 114. Consequently, this document also updates RFC 3679.
For the definition of Status, see RFC 2026.
For the definition of Stream, see RFC 8729.