This is the thrid article in the series The protocol gap. In the first two articles we’ve shown the difficulties that guest devices have to communicate with captive portals and the proposed solution for this problem by defining a new interface in RFC capport-architecture. To be precise, the IETF does not define a new protocol with this RFC, it defines a new interface over known protocols like DHCP, IPv6 RA and HTTPS.
In the previous article in this series we’ve already shown the flow and API, but some things have changed since then (Jan 2019):
Here's the current flow when a device enters the network:
1. The enduser device gets provisioned with initial network settings like IP, subnet mask, gateway, DNS server, … via DHCP. There is also a variation using PvD (Provisioning Domains) discussed. The device learns a URL of the CAPPORT API server via a new DHCP option (DHCP6 and RA for IPv6) defined in RFC-8910 (a new version of RFC-7710-bis).
2. The device asks the CAPPORT API server about the current restrictions and learns an URL for a webpage suited for humans. This page can consist of a login form, needed payment, or any other information.
3. The device opens a (captive) browser and presents the login page to the user.
4. Finally if the requirements of the captive portal are satisfied by the enduser, the device is set online and allowed to access the internet.
5. The device can send traffic now. But if the device is not allowed to access the internet the captive portal can optionally send a “signal”. The current state of this capport interface does not specify what this signal is. So this is not implemented on any side right now.
The capport API defined in RFC-8908 allows the client to interact with a captive portal over a typical HTTP API with JSON as data format. It’s mandatory to use HTTPS (HTTP over TLS – at least version 1.2). While the client device already knows that it’s behind a captive portal it now wants to get the current state and some details about the captivity. One important thing the API has to deliver is an URL for a webpage that is presented to the user with a login page or any other information.
An example request and response could look like this:
GET / capport_api HTTP/1.1
The server then responds with the JSON content for that client:
HTTP/1.1 200 OK
Date: Mon, 06 Jul 2020 10:07:35 GMT
Additional JSON entries can be registered at IANA. Of course this only makes sense if Google and Apple are registering them and (hopefully) using them in the same way.
After waiting for a long time we’ve been surprised to see announcments of Apple and Google in 2020 to support the new capport architecture in their newest releases.
So, we're done? Not yet - there are multiple things upen that will probably need years to be resolved. The old HTTP based connection checks will remain present as not all captive portals will support this API so we will see a parallel use for years.
Also the first implementations do not include the informational parts of the API like the venue URL or the seconds- and bytes-remaining entries which would be the real benefit.
The capport RFC is currently in the final stage and should be released soon and finally get an official number.
We will update the IACBOX to support newly added API fields as soon as they are released - so stay u2date.
Are you interested in wireless Internet access for guests, staff or things for your enterprise, or do you provide network solutions for clients? Drop a few lines to share your opinion with us: email@example.com
At Asteas, we see it as our task to shape wireless Internet access in networks efficient and legally conformant for the supplier, efficient and comfortable for the user and secure for both.
For more information, visit our website www.asteas.com or contact us here.