< draft-ietf-capport-rfc7710bis-05.txt   draft-ietf-capport-rfc7710bis-06.txt >
Network Working Group W. Kumari Network Working Group W. Kumari
Internet-Draft Google Internet-Draft Google
Obsoletes: 7710 (if approved) E. Kline Obsoletes: 7710 (if approved) E. Kline
Intended status: Standards Track Loon Intended status: Standards Track Loon
Expires: November 14, 2020 May 13, 2020 Expires: November 16, 2020 May 15, 2020
Captive-Portal Identification in DHCP / RA Captive-Portal Identification in DHCP / RA
draft-ietf-capport-rfc7710bis-05 draft-ietf-capport-rfc7710bis-06
Abstract Abstract
In many environments offering short-term or temporary Internet access In many environments offering short-term or temporary Internet access
(such as coffee shops), it is common to start new connections in a (such as coffee shops), it is common to start new connections in a
captive portal mode. This highly restricts what the customer can do captive portal mode. This highly restricts what the customer can do
until the customer has authenticated. until the customer has authenticated.
This document describes a DHCP option (and a Router Advertisement This document describes a DHCPv4 and DHCPv6 option and a Router
(RA) extension) to inform clients that they are behind some sort of Advertisement (RA) option to inform clients that they are behind some
captive-portal enforcement device, and that they will need to sort of captive-portal enforcement device, and that they will need to
authenticate to get Internet access. It is not a full solution 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; address all of the issues that clients may have with captive portals;
it is designed to be used in larger solutions. The method of it is designed to be one component of a standardized approach for
authenticating to, and interacting with the captive portal is out of hosts to interact with such portals. While this document defines how
scope of this document. the network operator may convey the captive portal API endpoint to
hosts, the specific methods of authenticating to, and interacting
with the captive portal are out of scope of this document.
This document replaces RFC 7710. RFC 7710 used DHCP code point 160. This document replaces RFC 7710. RFC 7710 used DHCP code point 160.
Due to a conflict, this document specifies 114. Due to a conflict, this document specifies 114.
[ This document is being collaborated on in Github at: [ This document is being collaborated on in Github at:
https://github.com/capport-wg/7710bis. The most recent version of https://github.com/capport-wg/7710bis. The most recent version of
the document, open issues, etc should all be available here. The the document, open issues, etc should all be available here. The
authors (gratefully) accept pull requests. Text in square brackets authors (gratefully) accept pull requests. Text in square brackets
will be removed before publication. ] will be removed before publication. ]
skipping to change at page 2, line 7 skipping to change at page 2, line 10
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 14, 2020. This Internet-Draft will expire on November 16, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 3
2. The Captive-Portal Option . . . . . . . . . . . . . . . . . . 3 2. The Captive-Portal Option . . . . . . . . . . . . . . . . . . 3
2.1. IPv4 DHCP Option . . . . . . . . . . . . . . . . . . . . 4 2.1. IPv4 DHCP Option . . . . . . . . . . . . . . . . . . . . 4
2.2. IPv6 DHCP Option . . . . . . . . . . . . . . . . . . . . 5 2.2. IPv6 DHCP Option . . . . . . . . . . . . . . . . . . . . 5
2.3. The Captive-Portal IPv6 RA Option . . . . . . . . . . . . 5 2.3. The Captive-Portal IPv6 RA Option . . . . . . . . . . . . 6
3. Precedence of API URIs . . . . . . . . . . . . . . . . . . . 6 3. Precedence of API URIs . . . . . . . . . . . . . . . . . . . 6
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
4.1. Captive Portal Unrestricted Identifier . . . . . . . . . 7 4.1. Captive Portal Unrestricted Identifier . . . . . . . . . 7
4.2. BOOTP Vendor Extensions and DHCP Options Code Change . . 7 4.2. BOOTP Vendor Extensions and DHCP Options Code Change . . 7
5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
7.1. Normative References . . . . . . . . . . . . . . . . . . 9 7.1. Normative References . . . . . . . . . . . . . . . . . . 9
7.2. Informative References . . . . . . . . . . . . . . . . . 10 7.2. Informative References . . . . . . . . . . . . . . . . . 10
Appendix A. Changes / Author Notes. . . . . . . . . . . . . . . 11 Appendix A. Changes / Author Notes. . . . . . . . . . . . . . . 11
Appendix B. Changes from RFC 7710 . . . . . . . . . . . . . . . 11 Appendix B. Changes from RFC 7710 . . . . . . . . . . . . . . . 11
Appendix C. Observations From IETF 106 Network Experiment . . . 11 Appendix C. Observations From IETF 106 Network Experiment . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction 1. Introduction
In many environments, users need to connect to a captive-portal In many environments, users need to connect to a captive-portal
device and agree to an Acceptable Use Policy (AUP) and / or provide device and agree to an Acceptable Use Policy (AUP) and / or provide
billing information before they can access the Internet. Regardless billing information before they can access the Internet. Regardless
of how that mechanism operates, this document provides functionality of how that mechanism operates, this document provides functionality
to allow the client to know when it is behind a captive portal and to allow the client to know when it is behind a captive portal and
how to contact it. how to contact it.
In order to present users with the payment or AUP pages, presently a In order to present users with the payment or AUP pages, presently a
captive-portal enforcement device has to intercept the user's captive-portal enforcement device has to intercept the user's
connections and redirect the user to a captive portal server, using connections and redirect the user to a captive portal server, using
methods that are very similar to man-in-the-middle (MITM) attacks. methods that are very similar to man-in-the-middle (MITM) attacks.
As increasing focus is placed on security, and end nodes adopt a more As increasing focus is placed on security, and end nodes adopt a more
secure stance, these interception techniques will become less secure stance, these interception techniques will become less
effective and/or more intrusive. effective and/or more intrusive.
This document describes a DHCP ([RFC2131]) option (Captive-Portal) This document describes a DHCPv4 [RFC2131] and DHCPv6 [RFC8415]
and an IPv6 Router Advertisement (RA) ([RFC4861]) extension that option (Captive-Portal) and an IPv6 Router Advertisement (RA)
informs clients that they are behind a captive-portal enforcement [RFC4861] option that informs clients that they are behind a captive-
device and how to contact an API for more information. portal enforcement device and the API endpoint that the host can
contact for more information.
This document replaces RFC 7710 [RFC7710]. This document replaces RFC 7710 [RFC7710].
1.1. Requirements Notation 1.1. Requirements Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
2. The Captive-Portal Option 2. The Captive-Portal Option
The Captive Portal DHCP / RA Option informs the client that it may be The Captive Portal DHCP / RA Option informs the client that it may be
behind a captive portal and provides the URI to access an API as behind a captive portal and provides the URI to access an API as
defined by [draft-ietf-capport-api]. This is primarily intended to defined by [draft-ietf-capport-api]. This is primarily intended to
improve the user experience by showing the user the captive portal improve the user experience by showing the user the captive portal
information faster and more reliably. Note that, for the foreseeable information faster and more reliably. Note that, for the foreseeable
future, captive portals will still need to implement the interception future, captive portals will still need to implement interception
techniques to serve legacy clients, and clients will need to perform techniques to serve legacy clients, and clients will need to perform
probing to detect captive portals. probing to detect captive portals.
Clients that support the Captive Portal DHCP option SHOULD include Clients that support the Captive Portal DHCP option SHOULD include
the option in the Parameter Request List in DHCPREQUEST messages. the option in the Parameter Request List in DHCPREQUEST messages.
DHCP servers MAY send the Captive Portal option without any explicit DHCP servers MAY send the Captive Portal option without any explicit
request. request.
In order to support multiple "classes" of clients (e.g. IPv4 only, In order to support multiple "classes" of clients (e.g. IPv4 only,
IPv6 only with DHCPv6 ([RFC8415]), and IPv6 only with RA) the captive IPv6 only with DHCPv6 ([RFC8415]), and IPv6 only with RA) the captive
skipping to change at page 6, line 40 skipping to change at page 6, line 49
IPv6 RA options. IPv6 RA options.
3. Precedence of API URIs 3. Precedence of API URIs
A device may learn about Captive Portal API URIs through more than A device may learn about Captive Portal API URIs through more than
one of (or indeed all of) the above options. Implementations can one of (or indeed all of) the above options. Implementations can
select their own precedence order (e.g., prefer one of the IPv6 select their own precedence order (e.g., prefer one of the IPv6
options before the DHCPv4 option, or vice versa, et cetera). options before the DHCPv4 option, or vice versa, et cetera).
If the URIs learned via more than one option described in Section 2 If the URIs learned via more than one option described in Section 2
are not all identical, this condition should be logged for the device are not all identical, this condition SHOULD be logged for the device
owner or administrator; it is a network configuration error if the owner or administrator; it is a network configuration error if the
learned URIs are not all identical. learned URIs are not all identical.
4. IANA Considerations 4. IANA Considerations
This document requests one new IETF URN protocol parameter This document requests one new IETF URN protocol parameter
([RFC3553]) entry. This document also requests a reallocation of ([RFC3553]) entry. This document also requests a reallocation of
DHCPv4 option codes (see Appendix C for background). DHCPv4 option codes (see Appendix C for background).
Thanks IANA! Thanks IANA!
4.1. Captive Portal Unrestricted Identifier 4.1. Captive Portal Unrestricted Identifier
This document registers a new entry under the IETF URN Sub-namespace This document registers a new entry under the IETF URN Sub-namespace
defined in [RFC3553]: for Registered Protocol Parameter Identifiers defined in [RFC3553]:
Registry name: Captive Portal Unrestricted Identifier
URN: urn:ietf:params:capport:unrestricted Registered Parameter Identifier: capport:unrestricted
Specification: RFC TBD (this document) Reference: RFC TBD (this document)
Repository: RFC TBD (this document) IANA Registry Reference: https://www.iana.org/assignments/params/
params.xml#params-1
Index value: Only one value is defined (see URN above). No Only one value is defined (see URN above). No hierarchy is defined
hierarchy is defined and therefore no sub-namespace registrations and therefore no sub-namespace registrations are possible.
are possible.
4.2. BOOTP Vendor Extensions and DHCP Options Code Change 4.2. BOOTP Vendor Extensions and DHCP Options Code Change
[ RFC Ed: Please remove before publication: RFC7710 uses DHCP Code [ RFC Ed: Please remove before publication: RFC7710 uses DHCP Code
160 -- unfortunately, it was discovered that this option code is 160 -- unfortunately, it was discovered that this option code is
already widely used by Polycom (see appendix). Option 114 (URL) is already widely used by Polycom (see appendix). Option 114 (URL) is
currently assigned to Apple (RFC3679, Section 3.2.3 - Contact: Dieter currently assigned to Apple (RFC3679, Section 3.2.3 - Contact: Dieter
Siegmund, dieter@apple.com - Reason to recover: Never published in an Siegmund, dieter@apple.com - Reason to recover: Never published in an
RFC) Tommy Pauly (Apple) and Dieter Siegmund confirm that this RFC) Tommy Pauly (Apple) and Dieter Siegmund confirm that this
codepoint hasn't been used, and Apple is willing to relinquish it for codepoint hasn't been used, and Apple is willing to relinquish it for
 End of changes. 17 change blocks. 
28 lines changed or deleted 29 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/