Advantages of LSB-First Method in Canonical MAC Address Transmission

ethernetmac address

When MAC addresses are sent out they are sent such that the Group Address Indicator is the first bit of the Ethernet frame but
when stored in memory this forms the LSB of the leftmost byte of the MAC address.
For example-

             In memory,      12       34       56       78       9A       BC
               canonical:   00010010 00110100 01010110 01111000 10011010 10111100

                            1st bit appearing on LAN (group address indicator)
                            |
               On LAN:      01001000 00101100 01101010 00011110 01011001 00111101

What is the reason for this design decision that requires swapping of the bits of a byte in the a address before it is sent out
on the LAN? Does it have a historic importance in that it made sense when the protocol was designed?
Does this design have certain specific advantages?

Also something of relevance to my question that I thought I must mention is that this wasn't the case with all the of the LAN adopters.
(mentioned here:RFC 2469)

Best Answer

There is no real advantage to sending LSB (Little-endian) or MSB (Big-endian) first. As long as the same convention is followed by everyone, this allows communication to take place. To your final note, other communications protocols such as RS-232 (serial) also used Little-endian and in general, I believe it was much more common to do so.

Keep in mind that computers operate based purely on bits. Anything else you see is simply a conversion to a more "human" way to deal with the bits.

If you were to use Big-endian, then the easiest way to store the same 48-bit address in memory would be as follows:

0100 1000 0010 1100 0110 1010 0001 1110 0101 1001 0011 1101

If the bits actually had significance beyond being just bits, then you would end up with the following in hex:

4 8 2 C 6 A 1 E 5 9 3 D

So your Little-endian address hex representation of the bits is 12-34-56-78-9A-BC, but the very same address in a Big-endian network would be 48-2C-6A-1E-59-3D (if I did all that right...been a while since I had to convert Little-endian addressing to Big-endian). The exact same address, just a different way to store/transmit the bits.

Heading off the beaten path, so feel free to stop reading...

This lead to some really interesting interactions with TCP/IP. Since Ethernet (Little-endian) came before Token Ring (Big-endian), ARP was designed around the Little-endian addressing. When you bridged traffic between Ethernet and Token Ring, the bridge has to support IP (in order to recognize ARP packets) and re-order the bits in the ARP address fields appropriately. This was a less than ideal solution as it forced L3 functionality on L2, but it did resolved the problem.

When FDDI (Big-endian) came along even later, the TCP/IP designers wanted to avoid this problem and designed ARP on FDDI to use Little-endian for the address fields. This avoided having to modify both the headers and the payload of ARP packets when bridging Ethernet to FDDI. However, it also meant a bridge connecting Token Ring to FDDI would need to re-order the bits in the address fields. It was just much rarer to bridge Token Ring to FDDI than it was to bridge Ethernet to FDDI.

Other protocols such as AppleTalk were also similarly affected, but generally weren't provided a solution as they were not as prevalent as TCP/IP. So, if you were to bridge Ethernet to Token Ring, this would break AppleTalk.

Related Topic