< draft-wkumari-dhc-capport-09.txt		draft-wkumari-dhc-capport-10.txt >
	Network Working Group W. Kumari		Network Working Group W. Kumari
	Internet-Draft Google		Internet-Draft Google
	Intended status: Informational O. Gudmundsson		Intended status: Informational O. Gudmundsson
	Expires: July 31, 2015 Shinkuro Inc.		Expires: August 1, 2015 Shinkuro Inc.
	P. Ebersman		P. Ebersman
	Comcast		Comcast
	S. Sheng		S. Sheng
	ICANN		ICANN
	January 27, 2015		January 28, 2015
	Captive-Portal identification in DHCP / RA		Captive-Portal identification in DHCP / RA
	draft-wkumari-dhc-capport-09		draft-wkumari-dhc-capport-10
	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 RA extension) to inform		This document describes a DHCP option (and a RA extension) to inform
	clients that they are behind some sort of captive portal device, and		clients that they are behind some sort of captive portal device, and
	skipping to change at page 1, line 42 ¶		skipping to change at page 1, line 42 ¶
	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 http://datatracker.ietf.org/drafts/current/.		Drafts is at http://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 July 31, 2015.		This Internet-Draft will expire on August 1, 2015.
	Copyright Notice		Copyright Notice
	Copyright (c) 2015 IETF Trust and the persons identified as the		Copyright (c) 2015 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
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://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
	skipping to change at page 2, line 23 ¶		skipping to change at page 2, line 23 ¶
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	1.1. Requirements notation . . . . . . . . . . . . . . . . . . 3		1.1. Requirements notation . . . . . . . . . . . . . . . . . . 3
	2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2.1. DNS Redirection . . . . . . . . . . . . . . . . . . . . . 4		2.1. DNS Redirection . . . . . . . . . . . . . . . . . . . . . 4
	2.2. HTTP Redirection . . . . . . . . . . . . . . . . . . . . 4		2.2. HTTP Redirection . . . . . . . . . . . . . . . . . . . . 4
	2.3. IP Hijacking . . . . . . . . . . . . . . . . . . . . . . 4		2.3. IP Hijacking . . . . . . . . . . . . . . . . . . . . . . 4
	3. The Captive-Portal DHCP Option . . . . . . . . . . . . . . . 5		3. The Captive-Portal Option . . . . . . . . . . . . . . . . . . 5
	3.1. IPv4 DHCP Option . . . . . . . . . . . . . . . . . . . . 5		3.1. IPv4 DHCP Option . . . . . . . . . . . . . . . . . . . . 5
	3.2. IPv6 DHCP Option . . . . . . . . . . . . . . . . . . . . 5		3.2. IPv6 DHCP Option . . . . . . . . . . . . . . . . . . . . 6
	4. The Captive-Portal IPv6 RA Option . . . . . . . . . . . . . . 6		4. The Captive-Portal IPv6 RA Option . . . . . . . . . . . . . . 6
	5. Use of the Captive-Portal Option . . . . . . . . . . . . . . 6		5. Use of the Captive-Portal Option . . . . . . . . . . . . . . 7
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 8		7. Security Considerations . . . . . . . . . . . . . . . . . . . 8
	8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9		8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
	9. Normative References . . . . . . . . . . . . . . . . . . . . 9		9. Normative References . . . . . . . . . . . . . . . . . . . . 9
	Appendix A. Changes / Author Notes. . . . . . . . . . . . . . . 9		Appendix A. Changes / Author Notes. . . . . . . . . . . . . . . 9
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
	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
	skipping to change at page 5, line 5 ¶		skipping to change at page 5, line 5 ¶
	2.3. IP Hijacking		2.3. IP Hijacking
	In this scenario, the captive portal intercepts connections to any IP		In this scenario, the captive portal intercepts connections to any IP
	address. It spoofs the destination IP address and "pretends" to be		address. It spoofs the destination IP address and "pretends" to be
	whatever the user tried to access.		whatever the user tried to access.
	This technique has issues similar to the HTTP solution, but may also		This technique has issues similar to the HTTP solution, but may also
	break other protocols, and may expose more of the user's private		break other protocols, and may expose more of the user's private
	information.		information.
	3. The Captive-Portal DHCP Option		3. The Captive-Portal Option
	The Captive Portal DHCP Option informs the client that it is behind a		The Captive Portal DHCP / RA Option informs the client that it is
	captive portal and provides the URI to access an authentication page.		behind a captive portal and provides the URI to access an
	This is primarily intended to improve the user experience; for the		authentication page. This is primarily intended to improve the user
	foreseeable future (until such time that most systems implement this		experience; for the foreseeable future (until such time that most
	technique) captive portals will still need to implement the		systems implement this technique) captive portals will still need to
	interception techniques to serve legacy clients.		implement the interception techniques to serve legacy clients.
			In order to support multiple "classes" of clients (e.g: IPv4 only,
			IPv6 only with DHCPv6, IPv6 only with RA) the captive portal can
			provide the URI via multiple methods (IPv4 DHCP, IPv6 DHCP, IPv6 RA).
			The captive portal operator should ensure that the URIs handed out
			are equivalent to reduce the chance of operational problems.
	In order to avoid having to perform DNS interception, the URI SHOULD		In order to avoid having to perform DNS interception, the URI SHOULD
	contain an address literal, but MAY contain a DNS name if the captive		contain an address literal, but MAY contain a DNS name if the captive
	portal allows the client to perform DNS requests to resolve the name.		portal allows the client to perform DNS requests to resolve the name.
	[ED NOTE: Using an address literal is less than ideal, but better		[ED NOTE: Using an address literal is less than ideal, but better
	than the alternatives. Recommending a DNS name means that the CP		than the alternatives. Recommending a DNS name means that the CP
	would need to allow DNS from unauthenticated clients (as we don't		would need to allow DNS from unauthenticated clients (as we don't
	want to force users to use the CP's provided DNS) and some users		want to force users to use the CP's provided DNS) and some users
	would use this to DNS Tunnel out, which may make the CP admin block		would use this to DNS Tunnel out, which may make the CP admin block
	skipping to change at page 7, line 23 ¶		skipping to change at page 7, line 38 ¶
	note: It may be useful to write another document that specifies how a		note: It may be useful to write another document that specifies how a
	client can determine that it has passed the CP. This document could		client can determine that it has passed the CP. This document could
	also contain advice to implementors on only intercepting actually		also contain advice to implementors on only intercepting actually
	needed ports, how to advertise that the CP needs to be satisfied		needed ports, how to advertise that the CP needs to be satisfied
	*again*, etc. This should not be done in this document though. ] The		*again*, etc. This should not be done in this document though. ] The
	connectivity test may also need to be used if the captive portal		connectivity test may also need to be used if the captive portal
	times out the user session and needs the user to re-authenticate.		times out the user session and needs the user to re-authenticate.
	The operating system may still find the information about the captive		The operating system may still find the information about the captive
	portal URI useful in this case.		portal URI useful in this case.
	If the device gets different URIs (for example, via DHCPv6 and IPv6
	RA) it should try them in the following order: DHCPv4, DHCPv6, RA.
	[Ed note: This ordering is somewhat arbitrary - this order was chosen
	because this is the order I expect the code to be implemented by OS
	vendors, and I'd like the same behavior from newer and older devices
	to make troubleshooting easier.]
	When the device is informed that it is behind a captive portal it		When the device is informed that it is behind a captive portal it
	should:		should:
	1. Not initiate new IP connections until the CP has been satisfied		1. Not initiate new IP connections until the CP has been satisfied
	(other than those to the captive portal browser session and		(other than those to the captive portal browser session and
	connectivity checks). Existing connections should be quiesced		connectivity checks). Existing connections should be quiesced
	(this will happen more often than some expect -- for example, the		(this will happen more often than some expect -- for example, the
	user purchases 1 hour of Internet at a cafe and stays there for 3		user purchases 1 hour of Internet at a cafe and stays there for 3
	hours -- this will "interrupt" the user a few times).		hours -- this will "interrupt" the user a few times).
	skipping to change at page 9, line 28 ¶		skipping to change at page 9, line 36 ¶
	9. Normative References		9. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	Appendix A. Changes / Author Notes.		Appendix A. Changes / Author Notes.
	[RFC Editor: Please remove this section before publication ]		[RFC Editor: Please remove this section before publication ]
			From 09 to 10:
			o Ted Lemon and Joel Jaeggli: there's no benefit to insisting on an
			ordering. I think you should just say that the ordering is
			indeterminate, and if different mechanisms give non-equivalent
			answers, this is likely to cause operational problems in practice.
	From 08 to 09:		From 08 to 09:
	o Put back the DHCPv6 option, and made the fact that is separate		o Put back the DHCPv6 option, and made the fact that is separate
	from the DHCPv4 option clearer (Ted Lemon)		from the DHCPv4 option clearer (Ted Lemon)
	From 07 to 08:		From 07 to 08:
	o Incorporated comments from Ted Lemon. Made the document much		o Incorporated comments from Ted Lemon. Made the document much
	shorter.		shorter.
End of changes. 11 change blocks.
	22 lines changed or deleted		27 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/