EtherType is a two-octet field in an Ethernet frame. It is used to indicate which protocol is encapsulated in the payload of an Ethernet Frame. The same field is also used to indicate the size of some Ethernet frames. EtherType was first defined by the Ethernet II framing standard, and later adapted for the IEEE 802.3 standard.
Overview
In modern implementations of Ethernet, the field within the Ethernet frame used to describe the EtherType also can be used to represent the size of the payload of the Ethernet Frame. Historically, depending on the type of Ethernet framing that was in use on an Ethernet segment, both interpretations were simultaneously valid, leading to potential ambiguity. Ethernet v2 framing considered these octets to represent EtherType while the original IEEE 802.3 framing considered these octets to represent the size of the payload in bytes.
In order to allow packets using Ethernet v2 framing and packets using the IEEE 802.3 framing to be used on the same Ethernet segment, a unifying standard (IEEE 802.3x-1997) was introduced that required that EtherType values be greater than or equal to 1536 (0x0600). That value was chosen because the maximum length (MTU) of the data field of an Ethernet 802.3 frame is 1500 bytes. Thus, values of 1500 and below for this field indicate that the field is used as the size of the payload of the Ethernet Frame while values of 1536 and above indicate that the field is used to represent EtherType. The interpretation of values 1501–1535, inclusive, is undefined.[1]
Jumbo frames
The size of the payload of non-standard jumbo frames, typically ~9000 Bytes long, falls within the range used by EtherType, creating a conflict. The proposition to resolve this conflict was to substitute the special EtherType 0x8870 when a length would otherwise be used.[2] However, the proposition was not accepted and it is defunct. The chair of IEEE 802.3 at the time, Geoff Thompson, responded to the draft outlining IEEE 802.3's official position and the reasons behind the position.[3] The draft authors also responded to the chair's letter, but no subsequent answer from the IEEE 802.3 has been recorded.[4] Currently, the value used for Ethertype in jumbo frames is not clear. The IEEE Registration Authority lists all the Ethertype values registered, and no reference to jumbo frames is found in the list.[5]
VLAN tagging
 |
This section provides insufficient context for those unfamiliar with the subject. |
With 802.1Q VLAN tagging and QinQ the sparse 16-bit EtherType is being completely used. The 16-bit EtherType not only tags the payload class, it also serves to help end any VLAN tagging or QinQ stacking. Via look-ahead peeking in streams, the 16-bit EtherType can help to confirm or package a QinQ 32+32+16=80-bit header between the 48-bit MAC addresses and the payload. Of those 80-bits only 32-bits are used for dynamic information. For a full 66-bit addressing system, 18 bits are needed beyond the MAC. Thus, additional EtherType values are required and used for Triple Tagging QinQinQ.
Inefficient and conservative use of a 16-bit Tag Protocol Identifier (TPID) on each four octets VLAN tag, followed by the trailing lone 16-bits creates a 48-bit signature that cannot easily be mistaken as part of the payload. Vendor implementations may avoid wasting bandwidth sending those 48-bits in proprietary link compression schemes. The EtherType usually does not contain any CRC or FCS information.
Examples
| EtherType | Protocol |
|---|---|
| 0x0800 | Internet Protocol version 4 (IPv4) |
| 0x0806 | Address Resolution Protocol (ARP) |
| 0x0842 | Wake-on-LAN[7] |
| 0x22F3 | IETF TRILL Protocol |
| 0x6003 | DECnet Phase IV |
| 0x8035 | Reverse Address Resolution Protocol |
| 0x809B | AppleTalk (Ethertalk) |
| 0x80F3 | AppleTalk Address Resolution Protocol (AARP) |
| 0x8100 | VLAN-tagged frame (IEEE 802.1Q) and Shortest Path Bridging IEEE 802.1aq[8] |
| 0x8137 | IPX |
| 0x8204 | QNX Qnet |
| 0x86DD | Internet Protocol Version 6 (IPv6) |
| 0x8808 | Ethernet flow control |
| 0x8819 | CobraNet |
| 0x8847 | MPLS unicast |
| 0x8848 | MPLS multicast |
| 0x8863 | PPPoE Discovery Stage |
| 0x8864 | PPPoE Session Stage |
| 0x8870 | Jumbo Frames (proposed)[2][3] |
| 0x887B | HomePlug 1.0 MME |
| 0x888E | EAP over LAN (IEEE 802.1X) |
| 0x8892 | PROFINET Protocol |
| 0x889A | HyperSCSI (SCSI over Ethernet) |
| 0x88A2 | ATA over Ethernet |
| 0x88A4 | EtherCAT Protocol |
| 0x88A8 | Provider Bridging (IEEE 802.1ad) & Shortest Path Bridging IEEE 802.1aq[9] |
| 0x88AB | Ethernet Powerlink[citation needed] |
| 0x88CC | Link Layer Discovery Protocol (LLDP) |
| 0x88CD | SERCOS III |
| 0x88E1 | HomePlug AV MME[citation needed] |
| 0x88E3 | Media Redundancy Protocol (IEC62439-2) |
| 0x88E5 | MAC security (IEEE 802.1AE) |
| 0x88E7 | Provider Backbone Bridges (PBB) (IEEE 802.1ah) |
| 0x88F7 | Precision Time Protocol (PTP) over Ethernet (IEEE 1588) |
| 0x88FB | Parallel Redundancy Protocol (PRP) |
| 0x8902 | IEEE 802.1ag Connectivity Fault Management (CFM) Protocol / ITU-T Recommendation Y.1731 (OAM) |
| 0x8906 | Fibre Channel over Ethernet (FCoE) |
| 0x8914 | FCoE Initialization Protocol |
| 0x8915 | RDMA over Converged Ethernet (RoCE) |
| 0x891D | TTEthernet Protocol Control Frame (TTE) |
| 0x892F | High-availability Seamless Redundancy (HSR) |
| 0x9000 | Ethernet Configuration Testing Protocol[10] |
Not all well known de facto uses of EtherTypes are always recorded in the IEEE list of EtherType values.[11] For example, EtherType 0x0806 (used by ARP) appears in the IEEE list only as "Symbolics, Inc., Protocol unavailable."[11] However, the IEEE Registration Authority lists all the accepted EtherTypes, including the 0x0806.[5]
https://en.wikipedia.org/wiki/EtherType