Ethernet 802.3 vs. Ethernet II Frame

[AdamBudzinski]

hi guys,

there are 2 types of Ethernet framing:  802.3 and Ethernet II. 

according to cisco "Ethernet II is the Ethernet frame format used in TCP/IP networks." So what about the 802.3 Frame ? I'm nor really able to find any explanation....

Thank you in advance and regards

Adam 

EDIT: Did a small test in Packet Tracer and Wireshark and the Frame is actually an Ethernet II frame, as an example:

[Peter Paluch]

Hi Adam,

Years ago, I recall we had a similar discussion here already, and I was able to find out the post I've written back then. You might be interested in reading it. Of course please come back with any questions you may have!

https://supportforums.cisco.com/discussion/11691016/ether-frames-8023-naming-conventions

Best regards,
Peter

[AdamBudzinski]

Hi Peter,

thank you for your comment. I think it's even more confusing to me now :/ also in the other post you both mentioned CCIE and I'm preparing for CCNA (maybe  it is out of scope) bur for any reason (that's why the question) i have the impression that CISCO focuses more on the 802.11 Frame even if the Ethernet II frame is, like you said and the CISCO training's are referring to be the one used today. I'm confused. 

Best regards,

Adam

[Peter Paluch]

Hi Adam,

I can understand you are confused, these are quite detailed things about the Ethernet operation.

However, to clear up things, I would need to know what confuses you the most. Can you pinpoint one or two things that confuse you the most? We will start with those and then see how it unravels.

Best regards,
Peter

[AdamBudzinski]

Hi Peter,

that sounds great :) ! 

ok. so basically the DIX standard aka Ethernet II Frame is the standard used today. When i use Packet Tracer i see the Ethernet II Frame fields (not 802.3), same when I use Wireshark (beside the fact that I'm missing the Preamble and FCS but this is normal) i see the Destination, Source, Type and User Data Fields)., again this looks to me like an Ethernet II Frame BUT when i look for Ethernet on the web (wikipedia, wireshark doc) they all refer to the 802.3 Frame Format. Where I'm going to see thie 802.3 Frame ? 

Best Regards

Adam 

[Peter Paluch]

Hi Adam,

The best is to use Wireshark - I am not sure how precise is Packet Tracer in these details.

Whether you see frames in your Wireshark as Ethernet II, 802.3 or SNAP depends on what traffic you have captured. Because of historical and functional reasons, different types of higher protocols use different frame formats.

Please unzip and open the attachment of this post in your Wireshark - you will find 5 frames there I captured within less than 60 seconds on my company network.

The first two frames are frames carrying a certain type of Spanning Tree Protocol called MSTP. Notice that Wireshark calls them IEEE 802.3 Ethernet, and when you open the frame header, you will find the following fields: Destination, Source, and Length. Further, you will see the Logical-Link Control header that contains three further fields: DSAP, SSAP, and Control. So this is in fact a 802.2 LLC frame, or, 802.3 container plus 802.2 LLC header, plus the body which, in this case, is MSTP message.

Frames three and four contain a simple ping and a response to this ping. These frames are Ethernet II frames. When you open the Ethernet II header, you will see three fields: Destination, Source, and Type (recall that in 802.3, there was the Length field instead of Type). There is no Logical-Link control in these frames, and the frame payload starts immediately after the Type field.

Finally, the last frame is the frame of a so-called Cisco Discovery Protocol. Notice again that this frame is identified as IEEE 802.3 Ethernet containing the Destination, Source, and Length in the 802.3 header. Then comes the Logical-Link Control header containing the usual DSAP, SSAP and Control fields, but in addition, this time, there are two more fields that comprise the so-called SNAP header: Organization Code and PID (Protocol ID). So in fact, this last frame is an 802 SNAP frame.

To put it simply, if you are going to look at an IPv4 or IPv6 communication, it will be practically always encapsulated into Ethernet II frames because those are the most efficient in terms of overhead. 802.3 + LLC frames are used nowadays mostly for older protocols authored by IEEE itself, such as STP/RSTP/MSTP. SNAP frames are often used for vendor-proprietary Layer2 protocols - Cisco uses it for CDP, DTP, VTP and PAgP, to name a few.

Any and all questions are welcome!

Best regards,
Peter

[AdamBudzinski]

OMG Peter this is awesome ! 

So basically (correct me if I'm wrong) we could say that we have to styles of Ethernet framing :

1. DIX or Ethernet 2 / Ethernet II 

2. 802.11

? 

EDIT: an the frame format depends on the Layer 2 Protocol used, correct ? 

Best Regards

Adam 

[Peter Paluch]

Hi Adam,

So basically (correct me if I'm wrong) we could say that we have to styles of Ethernet framing :

Just a small correction. In wired (copper, fiber) Ethernet networks, we commonly have three Ethernet frame variants:

1. Ethernet DIX = Ethernet II
2. 802.2 LLC (Wireshark displays this as 802.3 + LLC)
3. 802 SNAP (this is an extension of 802.2 LLC, Wireshark displays this as 802.3 + LLC + Organizational code + PID)

The 802.11 is a wireless standard (the WiFi as we call it) - it uses a frame that has significantly more fields and is much more complex. I suggest you do not bother with this frame format too much.

EDIT: an the frame format depends on the Layer 2 Protocol used, correct ? 

The frame format is the Layer2 protocol. The choice of Ethernet frame formats is on the higher protocol above Layer2 that asks Layer2 to provide specific encapsulation capabilities.

Let me put it this way: When a software engineer writes an IPv4 driver for an operating system, a part of this IPv4 driver has to use the frame transmission facilities provided by the driver of the network card. When calling the functions to transmit a frame, the IPv4 driver also tells the network card driver how it wants the packet to be encapsulated - whether it should be DIX, 802.2 LLC or 802 SNAP. Theoretically, it could be any one of these. However, a part of formal specification of IPv4 also deals with how the packets shall be encapsulated into various data link layer frames including Ethernet. So for IPv4, there are several normative references:

RFC 894 says:

   IP datagrams are transmitted in standard Ethernet frames.  The type
   field of the Ethernet frame must contain the value hexadecimal 0800.
   The data field contains the IP header followed immediately by the IP
   data.

So there you have it - you are supposed to use the Ethernet frame that uses the Type field which is, obviously, DIX.

When IEEE took the DIX Ethernet and came up with its own 802.3 Ethernet, 802.2 LLC and 802 SNAP, another RFC - this time, RFC 1042 - came out that dealt with encapsulating IPv4 into these IEEE frame formats. This RFC is more complex to read but it basically stipulates that for 802.3 Ethernet networks, the 802 SNAP shall be used.

So what shall the software engineer go with? If these two normative documents allow the engineer to make either choice then he should be ultimately fine with any of those. However, in this particular case, because RFC 894 - and DIX Ethernet frame format - existed sooner than IEEE Ethernet, and the payload size in DIX Ethernet is the biggest out of all Ethernet frame variants (1500 bytes), the use of DIX Ethernet format has become the de fact standard.

In fact, precisely because of this, the DIX Ethernet format has become the de facto standard for most deployments whatsoever. The fact that you still see the 802.2 LLC or 802 SNAP frames is backward compatibility with applications that were originally designed to use these frame types, or the added flexibility of the SNAP encapsulation (but I won't go into that right now) - at the expense of losing up to 8 bytes from each frame payload for additional header fields.

So, to sum this up, what frame format is going to be used depends on the software (at this level, usually a driver or an extremely low level system service) that asks the network card driver to transmit some data. The particular choice is usually decided by the author of the software. We could go into technical advantages and disadvantages of every frame format - something we have not covered yet in our discussion here - which are driving the software engineers choice, but in general, the Ethernet II (DIX), or in some cases, the SNAP are the ways to go, and Ethernet II is by far the most popular.

I hope I haven't caused more confusion again... As always, please feel welcome to ask further!

Best regards,
Peter

[AdamBudzinski]

Hi Peter, 

thank you for taking time to answer me. It definitely makes more sense to me know. If you don't mind i would like to ask few more questions to get a better idea. 

"The choice of Ethernet frame formats is on the higher protocol above Layer2 that asks Layer2 to provide specific encapsulation capabilities."

Which OSI layer would this be ? 

When calling the functions to transmit a frame, the IPv4 driver also tells the network card driver how it wants the packet to be encapsulated - whether it should be DIX, 802.2 LLC or 802 SNAP.

Is the IP driver representing somehow the higher layer  ? And also do you mean that it communicates with the network driver that i communicates with the LLC Sublayer ? 

Best Regards

Adam 

[Peter Paluch]

Hi Adam,

You are welcome.

"The choice of Ethernet frame formats is on the higher protocol above Layer2 that asks Layer2 to provide specific encapsulation capabilities."

Which OSI layer would this be ? 

It would be either a Layer3 protocol such as IPv4 or IPv6, or a Layer2 protocol that does not deal with frame formatting itself but needs to carry its messages directly in frames, such as CDP or STP. In general, sorting protocols into layers is sometimes a reason to start a flamewar, as our protocols are not created strictly according to the OSI model and so they often do not fit perfectly :)

When calling the functions to transmit a frame, the IPv4 driver also tells the network card driver how it wants the packet to be encapsulated - whether it should be DIX, 802.2 LLC or 802 SNAP.

Is the IP driver representing somehow the higher layer  ? And also do you mean that it communicates with the network driver that i communicates with the LLC Sublayer ?

Yes, the IP driver is an embodiment, or an implementation, of a particular Layer3 functionality. You see, a protocol on a certain OSI layer is just a set of rules, but it needs to be implemented, written as a software code or constructed as a hardware, in order to start to really exist.

And yes, when the IP driver needs to send or receive its packets over an Ethernet card, it can be assumed to communicate with the LLC sublayer implementation in the Ethernet card driver.

Best regards,
Peter

[AdamBudzinski]

Hi Peter,

thank you. Could you just please answer me very last question clear my doubts...

Which Data Link Sublayer is responsible for framing ? I mean, when I look on Ethernet is defined at the Physical Layer and Data Link's MAC Sublayer. So i would say that it's the MAC's sublayer job. If so, could you than say that the LLC  Sublayer is a form of a let's call it bridge to connect the software layers with the physical / hardware layers ? 

a BIG thank you Peter

Best Regards

Adam 

[Peter Paluch]

Hi Adam,

Which Data Link Sublayer is responsible for framing ?

It is the MAC sublayer.

If so, could you than say that the LLC  Sublayer is a form of a let's call it bridge to connect the software layers with the physical / hardware layers ?

Very good! It is that, and even more. The MAC sublayer in Ethernet will allow you to transmit data in the form of [Destination, Source, Message, Checksum]. Notice how crude this is: No information about what the Message really is, no connection-oriented communication, no reliability, no ordered delivery, no acknowledgements, no retransmissions, no flow control. All these features - if present - are implemented by the LLC sublayer:

• LLC helps identify the type of the Message part. If using Ethernet II, this is accomplished by the Type field in the frame header. If using 802.2 LLC or SNAP, this is accomplished by the DSAP, SSAP, Control, and optionally the SNAP fields in the frame header.
• LLC provides capabilities to establish a connection before exchanging frames. Ethernet II frame does not have specific frame fields to accomplish this. In 802.2 LLC and SNAP, additional fields and whole messages can be added to provide for connection establishment and termination.
• LLC provides capabilities for ordered frame delivery (numbering frames), acknowledgements, and retransmissions. Again, in Ethernet II frame, there are no such fields. In 802.2 LLC and SNAP, additional frame fields can be added to provide for frame sequencing, acknowledgements, and retransmissions.

The truth is, Ethernet can be connection-oriented and reliable if software engineers want it to! :) However, it makes the communication over Ethernet more complex, as these LLC features have to be implemented in software, and because there is extremely little demand for these features on Ethernet, they are not routinely a part of common NIC drivers, so software engineers would often need to implement these features themselves.

The most commonly seen function of the LLC sublayer is identifying the payload type of the frame, so that a single Ethernet network can be used to carry multiple higher protocols at the same time and still processing each of them correctly. The added features about the reliability, sequencing, connection-oriented operation - those are very rare in Ethernet, even though not unheard of.

As always, feel free to ask further!

Best regards,
Peter

[AdamBudzinski]

Peter,

i need to ask again (sorry, you WAY to good to let you go so quickly :D), you wrote:

"the LLC sublayer is identifying the payload type of the frame"

So in a Ethernet II Frame the value of 0x800 (I'm referring to packet 3 and 4 in your Wireshark capture) would indicate that the frame has an IPv4 packet , correct ? 

CISCO says (i know we are not talking now about the Ethernet II Frame)

"Length Field: For any IEEE 802.3 standard earlier than 1997 the Length field defines the exact length of the frame's data field."

So, does that me that Length = Data - Header (I'm referring to the 802.2 Header and Data Filed). 

Thank you in advance Peter.

Have a great day !

Best Regards

Adam

[Peter Paluch]

Hi Adam,

Thank you :)

So in a Ethernet II Frame the value of 0x800 (I'm referring to packet 3 and 4 in your Wireshark capture) would indicate that the frame has an IPv4 packet , correct ? 

Yes, absolutely correct. Ethernet frames carrying IPv4 have 0x0800 in their Type. Frames carrying ARP messages have 0x0806 in the Type field. Frames carrying IPv6 packets have 0x86DD in the Type field. Every unique protocol that is encapsulated into an Ethernet II frame will have a unique Type value. There is a public listing of all officially registered Type values - you can download it here:

https://standards.ieee.org/develop/regauth/ethertype/eth.txt

"Length Field: For any IEEE 802.3 standard earlier than 1997 the Length field defines the exact length of the frame's data field."

This statement is misleading. What it really tries to convey is that the revisions of the 802.3 standard earlier than 1997 said this (quoting from a 1985 revision):

The length field is a 2-octet field whose value indicates the number of LLC data octets in the data field.

and also had a footnote saying:

Packets with a length field value greater than those specified in 4.4.2 [1500 bytes] may be ignored, discarded, or used in a private manner. The use of such packets is beyond the scope of this standard.

So in other words, these older 802.3 revisions did not formally acknowledge or endorse the existence of Ethernet II frame format but at the same time, they did not consider it to be invalid - they simply said that it is beyond the scope of what they standardized.

However, this is no longer the case. To prove my point, check out this document:

http://standards.ieee.org/getieee802/download/802.3-2012_section1.pdf

You will need to select "Academic/Student" down at the page in the scrollbox and hit the ACCEPT button to actually download this file for free. Now, jump to the page numbered as 56 in the PDF file (it is actually page 110 of the PDF) and see the section 3.2.6 Length/Type field. It says:

This two-octet field takes one of two meanings, depending on its numeric value. For numerical evaluation, the first octet is the most significant octet of this field.
a) If the value of this field is less than or equal to 1500 decimal (05DC hexadecimal), then the Length/Type field indicates the number of MAC client data octets contained in the subsequent MAC Client Data field of the basic frame (Length interpretation).
b) If the value of this field is greater than or equal to 1536 decimal (0600 hexadecimal), then the Length/Type field indicates the Ethertype of the MAC client protocol (Type interpretation). The Length and Type interpretations of this field are mutually exclusive.

So simply, every time your computer receives an Ethernet frame, it looks at the 2-byte-long header field right after the Source MAC. If the value in this field is 1500 or less, this is a 802.2 LLC or SNAP frame, and the field is to be interpreted as Length. If the value in this field is 1536 or more, this is an Ethernet II frame, and the field is to be interpreted as Type. It is as simple as that, and this has been the way Ethernet has always operated.

Just to complete the thought, once you know that you have 802.2 LLC frame, knowing if it is "just" 802.2 LLC, or if it is 802 SNAP, is simple. SNAP frames will have the value 0xAA in both DSAP and SSAP fields of the LLC header. Any other value in either of these two fields means that this is not a SNAP frame.

Your further questions are welcome!

Best regards,
Peter

P.S.: Forgot to answer one of your questions so editing the post now. If the 802.2 LLC or 802 SNAP format is used, then the Length says how long is the entire "802.2 Header and Data field" - it is exactly that value between 46 and 1500.

[AdamBudzinski]

Hi Peter,

Hmm, so if the Length Filed (in a 802.3 container plus 802.2 LLC header Frame) is indicating how long the entire "802.2 Header and Data field" is, so I cannot imagine for what this filed could be use  . . . or is it purely to distinguish between a Ethernet II and 802.2 LLC , 802.2 SNAP frame, no less and more ? 

Also, when i look again at your Wireshark capture (on the first packet) and i browse the IEEE 802.3 Ethernet Frame I see the Length value (is it in bits? ) but I'm missing the 802.2 Header and Data Filed. 

Am I missing something ? Could you please clarify ? 

Best Regards

Adam