使用 hping 时报错的处理

Linux中使用Nmap , hping, ping 提示以下错误时

PHP: [main]	can't	open	raw	socket

Bash: Couldn’t open a raw socket. Error: Permission denied (13)

非root进程调用带有网络原始套接字(raw socket) 的相关命令时,会报错,需要使用getcap 设置 capabilities

(具体参考:https://cloud.tencent.com/developer/article/1539041)

# 以 ping 为例,先 which 查看命令地址
which ping

# 如无返回就是没有设置cap
getcap /usr/bin/ping

# 设置cap
sudo setcap cap_net_raw+ep /usr/bin/ping

# 再次getcap 已有设置值
getcap /usr/bin/ping
#/usr/bin/ping cap_net_raw=ep

setcap 之后问题就解决了。

到底是谁的 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 年之前。

又一些域名

logo

大部分都是在 freenom.com 注册的 free doamin.   那个 zao.li 是帮朋友拿的.

.TK 的注册系统其实是和freenom是共同的注册后台, 只是确认(confirm)验证方式不同.  有同一邮箱注册会出现收不到验证码的情况.

example.cf

in-addr.ga

invalid.cf

invalid.ga

keyword.cf

zao.li

了解 URI, URL, and URN

url-300x197

  • URI:Uniform Resource Identifier,统一资源标识符;(RFC 3986)
  • URL:Uniform Resource Locator,统一资源定位符;(RFC 1738
  • URN:Uniform Resource Name,统一资源名称。(RFC 1737

URI可被视为定位符(URL),名称(URN)或两者兼备。统一资源名(URN)如同一个人的名称,而统一资源定位符(URL)代表一个人的住址。换言之,URN定义某事物的身份,而URL提供查找该事物的方法。

用于标识唯一书目的ISBN系统是一个典型的 URN 使用范例。例如,ISBN 0-486-27557-4(urn:isbn:0-486-27557-4)无二义性地标识出莎士比亚的戏剧《罗密欧与朱丽叶》的某一特定版本。

为获得该资源并阅读该书,人们需要它的位置,也就是一个 URL 地址。在类Unix操作系统中,一个典型的URL地址可能是一个文件目录,例如file:///home/username/RomeoAndJuliet.pdf。该URL标识出存储于本地硬盘中的电子书文件。因此,URL和URN有着互补的作用。

URL方案分类图。URL(定位符)和URN(名称)方案属于URI的子类,URI可以为URL或URN两者之一或同时是URI和URN。技术上讲,URL和URN属于资源ID;但是,人们往往无法将某种方案归类于两者中的某一个:所有的URI都可被作为名称看待,而某些方案同时体现了两者中的不同部分。


URI 标准

RFC3986,即“Uniform Resource Identifier (URI):Generic Syntax”,是一个 Internet Standard。 Request for Comments (RFC) 系列是著名的档案式文档系列,该系列构成了 Internet Engineering Task Force (IETF) 标准过程的主干。 在数以千计的 RFC 中,只有很少的部分,比如   TCP (RFC793) 以及 Internet Mail 格式 (RFC821) 和协议 (RFC822), 提高了整个 Internet Standard 的发展水平。 RFC3986 在  2005 年 1 月也提高了这个水平。

按照 URI 标准,上面的第一个例子 —— http://www.cisco.com/en/US/partners/index.html —— 实际上是一个 URI,并且它由以下几个组成部分:

th

  • 方案名 (http)

url(uniformresourcelocator)

  • 域名 (www.cisco.com)
  • 路径 (/en/US/partners/index.html)

thCA1OQ0FA

IETF 达成共识,共同管理该方案。Official IANA Registry of URI Schemes(请参阅 参考资料)中包括一些大家所熟悉的方案,如 httphttpsmailto,还有其他许多您可能熟悉或不熟悉的方案。

URI 路径像一个典型的文件路径名。URI 按照 UNIX® 的惯例采用了正下划线 (a/b/c),因为在 20 世纪 80 年代后期设计 URI 的时候, 在 Internet 上, UNIX 文化比 PC 文化更流行。正是那个时候,出现了几个用于访问远程文件的流行表示法。其中一个是 Ange-ftp, 它是用来编辑远程文件的 emacs 的一个扩展。它用路径名将主机名和用户名结合起来,以获取像/jbrown@freddie.ucla.edu:~mblack/这样的结果。为了跨机器进行命名,为 Web 开发的 URI 语法(按照非标准的 Apollo Domain UNIX)使用了双下划线符号,但是它也引入了方案语法,这样,来自许多不同协议的命名约定得到了统一。其中的一些例子有:

  • mailto:mbox@domain
  • ftp://host/file
  • http://domain/path

这里介绍的第二个例子是 www.yahoo.com/sports,它不是一个真正的 URI。 它是对 http://www.yahoo.com/sports 的一种方便的简写,是一种受流行的 Web 浏览器用户界面  (UI) 支持的格式。然而,不要再犯在 XSLT 中遗漏方案这样的错误,如下所示:

<xsl:include href="exslt.org/math/min/math.min.template.xsl" />

因为它将不会按照您期望的那样工作,除非您真的 在 XSLT 样式表之后引用 exslt.org 目录中的一个文件。XSLT 的 href 属性采用了一个 URI 引用,它可能是绝对引用,也可能是相对引用。以一个方案和一个冒号开始的 URI 引用是绝对引用;否则,该引用就是相对引用。相对的 URI 引用更像一个文件路径。例如,../noarch/config.xsd 也是一个相对的 URI 引用。

国际化的资源标志符

HTML 中的 href 属性采用了 URI 引用,这样讲有些过于简单。URI 和 URI 引用都是从有限的 ASCII 字符集合中得出的,并且 HTML 比它们更加国际化。事实上,对遵循 RFC3986 的注释的请求是符合 RFC3987 标准,即 Internationalized Resource Identifiers (IRI) 标准(请参阅 参考资料)。此规范在 IETF 标准化过程中没有它的前辈走的远,但是技术本身已是相当成熟,并被广泛部署。除了能够使用所有 Unicode 字符,而不是仅仅能够使用 ASCII 字符之外,IRI 和 URI 是完全一样的。像 URI一样,每个 IRI 都有一个相应的编码,以防需要在只接受 URI 的协议(比如 HTTP)中使用 IRI。

用 xml:base 重写基本 URI

通常, URI 引用与在哪种文档中发现它有关。如果使用基本 URI http://exslt.org/math/min/math.min.template.xsl 查看一个文档,并看到了一个 URI 引用 ../../random/random.xml,那么引用将扩展为 http://exslt.org/random/random.xml。在 HTML 中,您可以把一个 base 元素放在文档顶端来重写基本 URI。XML Base 规范(请参阅 参考资料)在 XML 中也提供了同样的功能。

考虑一个既可以用 file:/my/doc 访问也可以用 http://my.domain/doc 访问的文档。通常,当通过文件系统访问文档时,您可能希望这些引用像 #part2 那样扩展为 file:/my/doc#part2;而通过 HTTP 访问文档时,您可能希望 #part2 扩展为 http://my.domain/doc#part2。但是在 Resource Description Framework (RDF) 模式中,为了使一些组件正常工作,展开的形式必须保持不变。 XML Base 使这种扩展变得容易(参见清单 1)。

清单 1. RDF 中的展开形式

				
<rdf:RDF
  xmlns="&owl;"
  xmlns:owl="&owl;"
  xml:base="http://www.w3.org/2002/07/owl"
  xmlns:rdf="&rdf;"
  xmlns:rdfs="&rdfs;"
>
...
    <Class rdf:about="#Nothing"/>

在这个例子中,无论您是在哪里找到的那个文件,#Nothing 引用均被扩展为 http://www.w3.org/2002/07/owl#Nothing

好了,关于 URI、IRI 和 URI 引用的介绍就到此结束了。

URL 和 URN

设计 URI 的目的是让它起到名称和定位器的作用。当 IETF 用它们实现标准化的时候,它们就成了通常所说的 Uniform Resource Locators,并且另一项关于 Uniform Resource Names 的独立的工作也已经开始了。

对于 Internet 主机,名称和位置都有单独的标准。主机名和域名有相同的语法(例如,zork1.example.edu)。这些主机名通过 Domain Name System (DNS) 协议和类似 192.168.300.21 的地址相连。当主机改变了在网络中的位置或重新编号之后,这种间接的做法允许主机保留其名称。

Web 中偶尔中断的链接使 Web 地址从外观上看更像是一个位置,而不是一个名称,并且在 IEIF 社区中也出现了不同的观点:

  • URI:RFC1630,发布于 1994 年 6 月,被称为“Universal Resource Identifiers in WWW: A Unifying Syntax for the Expression of Names and Addresses of Objects on the Network as used in the World-Wide Web”(请参阅 参考资料)。它是一个Informational RFC  —— 也就是说,它没有获得社区的任何认可。
  • URL:RFC1738,发布于 1994 年 12 月, 被称为“Uniform Resource Locators”(请参阅 参考资料)。它是一个 Proposed Standard —— 也就是说,它是一个共识过程的结果,虽然它还没有经过测试,并成熟到足以成为一个完整的 Internet Standard。
  • URN:RFC1737,发布于 1994 年 12 月,被称为“Functional Requirements for Uniform Resource Names”(请参阅 参考资料)。

1997 年,紧随 Proposed Standard RFC2141(即 URN Syntax)之后发布了 RFC1737,它指定了另一个方案 —— urn: —— 来加入 http:ftp:和其他协议中。

最终的 URI Standard (RFC3986) 在 1.1.3 小节“URI, URL, and URN”中澄清了这一区别:

URI 可以进一步分为定位器、名称,或者二者兼具。术语“Uniform Resource Locator” (URL) 涉及的是 URI 的子集,除识别资源外,它还通过描述其最初访问机制(比如它的网络“位置”)来提供定位资源的方法。 术语“Uniform Resource Name” (URN) 在历史上曾用于引用“urn”方案 [RFC2141] 下的 URI,这个 URI 需要是全球惟一的,并且在资源不存在或不再可用时依然保持不变,对于其他任何拥有名称的一些属性的 URI,都需要使用这样的 URI。

对于单独的方案,没有必要将其分为仅仅是一个 “名称”或者是一个“定位器”。 来自任意特定方案的 URI 实例可能有名称或定位器的特征,或两者兼而有之, 这通常取决于标识符分配中的持久性和命名机构对其关注程度, 而不取决于其他方案的质量。未来的规范和相关的文档应当使用通用术语“URI”,而不是使用有更多限制的条目“URL”和“URN” [RFC3305]。

http://www.ibm.com/developerworks/cn/xml/x-urlni.html

 

附录(梳理归类):

其中,URL,URN是URI的子集,其区别如下: Web上地址的基本形式是URI,它代表统一资源标识符,有两种形式: URL:目前URI的最普遍形式就是无处不在的URL或统一资源定位器。 URN:URL的一种更新形式,统一资源名称(URN, Uniform Resource Name)不依赖于位置,并且有可能减少失效连接的个数。但是其流行还需假以时日,因为它需要更精密软件的支持。

参考:http://www.cnlei.org/blog/article.asp?id=356

URN 站点 : http://purl.org/ | http://www.doi.org/demos.html

 

[文章部分内容引用地址] :

http://blog.sina.com.cn/s/blog_5c4a1a800100gxke.html

[分清 URI、URL 和 URN] http://www.ibm.com/developerworks/cn/xml/x-urlni.html

 

P.S. :  http://,https://,mms://,ftp://,rtsp://,ssl://,sftp://,pnm://,rtmp://等协议, 又如 thunder迅雷 , flashget快车 &&QQ旋风等.

thunder://类似的协议是base64编码加密。

 

Special-Use Domain Names

  • Created

2012-07-06

  • Last Updated

2013-02-21

Special-Use Domain Names

Registration Procedure(s)
Standards Action and IESG Approval
Reference
[RFC6761]
Note
The "Special Use" designation applies to both the listed domains and their subdomains.
Alternative Formats
CSV      Plain text
Name Reference
10.in-addr.arpa. [RFC6761]
16.172.in-addr.arpa. [RFC6761]
17.172.in-addr.arpa. [RFC6761]
18.172.in-addr.arpa. [RFC6761]
19.172.in-addr.arpa. [RFC6761]
20.172.in-addr.arpa. [RFC6761]
21.172.in-addr.arpa. [RFC6761]
22.172.in-addr.arpa. [RFC6761]
23.172.in-addr.arpa. [RFC6761]
24.172.in-addr.arpa. [RFC6761]
25.172.in-addr.arpa. [RFC6761]
26.172.in-addr.arpa. [RFC6761]
27.172.in-addr.arpa. [RFC6761]
28.172.in-addr.arpa. [RFC6761]
29.172.in-addr.arpa. [RFC6761]
30.172.in-addr.arpa. [RFC6761]
31.172.in-addr.arpa. [RFC6761]
168.192.in-addr.arpa. [RFC6761]
254.169.in-addr.arpa. [RFC6762]
8.e.f.ip6.arpa. [RFC6762]
9.e.f.ip6.arpa. [RFC6762]
a.e.f.ip6.arpa. [RFC6762]
b.e.f.ip6.arpa. [RFC6762]
example. [RFC6761]
example.com. [RFC6761]
example.net. [RFC6761]
example.org. [RFC6761]
invalid. [RFC6761]
local. [RFC6762]
localhost. [RFC6761]
test. [RFC6761]

域名注册信息查询工具 Net Info Tools

发布我自用的一个域名注册信息查询工具。 功能主要集中在域名WHOIS方面。

A Tools for Domain/IP Whois, HTTP Scan, Route trace, root servers Monitoring, QQWry IPLocate. :)p
一个多功能的域名工具. 可以whois域名/IP, 扫描http头信息, 路由追踪, 服务器状态, 调用QQWry查询ip归属. (最新版本 几乎支持所有域名后缀的可注册状态查询, 需要服务端接口支持, 暂不公开发布

下载:(可下载使用的版本

域名 和 IP地址的 WHOIS信息查询

1

WHOIS域名,查询域名相关注册信息,还可转至映射(Referral)的域名管理商WHOIS服务器查询更详细的注册信息。

IP WHOIS 查询IP地址所在的NIC归属,以及AS地址编码等相关分配所有信息。

2

HTTP Scan

扫描获取相关IP地址的WEB服务器HTTP 头信息, 可查询一个C类地址段。

22

IP Info

目前有3个功能, 简单路由追踪,Root跟服务器状态监视,ipv4地址分配表。

33

QQWty

如同其名,调用 纯真网络?的QQWty.dat 查询IP归属地。QQWty可以从 “纯真网络?->?金狐软件 获取。

44

Tools

域名注册及查询相关工具。 包括WHOIS服务器验证,以及域名列表生产器,可以根据各种域名后缀TDL, 进行组合成。

55

.CN Delete

到期删除的.CN域名和中文域名列表,可以查询最近3天的域名删除列表。 支持按后缀类型,长度进行筛选过滤。

66

Bulk

域名注册可用状态的批量查询。 支持从文件选择打开。

可配合上面Tools中的域名组合生成器,方便进行批量可用域名的检测,也可对所需域名进行全后缀的检测,适合玩米的人士。目前几乎支持世界上全部域名后缀的查询。 (P.S. 此功能需要服务器接口支持。由于目前性能及缺少可用服务器,暂不对外开放使用。)

77

TLDs Server

根据 IANA?所使用的 ISO 3166-1 自动检测查询各个 通用顶级域名(gTLD)和 国家顶级域名(ccTLD)? 的WHOIS服务器和注册地址,方便玩米的朋友注册,了解各域名的注册机开放信息。

88

关于

下图显示的是目前开发的最新版本,非可下载使用版本。 (?下载:可下载使用的版本

0

个人使用工具,难免问题众多。有建议和问题欢迎回复及谈论。

在考虑后续增加的一些功能:域名价格列表,在线注册,抢注和会员账号等。。。

文件大小换算

1 Mio file = 1 mebioctet* = 220 octets = 1,024 Kio = 1,048,576 octets
10 Mio file = 10 mebioctet = 10 x 220 octets = 10,240 Kio = 10,485,760 octets
100 Mio file = 100 mebioctet = 100 x 220 octets = 102,400 Kio = 104,857,600 octets
1 Gio file = 1 gibioctet = 230 octets = 1,024 Mio = 1,073,741,824 octets
10 Gio file = 10 gibioctet = 10 x 230 octets = 10,240 Mio = 10,737,418,240 octets

1 Mbit file = 1 megabit = 106 bits = 1,000 kbit = 1,000,000 bits
10 Mbit file = 10 megabit = 107 bits = 10,000 kbit = 10,000,000 bits
100 Mbit file = 100 megabit = 108 bits = 100,000 kbit = 100,000,000 bits
1 Gbit file = 1 gigabit = 109 bits = 1,000 Mbit = 1,000,000,000 bits
10 Gbit file = 10 gigabit = 1010 bits = 10,000 Mbit = 10,000,000,000 bits

 

IANA IPv4 地址空间注册表

IANA IPv4 Address Space Registry

Last Updated
2013-03-22
Description
The allocation of Internet Protocol version 4 (IPv4) address space to various registries is listed
here. Originally, all the IPv4 address spaces was managed directly by the IANA. Later parts of the
address space were allocated to various other registries to manage for particular purposes or
regional areas of the world. RFC 1466 [RFC1466] documents most of these allocations.

This registry is also available in plain text.

Prefix Designation Date Whois Status [1] Note
000/8 IANA – Local Identification 1981-09 RESERVED [2]
001/8 APNIC 2010-01 whois.apnic.net ALLOCATED
002/8 RIPE NCC 2009-09 whois.ripe.net ALLOCATED
003/8 General Electric Company 1994-05 LEGACY
004/8 Level 3 Communications, Inc. 1992-12 LEGACY
005/8 RIPE NCC 2010-11 whois.ripe.net ALLOCATED
006/8 Army Information Systems Center 1994-02 LEGACY
007/8 Administered by ARIN 1995-04 whois.arin.net LEGACY
008/8 Level 3 Communications, Inc. 1992-12 LEGACY
009/8 IBM 1992-08 LEGACY
010/8 IANA – Private Use 1995-06 RESERVED [3]
011/8 DoD Intel Information Systems 1993-05 LEGACY
012/8 AT&T Bell Laboratories 1995-06 LEGACY
013/8 Xerox Corporation 1991-09 LEGACY
014/8 APNIC 2010-04 whois.apnic.net ALLOCATED [4]
015/8 Hewlett-Packard Company 1994-07 LEGACY
016/8 Digital Equipment Corporation 1994-11 LEGACY
017/8 Apple Computer Inc. 1992-07 LEGACY
018/8 MIT 1994-01 LEGACY
019/8 Ford Motor Company 1995-05 LEGACY
020/8 Computer Sciences Corporation 1994-10 LEGACY
021/8 DDN-RVN 1991-07 LEGACY
022/8 Defense Information Systems Agency 1993-05 LEGACY
023/8 ARIN 2010-11 whois.arin.net ALLOCATED
024/8 ARIN 2001-05 whois.arin.net ALLOCATED
025/8 UK Ministry of Defence 1995-01 whois.ripe.net LEGACY
026/8 Defense Information Systems Agency 1995-05 LEGACY
027/8 APNIC 2010-01 whois.apnic.net ALLOCATED
028/8 DSI-North 1992-07 LEGACY
029/8 Defense Information Systems Agency 1991-07 LEGACY
030/8 Defense Information Systems Agency 1991-07 LEGACY
031/8 RIPE NCC 2010-05 whois.ripe.net ALLOCATED
032/8 AT&T Global Network Services 1994-06 LEGACY
033/8 DLA Systems Automation Center 1991-01 LEGACY
034/8 Halliburton Company 1993-03 LEGACY
035/8 Administered by ARIN 1994-04 whois.arin.net LEGACY
036/8 APNIC 2010-10 whois.apnic.net ALLOCATED
037/8 RIPE NCC 2010-11 whois.ripe.net ALLOCATED
038/8 PSINet, Inc. 1994-09 LEGACY
039/8 APNIC 2011-01 whois.apnic.net ALLOCATED
040/8 Administered by ARIN 1994-06 whois.arin.net LEGACY
041/8 AFRINIC 2005-04 whois.afrinic.net ALLOCATED
042/8 APNIC 2010-10 whois.apnic.net ALLOCATED
043/8 Administered by APNIC 1991-01 whois.apnic.net LEGACY
044/8 Amateur Radio Digital Communications 1992-07 LEGACY
045/8 Administered by ARIN 1995-01 whois.arin.net LEGACY
046/8 RIPE NCC 2009-09 whois.ripe.net ALLOCATED
047/8 Administered by ARIN 1991-01 whois.arin.net LEGACY
048/8 Prudential Securities Inc. 1995-05 LEGACY
049/8 APNIC 2010-08 whois.apnic.net ALLOCATED
050/8 ARIN 2010-02 whois.arin.net ALLOCATED
051/8 UK Government Department for Work and Pensions 1994-08 whois.ripe.net LEGACY
052/8 E.I. duPont de Nemours and Co., Inc. 1991-12 LEGACY
053/8 Cap Debis CCS 1993-10 LEGACY
054/8 Administered by ARIN 1992-03 whois.arin.net LEGACY
055/8 DoD Network Information Center 1995-04 LEGACY
056/8 US Postal Service 1994-06 LEGACY
057/8 SITA 1995-05 LEGACY
058/8 APNIC 2004-04 whois.apnic.net ALLOCATED
059/8 APNIC 2004-04 whois.apnic.net ALLOCATED
060/8 APNIC 2003-04 whois.apnic.net ALLOCATED
061/8 APNIC 1997-04 whois.apnic.net ALLOCATED
062/8 RIPE NCC 1997-04 whois.ripe.net ALLOCATED
063/8 ARIN 1997-04 whois.arin.net ALLOCATED
064/8 ARIN 1999-07 whois.arin.net ALLOCATED
065/8 ARIN 2000-07 whois.arin.net ALLOCATED
066/8 ARIN 2000-07 whois.arin.net ALLOCATED
067/8 ARIN 2001-05 whois.arin.net ALLOCATED
068/8 ARIN 2001-06 whois.arin.net ALLOCATED
069/8 ARIN 2002-08 whois.arin.net ALLOCATED
070/8 ARIN 2004-01 whois.arin.net ALLOCATED
071/8 ARIN 2004-08 whois.arin.net ALLOCATED
072/8 ARIN 2004-08 whois.arin.net ALLOCATED
073/8 ARIN 2005-03 whois.arin.net ALLOCATED
074/8 ARIN 2005-06 whois.arin.net ALLOCATED
075/8 ARIN 2005-06 whois.arin.net ALLOCATED
076/8 ARIN 2005-06 whois.arin.net ALLOCATED
077/8 RIPE NCC 2006-08 whois.ripe.net ALLOCATED
078/8 RIPE NCC 2006-08 whois.ripe.net ALLOCATED
079/8 RIPE NCC 2006-08 whois.ripe.net ALLOCATED
080/8 RIPE NCC 2001-04 whois.ripe.net ALLOCATED
081/8 RIPE NCC 2001-04 whois.ripe.net ALLOCATED
082/8 RIPE NCC 2002-11 whois.ripe.net ALLOCATED
083/8 RIPE NCC 2003-11 whois.ripe.net ALLOCATED
084/8 RIPE NCC 2003-11 whois.ripe.net ALLOCATED
085/8 RIPE NCC 2004-04 whois.ripe.net ALLOCATED
086/8 RIPE NCC 2004-04 whois.ripe.net ALLOCATED
087/8 RIPE NCC 2004-04 whois.ripe.net ALLOCATED
088/8 RIPE NCC 2004-04 whois.ripe.net ALLOCATED
089/8 RIPE NCC 2005-06 whois.ripe.net ALLOCATED
090/8 RIPE NCC 2005-06 whois.ripe.net ALLOCATED
091/8 RIPE NCC 2005-06 whois.ripe.net ALLOCATED
092/8 RIPE NCC 2007-03 whois.ripe.net ALLOCATED
093/8 RIPE NCC 2007-03 whois.ripe.net ALLOCATED
094/8 RIPE NCC 2007-07 whois.ripe.net ALLOCATED
095/8 RIPE NCC 2007-07 whois.ripe.net ALLOCATED
096/8 ARIN 2006-10 whois.arin.net ALLOCATED
097/8 ARIN 2006-10 whois.arin.net ALLOCATED
098/8 ARIN 2006-10 whois.arin.net ALLOCATED
099/8 ARIN 2006-10 whois.arin.net ALLOCATED
100/8 ARIN 2010-11 whois.arin.net ALLOCATED [5]
101/8 APNIC 2010-08 whois.apnic.net ALLOCATED
102/8 AFRINIC 2011-02 whois.afrinic.net ALLOCATED
103/8 APNIC 2011-02 whois.apnic.net ALLOCATED
104/8 ARIN 2011-02 whois.arin.net ALLOCATED
105/8 AFRINIC 2010-11 whois.afrinic.net ALLOCATED
106/8 APNIC 2011-01 whois.apnic.net ALLOCATED
107/8 ARIN 2010-02 whois.arin.net ALLOCATED
108/8 ARIN 2008-12 whois.arin.net ALLOCATED
109/8 RIPE NCC 2009-01 whois.ripe.net ALLOCATED
110/8 APNIC 2008-11 whois.apnic.net ALLOCATED
111/8 APNIC 2008-11 whois.apnic.net ALLOCATED
112/8 APNIC 2008-05 whois.apnic.net ALLOCATED
113/8 APNIC 2008-05 whois.apnic.net ALLOCATED
114/8 APNIC 2007-10 whois.apnic.net ALLOCATED
115/8 APNIC 2007-10 whois.apnic.net ALLOCATED
116/8 APNIC 2007-01 whois.apnic.net ALLOCATED
117/8 APNIC 2007-01 whois.apnic.net ALLOCATED
118/8 APNIC 2007-01 whois.apnic.net ALLOCATED
119/8 APNIC 2007-01 whois.apnic.net ALLOCATED
120/8 APNIC 2007-01 whois.apnic.net ALLOCATED
121/8 APNIC 2006-01 whois.apnic.net ALLOCATED
122/8 APNIC 2006-01 whois.apnic.net ALLOCATED
123/8 APNIC 2006-01 whois.apnic.net ALLOCATED
124/8 APNIC 2005-01 whois.apnic.net ALLOCATED
125/8 APNIC 2005-01 whois.apnic.net ALLOCATED
126/8 APNIC 2005-01 whois.apnic.net ALLOCATED
127/8 IANA – Loopback 1981-09 RESERVED [6]
128/8 Administered by ARIN 1993-05 whois.arin.net LEGACY
129/8 Administered by ARIN 1993-05 whois.arin.net LEGACY
130/8 Administered by ARIN 1993-05 whois.arin.net LEGACY
131/8 Administered by ARIN 1993-05 whois.arin.net LEGACY
132/8 Administered by ARIN 1993-05 whois.arin.net LEGACY
133/8 Administered by APNIC 1997-03 whois.apnic.net LEGACY
134/8 Administered by ARIN 1993-05 whois.arin.net LEGACY
135/8 Administered by ARIN 1993-05 whois.arin.net LEGACY
136/8 Administered by ARIN 1993-05 whois.arin.net LEGACY
137/8 Administered by ARIN 1993-05 whois.arin.net LEGACY
138/8 Administered by ARIN 1993-05 whois.arin.net LEGACY
139/8 Administered by ARIN 1993-05 whois.arin.net LEGACY
140/8 Administered by ARIN 1993-05 whois.arin.net LEGACY
141/8 Administered by RIPE NCC 1993-05 whois.ripe.net LEGACY
142/8 Administered by ARIN 1993-05 whois.arin.net LEGACY
143/8 Administered by ARIN 1993-05 whois.arin.net LEGACY
144/8 Administered by ARIN 1993-05 whois.arin.net LEGACY
145/8 Administered by RIPE NCC 1993-05 whois.ripe.net LEGACY
146/8 Administered by ARIN 1993-05 whois.arin.net LEGACY
147/8 Administered by ARIN 1993-05 whois.arin.net LEGACY
148/8 Administered by ARIN 1993-05 whois.arin.net LEGACY
149/8 Administered by ARIN 1993-05 whois.arin.net LEGACY
150/8 Administered by APNIC 1993-05 whois.apnic.net LEGACY
151/8 Administered by RIPE NCC 1993-05 whois.ripe.net LEGACY
152/8 Administered by ARIN 1993-05 whois.arin.net LEGACY
153/8 Administered by APNIC 1993-05 whois.apnic.net LEGACY
154/8 Administered by AFRINIC 1993-05 whois.afrinic.net LEGACY
155/8 Administered by ARIN 1993-05 whois.arin.net LEGACY
156/8 Administered by ARIN 1993-05 whois.arin.net LEGACY
157/8 Administered by ARIN 1993-05 whois.arin.net LEGACY
158/8 Administered by ARIN 1993-05 whois.arin.net LEGACY
159/8 Administered by ARIN 1993-05 whois.arin.net LEGACY
160/8 Administered by ARIN 1993-05 whois.arin.net LEGACY
161/8 Administered by ARIN 1993-05 whois.arin.net LEGACY
162/8 Administered by ARIN 1993-05 whois.arin.net LEGACY
163/8 Administered by APNIC 1993-05 whois.apnic.net LEGACY
164/8 Administered by ARIN 1993-05 whois.arin.net LEGACY
165/8 Administered by ARIN 1993-05 whois.arin.net LEGACY
166/8 Administered by ARIN 1993-05 whois.arin.net LEGACY
167/8 Administered by ARIN 1993-05 whois.arin.net LEGACY
168/8 Administered by ARIN 1993-05 whois.arin.net LEGACY
169/8 Administered by ARIN 1993-05 whois.arin.net LEGACY [7]
170/8 Administered by ARIN 1993-05 whois.arin.net LEGACY
171/8 Administered by APNIC 1993-05 whois.apnic.net LEGACY
172/8 Administered by ARIN 1993-05 whois.arin.net LEGACY [8]
173/8 ARIN 2008-02 whois.arin.net ALLOCATED
174/8 ARIN 2008-02 whois.arin.net ALLOCATED
175/8 APNIC 2009-08 whois.apnic.net ALLOCATED
176/8 RIPE NCC 2010-05 whois.ripe.net ALLOCATED
177/8 LACNIC 2010-06 whois.lacnic.net ALLOCATED
178/8 RIPE NCC 2009-01 whois.ripe.net ALLOCATED
179/8 LACNIC 2011-02 whois.lacnic.net ALLOCATED
180/8 APNIC 2009-04 whois.apnic.net ALLOCATED
181/8 LACNIC 2010-06 whois.lacnic.net ALLOCATED
182/8 APNIC 2009-08 whois.apnic.net ALLOCATED
183/8 APNIC 2009-04 whois.apnic.net ALLOCATED
184/8 ARIN 2008-12 whois.arin.net ALLOCATED
185/8 RIPE NCC 2011-02 whois.ripe.net ALLOCATED
186/8 LACNIC 2007-09 whois.lacnic.net ALLOCATED
187/8 LACNIC 2007-09 whois.lacnic.net ALLOCATED
188/8 Administered by RIPE NCC 1993-05 whois.ripe.net LEGACY
189/8 LACNIC 1995-06 whois.lacnic.net ALLOCATED
190/8 LACNIC 1995-06 whois.lacnic.net ALLOCATED
191/8 Administered by LACNIC 1993-05 whois.lacnic.net LEGACY
192/8 Administered by ARIN 1993-05 whois.arin.net LEGACY [9][10]
193/8 RIPE NCC 1993-05 whois.ripe.net ALLOCATED
194/8 RIPE NCC 1993-05 whois.ripe.net ALLOCATED
195/8 RIPE NCC 1993-05 whois.ripe.net ALLOCATED
196/8 Administered by AFRINIC 1993-05 whois.afrinic.net LEGACY
197/8 AFRINIC 2008-10 whois.afrinic.net ALLOCATED
198/8 Administered by ARIN 1993-05 whois.arin.net LEGACY [11]
199/8 ARIN 1993-05 whois.arin.net ALLOCATED
200/8 LACNIC 2002-11 whois.lacnic.net ALLOCATED
201/8 LACNIC 2003-04 whois.lacnic.net ALLOCATED
202/8 APNIC 1993-05 whois.apnic.net ALLOCATED
203/8 APNIC 1993-05 whois.apnic.net ALLOCATED [12]
204/8 ARIN 1994-03 whois.arin.net ALLOCATED
205/8 ARIN 1994-03 whois.arin.net ALLOCATED
206/8 ARIN 1995-04 whois.arin.net ALLOCATED
207/8 ARIN 1995-11 whois.arin.net ALLOCATED
208/8 ARIN 1996-04 whois.arin.net ALLOCATED
209/8 ARIN 1996-06 whois.arin.net ALLOCATED
210/8 APNIC 1996-06 whois.apnic.net ALLOCATED
211/8 APNIC 1996-06 whois.apnic.net ALLOCATED
212/8 RIPE NCC 1997-10 whois.ripe.net ALLOCATED
213/8 RIPE NCC 1993-10 whois.ripe.net ALLOCATED
214/8 US-DOD 1998-03 LEGACY
215/8 US-DOD 1998-03 LEGACY
216/8 ARIN 1998-04 whois.arin.net ALLOCATED
217/8 RIPE NCC 2000-06 whois.ripe.net ALLOCATED
218/8 APNIC 2000-12 whois.apnic.net ALLOCATED
219/8 APNIC 2001-09 whois.apnic.net ALLOCATED
220/8 APNIC 2001-12 whois.apnic.net ALLOCATED
221/8 APNIC 2002-07 whois.apnic.net ALLOCATED
222/8 APNIC 2003-02 whois.apnic.net ALLOCATED
223/8 APNIC 2010-04 whois.apnic.net ALLOCATED
224/8 Multicast 1981-09 RESERVED [13]
225/8 Multicast 1981-09 RESERVED [13]
226/8 Multicast 1981-09 RESERVED [13]
227/8 Multicast 1981-09 RESERVED [13]
228/8 Multicast 1981-09 RESERVED [13]
229/8 Multicast 1981-09 RESERVED [13]
230/8 Multicast 1981-09 RESERVED [13]
231/8 Multicast 1981-09 RESERVED [13]
232/8 Multicast 1981-09 RESERVED [13]
233/8 Multicast 1981-09 RESERVED [13]
234/8 Multicast 1981-09 RESERVED [13][14]
235/8 Multicast 1981-09 RESERVED [13]
236/8 Multicast 1981-09 RESERVED [13]
237/8 Multicast 1981-09 RESERVED [13]
238/8 Multicast 1981-09 RESERVED [13]
239/8 Multicast 1981-09 RESERVED [13][15]
240/8 Future use 1981-09 RESERVED [16]
241/8 Future use 1981-09 RESERVED [16]
242/8 Future use 1981-09 RESERVED [16]
243/8 Future use 1981-09 RESERVED [16]
244/8 Future use 1981-09 RESERVED [16]
245/8 Future use 1981-09 RESERVED [16]
246/8 Future use 1981-09 RESERVED [16]
247/8 Future use 1981-09 RESERVED [16]
248/8 Future use 1981-09 RESERVED [16]
249/8 Future use 1981-09 RESERVED [16]
250/8 Future use 1981-09 RESERVED [16]
251/8 Future use 1981-09 RESERVED [16]
252/8 Future use 1981-09 RESERVED [16]
253/8 Future use 1981-09 RESERVED [16]
254/8 Future use 1981-09 RESERVED [16]
255/8 Future use 1981-09 RESERVED [16][17]

Footnotes

[1]
Indicates the status of address blocks as follows:
RESERVED: designated by the IETF for specific non-global-unicast purposes as noted.
LEGACY: allocated by the central Internet Registry (IR) prior to the Regional Internet Registries
(RIRs). This address space is now administered by individual RIRs as noted, including maintenance
of WHOIS Directory and reverse DNS records. Assignments from these blocks are distributed globally
on a regional basis.
ALLOCATED: delegated entirely to specific RIR as indicated.
UNALLOCATED: not yet allocated or reserved.
[2]
0.0.0.0/8 reserved for self-identification [RFC1122], section 3.2.1.3. 
Reserved by protocol. For authoritative registration, see [IANA registry iana-ipv4-special-registry].
[3]
Reserved for Private-Use Networks [RFC1918].
Complete registration details for 10.0.0.0/8 are found in [IANA registry iana-ipv4-special-registry].
[4]
This was reserved for Public Data Networks [RFC1356]. See [IANA registry public-data-network-numbers].
It was recovered in February 2008 and was subsequently allocated to APNIC in April 2010.
[5]
100.64.0.0/10 reserved for Shared Address Space [RFC6598]. 
Complete registration details for 100.64.0.0/10 are found in [IANA registry iana-ipv4-special-registry].
[6]
127.0.0.0/8 reserved for Loopback [RFC1122], section 3.2.1.3. 
Reserved by protocol. For authoritative registration, see [IANA registry iana-ipv4-special-registry].
[7]
169.254.0.0/16 reserved for Link Local [RFC3927].
Reserved by protocol. For authoritative registration, see [IANA registry iana-ipv4-special-registry].
[8]
172.16.0.0/12 reserved for Private-Use Networks [RFC1918]. 
Complete registration details are found in [IANA registry iana-ipv4-special-registry].
[9]
192.0.2.0/24  reserved for TEST-NET-1 [RFC5737]. 
Complete registration details for 192.0.2.0/24 are found in [IANA registry iana-ipv4-special-registry].
192.88.99.0/24 reserved for 6to4 Relay Anycast [RFC3068]
Complete registration details for 192.88.99.0/24 are found in [IANA registry iana-ipv4-special-registry].
192.88.99.2/32 reserved for 6a44 Relay Anycast [RFC6751] (possibly collocated with 6to4 Relay 
at 192.88.99.1/32 - see [RFC3068] section 2.4)
192.168.0.0/16 reserved for Private-Use Networks [RFC1918]. 
Complete registration details for 192.168.0.0/16 are found in [IANA registry iana-ipv4-special-registry].
[10]
192.0.0.0/24 reserved for IANA IPv4 Special Purpose Address Registry [RFC5736]. 
Complete registration details for 192.0.0.0/24 are found in [IANA registry iana-ipv4-special-registry].
[11]
198.18.0.0/15 reserved for Network Interconnect Device Benchmark Testing [RFC2544]. 
Complete registration details for 198.18.0.0/15 are found in [IANA registry iana-ipv4-special-registry].
198.51.100.0/24 reserved for TEST-NET-2 [RFC5737]. 
Complete registration details for 198.51.100.0/24 are found in [IANA registry iana-ipv4-special-registry].
[12]
203.0.113.0/24 reserved for TEST-NET-3 [RFC5737]. 
Complete registration details for 203.0.113.0/24 are found in [IANA registry iana-ipv4-special-registry].
[13]
Multicast (formerly "Class D") [RFC5771] registered in [IANA registry multicast-addresses]
[14]
Unicast-Prefix-Based IPv4 Multicast Addresses [RFC6034]
[15]
Administratively Scoped IP Multicast [RFC2365]
[16]
Reserved for future use (formerly "Class E") [RFC1112].
Reserved by protocol. For authoritative registration, see [IANA registry iana-ipv4-special-registry].
[17]
255.255.255.255 is reserved for "limited broadcast" destination address [RFC919] and [RFC922].
Complete registration details for 255.255.255.255/32 are found in [IANA registry iana-ipv4-special-registry].

相关资源:

 

IANA IPv4 专用地址注册表

IANA IPv4 Special-Purpose Address Registry

Created
2009-08-19

Last Updated
2013-03-03

This registry is also available in plain text.

Registry included below

* IANA IPv4 Special Purpose Address Registry

IANA IPv4 Special Purpose Address Registry

Registration Procedure(s)

IETF Review

Reference
[RFC5736][RFC-bonica-special-purpose-07]

Note

The IETF has reserved the address block of 192.0.0.0/24 for use for
special purposes relating to protocol assignments. This registry
contains the current assignments made by the IETF from this address
block.

Address prefixes listed in the Special Purpose Address Registry are
not guaranteed routability in any particular local or global context.

Address   Block Name RFC Allocation Date
0.0.0.0/8 “This” Network [RFC1122], section 3.2.1.3 1981-09
10.0.0.0/8 Private-Use [RFC1918] 1996-02
100.64.0.0/10 Shared   Address Space [RFC6598] 2012-04
127.0.0.0/8 Loopback [RFC1122], section 3.2.1.3 1981-09
169.254.0.0/16 Link   Local [RFC3927] 2005-05
172.16.0.0/12 Private-Use [RFC1918] 1996-02
192.0.0.0/24[2] IETF Protocol Assignments [RFC-bonica-special-purpose-07],   section 2.1 2010-01
192.0.0.0/29 DS-Lite [RFC6333] 2011-06
192.0.2.0/24 Documentation   (TEST-NET-1) [RFC5737] 2010-01
192.88.99.0/24 6to4   Relay Anycast [RFC3068] 2001-06
192.168.0.0/16 Private-Use [RFC1918] 1996-02
198.18.0.0/15 Benchmarking [RFC2544] 1999-03
198.51.100.0/24 Documentation   (TEST-NET-2) [RFC5737] 2010-01
203.0.113.0/24 Documentation   (TEST-NET-3) [RFC5737] 2010-01
240.0.0.0/4 Reserved [RFC1112], section 4 1989-08
255.255.255.255/32 Limited   Broadcast [RFC919], section 7 1984-10

Footnotes

[1] Several protocols have been granted exceptions to this rule.  For
examples, see [RFC4379] and [RFC5884].
[2] Not useable unless by virtue of a more specific reservation.