How to understand the Ethertype field in Frame header
All data being sent on an Ethernet based network is encapsulated in a “frame”. This frame has a minimum size of 64 and a maximum size of 1518 bytes. Some of the space is however used by Ethernet itself.
At the end of each frame we will find a 4 byte checksum called FCS. This checksum is typically verified at each switch port as the frame travels through the LAN and also at the target Network Interface Card (NIC).
At the very beginning of each frame a 14 byte long “Ethernet header” is located.
(For information on the “space” between frames on a wire, called preamble and the interframe gap, please see this article. )
The Ethernet header contains three fields. The first two are “Destination MAC Address” and “Source MAC Address“. These fields are used for the Layer 2 equipment (switches) to deliver the frame to the correct NIC inside the LAN. Both these fields consumes 6 bytes (which is 48 bits, which is the size of an Ethernet MAC address).
MAC addresses are typically written in a hexadecimal representation, for example AB-DC-EF-12-34-56.
The third and final field is called “Ethertype” and will be discussed below.
When a certain frame has reached the target MAX addess the NIC will procede with several checks. It will verify that the “Destination MAC” is the either the NICs own unicast address, or if not, check if it might be destinated to the general Ethernet Broadcast Address (FF-FF-FF-FF-FF-FF) or if not, verify if the destination address is a Ethernet Multicast Address that the NIC has been instructed to “listen” on. If all of these address checks fails (and the NIC is not in promiscuous mode) the frame will be dropped.
The NIC will also run a mathematical checksum calculation (called CRC32) of the content of the frame and compare to the checksum attached at the tail of the frame.
If these tests checks out ok you could say that the NICs (and layer two at the whole) are almost “done”. They have completed the task of delivering a certain amount of bytes encapsulated in a frame to the correct NIC inside the LAN.
Note however that the NIC has no “knowledge” or capability to read anything “inside” the frame. It still has to do one final task and that is to deliver the frame content to the correct higher protocol (which typically implemented as code inside the operating system). However, since the NIC can not understand/read/de-code the actual payload it must have some way to still determine the next above destination.
The information on to which specific higher level component – that should receive the frame payload – has to be stored where it could actually be read by the NIC, i.e. inside the Ethernet header, and is the purpose of the last field discussed in this article: “Ethertype“.
The field has a length of two bytes. The value is typically expressed in a hexadecimal format, for example 0x0806.
The Ethertype value could be noted to always have a greater value than 0x0600, which in decimal is 1536. The reason for this is that an older header format (called 802.3) used this position in the frame to instead note the frame length. However, the current most used format – and the one discussed in this article – is called the Ethernet II format, which uses the Ethertype “method”.
If the position contains a value that is lower than 1536 it is evaluated as the older 802.3 header structure, but if the value is higher than 1536 it is a “Ethertype”. Note that the values are still typically expressed in hexadecimal format.
The values for Ethertype is predetermined, in the way that the sending machine must know the correct Ethertype value and insert this at the sending time – which will make sure it will later be delivered correctly inside the target host.
One example of an Ethertype value – and the most common one – is 0x0800. This will mean that the NIC will deliver the frame content to the IPv4 module at the destination host.
A list of the most common Ethertype values that is good to know is found in the next article.