[Dnssec-trigger] [rfc-dist] RFC 7710 on Captive-Portal Identification Using DHCP or Router Advertisements (RAs)

[Petr Spacek]

Hello,

this might be interesting for dnssec-trigger.

Basically it announces URI of the captive portal so the client knows that
captive portal detection is pointless and captive portal page can be opened
right away, without delays.

Security considerations are described in the RFC.

Petr^2 Spacek

-------- Forwarded Message --------
Subject: [rfc-dist] RFC 7710 on Captive-Portal Identification Using DHCP or
Router Advertisements (RAs)
Date: Mon,  7 Dec 2015 16:38:26 -0800 (PST)
From: rfc-editor at rfc-editor.org
To: ietf-announce at ietf.org, rfc-dist at rfc-editor.org
CC: drafts-update-ref at iana.org, rfc-editor at rfc-editor.org

A new Request for Comments is now available in online RFC libraries.


        RFC 7710

        Title:      Captive-Portal Identification Using DHCP or
                    Router Advertisements (RAs)
        Author:     W. Kumari, O. Gudmundsson,
                    P. Ebersman, S. Sheng
        Status:     Standards Track
        Stream:     IETF
        Date:       December 2015
        Mailbox:    warren at kumari.net,
                    olafur at cloudflare.com,
                    ebersman-ietf at dragon.net,
                    steve.sheng at icann.org
        Pages:      8
        Characters: 16352
        Updates/Obsoletes/SeeAlso:   None

        I-D Tag:    draft-wkumari-dhc-capport-16.txt

        URL:        https://www.rfc-editor.org/info/rfc7710

        DOI:        http://dx.doi.org/10.17487/RFC7710

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.

This is now a Proposed Standard.

STANDARDS TRACK: This document specifies an Internet Standards Track
protocol for the Internet community, and requests discussion and suggestions
for improvements.  Please refer to the current edition of the Official
Internet Protocol Standards (https://www.rfc-editor.org/standards) for the
standardization state and status of this protocol.  Distribution of this
memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  https://www.ietf.org/mailman/listinfo/ietf-announce
  https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see https://www.rfc-editor.org/search
For downloading RFCs, see https://www.rfc-editor.org/rfc.html

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-editor at rfc-editor.org.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.


The RFC Editor Team
Association Management Solutions, LLC


_______________________________________________
rfc-dist mailing list
rfc-dist at rfc-editor.org
https://www.rfc-editor.org/mailman/listinfo/rfc-dist
http://www.rfc-editor.org