Captive Portal Architecture
RFC 8952

Document Type RFC - Informational (November 2020; No errata)
Authors Kyle Larose  , David Dolson  , Heng Liu 
Last updated 2020-11-30
Replaces draft-larose-capport-architecture
Stream IETF
Formats plain text html xml pdf htmlized bibtex
Stream WG state Submitted to IESG for Publication
Document shepherd Martin Thomson
Shepherd write-up Show (last changed 2020-04-20)
IESG IESG state RFC 8952 (Informational)
Consensus Boilerplate Yes
Telechat date
Responsible AD Barry Leiba
Send notices to Martin Thomson <>
IANA IANA review state Version Changed - Review Needed
IANA action state No IANA Actions

Internet Engineering Task Force (IETF)                         K. Larose
Request for Comments: 8952                                      Agilicus
Category: Informational                                        D. Dolson
ISSN: 2070-1721                                                         
                                                                  H. Liu
                                                           November 2020

                      Captive Portal Architecture


   This document describes a captive portal architecture.  Network
   provisioning protocols such as DHCP or Router Advertisements (RAs),
   an optional signaling protocol, and an HTTP API are used to provide
   the solution.

Status of This Memo

   This document is not an Internet Standards Track specification; it is
   published for informational purposes.

   This document is a product of the Internet Engineering Task Force
   (IETF).  It represents the consensus of the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Not all documents
   approved by the IESG are candidates for any level of Internet
   Standard; see Section 2 of RFC 7841.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at

Copyright Notice

   Copyright (c) 2020 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   ( in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction
     1.1.  Requirements Language
     1.2.  Terminology
   2.  Components
     2.1.  User Equipment
     2.2.  Provisioning Service
       2.2.1.  DHCP or Router Advertisements
       2.2.2.  Provisioning Domains
     2.3.  Captive Portal API Server
     2.4.  Captive Portal Enforcement Device
     2.5.  Captive Portal Signal
     2.6.  Component Diagram
   3.  User Equipment Identity
     3.1.  Identifiers
     3.2.  Recommended Properties
       3.2.1.  Uniquely Identify User Equipment
       3.2.2.  Hard to Spoof
       3.2.3.  Visible to the API Server
       3.2.4.  Visible to the Enforcement Device
     3.3.  Evaluating Types of Identifiers
     3.4.  Example Identifier Types
       3.4.1.  Physical Interface
       3.4.2.  IP Address
       3.4.3.  Media Access Control (MAC) Address
     3.5.  Context-Free URI
   4.  Solution Workflow
     4.1.  Initial Connection
     4.2.  Conditions about to Expire
     4.3.  Handling of Changes in Portal URI
   5.  IANA Considerations
   6.  Security Considerations
     6.1.  Trusting the Network
     6.2.  Authenticated APIs
     6.3.  Secure APIs
     6.4.  Risks Associated with the Signaling Protocol
     6.5.  User Options
     6.6.  Privacy
   7.  References
     7.1.  Normative References
     7.2.  Informative References
   Appendix A.  Existing Captive Portal Detection Implementations
   Authors' Addresses

1.  Introduction

   In this document, "Captive Portal" is used to describe a network to
   which a device may be voluntarily attached, such that network access
   is limited until some requirements have been fulfilled.  Typically, a
   user is required to use a web browser to fulfill requirements imposed
   by the network operator, such as reading advertisements, accepting an
   acceptable-use policy, or providing some form of credentials.

   Implementations of captive portals generally require a web server,
   some method to allow/block traffic, and some method to alert the
   user.  Common methods of alerting the user in implementations prior
   to this work involve modifying HTTP or DNS traffic.

   This document describes an architecture for implementing captive
   portals while addressing most of the problems arising for current
   captive portal mechanisms.  The architecture is guided by these

   *  Current captive portal solutions typically implement some
      variations of forging DNS or HTTP responses.  Some attempt man-in-
      the-middle (MITM) proxy of HTTPS in order to forge responses.
      Captive portal solutions should not have to break any protocols or
      otherwise act in the manner of an attacker.  Therefore, solutions
      MUST NOT require the forging of responses from DNS or HTTP servers
      or from any other protocol.
Show full document text