< draft-wkumari-dhc-capport-14.txt		draft-wkumari-dhc-capport-15.txt >
	Network Working Group W. Kumari		Network Working Group W. Kumari
	Internet-Draft Google		Internet-Draft Google
	Intended status: Standards Track O. Gudmundsson		Intended status: Standards Track O. Gudmundsson
	Expires: February 14, 2016 CloudFlare		Expires: February 25, 2016 CloudFlare
	P. Ebersman		P. Ebersman
	Comcast		Comcast
	S. Sheng		S. Sheng
	ICANN		ICANN
	August 13, 2015		August 24, 2015
	Captive-Portal Identification in DHCP / RA		Captive-Portal Identification in DHCP / RA
	draft-wkumari-dhc-capport-14		draft-wkumari-dhc-capport-15
	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 49 ¶		skipping to change at page 1, line 49 ¶
	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 February 14, 2016.		This Internet-Draft will expire on February 25, 2016.
	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 3, line 34 ¶		skipping to change at page 3, line 34 ¶
	need to perform probing to detect captive portals.		need to perform probing to detect captive portals.
	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([RFC3315]), IPv6 only with RA) the captive		IPv6 only with DHCPv6([RFC3315]), IPv6 only with RA) the captive
	portal can provide the URI via multiple methods (IPv4 DHCP, IPv6		portal can provide the URI via multiple methods (IPv4 DHCP, IPv6
	DHCP, IPv6 RA). The captive portal operator should ensure that the		DHCP, IPv6 RA). The captive portal operator should ensure that the
	URIs handed out are equivalent to reduce the chance of operational		URIs handed out are equivalent to reduce the chance of operational
	problems.		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. If the captive portal allows the client
	portal allows the client to perform DNS requests to resolve the name.		to perform DNS requests to resolve the name, it is then acceptable
			for the URI to contain a DNS name.
	2.1. IPv4 DHCP Option		2.1. IPv4 DHCP Option
	The format of the IPv4 Captive-Portal DHCP option is shown below.		The format of the IPv4 Captive-Portal DHCP option is shown below.
	Code Len Data		Code Len Data
	+------+------+------+------+------+-- --+-----+		+------+------+------+------+------+-- --+-----+
	| code | len | URI ... |		| code | len | URI ... |
	+------+------+------+------+------+-- --+-----+		+------+------+------+------+------+-- --+-----+
	skipping to change at page 6, line 13 ¶		skipping to change at page 6, line 13 ¶
	credentials, etc. Redirection to a portal where TLS can be used		credentials, etc. Redirection to a portal where TLS can be used
	without hijacking can ameliorate some of the implications of		without hijacking can ameliorate some of the implications of
	connecting to a potentially malicious captive portal.		connecting to a potentially malicious captive portal.
	6. Acknowledgements		6. Acknowledgements
	Thanks to Vint Cerf for the initial idea / asking me to write this.		Thanks to Vint Cerf for the initial idea / asking me to write this.
	Thanks to Wes George for supplying the IPv6 text. Thanks to Lorenzo		Thanks to Wes George for supplying the IPv6 text. Thanks to Lorenzo
	and Erik for the V6 RA kick in the pants.		and Erik for the V6 RA kick in the pants.
	Thanks to Fred Baker, Paul Hoffman, Ted Lemon, Martin Nilsson, Ole		Thanks to Fred Baker, Paul Hoffman, Barry Leiba, Ted Lemon, Martin
	Troan and Asbjorn Tonnesen for detailed review and comments. Also		Nilsson, Ole Troan and Asbjorn Tonnesen for detailed review and
	great thanks to Joel Jaeggli for providing feedback and text.		comments. Also great thanks to Joel Jaeggli for providing feedback
			and text.
	7. Normative References		7. 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, DOI 10.17487/		Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/
	RFC2119, March 1997,		RFC2119, March 1997,
	<http://www.rfc-editor.org/info/rfc2119>.		<http://www.rfc-editor.org/info/rfc2119>.
	[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC		[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC
	2131, DOI 10.17487/RFC2131, March 1997,		2131, DOI 10.17487/RFC2131, March 1997,
	skipping to change at page 6, line 47 ¶		skipping to change at page 6, line 48 ¶
	[RFC7227] Hankins, D., Mrugalski, T., Siodelski, M., Jiang, S., and		[RFC7227] Hankins, D., Mrugalski, T., Siodelski, M., Jiang, S., and
	S. Krishnan, "Guidelines for Creating New DHCPv6 Options",		S. Krishnan, "Guidelines for Creating New DHCPv6 Options",
	BCP 187, RFC 7227, DOI 10.17487/RFC7227, May 2014,		BCP 187, RFC 7227, DOI 10.17487/RFC7227, May 2014,
	<http://www.rfc-editor.org/info/rfc7227>.		<http://www.rfc-editor.org/info/rfc7227>.
	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 14 to 15:
			o Incorporated readability comment from Barry Leiba
	From 13 to 14:		From 13 to 14:
	o Added a bunch of disclaimers explaining that this is not a		o Added a bunch of disclaimers explaining that this is not a
	complete solution. We expect that the actual interaction bit		complete solution. We expect that the actual interaction bit
	should be done in CAPPORT.		should be done in CAPPORT.
	From 13.2 to 13(posted):		From 13.2 to 13(posted):
	o Shortened the document by removing most of the [Editors notes],		o Shortened the document by removing most of the [Editors notes],
	Section 2, Section 5 and Appendix A. They were mainly background		Section 2, Section 5 and Appendix A. They were mainly background
End of changes. 7 change blocks.
	9 lines changed or deleted		14 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/