为什么 IPV4 以 10 进制表示

Question

根据 IP 点表示法，使用 base 10 表示而不是十六进制是标准的。

127.0.0.1 -> 7F.0.0.1
255.255.255.255 -> FF.FF.FF.FF
10.0.0.1 -> 0A.0.0.1
10.0.0.1/24 -> 0A.0.0.1/18

我在 RFC 中找不到任何关于为什么 IPv4 的约定是以 10 为基数的参考，但是 MAC 和 IPV6 默认使用十六进制。

我们这样做有什么原因吗？还是纯粹是历史性的？

Answer 1

在RFC 790中分配了网络号，您可以从那里得到问题的答案。

RFC 790 讨论分配的不同网络号，所有这些都是以 10 为基数的十进制格式。

Answer 2

十进制是事实上的标准； IPv4 地址的字符串格式从未正确标准化。几乎所有工具都只会采用十进制、点分四组、符号，但这并非普遍适用；任何仍在使用 inet_aton() 通用实现的工具都可能处理替代格式。

iputils 包中包含的

ping 是一个有用的示例。取一个 google 的地址，并尝试十进制、十六进制和八进制点分四边形：

ping -c1 216.58.195.238
ping -c1 0xd8.0x3a.0xc3.0xee
ping -c1 0330.072.0303.0356

这些都ping同一个地址，因为它们都代表同一个32位。

但它远不止于此。您不必严格使用四个八位位组；在无类寻址和可变长度网络掩码出现之前，曾经指定 8 位、16 位和 24 位网络前缀的有类寻址。其中一些仍然融入 inet_aton():

上面的地址，格式为8/8/16位：

ping -c1 216.58.50158
ping -c1 0330.072.0141756
ping -c1 0xd8.0x3a.0xc3ee

或者，格式化为 8/24 位：

ping -c1 216.3851246
ping -c1 0330.016541756
ping -c1 0xd8.0x3ac3ee

或者，忘记点，只输入 32 位：

ping -c1 3627729902
ping -c1 033016541756
ping -c1 0xd83ac3ee

但更好的是，您不必以相同的格式交出每个块：

ping -c1 0xd8.072.195.0xee

这一切都导致了一个合理的提醒，但是：inet_aton() 是一个非常老的功能，并且不理解什么是 IPv6 地址。如果你今天正在编写代码，你不会想使用 inet_aton()，你会想使用 inet_pton()，它同时处理这两者。我使用的 inet_pton() 的实现更加忠实于十进制点分四边形的实际标准 IPv4 地址表示形式。对于IPv6，实际上确实有an RFC on string representation，inet_pton()遵循标准！

为什么 IPV4 以 10 进制表示

Why is IPV4 represented in base 10

ip

networking

ipv4