Which is the intended bit (not byte) order in internet RFC packet diagrams

Question

I am parsing ICMPv6 datagrams on my home wired network, and can't find an explicit mention of the bit-ordering convention in the specific RFC.

Multi-byte fields are network order, but what about bits within a byte?

Machines are byte-addressible, but network hardware serializes bits. On diagrams, a bit to the "left" of a 8-bit field ends up in which bit of an unsigned byte (most significant, or least)? Is this per-RFC, or is it everywhere the same for all internet RFCs?

Example Reading a multi-byte field (Prf field)

Assume I have the packet data stored in a variable called data:

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

And that I find the particular byte (not bit) of interest containing the flags:

flag_byte = data[some_offset] #pseudocode

Trying to parse this message, RFC4161 section 2.3, specifies that the the Route information option has a 2-bit flag called Prf.

   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.

To phrase my question in terms of this example, (flag_byte & 0x18) >> 3 will get me the two bits. Will b & 0x10 be the sign bit? I'm also interested in figuring out the standard that specifies that this is the way it should be.

Network byte and bit order are big-endian, but Intel processors are little-endian. You end up reversed. See [RFC 1700, ASSIGNED NUMBERS](https://tools.ietf.org/html/rfc1700). — Ron Maupin, Oct 11 '16 at 04:33
The endianness of the computer architecture only affects the order of multi-byte integers. I would have this problem regardless of computer architecture. In my question, I wrote about order of _bits_ within a byte. The RFC you refer to does hold the info I'm looking for! Thanks! — init_js, Oct 11 '16 at 04:50
The IETF does have a document on this that says the bit order should be big-endian, too: "_3.2. Network Bit Order For certain low-level protocols or compression-oriented media types, bit-order may be an issue. When possible, big-endian is encouraged for consistancy with Network Byte Order._" — Ron Maupin, Oct 11 '16 at 04:53
removed the mention of ethernet. I just meant it was IP over ethernet. i'm reading packet data off a raw ICMPV6 socket. — init_js, Oct 11 '16 at 06:38
VG. Ethernet of course is standardized by an IEEE document, not an RFC. — user207421, Oct 12 '16 at 22:52

score 10 · Answer 1 · edited Oct 07 '21 at 08:14

As pointed out in a previous comment (thanks ron-maupin), RFC1700 specifies that messages (covering internet protocols) are depicted with most significant bits on the left.

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 was superseded by RFC3232, which puts the up-to-date protocol definitions online at iana.org/protocols. They seem to have kept that notation (e.g. RouterAdvertisementFlags).

I assume this convention on significance applies to n-bit bit fields too (1 < n < 8), and therefore the leftmost bit in a 2-bit field (such as Prf) would be the sign bit.

It should be up to the hardware to de-serialize bits on the physical medium and place them at their right location within a byte on the byte-addressible computer. Different physical layers (physical ethernet, wifi, coax, infiniband, fibre channel) might serialize bits in different orders on the "wire", but the respective positions in bytes at the packet-level would be the same regardless.

RFC791 Appendix B should be a better source! – YouJiacheng Dec 07 '22 at 07:22 — YouJiacheng, Dec 07 '22 at 07:22

Which is the intended bit (not byte) order in internet RFC packet diagrams

Example Reading a multi-byte field (Prf field)

1 Answers1

Linked