I like to monitor the IETF mailing lists for new Internet RFCs that are published. Many of these are cryptic things like RFC 7675, Session Traversal Utilities for NAT (STUN) Usage for Consent Freshness. I'm not sure I even know what that means. There are some that do make sense to me. Most recently RFC 7710, Captive-Portal Identification Using DHCP or Router Advertisements (RAs) was published and caught my attention.
Captive portals, if you aren't familiar with the term, are those systems that intercept a user's web traffic and redirects them to another page on the guest network. These may only require the user to agree to an acceptable use policy or they may require a login. In some venues the user may even have to pay for service. I'm not a big fan of these, as they are a perpetual nuisance to end users. Having an unexpected page open up in lieu of the page that was asked for isn't convenient. It is also problematic for many Wi-Fi devices, especially streaming devices. You might think, for example, that you could take a Chromecast or Apple TV with you to a hotel, plug it into the TV, and watch what you want. However, very few of these devices have any way to handle the captive portal, leaving the user connected to the Wi-Fi network without the ability to actually use it.
Currently, most operating systems use a hack to check for a captive portal. When a users connect to a network, the OS will attempt to access one or more specific URLs to see if they see the expected response. If it does not, the assumption is there is a captive portal and it will notify the user in some way and allow them to login for full Internet access.
For example, in recent releases of OS X, the test URLs is http://captive.apple.com/hotspotdetect.html. This page will return a simple response of "Success". If the OS does not receive that response, it will open the Captive Network Assistant and display whatever captive portal page to which the is redirecting requests. You can use this to authenticate to the portal, accept the required agreement, or do whatever else is required.
In an effort to be helpful, captive portals will sometimes send the user on to the URL they originally requested. If this is the URL that OS X uses to detect the captive portal, the user is now sent to a plain white page that says "Success". This is not exactly user friendly or particularly elegant. However, there are limited options for dealing with this, especially given that the test URLs seem to change with every OS release. This is where our new RFC comes in to play.
From RFC7710:
The format of the IPv4 Captive-Portal DHCP option is shown below. Code Len Data +------+------+------+------+------+-- --+-----+ | Code | Len | URI ... | +------+------+------+------+------+-- --+-----+ o Code: The Captive-Portal DHCPv4 option (160) (one octet). o Len: The length, in octets of the URI. o URI: The contact URI for the captive portal that the user should connect to (encoded following the rules in [RFC3986]).
To be clear from the start, RFC 7710 does not solve the problem, but it does provide a useful foundation that a solution can be built upon. RFC 7710 defines the new DHCP option (160) which will contain the URL of the captive portal. It also defines IPv6 DHCP option 103 and IPv6 Router Advertisement option type 37, both of which would also contain the URL of the captive portal. If the DHCP client or IPv6 stack in a client supports this option, it can more intelligently deal with the captive portal instead of guessing at it. The rest of the procedure would be about the same as it is today, just a little cleaner.
In theory, combining this with a standardized captive portal interface or API could result in devices like the Chromecast and AppleTV being able to display the AUP and give the user the option to accept it. This would be much more user friendly and reliable. It should also allow the user to access the network more quickly, especially if a device allowed the user to save their acceptance of the AUP or the login information. This could be a potential middle ground between where we are and where Hotspot 2.0 is taking things, since it would be much easier to implement on the infrastructure side. Of course, until clients start supporting it, it's all theory and dreaming.
RFC7710 provides a better way for client devices to detect the presence of a captive portal. It has the potential to open new options that will improve the user experience, but more pieces need to fall in place. The option must be added to the infrastructure and client software needs to be updated to use it. However, to really make things interesting and greatly enhance the user experience, there needs to be a standardized API for captive portals. That's going to be the hard part.
