Internet Engineering Task Force (IETF) W. Kumari
Request for Comments: 7710 Google
Category: Standards Track O. Gudmundsson
ISSN: 2070-1721 CloudFlare
P. Ebersman
Comcast
S. Sheng
ICANN
December 2015
Internet Engineering Task Force (IETF) W. Kumari
Request for Comments: 7710 Google
Category: Standards Track O. Gudmundsson
ISSN: 2070-1721 CloudFlare
P. Ebersman
Comcast
S. Sheng
ICANN
December 2015
Captive-Portal Identification Using DHCP or Router Advertisements (RAs)
使用DHCP或路由器播发（RAs）的捕获门户标识
Abstract
摘要
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.
在许多提供短期或临时Internet访问的环境中（如咖啡馆），通常以捕获门户模式启动新连接。这高度限制了客户在进行身份验证之前可以执行的操作。
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.
本文档描述了一个DHCP选项（和路由器广告（RA）扩展），用于通知客户端他们在某种捕获门户设备后面，并且需要进行身份验证才能访问Internet。它不是一个完整的解决方案，无法解决客户可能遇到的所有问题；它被设计用于更大的解决方案中。对捕获门户进行身份验证并与之交互的方法超出了本文档的范围。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7710.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7710.
Copyright Notice
版权公告
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2015 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements notation . . . . . . . . . . . . . . . . . . 3
2. The Captive-Portal Option . . . . . . . . . . . . . . . . . . 3
2.1. IPv4 DHCP Option . . . . . . . . . . . . . . . . . . . . 3
2.2. IPv6 DHCP Option . . . . . . . . . . . . . . . . . . . . 4
2.3. The Captive-Portal IPv6 RA Option . . . . . . . . . . . . 4
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
4. Security Considerations . . . . . . . . . . . . . . . . . . . 5
5. Normative References . . . . . . . . . . . . . . . . . . . . 6
6. Informative References . . . . . . . . . . . . . . . . . . . 7
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements notation . . . . . . . . . . . . . . . . . . 3
2. The Captive-Portal Option . . . . . . . . . . . . . . . . . . 3
2.1. IPv4 DHCP Option . . . . . . . . . . . . . . . . . . . . 3
2.2. IPv6 DHCP Option . . . . . . . . . . . . . . . . . . . . 4
2.3. The Captive-Portal IPv6 RA Option . . . . . . . . . . . . 4
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
4. Security Considerations . . . . . . . . . . . . . . . . . . . 5
5. Normative References . . . . . . . . . . . . . . . . . . . . 6
6. Informative References . . . . . . . . . . . . . . . . . . . 7
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
In many environments, users need to connect to a captive-portal device and agree to an Acceptable Use Policy (AUP) and/or provide billing information before they can access the Internet. It is anticipated that the IETF will work on a more fully featured protocol at some point, to ease interaction with captive portals. Regardless of how that protocol operates, it is expected that this document will provide needed functionality because the client will need to know when it is behind a captive portal and how to contact it.
在许多环境中，用户需要连接到捕获门户设备并同意可接受的使用策略（AUP）和/或提供计费信息，然后才能访问Internet。预计IETF将在某个时候使用功能更全面的协议，以简化与捕获门户的交互。无论该协议如何运行，本文档都将提供所需的功能，因为客户机需要知道它何时位于捕获门户后面，以及如何与捕获门户联系。
In order to present users with the payment or AUP pages, the captive-portal device has to intercept the user's connections and redirect the user to the captive portal, using 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 secure stance, these interception techniques will become less effective and/or more intrusive.
为了向用户提供支付或AUP页面，捕获门户设备必须拦截用户的连接，并使用与中间人（MITM）攻击非常类似的方法将用户重定向到捕获门户。随着人们越来越关注安全性，并且终端节点采取了更安全的立场，这些拦截技术将变得更不有效和/或更具侵入性。
This document describes a DHCP ([RFC2131]) option (Captive-Portal) and an IPv6 Router Advertisement (RA) ([RFC4861]) extension that inform clients that they are behind a captive-portal device and how to contact it.
本文档描述了一个DHCP（[RFC2131]）选项（捕获门户）和一个IPv6路由器公告（RA）（[RFC4861]）扩展，用于通知客户端他们在捕获门户设备后面以及如何联系它。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
The Captive-Portal DHCP/RA option informs the client that it is behind a captive portal and provides the URI to access an authentication page. This is primarily intended to improve the user experience by getting them to the captive portal faster; for the foreseeable future, captive portals will still need to implement the interception techniques to serve legacy clients, and clients will need to perform probing to detect captive portals.
捕获门户DHCP/RA选项通知客户端它位于捕获门户的后面，并提供访问身份验证页面的URI。这主要是为了提高用户体验，让他们更快地进入专属门户；在可预见的未来，捕获门户仍然需要实施拦截技术来服务遗留客户端，客户端需要执行探测来检测捕获门户。
In order to support multiple "classes" of clients (e.g., IPv4 only, IPv6 only with DHCPv6 ([RFC3315]), 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. The maximum length of the URI that can be carried in IPv4 DHCP is 255 bytes, so URIs longer than 255 bytes should not be used in IPv6 DHCP or IPv6 RA.
为了支持多个“类”客户端（例如，仅IPv4、仅IPv6和DHCPv6（[RFC3315]）、仅IPv6和RA），捕获门户可以通过多种方法（IPv4 DHCP、IPv6 DHCP、IPv6 RA）提供URI。受控门户运营商应确保发放的URI等同于减少运营问题的机会。IPv4 DHCP中可携带的URI的最大长度为255字节，因此在IPv6 DHCP或IPv6 RA中不应使用超过255字节的URI。
In order to avoid having to perform DNS interception, the URI SHOULD contain an address literal. If the captive portal allows the client to perform DNS requests to resolve the name, it is then acceptable for the URI to contain a DNS name. The URI parameter is not null terminated.
为了避免必须执行DNS拦截，URI应该包含地址文本。如果捕获门户允许客户端执行DNS请求以解析名称，则URI包含DNS名称是可以接受的。URI参数不是以null结尾的。
The format of the IPv4 Captive-Portal DHCP option is shown below.
IPv4捕获门户DHCP选项的格式如下所示。
Code Len Data
+------+------+------+------+------+-- --+-----+
| Code | Len | URI ... |
+------+------+------+------+------+-- --+-----+
Code Len Data
+------+------+------+------+------+-- --+-----+
| Code | Len | URI ... |
+------+------+------+------+------+-- --+-----+
o Code: The Captive-Portal DHCPv4 option (160) (one octet).
o 代码：捕获门户DHCPv4选项（160）（一个八位字节）。
o Len: The length, in octets of the URI.
o 长度，以URI的八位字节为单位。
o URI: The contact URI for the captive portal that the user should connect to (encoded following the rules in [RFC3986]).
o URI：用户应连接到的捕获门户的联系人URI（按照[RFC3986]中的规则编码）。
The format of the IPv6 Captive-Portal DHCP option is shown below.
IPv6捕获门户DHCP选项的格式如下所示。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option-code | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. URI (variable length) .
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option-code | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. URI (variable length) .
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o option-code: The Captive-Portal DHCPv6 option (103) (two octets).
o 选项代码：捕获门户DHCPv6选项（103）（两个八位字节）。
o option-len: The length, in octets of the URI.
o 选项len：URI的长度，以八位字节为单位。
o URI: The contact URI for the captive portal that the user should connect to (encoded following the rules in [RFC3986]).
o URI：用户应连接到的捕获门户的联系人URI（按照[RFC3986]中的规则编码）。
See Section 5.7 of [RFC7227] for more examples of DHCP options with URIs.
有关带有URI的DHCP选项的更多示例，请参见[RFC7227]的第5.7节。
The format of the Captive-Portal Router Advertisement option is shown below.
捕获门户路由器播发选项的格式如下所示。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | URI .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ .
. .
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | URI .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ .
. .
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Type: 37
o 类型：37
o Length: 8-bit unsigned integer. The length of the option (including the Type and Length fields) in units of 8 bytes.
o 长度：8位无符号整数。选项的长度（包括类型和长度字段），以8字节为单位。
o URI: The contact URI for the captive portal that the user should connect to. For the reasons described above, the implementer might want to use an IP address literal instead of a DNS name. This should be padded with NULL (0x0) to make the total option length (including the Type and Length fields) a multiple of 8 bytes.
o URI：用户应连接到的捕获门户的联系人URI。出于上述原因，实现者可能希望使用IP地址文字而不是DNS名称。这应该用NULL（0x0）填充，以使总选项长度（包括类型和长度字段）为8字节的倍数。
This document defines two DHCP Captive-Portal options, one for IPv4 and one for IPv6. An option code (160) has been assigned from the "BOOTP Vendor Extensions and DHCP Options" registry (http://www.iana.org/assignments/bootp-dhcp-parameters), as specified in [RFC2939]. Also, an option code (103) has been assigned from the "Option Codes" registry under DHCPv6 parameters (http://www.iana.org/assignments/dhcpv6-parameters).
本文档定义了两个DHCP捕获门户选项，一个用于IPv4，另一个用于IPv6。已从“BOOTP供应商扩展和DHCP选项”注册表分配选项代码（160）(http://www.iana.org/assignments/bootp-dhcp-parameters)，如[RFC2939]所述。此外，已在DHCPv6参数下从“选项代码”注册表分配选项代码（103）(http://www.iana.org/assignments/dhcpv6-parameters).
IANA also has assigned an IPv6 RA Option Type code (37) from the
"IPv6 Neighbor Discovery Option Formats" registry under ICMPv6
parameters (http://www.iana.org/assignments/icmpv6-parameters).
Thanks, IANA!
IANA also has assigned an IPv6 RA Option Type code (37) from the
"IPv6 Neighbor Discovery Option Formats" registry under ICMPv6
parameters (http://www.iana.org/assignments/icmpv6-parameters).
Thanks, IANA!
An attacker with the ability to inject DHCP messages could include this option and so force users to contact an address of his choosing. As an attacker with this capability could simply list himself as the default gateway (and so intercept all the victim's traffic), this does not provide the attacker with significantly more capabilities, but because this document removes the need for interception, the attacker may have an easier time performing the attack. As the operating systems and application that make use of this information know that they are connecting to a captive-portal device (as opposed to intercepted connections), they can render the page in a sandboxed environment and take other precautions, such as clearly labeling the page as untrusted. The means of sandboxing and how the user interface presents this information are not covered in this document -- by their nature, those are implementation specific and best left to the application and user-interface designers.
能够插入DHCP消息的攻击者可能会包括此选项，从而迫使用户联系他选择的地址。由于具有此功能的攻击者可以简单地将自己列为默认网关（从而拦截所有受害者的流量），因此这并不会为攻击者提供更多的功能，但由于本文档消除了拦截的需要，攻击者可能更容易执行攻击。由于使用此信息的操作系统和应用程序知道它们正在连接到捕获的门户设备（与拦截的连接相反），因此它们可以在沙盒环境中呈现页面，并采取其他预防措施，例如明确将页面标记为不受信任。沙盒的方法以及用户界面如何显示这些信息不在本文档中介绍——从本质上讲，这些都是特定于实现的，最好留给应用程序和用户界面设计者。
Devices and systems that automatically connect to an open network could potentially be tracked using the techniques described in this document (forcing the user to continually authenticate, or exposing their browser fingerprint). However, similar tracking can already be performed with the standard captive-portal mechanisms, so this technique does not give the attackers more capabilities.
可以使用本文档中描述的技术跟踪自动连接到开放网络的设备和系统（强制用户持续进行身份验证或公开其浏览器指纹）。但是，类似的跟踪已经可以通过标准的捕获门户机制执行，因此该技术不会为攻击者提供更多功能。
Captive portals are increasingly hijacking TLS connections to force browsers to talk to the portal. Providing the portal's URI via a DHCP or RA option is a cleaner technique and reduces user expectations of being hijacked; this may improve security by making users more reluctant to accept TLS hijacking, which can be performed from beyond the network associated with the captive portal.
捕获门户越来越多地劫持TLS连接，迫使浏览器与门户进行对话。通过DHCP或RA选项提供门户的URI是一种更干净的技术，可以降低用户被劫持的期望；这可能会使用户更不愿意接受TLS劫持，从而提高安全性。TLS劫持可以从与捕获门户相关的网络之外执行。
By simplifying the interaction with the captive-portal systems and doing away with the need for interception, we think that users will be less likely to disable useful security safeguards like DNSSEC validation, VPNs, etc. In addition, because the system knows that it is behind a captive portal, it can know not to send cookies, credentials, etc. By handing out a URI that is protected with TLS, the captive-portal operator can attempt to reassure the user that the captive portal is not malicious.
通过简化与捕获门户系统的交互并消除拦截的需要，我们认为用户不太可能禁用有用的安全保护措施，如DNSSEC验证、VPN等。此外，由于系统知道它在捕获门户后面，因此它可以知道不发送cookie、凭据、，等。通过分发受TLS保护的URI，捕获门户操作员可以尝试向用户保证捕获门户不是恶意的。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, DOI 10.17487/RFC2131, March 1997, <http://www.rfc-editor.org/info/rfc2131>.
[RFC2131]Droms，R.，“动态主机配置协议”，RFC 2131，DOI 10.17487/RFC2131，1997年3月<http://www.rfc-editor.org/info/rfc2131>.
[RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 2003, <http://www.rfc-editor.org/info/rfc3315>.
[RFC3315]Droms，R.，Ed.，Bound，J.，Volz，B.，Lemon，T.，Perkins，C.，和M.Carney，“IPv6的动态主机配置协议（DHCPv6）”，RFC 3315，DOI 10.17487/RFC3315，2003年7月<http://www.rfc-editor.org/info/rfc3315>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, <http://www.rfc-editor.org/info/rfc3986>.
[RFC3986]Berners Lee，T.，Fielding，R.，和L.Masinter，“统一资源标识符（URI）：通用语法”，STD 66，RFC 3986，DOI 10.17487/RFC3986，2005年1月<http://www.rfc-editor.org/info/rfc3986>.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, DOI 10.17487/RFC4861, September 2007, <http://www.rfc-editor.org/info/rfc4861>.
[RFC4861]Narten，T.，Nordmark，E.，Simpson，W.，和H.Soliman，“IP版本6（IPv6）的邻居发现”，RFC 4861，DOI 10.17487/RFC48612007年9月<http://www.rfc-editor.org/info/rfc4861>.
[RFC7227] Hankins, D., Mrugalski, T., Siodelski, M., Jiang, S., and S. Krishnan, "Guidelines for Creating New DHCPv6 Options", BCP 187, RFC 7227, DOI 10.17487/RFC7227, May 2014, <http://www.rfc-editor.org/info/rfc7227>.
[RFC7227]Hankins，D.，Mrugalski，T.，Siodelski，M.，Jiang，S.，和S.Krishnan，“创建新DHCPv6选项的指南”，BCP 187，RFC 7227，DOI 10.17487/RFC7227，2014年5月<http://www.rfc-editor.org/info/rfc7227>.
[RFC2939] Droms, R., "Procedures and IANA Guidelines for Definition of New DHCP Options and Message Types", BCP 43, RFC 2939, DOI 10.17487/RFC2939, September 2000, <http://www.rfc-editor.org/info/rfc2939>.
[RFC2939]Droms，R.，“新DHCP选项和消息类型定义的程序和IANA指南”，BCP 43，RFC 2939，DOI 10.17487/RFC2939，2000年9月<http://www.rfc-editor.org/info/rfc2939>.
Acknowledgements
致谢
Thanks to Vint Cerf for asking for this document to be written. Thanks to Wes George for supplying the IPv6 text. Thanks to Lorenzo and Erik for the V6 RA kick in the pants.
感谢Vint Cerf要求编写本文件。感谢Wes George提供IPv6文本。多亏了洛伦佐和埃里克的大力支持。
Thanks to Fred Baker, Paul Hoffman, Barry Leiba, Ted Lemon, Martin Nilsson, Ole Troan, and Asbjorn Tonnesen for detailed reviews and comments. Thanks for David Black for review and providing text for the security considerations. Also, great thanks to Joel Jaeggli for providing feedback and text.
感谢Fred Baker、Paul Hoffman、Barry Leiba、Ted Lemon、Martin Nilsson、Ole Troan和Asbjorn Tonnesen的详细评论和评论。感谢David Black的审阅，并提供了安全注意事项的文本。另外，非常感谢Joel Jaeggli提供反馈和文本。
Authors' Addresses
作者地址
Warren Kumari Google 1600 Amphitheatre Parkway Mountain View, CA 94043 United States
沃伦·库马里谷歌1600圆形剧场公园道山景，加利福尼亚州94043
Email: warren@kumari.net
Email: warren@kumari.net
Olafur Gudmundsson CloudFlare San Francisco, CA 94107 United States
Olafur Gudmundsson CloudFlare旧金山，加州94107美国
Email: olafur@cloudflare.com
Email: olafur@cloudflare.com
Paul Ebersman Comcast
保罗·埃伯斯曼·康卡斯特
Email: ebersman-ietf@dragon.net
Email: ebersman-ietf@dragon.net
Steve Sheng Internet Corporation for Assigned Names and Numbers 12025 Waterfront Drive, Suite 300 Los Angeles, CA 90094 United States Phone: +1.310.301.5800
美国加利福尼亚州洛杉矶滨水路12025号300室Steve Sheng互联网公司电话：+1.310.301.5800
Email: steve.sheng@icann.org
Email: steve.sheng@icann.org