IP header 长度和版本字段
IP header length and version field
我最近试图在 System Verilog 中创建一个 TCP/IP 数据包生成器和检查器。为了验证我的代码，我将生成器输出与 IP Golden 输出进行了比较。
我能够将几乎所有字段与 Golden 输出匹配，但 IP header 和版本字段似乎有所不同。我生成的数据包的 IP 版本为 4，IHL 为 5。
网上的位域总结如下header:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| IHL |Type of Service| Total Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
根据上面提到的位字段位置，我们有位 0:3 作为版本和位 4:7 作为 IHL。现在，传输的字节是通过连接两个字段形成的。因此，在生成器代码中，我将版本作为字节的 LSB 部分，将 IHL 作为字节的 MSB 部分。结果形成的字节是 0x54 但在 Golden 输出中我看到字节实际上是 0x45 看起来颠倒了？
这是两个输出：
发电机输出：
0000 00 a0 12 01 01 01 00 a0 12 01 01 02 08 00 **54** 00
0010 00 38 30 39 40 00 80 06 5a c9 0a 2a 5a a9 0a 00
0020 00 eb 00 0b 00 37 00 00 00 01 00 00 00 02 50 08
0030 00 03 03 87 04 00 00 01 02 03 04 05 06 07 08 09
0040 0a 0b 0c 0d 0e 0f
黄金产出：
0000 00 a0 12 01 01 01 00 a0 12 01 01 02 08 00 **45** 00
0010 00 38 30 39 40 00 80 06 5a c9 0a 2a 5a a9 0a 00
0020 00 eb 00 0b 00 37 00 00 00 01 00 00 00 02 50 08
0030 00 03 03 87 04 00 00 01 02 03 04 05 06 07 08 09
0040 0a 0b 0c 0d 0e 0f
不确定我是否遗漏了什么？请建议。
谢谢。
当引用 IETF 协议表示的位和字节顺序时，例如IPv4，您使用网络字节顺序（大端）。在您的示例中，位按编号顺序传输：0 到 31，这导致网络字节顺序。结果，您将在传输 IHL 之前传输 Version，这与您尝试做的相反，它导致第一个字节传输为 0x45
这在RFC 1700, ASSIGNED NUMBERS中有解释：
Data Notations
The convention in the documentation of Internet Protocols is to
express numbers in decimal and to picture data in "big-endian" order
[COHEN]. That is, fields are described left to right, with the
most significant octet on the left and the least significant octet on
the right.
The order of transmission of the header and data described in this
document is resolved to the octet level. Whenever a diagram shows a
group of octets, the order of transmission of those octets is the
normal order in which they are read in English. For example, in the
following diagram the octets are transmitted in the order they are
numbered.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 | 2 | 3 | 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 5 | 6 | 7 | 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 9 | 10 | 11 | 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Transmission Order of Bytes
Whenever an octet represents a numeric quantity the left most bit in
the diagram is the high order or most significant bit. That is, the
bit labeled 0 is the most significant bit. For example, the following
diagram represents the value 170 (decimal).
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|1 0 1 0 1 0 1 0|
+-+-+-+-+-+-+-+-+
Significance of Bits
Similarly, whenever a multi-octet field represents a numeric quantity
the left most bit of the whole field is the most significant bit.
When a multi-octet quantity is transmitted the most significant octet
is transmitted first.
我最近试图在 System Verilog 中创建一个 TCP/IP 数据包生成器和检查器。为了验证我的代码，我将生成器输出与 IP Golden 输出进行了比较。
我能够将几乎所有字段与 Golden 输出匹配，但 IP header 和版本字段似乎有所不同。我生成的数据包的 IP 版本为 4，IHL 为 5。
网上的位域总结如下header:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| IHL |Type of Service| Total Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
根据上面提到的位字段位置，我们有位 0:3 作为版本和位 4:7 作为 IHL。现在，传输的字节是通过连接两个字段形成的。因此，在生成器代码中，我将版本作为字节的 LSB 部分，将 IHL 作为字节的 MSB 部分。结果形成的字节是 0x54 但在 Golden 输出中我看到字节实际上是 0x45 看起来颠倒了？
这是两个输出：
发电机输出：
0000 00 a0 12 01 01 01 00 a0 12 01 01 02 08 00 **54** 00
0010 00 38 30 39 40 00 80 06 5a c9 0a 2a 5a a9 0a 00
0020 00 eb 00 0b 00 37 00 00 00 01 00 00 00 02 50 08
0030 00 03 03 87 04 00 00 01 02 03 04 05 06 07 08 09
0040 0a 0b 0c 0d 0e 0f
黄金产出：
0000 00 a0 12 01 01 01 00 a0 12 01 01 02 08 00 **45** 00
0010 00 38 30 39 40 00 80 06 5a c9 0a 2a 5a a9 0a 00
0020 00 eb 00 0b 00 37 00 00 00 01 00 00 00 02 50 08
0030 00 03 03 87 04 00 00 01 02 03 04 05 06 07 08 09
0040 0a 0b 0c 0d 0e 0f
不确定我是否遗漏了什么？请建议。
谢谢。
当引用 IETF 协议表示的位和字节顺序时，例如IPv4，您使用网络字节顺序（大端）。在您的示例中，位按编号顺序传输：0 到 31，这导致网络字节顺序。结果，您将在传输 IHL 之前传输 Version，这与您尝试做的相反，它导致第一个字节传输为 0x45
这在RFC 1700, ASSIGNED NUMBERS中有解释：
Data Notations
The convention in the documentation of Internet Protocols is to express numbers in decimal and to picture data in "big-endian" order [COHEN]. That is, fields are described left to right, with the most significant octet on the left and the least significant octet on the right.
The order of transmission of the header and data described in this document is resolved to the octet level. Whenever a diagram shows a group of octets, the order of transmission of those octets is the normal order in which they are read in English. For example, in the following diagram the octets are transmitted in the order they are numbered.
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1 | 2 | 3 | 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 5 | 6 | 7 | 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 9 | 10 | 11 | 12 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Transmission Order of Bytes
Whenever an octet represents a numeric quantity the left most bit in the diagram is the high order or most significant bit. That is, the bit labeled 0 is the most significant bit. For example, the following diagram represents the value 170 (decimal).
0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |1 0 1 0 1 0 1 0| +-+-+-+-+-+-+-+-+Significance of Bits
Similarly, whenever a multi-octet field represents a numeric quantity the left most bit of the whole field is the most significant bit. When a multi-octet quantity is transmitted the most significant octet is transmitted first.