Talk:EtherType

Ethernet II Prevalence

I seriously doubt that e.g. 802.3 is "the way we do IP traffic today" as was implied by this article prior to my changes. AFAIK Ethernet Version 2 is and remains the way most Internet Protocol networks are set up.

I do understand that the IEEE most dearly would like 802.3 to be used instead of Ethernet Version 2, and as writers of textbooks and the like tend to listen to people with big mouths they readily sometimes believe that 802.3 is a common protocol. It is not. Ethernet Version 2 is very very common though. It is the default behaviour of e.g. Microsoft Windows and Linux to use Ethernet Version 2.

Prove me wrong - empirically. — Preceding unsigned comment added by Nixdorf (talk • contribs) 15:45, 19 December 2002 (UTC (UTC)

The article no longer says that and, as of 1997, IEEE 802.3 supports using the 2-byte field after the source MAC address as a type field or a length field, by disallowing type field values < 1536. Guy Harris (talk) 23:42, 29 August 2016 (UTC)

802.3 Compatibility

Taken from other 802.3 twiki: IEEE 802.3x-1997 allows the 16-bit field after the MAC addresses to be used as a type field or a length field, so that Ethernet II frames are also valid 802.3 frames in 802.3x-1997 and later versions of the IEEE 802.3 Ethernet standard. — Preceding unsigned comment added by 194.149.124.54 (talk • contribs) 12:48, 24 February 2006 (UTC)

Ant the article now says that. Guy Harris (talk) 23:44, 29 August 2016 (UTC)

EtherType Database

I work as a technical consultant to the IEEE Registration Authority for evaluating new EtherType assignments. At the recent July 07 meeting of the IEEE Registration Authority Committee (RAC), we had a long discussion about the poor quality of information about existing EtherType assignments in the IEEE's public EtherType listing. They decided NOT to undertake a project within the IEEE to update and expand the information content in their EtherType public listing, and instead I was instructed to contact Wikipedia about the possibility that they should host the definitive list of EtherType assignments.

The fundamental problem is that the IEEE listing is basically just a transaction log showing who made the request for each assigned EtherType, without attempting to track who is currently responsible for maintaining the protocol. As a result: (1) there is very little information about long-standing EtherType assignments (that happened before the responsibility for EtherType assignments shifted from Xerox to the IEEE); and (2) it is difficult to determine what protocol belongs to each EtherType, even for well-known protocols defined by IEEE and/or IETF standards. For example, the EtherType value 0x8808 is used for the MAC Control Frames as defined in 802.3x-1997, but the IEEE public EtherType listing says it belongs to Bay Networks with ``protocol unavailable. OTOH, at least you can find the EtherType by looking it up in the Ethernet standard (IEEE Std 802.3-2005, clause 31.4.1.3).

The situation is much worse for IETF standards, because the RFC documents don't get edited to include the EtherType value after it has been assigned. For example, the definition of ARP in RFC 826 (aka STD0037) does not include EtherType value 0x0806, but merely refers to it mnemonically as ``ether_type$ADDRESS_RESOLUTION. Although the EtherType value for ARP was listed in RFC 1700, that document was obsoleted by RFC 3232 moving the responsibility for assigned numbers to an online repository at IANA -- which for EtherTypes points to the IEEE public listing which does not mention ARP, and says that 0x0806 belongs to Symbolics, Inc. with "protocol unavailable".

So the bottom line is, can we rely on the Wikipedia entry for EtherTypes to be used as the definitive reference for the usage of existing EtherType values? I would work to make sure sure that all entries for IEEE protocols are complete and up-to-date, and would ask the IETF to do the same for their protocols. I can also ask that the applicant for each newly-assigned EtherType value take responsibility for maintaining their own entry. Does this make sense? Comments please! DrBLAM 22:20, 30 July 2007 (UTC)

Your suggestion appears to be at odds with comments in the wiki source which discourages adding any but common protocols to the table published there. I've added to the table anyway. --Kvng (talk) 18:18, 22 May 2008 (UTC)

Same for me. I think its better to have a place like wikipedia to keep track of the numbers then to have nothing at all, or outdated info on IEEE lists. User:Psy —Preceding unsigned comment added by 80.101.176.184 (talk) 12:50, 19 November 2009 (UTC)

If we think a complete list is important, someone could create List of EtherTypes or somesuch. There is precedent for this in List of IP protocol numbers. Despite my previous infractions I don't support including everything and I'm not saying I think that List of EtherTypes is a great idea, just that it is an option we can discuss. ~KvnG 19:56, 23 October 2013 (UTC)

Wikipedia as a definitive reference? Be careful what you ask for....

And List of IP protocol numbers isn't the definitive reference for IP protocol numbers; the IANA's registry is the closest thing to a definitive reference. Guy Harris (talk) 23:53, 29 August 2016 (UTC)

Yes, terrible idea. IEEE or someone else needs to track this stuff. This is not Wikipedia's role in the infosphere. ~Kvng (talk) 14:04, 1 September 2016 (UTC)

It is worth noting that the IEEE list also contains several cases where the same value is assigned to multiple entities (eg: 0x8101). — Preceding unsigned comment added by Schallee (talk • contribs) 21:13, 21 December 2018 (UTC)

Table Order

I would like to suggest that the order in the table is sorted in increasing EtherType value. As it is right now the table is not ordered in a fashion that seems to follow a coherent order. —Preceding unsigned comment added by 77.110.39.122 (talk) 09:31, 26 November 2008 (UTC)

Seems to have been taken care of at some point. ~KvnG 20:02, 23 October 2013 (UTC)

Corrections?

The list has an Ethertype 0x88b5 used for 'AVB Transport Protocol', although this is reserved for local experimentation by IEEE (as defined in 802a-2003). Maybe this came from an early draft proposal? In any case, it should be removed or updated, but I am not sure if it actually has an assigned type (couldn't find this quickly in the IEEE AVB workgroup pages) 78.108.141.146 (talk) 10:23, 19 January 2010 (UTC)

This is probably referring to IEEE 1722. This standard is not yet ratified. Inclusion is premature. I have deleted it. --Kvng (talk) 16:04, 19 January 2010 (UTC)

The page notes 'For example, EtherType 0x0806 (used by ARP) appears in the IEEE list only as "Symbolics, Inc., Protocol unavailable."', this may have been true at the time of access, the IEEE list now specifies 'Address Resolution Protocol - A. R. P.' --84.207.234.67 (talk) 08:29, 19 July 2019 (UTC)

Yes, but it doesn't list 0x0800! I've updated the section to reflect that. Guy Harris (talk) 17:22, 19 July 2019 (UTC)

It does list 0800 now when I just accessed it. Organization "Xerox" and "IPv4 Internet Protocol Version" with a comment pointing to RFC894. 2601:646:C500:119:ED08:AC03:601A:6D39 (talk) 00:35, 3 November 2022 (UTC)

Contribution

This paragraph was added to the lead by 75.57.165.178 (talk · contribs). It does not belong in the lead through the information may be useful for the body, in 802.1Q or QinQ. --Kvng (talk) 14:02, 25 September 2010 (UTC)

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 32-bit VLAN Tag, followed by the trailing lone 16-bits creates a 48-bit Signature that can not easily be mistaken as part of the PayLoad. Vendor implementations may avoid wasting band-width sending those 48-bits in proprietary link compression schemes. The EtherType is not expected to contain any CRC or FCS information.

What on earth is this "full 66-bit addressing system" that suddenly crops up here and on the 802.1Q article? I smell a rat trying to sell their wonderful new network appliance... 2.151.244.173 (talk) 20:39, 24 July 2011 (UTC)

So by "the sparse 16-bit EtherType is being completely used" do they mean "all values between 1536 and 65535 have now been assigned"? I don't believe that to be the case. Guy Harris (talk) 23:48, 29 August 2016 (UTC)

Examples inclusion criteria

This comment appears at the beginning of the Example section: <!-- please don't add any protocol you find here. This is for [[WP:N|NOTABLE]] protocols. Any protocol added should minimally have an article elsewhere on Wikipedia. -->

I don't know who put it there but it's been there for years and seems to be good policy and I have assumed there is consensus on this. ~Kvng (talk) 14:12, 9 February 2017 (UTC)

Add AVTP Ethertype to the table

Suggest adding AVTP EtherType (0x22F0 - ref. IEEE Std 1722-2016 section 4.4.2) to the table of EtherType values. 62.219.254.22 (talk) 15:00, 15 October 2017 (UTC)

So go ahead and implement your suggestion. Guy Harris (talk) 18:26, 15 October 2017 (UTC)

This is not intended to be a comprehensive list. An HTML comment at the top of the section says, "Please don't add any protocol you find here. This is for NOTABLE protocols. Any protocol added should minimally have an article elsewhere on Wikipedia." Although IEEE 1722 is mentioned in Audio Video Bridging, I don't think AVTP meets the requirements set out in the comment. I'm happy to discuss whether the comment reflects what we actually want to include. ~Kvng (talk) 14:27, 17 October 2017 (UTC)