Everyone has met a captive portal: the hotel Wi-Fi sign-in page, the airport "accept terms" form, the coffee shop voucher screen. For about two decades, captive portals operated entirely outside the standards stack — a tower of hacks that violated nearly every layer of the Internet model. RFC 8952 is the IETF's belated attempt to describe what a proper captive portal should look like, and it sits at the center of a small family of RFCs (8908 for the API, 8910 for the DHCP/RA signaling) that together replace the hacks with a real protocol.

The problem space. Historically, networks trapped unauthenticated clients by:

• Intercepting DNS lookups and returning the portal's IP for every name.
• Transparently proxying TCP/80 and injecting an HTTP 302.
• Returning forged HTTP responses to operating-system probe URLs (captive.apple.com, www.msftncsi.com, connectivitycheck.gstatic.com).
• Silently dropping everything else and hoping the user opens a browser.

This worked in 2005. It fails badly in a world of HTTPS-by-default, HSTS, DoH/DoT, QUIC, and background sync. A modern phone wakes up on hotel Wi-Fi, tries a TLS connection to a pinned server, gets a redirect to a self-signed portal, refuses the cert, and the user sees a permanent "no internet" indicator. Meanwhile push notifications, mail fetch, and OS updates all silently fail.

What RFC 8952 actually says. It is an architecture document, not a wire protocol. It identifies three actors — the User Equipment (UE), the Provisioning Service (DHCP/RA), and the Captive Portal API Server — and four behaviors the system must support:

• Signaling: the network tells the client "you are captive" via a standard, trustworthy channel (DHCP option 114, IPv6 RA option, or PvD), not by lying about DNS or HTTP.
• State query: the client asks a JSON API "am I captive, and if so where do I authenticate?" — defined in RFC 8908.
• Enforcement: the gateway still blocks non-authenticated traffic, but it does so honestly (ICMP unreachable, TCP RST, or simply drop) instead of impersonating the destination.
• Notification: the API can return remaining bytes, seconds, or a "session about to expire" hint so the OS can prompt the user proactively.

Key design decisions worth noting. The working group consciously rejected putting portal information inside DNS, because DNSSEC and resolver caching make per-client answers unsafe. They also rejected piggybacking on HTTP because TLS makes HTTP interception strictly worse than useless. The DHCP/RA option carries only a URL (an HTTPS URL, with a real certificate, served by the venue or its hosting provider) — everything else flows over normal TLS.

Why it matters today. iOS 14, macOS Big Sur, Android 11, and Windows 11 all implement RFC 8908/8910. If you maintain a guest network at a hotel, conference, or office, the modern recipe is: hand out DHCP option 114 pointing at an HTTPS endpoint that returns the application/captive+json media type, let the OS surface its own native sign-in sheet, and stop intercepting traffic. The user gets a clean modal instead of broken HTTPS errors; your guests' Apple Watches keep syncing; you stop being blamed for "the Wi-Fi is broken."

The quietly subversive aspect of RFC 8952 is that it formalizes something the IETF spent years refusing to formalize, on the grounds that captive portals are a violation of the end-to-end principle. They are — but pretending they did not exist made the Internet worse, not better. RFC 8952 is what acceptance looks like.