订阅以接收新文章的通知:

利用 DNS 估算 IPv6 全球采用情况

2023/12/14

15 分钟(阅读时间)
Using DNS to estimate the worldwide state of IPv6 adoption

为了使一台设备能够使用恰当命名的互联网协议 (IP) 与互联网上的其他设备进行通信,首先必须为其分配一个唯一的数字地址。该地址的外观取决于所使用的 IP 版本:IPv4 还是 IPv6

IPv4 于 1983 年首次部署。它是催生了现代互联网的 IP 版本,并且至今仍然占据主导地位。IPv6 的历史可以追溯到 1998 年,但直到最近十年,它才开始获得巨大的关注——从不到 1% 上升到 30% 到 40% 之间,具体取决于报告方、报告内容和测量方式。

随着连接设备的增长远远超过可用的 IPv4 地址数量,并且其成本不断上升,IPv6 提供的更大地址空间本应该使其成为目前的主导协议。然而,正如我们将看到的,事实并非如此。

Cloudflare 多年来一直是 IPv6 的坚定倡导者,并且我们一直通过 Cloudflare Radar 密切关注 IPv6 在互联网上的采用情况。Radar 已经推出三年了,仍然是一个相对较新的平台。如果要追溯到更早的时间,我们可以简单地向 APNIC1 (五个地区互联网注册管理机构 (RIRs)之一)的朋友求助。通过他们追溯到 2012 年的数据,我们可以看到 IPv6 在 2017 年年中之前经历了一段看似指数级的增长期,之后进入了线性增长期,目前仍在持续:

由于两种协议之间缺乏兼容性(必须同时为设备分配 IPv4 和 IPv6 地址)以及事实上互联网上的所有设备仍然支持 IPv4,IPv6 的采用速度减慢了。然而,IPv6 对于互联网的未来至关重要,因此需要继续努力增加其部署。

Cloudflare Radar 与 APNIC 和当今大多数其他来源一样,发布的数据主要反映了互联网服务提供商 (ISP) 部署 IPv6 的程度:客户端。这是一个非常重要的角度,直接影响最终用户,但还有等式的另一端:服务器端

考虑到这一点,我们邀请您跟随我们进行一个快速实验,我们的目的是了解服务器端 IPv6 的采用情况,以及客户端实际上(或可能)能够通过 IPv6 与服务器通信的频率。我们将依靠 DNS 进行此探索,正如他们所说,结果可能会让您感到惊讶。

客户端的 IPv6 采用情况(来自 HTTP)

从 Cloudflare 的角度来看,截至 2023 年 10 月,整个互联网的 IPv6 采用率约为所有流量的 36%,根据一天中的时间和一周中的日期略有变化。如果排除机器人,这一估计值将上升至 46% 以上,而如果排除人类,则该估计值会下降到近 24%。这些数字指的是通过 IPv6 提供的 HTTP 请求在所有启用 IPv6 的内容(默认设置)中所占的份额。

对于这项工作来说,最重要的是人类机器人的数量。造成这两种流量采用率差距的原因有很多——从所使用的大量客户端软件对 IPv6 的支持程度不同,到流量来源的众多网络内部 IPv6 部署程度不同,再到这些网络的规模不同,等等,但这都是后话了。如果您对某个国家或网络的数字感到好奇,可以查阅 Cloudflare Radar 和我们的 2023 年度回顾报告。

等式的两端

读者可能会指出,对“客户端-服务器”等式中的“客户端”一侧进行测量,只能说明问题的一半:要让支持 IPv6 的“客户端”通过 IPv6 与服务器建立连接,服务器也必须支持 IPv6。

这就提出了两个问题:

  1. 服务器端采用 IPv6 的程度如何?
  2. 客户端采用 IPv6 与服务器采用 IPv6 的一致性如何?

有几种可能的答案,取决于我们谈论的是用户、设备还是传输的字节数等等。我们将把重点放在连接(稍后就会明白为什么),我们提出的综合问题是:

在典型的使用模式下,支持 IPv6 的客户端在连接互联网上的服务器时,能够使用 IPv6 的频率如何?

典型的使用模式包括人们每天访问某些网站的频率高于其他网站,或者自动客户端调用 API。我们将通过 DNS 来了解这一点。

进入 DNS

无论是使用传统的 IPv4 协议还是更现代的 IPv6 协议,客户端在尝试通过名称与服务器建立连接之前,都必须在互联网的电话簿——域名系统 (DNS)——中查找服务器的 IP 地址。

在 DNS 中查找主机名是一个递归过程。要查找服务器的 IP 地址,必须在多个 DNS 权威服务器上跟踪域层次结构(服务器名称的点分隔组件),直到其中一个服务器返回所需的响应2。不过,大多数客户端不会直接这样做,而是让一个称为递归解析器的中间服务器代劳。Cloudflare 就运营着这样一个任何人都可以使用的递归解析器:1.1.1.1

举个简单的例子,当客户端向 1.1.1.1 询问 “www.example.com” 所在的 IP 地址时,1.1.1.1 会先向 DNS 根服务器3询问有关“.com”的信息,然后向 .com DNS 服务器询问有关“example.com”的信息,最后向 example.com DNS 服务器询问有关 “www.example.com”的信息,后者直接了解该信息并用 IP 地址进行答复。为了让下一个提出类似问题的客户端更快地得到答案,1.1.1.1 会缓存(暂时记忆)最终答案和中间的步骤。

这意味着 1.1.1.1 能够很好地统计客户端尝试查找 IPv4 地址(A 类查询)的频率尝试查找 IPv6 地址(AAAA 类查询)的频率,覆盖了大部分可观察到的互联网。

但是,客户端如何知道何时询问服务器的 IPv4 地址或 IPv6 地址?

简而言之,可以使用 IPv6 的客户端会同时请求 IPv4 和 IPv6 地址,即为它們希望连接的每台服务器进行单独的 AAAAA 查找。这些支持 IPv6 的客户端在获得非空 AAAA 答复时将优先通过 IPv6 进行连接,无论它们是否也获得非空 A 答复(正如我们将看到的,它们几乎总是会得到非空的 A 答复)。推动这种现代性偏好的算法被称为 Happy Eyeballs,如果您对细节感兴趣,可在此查看。

我们现在可以开始查看一些实际数据了…

客户端的 IPv6 采用情况(来自 DNS)

第一步是通过从 1.1.1.1 的角度测量客户端 IPv6 部署并将其与我们开始时的 HTTP 请求数量进行比较来建立基线。

计算客户端使用 IPv6 连接到 1.1.1.1 的频率很有诱惑力,但由于以下几个原因,结果会产生误导,其中最重要的一个原因隐藏在显而易见的地方:在客户端可用来通过 1.1.1.1 服务执行 DNS 查找的 IPv4 和 IPv6 地址集合中,1.1.1.1 是最容易记住的地址。理想情况下,使用 1.1.1.1 作为递归解析器的支持 IPv6 的客户端应配置以下所有四个 IP 地址,而不仅仅是前两个:

  • 1.1.1.1 (IPv4)
  • 1.0.0.1 (IPv4)
  • 2606:4700:4700::1111 (IPv6)
  • 2606:4700:4700::1001 (IPv6)

但是,当涉及手动配置时4,人类会发现 IPv6 地址不如 IPv4 地址好记,而且不太可能进行配置,因此认为 IPv4 地址就足够了。

与此相关但不太明显的干扰因素是,许多支持 IPv6 的客户端即使配置了 1.1.1.1 的 IPv6 地址,仍然会通过 IPv4 执行 DNS 查找,因为分散查找可用地址是一种流行的默认选项。

从 DNS 客户端活动评估 IPv6 采用情况的更合理方法是计算 AAAA 类型查询占 A 类型查询总量的百分比(假设 IPv6 客户端始终同时执行这两种查询5,如前所述)。

那么,从 1.1.1.1 的角度来看,按查询量计算,客户端的 IPv6 采用率估计为 30.5%。这略低于我们从 HTTP 流量中观察到的同期数据 (35.9%),但两种不同视角之间的差异并不出人意料。

关于 TTL 的说明

不仅递归解析器会缓存 DNS 响应,大多数 DNS 客户端也有自己的本地缓存。您的 Web 浏览器、操作系统甚至是家用路由器都会保留答案,希望能加快后续查询的速度。

每个答案在缓存中保留的时间取决于随 DNS 记录传回的生存时间 (TTL) 字段。如果您熟悉 DNS,可能会想知道 A 和 AAAA 记录是否具有相似的 TTL。如果不相似,则对于这两种类型种的一种,我们可能会收到更少的查询(因为它在客户端级别缓存的时间更长),从而使最终的采用数据产生偏差。

这里的饼图细分了 1.1.1.1 响应 A 和 AAAA 查询时传回的最小 TTL6。两种类型之间存在一定差异,但差异很小。

服务器端的 IPv6 采用情况

下图显示了 A 和 AAAA 类型查询获得非空响应的频率,揭示了服务器端的 IPv6 采用情况,让我们更接近我们想要的答案:

按查询量计算,服务器采用 IPv6 的比例估计为 43.3%,明显高于客户端。

双方同时接受的频率

如果由 1.1.1.1 处理的 IP 地址查询中有 30.5% 可以使用 IPv6 地址连接到预定目的地,但其中只有 43.3% 的查询得到了非空响应,那么这就为我们提供了一个很好的基础,说明客户端和服务器之间的 IPv6 连接频率大约为 13.2%

热门域名的潜在影响

根据 Radar 前 100 列表中的域的查询量衡量,IPv6 服务器端采用率为 60.8%。如果我们从整体计算中排除这些域,之前的 13.2% 数字将下降至 8%。这是一个显着差异,但并不意外,因为前 100 个域占 1.1.1.1 所有 A 和 AAAA 查询量的 55% 以上。

如果今天在这些非常受欢迎的域中有更多部署 IPv6,那么观察到的采用率就会明显提高,支持 IPv6 的客户端使用 IPv6 建立连接的机会也会随之增加。

结束语

观察整个互联网采用 IPv6 的程度可能意味着不同的事情:

  • 计算具有 IPv6 互联网访问能力的用户
  • 计算支持 IPv6 的设备或这些设备(客户端和/或服务器)上的软件;
  • 计算流经 IPv6 连接的流量(以字节为单位);
  • 计算 IPv6 连接(或单个请求)的比例。

在本次练习中,我们选择查看连接和请求。考虑到只有从几个不同的角度才能真正理解基本现实,我们看到了三种不同的 IPv6 采用数据:

  • 在计算 Cloudflare CDN 提供的 HTTP 请求时为 35.9%(客户端);
  • 在计算 1.1.1.1 处理的 A 和 AAAA 类型 DNS 查询时,为 30.5%(客户端);
  • 对同样来自 1.1.1.1 的 AAAA 类型 DNS 查询的积极回复率为 43.3%(服务器端)。

我们从 DNS 角度结合了客户端服务器端的数据,来估计通过 IPv6 而非 IPv4 与第三方服务器建立连接的频率:仅为 13.2%

要提高这些数字,ISP、云和托管提供商以及企业都必须提高其网络设备的 IPv6 可用率。但是,大型网站和内容源在使支持 IPv6 的客户端更频繁地使用 IPv6 方面也发挥着关键作用,因为在对 Radar 前 100 的域的查询中,有 39.2%(占 1.1.1.1 的所有 A 和 AAAA 查询的一半以上)仍然限于仅 IPv4 的响应。

对于全面采用 IPv6 的目标,互联网还没有完全实现。但是,所有相关各方的持续努力可以帮助它继续向前发展,甚至可能加速进展。

在服务器端,Cloudflare 多年来一直通过为所有域提供免费的 IPv6 支持来推进这项全球性的工作。在客户端,1.1.1.1 应用程序会自动为您的设备启用 IPv6,即使您的 ISP 不提供任何 IPv6 支持。而且,如果您碰巧管理仅 IPv6 的网络,1.1.1.1 的 DNS64 支持也可以满足您的需求。

***
1Cloudflare 的公共 DNS 解析器 (1.1.1.1) 与 APNIC 合作运营。您可以在原始公告博客文章和 1.1.1.1 的隐私政策中阅读更多相关信息。
2有关 DNS 如何工作的更多信息,请参阅我们网站中的“什么是 DNS?”部分。如果您喜欢动手学习,我们建议您看看 Julia Evans 的“mess with dns”。
3任何递归解析器都已经事先知道 13 个根服务器的 IP 地址。Cloudflare 还通过向 E 和 F-Root 实例提供 Anycast 服务来参与 DNS 的最顶层,这意味着 1.1.1.1 不需要走很远就能完成第一个查找步骤。
4使用 1.1.1.1 应用程序时,会自动配置全部四个 IP 地址。
5为了简单起见,我们假定纯 IPv6 客户端的数量仍然少得可以忽略不计。总体而言,这是一个合理的假设,我们所掌握的其他数据集也证实了这一点。
61.1.1.1 与其他递归解析器一样,返回调整后的 TTL:记录的原始 TTL 减去自上次缓存记录以来的秒数。空 A 和 AAAA 答复将按照 RFC 2308 指定的域授权机构起始 (SOA) 记录中定义的时间进行缓存。

我们保护整个企业网络,帮助客户高效构建互联网规模的应用程序,加速任何网站或互联网应用程序抵御 DDoS 攻击,防止黑客入侵,并能协助您实现 Zero Trust 的过程

从任何设备访问 1.1.1.1,以开始使用我们的免费应用程序,帮助您更快、更安全地访问互联网。要进一步了解我们帮助构建更美好互联网的使命,请从这里开始。如果您正在寻找新的职业方向,请查看我们的空缺职位
Cloudflare Radar (CN)IPv6 (CN)DNS (CN)简体中文

在 X 上关注

Cloudflare|@cloudflare

相关帖子