Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Looking at the Ethernet entry on Wikipedia, I can't figure out how it's indicated how long the Ethernet frame is. The EtherType/Length header field apparently can indicate either a frame type or an explicit length, and I'm guessing that in the case of a frame type, it has to do some other logic to figure out how long the packet is. For example, if the EtherType field is 0x0800, that indicates an IPv4 payload, and so the receiving NIC would have to examine the first 32 bits of the payload to find the length of the IP packet, and therefore to figure out the total length of the Ethernet frame, and know when to look for the end-of-frame checksum and interframe gap.

Does this sound correct? I also looked at the IEEE 802.3 spec for Ethernet (part 1, anyway) which seems to corroborate this, but it's pretty opaque.

share|improve this question
See… – ysdx Aug 27 '11 at 2:07
up vote 16 down vote accepted

The Physical Coding Sublayer is responsible for delimiting the frames, and sending them up to the MAC layer.

In Gigabit Ethernet, for example, the 8B/10B encoding scheme uses a 10 bit codegroup to encode an 8-bit byte. The extra two bits tell whether a byte is control information or data. Control information can be Configuration, Start_of_packet, End_of_packet, IDLE, Carrier_extend, Error_propagation.

That is how a NIC knows where a frame start and ends. This also means that the length of the frame is not known before it has fully decoded, analogous to a NULL-terminated string in C.

share|improve this answer

The article you really want to answer your question is; which says:

As this industry-developed standard went through a formal IEEE standardization process, the EtherType field was changed to a (data) length field in the new 802.3 standard. (Original Ethernet packets define their length with the framing that surrounds it, rather than with an explicit length count.) Since the packet recipient still needs to know how to interpret the packet, the standard required an IEEE 802.2 header to follow the length and specify the packet type.

share|improve this answer
I guess I'm unclear on what "Original Ethernet packets define their length with the framing that surrounds it" means. The preamble/begin-frame bits are pretty clear, but how does the client know the end of the frame has been reached? How does it distinguish between the CRC and the interframe gap? Is the IFG random electrical noise, easily distinguishable from real signal? – dirtside Nov 24 '09 at 22:43
The end of frame in "classic Ethernet" is signalled by an illegal encoding. – Vatine Oct 24 '10 at 18:24

Logically, there are only three options:

  1. Using a static frame size like in .
  2. Specifying the frame size in its header, or elsewhere, or even bounding it with some flags.
  3. No sending of frames at all

One of these works in Ethernet because there are no other options currently available for modern networking ;) 1st and 3rd are wrong for Ethernet, so you're correct!

share|improve this answer

Took a while to work this out once before, and again now. Not much info on it available, which is surprising as it's such an obvious question. I finally settled on the solution that the length fields in the packet headers are used. See the following link

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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