<?xml version="1.0" encoding="UTF-8"?>
<reference anchor="I-D.wkumari-dhc-capport" target="https://datatracker.ietf.org/doc/html/draft-wkumari-dhc-capport-16">
   <front>
      <title>Captive-Portal Identification Using DHCP or Router Advertisements (RAs)</title>
      <author initials="W." surname="Kumari" fullname="Warren Kumari">
         <organization>Google</organization>
      </author>
      <author initials="O." surname="Guðmundsson" fullname="Ólafur Guðmundsson">
         <organization>CloudFlare</organization>
      </author>
      <author initials="P." surname="Ebersman" fullname="P Ebersman">
         <organization>Comcast</organization>
      </author>
      <author initials="S." surname="Sheng" fullname="Steve Sheng">
         <organization>ICANN</organization>
      </author>
      <date month="August" day="31" year="2015" />
      <abstract>
	 <t>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 for this document.
	 </t>
      </abstract>
   </front>
   <seriesInfo name="Internet-Draft" value="draft-wkumari-dhc-capport-16" />
   
</reference>
