互联网 RFC 数据包图中预期的位（不是字节）顺序

Question

我正在我的家庭有线网络上解析 ICMPv6 数据报，但在特定 RFC 中找不到对位排序约定的明确提及。

多字节字段是网络顺序的，但是字节内的位呢？

机器是字节寻址的，但网络硬件对位进行序列化。在图表中，8 位字段“左侧”的一位最终位于无符号字节的哪一位（最高有效位或最低有效位）？这是每个 RFC，还是所有互联网 RFC 都一样？

读取多字节字段（Prf 字段）的示例

假设我将数据包数据存储在名为

data

的变量中：

data, remote_peer = sock.recvfrom(1024) #pseudocode

并且我发现包含标志的特定感兴趣的byte（不是位）：

flag_byte = data[some_offset] #pseudocode

尝试解析此消息，RFC4161 第 2.3 节，指定路由信息选项有一个名为

Prf

的 2 位标志。

   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
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |     Type      |    Length     | Prefix Length |Resvd|Prf|Resvd|
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                        Route Lifetime                         |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                   Prefix (Variable Length)                    |
  .                                                               .
  .                                                               .
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...
Prf (Route Preference)
           2-bit signed integer.  The Route Preference indicates
           whether to prefer the router associated with this prefix
           over others, when multiple identical prefixes (for
           different routers) have been received.  If the Reserved
           (10) value is received, the Route Information Option MUST
           be ignored.

用这个例子来表达我的问题，

(flag_byte & 0x18) >> 3

会给我这两位。

b & 0x10

会是符号位吗？我也有兴趣找出规定这应该是这样的标准。

Answer 1

正如之前评论中所指出的（感谢 ron-maupin），RFC1700 指定消息（涵盖互联网协议）在左侧用最高有效位进行描述。

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.

RFC1700 被 RFC3232 取代，后者将最新的协议定义放在 iana.org/protocols 上。他们似乎保留了该符号（例如RouterAdvertisementFlags）。

我假设这种重要性约定也适用于 n 位位字段（1 < n < 8), and therefore the leftmost bit in a 2-bit field (such as

Prf

）将是符号位。

应该由硬件来对物理介质上的位进行反序列化，并将它们放置在字节可寻址计算机上的字节内的正确位置。不同的物理层（物理以太网、wifi、同轴电缆、infiniband、光纤通道）可能会在“线路”上以不同的顺序序列化位，但无论如何，数据包级别的相应字节位置将是相同的。

Answer 2

我一直认为 RFC 完全错了。最高有效位应具有最高的“位数”，即在一个字节中，第 7 位是 MSB。这就是 DEC 绘制内容、控制和状态寄存器等在内存中表示的图表的方式。我们被困在次优的表示中，并且在我看来，我们被困在像 SIP/RTP 这样非常糟糕的协议中。是的，我有电信背景！