Skip to main content

Captive-Portal Identification in DHCP / RA

Document Type Replaced Internet-Draft (individual)
Expired & archived
Authors Warren "Ace" Kumari , Erik Kline
Last updated 2019-03-11
Replaced by draft-ietf-capport-rfc7710bis
RFC stream (None)
Intended RFC status (None)
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state Replaced by draft-ietf-capport-rfc7710bis
Telechat date (None)
Responsible AD (None)
Send notices to (None)

This Internet-Draft is no longer active. A copy of the expired Internet-Draft is available in these formats:


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: 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. ]


Warren "Ace" Kumari
Erik Kline

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