7

In an Ethernet frame header, the destination MAC (DMAC) is placed before the source MAC for obvious reasons (stations accept based on DMAC). But why is not the same thing maintained for destination IP (DIP) and source IP (SIP) in the IP Header?

Why is SIP ahead of DIP in an IP Frame header, unlike in an Ethernet frame where DMAC is ahead of SMAC?

Improve this question
4
  • 4
    I think ethernet guys envisioned 'cut-through' early on. With IP, 'cut-through' isn't really possible, as 'header checksum' is before any IP addresses, but it includes IP addresses, so you need to read whole IP header before you can determine value in the header, which really makes the order of the header in this context irrelevant. But it still begs the question, why isn't IP header designed to be 'cut-through' friendly. And answer probably is, it wasn't remotely interesting/important at the time and it's debatable if it is today.
    – ytti
    Aug 28, 2013 at 19:08
  • 2
    @ytti: What improvement would it do if IP would support 'cut-through' ? IP is seldom used without a layer 2.
    – BatchyX
    Aug 28, 2013 at 19:29
  • 2
    For Ethernet, I think putting destination first was due to hubs being all the rage back then and making it more efficient for hosts to determine if a frame was for them. Earlier versions of IP and TCP did have the destination address first. There's no real explanation why it was switched in v4. I don't believe efficiency or speed has ever been a point of emphasis in IP.
    – Santino
    Aug 29, 2013 at 0:25
  • @BatchyX while IP is used with L2, if you need to do L3 routing decision, you cannot do it 'cut-through' because of the frame design, I'm personally not very convinced cut-through is useful even in L2, but I also don't feel very strongly about it. Maybe some people have nice use-case for IP cut-through.
    – ytti
    Aug 29, 2013 at 4:51

1 Answer 1

Reset to default
3

The idea was to know as soon as possible whether a frame was multicast; the network byte order was screwed up slightly in the design, so that's in the second instead of the first nibble.

Improve this answer
1
  • 3
    TokenRing would sent the MAC left-to-right, so multicast bit would be seen as 1st bit, instead of 8th bit.
    – ytti
    Aug 29, 2013 at 4:57

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