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.

Answer 1

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.