Network Working Group M. Nottingham
Internet-Draft April 4, 2016
Intended status: Informational
Expires: October 6, 2016

Captive Portals Problem Statement


This draft attempts to establish a problem statement for “Captive Portals”, in order to inform discussions of improving their operation.

Note to Readers

The issues list for this draft can be found at

The most recent (often, unpublished) draft is at

Recent changes are listed at

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on October 6, 2016.

Copyright Notice

Copyright (c) 2016 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

This draft attempts to establish a problem statement for “Captive Portals”, in order to inform discussions of improving their operation.

1.1. Notational Conventions

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in [RFC2119].

2. Defining Captive Portals and Networks

A “captive network” is a network that employs a captive portal for a variety of purposes; see Section 2.1. A “captive portal” is a Web site that captive networks direct users to.

This is achieved by directing requests for “normal” Web access to the captive portal, through variety of techniques, including DNS poisoning, TCP interception, HTTP response modification and/or HTTP redirection.

Once the captive network’s goals are met, the network “remembers” that the user is allowed network access, usually by MAC address, although there is a significant amount of variance between implementations.

Over time, operating systems have developed “captive portal detection” processes to discover captive networks, and to assist users through the process of obtaining full network access. They often involve specialised “captive portal browsers” which only allow the captive portal to use a subset of the full capabilities of a Web browser, and have a different user experience.

2.1. Why Captive Portals Are Used

Captive portals are deployed in a variety of situations, but the most common motivations are:

In all of these cases, using a Web browser is attractive, because it gives the network the ability to tailor the user’s interface and experience, as well as the ability to integrate third-party payment, advertising, authentication and other services.

3. Issues Caused by Captive Portals

When a network imposes a captive portal, it can cause a variety of issues, both for applications and end users.

4. Issues Caused by Captive Portal Detection

Many operating systems attempt to detect when they are on a captive network. Detection aims to minimize the negative effects caused by interposition of captive portals, but can cause different issues, including:

4.1. Issues Caused by Defeating Captive Portal Detection

Many captive portal devices provide optional mechanisms that aim to defeat captive portal detection.

Such defeat mechanisms aim to avoid the problems caused by captive portal detection (see Section 4), with the consequence that they also cause the same problems that detection was intended to avoid (see Section 3).

5. Security Considerations


6. Normative References

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997.
[RFC6108] Chung, C., Kasyanov, A., Livingood, J., Mody, N. and B. Van Lieu, "Comcast's Web Notification System Design", RFC 6108, DOI 10.17487/RFC6108, February 2011.

Appendix A. Acknowledgements

This draft was seeded from the HTTP Working Group Wiki Page on Captive Portals; thanks to all who contributed there.

Thanks to Martin Thomson, Yaron Sheffer, David Bird and Jason Livingood for their suggestions.

Author's Address

Mark Nottingham EMail: URI: