0.0.0.0 是有效的 IP 地址吗？

Posted 2023-04-14

【中文标题】0.0.0.0 是有效的 IP 地址吗？

【英文标题】：Is 0.0.0.0 a valid IP address?

【发布时间】：2011-04-09 00:23:15

【问题描述】：

我希望我的程序能够将其存储为没有使用地址的指示，但如果它实际上是有效的，这将不起作用。

【问题讨论】：

为什么？这可能有什么应用？

你试过ping它吗？

保留IP地址列表为here.

所以，我认为这是一个合理的问题，并且与编程有关。例如，如果您正在存储一个 IP 地址，您可能希望将“没有可用的 IP 地址”表示为零，如果 0.0.0.0 是一个有效的 IP 地址，您就无法做到这一点。

这是“谁打开***更快”竞赛。所有答案都参考它。

【参考方案1】：

它是有效的，因为它包含四个八位字节，每个字节都在 0 到 255 的范围内。但是，它不能使用作为真实的 IP 地址。

RFC1700 ^(a) 声明 0.0.0.0/8 (0.<anything>.<anything>.<anything>) 仅保留为源地址。您可能会遇到您似乎拥有此地址的情况，但这通常是因为没有为您分配地址（例如，通过 DHCP）。

另见Wikipedia entry on IPv4。

---

^(a) 尽管现在认为此 RFC 已过时，但就给定行为而言，它仍然是正确的。它的替代品https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml 仍然有相同的文本，详细说明了 0.0.0.0 地址的使用。

【讨论】：

我可能错了，但它实际上是一个 IP 地址——它只是保留的。仅仅因为它被保留并不意味着它不是一个 IP 地址。

嗯，我认为“有效”是指可用。这当然是一个合法的 IP 地址，因为每个八位字节都在 0 到 255 的范围内。调整答案以澄清。

我想确保我之前的评论是正确的，所以我做了一些阅读。 RFC 1700 规定：“有五类 IP 地址：A 类到 E 类。”在 RFC 790 中，它声明 0.rrr.rrr.rrr 在“A 类网络”下。因此，由于 0.0.0.0 是 A 类地址，因此它是 IP 地址。如果这些陈述中有任何错误，请随时纠正我。

@Daniel，我认为您的任何陈述都没有错，我们只是对“有效”的含义有不同的想法，这就是我澄清的原因。

RFC1700 已被 RFC3232 废弃，RFC3232 声明“RFC 1700 已废弃，其值不完整，在某些情况下可能是错误的。”。

【参考方案2】：

让我们看看 OP 在这里提出的问题。

0.0.0.0 是有效的 IP 地址吗？

是的。这在技术上是一个有效的 IP 地址，其他答案描述了它的许多不同用途（我不会在这里重新发布 wikipedia 链接......或者我可能是）。

因此，我认为上面的paxdiablo's answer 是最正确的，但也让我们看看您的问题的上下文。

我希望我的程序能够将其存储为没有使用地址的指示，但如果它确实有效，这将不起作用。

这完全取决于您的用例。鉴于这是一个程序员论坛，让我们考虑一下这个观点。

如果您的软件正在存储实际的互联网地址——服务器位置、网站访问者、复制/镜像或备份站点、网络服务或数据库服务器等——那么这将是完全有效的。互联网上的任何机器都不会分配此地址，也不会解析到有效连接。

另一方面，如果您正在编写防火墙或路由器固件，那么此地址确实具有特殊含义；默认路由，接受任何 IP 源/目的地，阻止所有 IP 源/目的地，跌落全包，等等。不过，我要指出，如果你是在这个级别上编码，你应该对网络协议有足够的了解，这样一开始就不需要问这个问题。

因此，我假设大多数查看此问题的人都属于第一类，并建议这是存储空、空或丢失 IP 地址的一种完全有效的方法，如果有无法使用实际的null 值是出于某种原因。即使您忽略了验证检查并且您的软件确实尝试连接到此 IP 地址，它也根本无法建立连接。

【讨论】：

如果没有别的，允许一个有效值作为标志项被重载的问题是它鼓励了坏习惯。但这也可能是一个真正的问题：代码在重载值有意义的其他地方重用，现在有一些细微的错误。

【参考方案3】：

0.0.0.0 用于绑定所有 IPv4 接口。所以它是一个特殊的值，就像127.0.0.1。

【参考方案4】：

是的，它是一个 IP 地址但它是保留的。

0.0.0.0/8 - 此块中的 地址 指“this”上的源主机 网络。地址 0.0.0.0/32 可用作此的源地址 该网络上的主机； 0.0.0.0/8 内的其他地址可用于 引用此网络上的指定主机

【参考方案5】：

它被保留为default route 地址。

当没有为您分配地址时，通常通过 ipconfig 看到这一点。

【讨论】：

您认为 0.0.0.0/0 与 0.0.0.0/32 非常不同。

【参考方案6】：

出于所有意图和目的，是的。由句点分隔的四个数字中的每一个都有一个从 0 到 255 的值，因此 0.0.0.0 在技术上是有效的。

但我认为世界上不会有人真正拥有该 IP。

编辑：好的，它是为默认路由保留的，但它仍然有效。

【讨论】：

保留给默认路由。

【参考方案7】：

你可以在你的应用程序中使用它来表示它没有IP地址，微软在机器没有IP地址时也使用0.0.0.0。

上面谈到的“有效”场景取决于与您的应用程序无关的特定场景。

【讨论】：

你可以，但你不应该。因为它是一个可以寻址的ip地址，有一个功能。

@TheSurrican 是无法寻址的IP地址，有功能。

【参考方案8】：

进行网络 Whois 查询也可以产生非常有用的输出。 示例：http://whois.arin.net/rest/nets;q=0.0.0.0?showDetails=true

注释：地址 0.0.0.0 只能在计算机学习它应该使用哪个 IP 地址时用作传出数据包的地址。它从不用作目标地址。以“0”开头的地址。有时用于向直接连接的设备进行广播。

【参考方案9】：

正如其他答案所涵盖的那样，0.0.0.0 对于某些目的来说是合法且有效的 IP 地址。

如果一个范围内的所有值都是合法值，那么您要定义的任何标志项都必须来自其他地方。否则，您将重载具有标志含义的合法值，并且在使用重载值时，无法 100% 确定是合法值还是标志含义。这将导致错误，必须通过重构来解决，这可能是一项昂贵的工作。

重载合法值一直在发生，IP 地址和 MAC 地址（是的，00:00:00:00:00:00 是合法且已分配）是最常见的受害者。

巧合的是，我现在正在开发一个系统（不是基于以太网/IP），其中帧的长度被限制在大约 40 个字节。由于一个字节可以表示 0 - 255 个字节的长度，并且最大长度为 40 个字节，因此我可以使用一些未使用的又名非法值（252 到 255）来表示标志项。这些带内标志没问题，因为没有重载。

【讨论】：

"我现在正在开发一个系统，其中帧的长度被限制在大约 40 字节。" 哪种数据链路协议将帧限制在 40 字节？通常，存在最小帧长度。例如，以太网要求最小帧长度为 64 字节，它会填充有效负载来实现这一点。

@RonMaupin 这不是以太网/IP 系统，它只是我手头的带内标记的真实示例。

【参考方案10】：

当然是。 但是，它对网络上的单个主机无效。它在本地网络的广播范围内。在这里阅读：https://www.rfc-editor.org/rfc/rfc1700