Network Engineering Stack Exchange is a question and answer site for network engineers. It only takes a minute to sign up.
Sign up to join this community
I'm studying for some networking concepts and have learned that a receiving host looks at an Ethernet frame's header to determine what protocol being used by the packet. It makes me wonder though, since a packet header includes this same info, why doesn't Ethernet protocol try to save space in the frame by just determining what network protocol is being used by looking at the packet header?
Thank you for the help!
The receiver has to look at the Ethernet frame to decide its contents, which might be DECnet, Appletalk or many other things -- Internet Protocol is only one of many protocols running on top of Ethernet.
When Ethernet was being designed, it wasn't obvious at all what protocols might exist in the future, and the winner-take-all effect wasn't obviously so large. A key goal of Ethernet was ubiquity -- in order to be cheap it had to be everywhere, and so it was designed to be completely neutral about its contents.
It's also a fundamental idea in the separation of the layers: code for each layer does not look inside the contents, it has a label on the outside which says what it contains along with whatever is required for addressing. For example the Ethernet frame might say "contains IP". Inside its payload, the IP header has a label which says "contains UDP". The UDP header says "contains DNS" (inferred from port number). And the DNS program is responsible for deciding what to do with that. If you don't do it like this then you duplicate at least a little of the code of the upper layer in the lower. (Or, required some kind of mechanism for the lower layer to ask an upper layer "is this packet one of yours?".) And, worse than that, this then limits the lower layer to working with upper layers which the lower-layer implementer knew and cared about. I guarantee you the Ethernet designers didn't know about IPv6, and it's the separation of layers which permits the easy development of new protocols.
Those who were obsessed about a few bytes generally wrote their protocols raw on top of Ethernet, essentially using it in the way we might use UDP. Most of those surely regretted it and converted to TCP or UDP later when they needed a facility such as ports or reliable ordered two-way byte streams, or indeed, multi-hop transport.
This is a fun question with a lot of history. Originally, the EtherType field indicated the length of the frame; not the type of payload. The relevant Wikipedia article contains a good explanation with references.
MPLS is an example of a protocol which lacks a field indicating the payload type. This has important consequences! Although the devices at each end of an MPLS LSP should know the type of payload -- because of how MPLS LSPs are signaled, transit devices or P-nodes do not know.
MPLS P-nodes have to guess about the payload type for some operations, such as equal-cost multi-path routing. This can have consequences when that guess is wrong. For example, MPLS routers generally misinterpret Ethernet pseudo-wire traffic destined for a MAC address beginning with a 6 as an IPv6 packet, not an Ethernet frame. This can cause unexpected packet re-ordering within flows, which can manifest as real problems for applications that don't tolerate re-ordering well!
This problem is so important that router manufacturers have designed several different approaches MPLS networks can use to allow MPLS ECMP hashing without explicitly signaling the payload type, such as Flow-Aware Transport and Entropy Labels.
