Movatterモバイル変換


[0]ホーム

URL:


Search RFCs

Advanced Search

RFC Editor

RFC 8910

Captive-Portal Identification in DHCP and Router Advertisements (RAs),September 2020

File formats:

icon for HTMLicon for text fileicon for v3pdficon for XMLicon for inline errata
Also available:XML file for editing
 
Status:
PROPOSED STANDARD
Obsoletes:
RFC 7710
Updates:
RFC 3679
Authors:
W. Kumari
E. Kline
Stream:
IETF
Source:
capport (art)

Cite this RFC:TXT  | XML  |  BibTeX

DOI:  https://doi.org/10.17487/RFC8910

Discuss this RFC: Send questions or comments to the mailing listcaptive-portals@ietf.org

Other actions:View Errata  | Submit Errata  | Find IPR Disclosures from the IETF  | View History of RFC 8910


Abstract

In many environments offering short-term or temporary Internet access(such as coffee shops), it is common to start new connections in acaptive portal mode. This highly restricts what the user can do untilthe user has satisfied the captive portal conditions.

This document describes a DHCPv4 and DHCPv6 option and a RouterAdvertisement (RA) option to inform clients that they are behind somesort of captive portal enforcement device, and that they will need tosatisfy the Captive Portal conditions to get Internet access. It isnot a full solution to address all of the issues that clients mayhave with captive portals; it is designed to be one component of astandardized approach for hosts to interact with such portals. Whilethis document defines how the network operator may convey the captiveportal API endpoint to hosts, the specific methods of satisfying andinteracting with the captive portal are out of scope of thisdocument.

This document replaces RFC 7710, which used DHCP code point 160. Dueto a conflict, this document specifies 114. Consequently, thisdocument also updates RFC 3679.


For the definition ofStatus,seeRFC 2026.

For the definition ofStream, seeRFC 8729.




IABIANAIETFIRTFISEISOCIETF Trust
ReportsPrivacy StatementSite MapContact Us

Advanced Search

[8]ページ先頭

©2009-2026 Movatter.jp