RFC 7710，使用DHCP或路由器广告（RAS）的圈式式识别

我喜欢监视IETFmailing lists for new Internet RFCs that are published. Many of these are cryptic things likeRFC 7675, Session Traversal Utilities for NAT (STUN) Usage for Consent Freshness。我不确定我什至知道这意味着什么。有些对我来说确实很有意义。最近RFC 7710，使用DHCP或路由器广告（RAS）的圈式式识别出版并引起了我的注意。

俘虏门户网站,如果你不熟悉term, are those systems that intercept a user's web traffic and redirects them to another page on the guest network. These may only require the user to agree to an acceptable use policy or they may require a login. In some venues the user may even have to pay for service. I'm not a big fan of these, as they are a perpetual nuisance to end users. Having an unexpected page open up in lieu of the page that was asked for isn't convenient. It is also problematic for many Wi-Fi devices, especially streaming devices. You might think, for example, that you could take a Chromecast or Apple TV with you to a hotel, plug it into the TV, and watch what you want. However, very few of these devices have any way to handle the captive portal, leaving the user connected to the Wi-Fi network without the ability to actually use it.

当前，大多数操作系统都使用黑客检查圈养门户。当用户连接到网络时，操作系统将尝试访问一个或多个特定的URL，以查看他们是否看到预期响应。如果没有，则假设是一个圈养门户，它将以某种方式通知用户，并允许他们登录以进行完整的Internet访问。

例如，在OS X的最新版本中，测试URL为http://captive.apple.com/hotspotdetect.html。此页面将返回“成功”的简单响应。如果操作系统未收到该响应，它将打开圈养网络助理并显示重定向请求的任何圈养门户页面。您可以使用它来验证门户网站，接受所需的协议或执行其他需要的操作。

为了获得帮助，圈养门户有时会将用户发送到最初要求的URL。如果这是OS X检测圈养门户的URL，则现在将用户发送到一个纯白页，上面显示“成功”。这并不完全用户友好或特别优雅。但是，处理此问题的选择有限，尤其是考虑到每个OS版本的测试URL似乎都在变化。这是我们的新RFC来播放的地方。

From RFC7710:

IPv4圈式 - 端口DHCP选项的格式如下所示。代码LEN数据+------+------+------+------+------+-------+ - + - +-----+|代码|Len |Uri ... |+-------+------+-------+-------+-------+ - + - +-----+o代码：圈式 - 端口DHCPV4选项（160）（一个八位位）。o len：长度，在URI的八位。O URI：用户应连接到的圈养门户的联系URI（按照[RFC3986]中的规则进行编码）。

从一开始，RFC 7710并不能解决问题，但是它确实提供了可以建立解决方案的有用基础。RFC 7710定义了新的DHCP选项（160），该选项将包含圈养门户的URL。它还定义了IPv6 DHCP选项103和IPv6路由器广告选项类型37，这两个选项都将包含圈式门户网站的URL。如果客户端中的DHCP客户端或IPv6堆栈支持此选项，则可以更智能地处理圈养门户，而不是猜测它。其余的过程将与今天相同，只是更干净。

从理论上讲，将其与标准化的圈养门户接口或API结合使用，可能会导致诸如Chromecast和AppleTV之类的设备能够显示AUP并为用户提供接受它的选项。这将更加用户友好和可靠。它还应允许用户更快地访问网络，尤其是如果设备允许用户保存对AUP或登录信息的接受。这可能是我们所在的位置和Hotspot 2.0所采取的物品之间的潜在中间立场，因为在基础设施方面实施要容易得多。当然，在客户开始支持它之前，这一切都是理论和梦想。

RFC7710为客户设备检测圈养门户的存在提供了一种更好的方法。它有可能打开可以改善用户体验的新选项，但需要更多的作品才能落在原位。必须将选项添加到基础架构中，并且需要更新客户端软件才能使用它。但是，要真正使事情变得有趣并大大增强了用户体验，需要有一个标准化的API来圈养门户。那将是困难的部分。