Why was ethernet MTU calculated as 1500 bytes?

What specific calculation was done to arrive at 1500 byte ethernet MTUs, and what factors were considered for that calculation?

  • 3
    IEEE people are resisting adding 9k to the standard because mathematical guarantees FCS brings today at 1.5k would not all be true anymore at 9k.
    – ytti
    Aug 25, 2013 at 6:27
  • 6
    @ytti, that is only one of the arguments against endorsing > 1500 frames. The full text of Geoff Thomson's letter (containing the IEEE objections to standardizing jumbo frames) is in draft-ietf-isis-ext-eth-01 Appendix 1. The objections start with the word "Consideration" Aug 26, 2013 at 4:57
  • 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 can post and accept your own answer.
    – Ron Maupin
    Jan 3, 2021 at 1:18

5 Answers 5


padmaraj asked:

Why was ethernet MTU calculated as 1500 bytes?

What specific calculation was done to arrive at 1500 byte ethernet MTUs, and what factors were considered for that calculation?

Short story

The answer to "Why is Ethernet MTU calculated as 1500 bytes?" is layered. A lot depends on the Ethernet protocols in question. Unfortunately we don't always know in advance what Layer-2 protocol is wrapped by an Ethernet frame header.

Ethernet uses the two / four bytes after the source mac-address in different ways:

  • 802.1Q tagged frames use the FOUR bytes following the source mac-address as a vlan tag. 802.1Q is EtherType 0x8100
  • Untagged Ethernet II DIX frames use TWO bytes after the Ethernet source mac-address for a EtherType
  • 802.3 frames (such as 802.2 ISIS / Spanning-Tree) use TWO bytes after the Ethernet source mac-address as a Length field.

How do you know which Ethernet Layer-2 protocol we're parsing off the wire? Usually, we know from the MAC-layer EtherType, but 802.3 with 802.2 LLC encap doesn't have an EtherType.

Thus, the payload of ISO 802.2 LLC frames (such as ISIS or Spanning-Tree) should not exceed 1500 bytes. Other Ethernet protocols (such as Ethernet II DIX) unofficially can exceed 1500 bytes as long as their Ethernet PHY-layer doesn't depend on CSMA/CD.

Longer story

A lot depends on the Ethernet protocols in question. The most basic technique to read Ethernet headers is explained in draft-ietf-isis-ext-eth-01, specifically Section 3-5. Quoting from that RFC draft...

  1. Problem with Large Length interpretation Frames in the presence of Type Interpretation Frames

    Some protocols commonly used in the Internet have no reserved EtherType. An example is the set of ISO Network layer protocols, of which ISIS is a member. Such protocols are only defined to use the IEEE 802.3/802.2 encoding, and so their packets are limited in length to 1500 bytes.

    Type Interpretation frames have no length field. Protocols encapsulated in Type interpretation frames, such as IP, are not limited in length to 1500 bytes by framing.

I'm including an annotated diagram below of Ethernet II DIX and 802.3 frames, these illustrate where the conflicting bytes are in the ethernet header:

  • RFC 894 Ethernet II (DIX) frames have an EtherType after the source mac-address

        | DA | SA | EtherType | Data | FCS |
        DA           Destination MAC Address (6 bytes)
        SA           Source MAC Address      (6 bytes)
        EtherType    Protocol                (2 bytes: >= 0x0600 or 1536 decimal)  <---
        Data         Protocol Data           (46 - 1500 bytes)
        FCS          Frame Checksum          (4 bytes)
  • IEEE 802.3 with ISO 802.2 LLC / SNAP (used by [Spanning-Tree], ISIS) use these same bytes for Length; 802.2 ISO ISIS doesn't have an EtherType and Spanning-Tree doesn't have an EtherType. Therefore 802.2 frame payloads MUST be smaller than 1500 bytes in order for the Length field to avoid conflict with reserved EtherType values.

        | DA | SA | Len  | DSAP / SSAP / Ctl (DSC) | Data | FCS |
        DA      Destination MAC Address (6 bytes)
        SA      Source MAC Address      (6 bytes)
        Len     Length of Data field    (2 bytes: <= 0x05DC or 1500 decimal)  <---
        DSC     802.2 DSAP, SSAP, Ctl   (3 bytes)
        Data    Protocol Data           (46 - 1500 bytes)
        FCS     Frame Checksum          (4 bytes)

IEEE's objections to official Jumbo frame support

    General comments on the use of jumbo frames in Ethernet networks:

    Consideration #1: The expectation of no more than 15-1600 bytes
    between frames and an interpacket gap before the next frame is
    deeply ingrained throughout the design and implementation of
    standardized Ethernet/802.3 hardware. This shows up in buffer
    allocation schemes, clock skew and tolerance compensation and fifo

    Consideration #2: For some Ethernet/802.3 hardware (repeaters are
    one specific example) it is not possible to design compliant
    equipment which meets all of the requirements and will still pass
    extra long frames.  Further, since clock frequency may vary with
    time and temperature, equipment may successfully pass long frames
    at times and corrupt them at other times.  Therefore, attempts to
    verify the ability to send long frames over a path may produce
    inaccurate results.

    Consideration #3: The error checking mechanism embodied in the 4
    byte checksum has not been well characterized at greater frame
    lengths, but is known to degrade. Therefore the data reliability of
    transfers in long frame transfers will have a greater rate of
    undetected frame errors.

    Consideration #4: The length of frames proposed by this draft can
    not be assured to pass through standards conformant hardware. The
    huge value of Ethernet/802.3 systems in the data networking
    universe is their standardization and the resulting assurance that
    systems will all interoperate. No such assurance can be provided
    for oversize frames with both the current broadly accepted standard
    and the large installed base ofstandards based equipment.

    In summary with regard to greatly longer frames for Ethernet, much
    of the gear produced today would be intolerant of greatly longer
    frames.  There is no way proposed to distinguish between frame
    types in the network as they arrive from the media. Bridges might
    and repeaters would drop or truncate frames (and cause errors doing
    so) right and left for uncharacterized reasons. It would be a
    mess. What might seem okay for small carefully characterized
    networks would be enormously difficult or impossible to do across
    the Standard.


The safest Ethernet MTU is 1500-byte payloads; IEEE refuses to endorse Ethernet payloads > 1500 bytes. Depending on circumstances, we can CAUTIOUSLY increase Ethernet II payloads over the existing MTU of 1500-bytes.

If you want to implement jumbo frames (MTU > 1500), you should test your network to ensure you aren't breaking things in subtle ways. Thoroughly read IEEE's objections to jumbo frames (see above) before you test.

I will summarize with some simple guidance around jumbo frame support:

  • Ethernet 802.2 LLC ISIS / Spanning-Tree frames must NOT exceed a 1500-byte payload (to avoid EtherType / frame Length conflicts).
  • Ethernet II DIX frame payloads CAN exceed 1500 bytes on full-duplex links
  • Ethernet II DIX frame payloads must NOT exceed 1500 bytes on half-duplex links, which use CSMA/CD (and Ethernet CSMA/CD assumes the payload is <= 1500 bytes)
  • 802.1Q Frames cannot use 802.3 / 802.2 encapsulation, and 802.1Q frame payloads CAN exceed 1500 bytes on full-duplex links.

As mentioned above, if you implement jumbo frames, test to ensure you aren't breaking things.

FYI, I am including a link to pdf copies of the Ethernet Version 1 spec and Ethernet Version 2 spec, in case anyone is interested...

  • 2
  • 3
    Well, Ethernet II frames have their type field begin at 0x0600 (from the IEEE 802.3x-1997 spec) because the max max length of 802.3 was just below that. So that's just an effect, not a cause.
    – nos
    Aug 27, 2013 at 8:09
  • 1
    @nos, to claim that this is an effect instead of a cause presupposes that you can prove the cause... can you provide authoritative evidence for your proposed cause? The original Ethernet Version 1 spec published in 1980 already uses the Type field, and in 1984, the IP protocol was specified using Ethertype 0x0800 Aug 27, 2013 at 9:11
  • 2
    Indeed, the ethernet I and II spec already had a type field (which at that time had no restrictions), and already specified the max data length of 1500 - at that time there was no 802.3 frames. So one cannot conclude that the limit of 1500 was added in a later spec because of the type field.
    – nos
    Aug 27, 2013 at 10:45
  • 2
    @nos I disagree, Ethernet II had to coexist with the preexisting standard. And it also defined the use of the same field to act as both a type field in the prior standard and a length field in the new standard. Given that there MUST be NO possibility of confusion between the two standards, that must coexist in the same network, any length that could look like an existing type would not be allowed. As existing type list started at 0x600 a number less than that had to be chosen. To allow for no further expansion to the standard there had to be some band left available should it be needed.
    – user3104
    Oct 31, 2013 at 0:12

At the other end of the range - 1500 bytes, there were two factors that lead to the introduction of this limit. First, if the packets are too long, they introduce extra delays to other traffic using the Ethernet cable. The other factor was a safety device built into the early shared cable transceivers. This safety device was an anti-babble system. If the device connected to a transceiver developed a fault and started transmitting continuously, then it would effectively block any other traffic from using that Ethernet cable segment. To protect from this happening, the early transceivers were designed to shut off automatically if the transmission exceeded about 1.25 milliseconds. This equates to a data content of just over 1500 bytes. However, as the transceiver used a simple analogue timer to shut off the transmission if babbling was detected, then the 1500 limit was selected as a safe approximation to the maximum data size that would not trigger the safety device.

Source: http://answers.yahoo.com/question/index?qid=20120729102755AAn89M1

  • 6
    Hi @user1171: StackExchange preferred style is to include the answer material here, and link out as a reference. That way, when the link eventually rots, the answer is still useful. Aug 25, 2013 at 12:02
  • The jabber function required the MAU to shut down after 20 to 150 ms for 10 Mbit/s (IEEE 802.3 Clause, 40 to 75 kbit for Fast Ethernet (Clause and twice that for Gigabit Ethernet, far exceeding the frame length. The Yahoo post is wrong.
    – Zac67
    Jul 20, 2018 at 13:50

When Ethernet was originally developed as a shared medium or bus with 10Base5 and 10Base2, collisions of frames were frequent (what else you would expect in a connection where you fork the signal by drilling a tap into the cable) and expected as part of the design. Contrast this to today, when most everything is switched with separate collision domains and running full-duplex, where no one expects to see collisions.

The mechanism to share the "ether" employed CSMA/CD (Carrier Sense Multiple Access/Collision Detection)

Carrier Sense meant that a station wanting to transmit must listen to the wire -- sense the carrier signal -- to ensure no one else was talking since it was Multiple Access on that medium. Allowing 1500 bytes (though an arbitrary number as far as I can tell) was a compromise that meant a station could not capitalize the wire too long by talking too much at one time. The more bytes transmitted in a frame, the longer all other stations must wait until that transmission completes. In other words, shorter bursts or smaller MTU meant other stations got more opportunity to transmit and a fairer share. The slower the rate of the transmission medium (10Mb/s), stations would have longer delays to transmit as the MTU increases (if allowed to exceed 1500).

An interesting corollary question would be why the minimum frame size of 64 bytes? Frames were transmitted in "slots" that are 512 bits and took 51.2 microseconds for round-trip signal propagation in the medium. A station has to not only listen to when to start talking by sensing the IFG (interframe gap of 96 bits), but to listen for collisions with other frames. Collision Detection assumes maximum propagation delay and doubles that (to be safe) so it doesn't miss a transmission starting about the same time from the other end of the wire or a signal reflection of its own transmission when someone forgot the terminating resistor at the ends of the cable. The station must not complete the sending of its data before sensing a collision, so waiting 512 bits or 64 bytes guarantees this.


Originally, max. payload was defined as 1500 bytes in 802.3. Ethernet v2 supports frame length of >=1536 and this is what IP implementations use. Most carrier-class vendors support around 9000 bytes ("jumbo frames") these days. Since 1500 byte is the standard that all Ethernet implementations must support, this is what is normally set as default on all interfaces.

  • You should google maxValidFrame, it was defined by IEEE; consequently, the 9KB jumbo frame implementations that are common today are not officially compliant with Ethernet, but they work quite well for Ethernet II payloads Aug 24, 2013 at 18:00
  • Strictly speaking, not 802.3-compliant. IP uses Ethernet v2 though, so I tend not to even think of 802.3...
    – user661
    Aug 24, 2013 at 18:19
  • 5
    Jumbos are not compliant with Ethernet II or 802.3 after 802.3x was ratified. 802.3x Clause defines maxValidFrame at 1500B payloads. Thus after 1997, any payload exceeding 1500 bytes is not compliant. See the letter that the IEEE 802.3 chairman sent to IETF regarding this issue. In short, 802.3 is much more than a frame standard... it defines both framing and hardware requirements. This means the hardware implementations depend on compliance with the frame format. Half Duplex w/ CSMA-CD needs <= 1500B payloads. Aug 24, 2013 at 18:42

The minimum ethernet frame is based on the Ethernet Slot Time, which is 512 bit lengths (64 Bytes) for 10M ethernet. After subtracting 18 bytes for the ethernet header and CRC, you get 46 bytes of payload.

Ethernet Slot Time was specified so CSMA/CD would correctly function. One must be sure that the minimum frame size does not exceed the longest possible length of cable; if it did deterministic collision detection would be impossible. After collision detection at the maximum length of cable, you need the collision detection signal to return to the sender.

  • 4
    I'm having trouble understanding how the mechanism for determining the minimum ethernet frame size has anything to do with the current 1500 byte maximum defacto standard. Please elaborate!
    – Stuggi
    Oct 23, 2016 at 8:43
  • 3
    @Stuggi It doesn't.
    – Ken Sharp
    Jul 17, 2017 at 2:21

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