RFC 7710
Captive-Portal Identification Using DHCP or Router Advertisements (RAs)
RFC 7710 ✨ Captive-Portal Identification Using DHCP or Router Advertisements (RAs)
okay bestie, RFC 7710 is a Standards Track doc from December 2015 💖 It's by W. Kumari (Google), O. Gudmundsson (CloudFlare), P. Ebersman (Comcast), and S. Sheng (ICANN). It has ISSN 2070-1721, and the header doesn't list any obsoletes or updates. So it's its own thing, no drama 🫶
Captive-Portal Identification Using DHCP or Router Advertisements (RAs)Abstract 🌸
in a lot of places that give you short-term or temporary internet, like coffee shops, new connections usually start in a captive-portal mode. that mode seriously limits what the customer can do until they've authenticated 🙈
this doc describes a DHCP option (plus a Router Advertisement (RA) extension) that tells clients they're behind some kind of captive-portal device and that they'll need to authenticate to get internet access 🦋 it's not a full fix for every problem clients might have with captive portals. it's built to be used inside bigger solutions ✨ how you authenticate to the portal and interact with it is out of scope here.
Status of This Memo 📜
this is an Internet Standards Track document 🔥
it's a product of the Internet Engineering Task Force (IETF), and it reflects the consensus of the IETF community. it got public review and was approved for publication by the Internet Engineering Steering Group (IESG). more info on Internet Standards is in Section 2 of RFC 5741.
for the current status, any errata, and how to give feedback, check http://www.rfc-editor.org/info/rfc7710.
Copyright Notice 🎀
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
this document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stand on the date this document was published. please read these carefully, because they describe your rights and restrictions for this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they're provided without warranty as described in the Simplified BSD License.
Table of Contents 🗂️
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements notation . . . . . . . . . . . . . . . . . . 3
2. The Captive-Portal Option . . . . . . . . . . . . . . . . . . 3
2.1. IPv4 DHCP Option . . . . . . . . . . . . . . . . . . . . 3
2.2. IPv6 DHCP Option . . . . . . . . . . . . . . . . . . . . 4
2.3. The Captive-Portal IPv6 RA Option . . . . . . . . . . . . 4
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
4. Security Considerations . . . . . . . . . . . . . . . . . . . 5
5. Normative References . . . . . . . . . . . . . . . . . . . . 6
6. Informative References . . . . . . . . . . . . . . . . . . . 7
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 81. Introduction ✨
in a lot of places, people have to connect to a captive-portal device and agree to an Acceptable Use Policy (AUP) and/or give billing info before they can get online 💅 the IETF is expected to work on a more fully featured protocol at some point to make captive portals easier to deal with. whatever that protocol ends up looking like, this doc should still be useful, because the client will need to know when it's behind a captive portal and how to contact it 🫶
to show users the payment or AUP pages, the captive-portal device has to intercept their connections and redirect them to the portal. it does this with methods that are super similar to man-in-the-middle (MITM) attacks 💀 as more focus goes on security and end nodes get more secure, these interception techniques will become less effective and/or more intrusive 😭
this document describes a DHCP ([RFC2131]) option (Captive-Portal) and an IPv6 Router Advertisement (RA) ([RFC4861]) extension. both tell clients that they're behind a captive-portal device and how to reach it 🦋
1.1. Requirements Notation 📝
the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] 🎀
2. The Captive-Portal Option 💖
the Captive-Portal DHCP/RA option tells the client that it's behind a captive portal and gives it the URI for an authentication page. the main goal is a better user experience, because it gets people to the portal faster 🚀 for the foreseeable future, though, captive portals still need the interception techniques to serve legacy clients, and clients still need to probe to detect captive portals 🙈
to support multiple "classes" of clients (like IPv4 only, IPv6 only with DHCPv6 ([RFC3315]), and IPv6 only with RA), the captive portal can hand out the URI through several methods: IPv4 DHCP, IPv6 DHCP, and IPv6 RA ✨ the captive-portal operator should make sure the URIs handed out are equivalent, so there's less chance of operational problems 🫶 the maximum length of a URI carried in IPv4 DHCP is 255 bytes, so URIs longer than 255 bytes should not be used in IPv6 DHCP or IPv6 RA 💅
heads up: the reason URIs should stay short in those lower-case "should" spots is just what the spec says, so keep it in mind when you're building one 🌈
to avoid having to do DNS interception, the URI SHOULD contain an address literal 👑 if the captive portal lets the client make DNS requests to resolve a name, then it's fine for the URI to contain a DNS name instead. the URI parameter is not null terminated 🍓
2.1. IPv4 DHCP Option 🌸
the format of the IPv4 Captive-Portal DHCP option is shown below 🎀
Code Len Data
+------+------+------+------+------+-- --+-----+
| Code | Len | URI ... |
+------+------+------+------+------+-- --+-----+- Code: the Captive-Portal DHCPv4 option (160) (one octet) 💜
- Len: the length, in octets, of the URI 💜
- URI: the contact URI for the captive portal that the user should connect to (encoded following the rules in [RFC3986]) 🦋
2.2. IPv6 DHCP Option 🧚
the format of the IPv6 Captive-Portal DHCP option is shown below 🌈
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option-code | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. URI (variable length) .
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- option-code: the Captive-Portal DHCPv6 option (103) (two octets) 💖
- option-len: the length, in octets, of the URI 💖
- URI: the contact URI for the captive portal that the user should connect to (encoded following the rules in [RFC3986]) 🦋
for more examples of DHCP options with URIs, see Section 5.7 of [RFC7227] 💅
part 1 wraps here, and part 2 (Section 2.3 onward, plus IANA, Security, and the references) is coming right up 💖
4. Security Considerations 🔐
okay bestie, this is the serious part 😭 but I'm still gonna make it fun. An attacker who can inject DHCP messages could include this option and force users to contact an address of their choosing 💀. BUT here's the tea: an attacker with that power could just list themselves as the default gateway and intercept all the victim's traffic anyway. So this doesn't give them significantly more capabilities. The catch is that this document removes the need for interception, so the attacker might have an easier time pulling it off 🙈.
Operating systems and applications that use this info know they're talking to a captive-portal device (not an intercepted connection). That means they can render the page in a sandboxed environment and take other precautions, like clearly labeling the page as untrusted 🫶. How the sandboxing works and how the UI shows all this isn't covered in this document. That stuff is implementation-specific and best left to the app and UI designers 🎀.
Devices and systems that automatically connect to an open network could potentially be tracked using the techniques in this document, like forcing the user to keep authenticating or exposing their browser fingerprint 👀. However, similar tracking is already possible with the standard captive-portal mechanisms, so this technique doesn't hand attackers any new powers ✨.
Captive portals are increasingly hijacking TLS connections to force browsers to talk to the portal 😤. Giving out the portal's URI through a DHCP or RA option is a cleaner technique, and it reduces user expectations of being hijacked. This may improve security by making users more reluctant to accept TLS hijacking, which can be performed from beyond the network associated with the captive portal 🧚.
By simplifying the interaction with captive-portal systems and doing away with the need for interception, we think users will be less likely to disable useful security safeguards like DNSSEC validation, VPNs, etc. 🔒 Also, because the system knows it's behind a captive portal, it can know not to send cookies, credentials, etc. And by handing out a URI that's protected with TLS, the captive-portal operator can try to reassure the user that the captive portal isn't malicious 💜.
5. Normative References 📚
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, DOI 10.17487/RFC2131, March 1997, <http://www.rfc-editor.org/info/rfc2131>.
[RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 2003, <http://www.rfc-editor.org/info/rfc3315>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, <http://www.rfc-editor.org/info/rfc3986>.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, DOI 10.17487/RFC4861, September 2007, <http://www.rfc-editor.org/info/rfc4861>.
[RFC7227] Hankins, D., Mrugalski, T., Siodelski, M., Jiang, S., and S. Krishnan, "Guidelines for Creating New DHCPv6 Options", BCP 187, RFC 7227, DOI 10.17487/RFC7227, May 2014, <http://www.rfc-editor.org/info/rfc7227>.
6. Informative References 🌸
[RFC2939] Droms, R., "Procedures and IANA Guidelines for Definition of New DHCP Options and Message Types", BCP 43, RFC 2939, DOI 10.17487/RFC2939, September 2000, <http://www.rfc-editor.org/info/rfc2939>.
Acknowledgements 💖
Thanks to Vint Cerf for asking for this document to be written 👑. Thanks to Wes George for supplying the IPv6 text 🧚. Thanks to Lorenzo and Erik for the V6 RA kick in the pants 😭.
Thanks to Fred Baker, Paul Hoffman, Barry Leiba, Ted Lemon, Martin Nilsson, Ole Troan, and Asbjorn Tonnesen for detailed reviews and comments 🫶. Thanks for David Black for review and providing text for the security considerations 🔐. Also, great thanks to Joel Jaeggli for providing feedback and text 🌈.
Authors' Addresses 🦋
Warren Kumari
Google
1600 Amphitheatre Parkway
Mountain View, CA 94043
United States
Email: warren@kumari.net
Olafur Gudmundsson
CloudFlare
San Francisco, CA 94107
United States
Email: olafur@cloudflare.com
Paul Ebersman
Comcast
Email: ebersman-ietf@dragon.net
Steve Sheng
Internet Corporation for Assigned Names and Numbers
12025 Waterfront Drive, Suite 300
Los Angeles, CA 90094
United States
Phone: +1.310.301.5800
Email: steve.sheng@icann.org📦 where this page comes from
- ietf: rfc7710 2015-12
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms