Editing Captive portal (section)

==Implementation==

There are various ways to implement a captive portal.

=== HTTP redirect ===
A common method is to direct all [[World Wide Web]] traffic to a web server, which returns an [[HTTP 302|HTTP redirect]] to a captive portal.<ref>{{Cite web
| url=https://andrewwippler.com/2017/04/07/captive-portal-overview/
| title=Captive Portal Overview
| last=Wippler
| first=Andrew J.
| date=April 7, 2017
| website=Andrew Wippler's Sketchpad
| access-date=2019-03-06
| archive-date=2019-05-04
| archive-url=https://web.archive.org/web/20190504093331/https://andrewwippler.com/2017/04/07/captive-portal-overview/
| url-status=live
}}</ref> When a modern, Internet-enabled device first connects to a network, it sends out an HTTP request to a detection URL predefined by its vendor and expects an [[List_of_HTTP_status_codes#2xx success|HTTP status code]] 200 OK or 204 No Content. If the device receives a HTTP 2xx status code, it assumes it has unlimited internet access. Captive portal prompts are displayed when you are able to manipulate this first HTTP message to return a HTTP status code of 302 (redirect) to the captive portal of your choice.<ref>{{Cite web
| url=https://andrewwippler.com/2016/03/11/wifi-captive-portal/
| title=WiFi Captive Portal
| last=Wippler
| first=Andrew J.
| date=March 11, 2016
| website=Andrew Wippler's Sketchpad
| access-date=2019-03-06
| archive-date=2019-05-04
| archive-url=https://web.archive.org/web/20190504093332/https://andrewwippler.com/2016/03/11/wifi-captive-portal/
| url-status=live
}}</ref><ref>{{Cite web
| url=https://www.chromium.org/chromium-os/chromiumos-design-docs/network-portal-detection
| title=Network Portal Detection
| publisher=[[Chromium_(web_browser)|Chromium]]
| access-date=2019-03-06
| archive-date=2019-03-03
| archive-url=https://web.archive.org/web/20190303050020/http://www.chromium.org/chromium-os/chromiumos-design-docs/network-portal-detection
| url-status=live
}}</ref> {{IETF RFC|6585}} specifies the 511 Network Authentication Required status code.

===ICMP redirect===

Client traffic can also be redirected using [[ICMP Redirect Message|ICMP redirect]] on the layer 3 level.

===Redirect by DNS===

When a client requests a resource on a remote host by name, [[Domain name system|DNS]] is queried to resolve that hostname. In a captive portal, the [[Firewall (computing)|firewall]] will make sure that only the DNS server(s) provided by the network's DHCP can be used by unauthenticated clients (or, alternatively, it will forward all DNS requests by unauthenticated clients to that DNS server). This DNS server will return the IP address of the captive portal page as a result of all DNS lookups.

In order to perform redirection by DNS the captive portal uses [[DNS hijacking]] to perform an action similar to a [[man-in-the-middle attack]]. To limit the impact of DNS poisoning, a [[Time to live|TTL]] of 0 is typically used.

===Captive Portal API===
{{IETF RFC|8910}} introduces a standardized method for networks to inform clients about the presence of {{IETF RFC|8908}} Captive Portal API endpoints using [[Dynamic Host Configuration Protocol|DHCP]] (both IPv4 and [[DHCPv6]]) options and IPv6 [[Neighbor Discovery Protocol|NDP router advertisements]]. RFC 8910 was implemented in [[systemd]]-networkd v254 in July 2023.<ref>{{Cite web |url=https://github.com/systemd/systemd/releases/tag/v254 |title=systemd v254 |author=<!--Not stated--> |date=28 July 2023 |website=GitHub |access-date=2024-11-03}}</ref><ref>{{Cite web |url=https://github.com/systemd/systemd/pull/28132 |title=Implement RFC8910: captive portal dhcp options |author=Ronan Pigott |date=22 June 2023 |website=GitHub |access-date=2024-11-03}}</ref> [[NetworkManager]] discussions have also explored using them for captive portal interactions.<ref>{{Cite web |url=https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/1305 |title=[RFE] Support of captive portal API |author=Petr Menšík |date=30 May 2023 |website=Freedesktop GitLab |access-date=2024-11-03}}</ref>