![](https://csdnimg.cn/release/download_crawler_static/88891926/bg4.jpg)
in the manner of an attacker. Therefore, solutions require the forging of
responses from DNS or HTTP servers or from any other protocol.
Solutions permit clients to perform DNSSEC validation, which rules out solutions that
forge DNS responses. Solutions permit clients to detect and avoid TLS man-in-the-
middle attacks without requiring a human to perform any kind of "exception" processing.
To maximize universality and adoption, solutions operate at the layer of Internet
Protocol (IP) or above, not being specific to any particular access technology such as cable,
Wi-Fi, or mobile telecom.
Solutions allow a device to query the network to determine whether the device is
captive, without the solution being coupled to forging intercepted protocols or requiring the
device to make sacrificial queries to "canary" URIs to check for response tampering (see
Appendix A). Current captive portal solutions that work by affecting DNS or HTTP generally
only function as intended with browsers, breaking other applications using those protocols;
applications using other protocols are not alerted that the network is a captive portal.
The state of captivity be explicitly available to devices via a standard protocol,
rather than having to infer the state indirectly.
The architecture provide a path of incremental migration, acknowledging the
existence of a huge variety of pre-existing portals and end-user device implementations and
software versions. This requirement is not to recommend or standardize existing
approaches, but rather to provide device and portal implementors a path to a new standard.
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
with user interfaces.
The architecture uses the following mechanisms:
Network provisioning protocols provide end-user devices with a Uniform Resource Identifier
(URI) for the API that end-user devices query for information about what is
required to escape captivity. DHCP, DHCPv6, and Router Advertisement options for this
purpose are available in . Other protocols (such as RADIUS), Provisioning Domains
, or static configuration may also be used to convey this Captive Portal API
URI. A device query this API at any time to determine whether the network is holding
the device in a captive state.
A Captive Portal can signal User Equipment in response to transmissions by the User
Equipment. This signal works in response to any Internet protocol and is not done by
modifying protocols in band. This signal does not carry the Captive Portal API URI; rather, it
provides a signal to the User Equipment that it is in a captive state.
Receipt of a Captive Portal Signal provides a hint that User Equipment could be captive. In
response, the device query the provisioned API to obtain information about the
network state. The device can take immediate action to satisfy the portal (according to its
configuration/policy).
MUST NOT
• MUST
SHOULD
• MUST
• SHOULD
• SHOULD
• MUST
•
[RFC3986]
[RFC8910]
[CAPPORT-PVD]
MAY
•
•
MAY
RFC 8952 Captive Portal Architecture November 2020
Larose, et al. Informational Page 4