Talk:IEEE 802.1Q

This is the talk page for discussing improvements to the IEEE 802.1Q article.
This is not a forum for general discussion of the article's subject.

Put new text under old text. Click here to start a new topic.
New to Wikipedia? Welcome! Learn to edit; get help.

Article policies

Find sources: Google (books · news · scholar · free images · WP refs) · FENS · JSTOR · TWL

Archives: 1: 365 days

Computing: Networking Low‑importance

	This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.ComputingWikipedia:WikiProject ComputingTemplate:WikiProject ComputingComputing articles
Low	This article has been rated as Low-importance on the project's importance scale.
	This article is supported by Networking task force (assessed as Mid-importance).

Case of 'Q'[edit]

Note that the 'Q' is supposed to be upper case; see the IEEE web site: http://www.ieee802.org/1/pages/802.1Q.html. Although lower case is commonly used, it is technically incorrect. --Rick Sidwell 06:33, 17 December 2005 (UTC)[reply]

Addressed at some point. All Qs are capital now. ~Kvng (talk) 03:43, 2 August 2019 (UTC)[reply]

Update of figure two[edit]

The text related to figure two states: "...in such cases, an alternate TPID such as hex 9100, or even 9200 or 9300, sometimes may be used for the outer tag; however this is being deprecated by 802.1ad, which specifies 88a8 for service-provider outer tags."

Shouldn't the figure TPID field then be changed to 88a8 since that is what is being usedm not 9100? —Preceding unsigned comment added by 77.110.39.122 (talk) 09:50, 26 November 2008 (UTC)[reply]

The figure was updated at some point and now shows 88a8. ~Kvng (talk) 03:41, 2 August 2019 (UTC)[reply]

Overall Frame Length - 1500[edit]

There is an error in the diagrams. The overall frame length should be bounded by the standard sizes of 64bytes - 1518 bytes. This should be the case regardless of the number of VLAN tags added.

Thus, the diagrams should read n=42-1496 for the single tagged frames, and n=38-1492 for the double tagged frame. —Preceding unsigned comment added by Neilneil2000 (talk • contribs) 11:37, 17 August 2009 (UTC)[reply]

Not so. .1q extends the maximum frame size so that tagged frames can still have a payload of 1500 bytes. --Stefan Bethke (talk) 10:00, 25 July 2010 (UTC)[reply]

A cooperative change in the 802.3 standard allows for the slightly longer transmissions to retain the 1500 byte payload with 802.1Q. ~Kvng (talk) 03:46, 2 August 2019 (UTC)[reply]

66-bit Addressing[edit]

Some amendmens have been made that add an explanation of using tagged frames for extended addressing. The relevant changes are:

VLAN Identifier (VID) is extended to read: The 12-bit field can be partitioned into two 6-bit fields to extend the Destination and Source 48-bit addressing. With Triple-tagging 18 bits are added to the 48 resulting in 66 bits of addressing.
Triple-tagging is extended: The 12-bit VID fields extend the 48-bit Destination and Source addressing to 66 bits. The middle 3-bit PCP field could be used as a Virtual TTL or Hop-Count to ensure packets do not circulate forever. A more complex ingress-egress encoding overloads one of the bits. The last 3-bit PCP field is used for Content Rating - 000 NR to 111 XXX. The three CFI bits are combined to encode the Next Header (or Protocol) found in the Payload Section. Only two of the CFI bits can be used, resulting in four protocols. [NOP,ICMP,UDP,ENCAP] The NOP (No Protocol) is a tiny Payload Section mostly for IP byte/pipe streams. ICMP provides control. UDP adds Ports, a semi-redundant length and an optional Checksum from IP. The ENCAP protocol or Payload Type allows all of the above to be ENCAPsulated without the Preamble but including CRC/FCS. With ENCAP the tags, TTL and length are placed in front of the 48-bit address fields to allow hardware to process those bits first, reducing latency.

There is no basis in IEEE or other standards, vendor implementations or elsewhere. If you have references describing frames extended in such a way, please feel free to add the explanations back with those references. I have reverted those changes again. —Preceding unsigned comment added by Stefan Bethke (talk • contribs) 10:07, 25 July 2010 (UTC)[reply]

This 66-bit addressing topic is mentioned in one paragraph in the article. If it is notable, it needs to be properly introduced. If it is not notable, we should, of course, remove it. --Kvng (talk) 15:41, 28 September 2010 (UTC)[reply]

Triple tagging is no longer mentioned. ~Kvng (talk) 03:51, 2 August 2019 (UTC)[reply]

Probably citation of wrong standard[edit]

[...]but the current (IEEE Std 802.1D- 2004) standard does not use the terms trunk or native.[...] -> I'm not quite sure, but 802.1D is "Rapid Spanning Tree Protocol" so shouldn't we instead refer to 802.1Q here? 217.91.83.80 (talk) 12:35, 27 January 2011 (UTC)[reply]

This text is no longer in the article. Despite what IEEE 802.1D seems to be saying, my recollection is that VLAN tagging was first described in 802.1D and then it was split out into 802.1Q. As mentioned elsewhere here, it would be helpful to have a history section to lay all this out. ~Kvng (talk) 03:57, 2 August 2019 (UTC)[reply]

Incorrect order of header fields in image "Frame Format"[edit]

The correct order of the header fields is DMAC, SMAC, Type, Dot1Q tag, and so on. This article's header image shows the Dot1Q tag preceding the Type field. But the Type field value of 0x8100 indicates that a Dot1Q tag is the following field in the header. The Dot1Q tag shouldn't precede the Type field. Note when the Type field is less than 1500 (decimal) is denotes the payload size of the frame in bytes and is known as the Length. When the Type field is over 1536 it denotes the Type of payload. Some examples are: IPv4 – 0x0800 IPv6 – 0x86dd ARP – 0x0806 802.1Q – 0x8100 45.30.36.245 (talk) 23:07, 26 April 2023 (UTC)[reply]

You're wrong. The 802.1Q squeezes in in front of the EtherType field. The 0x8100 field is already part of the Q tag and the actual EtherType follows the Q tag. --Zac67 (talk) 06:03, 27 April 2023 (UTC)[reply]

The type field 0x8100 indicates this is 802.1Q encapsulation. A new type field is added at the end of the encapsulation to serve the payload. ~Kvng (talk) 14:04, 30 April 2023 (UTC)[reply]