Captive-Portal Identification in DHCP / RA
draft-ietf-capport-rfc7710bis-00

The information below is for an old version of the document
Document Type Expired Internet-Draft (capport WG)
Authors Warren Kumari  , Erik Kline 
Last updated 2020-01-03 (latest revision 2019-07-02)
Replaces draft-ekwk-capport-rfc7710bis
Stream IETF
Intended RFC status (None)
Formats
Expired & archived
pdf htmlized (tools) htmlized bibtex
Reviews
Additional Resources
- Mailing list discussion
Stream WG state WG Document
Document shepherd No shepherd assigned
IESG IESG state Expired
Consensus Boilerplate Unknown
Telechat date
Responsible AD (None)
Send notices to (None)

This Internet-Draft is no longer active. A copy of the expired Internet-Draft can be found at
https://www.ietf.org/archive/id/draft-ietf-capport-rfc7710bis-00.txt

Abstract

In many environments offering short-term or temporary Internet access (such as coffee shops), it is common to start new connections in a captive portal mode. This highly restricts what the customer can do until the customer has authenticated. This document describes a DHCP option (and a Router Advertisement (RA) extension) to inform clients that they are behind some sort of captive-portal device, and that they will need to authenticate to get Internet access. It is not a full solution to address all of the issues that clients may have with captive portals; it is designed to be used in larger solutions. The method of authenticating to, and interacting with the captive portal is out of scope of this document. [ This document is being collaborated on in Github at: https://github.com/wkumari/draft-ekwk-capport-rfc7710bis. The most recent version of the document, open issues, etc should all be available here. The authors (gratefully) accept pull requests. Text in square brackets will be removed before publication. ]

Authors

Warren Kumari (warren@kumari.net)
Erik Kline (ek@google.com)

(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)