RFC - Captive Portal

RFC 8952

Captive Portal Architecture

Abstract

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.

Stream: Internet Engineering Task Force (IETF)

RFC: 8952

Category: 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 .https://www.rfc-editor.org/info/rfc8952

Copyright Notice

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

reserved.

https://trustee.ietf.org/license-info

Larose, et al. Informational Page 1

Larose, et al. Informational Page 2

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.

Authors' Addresses

Larose, et al. Informational Page 3

A side benefit of the architecture described in this document is that devices without user

interfaces are able to identify parameters of captivity. However, this document does not describe

a mechanism for such devices to negotiate for unrestricted network access. A future document

could provide a solution to devices without user interfaces. This document focuses on devices

, or static configuration may also be used to convey this Captive Portal API

Larose, et al. Informational Page 4

The architecture attempts to provide confidentiality, authentication, and safety mechanisms to

the extent possible.

The key words " ", " ", " ", " ", " ", " ", "

Larose, et al. Informational Page 5