9

According to big endian byte ordering or network byte order the bits are transmitted in this order: bits 0-7 first, then bits 8-15, then 16-23 and bits 24-31 last. Does this means that bits from version, identification, TTL etc go first and then bits from next fields?

enter image description here

4 Answers 4

6

There is a confusion here. The network byte order does not specify how bits are transmitted over the network. It specifies how values are stored in multi byte fields.

Example:

The Total Length field is composed of two bytes. It specifies in bytes the size of the packet.

Lets say we have the value 500 for that field. Using the Network Byte Order it will be seen over the wire like this, being transmitted transmission from left to right:

00000001 11110100

If we would use the little endian format then it would have been seen over the wire like this:

11110100 00000001

After the whole packet is constructed the bits will be sent starting with the lowest addressed bit of the header (bit 0), so the transmission will start with the Version field.

A final point to make here is that the Network byte order is, as you mentioned, the Big Endian Order. This was chosen arbitrarily to have a common format for all network protocols and implementations.

3
  • 1
    So, in case the first field that will go on wire is version, then HL, then Type, then Total Length, then Identification, and so on. Big endian and little endian only determine how the bits are stored in the header fields.
    – MUSR
    Nov 10, 2015 at 13:42
  • Yes you got it :)
    – dragosb
    Nov 10, 2015 at 13:50
  • 1
    @MUSR: no, they determine the order in which bytes in a multi-byte field are transmitted.
    – EML
    Aug 10, 2018 at 11:07
3

It's very easy to think that internet packets go on the wire in a very simple "serial port" kind of way. In practice there is nothing inherently serial about it.

If you think about some interface details it might make this clearer:

  • Consider Parallel port IP, which actually sends the data 4-bits at a time over four wires. https://en.wikipedia.org/wiki/Parallel_Line_Internet_Protocol
  • Actual 100baseTX scrambles 4-bit blocks and sends them as 5 bits serially but the original data isn't visible in the output, so the question about what order they go in doesn't have an answer. https://en.wikipedia.org/wiki/4B5B
  • When you send a packet across a loopback interface, it might be copied inside the computer's bus 64-bits at a time; or indeed just by memory remapping which would really be whole packet in parallel.

Of course parallel port IP isn't common, but it illustrates the point; the other two are ubiquitous.

Hope that helps

Jonathan.

3

Other protocols may be different, but Ethernet transmits most signficant octet/byte first and within each byte least significant bit first. So, a 16-bit field is transmitted 8-9-10-11-12-13-14-15 - 0-1-2-3-4-5-6-7 (0=least signficant bit, 15=most significant bit). Check IEEE 802.3 Clauses 3.1.1, 3.2.6, and 3.3.

(This is for purely serial Ethernet - depending on the physical layer, up to eight bits may be transferred simultaneously. Additionally, the bit order goes only for the unencoded layer 1.)

IPv4 also uses most significant octet first, check RFC 791. However, numbering in IETF RFCs is in order of transmission with the bit numbering in reverse to Ethernet: Bit 0 = most significant bit = transmitted first (where not otherwise defined).

5
  • You confused octets and bit order it should be : 7-6-5-4-3-2-1 15-14-13-12-11-10-9-8 first octet is 0-7 the 7th bit being the least significant.
    – Gopoi
    Oct 8, 2019 at 22:16
  • 1
    @Gopoi If you number the bits that way you're right. However, usually "0" is the least significant bit (last in human written form) and "15" is the most significant bit (first in human written form) - according to their power of two values.
    – Zac67
    Oct 9, 2019 at 6:32
  • I always thought of the bit numbering as the transmit order since RFCs headers are shown thusly. The more you know!
    – Gopoi
    Oct 10, 2019 at 2:07
  • That's why big endian makes no sense and is unlogical! Aug 17, 2020 at 6:57
  • @BogdanMart All conventions have their pros and cons and none makes complete sense all the time. Still, they're required.
    – Zac67
    Aug 17, 2020 at 7:51
0

It is important to note that "ordering" is a very personal concept, dependent upon culture and experience. "Most people" fail to disclose their own personal concept of "ordering" when engaging in conversation, simply assuming that the other person holds the same concept of ordering as themselves. That assumption, then, is very likely to be both "hidden" and wrong.

I grew-up speaking English, and reading "left to right", "top to bottom". So I tend to "image" in that format. Most of my assembly programming was on Intel microprocessors, with storage "imaged" with "the top of memory" - the memory location with the largest address - at the "top" of a written page. So that's my reference point, and any other ordering format will seem "altered" to me.

My Intel storage image seems "natural" to me because, in English, by convention, we write numbers with the largest weighted symbol on the left. This format has the "natural" advantage of the storage image being independent of the word width. Bit locations in storage do not change when writing different length "chunks" into storage. The bits are always "imaged" in the same order, "left to right", "top to bottom".

That is the "little endian" way. In contrast, with "big endian" format, the bit order in the storage image appears "scrambled", changing with the length of the "chunk" being written. Bits are written "MSB to LSB", and words are written in the opposite order, "Lowest Address to Highest Address". But "scrambled" is only relative to my personal ordering system.

Similarly, display utilities like hexdump appear to me to be "bit-swapped". On the other hand, though, hexdump will display C language text strings in the conventional, readable, left to right order.

However, from my perspective as a "hardware person", then, my "little endian" format is, instead, "backward". I will draw a hardware counter/divider with the fast input clock on the left, which would represent the least weighted symbol in a counter, and draw divider stages "left to right", which is like representing a number "LSB to MSB" - which is "backward".

Similarly, converting "storage order" to network "wire order" depends very much upon your concept of the hardware. Serial or Parallel? Shift Left or Shift Right? Bits or Bauds?

With respect to the original poster's RFC 791 "Internet Header Format" example, we can then refer to "APPENDIX B: Data Transmission Order" from that same document. We find, perhaps counterintuitively, that:

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

                              Figure 10.

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.

People might be inclined, instead, to consider "the bit labelled 0" to be the least significant bit, but that is not the convention here. In particular, note that the document describes the transmission octet order, and says nothing about the transmission bit order. In practice, then, the Internet Protocol transmission bit order is only meaningful in the context of bit-serial transmission, and meaningless in the context of multi-bit symbol transmission, as, for example, with WiFi. Internet Protocol transmission will depend entirely upon the underlying Link Layer and Physical Hardware Layer, using the OSI Network Stack Model terminology. Furthermore, the computer "storage image" of this "Octet-Oriented" Internet Protocol will also depend entirely upon the word size and byte ordering of the underlying Programming Language and Physical Hardware of the computer system.

There are many "moving parts" here, and too many moving parts to provide a simple answer to the original question about "which bits go first". Context is everything. Still, for Internet Protocol itself, the answer is: octet by octet, in "the normal order in which they are read in English", left to right, top to bottom, as read from each diagram in the Internet Protocol documentation.

"Altered", "natural", "scrambled", "bit-swapped", "backward" - depends upon your point of view. While there is no "one true way" of ordering, it is very useful to, first, choose a personal "reference ordering system", and then second, to always communicate that reference in conversation.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.