为什么不能在主机上使用IP地址主机部分的全部零？

是否将IP数据包的目的地设置为子网IP地址？

是。 这是一个有效的IP，因此可以使用。

如果是的话，在什么情况下，为什么？

它只是/ 24中255个可用IP中的一个

如果不是，那么为什么不释放该地址供任何主机使用？

如果你有古老的硬件，那么你需要检查它是否使用第一个或最后一个地址作为networking地址。 （掩码为FF.FF.FF.00的networking的.0或.255）

这使跳过该IP的一个好习惯。 很久以前学习的习惯很难忽视。

而不了解背景的人不会使用它，因为别人也不使用它，所以使用它一定是错误的，或者因为他们没有意识到“0”可以是第一个数字。

[编辑] Grezzo刚刚在Windows XP上进行了testing，Windowsnetworking界面“有用”地阻止了这个设置。 Windows 7具有相同的行为。 然后，我试着在非Windows主机上运行。 如果您使用Windows，那么您可能需要通过IPconfig手动configuration您的networking，以将其设置为全零。

[编辑2]

我工作的时间越长，我就越困惑。

Rfc4632 – 无类别域间路由似乎并不禁止它，但都不明确。

这个ServerFault文章提到： “由于历史原因，许多操作系统把第一个地址视为广播，例如，在本地（/ 24）networking上从OS X，Linux和Solaris ping xxx0就会得到响应。默认情况下是第一个地址，但是您可以使用SetIPUseZeroBroadcast WMI方法来启用它，不知您是否可以在全Windowsnetworking上使用.0作为主机地址。 。

这是同样的问题，但不是答案。

networking地址也用于路由表中。 但是我不明白为什么它不起作用。 在路由表中相同的符号将路由到正确的networking。 一旦在正确的networking上，它会到达一台IP为0的PC。

（所有这一切为一个192.168.1 / 24。
如果你使用的是192.168.0 / 23，那么192.168.1.0将是一个在范围中间的有效且安全的值）

[编辑3]

多一个链接到同一个问题。 在堆栈交换中似乎有点stream行：

https://superuser.com/questions/379451/why-can-a-network-address-not-be-a-valid-host-address

还有一个想法：

在与路由表中的条目进行比较之前，Destination_IP可能与networking桅杆（硬件中的快速操作）进行了AND编辑。 但：

（半随机IP）192.168.0.42和255.255.255.0将产生192.168.0.0
但192.168.0.0和255.255.255.0也会产生192.168.0.0

[编辑4 – 写了这个答案很长 – 我可能需要重写整个职位，由于这个新的信息 ]

RFC923在第3页指出：

  In certain contexts, it is useful to have fixed addresses with functional significance rather than as identifiers of specific hosts. When such usage is called for, the address zero is to be interpreted as meaning "this", as in "this network". The address of all ones are to be interpreted as meaning "all", as in "all hosts". For example, the address 128.9.255.255 could be interpreted as meaning all hosts on the network 128.9. Or, the address 0.0.0.37 could be interpreted as meaning host 37 on this network. 

在我们的networking工程网站上引用@ylearn

我相信第一个文档来自RFC950 ，它引用了RFC943 （它已经废弃了上面的RFC923 ，但对特殊地址使用相同的语言）：

  It is useful to preserve and extend the interpretation of these special addresses in subnetted networks. This means the values of all zeros and all ones in the subnet field should not be assigned to actual (physical) subnets. 

具有全零主机部分的地址是指networking本身，而不是指任何特定的主机。

历史上，这个零主机地址已经作为替代广播地址，而设备仍然以这种方式响应。

所以，我不得不不同意其他答案：不，零不是一个完全可用的主机地址。 如果您需要超过254个地址，则必须创build一个更大的子网。

看，我的Linksys路由器，其地址是.1响应.0 。 （networking掩码是255.255.255.0 ，所以最后一个八位组对应于主机号码。）

 webserver:~# ping 192.168.1.0 Do you want to ping broadcast? Then -b webserver:~# ping -b 192.168.1.0 WARNING: pinging broadcast address PING 192.168.1.0 (192.168.1.0) 56(84) bytes of data. 64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=1.46 ms 64 bytes from 192.168.1.1: icmp_seq=2 ttl=64 time=0.812 ms 64 bytes from 192.168.1.1: icmp_seq=3 ttl=64 time=0.819 ms 

如果我将.0地址分配给某个主机，那么如果没有路由器同时响应，我也不能ping通它。 正如你所看到的，像路由器的ping版本这样的工具把0视为一个广播。

如果您愿意修补受此类弯曲影响的所有协议栈和其他软件，则可以遵守这些规则。 否则，坚持规则。

例如。

我曾在一家公司devise过一个14插槽机箱的networking节点，在几种types的卡上运行许多独立的操作系统映像，所有这些都通过背板进行通信。 有一个在背板上的networking设置，其约定是127.X.0.Y是插槽X中节点Y的内部IP地址，全部从1开始编号。

我们基本上为了自己的目的划分了回送地址。 为了使它工作，我们不得不在Linux内核中进行修补，还有一些用户空间的IIRC。

由于该networking仅用于盒子，大多数需要环回的程序使用127.0.*networking（实际上是特定的地址127.0.0.1 ），继续正常工作，一切都很酷。

实际上它取决于networking掩码，例如，对于networking83.23.159.0/23,83.23.159.0是一个完全可用的IP地址

听起来这里有一些基本的networking混乱。

在其中一个响应中提到的“古老硬件”将不会使用IP子网零 – 使用IP地址xxx0与networking设置为/ 24 CIDR或255.255.255.0子网掩码是完全不同的问题。

IP子网零

• 较旧的硬件不会使用IP子网零 – 这意味着它们不会使用多子网networking系统上的第一个子网。 因此，在/ 23或255.255.254.0networking上，子网XXX0及其所有地址都不会被使用。 现代路由器没有这个限制，但可以configuration为使用这个旧的模型IE不使用子网零，如果需要的话。

子网上可用的主机IP地址

• 基本networking：
  • 用/ 24即子网掩码255.255.255.0
  • xxx0被保留为networking地址。 路由器和路由协议（EIGRP，RIP2等）使用networking地址来定义在networking边界内和跨networking边界移动数据包的网段。
  • xxx255保留给广播地址
  • 通常的做法是在路由器上使用地址.1或.254，以便留下253个可用的IP号码。

networking地址和广播地址都是保留的，不能（按当前和以前的networking标准）分配给设备。 在/ 24系统上使用xxx0作为主机地址是错误的。 即使Linux让你使用它也并不意味着它是正确的，它只是意味着Linux认为你知道你在做什么。

如果你的系统允许你将xxx0作为IP4地址分配给一个主机，并且它似乎正在工作 – 这个特定的主机正在接收所有针对该networking上的任何设备的所有通信，所以它的networking可能不能正常工作。

RFC 1122 （“互联网主机 – 通信层的要求”）禁止：

对于任何<主机号码>，<networking号码>或<子网号码>字段，不允许IP地址的值为0或-1

其实答案是子网划分的基础。 您的子网的“全零”IP与networkingID结合在一起用于计算数据包的发送位置。

在你的例子中你有一个255.255.255.0的子网。 任何知道TCP / IP协议的设备都将使用与IP地址结合的networking掩码来计算数据包是发往本地networking（通过执行逻辑AND操作）还是必须通过网关/路由器发送。

所以我猜想IP不能被使用的原因是因为它已经被用来通过devise与networking掩码一起“定义”networking边界。

有人要求我转发来自NetworkEngineering的答复，所以我会对这个网站做一些修改。

在RFC919中 ，它提到了networking地址的普遍接受：

 However, as a notational convention, we refer to networks (as opposed to hosts) by using addresses with zero fields. For example, 36.0.0.0 means "network number 36" 

如果有人提到“10.1.2.0”作为networking而不是networking上的主机，这就提供了一个应该澄清我们理解的约定。

从那里，在IP地址中使用“0”在RFC923中被定义并且在相继的RFC中继续：

 Special Addresses: In certain contexts, it is useful to have fixed addresses with functional significance rather than as identifiers of specific hosts. When such usage is called for, the address zero is to be interpreted as meaning "this", as in "this network". The address of all ones are to be interpreted as meaning "all", as in "all hosts". For example, the address 128.9.255.255 could be interpreted as meaning all hosts on the network 128.9. Or, the address 0.0.0.37 could be interpreted as meaning host 37 on this network. 

这个例子通过在地址的networking部分使用0来提供当前networking上的特定主机（0.0.0.37），但是实际上并没有阐明相反的情况（地址的主机部分为0）。 但是，它确实将“0”定义为“this”。

在RFC1060中 ，地址“0.0.0.0”被明确logging为“该networking上的该主机”：

  (a) {0, 0} This host on this network. Can only be used as a source address (see note later). 

由于地址的主机部分的全部零表示“该主机”，因此在逻辑上将其作为主机地址不可用。

回到直接回答你的问题：

1. 是否将IP数据包的目的地设置为子网IP地址？
2. 如果是的话，在什么情况下，为什么？
3. 如果不是，那么为什么不释放该地址供任何主机使用？

根据我在RFC中find的，这不应该被使用。 我承认这不是我想要的那么明确，但是这在许多标准中都是相同的。 如果标准在某一点上不那么坚定，那么这个行业似乎会“解决”成一个普遍接受的解释。

此外，根据RFC的内容，可以编写软件来假定这个地址被用来寻址networking而不是一个特定的主机。 甚至更像字面上的某种“回送”（即在指定networking上的这个主机）。

那么为什么有些操作系统明确允许它的使用？ 我想像很多事情，它归结为开发人员时间/资源或没有人真的想join有效性检查。 由于较大的子网（a / 23或更大）将包含.255和.0的有效IP地址（即10.1.2.0/23同时包含有效的IP），所以逻辑必须比“如果以0结尾”地址10.1.2.255和10.1.3.0）。 尽pipe一些组织也避免在较大的子网中使用这些有效的地址，以避免软件不能正确支持现代子网的问题。

至于为什么不释放一个IP地址，它只是降低成本/收益。 要花费很多的时间和精力来做这个改变，以便每个子网取回一个IP地址，以及在多less个你需要额外的IP地址的情况下，只有一个地址就足够了？ 添加第二个子网或放大当前子网要容易得多，可能会给您许多地址而不是一个地址，而不会对任何软硬件进行重大更改。