Skip to content

Captive portal option - RFC 8910

Problem Typically used when public wifi access is provided, a captive portal provides 'captures' the client html traffic and redirects it to a web page that provides information, advertising, a log-in or registration feature, or a click-to-accept statement of responsibility. Earlier implementations of captive portals involved MITM-type interception of traffic. Current recommended practice is to explicitly provision the captive portal api address to the client via explicit network provisioning (DHCP).

New (2020) IETF work has updated the specifications for captive portal signaling, changing the DHCP code point recommended for specifying the URL of the captive portal.

  • option 114 for DHCPv4, option 103 for DHCPv6. Note that the DHCPv4 option is new, it used to be 160.

  • Kea should send this option, if configured, whether it is requested or not. This is a new RFC, and it is likely a lot of clients won't be requesting it immediately. "Clients that support the Captive Portal DHCP option SHOULD include the option in the Parameter Request List in DHCPREQUEST messages. DHCP servers MAY send the Captive Portal option without any explicit request."

  • Kea should ensure that the option value is a valid URI. It should not be an IP address (this should be mentioned in the documentation). Should we enforce the shorter URI limit for DHCPv6 so the same URI will work for both? "As the maximum length of the URI that can be carried in IPv4 DHCP is 255 bytes, URIs longer than this SHOULD NOT be provisioned by any of the IPv6 options described in this document. In IPv6-only environments, this restriction can be relaxed."

  • Include in the documentation the instruction to specify if no captive portal is present with the URI below. ? Perhaps we should make this URI the default, if nothing is configured? text from the rfc "Networks with no captive portals may explicitly indicate this condition by using this option with the IANA-assigned URI for this purpose. Clients observing the URI value "urn:ietf:params:capport:unrestricted" may forego time-consuming forms of captive portal detection."

  • There is a related issue wrt Bootp options for captive portal, because that code point has also changed. I dk if we should make changes to bootp at this time, because being a legacy service, it is unlikely clients will be updated to understand the new code point. But we should consider it.

Edited by Tomek Mrugalski
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information