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?

  • 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 '13 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 '13 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 '13 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 '13 at 4:51
  • Did any answer help you? if so, you should accept the answer so that the question doesn't keep popping up forever, looking for an answer. Alternatively, you could provide and accept your own answer. – Ron Maupin Aug 8 '17 at 14:34
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.

  • 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 '13 at 4:57

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.