Linux下date的默认输出格式

在两个debian主机下 使用date命令,显示的格式不一样,分为两种(A/B):

  • A:Sat Sep 14 10:15:03 PM CST 2024
  • B:Sat Sep 14 22:15:15 CST 2024

以晚上十点一刻为例,A 的10:15是12小时制,带有PM, B的22:15是24小时制,没有PM。

所以问题是, 如何设置12小时制 为 24小时制? 继续尝试几种涉及时间设置的命令。

使用 timedatectl查看 : (题外话:该命令在wsl,windows子系统中无效

timedatectl status
 timedatectl status
Local time: Sat 2024-09-14 21:56:01 CST
Universal time: Sat 2024-09-14 13:56:01 UTC
RTC time: Sat 2024-09-14 13:55:53
Time zone: Asia/Shanghai (CST, +0800)
System clock synchronized: no
NTP service: n/a
RTC in local TZ: no
timedatectl status
Local time: Sat 2024-09-14 21:56:07 CST
Universal time: Sat 2024-09-14 13:56:07 UTC
RTC time: n/a
Time zone: Asia/Shanghai (CST, +0800)
System clock synchronized: no
NTP service: n/a
RTC in local TZ: no

“Local time” , “Universal time”, “Time zone” 时间都是正确,并一致的。时钟同步,NTP服务也都并未使用。RTC time一个有时间,一个为空,应该是虚拟化不同的问题。看来timedatectl的信息并不显示时间是否12/24制式。

locale 查看本地设置:

locale -a
C
C.utf8
en_US.utf8
POSIX
C
C.utf8
POSIX
en_US.utf8

都是 “en_US.utf8″,只是 POSIX顺序不用,也无关。

使用 dpkg-reconfigure tzdata 重新设置时区:

dpkg-reconfigure tzdata

之后再看date,结果证明也与时间12/24制式无关。

使用 date –debug,会显示输出格式:

date --debug
date --debug
date: output format: ‘%a %b %e %r %Z %Y’
Sat Sep 14 10:15:03 PM CST 2024
date --debug
date: output format: '%a %b %e %H:%M:%S %Z %Y'
Sat Sep 14 22:14:50 CST 2024

看到不同了把? date 输出不同时间进制,与设置时间的命令无关。只有输出个格式的不同。那么这个格式是什么决定的?在哪里定义的?

之后看到这篇文章:https://linuxopsys.com/change-default-date-format-in-linux

原来 date 命令的默认日期格式。是根据 locale 中的 LC_TIME 参数,根据参数名,使用关联的设置文件。

例如,运行 locale 命令并查找 LC_TIME 变量。

locale

如图,看到 LC_TIME = “en_US.UTF-8“,这是美国常用的日期格式。

第 2 步:找到与 Locale 关联的文件
locale 文件通常位于 /usr/share/i18n/locales/ 中。您将找到一个名称与您的 LC_TIME locale 设置相对应的文件,如果 LC_TIME 区域设置是 en_US, 对应文件为/usr/share/i18n/locales/en_US


查看 Locale 文件,可以看到其中的 date_fmt 之后的定义 与 date –debug 显示的输出格式一样,

//12小时
"%a %b %e %r %Z %Y"

//24小时
"%a %b %e %H:%M:%S %Z %Y"
~ # date +"%a %b %e %r %Z %Y"
Sun Sep 15 12:16:14 AM CST 2024

~ # date +"%a %b %e %H:%M:%S %Z %Y"
Sun Sep 15 00:17:31 CST 2024

使用 date + “输出格式” 测试, 由此我们发现了问题根源。但是什么,两个“LC_TIME ” 都是 “en_US”,格式会不同呢?答案在 en_US 文件的注释中:

% Appropriate date and time representation for date(1). This is
% different from d_t_fmt for historical reasons and has been different
% since 2000 when date_fmt was added as a GNU extension. At the end
% of 2018 it was adjusted to use 12H time (bug 24046) instead of 24H.

也就是说,一个系统是2018年前安装,或设置生成的 Locale 文件,一个是在2018年之后

结尾

如此,明白了问题根源,就可以通过修改 locale 文件的date_fmt 或 重新设置 LC_TIME 环境变量,重新生成区域设置文件以应用更改。

locale-gen
update-locale

或者 用更简单的方法:

export LC_TIME=POSIX

直接设置 LC_TIME=POSIX,可以快速统一多台,不同本地语言设置的时间格式。

【END】

到底是谁的 CIDR?

原文:Whose CIDR Is It Anyway?

https://labs.ripe.net/author/jschauma/whose-cidr-is-it-anyway

【以下由 微软Bing 机翻】

IP 地址空间并没有被平均分配,经过多年的重新分配和重新分配,我想到的问题是:谁拥有它的哪些部分?在有关互联网集中化的系列文章的最新一篇中,Jan Schaumann 深入研究了数据,试图获得更清晰的视图。


今年是 2035 年,是桌面版 Linux 的一年(祈祷,这将是它!),IPv6 的广泛采用迫在眉睫,而 Amazon 刚刚购买了它没有拥有的最后一个 /8:。255.0.0.0/8

我们是怎么走到这一步的?

首先,我认为我们比 2035 年更接近这种情况,因为 Amazon 已经在内部使用 E 类地址,为什么不呢:

$ traceroute www.amazon.com
traceroute to e15316.dsca.akamaiedge.net (23.209.110.82), 64 hops max, 40 byte packets
 1  244.5.5.97 (244.5.5.97)  8.543 ms
    244.5.5.81 (244.5.5.81)  3.580 ms
    244.5.5.97 (244.5.5.97)  6.846 ms
 2  240.0.56.98 (240.0.56.98)  0.388 ms
    240.0.56.65 (240.0.56.65)  0.367 ms
    240.4.112.65 (240.4.112.65)  0.352 ms
 3  242.0.227.213 (242.0.227.213)  1.687 ms
    242.0.227.81 (242.0.227.81)  1.448 ms
    242.0.227.83 (242.0.227.83)  1.055 ms
 4  240.3.180.14 (240.3.180.14)  1.319 ms
    240.3.180.12 (240.3.180.12)  1.320 ms
    240.3.180.15 (240.3.180.15)  1.991 ms
[...]

当该网络块最终由 IANA 分配时,这将很有趣(例如,本草案中提议的1)和 Amazon 基本上会说“对不起,我们有 dibs。你不能指望我们重新编号所有 EC2,所以你还不如把整个 /4 给我们,kthanxbye。

(旁注:当然,它们的 IPv6 地址会做其他人做的事情,并将 IPv4 地址编码在其 v6 地址的底部字节中:

$ traceroute6 www.amazon.com
traceroute6: `www-amazon-com.customer.fastly.net' has multiple addresses; using `2606:2cc0::374'
traceroute6 to www-amazon-com.customer.fastly.net (2606:2cc0::374) from 2600:1f18:400c:b800:bdf1:6584:1971:4efe, 64 hops max, 12 byte packets
 1  2620:107:4000:2210:8000:0:f405:667  58.911 ms  # 244.5.102.7
    2620:107:4000:2210:8000:0:3ec:3e71  0.831 ms
    2620:107:4000:2210:8000:0:3ec:3e73  0.808 ms
 2  2620:107:4000:a792::f000:3841  0.419 ms        # 240.0.56.65
    2620:107:4000:a792::f000:3843  0.473 ms
    2620:107:4000:a792::f000:3842  0.4 ms
 3  2620:107:4000:cfff::f20c:2b01  17.258 ms       # 242.12.43.1
    2620:107:4000:cfff::f20c:2b81  12.562 ms
    2620:107:4000:cfff::f200:e353  2.026 ms
 4  2620:107:4000:c5c0::f3fd:1  1429.46 ms  1299.83 ms
    2620:107:4000:c5c0::f3fd:3  1368.37 ms
 5  2620:107:4000:cfff::f202:d4c3  2.15 ms
    2620:107:4000:cfff::f202:d545  1.931 ms
    2620:107:4000:cfff::f202:d445  1.358 ms
 6  2620:107:4000:8001::24  2.469 ms
    2620:107:4000:8001::44  10.271 ms
    2620:107:4000:8001::24  1.16 ms
[...]
$

这种做法对于戴着各种帽子的信息安全书来说非常有用,因为巨大的 IPv6 地址空间变得更加易于管理,通过这种方式,您可以收集有关目标的其他信息,所以谢谢你 – 但我跑题了。

总之,我想你明白我要说的是什么了:我们被告知,IANA 将 IP 空间分配给地区注册管理机构,他们进一步管理分配的网络块。一些早期采用者从 Jon Postel(最初的 IANA)那里得到了一份特别的礼物:他们自己的 /8。

在区域注册表级别,可用的 IP 空间没有均匀分配。如果我们去掉保留的 IP 空间(总共 35 /8,包括 E 类、组播和选定的其他网络块),只查看分配给不同区域互联网注册机构 (RIR) 的实际可用 IP 地址,那么我们会发现 ARIN 管理着超过 50% 的 IPv4 IP 空间,而 AFRINIC 只管理着 2.7%。相比之下,IPv6 地址空间的分配要均匀得多:

当然,当我们用完 IP 地址时,网络块被重新分配和重新分配,在区域注册表之间转移,公司开始交易网络块,如果你有一个备用的 /9 左右,这被证明是一个非常好的快速赚钱方式。

这样的例子有很多,例如谷歌在 2017 年从 Merit Networks 购买了 35.192.0.0/12,但让我们以亚马逊为例:

哦,在 2023 年,AWS 开始对公有 IPv4 地址的使用收费:0.005 USD/小时

但我开始这项研究基本上是因为我碰巧正在查看 AWS 发布的 ip-ranges 文件,我心想:“嗯,光是一家公司就有这么多 IP 地址。这甚至不是 Amazon 的全部,只是 AWS:

$ curl -s https://ip-ranges.amazonaws.com/ip-ranges.json | jq -r '.prefixes[].ip_prefix' | wc -l
    9180
$ curl -s https://ip-ranges.amazonaws.com/ip-ranges.json | \
    jq -r '.prefixes[].ip_prefix' | \
    awk -F/ '{ sum += 2^(32-$2) } END { printf("%'"'"'d\n", sum) }'
144,578,747
$

顺便说一句,如果你应用 Amazon 的逻辑,对每个 IP 地址每小时收取半美分的费用,那么那里的 CIDR 每年为 Amazon 提供 63 亿美元的净价值。不算太寒酸。

但是,看着 Amazon 在这里拥有的巨大股份,以及各种其他 netblock 交易、重新分配和重新分配,我在想:我们甚至知道谁拥有 IP 空间的哪些部分吗?我的意思是,当然,我们有点“知道”,因为这些信息是必须可用的……地方。但是我们如何看待这些数据呢?

现在,如果您自己恰好不是 RIR,您该如何查找这些信息呢?我们知道 CIDR 块分配在 中,虽然它非常简单,而且当你是人类时,输出真的很容易阅读,但试图大规模地使用数据做任何事情都会一团糟whoiswhoiswhois

“有些人在遇到问题时会想’我知道,我会用 whois。’现在他们遇到了非结构化的文本问题。

幸运的是,RIR 自己发布了统计数据,以有据可查的格式显示了他们在此处联合进行的 ASN、IPv4 和 IPv6 分配(或按 RIR 为 AFRINIC、ARIN、APNIC、RIPE NCC 和 LACNIC)。这些数据如下所示:

$ curl -s https://ftp.ripe.net/pub/stats/ripencc/nro-stats/latest/nro-delegated-stats | \
    grep "|ipv4|"
[...]
iana|ZZ|ipv4|0.0.0.0|16777216|19810901|reserved|ietf|iana
apnic|AU|ipv4|1.0.0.0|256|20110811|assigned|A91872ED|e-stats
apnic|CN|ipv4|1.0.1.0|256|20110414|assigned|A92E1062|e-stats
apnic|CN|ipv4|1.0.2.0|512|20110414|assigned|A92E1062|e-stats
apnic|AU|ipv4|1.0.4.0|1024|20110412|assigned|A9192210|e-stats
apnic|CN|ipv4|1.0.8.0|2048|20110412|assigned|A92319D5|e-stats
apnic|JP|ipv4|1.0.16.0|4096|20110412|assigned|A92D9378|e-stats
apnic|CN|ipv4|1.0.32.0|8192|20110412|assigned|A92319D5|e-stats
apnic|JP|ipv4|1.0.64.0|16384|20110412|assigned|A9252414|e-stats
apnic|TH|ipv4|1.0.128.0|32768|20110408|assigned|A91CF4FE|e-stats
[...]
$

这非常有用,但请注意,我们没有得到实际的 CIDR 分配 — 我们得到的是起始地址和 IP 地址计数。我们确实得到了国家/地区代码信息(是的!),但没有 AS 信息,也没有所有权数据。所以不完全是我们正在寻找的。

但是,嘿 – 我们记得因为 whois 很愚蠢,互联网已经同意使用 RDAP 来代替了?那会很整洁!RDAP 是 RESTful 的!这是 JSON!它在 RFC 中指定(这么多很多很多很多 RFC),甚至还有真正有用的文档

$ curl -s -L https://rdap.db.ripe.net/ip/2.19.4.0
{
  "handle" : "2.19.0.0 - 2.19.15.255",
  "startAddress" : "2.19.0.0",
  "endAddress" : "2.19.15.255",
  "ipVersion" : "v4",
  "name" : "AKAMAI-PA",
  "type" : "ASSIGNED PA",
  "country" : "EU",
  "parentHandle" : "2.16.0.0 - 2.23.255.255",
  "cidr0_cidrs" : [ {
    "v4prefix" : "2.19.0.0",
    "length" : 20
  } ],
  "status" : [ "active" ],
  "entities" : [ {
    "handle" : "AKAM1-RIPE-MNT",
[...]

这看起来非常有用,但当然,最后我使用了所有这些交叉事实来源的组合:我只是从 开始,查找 RDAP 信息,提取 ,确定紧随其后的地址,然后重复 RDAP 查找,以这种方式迭代整个 IPv4 空间。0.0.0.0endAddress2然后,我对 Team Cymru 的 IP 到 ASN 服务执行了 DNS 查找,并使用通常的 Perl、 和 shell 胶水大杂烩,将所有这些数据与已发布的 RIR 统计数据进行交叉引用。awk(1)

现在,使用多个事实来源的问题是 — 正如任何曾经尝试过创建、使用或与之交互的人(例如资产清单)所告诉您的那样 — 您充其量只能获得所有不同来源的交叉视图。还有 bug。

“whois 很愚蠢*,请使用 RDAP。那会很棒!…他们说

使用标准化协议从互联网上的不同来源收集大量数据的有趣之处在于,它如何破坏您对标准化协议的信念,同时让您对遇到的所有边缘情况感到困惑。

RDAP 有很多优点,但该服务由五个以上的主要方(RIR 加上各种区域 NIC)运行,我发现了许多错误和问题:

  • 带和不带负载正文的 HTTP 重定向
  • 在 RIR 之间重定向循环3
  • RDAP IP 查询结果不包括 AS 编号(有时包含)whois
  • AFRINIC 有 API 限制,但不会告诉您它们是什么
  • 超过未知 API 限制时,AFRINIC 返回 429 状态代码 (yay),但没有 Retry-After 标头 (boo)
  • https://rdap.registro.br/会告诉你他们的 API 限制是每 20 秒 1 个请求;如果你超过它,那就是 403 Forbidden – 再见!(是时候轮换源地址了…
  • AFRINIC 有时会返回 -1 的网络掩码(例如196.28.253.0/22)
  • endAddressCIDR0_CIDRS4
  • ARIN 和 LACNIC 在 RDAP 中不包含国家/地区代码信息
  • JPNIC 不包含分配类型,实际上是将其设置为null

所以是的……

RDAP:与 “” 相同 GIGO,但至少它是 JSON。

whois

按国家/地区代码划分的 IPv4 分配

在收集并关联所有数据后,我最终得到了大约 300K 的信息5近 240 个国家/地区的 CIDR 分配。6CIDR 分配计数排名前 10 的国家/地区7是:

  1. 🇷🇺 俄罗斯(> 17K 分配)
  2. 🇩🇪 德国 (12.5K)
  3. 🇧🇷 巴西 (12.1K)
  4. 🇬🇧 英国 (11.8K)
  5. 🇮🇳 印度 (9.4K)
  6. 🇨🇳 中国 (9.3K)
  7. 🇦🇺 澳大利亚 (7.2K)
  8. 🇳🇱 荷兰 (7.2K)
  9. 🇯🇵 日本 (7.1K)
  10. 🇺🇸 美国 (6.5K)

但并非所有 CIDR 都是相等的 – 分配了数百个 /24 并不能弥补分配一个 /8。也许计算 IP 地址可能会更好?我们可以轻松地将这些数字相加,然后将它们与 IPv4 地址空间的总量进行比较:

  1. 🇺🇸 美国(1.61B 个 IP,占所有 IPv4 的 43.8%)
  2. 🇨🇳 中国 (343.17M, 9.3%)
  3. 🇯🇵 日本 (189.81M, 5.1%)
  4. 🇬🇧 英国 (127.41M, 3.5%)
  5. 🇩🇪 德国 (124.21M, 3.4%)
  6. 🇰🇷 韩国 (112.5M, 3.1%)
  7. 🇧🇷 巴西 (87.14M, 2.4%)
  8. 🇫🇷 法国 (82.18M, 2.2%)
  9. 🇨🇦 加拿大 (68.52M, 1.9%)
  10. 🇮🇹 意大利 (54.03M, 1.5%)

这里突出的当然是分配给美国的大量 IP 地址,以及美国和中国合计占 50% 以上的事实,是整个 IPv4 地址空间 75% 以上的前十个国家。

按国家/地区代码划分的 IPv6 分配

对于 IPv6 分配,我的数据仅基于 RIR 统计数据。总的来说,那里的信息没那么有趣,仅仅是因为 IP 空间如此之大,以至于集中化真的不是问题。为了完整起见,我在此处列出了 IPv6 的发现:

有趣的是,显然,中非共和国、厄立特里亚和朝鲜(以及南极洲、福克兰群岛、法属南部和南极地区、科索沃、斯瓦尔巴群岛和扬马延岛以及西撒哈拉)都没有 IPv6 分配。

按 RIR 分配的 IPv4

非洲人

如果我们从区域注册管理机构的角度来看,我们会注意到 AFRINIC 覆盖的不仅仅是非洲,尽管 AFRINIC 的前十名分配(占其所有分配的 80% 以上)都位于非洲大陆。嗯,除了香港:

这里需要注意的一点是,RIR 统计数据仅确定了 AFRINIC 向其分配 IP 块的 54 个国家/地区,但从 RDAP 收集的数据暗示了更广泛的传播。这表明这里正在进行相当活跃的 CIDR 区块交易。

另一个惊喜(至少对我来说)是向毛里求斯这个相对较小的国家进行了大量拨款。通常,我预计分配与人口大致成正比,尽管一个国家的经济权重在这里起着更大的作用:至少在 2014 年,毛里求斯在非洲排名第三。但话又说回来,AFRINIC 的总部设在毛里求斯……啊啊。

APNIC 的

毫不奇怪,APNIC 将中国列为拥有 IP 地址最多的国家/地区,其次是日本和韩国,前十名中的其他国家至少都在亚洲,尽管它们再次高度集中:中国、日本和韩国几乎占 APNIC 分配的所有 IP 地址的 75%:

阿林

ARIN 在此处分配的 IP 地址的地理分布仅来自 RIR 统计数据,因为 ARIN 提供的 RDAP 数据不包括国家/地区代码。与其他 RIR 一样,我们看到的分配远远超出了其假定的地理区域,当然,不出所料,主要的异常值是美国,占 ARIN 所有分配的 95% 以上:

  1. 🇺🇸 美国(1.59B 个IP,95.4% 的 ARIN,~37% 的所有 IP)
  2. 🇨🇦 加拿大 (68.2M, 4.1%)
  3. 🇵🇷 波多黎各 (757K)
  4. 🇨🇿 捷克共和国 (395K)
  5. 🇯🇲 牙买加 (222K)
  6. 🇧🇧 巴巴多斯 (168K)
  7. 🇧🇸 巴哈马 (138K)
  8. 🇬🇧 英国 (136K)
  9. 🇻🇮 美属维京群岛 (118K)
  10. 🇧🇲 百慕大 (108K)

LACNIC

与 ARIN 一样,LACNIC 的 RDAP 服务不提供国家/地区代码(尽管提供),因此此处的统计数据同样仅基于 RIR 统计数据:nic.br

  1. 🇧🇷 巴西(87.14M 个 IP,占 LACNIC 的 45.8%)
  2. 🇲🇽 墨西哥 (29.02M, 15.3%)
  3. 🇦🇷 阿根廷 (19.46M, 10.2%)
  4. 🇨🇴 哥伦比亚 (17.37M, 9.1%)
  5. 🇨🇱 智利 (10.03M, 5.3%)
  6. 🇻🇪 委内瑞拉 (6.71M, 3.5%)
  7. 🇵🇪 秘鲁 (3.24M, 1.7%)
  8. 🇪🇨 厄瓜多尔 (2.71M, 1.4%)
  9. 🇺🇾 乌拉圭 (2.44M, 1.3%)
  10. 🇨🇷 哥斯达黎加 (2.34M, 1.2%)

请注意,LACNIC 似乎是受区域限制最严格的注册机构,如果您愿意的话,它几乎保持在指定的边界内。也就是说,其他 RIR 向 LACNIC 进行的 IP 区块交易似乎较少。

成熟的 NCC

现在,我们冗余的欧洲 IP 网络协调中心是具有最广泛全球影响力的 RIR,负责全球 164 个国家/地区的分配:

  1. 🇩🇪 德国(130.75M IP,占 RIPE NCC 的 15.2%)
  2. 🇬🇧 英国 (130.48M, 15.2%)
  3. 🇫🇷 法国 (87.03M, 10.1%)
  4. 🇮🇹 意大利 (56.69M, 6.6%)
  5. 🇳🇱 荷兰 (48.7M, 5.7%)
  6. 🇷🇺 俄罗斯 (47.29M, 5.5%)
  7. 🇪🇸 西班牙 (33.9M, 3.9%)
  8. 🇸🇪 瑞典 (28.93M, 3.4%)
  9. 🇨🇭 瑞士 (25.2M, 2.9%)
  10. 🇵🇱 波兰 (20.35M, 2.4%)

按分配类型划分的分配

我查看的另一件事是不同 RIR 分配了哪些类型的网络块。此信息可在 RDAP 响应中找到,请记住,RDAP 很棒,因为它定义明确!例如,RFC9083 告诉我们:

type – 一个字符串,其中包含根据该 RIR 的注册模型对网络进行的特定 RIR 分类

哦,天哪,一根绳子。井。是的。因此,不同的 RIR 选择定义不同的字符串也就不足为奇了:

例如,请参阅 APNIC 对不同分配类型的解释;通常,“PA”代表“提供商可聚合”,而“PI”代表“独立于提供商”。

按类型划分的所有 22 个不同分配的完整分布如下所示:

这些数据有一个警告:JPNIC 的 RDAP 结果始终将“Allocation Type”字段设置为 。但是,让我们按 RIR 比较这些分配。null

为了帮助我们回答谁拥有 CIDR 的问题,将本地注册管理机构的分配与最终用户的分配分开可能是有意义的。遗憾的是,不同的 RIR 对这些 RIR 使用不同的类型(在上面的每张图片中以红色圈出),但实际上这是一个很难区分的地区。

例如,ARIN 的“DIRECT ALLOCATION”应该用于本地注册管理机构和 ISP/电信公司,但尚不清楚例如,可能为其 ATM 网络重新分配净块的银行是否被视为本地注册管理机构;就我们在这里的目的而言,他们是同一个所有者。哦,当然,RIPE NCC 的“传统”分配可能是也可能不是最终用户分配。谁知道呢。

分配大小

接下来,我查看了分配的 net blocks 有多大。我发现了 25 种不同的 CIDR 大小,其中 ~5K 分配为 /n < /16,~7.2K 分配为 /n > /24。大多数是 /24s、/22s 和 /23s,但当然还有 23 个 /8s、11 个 /9s,以及光谱两端不可忽略的异常值:

数据科学书告诉我,饼图很糟糕,所以下面是相同数据的帕累托图:

让我有点惊讶的是 /32 分配的显著数量 (1,387),但除此之外,/24 分配是迄今为止最常见的分配,这也反映在所有 RIR 的分配中——除了 LACNIC,它似乎更偏爱 /22。(您可以在此处查看每个 RIR 的帕累托图: AFRINIC、APNIC、ARIN、LACNIC、RIPE NCC

为了方便起见,我还检查了 IPv6 分配大小(70 种不同的分配大小;22 个 CIDR /n < /32(252K 个分配),18 个 CIDR /n > /48(572 个分配),9 个 CIDR /n > /100(22 个分配)),其中 /24 也是最受欢迎的一个。当然,在 IPv6 中,/24 大约是 2 个十分 IP 地址,而不是 256 个,但没关系。

按网络名称划分

但我仍在寻找网络区块的实际所有者名称。RDAP(很像 )使用“网络名”标识子网,因此我们可以按分配频率以及分配给给定网络名的 IP 地址总数来计算这些子网。whois

每个 “网络名称” 可能与大量不同的自治系统 (AS) 编号相关联,而 “网络名称” 当然不一定具有很强的描述性或揭示性:要尝试将这些名称映射到实际的组织名称,您需要相当多的人为关联。

此外,有时您需要知道(或推断)不同的实体实际上是同一个实体:“Amazon Technologies Inc.”和“Amazon.com Inc.”显然是相关的,但被确定为“Level 3 Parent LLC”和“Century Link Communications”拥有的网络具有相同的父所有者(在本例中为 Lumen Technologies, Inc.)这一事实远非明显。8

按 AS 编号划分的分配

尝试通过将 IP 地址与 AS 编号相关联来映射数据(如上所述,主要通过 Team Cymru 的 IP 到 ASN 服务),我发现了大约 63K 个不同的 AS 编号:

(是的,这张图中突出显示的“斯塔克工业”是布赖恩·克雷布斯最近在不同的上下文中讨论的那个。我之所以提到它,只是因为它让我觉得这是一个非常科技兄弟的名字。

但观察到的 AS 频率是一个因素。如果我们统计给定 CIDR 的 IP 地址并按 AS 映射这些地址,则会出现不同的视图:

换句话说,我们发现自己是触摸大象的盲人之一——我们从不同的侧面得到不同的观点,却没有真正得到完整的视角。尝试将 AS 编号和网络名称组合在一起并手动将它们与实体相关联,我得出了拥有最多 IP 地址的顶级组织的粗略分布,这些地址占所有 IP 空间的很大一部分,并且至少在一定程度上回答了我们最初的问题。前十名(无论如何,按这个计数计算)是:

  1. 美国国防部(352M 个 IP 地址,占所有 IPv4 地址的 8.19%)
  2. 亚马逊(181M,4.21%)
  3. 中国电信 (112M, 2.61%)
  4. AT&T (111M, 2.59%)
  5. Verizon (101M,2.35%)
  6. 康卡斯特 (71M, 1.64%)
  7. Lumen Technologies (65M, 1.52%)
  8. Microsoft(59M,1.37%)
  9. 软银 (48M, 1.1%)
  10. 韩国电信 (46M, 1.08%)

这里需要指出的一点(除了 DoD 是一个明显的异类)是只有两家公司不是电信提供商:Amazon 和 Microsoft。所有其他公司实际上是 ISP 和 Telco。

总结

嗯,这是很多数据,都呈现出略有不同的观点。这些数据是否回答了我们关于谁拥有哪些 CIDR 的主要问题?只是在某种程度上,真的。整个练习有点令人沮丧,但以下是一些结论性发现:

首先,区分 “最终用户” 和 LIR 真的很难。Amazon 是否是 LIR,因为不同的客户通过 AWS 使用他们的 IP 空间?

我们还发现不同的 RIR 定义存在很多不一致之处,这使得数据难以关联,并且 RDAP 中的一些数据在单个 RIR 内不一致、有缺陷或不完整。我已经向不同的 RIR 报告了一些发现;一些发现已经得到解决,但总的来说,我认为这是一个有很大改进空间的领域。

另一件让我有点惊讶的事情是,区域互联网注册管理机构似乎比您想象的要少得多,因为区块被交易、转让或分配给其所在地区以外的实体。

但总的来说,根据我所看到的,看起来大约 30% 的 IP 地址只由少数组织管理,当然,国防部仍然拥有其中的大部分9

我们已经看到,除了 ISP/电信公司或 LIR(对他们来说拥有大部分 IP 空间似乎是合理的)之外,前十名中只有两家大型互联网公司。这两家公司也恰好控制着互联网或行业和市场的其他方面,这再次暗示了中心化的趋势。

最后,对 IPv6 进行相同的练习就没那么有趣了。它太多了,以至于交易 netblocks 等的考虑因素并不那么相关。IPv6 很无聊。这是一件好事。我真的很喜欢无聊 – 我们应该做更多这样的事。甚至可能在 2035 年之前。