Captive-Portal Identification Using DHCP or Router Advertisements (RAs)
obsoleted by
- rfc-8910 — Captive-Portal Identification in DHCP and Router Advertisements (RAs)
Extracted elements (19)
The document explicitly defers the method of authenticating and interacting with the captive portal to other work, positioning this DHCP/RA option as a narrowly scoped discovery mechanism intended to be embedded in larger captive-portal solutions.
Three distinct delivery mechanisms (IPv4 DHCP, IPv6 DHCP, IPv6 RA) are specified to support different classes of clients — IPv4-only, IPv6-only with DHCPv6, and IPv6-only with RA — ensuring captive-portal notification reaches all device types without requiring protocol-specific fallbacks.
Using a URI with an IP address literal rather than a DNS name avoids the need for DNS interception by the captive-portal device, which is a common but operationally fragile technique that can conflict with DNSSEC validation.
For the foreseeable future, captive portals will still need to implement legacy interception techniques to serve clients that do not support the Captive-Portal DHCP/RA option; this option is intended to improve the experience for capable clients, not to replace interception entirely.
The IPv4 DHCP maximum option length of 255 bytes imposes a practical URI length ceiling; URIs exceeding 255 bytes should not be used even in IPv6 DHCP or RA contexts to preserve cross-transport parity when a single portal serves both address families.
Because the maximum URI length in IPv4 DHCP is 255 bytes, URIs longer than 255 bytes should not be used in IPv6 DHCP or IPv6 RA options to maintain cross-method consistency.
The IPv6 RA Captive-Portal URI SHOULD be padded with NULL (0x0) bytes so that the total option length (including the Type and Length fields) is a multiple of 8 bytes.
The URI parameter in the Captive-Portal DHCP option is not null-terminated; the length field alone delimits the URI value.
To avoid having to perform DNS interception, the URI carried in the Captive-Portal option SHOULD contain an IP address literal. A DNS name is acceptable only if the captive portal allows the client to perform DNS requests to resolve the name.
When delivering the captive-portal URI via multiple methods (IPv4 DHCP, IPv6 DHCP, IPv6 RA), the captive-portal operator should ensure that the URIs handed out are equivalent to reduce the chance of operational problems.
IPv6 RA Option Type code 37 was assigned from the IANA 'IPv6 Neighbor Discovery Option Formats' registry under ICMPv6 parameters for the Captive-Portal RA option.
Option code 103 was assigned from the IANA 'Option Codes' registry under DHCPv6 parameters for the IPv6 Captive-Portal DHCPv6 option.
Option code 160 was assigned from the IANA 'BOOTP Vendor Extensions and DHCP Options' registry for the IPv4 Captive-Portal DHCP option, as specified in RFC 2939.
An attacker able to inject DHCP messages could include the Captive-Portal option and force users to contact an address of the attacker's choosing. Because the attacker could also hijack the default gateway, this does not significantly expand attack capabilities, but clients aware they are connecting to a captive-portal device can sandbox the page and label it as untrusted.
Devices that automatically connect to open networks could be tracked via forced authentication or browser fingerprinting using this mechanism; however, standard captive-portal interception already enables similar tracking, so this option does not materially increase attacker capabilities.
Providing the portal's URI via DHCP or RA is a cleaner alternative to TLS hijacking and reduces user expectation of being hijacked; this may improve security by making users less willing to accept TLS interception from beyond the captive-portal network. Systems aware they are behind a captive portal can also refrain from sending cookies and credentials.
The IPv4 DHCP Captive-Portal option uses option code 160 (one octet), a Len field (one octet) indicating the length of the URI in octets, and a variable-length URI field encoded per RFC 3986. The URI is not null-terminated.
The IPv6 DHCP Captive-Portal option uses a two-octet option-code (103), a two-octet option-len field indicating the URI length in octets, and a variable-length URI field encoded per RFC 3986. The URI is not null-terminated.
The IPv6 RA Captive-Portal option uses Type 37 (one octet), an 8-bit unsigned Length field in units of 8 bytes (including Type and Length), and a variable-length URI field padded with NULL (0x0) to make the total option length a multiple of 8 bytes.